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
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:
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.
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.
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.
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
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
- CMS form 20027 OR
- Level 1 Redetermination Request form from the NGS website OR
- 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.
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.
- Example: 999.filename.txt_00001.20170406203625.6025
- 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.
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.
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 |
Reviewed 9/23/2024