CMS-10877 Communications Toolkit

EDE Business Audit Instructions and Report Template
February 24, 2023

OMB Control #: 0938-NEW
Expiration Date: XX/XX/20XX

Enhanced Direct Enrollment (EDE)
Business Audit Instructions and Report Template
1.0 Instructions for Completion of the EDE Business Requirements Audit Report
Template and Toolkits
The Auditor conducting the business requirements audit must complete the Business
Requirements Audit Report Template (Business Report) provided in Section 2.0 of this
document, as well as the applicable toolkits provided by the Centers for Medicare & Medicaid
Services (CMS). The completed Business Report and toolkits will make up the final business
requirements audit package that the Direct Enrollment (DE) Entity will submit to CMS to
participate in EDE.
CMS will not begin its review of a prospective EDE Entity’s business requirements audit until
the EDE Entity has submitted a fully completed Business Report and applicable toolkits,
including any supplemental documentation required by the toolkits.
For more information, please refer to the Third-party Auditor Operational Readiness Reviews for
the Enhanced Direct Enrollment Pathway and Related Oversight Requirements (Guidelines)
(The Guidelines for Year 6 will be located here: https://zone.cms.gov/document/general-edeguidance-and-information and here: https://www.cms.gov/programs-and-initiatives/healthinsurance-marketplaces/direct-enrollment-and-enhanced-direct-enrollment)
Steps to Start the Business Audit
1) Read this document thoroughly.
2) Review the Auditor User Guide tab in each available toolkit.

1.1 How to Complete the Business Report Template in Section 2.0
The Auditor conducting the business requirements audit must use the Business Report template
to document a prospective EDE Entity’s compliance with each business requirement review
category, including those review categories that the Auditor has reviewed using CMS-provided
toolkits.
Using the Business Report template provided in Section 2.0, the Auditor will complete a table
and two fields for each review category listed. See Exhibit 5 in Appendix A for descriptions of
each business requirement and the Auditor review standard. The Business Report template
provides spaces for the Auditor to supply the following information for each review category:
•

Risk Identified,

PRA DISCLOSURE: According to the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of
information unless it displays a valid OMB control number. The valid OMB control number for this information collection is 0938NEW, expiration date is XX/XX/20XX. The time required to complete this information collection is estimated to take up to 144,652
hours annually for all direct enrollment entities. If you have comments concerning the accuracy of the time estimate(s) or suggestions
for improving this form, please write to: CMS, 7500 Security Boulevard, Attn: PRA Reports Clearance Officer, Mail Stop C4-26-05,
Baltimore, Maryland 21244-1850. ****CMS Disclosure**** Please do not send applications, claims, payments, medical records or any
documents containing sensitive information to the PRA Reports Clearance Office. Please note that any correspondence not
pertaining to the information collection burden approved under the associated OMB control number listed on this form will not be
reviewed, forwarded, or retained. If you have questions or concerns regarding where to submit your documents, please contact
Brittany Cain at Brittany.Cain@cms.hhs.gov.

1

EDE Business Audit Instructions and Report Template
February 24, 2023
•
•
•
•
•

Risk Level,
Risk Mitigation Strategies,
Estimated Resolution Date,
Notes, and
Compliance Determination.

See the following subsections for more detailed instructions.

1.1.1 Risk Identified, Risk Level, Risk Mitigation Strategies, and Resolution
The Auditor will use a table display like the one shown as Exhibit 1 to fully document any risks
and mitigation strategies specific to the review category.
Exhibit 1: Risk and Mitigation Strategy Display
Risks Identified

Risk Level

Risk Mitigation Strategy

Estimated Resolution
Date

When the Auditor identifies risks and mitigation strategies within a toolkit, it should refer CMS
to the toolkit. Note that the Auditor does not need to repeat each risk and each mitigation
strategy in the Business Report if these risks and mitigation strategies have been documented
within the toolkit. If, while completing the toolkit, the Auditor identifies any risks that are not
related to a specific toolkit requirement or that are a general risk applicable to an entire toolkit or
review requirement, the Auditor should document the risks and mitigation strategies in the
Business Report (Section 2.0).
Risk Identified
The Auditor must list all risks not already identified in the toolkits (if applicable), which
includes:
•

•

Unresolved risks: These are outstanding risks that have a mitigation strategy and future
estimated resolution date. Please note that low-risk issues must be documented, but do
not require a mitigation strategy and future estimated resolution date. All high-risk
issues require these items.
Resolved risks: These are any risks that the Auditor identified that were resolved by the
prospective EDE Entity prior to its submission of the Business Report to CMS. The
Auditor must document the mitigation strategy and resolution date.

If the Auditor has not identified any risks specific to the review category, it should indicate
“N/A” in the first row of Exhibit 1. If the Auditor explained all risks specific to the review
category in the toolkit, it should write “Please see associated toolkit” in the first row of Exhibit 1.
Risk Level

2

EDE Business Audit Instructions and Report Template
February 24, 2023
The Auditor must assign a risk level of “low” or “high” to each risk it identifies. 1 The Auditor
must base the risk level determination on the severity and scope of the risk. CMS will take the
risk level assigned by the Auditor into consideration when reviewing the audit but may adjust it
if necessary.
0F

•

•

High-risk issues may impact a consumer’s eligibility determination, enrollment
disposition or status, or legal attestation. High-risk issues may also greatly hinder the
consumer experience or impact data collection (e.g., skipping a question that is required
for an EDE Entity to ask, but optional for the consumer to answer).
Low-risk issues are unlikely to affect a consumer’s eligibility determination, enrollment
disposition or status, legal attestation, experience (i.e., in a negative or confusing way), or
data collection.

Note: These risk determinations are applicable for the business audit only and not the privacy
and security audit.
Risk Mitigation Strategy
Auditors must explain how a resolved risk(s) was mitigated. If high-risk findings have been
identified and not yet resolved, Auditors must indicate how these risks can be closed or
mitigated. A prospective EDE Entity must resolve all high-risk findings prior to receiving final
approval to use the EDE pathway. The Auditor and prospective EDE Entity can determine
whether the low-risk issues must be resolved or not (i.e., the Auditor may list but is not required
to list a mitigation strategy for unresolved low-risk findings).
Estimated Resolution Date
For unresolved high-risk findings, the Auditor must also indicate the date by which it reasonably
expects the prospective EDE Entity to fully resolve the risk in the “Estimated Resolution Date”
column if the issue cannot be resolved prior to audit submission to CMS. CMS recommends
Auditors work with the prospective EDE Entity to provide a realistic timeframe of when a risk
will be closed or mitigated, given other dependencies and their expertise.
Note: In some cases, the toolkit does not cover the full requirement (i.e., compliance with toolkit
rows alone does not address the requirement) so please review each review category requirement
in full (see Appendix A) when completing the Business Report template.

1.1.2 Notes
The Auditor may also explain any findings that it would like to share with CMS that would not
be considered risks. If desired, the Auditor may also explain the rationale for characterizing a
specific risk as low risk or high risk in this section. If the Auditor does not have any notes for the
review category, it should indicate “N/A” in this space.

1

These risk determinations are applicable for the business audit only and not for the privacy and security audit.

3

EDE Business Audit Instructions and Report Template
February 24, 2023

1.1.3 Compliance Determination
The Auditor must provide a conclusive and affirmative statement of the prospective EDE
Entity’s compliance with all requirements set forth in the review category. The Auditor must
provide this statement for each review category, regardless of what the Auditor documented in
the toolkit.
The Auditor will base its determination on the outcome of the audit conducted in accordance
with the review standard identified in Appendix A. Some of the requirements set forth in the
review standards and in toolkit instructions are subject to interpretation. In such cases, the
Auditor should use its reasonable judgment in interpreting the standard.
The Auditor should carefully read the review standard for the review category prior to
completing the Business Report and corresponding toolkit (if applicable) to ensure that it has
recorded a determination for each requirement set forth in the review standard. The Auditor will
complete its review of the various requirements set forth in the review standard through the
completion of a corresponding toolkit (if applicable) and/or through other methods described in
the review standard.

1.2 How to Use and Complete the CMS-Provided Business Requirement Toolkits
The Auditor conducting the business requirements audit must utilize and complete the following
CMS-provided toolkits: (1) API Functional Integration Testing, (2) Eligibility Results, 2 (3)
Application User Interface (UI), and (4) Communications. Each toolkit provides information
(e.g., testing scenarios, application questions) that the Auditor will use to verify the prospective
EDE Entity’s compliance with one or more business requirement review categories. The baseline
toolkits are available in a zip file on CMS zONE at: https://zone.cms.gov/document/businessaudit. The Auditor User Guide tab in each toolkit contains comprehensive instructions for
completing that toolkit. The Auditor User Guide describes the contents of the toolkit and how the
Auditor should review those requirements and/or scenarios.
1F

Auditor Compliance Findings
Within each toolkit, certain fields are designated for the Auditor to complete; these are the
auditor compliance findings fields. In the identified tabs, the Auditor must scroll to the right to
complete the last six columns whose column headings are shaded in yellow, as shown in Exhibit
2. These columns are where the Auditor must indicate the prospective EDE Entity’s compliance,
risks identified, risk level (high or low), risk mitigation strategies, estimated resolution dates, and
limited Auditor comments (e.g., screenshot file names that are evidence of compliance with the
requirement). The Auditor User Guide tab in each toolkit contains further instructions for
completing these fields.

2

There are three versions of the “Eligibility Results Toolkit,” and each one corresponds to one of the three EDE
phases. The Auditor must read the instructions in all three toolkits as phases 2 and 3 require the Auditor to use more
than one Eligibility Results Toolkit.

4

EDE Business Audit Instructions and Report Template
February 24, 2023
Exhibit 2. Sample Yellow-shaded Columns for COMPLETION

In the Application UI Toolkit only, essential fields are indicated with blue shading in the column
heading. They are also indicated (along with the auditor compliance findings fields) with a
double asterisk (**). This will help the Auditor distinguish fields that DE Entities will use in
building the eligibility application and the fields that are essential to the audit. The Auditor must
review the essential fields, as shown in Exhibit 3.
Exhibit 3: Sample Blue-shaded Essential Field Columns in the Application UI Toolkit for REVIEW

1.3 How to Submit the Completed Business Report and Toolkits
The prospective EDE Entity must submit the completed Business Report (as a PDF) and toolkits
in a zip file through its DE/EDE PME site.
Some toolkits may require submission of supplemental documentation, such as screenshots, raw
Extensible Markup Language (XML), raw JavaScript Object Notations (JSONs), and eligibility
determination notices (EDNs). In such cases, the prospective EDE Entity should upload the
supplemental documentation to the appropriate toolkit folder. Please note the following
documentation will not be accepted:
•

Supplemental documentation not requested by CMS (i.e., any documentation that does
not directly link to a requirement that needs evidence, as specified in the toolkit, will not
be reviewed)

An example of the structure of the zip file and the naming conventions of the folders and files
within the zip file is shown below (folders are listed in bold font and documents are listed in
italics). Please put your prospective EDE Entity’s name in each file name.
•

Zip file name: Business Audit Package_[insert prospective EDE entity name]
o Completed Business Requirements Audit Report Template (PDF)
o Eligibility Results Toolkit

5

EDE Business Audit Instructions and Report Template
February 24, 2023
Completed Eligibility Results Toolkit(s) 3
Supplemental Documentation: Folders for each Test Case containing
documentation described in the toolkit labeled as:
• TestCase [Insert Phase #][Insert Test Case Letter] (e.g.,
TestCase1A)
• Each test case screenshot within the folders should be labeled with
the test case number and letter followed by the number of the
screenshot (e.g., 1A_1.png, TestCase1A_2.png). Similarly, the
Auditor should name the raw JSON or XML files to clearly
identify them as belonging to a specific test case (e.g.,
TestCase1A-JSON). The EDN should be labeled in the same
manner (e.g., TestCase1A_EDN.pdf). No test case screenshot
should have the same file name across all test cases.
• CMS strongly recommends that Auditors sequentially aggregate
the screenshots in a single document for each test case (e.g., a
Microsoft Word, PowerPoint, or PDF document with each image
labelled “TestCase1-A”) instead of submitting each screenshot as
an individually saved image (e.g., TestCase1A-1.jpg, TestCase1A2.jpg). This may help expedite CMS’s audit review.
o Completed Application UI Toolkit (just the spreadsheet, CMS does not review
screenshot evidence for this toolkit)
 For Auditors reviewing a prospective EDE Entity’s Spanish-language
version of the application UI, the Auditor can document its audit findings
for the Spanish-language version of the application UI by adding columns
for the auditor compliance findings fields (yellow-shaded columns) to the
Application UI Toolkit required tabs (please refer to the Auditor User
Guide information for detailed instructions on the required tabs) or by
completing a second copy of the Application UI Toolkit. 4
o API Functional Integration Toolkit
 Completed API Functional Integration Toolkit
 Supplemental Documentation: Folders for each Test Case containing
documentation described in the toolkit labeled as:
• TestCase[Insert Phase #] (e.g., TestCaseF001)
• The required evidence files should be named sequentially, and the
file name should clearly identify them as belonging to a specific
test case. For example, the Auditor should use this naming
structure: TestCaseF00#_Step#_Item



2F

3F

3
The Auditor will complete one or more of three phase testing scenarios toolkits. The Auditor User Guide tab
within each toolkit specifies which of the three testing scenario toolkits to complete.
4
FAQs Regarding Spanish Translation and Audit Requirements for Enhanced Direct Enrollment (EDE) Entities
Serving Consumers in States with FFEs (June 20, 2018) are available here: https://www.cms.gov/CCIIO/Programsand-Initiatives/Health-Insurance-Marketplaces/Downloads/FAQ-EDE-Spanish-Translation-and-AuditRequirements.PDF

6

EDE Business Audit Instructions and Report Template
February 24, 2023
#_Document#_ElementName.png, which would appear as
“F001_5_1_1_person search API.png” in the file submission. In
the Test Cases tab, the information to populate “TestCaseF00#”
can be found in column A, “Step#” can be found in column D, and
“Item #” can be found in column H. Auditors should use
“Document#” to indicate the sequential order of the documents in
the audit submission and “ElementName” to describe the content
within the document.
o Communications Toolkit
 Completed Communications Toolkit 5
 For Auditors reviewing a prospective EDE Entity’s Spanish-language
version of critical communications, the Auditor can document its audit
findings for the Spanish-language version of the Communications Toolkit
by adding columns for the auditor compliance findings fields (yellowshaded columns) to the Communications Toolkit required tabs (please
refer to the Auditor User Guide information for detailed instructions on
the required tabs) or by completing a second copy of the Communications
Toolkit.
 Supplemental Documentation: Folders for each requirement that needs
screenshots or video files for evidence of compliance (as noted in the
toolkit). Each folder should be labeled with the requirement row number
(e.g., Requirement 2).
 Each screenshot or video file within the requirement folders should be
clearly labeled. The Auditor has discretion for these naming conventions,
but CMS recommends descriptive file names (e.g., DMI_Citizenship,
SVI_Marriage, Education_1).
 Please note that CMS will require Spanish-language screenshots for those
Communications toolkit rows requiring evidence, if applicable. The
Spanish Communications toolkit and screenshots may be submitted at the
time of audit submission if the prospective EDE Entity is pursuing use the
EDE pathway in Texas; however, CMS will request updated Spanishlanguage screenshots after the English Communications requirements are
approved.
4F

1.4 Resubmissions After CMS Review
Once CMS determines an audit is complete, it will review the audit submission for compliance.
During CMS’s compliance review of the audit submission, CMS may request revisions and
resubmissions to address non-compliant requirements. Below are CMS expectations related to
these resubmissions:

5

See FAQs referenced in footnote 4

7

EDE Business Audit Instructions and Report Template
February 24, 2023
•

•

The prospective EDE may be required to continue engaging its Auditor after audit
submission.
o If the resubmission requires another audit of the requirement(s) in a template or a
toolkit, the prospective EDE Entity is expected to engage its Auditor to confirm
that the resubmitted requirement(s) is compliant.
o The Auditor may be expected to engage in a phone call with CMS to discuss its
compliance determinations and applicable entity mitigation strategies.
Prospective EDE Entities and their Auditors must submit all requested re-audited
documentation, when requested by CMS (i.e., resubmit the entire Business Audit
Package). This ensures that CMS has the full submission of updated documents in one
complete package.

1.5 Audit Submission Package
In addition to the Business Report, toolkits, and supplemental documentation (the Business Audit
Package) outlined in Section 1.3, the EDE Entity and its Auditor must submit additional
documents. For more information, see Section VI, Business Audit Requirements and Scope, of
the Guidelines.

1.6 Completeness Requirements
CMS will review each business requirements audit submission for completeness. CMS will not
accept incomplete audits. A complete business requirements audit submission meets the criteria
described in Exhibit 4, at a minimum. CMS strongly encourages entities to review these
requirements thoroughly to avoid having their audits rejected during the audit submission
window.
Exhibit 4: Business Requirements Audit Submission Requirements for a Complete Audit
Toolkit & Template
All Toolkits

Minimum Requirements for a Complete Audit








Provide complete Auditor documentation (i.e., required columns indicated for Auditor results
contain details regarding the Auditor’s evaluation of the requirement, including compliance
status, risks, and mitigation strategies (if applicable)). The Auditor’s evaluation must contain
no ambiguous language about potential unmitigated risks (e.g., stating that the Auditor has
identified risks, or the prospective EDE Entity has mitigated the risks without a description of
the risks or mitigation strategies).
Complete screenshots that demonstrate all reviewed content without missing, obscured, or
cut-off elements that are required to evaluate compliance with the requirements represented
by the screenshot.
All required rows, across all required tabs, of each toolkit are completed. Auditors should
refer to the Auditor User Guide tab of each Toolkit to identify required tabs, columns, and
rows.
Risks identified during the course of the audit must be documented and explained, even if
the EDE Entity has subsequently mitigated the risks (i.e., a history of initial risk identification
and attempted mitigation through any and all subsequent reviews and mitigation attempts
should be documented to enable CMS to understand the original and subsequent risks
identified and how all risks were mitigated).
The prospective EDE Entity may be required to continue engaging its Auditor after audit
submission.
– If the resubmission requires another audit of the requirement(s) in a template or a
toolkit, the prospective EDE Entity is expected to engage its Auditor to confirm that
the resubmitted requirement(s) is compliant.

8

EDE Business Audit Instructions and Report Template
February 24, 2023
Toolkit & Template

Minimum Requirements for a Complete Audit
The Auditor may be expected to engage in a phone call with CMS to discuss its
compliance determinations and applicable entity mitigation strategies.
 Prospective EDE Entities and their Auditors must submit all requested
re-audited documentation, when requested by CMS (i.e., resubmit the
entire Business Audit Package). This ensures that CMS has the full
submission of updated documents in one complete package.
Note: For any issues or risks identified during the completeness review that are attributable
to CMS-confirmed Exchange defects, CMS will not hold prospective EDE Entities
responsible for such defects; however, the prospective EDE Entity must confirm the defect
exists with CMS help desk teams 6 and document that the issue exists in the applicable
Toolkit or Business Audit Report. CMS may require the prospective EDE Entity demonstrate
the required functionality once CMS has resolved the CMS-confirmed Exchange defect. For
example, if a prospective EDE Entity is unable to complete an API Functional Integration
Toolkit test case due to a CMS-confirmed Exchange defect, CMS may require the EDE
Entity to submit the test case in full once CMS has resolved the defect.
–

All Toolkits
(continued)



5F

Communications
Toolkit

Complete screenshots that demonstrate compliance when the applicable requirements
require screenshots to be provided as evidence under the Requirements tab in the toolkit.
 EDE Entities of all phases must submit screenshots to support document upload
requirements for all DMIs and SVIs 7. There are no phase-specific exceptions for the account
management and document upload requirements.
For any Communications Toolkit screenshots that involve multiple webpages or screens, EDE
Entities must provide screenshots of all relevant webpages or screens (e.g., if the EDE Entity is
providing a link to the consumer FAQs from the Communications Toolkit requirements, provide
the screenshots of the link origin and destination).



6F

Application User
Interface (UI) Toolkit



The Application UI Toolkit must be reviewed in full and documented appropriately (see the
“All Toolkits” minimum requirements above) for the applicable phase, which includes all UI
elements included in that phase (e.g., an audit of a phase 3 application would include
application questions that are also applicable to phases 1 and 2, as well as application
questions specific to phase 3 only). Note: The test cases in the Eligibility Results Toolkits do
not cover all questions or requirements in the Application UI Toolkit. As a result, Auditors
must develop a methodology to ensure each element of the Toolkit is evaluated. Prospective
EDE Entities have the option to test a variety of functionalities in their UIs using additional,
optional, EDE Partner Test Cases 8.
7F

Eligibility Results
Toolkit(s)





Eligibility Results
Toolkit(s)

Each phase has its own Eligibility Results Toolkit. Phase 1 EDE Entities must complete all
phase 1 test cases. Phase 2 EDE Entities must complete all phase 2 test cases and some of
the phase 1 test cases. Phase 3 EDE Entities must complete all phase 3 test cases and
some of the phase 1 and phase 2 test cases. Please refer to the User Guide tab in the
Eligibility Results Toolkits for more specific test case instructions. Please note, depending
upon an Entity’s planned service areas, it may need to request modifications to test cases,
as described in the User Guide tab in the Eligibility Results Toolkits.
Screenshots of the entire application flow are provided for each test case from either the
coverage year and coverage state questions (items #1 and #2 in the Application UI Toolkit)
or the privacy notice disclaimer (item #3 in the Application UI Toolkit), whichever comes first
in the Entity’s environment, through the entire application including the eligibility results
page.
–

Note: The screenshots described above are required for the toolkit associated with
the entity’s target application phase, but not for lower phase toolkits. For example,
a prospective phase 2 EDE Entity would submit screenshots for the phase 2

6

Please refer to Section XII.A, Help Desk, of the EDE Auditor Guidelines for more information on submitting
tickets to the appropriate CMS help desk.

7
As a result of the 2023 Notice of Benefits and Payment Parameters Final Rule, CMS only requires evidence for the
SVI type, "Losing Qualifying Health Coverage". The Auditor is not required to provide screenshots for any other
SVI types.
8
Please refer to the EDE Partner Test Cases and EDE Partner Test Cases User Guide, available on CMS zONE at
the following link: https://zone.cms.gov/document/eligibility-information.

9

EDE Business Audit Instructions and Report Template
February 24, 2023
Toolkit & Template

Minimum Requirements for a Complete Audit

(continued)






Eligibility Results Toolkit test cases, but not phase 1 test cases. The EDN and
JSON requirements described below apply to all required test cases across all
required toolkits. For example, a prospective phase 2 EDE Entity would submit
EDNs and raw JSONs from the Get App API Response for both phase 1 and
phase 2 Eligibility Results Toolkit test cases. A screenshot depicting the eligibility
results page with correct eligibility results and EDN are provided for each test
case. The eligibility results must not differ between the eligibility results page and
the EDN, and every element of the eligibility results should be correctly
represented.
A copy of the raw JSON from a Get App API Response for the application version depicted
in the screenshots for each test case.
CMS will review the eligibility results page and the EDN for the correct results for each
applicant based on the Toolkits and consistent results between the eligibility results page
and the EDN for the following elements:
– Exchange OEP or SEP eligibility (QHP);
– Advance payments of the premium tax credit (exact amount, if applicable);
– CSRs;
– Medicaid eligibility;
– CHIP eligibility;
– SVIs; and
Non-MAGI Medicaid Referral.

Correct results and successful completion of each test case is documented.
− If an EDE Entity will pursue approval to use both the Consumer pathway and the Agent and
Broker pathway, the submission must include documentation reflecting the expected results
for each pathway. In other words, the EDE Entity must complete the full test case in both
the Agent/Broker and Consumer pathways and submit the required documentation for each
pathway. The EDE Entity may not use evidence from one pathway to satisfy the evidence
for the other pathway (e.g., using screenshots or API calls from the Consumer pathway
application to satisfy the requirement for the Agent/Broker pathway), if the EDE Entity must
provide evidence for both pathways.
 Successful completion of the DMI and SVI test cases consistent with the Toolkit’s
instructions.
 Complete submission of all required evidence outlined in the “Required Evidence” column,
Column H, on the “Test Cases” tab within the API Functional Integration Toolkit, including
the complete header and body for each required API request and response.
– JSONs and XML files submitted as required evidence for a Test Case must be raw
and unmodified by the EDE Entity.

API Functional
Integration Toolkit



EDE Business Audit
Report Template



Complete descriptions of each requirement; Auditors must not exclude required review
criteria from their review and description of each requirement (e.g., the Requirement and
Review Standard criteria for each business requirement).

PY 2023 DE Entity
Documentation
Package



CMS requires that the prospective EDE Entity submit a complete PY 2023 DE Entity
Documentation Package. While the prospective EDE Entity may need to re-submit
documentation during EDE Agreement Renewal or prior to approval, CMS requires a
complete PY 2023 DE Entity Documentation Package at audit submission to review the
documentation for compliance.

An incomplete business requirements audit is an audit that does not meet the criteria described
above. The Auditor must take the appropriate actions to complete the incomplete audit and the
prospective EDE Entity must resubmit it, as applicable. Please review Section X.B, Audit
Submission, of the Guidelines, for more information.
CMS will conduct an initial high-level review of all audit submissions in the order they are
received and based on available resources. If a prospective EDE Entity submits an incomplete
audit, CMS will communicate the missing elements to the Entity based on the initial high-level
review and the audit will be removed from the audit review queue. The Entity may receive
10

EDE Business Audit Instructions and Report Template
February 24, 2023
multiple rounds of feedback from CMS on its business requirement audit. It may take several
weeks to resolve all missing elements prior to CMS accepting an Entity’s audit submission.
Consistent with the deadlines in Section X.B, Audit Submission, of the Guidelines, CMS will
require that missing elements of incomplete audits be resubmitted by the EDE Entity or its
Auditor, when an Auditor’s re-evaluation is specifically required by CMS and CMS will
prioritize its review of these resubmitted audits based on the date the complete audit is submitted.
Audits should not include comments that describe the Auditor’s process for verifying the
requirement unless there is a specific issue or concern with respect to the requirement that
warrants raising the concern to CMS.

2.0 Business Requirements Audit Report Template (to be completed by Auditor)
The review categories for the business operational readiness review are listed below, along with
the corresponding toolkit that should be reviewed. In some cases, the toolkit does not cover the
full requirement, so the Auditor must review each review category requirement in full (see
Appendix A). Auditors must ensure the prospective EDE Entity is compliant with the specific
requirements for each review category in Appendix A.
Please note, for those approved EDE Entities requesting Phase Change Requests, the Auditor
must audit a CMS-defined subset of requirements. Please refer to Section XI.A.ii, EDE Entityinitiated EDE Phase Change Requests, of the Guidelines for more information on changing
phases.
Please fill in the information requested below:
•
•
•

EDE Entity Point of Contact (POC) and Email: [insert prospective EDE Entity POC and
Email]
Auditor Name: [insert Auditor Company Name]
Auditor POC and Email: [insert Auditor POC and email]

2.1 Review Category #1: Consumer Identity Proofing Implementation
1. List all identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified
[insert Risk]

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

[insert Mitigation Strategy]

2. Notes: [insert Notes]

11

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity
will resolve risk]

EDE Business Audit Instructions and Report Template
February 24, 2023
3. Compliance Determination: [insert Compliance Determination]

2.2 Review Category #2: Agent and Broker Identity Proofing Verification
1. List identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

2.3 Review Category #3: Phase-dependent Screener Questions (EDE Phase 1 and
2 EDE Entities Only) (Corresponding Toolkit: Application UI)
1. List all identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

12

EDE Business Audit Instructions and Report Template
February 24, 2023

2.4 Review Category #4: Accurate and Streamlined Eligibility Application User
Interface (UI) (Corresponding Toolkit: Application UI)
1. List all identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

2.5 Review Category #5: Post-Eligibility Application Communications
(Corresponding Toolkit: Communications)
1. List all identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

[insert Risk Level (low
/high)]

2. Notes: [insert Notes]
3. Compliance Determination: [insert Compliance Determination]

13

EDE Business Audit Instructions and Report Template
February 24, 2023

2.6 Review Category #6: Accurate Information about the Exchange and Consumer
Communications (Corresponding Toolkit: Communications)
1. List all identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

2.7 Review Category #7: Documentation of Interactions with Consumer
Applications or the Exchange
1. List all identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

[insert Risk Level (low
/high)]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

2.8 Review Category #8: Eligibility Results Testing and SES Testing (Corresponding
Toolkit: Eligibility Results)
1. List all identified risks and mitigation strategies associated with this review category in
the table below.

14

EDE Business Audit Instructions and Report Template
February 24, 2023
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low/
high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

2.9 Review Category #9: API Functional Integration Requirements (Corresponding
Toolkit: API Functional Integration)
1. List all identified risks and mitigation strategies associated with this review category in
the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

[insert Risk Level (low/
high)]

2. Notes: [insert notes]
3. Compliance Determination: [insert Compliance Determination]

15

EDE Business Audit Instructions and Report Template
February 24, 2023

2.10 Review Category #10: Application UI Validation (Corresponding Toolkit:
Application UI)
1. List all identified risks and mitigation strategies associated with this review category in
the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low/
high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert Notes]
3. Compliance Determination: [insert Compliance Determination]

2.11 Review Category #11: Section 508-compliant UI
1. List identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

[insert Risk Level (low
/high)]

2. Notes: [insert Notes]
3. Compliance Determination: [insert Compliance Determination]

16

EDE Business Audit Instructions and Report Template
February 24, 2023

2.12 Review Category #12: Non-English-language Version of the Application UI and
Communication Materials (Corresponding Toolkits: Communications and
Application UI)
1. List identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert Notes]
3. Compliance Determination: [insert Compliance Determination]

2.13 Review Category #13: EDE Change Management Process
1. List identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

[insert Risk Level (low
/high)]

2. Notes: [insert Notes]
3. Compliance Determination: [insert Compliance Determination]

17

EDE Business Audit Instructions and Report Template
February 24, 2023

2.14 Review Category #14: Health Reimbursement Arrangement (HRA) Offer
Required UI Messaging (if applicable)
1. List identified risks and mitigation strategies associated with this review category, and
not already explained in the toolkit, in the table below.
Risks Identified

Risk Level

Risk Mitigation Strategy

[insert Risk Level (low
/high)]

Estimated Resolution
Date
[insert estimated date that
prospective EDE Entity will
resolve risk]

2. Notes: [insert Notes]
3. Compliance Determination: [insert Compliance Determination]

Appendix A - Auditor Review Standards
The specific requirements for each review category are summarized in Exhibit 5.

18

EDE Business Audit Instructions and Report Template
February 24, 2023
Exhibit 5. EDE Business Requirements Table
Review Category

Requirement and Audit Standard

Consumer Identity 
Proofing
Implementation



Requirement: The EDE Entity must conduct identity proofing (ID proofing) for Consumers entering
the EDE pathway for enrollments through both Consumer and in-person Agent and Broker
pathways.64 The EDE Entity must conduct ID proofing prior to submitting a Consumer’s application to
the Exchange. If an EDE Entity is unable to complete ID proofing of the Consumer, the EDE Entity
may either direct the Consumer to the classic DE (i.e., double-redirect) pathway or direct the
Consumer to the Exchange (HealthCare.gov or the Exchange Call Center at 1-800-318-2596 [TTY: 1855-889-4325]).
– Remote ID Proofing/Fraud Solutions Archive Reporting Services (RIDP/FARS) or ThirdParty ID Proofing Service: CMS will make the Exchange RIDP and FARS services available
for the EDE Entity to use when remote ID proofing consumers for the Consumer pathway
(i.e., when a consumer is interacting directly with the EDE environment without the
assistance of an individual agent or broker). If an EDE Entity uses the Exchange RIDP
service, it must use the RIDP service only after confirming the Consumer is seeking
coverage in a state supported by the Exchange/Federal Platform, and only after confirming
the consumer is eligible for the EDE Entity’s chosen phase. However, CMS does not require
that EDE Entities use the Exchange RIDP and FARS services, specifically, to complete ID
proofing. An EDE Entity may instead opt to use a third-party ID proofing service for ID
proofing in the consumer pathway. If an EDE Entity uses a third-party identity proofing
service, the service must be Federal Identity, Credential, and Access Management (FICAM)
Trust Framework Solutions (TFS)-approved, and the EDE Entity must be able to produce
documentary evidence that each Applicant has been successfully ID proofed.
Documentation related to a third-party service could be requested in an audit or investigation
by CMS (or its designee), pursuant to the EDE Business Agreement. Applicants do not need
to be ID proofed on subsequent interactions with the EDE Entity if the Applicant creates an
account (i.e., username and password) on the EDE Entity’s website, and the EDE Entity
tracks that ID proofing has occurred when the Applicant’s account was created.
– Manual ID Proofing in the In-Person Agent and Broker Pathway: EDE Entities may also offer
a manual ID proofing process. Consumers being ID proofed in the in-person Agent and
Broker pathway (i.e.., when an Agent or Broker is working with a consumer and conducting
ID proofing in-person, rather than remotely) must be ID proofed following the guidelines
outlined in the document “Acceptable Documentation for Identity Proofing” available on CMS
zONE (https://zone.cms.gov/document/api-information).
– For the Consumer pathway, the EDE Entity must provide the User ID of the requester in the
header for each EDE API call. For the Consumer pathway, the User ID should be the User
ID for the Consumer’s account on the EDE Entity’s site, or some other distinct identifier the
EDE Entity assigns to the Consumer.
– Additionally, if an EDE Entity is using the Fetch Eligibility API, the same User ID
requirements apply. However, instead of sending the User ID via the header, the User ID will
be provided in the request body via the following path:
ExchangeUser/ExchangeUserIdentification/IdentificationID.
Review Standard:
– If an EDE Entity uses the Exchange RIDP service, the Auditor must verify that the EDE
Entity has successfully passed testing with the Hub.65
– If an EDE Entity uses a third-party ID proofing service, the Auditor must evaluate and certify
the following:
o
The ID proofing service is FICAM TFS-approved, and
o
The EDE Entity has implemented the service correctly.
– If an EDE Entity offers a Manual ID proofing option for an in-person Agent and Broker
pathway, the Auditor must verify that the EDE Entity requires Agents and Brokers to ID proof
consumers as described in the “Acceptable Documentation for Identity Proofing” document.
– EDE Entity’s inclusion of the appropriate Consumer User ID fields in the EDE and Fetch
Eligibility API calls.

19

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category
Agent and Broker
Identity Proofing
Verification

Requirement and Audit Standard


Requirement: If an EDE Entity is implementing an Agent and Broker pathway for its EDE
environment, the EDE Entity must implement Agent and Broker ID proofing verification procedures
that consist of the following requirements:
– EDE Entity must integrate with IDM-Okta66 and provide the User ID of the requester and
IDM-Okta token in the header for each EDE API call. For Agents and Brokers, the User ID
must exactly match the Exchange User ID (i.e. the Agent’s or Broker’s portal.cms.gov User
ID) for the Agent or Broker, or the request will fail Exchange User ID validation.
o
The same User ID requirements apply to the Fetch Eligibility and
Submit Enrollment APIs. However, instead of sending the User ID via the
header, the User ID will be provided in the request body via the following
path: ExchangeUser/ExchangeUserIdentification/IdentificationID.
– EDE Entity must ID proof all Agents and Brokers prior to allowing the Agents and Brokers to
use its EDE environment. EDE Entity may conduct ID proofing in one of the following ways:
o
Use the Exchange-provided RIDP/FARS APIs to remotely ID proof
Agents and Brokers; OR
o
Manually ID proof Agents and Brokers following the guidelines
outlined in the document “Acceptable Documentation for Identity Proofing”
available on CMS zONE EDE webpage (https://zone.cms.gov/document/apiinformation).
o
EDE Entities are permitted to use manual ID proofing as an
alternative for Agents and Brokers that cannot be ID proofed via the
RIDP/FARS services.
– EDE Entity must validate an Agent’s or Broker’s National Producer Number (NPN) using the
National Insurance Producer Registry (https://www.nipr.com) prior to allowing the Agent or
Broker to use its EDE environment.
– EDE Entity must systematically provide an Agent and Broker ID proofing process—that
meets all of the requirements defined here—that applies to all downstream Agents and
Brokers of the primary EDE Entity.
– Additionally, all Agent and Broker users of an upstream EDE Entity’s EDE website (hosted
by a primary EDE Entity) must be ID proofed consistent with these requirements. The
primary EDE Entity may provide one centralized ID proofing approach for any Agents and
Brokers that will use the primary EDE Entity’s EDE environment (including when utilized by
upstream EDE Entities and their downstream Agents and Brokers).
o
Alternatively, the upstream EDE Entity may conduct its own ID
proofing process of its downstream Agents and Brokers consistent with
these requirements. The upstream EDE Entity must provide the information
for Agents and Brokers that have passed and failed ID proofing to the
primary EDE Entity using a secure data transfer. If an upstream EDE Entity
wants to pursue this flexibility, its ID proofing process must be audited by an
Auditor consistent with these standards and the arrangement will be
considered a hybrid arrangement.
– Note: If a primary EDE Entity does not provide a centralized process for ID proofing an
upstream EDE Entity’s downstream Agent and Broker and if the primary EDE Entity intends
to provide the EDE environment to upstream EDE Entities, the upstream EDE Entities will be
required to provide documentation of an Auditor’s evaluation of its ID proofing approach
consistent with these standards. This process must be categorized as an EDE Entityinitiated Change Request (Section XI.A, EDE Entity-initiated Change Requests) if it occurs
after the primary EDE Entity’s initial audit submission and the arrangement with the
upstream EDE Entity will be considered a hybrid arrangement.
– All Agents and Brokers that will use EDE must be ID proofed consistent with these
standards. This includes downstream Agents and Brokers of primary EDE Entities and
upstream EDE Entities. The Auditor must evaluate the primary EDE Entity’s centralized
implementation for ID proofing (if applicable) or the upstream EDE Entity’s implementation
for ID proofing (if applicable).

20

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category
Agent and Broker
Identity Proofing
Verification
(continued)

Requirement and Audit Standard



Phase-dependent 
Screener Questions
(EDE Phase 1 and 2
EDE Entities Only)



Accurate and
Streamlined
Eligibility
Application User
Interface (UI)

EDE Entity is strongly encouraged to implement multi-factor authentication for Agents and
Brokers that is consistent with NIST SP 800-63-3.
Review Standard: The Auditor must verify and certify the following:
– EDE Entity’s inclusion of the appropriate Agent and Broker User ID and IDM-Okta token
fields in the EDE and Fetch Eligibility and Submit Enrollment API calls.
– EDE Entity’s process for ID proofing an Agent or Broker prior to allowing an Agent or Broker
to use its EDE environment.
– EDE Entity’s process for validating an Agent’s or Broker’s NPN using the National Insurance
Producer Registry prior to allowing an Agent or Broker to use its EDE environment.
– EDE Entity’s process for systematically providing an Agent and Broker ID proofing approach
for all downstream Agents and Brokers of the EDE Entity and, if applicable, any upstream
EDE Entities.
o
If the primary EDE Entity has not provided a centralized ID
proofing approach to an upstream EDE Entity, primary EDE Entity’s process
for verifying that an upstream EDE Entity has conducted appropriate ID
proofing, consistent with this requirement, for all of the upstream EDE
Entity’s downstream Agents and Brokers prior to those Agents and Brokers
being able to use the primary EDE Entity’s EDE environment.
Requirement: An EDE Entity that implements either EDE Phase 1 or Phase 2 must implement
screening questions to identify Consumers whose eligibility circumstances the EDE Entity is unable
to support consistent with the eligibility scenarios supported by the EDE Entity’s selected EDE phase.
These phase-dependent screener questions must be located at the beginning of the EDE application,
but may follow the QHP plan compare experience. For those Consumers who won’t be able to apply
through scenarios covered by the EDE phase that the EDE Entity implements, the EDE Entity must
either route the Consumer to the classic DE double-redirect pathway or direct the Consumer to the
Exchange by providing the following options: HealthCare.gov or the Exchange Call Center at 1-800318-2596 [TTY: 1-855-889-4325].
Review Standard: The Auditor must verify the following:
– The EDE Entity has implemented screening questions—consistent with the requirements in
the Exchange Application UI Principles document and Application UI Toolkit—to identify
Consumers with eligibility scenarios not supported by the EDE Entity’s EDE environment
and selected EDE phase.
– The EDE Entity’s EDE environment facilitates moving Consumers to one of the alternative
enrollment pathways described immediately above.
Requirement: EDE Entities using the EDE pathway must support all application scenarios outlined in
EDE Entity’s selected EDE phase. The EDE Entity must adhere to the guidelines set forth in the FFE
Application UI Principles document when implementing the application. EDE Entities can access the
FFE Application UI Principles document on CMS zONE (https://zone.cms.gov/document/eligibilityinformation). Auditors will need to access the FFE Application UI Principles document to conduct the
audit.
– As explained in the FFE Application UI Principles document, the EDE Entity must implement
the application in accordance with the Exchange requirements. For each supported eligibility
scenario, the EDE Entity must display all appropriate eligibility questions and answers,
including all questions designated as optional. (Note: These questions are optional for the
Consumer to answer, but are not optional for EDE Entities to implement.) The FFE
Application UI Principles document and Application UI Toolkit define appropriate flexibility
EDE Entities may implement with respect to question wording, question order or structure,
format of answer choices (e.g., drop-down lists, radio buttons), and integrated help
information (e.g., tool tips, URLs, help boxes). In most cases, answer choices, question logic
(e.g., connections between related questions), and disclaimers (e.g., APTC attestation) must
be identical to those of the Exchange.
–



21

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category

Requirement and Audit Standard

Accurate and
Streamlined
Eligibility
Application User
Interface (UI)
(continued)

Post-eligibility
Application
Communications

Note: The phrase “supported eligibility scenario” does not refer to the
Eligibility Results Toolkit scenarios. Auditors must verify that EDE Entities
can support all scenarios supported by the EDE Entity’s selected phase and
this exceeds the scope of the test cases in the Eligibility Results Toolkits.
– EDE Entities will also need to plan their application’s back-end data structure to ensure that
attestations can be successfully submitted to Standalone Eligibility Service (SES) APIs at
appropriate intervals within the application process and that the EDE Entity can process
responses from SES and integrate them into the UI question flow logic, which is dynamic for an
individual Consumer based on his or her responses. The EDE Entity will need to ensure that
sufficient, non-contradictory information is collected and stored such that accurate eligibility
results will be reached without any validation errors.
– Review Standard: The Auditor must review and certify the following:
– The FFE Application UI has been implemented in EDE Entity’s environment in accordance with
the Exchange Application UI Principles document.
– The FFE Application UI displays all appropriate eligibility questions and answers from the
Application UI Toolkit, including any questions designated as optional.
– The Auditor will review the application for each supported eligibility scenario under the phase the
EDE Entity has implemented to confirm that the application has been implemented in
accordance with the FFE Application UI Principles document and Application UI Toolkit. The
Auditor will document this compliance in the Application UI Toolkit.
– Note: The phrase “supported eligibility scenario” does not refer to the Eligibility Results Toolkit
scenarios. Auditors must verify that EDE Entities can support all scenarios supported by the
EDE Entity’s selected phase and this exceeds the scope of the test cases in the Eligibility
Results Toolkits.
– If EDE Entity has implemented Phase 1 or Phase 2, the Auditor will confirm that the UI includes
a disclaimer stating that the environment does not support all application scenarios, and
identifying which scenarios are and are not supported. The disclaimer should direct the
Consumer to alternative pathways, such as the classic DE double-redirect pathway or direct the
Consumer to the Exchange (HealthCare.gov or the Exchange Call Center at 1-800-318-2596
(TTY: 1-855-889-4325)). This requirement is included in the Communications Toolkit.
Requirement: The EDE environment must display high-level eligibility results, next steps for
enrollment, and information about each Applicant’s insurance affordability program eligibility (e.g.,
APTC, CSR, Medicaid, and/or CHIP eligibility), Data Matching Issues (DMIs), special enrollment
periods (SEPs), SEP Verification Issues (SVIs), and enrollment steps in a clear, comprehensive and
Consumer-friendly way. Generally, CMS’s Communications Toolkit constitutes the minimum posteligibility application communications requirements that an EDE Entity must provide to users of the
EDE environment; CMS does not intend for the Communications Toolkit requirements to imply that
EDE Entities are prohibited from providing additional communications or functionality, consistent with
applicable requirements.
– EDE Entity must provide Consumers with required UI messaging tied to API functionality and
responses as provided in the EDE API Companion Guide67.
– EDE Entity must provide Consumers with the CMS-provided Eligibility Determination Notices
(EDNs) generated by the Exchange any time it submits or updates an application pursuant
to requirements provided by CMS in the Communications Toolkit.
– EDE Entity must provide the EDN in a downloadable format at the time the Consumer’s
application is submitted or updated and must have a process for providing access to the
Consumer’s most recent EDN via the API as well as providing access to the Consumer’s
historical notices—accessed via the Notice Retrieval API by the EDE Entity’s EDE
environment—within the UI. The UI requirements related to accessibility of a Consumer’s
EDN are set forth in the Communications Toolkit.
o



22

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category

Requirement and Audit Standard

Post-eligibility
Application
Communications
(continued)

EDE Entities are not required to store notices downloaded from the Exchange. EDE Entities
must use the Metadata Search API and the Notice Retrieval API to generate the most recent
Exchange notices when Consumers act to view/download notices consistent with the
Communications Toolkit. EDE Entities must also provide access to view/download historical
notices in their UIs.
– EDE Entity must provide and communicate status updates and access to information for
Consumers to manage their applications and coverage. These communications include, but
are not limited to, status of DMIs and SVIs, enrollment periods (e.g., SEP eligibility and the
OEP), providing and communicating about new notices generated by the Exchange,
application and enrollment status, and supporting document upload for DMIs and SVIs. This
requirement is detailed in the Communications Toolkit.
– EDE Entity must provide application and enrollment management functions for the
Consumer in a clear, accessible location in the UI (e.g., an account management hub for
managing all application- and enrollment-related actions).
– For any Consumers enrolled, including via the Agent and Broker pathway, the EDE Entity
must provide critical communications to Consumers notifying them of the availability of
Exchange-generated EDNs, critical communications that the Consumer will no longer
receive from the Exchange (i.e., if the EDE Entity has implemented and been approved by
CMS to assume responsibility for those communications), and any other critical
communications that an EDE Entity is providing to the Consumer in relation to the
Consumer’s application or enrollment status.
– All EDE Entities, regardless of phase, must provide consumers with status updates and
document upload capabilities for all DMIs and SVIs. Even if an EDE Entity’s chosen eligibility
application phase does not support the questions necessary to reach a certain DMI or SVI,
the post-application and post-enrollment functionality must support any consumer with any
DMI or SVI; post-application and post-enrollment DMI and SVI management is not
dependent on the EDE Entity’s chosen eligibility application phase.
Review Standard: The Auditor must verify and certify the following:
– The EDE Entity’s EDE environment is compliant with the requirements contained in the
Communications Toolkit and API Companion Guide.
– The EDE Entity’s EDE environment notifies Consumers of their eligibility results prior to QHP
enrollment, including when submitting a CiC in the environment. For example, if a
Consumer’s APTC or CSR eligibility changes, EDE Entity must notify the Consumer of the
change and allow the Consumer to modify his or her QHP selection (if SEP-eligible) or
APTC allocation accordingly.
– EDE Entity must have a process for providing Consumers with a downloadable EDN in its
EDE environment and for providing access to a current EDN via the API. EDE Entity must
share required eligibility information that is specified by CMS in the Communications Toolkit.
– The Auditor must verify that EDE Entity’s EDE environment is providing status updates and
ongoing communications to Consumers according to CMS requirements in the
Communications Toolkit as it relates to the status of their application, eligibility, enrollment,
notices, and action items the Consumer needs to take.
– The EDE Entity must provide application and enrollment management functions for the
Consumer in a clear, accessible location in the UI.
– The EDE Entity must have a means for providing critical communications to the Consumer
consistent with the standards above.
– The EDE Entity must support all DMIs and SVIs in its post-eligibility application and postenrollment functionality.
–



23

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category

Requirement and Audit Standard

Accurate

Information about
the Exchange and
Consumer
Communications 
Documentation of 
Interactions with
Consumer
Applications or the
Exchange


Eligibility Results
Testing and SES
Testing





Requirement: EDE Entity must provide Consumers with CMS-provided language informing and
educating the Consumers about the Exchanges and HealthCare.gov and Exchange-branded
communications Consumers may receive with important action items. CMS defines these
requirements in the Communications Toolkit.
Review Standard: The Auditor must verify and certify that the EDE Entity’s EDE environment includes
all required language, content, and disclaimers provided by CMS in accordance with the standards
stated in guidance and the Communications Toolkit.
Requirement: EDE Entity must implement and maintain tracking functionality on its EDE environment
to track Agent, Broker, and Consumer interactions, as applicable, with Consumer applications using a
unique identifier for each individual, as well as an individual’s interactions with the Exchanges (e.g.,
application; enrollment; and handling of action items, such as uploading documents to resolve a
DMI). This requirement also applies to any actions taken by a downstream Agent or Broker,68 as well
as the upstream EDE Entity users, of a primary EDE Entity’s EDE environment.
Review Standard: The Auditor must verify EDE Entity’s process for determining and tracking when an
upstream EDE Entity, downstream Agent or Broker, and Consumer has interacted with a Consumer
application or taken actions utilizing the EDE environment or EDE APIs. The Auditor must verify and
certify the following:
– The EDE Entity’s environment tracks, at a minimum, the interactions of upstream EDE
Entities, downstream Agents or Brokers, and Consumers with a Consumer’s account,
records, application, or enrollment information utilizing the EDE environment or EDE APIs.
– The EDE Entity’s environment tracks when an upstream Entity, downstream Agent or
Broker, or Consumer views a Consumer’s record, enrollment information, or application
information utilizing the EDE environment or EDE APIs.
– The EDE Entity’s environment uses unique identifiers to track and document activities by
Consumers, downstream Agents and Brokers, and upstream EDE Entities using the EDE
environment.
– The EDE Entity’s environment tracks interactions with the EDE suite of APIs by an upstream
EDE Entity, a downstream Agent or Broker, or Consumer.
– The EDE Entity’s environment stores this information for 10 years.
Requirement: EDE Entity must submit accurate applications through its EDE environment that result
in accurate and consistent eligibility determinations for the supported eligibility scenarios covered by
EDE Entity’s chosen EDE phase.
– The business requirements audit package must include testing results in the designated
Exchange EDE testing environment. CMS has provided a set of Eligibility Results Toolkits
with the eligibility testing scenarios on CMS zONE https://zone.cms.gov/document/businessaudit).
Review Standard: The Auditor must verify and certify the following:
– The Auditor was able to successfully complete a series of test eligibility scenarios in the EDE
Entity’s EDE environment implementation using the Eligibility Results Toolkits. For example,
these scenarios may include Medicaid and CHIP eligibility determinations, and different
combinations of eligibility determinations for APTC and CSRs. Note: These scenarios do not
test, and are not expected to test, every possible question in the Application UI flow for an
EDE Entity’s selected phase. In addition to reviewing the eligibility results test cases, the
Auditor must review the Application UI for compliance as defined above.
– The Auditor must test each scenario and verify that the eligibility results and the eligibility
process were identical to the expected results and process. The Auditor must provide CMS
confirmation that each relevant eligibility testing scenario was successful, that the expected
results were received, and must submit the required proof, as defined in the Eligibility
Results Toolkits. This will include screenshots, EDNs, and the raw JSON from the Get App
API response for the application version used to complete the scenario. Note: EDNs and raw
JSONs are required for all required toolkit scenarios; however, screenshots are only required
for the highest phase an entity is submitting (for example, a prospective phase 3 EDE Entity
must submit screenshots for the Phase 3 Eligibility Results Toolkit only, but must submit
EDNs and raw JSONs for applicable Phase 1, Phase 2, and Phase 3 toolkit scenarios).

24

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category
API Functional
Integration
Requirements

Requirement and Audit Standard




Application UI
Validation




Section 508compliant UI





Requirement: EDE Entity must implement the EDE API suite and corresponding UI functionality in
accordance with the API specifications and EDE API Companion Guide provided by CMS. The EDE
API specifications and EDE API Companion Guide are available on CMS zONE
(https://zone.cms.gov/document/api-information).
Review Standard: The Auditor must complete the set of test scenarios as outlined in the API
Functional Integration Toolkit to confirm that the EDE Entity’s API and corresponding UI integration
performs the appropriate functions when completing the various EDE tasks. For example, the Auditor
may have to complete a scenario to verify that a Consumer or Agent and Broker is able to view any
SVIs or DMIs that may exist for a consumer, and confirm that the Consumer or Agent and Broker has
the ability to upload documents to resolve any SVIs or DMIs. Some of the test cases require that the
Auditor and EDE Entity request CMS to process adjudication actions; the Auditor cannot mark these
particular test cases as compliant until evaluating whether the expected outcome occurred after CMS
takes the requested action. The Auditor will also need to be aware of the following requirements
related to the test scenarios:
– Test scenarios in the API Functionality Integration Toolkit must be completed for both the
Consumer pathway and the Agent and Broker pathway if an EDE Entity is pursuing approval
to use both pathways.
– The API Functional Integration Toolkit includes a “Required Evidence” column, Column H,
on the “Test Cases” tab. Auditors will need to submit the applicable “Required Evidence,”
including the complete header and body for each required API request and response, as part
of the audit submission.
Requirement: EDE Entity must implement CMS-defined validation requirements within the
application. The validation requirements prevent EDE Entity from submitting incorrect data to the
Exchange.
Review Standard: The Auditor must confirm that EDE Entity has implemented the appropriate
application field-level validation requirements consistent with CMS requirements. These field-level
validation requirements are documented in the FFE Application UI Principles document.
Requirement: Pursuant to 45 C.F.R. § 155.220(c)(3)(ii)(D) (citing 45 C.F.R. §§ 155.230 and
155.260(b)) and 45 C.F.R. § 156.265(b)(3)(iii) (citing 45 C.F.R. §§ 155.230 and 155.260(b)), webbrokers and QHP issuers participating in DE, including all EDE Entities, must implement an eligibility
application UI that is Section 508 compliant. A Section 508-compliant application must meet the
requirements set forth under Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. §
794(d)).
Review Standard: The Auditor must confirm that EDE Entity’s application UI meets the requirements
set forth under Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794(d)). The
Auditor must verify and certify the following:
– Within the Business Requirements Audit Report Template, the Auditor must confirm that the
EDE Entity’s application UI is Section 508 compliant. No specific report or supplemental
documentation is required.
– The Auditor may review results produced by a 508 compliance testing tool. If an EDE Entity
uses a 508 compliance testing tool to verify that its application UI is 508 compliant, its
Auditor must, at a minimum, review the results produced by the testing tool and document
any non-compliance, as well as any mitigation or remediation to address the noncompliance. It is not sufficient for an Auditor to state that an EDE Entity complies with this
requirement by confirming that the EDE Entity utilized a 508 compliance testing tool.

25

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category

Requirement and Audit Standard

Non-English
language Version of
the Application UI
and Communication
Materials



EDE Change
Management
Process




Health

Reimbursement
Arrangement (HRA)

Requirement: In accordance with 45 C.F.R. § 155.205(c)(2)(iv)(B) and (C), QHP issuers and webbrokers, including those that are EDE Entities, must translate applicable website content (e.g., the
application UI) on Consumer-facing websites into any non-English language that is spoken by a
limited English proficient (LEP) population that reaches ten (10) percent or more of the population of
the relevant state, as determined in current guidance published by the Secretary of HHS.69 EDE
Entities must also translate communications informing Consumers of the availability of Exchangegenerated EDNs; critical communications that the Consumer will no longer receive from the
Exchange (i.e., if the EDE Entity has implemented and been approved by CMS to assume
responsibility for those communications); and any other critical communications that an EDE Entity is
providing to the Consumer in relation to the Consumer’s use of its EDE environment into any nonEnglish language that is spoken by an LEP population that reaches ten (10) percent or more of the
population of the relevant state, as determined in guidance published by the Secretary of HHS.70
Review Standard: The Auditor must verify and certify the following:
– The Auditor must confirm that the non-English-language version of the application UI and
associated critical communications are compliant with the Exchange requirements, including
the Application UI Toolkit and Communications Toolkit.
– The Auditor must verify that the application UI has the same meaning as its Englishlanguage version.
– The Auditor must also verify that EDE Entity has met all EDE communications translation
requirements released by CMS in the Communications Toolkit.
– The Auditor must document compliance with this requirement within the Business
Requirements Audit Report Template, the Application UI Toolkit, and the Communications
Toolkit. In the toolkits, the Auditor can add additional columns for the Auditor compliance
findings fields (yellow-shaded columns) or complete the Spanish audit in a second copy of
each of the two toolkits.
Requirement: EDE Entity must develop and consistently implement processes for managing changes
to the EDE environment relevant to the business requirements audit requirements. This requirement
does not replace the evaluation necessary for relevant privacy and security controls. At a minimum,
the EDE Entity’s change management plan must include the following elements:
– A process that incorporates all elements of the Change Notification SOP as referenced in
Section XI.A.i, EDE Entity-initiated Change Request Process;
– All application and business audit-related changes are thoroughly defined and evaluated
prior to implementation, including the potential effect on other aspects of the EDE end-user
experience;
– A process for defining regression testing scope and developing or identifying applicable
testing scenarios;
– A process for conducting regression testing;
– A process for identifying and correcting errors discovered through regression testing and retesting the correction;
– A process for maintaining separate testing environments and defining the purposes and
releases for each environment;
– The change management process must be maintained in writing and relevant individuals
must be informed on the change management process and on any updates to the process;
and
– The change management process must include a process, if applicable, for an EDE Entity to
update the non-English-language version of the application UI and communication materials
for any changes to the application UI or communication materials in the English-language
version of the EDE environment.
Review Standard: The Auditor must evaluate the EDE Entity’s change management plan for
compliance with the elements and criteria defined above.
Requirement: Phase 3 EDE Entities, Phase 2 EDE Entities that optionally implement full HRA
functionality, and EDE Entities that also offer a classic DE pathway, must implement required UI
messaging for qualified individuals who have an HRA offer that is tailored to the type and affordability
of the HRA offered to the qualified individuals consistent with CMS guidance. Required UI messaging

26

EDE Business Audit Instructions and Report Template
February 24, 2023
Review Category
Offer Required UI
Messaging

Requirement and Audit Standard



for various scenarios are detailed in the FFEs DE API for Web-brokers/Issuers Technical
Specifications document.71
Review Standard: The Auditor must review the EDE Entity’s HRA offer implementation to confirm that
the required UI messaging content is displayed for each of the relevant scenarios detailed in the
FFEs DE API for Web-brokers/Issuers Technical Specifications document.

27