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
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.
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
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.
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 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
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
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)
- Example: TA1.Filename.txt_00001.9014
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.
- Example: 999.filename.txt_00001.20170406203625.6025
- 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
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.
IX. Trading Partner Information Change Summary
| Version | Date | Section(s) Changed | Change Summary |
|---|---|---|---|
| 1.0 | All | Initial Draft |
Reviewed 9/23/2024