DE Entity Operational Readiness Review (ORR)

Supporting Statement for Direct Enrollment Entities (CMS-10877)

Appendix_G_API-Functional-Integration-Toolkit_03.31.23_508

DE Entity Operational Readiness Review (ORR)

OMB: 0938-1463

Document [pdf]

Download: pdf | pdf

OMB Control #: 0938-NEW
Expiration Date: XX/XX/20XX
API Functional Integration Toolkit
Purpose of This Toolkit
This document is designed to help Enhanced Direct Enrollment (EDE) Auditors ensure that an EDE Entity has successfully integrated on a basic functional level with each of the EDE
application programming interfaces (APIs). This document is also designed to help EDE Auditors ensure that an EDE Entity has successfully implemented required UI functionality related
to the APIs. Each test case in this toolkit requires integration with multiple EDE APIs. The Auditor must either complete each test case on its own, or work with the EDE Entity to verify the
test cases work appropriately. In both scenarios, the Auditor must provide a statement of compliance for each test case.
For each test case, the EDE Entity must correctly call all applicable APIs and yield the applicable expected results after calling each API. The EDE Entity and Auditor must use the test data
provided in the Zip file, "EDE End-to-End Test Data." There are nine data sets; column G, "Data Inputs," in the Test Cases tab displays which data set to use for each test case.
The EDE Entity must also follow the adjudication instructions on the "Adjudication Instructions" tab when adjudication of a data matching issue (DMI) or special enrollment period (SEP)
verification issue (SVI) is required.
Required Documentation
The Auditor must provide written confirmation in this toolkit, as part of the Operational Readiness Review (ORR), stating that it confirmed the DE Entity is able to successfully pass the API
integration scenarios listed in this toolkit. The Auditor must also provide any required evidence to confirm that the test scenarios were completed successfully, as described in column H,
"Required Evidence," in the Test Cases tab. The Auditor should name the required evidence files sequentially and clearly identify them as belonging to a specific test case. For example,
the Auditor should use this naming structure: TestCaseF0##_Step#_Item #_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 “TestCaseF0##” 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.
Note on Version
It is important to note that this document is subject to change.
Tab
Test Case Overview

Tabs for Auditor Review
Description
This tab displays an overview of the test scenarios
and general assumptions to implement or consider
throughout each test case. The Auditor will document
the compliance findings for each Test Case in this tab.

How to Review
The Auditor will use this tab to document compliance with each test case
defined in the subsequent tab. The Auditor must carefully examine that the
EDE Entity is achieving the expected results for each test case on the Test
Cases tab prior to confirming the EDE Entity's compliance with each test
case in the columns whose column headings are shaded in yellow or marked
with "**."

Test Cases

This tab displays a detailed overview of the test
scenarios, required API calls, expected results, and
any required evidence.

The Auditor will also use this tab to track compliance. The Auditor must
carefully examine the required APIs and expected results for each test case
on the Test Cases tab prior to confirming the EDE Entity's compliance with
each test case. The Auditor must provide any required evidence described in
this tab, to confirm that the test scenarios were completed successfully.

Adjudication Instructions

This tab displays Data Matching Issue (DMI) and
Special Enrollment Period Verification Issue (SVI)
adjudication instructions.

The Auditor must verify that the entity received the appropriate result for
the adjudication test cases.

Audit Requirements by Tab
Tab: Test Case Overview
In this tab, the Auditor must scroll to the right to complete the last six columns whose column headings are shaded in yellow or marked with "**."
Columns & Sections
Description
How to Review
Test Case ID
Test Case ID that corresponds to each case listed on The Auditor must match the Test Case ID in this tab to the corresponding
the subsequent tab, Test Cases.
test case in the subsequent tab, Test Cases. The Auditor must use
information from both tabs to complete the audit.
Scenario description
Summary of test data for each test case.
The Auditor may use this summary information to inform the audit.
Detailed Scenario Description
Mapping Test Data Sheet

Description of each test case.
Test data in the "EDE_End-to-End Test Data" folder
that is to be used for a particular scenario.

The Auditor may use this description to inform the audit.
The Auditor must either use this data to complete each test case on its own,
or work with the EDE Entity to verify the test cases work appropriately.

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 0938-NEW, expiration
date is XX/XX/20XX. The time required to complete this information collection is estimated to take up to 56,290 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 [email protected].

Auditor Compliance Conclusion
**

The Auditor must provide a conclusion as to whether
the scenario (and corresponding requirements
defined in the Test Cases tab) defined in each row is
compliant with the CMS requirements. A compliance
conclusion should be indicated as "Yes" or "No."

The Auditor will use the requirements in the Test Cases tab to confirm each
test case is compliant. For DMI and SVI adjudications, the Auditor must
confirm the EDE Entity requested the adjudication and received the
expected result for the test case(s). If the test case is compliant, the Auditor
must indicate "Yes" in this column. If the row is not compliant, the Auditor
must indicate the noncompliance with a "No" in this column.
There are several required fields in each cell within this column:
- The first required field in the set of rows specific to each test case is "Test
Case F0## compliance conclusion: _____." If the results of the test case are
compliant, and match the expected results for the test case, the Auditor
must indicate "Yes" in this column. If the results of the test case are not
compliant, the Auditor must indicate the noncompliance with a "No" in this
column.
-The subsequent required cells for each test case refer to the Auditor
Checklist Items in the "Expected Result and Auditor Checklist Items" column
of the Test Cases tab. These Auditor Checklist Items reference the step and
the row number from the test case where there is an Auditor checklist list
item indicated by "Auditor Checklist Item F0## Step ##: Auditor confirms
[...]." For example, the first item in the API Functional Integration Test Case
001 (Auditor Checklist Item F001 Step 2a (row 3) is, "Auditor confirms the
agent is required to enter the document type and document identifier used
for manual ID proofing in the in-person agent/broker flow." After the
Auditor verifies this checklist item, the Auditor must document its
compliance determination in the corresponding cell and field in the
"Auditor Compliance Conclusion" column in the Test Case Overview tab,
"Auditor Checklist Item F001 Step 2a (row 3) compliance conclusion:"
As the Auditor reviews each test case in its entirety, the Auditor must
indicate any compliance risks identified in this column. This includes any
compliance risks that the EDE Entity has since resolved. One example finding
is that the scenario could not be completed because the Eligibility
Determination Notice (EDN) could not successfully be downloaded. An
example mitigation strategy would be that the EDE Entity made a system or
user interface (UI) change to correct the issue. When the scenario was
retested, the EDN was successfully downloaded and the scenario
successfully completed.

Risks Identified**

The Auditor must detail any compliance risks
identified during the audit in this column for each
applicable row. Use this column if the Compliance
Conclusion was “No” or if the entity resolved a risk
prior to audit submission. There are two types of
risks: resolved and unresolved. Please document
them both here. Do not document a risk if the
requirement is compliant and there was no
mitigation required.

Risk Level**

Auditors must assign a risk level to each risk it
identifies.

Risk Mitigation Strategy**

The Auditor must explain how each risk was
mitigated. For example, if the entity was unable to
correctly call an API, the Auditor must identify that as
a risk and list how the EDE Entity corrected the
finding (i.e., mitigated the risk). This field is required
for high-risk findings. The Auditor can work with the
DE Entity to decide on whether or not to include this
for low-risk findings.

Estimated Resolution Date**

Auditors must provide a timeframe for risk resolution CMS recommends Auditors work with the EDE Entity to provide a realistic
(required for unresolved high-risk findings).
timeframe of when a risk will be closed or mitigated given other
dependencies and their expertise.
The Auditor can use this column to provide any
The Auditor can add any comments necessary during the review, but is not
additional notes or comments pertaining to each
required to do so. Business requirements audits should not include
item.
comments that describe the Auditor’s process for verifying the requirement
unless there is a specific issue or concern regarding the requirement that
warrants raising a concern.

Auditor Comments

The Auditor must assign a risk level of "high" or "low" to each risk. 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
CMS will take the risk level assigned by the Auditor
into consideration when reviewing the audit, but may question that is required for a EDE Entity to ask, but optional for the
consumer to answer).
adjust it if necessary.
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.
As the Auditor identifies compliance risks, the Auditor and EDE Entity will
identify a mitigation strategy that will mitigate or eliminate the compliance
risk. The Auditor must document that mitigation strategy here. This includes
documenting the mitigation strategy for any identified risk that the EDE
Entity has resolved. For example, for a scenario that could not be completed
because during the “Submit App” step, an error was displayed within the
EDE Entity’s UI and within the Submit App API Response, an example
mitigation strategy would be that the EDE Entity made a system or UI
change to correct the issue. When the scenario was retested, the application
was successfully submitted and the scenario successfully completed.

Columns
Test Case ID

Tab: Test Cases
Description
Testing Notes
Test Case ID that corresponds to each test case listed
on the previous tab, "Test Case Overview."

High-level Description
Description
Step

High-level description of each test case.
Description of each test case.
Steps to complete each test case, listed numerically.

High-level Steps

Steps to complete each test case, described in detail.

Expected Result
Data Inputs

The expected result after each step is completed.
Data (e.g., test data sheet) the EDE Entity must use to
complete each test case at the applicable step. Data
sets can be found in the "EDE End-to-End Test Data"
folder.
For example, for test case "MTST_EDE_E2E_ F001,"
the EDE Entity should use the data set, "F001_MPL-02A-1081" at step 9.

Required Evidence

Required evidence to substantiate that the test case
was successful.

Sections
DMI and SVI Adjudication Instructions

SVI/DMI Adjudication Request

The submission must include:
-Correct results and successful completion of each test case: 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 and compliant 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.
- JSON and XML files submitted as required evidence must demonstrate
successful OKTA integration. That is, the User ID provided in API request
headers, and within Fetch Eligibility/Submit Enrollment request bodies,
must be the agent/brokers’ FFE User ID. Fetch Eligibility XML files are
required when requested if the Entity has integrated with the Fetch
Eligibility API.

Tab: Adjudication Instructions
Description
Testing Notes
Instructions for adjudicating DMIs and SVIs.
The Auditor must confirm the EDE Entity requested the adjudication and
received the expected result for the test case(s). Note that it is expected that
entities complete adjudication prior to submission.
Instructions for formatting the spreadsheet EDE
Entities must submit to adjudicate DMIs and SVIs.

General Testing Assumptions
1. Entities implementing a consumer flow will complete each scenario via their consumer flow. Entities that are implementing an Agent/Broker (A/B) flow will complete each scenario via their A/B flow, and those that are implementing both a consumer flow and an A/B flow will complete each scenario via both of their flows.
2. Step 1 in each test case (consumer account creation) may vary depending upon an EDE Entity's account creation process; some Entities may require consumers to create an account, while other Entities may not. Note that consumers are only required to complete ID proofing once as long as they are required to create an account on the Entity's site and the ID proofing occurrence is associated with the created account.
3. Web-brokers (WBEs) should add the text "DONOTSEND" in Address Line 2 when completing applications, in order to prevent 834s from being sent to issuers.
4. IMPORTANT: Mapped test data sheets are provided separately (see description below). Please note that each Entity must change the first name, last name, date of birth, street address, and email address of the applicants within the data provided when creating applications. The demographic data used must also be randomized for each test scenario (i.e. Entities should not use the same first name, last name, etc. for each test scenario). There are a number of issues that Entities
may encounter if they don't randomize the demographic data, including SVIs and DMIs not generating.
5. Entities are permitted to change the birth dates for the household members so that all household members are QHP-eligible. For example, making a child age 19-25 may prevent the child from being eligible for CHIP; some scenarios indicate when an Entity may want/need to make a child age 19-25.
6. Entities are permitted to change the attested income for the scenarios so that all household members are eligible for a QHP, except for scenario 7; income for scenario 7 is provided within steps, and is required to trigger the Income DMI.
7. If a test case calls for a non-financial assistance (non-FA) application, the income and tax-related attestations in the test data can be ignored.
8. The “Did you get help from a navigator or agent/broker?” question can be answered "Yes" for each scenario, and the Entity can include an A/Bs name and NPN. This is optional.
9. Test case MTST_EDE_E2E_ F003 requires the Entity to report a change in circumstances (CIC) on an application that wasn't originally created by the Entity. The Entity should email [email protected], with the subject line, "Request for App IDs: EDE API Test Scenario F003," to obtain existing applications. Upon request, three applications will be provided to the Entity. Additional applications can be requested by the Entity, if needed. Note, the existing
applications will be Alabama applications. If an EDE Entity needs non-Alabama applications, that should be noted in the email request.
10. Test case MTST_EDE_E2E_F011 requires the Entity to create a 2023 application using a 2022 application. The entity should email [email protected], with the subject line, "Request for App IDs: EDE API Test Scenario F011," to obtain 2022 applications. Upon request, three applications will be provided to the Entity. Additional applications can be requested by the Entity, if needed. Note, the 2022 applications will be Arizona applications. If an Entity
needs non-Arizona applications, that should be noted in the email request.
11. The order of the API calls may vary depending on an Entity's implementation. All API calls should be made however, unless otherwise indicated in the test case.
12. For any necessary SVI or DMI adjudications, Entities will follow the instructions on the Adjudication Instructions tab.
13. Many of the test scenarios are designed to be completed outside of OE. Accordingly, Entities should complete the scenarios in the test environment when the test environment is not set to OE.
Summary of Test Cases along with Data Mapping
Detailed Scenario Description

Test Case ID

Scenario Description

MTST_EDE_E2E_ F001

Initial financial assistance (FA) application with no SVI User submits an initial FA application for 2 members. Both members are US
or DMI
Citizens and the application has no DMI or SVI

F001_MPL-02-A-1081

Test Case F001 compliance conclusion:

MTST_EDE_E2E_ F002

CIC FA application with no DMI or SVI

User performs a CIC on an initial FA application existing in the EDE Entity's system.
The application has no SVI or DMIs.

Continuation of F001

Auditor Checklist Item F001 Step 2a (row 3) compliance conclusion:
Auditor Checklist Item F001 Step 2b (row 3) compliance conclusion:
Auditor Checklist Item F001 Step 5a (row 6) compliance conclusion:
Auditor Checklist Item F001 Step 5b (row 6) compliance conclusion:
Auditor Checklist Item F001 Step 5c (row 6) compliance conclusion:
Auditor Checklist Item F001 Step 5d (row 6) compliance conclusion:
Auditor Checklist Item F001 Step 16 (row 17) compliance conclusion:
Test Case F002 compliance conclusion:

MTST_EDE_E2E_ F003

CIC with an added member for an application that
currently does not exist in EDE Entity's system, and
then Batch Auto-Renewal (BAR) opt-out
Pick up an existing in-progress FA application and
remove a member

User claims an initial application that does not exist in EDE Entity's system and
performs a CIC by adding a member. The application has no SVI or DMIs. After the
CIC, the user opts out of BAR.
User creates a 7 member FA initial application and leaves it in-progress;
returns to the application at a later time, removes a member and submits. The
application has Past Loss of MEC SVI and pended Plan Selection (PPS).
User returns to an existing initial application and performs a non-SEP CIC with
changes to communication preferences. He/She changes elected APTC on existing
pended enrollment.
Consumer has an existing initial application in an EDE Entity's system. Consumer
cancels existing coverage. Consumer then revokes permissions for their current
EDE Entity.
User creates an initial FA application for 2 members eligible for QHP and enrolls in
pended plans. The application has Income DMI and Past Loss of MEC SVI. Both the
SVI and the DMI are resolved and pended plans are released. Consumer
subsequently terminates their coverage.

F003_MPL-02-A-1011

MTST_EDE_E2E_ F004

MTST_EDE_E2E_ F005

Non-SEP CIC with changes to communication
preferences and elected APTC

MTST_EDE_E2E_ F006

Consumer cancels coverage and then revokes
permission for the current EDE Entity

MTST_EDE_E2E_ F007

Initial FA application with DMI and SVI, where both
the DMI and SVI are resolved and pended plans are
released; consumer subsequently terminates
coverage

MTST_EDE_E2E_ F008

Initial non-FA application with each individual
member enrolling in a different plan, and subsequent
Initial non-FA application with an SVI; PPS is cancelled
when SVI is expired

MTST_EDE_E2E_ F009

MTST_EDE_E2E_ F010

MTST_EDE_E2E_ F011
MTST_EDE_E2E_ F012

Initial non-FA application with an SSN DMI and
Citizenship DMI. The Citizenship DMI is expired and
applicant becomes ineligible for QHP
2023 FA application created from 2022 application
Consumer attests to being an American
Indian/Alaskan Native; Phase 1 and Phase 2 EDE
Entities redirect consumer from their website to the
Classic DE (aka double-redirect) pathway or to

User submits an initial non-FA application for 3 members. The application has no
SVI and no DMIs. Each individual member is enrolled into a different plan. User
User submits an initial non-FA application for 3 members and selects plans. The
application has an SVI and no DMI. The SVI is expired and pended plans are
cancelled.
User creates an initial 2 member non-FA application eligible for APTC.
The primary member has an SSN DMI and a Citizenship DMI. There is no SVI on the
application. The Citizenship DMI is expired and the primary becomes ineligible for
User pre-populates an initial 2023 FA application, using an inactive 2022 non-FA
application. The application is eligible for APTC.
User creates a 3 member initial FA application eligible for APTC.
All members attest to being American Indian/Alaska native.

Mapping Test Data Sheet

Auditor Compliance Conclusion
**

F004_MPL-07-AC-5158

Auditor Checklist Item F002 Step 9 (row 27) compliance conclusion:
Test Case F003 compliance conclusion:
Auditor Checklist Item F003 Step 8 (row 35) compliance conclusion:
Auditor Checklist Item F003 Step 17 (row 44) compliance conclusion:
Test Case F004 compliance conclusion:

Continuation of F004

Auditor Checklist Item F004 Step 23 (row 69) compliance conclusion:
Test Case F005 compliance conclusion:

Continuation of F005

Auditor Checklist Item F005 Step 9 (row 80) compliance conclusion:
Test Case F006 compliance conclusion:

F007_MPL-02-Q-4006

F008_MPL-04-Q-4010
F009_MPL-03-A-5019

F010-TCS-128

F011_MPL-02-AC-5243
F012_MPL-03-AC-1023

Auditor Checklist Item F006 Step 3 (row 83) compliance conclusion:
Test Case F007 compliance conclusion:
Auditor Checklist Item F007 Step 16 (row 100) compliance conclusion:
Auditor Checklist Item F007 Step 18 (row 102) compliance conclusion:
Auditor Checklist Item F007 Step 22 (row 106) compliance conclusion:
Auditor Checklist Item F007 Step 24 (row 108) compliance conclusion:
Auditor Checklist Item F007 Step 25 (row 109) compliance conclusion:
Test Case F008 compliance conclusion:
Auditor Checklist Item F008 Step 16 (row 125) compliance conclusion:
Test Case F009 compliance conclusion:
Auditor Checklist Item F009 Step 16 (row 152) compliance conclusion:
Test Case F010 compliance conclusion:
Auditor Checklist Item F010 Step 16 (row 173) compliance conclusion:
Auditor Checklist Item F010 Step 20 (row 177) compliance conclusion:
Test Case F011 compliance conclusion:
Auditor Checklist Item F011 Step 17 (row 195) compliance conclusion:
Test Case F012 compliance conclusion:
Auditor Checklist Item F012 Step 2 (row 198) compliance conclusion:
Auditor Checklist Item F012 Step 13 (row 209) compliance conclusion:
Auditor Checklist Item F012 Step 17 (row 213) compliance conclusion:

Compliance Documentation (Required)
Risk Level**
Risks Identified**

Risk Mitigation Strategy**

Estimated Resolution Date**

Auditor Comments

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E Initial FA application with
_ F001
no SVI or DMIs

MTST_EDE_E2E
_ F001

User submits an initial FA application
for 2 members. Both members are US
citizens and the application has no SVI
or DMIs.

Step 1

Step 2

Consumer pathway testing: Consumer account is created (optional, depending on EDE
Entity's implementation).
Agent/Broker pathway testing: Consumer account creation should not be required in
the agent/broker workflow.

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

For the in-person agent/broker flow, manual ID proofing is required, but
can be simulated for purposes of testing the A/B flow.

Auditor Checklist Item F001 Step 2a: Agent/Broker pathway testing: Auditor confirms
the agent is required to enter the document type and document identifier used for
manual ID proofing in the in-person agent/broker flow.

For RIDP/FARS testing, refer to the RIDP/FARS data For agent/broker pathway testing only:
available on the zONE at the following location:
1) UI screenshot showing that the agent/broker is required to
https://zone.cms.gov/document/enhanced-direct- enter the document type and document identifier used for
enrollment-ede-documents-and-materials
manual ID proofing in the in-person agent/broker flow.

Auditor Checklist Item F001 Step 2b: Agent/Broker pathway testing: Auditor confirms
that the EDE Entity's UI requirements for manually ID proofing are in alignment with
the "Acceptable Documentation for ID Proofing" document on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andNote: Since RIDP/FARS and 3rd-party ID proofing service test harness data materials.
will not be in sync with FFM test harness data, this step is optional for
consumer pathway testing. EDE Entities are permitted to bypass ID
proofing for the consumer pathway in the test environment. EDE Entities
that will use the RIDP/FARS services in production however, should note
that there is separate RIDP/FARS testing that must be completed through
the Hub in order to get approved to use these services; the separate
RIDP/FARS testing requirements can be found on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ededocuments-and-materials.
For the telephone agent/broker flow, manual ID proofing is not required.
For purposes of testing, EDE Entities must simulate manual ID proofing in
an in-person agent/broker flow if they have an agent/broker pathway.

MTST_EDE_E2E
_ F001

Step 3

Call Store ID Proofing Record API to store the ID proofing information.

The ID proofing record is successfully stored.

Note: This step is systematically required only for the consumer and inperson A/B flows.

1) Store ID Proofing API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

Note: If consumer pathway ID proofing is bypassed for testing in Step 2,
the EDE Entity will still need to store ID proofing data in order to obtain
permission for the application; a mock online transaction identifier can be
provided in the Store ID Proofing call if the consumer pathway ID proofing
was bypassed for testing.
MTST_EDE_E2E
_ F001

Step 4

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

Note: The location of the permission attestation may vary in the EDE
Entity's UI for the consumer pathway. For the agent/broker pathway
however, this attestation must be presented to the A/B on the Person
Search UI page.

MTST_EDE_E2E
_ F001

Step 5

Call Person Search API to check if there is an existing application.

No results are returned from Person Search call.

Note: Manual searching/claiming will occur for the Agent/Broker flow and Auditor Checklist Item F001 Step 5a: Consumer pathway testing: Auditor confirms the
backend searching/claiming will occur for consumer flow.
EDE Entity's UI does not have a consumer facing Person Search option. This should be
a backend search in the consumer flow, that isn't exposed directly to the consumer.

Auditor Checklist Item F001 Step 5c: Agent/Broker pathway testing: Auditor also
confirms the agent/broker isn't able to proceed with the Person Search until the
necessary attestation is provided, and that the agent/broker receives an applicable
error when attempting to proceed with the Person Search without completing the
necessary attestation.
Auditor Checklist Item F001 Step 5d: Agent/Broker pathway testing: Auditor confirms
the Person Search UI option meets the requirements outlined in the "EDE Person
Search" Section of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.
Step 6

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot showing that the user is required to attest
that permission has been granted to act on the consumer's
behalf. Note that for the agent/broker pathway, the
agent/broker is required to attest on the Person Search UI
page to having the consumer's permission to work on their
behalf, and related screenshots should reflect such.

Auditor Checklist Item F001 Step 5b: Agent/Broker pathway testing: Auditor confirms
the agent is required to attest to having the consumer's permission to work on their
behalf on the Person Search page. For the agent/broker pathway, the permission
attestation must be located on the Person Search page.

MTST_EDE_E2E
_ F001

For both consumer pathway and agent/broker pathway
testing:

Call Create App API to create an application and an Application ID, after
An Application ID is generated.
user enters basic information by providing household contact information,
such as home/mailing address, phone number, and communication
preferences.

For both consumer pathway and agent/broker pathway
testing:
1) Person Search API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
For agent/broker pathway testing:
1) UI screenshot showing the error that the agent/broker
receives if attempting to proceed with the Person Search
without completing the attestation that they have permission
to work on the consumer's behalf.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F001

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

For both consumer pathway and agent/broker pathway
testing:
1) Store Permission API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F001

Step 8

MTST_EDE_E2E
_ F001

Step 9

Call Add Member API when user adds additional members to the
application.

Members added to the application.

This step is optional, depending on entity implementation. Entities can
alternatively add both members during the initial Create App API call.
User enters application data for each member within the EDE Entity's UI.

User is able to proceed with completion of the application.

Refer to details in the "Data Inputs" column.

Member 1 attests to a Release from Incarceration
SEP.

Primary is filing taxes and claiming Member 2 (M2) as dependent.
MTST_EDE_E2E
_ F001

Step 10

Call Update App API to store attestations and trigger related flows.

Refer to data set F001_MPL-02-A-1081

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

MTST_EDE_E2E
_ F001

Step 11

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F001

Step 12

Call Get App API to retrieve the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F001

Step 13

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Eligibility Determination Notice (EDN).

Consumer can download EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F001

Step 14

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

The API calls return no data. No SVI or DMI messaging is displayed in the UI.

MTST_EDE_E2E
_ F001

Step 15

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.

Enrollment is submitted successfully.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

For agent/broker pathway testing:
1) Fetch Eligibility API request and response. Note: This step is
optional, depending on entity implementation. Entities that
utilize Fetch Eligibility must provide this evidence.

For agent/broker pathway testing:
1) Submit Enrollment API request and response

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
MTST_EDE_E2E
_ F001

Step 16

MTST_EDE_E2E
_ F001

Step 17

Call Get Enrollment API to retrieve enrollment details/status.

Enrollment information is displayed in the UI.
Auditor Checklist Item F001 Step 16: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

Call Payment Redirect API to retrieve payment redirect URL and payment
redirect SAML.
Note: If the EDE Entity is an issuer, the entity is not required to integrate
with the Payment Redirect API if the entity directly hosts a payment
service; the issuer would still need to provide evidence that the consumer
can make a payment, as described in #1 in the "Required Evidence"
column. If the EDE Entity is an issuer and does not offer an option for a
consumer to make a binder payment online, the auditor can indicate this
in lieu of providing the "Required Evidence" in column H.

Either: 1) Payment redirect occurs for the consumer in the UI, or 2) the consumer isn't
given a payment redirect option if they selected a plan with an issuer that doesn't
support payment redirect (in which case the Payment Redirect API response won't
include a payment redirect URL).
Note: The payment redirect URL returned by the Payment Redirect API will be for the
issuer's production environment, and payment redirect to the issuer's payment site
may therefore fail from the test environment; this is an acceptable result, however
note that the Payment Redirect API should still return a successful response in this
scenario.

For both consumer pathway and agent/broker pathway
testing:
1) If the user selects a plan that is eligible for payment
redirect, UI screenshot showing the payment redirect option
in the EDE Entity's UI.
2) Payment Redirect API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response. Note: This is not
required if the EDE Entity is an issuer that directly hosts a
payment service; the auditor should document this if
applicable. This is also not required if the EDE Entity is an
issuer that does not offer an online option for binder
payments; the auditor should document this if applicable.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E CIC FA application with no
_ F002
SVI or DMIs

User performs a CIC on an initial FA
application existing in the EDE Entity's
system. The application has no SVI or
DMIs.

Step 1

Log in (if applicable) to an existing user account from test case
MTST_EDE_E2E_ F001 and call Person Search API to retrieve the linked
application.

MTST_EDE_E2E
_ F002

Step 2

Call Get App API to retrieve the application details.

MTST_EDE_E2E
_ F002

Step 3

User reports a life change and proceeds through application. User
User is able to proceed with completion of the application.
updates/changes previously attested income amount and Update App API
is called to trigger related flows. Income should be such that the
Update App API call(s) return(s) "Success."
consumers are still QHP eligible.

Existing application linked to the consumer is displayed.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Note: This step may vary depending upon a EDE Entity's implementation. Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
Some entities may require consumers to create an account, while other
having the consumer's permission to work on their behalf on the Person Search page.
entities may not. Note that consumers are only required to complete ID
For the agent/broker pathway, the permission attestation must be located on the
proofing once as long as they are required to create an account on the
Person Search page.
entity's site and the ID proofing occurrence is associated with the created Auditor also confirms the agent/broker isn't able to proceed with the Person Search
account.
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
Note: Manual searching/claiming will occur for the Agent/Broker flow and completing the necessary attestation.
backend searching/claiming will occur for consumer flow.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.
Consumer is presented with the pre-populated application.

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.
MTST_EDE_E2E
_ F002

Step 4

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F002

Step 5

Call Get App API to retrieve the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F002

Step 6

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the new EDN.

Consumer can download EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F002

Step 7

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

The API calls return no data. No SVI or DMI messaging is displayed in the UI.

MTST_EDE_E2E
_ F002

Step 8

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.

Enrollment is submitted successfully.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
MTST_EDE_E2E
_ F002

MTST_EDE_E2E Pick up an existing
_ F003
application and report a
CIC with an added
member, and then opt out
of BAR

Step 9

Call Get Enrollment API to retrieve the updated enrollment details/status. Updated enrollment information is displayed in the UI.
Auditor Checklist Item F002 Step 9: Auditor confirms that the required enrollment data
is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

User claims an initial application that
Step 1
does not exist in EDE Entity's system
and performs a CIC with an added
member. The application has no SVI or
DMIs. After the CIC, the user opts out
of BAR.

ISAVE submits an initial 1 member FA application via the Call Center
An application is created.
Representative (CCR) portal with a large currentIncome sequence number.
Note: This step is not completed by the EDE Entity, however applications
must be requested by the EDE Entity, as per the, "Data Inputs."

Test case MTST_EDE_E2E_ F003 requires the EDE
Entity to report a CIC on an application that wasn't
originally created by the EDE Entity. The EDE Entity
should email
[email protected] with
the subject line, "Request for App IDs: EDE API
Test Scenario F003," to obtain existing
applications. Upon request, three applications will
be provided to the EDE Entity. Additional
applications can be requested by the EDE Entity, if
needed.
Note: The existing applications will be Alabama
applications. If an EDE Entity needs non-Alabama
applications, that should be noted in the email
request.

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F003

MTST_EDE_E2E
_ F003

Step 2

Step 3

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

For the telephone agent/broker flow, manual ID proofing is not required.
For purposes of testing, EDE entities must simulate manual ID proofing in
an in-person agent/broker flow if they have an agent/broker pathway.
Note: Since RIDP/FARS and 3rd-party ID proofing service test harness data
will not be in sync with FFM test harness data, this step is optional for
consumer pathway testing. EDE Entities are permitted to bypass ID
proofing for the consumer pathway in the test environment. EDE Entities
that will use the RIDP/FARS services in production however, should note
that there is separate RIDP/FARS testing that must be completed through
the Hub in order to get approved to use these services; the separate
RIDP/FARS testing requirements can be found on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ededocuments-and-materials.

Step 4

Agent/Broker pathway testing: Consumer account creation should not be required in
the agent/broker workflow.

Consumer is ID proofed.

For the in-person agent/broker flow, manual ID proofing is required, but
can be simulated for purposes of testing the A/B flow.

MTST_EDE_E2E
_ F003

Consumer pathway testing: Consumer account is created (optional, depending on EDE
Entity's implementation).

Call Store ID Proofing Record API to store the ID proofing information.
Note that the Date of Birth for the existing member will be provided
when applications are requested in Step 1.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: in Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor reviewed
this functionality. The Auditor must complete the review described in this cell (see the
two "Auditor confirms..." items). However, the Auditor does not need to re-document
that the functionality described in the "Auditor confirms..." clauses works as expected
if the functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 2a and Step 2b. However, if the functionality does not
operate consistent with the Auditor's compliance determination as documented for
Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor must document this
discrepancy as a risk for this test case. The Auditor must document risks in the "Test
Case Overview" tab where the Auditor is documenting its compliance determinations.

The ID proofing record is successfully stored.

Note: This step is systematically required only for the consumer and inperson A/B flows.
Note also: If consumer pathway ID proofing is bypassed for testing in Step
3, the EDE Entity will still need to store ID proofing data in order to obtain
permission for the application; a mock online transaction identifier can be
provided in the Store ID Proofing call if the consumer pathway ID proofing
was bypassed for testing.
MTST_EDE_E2E
_ F003

Step 5

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

Step 6

Call Person Search API by using a combination of SSN and Date of Birth to
check if there is an existing application. Note that the SSN and DOB for
the existing member will be provided when applications are requested in
Step 1.
Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

Existing application details are displayed and/or existing application is claimed.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F003

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F003

Step 8

User reports a life change and Get App API is called to retrieve details for
the existing application.

Consumer is presented with the pre-populated application.

For both consumer pathway and agent/broker pathway
testing:

Auditor Checklist Item F003 Step 8: Auditor confirms the UI only displays the original
consumer and is pre-populated with the original consumer's previous attestations.

1) UI screenshot(s) showing the entity's eligibility application
(test names, addresses, and household information) is prepopulated with the information the consumer already
provided on the existing eligibility application.
2) Get App API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F003

Step 9

Request financial assistance and
call Add Member API to add a new member to the application

Member is added to the application and the Add Member API call returns "Success."

For both consumer pathway and agent/broker pathway
testing:
1) Add Member API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F003

Step 10

User enters application data for each member within the EDE Entity's UI.

User is able to proceed with completion of the application.

MTST_EDE_E2E
_ F003

Step 11

MTST_EDE_E2E
_ F003

Step 12

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F003

Step 13

Call Get App API to fetch the updated eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F003

Step 14

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the new EDN.

Consumer can download EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F003

Step 15

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

The API calls return no data. No SVI or DMI messaging is displayed in the UI.

MTST_EDE_E2E
_ F003

Step 16

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.

Enrollment is submitted successfully.

MTST_EDE_E2E
_ F003

Step 17

MTST_EDE_E2E
_ F003

Step 18

Refer to details in the "Data Inputs" column.

Call Update App API to store attestations and trigger related flows.

Member 1 attests to a Release from Incarceration
SEP and
Member 2 attests to a Permanent Move SEP.
Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
Call Get Enrollment API to retrieve the enrollment details/status.

For both consumer pathway and agent/broker pathway
testing:
1) Screenshot(s) of post-enrollment confirmation page(s).

Enrollment information is displayed in the UI.
Auditor Checklist Item F003 Step 17: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

Call Payment Redirect API to retrieve payment redirect URL and payment
redirect SAML.
Note: If the EDE Entity is an issuer, the entity is not required to integrate
with the Payment Redirect API if the entity directly hosts a payment
service; the user would be routed to the issuer-hosted payment service
directly in this case. If the EDE Entity is an issuer and does not offer an
option for a consumer to make a binder payment online, the entity does
not need to complete this step; the auditor should document this, if
applicable.

MTST_EDE_E2E
_ F003

Refer to data set F003_MPL-02-A-1011

Step 19

Call Update Policy API to opt out of BAR.
Note: In production, BAR opt-out can only occur during a configurable
period identified via the System Reference Data API. In the test
environment, reference data is set to allow BAR opt-out all year.

For both consumer pathway and agent/broker pathway
testing:
1) Screenshots reflecting the location of the BAR opt-out
functionality in the EDE Entity's UI and any related messaging
displayed in the EDE Entity's UI.
2) Update Policy API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E Pick up an existing in_ F004
progress application, and
remove a member

MTST_EDE_E2E
_ F004

User creates a 7 member initial FA
Step 1
application and leaves it in-progress,
then returns to the application at a later
time and removes a member and
submits the application. The application
has a Past Loss of MEC SVI and a
Pended Plan Selection (PPS).
Step 2

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

For the telephone agent/broker flow, manual ID proofing is not required.
For purposes of testing, EDE Entities must simulate manual ID proofing in
an in-person agent/broker flow if they have an agent/broker pathway.
Note: Since RIDP/FARS and 3rd-party ID proofing service test harness data
will not be in sync with FFM test harness data, this step is optional for
consumer pathway testing. EDE Entities are permitted to bypass ID
proofing for the consumer pathway in the test environment. EDE Entities
that will use the RIDP/FARS services in production however, should note
that there is separate RIDP/FARS testing that must be completed through
the Hub in order to get approved to use these services; the separate
RIDP/FARS testing requirements can be found on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ededocuments-and-materials.

Step 3

Agent/Broker pathway testing: Consumer account creation should not be required in
the agent/broker workflow.

Consumer is ID proofed.

For the in-person agent/broker flow, manual ID proofing is required, but
can be simulated for purposes of testing the A/B flow.

MTST_EDE_E2E
_ F004

Consumer pathway testing: Consumer account is created (optional, depending on EDE
Entity's implementation).

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

Note: This step is systematically required only for the consumer and inperson A/B flows.
Note also: If consumer pathway ID proofing is bypassed for testing in Step
2, the EDE Entity will still need to store ID proofing data in order to obtain
permission for the application; a mock online transaction identifier can be
provided in the Store ID Proofing call if the consumer pathway ID proofing
was bypassed for testing.

MTST_EDE_E2E
_ F004

Step 4

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

Step 5

MTST_EDE_E2E
_ F004

Step 6

Call Person Search API to check if there is an existing application.
Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

Call Create App API to create an application and an application ID when
user enters basic information by providing household contact information
such as home/mailing address, phone number, and communication
preferences.

No results are returned from person search call.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.
An application ID is generated.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F004

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F004

Step 8

Call Add Member API when user adds additional 6 members to the
application.

Members are added to the application.

MTST_EDE_E2E
_ F004

Step 9

User enters application data for each member within the EDE Entity's UI
(refer to data inputs column) and leaves the application in-progress after
completing income section.

User is able to proceed with completion of the application up until the point the user
leaves the application.

MTST_EDE_E2E
_ F004

Step 10

Call Update App API to store attestations and trigger related flows.

Update App API call(s) return(s) "Success."

MTST_EDE_E2E
_ F004

Step 11

This step is optional, depending on entity implementation. Entity can
alternatively add all members during the initial Create App API call.
Refer to data set F004_MPL-07-AC-5158
All members attest to a Pass Lost of MEC SVI.

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.
User logs out and then logs back into the EDE Entity's website at a later
time (or closes browser and then opens new browser window, returning
to EDE Entity's website).

User is able to login to the account successfully.

(1) Screenshot of application status (not enrollment/policy
status).

Note: This step may vary depending upon a EDE Entity's implementation.
Some entities may require consumers to create an account, while other
entities may not. Note that consumers are only required to complete ID
proofing once as long as they are required to create an account on the
entity's site and the ID proofing occurrence is associated with the created
account.
Call Person Search API to check if there is an existing application.

MTST_EDE_E2E
_ F004

Step 12

MTST_EDE_E2E
_ F004

Step 13

Call Get App API to retrieve application details.

MTST_EDE_E2E
_ F004

Step 14

Navigate to the Household section to remove a member previously added. User is able to navigate the household section and is successfully able to remove a
member.

MTST_EDE_E2E
_ F004

Step 15

Call Remove Member API to remove a member from the application.

Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/auto-claiming will occur for consumer flow.

For both consumer pathway and agent/broker pathway
testing:

Existing in-progress application is displayed.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.
User is able to resume the in-progress application. Previously entered data is prepopulated in the application.

One of the members is removed successfully from the application.

For both consumer pathway and agent/broker pathway
testing:
1) Remove Member API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F004

Step 16

MTST_EDE_E2E
_ F004

Step 17

Attest to Past Loss of MEC SVI for all remaining members.

User is able to proceed with completion of the application and is able to successfully
attest to a Past Loss of MEC SVI for all remaining members.

Call Update App API to store attestations and trigger related flows.

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

MTST_EDE_E2E
_ F004

Step 18

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F004

Step 19

Call Get App API to fetch the eligibility results.

Eligibility results are displayed in the UI. None of the members are determined
Medicaid/CHIP eligible.

MTST_EDE_E2E
_ F004

Step 20

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.
Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Eligibility Determination Notice (EDN).

Consumer can download EDN from the EDE Entity's website.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F004

Step 21

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Past Loss of MEC SVI messaging is displayed in the UI.
There are no DMIs on the application.

For both consumer pathway and agent/broker pathway
testing:
(1) Screenshot of application status (not enrollment/policy
status)

MTST_EDE_E2E
_ F004

Step 22

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment. The user elects only a portion of the available
Max APTC.

Enrollment is submitted successfully.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot(s) showing the plan selection(s). Note: This is
not asking for screenshots of the QHP shopping page(s) but
the selected QHPs. If the EDE Entity only displays the selected
QHPs within the QHP shopping page(s), then a screenshot of
the QHP shopping page(s) showing the selected QHPs is
sufficient.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.

2) UI screenshot showing the user electing only a portion of
the available Max APTC.
3) Submit Enrollment API request and response, which must
be raw/unmodified and include the complete header and
body for each required API request and response.
MTST_EDE_E2E
_ F004

Step 23

MTST_EDE_E2E
_ F004

Step 24

Call Get Enrollment API to retrieve the enrollment information.

Pended Plan Selection information is displayed in the UI.
Auditor Checklist Item F004 Step 23: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Pended Plan Selection Clock Notice.

Consumer can download Pended Plan Selection Clock Notice from the EDE Entity's
website.

For both consumer pathway and agent/broker pathway
testing:
1) Copy of the Pended Plan Selection Clock Notice.
2) Screenshot of the UI that displays where a consumer can
see all of their notices.
3) Metadata Search API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
4) Notice Retrieval API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F004

Step 25

Call Get SVI API to retrieve updated SVI information for display in the UI.

UI displays a timer for submitting supporting documents for Past Loss of MEC SVI.

For both consumer pathway and agent/broker pathway
testing:
1) Get SVI API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
2) UI screenshot(s) showing the display of the Loss of MEC SVI
messaging as provided by the SVI API including (1) the SVI
status, (2) deadline for each applicable applicant, (3) initial
document upload page, and (4) any other screenshots that
constitute the SVI document upload functionality.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E Non-SEP CIC
_ F005

User returns to an existing initial
Step 1
application and performs a non-SEP CIC
with changes to communication
preferences. User also changes elected
APTC on existing Pended Plan Selection.

Log in to an existing user account from test case MTST_EDE_E2E_ F004
and call Person Search API to retrieve the existing application.
Note: This step may vary depending upon a EDE Entity's implementation.
Some entities may require consumers to create an account, while other
entities may not. Note that consumers are only required to complete ID
proofing once as long as they are required to create an account on the
entity's site and the ID proofing occurrence is associated with the created
account.
Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/auto-claiming will occur for consumer flow.

Existing application linked to the consumer is displayed.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.

MTST_EDE_E2E
_ F005

Step 2

Call Get App API to retrieve the application details.

The application is pre-populated in the EDE Entity's UI.

MTST_EDE_E2E
_ F005

Step 3

Report a life change and update the communication preferences on the
application. Do not make any other changes.

User is successfully able to make the application update to the communication
preferences.

Call Update App API to store attestations and trigger related flows.

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.
MTST_EDE_E2E
_ F005

Step 4

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F005

Step 5

Call Get App API to retrieve the updated eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F005

Step 6

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the new EDN.

Consumer can download EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F005

Step 7

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Past Loss of MEC SVI details are returned/displayed.
There are no DMIs on the application.

MTST_EDE_E2E
_ F005

Step 8

Enrollment is submitted successfully.
User elects to remain in the same plan during plan shopping and the
Submit Enrollment API is called to complete the enrollment. User elects to
use all of the available Max APTC.

MTST_EDE_E2E
_ F005

Step 9

Call Get Enrollment API to retrieve the updated enrollment details/status. Updated Pended Plan Selection information is displayed in the UI.

MTST_EDE_E2E Consumer cancels
_ F006
coverage and revokes
permission

MTST_EDE_E2E
_ F006

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

Auditor Checklist Item F005 Step 9: Auditor confirms that the required enrollment data
is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.
Consumer has an existing initial
Step 1
application in an EDE Entity's system.
Consumer cancels their existing
coverage. Consumer then revokes
permission for their current EDE Entity.

Step 2

User can access the account.

Note: This step may vary depending upon a EDE Entity's implementation.
Some entities may require consumers to create an account, while other
entities may not. Note that consumers are only required to complete ID
proofing once as long as they are required to create an account on the
entity's site and the ID proofing occurrence is associated with the created
account.
User retrieves details for the existing Past Loss of MEC SVI. A
corresponding call is made to the Get SVI API to retrieve the data.

Past Loss of MEC SVI details are returned/displayed in the EDE Entity's UI.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot(s) showing the plan selection(s) Note: This is
For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot(s) showing the enrollment status as pended.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F006

Step 3

Call Update Policy API to cancel existing coverage.

For both consumer pathway and agent/broker pathway
testing:

Existing coverage is cancelled.
Auditor Checklist Item F006 Step 3: Auditor confirms the EDE Entity's UI only allows the
user to select a cancellation date that is equal to, or one day prior, to the coverage start
date.

1) Screenshots reflecting the location of the cancellation
functionality in the EDE Entity's UI, along with any related
messaging displayed in the EDE Entity's UI.
2) Update Policy API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F006

Step 4

Call Revoke Permission API when user revokes permission in the EDE
Entity's UI.

The Revoke Permission API call returns "Success."

For consumer pathway testing only:
1) Revoke Permission API request and response, which must
be raw/unmodified and include the complete header and
body for each required API request and response.

Note: This step does not need to be completed for the agent/broker
pathway, and is only applicable to the consumer pathway.

2) UI screenshot showing the option to revoke permission
within the EDE Entity's UI.
MTST_EDE_E2E Resolve SVI and DMI and
_ F007
subsequently terminate
coverage

MTST_EDE_E2E
_ F007

User creates an initial FA application for Step 1
2 members eligible for a QHP and
enrolls the members in a Pended Plan
Selection. The application has an
Income DMI and Past Loss of MEC SVI.
Both the SVI and the DMI are resolved
and the Pended Plan Selection becomes
a policy. Consumer subsequently
terminates their existing coverage.

Step 2

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

Step 3

Agent/Broker pathway testing: Consumer account creation should not be required in
the agent/broker workflow.

IMPORTANT: As per the assumptions in the Test Case Overview tab,
please note that each entity must change the first name, last name, date
of birth, street address and email address of the applicants within the
data provided when creating applications. The demographic data used
must also be randomized for each test scenario (i.e. you shouldn't use the
same first name, last name, etc. for each test scenario). There are a
number of issues that entities may encounter if they don't randomize the
demographic data, including SVIs and DMIs not generating.

For the in-person agent/broker flow, manual ID proofing is required, but
can be simulated for purposes of testing the A/B flow.

MTST_EDE_E2E
_ F007

Consumer pathway testing: Consumer account is created (optional, depending on EDE
Entity's implementation).

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

MTST_EDE_E2E
_ F007

Step 4

Record consumer's permission to act on their behalf within the EDE
Entity's UI.
Note: The location of the permission attestation may vary in the EDE
entity's UI for the consumer pathway. For the agent/broker pathway
however, this attestation must be presented to the A/B on the Person
Search UI page.

EDE Entity records user/consumer permissions.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F007

Step 5

Call Person Search API to check if there is an existing application.

MTST_EDE_E2E
_ F007

Step 6

An Application ID is generated.
Call Create App API to create an application and an Application ID when
user enters basic information by providing household contact information
such as home/mailing address, phone number, and communication
preferences.

MTST_EDE_E2E
_ F007

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F007

Step 8

Call Add Member API when user adds additional members to the
application.

Members are added to the application.

Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

No results are returned from Person Search call.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.

This step is optional, depending on entity implementation. Entity can
alternatively add all members during the initial Create App API call.
MTST_EDE_E2E
_ F007

Step 9

User enters application data for each member within the EDE Entity's UI
and provides an income of $47000 per year to generate Income DMI.

User is able to proceed with completion of the application.

Member 1 attests to a Past Loss of MEC SVI

Refer to data in the "Data Inputs" column.
EDE Entity may need to make the child age 19-25 for this scenario, to
prevent a Medicaid/CHIP eligibility determination.
Call Update App API to store attestations and trigger related flows.

MTST_EDE_E2E
_ F007

Step 10

MTST_EDE_E2E
_ F007

Step 11

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F007

Step 12

Call Get App API to fetch the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F007

Step 13

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

Refer to data set F007_MPL-02-Q-4006

Consumer can download EDN from the EDE Entity's website.

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F007

Step 14

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Past Loss of MEC SVI and Income DMI messaging are displayed in the UI.

For both consumer pathway and agent/broker pathway
testing:
1) Get DMI API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
2) Get SVI API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
3) UI screenshot showing the display of the Income DMI
messaging, as provided by the DMI API including (1) the DMI
status, (2) deadline for each applicable applicant, (3) initial
document upload page, and (4) any other screenshots that
constitute the DMI document upload functionality (note: this
required evidence is similar to Requirement 2 in the
Communications Toolkit).
4) UI screenshot showing the display of the Loss of MEC SVI
messaging. The Entity must provide evidence that the UI
displays the SVI, status, and deadline from the Get SVI API
response for each applicable applicant.

MTST_EDE_E2E
_ F007

Step 15

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.

Enrollment transaction is completed successfully and UI reflects that the plan selection
is pended.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
MTST_EDE_E2E
_ F007

Step 16

Call Get Enrollment API to retrieve and display enrollment details.

Pended Plan Selection information is displayed in UI.
Auditor Checklist Item F007 Step 16: Auditor confirms that the required Pended Plan
Selection Information is displayed in the UI in accordance with guidance in Section 9.1.1
UI Display of Get Enrollment Data of the EDE API Companion Guide available on zONE
at https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot showing the Pended Plan Selection
information displayed in the UI (i.e., plan status [pending] and
the associated data: QHP ID, Plan Name, Start Date, End Date,
Total Premium, Applied APTC, Individual Responsibility
Amount, and Enrollees).
2) Get Enrollment API request and response.

MTST_EDE_E2E
_ F007

Step 17

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Pended Plan Selection Clock Notice.

MTST_EDE_E2E
_ F007

Step 18

Call Document Upload API to upload supporting documents for Income
User is able to successfully upload supporting documentation.
DMI and Past Loss of MEC SVI. For purposes of testing, the documents can
Auditor Checklist Item F007 Step 18: Auditor confirms that the Document Upload API
be "mock" documents.
request includes the required metadata in accordance with guidance in Section 8.2
Uploading a Document of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

MTST_EDE_E2E
_ F007

Step 19

MTST_EDE_E2E
_ F007

Step 20

ISAVE resolves the Past Loss of MEC SVI and Income DMI.

Consumer can download Pended Plan Selection Clock Notice from the EDE Entity's
website.
For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot showing the document upload option in the
UI.
2) Document Upload API request and response, which must
be raw/unmodified and include the complete header and
body for each required API request and response.

The SVI and DMI are resolved successfully and the Pended Plan Selection is released.

Note: This requires the EDE Entity to submit an adjudication request to
[email protected], following the separate adjudication
instructions on the Adjudication Instructions tab. Note that DMI and SVI
adjudication will generally occur within 24-48 business hours (during
weekdays) of submission.
Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Past Loss of MEC SVI status reflects that it has been resolved in the EDE Entity's UI.
Income DMI status reflects that is has been resolved in the EDE Entity's UI.

For both consumer pathway and agent/broker pathway
testing:
1) Get DMI API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
2) Get SVI API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
3) UI screenshot showing the display of the Income DMI
messaging. The Entity must provide evidence that the UI
displays the DMI, status, and deadline from the Get DMI API
response.
4) UI screenshot showing the display of the Loss of MEC SVI
messaging. The Entity must provide evidence that the UI
displays the SVI, status, and deadline from the Get SVI API
response for each applicable applicant.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F007

Step 21

Call Metadata Search API and Notice retrieval API to retrieve the
Consumer can download an SVI Resolution notice and a DMI Resolution notice from
applicable DSRS IDs, as well as both the SVI Resolution notice and the DMI the EDE Entity's website.
Resolution notice.

For both consumer pathway and agent/broker pathway
testing:
1) Copy of the SVI Resolution Notice.
2) Copy of the DMI Resolution Notice.
3) Screenshot of the UI that displays where a consumer can
see all of their notices.
4) Metadata Search API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
5) Notice Retrieval API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F007

Step 22

Call Get Enrollment API to retrieve the updated enrollment status.

EDE Entity's UI reflect the updated enrollment status (Pended Plan Selection is now a
policy).

For both consumer pathway and agent/broker pathway
testing:

Auditor Checklist Item F007 Step 22: Auditor confirms that the required Policy
Information is displayed in the UI in accordance with guidance in Section 9.1.1 UI
Display of Get Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

1) UI screenshot showing the enrollment information
displayed in the UI (i.e., the enrollment displays in the UI with
the updated enrollment status and the UI includes data
associated with the policy [i.e., QHP ID, Plan Name, Start Date,
End Date, Total Premium, Applied APTC, Individual
Responsibility Amount, and Enrollees]).
2) Get Enrollment API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F007

Step 23

Verify that the following Event-Based Processing API events have been
received, and that the corresponding emails have been generated for the
consumer:
1) Application submitted event.
2) DMI created event.

1) Application submitted event received, and corresponding email is generated and
sent to the consumer.
2) DMI created event received, and corresponding email is generated and sent to the
consumer.

Note: The Event-Based Processing API is required for DMIs and optional
for SVIs.

For both consumer pathway and agent/broker pathway
testing (if applicable, based on notes in Column E):
1) Event-Based Processing API request(s) and response(s),
which must be raw/unmodified and include the complete
header and body for each required API request and response.
2) Copies of the generated emails.

Note: The Get App API may be used to retrieve any additional metadata
that is necessary for email communication (i.e. consumer’s name, email
address, preferred written language, etc.).
MTST_EDE_E2E
_ F007

MTST_EDE_E2E
_ F007

Step 24

Step 25

Call Update Policy API to terminate existing coverage, effective 12/31 of
the applicable coverage year.

Call Update Policy API to terminate existing coverage, effective any date
prior to 12/31 of the applicable coverage year.

Existing coverage is terminated, effective 12/31 of the applicable coverage year.
Auditor Checklist Item F007 Step 24: Auditor confirms the EDE Entity's UI only allows
the user to select a termination date that is the current or a prospective date, and a
date that is equal to or prior to 12/31 of the applicable coverage year.

For both consumer pathway and agent/broker pathway
testing:
1) Screenshots reflecting the location of the termination
functionality in the EDE Entity's UI, along with any related
messaging displayed in the EDE Entity's UI (including the
updated display of the terminated enrollment status and end
date).

Existing coverage is terminated, effective a date prior to 12/31 of the applicable
coverage year.

For both consumer pathway and agent/broker pathway
testing:

Auditor Checklist Item F007 Step 25: Auditor confirms the EDE Entity's UI only allows
the user to select a termination date that is the current or a prospective date, and a
date that is equal to or prior to 12/30 of the applicable coverage year.

1) Screenshots reflecting the location of the termination
functionality in the EDE Entity's UI, along with any related
messaging displayed in the EDE Entity's UI (including the
updated display of the terminated enrollment status and end
date).
2) Update Policy API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E Initial non-FA application
_ F008
with each individual
member enrolling in a
different plan, and
subsequent CIC
application/enrollment
subject to Plan Category
Limitations.

User submits an initial non-FA
Step 1
application for 3 members. The
application has no SVI and no DMIs.
Each individual member is enrolled into
a different plan. User then reports a
CIC on a subsequent day and adds a
newly adopted child; during enrollment
the initial 3 members are restricted to
existing plan selection, and only the
new member can select from all
available plans in the EDE Entity's UI.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F008

Step 2

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

For the in-person agent/broker flow, manual ID proofing is required, but
can be simulated for purposes of testing the A/B flow.
For the telephone agent/broker flow, manual ID proofing is not required.
For purposes of testing, EDE Entities must simulate manual ID proofing in
an in-person agent/broker flow if they have an agent/broker pathway.
Note: Since RIDP/FARS and 3rd-party ID proofing service test harness data
will not be in sync with FFM test harness data, this step is optional for
consumer pathway testing. EDE Entities are permitted to bypass ID
proofing for the consumer pathway in the test environment. EDE Entities
that will use the RIDP/FARS services in production however, should note
that there is separate RIDP/FARS testing that must be completed through
the Hub in order to get approved to use these services; the separate
RIDP/FARS testing requirements can be found on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ededocuments-and-materials.

MTST_EDE_E2E
_ F008

Step 3

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

MTST_EDE_E2E
_ F008

Step 4

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

Step 5

Call Person Search API to check if there is an existing application.
No results are returned from Person Search call.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
Note: Manual searching/claiming will occur for the Agent/Broker flow and consumer facing Person Search option. This should be a backend search in the
backend searching/claiming will occur for consumer flow.
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.

MTST_EDE_E2E
_ F008

Step 6

An Application ID is generated.
Call Create App API to create an application and an Application ID, after
user enters basic information by providing household contact information,
such as home/mailing address, phone number, and communication
preferences.

MTST_EDE_E2E
_ F008

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F008

Step 8

Call Add Member API when user adds additional members to the
application.

Members added to the application.

This step is optional, depending on entity implementation. Entities can
alternatively add both members during the initial Create App API call.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F008

Step 9

User enters application data for each member within the EDE Entity's UI.

User is able to proceed with completion of the application.

Refer to data set F008_MPL-04-Q-4010
Member 3 (newborn child) must be exactly 60
days old, which will result in a Newborn SEP.
Note, if the child's date of birth does not meet
this requirement, the expected outcome of the
test scenario may not be achieved.

Refer to details in the "Data Inputs" column.

Application data should only be entered for
Members 1, 2, and 3. Application data for
Member 4 should not be entered until Step 20.
MTST_EDE_E2E
_ F008

Step 10

Call Update App API to store attestations and trigger related flows.

MTST_EDE_E2E
_ F008

Step 11

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F008

Step 12

Call Get App API to retrieve the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F008

Step 13

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Eligibility Determination Notice (EDN).

Consumer can download EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F008

Step 14

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

The API calls return no data. No SVI or DMI messaging is displayed in the UI.

MTST_EDE_E2E
_ F008

Step 15

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment. Each member of the household enrolls into a
different plan.

Enrollment is submitted successfully.

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot(s) showing the plan selections. Note: This is
not asking for screenshots of the QHP shopping page(s) but
the selected QHPs. If the EDE Entity only displays the selected
QHPs within the QHP shopping page(s), then a screenshot of
the QHP shopping page(s) showing the selected QHPs is
sufficient.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.

2) Submit Enrollment API request and response, which must
be raw/unmodified and include the complete header and
body for each required API request and response.
3) UI Screenshot(s) showing all post-enrollment pages.
MTST_EDE_E2E
_ F008

Step 16

Call Get Enrollment API to retrieve enrollment details/status.

Enrollment information is displayed in the UI. UI reflects 3 separate enrollment groups,
with each member being enrolled in a different plan.

For both consumer pathway and agent/broker pathway
testing:

Auditor Checklist Item F008 Step 16: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

1) UI screenshot showing the enrollment information
displayed in the UI (i.e., plan status and the associated data:
QHP ID, Plan Name, Start Date, End Date, Total Premium,
Applied APTC, Individual Responsibility Amount, and
Enrollees).
2) UI screenshot showing instructions to the consumer on
how to make any necessary updates to their FFE application,
including reporting CiCs or supporting consumers during SEPs
outside of the OEP.
3) Get Enrollment API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F008

Step 17

User logs out of the EDE Entity's website (or closes browser window).
Note: The remaining steps must be completed on a subsequent day. If
the EDE Entity attempts to complete the remaining steps the same day,
the expected results will not be achieved.

User successfully logs out of the EDE Entity's website (or closes the browser window).

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F008

Step 18

User returns to the existing account to report a CIC.

Existing application linked to the consumer is displayed.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
Note: This step may vary depending upon a EDE Entity's implementation. For the agent/broker pathway, the permission attestation must be located on the
Some entities may require consumers to create an account, while other
Person Search page.
entities may not. Note that consumers are only required to complete ID
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
proofing once as long as they are required to create an account on the
until the necessary attestation is provided, and that the agent/broker receives an
entity's site and the ID proofing occurrence is associated with the created applicable error when attempting to proceed with the Person Search without
account.
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
Note: Manual searching/claiming will occur for the Agent/Broker flow and requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directbackend searching/claiming will occur for consumer flow.
enrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab.

Log in (if applicable) to an existing user account from test case
MTST_EDE_E2E_ F001 and call Person Search API to retrieve the linked
application.

MTST_EDE_E2E
_ F008

Step 19

Call Get App API to retrieve the application details.

MTST_EDE_E2E
_ F008

Step 20

User reports a life change to add a newly adopted child. Call Add Member Member 4 (adopted child) is added to the application.
API when user adds adopted child (Member 4) to the application.

Consumer is presented with the pre-populated application.

MTST_EDE_E2E
_ F008

Step 21

User proceed with completion of the application. User attests to Member User is able to proceed with completion of the application.
4 being newly adopted in the last 60 days. No other changes are made to
Update App API call(s) return(s) "Success."
the application. Call Update App API to store attestations and trigger
related flows.

Refer to data set F008_MPL-04-Q-4010
User attests to Adoption SEP for Member 4.

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.
MTST_EDE_E2E
_ F008

Step 22

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F008

Step 23

Call Get App API to retrieve the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F008

Step 24

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the new EDN.

Consumer can download EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F008

Step 25

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

The API calls return no data. No SVI or DMI messaging is displayed in the UI.

MTST_EDE_E2E
_ F008

Step 26

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment. During plan shopping, EDE Entity's UI reflects
that Members 1, 2, and 3 are restricted to their existing plans in their
separate enrollment groups; EDE Entity's UI reflects that Member 4 can
select from any available plan. Member 4 either selects their own plan, or
chooses to enroll with one of the existing enrollment groups (given QHP
business rules allow such).

During plan shopping, EDE Entity's UI reflects that Members 1, 2, and 3 are restricted to
their existing plans in their separate enrollment groups; EDE Entity's UI reflects that
Member 4 can select from any available plan.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

Enrollment is submitted successfully.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
Note also: Plan Category Limitations guidance can be found in the DE API
Specs available on zONE at https://zone.cms.gov/document/directenrollment-de-documents-and-materials.

MTST_EDE_E2E
_ F008

Step 27

Call Get Enrollment API to retrieve the updated enrollment details/status. Updated enrollment information is displayed in the UI.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot(s) showing the plan selections for all
members. Note: This is not asking for screenshots of the QHP
shopping page(s) but the selected QHPs. If the EDE Entity only
displays the selected QHPs within the QHP shopping page(s),
then a screenshot of the QHP shopping page(s) showing the
selected QHPs is sufficient.
2) UI screenshot(s) showing that Members 1, 2, and 3 are
restricted to their existing plans in their separate enrollment
groups while Member 4 can select from any plan.
3) Submit Enrollment API request and response, which must
be raw/unmodified and include the complete header and
body for each required API request and response.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E Non-FA application with
_ F009
SVI. PPS is cancelled when
SVI is expired.

User submits an initial non-FA
Step 1
application for 3 members and selects
plans. The application has an SVI and
no DMI. The SVI is expired and Pended
Plan Selections are cancelled.

IMPORTANT: As per the assumptions on the Test Case Overview tab,
please note that each entity must change the first name, last name, date
of birth, street address and email address of the applicants within the
data provided when creating applications. The demographic data used
must also be randomized for each test scenario (i.e. you shouldn't use the
same first name, last name, etc. for each test scenario). There are a
number of issues that entities may encounter if they don't randomize the
demographic data, including SVIs and DMIs not generating.
MTST_EDE_E2E
_ F009

Step 2

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

MTST_EDE_E2E
_ F009

Step 3

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

MTST_EDE_E2E
_ F009

Step 4

Record consumer's permission to act on their behalf within the EDE
Entity's UI.
Note: The location of the permission attestation may vary in the EDE
Entity's UI for the consumer pathway. For the agent/broker pathway
however, this attestation must be presented to the A/B on the Person
Search UI page.

EDE Entity records user/consumer permissions.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F009

Step 5

Call Person Search API to check if there is an existing application.

MTST_EDE_E2E
_ F009

Step 6

MTST_EDE_E2E
_ F009
MTST_EDE_E2E
_ F009

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

Step 8

Call Add Member API when user adds additional members to the
application.

Members are added to the application.

MTST_EDE_E2E
_ F009

Step 9

MTST_EDE_E2E
_ F009

Step 10

MTST_EDE_E2E
_ F009

Step 11

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F009

Step 12

Call Get App API to fetch the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F009

Step 13

Consumer can download EDN from the EDE Entity's website.
Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and retrieve the Eligibility Determination Notice (EDN).

MTST_EDE_E2E
_ F009

Step 14

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

This step is optional, depending on entity implementation. Entity can
alternatively add all members during the initial Create App API call.
User chooses a non-FA flow and enters application data for each member User is able to proceed with completion of the application.
within the EDE Entity's UI and attests to a Past Loss of MEC SEP for the
primary member.
(Refer to data in the "Data Inputs" column).
Call Update App API to store attestations and trigger related flows.

Refer to data set F009_MPL-03-A-5019
Member 1 attests to a Past Loss of MEC SEP

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

Past Loss of MEC SVI is displayed in the UI. There is no DMI on the application.

MTST_EDE_E2E
_ F009

Step 15

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.
Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.

Enrollment transaction is completed successfully and UI reflects that the plan selection
is pended.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F009

Step 16

MTST_EDE_E2E
_ F009
MTST_EDE_E2E
_ F009

Step 17

Call Get Enrollment API to retrieve and display enrollment details.

Pended Plan Selection information is displayed in the UI.
Auditor Checklist Item F009 Step 16: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

Step 18

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Pended Plan Selection Clock Notice.
No supporting documents are uploaded for the Past Loss of MEC SVI and
the timer expires. ISAVE runs the Expire SVI API for the Past Loss of MEC
SVI.

Consumer can download Pended Plan Selection Clock Notice from the EDE Entity's
website.
The Past Loss of MEC SVI is expired and Pended Plan Selections are cancelled.

Note: This requires the EDE Entity to submit an adjudication request to
[email protected], following the separate adjudication
instructions on the, "Adjudication Instructions," tab. Note, DMI and SVI
adjudication will generally occur within 24-48 business hours (during
weekdays) of submission.
MTST_EDE_E2E
_ F009

Step 19

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Past Loss of MEC SVI status reflects the SVI is expired. There is no DMI on the
application.

MTST_EDE_E2E
_ F009

Step 20

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the SVI Expiration Notice.

Consumer can download the SVI Expiration Notice from the EDE Entity's website.

For both consumer pathway and agent/broker pathway
testing:
1) Copy of the SVI Expiration Notice.
2) Screenshot of the UI that displays where a consumer can
see all of their notices.
3) Metadata Search API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
4) Notice Retrieval API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F009

Step 21

Call Get Enrollment API to retrieve the updated enrollment status.

Enrollment status reflects that any plans have been cancelled.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot showing any plans that have been cancelled
(i.e., the screenshot must demonstrate the UI displays an
enrollment status (i.e. cancelled) for any plans that have been
cancelled).
2) Get Enrollment API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E Non-FA application with an
_ F010
SSN DMI and Citizenship
DMI. There is no SVI on the
application. The Citizenship
DMI is expired.

User creates an initial 2-member nonFA application eligible for QHP.
The primary member has an SSN DMI
and a Citizenship DMI. There is no SVI
on the application. When the
Citizenship DMI is expired the primary
member becomes ineligible for a QHP
and the second member is re-enrolled
into the existing plan.

Step 1

A consumer account is created on the EDE Entity website.
Note: This step is optional and may vary depending upon a EDE Entity's
implementation. Some entities may require consumers to create an
account, while other entities may not. Note that consumers are only
required to complete ID proofing once as long as they are required to
create an account on the entity's site and the ID proofing occurrence is
associated with the created account.
IMPORTANT: As per the assumptions on the Test Case Overview tab,
please note that each entity must change the first name, last name, date
of birth, street address and email address of the applicants within the
data provided when creating applications. The demographic data used
must also be randomized for each test scenario (i.e. you shouldn't use the
same first name, last name, etc. for each test scenario). There are a
number of issues that entities may encounter if they don't randomize the
demographic data, including SVIs and DMIs not generating.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F010

Step 2

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

MTST_EDE_E2E
_ F010

Step 3

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

MTST_EDE_E2E
_ F010

Step 4

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

Step 5

Call Person Search API to check if there is an existing application.

MTST_EDE_E2E
_ F010

Step 6

MTST_EDE_E2E
_ F010

Step 7

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F010

Step 8

Call Add Member API when user adds additional members to the
application.

Members are added to the application.

Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

This step is optional, depending on entity implementation. Entity can
alternatively add all members during the initial Create App API call.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F010

Step 9

User chooses a non-FA flow and enters application data for each member User is able to proceed with completion of the application.
within the EDE Entity's UI and attests to a Release from Incarceration SEP
for the second member. The primary applicant has an SSN DMI and a
Citizenship DMI.

MTST_EDE_E2E
_ F010

Step 10

MTST_EDE_E2E
_ F010

Step 11

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F010

Step 12

Call Get App API to fetch the eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F010

Step 13

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Eligibility Determination Notice (EDN).

Consumer can download the EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F010

Step 14

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

SSN and Citizenship DMIs are displayed in the UI. There is no SVI on the application.

Refer to data set F010-TCS-128
Member 2 attests to a Release from Incarceration
SEP.

Refer to data in the "Data Inputs" column.
Call Update App API to store attestations and trigger related flows.

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.

MTST_EDE_E2E
_ F010

Step 15

User completes plan shopping and the Submit Enrollment API is called to Enrollment is submitted successfully.
complete the enrollment. The applicants enroll together in the same plan.
Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.

MTST_EDE_E2E
_ F010

Step 16

Call Get Enrollment API to retrieve and display enrollment details.

Plan information is displayed in the UI.
Auditor Checklist Item F010 Step 16: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

MTST_EDE_E2E
_ F010

Step 17

No supporting documents are uploaded for the Citizenship DMI and the
timer expires. ISAVE expires the Citizenship DMI which results in the
eligibility being redetermined and the enrollment being updated.

The Citizenship DMI is expired and the primary applicant is ineligible for QHP.
Eligibility is redetermined and only the second member is re-enrolled in the same plan.

Step 18

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

Citizenship DMI status reflects that it is expired. There is no SVI on the application.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F010

Step 19

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the DMI Clock Expiration Notice.

Consumer is able to retrieve the DMI Clock Expiration Notice via the EDE Entity's UI.

For both consumer pathway and agent/broker pathway
testing:
1) Copy of the DMI Clock Expiration Notice.
2) Screenshot of the UI that displays where a consumer can
see all of their notices.
3) Metadata Search API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.
4) Notice Retrieval API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F010

Step 20

Call Get Enrollment API to retrieve the updated enrollment status.

Initial enrollment status reflects that it has been cancelled/terminated. New enrollment
details are displayed, with only the second member being enrolled in coverage.

For both consumer pathway and agent/broker pathway
testing:

Auditor Checklist Item F010 Step 20: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

1) UI screenshot showing that the initial enrollment has been
cancelled/terminated, and that a new enrollment has been
created with only the second member being enrolled in
coverage (i.e., the screenshot must demonstrate the UI
displays enrollment statuses for two distinct policy activities,
one that is cancelled displaying two members, and one that is
active displaying one member).
2) Get Enrollment API request and response, which must be
raw/unmodified and include the complete header and body
for each required API request and response.

MTST_EDE_E2E
_ F010

Step 21

1) Application submitted event received, and corresponding email is generated and
sent to the consumer.
2) DMI created event received, and corresponding email is generated and sent to the
consumer.
3) DMI expired event received, and corresponding email is generated and sent to the
consumer.

Note: The Event-Based Processing API is required for DMIs and optional
for SVIs.
Note: The Get App API may be used to retrieve any additional metadata
that is necessary for email communication (i.e. consumer’s name, email
address, preferred written language, etc.).
Step 1
MTST_EDE_E2E Create 2023 app from 2022 User pre-populates an initial 2023 FA
_ F011
app
application, using an inactive 2022 nonFA application. The application is
eligible for APTC.

ISAVE creates and submits a 2022 non-FA application for 2 members.

An application is created.

Note: This step is not completed by the EDE Entity, however applications
must be requested by the EDE Entity, as per the instructions in the "Data
Inputs" column.

Test case MTST_EDE_E2E_ F011 requires the
entity create a 2023 application using a 2022
application. The entity should email
[email protected],
with the subject line, "Request for App IDs: EDE
API Test Scenario F011," to obtain 2022
applications. Upon request, three applications will
be provided to the EDE Entity. Additional
applications can be requested by the EDE Entity, if
needed.
Note: The 2022 applications will be Arizona
applications. If an EDE Entity needs non-Arizona
applications, that should be noted in the email
request.

MTST_EDE_E2E
_ F011

Step 2

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F011

Step 3

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

MTST_EDE_E2E
_ F011

Step 4

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

MTST_EDE_E2E
_ F011

Step 5

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

Step 6

MTST_EDE_E2E
_ F011

Step 7

Call Person Search API to check if there is an existing 2023 application.
Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

Call Create App from Prior Year App API to create an application for the
2023 coverage year.

Consumer only has a 2022 application. Consumer or agent/broker is required to use a
pre-populated 2023 application that is created in Step 7 and prepopulated in Step 9,
and is not allowed to create a new 2023 application.
Consumer pathway testing: Auditor confirms the EDE Entity's UI does not have a
consumer facing Person Search option. This should be a backend search in the
consumer flow, that isn't exposed directly to the consumer.
Agent/Broker pathway testing: Auditor confirms the agent is required to attest to
having the consumer's permission to work on their behalf on the Person Search page.
For the agent/broker pathway, the permission attestation must be located on the
Person Search page.
Auditor also confirms the agent/broker isn't able to proceed with the Person Search
until the necessary attestation is provided, and that the agent/broker receives an
applicable error when attempting to proceed with the Person Search without
completing the necessary attestation.
Agent/Broker pathway testing: Auditor confirms the Person Search UI option meets the
requirements outlined in the "EDE Person Search" Section of the EDE API Companion
Guide available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d, the
Auditor already reviewed the functionality in this cell. The Auditor must review the
functionality and complete the assessment described in this cell (i.e., the four "Auditor
confirms..." items). However, the Auditor does not need to re-document that the
functionality described in the "Auditor confirms..." clauses works as expected if the
functionality operates consistent with the Auditor's compliance determination for
Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d. However, if the
functionality does not operate consistent with the Auditor's compliance determination
as documented for Auditor Checklist Items F001 Step 5a, Step 5b, Step 5c, and Step 5d,
the Auditor must document this discrepancy as a risk for this test case in the Test Case
Overview tab
A 2023 Application ID is created.

For both consumer pathway and agent/broker pathway
testing:
1) Create App from Prior Year App API request and response,
which must be raw/unmodified and include the complete
header and body for each required API request and response.

MTST_EDE_E2E
_ F011

Step 8

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F011

Step 9

Call Get App API to retrieve the existing application data, which will then
be pre-populated in the UI for the consumer.

User is presented with a pre-populated 2023 application.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F011

Step 10

User completes the application, requesting financial assistance. User
attests to an APTC-eligible income.

User successfully updates and completes the pre-populated 2023 application.

MTST_EDE_E2E
_ F011

Step 11

Call Update App API to store attestations and trigger related flows.

Update App API call(s) return(s) "Success."

Refer to data set F011_MPL-02-AC-5243

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

MTST_EDE_E2E
_ F011

Step 12

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F011

Step 13

Call Get App API to retrieve the updated eligibility results.

Eligibility Results are displayed in the UI.

MTST_EDE_E2E
_ F011

Step 14

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the EDN.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results.
Consumer can download the EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F011

Step 15

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in the UI.

The API calls return no data. No SVI or DMI messaging is displayed in the UI.

MTST_EDE_E2E
_ F011

Step 16

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.

Enrollment is submitted successfully.

MTST_EDE_E2E
_ F011

Step 17

MTST_EDE_E2E
_ F011

Step 18

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
Call Get Enrollment API to retrieve the enrollment details.

Auditor Checklist Item F011 Step 17: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.
Call Payment Redirect API to retrieve payment redirect URL and payment
redirect SAML.
Note: If the EDE Entity is an issuer, the entity is not required to integrate
with the Payment Redirect API if the entity directly hosts a payment
service; the user would be routed to the issuer-hosted payment service
directly in this case. If the EDE Entity is an issuer and does not offer an
option for a consumer to make a binder payment online, the entity does
not need to complete this step; the auditor should document this, if
applicable.

MTST_EDE_E2E AI/AN scenario - Phase 1
_ F012
and Phase 2 EDE Entities
redirect user to Classic DE
or to HealthCare.gov, and
Phase 3 EDE Entities enroll
the consumer.

Plans details are displayed.

User creates a 3 member initial FA
Step 1
application eligible for APTC. All
members attest to being American
Indian/Alaskan Native. All members on
the application have an AI/AN DMI.
Phase 1 and Phase 2 EDE Entities screen
the user out of their EDE pathway and
redirect the user to HealthCare.gov or
the Classic DE (aka double-redirect)
pathway to complete the application.

Phase 3 EDE Entities allow the user to
continue with application and complete
the enrollment.
MTST_EDE_E2E
_ F012

Step 2

This step is applicable to only Phase 1 and Phase 2 EDE Entities. Phase 3
EDE Entities should skip this step.

Phase 1 and Phase 2 EDE Entities screen the user out at this point and redirect them to
Healthcare.gov or the Classic DE (aka double-redirect) pathway.

For both consumer pathway and agent/broker pathway
testing (Phase 1 and Phase 2 EDE Entities only):

User completes the screener on the Phase 1 or Phase 2 EDE site. User
indicates all members are American Indians.

Auditor Checklist Item F012 Step 2: Auditor confirms the redirect messaging displayed
in the UI aligns with Requirement 4. Phase-Specific Requirements in the EDE
Communications Toolkit contained in the EDE Business Requirements Toolkits zip file.

1) UI screenshot(s) reflecting any messaging or redirect that
occurs when the consumer is screened out of the EDE
pathway.

Phase 1 and Phase 2 EDE Entities do not need to complete any additional steps for this
test scenario.

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F012

Step 3

Consumer is ID proofed.

Consumer is successfully ID proofed.

For the consumer flow, a call is made to the RIDP/FARS API or an
equivalent 3rd-party FICAM TFS approved service.

If using the RIDP/FARS API, a DSH Reference ID will be successfully generated.

MTST_EDE_E2E
_ F012

Step 4

Call Store ID Proofing Record API to store the ID proofing information.

Agent/Broker pathway testing: Auditor confirms the agent is required to enter the
document type and document identifier used for manual ID proofing in the in-person
agent/broker flow.
Agent/Broker pathway testing: Auditor confirms that the EDE Entity's UI requirements
for manually ID proofing are in alignment with the "Acceptable Documentation for ID
Proofing" document on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
Please note: In Auditor Checklist Items F001 Step 2a and Step 2b, the Auditor already
reviewed the functionality in this cell. The Auditor must review the functionality and
complete the assessment described in this cell (i.e., the two "Auditor confirms..."
items). However, the Auditor does not need to re-document that the functionality
described in the "Auditor confirms..." clauses works as expected if the functionality
operates consistent with the Auditor's compliance determination for Auditor Checklist
Items F001 Step 2a and Step 2b. However, if the functionality does not operate
consistent with the Auditor's compliance determination as documented for Auditor
Checklist Items F001 Step 2a and Step 2b, the Auditor must document this discrepancy
as a risk for this test case in the Test Case Overview tab.
The ID proofing record is successfully stored.

MTST_EDE_E2E
_ F012

Step 5

Record consumer's permission to act on their behalf within the EDE
Entity's UI.

EDE Entity records user/consumer permissions.

MTST_EDE_E2E
_ F012

Step 6

MTST_EDE_E2E
_ F012

Step 7

MTST_EDE_E2E
_ F012

Step 8

Call Store Permission API using App ID as input.

Permission is stored successfully.

MTST_EDE_E2E
_ F012

Step 9

Call Add Member API when user adds additional members to the
application.

Members are added to the application.

Note: Manual searching/claiming will occur for Agent/Broker flow and
backend searching/claiming will occur for consumer flow.

This step is optional, depending on entity implementation. Entity can
alternatively add all members during the initial Create App API call.

For RIDP/FARS testing, refer to the RIDP/FARS data
available on the zONE at the following location:
https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials

Required Evidence

Test Case ID

High-level Description

Description

Step

High-Level Steps

Expected Result and Auditor Checklist Items

Data Inputs

Required Evidence

Note: Auditor Checklist Items compliance results must be documented on the Test
Case Overview tab.
MTST_EDE_E2E
_ F012

Step 10

User chooses an FA flow and enters application data for each member
within the EDE Entity's UI.

User is able to proceed with completion of the application.

Refer to data set F012_MPL-03-AC-1023
Member 1 attests to a QSEHRA SEP.

Refer to data in the "Data Inputs" column.
EDE Entity may need to make the child age 19-25 for this scenario, to
prevent a Medicaid/CHIP eligibility determination.
MTST_EDE_E2E
_ F012

Step 11

Call Update App API to store attestations and trigger related flows.

Update App API call(s) return(s) "Success."

Note: Update App may be called at different times depending upon the
EDE Entity's implementation.

MTST_EDE_E2E
_ F012

Step 12

Call Submit App API when user signs and submits the application.

The Submit App API call returns "Success."

MTST_EDE_E2E
_ F012

Step 13

Call Get App API to fetch the eligibility results.

Eligibility Results are displayed in the UI.

Note: The Fetch Eligibility API may also be used to obtain Eligibility Results. QSEHRA-specific messaging is displayed on the eligibility results page. Alternatively, the
QSEHRA-specific messaging is displayed as part of the plan shopping/confirmation
experience.

For both consumer pathway and agent/broker pathway
testing:
1) UI screenshot showing the display of the appropriate
QSEHRA-specific messaging.

Auditor Checklist Item F012 Step 13: Auditor confirms that appropriate QSEHRA
messaging is displayed in the UI in accordance with guidance in Appendix F of the DE
API Specs available on zONE at https://zone.cms.gov/document/enhanced-directenrollment-ede-documents-and-materials.
MTST_EDE_E2E
_ F012

Step 14

Call Metadata Search API and Notice retrieval API to retrieve the
applicable DSRS ID and the Eligibility Determination Notice (EDN).

Consumer can download the EDN from the EDE Entity's website.

MTST_EDE_E2E
_ F012

Step 15

Call Get DMI API and Get SVI API to retrieve and display any applicable
DMI and SVI information in UI.

The SVI API returns no results. The DMI API returns an AI/AN DMI for all members,
which is reflected in the EDE Entity's UI.

MTST_EDE_E2E
_ F012

Step 16

User completes plan shopping and the Submit Enrollment API is called to
complete the enrollment.

Enrollment is submitted successfully.

Note: Plan shopping may occur earlier in the workflow, depending on EDE
Entity implementation.
MTST_EDE_E2E
_ F012

Step 17

MTST_EDE_E2E
_ F012

Step 18

Call Get Enrollment API to retrieve the enrollment details.

1) Screenshot(s) of post-enrollment confirmation page(s).
Plan details are displayed in UI.
Auditor Checklist Item F012 Step 17: Auditor confirms that the required enrollment
data is displayed in the UI in accordance with guidance in Section 9.1.1 UI Display of Get
Enrollment Data of the EDE API Companion Guide available on zONE at
https://zone.cms.gov/document/enhanced-direct-enrollment-ede-documents-andmaterials.

Call Payment Redirect API to retrieve payment redirect URL and payment
redirect SAML.
Note: If the EDE Entity is an issuer, the entity is not required to integrate
with the Payment Redirect API if the entity directly hosts a payment
service; the user would be routed to the issuer-hosted payment service
directly in this case. If the EDE Entity is an issuer and does not offer an
option for a consumer to make a binder payment online, the entity does
not need to complete this step; the auditor should document this, if
applicable.

For both consumer pathway and agent/broker pathway
testing:

DMI and SVI Adjudication Instructions:

1. For scenarios where DMI or SVI adjudication is required, entities will need to send an
adjudication request to [email protected]. Note that DMI and SVI
adjudication will generally occur within 24-48 business hours (during weekdays) of
submission.
2. Entities should use the subject line, "EDE DMI/SVI Adjudication Request."
3. Entities should include a spreadsheet with the details included in the columns to the
right of this box. Entities will need to add the Application IDs and applicable testing
environment in the columns highlighted yellow.

SVI/ DMI ADJUDICATION REQUEST
Testing
Environment (i.e.
UAT0, IMP1A,
IMPL2, etc.)

Name of the SVI/DMI to be
Adjudicated

SVI/DMI Adjudication Request

Scenario # F007

Past Loss of MEC SVI and
Income DMI

Resolve Past Loss of MEC SVI
and Income DMI

Scenario # F009

Past Loss of MEC SVI

Expire Past Loss of MEC SVI

Scenario # F010

Citizenship DMI

Expire Citizenship DMI

E2E Scenario ID

Application ID

File Type	application/pdf
File Title	API Functional Integration Toolkit
Subject	API Functional Integration Toolkit, Centers for Medicare & Medicaid Services
Author	Centers for Medicare & Medicaid Services
File Modified	2024-03-19
File Created	2023-10-11