Collection of Encounter Data from Medicare Advantage Organizations

_________________________________________________________________

Encounter Data System
Standard Companion Guide Transaction Information

Instructions related to the 837 Health Care Claim: Institutional
Transaction based on ASC X12 Technical Report Type 3 (TR3), Version
005010X223A2

Companion Guide Version Number: 4.0
Created: December 9, 2011

1
837 Institutional Companion Guide Version 4.0/December 9, 2011

Preface
The Encounter Data System (EDS) Companion Guide contains information to assist Medicare Advantage
Organizations (MAOs) and other entities in the submission of encounter data. The EDS Companion
Guide is under development and the information in this version reflects current decisions and will be
modified on a regular basis. All versions of the EDS Companion Guide are identified by a version number
which is located in the version control log on the last page of the document. Questions regarding the
contents of the EDS Companion Guide should be directed to [email protected].

2
837 Institutional Companion Guide Version 4.0/December 9, 2011

Table of Contents
1.0

Introduction
1.1
Scope
1.2
Overview
1.3
Major Updates
1.3.1 CAS Segment
1.3.2 Atypical Provider Default Values
1.4
References

2.0

Contact Information
2.1
CSSC
2.2
[email protected]
2.3
Applicable websites/email

3.0

File Submission
3.1
File Size Limitations
3.2
File Structure

4.0

Control segments/envelopes
4.1
ISA-IEA
4.2
GS-GE
4.3
ST-SE

5.0

Transaction Specific Information
5.1
837-I Transaction Specific Table

6.0

Acknowledgements and/or Reports
6.1
TA1
6.2
999
6.3
277CA

7.0

Front-End Edits

8.0

Duplicate Logic
8.1
Header Level
8.2
Detail Level

9.0

Institutional Business Cases – Under Development

3
837 Institutional Companion Guide Version 4.0/December 9, 2011

1.0

Introduction

1.1

Scope

The CMS Encounter Data System (EDS) Companion Guide for the 837-I transactions addresses how
MAOs and other entities conduct Institutional claim HIPAA standard electronic transactions with CMS.
CMS’ Encounter Data transaction system supports transactions adopted under HIPAA, as well as
additional supporting transactions described in this guide.
The CMS EDS Companion Guide must be used in conjunction with the associated 837-I Implementation
Guide (TR3). The instructions in the CMS EDS Companion Guide are not intended to be a stand-alone
requirements document.
1.2

Overview

The CMS EDS Companion Guide includes information needed to begin and maintain communication
exchange with CMS. The information is organized in the sections listed below:
Contact Information: This section includes telephone and fax numbers for EDS contacts.
Control Segments/Envelopes: This section contains information needed to create the ISA/IEA,
GS/GE, and ST/SE control segments for transactions to be supported by EDS.
Acknowledgements and Reports: This section contains information on all transaction
acknowledgements sent by EDS, including the TA1, 999, and 277CA.
Transaction Specific Information: This section describes how X12N Implementation Guides (IGs)
adopted under HIPAA will be detailed with the use of a table. The tables contain a row for each
segment with CMS specific information in addition to the information in the IGs. That
information can contain:
o
o
o
o
o

Limits on the repeat of loops, or segments
Limits on the length of a simple data element
Specifics on a sub-set of the IG’s internal code listings
Clarifications of the use of loops, segments, composite and simple data elements
Any other information tied directly to a loop, segment, and composite or simple data
element pertinent to trading electronically with CMS.

In addition to the row for each segment, one (1) or more additional rows are used to describe EDS’
usage for composite or simple data elements and for any other information.

4
837 Institutional Companion Guide Version 4.0/December 9, 2011

1.3

Major Updates

1.3.1

CAS Segment

MAOs and other entities were previously instructed to populate the following values to indicate an
encounter is a correction/replacement or deletion of a previously submitted encounter in the Encounter
Operational Data Store:
Loop 2300, REF01=’F8’ and REF02=ICN
Loop 2300, CLM05-3=’7’ (Correct/Replacement) or CLM05-3=’8’ (Deletion)
Loop 2320, CAS01=’CR’ (Correct/Replace) or CAS01=’OA’ (Delete), CAS02=’223’, and CAS03= the
amount affected by the correction/replacement or deletion encounter.
Upon further review of technical specifications and testing, MAOs and other entities are now instructed
to populate the following values to indicate an encounter is a correction/replacement or deletion of a
previously submitted encounter in the Encounter Operational Data Store:
Loop 2300, REF01=’F8’ and REF02=ICN
Loop 2300, CLM05-3=’7’ (Correct/Replacement) or CLM05-3=’8’ (Deletion)
NOTE: MAOs and other entities are not required to populate the CAS segment to indicate a
correction/replacement or deletion of a previously submitted encounter.
1.3.2

Atypical Provider Operational Guidance

In order to submit atypical provider encounters, it may be necessary for MAOs and other entities to
submit default values in order for the encounter to process correctly through the Encounter Data FrontEnd System and the Encounter Data Processing and Pricing System. MAOs and other entities were
previously instructed to submit specific default NPIs; however, the default NPI provided in Table 4, Loop
2010AA, NM109 should be used.
Atypical provider encounters will not be used for risk adjustment purposes, but will be stored and used
for analytic purposes.

CMS is advising MAOs and other entities that we are relaxing the requirements for the
collection of Encounter claims from Atypical providers for a period of time.
Providers who are not considered health care providers and do not provide health care services
are referred to as “atypical service providers.” Examples of atypical service providers include,
but are not limited to, Non-Emergency Transportation Providers such as Taxis, Personal Care
Attendants, Building Contractors, and Language Interpreters.
If MAOs and other entities are able to submit Atypical provider Encounter claims they may;
however, this notification is to advise that the requirement to submit such claims will be
delayed.

5
837 Institutional Companion Guide Version 4.0/December 9, 2011

1.4

References

MAOs and other entities must use the ASC X12N IG adopted under the HIPAA Administrative
Simplification Electronic Transaction rule along with CMS’ Encounter Data Participant Guides, and CMS’
EDS Companion Guidelines for development of EDS transactions. These documents are accessible at the
following:
www.csscoperations.com.
Additionally, the EDS submitter guidelines and application, testing documents, 5010 companion guides,
and Encounter Data Participant Guides can be found at that location.
MAOs and other entities must use the most current national standard code lists applicable to the 5010
transaction. The code lists may be accessed at the Washington Publishing Company (WPC) website:
http://www.wpc-edi.com
The applicable code lists are as follows:
Claim Adjustment Reason Code
Claim Status Category Codes
Claim Status Codes
CMS provides X12 5010 file format technical edit spreadsheets for the 837-I and 837-P. The edits
included in the spreadsheet are intended to clarify the WPC instructions or add Medicare specific
requirements. In order to determine the implementation date of the edits contained in the
spreadsheet, MAOs and other entities will first need to refer to the spreadsheet version. The version is
a 10 character identifier as follows:
Positions 1-2 indicate the line of business:
o EA – Part A (837-I)
o EB – Part B (837-P)
Positions 3-6 indicate the year (e.g. 2011)
Position 7 indicates the release quarter month
o 1 – January release
o 2 – April release
o 3 – July release
o 4 – October release
Positions 8-10 indicate the spreadsheet version iteration number (e.g. V01-first iteration, V02second iteration)
The effective date of the spreadsheet is the first calendar day of the release quarter month. The
implementation date is the first business Monday of the release quarter month. Federal holidays which
could potentially fall on the first business Monday must be accounted for when determining the
6
837 Institutional Companion Guide Version 4.0/December 9, 2011

implementation date. For example, the edits contained in a spreadsheet version of EB20113V01 are
effective July 1, 2011 and will be implemented on July 5, 2011.
2.0

Contact Information

2.1

The Customer Service and Support Center (CSSC)

The Customer Service and Support Center (CSSC) personnel are available for questions from 8:00A.M. –
7:00P.M. EST, Monday-Friday, with the exception of federal holidays and can be contacted at 1-877-534CSSC (2772).
2.2

Applicable websites/email

The following websites provide information to assist in EDS submission:
Resource
Encounter Data Participant
Guides
EDS Email
ANSI ASC X12 TR3
Implementation Guides
Washington Publishing Company
Health Care Code Sets
CMS Edits Spreadsheet
3.0

File Submission

3.1

File Size Limitations

Web Address
www.csscoperations.com
[email protected]
www.wpc-edi.com
www.wpc-edi.com
http://www.cms.gov/MFFS5010D0/20_TechnicalDocumentation.asp

Due to system limitations, the combination of all ST-SE transaction sets per file cannot exceed certain
thresholds depending upon the connectivity method of the submitter. FTP and NDM users cannot
exceed 85,000 encounters per file. Gentran users cannot exceed 5,000 encounters per file. For all
connectivity methods, the TR3 allows no more than 5000 CLMS per ST-SE segment. The following
demonstrates the limits due to connectivity methods:
Connectivity
FTP/NDM
Gentran

Maximum Number of
Encounters
85,000
5,000

Maximum Number of ST-SE
5,000
5,000

Note: Due to system processing overhead associated with smaller numbers of encounters within the
ST-SE, it is highly recommended that larger numbers of encounters within the ST-SE be used.
In an effort to support and provide the most efficient processing system, it is recommended that FTP
submitters’ scripts should not upload more than one (1) file per five (5) minute interval to allow
7
837 Institutional Companion Guide Version 4.0/December 9, 2011

maximum performance. Files that are zipped should contain one (1) file per transmission. MAOs and
other entities should refrain from submitting multiple files within the same transmission. NDM and
Gentran users may submit a maximum of 255 files per day.
3.2

File Structure – NDM/Connect Direct and Gentran Submitters Only

80 byte fixed block is a common mainframe term. This means every line (record) in a file must be
uploaded as 80 bytes/characters long. NDM/Connect Direct and Gentran submitters must use this
approach.
Files should be created in a manner where the segments are one continuous stream of information that
continues to the next line every 80 characters.
Segments should be stacked in the file, using only 80 characters per line. Using the Enter key or Carriage
Return in position 81 will ensure no more than 80 bytes/characters are contained in each record. If the
last line in the file does not fill to 80 bytes/characters, it should be spaced out to position 80 and then
save the file. Do not use the Enter key or Carriage Return at the end of the last record because this will
create an additional blank record at the end of the file.
For example the ISA record is 106 characters long:
The first line of the file will contain the first 80 characters of the ISA segment; the last 26 characters of
the ISA segment will be continued on the second line. The next segment will start in the 27th position
and continue until column 80.
ISA*00*
*00*
*ZZ*
ENH9999*ZZ*
4*^*00501*000000031*1*P*:~
4.0

Control Segments/Envelopes

4.1

ISA-IEA

80881*120816*114

The term interchange denotes the ISA-IEA envelope that is transmitted. Interchange control is achieved
through several “control” components, as defined in Table 2. The interchange control number is
contained in data element ISA13 of the ISA segment. The identical control number must also occur in
data element IEA02 of the IEA segment. All elements in the ISA-IEA interchange must be populated.
There are several elements within the ISA-IEA interchange that must be populated specifically for
encounter data purposes. Table 2 below provides EDS Interchange Control (ISA-IEA) specific elements.
Note: Only those elements that provide specific details relevant to encounter data are presented in
the table. When developing the encounter data system, users should base their logic on the highest
level of specificity. First, consult the WPC/TR3. Second, consult the CMS edits spreadsheets. Third,
consult the Encounter Data Companion Guide. If there are options expressed in the WPC/TR3 or the
CEM edits spreadsheet that are broader then the options identified in the Encounter Data Companion
Guide, the rules identified in the Encounter Data Companion Guide must be used.
8
837 Institutional Companion Guide Version 4.0/December 9, 2011

Legend
SHADED rows represent segments in the X12N Implementation Guide
NON-SHADED rows represent data elements in the X12N Implementation Guide
TABLE 1 – ISA-IEA INTERCHANGE ELEMENTS
Loop ID
ISA

Reference

ISA01

ISA02
ISA03

ISA04
ISA05

ISA06
ISA07

ISA08
ISA11
ISA13

Name
Interchange
Control Header
Authorization
Information
Qualifier
Authorization
Information
Security
Information
Qualifier
Security
Information
Interchange ID
Qualifier

Interchange
Sender ID
Interchange ID
Qualifier

Interchange
Receiver ID
Repetition
Separator
Interchange
Control Number

Codes

00

00

ZZ

ZZ

Notes/Comments

No authorization
information
present
Use 10 blank
spaces
No security
information
present
Use 10 blank
spaces
CMS expects to
see a value of
“ZZ” to designate
that the code is
mutually defined
EN followed by
Contract
CMS expects to
see a value of
“ZZ” to designate
that the code is
mutually defined

80881
^
Must be a fixed
length with nine
(9) characters
and match IEA02

9
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 1 – ISA-IEA INTERCHANGE ELEMENTS (CONTINUED)
Loop ID

Reference
ISA14

ISA15
IEA
IEA02

4.2

Name
Acknowledgeme
nt Requested

Usage Indicator

Codes
1

Notes/Comments
Acknowledgement
Requested
A TA1 will be sent
if the file is
syntactically
incorrect,
otherwise only a
‘999’ will be sent.
Test
Production

T
P

Interchange
Control Trailer
Interchange
Control Number

Must match the
value in ISA13.

GS-GE

The functional group is outlined by the functional group header (GS segment) and the functional group
trailer (GE segment). The functional group header starts and identifies one or more related transaction
sets and provides a control number and application identification information. The functional group
trailer defines the end of the functional group of related transaction sets and provides a count of
contained transaction sets.
All elements in the GS-GE functional group must be populated. There are several elements within the
GS-GE that must be populated specifically for encounter data collection. Table 3 provides EDS functional
group (GS-GE) specific elements.
Note: Only those elements that require explanation are presented in the table.
TABLE 2 - GS-GE FUNCTIONAL GROUP ELEMENTS
Loop ID
GS

Reference
GS02
GS03

Name
Functional Group Header
Application Sender’s
Code
Application Receiver’s
Code

Codes

Notes/Comments

80881

EN followed by
Contract
This value must
match the value
in ISA08

10
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 2 - GS-GE FUNCTIONAL GROUP ELEMENTS (CONTINUED)
Loop ID

Reference
GS06

Name
Group Control Number

GS08

Version/Release/Industry 005010X223A2
Identifier Code
Functional Group Trailer
Group Control Number

GE
GE02

4.3

Codes

Notes/Comments
This value must
match the value
in GE02

This value must
match the value
in GS06

ST-SE

The transaction set (ST-SE) contains required, situational, and unused loops, segments, and data
elements. The transaction set is outlined by the transaction set header (ST segment) and the
transaction set trailer (SE segment). The transaction set header identifies the start and identifies the
transaction set. The transaction set trailer identifies the end of the transaction set and provides a count
of the data segments, which includes the ST and SE segments. There are several elements that must be
populated specifically for encounter data purposes. Table 5 provides EDS transaction set (ST-SE) specific
elements.
Note: Only those elements that require explanation are presented in the table.
TABLE 3 - ST-SE TRANSACTION SET HEADER AND TRAILER ELEMENTS
Loop ID
ST

Reference

ST01
ST02

ST03

SE
SE01

Name
Transaction Set
Header
Transaction Set
Identifier Code
Transaction Set
Control Number

Codes

Implementation
Convention
Reference
Transaction Set
Trailer
Number of
Included
Segments

005010X223A2

Notes/Comments

837
This value must
match the value in
SE02

Must contain the
actual number of
segments within
the ST-SE
11

837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 3 - ST-SE TRANSACTION SET HEADER AND TRAILER ELEMENTS (CONTINUED)
Loop ID

5.0

Reference
SE02

Name
Transaction Set
Control Number

Codes

Notes/Comments
This value must be
match the value in
ST02

837 Institutional: Data Element Table

Within the ST-SE transaction set, there are multiple loops, segments, and data elements that provide
billing provider, subscriber, and patient level information. MAOs and other entities should reference
www.wpc-edi.com to obtain the most current Implementation Guide. EDS transactions must be
submitted using the most current transaction version.
The 837 Institutional Data Element table identifies only those elements within the X12N Implementation
Guide that require comment within the context of EDS submission. Table 6 indentifies the 837
Institutional Implementation Guide by loop name, segment name and identifier, and data element name
and identifier for cross reference. Not all data elements listed in the table below are required, but if
they are used, the table reflects the values CMS expects to see.
TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM
Loop ID

Reference
BHT
BHT03

1000A

1000A

BHT06
NM1
NM102
NM109
PER
PER03

PER05

Name
Beginning of Hierarchical
Transaction
Originator Application
Transaction Identifier
Claim Identifier
Submitter Name
Entity Type Qualifier
Submitter Identifier
Submitter EDI Contact
Information
Communication Number
Qualifier

Communication Number
Qualifier

Codes

CH

Notes/Comments

Must be a unique identifier
across all files
Chargeable

2

Non-Person Entity
EN followed by Contract
Number

TE

It is recommended that MAOs
and other entities populate
the submitter’s telephone
number
It is recommended that MAOs
and other entities populate
the submitter’s email address

EM

12
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)
Loop ID

1000B

2010AA

Reference
PER07

Name
Communication Number
Qualifier

NM1
NM102
NM103
NM109

Receiver Name
Entity Type Qualifier
Receiver Name
Receiver ID

NM1
NM108

Billing Provider Name
Billing Provider ID
Qualifier
Billing Provider Identifier

NM109

Codes
FX

2
80881

XX

N4
N403

2010AA

REF
REF01
REF02

2000B

SBR
SBR01
SBR09

Billing Provider City,
State, Zip Code
Zip Code

Billing Provider Tax
Identification Number
Reference Identification
Number
Billing Provider Tax
Identification Number
Subscriber Information
Payer Responsibility
Number Code
Claim Filing Indicator
Code

Non-Person Entity
EDSCMS
Identifies CMS as the receiver
of the transaction and
corresponds to the value in
ISA08 Interchange Receiver ID
NPI Identifier
Must be populated with a ten
digit number, must begin with
1.

1999999976
2010AA

Notes/Comments
It is recommended that MAOs
and other entities populate the
submitter’s fax number

Atypical institutional provider
default NPI

The full nine (9) digits of the
ZIP Code are required. If the
last four (4) digits of the ZIP
code are not available,
populate a default value of
“9999”.

EI

Employer’s Identification
Number (EIN)
199999997 - Atypical
institutional provider default
EIN

S

EDSCMS is considered the
destination (secondary) payer
Must be populated with a
value of MA – Medicare Part A.

MA

13
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)
Loop ID
2010BA

Reference
NM1
NM108

Name
Subscriber Name
Subscriber Id Qualifier

NM109

Subscriber Primary
Identifier

NM1
NM103
NM108

Payer Name
Payer Name
Payer ID Qualifier

2010BB

NM109
N3
N301
N4

2010BB

N401
N402
N403
REF

Payer Identification
Payer Address
Payer Address Line
Payer City, State, ZIP
Code
Payer City Name
Payer State
Payer ZIP Code
Other Payer Secondary
Identifier
Contract ID Identifier
Contract ID Number

2010BB

2010BB

REF01
REF02
2300

CLM
CLM02
CLM05-3

Claim Information
Total Claim Charge
Amount
Claim Frequency Type
Code

Codes
MI

PI

Notes/Comments
Must be populated with a
value of MI – Member
Identification Number
This is the subscriber’s Health
Insurance Claim (HIC) number.
Must match the value in Loop
2330A, NM109.
EDSCMS
Must be populated with the
value of PI – Payer
Identification

80881
7500 Security Blvd

Baltimore
MD
212441850

2U
MAO or other entities Contract
ID number

1
2
3
4
7
8

Must balance to the sum SV2
service lines in Loop 2400.
1=Original claim submission
2=Interim – First Claim
3=Interim – Continuing Claim
4=Interim – Last Claim
7=Replacement
8=Deletion

14
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)
Loop ID
2300

Reference
DTP
DTP02
DTP03

Name
Date – Admission
Date/Hour
Date Time Period Format
Qualifier
Admission Date/Hour

Codes

D8

Notes/Comments

D8=CCYYMMDD
Hours (HH) are expressed as
“00” for midnight, “01” for
1A.M., and so on through
“23” for 11P.M.
Minutes (MM) are expressed
as “00” through “59”. If the
actual minutes are not known,
use a default of “00”.
This is only required for
original or final bills.

2300

PWK
PWK01

2300

2300

Claim Supplemental
Information
Report Type Code

PWK02

Attachment
Transmission Code

CN1
CN101

Contract Information
Contract Type Code

REF

Payer Claim Control
Number
Original Reference
Number
Payer Claim Control
Number

REF01
REF02

09
AA

05

Populated for chart review
submissions only
Populated for chart review
submissions only. Available
upon request at provider site
Populated for capitated/ staff
model arrangements

F8
Identifies ICN from original
claim when submitting
adjustment or chart review
data.

15
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)
Loop ID
2320

Reference
SBR
SBR01

2320

2320

2320

2330A

SBR09

Claim Filing Indicator
Code

CAS
CAS02

Claim Adjustment
Adjustment Reason Code

AMT
AMT02

COB Payer Paid Amount
Payer Paid Amount

OI
OI03

Coverage Information
Benefits Assignment
Certification Indicator
Other Subscriber Name
Identification Code
Qualifier
Subscriber Primary
Identifier
Other Payer Name
Identification Code
Qualifier
Other Payer Primary
Identifier

NM1
NM108
NM109

2330B

Name
Other Subscriber
Information
Payer Responsibility
Sequence Number Code

NM1
NM108
NM109

Codes

P
T

16

N3
N301

P=Primary (when MAOs or
other entities populate the
payer paid amount)
T=Tertiary (when MAOs or
other entities populate a true
COB)
Health Maintenance
Organization (HMO) Medicare
Risk
If a claim is denied in the MAO
or other entities’ adjudication
system, the denial reason
should be populated.
MAO and other entity’s paid
amount
Must match the value in Loop
2300, CLM08

MI
Must match the value in Loop
2010BA, NM109
XV
MAO or other entity’s
Contract ID number.

Payer01
2330B

Notes/Comments

Other Payer Address
Other Payer Address
Line

Only populated if there is no
Contract ID available for a
true other payer
MAO or other entity’s address

16
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 4 - 837 INSTITUTIONAL HEALTH CARE CLAIM (CONTINUED)
Loop ID
2330B

2430

Reference
N4
N401

Name
Other Payer City, State,
ZIP Code
Other Payer City Name

N402
N403

Other Payer State
Other Payer ZIP Code

SVD

Line Adjudication
Information
Other Payer Primary
Identifier
Line Adjustments
Adjustment Reason Code

SVD01
2430

CAS
CAS02

6.0

Acknowledgements and Reports

6.1

TA1 – Interchange Acknowledgement

Codes

Notes/Comments

MAO or other entity’s City
Name
MAO or other entity’s State
MAO or other entity’s ZIP
Code. The full nine (9) digits
of the ZIP Code are required.
If the last four (4) digits are
not available, populate a
default value of “9999”.

Must match the value in Loop
2330B, NM109
If a service line is denied in
the MAO or other entities’
adjudication system, the
denial reason should be
populated.

The TA1 report enables the receiver to notify the sender that problems were encountered with the
interchange control structure. As the interchange envelope enters the EDFES, the EDI translator
performs TA1 validation of the control segments/envelope. You will only receive a TA1 if you have
syntax errors in your file. Errors found in this stage will cause the entire X12 interchange to be rejected
with no further processing.
MAOs and other entities will receive a TA1 interchange report acknowledging the syntactical
incorrectness of an X12 interchange header ISA and trailer IEA, and the envelope’s structure.
Encompassed in the TA1 is the interchange control number, interchange date and time, interchange
acknowledgement code, and interchange note code. The interchange control number, date, and time
are identical to those that were populated on the original 837-I or 837-P ISA line, which allows for MAOs
and other entities to associate the TA1 with a specific file previously submitted.

17
837 Institutional Companion Guide Version 4.0/December 9, 2011

Within the TA1 segment, MAOs and other entities will be able to determine if the interchange was
rejected by examining the interchange acknowledgement code (TA104) and the interchange note code
(TA105). The interchange acknowledgement code stipulates whether the interchange (ISA/IEA) rejected
due to syntactical errors. An “R” will be the value in the TA104 data element if the interchange was
rejected due to errors. The interchange note code is a numeric code that notifies MAOs and other
entities of the specific error. The TA1 interchange acknowledgment report is generated and returned
within 24 hours after submitting the interchange if a fatal error occurs. If a TA1 interchange control
structure error is identified, MAOs and other entities must correct the error and resubmit the
interchange file.
6.2

999 – Functional Group Acknowledgement

After the interchange passes the TA1 edits, the next stage of editing is to apply Implementation Guide
(IG) edits and verify the syntactical correctness of the functional group(s) (GS/GE). Functional groups
allow for like data to be organized within an interchange; therefore, more than one (1) functional group
with multiple claims within the functional group can be populated in a file. The 999 acknowledgement
report provides information on the validation of the GS/GE functional group(s) and their consistency
with the data contained. The 999 report provides MAOs and other entities information on whether the
functional group(s) were accepted or rejected.
If a file has multiple GS/GE segments and errors occurred at any point within one of the syntactical and
IG level edit validations, the GS/GE segment will be rejected, and processing will continue to the next
GS/GE segment. For instance, if a file is submitted with three (3) functional groups and the second
functional group encounters errors, the first functional group will be accepted the second functional
group will be rejected and processing will continue to the third functional group.
The 999 transaction set is designed to report on adherence to IG level edits and CMS standard syntax
errors as depicted in the CMS edit spreadsheet. Three (3) possible acknowledgement values are:
“A” – Accepted
“R” – Rejected
“E” – Accepted with non-syntactical errors
When viewing the 999 report, MAOs and other entities should navigate to the IK5 and AK9 segments. If
an “A” is displayed in the IK5 and AK9 segments, the claim file is accepted and will continue processing.
If an “R” is displayed in the IK5 and AK9 segments, an IK3 and an IK4 segments will be displayed. These
segments indicate what loops and segments contain the error that needs correcting so the interchange
can be resubmitted. The third element in the IK3 segment tells the loop that contains the error. The
first element in the IK3 and IK4 indicate the segment and element that contain the error. The third
element in the IK4 segment indicates the reason code for the error.

18
837 Institutional Companion Guide Version 4.0/December 9, 2011

6.3

277CA – Claim Acknowledgement

After the file is accepted at the interchange and functional group levels, the third level of editing occurs
at the transaction set level within the CEM in order to create the Claim Acknowledgement Transaction
(277CA) report. The CEM checks the validity of the values within the data elements. For instance, data
element N403 must be a valid nine (9) digit zip code. If a non-existent zip code is populated, the CEM
will reject the encounter. The 277CA is an unsolicited acknowledgement report from CMS to MAOs and
other entities.
The 277CA is used to acknowledge the acceptance or rejection of encounters submitted using a
hierarchical level (HL) structure. The first level of hierarchical editing is at the Information Source level.
This entity is the decision maker in the business transaction receiving the X12 837 transactions
(EDSCMS).The next level is at the Information Receiver level. This is the entity that expects the response
from the Information Source. The third hierarchal level is at the Billing Provider of Service level and the
fourth and final level is done at the Patient level. Acceptance or rejection at this level is based on the
WPC and the CMS edits spreadsheet. Edits received at any hierarchical level will stop and no further
editing will take place. For example, if there is a problem with the Billing Provider of Service submitted
on the 837, individual patient edits will not be performed. For those encounters not accepted, the
277CA will detail additional actions required of MAOs and other entities in order to correct and resubmit
those encounters.
If an MAO or other entity receives a 277CA indicating an encounter was rejected, the MAO or other
entity must resubmit the encounter until the 277CA indicates no errors were found.
If an encounter is accepted, the 277CA will provide the ICN assigned to that encounter. The ICN
segment for the accepted encounter will be located in 2200D REF segment, REF01=IK and REF02=ICN.
The ICN is a unique 13-digit number.
If an encounter is rejected, the 277CA will provide edit information in the STC segment. The STC03 data
element will convey whether the HL structures accepted or rejected. The STC03 is populated with a
value of “WQ”, if the HL was accepted. If the STC03 data element is populated with a value of “U”, the
HL is rejected and the STC01 data element will list the acknowledgement code.
7.0

Permanently Deactivated Front-End Edits

Several CEM edits that are currently active in the Fee-For-Service CEM edits spreadsheet will be
permanently deactivated in order to ensure syntactically correct encounters pass front-edit editing.
Table 5 provides the current EDS front-end edits that will be deactivated. The edit reference column
provides the exact edit reference that will be deactivated. The edit description column provides the
Claim Status Category Code (CSCC), the Claim Status Code (CSC), and the Entity Identifier Code (EIC),
when applicable. The notes column provides a description of the edit reason. MAOs and other entities
should reference the WPC website at www.wpc-edi.com for a complete listing of all CSCC, CSC, and EICs.

19
837 Institutional Companion Guide Version 4.0/December 9, 2011

TABLE 5 - 837 INSTITUTIONAL PERMANENTLY DEACTIVATED CEM EDITS
Edit Reference
Edit Description
X223.084.2010AA.NM109.050 CSCC A8: “Acknowledgement/rejected
for relational field in error”
CSC 496: “Submitter not approved for
electronic claim submission on behalf
of this entity””
EIC 85: “Billing Provider”
X223.087.2010AA.N301.070
CSCC A7: “Acknowledgement/rejected
for invalid information”
CSC 503: “Entity’s Street Address”
EIC 85: Billing Provider
X223.127.2010BB.REF.010

X223.424.2400.SV202-7.025

8.0

CSCC A7: “Acknowledgement/rejected
for invalid information”
CSC 732: “Information inconsistent
with billing guidelines”
CSC 560: “Entity’s
Additional/Secondary Identifier”
EIC: PR “Payer”
CSCC A8: “Acknowledgement/rejected
for relational field in error”
CSC 306: Detailed description of
service

Edit Notes
2010AA.NM109 billing provider
must be “associated” to the
submitter (from a trading partner
management perspective) in
1000A.NM109.
2010AA.N301 must not contain the
following exact phrases (not case
sensitive): "Post Office Box", "P.O.
BOX", "PO BOX", "LOCK BOX",
"LOCK BIN", "P O BOX".
Non-VA claims: 2010BB.REF with
REF01=”2U”, “EI”, “FY”, or “NF”
must not be present. VA claims:
2010BB.REF with REF01=”EI”, “FY”,
or “NF” must not be present.

2400.SV202-7 must be present
when 2400.SV202-2 contains a
non-specific procedure code.

Duplicate Logic

In order to ensure encounters submitted are not duplicates of encounters previously submitted, header,
and detail level duplicate checking will be performed. If the header and/or detail level duplicate
checking determines the file is a duplicate, the file will be rejected as a duplicate, and an error report
will be returned to the submitter.
8.1

Header Level

When a file (ISA – IEA) is received, the system assigns a hash total to the file based on the entire ISA-IEA
interchange. Hash totals are a method for ensuring the accuracy of processed data. The hash total is a
total of several fields or data in a file, including fields not normally used in calculations, such as account
number. At various stages in the processing, the hash total is recalculated and compared with the
original. If a file comes in later in a different submission or a different submission of the same file, and
gets the same hash total, it will be rejected as a duplicate. There will be other duplicate edits in the
processing system.
20
837 Institutional Companion Guide Version 4.0/December 9, 2011

8.2

Detail Level

Once an encounter passes through the institutional or professional processing and pricing system, it is
stored in an internal repository, the Encounter Operational Data Store (EODS). If a new encounter is
submitted that matches specific values to another stored encounter, the encounter will be rejected and
will be considered a duplicate encounter. The encounter will be returned to the submitter with an error
message identifying it as a duplicate encounter. Currently the following values are the minimum set of
items being used for matching an encounter in the EODS:
Beneficiary Demographic
o Health Insurance Claim Number (HICN)
o Name
Date of Service
Type of Bill (TOB)
Procedure Code(s)
Billing Provider NPI
Paid Amount*
* The Paid Amount is the amount paid by the MAO or other entity and should be populated in Loop
ID-2320, AMT02.

21
837 Institutional Companion Guide Version 4.0/December 9, 2011

9.0

837 Institutional Business Cases – Under Development

The business cases will present business cases for data contained within the 837-I claim:

22
837 Institutional Companion Guide Version 4.0/December 9, 2011

REVISION HISTORY
Version

Date

2.1

9/9/2011

Description of Revision
Baseline Version

3.0

11/16/2011 Release 1

4.0

12/2/2011

4.0

12/2/2011

4.0

12/2/2011

4.0

12/2/2011

Section 3.0 – Added the maximum number of files
Gentran and NDM users may submit in per day
Section 7.0 – Added “Front-End Edits” section

4.0

12/2/2011

Section 8.0 – Changed to “Duplicate Logic”

Section 1.3.2 – Added atypical provider operational
guidance
Section 1.4 – Corrected www.wpc-edi.com reference

23
837 Institutional Companion Guide Version 4.0/December 9, 2011