Standard Companion Guide Trading Partner Information

Instructions Related to the X12 278 and 275 Prior Authorization Transactions
Companion Guide Version Number: 1.0 Created: April, 2022

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 for the 278 and 275 transactions
5.2 GS-GE for the 278 and 275 transactions
5.3 Transaction Details for the 275 transaction
5.4Transaction Details for the 278 transaction
5.5 HL7 C-CDA R2.1 Details

VI. Specific Business Rules
6.1 General Notes

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 Prior Authorization Request 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 278 Health Care Services Review Request and Response Version 5010 transaction, X12 275 Additional Information to Support a Health Care Services Review Version 6020 transaction and the HL7 C-CDA R2.1 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 278 v5010, 275 v6020 and C-CDA R2.1 to support the electronic request for prior authorization with submission of supporting documentation submitted to NGS.

Included are requests for prior authorization and submission of ‘unsolicited’ documentation.

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 electronically submitting prior authorization requests with submission of unsolicited supporting documentation. 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 278 v5010 X217 and 275 v6020 X316 transaction.

• Health Level 7 (HL-7)
• ​​​​​​​ASC X12

[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 Protected Health Information (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 278 and 275 files 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 TA1 and 999 for the 278 and 275 transactions 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 5 for the specific transaction requirements

[Return to Top]

III. Connectivity/Communications

3.1 Process Flows for Batch Submissions

• NGS supports the unsolicited 278 and 275 models.
• The X12 275 transaction with the embedded HL7 supporting documentation should be sent after the accepted 999 transaction is received for the 278 transaction
• All X12 275 transactions will receive the 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 278 or 275 files that have successfully passed EDI front-end editing without specific instruction from NGS.

Submitters may retransmit any 278 or 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 Prior Authorization 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 Prior Authorization 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 278 and 275 transactions

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 278 and 275 transactions

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). The X12 275 transaction MUST be in a separate ISA/IEA from the 278 file
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 HI	PI ID assigned to 275 transaction HI ID assigned to 278 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	Value for unsolicited 275 transaction – Only the unsolicited 275 is supported for electronic Prior Authorizations
2000A 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
2000A TRN01	Trace Type Code	1	Value for unsolicited 275 transaction – Only the unsolicited model is supported
2000A 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 278
2000A STC Segment	Status Information		This segment is not used in the unsolicited 275 model
2100A CAT02	Report Transmission Code	HL, MB or TX	Currently we support structured or unstructured HL7 The IA value is not supported by NGS
2110A 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 Transaction Details for the 278 transaction

Reference	Name	Code	Notes/Comments
BHT02	Transaction Set Purpose	13	Only the 13 value is supported
BHT06	Transaction Type Code		Do not use this data element
2010A NM101	Entity Identifier Code	X3	Only the X3 value is supported
2010A NM108	Identification Code Qualifier	PI	Only the PI value is supported
2010A NM109	Identification Code		ID assigned by NGS, MAC contractor number.
2010B NM101	Entity Identifier Code	1P FA	Value must be 1P for provider or FA for facility
2010B NM103	Name Last or Org Name		Requesting provider last name or facility name – this data is required for prior authorizations
2010B NM104	Name First		Requesting provider first name, if available, this data is required for prior authorizations
2010B NM108	Identification Code Qualifier	XX	Only the XX value is supported
2010B NM109	Identification Code		Requesting provider NPI
2010B REF01	Reference Identification Qualifier	ZH	Required for reporting PTAN number – this data is required for prior authorizations
2010B REF02	Reference Identification		Requesting provider PTAN number – this data is required for prior authorizations.
2010B N3 segment	Requestor Address		Requesting provider address information – this data is required for prior authorizations
2010B N4 segment	Requestor City, State and Zip		Requesting provider address information – this data is required for prior authorizations
2010B PER03	Communication Number Qualifier	TE	Only TE is required data for prior authorizations
2010B PER04	Communication Number		Requesting provider phone number – this data is required for prior authorizations
2010C NM103	Name Last or Org Name		Bene name data is required for prior authorizations
2010C NM104	Name First		Bene name data is required for prior authorizations
2010C N3 segment	Bene Address		Bene address data is required for prior authorizations
2010C N4 segment	Bene City, State and Zip		Bene address data is required for prior authorizations
2010C DMG02	Date Time Period		Bene date of birth is required for prior authorizations
2000D/2010D Loops	Patient Information		2000D/2010D loops are not used for prior authorizations for NGS
2000E UM01	Request Category Code	HS	Only HS value is supported for prior authorizations
2000E UM02	Certification Type Code	I	Only I value is supported for prior authorizations
2000E UM04	Health Care Service Location Information		2000E UM04 data element is required for prior authorizations
2000E DTP01	Event Date Date/Time qualifier	AAH	AAH qualifier is required for prior authorizations
2000E DTP03	Date Time Period		2000E DTP is required for prior authorizations, DTP03 should be the Anticipated date of service
2000E PWK06	Identification Code		Supporting documentation is required for all NGS prior authorization policies, PWK06 is required to match the prior auth request (X12 278 transaction) to the supporting documentation (X12 275 transaction). PWK06 is the Attachment Control Number. 2000E PWK overrides the 2000F PWK. 2000E or 2000F are required for prior authorizations. PWK06 must be a minimum of two and maximum of 50 characters and must match the value in the X12 275 2000A TRN02
2010EA NM101	Identity Identifier Code	SJ – Service Provider/Rendering provider FA – Facility 71 – Attending Physician	2010EA segments/elements are required for prior authorizations.
2010EA NM103	Last Name/Org		2010EA segments/elements are required for prior authorizations
2010EA NM104	First Name		2010EA segments/elements are required for prior authorizations
2010EA NM109	Identification Code		2010EA segments/elements are required for prior authorizations
2010EA N3	Provider Address		2010EA segments are required for prior authorizations
2010EA N4	Provider City, State and Zip		2010EA segments are required for prior authorizations
2010EA PER02	Name		2010EA PER is required for prior authorizations when 2010EA NM101 value is FA, Facility. This is the contact name for the facility
2010EA PER04	Communication Number		2010EA PER is required for prior authorizations when 2010EA NM101 value is FA, Facility. This is the phone number of the contact name for the facility
2000F Loop	Service Level Loop		Required for prior authorization, only five 2000F loops are allowed
2000F SV1	Professional Service		Required for Part B prior authorizations
2000F SV2	Institutional Service Line		Required for Part A prior authorizations
2000F PWK06	Identification Code		Supporting documentation is required for all NGS prior authorization policies, PWK06 is required to match the prior auth request (X12 278 transaction) to the supporting documentation (X12 275 transaction). PWK06 is the Attachment Control Number. 2000E PWK overrides the 2000F PWK. 2000E or 2000F are required for prior authorizations. PWK06 must be a minimum of 2 and maximum of 50 characters and must match the value in the X12 275 2000A TRN02
2010F Loop	Service Provider Information		All provider information must be reported in the 2010EA loops, 2010F loops must not be used for prior authorizations

5.5 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.

The NGS response to the Prior Authorization Request/278 transaction will be a hard copy letter through the US Postal Service. In the future, we will support the X12 278 Response transaction.

6.2 Prior Authorization Requirements:

Part B Prior Authorization Requirements include:

The CMS implemented a prior authorization model for repetitive scheduled nonemergent ambulance transport to determine whether prior authorization helps reduce expenditures while maintaining and/or improving quality of care.

The RSNAT prior authorization model applies to ambulance suppliers who provide Part B Medicare covered ambulance services and are enrolled as independent ambulance suppliers. Institutional (hospital) based ambulance services are excluded from the model.

• Non-Emergent, Repetitive, Scheduled Ambulance Transport

Part A Prior Authorization Requirements include:

The CMS implemented a prior authorization program for certain hospital OPD services for DOS on or after 7/1/2020. CMS believes prior authorization for certain hospital OPD services will ensure that Medicare beneficiaries continue to receive medically necessary care while protecting the Medicare Trust Fund from improper payments and keeping the medical necessity documentation requirements unchanged for providers. As a condition of payment for DOS on or after 7/1/2020, a PAR is required for the following hospital OPD services:

• Blepharoplasty, eyelid surgery, brow lift and related services
• Botulinum toxin injections
• Panniculectomy, excision of excess skin and subcutaneous tissue (including lipectomy) and related services
• Rhinoplasty and related services
• Vein ablation and related services

CMS has added two new services to the hospital OPD Prior Authorization program. For dates of service beginning on or after 7/1/2021, the additional hospital OPD services will be required as a condition of payment. These services are:

• Cervical Fusion with Disc Removal
• Implanted Spinal Neurostimulators

[Return to Top]

VII. Acknowledgements and Reports

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

7.1 Report Inventory

Transaction Acknowledgement (TRN) Report

The TRN is a text report file indicating initial validation of the inbound 278 and 275 files, 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
  • 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 278 and 275 files

• 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 278 and 275 files
• 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 278 v5010, 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 278 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