EDI Solutions Details

Standard Companion Guide Trading Partner Information

Instructions Related to the X12 275 Claims Attachment Version 6020 and HL7 Consolidated Clinical Document Architecture R2.1

Companion Guide Version Number: 7.0 Revised: February 2024

Preface

Companion Guides (CG) may contain two types of data, instructions for electronic communications with the publishing entity (Trading Partner Information) and supplemental information for creating transactions for the publishing entity while ensuring compliance with the associated ASC X12 Implementation Guide (IG) (Transaction Instructions). Either the Trading Partner Information component or the Transaction Instruction component must be included in every CG. The components may be published as separate documents or as a single document.

The Trading Partner Information component is included in the CG when the publishing entity wants to convey the information needed to commence and maintain communication exchange.

The Transaction Instruction component is included in the CG when the publishing entity wants to clarify the IG instructions for submission of specific electronic transactions.

The Transaction Instruction component content is limited by the ASC X12 copyrights and Fair Use statement.

Table of Contents

I. Trading Partner Information Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
1.4 References

II. Getting Started
2.1 Working Together
2.2 Trading Partner Registration
2.3 Trading Partner Testing Process

III. Connectivity/Communications
3.1 Process Flows for Batch Submissions
3.2 Transmission Administrative Procedures
3.3 Re-transmission Procedures
3.4 Communication Protocols
3.5 Security Protocols

IV. Contact information
4.1 EDI Customer Service and Technical Assistance
4.2 Provider Services
4.3 Applicable Websites/Email

V. Control Segments/Envelopes
5.1 ISA-IEA
5.2 GS-GE
5.3 Transaction Details
5.4 HL7 C-CDA R2.1 Details

VI. Specific Business Rules
6.1 General Notes
6.2 Unsolicited Attachments
6.3 Solicited Attachments
6.4 Request for Appeal
6.5 LX Loop

VII. Acknowledgements and Reports
7.1 Report Inventory

VIII. Additional Trading Partner Information
8.1 Implementation Checklist
8.2 Trading Partner Agreement

XI. Trading Partner Information Change Summary

[Return to Top]

I. Trading Partner Information Introduction

1.1 Purpose

National Government Services is publishing this document which is intended to provide information to trading partners for implementation of the transactions and documents necessary to exchange Claims Attachment data electronically with NGS.

This CG clarifies, supplements and further defines specific data content requirements to be used in conjunction with, and not in place of, the ASCX12N TR3s for the X12 275 Claims Attachment v6020 Transaction and the HL7 C-CDA Implementation Guides.

The CG provides communication, connectivity and transaction specific information to NGS trading partners and serves as the authoritative source for NGS-specific EDI protocols.

Operational information regarding registration, testing, support and specific information about control record setup is also documented.

1.2 Scope

With this document NGS EDI addresses how providers/suppliers, or their business associates exchange the 275 v6020 and C-CDA R2.1 to support the electronic submission of medical record data in follow-up to Medicare claims submitted to NGS.

Included are responses to solicited requests received for the 277 Health Care Claim Request for Additional Information or hard copy letter; and submission of ‘unsolicited’ documentation.

The provider can also use the 275 transaction to request a first level appeal which may include additional documentation to support a redetermination.

See Section 5 and 6 for the specific details.

1.3 Overview

This CG includes information needed to commence and maintain communication exchange with NGS for the purpose of submitting Claims Attachment data and Appeal requests electronically. In addition, this CG has been written to assist you in designing and implementing the associated transactions and documents to meet NGS processing standards. This information is organized in the sections listed below:

  • Getting Started: This section includes information related to system operating hours. Information concerning Trading Partner registration is also included in this section.
  • Testing Requirements: This section includes detailed transaction testing information needed to complete transaction testing with Medicare.
  • Connectivity/Communications: This section includes information on NGS’ transmission procedures as well as communication and security protocols.
  • Contact Information: This section includes EDI customer service, EDI technical assistance and applicable websites.
  • Control Segments/Envelopes: This section contains information needed to create the ISA/IEA, GS/GE and ST/SE control segments for transactions to be submitted to Medicare.
  • Acknowledgments and Reports: This section contains information on all transaction acknowledgments sent by Medicare and report inventory.
  • Additional Trading Partner Information: This section contains information related to implementation checklist, transmission examples, Trading Partner Agreements and other resources.

1.4 References

The following websites provide information for where to obtain documentation for the HL7 documents and the X12 275 v6020 X314 transaction:

[Return to Top]

II. Getting Started

2.1 Working Together

NGS will work with providers directly through set-up, development, testing, and production implementation of the prior authorization initiative.

Upon implementation, the NGS EDI help desk is the first point of contact for basic information and troubleshooting. An EDI email process is also accessible as a method of communicating with NGS. The email account is monitored by knowledgeable staff ready to assist you. When communicating via email, please exclude any PHI to ensure security is maintained. In addition to the NGS EDI help desk and email access, feel free to communicate via alternative methods (see Section IV for contact information).

Specific information about the above-mentioned items can be found in the following sections.

2.2 Trading Partner Registration

The EDI Prior Authorization process is offered to Part A and Part B providers that are currently enrolled for electronic claims with NGS. EDI Analysts will work directly with the provider to ensure all trading partner management activity is appropriately completed. As a reminder, providers are required to use a Network Service Vendor (NSV) to connect to the NGS EDI Gateway.

2.3 Trading Partner Testing Process

Providers are required to test 275 with the embedded HL7 C-CDA prior to submitting production files.

  • Notify the NGS help desk when a test file has been submitted.
  • Acknowledgement transactions TRN, TA1 or 999 for the 275 transaction will be available within minutes.
  • NGS will contact the provider with the results of the processing of the HL7 test data.
  • Test files will not be sent to the processing systems.
  • EDI analysts will work directly with the provider during the test period.
  • See section 6.3 for the specific transaction requirements.

[Return to Top]

III. Connectivity/Communications

3.1 Process Flows for Batch Submissions

  • NGS supports the unsolicited 275 models.
  • The X12 275 transaction with the embedded HL7 supporting documentation should be sent at the same time as the claim and must be received within seven calendar days of the claim submission.
  • For the unsolicited model, an 837 received without the PWK segment for the associated 275 attachment will process following current guidelines without reviewing the additional documentation.
  • All X12 275 transactions will receive the TRN and 999 Acknowledgement transactions.

3.2 Transmission Administrative Procedures

The NGS EDI Gateway is accessed through an NGS-approved NSV.

3.3 Re-transmission Procedures

Submitters should not retransmit any 275 file that have successfully passed EDI front-end editing without specific instruction from NGS.

Submitters may retransmit any 275 file that has failed front-end editing and received a rejected 999 acknowledgement, once the file has been corrected.

3.4 Communication Protocols

NGS supports Secured FTP (sFTP) protocol for all EDI file transfer activity with connectivity through an NGS-approved NSV.

For the implementation of the Claims Attachment service, it is expected that providers can utilize their existing NSV connectivity to the NGS EDI Gateway. It is recommended that providers contact their NSV to discuss any impacts to their existing connection prior to initiating the Electronic Attachment work with NGS.

3.5 Security Protocols

Trading Partners who conduct business with NGS Medicare are subject to CMS security policies.

See the Appendix A CMSR High Impact Level Data document (Section SA-9) located on the CMS website.

CMS’ information security policy strictly prohibits the sharing or loaning of Medicare-assigned IDs and passwords. Users should take appropriate measures to prevent unauthorized disclosure or modification of assigned IDs and passwords. Violation of this policy will result in revocation of all methods of system access, including but not limited to EDI front-end access or EDC RACF user access. NGS is responsible for notifying all affected providers/suppliers as well as reporting the system revocation to CMS. See the Appendix A CMSR High Impact Level Data document (Section IA-2) located on the CMS website.

  • EDI Submitter ID passwords will expire after 60 days.
  • EDI Submitter IDs will suspend after 30 days of inactivity.
  • Passwords may not contain a four letter or greater ‘dictionary’ word, i.e., any word four letters or greater that can be found in a dictionary.
  • A minimum of four characters must be changed in each password reset.
  • Passwords may not be changed more than once in any 24-hour rolling period.
  • Passwords must be eight (8) characters in length, not more or less.
  • Passwords must contain a combination of alpha and numeric characters.
  • Passwords must include at least one (1) uppercase and one (1) lowercase letter (case sensitive).
  • Passwords must contain a special character; e.g. @, #, $.
  • Passwords must be different than the last nine (9) passwords.
  • Passwords must not be stored in scripts, files, or applications unless compensating controls are in place.

[Return to Top]

IV. Contact Information

4.1 EDI Customer Service and Technical Assistance

  • EDI Help Desk:
    • J6: 877-273-4334
    • JK: 888-379-9132
  • EDI Help Desk hours: 7:00 a.m.-4:00 p.m. CT / 8:00 a.m.-5:00 p.m. ET

4.2 Provider Services

Questions related to claims and/or the associated attachment data should be directed to the Provider Contact Center as follows:

  • JK (CT, MA, ME, NH, NY, RI, VT):
    • IVR: 877-567-7205
    • Toll-Free Number: 888-855-4356
    • TTY : 866-786-7155
    • Hours available: 8:00 a.m.-4:00 p.m. ET
      • Closed for training on the second and fourth Friday of the month from 12:00-4:00 p.m. ET
  • J6 (IL, MN, WI):
    • IVR: 877-309-4290
    • Toll-Free Number: 877-702-0990
    • TTY: 888-897-7523
    • Hours available: 8:00 a.m.-4:00 p.m. CT
      • Closed for training on the second and fourth Friday of the month from 11:00 a.m.-3:00 p.m. CT

4.3 Applicable Websites/Email

Questions directed to the EDI help desk can also be submitted via the EDI Email Inquiry Form on the NGS website.

[Return to Top]

V. Control Segments/Envelopes

Enveloping information must be as follows:

Interchange Control (ISA/IEA), Function Group (GS/GE), and Transaction (ST/SE) envelopes must be used as described in the standard implementation guides. Medicare’s expectations for inbound ISAs and a description of data on outbound ISAs are detailed in this chapter.

Note: NGS only accepts functional groups based upon one TR3 Implementation Guide per Interchange Envelope (ISA/IEA). If transactions based upon more than one TR3 Implementation Guide are being submitted, each must be contained within its own Interchange

Delimiters – Inbound Transactions

As detailed in the HIPAA-adopted implementation guides, delimiters are determined by the characters sent in specified, set positions of the ISA header. For transmissions to NGS (inbound transmissions), these characters are determined by the submitter and can be any characters which are not contained within any data elements within the ISA/IEA Interchange Envelope. This includes the text data within the HL7 standard in the BDS segment.

Delimiters – Outbound Transactions

NGS recommends the use of the following delimiters in all outbound transactions; trading partners/submitters should contact their local A/B MAC or CEDI for any deviations. Note that these characters will not be used in data elements within an ISA/IEA Interchange Envelope.

Delimiter Character Used Dec Value Hex Value
Data Element Separator > 62 3E
Repetition Separator ^ 94 5E
Component Element Separator + 43 2B
Segment Terminator - 126 7E


Inbound Data Element Detail and Explanation

All data elements within the interchange envelop (ISA/IEA) must follow X12 syntax rules as defined within the adopted implementation guide.

5.1 ISA-IEA for the 275 transaction

Reference Name Codes Notes/Comments
ISA Interchange Control Header    
ISA01 Authorization Information Qualifier 00 NGS expects the value to be 00
ISA02 Authorization Information   ISA02 shall contain 10 blanks
ISA03 Security Information Qualifier 00 NGS expects the value to be 00
ISA04 Security Information   NGS does not use security information and will ignore content sent in ISA04
ISA05 Interchange ID Qualifier ZZ Sender ID Qualifier
ISA06 Interchange Sender ID   NGS assigned Submitter ID. This is also required in the GS02 Application Sender
ID.
ISA07 Interchange ID Qualifier ZZ Receiver ID Qualifier
ISA08 Interchange Receiver ID   NGS specific MAC contractor number. These Receiver IDs are also required in the GS03
ISA11 Repetition Separator   Must be present
ISA14 Acknowledgement Requested 1 NGS requires submitter to send code value 1 - Interchange Acknowledgment Requested (TA1). NGS will only return a
TA1 segment when there is an error in the ISA/IEA Interchange Envelope.


5.2 GS-GE for the 275 transaction

Functional group (GS-GE) codes are transaction specific. The following are NGS rules related to processing of the functional groups.

Reference Name Codes Notes/Comments
GS Segment Rule   Contractor will only process one transaction type (records group) per interchange (transmission); a submitter must only submit one type of GS-GE (Functional Group) within an ISA-IEA (Interchange).
GS Segment Rule   Contractor will only process one type of transaction per functional group; a submitter must only submit one ST-SE (Transaction Set) within a GS-GE (Functional Group).
GS01 Functional Identifier Code PI PI ID assigned to 275 transaction
GS02 Application Sender Code   Include submitter number assigned by NGS.
GS03 Application Receiver’s Code   Receiver ID assigned by NGS, MAC contractor number. GS03 value must match ISA08
GS08 Version Identifier Code   GS08 must also match the ST03.


5.3 Transaction Details for the 275 transaction

NGS will accept up to ten Attachments (CDA/C-CDA Documents)/LX Loops with the BDS segment within a single 275 ST-SE. Multiple ST-SEs are acceptable within the ISA-IEA envelope.275 Transaction Details

Reference Name Code Notes/Comments
BGN01 Transaction Set Purpose Code 02
11
15
Value for unsolicited 275 transaction
Value for solicited 275 transaction
Value for Appeal 275 transaction
1000A PER Payer Contact Information   Required when BGN01 value is 11 and the Payer Response Contact Information (PER segment) was reported in loop 2210D PER segment of the 277 Health Care Claim Request for Additional Information
LX Loop Assigned Number   Currently, ten iterations of the LX loop can be used within a specific ST/SE. A separate LX loop is required for each document
TRN01 Trace Type Code 1
2
Value for unsolicited and appeal 275 transaction Value for solicited 275 transaction
TRN02 Provider Attachment Control Number   For unsolicited, an Unique number assigned by the provider. This value is also submitted in the PWK06 of the corresponding 837.
For solicited, the claim number assigned by the payer. This value will be in the 277 Healthcare Claim Request for Additional Information transaction, loop 2200D, TRN02 data element.
For electronic appeals, the claim number assigned by the payer should be used.
STC Segment Status Information   This segment is not used in the unsolicited or appeal; the segment is expected with a response to a solicited request.
CAT02 Report Transmission Code HL, MB or TX Currently we support structured or unstructured HL7
The IA value is not supported by NGS.
BDS01 Filter ID Code ASC or B64 Recommend the value of B64
BDS03 Binary Data   HL7 clinical data is embedded in this data element If BDS01 value is B64, BDS03 should be base64 encoded using RFC 4648. Only one document can be embedded in BDS03.

5.4 HL7 C-CDA R2.1 Details

The HL7 C-CDA R2.1 will be embedded within the BDS segment of the 275 transaction.

The C-CDA R2.1 templates supported by NGS are the Operative Note Template and the Unstructured Document Template. The specific requirements are included in the following HL7 Implementation Guides:

  • HL7 Implementation Guide for CDA Release 2: Consolidated CDA (C-CDA) Templates for Clinical Notes (US Realm) DSTU Release 2.1 – Volume 2 Templates and Supporting Material
  • HL7 Implementation Guide for CDA Release 2: Consolidated CDA (C-CDA)Templates for Clinical Notes (US Realm) DSTU Release 2 – Volume 1 Introductory Material
  • HL7 CDA R2 Attachment Implementation Guide: Exchange of C-CDA Based Documents, Release 1 US Realm

[Return to Top]

VI. Specific Business Rules

6.1 General Notes

The 275 BDS03 size is limited to 100MB. Any 275 transaction submitted with a BDS03 size greater than 100MB will be rejected on the 999 transaction where IK403 value is 10.

6.2 Unsolicited Attachments:

Part B unsolicited criteria includes:

  • Services submitted with the 22 or 66 modifier requires a clear concise statement and the operative notes
  • Services submitted with the 62 modifier and the procedure code has a multiple surgery indicator code of 1 require the operative notes.
  • Claims submitted with procedure codes 21031, 21032, 21110, 30120, 30400, 30410, 30420, 30430, 30435, 30450, and 69300 require medical necessity documentation.
  • Services submitted with AS, 80, 81 and 82 modifiers and the procedure code has an assistant surgery indicator of 0 require the operative notes.
  • Claims submitted with greater than five surgeries on the date of service.
  • Claim scenarios that require additional documentation, as identified by the provider’s billing history
  • Surgical NOC procedure codes require an operative note when the procedure can’t be adequately described in the comment field.
  • Services submitted with the 53 modifier require an operative note when the procedure can’t be adequately described in the comment field.
  • Modifier GM requires documentation including the specifics of a multiple patient transport, must include the number of patients transported and their Medicare HICN/MBI.

Part A unsolicited criteria includes:

  • Claim scenarios that require additional documentation, as identified by the provider’s billing history

6.3 Solicited Attachments

The 275 transaction can be sent as a response to the electronic request (277 Healthcare Claim Request for Additional Information) or in response to a paper letter requesting additional information about a claim.

6.4 Request for Appeal:

When requesting an appeal using the 275 transaction it is required to include one of the following:

  • Completed level 1 Appeal Request form
  • Letter that includes the following data:
    • Beneficiary name
    • Medicare number/MBI
    • Specific service/items for which the appeal is being requested
    • Specific dates of service
    • Name of the party or representative of the party (the provider)

6.5 LX Loop

The 275 transaction only supports one document in each BDS segment. If you are required to send more than one document, additional LX loops (within the ST/SE) are required. NGS supports 10 iterations of the LX loop for each ST/SE.

[Return to Top]

VII. Acknowledgements and Reports

NGS will return the TRN, TA1 and 999 Version 5010 as appropriate in response to the 275 version 6020 transaction. NGS will contact the Trading Partner directly regarding any issues with the HL7 or Attachment document.

7.1 Report Inventory

Transaction Acknowledgement (TRN) Report

The TRN is a text report file indicating initial validation of the inbound 275 file, including whether or not the file was identified as being an ANSI file.

  • The naming format is TRN. (input filename).txt.#### where - #### is a sequence number generated by EDI Systems
    • For example: TRN.TRANS.837.041313.txt.0062
  • The TRN will contain the Time Stamp, File Name, Trading Partner ID and Original File size of the received claim file.

Transaction Acknowledgement (TA1)

  • The TA1 segment indicates whether there are problems encountered with the X12 interchange control structure.
  • The TA1 will not be returned if the originally submitted data was not recognized as an X12 formatted file. This error will be returned on the TRN acknowledgment.
  • For TA1s generated in response to transactions sent via the sFTP Gateway, the file naming convention is as follows: TA1.inputfilename.txt_00001.#### where #### is a system sequence number.
    • Example: TA1.Filename.txt_00001.9014

Implementation Acknowledgement for Health Care Insurance (999)

The 999 is an ANSI file indicating results of data integrity analysis of the 275 file.

  • The naming format is 999.inputfilename.txt_00001.ccyymmddhhmmss.#### where #### is a sequence number generated by EDI systems.
    • Example: 999.filename.txt_00001.20170406203625.6025
      Note: ‘input file name’ if more than 32 characters will start to truncate the 999 name generated.
  • The 999 will return standard delimiters regardless of those used in the 275 file.
  • If the 999 is rejected at the Functional Group Response Trailer (AK9), the 999 will return the delimiters used in the original submitted file.
  • The 999 will be “wrapped,” with all segments on one long line of data.

[Return to Top]

VIII. Additional Trading Partner Information

While NGS EDI Gateway is available 24/7, NGS has scheduled regular maintenance for Sundays. Access to the EDI Gateway may be interrupted while maintenance is performed.

8.1 Implementation Checklist

  • Existing NGS Trading Partner with NSV connectivity and submitter ID established
  • Software to support the development of the 275 v6020 Transactions and HL7 C-CDA R2.1 Operative Note Template or Unstructured Document.
  • The X12 275 transaction must not be sent in the same Interchange as the claim transactions.
  • At this time, NGS only supports ten iterations of the LX loop in the 275 file in a specific ST/SE

8.2 Trading Partner Agreement

EDI Trading Partner Agreements ensure the integrity of the electronic transaction process. The Trading Partner Agreement is related to the electronic exchange of information, whether the agreement is an entity or a part of a larger agreement, between each party to the agreement.

For the purposes of the Claims Attachment Initiative, the provider must be an active NGS EDI Trading Partner with an EDI Enrollment Agreement already on file.

[Return to Top]

IX. Trading Partner Information Change Summary

Version Date Section(s) Changed Change Summary
1.0   All Initial Draft
4.0 6/1/2020 Section 1.2 Revised Scope
4.0 6/1/2020 Section VI Added new section
4.0 6/1/2020 Sections VII, VIII, IX, X Due to adding new section VI, renumbered following sections.
5.0 8/12/2020 6.4 Added Level 1 Redetermination Request form and the location to the forms.
5.0 8/18/2020 1.4 Updated the WPC web address per TDL 200391
6.0 5/24/2021 Multiple Removed HL7 CDA R2, several corrections and added Part B letter 275 transaction information
7.0 2/1/2024 Multiple Removed Part B letter 275 transaction information

Posted 2/8/2024