Collection of Encounter Data from Medicare Advantage Organizations

_________________________________________________________________

Encounter Data System
Standard Companion Guide Transaction Information

Instructions related to the 837 Health Care Claim: Durable Medical
Equipment (DME) Supplier Professional Transaction based on ASC X12
Technical Report Type 3 (TR3), Version 005010X222A1

Companion Guide Version Number: 22.0
Created: May 2014

837 DME Professional Companion Guide Version 22.0/May 2014

1

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. Users should
verify that they are using the most current version.
Questions regarding the contents of the EDS Companion Guide should be directed to
[email protected].

837 DME Professional Companion Guide Version 22.0/May 2014

2

Table of Contents
1.0

Introduction
1.1
Scope
1.2
Overview
1.3
Major Updates
1.3.1 EDS Acronyms
1.4
References

2.0

Contact Information
2.1
CSSC
2.2
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-P (DME) Transaction Specific Table

6.0

Acknowledgements and/or Reports
6.1
TA1
6.2
999
6.3
277CA
6.4
MAO-001 – Encounter Data Duplicates Report
6.5
MAO-002 – Encounter Data Processing Status Report
6.6
Reports File Naming Conventions
6.6.1 Testing
6.6.2 Production
6.7
EDFES Notifications

7.0

Front-End Edits
7.1
Deactivated Front-End Edits
7.2
Temporarily Deactivated Front-End Edits

8.0

Duplicate Logic
8.1
Header Level
8.2
Detail Level

837 DME Professional Companion Guide Version 22.0/May 2014

3

Table of Contents
9.0

Business Cases
9.1
DME Supplier Encounter – Oxygen Rental
9.2
DME Supplier Encounter – Capped Rental – Wheelchair
9.3
DME Supplier Encounter – Purchase – Portable Toilet
9.4
DME Supplier Encounter – Prosthetic
9.5
DME Supplier Encounter – Tub Rail
9.6
DME Supplier Encounter – Parenteral

10.0

Encounter Data DME Processing and Pricing System Edits
10.1 EDDPPS Enhancements Implementation Dates
10.2 EDPS Edits Prevention and Resolution Strategies
10.2.1 EDPS Edits Prevention and Resolution Strategies – Phase I
10.2.2 EDPS Edits Prevention and Resolution Strategies – Phase II
10.2.3 EDPS Edits Prevention and Resolution Strategies – Phase III

11.0

DME Supplier vs. Incident to Services Submission

12.0

Submission of Default Data in a Limited Set of Circumstances
12.1 Default Data Reason Codes

13.0

Tier II Testing

14.0

EDS Acronyms

837 DME Professional Companion Guide Version 22.0/May 2014

4

1.0

Introduction

1.1

Scope

The CMS Encounter Data System (EDS) 837-P DME Companion Guide addresses how MAOs and other
entities conduct Professional DME supplier claims Health Information Portability and Accountability Act
(HIPAA) standard electronic transactions with CMS. The CMS EDS supports transactions adopted under
HIPAA, as well as additional supporting transactions described in this guide.
The CMS EDS 837-P DME Companion Guide must be used in conjunction with the associated 837-P
Implementation Guide (TR3) and the Encounter Data Front-End System (EDFES) CEM Edits Spreadsheets.
The instructions in the CMS EDS 837-P DME Companion Guide are not intended for use as a stand-alone
requirements document.
1.2

Overview

The CMS EDS 837-P DME Companion Guide includes information required to initiate and maintain
communication exchange with CMS. The information is organized in the sections listed below:
•

Contact Information: Includes telephone numbers and email addresses for EDS contacts.

•

Control Segments/Envelopes: Contains information required to create the ISA/IEA, GS/GE, and
ST/SE control segments in order for the EDS to support these transactions.

•

Acknowledgements and Reports: Contains information for all transaction acknowledgements
and reports sent by EDS.

•

Transaction Specific Information: Describes the details of the HIPAA X12N Implementation
Guides (IGs), using a tabular format. The tables contain a row for each segment with CMS and
IG specific information. That information may contain:
o

Limits on the repeat of loops or segments

o

Limits on the length of a simple data element

o

Specifics on a sub-set of the IG’s internal code listings

o

Clarification of the use of loops, segments, and composite or simple data elements

o

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 describe the EDS’ usage for
composite or simple data elements and for any other information.

837 DME Professional Companion Guide Version 22.0/May 2014

5

1.3 Major Updates
1.3.1

EDS Acronyms

MAOs and other entities may reference Section 14.0, Table 19 for additional acronyms frequently used
by the EDS.
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 EDS
Companion Guidelines, for development of EDS’ transactions. These documents are accessible on the
CSSC Operations website at www.csscoperations.com.
Additionally, CMS publishes the EDS’ submitter guidelines and application, testing documents, 837 EDS
Companion Guides and Encounter Data Participant Guides on the CSSC Operations website.
MAOs and other entities must use the most current national standard code lists applicable to the 5010
transaction. The code lists is accessible at the Washington Publishing Company (WPC) website at
http://www.wpc-edi.com
The applicable code lists are as follows:
• Claim Adjustment Reason Code (CARC)
• Claim Status Category Codes (CSSC)
• Claim Status Codes (CSC)
CMS provides X12 5010 file format technical edit spreadsheets for the 837-P and 837-I. The edits
included in the spreadsheets are provided 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 should initially refer to the spreadsheet version identifier. The
version identifier is comprised of ten (10) characters 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 that
potentially occur on the first business Monday are considered when determining the implementation
837 DME Professional Companion Guide Version 22.0/May 2014

6

date. For example, the edits contained in a spreadsheet version of EB20113V01 are effective July 1,
2011 and 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-877534-CSSC (2772) or by email at [email protected].
2.2

Applicable Websites/Email Resources

The following websites provide information to assist in EDS submission:
RESOURCE
EDPS Bulletin
EDS Inbox
EDS Participant Guides
EDS User Group Materials
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
http://www.csscoperations.com/
[email protected]
http://www.csscoperations.com/
http://www.csscoperations.com/
http://www.wpc-edi.com/
http://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, dependent upon the connectivity method of the submitter. FTP and NDM users cannot
exceed 85,000 encounters per file. Gentran/TIBCO 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
table demonstrates the limits due to connectivity methods:
CONNECTIVITY
FTP/NDM
Gentran/TIBCO

MAXIMUM NUMBER OF
ENCOUNTERS
85,000
5,000

MAXIMUM NUMBER OF
ENCOUNTERS PER 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 MAOs and other entities submit larger numbers of encounters
within the ST/SE, not to exceed 5,000 encounters.
In an effort to support and provide the most efficient processing system, and to allow for maximum
performance, CMS recommends that FTP submitters’ scripts upload no more than one (1) file per five (5)
minute intervals. Zipped files should contain one (1) file per transmission. MAOs and other entities
837 DME Professional Companion Guide Version 22.0/May 2014

7

should refrain from submitting multiple files within the same transmission. NDM and Gentran/TIBCO
users may submit a maximum of 255 files per day.
3.2

File Structure – NDM/Connect:Direct and Gentran/TIBCO Submitters Only

NDM/Connect Direct and Gentran/TIBCO submitters must format all submitted files in an 80-byte fixed
block format. This means MAOs and other entities must upload every line (record) in a file with a length
of 80 bytes/characters.
Submitters should create files with segments stacked, using only 80 characters per line. At position 81
of each segment, MAOs and other entities must create a new line. On the new line starting in position
1, continue for 80 characters, and repeat creating a new line in position 81 until the file is complete. If
the last line in the file does not fill to 80 characters, the submitter should space the line out to position
80 and then save the file.
Note: If MAOs and other entities are using a text editor to create the file, pressing the Enter key will
create a new line. If MAOs and other entities are using an automated system to create the file, create a
new line by using a CRLF (Carriage Return Line Feed) or a LF (Line Feed).
For example the ISA record is 106 characters long:
ISA*00*
*00*
*ZZ*ENH9999
4*^*00501*000000031*1*P*:~

*ZZ*80887

*120430*114

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.
Note to NDM/Connect:Direct Users: If a submitter has not established a sufficient number of
Generated Data Groups (GDGs) to accommodate the number of files returned from the EDFES, not all of
the EDFES Acknowledgement reports will be stored in the submitter’s system. To prevent this situation,
NDM/ Connect:Direct submitters should establish a limit of 255 GDGs in their internal systems.
4.0

Control Segments/Envelopes

4.1

ISA/IEA

The term interchange denotes the transmitted ISA/IEA envelope. Interchange control is achieved
through several “control” components, as defined in Table 1. 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. MAOs and other entities must populate all elements in the
ISA/IEA interchange. There are several elements within the ISA/IEA interchange that must be populated
specifically for encounter data purposes. Table 1 provides EDS Interchange Control (ISA/IEA) specific
elements.
Note: Table 1 presents only those elements that provide specific details relevant to encounter data.
When developing the encounter data system, users should base their logic on the highest level of

837 DME Professional Companion Guide Version 22.0/May 2014

8

specificity. First, consult the WPC/TR3. Second, consult the CMS edits spreadsheets. Third, consult the
CMS EDS 837-P Companion Guide. If the options expressed in the WPC/TR3 or the CEM edits
spreadsheet are broader than the options identified in the CMS EDS 837-P Companion Guide, MAOs and
other entities must use the rules identified in the Companion Guide.
Legend
SHADED rows represent segments in the X12N Implementation Guide
NON-SHADED rows represent data elements in the X12N Implementation Guide

LOOP ID
ISA

REFERENCE
ISA01
ISA02
ISA03
ISA04
ISA05

ISA05

ISA06
ISA07

ISA08
ISA
ISA11
ISA13

ISA14

TABLE 1 – ISA/IEA INTERCHANGE ELEMENTS
NAME
CODES
NOTES/COMMENTS
Interchange Control Header
Authorization Information
00
No authorization information present
Qualifier
Authorization Information
Use 10 blank spaces
Security Information Qualifier
00
No security information present
Security Information
Use 10 blank spaces
Interchange ID Qualifier
ZZ
CMS expects to see a value of “ZZ” to
designate that the code is mutually
defined
Interchange ID Qualifier
ZZ
CMS expects to see a value of “ZZ” to
designate that the code is mutually
defined
Interchange Sender ID
EN followed by Contract ID Number
Interchange ID Qualifier
ZZ
CMS expects to see a value of “ZZ” to
designate that the code is mutually
defined
Interchange Receiver ID
80887
Interchange Control Header
Repetition Separator
^
Interchange Control Number
Must be a fixed length with nine (9)
characters and match IEA02.

Acknowledgement Requested

1

Used to identify file level duplicate
collectively with GS06, ST02, and BHT03.
Interchange Acknowledgement Requested
(TA1)
A TA1 will be sent if the file is syntactically
incorrect, otherwise only a ‘999’ will be
sent.

837 DME Professional Companion Guide Version 22.0/May 2014

9

LOOP ID

REFERENCE
ISA15

IEA
IEA02
4.2

TABLE 1 – ISA/IEA INTERCHANGE ELEMENTS (CONTINUED)
NAME
CODES
NOTES/COMMENTS
Usage Indicator
T
Test
P
Production
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.
MAOs and other entities must populate elements in the GS/GE functional group. There are several
elements within the GS/GE that must be populated specifically for encounter data collection. Table 2
provides EDS functional group (GS/GE) specific elements.
Note: Table 2 presents only those elements that require explanation.

LOOP ID

REFERENCE

GS
GS02

TABLE 2 - GS/GE FUNCTIONAL GROUP ELEMENTS
NAME
CODES
NOTES/COMMENTS
Functional Group Header
Application Sender’s Code
EN followed by Contract ID
Number

GS03

Application Receiver’s Code

GS06

Group Control Number

80887

This value must match the value
in ISA06
This value must match the value
in ISA08
This value must match the value
in GE02
Used to identify file level
duplicates collectively with ISA13,
ST02, and BHT03

GS08
GE
GE02

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

005010X222A1

837 DME Professional Companion Guide Version 22.0/May 2014

This value must match the value
in GS06

10

4.3

ST/SE

The transaction set (ST/SE) contains required, situational loops, 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 3 provides EDS’ transaction set (ST/SE)
specific elements.
Note: Table 3 presents only those elements that require explanation.

LOOP ID
ST

TABLE 3 - ST/SE TRANSACTION SET HEADER AND TRAILER ELEMENTS
REFERENCE
NAME
CODES
NOTES/COMMENTS
Transaction Set Header
ST01
Transaction Set Identifier Code
837
ST02
Transaction Set Control Number
This value must match the value
in SE02
Used to identify file level
duplicates collectively with
ISA13, GS06, and BHT03
ST03

SE01

Implementation Convention
Reference
Transaction Set Trailer
Number of Included Segments

SE02

Transaction Set Control Number

SE

5.0

Transaction Specific Information

5.1

837 Professional: Data Element Table

005010X222A1

Must contain the actual number
of segments within the ST/SE
This value must be match the
value in ST02

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. MAOs and other entities must
submit EDS transactions using the most current transaction version.
The 837 Professional (DME) Data Element table identifies only those elements within the X12N
Implementation Guide that require comment within the context of EDS’ submission. Table 4 identifies
the 837 Professional Implementation Guide by loop name, segment name, segment identifier, data
element name, and data element identifier for cross reference. Not all of the data elements listed in
Table 4 are required; but if they are used, the table reflects the values CMS expects to see.

837 DME Professional Companion Guide Version 22.0/May 2014

11

LOOP ID

REFERENCE
BHT
BHT03

1000A

1000A

BHT06
NM1
NM102
NM109
PER

Claim Identifier
Submitter Name
Entity Type Qualifier
Submitter Identifier
Submitter EDI Contact
Information
Communication Number
Qualifier

CH

PER05

Communication Number
Qualifier

EM

PER07

Communication Number
Qualifier

FX

NM1
NM102
NM103
NM109

Receiver Name
Entity Type Qualifier
Receiver Name
Receiver ID

NM1
NM108
NM109

Billing Provider Name
Billing Provider ID Qualifier
Billing Provider Identifier

N4

Billing Provider City, State,
Zip Code
Zip Code

PER03

1000B

2010AA

2010AA

TABLE 4 - 837 PROFESSIONAL HEALTH CARE CLAIM
NAME
CODES
NOTES/COMMENTS
Beginning of Hierarchical
Transaction
Originator Application
Must be a unique identifier across all
Transaction Identifier
files

N403

Used to identify file level duplicates
collectively with ISA13, GS06, and ST02
Chargeable

2

Non-Person Entity
EN followed by Contract ID 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
It is recommended that MAOs and
other entities populate the submitter’s
fax number

2
80887

XX
1999999992

837 DME Professional Companion Guide Version 22.0/May 2014

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 the number 1
DME provider default NPI when the
provider has not been assigned an 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 “9998”
12

LOOP ID
2010AA

2000B

2010BA

TABLE 4 - 837 PROFESSIONAL HEALTH CARE CLAIM (CONTINUED)
REFERENCE
NAME
CODES
NOTES/COMMENTS
REF
Billing Provider Tax
Identification
REF01
Reference Identification
EI
Employer’s Identification Number
Qualifier
REF02
Reference Identification
199999999
DME provider default EIN
SBR
Subscriber Information
SBR01
Payer Responsibility Number
S
EDSCMS is considered the destination
Code
(secondary) payer
SBR09
Claim Filing Indicator Code
MB
Must be populated with a value of MB –
Medicare Part B
NM1
Subscriber Name
NM108
Subscriber ID Qualifier
MI
Must be populated with a value of MI –
Member Identification Number
NM109
Subscriber Primary Identifier
This is the subscriber’s Health Insurance
Claim (HIC) number.
Must match the value in Loop 2330A,
NM109

2010BB

2010BB

2010BB

2010BB

2300

NM1
NM103
NM108

Payer Name
Payer Name
Payer ID Qualifier

NM109
N3
N301

Payer Identification
Payer Address
Payer Address Line

N4
N401
N402
N403
REF
REF01
REF02

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

CLM
CLM02
CLM05-3

Claim Information
Total Claim Charge Amount
Claim Frequency Type Code

PI

EDSCMS
Must be populated with the value of PI –
Payer Identification

80887
7500 Security
Blvd
Baltimore
MD
212441850

2U

837 DME Professional Companion Guide Version 22.0/May 2014

MAO or other entity’s Contract ID
Number

1
7
8

1=Original claim submission
7=Replacement
8=Deletion
13

LOOP ID
2300

TABLE 4 - 837 PROFESSIONAL HEALTH CARE CLAIM (CONTINUED)
REFERENCE
NAME
CODES
NOTES/COMMENTS
PWK
Claim Supplemental
Information
PWK01
Report Type Code
09
Populated for chart review submissions
only

PWK02
2300
2300

2300

CN1
CN101
REF
REF01
REF02
REF
REF01
REF02

Attachment Transmission
Code
Contract Information
Contract Type Code
Payer Claim Control Number
Original Reference Number
Payer Claim Control Number
Medical Record Number
Medical Record
Identification Number
Medical Record
Identification Number

OZ

Populated for encounters generated as a
result of paper claims only

PY

Populated for encounters generated as a
result of 4010 claims only
Populated for chart review, paper
generated encounters, or 4010 claims

AA

05
F8

Identifies ICN from original claim when
submitting adjustment or chart review
EA
8

Deleted
Diagnosis
Code(s)

2320

2320
2320

CAS
CAS02

Claim Adjustment
Adjustment Reason Code

AMT
AMT02
OI
OI03

COB Payer Paid Amount
Payer Paid Amount
Coverage Information
Benefits Assignment
Certification Indicator

Populated for capitated arrangements

837 DME Professional Companion Guide Version 22.0/May 2014

Chart review delete diagnosis code
submission only – Identifies the
diagnosis code populated in Loop 2300,
HI must be deleted from the encounter
ICN in Loop 2300, REF02
Chart review add and delete diagnosis
code submission only – Identifies
diagnosis code(s) that must be deleted
from the encounter ICN in Loop 2300,
REF02
If a claim is denied in the MAO or other
entity’s adjudication system, the denial
reason must be populated
MAO and other entity’s paid amount
Must match the value in Loop 2300,
CLM08
14

LOOP ID
2330A

2330B

TABLE 4 - 837 PROFESSIONAL HEALTH CARE CLAIM (CONTINUED)
REFERENCE
NAME
CODES
NOTES/COMMENTS
NM1
Other Subscriber Name
NM108
Identification Code Qualifier MI
NM109
Subscriber Primary Identifier
Must match the value in Loop 2010BA,
NM109
NM1
Other Payer Name
NM108
Identification Code Qualifier XV
NM109
Other Payer Primary
Payer01
MAO or other entity’s Contract ID
Identifier
Number
Only populated if there is no Contract ID
Number available for a true other payer

2330B
2330B

N3
N301
N4

2400

N401
N402
N403
PWK

PWK01
PWK02

2400

2430

CN1
CN101

Contract Information
Contract Type Code

SVD

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

SVD01
2430

Other Payer Address
Other Payer Address Line
Other Payer City, State, ZIP
Code
Other Payer City Name
Other Payer State
Other Payer ZIP Code
Durable Medical Equipment
Certificate of Medical
Necessity Indicator
Attachment Report Type
Code
Attachment Transmission
Code

CAS
CAS02

MAO or other entity’s address

MAO or other entity’s City Name
MAO or other entity’s State.
MAO or other entity’s ZIP Code

CT
NS

Not Specified – Paperwork is available on
request
MAOs and other entities must not
submit supplemental forms

05

Populated for each capitated/staff
service line

837 DME Professional Companion Guide Version 22.0/May 2014

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

15

LOOP ID
2430

TABLE 4 - 837 PROFESSIONAL HEALTH CARE CLAIM (CONTINUED)
REFERENCE
NAME
CODES
NOTES/COMMENTS
DTP
Line Check or Remittance
Date
DTP03
Populate the claim receipt date minus
one (1) day as the default primary payer
adjudication date only in the instance
that the primary payer adjudication date
is not available

6.0

Acknowledgements and/or Reports

6.1

TA1 – Interchange Acknowledgement

The TA1 report enables the receiver to notify the sender when there are problems with the interchange
control structure. As the interchange envelope enters the EDFES, the EDI translator performs TA1
validation of the control segments/envelope. The sender will only receive a TA1 if there are syntax
errors in the file. Errors found in this stage will cause the entire X12 interchange to reject with no
further processing.
MAOs and other entities will receive a TA1 interchange report acknowledging the syntactical inaccuracy
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
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.
Within the TA1 segment, MAOs and other entities will be able to determine if the interchange 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 rejected due to
errors. The interchange note code is a numeric code that notifies MAOs and other entities of the
specific error. If a fatal error occurs, the EDFES generates and returns the TA1 interchange
acknowledgement report within 24 hours of the interchange submission. 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 organization of like data 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 the consistency of
837 DME Professional Companion Guide Version 22.0/May 2014

16

the data. 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 reject, and processing will continue to the next GS/GE
segment. For instance, if a file is submitted with three (3) functional groups and there are errors in the
second functional group, the first functional group will accept, the second functional group will reject,
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
“P” - Partially Accepted, At Least One Transaction Set Was Rejected

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 segment 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 identifies the loop that contains the error.
The first element in the IK3 and IK4 indicates the segment and element that contain the error. The third
element in the IK4 segment indicates the reason code for the error.
6.3

277CA – Claim Acknowledgement

After the file accepts 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 expecting 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

837 DME Professional Companion Guide Version 22.0/May 2014

17

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 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 rejects, 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 rejects and the STC01 data element will list the acknowledgement code.
6.4

MAO-001 – Encounter Data Duplicates Report

When the MAO-002 Encounter Data Processing Status Report is returned to an MAO or other entity, and
contains edit 98325 – Service Line(s) Duplicated, the EDPS will also generate and return the MAO-001
Encounter Data Duplicates Report. MAOs and other entities will not receive the MAO-001 report if
there are no duplicate errors received on submitted encounters.
The MAO-001 report is a fixed length report available in flat file and formatted report layouts. It
provides information for encounters and service lines that receive a status of “reject” and the specific
error message of 98325 – Service Line(s) Duplicated. MAOs and other entities must correct and
resubmit all encounters and/or service lines for edit 98325. The MAO-001 report allows MAOs and
other entities the opportunity to more easily reconcile these duplicate encounters and service lines.
6.5

MAO-002 – Encounter Data Processing Status Report

After a file accepts through the EDFES, the file is transmitted to the Encounter Data Processing System
(EDPS) where further editing, processing, pricing, and storage occurs. As a result of EDPS editing, the
EDPS will return the MAO-002 – Encounter Data Processing Status Report.
The MAO-002 report is a fixed length report available in flat file and formatted report layouts that
provide encounter and service line level information. The MAO-002 reflects two (2) statuses at the
encounter and service line level: “accepted” and “rejected”. Lines that reflect a status of “accept” yet
contain an error message in the Edit Description column are considered “informational” edits. MAOs
and other entities are not required to take further action on “informational” edits.
The ‘000’ line on the MAO-002 report identifies the header level and indicates either “accepted” or
“rejected” status. If the ‘000’ header line is rejected, the encounter is considered rejected and MAOs
and other entities must correct and resubmit the encounter. If the ‘000’ header line is “accepted” and
at least one (1) other line (i.e., 001 002 003 004) is accepted, then the overall encounter is accepted.
837 DME Professional Companion Guide Version 22.0/May 2014

18

6.6

Reports File Naming Conventions

In order for MAOs and other entities to receive and identify the EDFES acknowledge reports (TA1, 999,
and 277CA) and EDPS MAO-002 Encounter Data Processing Status Report, specific reports file naming
conventions have been used. The file name ensures that the specific reports are appropriately
distributed to each secure, unique mailbox. The EDFES and EDPS have established unique file naming
conventions for reports distributed during testing and production.
6.6.1

Testing Reports File Naming Convention

Table 5 provides the EDFES reports file naming conventions according to connectivity method. MAOs
and other entities should note that Connect:Direct (NDM) users’ reports file naming conventions are
user defined.
REPORT TYPE
EDFES Notifications
TA1
999
999
277CA

TABLE 5 – TESTING EDFES REPORTS FILE NAMING CONVENTIONS
GENTRAN/TIBCO MAILBOX
FTP MAILBOX
T.xxxxx.EDS_RESPONSE.pn
RSPxxxxx.RSP.REJECTED_ID
T.xxxxx.EDS_REJT_IC_ISAIEA.pn
X12xxxxx.X12.TMMDDCCYYHHMMS
T.xxxxx.EDS_REJT_FUNCT_TRANS.pn
999#####.999.999
T.xxxxx.EDS_ACCPT_FUNCT_TRANS.pn
999#####.999.999
T.xxxxx.EDS_RESP_CLAIM_NUM.pn
RSPxxxxx.RSP_277CA

Table 6 provides the EDPS reports file naming convention by connectivity method. MAOs and other
entities should note that Connect:Direct (NDM) users’ reports file naming conventions are user defined.
TABLE 6 – TESTING EDPS REPORTS FILE NAMING CONVENTIONS
CONNECTIVITY
METHOD
GENTRAN/
TIBCO

FTP

TESTING NAMING CONVENTION
FORMATTED REPORT
T .xxxxx.EDPS_001_DataDuplicate_Rpt
T.xxxxx.EDPS_002_DataProcessingStatus_Rpt
T .xxxxx.EDPS_004_RiskFilter_Rpt
T.xxxxx.EDPS_005_DispositionSummary_Rpt
T .xxxxx.EDPS_006_EditDisposition_Rpt
T .xxxxx.EDPS_007_DispositionDetail_Rpt
RPTxxxxx.RPT.EDPS_001_DATDUP_RPT
RPTxxxxx.RPT.EDPS_002_DATPRS_RPT
RPTxxxxx.RPT.EDPS_004_RSKFLT_RPT
RPTxxxxx.RPT.EDPS_005_DSPSUM_RPT
RPTxxxxx.RPT.EDPS_006_EDTDSP_RPT
RPTxxxxx.RPT.EDPS_007_DSTDTL_RPT

TESTING NAMING CONVENTION
FLAT FILE LAYOUT
T .xxxxx.EDPS_001_DataDuplicate_File
T.xxxxx.EDPS_002_DataProcessingStatus_File
T .xxxxx.EDPS_004_RiskFilter_File
T.xxxxx.EDPS_005_DispositionSummary_ File
T .xxxxx.EDPS_006_EditDisposition_ File
T .xxxxx.EDPS_007_DispositionDetail_ File
RPTxxxxx.RPT.EDPS_001_DATDUP_File
RPTxxxxx.RPT.EDPS_002_DATPRS_File
RPTxxxxx.RPT.EDPS_004_RSKFLT_ File
RPTxxxxx.RPT.EDPS_005_DSPSUM_ File
RPTxxxxx.RPT.EDPS_006_EDTDSP_ File
RPTxxxxx.RPT.EDPS_007_DSTDTL_ File

Table 7 provides a description of the file name components, which will assist MAOs and other entities in
identifying the report type.

837 DME Professional Companion Guide Version 22.0/May 2014

19

TABLE 7 –FILE NAME COMPONENT DESCRIPTION
FILE NAME
COMPONENT
RSPxxxxx
X12xxxxx
TMMDDCCYYHHMMS
999xxxxx
RPTxxxxx
EDPS_XXX
XXXXXXX
RPT/FILE
6.6.2

DESCRIPTION
The type of data ‘RSP’ and a sequential number assigned by the server ‘xxxxx’
The type of data ‘X12’ and a sequential number assigned by the server ‘xxxxx’
The Date and Time stamp the file was processed
The type of data ‘999’ and a sequential number assigned by the server ‘xxxxx’
The type of data ‘RPT’ and a sequential number assigned by the server ‘xxxxx’
Identifies the specific EDPS Report along with the report number (i.e., ‘002’, etc.)
Seven (7) characters available to be used as a short description of the contents of the file
Identifies if the file is a formatted report ‘RPT’ or a flat file ‘FILE’ layout

Production Reports File Naming Convention

A different production reports file naming convention is used so that MAOs and other entities may easily
identify reports generated and distributed during production. Table 8 provides the reports file naming
conventions per connectivity method for production reports.
TABLE 8 – PRODUCTION EDFES REPORTS FILE NAMING CONVENTIONS
REPORT TYPE
GENTRAN/TIBCO MAILBOX
FTP MAILBOX
EDFES Notifications
P.xxxxx.EDS_RESPONSE.pn
RSPxxxxx.RSP.REJECTED_ID
TA1
P.xxxxx.EDS_REJT_IC_ISAIEA.pn
X12xxxxx.X12.TMMDDCCYYHHMMS
999
P.xxxxx.EDS_REJT_FUNCT_TRANS.pn
999#####.999.999
999
P.xxxxx.EDS_ACCPT_FUNCT_TRANS.pn
999#####.999.999
277CA
P.xxxxx.EDS_RESP_CLAIM_NUM.pn
RSPxxxxx.RSP_277CA
Table 9 provides the production EDPS reports file naming conventions per connectivity method.
TABLE 9 – PRODUCTION EDPS REPORTS FILE NAMING CONVENTIONS
CONNECTIVITY
METHOD
GENTRAN/
TIBCO

FTP

PRODUCTION NAMING CONVENTION
FORMATTED REPORT
P.xxxxx.EDPS_001_DataDuplicate_Rpt
P.xxxxx.EDPS_002_DataProcessingStatus_Rpt
P.xxxxx.EDPS_004_RiskFilter_Rpt
P.xxxxx.EDPS_005_DispositionSummary_Rpt
P.xxxxx.EDPS_006_EditDisposition_Rpt
P.xxxxx.EDPS_007_DispositionDetail_Rpt
RPTxxxxx.RPT.PROD_001_DATDUP_RPT
RPTxxxxx.RPT.PROD_002_DATPRS_RPT
RPTxxxxx.RPT.PROD_004_RSKFLT_RPT
RPTxxxxx.RPT.PROD_005_DSPSUM_RPT
RPTxxxxx.RPT.PROD_006_EDTDSP_RPT
RPTxxxxx.RPT.PROD_007_DSTDTL_RPT

837 DME Professional Companion Guide Version 22.0/May 2014

PRODUCTION NAMING CONVENTION
FLAT FILE LAYOUT
P.xxxxx.EDPS_001_DataDuplicate_File
P.xxxxx.EDPS_002_DataProcessingStatus_File
P.xxxxx.EDPS_004_RiskFilter_File
P.xxxxx.EDPS_005_DispositionSummary_ File
P.xxxxx.EDPS_006_EditDisposition_ File
P.xxxxx.EDPS_007_DispositionDetail_ File
RPTxxxxx.RPT.PROD_001_DATDUP_File
RPTxxxxx.RPT.PROD_002_DATPRS_File
RPTxxxxx.RPT.PROD_004_RSKFLT_ File
RPTxxxxx.RPT.PROD_005_DSPSUM_ File
RPTxxxxx.RPT.PROD_006_EDTDSP_ File
RPTxxxxx.RPT.PROD_007_DSTDTL_ File

20

6.7

EDFES Notifications

The EDFES distributes special notifications to submitters when encounters have been processed by the
EDFES, but will not proceed to the EDPS for further processing. These notifications are distributed to
MAOs and other entities, in addition to standard EDFES Acknowledgement Reports (TA1, 999, and
277CA) in order to avoid returned, unprocessed files from the EDS.
Table 10 provides the file type, EDFES notification message, and EDFES notification message description.
The file has an 80 character record length and contains the following record layout:
1. File Name Record
a. Positions 1 – 7 = Blank Spaces
b. Positions 8 – 18 = File Name:
c. Positions 19 – 62 = Name of the Saved File
d. Positions 63 – 80 = Blank Spaces
2. File Control Record
a. Positions 1 – 4 = Blank Spaces
b. Positions 5 – 18 = File Control:
c. Positions 19 – 27 = File Control Number
d. Positions 28 – 80 = Blank Spaces
3. File Count Record
a. Positions 1 – 18 = Number of Claims:
b. Positions 19 – 24 = File Claim Count
c. Positions 25 – 80 = Blank Spaces
4. File Separator Record
a. Positions 1 – 80 = Separator (----------)
5. File Message Record
a. Positions 1 – 80 = FILE WAS NOT SENT TO THE EDPS BACK-END PROCESS FOR THE
FOLLOWING REASON(S)
6. File Message Records
a. Positions 1 – 80 = File Message
The report format example is as follows:
FILE NAME: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
FILE CONTROL: XXXXXXXXX
NUMBER OF CLAIMS: 99,999
FILE WAS NOT SENT TO THE EDPS BACK-END PROCESS FOR THE FOLLOWING REASON(S)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

837 DME Professional Companion Guide Version 22.0/May 2014

21

TABLE 10 – EDFES NOTIFICATIONS
APPLIES TO

ENCOUNTER
TYPE

All files submitted

All

All files submitted

All

All files submitted

All

All files submitted

All

All files submitted

All

Production files
submitted

All

Tier 2 file submitted

All

Tier 2 file submitted

All

DME End-to-End Testing
- PACE
DME End-to-End Testing
– File 1

DME
DME

NOTIFICATION MESSAGE
FILE ID (XXXXXXXXX) IS A
DUPLICATE OF A FILE ID SENT
WITHIN THE LAST 12 MONTHS
SUBMITTER NOT AUTHORIZED TO
SEND CLAIMS FOR PLAN
(CONTRACT ID)
PLAN ID CANNOT BE THE SAME AS
THE SUBMITTER ID
AT LEAST ONE ENCOUNTER IS
MISSING A CONTRACT ID IN THE
2010BB-REF02 SEGMENT

NOTIFICATION MESSAGE
DESCRIPTION
The file ID must be unique for a 12
month period
The submitter is not authorized to
send for this plan
The Contract ID cannot be the
same as the Submitter ID
The Contract ID is missing

SUBMITTER NOT CERTIFIED FOR
PRODUCTION
THE INTERCHANGE USAGE
INDICATOR MUST EQUAL ‘T’
PLAN (CONTRACT ID) HAS (X,XXX)
CLAIMS IN THIS FILE. ONLY 2,000
ARE ALLOWED
FILE CANNOT CONTAIN MORE
THAN 8 ENCOUNTERS
FILE CAN ONLY CONTAIN FILE 1
ENCOUNTERS

The submitter must be front-end
certified to send encounters for
validation or production
The submitter must be certified to
send encounters for production
The Professional Tier II file is being
sent with a ‘P’ in the ISA15 field
The number of encounters for a
Contract ID cannot be greater than
2,000
The number of encounters cannot
be greater than 8
The test cases from file 1 and Files
2 or 3 cannot be in the same file

SUBMITTER NOT FRONT-END
CERTIFIED

DME End-to-End Testing
– File 1

DME

FILE CANNOT CONTAIN MORE
THAN 10 ENCOUNTERS

The number of encounters cannot
be greater than 10

DME End-to-End Testing
– File 2

DME

FILE CANNOT CONTAIN MORE
THAN 2 ENCOUNTERS

The number of encounters cannot
be greater than 2

DME End-to-End Testing
– File 3

DME

FILE CANNOT CONTAIN MORE
THAN 2 ENCOUNTERS

The number of encounters cannot
be greater than 2

DME End-to-End Testing
– File 3

DME

CANNOT SEND TEST CASE 7 UNTIL
AN MAO-002 REPORT HAS BEEN
RECEIVED FOR FILE 1

The MAO-002 report must be
received before File 3 can be
submitted

DME End-to-End Testing
– File 3

DME

FILE CAN ONLY CONTAIN TEST CASE
7 ENCOUNTERS

The test cases in File 3 can only be
test case 7 Encounters

All

PATIENT CONTROL NUMBER IS
MORE THAN 20 CHARACTERS LONG
THE TC# WAS TRUNCATED

The Claim Control Number,
including the Test Case Number,
must not exceed 20 characters

All

FILE CONTAINS (X) TEST CASE (X)
ENCOUNTER(S)

The file must contain two (2) of
each test case

End-to-End Testing – File
1
End-to-End Testing –
Additional File(s)
End-to-End Testing – File
1

837 DME Professional Companion Guide Version 22.0/May 2014

22

APPLIES TO
End-to-End Testing –
Additional File(s)
All files submitted
All files submitted
All files submitted
Test

7.0

TABLE 10 – EDFES NOTIFICATIONS (CONTINUED)
ENCOUNTER
NOTIFICATION MESSAGE
NOTIFICATION MESSAGE
TYPE
DESCRIPTION
ADDITIONAL FILES CANNOT BE
The MAO-002 report must be
All
VALIDATED UNTIL AN MAO-002
received before additional files can
REPORT HAS BEEN RECEIVED
be submitted
DATE OF SERVICE CANNOT BE
Files cannot be submitted with a
All
BEFORE 2011
date of service before 2011
TRANSACTION SET (ST/SE)
There can only be 5,000 claims in
All
(XXXXXXXXX) CANNOT EXCEED
each ST/SE Loop
5,000 CLAIMS
FILE CANNOT EXCEED 85,000
The maximum number of
All
ENCOUNTERS
encounters allowed in a file
This file was processed with the
NO TEST CASES FOUND IN THIS
Interchange Indicator = ‘T’ and the
All
FILE
Submitter was not yet Front-End
Certified

Front-End Edits

CMS provides a list of the edits used to process all encounters submitted to the EDFES. The Fee-forService (FFS) Professional CEM Edits Spreadsheet identifies active and deactivated edits for MAOs and
other entities to reference for programming their internal systems and reconciling EDFES
Acknowledgement Reports. The edits for Professional DME submission are identified in the column
labeled “CEDI”.
The Professional CEM Edits Spreadsheet provides documentation regarding edit rules that explain how
to identify an EDFES edit and the associated logic. The Professional CEM Edits Spreadsheet also provides
a change log that lists the revision history for edit updates.
MAOs and other entities are able to access the Professional CEM Edits Spreadsheet on the CMS website
at https://www.cms.gov/Medicare/Billing/MFFS5010D0/Technical-Documentation.html and on the
CSSC Operations website at:
http://www.csscoperations.com/internet/cssc3.nsf/docsCat/CSSC~CSSC%20Operations~Encounter%20
Data~Resources?open&expand=1&navmenu=Encounter^Data||.
7.1

Deactivated Front-End Edits

Several CEM edits currently active in the FFS Professional CEM edits spreadsheet will be deactivated in
order to ensure that syntactically correct encounters pass front-edit editing. Table 11 provides a list of
the deactivated EDFESCEM edits. The edit reference column provides the exact reference for the
deactivated edits. 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 CSCCs and CSCs.

837 DME Professional Companion Guide Version 22.0/May 2014

23

Note: The EDFES has deactivated all DME translator and CEM level edits pertaining to balancing. The
deactivated balancing edits are now included in Table 11.
TABLE 11 – 837-P DME DEACTIVATED FRONT-END EDITS
EDIT REFERENCE
EDIT DESCRIPTION
EDIT NOTES
X222.087.2010AA.NM109.030 CSCC A7: "Acknowledgement /Rejected Valid NPI Crosswalk must be available for this
for Invalid Information…"
edit.
CSC 562: "Entity's National Provider
Identifier (NPI)"
EIC: 85 Billing Provider
X222.087.2010AA.NM109.050 CSCC A8: "Acknowledgement /
This Fee for Service edit validates the NPI and
X222.140.2010BB.REF02.075
Rejected for relational field in error"
submitter ID number to ensure the submitter is
CSC 496 "Submitter not approved for
authorized to submit on the provider’s behalf.
electronic claim submissions on behalf Encounter data cannot use this validation as
of this entity."
we validate the plan number and submitter ID
EIC: 85 Billing Provider
to ensure the submitter is authorized to submit
on the plans behalf.
X222.091.2010AA.N301.070
CSCC A7: "Acknowledgement /Rejected Remove edit check for 2010AA N3 P O Box
X222.091.2010AA.N302.060
for Invalid Information…"
variations when ISA08 = 80882 (Professional
CSC 503: "Entity's Street Address"
payer code).
EIC: 85 Billing Provider
X222.094.2010AA.REF02.040
CSCC A7: "Acknowledgement /Rejected 2010AA.REF02 must be nine digits with no
for Invalid Information…"
punctuation.
CSC 128: "Entity's tax id"
EIC: 85 Billing Provider
X222.094.2010AA.REF02.050
CSCC A8: "Acknowledgement /
Valid NPI Crosswalk must be available for this
Rejected for relational field in error"
edit.
CSC 562: "Entity's National Provider
Identifier (NPI)"
CSC 128: "Entity's tax id"
EIC: 85 Billing Provider
X222.116.2000B.SBR03.004
CSCC A8: Acknowledgement/Rejected
X222.116.2000B.SBR03.006
for relational field in error
CSC 163: Entity's Policy Number
CSC 732: Information submitted
inconsistent with billing guidelines
EIC IL: Subscriber
X222.116.2000B.SBR04.005
CSCC A8: Acknowledgement/Rejected
X222.116.2000B.SBR04.007
for relational field in error
CSC 663: Entity's Group Name
CSC 732: Information submitted
inconsistent with billing guidelines
EIC IL: Subscriber

837 DME Professional Companion Guide Version 22.0/May 2014

24

TABLE 11 – 837-P DME DEACTIVATED FRONT-END EDITS (CONTINUED)
EDIT REFERENCE
EDIT DESCRIPTION
EDIT NOTES
X222.138.2010BB.REF.010
CSCC A7: "Acknowledgement /Rejected
This REF Segment is used to capture the Plan
for Invalid Information…"
number, as this is unique to Encounter
CSC 732: "Information submitted
Submission only. The CEM has the following
inconsistent with billing guidelines."
logic that is applied:
CSC 560: "Entity's Additional/Secondary Non-VA claims: 2010BB.REF with REF01 =
Identifier."
"2U", "EI", "FY" or "NF" must not be present.
EIC: PR "Payer"
VA claims: 2010BB.REF with REF01 = "EI", "FY"
or "NF" must not be present.
This edit needs to remain off in order for the
submitter to send in his plan number.
X222.157.2300.CLM02.020
IK403 = 6: "Invalid Character in Data
2300.CLM02 must be numeric.
Element"
X222.157.2300.CLM05-3.020

CSCC A7: "Acknowledgement /Rejected
for Invalid Information…"
CSC 535: "Claim Frequency Code"

X222.196.2300.REF.010

CSCC A7: "Acknowledgement /Rejected
for Invalid Information…"
CSC 732: "Information submitted
inconsistent with billing guidelines."
CSC 464: "Payer Assigned Claim Control
Number."

X222.262.2310B.NM109.030

CSCC A7: "Acknowledgement /Rejected
for Invalid Information…"
CSC 562: "Entity's National Provider
Identifier (NPI)"
EIC: 82 Rendering Provider
"CSCC A8: ""Acknowledgement /
Rejected for relational field in error""
CSC 306 Detailed description of service"
2400.SV101-7 must be present when
2400.SV101-2 is present on the table of
procedure codes that require a
description.

X222.351.2400.SV101-7.020

X222.430.2420A.NM109.030

X222.480.2430.SVD02.020

CSCC A7: "Acknowledgement /Rejected
for Invalid Information…"
CSC 562: "Entity's National Provider
Identifier (NPI)"
EIC 82 "Rendering Provider"
IK403 = 6: Invalid Character in Data
Element

837 DME Professional Companion Guide Version 22.0/May 2014

Fee for Service does not allow a claim to come
in with a frequency type other than 1 (Original
Claim). This Edit is turned off for Encounter so
that submitters can submit a frequency type =
7 Replacement and frequency type = 8
Deletion
Fee for service does not allow a REF segment
containing a claim control number to be used
when sending a corrected (Frequency type =
7) or deleted (Frequency type = 8) claim.
2300.REF with REF01 = "F8" must not be
present. This edit needs to remain off in order
for the submitter to send the claim control
number they are trying to correct or delete.
Valid NPI Crosswalk must be available for this
edit.

When using a not otherwise classified or
generic HCPCS procedure code the CEM is
editing for a more descriptive meaning of the
procedure code. For example, the submitter is
using J3490. The description for this HCPCS is
Not Otherwise Classified (NOC) Code. CMS
has made a decision not to price claims with
these types of codes.
2420A.NM109 must be a valid NPI on the
Crosswalk when evaluated with
1000B.NM109.

25

7.2

Temporarily Deactivated Front-End Edits

Table 12 provides a list of the temporarily deactivated EDFES DME CEM balancing edits in order to
ensure that encounters that require balancing of monetary fields will pass front-end editing.
Note: The DME edits listed in Table 12 are not all-inclusive and are subject to amendment.
TABLE 12 – 837-P DME TEMPORARILY DEACTIVATED CEM EDITS
EDIT REFERENCE
X222.157.2300.CLM02.070

EDIT DESCRIPTION
CSCC A7: "Acknowledgement/Rejected
for Invalid Information…"
CSC 178: "Submitted Charges"

EDIT NOTES
2300.CLM02 must equal the sum of all
2400.SV102 amounts.

X222.157.2300.CLM02.090

CSCC A7: "Acknowledgement /Rejected
for Invalid Information…"
CSC 400: "Claim is out of Balance"
CSC 672: "Payer's payment information
is out of balance"
CSCC A7: Acknowledgement/Rejected
for Invalid Information
CSC 41: Special handling required at
payer site
CSC 286: Other Payer's Explanation of
Benefits/payment information
CSC 732: Information submitted
inconsistent with billing guidelines
CSCC A7: "Acknowledgement/Rejected
for Invalid Information…"
CSC 672: "Other Payer's payment
information is out of balance"
CSC 286: Other payer's Explanation of
Benefits/payment information

2300.CLM02 must equal the sum of all 2320 &
2430 CAS amounts and the 2320 AMT02
(AMT01=D).

CSCC A7: "Acknowledgement/Rejected
for Invalid Information…"
CSC 400: "Claim is out of balance:
CSC 583:"Line Item Charge Amount"
CSC 643: "Service Line Paid Amount"

SV102 must = the sum of all payer amounts
paid found in 2430 SVD02 and the sum of all
line adjustments found in 2430 CAS
Adjustment Amounts.

X222.305.2320.AMT.040

X222.305.2320.AMT02.060

X222.351.2400.SV102.060

8.0

2320 AMT02 must = the sum of all existing
2430.SVD02 payer paid amounts (when the
value in 2430.SVD01 is the same as the value
in 2330B.NM109) minus the sum of all claim
level adjustments (2320 CAS adjustment
amounts) for the same payer.
NOTE: Perform this edit only when 2430SVD
segments are present for this 2320-2330x
iteration's payer.

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 that determines the file is a duplicate, the file will reject, and an error report will be returned
to the submitter.

837 DME Professional Companion Guide Version 22.0/May 2014

26

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. The EDS uses hash totals to ensure 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 the
account number. At various stages in 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 reject as a duplicate.
In addition to the hash total, the system also references the values collectively populated in ISA13, GS06,
ST02, and BHT03. If two (2) files are submitted with the exact same values populated as a previously
submitted and accepted file, the file will be considered a duplicate and the error message CSCC - A8 =
Acknowledgement / Rejected for relational field in error, CSC -746 = Duplicate Submission will be
provided on the 277CA.
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 on another stored encounter, the encounter will be rejected and
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
Place of Service (2 digits)
Type of Service – not submitted on the 837-P, but is derived from data captured
Procedure Code(s) and 4 modifiers
Rendering Provider NPI
Paid Amount*

* Paid Amount is the amount paid by the MAO or other entity and should be populated in Loop ID-2320,
AMT02.

837 DME Professional Companion Guide Version 22.0/May 2014

27

9.0

837-P DME Business Cases

In accordance with 45 CFR 160.103 of the HIPAA, Protected Health Information (PHI) has been removed
from all business cases. As a result, the business cases have been populated with fictitious information
about the Subscriber, MAO and provider(s). The business cases reflect 2012 dates of service.
Although the business cases are provided as examples of possible encounter submissions, MAOs and
other entities must populate valid data in order to successfully pass translator and CEM level editing.
MAOs and other entities should direct questions regarding the contents of the EDS Test Case
Specifications to [email protected].
Note: The business cases identified in the CMS EDS 837-P DME Companion Guide indicate paid amounts
and DTP segments at the line level.
The Adjudication or Payment Date (DTP 573 segment) must follow the paid amount. For example, if the
paid amount is populated at the claim level, the DTP 573 segment must be populated at the claim
level. If the paid amount is populated at the line level, the DTP 573 segment must be populated at the
line level.

837 DME Professional Companion Guide Version 22.0/May 2014

28

9.1

DME Supplier Encounter – Oxygen Services

Business Scenario 1: Mary Dough is the patient and the subscriber and went to Dr. Shannon Wilson,
who prescribed Mary Dough with oxygen service rental from Oxygen Supply Company due to chronic
airway obstruction. Happy Health Plan is the MAO.

File String 1:
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80887
*120430*114
4*^*00501*200000031*1*P*:~
GS*HC*ENH9999*80887*20120430*1144*69*X*005010X222A1~
ST*837*0534*005010X222A1~
BHT*0019*00*3920394930206*20120428*1615*CH~
NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~
PER*IC*JANE DOE*TE*5555552222~
NM1*40*2*EDSCMS*****46*80887~
HL*1**20*1~
NM1*85*2*OXYGEN SUPPLY COMPANY*****XX*1299999999~
N3*123 BREATH DRIVE~
N4*NORFOLK*VA*235149999~
REF*EI*344232321~
PER*IC*BETTY SMITH*TE*9195551111~
HL*2*1*22*0~
SBR*S*18*XYZ1234567**47****MB~
NM1*IL*1*DOUGH*MARY****MI*672148306~
N3*1234 STATE DRIVE~
N4*NORFOLK*VA*235099999~
DMG*D8*19390807*F~
NM1*PR*2*EDSCMS*****PI*80887~
N3*7500 SECURITY BLVD~
N4*BALTIMORE*MD*212441850~
REF*2U*H9999~
CLM*2997677856479709654A*260.12***11:B:1*Y*A*Y*Y~
HI*BK:496*BF:51881~
SBR*P*18*XYZ1234567******16~
AMT*D*260.12~
OI***Y***Y~
NM1*IL*1*DOUGH*MARY****MI*672148306~
N3*1234 STATE DRIVE~
N4*NORFOLK*VA*235099999~
NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~
N3*705 E HUGH ST~
N4*NORFOLK*VA*235049999~
REF*T4*Y~
LX*1~
SV1*HC:E1390:RR*230.55*UN*1***1:2~
837 DME Professional Companion Guide Version 22.0/May 2014

29

PWK*CT*NS~
CR3*I*MO*99~
DTP*472*RD8*20120401-20120430~
DTP*463*D8*2012022212~
SVD*H9999*230.55*HC:E1390:RR*1~
DTP*573*D8*20120514~
LX*2~
SV1*HC:E0431:RR*29.57*UN*1***1:2~
PWK*CT*NS~
CR3*I*MO*99~
DTP*472*RD8*20120401-20120430~
DTP*463*D8*2012022212~
SVD*H9999*29.57*HC:E0431:RR**1~
DTP*573*D8*20120514~
SE*50*0534~
GE*1*69~
IEA*1*200000031~

837 DME Professional Companion Guide Version 22.0/May 2014

30

9.2

DME Supplier Encounter – Capped Rental – Wheelchair

Business Scenario 2: John Smith is the patient and the subscriber and went to Dr. Jim Fortune, who
prescribed John Smith with a powered wheelchair rental from Scooter Rehab Store due to a stroke,
which caused paralysis. Happy Health Plan is the MAO.

File String 2:
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80887
*120430*114
4*^*00501*200000331*1*P*:~
GS*HC*ENH9999*80887*20120430*1144*34*X*005010X222A1~
ST*837*0535*005010X222A1~
BHT*0019*00*4897574384904*20120428*1615*CH~
NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~
PER*IC*JANE DOE*TE*5555552222~
NM1*40*2*EDSCMS*****46*80887~
HL*1**20*1~
NM1*85*2*SCOOTER REHAB STORE*****XX*1239999999~
N3*456 TRAVEL DRIVE~
N4*NORFOLK*VA*235159999~
REF*EI*809845839~
PER*IC*BETTY SMITH*TE*9195551111~
HL*2*1*22*0~
NM1*DK*1*FORTUNE*JIM****XX*1234589999~
N3*1518 STATE PARK AVENUE~
N4*VIRGINIA BEACH*VA*234539999~
SBR*S*18*XYZ1234567**47****MB~
NM1*IL*1*SMITH*JOHN****MI*6459482938~
N3*1234 STATE DRIVE~
N4*NORFOLK*VA*235099999~
DMG*D8*19460806*M~
NM1*PR*2*EDSCMS*****PI*80887~
N3*7500 SECURITY BLVD~
N4*BALTIMORE*MD*212441850~
REF*2U*H9999~
CLM*2997677886479709654A*378.12***11:B:1*Y*A*Y*Y~
HI*BK:436*BF:3449~
SBR*P*18*XYZ1234567******16~
AMT*D*378.12~
OI***Y***Y~
NM1*IL*1*SMITH*JOHN****MI*6459482938~
N3*1234 STATE DRIVE~
N4*NORFOLK*VA*235099999~
NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~
N3*705 E HUGH ST~
N4*NORFOLK*VA*235049999~
837 DME Professional Companion Guide Version 22.0/May 2014

31

REF*T4*Y~
LX*1~
SV1*HC:K0010:RR:BR:KH*378.12*UN*1***1:2~
PWK*CT*NS~
CR3*I*MO*99~
DTP*472*RD8*20120401-20120430~
DTP*463*D8*2012022212~
SVD*H9999*378.12*HC:K0010:RR:BR:KH**1~
DTP*573*D8*20120514~
SE*42*0535~
GE*1*34~
IEA*1*200000331~

837 DME Professional Companion Guide Version 22.0/May 2014

32

9.3

DME Supplier Encounter – Purchase – Portable Toilet

Business Scenario 3: Jasmine Connors is the patient and the subscriber and went to Dr. Martin
Stevenson, who prescribed Jasmine Connors with a commode chair from the Loucks Family
Medical Supply due to a broken back. Happy Health Plan is the MAO.
File String 3:
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80887
*120430*114
4*^*00501*200000631*1*P*:~
GS*HC*ENH9999*80887*20120430*1144*98*X*005010X222A1~
ST*837*8876*005010X222A1~
BHT*0019*00*4897574384905*20120428*1615*CH~
NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~
PER*IC*JANE DOE*TE*5555552222~
NM1*40*2*EDSCMS*****46*80887~
HL*1**20*1~
NM1*85*2*LOUCKS FAMILY MEDICAL SUPPLY*****XX*1239999999~
N3*459 TRAVEL DRIVE~
N4*NORFOLK*VA*235199999~
REF*EI*809845838~
PER*IC*BETTY SMITH*TE*9195551111~
HL*2*1*22*0~
SBR*S*18*XYZ1234567**47****MB~
NM1*IL*1*CONNORS*JASMINE****MI*6459472938~
N3*1234 STATE DRIVE~
N4*NORFOLK*VA*235099999~
DMG*D8*19430812*F~
NM1*PR*2*EDSCMS*****PI*80887~
N3*7500 SECURITY BLVD~
N4*BALTIMORE*MD*212441850~
REF*2U*H9999~
CLM*2997877886479709654A*158.98***11:B:1*Y*A*Y*Y~
HI*BK:8058~
SBR*P*18*XYZ1234567******16~
AMT*D*158.98~
OI***Y***Y~
NM1*IL*1*CONNORS*JASMINE****MI*6459472938~
N3*1235 STATE DRIVE~
N4*NORFOLK*VA*235099999~
NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~
N3*705 E HUGH ST~
N4*NORFOLK*VA*235049999~
REF*T4*Y~
LX*1~
SV1*HC:E0170:RR:KX*158.98*UN*1***1~
837 DME Professional Companion Guide Version 22.0/May 2014

33

PWK*CT*NS~
DTP*472*D8*20120403~
DTP*463*D8*2012022212~
CR3*I*MO*99~
SVD*H9999*158.98*HC:E0170:RR:KX**1~
DTP*573*D8*20120514~
SE*42*8876~
GE*1*98~
IEA*1*200000631~

837 DME Professional Companion Guide Version 22.0/May 2014

34

9.4

DME Supplier Encounter – Prosthetic Device

Business Scenario 4: Kelly Anderson is the patient and the subscriber and went to Dr. James
Washington, who prescribed Kelly Anderson with a below the knee leg prosthesis from Doctor’s
Choice due to an auto accident, which was conditionally covered. Happy Health Plan is the
MAO.
File String 4:
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80887
*120530*114
7*^*00501*200000931*1*P*:~
GS*HC*ENH9999*80887*20120530*1147*98*X*005010X222A1~
ST*837*0567*005010X222A1~
BHT*0019*00*3920394830206*20120530*1147*CH~
NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~
PER*IC*JANE DOE*TE*5555552222~
NM1*40*2*EDSCMS*****46*80887~
HL*1**20*1~
NM1*85*2*DOCTORS CHOICE*****XX*1299999799~
N3*129 DOCTOR DRIVE~
N4*NORFOLK*VA*235189999~
REF*EI*456769032~
PER*IC*BETTY SMITH*TE*9195551111~
HL*2*1*22*0~
SBR*S*18*XYZ1234567**47****MB~
NM1*IL*1*ANDERSON*KELLY****MI*672248306~
N3*1237 STATE DRIVE~
N4*NORFOLK*VA*235099999~
DMG*D8*19401224*F~
NM1*PR*2*EDSCMS*****PI*80887~
N3*7500 SECURITY BLVD~
N4*BALTIMORE*MD*212441850~
REF*2U*H9999~
CLM*2997677858479709654A*2245.89***11:B:1*Y*A*Y*Y~
HI*BK:V4975~
SBR*P*18*XYZ1234567******16~
AMT*D*2245.89~
OI***Y***Y~
NM1*IL*1*ANDERSON*KELLY****MI*672248306~
N3*1237 STATE DRIVE~
N4*NORFOLK*VA*235099999~
NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~
N3*705 E HUGH ST~
N4*NORFOLK*VA*235049999~
REF*T4*Y~
LX*1~
837 DME Professional Companion Guide Version 22.0/May 2014

35

SV1*HC:L5105:RR*2245.89*UN*1***1~
PWK*CT*NS~
CR3*I*MO*99~
DTP*472*D8*20120403~
DTP*463*D8*2012022212~
SVD*H9999*2245.89*HC:L5105:RR**1~
DTP*573*D8*20120514~
SE*42*0567~
GE*1*98~
IEA*1*200000931~

837 DME Professional Companion Guide Version 22.0/May 2014

36

9.5

DME Supplier Encounter – Bathtub Rail

Business Scenario 5: Zaffer Rahman is the patient and the subscriber and went to Dr. Jamar
Lee, who prescribed Zaffer Rahman with a bathtub rail from Medical Supply Corporation due to
rheumatoid arthritis. Happy Health Plan is the MAO that denied the claim because the safety
item was not included in the benefit structure.
File String 5:
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80887
*120530*114
7*^*00501*700000459*1*P*:~
GS*HC*ENH9999*80887*20120530*1147*22*X*005010X222A1~
ST*837*0119*005010X222A1~
BHT*0019*00*3920304830206*20120530*1147*CH~
NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~
PER*IC*JANE DOE*TE*5555552222~
NM1*40*2*EDSCMS*****46*80887~
HL*1**20*1~
NM1*85*2*MEDICAL SUPPLY CORPORATION*****XX*1299699799~
N3*129 DOCTOR DRIVE~
N4*NORFOLK*VA*235189999~
REF*EI*456969032~
PER*IC*BETTY SMITH*TE*9195551111~
HL*2*1*22*0~
SBR*S*18*XYZ1234567**47****MB~
NM1*IL*1*RAHMAN*ZAFFER****MI*672248306~
N3*1230 STATE DRIVE~
N4*NORFOLK*VA*235099999~
DMG*D8*19411224*M~
NM1*PR*2*EDSCMS*****PI*80887~
N3*7500 SECURITY BLVD~
N4*BALTIMORE*MD*212441850~
REF*2U*H9999~
CLM*2997677898479709654A*38.98***11:B:1*Y*A*Y*Y~
HI*BK:7140~
SBR*P*18*XYZ1234567******16~
CAS*CO*204*38.98
AMT*D*0.00~
OI***Y***Y~
NM1*IL*1*RAHMAN*ZAFFER****MI*672248306~
N3*1230 STATE DRIVE~
N4*NORFOLK*VA*235099999~
NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~
N3*705 E HUGH ST~
N4*NORFOLK*VA*235049999~
REF*T4*Y~
837 DME Professional Companion Guide Version 22.0/May 2014

37

LX*1~
SV1*HC:E0240:NU*38.98*UN*1***1~
PWK*CT*NS~
CR3*I*MO*99~
DTP*472*D8*20120403~
DTP*463*D8*2012022212~
SVD*H9999*0.00*HC:E0240:NU**1~
DTP*573*D8*20120514~
SE*43*0119~
GE*1*22~
IEA*1*700000459~

837 DME Professional Companion Guide Version 22.0/May 2014

38

9.6

DME Supplier Encounter - Parenteral

Business Scenario 6: Hiro Hernandez is the patient and the subscriber and went to Dr. Kim Lee,
who prescribed Hiro Hernandez with TPN from Doctor’s Best due to dysphagia. Happy Health
Plan is the MAO.
File String 6:
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80887
*120530*114
7*^*00501*240000459*1*P*:~
GS*HC*ENH9999*80887*20120530*1147*42*X*005010X222A1~
ST*837*1372*005010X222A1~
BHT*0019*00*3927304830206*20120530*1147*CH~
NM1*41*2*HAPPY HEALTH PLAN*****46*ENH9999~
PER*IC*JANE DOE*TE*5555552222~
NM1*40*2*EDSCMS*****46*80887~
HL*1**20*1~
NM1*85*2*DOCTORS BEST*****XX*1299899799~
N3*130 DOCTOR DRIVE~
N4*NORFOLK*VA*235189999~
REF*EI*456969032~
PER*IC*BETTY SMITH*TE*9195551111~
HL*2*1*22*0~
SBR*S*18*XYZ1234567**47****MB~
NM1*IL*1*HERNANDEZ*HIRO****MI*673248306~
N3*1230 STATE DRIVE~
N4*NORFOLK*VA*235099999~
DMG*D8*19410924*M~
NM1*PR*2*EDSCMS*****PI*80887~
N3*7500 SECURITY BLVD~
N4*BALTIMORE*MD*212441850~
REF*2U*H9999~
CLM*2997697898479709654A*248.99***11:B:1*Y*A*Y*Y~
HI*BK:78720~
SBR*P*18*XYZ1234567******16~
AMT*D*248.99~
OI***Y***Y~
NM1*IL*1*HERNANDEZ*HIRO****MI*673248306~
N3*1230 STATE DRIVE~
N4*NORFOLK*VA*235099999~
NM1*PR*2*HAPPY HEALTH PLAN*****XV*H9999~
N3*705 E HUGH ST~
N4*NORFOLK*VA*235049999~
REF*T4*Y~
LX*1~
SV1*HC:B4193:BR*248.99*UN*1***1~
837 DME Professional Companion Guide Version 22.0/May 2014

39

PWK*CT*NS~
CR3*I*MO*99~
DTP*472*D8*20120403~
DTP*463*D8*2012022212~
SVD*H9999*248.99*HC:B4193:BR**1~
DTP*573*D8*20120514~
SE*42*1372~
GE*1*42~
IEA*1*240000459~

837 DME Professional Companion Guide Version 22.0/May 2014

40

10.0

Encounter Data DME Processing and Pricing System Edits

After a DME encounter passes translator and CEM level editing and receives an ICN on a 277CA, the
EDFES then transfers the encounter to the Encounter Data DME Processing and Pricing System (EDDPPS)
where editing, processing, pricing, and storage occur. In order to assist MAOs and other entities in
submission of encounter data through the EDDPPS, CMS has provided the current list of the EDDPPS
edits in Table 13.
Note: The edit descriptions listed in Table 13 have been revised to identify a maximum of 41 characters
in order to display a more comprehensive explanation of edits on the MAO-002 Reports.
The EDDPPS edits are organized in four (4) different categories, as provided in Table 13, Column 2. The
EDDPPS edit categories include the following:
•
•
•
•

Validation
Beneficiary
Reference
Duplicate

Table 13, Column 3 identifies two (2) edit dispositions: Informational and Reject. Informational edits
will cause the encounter to be flagged; however, the Informational edit will not cause processing and/or
pricing to cease. Reject edits will cause an encounter to stop processing and/or pricing, and the MAO or
other entity must resubmit the encounter through the EDFES. T The encounter must then pass
translator and CEM level editing prior to transferring the data to the EDDPPS for reprocessing. The
EDDPPS edit description, as found in Table 13, Column 4, is included on the EDPS transaction reports to
provide further information for the MAO or other entity to identify the specific reason for the edit
generated.
If there is no reject edit at the header level and at least one of the lines is accepted, then the encounter
is accepted. If there is no reject edit at the header level, but all lines reject, then the encounter will
reject. If there is a reject edit at the header level, the encounter will reject.
Table 13 reflects only the currently programmed EDDPPS edits. MAOs and other entities should note
that, as testing progresses, it may be determined that the current edits require modifications, additional
edits may be necessary, or edits may be deactivated. MAOs and other entities must always reference
the most recent version of the CMS EDS 837-P DME Companion Guide to determine the current edits in
the EDDPPS.

837 DME Professional Companion Guide Version 22.0/May 2014

41

TABLE 13 – ENCOUNTER DATA DME PROCESSING AND PRICING SYSTEM (EDDPPS) EDITS
EDDPPS
EDIT#

EDDPPS EDIT
CATEGORY

EDDPPS EDIT
DISPOSITION

EDDPPS EDIT ERROR MESSAGE

00010
00011
00012
00025
00265
00699
00755
00760
00761
00762
00764
00765
02106
02110
02112
02120
02125
02240
02255
02256
03015
03101
30135
30261
30262
31000
31100
31105
98315
98320
98325

Validation
Validation
Validation
Validation
Validation
Validation
Validation
Validation
Validation
Validation
Validation
Validation
Beneficiary
Beneficiary
Beneficiary
Beneficiary
Beneficiary
Beneficiary
Beneficiary
Beneficiary
Reference
Validation
Reference
Validation
Validation
Validation
Validation
Validation
Duplicate
Duplicate
Duplicate

Reject
Reject
Reject
Reject
Reject
Reject
Reject
Reject
Reject
Reject
Reject
Reject
Informational
Reject
Reject
Reject
Reject
Reject
Reject
Reject
Informational
Informational
Informational
Informational
Informational
Informational
Informational
Informational
Reject
Reject
Reject

From DOS Greater Than TCN Date
Missing DOS in Header/Line
DOS Prior to 2012
Through DOS After Receipt Date
Correct/Replace or Void ICN Not in EODS
Void Must Match Original
Void Encounter Already Void/Adjusted
Adjusted Encounter Already Void/Adjusted
Billing Provider Different from Original
Unable to Void Rejected Encounter
Original Must Be Chart Review to Void
Original Must Be Chart Review Encounter to Adjust
Invalid Beneficiary Last Name
Beneficiary HICN Not on File
DOS After Beneficiary DOD
Beneficiary Gender Mismatch
Beneficiary DOB Mismatch
Beneficiary Not Enrolled in MAO for DOS
Beneficiary Not Part A Eligible for DOS
Beneficiary Not Part C Eligible for DOS
DOS Spans CPT/HCPCS Effective/End Date
Invalid Gender for CPT/HCPCS
Gender Mismatch for Dx Code
Referring Physician NPI Required
Invalid Modifier
HCPCS Require LT or RT Modifier
Invalid Dx Code For CPT/HCPCS
Invalid Modifier AY/AX Combination
Linked Chart Review Duplicate
Chart Review Duplicate
Service Line(s) Duplicated

10.1

EDDPPS Edits Enhancements Implementation Dates

As the EDS matures, the EDPS may require enhancements to the EDDPPS editing logic. As these
enhancements occur, CMS will provide the updated information (i.e., disposition changes and activation
or deactivation of an edit). Table 14 provides MAOs and other entities with the implementation dates
for enhancements made to the EDDPPS since the last release of the CMS EDS 837-P DME Companion
Guide.

837 DME Professional Companion Guide Version 22.0/May 2014

42

Note: Table 14 will not be provided when there are no enhancements implemented for the current
release of the CMS EDS Companion Guides.
10.2

EDPS Edits Prevention and Resolution Strategies

In order to assist MAOs and other entities with the prevention of potential errors in their encounter
data submission and with resolution of edits received on the generated MAO-002 reports, CMS has
provided comprehensive strategies and scenarios. CMS has identified the strategies and scenarios in
three (3) phases.
10.2.1 EDPS Edits Prevention and Resolution Strategies – Phase I: Frequently Generated EDDPPS
Edits
Edits previously identified in this section have been deactivated and are no longer required for
submission of DME encounter data. Table 15 has been removed from the CMS EDS 837-P DME
Companion Guide.
10.2.2 EDPS Edits Prevention and Resolution Strategies
Table 16 outlines Phase II for edits mutually generated in all subsystems of the EDPS (Professional,
Institutional, and DME).
TABLE 16 – EDPS EDITS PREVENTION AND RESOLUTION STRATEGIES – PHASE II
COMMON EDPS EDITS
Edit
Edit #
Edit Description
Comprehensive Resolution/Prevention
Disposition
00010 From DOS Greater Than TCN
Reject
Encounter must have a DOS prior to submission date.
Date
Scenario: Perfect Health of America submitted an encounter on May 10, 2012 for a knee replacement at Wonderful Hills
Mediplex for DOS May 12, 2012. The encounter was rejected because “from” DOS was after date of encounter submission.
00011 Missing DOS in Header/Line
Reject
Encounter header and line levels must include “from” and
“through” DOS (procedure or service start date).
Scenario: Chloe Pooh was admitted to Regional Port Hospital on October 21, 2012 for a turbinectomy and was released on
October 22, 2012. Regional Port Hospital submitted a claim to Robbins Health for the surgical procedure. Robbins Health
submitted the encounter to the EDS, but did not include the “through” DOS of October 22, 2012.
00012 DOS Prior to 2012
Reject
Encounter must contain 2012 “through” DOS for each line.
Scenario: Ion Health submitted an encounter with DOS from December 2, 2011 through December 28, 2011, for an
inpatient admission at Better Health Hospital. The encounter was rejected because the EDS will only process encounters
that include a 2012 “through” DOS or later.
00025 Through DOS After Receipt Date
Reject
Encounter submitted with a service line “through” DOS that
occurred after the date the encounter was submitted.
Scenario: Leverage Community Health submitted an encounter on August 23, 2012 for a myringotomy performed by Dr.
Earwell. The service line DOS for the procedure was August 29, 2012. The encounter was rejected because the encounter
was submitted to the EDS before the DOS listed on the encounter.

837 DME Professional Companion Guide Version 22.0/May 2014

43

TABLE 16 – EDPS EDITS PREVENTION AND RESOLUTION STRATEGIES – PHASE II (CONTINUED)
COMMON EDPS EDITS
Edit
Edit #
Edit Description
Comprehensive Resolution/Prevention
Disposition
00265 Correct/Replace or Void ICN Not
Reject
Adjustment/Void encounter submitted with an invalid ICN.
in EODS
Verify the accuracy of the ICN on the returned MAO-002 report.
Scenario: Chance Medical Services submitted an encounter to the EDS and received an MAO-002 report with an accepted
ICN of 123456789. The encounter required adjustment. Chance Medical Services submitted an adjustment encounter
using ICN 234567899. The adjustment encounter was rejected because there was no original record in the EDS for this ICN
with the same Submitter ID.
00699 Void Must Match Original
Reject
Voided encounter must have the same number of lines as the
original encounter.
Scenario: Lamb Professional Care submitted an encounter for an inpatient hospital stay with five (5) service lines. Lamb
Professional Care submitted a void encounter for the hospital stay. However, the void encounter contained only 4 lines
from the original encounter. Lamb Professional Care received an MAO-002 report with edit 00699 because one of the lines
from the original encounter was not included on the void encounter.
00761 Billing Provider Different from
Reject
Billing provider’s NPI must be identical in both the original and
Original
void encounters.
Scenario: Mastermind General Hospital submitted an encounter for a procedure performed by Dr. Jackson Martinez on
October 17, 2012. Spartacus Regional Health submitted the encounter to the EDS and received an MAO-002 report with an
accepted ICN of 342431098. On October 27, 2012, Spartacus Regional Health submitted a void encounter for ICN
342431098 using an NPI for Dr. Mary Jane. The encounter was rejected because the billing provider NPI on the void
encounter did not match the billing provider on the original encounter.
02106 Invalid Beneficiary Last Name
Informational Verify that last name populated on the encounter matches
the last name listed in MARx database.
Scenario: BlueSkies Rural Health submitted an encounter for patient Ina Batiste-Rhogin. The MARx database listed the
patient as Ina Rhogin. The EDPS processed and accepted the encounter with an informational flag indicating that the name
provided on the encounter was not identical to the name listed in the eligibility database.
02110 Beneficiary HICN Not on File
Reject
Verify that HICN populated on the encounter is valid in MARx
database.
Scenario: Bright Medical Center submitted a claim to Sunshine Complete Health for an office visit for Mr. Everett Banks for
DOS May 26, 2012. Sunshine Complete Health submitted an encounter to the EDS. The encounter was rejected for edit
02110, because the HICN populated on the encounter was not on file in the MARx database.
02112 DOS After Beneficiary DOD
Reject
Verify that DOS submitted is accurate and does not exceed
the beneficiary DOD.
Scenario: Mountain Health submitted an encounter for an inpatient admission for Ray Rayson for DOS July 15, 2012. The
EDPS was unable to process the encounter because the MARx database indicated that Mr. Rayson expired on July 13, 2012.
02120 Beneficiary Gender Mismatch
Reject
Verify that gender populated on the encounter is accurate
and matches gender listed in MARx database.
Scenario: Jenna Jorgineski went to Lollipop Lab for a sleep study on September 4, 2012. Lollipop Lab submitted a claim for
the sleep study to Capital City Community Care with Ms. Jorgineski’s gender identified as “male”. Capital City Community
Care submitted the encounter. The EDS processed and accepted the encounter. The MAO-002 report was returned with a
reject edit 02120, because Ms. Jorgineski’s gender was listed as “female” in the MARx database.
02125 Beneficiary DOB Mismatch
Reject
Verify that DOB populated on the encounter is accurate and
matches DOB listed in MARx database.
Scenario: Swan Health submitted an encounter to the EDS for Joe Blough on March 3, 2012. The encounter listed Mr.
Blough’s DOB as December 13, 1940. The eligibility database (MARx) listed Mr. Blough’s DOB as December 13, 1937. The
EDS returned the MAO-002 report to Swan Health with edit 02125 due to the conflicting dates of birth.
837 DME Professional Companion Guide Version 22.0/May 2014

44

TABLE 16 – EDPS EDITS PREVENTION AND RESOLUTION STRATEGIES – PHASE II (CONTINUED)
COMMON EDPS EDITS
Edit
Edit #
Edit Description
Comprehensive Resolution/Prevention
Disposition
02240 Beneficiary Not Enrolled in MAO
Reject
Verify that beneficiary was enrolled in your MAO during DOS
for DOS
on the encounter.
Scenario: Gabrielle Boyd was admitted to Faith Hospital for an appendectomy on June 11, 2012 and was discharged on
June 14, 2012. Faith Hospital submitted the claim for the hospital admission to Adams Healthcare. Adams Healthcare
adjudicated the claim and submitted an encounter to the EDS on July 12, 2012. Ms. Boyd’s effective date with Adams
Healthcare was July 1, 2011. The EDS returned an MAO-002 report to Adams Health with edit 02240 because Ms. Boyd
was not enrolled with the health plan for the DOS submitted by Faith Hospital.
02255 Beneficiary Not Part A Eligible
Reject
Verify that beneficiary was enrolled in Part A for DOS listed
for DOS
on the encounter.
Scenario: Mr. Carl Evergreen was transferred from a VA hospital and admitted to Rainforest Regional on April 28, 2012.
Mr. Evergreen was effective for Medicare Part A on May 1, 2012. Strides in Care Health Plan submitted the encounter for
the admission to Rainforest Regional and received an MAO-002 report with edit 02255 because Mr. Evergreen was
enrolled in Medicare Part A after the date of hospital admission.
02256 Beneficiary Not Part C Eligible
Reject
Verify that beneficiary was enrolled in Part C for DOS listed on
for DOS
the encounter.
Scenario: On July 4, 2012, Gail Williams has severe chest pains and goes to the emergency room for a chest x-ray at
Underwood Memorial Hospital. At the time of the emergency room visit, Ms. Williams only has Part A Medicare
coverage. Underwood Memorial submits the claim to AmeriHealth and the claim is adjudicated under Part A
Medicare. AmeriHealth submits an encounter to the EDS, which is rejected with edit 02256, because Ms. Williams is not
covered under Part C Medicare for the DOS.
03015 DOS Spans CPT/HCPCS
Informational The procedure code is not valid/effective for the DOS
Effective/End Date
populated on the encounter
Scenario: Oren Davis goes to Independent Lab for a urinalysis on February 24, 2012. Independent Lab submits the claim to
World Healthcare with a procedure code of 81000. As of August 1, 2011, procedure code 81004 is no longer a valid
procedure code. World Health adjudicates the claim and submits the encounter to the EDS. World Health receives an
MAO-002 report with a “reject” status for edit 03015 because the procedure code was not valid on the DOS.
03101 Invalid Gender for CPT/HCPCS
Informational Verify that the gender populated on the encounter is
accurate. Ensure that the beneficiary’s gender is appropriate
for the CPT/HCPCS code provided
Scenario: True Blue General Hospital submitted a claim to Valley View Health for Ms. Clara Bell with CPT code 54530.
Valley View adjudicated the claim and submitted an encounter. Valley View received an MAO-002 report with edit 03101
because the procedure identified for Ms. Bell was an orchiectomy, which is routinely performed for a male.
98325 Service Line(s) Duplicated
Reject
Verify that encounter was not previously submitted. If not a
duplicate encounter, ensure that elements validated by
duplicate logic are not the same.
Scenario: Sanford Health Systems submitted an encounter for two (2) service lines for 15-minute therapy services. The
encounter lines submitted were the same for the timed procedure code, totaling 35 minutes and should have been
submitted with 2 units of service under the total time rather than as separate duplicate lines.
10.2.3 EDDPPS Edits Prevention and Resolution Strategies – Phase III: General EDDPPS Edits
Table 17 outlines Phase III for the remaining EDDPPS edits generated on the MAO-002 Encounter Data
Processing Status Reports.
837 DME Professional Companion Guide Version 22.0/May 2014

45

TABLE 17 – EDPS EDITS PREVENTION AND RESOLUTION STRATEGIES – PHASE III
GENERAL EDPS EDITS
Edit
Edit #
Edit Description
Comprehensive Resolution/Prevention
Disposition
00755 Void Encounter Already
Reject
Submitter has previously voided or adjusted an encounter
Void/Adjusted
and is attempting to void the same encounter. Submitter
should review returned MAO-002 reports to confirm
processing of the voided encounter prior to resubmission of
the void.
Scenario: Happy Trails Health Plan submitted a void/delete encounter on October 10, 2012. Happy Trails Health Plan
voided the same encounter, in error, on October 15, 2012, prior to receiving the MAO-002 report for the initial void/delete
encounter, which was returned on October 16, 2012. The MAO-002 report for the subsequent voided encounter was
returned with edit 00755 due to the submission of the second void/delete encounter.
00762 Unable to Void Rejected
Reject
Submitter is attempting to void a previously rejected
Encounter
encounter. Review returned MAO-002 reports to confirm the
rejected encounter.
Scenario: On July 20, 2012, Hero Health Plan submitted an encounter with an invalid HICN. On July 26, 2012, Hero Health
Plan attempted to void the encounter due to the invalid HICN without referencing the MAO-002 report, dated July 25,
2012, that indicated that the encounter was rejected. On August 1, 2012, Hero Health Plan received an MAO-002 report
with edit 00762 for the voided encounter because the original encounter had already been processed and rejected.
00764 Original Must Be Chart Review
Reject
Submitter must ensure that, if the void encounter (frequency
to Void
code ‘8’) is populated with PWK01=’09 and PWK02=’AA’, the
original encounter submission was a chart review encounter
populated with PWK01=’09’ and PWK02=’AA’
Scenario: On January 12, 2013, Paisley Community Health submitted an original encounter for Mr. Jolly Jones to the EDS
and received the accepted ICN of 3029683010582. On February 2, 2013, Paisley Community Health submitted a chart
review encounter to the EDPS to delete a diagnosis code from the original encounter and received the accepted ICN of
5039530285074. In April 2013, Paisley Community Health performed another chart review of Mr. Jones’ medical records
and discovered that the service was never provided. Paisley Community Health submitted a void encounter to the EDS
using the reference ICN of 3029683010582 (the original encounter ICN) and populated PWK01=’09’ and PWK02=’AA’. The
EDS rejected the encounter because the ICN referenced was for the original encounter, not the initial chart review.
00765 Original Must Be Chart Review
Reject
Submitter must ensure that, if the correct/replace encounter
to Adjust
(frequency code ‘7’) is populated with PWK01=’09 and
PWK02=’AA’, the original encounter submission was a chart
review encounter populated with PWK01=’09’ and
PWK02=’AA’. The submitter must also ensure that the ICN
references the initial chart review encounter, not the original
full encounter.
Scenario: Flashback Health performed a chart review for Prosperous Living Medical Center. Flashback Health discovered
two (2) additional diagnosis codes for an encounter previously submitted for Ms. Leanne Liberty. Flashback Health
submitted an initial chart review encounter using the frequency code of ‘7’. The EDS rejected the chart review encounter
submission because initial chart review encounters should contain a frequency code ‘1’.
31100 Invalid Dx Code for CPT/HCPCS
Informational Verify that the diagnosis codes submitted is appropriate for
the service populated on the encounter.
Scenario: Beach Health submitted and encounter for a bedside drainage bag (A4357) for beneficiary, Marsha Glee with a
diagnosis of 683-Acute lymphadenitis. The MAO-002 report was returned with informational edit 31100 because the
diagnosis was not valid for the service provided.

837 DME Professional Companion Guide Version 22.0/May 2014

46

Edit #
30135

TABLE 17 – EDPS EDITS PREVENTION AND RESOLUTION STRATEGIES – PHASE III (CONTINUED)
GENERAL EDPS EDITS
Edit
Edit Description
Comprehensive Resolution/Prevention
Disposition
Gender Mismatch for Dx Code
Informational Verify that the gender populated on the encounter matches
the gender for the beneficiary in MARx. Ensure that the
diagnosis is appropriate for the gender.

Scenario: GreenTrees Community Health submitted and encounter for Ms. Clara Shel with a diagnosis of 608.89-Seminal
vesicle fibrosis. GreenTrees Community Health received an MAO-002 report with informational edit 30135 because the
diagnosis was not valid for a female.
00760 Adjusted Encounter Already
Reject
Submitter has previously adjusted or voided an encounter
Void/Adjusted
and is attempting to adjust the same encounter. Submitter
should review returned MAO-002 reports to confirm
processing of the adjusted encounter prior to resubmission of
the adjustment.
Scenario: On August 20, 2012, Pragmatic Health submitted a correct/replace encounter to correct a CPT code. Pragmatic
Health had not received their MAO-002 report by August 23, 2012 and decided to resubmit the correct/replace encounter.
The MAO-002 report was returned on August 24, 2012 with the correct/replace encounter identified as accepted.
Pragmatic Health received edit 00760 on a subsequent MAO-002 report because the EDPS had already processed the
resubmitted correct/replace encounter.
98315 Linked Chart Review Duplicate
Reject
Linked Chart Review encounters cannot be submitted where
the HICN, Associated ICN and header DOS, diagnosis code(s)
contain the exact same values as another Chart Review
encounter already present within the EODS.
Scenario: Sequoia Health Plan conducted an audit of Timber Lake Family Physicians and discovered an encounter
previously submitted to the EDS contained an unnecessary diagnosis code. On 04/01/14, Sequoia Health Plan submitted a
linked chart review encounter to the EDS containing the associated ICN of the original counter to identify the unnecessary
diagnosis code. On 05/01/14 Sequoia Health Plan inadvertently submitted the exact same linked chart review encounter
to the EDS. The EDS rejected the second submission of the linked chart review encounter because no changes were
detected between the two linked chart review encounters.
98320 Chart Review Duplicate
Reject
Unlinked Chart Review encounters cannot be submitted
where the HICN, header DOS and diagnosis code(s) contain
the exact same values as another Chart Review encounter
already present within the EODS.
Scenario: Ohio Health Plan conducted an audit of Cincinnati Fair Physicians Group and discovered an encounter not
previously submitted to the EDS required an additional diagnosis code. On 03/15/14, Ohio Health Plan submitted an
unlinked chart review encounter to the EDS to include the additional diagnosis code. On 06/01/14, Ohio Health Plan
submitted the same unlinked chart review encounter to the EDS due to a clerical error. The EDS rejected the second
submission of the unlinked chart review encounter because the EDS detected no changes between the two unlinked chart
review encounters.
11.0

DME Supplier vs. Incident to Services Submission

For submission of production data, DME Incident to and DMEPOS Supplier encounter submissions will
be validated according to the NPI and Payer ID only. MAOs and other entities are not required to use
the DMEPOS HCPCS Fee Schedule Job to determine the DME HCPCS jurisdiction.

837 DME Professional Companion Guide Version 22.0/May 2014

47

12.0

Submission of Default Data in a Limited Set of Circumstances

MAOs and other entities may submit default data in a limited set of circumstances, as identified and
explained in Table 18. MAOs and other entities cannot submit default data for any circumstances other
than those listed in Table 18. CMS will use this interim approach for the submission of encounter data.
In each circumstance where default information is submitted, MAOs and other entities are required to
indicate in Loop 2300, NTE01=’ADD’, NTE02 = the reason for the use of default information. If there are
questions regarding appropriate submission of default encounter data, MAOs and other entities should
contact CMS for clarification. CMS will provide additional guidance concerning default data, as
necessary.
12.1

Default Data Reason Codes (DDRC)

Loop 2300, NTE02 allows for a maximum of 80 characters and one (1) iteration, which limits the
submission of default data to one (1) message per encounter.
In order to allow the population of multiple default data messages in the NTE02 field, CMS will use a
three (3)-digit default data reason code (DDRC), which will map to the full default data message in the
EDS.
MAOs and other entities may submit multiple DDRCs with the appropriate three (3)-digit DDRC.
Multiple DDRCs will be populated in a stringed sequence with no spaces or separators between each
DDRC (i.e., 036040048). Table 18 provides the CMS approved situations for use of default data, the
default data message, and the default data reason code.
TABLE 18 – DEFAULT DATA
*DEFAULT DATA

DEFAULT DATA MESSAGE

DEFAULT DATA
REASON CODE (NTE02)

Rejected Line Extraction

REJECTED LINES CLAIM CHANGE DUE TO REJECTED
LINE EXTRACTION

036

Medicaid Service Line Extraction

MEDICAID CLAIM CHANGE DUE TO MEDICAID
SERVICE LINE EXTRACTION

040

EDS Acceptable Anesthesia Modifier

MODIFIER CLAIM CHANGE DUE TO EDS
ACCEPTABLE ANESTHESIA MODIFIER

044

Default NPI for atypical, paper, and 4010
claims

NO NPI ON PROVIDER CLAIM

048

Default EIN for atypical providers

NO EIN ON PROVIDER CLAIM

052

Chart Review Default Procedure Codes

DEFAULT PROCEDURE CODES INCLUDED IN CHART
REVIEW

056

True COB Default Adjudication Date

DEFAULT TRUE COB PAYMENT ADJUDICATION
DATE

060

837 DME Professional Companion Guide Version 22.0/May 2014

48

13.0

Tier II Testing

CMS developed the Tier II testing environment to ensure that MAOs and other entities have the
opportunity to test a more inclusive sampling of their data. MAOs and other entities that have obtained
end-to-end certification may submit Tier II testing data.
CMS encourages MAOs and other entities to utilize the Tier II testing environment when they have
questions or issues regarding edits received on EDFES Acknowledgement Reports or MAO-002
Encounter Data Processing Status reports; and when they have new submission scenarios that they wish
to test prior to submitting to production.
MAOs and other entities may submit chart review, correct/replace, or void/delete encounters to the
Tier II testing environment only when the encounters are linked to previously submitted and accepted
encounters in the Tier II testing environment.
Encounter files submitted to the Tier II testing environment must comply with the TR3, CMS Edits
Spreadsheet, and the CMS EDS Companion Guides, as well as the following requirements:
•
•
•
•
•
•

Files must be identified using the Authorization Information Qualifier data element “Additional
Data Identification” in the ISA segment (ISA01= 03).
Files must be identified using the Authorization Information data element to identify the “Tier II
indicator” in the ISA segment (ISA02= 8888888888).
Files must be identified as “Test” in the ISA segment (ISA15=T).
Submitters may send multiple Contract IDs per file
Submitters may send multiple files for a Contract ID, as long as each file does not exceed 2,000
encounters per Contract ID
If any Contract ID on a given file exceeds 2,000 encounters during the processing of the file, the
entire file will be returned

As with production encounter data, MAOs and other entities will receive the TA1, 999, and 277CA
Acknowledgement Reports and the MAO-002 Reports.
While not required, MAOs and other entities are strongly encouraged to correct errors identified on the
reports and resubmit data.

837 DME Professional Companion Guide Version 22.0/May 2014

49

14.0

EDS Acronyms

Table 19 outlines a list of acronyms currently used in the EDS documentation, materials, and reports
distributed to MAOs and other entities. This list is not all-inclusive and should be considered as a living
document, as CMS will add acronyms as required.
TABLE 19 – EDS ACRONYMS

ACRONYM

DEFINITION

A
ASC
C
CAH
CARC
CAS
CC
CCI
CCN
CEM
CMG
CMS
CORF
CPO
CPT
CRNA
CSC
CSCC
CSSC
D

Ambulatory Surgery Center

DDRC

Default Data Reason Code

DME

Durable Medical Equipment

DMEPOS
DMERC

Durable Medical Equipment, Prosthetics, Orthotics, and Supplies
Durable Medical Equipment Carrier

DOB
DOD

Date of Birth
Date of Death

DOS
E

Date(s) of Service

E & M or E/M
EDDPPS

Evaluation and Management
Encounter Data DME Processing and Pricing Sub-System

EDFES
EDI

Encounter Data Front-End System
Electronic Data Interchange

EDIPPS

Encounter Data Institutional Processing and Pricing Sub-System

Critical Access Hospital
Claim Adjustment Reason Code
Claim Adjustment Segments
Condition Code
Correct Coding Initiative
Claim Control Number
Common Edits and Enhancement Module
Case Mix Group
Centers for Medicare & Medicaid Services
Comprehensive Outpatient Rehabilitation Facility
Care Plan Oversight
Current Procedural Terminology
Certified Registered Nurse Anesthetist
Claim Status Code
Claim Status Category Code
Customer Service and Support Center

837 DME Professional Companion Guide Version 22.0/May 2014

50

TABLE 19 – EDS ACRONYMS (CONTINUED)

ACRONYM

DEFINITION

EDPPPS
EDPS
EDS
EIC
EODS
ESRD

Encounter Data Professional Processing and Pricing Sub-System
Encounter Data Processing System
Encounter Data System
Entity Identifier Code
Encounter Operational Data Store
End Stage Renal Disease

F
FFS

Fee-for-Service

FQHC
FTP

Federally Qualified Health Center
File Transfer Protocol

FY
H

Fiscal Year

HCPCS
HHA
HICN
HIPAA
HIPPS
I
ICD-9CM/ICD-10CM
ICN

Healthcare Common Procedure Coding System
Home Health Agency
Health Information Claim Number
Health Insurance Portability and Accountability Act
Health Insurance Prospective Payment System

IPPS

Inpatient Prospective Payment System

IRF
M
MAC
MAO
MTP

Inpatient Rehabilitation Facility

MUE
N
NCD
NDC

Medically Unlikely Edits

NPI
NCCI
NOC
NPPES

National Provider Identifier
National Correct Coding Initiative
Not Otherwise Classified
National Plan and Provider Enumeration System

O
OCE
OIG
OPPS

Outpatient Code Editor
Officer of Inspector General
Outpatient Prospective Payment System

International Classification of Diseases, Clinical Modification (versions 9 and 10
Interchange Control Number

Medicare Administrative Contractor
Medicare Advantage Organization
Multiple Technical Procedure

National Coverage Determination
National Drug Codes

837 DME Professional Companion Guide Version 22.0/May 2014

51

TABLE 19 – EDS ACRONYMS (CONTINUED)

ACRONYM
P
PACE
PHI
PIP
POA
POS

DEFINITION
Program for All-Inclusive Care for the Elderly
Protected Health Information
Periodic Interim Payment
Present on Admission
Place of Service

PPS
R

Prospective Payment System

RAP
RHC

Request for Anticipated Payment
Rural Health Clinic

RNHCI

Religious Nonmedical Health Care Institution

RPCH
S
SME
SNF
SSA
T
TARSC
TCN
TOB
TOS
TPS
V
VC
Z
ZIP Code

Regional Primary Care Hospital
Subject Matter Expert
Skilled Nursing Facility
Social Security Administration
Technical Assistance Registration Service Center
Transaction Control Number
Type of Bill
Type of Service
Third Party Submitter
Value Code
Zone Improvement Plan Code

837 DME Professional Companion Guide Version 22.0/May 2014

52

REVISION HISTORY
VERSION

DATE

DESCRIPTION OF REVISION

1.0

6/22/2012

Baseline Version

2.0

8/31/2012

Release 1

3.0

9/26/2012

Release 2

4.0

10/25/2012

Release 3

5.0

11/26/2012

Release 4

6.0

12/21/2012

Release 5

7.0

01/25/2013

Release 6

8.0

02/26/2013

Release 7

9.0

03/20/2013

Release 8

10.0

04/25/2013

Release 9

11.0

05/20/2013

Release 10

12.0

06/24/2013

Release 11

13.0

7/25/2013

Release 12

14.0

09/26/2013

Release 13

15.0

10/25/2013

Release 14

16.0

11/26/2013

Release 15

17.0

12/27/2013

Release 16

18.0

01/22/2014

Release 17

19.0

02/21/2014

Release 18

20.0

3/18/2014

Release 19

21.0

04/28/2014

Release 20

22.0

05/30/2014

Section 14.0, Table 19 – Updated EDS Acronyms table

837 DME Professional Companion Guide Version 22.0/May 2014

53