Direct Enrollment (DE) permits consumers to purchase a Marketplace health plan from a source other than Healthcare.gov; however, the process was cumbersome – consumers had to be redirected to Healthcare.gov to fill out the official application, and once they receive the eligibility notification, they would be redirected back to the web broker’s site. This multi-step process led many consumers to prematurely “drop off” due to confusion or errors.
The Centers for Medicare and Medicaid Services released detailed guidance to implement the Enhanced Direct Enrollment (EDE) pathway in February 2018.
The DE and EDE pathways are only available for states that use the Federally Facilitated Exchange (FFE), also known as the Marketplace, or State-based Exchange on the Federal Platform (SBE-FP), totaling 36 states.
What Is Direct Enrollment (DE)?
The Direct Enrollment (DE) allows approved Qualified Health Plan (QHP) issuers and third-party web-brokers (online insurance sellers) to enroll consumers in Exchange coverage, with or without the assistance of an agent/broker, directly from their websites. This allows for a greater variety of insurance offerings, not limited to those in HealthCare.gov.
As described, the consumer in the “Classic” DE experience, starts on a DE entity’s website. The issuer or web broker redirects users to HealthCare.gov to complete the eligibility application portion of the process. After completing their eligibility application, HealthCare.gov redirects the user back to the issuer or web broker website to shop for a plan and enroll in Exchange coverage.
The DE website manages the Plan selection and enrollment in Exchange for coverage for those applications approved by HealthCare.gov (cuidadodesalud.gov if in Spanish).
What Is Enhanced Direct Enrollment (EDE)?
The Enhanced Direct Enrollment (EDE) provides a comprehensive consumer experience including the eligibility application, Exchange enrollment, and post-enrollment year-round customer service capabilities for consumers and agents/brokers, directly on issuer and web-broker websites.
EDE entities build and host a version of the HealthCare.gov eligibility application directly on their websites that securely integrates via a suite of FFE application programming interfaces (APIs) that facilitate the eligibility, enrollment, and post-enrollment experience.
There are three (3) phases for implementation, where Phase 3 covers all possible use cases (e.g. native Americans, Dependents’ applicants who are not daughters, sons, or spouses, etc.).
How Do Issuers and Web-brokers Implement EDE?
EDE entities assist consumers with applying for coverage through an Exchange, as well as applying for Advanced Payments of the Premium Tax Credit (APTC), Cost-Sharing reductions (CSRs), and with electing QHPs.
Issuers and web-brokers can participate in EDE as a primary EDE entity, or as an upstream EDE entity. Primary EDE entities build the EDE platform, whereas upstream EDE entities leverage a primary EDE entity’s platform, usually with customized branding for the upstream entity.
Upstream EDE entities manage the “EDE end-user experience” which consists of all aspects of the pre-application, application, plan shopping, plan selection, enrollment, and post-enrollment experience and any data collected necessary for those steps or for the purposes of any authorized functions.
Primary EDE entities must undergo an extensive third-party audit of their EDE application and privacy/security structure, along with a CMS approval process and ongoing monitoring.
Upstream EDE entities that leverage a primary EDE entity’s platform, with only minor branding changes, are generally not subject to an audit of their application and privacy/security structure.
It is important to note that the Exchange retains responsibility for making eligibility determinations.
What Is the Process for Web-brokers to Offer Direct Enrollment (DE)?
Prospective web-brokers can request approval to enroll consumers in Exchange coverage through DE or EDE by initiating the web-broker onboarding process; web brokers may onboard year-round.
A primary EDE Entity must have a third-party Auditor, complete the business requirements, privacy and security audits, sign the ISA and EDE Business Agreement, have its own Partner ID, and comply with all applicable requirements including conducting oversight of upstream EDE Entity and downstream agent, and broker users of its approved EDE environment.
All upstream EDE Entities must have a legal relationship with a primary EDE Entity reflected in a signed written agreement between the upstream EDE Entity and the primary EDE Entity.
There are three categories of upstream EDE Entities:
1. White-label Issuers – White-label issuers use a primary EDE Entity’s approved EDE environment but make minor branding and QHP display changes.
- White-label issuer upstream EDE Entities are not required to conduct and submit a business requirements audit or a privacy and security audit, but they must submit the applicable DE Entity Documentation Package, the EDE Business Agreement, and maintain a unique Partner ID.
2. Hybrid Issuers – A hybrid issuer upstream EDE Entity is an issuer that implements additional functionality or systems to the primary EDE Entity’s EDE environment beyond minor branding changes or QHP display changes.
- Hybrid issuer upstream EDE Entities must sign an EDE Business Agreement and maintain a unique Partner ID.
3. Hybrid, Non-issuers – Hybrid, Non-issues are agents, brokers, or web brokers that use a primary EDE Entity’s EDE environment with additional functionality that changes the EDE end-user experience.
- Hybrid non-issuer upstream EDE Entities are required to retain an Auditor to conduct a privacy and security audit relevant to the additional functionalities or systems it seeks to add to the primary EDE Entity’s approved EDE environment, must sign an EDE Business Agreement, and maintain a unique Partner ID.
Only a primary EDE Entity can provide an EDE environment to a hybrid, non-issuer, or issuer (whether a white-label or hybrid issuer). Upstream EDE Entities cannot provide an EDE environment to other upstream EDE Entities.
Downstream Third-party Agent and Broker Arrangements
An EDE Entity may allow third-party agents and brokers to use its approved EDE environment, either directly through the primary EDE Entity or by way of an arrangement with an upstream EDE Entity.
Downstream third-party agents and brokers will not sign an EDE Business Agreement or the ISA, and will not be provided or allowed to use a unique Partner ID for EDE API transactions.
What is the Process for Qualified Health Plan Issuers to Offer Direct Enrollment (DE)?
Issuers that are providing QHPs on the FFE can request to participate in DE by submitting a Hub Onboarding Form. CMS will provide additional instructions.
Issuers must:
- Meet CMS’s regulatory requirements
- Have a secure website
- Sign a QHP certification agreement with CMS and
- Implement the technical requirements to connect with the FFE through the DE pathway (Create and digitally sign SAML responses and invoke SOAP web services).
Best Practices to Get Ready for EDE
EDE Entities must complete the development of their EDE environments and any related systems prior to initiating their audits, which includes integrating with all required APIs. It is strongly recommended that EDE Entities complete the development of their environments prior to the start of the audit submission window which annually starts on April 1st and ends by July 1st at 3:00 AM EST.
It is extremely advisable that the EDE Entity tests their environments using the supplemental EDE Partner Test Case Suite in addition to all applicable required test cases contained in the toolkits.
It is strongly recommended that EDE Entities not begin the business requirements portion of their third-party audits (i.e., portions that use the Eligibility Results Toolkits, API Functional Integration Toolkit, Communications Toolkit, or the Business Audit Instructions and Report Template) until CMS releases the new baseline versions of each toolkit and template in the first quarter of the year (usually around mid to late February). However, the application should be fully completed and functional by February to ensure that developers have time to make any last-minute changes requested by CMS and allow time to complete the audit.
Note that CMS can take two weeks or more to provide feedback on the package and if the package is not complete or the testing was not successful – entities cannot be approved for completeness and hence would want the feedback as soon as possible (e.g. early May) to ensure that there is more time to submit another package that will be approved. Ensuring all API, communications, and UI functionality and documentation is an expected request by CMS and in their toolkits as the most important to ensure a successful business requirements audit.
Moreover, Elevate recommends that the infrastructure and operational processes are fully implemented as evidence of ongoing monitoring and are required as part of the risk assessment and completion of the SAR (Security and Audit Report).
How Elevate can help with CMS DE and EDE Pathway
- Project Planning: Especially for EDE Entities, Elevate can help you build your project plan once you have decided to move forward with an EDE implementation. Elevate’s team of experts has a deep understanding of all requirements and steps through the process to approval.
- Audit: Whether you are a Hybrid Upstream Issuer or EDE Entity, Elevate has a deep understanding of all requirements by entity type. This includes a complete audit of Business Requirements for the EDE Entity and completion of all toolkits and complete packages. Moreover, Elevate has audited full EDE Security and Privacy Audits of the 294 NIST 800-53 and CMS-specific controls or subsets depending on if the hybrid upstream entity or DE Classic entity. We will prepare and complete all required toolkits for business requirements audits, packages, and business requirements reports, in addition to the Privacy and Security audit requirements (SAP, SAR, Risk Assessment, POA&M, scans, and penetration test).
- Audit Preparation: Elevate can provide advice on how to meet audit requirements for the privacy and security portion of the audit. Elevate will never have system access or any privileges to the system to remain independent of the process. However, we understand how to architect a secure and operational platform that will pass CMS requirements.
- Penetration Testing: We understand the scope and notification requirements from CMS to perform a thorough and complete penetration test of the environment in scope.
- Ongoing Vulnerability Scans: We perform the monthly required scans to be provided to CMS quarterly as part of their continuous monitoring requirements.
- Ongoing Monitoring Advisory: Staying in compliance with CMS is not a “set it and forget it” situation. You must maintain a robust compliance program and quarterly reporting to CMS. Elevate can help you design your ongoing compliance program to ensure proper compliance.