T-5 Draft RFP Attachment J-XX T-5 MHS Genesis Interface Control Document (ICD) Draft RFP.pdf

Attachment J-XX MHS Genesis Interface Control Document (ICD)

HT9402-XX-C-000X Page 1 of 36

Interface Control Document (ICD) for Legacy Replacement Bi-

Directional Interface from MHS Genesis to the Managed Care Support

Contractor, {insert contract name}

Insert Date Here

Introduction/Background

The connectivity for referrals and authorizations between the Military Treatment Facilities (MTF) and the Purchased Care Sector are managed through an interface between the Managed Care Support Contractor (MCSC) and t h e Composite Occupational Health and Operational Risk Tracking Referral Management System (COHORT/RMS) from SpinSys. The existing Composite Health Care System (CHCS), Care Point Health Care Application Suite (CHAS), and COHORT/RMS have all been deemed Legacy Systems and will be replaced by MHS GENESIS [the new DoD Electronic Health Record (EHR) being managed by the Defense Healthcare Management Systems Modernization (DHMSM) Program Management Office (PMO)]. When MHS GENESIS is deployed to an MTF, those MTFs will discontinue input into COHORT/RMS. Existing CHCS, CHAS, COHORT/RMS interfaces will continue to be used at MTFs that have not been deployed MHS GENESIS. The MCSCs shall be required to run dual interfaces until the MHS GENESIS deployment is completed in their region of support.

1.0 Overall Objectives

The objective of the MHS GENESIS to MCSC bi-directional interface is to ensure all required data to perform referral management and all referral management messages are properly exchanged with MCSC’s Referral and Authorization system. The MHS GENESIS to MCSC’s Referral and Authorization interface, once established, will be maintained to ensure all MHS facilities utilizing MHS GENESIS will have the capability to conduct referral management activities. Additionally, the introduction of MHS GENESIS to MCSC’s Referral and Authorization interface will not interfere or affect the operation and maintenance of the Legacy S y s t e m s interface for all MHS facilities utilizing Legacy Systems.

2.0 MHS GENESIS/MCSC Interface Requirements/Scope

This ICD is for the establishment and maintenance of a new MHS GENESIS to MCSC’s Referral and Authorization system interface to facilitate referral management activities for all applicable MHS GENESIS facilities. Because the MHS GENESIS product is a Commercial off the Shelf (COTS) product different from the Legacy Systems and provides new/different functionalities and capabilities, there may be data differentials, which will affect the MCSC’s Referral and Authorization system data intake, compliance, functionality, and through-put processing. In order to properly plan, develop, test, and field the interface, an output-based, phased approach is required.

2.1 Key Facts and Assumptions

2.1.1 The MCSC shall have the appropriate personnel to engage i n all aspects of the planning, development, testing, and fielding of any associated changes (including but not limited to infrastructure, platform, software, and cybersecurity) required to support the creation and sustainment of the MHS GENESIS interface with MCSC’s Referral and Authorization system.

HT9402-XX-C-000X Page 2 of 36

2.1.2 The MCSC shall support the MHS GENESIS interface to enable proper performance of all referral management activities conducted by the MCSC for MTFs without impacting the stabilization and sustainment of the MCSC’s Referral and Authorization system.

2.1.3 A standard 278 Electronic Referral Management Interface has been built to facilitate a connection to the MCSC’s Referral and Authorization system. The MCSC shall comply with the MHS GENESIS standard 278 electronic interface.

2.1.4 The MCSC shall perform all activities in accordance with the time sensitive overarching DHMSM PMO's MHS GENESIS schedule – To be published upon completion of revisions.

2.1.5 The Phases detailed in sections 2.2.1-2.2.3 will repeat throughout the lifecycle of

MHS GENESIS as interface upgrades and new capabilities are introduced.

2.2 Specific Tasks

A phased, output-based approach will be utilized for the development of MHS GENESIS to MCSC’s Referral and Authorization system bi-directional interface and the evolution of the interface to include the MCSC Right of First Refusal (ROFR).

The MCSC shall be required to support the MHS GENESIS Interface through multiple phases of activity throughout the life cycle of MHS GENESIS. The phases are listed in detail in sections 2.2.1-2.2.3

The MCSC may build multiple test environments for MHS GENESIS to support multiple testing and evaluation events or to support multiple MHS GENESIS activities. If the MCSC provides only one development and test environment, the MCSC must support movement of connections between their environment and MHS GENEISIS environments.

2.2.1 Phase I Analysis

2.2.1.1 Baseline Capability

MCSC shal l provide Subject Matter Experts (SMEs) to engage with the DHMSM PMO SMEs to determine the technical and programmatic details required to establish a successful interface between MHS GENESIS and MCSC’s Referral and Authorization system. These activities will include the planning and subsequent development, testing, and fielding activities for the exchange of referral information initiated by MHS GENESIS and the exchange of referral information initiated by the MCSC Referral and Authorization System. The initial sessions of the Analysis Phase will consist of a detailed mapping of the new interface to include, but not limited to, defining responsibilities, data elements, data ingest, infrastructure, platform and software changes, cybersecurity impacts, testing and sustainment processes.

HT9402-XX-C-000X Page 3 of 36

2.2.1.2 Technical- Determining the technical approach for the MCSC’s Referral and Authorization system interface with MHS GENESIS requires a clear understanding of how MHS GENESIS currently exchanges data. The following topics will be addressed, and appropriate SME(s) will be required to support this effort:

2.2.1.2.1 DHMSM PMO, the MHS GENESIS vendor and the MCSC

s h a l l e s t a b l i s h t he referral management data mapping requirements based on the native data in MHS GENESIS and data required to process and authorize a referral by the MCSC.

2.2.1.2.2 For rejected/returned referrals, MCSC shall provide responses and text explanations using the HIPAA compliant 278 transaction code set. The text explanations shall describe why the MCSC is returning or rejecting the referral. This shall include the name of the data element that needs to be corrected and what the MCSC wants the MTF to correct on the referral before resubmitting the referral for re-review. In cases where the Government cannot resolve issues associated with rejected/returned referrals via the interface with MHS GENESIS, referral-related information may be faxed for clarification (categories of patients that will require fax referrals will be identified by the Government).

2.2.1.2.3 HIPAA Compliant 278 Referral Processing for Level 2

Rejections Requiring Additional Information:

2.2.1.2.3.1 When processing level 2 rejections for additional information, the MCSC shall not cancel the 278 transaction. Instead, the MCSC shall append the referrals and send the submitting MTF a 278 response message with the reason for rejection.

2.2.1.2.3.2 The contractor shall allow a referral to be modified and resubmitted if cancelled when processing a 278 transaction Level 2 rejection

2.2.1.2.4 The MCSC’s Referral Management functional

requirements SME shall support determination of criticality of the data and the business impact corrupted data will have on the current capability provided by the MCSC to the DOD.

2.2.1.2.4.1 The MCSC’s Data Structure and Mapping SME

shall determine flexibility and accommodations needed to support native MHS GENESIS data elements correlating to MCSC’s Referral and Authorization system data elements.

HT9402-XX-C-000X Page 4 of 36

2.2.1.2.4.2 The MCSC’s testing support SME for planning, execution and testers for all testing events, shall validate the consumption and business capability for all agreed data elements mapped to functional requirements.

2.2.1.2.4.3 The MCSC’s Technical

infrastructure/communications SMEs for initiating and completing necessary B2B requirements and supporting all test phases, shall ensure the availability of t h e dot mil system required for interface and functionality testing.

2.2.1.2.4.4 The MCSC shall have an Interface SME with

expertise in file transmission and receipt for informational exchanges between MHS GENESIS and the MCSC’s Referral and Authorization systems.

2.2.1.2.4.5 The MCSC’s Information Assurance (IA) support

SME shall be responsible for Ports, Protocols and Services Management (PPSM), as wells as determining the NIST Certifications necessi t ies

2.2.1.3 System Upgrades - MCSC shall provide Subject Matter Experts (SMEs) to engage with the DHMSM PMO SMEs to determine the technical and programmatic details required to establish a successful interface between MHS GENESIS and MCSC’s Referral and Authorization system. The sessions of the Analysis Phase will consist of a detailed mapping of the new interface to include, but not limited to, defining responsibilities, data elements, data ingest, infrastructure, platform and software changes, cybersecurity impacts, testing and sustainment processes. Content will include but is not limited to:

2.2.1.3.1 The MCSC shall send Right of First Refusals (ROFRs) to an

MTF/eMSM via a HIPAA compliant 278, or other process as identified by the Government. The request shall contain the minimum data set and requirements that will be provided by the Government.

2.2.1.3.2 HIPAA ICD-10 Codes Standard Lis t Changes

(annual ly)

2.2.1.3.3 Future Versions of the MHS GENESIS interface control document (ICD) (as needed)

2.2.1.3.4 Perform issue analysis as requested

HT9402-XX-C-000X Page 5 of 36

2.2.1.3.5 The MCSC shall put in place a process to communicate major infrastructure upgrades to the DHMSM PMO to enable sufficient time to perform regression testing prior to test events.

2.2.2 Phase II Development/Configuration/Testing/Implementation

2.2.2.1 Development/Configuration:

2.2.2.2 The MCSC shall develop/configure the Referral and

Authorization system 278 interface based on the approved MHS GENESIS Interface Control Document (ICD) mapping specifications.

2.2.2.3 The MCSC shall meet all MHS GENESIS security requirements as outlined in the approved MHS GENESIS Interface Control Document (ICD) section 4.6 Security Requirements.

2.2.2.4 The MCSC shall configure the Referral and Authorization system to connect to MHS GENESIS using a B2B .mil connections. If MCSC’s system is a .com, a B2B .com to B2B .mil connection will be required for connections with MHS GENESIS .mil.

2.2.2.5 Testing Implementation - In addition to the technical details, the

DHMSM PMO's MHS GENESIS schedule shall be met to support MHS GENESIS at all existing sites and all future sites as identified in the PMO implementation wave schedule. To support MHS GENESIS at the existing sites and successive waves of MTFs in CONUS, the MCSC’s interface must be available to suppor t testing in the MHS GENESIS test environments for multiple phases of tests to include but not limited to:

2.2.2.5.1 Commercial upgrades (tentatively every 6 months)

2.2.2.5.2 Interface system upgrades

2.2.2.5.3 MHS GENESIS releases

2.2.2.5.4 Technical review of MCSC ICD

2.2.2.5.5 Environment Refresh (All DHMSM Pre-Prod

environments): Interface upgrade support in MHS GENESIS Test Environments or Production Environment as needed

2.2.2.5.6 Change Requests - Defects and Fixes; Testing support activities - supports testing and validation activities for defects, fixes, and changes

2.2.2.5.7 MCSC’s Integrator Test – All applicable TRICARE

Regions

HT9402-XX-C-000X Page 6 of 36

2.2.2.5.8 Provide production logs and or test logs for MCSC /MTF as requested by DHMSM PMO in support of MHS GENESIS test activities

2.2.2.5.9 Update interface configuration changes

2.2.2.5.10 Test support for issue analysis as requested

2.2.2.5.11 Data preparation/seeding for testing

2.2.2.5.12 Test Activities in Support of the following:

2.2.2.5.12.1 Connection Line of Sight (LOS) and Smoke Test

2.2.2.5.12.2 Engineering Test (ET) and Test & Evaluation (T&E)

2.2.2.5.12.3 Regression testing

2.2.2.5.12.4 DT&E testing

2.2.2.5.12.5 IV&V testing if required by the DHMSM PMO

2.2.2.5.12.6 Integration Validation (IV) testing as part of

Deployment Waves

2.2.2.5.12.7 Production Cutover Support for new MHS

GENESIS sites if required by the DHMSM PMO for Reconciliation reporting during first 90 days after each site “Go Live”

2.2.2.5.13 HIPAA ICD-10 Codes Standard Lis t Changes

(annual ly)

2.2.2.6 Dates established for testing in support of each individual MHS GENESIS implementation site will be communicated via e-mail from the DHMSM PMO PM and/or DHMSM PMO T&E team to MCSC’s Contract Management team and Testing SME(s).

2.2.2.7 The MCSC shall provide support for regression testing in the test environment due to any and all remediation of testing deficiencies which occur in testing or implementation of the sites. This testing is in addition to testing directly related to implementing MHS GENESIS at the scheduled implementation sites.

2.2.3 Phase III Sustainment

The MCSC shall maintain this interface throughout its performance period inclusive of all exercised option periods as required. Sustainment shall include but is not limited to the following tasks:

2.2.3.1 Final Operational Test & Evaluation (FOT&E) (30-60 days after wave 1 "Go-Live")

2.2.3.2 Update interface configuration changes

2.2.3.3 Commercial upgrades (tentatively every 6 months)

2.2.3.4 Interface system upgrades

2.2.3.5 MHS GENESIS releases

2.2.3.6 Technical review of MCSC ICD

2.2.3.7 Environment Refresh (All MHS GENESIS Pre-Prod and Production environments): Interface upgrade support in MHS GENESIS Test Environments or Production Environment as needed

2.2.3.8 Change Requests – Defects and Fixes; Testing support activities -supports testing and validation activities for defects, fixes, and changes

HT9402-XX-C-000X Page 7 of 36

2.2.3.9 MCSC’s Integrator Test – All applicable TRICARE regions

2.2.3.10 Provide productions logs and or test logs for MCSC/MTF as requested by DHMSM PMO in support of MHS GENESIS test activities

2.2.3.11 Test Support for issue analysis as requested

2.2.3.12 Data preparation/seeding for testing

2.2.3.13 Support other MHS GENESIS tasks as requested by the DHMSM

PMO

2.2.3.14 Test Activities in Support of:

2.2.3.14.1 Connection Line of Sight (LOS) and Smoke Test

2.2.3.14.2 Engineering Test (ET) and Test and Evaluation (T&E)

2.2.3.14.3 Regression testing

2.2.3.14.4 DT&E Testing

2.2.3.14.5 IV&V Testing if required by the DHMSM PMO

2.2.3.15 Reconciliation reporting during first 90 days after each site “Go Live”

2.2.3.16 Data preparation/seeding for testing

2.2.3.17 Support other MHS GENESIS tasks as requested by the

DHMSM PMO

2.2.3.18 MTF wave deployment testing as required

Discussion locations:

Tele-conference

Washington, D.C. Metro Area –TBD

MCSC– Facilities as needed – TBD

Primary POC for coordinating discussions:

Lt Col Christina L Sheets APM, Baseline DHMSM Program Management Office christina.l.sheets.mil@mail.mil

Alternate POC for coordinating discussions:

Jeffrey M Fox APM, Systems Engineering DHMSM Program Management Office jeffrey.fox@navy.mil

3.0 MHS GENESIS Decomposed Requirements List

HT9402-XX-C-000X Page 8 of 36

DNG

No

Stakeholder Requirement

Primary Text

DNG

No.

System Spec Requirement

Primary Text

Requirement

2 ID

Decomposed Requirement Primary Text

Referral Management Interface

The system shall establish a bidirectiona l interface with the Managed Care Support Contractor

(MCSC)

system.

The

DODEHR

shall have the capability to send an X12

278 EDI

formatted outbound request message wrapped in XML via a SOAP web service through HTTPS to

MCSC

The

DODEHR

shall have the capability to send an X12 278

EDI

formatted outbound request message wrapped in XML via a SOAP web service through HTTPS to

MCSC

200702 The DODEHR shall have the capability to send the 'CLINICAL SPECIALITY’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the 'CLINICAL SPECIALITY’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200704 The DODEHR shall have the capability to send the 'SIGNATURE LINE’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the 'SIGNATURE LINE’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200705 The DODEHR shall have the capability to populate the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200706 The DODEHR shall have the capability to send the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

HT9402-XX-C-000X Page 9 of 36

200707 The DODEHR shall have the capability to populate the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200708 The DODEHR shall have the capability to send the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200709 The DODEHR shall have the capability to populate the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

The DODEHR shall have the capability to populate the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

200710 The DODEHR shall have the capability to send the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

The DODEHR shall have the capability to send the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

200711 The DODEHR shall have the capability to populate the ‘SUBSCRIBER GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

The DODEHR shall have the capability to populate the ‘SUBSCRIBER GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

200712 The DODEHR shall have the capability to send the ‘SUBSCRIBER GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

The DODEHR shall have the capability to send the ‘SUBSCRIBER GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

HT9402-XX-C-000X Page 10 of 36

200713 The DODEHR shall have the capability to populate the ‘SUBSCRIBER ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

The DODEHR shall have the capability to populate the ‘SUBSCRIBER ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

200714 The DODEHR shall have the capability to send the ‘SUBSCRIBER ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

The DODEHR shall have the capability to send the ‘SUBSCRIBER ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the subscriber

200715 The DODEHR shall have the capability to populate the ‘DEPENDENT DBN’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to populate the ‘DEPENDENT DBN’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200716 The DODEHR shall have the capability to send the ‘DEPENDENT DBN’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to send the ‘DEPENDENT DBN’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200717 The DODEHR shall have the capability to populate the ‘DEPENDENT EDIPI’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to populate the ‘DEPENDENT EDIPI’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

HT9402-XX-C-000X Page 11 of 36

200718 The DODEHR shall have the capability to send the ‘DEPENDENT EDIPI’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to send the ‘DEPENDENT EDIPI’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200719 The DODEHR shall have the capability to populate the ‘DEPENDENT NAME’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to populate the ‘DEPENDENT NAME’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200720 The DODEHR shall have the capability to send the ‘DEPENDENT NAME’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to send the ‘DEPENDENT NAME’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200721 The DODEHR shall have the capability to populate the ‘DEPENDENT DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to populate the ‘DEPENDENT DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200722 The DODEHR shall have the capability to send the ‘DEPENDENT DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to send the ‘DEPENDENT DOB’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

HT9402-XX-C-000X Page 12 of 36

200723 The DODEHR shall have the capability to populate the ‘DEPENDENT GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to populate the ‘DEPENDENT GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200724 The DODEHR shall have the capability to send the ‘DEPENDENT GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to send the ‘DEPENDENT GENDER’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200725 The DODEHR shall have the capability to populate the ‘DEPENDENT ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to populate the ‘DEPENDENT ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200726 The DODEHR shall have the capability to send the ‘DEPENDENT ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

The DODEHR shall have the capability to send the ‘DEPENDENT ADDRESS’ as a conditional required data element in the X12 278 EDI formatted outbound request message to MCSC if the referral is for the dependent

200727 The DODEHR shall have the capability to populate the ‘REFERRAL ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘REFERRAL ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200728 The DODEHR shall have the capability to send the ‘REFERRAL ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘REFERRAL ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

HT9402-XX-C-000X Page 13 of 36

200729 The DODEHR shall have the capability to populate the DIAGNOSIS’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the DIAGNOSIS’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200730 The DODEHR shall have the capability to send the ‘DIAGNOSIS’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘DIAGNOSIS’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200731 The DODEHR shall have the capability to populate the ‘REFERRAL_DATE’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘REFERRAL_DATE’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200732 The DODEHR shall have the capability to send the ‘REFERRAL_DATE’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘REFERRAL_DATE’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200733 The DODEHR shall have the capability to populate the ‘PRIORITY’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘PRIORITY’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200734 The DODEHR shall have the capability to send the ‘PRIORITY’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘PRIORITY’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

HT9402-XX-C-000X Page 14 of 36

200735 The DODEHR shall have the capability to populate the

‘ORDERING_PHYSICIAN_NP

I’ as a required data element in the X12 278 EDI formatted outbound request message to

MCSC

The DODEHR shall have the capability to populate the ‘ORDERING_PHYSICIAN_NPI’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200736 The DODEHR shall have the capability to send the

‘ORDERING_PHYSICIAN_NP

I’ as a required data element in the X12 278 EDI formatted outbound request message to

MCSC

The DODEHR shall have the capability to send the ‘ORDERING_PHYSICIAN_NPI’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200737 The DODEHR shall have the capability to populate the ‘MTF_NAME’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘MTF_NAME’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200738 The DODEHR shall have the capability to send the ‘MTF_NAME’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘MTF_NAME’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200739 The DODEHR shall have the capability to populate the

‘MCP_REFERRAL_NUMBER’

as a required data element in the X12 278 EDI formatted outbound request message to

MCSC

The DODEHR shall have the capability to populate the ‘MCP_REFERRAL_NUMBER’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200740 The DODEHR shall have the capability to send the

‘MCP_REFERRAL_NUMBER’

as a required data element in the X12 278 EDI formatted outbound request message to

MCSC

The DODEHR shall have the capability to send the ‘MCP_REFERRAL_NUMBER’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

HT9402-XX-C-000X Page 15 of 36

ATTACH

MENT J-

DHMSM

Interface Control Document

(ICD) 15

May 2017 Table D-1:

Decompose d Requireme nts List

200913 The DODEHR shall have the capability to populate the

‘ORDERING_PHYSICIAN_NA

ME’ as a required data element in the X12 278 EDI formatted outbound request message to

MCSC

The DODEHR shall have the capability to populate the

‘ORDERING_PHYSICIAN_NAME’

as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200914 The DODEHR shall have the capability to send the

‘ORDERING_PHYSICIAN_NA

ME’ as a required data element in the X12 278 EDI formatted outbound request message to

MCSC

The DODEHR shall have the capability to send the

‘ORDERING_PHYSICIAN_NAME’

as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200933 The DODEHR shall have the capability to populate the ‘MTF_DMIS ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to populate the ‘MTF_DMIS ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200934 The DODEHR shall have the capability to send the ‘MTF_DMIS ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

The DODEHR shall have the capability to send the ‘MTF_DMIS ID’ as a required data element in the X12 278 EDI formatted outbound request message to MCSC

200782 The DODEHR shall have the capability to receive an X12 278 EDI formatted inbound response message wrapped in XML via a SOAP web service through HTTPS from MCSC

The DODEHR shall have the capability to receive an X12 278 EDI formatted inbound response message wrapped in XML via a SOAP web service through HTTPS from MCSC

HT9402-XX-C-000X Page 16 of 36

200783 The DODEHR shall have the capability to receive the

‘CERTIFICATION_NUMBER’

as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘CERTIFICATION_NUMBER’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from

MCSC

200784 The DODEHR shall have the capability to store the

‘CERTIFICATION_NUMBER’

as a required data element when coming from the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘CERTIFICATION_NUMBER’ as a required data element when coming from the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200785 The DODEHR shall have the capability to receive the

‘APPROVED_PROCEDURE’

as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘APPROVED_PROCEDURE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from

MCSC

200786 The DODEHR shall have the capability to store the

‘APPROVED_PROCEDURE’

as a required data element when coming from the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘APPROVED_PROCEDURE’ as a required data element when coming from the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200787 The DODEHR shall have the capability to receive the

‘CERTIFICATION_ISSUE_DA

TE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the

‘CERTIFICATION_ISSUE_DATE’

as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from

MCSC

200788 The DODEHR shall have the capability to store the

‘CERTIFICATION_ISSUE_DA

TE’ as a required data element when coming from the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the

‘CERTIFICATION_ISSUE_DATE’

as a required data element when coming from the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

HT9402-XX-C-000X Page 17 of 36

200789 The DODEHR shall have the capability to receive the

‘CERTIFICATION_EFFECTIV

E_DATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the

‘CERTIFICATION_EFFECTIVE_D

ATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200790 The DODEHR shall have the capability to store the

‘CERTIFICATION_EFFECTIV

E_DATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the

‘CERTIFICATION_EFFECTIVE_D

ATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200791 The DODEHR shall have the capability to receive the

‘CERTIFICATION_EXPIRATI

ON_DATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the

‘CERTIFICATION_EXPIRATION_

DATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200792 The DODEHR shall have the capability to store the

‘CERTIFICATION_EXPIRATI

ON_DATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the

‘CERTIFICATION_EXPIRATION_

DATE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200793 The DODEHR shall have the capability to receive the ‘ACTION_CODE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘ACTION_CODE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

200794 The DODEHR shall have the capability to store the ‘ACTION_CODE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘ACTION_CODE’ as a required data element in the ‘Approved’ X12 278 EDI formatted inbound response message from MCSC

HT9402-XX-C-000X Page 18 of 36

200795 The DODEHR shall have the capability to receive the

‘REJECTION_REASON_COD

E’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘REJECTION_REASON_CODE’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from

MCSC

200796 The DODEHR shall have the capability to store the

‘REJECTION_REASON_COD

E’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘REJECTION_REASON_CODE’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from

MCSC

200797 The DODEHR shall have the capability to receive the ‘REJECTION_REASON’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘REJECTION_REASON’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from

MCSC

200798 The DODEHR shall have the capability to store the ‘REJECTION_REASON’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘REJECTION_REASON’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from

MCSC

200799 The DODEHR shall have the capability to receive the

‘FOLLOWUP_ACTION_CODE

’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘FOLLOWUP_ACTION_CODE’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from

MCSC

200800 The DODEHR shall have the capability to store the

‘FOLLOWUP_ACTION_CODE

’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘FOLLOWUP_ACTION_CODE’ as a required data element in the ‘level 2 Rejection’ X12 278 EDI formatted inbound response message from

MCSC

HT9402-XX-C-000X Page 19 of 36

200801 The DODEHR shall have the capability to receive the ‘ACTION_CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘ACTION_CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200802 The DODEHR shall have the capability to store the ‘ACTION_CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from

MCSC

The DODEHR shall have the capability to store the ‘ACTION_CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200803 The DODEHR shall have the capability to receive the

‘DENIED INDUSTRY CODE’

as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘DENIED INDUSTRY CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200804 The DODEHR shall have the capability to store the ‘DENIED INDUSTRY CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘DENIED INDUSTRY CODE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200805 The DODEHR shall have the capability to receive the ‘DENIED REASON’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘DENIED REASON’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200806 The DODEHR shall have the capability to store the ‘DENIED REASON’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘DENIED REASON’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

HT9402-XX-C-000X Page 20 of 36

200807 The DODEHR shall have the capability to receive the ‘DENIED DATE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘DENIED DATE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200808 The DODEHR shall have the capability to store the ‘DENIED DATE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘DENIED DATE’ as a required data element in the ‘level 3 Denied’ X12 278 EDI formatted inbound response message from MCSC

200809 The DODEHR shall have the capability to receive the ‘ACTION_CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘ACTION_CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200810 The DODEHR shall have the capability to store the ‘ACTION_CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from

MCSC

The DODEHR shall have the capability to store the ‘ACTION_CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200811 The DODEHR shall have the capability to receive the

‘CANCEL INDUSTRY CODE’

as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘CANCEL INDUSTRY CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200812 The DODEHR shall have the capability to store the ‘CANCEL INDUSTRY CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘CANCEL INDUSTRY CODE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

HT9402-XX-C-000X Page 21 of 36

200813 The DODEHR shall have the capability to receive the ‘CANCEL REASON’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘CANCEL REASON’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200814 The DODEHR shall have the capability to store the ‘CANCEL REASON’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘CANCEL REASON’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200815 The DODEHR shall have the capability to receive the ‘CANCEL DATE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘CANCEL DATE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200816 The DODEHR shall have the capability to store the ‘CANCEL DATE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

The DODEHR shall have the capability to store the ‘CANCEL DATE’ as a required data element in the ‘level 3 Cancel’ X12 278 EDI formatted inbound response message from MCSC

200817 The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from MCSC

200818 The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Level 2 Rejection’

HT9402-XX-C-000X Page 22 of 36

200819 The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from

MCSC

200821 The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Level 3 Cancel’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER NAME’ as a required data element in the X12 278 EDI formatted ‘Level 3 Cancel’ inbound response message from

MCSC

200823 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from MCSC

200824 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from

MCSC

200825 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC

200827 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Level 3 Cancel’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DBN’ as a required data element in the X12 278 EDI formatted ‘Level 3 Cancel’ inbound

HT9402-XX-C-000X Page 23 of 36

200829 The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from

MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from MCSC

200830 The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from

MCSC

200831 The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC

200833 The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Level 3 Cancel’ inbound response message from MCSC

The DODEHR shall have the capability to receive the ‘SUBSCRIBER EDIPI’ as a required data element in the X12 278 EDI formatted ‘Level 3 Cancel’ inbound response message from MCSC

200835 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from MCSC if the referral is for the subscriber

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted ‘Approved’ inbound response message from MCSC if the referral is for the subscriber

200836 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from MCSC if the referral is for the subscriber

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted ‘Level 2 Rejection’ inbound response message from MCSC if the referral is for the

HT9402-XX-C-000X Page 24 of 36

200837 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC if the referral is for the subscriber

The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a conditional required data element in the X12 278 EDI formatted ‘Level 3 Denied’ inbound response message from MCSC if the referral is for the subscriber

200839 The DODEHR shall have the capability to receive the ‘SUBSCRIBER DOB’ as a…