Medicare FFS Companion Guide
Medicare Fee-ForService
Standard Companion Guide
Trading Partner Information
Instructions related to Transactions
Based on ASC X12 Implementation
Guides, version 005010
Companion Guide Version Number: 7
March 19, 2017
March 2017 ● 005010]
1
Medicare FFS Companion Guide
Disclaimer
This document may be freely redistributed in its entirety or in parts. The content of this document may not be altered by external
entities. This document may not be sold for profit or used in commercial documents without written permission.
The information in this document is subject to change.
CAQH CORE Phase IV requirements, WSDL, and XSD
can be found here:
CAQH CORE Phase IV
http://www.caqh.org/core/caqh-core-phase-iv-operating-rules
WSDL
http://www.caqh.org/sites/default/files/core/wsdl/CORERule4.0.0.wsdl
XSD
http://www.caqh.org/sites/default/files/core/wsdl/CORERule4.0.0.xsd
If you are referencing a downloaded copy, it is the responsibility of the reader to verify the correct version. CAHABA®, LLC will track
revision changes using a Change Control Summary Table.
This document contains references to websites that may be useful or of interest to Practice Management software vendors,
Clearinghouses, and providers. However, CAHABA®, LLC is not responsible for the content or privacy practices used by other site
owners, nor does it endorse the information contained at these external sites.
The information in the CAQH CORE Phase IV requirements is an implementation of EDI Process via public internet. This
process will allow providers to submit and retrieve EDI work over the web by implementing CAQH CORE Phase IV operating
rules. This path is in addition to the existing EDI process and will all allow providers perform transactions via both EDI Web
and existing EDI. CAQH CORE Phase IV operating rules will allow providers and Medicare Administrative Contractors (MACs)
to communicate with each other in a standardized format. CACH CORE II (http://www.caqh.org/core/caqh-core-phase-iirules) serves as precursor to moving into CAQH CORE IV and providers can refer CACH CORE II to get better understanding of
the transactions/payload types being implemented.
This is intended to serve only as a companion document for the ASC X12 Type 3 Technical Reports (TR3) adopted under the Health
Insurance Portability and Accountability Act (HIPAA). The tables contain requirements to be used for processing data in the CAHBA
claims processing system, specifically: ASC X12N/005010X221 Health Care Claim Payment/Advice (835), ASC X12N/005010X222
Health Care Claim: Professional (837), ASC X12N/005010X223 Health Care Claim: Institutional (837), and any Type 1 Errata published
by ASC X12 and adopted under HIPAA. Also included is guidance for acknowledgment TR3s, specifically: ASC X12N/005010X214
Health Care Claim Acknowledgment (277), and ASC X12C/005010X231 Implementation Acknowledgment for Health Care Insurance
(999), and any Type 1 Errata published by ASC X12.
The use of this document is solely for the purpose of clarification. This document supplements, but does not contradict any
requirements in the CAQH CORE Phase IV and ASC X12N implementation guides.
March 2017 ● 005010]
2
Medicare FFS Companion Guide
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 CAQH CORE Phase IV, 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 ASCX12’s
copyrights and Fair Use statement.
March 2017 ● 005010]
3
Medicare FFS Companion Guide
Table of Contents
DOCUMENT CHANGE SUMMARY LOG
6
1.0 INTRODUCTION
7
1.1 Purpose
1.2 Scope
1.3 Overview
1.4 References
1.5 Additional Information
1.5.1 EDI Acronyms
7
7
8
9
10
10
2.0 GETTING STARTED
13
2.1 Working Together
2.2 Trading Partner Registration
2.3 Trading Partner Testing and Certification Process
2.3.1 Testing Expectations from MAC to Trading Partner
2.3.2 Processing Guidelines and File Availability
2.3.3 How to Sign Up
2.3.4 Process for Testing
2.3.5 What to expect throughout the process
2.3.6 Description of delivery and interpretation of results
13
14
16
16
17
31
31
31
32
3.0 TESTING AND CERTIFICATION REQUIREMENTS
32
3.1 Testing Requirements
3.1.1 File Naming Convention
3.1.2 File Naming Convention – ANSI ASC X12N 837 Claim Transaction
3.1.3 File Naming Convention – ANSI ASC X12N 276 Claim Status Request
3.1.4 Electronic Remittance Advice (ERA)
3.1.5 ANSI ASC X12N 277 Claim Status Request Response
3.2 Certification Requirements
32
34
34
35
35
36
36
4.0 CONNECTIVITY / COMMUNICATIONS
36
4.1 Process flows
4.2 Transmission Administrative Procedures
4.2.1 Re-transmission procedures
4.3 Communication Protocols
4.4 Security Protocols
36
37
38
38
39
5.0 CONTACT INFORMATION
41
5.1 EDI Customer Service
March 2017 ● 005010]
41
4
Medicare FFS Companion Guide
5.2 EDI Technical Assistance
5.3 Provider Services
5.4 Applicable Websites / email
42
42
42
6.0 CONTROL SEGMENTS / ENVELOPES
42
6.1 ISA-IEA
6.1.1 Claims
6.1.2 Remittances
6.1.3 Delimiters
6.1.4 Character Sets
6.2 GS-GE
6.2.1 Claims
6.2.2 Remittances
6.3 ST-SE
6.4 1000A Submitter Name
6.5 1000B Receiver Name
43
43
44
44
45
45
46
46
46
46
46
7.0 ACKNOWLEDGEMENTS AND REPORTS
47
7.1 Report Inventory
49
8.0 ADDITIONAL TRADING PARTNER INFORMATION
51
8.1 Transmission Examples
8.2 Trading Partner Agreement
8.3 Frequently Asked Questions
8.4 Other Resources
51
53
53
54
9. TRADING PARTNER INFORMATION CHANGE SUMMARY
54
10. APPENDICES
54
March 2017 ● 005010]
5
Medicare FFS Companion Guide
Document Change Summary Log
Information regarding version and change control pertinent to any section of this document has been consolidated
Version
Date
Section
Comment
DRAFT
09/01/2010
All
Initial draft version of document
DRAFT1
02/18/2011
TPI: 6.1.2,
6.1.3, 6.1.4,
6.3, 7.1
Updated with required revisions per Data Interchange
Standards Association (DISA) review
TI: 3.0, 4.2
DRAFT2
08/22/2011
ALL
Updated with removal of HH+H information; Changed
VisionShare information to Ability Network.
FINAL
02/15/2012
ALL
Final Version
UPDATE
05/16/2012
TPI: 8.2
Updated links, clarified 1000A and 1000B loops
UPDATE
05/10/2013
All
Updated with new information and removed obsolete
references.
UPDATE
06/24/2014
All
Updated with new information and removed obsolete
references.
UPDATE
03/17/2017
All
CAQH CORE PHASE IV
March 2017 ● 005010]
6
Medicare FFS Companion Guide
Trading Partner Information
1.0 Introduction
1.1 Purpose
This document is intended to provide information from the author of this guide to trading partners to
give them the information they need to exchange EDI data with the author. This includes information
about registration, testing, support, and specific information about control record setup.
An Electronic Data Interchange (EDI) Trading Partner is defined as any Medicare customer (e.g.,
provider/supplier, billing service, and clearinghouse or software vendor) that transmits to, or receives
electronic data from, Medicare. Medicare’s EDI transaction system supports transactions adopted under
the Health Insurance Portability and Accountability Act of 1996 (HIPAA) as well as additional supporting
transactions as described in this guide.
Medicare FFS is publishing this Companion Guide to clarify, supplement and further define specific data
content requirements to be used in conjunction with, and not in place of, the ASCX12NTR3s for all
transactions mandated by Affordable Care Act (ACA), HIPAA and/or adopted by Medicare FFS for EDI.
This Companion Guide provides communication, connectivity and transaction specific information to
Medicare FFS trading partners and serves as the authoritative source for Medicare FFS specific EDI
protocols.
Additional information on Medicare FFS EDI practices are referenced within Pub. 100-04, Medicare
Claims Processing Manual, Chapter 24 on General EDI and EDI Support, Requirements, Electronic Claims
and Mandatory Electronic Filing of Medicare Claims. This document can be accessed at
http://www.cms.gov/manuals/downloads/clm104c24.pdf.
1.2 Scope
EDI addresses how providers/suppliers, or their business associates, exchange professional and
institutional claims, claim acknowledgments, claim remittance advice, claim status inquiry and
responses, and eligibility inquiry and responses electronically with Medicare. This guide also applies to
electronic transactions that are being exchanged with Medicare by third parties, such as clearinghouses,
billing services or network service vendors. Below is a listing of transactions required by Medicare FFS:
March 2017 ● 005010]
7
Medicare FFS Companion Guide
Transactions
Version
270/ 271 Health Care Eligibility Benefit Inquiry and
Response
005010X279A1
837 Health Care Claim: Professional
005010X222A1
837 Health Care Claim: Institutional
005010X223A2
999 Implementation Acknowledgment For Health Care
Insurance
005010X231A1
835 Health Care Claim: Payment/Advice
005010X221A1
276/277 Status Inquiry and Response
005010X212
277CA Claim Acknowledgement
005010X214
National Council for Prescription Drug Programs
(NCPDP) Version D.0 of the Telecom Standard
D.0 April 2009
This companion Guide provides technical and connectivity specification for the following above
listed transactions:

837 Health Care Claim: Institutional

837 Health Care Claim: Professional

835 Health Care Claim: Payment Advice

276/277 Status Inquiry and Response
Technical specifications for the 999 Implementation Acknowledgement for Health Care Insurance
and 277CA Claim Acknowledgement are subsumed under the technical specifications for the 837
Institutional and Professional Claim transaction.
The 270/271 Health Care Eligibility Benefit Inquiry and Response has its own companion guide that
can be found at: http://www.cms.gov/HETSHelp/.
NCPDP Version D.0 also has its own companion guide that can be found at:
http://www.ngscedi.com/.
1.3 Overview
March 2017 ● 005010]
8
Medicare FFS Companion Guide
This Companion Guide includes information needed to commence and maintain communication
exchange with Medicare. In addition, this Companion Guide has been written to assist you in
designing and implementing transaction standards to meet Medicare's processing standards. This
information is organized in the sections listed below:

Getting Started: This section includes information related to hours of operation, data services,
and audit procedures. Information concerning Trading Partner registration and the Trading
Partner testing process is also included in this section.

Testing and Certification Requirements: This section includes detailed transaction testing
information as well as certification requirements needed to complete transaction testing with
Medicare.

Connectivity/Communications: This section includes information on Medicare’s transmission
procedures as well as communication and security protocols.

Contact Information: This section includes EDI customer service, EDI technical assistance,
provider services 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.

Trading Partner Information Change Summary: This section describes the differences between
the current Companion Guide and the previous Companion Guide(s).
1.4 References
The following Websites provide information for where to obtain documentation for Medicare
adopted EDI transactions and code sets.
Resource
Web Address
ASC X12 TR3 Implementation
Guides
http://store.x12.org/
March 2017 ● 005010]
9
Medicare FFS Companion Guide
Resource
Web Address
Washington Publishing Company
Health Care Code Sets
http://www.wpc-edi.com/content/view/711/401/
1.5 Additional Information
1.5.1 EDI Acronyms
Acronym
ACA
Term/Explanation
Affordable Care ACT
ANSI
American National Standards Institute
ASC X12
The Accredited Standards Committee (ASC) X12 was tasked to develop uniform
standards for inter-industry electronic interchange of business transactions by the
American National Standards Institute.
“ASC X12 develops, maintains, interprets, publishes and promotes the proper use of
American National and UN/EDIFACT International Electronic Data Interchange
Standards.Ӡ
CCI
Communications/Connectivity Information
CG
Companion Guide
CAQH
Council for Affordable Quality Healthcare
CORE
Council for Affordable Quality Healthcare
DNS
Domain Name Server - Computers on the Internet are indexed by an Internet Protocol
(IP) address. These are not very easy to remember and may sometimes change. When
the DNS is sent in place of an IP, there is no need to remember a complicated number.
It also eliminates errors when IPs change. Typically, the DNS of the old IP is redirected
to point to the new IP, so connectivity issues are less likely to occur when using a DNS.
EDI
Electronic Data Interchange
ERF
Electronic Report File – Formatted acknowledgment file prior to Version 5010 in
proprietary layout.
FTP
File Transfer Protocol – This is a method available to deliver and retrieve batch files to
and from Cahaba Government Benefit Administrators®, LLC (Cahaba)
March 2017 ● 005010]
10
Medicare FFS Companion Guide
Acronym
IT
Term/Explanation
Information Technology
HCCA
Health Care Claim Acknowledgment – The HCCA is created using the 277 Transaction
with 005010X214 in the ST03 and TH in the BHT06 to indicate its intent.
HIPAA
Health Insurance Portability and Accountability Act – Federal law that addresses
various aspects of healthcare that include pre-existing conditions, privacy, security,
and transactions and codes sets.
HTTP
Hypertext Transfer
HTTPS
Hypertext Transfer Protocol within a connection encrypted by Transport Layer Security
LAN
Local Area Network - A system that links together electronic office equipment and
forms a network within an office or building.
MIME
Multipurpose Internet Mail Extensions
NPI
National Provider Identifier
PHI
Protected Health Information - The HIPAA Privacy Rule defines PHI as individually
identifiable health information about the past, present, or future physical or mental
health or condition (including the provision of his/her healthcare, insurance, payment
status, etc.) of an individual.
SHA
SOAP
Secure Hash Algorithm-is one of a number of cryptographic hash functions. A
cryptographic hash is like a signature for a text or a data file. SHA-256 algorithm
generates an almost-unique, fixed size 256-bit (32-byte) hash. Hash is a one way
function – it cannot be decrypted back. This makes it suitable for password validation,
challenge hash authentication, anti-tamper, digital signatures. SHA-256 is one of the
successor hash functions to SHA-1, and is one of the strongest hash functions
available.
Simple Object Access Protocol
SSL
Secure Socket Layer
TI
Transaction Instruction
TR3
Technical Type Report 3 – The report type used to contain implementation guidance
for a specific ASC X12 transaction. Prior to 5010 this type of instruction was contained in
documents referred to as Implementation Guides (IG).
TRANFILE
March 2017 ● 005010]
Transmission File – This file contains high-level status of an 837 transmission prior to
running through standard and implementation edits such as whether a file was
unzipped successfully or if the file was rejected due to invalid format (this is not an
11
Medicare FFS Companion Guide
Acronym
Term/Explanation
ASC X12 transaction).
WSDL
Web Service Definition Language
WEDI
Workgroup for Electronic Data Interchange
“MISSION: To provide multi-stakeholder leadership and guidance to the healthcare
industry on how to use and leverage the industry's collective technology, knowledge,
expertise and information resources to improve the administrative efficiency, quality
and cost effectiveness of healthcare information.” ‡
X12N
See ASC: Within X12 there are committees designated with a letter. N represents
Insurance.
The Websites listed below provide additional resources during the transition year for HIPAA version
5010 implementation.
Resource
Web Address
Central Version 005010 and D.0
Webpage on CMS Website
http://www.cms.gov/Versions5010andD0/
Educational Resources (including MLN .http://www.cms.gov/Versions5010andD0/40_Educ
articles, fact sheets, readiness
ational_Resources.asp#TopOfPage
checklists, brochures, quick reference
charts and guides, and transcripts from
national provider calls)
Affordable Care Act - Operating Rules Requirements for Phase II and Phase III
Compliance for Batch Processing
https://www.cms.gov/Outreach-andEducation/Medicare-Learning-NetworkMLN/MLNMattersArticles/Downloads/MM9358.pdf
Dedicated HIPAA 005010/D.0 Project
Web page (including technical
documents and communications at
national conferences)
http://www.cms.gov/MFFS5010D0/
Frequently Asked Questions
http://questions.cms.hhs.gov/app/answers/list/kw/
March 2017 ● 005010]
12
Medicare FFS Companion Guide
Resource
Web Address
5010
Responses to Technical Comments
http://www.cms.gov/TransactionCodeSetsStands
To request changes to HIPAA adopted
standards
http://www.hipaa-dsmo.org/
The following website provides operational information for EDI and electronic transaction
standards:
Medicare FFS EDI Operations http://www.cms.gov/ElectronicBillingEDITrans/
2.0 Getting Started
2.1 Working Together
Cahaba Government Benefit Administrators®, LLC (Cahaba) is dedicated to providing several
communication channels to ensure communication remains constant and efficient. Cahaba has several
options in an effort to assist the community with their electronic data exchange needs. By using any of
these methods Cahaba is focused on supplying the Trading Partner community with a variety of support
tools.
An EDI help desk is established for the first point of contact for basic information and troubleshooting.
The help desk is available to support most EDI questions/incidents while at the same time being
structured to triage each incident if more advanced research is needed. An EDI e-mail is also accessible
as a method of communicating with Cahaba. 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 Cahaba’s EDI help desk and email access, feel
free to communicate via alternative methods (see section 5 below for contact information).
Cahaba also has several external communication components in place to reach out to the trading
partner community. Cahaba posts all critical updates, system issues and EDI specific billing material to
their website, https://www.cahabagba.com/. All Trading Partners are encouraged to visit this page to
ensure familiarity with the content of the site. Cahaba also distributes EDI pertinent information in the
form of an EDI newsletter or comparable publication, which is posted to the Website every month. In
addition to the Website, a distribution list has been established in order to broadcast urgent messages.
Please register for Cahaba’s distribution list by completing the subscription form at
https://www.cahabagba.com/forms/subscribeForm.htm.
March 2017 ● 005010]
13
Medicare FFS Companion Guide
Specific information about the above-mentioned items can be found in the sections below.
2.2 Trading Partner Registration
An EDI Trading Partner is any entity (provider, billing service, clearinghouse, software vendor, employer
group, financial institution, etc.) that transmits electronic data to or receives electronic data from
another entity.
Medicare FFS and Cahaba support many different types of trading partners or customers for electronic
data interchange (EDI). To ensure proper registration it is important to understand the terminology
associated with each customer type.
A Submitter is the entity that owns the submitter ID associated with the healthcare data being
submitted. It is most likely the provider, hospital, clinic, supplier, etc., but could also be a third party
submitting on behalf of one of these entities. However, a submitter must be directly linked to each
billing NPI. Often the terms submitter and trading partner are used interchangeably because a Trading
Partner is defined as the entity engaged in the exchange or transmission of electronic transactions.
Thus, the entity that is submitting electronic administrative transactions to Cahaba is a Medicare FFS
trading partner.
Provider/Supplier – the entity that renders services to beneficiaries and submits health care claims to
Medicare.
A Vendor is an entity that provides hardware, software and/or ongoing technical support for covered
entities. In EDI, a vendor can be classified as a software vendor, billing or network service vendor or
clearinghouse.
Software Vendor – an entity that creates software used by billing services, clearinghouses and
providers/suppliers to conduct the exchange of electronic transactions with Medicare FFS.
Billing Service – a third party that prepares and/or submits claims for a provider/supplier.
Clearinghouse – a third party that submits and/or exchanges electronic transactions (claims, claim
status or eligibility inquiries, remittance advice, etc.) on behalf of a provider/supplier.
Network Service Vendor – a third party that provides connectivity between a provider, supplier, clearing
house or billing service and Cahaba.
Medicare requires all trading partners to complete EDI registration and sign an EDI Enrollment form. The
EDI enrollment form designates the Medicare contractor and/or CEDI as the entity they agree to engage
in for EDI and ensures agreement between parties to implement standard policies and practices to
ensure the security and integrity of information exchanged. The forms can be accessed at:
Part B (Professional)
March 2017 ● 005010]
14
Medicare FFS Companion Guide
https://www.cahabagba.com/part_b/edi/forms.htm
Part A (Institutional)
https://www.cahabagba.com/part_a/edi/forms.htm
Entities processing paper do not need to complete an EDI registration.
New providers to EDI and providers wishing to change their method of interchange for any available
transaction must complete an EDI Application/Agreement prior to the change taking effect. These forms
and the detailed instructions for completing and submitting them can be found by following the links
above.
 NOTE: The EDI forms must be completed on the Cahaba website prior to being printed.
Please sign all signature fields and fax to the number listed on the first page of the
application.
Under HIPAA, EDI applies to all covered entities transmitting the following administrative transactions:
837I and 837P, 835, 270/271, 276/277 and NCPDP. Beginning on January 1, 2011, Medicare contractors
and CEDI will also use the TA1, 999 and 277CA error handling transactions.
Medicare requires that we furnish new providers/suppliers that request Medicare claim privileges
information on EDI. Additionally, Medicare requires us to assess the capability of entities to submit data
electronically, establish their qualifications (see test requirements in Section 3.0 below), and enroll and
assign submitter EDI identification numbers to those approved to use EDI. The EDI enrollment process
for the Medicare beneficiary inquiry system (HETS 270/271) is currently a separate process. Information
on the EDI enrollment process for HETS can be found on the CMS HETS Help website
(http://www.cms.gov/HETSHelp/).
A provider must obtain an NPI and furnish that NPI to Cahaba prior to completion of an initial EDI
Enrollment Agreement and issuance of an initial EDI number and password by that contractor. Cahaba is
required to verify that NPI is on the NPI Crosswalk. If the NPI is not verified on the NPI Crosswalk, the EDI
Enrollment Agreement is denied and the provider is encouraged to contact Cahaba’s provider
enrollment department (for Medicare Part A and Part B providers) or the National Supplier
Clearinghouse (for DME suppliers) to resolve the issue. Once the NPI is properly verified, the provider
can reapply the EDI Enrollment Agreement.
A provider’s EDI number and password serve as a provider’s electronic signature and the provider would
be liable if any entity with which the provider improperly shared the ID and password performed an
illegal action while using that ID and password. A provider’s EDI access number and password are not
part of the capital property of the provider’s operation, and may not be given to a new owner of the
provider’s operation. New owners must obtain their own EDI access number and password.
March 2017 ● 005010]
15
Medicare FFS Companion Guide
If providers elect to submit/receive transactions electronically using a third party such as a billing agent,
a clearinghouse, or network services vendor, they are required to have an agreement signed by that
third party. The third party must agree to meet the same Medicare security and privacy requirements
that apply to the provider in regard to viewing or use of Medicare beneficiary data. These agreements
are not to be submitted to Medicare, but are to be retained by the providers. Providers will notify
Cahaba which third party agents they will be using on their EDI Enrollment form.
Third parties are required to register with Cahaba by completing the third party agreement form. This
will insure that their connectivity is completed properly; however, a separate enrollment may be
required for enrollment in mailing lists to receive all publications and email notifications.
This agreement can be downloaded from the Cahaba website at:
Part B (Professional)
https://www.cahabagba.com/part_b/edi/forms.htm
Part A (Institutional)
https://www.cahabagba.com/part_a/edi/forms.htm
Providers must also be informed that they are not permitted to share their personal EDI access number
and password with any billing agent, clearinghouse/network service vendor. Providers must also not
share their personal EDI access number with anyone on their own staff who does not need to see the
data for completion of a valid electronic claim, to process a remittance advice for a claim, to verify
beneficiary eligibility, or to determine the status of a claim. No other non-staff individuals or entities
may be permitted to use a provider’s EDI number and password to access Medicare systems.
Clearinghouse and other third party representatives must obtain and use their own unique EDI access
number and password from Cahaba. For a complete reference to security requirements see section 4.4
below and refer to the Appendix A CMSR High Impact Level Data document located on the CMS website
(http://www.cms.gov/informationsecurity/downloads/ARS_App_A_CMSR_HIGH.pdf.)
2.3 Trading Partner Testing and Certification Process
2.3.1 Testing Expectations from MAC to Trading Partner
 Test 837P and/or 837I, and 835 if applicable.
 Obtain testing instructions from the Cahaba website
 Review Companion Guide
 Download, review, and understand the 837, 999, and 277CA TR3 Documents.
March 2017 ● 005010]
16
Medicare FFS Companion Guide
 Dedicate resources to provide technical support for testing to ensure accuracy and timely
feedback.
 To become familiar with the Edits Spreadsheets which are also located on the CMS website
at http://www.cms.gov/Medicare/Billing/MFFS5010D0/Technical-Documentation.html.
 Vendor and/or billing service or clearinghouse to support providers with human readable
formats of the acknowledgements transactions (999 and 277CA).
Processing Guidelines and File Availability
CR9358 requires the MACs to implement a solution to comply with CAQH CORE Phase II Connectivity Rule 270, including the
use of X.509 Client Certificates over SSL. This solution must be able to receive and post the batch 276/277 transactions for
using the public internet for the Hypertext Transfer Protocol within a connection encrypted by Transport Layer Security
(HTTP/S) transport. The MACs shall accept 276 transactions up until 9pm Eastern time of a business day, which equates to
receipt of the 276 within the EDI front-end system for any 276 transactions submitted via either the MAC’s Electronic Data
Interchange (EDI) gateway or the public Internet. The MAC must then return the 277 transaction by 7:00 am Eastern time
the next business day. The MACs must also track the times of any received inbound messages with the capability to
generate a report (audit log) that tracks the 999 response to the inbound 276 as well as date and timestamp for the 277,
including the date and time the message was sent in HTTP+MIME or SOAP+WSDL Message Header tags. The MACs must
support both Message Envelope Standards and Message Exchanges (HTTP+MIME) and Simple Object Access Protocol and
Web Service Definition Language (SOAP+WSDL) Message. The solution must be able to report HTTP server errors with an
HTTP 500 Internal Service Error or a HTTP 503 Service Unavailable error message for 276/277/835/999 transactions. The
MACs must support Submitter Authentication Standards as detailed in Operating rule 153 for the 276/277/835/999
transactions.
Certain transactions may be transmitted and received via the Internet, provided the user meets the required
security standards:



Either HTTP+MIME or SOAP+WSDL
o ‘Sender ID’ will be populated by the unique submitter ID assigned by Cahaba to
the sender
o ‘Receiver ID’ will be the Cahaba Receiver ID specified in section 6.1.1 of this
document
X.509 Client Certificates over Secure Socket Layer (SSL)
Submitter must meet Submitter Authentication Standards detailed in Operating rule
153, Section 5.
This is in accordance with the Phase II Connectivity Rule 270, which is based on the Phase I Connectivity Rule
153.
For electronic remittance advice (835) Cahaba uses HTTP/S Version 1.1 as a transport method for users who
retrieve their files via the public Internet.
March 2017 ● 005010]
17
Medicare FFS Companion Guide
For files submitted and retrieved via the public Internet, Cahaba complies with the security and authentication
requirements as detailed in the Phase II CORE 270 Connectivity Rule.
March 2017 ● 005010]
•
Claim files must be received on the Secure FTP server before 8 p.m. CST (9 p.m. EST) for
complete processing to occur that business day.

999 and Daily Log will be available for retrieval in your directory on the Secure FTP server
within two hours of file submission of ANSI 837 or 276 file from 8:00 a.m. CST to 3:30 p.m.
CST (9:00 a.m. EST to 4:30 p.m. EST).

Files accepted on the 999 are moved from the Secure FTP Server to the mainframe to pass
through the Common Edit Module (CEM) for additional editing.

The 277CA (Claim Acknowledgement) and 277 will be available for retrieval after 6:00 a.m.
CST (7:00 a.m. EST) on the next business day.
•
Only Batch processing mode is currently being implemented.
•
Following four transactions are currently being implemented:
1.
276
Claim Status Request
2.
999
Implementation
Acknowledgement
3.
277
Claim Status Response
4.
835
Electronic Remittance Advice
•
Provider will need to use X.509 certificate for authentication and SOAP + MTOM as a message format
(CAQH CORE Phase IV).
•
For data retrieval (in case of 999, 277, and 835) provider will need to provide the soap message
(CAQH CORE Phase IV) along with a single MTOM payload of an XML file. Using the transaction type
in the soap message along with the date provided in the XML file, provider will be able to retrieve the
entire set of files specific to a transaction type and the date files were processed at the backend.
18
Medicare FFS Companion Guide
Sample XML
dateRequest.xml
XSD
dateRequest.xsd
Date Format
•
Provider will have a flexibility to send files via one medium (EDI/EDI Web) and retrieve file from
another.
•
Batch submission
o
March 2017 ● 005010]
YYYYMMDD
The Batch Submission message structure shown below specifies SOAP 1.2, and also uses
MTOM to send the payload file. This shows the following:
 The HTTP Headers are shown colored in blue.

The portion of the SOAP envelope colored in green

The Batch file (MTOM attachment) is shown colored in orange.
19
Medicare FFS Companion Guide
•
Batch submission response
o
March 2017 ● 005010]
The Batch Submission message structure shown below specifies SOAP 1.2, and also uses
MTOM to send the payload file. This shows the following:
 This response will not have any payload but will still be in an MTOM format
20
Medicare FFS Companion Guide
•
Batch submission secondary acknowledgement retrieval request
o
March 2017 ● 005010]
The Batch Submission Acknowledgement Retrieval Request message structure shown below
specifies SOAP 1.2. The use of MTOM in Batch mode request/response creates multipart
MIME even though there is no payload. This shows the following:
 This retrieval request will contain an XML file containing a single date field in
‘YYYYMMDD’ format. (See Example ‘dateRequest.xml’ on Page 19.)
 This field will be extracted by the API.
 API will then take the extracted Date and payload type to find files on the directory.
21
Medicare FFS Companion Guide
•
Batch submission secondary acknowledgement retrieval response
o
March 2017 ● 005010]
The Batch Submission Acknowledgement Retrieval Response message structure shown
below specifies SOAP 1.2 and MTOM. This shows the following:
 The API will package all the files that matches the search and send this message
with files in the payload
22
Medicare FFS Companion Guide
•
Batch submission result retrieval request
o
March 2017 ● 005010]
The Batch Results Retrieval Request message structure shown below specifies SOAP 1.2. The
use of MTOM in Batch Mode request/response creates multipart MIME even though there is
no payload (which may be the case for a Batch Retrieval Request). This shows the following:
 This retrieval request will contain an XML payload (dateRequest.xml) file containing
a single date field.
 This field will be extracted by the API.
 API will then take the extracted Date and payload type to find files on the directory.
23
Medicare FFS Companion Guide
•
Batch submission result retrieval response
o The Batch Results Retrieval Response message structure shown below specifies SOAP 1.2
and MTOM. This shows the following:

March 2017 ● 005010]
The API will package all the files that matches the search and send this message
with files in the payload
24
Medicare FFS Companion Guide
•
March 2017 ● 005010]
Batch results ack submission message
o This is the submission of ack file for the successful receipt of Batch result files
25
Medicare FFS Companion Guide
March 2017 ● 005010]
26
Medicare FFS Companion Guide
•
March 2017 ● 005010]
Batch Results Acknowledgement Submission Response Message
o Ack receipt response.
27
Medicare FFS Companion Guide
Error Handling:
element name
Data type
validation condition
ErrorMessage
ErrorCode
PayloadType
string
"X12_999_SubmissionRequest_005010X231A1"
"X12_Response_ConfirmReceiptReceived"
"X12_999_RetrievalRequest_005010X231A1"
"X12_999_Response_005010X231A1"
"X12_276_Request_005010X279A1"
"X12_BatchReceiptConfirmation"
"X12_005010_Request_Batch_Results_277"
"X12_277_Response_005010X279A1"
"X12_835_Request_005010X221A1"
"X12_835_Response_005010X221A1"
A request was
received at this
server with an invalid
PayloadType that is
currently not
implemented by this
server
NotSupported
March 2017 ● 005010]
28
Medicare FFS Companion Guide
A request was
received at this
server with an invalid
ProcessingMode that
is currently not
implemented by this
server
NotSupported
Maximum length 50 characters
Illegal value provided
for SenderID. Value
provided is not valid
based on the
metadata constraints
defined in the CAQH
CORE Connectivity
Rule.
Illegal
string
Maximum length 50 characters
Illegal value provided
for ReceiverID. Value
provided is not valid
based on the
metadata constraints
defined in the CAQH
CORE Connectivity
Rule.
Illegal
CORERuleVersion
string
4.0.0
The CAQH CORE Rule
Version sent is not
valid at the receiver
(server).
VersionMismatch
CheckSum
string
64 digits (SHA 256)
The checksum value
computed on the
recipient did not
match the value that
was sent in the
envelope.
ChecksumMismatch
ed
ProcessingMode
string
PayloadID
string
PayloadLength
string
TimeStamp
datetime
format: 2007-08-30T10:20:34Z
SenderID
string
ReceiverID
March 2017 ● 005010]
"Batch"
29
Medicare FFS Companion Guide
Payload (Xml with
Date)
If more than one xml is uploaded or date is not
properly formated per the xsd
Date value provided
is not valid based on
the metadata
constraints defined
in the Companion
guide.
Payload
If payload failed to process (create on EFT)
Send Http 500 error No error required.
(Will send Soap
server fault)
FormatNotSupporte
d
**success**
Envelope was
processed
successfully.
Success
**No files found**
Envelope was
processed
successfully but no
files were found
matching provided
information
Success
March 2017 ● 005010]
30
Medicare FFS Companion Guide
2.3.3 How to Sign Up
 Contact the Cahaba EDI Help Desk at:
Part A and Part B: (866)582-3253
 Complete EDI Application
Existing Vendor and/or Billing Service or Clearinghouse
If you are an Existing vendor and/or Billing Service or Clearinghouse, you do not need to
complete the EDI Application.
New Vendors/Billing Services/Clearinghouses –
You must complete the following:
•
EDI Vendor Application and Network Service Agreement
•
EDI Application or System Access Application completed for each
client/medical practice and signed by the authorized personnel in the
provider’s office.
•
Billing Service Application (if applicable)
EDI Applications are located on Cahaba’s website at:
Part B (Professional) https://www.cahabagba.com/part_b/edi/forms.htm
Part A (Institutional) https://www.cahabagba.com/part_a/edi/forms.htm
2.3.4 Process for Testing
• New vendors need to complete the Vendor Application available on our website at
https://www.cahabagba.com/forms/.
•
At least one EDI application from a provider who will be using the software to be tested
must be included with the vendor application.
•
It is important that you download and review the reports on the Secure FTP Server for a
status of your test files. Please make corrections as needed and continue to send test files.
•
Once you have successfully met the criteria for testing, the test submitter should contact
the EDI Help Desk for production status.
2.3.5 What to expect throughout the process
 Testing instructions on Cahaba’s website at:
March 2017 ● 005010]
31
Medicare FFS Companion Guide
For Part A
https://www.cahabagba.com/part_a/edi/testing_procedures.htm
For Part B
https://www.cahabagba.com/part_b/edi/Overview_N3_Testing_procedures.htm
 Accommodation of all requests for testing within a reasonable time frame. (Once the vendor
has notified Cahaba of their desire to test, they will be required to send their initial test file
within thirty days and proactively monitor their testing until approval is received from
Cahaba).
 An approved vendor list with all successfully tested vendors published on Cahaba’s
website at:
 For Part A
http://www.cahabagba.com/part-a/claims/electronic-data-interchange-edi/directoryof-approved-vendors/
For Part B

http://www.cahabagba.com/part-b/claims-2/electronic-data-interchange-edi/directoryapproved-vendors/

Test results will be available in your directory on the Secure FTP Server within 24 hours
of file submission. All submitters are responsible for retrieving their test results from
their directory and making necessary corrections.
2.3.6 Description of delivery and interpretation of results
Output file will be available for them to interpret based on the guidelines and the edit reference
guide.
3.0 Testing and Certification Requirements
3.1 Testing Requirements
All claim submitters must produce accurate electronic test claims before being allowed to submit claim
transactions in production. All submitters must send a test file containing at least 25 claims, which are
representative of their practice or services. The number of claims could be increased or decreased, on a
case by case basis, to ensure adequate testing of any given submitter. Test claims are subject to
March 2017 ● 005010]
32
Medicare FFS Companion Guide
standard syntax and IG semantic data edits; documentation will be provided when this process detects
errors.
•
Standard syntax testing validates the programming of the incoming file and includes file layout,
record sequencing, balancing, alpha-numeric/numeric/date file conventions, field values, and
relational edits. Test files must pass 100 percent of the standard syntax edits before production is
approved.
•
IG Semantic Data testing validates data required for claims processing, e.g., procedure/diagnosis
codes, modifiers. A submitter must demonstrate, at a minimum, a 95 percent accuracy rate in data
testing for at least two consecutive test files before production is approved where, in the judgment
of Cahaba, the vendor/submitter will make the necessary correction(s) prior to submitting a
production file. For FIs, the minimum 95 percent accuracy rate includes the front-end edits applied
using the FISS implementation guide editing module.
•
A 999 will be available within an hour after a test file has been submitted. If the file is accepted, or
accepted with errors, the 277CA will be available by the morning of the next business day.
Many claim submitters use the same software to submit their electronic claims to Medicare.
•
In those cases Cahaba is not required to test each submitter that uses the same software.
•
Once the vendor’s software is approved for production, all of the facilities/providers/billing services
/clearinghouses are approved.
•
The facility/provider must have an EDI Application on file for that vendor and/or Billing Service or
Clearinghouse before submitting electronic claims. Billing Services/Clearing houses must have a
completed Billing Service Application on file for the vendor’s software they are using.
Providers/suppliers who submit transactions directly to more than one FI, Carrier, RHHI, A/B MAC,
and/or CEDI, and billing services and clearinghouses that submit transactions to more than one FI,
Carrier, RHHI, A/B MAC, and/or CEDI, must contact each FI, Carrier, RHHI, A/B MAC, and/or CEDI with
whom they exchange EDI transactions to inquire about the need for supplemental testing whenever
they plan to begin to use an additional EDI transaction, different or significantly modified software for
submission of a previously used EDI transaction, or before a billing agent or clearinghouse begins to
submit transactions on behalf of an additional provider. The individual FI, Carrier, RHHI, A/B MAC,
and/or CEDI may need to retest at that time to re-establish compatibility and accuracy, particularly if
there will also be a change in the telecommunication connection to be used.
Billing services and clearinghouses are not permitted to begin to submit or receive EDI transactions on
behalf of a provider prior to submission of written authorization by the provider that the billing agent or
March 2017 ● 005010]
33
Medicare FFS Companion Guide
clearinghouse has been authorized to handle those transactions on the provider’s behalf. See section 2.2
above for further information on EDI Enrollment.
3.1.1 File Naming Convention
Claim Type
Naming Convention (Example)
Professional Claim
PALPnnnn.8375010.clm
Institutional Claim
PALInnnn.8375010.clm
Professional Claim Status
PALBnnnn.2765010.276
Institutional Claim Status
PALAnnnn.2765010.276
Remits
submitter.date.8355010.zip
Claim Status Response
submitter.date.2775010.zip
Implementation Acknowledgement
submitter.filename.date.time.999
Health Care Claim Acknowledgement
submitter.date.277CA5010.zip
3.1.2 File Naming Convention – ANSI ASC X12N 835 Electronic Remittance Advice
Files must be named according to the following file naming specifications and compressed prior to
transmission.
Uncompressed (unzipped):
(t,p)(al, ga, tn) (i, p)(0000-9999).(8375010).clm
Compressed (zipped):
(t,p)(al,ga, tn) (i,p)(0000-9999).(8375010).zip
(t,p) : t = Test, p = Production
(al, ga, tn) –
March 2017 ● 005010]
State code for Medicare Line of Business
34
Medicare FFS Companion Guide
(i, p):
i = Institutional or HH + H ANSI 837, p = Professional ANSI 837
(0000-9999) -
Transmission number per day
Example Test/ Production File Name Uncompressed:
o
tgap0000.8375010.clm or pgap0000.8375010.clm
Example Test/Production File Name Compressed:
o
tgap0000.8375010.zip or pgap0000. 8375010.zip
3.1.3 File Naming Convention – ANSI ASC X12N 276 Claim Status Request
Files must be named according to the following file naming specifications and compressed prior
to transmission. Use either all UPPERCASE or all lowercase:
(P)(AL, GA, TN)(A, B) (nnnn).2765010.276
(P) : P = Production
(AL, GA, TN): State code for Medicare Line of Business
(A, B)
A = Part A Institutional
B = Part B Professional
(nnnn) : Transmission number per day
Example Uncompressed:
PGAB0001.276 5010.276 or pgab0001.2765010.276
Example Compressed:
PGAB0001.2765010.ZIP or pgab0001.2765010.zip
3.1.4 Electronic Remittance Advice (ERA)
Electronic Remittance Advice (ERA) – The electronic remittance advice is a standard ANSI ASC X12N
835 transaction that corresponds to a Standard Paper Remittance Advice. ERA files are available for
downloading from the Secure FTP server following the regularly scheduled payment cycles. ERA files
are available on the Secure FTP server for 45 days after which they are purged and can no longer be
March 2017 ● 005010]
35
Medicare FFS Companion Guide
restored or retrieved. Please ensure you download your ERA files on a regular basis to avoid having
to request a duplicate hard copy remittance. The ERA files are named as follows:
[Submitter ID].[Date].8355010.zip
e.g. – USERID.20110101.8355010.zip
3.1.5 ANSI ASC X12N 277 Claim Status Request Response
ANSI ASC X12N 277 Claim Status Request Response – The 277 claim status response is a standard
ANSI ASC X12N 277 transaction that corresponds to the ANSI ASC X12N 276 claim status request.
The 277 files are available the following business day after submitting the 276 request. The 277 files
are named as follows:
[USERID].[file processed date].2775010.zip
e.g. gaf12345.20110101.2775010.zip
3.2 Certification Requirements
Medicare FFS does not certify providers/suppliers; however, Cahaba does certify vendors in the
form of testing with them and maintaining an approved vendor list that can be accessed at:
Part B
http://www.cahabagba.com/part-b/claims-2/electronic-data-interchange-edi/directory-approvedvendors/
Part A
http://www.cahabagba.com/part-a/claims/electronic-data-interchange-edi/directory-of-approvedvendors/
Billing Services and Clearinghouses using an approved vendor’s software to submit their claims do
not need to test. Billing Services and Clearinghouses who are using their own proprietary software
to submit their claims will need to test according to the procedures outlined in this document for
vendors.
4.0 Connectivity / Communications
4.1 Process flows
1) A submitter will log onto a designated account on the Secure FTP Server at bluecmsftp.bcbsal.org
using a connection via an approved Network Service Vendor connection.
2) The claim files will be sent to the users' respective directories.
March 2017 ● 005010]
36
Medicare FFS Companion Guide
4) After the files go through pre-edits (Pre-edits are high-level edits for zip errors, filename errors,
ISA presence checks, etc.) and compliance checks [Level 1 (Standard) and Level 2 (Implementation
Guide) verification], the information will be compiled in the 999 acknowledgement.
5) The file will then be translated to the CMS Flat File with 999E level errors denoted by including a
STC segment within the file and FTPed to the CEM Server.
6) The files are processed by the appropriate CEMA/B module, utilizing Reference files located on a
MS SQL Server, for detailed editing along with Receipt Control Balancing processing and accepted
claims will be assigned claim numbers (DCN/ICN).
7) The CMS Flat Files containing the CTRD record will then be FTPed to the Cahaba Mainframe.
8) A 277HCCA Claim Acknowledgement transaction is created for each claim file processed. This data
will be sent back to the Submitter’s Directory.
9) The CMS Flat Files (837 I/P and 276 Claim Status Request) will be grouped and NDMed to the
respective Enterprise Data Center for processing.
10) Once processing is complete at the EDC, the CMS Flat Files (835 Remittance and 277 Response)
are NDMed back to the Cahaba Mainframe.
11) The CMS Flat Files are FTPed to the CEM Server for Receipt Control Balancing processing.
12) The processed CMS Flat Files will be FTPed to the FTP Server for distribution to the Submitter’s
Directory.
4.2 Transmission Administrative Procedures
•
Claim files must be received on the Secure FTP server before 3:30 p.m. CST (4:30 p.m. EST) for
complete processing to occur that business day. Files received after 3:30 p.m. CST (4:30 p.m. EST)
will be processed the following business day.
•
Please try and send claim files throughout the day instead of sending all files right before the
established cut-off time. Any large claim files should not be sent at the cut-off time because this can
result in an interruption to the end-of-day processing.
•
999 and Daily Log will be available for retrieval in your directory on the Secure FTP server within two
hours of file submission of ANSI 837 or 276 file by your Network Service Vendor (NSV).
•
Files accepted on the 999 are moved from the Secure FTP Server to the mainframe to pass through
the Common Edit Module (CEM) for additional editing.
•
The 277CA (Claim Acknowledgement) will be available for retrieval the following business day.
March 2017 ● 005010]
37
Medicare FFS Companion Guide
4.2.1
Re-transmission procedures
• CEM does perform duplicate check validation as a hash total of data within each ST-SE
(transaction set)
•
If the transaction set needs to be retransmitted due to transmission failure, change the value in
BHT02 to ‘18’ and resubmit the files; or,
•
Add or delete claims to or from the files to alter the batch so it is not the same data, then
resubmit the file(s).
4.3 Communication Protocols
Requirements for Using the FTP Server
A TCP/IP stack
An FTP executable or FTP client software
Compression software (e.g. WinZip or PKZip)
A valid EDI user ID and password assigned by Cahaba
Service through an approved Network Service Vendor
Server Specifications
Hostname: bluecmsftp.bcbsal.org
For Specific IP Addresses - Please contact EDI Services helpdesk or refer to the FTP Procedures
instructions document at www.Cahabagba.com.
Required Protocol for Data Transmission
The following connection method and clients have been verified to work with our version of
Connect: Enterprise. While other clients may also work, connectivity problems to the new server
will only be researched by the Cahaba EDI help desk if one of the following clients is used. You
will need to use the binary transport method when transferring files. SFTP clients default to the
binary transport method. To change the transport method in FTP, issue the bin command after
logging in.
SFTP: bluecmsftp.bcbsal.org

March 2017 ● 005010]
Supported clients:
o
Filezilla,
o
WS-FTP Pro
38
Medicare FFS Companion Guide
o
CuteFTP Pro
o
WinSCP
o
OpenSSH
o
Can support envelope, WSDL, SOAP and MIME.
Secure FTP client software such as CuteFTP or WS_FTP is recommended if your software does not use
scripts to perform FTP commands.
The list of approved Network Service Vendors is available on our website at
http://www.cahabagba.com/part-a/claims/electronic-data-interchange-edi/directory-of-approvedvendors/
4.4 Security Protocols
Trading Partners who conduct business with Medicare are subject to CMS security policies.
CMS’ information security policy strictly prohibits any trading partner from outsourcing system functions
to any resource located outside of the United States or its territories. Prohibited outsourced functions
include but are not limited to the transmission of electronic claims, receipt of remittance advice, or any
system access to obtain beneficiary PHI and/or eligibility information. 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. Cahaba 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 SA9) located on the CMS website
(http://www.cms.gov/informationsecurity/downloads/ARS_App_A_CMSR_HIGH.pdf.)
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. Cahaba 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
https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-InformationTechnology/InformationSecurity/Info-Security-Library-Items/ARS-30Publication.html?DLPage=1&DLEntries=10&DLSort=0&DLSortDir=ascending
March 2017 ● 005010]
39
Medicare FFS Companion Guide
•
All EDI applications must be completed online, printed, signed, and faxed to the number
provided on the application. Providers must not use their own coversheet. It is important that
the first page of the application, which contains the bar code, should be the cover page of the
fax. For further instructions on completing the application go to:
Part B (Professional)
https://www.cahabagba.com/part_b/edi/forms.htm
Part A (Institutional)
https://www.cahabagba.com/part_a/edi/forms.htm
All EDI Applications are sent via fax and received through a secured ‘filenet’ and electronically read into
the EDI System and processed. During processing of the EDI Application, logon IDs and passwords are
assigned by our Information Security department. When processing is complete an approval letter is
faxed to the fax number and contact name provided on the application.
•
Do not share passwords.
•
Submitter IDs and passwords are assigned to the entity that sent the request.
•
For DDE Access: Logon IDs and passwords are assigned to the users listed on the EDI Application.
Each user will receive a separate letter with his or her logon information.
•
EDI Transactions submitted by unauthorized Trading Partners (TPs) will not be accepted.
•
TPs should protect password privacy by limiting knowledge of the password to key personnel.
•
Passwords should be changed when there are any personnel changes.
Password requirements:
Passwords must meet the following specifications:
 Eight (8) characters long
 Include at least one (1) number , but no more than two (2)
 Include at least one (1) upper case letter
 Include at least one (1) lower case letter
 Include one (1) of the following special characters, but no more than two (2):
March 2017 ● 005010]
40
Medicare FFS Companion Guide
@, #, or $
 Characters cannot be repeated more than two (2) times
 Must change at least four (4) characters (letters, number, or special characters) of
the password each month
 Cannot be the same password used in any of the previous 12 months or last 12
passwords
 Must start with a letter (not a number or special character)
If you are unable to remember your password contact EDI Services Helpdesk at 866-582-3253 to request
a password reset.
Password duration/expiration, resetting, requirements (FISMA, Audit Security)
•
If you need to reset the password contact the EDI Services Helpdesk.
•
Currently, password duration/expiration is restricted to users who access the Part A
Processing System (FISS) to enter claims directly in to the System via Direct Data Entry (DDE)
access only. Passwords expire every 30 days and must be changed by the user. If the
password is forgotten, the user may contact the EDI Services Helpdesk at Cahaba to request
for a password reset. The user must have their 4 digit PIN when calling to request a
password reset. If the PIN is not known or lost, the user must create a new PIN and reapply
for DDE access by completing and submitting a new Part A System Access Application
located on Cahaba’s website at https://www.cahabagba.com/part_a/edi/forms.htm .
•
New passwords cannot have more than four characters in common with the previous
password, and must not be the same as any of the twelve previous passwords.
Also, if the user does not log into the FISS system after 60 days, the password will be deactivated and
cannot be reset. Therefore, the user will have to complete a new Part A System Access Application (see
above) to be reinstated under the same user ID and given a default password.
5.0 Contact information
5.1 EDI Customer Service
Part A & B: 866-582-3253
EDI Email Address:
March 2017 ● 005010]
41
Medicare FFS Companion Guide
Part A: [email protected]
Part B: [email protected]
Days/Hours of Operation: Monday – Friday, 7:00 a.m. – 4:00 p.m. CST (8:00a.m. – 5:00p.m. EST)
Link to EDI closures and holiday schedule:
http://www.cahabagba.com/part-b/claims-2/electronic-data-interchange-edi/cahaba-edi-services-callcenter-schedule/
Link to EDI frequently asked questions (FAQs):
http://www.cahabagba.com/part-b/claims-2/education-and-outreach-frequently-asked-questions2/edi/
5.2 EDI Technical Assistance
Part A & B: 866-582-3253
5.3 Provider Services
Provider Contact Center Part A and Part B: 877-567-7271
Provider Enrollment: 877-567-7271
Electronic Funds Transfer: 877-567-7271
Visit our website for other provider services contact information at:
https://www.cahabagba.com/contact.htm.
5.4 Applicable Websites / email
See sections 5.2 and 5.3 above for applicable website/email information.
6.0 Control Segments / Envelopes
Interchange Control (ISA/IEA), Function Group (GS/GE), and Transaction (ST/SE) envelopes must be used as
described in the national implementation guides. Medicare’s expectations for inbound ISAs and a description of
data on outbound ISAs are detailed in this chapter. Specific guidelines and instructions for GS and GE segments
are contained in each Transaction Information Companion Guide.
Note: Medicare 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
March 2017 ● 005010]
42
Medicare FFS Companion Guide
For Medicare FFS specific guidance refer to the appropriate Medicare FFS transaction specific edit documents
found at http://www.cms.gov/ElectronicBillingEDITrans/.
The MAC will implement Server capability to support both Message Envelope Standards and Message Exchanges {Hypertext
Transfer Protocol & Multipurpose Internet Mail Extensions (HTTP+MIME) and Simple Object Access Protocol & Web Service
Definition Language (SOAP+WSDL) Message} in accordance with the Phase II Connectivity Rule 270, which is based on the
Phase I Connectivity Rule 153. The MAC will use X.509 Client Certificates over Secure Socket Layer (SSL). This applies to the
276/277 batch transactions..
6.1 ISA-IEA
The Interchange Control Header Segment (ISA) contains information regarding the identification of an
interchange and related control segments. The ISA is always the first segment in an interchange.
Because every data element within the ISA must be filled to the maximum length, the ISA has a fixed
length.
6.1.1 Claims
Below are the envelope requirements for 837I and 837P submissions. Refer to TPI Section 8.2 to
view sample ISA and IEA segments.

The Interchange Sender ID (ISA06) must contain the assigned submitter ID followed by the
appropriate number of spaces to meet the data element requirement of 15 bytes.
Note: The Submitter ID reported in ISA06 must match the Submitter ID reported in GS02.

The Interchange ID Qualifier (ISA07) should be the mutually defined code of ZZ.

The Interchange Receiver ID (ISA08) must contain the receiver ID (left justified) followed by
the appropriate number of spaces to meet the data element requirement of 15 bytes.
Receiver IDs are applicable to line-of-business.
State
March 2017 ● 005010]
Cahaba Receiver ID
Alabama – Part A
MACJJ10101
Alabama – Part B
MACJJ10102
Georgia – Part A
MACJJ10201
Georgia – Part B
MACJJ10202
Tennessee – Part A
MACJJ10301
Tennessee – Part B
MACJJ10302
43
Medicare FFS Companion Guide
! The National Health Plan Identifier will be sent in place of the above receiver IDs once it is
implemented.

6.1.2 Remittances

6.1.3
If a vendor submits more than one interchange to the same directory on the same day
for the same submitter ID, it is advisable that there be unique interchange control
numbers in the ISA13 for each.
The Authorization Information Qualifier (ISA01) will be 03 and the Authorization
Information (ISA02) will be the Payee’s Tax Identifier.

The ISA-IEA interchange will represent a single remittance for the unique combination of
Payee NPI, Tax Identifier and line-of-business per payroll date. Therefore, an
organization that uses the same Organizational NPI and tax ID combination to submit
both professional and institutional claims, the organization will receive two separate
remittances. Effective April 1, 2012 only one receiver ID will be allowed for 835
transactions for professional claims.

All remittance data will be in uppercase regardless of the case submitted in the 837
claim.
Delimiters
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 Medicare
(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.
Delimiters – Outbound Transactions
Medicare recommends the use of the following delimiters in all outbound transactions.
Trading partners/submitters should contact their local FI, RHHI, Carrier, 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
March 2017 ● 005010]
Character Used Dec Value Hex Value
Data Element Separator
*
42
2A
Repetition Separator
^
94
5E
44
Medicare FFS Companion Guide
Delimiter
Character Used Dec Value Hex Value
Component Element Separator
Segment Terminator
:
58
3A
~<nl>
12610
7E0A
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.
6.1.3.1
Text Fields
The only special characters that should be used in free-formatted text data elements are
the hyphen (-) and the apostrophe (‘).
The usage of other special characters within text data elements in the incoming 837
transaction may cause problems with creation of subsequent transactions, including the
outbound 837 and the 835. For instance, if a colon is used within a text field the
translator may interpret the colon in the text as a delimiter which would cause the
transaction to reject back in the 999.
6.1.4 Character Sets
This general information on character sets is applicable to all transactions.

Cahaba will convert all lowercase characters submitted on an inbound 837 file to
uppercase when sending data to the processing system.

You must submit incoming 837 claim data using the basic character set as defined in
Appendix B of the 837 TR3 documents. In addition to the basic character set, you
may choose to submit lowercase characters, the apostrophe (‘) and the @ symbol
from the extended character set. Any other characters submitted from the extended
character set will cause the interchange to be rejected. Refer to TPI Section 7 for
more information about acknowledgments.
6.2 GS-GE
Functional group (GS-GE) codes are transaction specific. Therefore, information concerning the GS/GE
Functional Group Envelope can be found in the transaction specific appendices of this companion guide.
The Functional Group Header (GS) is intended to group similar transaction sets within the same
interchange. Cahaba will only process one transaction type per interchange (transmission); therefore, a
submitter must only send one GS-GE (Functional Group) within an ISA-IEA (Interchange). If multiple
functional group types (i.e. 005010x222A1 and 0005010x0214) are submitted in the same transmission,
only the first functional group will be processed. Any subsequent functional groups will be ignored.
March 2017 ● 005010]
45
Medicare FFS Companion Guide
6.2.1 Claims
Below are the functional group requirements for 837I and 837P submissions. Refer to TPI Section 8.2 to
view sample GS and GE segments.

Use the 8-character Submitter ID assigned by Cahaba in the Application Sender’s
Code (GS02) data element. The Submitter ID reported in this segment must match
the Submitter ID submitted in ISA06.

The Application Receiver’s Code (GS03) should contain the applicable receiver ID for
professional and institutional claims, and for each state (GA. AL, and TN). Refer to
TPI Section 8.2 to view a sample GS segment.

If a vendor submits more than one functional group to the same directory on the
same day, it is advisable that there be unique functional control numbers in the
GS06 in those submissions

The Application Sender’s Code (GS02) will be the contractor ID for each state for
professional and for institutional data.
6.2.2 Remittances
6.3 ST-SE
Medicare has no requirements outside the HIPAA adopted transaction implementation guides.
Refer to TPI Section 8.2 to view a sample ST segment.

If a vendor submits more than one transaction set to the same directory on the same
day for the same type of transaction, it is advisable that there be unique transaction set
control numbers in the ST02 of those transactions. This is to allow for ease in matching
the specific 277 HCCA back to its 837 counterpart since a separate 277 HCCA will not be
created for each 837.
6.4 1000A Submitter Name
The NM109 element in the Submitter Name loop should be populated with the submitter code assigned
to the biller by Cahaba.
6.5 1000B Receiver Name

March 2017 ● 005010]
The NM109 element in the Receiver Name loop should be populated with the
appropriate value from the list below:
o
10101 Alabama Part A
o
10102 Alabama Part B
o
10201 Georgia Part A
46
Medicare FFS Companion Guide
o
10202 Georgia Part B
o
10301 Tennessee Part A
o
10302 Tennessee Part B
7.0 Acknowledgements and Reports look at these
Below is a complete list of acknowledgments (both proprietary and ASC X12 formats) that may be generated
within the process of submitting an 837 file. ASC X12 transactions are explained in TPI Section 7.1 and
proprietary reports are explained in TPI Section 7.2.
This list demonstrates the order in which these acknowledgments will be created as 837 files continue through
the editing process. If files reject during the process of translating, validating or editing, the reporting process
may not continue to generate the reports that are produced later in the process. For instance, if a transaction is
rejected for compliance errors in the 999 there will not be a 277 HCCA created for that file.






Daily Log (Transmission File – Proprietary)
TA1
(Interchange Acknowledgment – ASC X12)
999
(Implementation Acknowledgment – ASC X12)
277 HCCA (Health Care Claim Acknowledgment – ASC X12)
HTTP 503 Error- Service Unavailable error message for transactions
HTTP 500 – Internal Service Error
Medicare has adopted two new acknowledgement transactions, the 999 Implementation Acknowledgment for
Health Care Insurance and the 277 Claims Acknowledgement or 277CA. These two acknowledgments will
replace proprietary reports previously provided by Cahaba.
Medicare FFS has adopted a process to only reject claim submissions that are out of compliance with the ASC
X12 version 5010 standard; the appropriate response for such errors will be returned on a 999 Implementation
Acknowledgment transaction. Batch submissions with errors will not be rejected in totality, unless warranted,
but will selectively reject the claims submitted in error within each transaction set (ST-SE segment). Thus,
Medicare FFS will reject claim submissions and return a 999 Implementation Acknowledgment transaction with
the error responses listed within the 837 Institutional or Professional Edits Spreadsheet found at
http://www.cms.gov/Medicare/Billing/MFFS5010D0/Technical-Documentation.html.
The following ASC X12 acknowledgments may be created during the process of translating, validating and
editing 837 claim files.
TA1
March 2017 ● 005010]
This segment acknowledges the interchange structure only. The 837 file does not progress to the
next step if a rejection occurs at this level. When the ISA in the 837 is in error a TA1 will be created
47
Medicare FFS Companion Guide
with only an envelope (interchange) to hold the structure errors (ISA, TA1, IEA segments only) if the
837 ISA14=1.
If the ISA passes envelope structure edits, the TA1 will be included in the envelope of the 999
acknowledgment (instead of by itself) IF the ISA14 in the 837 contains the value of 1
(1=Interchange Acknowledgment Requested).
999
The 999 contains TR3 compliance information. The 999 will be generated for Rejected (IK5*R
and/or AK9*R), Accepted (IK5*A and/or AK9*A) and Accepted with errors noted (IK5*E or AK9*E)
status.
Accepted but with errors noted status is generated when there are non-fatal implementation
errors. These will be listed as rejections in the 277 HCCA. However, permitting these ‘E’s to pass the
999 edit checking will allow partial acceptance in the 277 HCCA vs. rejecting the entire batch.
277 HCCA The Health Care Claim Acknowledgment 277 transaction will be created when an 837 file has
received an Accepted and Accepted but with errors noted status in its 999. Only Accepted claims
move immediately on to business editing.
The 277 HCCA will contain specific edit information in STC segments. STC segments will be
generated to indicate acceptance or rejection at the Information Receiver, Billing Provider, Claim or
Line Level. There may be one STC or a combination of STCs to help clarify the status of applicable
information.
ACCEPTED CLAIMS:
Claims accepted for adjudication will include a REF segment with a 1K value that will contain the
assigned Medicare claim number(s). This claim number may be used to submit a 276 Health Care
Claim Status Request to receive status on that specific claim.

Accepted claims will only have claim status information in the STC01 data element.
o
An STC segment for an accepted claim will be created as follows:
STC*A2:20*ccyymmdd*WQ*$$~
Where:
ccyymmdd is the effective date of the status information
$$ is the numeric amount of the original submitted charges

Accepted corrected bills will only have claim status information in the STC01 data element.
o
An STC segment for an accepted corrected bill will be created as follows:
STC*A0:19:PR*ccyymmdd*WQ*$$~
Where:
ccyymmdd is the effective date of the status information.
March 2017 ● 005010]
48
Medicare FFS Companion Guide
REJECTED CLAIMS:
Claims that reject in the 999 level will not generate a 277 HCCA. Claims that receive a 999
edit that reflects Accepted but with errors noted will be included in the 277 HCCA;
however, they will be rejected claims in the 277 HCCA. Allowing Accepted but with errors
noted to pass beyond the 999 edit level will accommodate partial acceptance of an entire
batch of claims.
Claims rejected in the 277 HCCA may contain more than one STC data element within an STC
segment or perhaps even multiple STC segments to help clarify the rejection.
Although the 277 HCCA is not yet listed as a covered transaction under HIPAA legislation, it
is of the same standard format and is compatible with all HIPAA requirements. For version
5010 837 files, the 999 transaction will be created for their receipt instead of the 997
transaction (created for the receipt of version 4010A1).
7.1 Report Inventory
The following proprietary reports may be created during the process of translating, validating and
editing 837 claim files.
Daily Log File
The Daily Log File is a text file log generated upon creation of the 999. One log file is generated
per transmission date. The log file is appended to throughout the day as the status of the 837
and 276 files change. The daily log file confirms receipt of the file, unzipped status, and indicates
if there are errors.
Example of Daily Log:
The file name is as follows:
[USERID].[Submission Date]
e.g. – USERID.20110101
Example of a Submitter’s Daily log file
*******************************************************************************************
*********
tgap0001.8375010.zip
March 2017 ● 005010]
Date: 01/03/2011
Time: 21:31:31
49
Medicare FFS Companion Guide
*******************************************************************************************
Unzip Results:
FILE UNZIPPED SUCCESSFULLY
**** ACCEPTED *****
*******************************************************************************************
tgap0001.8375010.clm
Date: 01/01/2011
Time: 21:31:36
*******************************************************************************************
File Level Validation:
INVALID RECEIVER ID--0099999
***** REJECTED *****
*******************************************************************************************
*****************
pgap0099.8375010.zip
Date: 01/15/2011
Time: 10:45:09
*******************************************************************************************
Unzip Results:
FILE UNABLE TO UNZIP
***** REJECTED*****
*******************************************************************************************
****************************************************************************************
tgap0003.8375010.zip
March 2017 ● 005010]
Date: 01/20/2011
Time: 10:58:05
50
Medicare FFS Companion Guide
*******************************************************************************************
******************
Unzip Results:
FILE UNZIPPED SUCCESSFULLY
***** ACCEPTED****
*******************************************************************************************
*****************
tgap0003.8375010.clm
Date: 01/20/2011
Time: 11:30:10
*******************************************************************************************
*****************
File Level Validation:
FILE WAS OF INVALID TYPE: tgap0003.8375010.clm
***** REJECTED ****
****************************************************************************************
8.0 Additional Trading Partner Information
8.1 Transmission Examples
Element
ISA06
Sender ID
GS02
1000A/NM109
March 2017 ● 005010]
51
Medicare FFS Companion Guide
Element
ISA08
Receiver ID
GS03
1000B/NM109
GS08
005010X222A1 or
005010X223A2
ST03
005010X222A1 or
005010X223A2
Interchange Sender and Receiver ID

The Interchange Sender ID data element within the ISA segment (ISA06), the Application
Sender’s Code data element within the GS segment (GS02), and the Submitter Name
(1000A loop NM109 segment) must be populated with the applicable submitter ID assigned
by Cahaba ®, LLC.

The Interchange Receiver ID data element within the ISA segment (ISA08), the Application
Receiver’s Code data element within the GS segment (GS03), and the Receiver Name
(1000B loop NM109 segment) must be populated as follows:
State

March 2017 ● 005010]
Cahaba Receiver ID
Alabama – Part A
10101
Alabama – Part B
10102
Georgia – Part A
10201
Georgia – Part B
10202
Tennessee – Part A
10301
Tennessee – Part B
10302
ISA/IEA segments are related to the entire interchange, GS/GE segments are related
to the functional group and the ST/SE segments are pertinent to the transaction.
52
Medicare FFS Companion Guide
Sample 837P ISA and Matching IEA Segments:
Position:
1
1
1
2
3
4
5
6
7
8
9
0
1
0
0
0
0
0
0
0
0
0
0
0
----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|----|
ISA*00*
*00*
*ZZ*ABCTEST1
*ZZ*00510
*010509*0930*^*00501*123456789*1*T*:~
Add spaces to the ISA data elements that do not meet length requirements.
Interchange 123456789 contains 1 Functional Group.
IEA*1*123456789~
TEST
(PRODUCTION=P)
Sample 837P GS and Matching GE Segments:
GS*HC*ABCTEST1*00510*20091231*0930*432*X*005010X222A1~
Functional Group 432 contains 1 transaction set.
GE*1*432~
Sample 837P ST and Matching SE Segments:
ST*43789*005010X222A1~
SE*117*43789~
Transaction Set 43789 contains 117 segments including the ST and 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.
Medicare FFS requires all Trading Partners to sign a Trading Partner Agreement with Cahaba. This
agreement can be found at:

Part B (Professional) https://www.cahabagba.com/part_b/edi/forms.htm

Part A (Institutional) https://www.cahabagba.com/part_a/edi/forms.htm
Additionally, Cahaba’s trading partner agreement process is identical to their EDI enrollment and
registration.
8.3 Frequently Asked Questions
Frequently asked questions can be accessed at:
March 2017 ● 005010]
53
Medicare FFS Companion Guide
http://www.cms.gov/ElectronicBillingEDITrans/
https://www.cahabagba.com/part_b/education_and_outreach/faq_edi.htm
8.4 Other Resources
E-mail Notification Service Subscription Form or Listserv:
https://www.cahabagba.com/forms/subscribeForm.htm
9. Trading Partner Information Change Summary
Version
Date
Section(s) changed
Change Summary
1.0
November 5, 2010
All
Initial Draft
2.0
January 3, 2010
All
1st Publication Version
3.0
May 16, 2012
All
Updated links, clarified
1000A and 1000B
loops.
4
May 10, 2013
All
Updated and removed
obsolete information.
5
June 27, 2013
Disclaimer
Updated links
6
July 28, 2015
All
Updated links
7
03/17/2017
All
Updated for CAQH
CORE
10. Appendices
A. 837 Institutional Claim Transaction Specific Information
http://www.cms.gov/ElectronicBillingEDITrans/Downloads/5010A2837ACG.pdf
B. 837 Professional Claim Transaction Specific Information
http://www.cms.gov/ElectronicBillingEDITrans/Downloads/5010A1837BCG.pdf
C. 276/277 Claim Status Inquiry and Response Transaction Specific Information
March 2017 ● 005010]
54
Medicare FFS Companion Guide
http://www.cms.gov/ElectronicBillingEDITrans/Downloads/5010276277CG.pdf
D. 835 Remittance Advice Transaction Specific Information
http://www.cms.gov/ElectronicBillingEDITrans/Downloads/5010A1835CG.pdf
March 2017 ● 005010]
55