PL 001 ELECTRONIC DATA INTERCHANGE (EDI).pdf

SCDHHS - Confidential Page 1 of 16

EA - TRA04.07 - Electronic Data Interchange (EDI) Document Purpose

Provides guidance on when the ASC X12N standards apply to transactions coming into and going out of the SCDHHS Medicaid systems Describes how SCDHHS processes ASC X12N-compliant transactions coming into and going out of the SCDHHS Medicaid Enterprise System

(MES)

Document Status

REVIEW

Version 0.07

Date last updated: 2019-3-27

Table of Contents

1. Introduction

2. EDI at SCDHHS

3. EDI Transaction Processing

3.1. Transactions Inbound

to the MES

3.2. Transactions Outbound

from the MES

3.3. Acknowledging the

Transaction Transmission

3.4. Common Processing

3.4.1. Security and

Privacy

3.4.2. Process Logging

3.4.3. Exception Handling

3.5. Operational

Considerations

3.5.1. High Availability

and Failover Mechanisms

3.5.2. Data Backup and

Recovery

3.5.3. Automation

3.5.4. File-Naming

Conventions

4. Use Cases

4.1. Batch 834 EDI

Transaction

4.2. Real-time 276/277

Transaction

5. Tools and Technologies Appendix A. Revision History Appendix B. Acronyms Appendix C. Referenced Documents

Table of Figures

Figure 1. EDI at SCDHHS Figure 2. Process for transactions inbound to the MES Figure 3. Process for transactions outbound from the MES Figure 4. BRIDGES use case diagram Figure 5. 276/277 real-time mode transaction use case diagram

Table of Tables

Table 1. Descriptions of the EDI transactions at SCDHHS Table 2. Events and metrics to record in EDI process logs

Table of Standards

TRA04.07-S1. SCDHHS uses 834 transactions to send member data to ASOs, the enrollment broker, and the TPL vendor.

TRA04.07-S2. The TPL vendor and state agencies use 834 transactions to send OHI data to MES.

TRA04.07-S3. The ASOs and the MCO enrollment broker use 834 transactions to report member enrollment to the MES.

TRA04.07-S4. SCDHHS supports use of the 834 transaction in batch mode.

TRA04.07-S5. The MES, ASOs, and TPs use 270/271 transactions to request/respond electronically to inquiries about member eligibility.

TRA04.07-S6. SCDHHS supports use of the 270/271 transaction in real-time or batch mode.

TRA04.07-S7. The MES, ASOs, and TPs send PAs electronically using 278 transactions.

TRA04.07-S8. SCDHHS supports the use of the 278 transaction in real-time mode.

TRA04.07-S9. Providers and CHs use 837 transactions when sending claims electronically to the appropriate ASO.

TRA04.07-S10. The DASO and MASO use 837 transactions to send claims awaiting payment and denied claims to SCDHHS.

TRA04.07-S11. Pharmacies and clearing houses use the NCPDP transaction when sending pharmacy and supplier claims electronically to the PASO.

TRA04.07-S12. The PASO uses NCPDP transactions to send claims awaiting payment and denied claims to SCDHHS.

TRA04.07-S13. SCDHHS supports the 837 and NCPDP transactions only in batch mode.

TRA04.07-S14. The MES, ASOs, and TPs use 276/277 transactions to request/respond electronically to inquiries for the status of claims.

TRA04.07-S15. SCDHHS supports use of the 276/277 transaction in real-time or batch mode.

TRA04.07-S16. The MES uses 835 transactions when sending remittance advice electronically to ASOs.

TRA04.07-S17. ASOs use 835 transactions to send remittance advice electronically to clearing houses and providers.

TRA04.07-S18. SCDHHS supports the use of the 835 transaction in batch mode only.

TRA04.07-S19. SCDHHS uses 820 transactions to send capitation remittance advice.

TRA04.07-S20. SCDHHS supports the use of the 820 transaction in batch mode only.

TRA04.07-S21. SCDHHS, ASOs, and TPs use the TA1/999 transaction to acknowledge the receipt of an EDI transaction, with or without errors in the transaction envelope.

TRA04.07-S22. The MES must retain the historical archives and records for EDi transactions according to data retention standards.

TRA04.07-S23. The MES must retain an online copy of each EDI file transmitted or received for a minimum of forty-five (45) days.

TRA04.07-S24. The MES must retain online or offline a copy of each EDI file

SCDHHS - Confidential Page 2 of 16 transmitted or received for a minimum of seven (7) years.

TRA04.07-S25. The Integration Hub must identify individual data elements received from the source system and ingest the elements using metadata.

TRA04.07-S26. EDI transactions must meet the security and privacy requirements for the MES.

TRA04.07-S27. The EDI transaction processing will log important events and metrics.

TRA04.07-S28. The EDI transaction processes will not write PHI, PII, or FTI in logs.

TRA04.07-S29. The EDI process will adhere to the MES log retention policy.

TRA04.07-S30. The EDI transaction process will adhere to the enterprise error-handling guidelines.

TRA04.07-S31. Only one server will access/process a particular file.

TRA04.07-S32. If a server fails, while processing a transaction access the applicable run book.

TRA04.07-S33. The EDI transaction process will ensure timely data delivery.

TRA04.07-S34. The EDI transaction process will support event-driven automation.

TRA04.07-S35. The MES will support scheduling EDI transaction processing.

TRA04.07- S36. Folders and files used in processing EDI transactions will follow naming conventions.

SCDHHS expressly restricts the distribution of this document to include only those SCDHHS staff, SCDHHS processing environment contractors, or any entity given explicit access to this document with SCDHHS executive or management approval.

Intended Audience

The SCDHHS TRA audience includes SCDHHS staff, trading partners, and third-party vendors who will be implementing, integrating, managing, or operating the SCDHHS MES. The SCDHHS TRA provides the reference model by which technologies and components of the SCDHHS MES will be measured for development and implementation.

1. Introduction

The Health Insurance Portability and Accountability Act (HIPAA) required Health and Human Services (HHS) to establish national standards for electronic transactions to improve the efficiency and effectiveness of the nation's health care[1] system. These standards apply to all HIPAA-covered entities, including the South Carolina Department of Health and Human Services (SCDHHS). The Centers for Medicare and Medicaid Services (CMS) provides an overview of the standards on their website stating the following regarding electronic health care transactions:[2]

Accredited Standards Committee (ASC) X12 Version 5010 is the adopted standard format for transactions,[3] [4] except those with retail pharmacies.

For retail pharmacy transactions, HHS adopted two standards from the National Council for Prescription Drug Programs (NCPDP ) :[5]

Pharmacy and supplier transactions – NCPDP Version D.0 Medicaid subrogation – NCPDP Version 3.0

This document:

Provides guidance on when the ASC X12N or NCPDP standards apply to transactions (hereafter called EDI transactions) coming into and going out of the SCDHHS Medicaid systems Describes how SCDHHS processes ASC X12N-compliant transactions coming into and going out of the SCDHHS Medicaid Enterprise System (MES)

Implementation guides clarify and specify the data content in the electronic exchanges. SCDHHS companion guides convey information within the framework of the implementation guides; e.g., limiting the repeat of segments. The SCDHHS companion guides also describe the process and requirements for setting up new EDI transactions as an SCDHHS trading partner (TP). See for links to the SCDHHS companion guides.Appendix C. Referenced Documents Obtain the ASC X12N implementation guides from the X12 authorized publisher at . Thehttp://www.wpc-edi.com/ SCDHHS companion guides include:

ANSI X12N 834 Benefit Enrollment and Maintenance SCDHHS/MES Companion Guide SCDHHS 820 Companion Guide SCDHHS 835 Companion Guide SCDHHS 837 Institutional Companion Guide Final SCDHHS 837 Professional Companion Guide Final SCDHHS 837 Dental Companion Guide

SCDHHS 276-277 Companion Guide SCDHHS NCPDP Post Adjudication Companion Guide http://cuihhsiutl12.clemson.edu#%5B2%5D http://cuihhsiutl12.clemson.edu#%5B3%5D http://cuihhsiutl12.clemson.edu#%5B4%5D http://cuihhsiutl12.clemson.edu#%5B5%5D http://www.wpc-edi.com/ https://cuihhsiutl12.clemson.edu:8443/download/attachments/57550785/SCDHHS%20834%20Companion%20Guide.docx?api=v2 https://www.scdhhs.gov/sites/default/files/20130101_820_0.pdf https://www.scdhhs.gov/sites/default/files/CompanionGuide_835_January%202014.pdf https://www.scdhhs.gov/sites/default/files/837%20Institutional%20Companion%20Guide_Final_2.pdf https://www.scdhhs.gov/sites/default/files/837%20Professional%20Companion%20Guide_Final_1.pdf https://www.scdhhs.gov/sites/default/files/20130101_837D_0.pdf https://www.scdhhs.gov/sites/default/files/20130101_276_277_0.pdf https://www.scdhhs.gov/sites/default/files/NCPDP%20Post%20Adjudication%20Companion%20Guide_Final.pdf

SCDHHS - Confidential Page 3 of 16

2. EDI at SCDHHS

Figure 1. EDI at SCDHHS depicts the use of EDI transactions at SCDHHS.

Figure 1. EDI at SCDHHS

Table 1. Descriptions of the EDI transactionsat SCDHHS provides descriptions of each of EDI transaction depicted in Fig .ure 1. EDI at SCDHHS

Table 1. Descriptions of the EDI transactions at SCDHHS

Transaction Sender Receiver Mode [6]

834 Member eligibility and enrollment update and managed care organization (MCO) assignments

MES Administrative services organizations (ASOs)

Initially batch;

however, could be real-time

MES MCO enrollment broker

MCO enrollment broker MCOs

MES Third-party liability (TPL)

834 Reporting member enrollment ASOs MES Initially batch;

however, could be real-timeMCO enrollment broker MES

834 Other health insurance (OHI) data for members TPL MES Initially batch;

however, could be real-timeAgencies (DEW, DHEC, DMV, DSS/IV-D, WCC)

MES

270 / 271 Eligibility verification request (270) / response (271)) Providers (270) / ASOs (271)

ASOs (270) / Providers (271)

Usually real-time; could be batch

ASOs (270) / MES (271)

MES (270) /

ASOs (271) http://cuihhsiutl12.clemson.edu#%5B6%5D

SCDHHS - Confidential Page 4 of 16

TPL Insurance carriers

278 Prior authorization (PA) Providers & clearing houses (CHs) (request) / ASOs (response)

ASOs (request) / Providers & CH (response)

Real-time

ASOs (request) / MES (response)

MES (request) / ASOs (response)

837P/837I/837D/NCPDP Professional health care claim (837P), institutional health care claim (837I), dental health care claim (837D), or pharmaceutical claim (NCPDP)

Providers / CHs ASOs Only batch

MES TPL

837P/837I/837D/NCPDP Claims awaiting payment and denied claims

ASOs MES Only batch

277CA Claim acknowledgement pre-adjudication ASOs Providers / CHs Only batch

276 / 277 Claim status request (276) / response (277) Providers (276) / ASOs (277)

ASOs (276) / Providers (277)

Usually real-time; could be batch

ASOs (277) / MES (276)

MES (276) /

ASOs (277)

820 Premium payment MES MCOs Only batch

835 Claim payment advice MES ASOs Only batch

ASOs Providers/CHs

TA1/999 Implementation acknowledgement [7] Varies depending on transaction sender

Varies depending on transaction sender

Not applicable.

TRA04.07-S1. SCDHHS uses 834 transactions to send member data to ASOs, the enrollment broker, and the TPL vendor.

The MES receives member enrollment/eligibility from the enrollment/eligibility subsystems. The MES sends the member information to ASOs and the enrollment broker in 834 format. The member eligibility and enrollment update transaction has segments for all member centric data elements, including benefits enrollment information, coordination of benefits, and MCO assignments.

The MES sends member enrollment/eligibility information to the TPL vendor for use in determining other health information (OHI).

TRA04.07-S2. The TPL vendor and state agencies use 834 transactions to send OHI data to MES.

The TPL vendor sends OHI information to the MES in 834 format. State agencies, such as DEW, DHEC, DMV, DSS/IV-D, and WCC send OHI in 834 format.

TRA04.07-S3. The ASOs and the MCO enrollment broker use 834 transactions to report member enrollment to the MES.

The ASOs and MCO enrollment broker report back to the MES to ensure that they enrolled members properly. The ASOs and MCO enrollment broker send the MES data about member enrollment using an 834 transaction.

TRA04.07-S4. SCDHHS supports use of the 834 transaction in batch mode.

SCDHHS supports the use of the 834 transaction in batch mode.

TRA04.07-S5. The MES, ASOs, and TPs use 270/271 transactions to request/respond electronically to inquiries about member eligibility.

The MES supports 270/271 transactions from the ASOs. SCDHHS intends that ASOs support 270/271 transactions from

SCDHHS - Confidential Page 5 of 16

TPs (e.g., providers).

TRA04.07-S6. SCDHHS supports use of the 270/271 transaction in real-time or batch mode.

SCDHHS supports the use of the 270/271 transaction in real-time mode, either through a portal or web service. SCDHHS allows the use of the 270/271 in batch mode; i.e., the requester could create a large file of requests to process, and the MES could create a file containing the responses to the requests.

TRA04.07-S7. The MES, ASOs, and TPs send PAs electronically using 278 transactions.

SCDHHS intends that the provider or CH TP send the 278 to the MASO, DASO, or PASO, which sends the request to the core PA processing system. After approving/denying the PA, the ASO sends the response.

For evaluation during MASO adjudication, MASO needs the pharmacy prior authorizations of physician administered drugs and dental authorizations for surgical procedures of the mouth.

TRA04.07-S8. SCDHHS supports the use of the 278 transaction in real-time mode.

SCDHHS supports the use of the 278 transaction in real-time mode, either through a portal or web service. SCDHHS allows the use of the 278 in batch mode; i.e., the requester could create a large file of requests to process, and the MES could create a file containing the responses to the requests.

TRA04.07-S9. Providers and CHs use 837 transactions when sending claims electronically to the appropriate ASO.

Providers and CHs (including professional groups and institutions, such as hospitals) that submit electronic claims for adjudication to their ASO, must submit the electronic claims in 837 format.

Trading partners that are Send

Medical professionals and clearing houses for medical professionals 837P transactions

Medical institutions (e.g., hospitals) 837I transactions

Dental groups and clearing houses 837D transactions

TRA04.07-S10. The DASO and MASO use 837 transactions to send claims awaiting payment and denied claims to SCDHHS.

Post adjudication, the dental ASO (DASO) and MASO send the adjudicated claims awaiting payment and denied claims to the MES electronically in 837 format.

Trading partners that are Send

MASO 837P and 837I transactions

DASO 837D transactions

TRA04.07-S11. Pharmacies and clearing houses use the NCPDP transaction when sending pharmacy and supplier claims electronically to the PASO.

When sending pharmacy and supplier claims electronically to the pharmaceutical ASO (PASO), the pharmacies and pharmaceutical clearing houses use NCPDP transactions.

TRA04.07-S12. The PASO uses NCPDP transactions to send claims awaiting payment and denied claims to SCDHHS.

Post adjudication, the PASO sends the adjudicated claims awaiting payment and denied claims to the MES electronically

SCDHHS - Confidential Page 6 of 16 in NCPDP format.

TRA04.07-S13. SCDHHS supports the 837 and NCPDP transactions only in batch mode.

SCDHHS supports the use of the 837 and NCPDP transactions in batch mode. SCDHHS does not support the use of the 837 and NCPDP transactions in real-time mode.

TRA04.07-S14. The MES, ASOs, and TPs use 276/277 transactions to request/respond electronically to inquiries for the status of claims.

The MES supports 276/277 transactions from the ASOs. SCDHHS intends that ASOs support 276/277 transactions from TPs (e.g., providers).

TRA04.07-S15. SCDHHS supports use of the 276/277 transaction in real-time or batch mode.

SCDHHS supports the use of the 276/277 transaction in real-time mode, either through a portal or web service. SCDHHS allows the use of the 276/277 in batch mode; i.e., the requester could create a large file of requests to process, and the MES could create a file containing the responses to the requests.

TRA04.07-S16. The MES uses 835 transactions when sending remittance advice electronically to

ASOs.

The SCDHHS financial system sends payment update files to the MES. The MES sends that payment information to each ASO in 835 format.

TRA04.07-S17. ASOs use 835 transactions to send remittance advice electronically to clearing houses and providers.

The MES sends payment update files to each ASO. When providing the remittance advice electronically to clearing houses and providers, the ASO sends the remittance advice in 835 format.

TRA04.07-S18. SCDHHS supports the use of the 835 transaction in batch mode only.

SCDHHS supports the use of the 835 transactions in batch mode. SCDHHS does not support the use of the 835 transactions in real-time mode.

TRA04.07-S19. SCDHHS uses 820 transactions to send capitation remittance advice.

The MES receives a payment update file from SCEIS. The MES creates and sends the capitation remittance advice to the MCOs in 820 format.

TRA04.07-S20. SCDHHS supports the use of the 820 transaction in batch mode only.

SCDHHS supports the use of the 820 transactions in batch mode. SCDHHS does not support the use of the 820 transactions in real-time mode.

TRA04.07-S21. SCDHHS, ASOs, and TPs use the TA1/999 transaction to acknowledge the receipt of an EDI transaction, with or without errors in the transaction envelope.

After receiving an EDI transaction file, the recipient acknowledges the transaction with a TA1/999 transaction.

Standards addressing retention of the EDI transaction files transmitted and received include the following.

TRA04.07-S22. The MES must retain the historical archives and records for EDi transactions according to data retention standards.

SCDHHS - Confidential Page 7 of 16

1.

2.

3.

4.

TRA04.07-S23. The MES must retain an online copy of each EDI file transmitted or received for a minimum of forty-five (45) days.

TRA04.07-S24. The MES must retain online or offline a copy of each EDI file transmitted or received for a minimum of seven (7) years.

3. EDI Transaction Processing

This document groups the information about EDI transaction processing into the following:

Processing of transactions inbound to the MES ( )Section 3.1. Transactions Inbound to the MES Processing of transactions outbound from the MES ( )Section 3.2. Transactions Outbound from the MES Responses to the transaction ( )Section 3.3. Acknowledging the Transaction Transmission Common transaction processing ( )Section 3.4. Common Processing Operational considerations for transaction processing ( )Section 3.5. Operational Considerations

3.1. Transactions Inbound to the

MES

Figure 2. Process for transactions inbound to the MES de picts the inbound transaction process described in this section.

The inbound EDI transactions flow through the following sequence of steps:

[Trading partner] Encode EDI file—Inbound transactions start with the TP creating the ASC X12N file in accordance with the TP agreement.

[Trading partner] Put file on SFTP server or invoke web service—For batch mode transactions, the TP places the file on the agreed-upon Secure File Transfer Protocol (SFTP) server. Typically, the SFTP server belongs to SCDHHS and the TP has permission to access its file the server belongs to the TPor and SCDHHS has permission to access the transaction files. For real-time transactions the TP invokes the web service (via portal or direct call to web service) per the TP agreement.

[SCDHHS] Process payload & send acknowledgement—For batch mode the MES Managed File Transfer (MFT) listens to the SFTP folder and at the presence of an EDI file, MFT securely transfers the file to the Oracle Service-Oriented Architecture/Oracle Service Bus (SOA/OSB) and places a copy on the archives file shared mount location. For real-time transactions, the OSB transfers the payload to the SOA/OSB and places a copy on the archives shared mount location. The MES validates the inbound file header, and sends an acknowledgement (back to the SFTP server or invoking service) to reject files with bad headers or accept files with correct headers. The MES continues processing the file and sends an acknowledgement (to the SFTP server or invoking service) with the results of processing the records per the specific TP agreement for the file. Processing includes translating the EDI format to JavaScipt Object Notation (JSON) format.

[SCDHHS] Insert record to RDL—The MES data service inserts the record as is into the raw data

Figure 2. Process for transactions inbound to the MES

SCDHHS - Confidential Page 8 of 16

4.

5.

6.

1.

2.

3.

4.

lake (RDL), appending the headers, tuples, and metadata.

[SCDHHS] Harmonize record and insert into ODS —The MES data service transforms the data into the appropriate data structure, maps the RDL data structure to the operational data store (ODS) structure, adds the sources field to the ODS document headers, and inserts the record into the

ODS.

[SCDHHS] Master the records in the ODS—The MES data service matches and merges records in the ODS.

See the data management supplements for rules on data quality, matching, mastering, retention, etc.

Standards that apply to inbound transactions include:

TRA04.07-S25. The Integration Hub must identify individual data elements received from the source system and ingest the elements using metadata.

3.2. Transactions Outbound from

the MES

Figure 3. Process for transactions outbound from the MES depicts the outbound transaction process described in this section.

The outbound transaction flows through the following steps:

[SCDHHS] Extract data from ODS and send to the translator—The MES data service extracts the data from the ODS (according to the selection criteria and rules documented in the TP agreement) and sends the data to the translator.

[SCDHHS] Encode the transaction—The Integration Hub service encodes the file as defined in the TP agreement.

[SCDHHS] Put payload on SFTP server or invoke web services—For batch mode transactions, the Integration Hub transfers the file to the SFTP server as defined in the TP agreement. For real-time mode transactions, the Integration Hub transfers the response payload to the requester (via a web service, and if applicable, the portal).

[Trading partner] Process EDI transaction & send acknowledgement—The TP processes the transaction and sends an acknowledgment to

SCDHHS.

Figure 3. Process for transactions outbound from the MES

3.3. Acknowledging the Transaction Transmission

This section provides additional details about the acknowledgments described in:

Section 3.1. Transactions Inbound to the MES step 3 [SCDHHS] Process payload and send acknowledgement Section 3.2. Transactions Outbound from the MES step 4 [Trading partner] Process EDI transaction & send acknowledgement

The recipient of the EDI transaction acknowledges receipt of a file and identifying the acceptance or rejection of the functional group, transaction sets, or segments, and identifying the data elements in error. The TA1 segment allows the transaction receiver to indicate receipt of a valid envelope or of problems encountered with the transaction control

SCDHHS - Confidential Page 9 of 16 structure. The TA1 verifies the envelopes only. The 999 response transaction set reports syntactical errors against a functional group based on an implementation guideline, or reports receipt of a functional group that fully complies with an implementation guideline. The 999 is a transaction set and thus is encapsulated within the interchange control structure (envelopes) for transmission.

3.4. Common Processing

In addition to the EDI transaction steps discussed previously, a common infrastructure spans the EDI process end-to-end. These common infrastructure requirements define how process logging, scheduling, monitoring, and exception handling happen on each EDI transaction.

3.4.1. Security and Privacy

A major goal of the EDI transaction process is to ensure that the sensitive and proprietary data moves safely without interception or alteration.

TRA04.07-S26. EDI transactions must meet the security and privacy requirements for the MES.

3.4.2. Process Logging

Process logging provide process execution information to enterprise operations and maintenance team members, such as IT helpdesk, system administrators, and developers. The systems administrators decide and configure the tools involved in the EDI transactions to an optimum logging level, considering technical and compliance requirements.

Detailed logs assist investigations; however, creating and maintaining detailed logs is expensive in terms of processing power and memory. See also the audit logging requirements associated with security and privacy.

TRA04.07-S27. The EDI transaction processing will log important events and metrics.

The EDI process shall have a mechanism to log important events and metrics before, during, and after the execution of the process. HIPAA requires reporting of disclosures of protected health information (PHI) if requested by the individual whose information was disclosed.

TRA04.07-S28. The EDI transaction processes will not write PHI, PII, or FTI in logs.

No PHI, personally identifying information (PII), or federal tax information (FTI) should be written to log files. However, a unique key to the personal data must be included in the log for troubleshooting by authorized personnel.

TRA04.07-S29. The EDI process will adhere to the MES log retention policy.

MES shall have a policy to determine the retention time of the logs. A shorter log retention period ensures that the process logs do not quickly fill up with the logs being generated daily, while a longer log retention period helps analyze EDI loads and may fulfill the regulatory requirements, such as HIPAA rules for reporting of disclosures of PHI.

Systems operations and maintenance staff can use process logs to perform an initial analysis of process execution. To ensure that appropriate, and consistent, data is available for analysis, the following events will be captured consistently across all EDI processes.

Table 2. Events and metrics to record in EDI process logs

Event/Metric Description

Process name

The process name, according to the configuration management database.

Start and stop events

The beginning and ending time stamp for the EDI process as a whole, as well as the individual steps, should be stored.

SCDHHS - Confidential Page 10 of 16

Status Process steps can succeed or fail individually, and as such, their status (not started, running, succeeded, or failed) should be logged individually.

Errors and other exceptions

While logging failures and anomalies often consumes the most time when building a logging infrastructure, these logs also yield the most value during testing and troubleshooting. See Section

3.4.3 Exception Handling for failure response scenarios, logging requirements, and information logged for errors and exceptions.

Testing and debugging information

This is particularly useful during the development and testing phase, most notably for processes that are heavy on the transformation part of EDI.

Audit information

See the security and privacy standards.

Security events

Security events, such as user login, login time, etc.

3.4.3. Exception Handling

In anticipation of an unexpected event in the EDI transaction, the EDI process should be designed to handle errors gracefully. The process should either quit or execute an alternate routine based on the design and should provide the system administrators enough information regarding the occurrence to perform fault-analysis.

TRA04.07-S30. The EDI transaction process will adhere to the enterprise error-handling guidelines.

The MES provides a uniform enterprise-wide exception-handling mechanism with a repository of error codes and descriptions. In the event of any failure in the file transfer process, the EDI transaction process handles the exception according to the enterprise error-handling guidelines.

The goal of the error-handling procedure in the EDI transaction process is to send notification(s) the appropriate individuals with the information such as:

File name File size File format File encoding Target location Reason for failure

Error code Error description

3.5. Operational Considerations

The following operational considerations ensure successful and consistent EDI transaction processing.

3.5.1. High Availability and Failover Mechanisms

The EDI transaction processing is implemented in clusters to support high availability (HA) and to ensure the SCDHHS meets service-level agreements (SLA) with TPs. If one server fails, other servers continue to support the transaction processing.

TRA04.07-S31. Only one server will access/process a particular file.

The HA configuration ensures that at any point, only one server is accessing and processing a particular file.

TRA04.07-S32. If a server fails, while processing a transaction access the applicable run book.

Run books for MES cluster/servers and applications (e.g., MFT Runbook and OSB Runbook) document failure procedures. Access the appropriate runbook and the TP agreement.

SCDHHS - Confidential Page 11 of 16 a.

TRA04.07-S33. The EDI transaction process will ensure timely data delivery.

EDI transactions must deliver data on time and within the SLAs established with the TPs.

3.5.2. Data Backup and Recovery

The MES backup and recovery plan describes all aspects of copying/recovering data to/from an appropriately secure and reliable repository. Considerations (pertaining to EDI transactions) to support the backup and recovery of this system include:

Run books for MES cluster/servers and applications (e.g., MFT Runbook and OSB Runbook) document recovery procedures. Access the appropriate runbook and the TP agreement.

3.5.3. Automation

The EDI transaction process is highly integrated with the MES Integration Hub and has the ability to invoke Integration Hub and EDS processes, which helps automate the execution of batch processing based on file transmission. See the T

, , and suppleRA04 - Integration Hub TRA04.01 - Enterprise Service Bus (ESB) TRA04.06 - Managed File Transfer (MFT) ments for more information about the integration of the EDI transaction processing and the integration hub.

TRA04.07-S34. The EDI transaction process will support event-driven automation.

The EDI transaction process initiates action at the occurrence of a particular system event; e.g., the arrival of a file in a specific folder triggers the inbound transaction processing.

TRA04.07-S35. The MES will support scheduling EDI transaction processing.

The MES will be able to process EDI transactions at a pre-defined interval; e.g., monthly audits of 834 transactions.

3.5.4. File-Naming Conventions

The MES defines file-naming conventions for all files passing through the enterprise. File-naming conventions not only help identify the contextual details of the file, but also help automate processing EDI transactions.

TRA04.07- S36. Folders and files used in processing EDI transactions will follow naming conventions.

Naming conventions for the file server folders, or directories indicate where the file is sent and who has access to it. Secti in the supplement defines the directory andon 4.7.3. File-Naming Conventions TRA04.06 - Managed File Transfer (MFT)

EDI file name conventions.

4. Use Cases

This section provides use cases to show how the standards described in this document apply to example EDI transactions.

4.1. Batch 834 EDI Transaction

This section describes the 834 EDI transaction between MES and the BabyNet Reporting & Intervention Data Gathering Electronic System (BRIDGES) TP. The steps illustrated in includFigure 4. BRIDGES use case diagram e:

Daily, Apache NiFi Invokes a data hub flow to extract BabyNet member updates and additions https://cuihhsiutl12.clemson.edu:8443/display/EAST/EA+-+TRA04+-+Integration+Hub https://cuihhsiutl12.clemson.edu:8443/display/EAST/EA+-+TRA04+-+Integration+Hub https://cuihhsiutl12.clemson.edu:8443/pages/viewpage.action?pageId=35527644 https://cuihhsiutl12.clemson.edu:8443/pages/viewpage.action?pageId=35527670 https://cuihhsiutl12.clemson.edu:8443/pages/viewpage.action?pageId=35527670

SCDHHS - Confidential Page 12 of 16 a.

b.

c.

2.

3.

a.

b.

c.

d.

e.

4.

a.

b.

c.

5.

a.

b.

c.

1.

2.

a.

b.

c.

d.

to a JSON file.

Sends an email notification (success or failure to appropriate email group).

Emits an event to the process or log REST endpoint and sends JSON with details of the event to the end-points, which triggers a call to push the message to the enterprise queue and to insert the message to the logs database.

Oracle MFT securely transfers the JSON file from the NiFi server to the Oracle JSON file folder.

Oracle SOA:

Emits an event to the process log for each record, which documents the auditable step in the Logs database.

Maps the file (ODS eXtensible Markup Language (XML)) to 834 format, documenting any errors in the error log database and in the MarkLogic Audit Collection.

Transforms the file from XML to EDI, and validates the format, emitting error events to the EDI error handling service, which are logged to the Log database.

Persists the TA1 status to the raw data lake (RDL) using Representation al State Transfer (REST) Uniform Resource Locator

.(URL

Sends an email notification (success or failure to appropriate email group).

Oracle MFT:

Transfers the BRIDGES 834 file to the SCDHHS SFTP server.

Puts a copy on the archive shared mount location.

Sends an email notification (success or failure to appropriate email group).

The TP:

Pulls the file from the SFTP server.

Processes the file.

Creates and sends an acknowledgement.

Figure 4. BRIDGES use case diagram

4.2. Real-time 276/277 Transaction

This section describes a real-time mode transaction between MES and an ASO. The steps illustrated in Figure i5. 276/277 real-time mode transaction use case diagram nclude:

ASO submitting a 276 inquiry via a portal’s call or direct call to the published web service to the MES per the TP agreement.

Oracle SOA:

Emits an event to the process log for the record, which documents the auditable step in the Logs database.

Maps the payload to EDI 276 format, documenting any errors in the error log database and in the MarkLogic Audit Collection.

Transforms the payload from EDI to JSON, and validates the format, emitting error events to the EDI error handling service, which logs the errors in the Log database.

Sends an email notification (success or

Figure 5. 276/277 real-time mode transaction use case diagram

SCDHHS - Confidential Page 13 of 16

2.

d.

e.

f.

g.

h.

i.

j.

k.

l.

m.

3.

a.

b.

failure to appropriate email group).

Sends the TA1 acknowledgment to the

ASO.

Extracts the response from the ODS to a JSON file.

Sends an email notification (success or failure to appropriate email group).

Emits an event to the process log for the record, which documents the auditable step in the Logs database.

Maps the payload to EDI 277 format, documenting any errors in the error log database and in the MarkLogic Audit Collection.

Transforms the payload from JSON to EDI and validates the format, emitting error events to the EDI error handling service, which are logged to the Log database.

Persists the TA1 status to the RDL using

REST URL.

Sends an email notification (success or failure to appropriate email group).

Invokes the service to send the payload to the ASO.

The ASO:

Processes the payload.

Creates and sends an acknowledgement.

5. Tools and Technologies

Lists specific tools/technologies providing functionality described in process section

Function Tool/technology

Manage ESB events/services, encode/decode, encrypt/decrypt, and compress/decompress payload, extract data from the ODS.

Oracle SOA

Authenticate users/service accounts

Authorize access

Log processes

Handle exceptions

Appendix A. Revision History

Version Number

Date Author(s) Description of Change

0.01 12/2 N Hobbs Initial draft

0.02 12/17 B O’Leary, D Keels, J Wingard

Comments on initial draft

0.03 12/18 N Hobbs Incorporation of comments and inclusion of BRIDGES use case.

0.04 01/19 Gerhard Ungerer Review comments

0.05 01/26 N Hobbs Respond to review comments, add real-time transactions and comments from B O’Leary.

0.06 1/31 N Hobbs Respond to Venkat’s review comments. Prepare and send document to final review.

SCDHHS - Confidential Page 14 of 16

0.07 3/27 N Hobbs Respond to Gerhard's review comments.

0.08 4/18 N Hobbs Add transactions per approved TPL solution plan.

Appendix B. Acronyms

Acronym Meaning

ASC Accredited Standards Committee

ASO Administrative services organization

BRIDGES BabyNet Reporting & Intervention Data Gathering Electronic System

CH Clearing house

CMS Centers for Medicare and Medicaid Services

DASO Dental administrative service organization

EDI Electronic Data Interchange

FTI Federal tax information

HA High availability

HHS Health and Human Services

HIPAA Health Insurance Portability and Accountability Act

JSON JavaScript Object Notation

MCO Managed care organization

MES Medicaid Enterprise System

MFT Managed file transfer

NCPDP National Council for Prescription Drug Programs

ODS Operational data store

OHI Other health insurance

OSB Oracle Service Bus

PASO Pharmaceutical administrative service organization

PHI Protected health information

PII Personally identifying information

RDO Raw data lake

REST Representational State Transfer

SCDHHS South Carolina Department of Health and Human Services

SFTP Secure File Transfer Protocol

SLA Service level agreement

SOA Service-oriented architecture

TP Trading partner

TPL Third-party liability

SCDHHS - Confidential Page 15 of 16

URL Uniform Resource Locator

XML eXtensible Markup Language

Appendix C. Referenced Documents

Referenced Document Title

Location or URL

SCDHHS 820

Companion Guide https://www.scdhhs.gov/sites/default/files/20130101_820_0.pdf

ANSI X12N

834 Benefit Enrollment and Maintenance

SCDHHS/MES

Companion Guide https://cuihhsiutl12.clemson.edu:8443/download/attachments/57550785/SCDHHS%20834%20Companion%20Guide.docx?api=v2

SCDHHS 835

Companion Guide https://www.scdhhs.gov/sites/default/files/CompanionGuide_835_January%202014.pdf

837 Dental Companion Guide https://www.scdhhs.gov/sites/default/files/20130101_837D_0.pdf

SCDHHS 837

Institutional Companion Guide Final https://www.scdhhs.gov/sites/default/files/837%20Institutional%20Companion%20Guide_Final_2.pdf

SCDHHS 837

Professional Companion Guide Final https://www.scdhhs.gov/sites/default/files/837%20Professional%20Companion%20Guide_Final_1.pdf

SCDHHS

276-277 Companion Guide https://www.scdhhs.gov/sites/default/files/20130101_276_277_0.pdf

SCDHHS

NCPDP Post Adjudication Companion Guide https://www.scdhhs.gov/sites/default/files/NCPDP%20Post%20Adjudication%20Companion%20Guide_Final.pdf

SCDHHS

Policy for Information Technology Use and Security July https://team.scdhhs.gov/OPS/ADMIN/PS/HR/Shared%20Documents/IT%20Use%20and%20Security%20Policy.pdf

"FIPS PUB

140-2: Security Requirements for Cryptographic Modules". NIST https://web.archive.org/web/20070825103724/http://csrc.nist.gov/cryptval/140-2.htm https://www.scdhhs.gov/sites/default/files/20130101_820_0.pdf https://cuihhsiutl12.clemson.edu:8443/download/attachments/57550785/SCDHHS%20834%20Companion%20Guide.docx?api=v2 https://www.scdhhs.gov/sites/default/files/CompanionGuide_835_January%202014.pdf https://www.scdhhs.gov/sites/default/files/20130101_837D_0.pdf https://www.scdhhs.gov/sites/default/files/837%20Institutional%20Companion%20Guide_Final_2.pdf https://www.scdhhs.gov/sites/default/files/837%20Professional%20Companion%20Guide_Final_1.pdf https://www.scdhhs.gov/sites/default/files/20130101_276_277_0.pdf https://www.scdhhs.gov/sites/default/files/NCPDP%20Post%20Adjudication%20Companion%20Guide_Final.pdf https://team.scdhhs.gov/OPS/ADMIN/PS/HR/Shared%20Documents/IT%20Use%20and%20Security%20Policy.pdf https://web.archive.org/web/20070825103724/http://csrc.nist.gov/cryptval/140-2.htm

SCDHHS - Confidential Page 16 of 16

TRA04.06

Managed File Transfer (MFT) https://schhs.sharepoint.com/:w:/r/teams/INTHub/ES/Standards/TRA04.06%20-%20Managed%20File%20Transfer%20(MFT).docx?d=w4a1a0a75334540d2af0fc005c7859841&csf=1&e=dN8vVv

“A transaction is an electronic exchange of information between two parties to carry out financial or administrative activities related to health care.” Per https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Trans actions/TransactionsOverview.html https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/AdoptedStandardsandOperat ingRules.html

The Accredited Standards Committee (ASC) X12 is a standards organization chartered by the American National Standards Institute to develop and maintain the X12 electronic data interchange.

https://www.gpo.gov/fdsys/pkg/FR-2009-01-16/pdf/E9-740.pdf https://www.ncpdp.org/

Batch—In a batch mode the sender does not remain connected while the receiver processes the transactions.

Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery. The sender of the original transmission reconnects at a later time and picks up the response transaction.

This implementation guide does not set specific response time parameters for these activities.

—In real-time mode the sender remains connected while the receiver processes the transactions and returnsReal-Time a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

Not shown in Figure 1. EDI in SCDHHS Medicaid systems https://schhs.sharepoint.com/:w:/r/teams/INTHub/ES/Standards/TRA04.06%20-%20Managed%20File%20Transfer%20(MFT).docx?d=w4a1a0a75334540d2af0fc005c7859841&csf=1&e=dN8vVv https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Transactions/TransactionsOverview.html https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Transactions/TransactionsOverview.html https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/AdoptedStandardsandOperatingRules.html https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/AdoptedStandardsandOperatingRules.html https://www.gpo.gov/fdsys/pkg/FR-2009-01-16/pdf/E9-740.pdf https://www.ncpdp.org/

EA - TRA04.07 - Electronic Data Interchange (EDI)