Download:
pdf |
pdfENCOUNTER DATA SUBMISSION
AND PROCESSING GUIDE
Medicare Advantage Program
October 2020 | Version 4.0
This page left intentionally blank for double-sided copying.
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
CONTENTS
Preface
Chapter 1. Overview of Requirements and Systems for Risk Adjustment Data
Chapter 2. Encounter Data Submission Requirements
Chapter 3. MA Companion Guide for EDR and CRR Submissions
Chapter 4. EDFES Processing
Chapter 5. EDPS Processing
Chapter 6. Prevention and Resolution Tips for ED Submission Errors
Page 1 of 1
This page left intentionally blank for double-sided copying.
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
PREFACE
The Encounter Data Submission and Processing Guide is a technical guide on how to populate and submit
encounter data records (EDRs) and chart review records (CRRs) that comply with guidance from the Centers for
Medicare & Medicaid Services (CMS). In addition, the guide provides information on how these records are
processed in CMS’ systems, and provides tips on problem resolution in response to transaction and
acknowledgement reports from CMS’ systems.
The guide is organized as follows:
Chapter
Chapter Name
Appendices
1
Overview of Requirements and
Systems for Risk Adjustment Data
2
Encounter Data Submission
Requirements
3
MA Companion Guide for EDR &
CRR Submissions
Appendix 3A. MA Companion Guide: CMS’ Supplemental
Instructions for EDR and CRR Data Elements
Appendix 3B. Crosswalk from Retired Minimum Data
Elements List to Appendix 3A MA Companion Guide
Appendix 3C. MBI Edits for ED and RAPS Data
4
EDFES Processing
Appendix 4A. Deactivated Edits
5
EDPS Processing
6
Prevention and Resolution Tips for
ED Submission Errors
CMS = Centers for Medicare & Medicaid Services; EDR = encounter data record; CRR = chart review record;
EDFES = Encounter Data Front-End System; EDPS = Encounter Data Processing System; ED = Encounter Data;
RAPS = Risk Adjustment Processing System; FERAS = Front-End Risk Adjustment System; MA = Medicare
Advantage; MDE = Minimum Data Elements; MBI = Medicare Beneficiary Identifier
The guide is a compilation into a single document of CMS guidance on risk adjustment data submissions from
the following sources:
1.
Health Plan Management System (HPMS) Memos
2.
User Group slides and Questions and Answers
3.
Mailbox Questions and Answers
4.
Companion Guides
5.
Participants Guides
6.
Training materials
Preface
Page 1 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
7.
Bulletins and newsletters
With the release of version 1.0 of the Encounter Data Submission and Processing Guide, sources 4 through 7
are now archived on the CSSC Operations website (http://www.csscoperations.com/). This guide will become the
key source of guidance for Medicare Advantage Organizations (MAOs) and other submitters of encounter data and
RAPS data. New information from sources 1 through 3 will be incorporated into the guide on a regular schedule.
1.1. Topics Not Included in this Guide
The following three topics are not included in this guide. Documentation pertaining to these topics can be
found on the CSSC Operations website (http://www.csscoperations.com/).
1.
How to connect and interface with front-end systems. Submitters will still need to refer to the new Medicare
Advantage & Part D Communications Handbook on how to connect to CMS’ front-end systems for encounter
data and RAPS data. The Handbook is a consolidation of previous guides for CMS’ front-end systems that
ingest encounter data, RAPS data, and Prescription Drug Event (PDE) data files: the EDFES User Guide,
FERAS User Guide, and the PDFS User Guide. There are also other documents at this location pertaining to the
submission of data to CMS.
2.
Filtering and risk score calculation. See the December 22, 2015, Health Plan Management System (HPMS)
memo “Final Encounter Data Diagnosis Filtering Logic” for information on filtering, and for information on
risk score calculations, see Chapter 7 on Risk Adjustment, which can be found at
https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/downloads/mc86c07.pdf, and CMS’
Advance Notices and Rate Announcements at https://www.cms.gov/Medicare/HealthPlans/MedicareAdvtgSpecRateStats/Announcements-and-Documents.html.
3.
Guidance for Medicare-Medicaid Plans (MMPs) can be found at https://www.cms.gov/Medicare-MedicaidCoordination/Medicare-and-Medicaid-Coordination/Medicare-Medicaid-CoordinationOffice/FinancialAlignmentInitiative/FinancialModelstoSupportStatesEffortsinCareCoordination.html.
Preface
Page 2 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
CHANGE HISTORY
Document version
Version 1.0
Version 2.0
Preface
Date
May 2018
November 2018
Description of significant changes
Initial version of the document
Chapter 2
- Updating Section 2.3 CRRs;
- Adding Section 2.3.5 “Submission of Data
Collection Year Diagnoses on CRRs”;
- Adding Section 2.6 “Required X12 837 5010
Format for EDR and CRR Submissions”;
- Updating Section 2.7.2. E-codes;
- Updating Section 2.11 “ED Monitoring and
Compliance Policy”
Chapter 3
- Updating Section 3.2.2;
- Adding section 3.2.3. addressing situational
edits
- Section 3.3.2 clarifying the position of the
Beneficiary Identifier field.
- Adding a table to section 3.5 NPIs and EINs
to capture default EIN assignments by service
type. And correct the default EIN instruction
for DME.
Chapter 6
- Updating edit code 98325 bypass logic and
02240 chart review applicability.
Appendix 3A
Correct the default DME EIN instruction in Loop
2010AA\REF02
Page 3 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Document version
Version 3.0
Preface
Date
March 2019
Description of significant changes
Chapter 1 – Introduction
Clarifying the instructions on how to access the 5010
Edits Spreadsheets from www.cms.gov in the table of
Resources for Risk Adjustment Data Submission
Chapter 2 – Encounter Data Submission Policies
Adding specific field-level instruction on how to link
CRRs to encounter data records or other CRRs
(Section 2.3)
Adding summary tables from the November 2018
Training Session that summarizes submission
requirements for Add/Delete, Linked/Unlinked CRRs
(Section 2.3.2) and replacing and voiding previously
submitted EDRs and CRRs (Section 2.3.3 and 2.3.4)
Chapter 3 – MA Companion Guide
Adding a note about how X12 loop segments are
terminated (Section 3.2.1)
Adding a table showing X12 837 envelope structure
(Section 3.2.1)
Clarifying DME guidance (Section 3.10)
Chapter 4 – EDFES Processing
Adding a description of the impact to encounter
records’ acceptance when an edit is triggered at the
999 or CCEM level (Section 4.4)
Updating images and tables for the TA1, 999R, and
277CA report examples (Section 4.6.1, 4.7.2, and
Section 4.8.4)
Several updates to instructions for reconciling the 999
Acknowledgement Report example (Section 4.7.2)
Chapter 5 – EDPS Processing
Adding reminder that MAO-001 and -002 reports are
available in 5 business days (Section 5.3)
Adding a note that entities will not receive MAO-001
on test files (Section 5.3)
Appendix 4D – Deactivated Edits
- Adding a deactivated institutional edit,
X223.129.2010BB.REF02.070.
Page 4 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Version 4.0
October 2020
Chapter 1 – Overview of Requirements and Systems for
Risk Adjustment Data
- Update Table 1.1 with new links to CSSCOperations
and reference to Appendix 4A (applicable edits)
Chapter 2 – Encounter Data Submission Requirements
- Renamed the chapter from Encounter Data
Submission Policies to Encounter Data Submission
Requirements
- Removed “pending” from list of claims’ status that
should be submitted to CMS (Section 2.1)
- Clarified that a Replacement CRR-Delete will be
rejected in all situations (Section 2.3.3)
- Updated HIPPS Codes information (Section 2.9.2.)
- Retitled section ED Monitoring and Compliance
Guidance (Section 2.11)
Chapter 3 – MA Companion Guide for EDR and CRR
Submissions
-
Added Section 3.3 Tier II Testing Environment
Updated references to Appendix
Added information about acceptable provider
specialties for risk adjustment data submission
(Section 3.6.1)
Updated instructions for partial capitation submission
(Section 3.8)
Updated Ambulance Encounter Processing (Section
3.12)
Added Telehealth Encounter Processing (Section
3.13)
Chapter 4 – EDFES Processing
- Edit Figure 4.4 and text example associated with
figure.
- Fix a pre-screen EDFES error message text (see .txt
file) and remove "when submitted through
Connect:Direct" phrase (Section 4.5)
- Clarified language in Pre-Screening Validation and
Invalid Report (Section 4.5)
- Updated references to former Appendices 4A, 4B and
4C (Sections 4.6, 4.7, 4.8, and 4.8.3)
Chapter 5 – EDPS Processing
- Updated references to former Appendices 5A and 5B
(Section 5.3.1 and 5.3.2)
Chapter 6 – Prevention and Resolution Tips for ED
Submission Errors
Preface
Page 5 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Document version
Date
Description of significant changes
-
Updated references to Appendix 4A (Section 6.1)
Added a new section to describe new or updated edits
implemented since the prior version (Section 6.2)
The following Appendices now have corresponding job
aides and were removed:
- Appendix 4A. TA1 Acknowledgement Report Key
Segments
- Appendix 4B. 999 Acknowledgement Report Key
Segments
- Appendix 4C. 277CA Acknowledgement Report Key
Segments
- Appendix 5A; MAO 001 Report Layout
- Appendix 5B: MAO 002 Report Layout
Appendix 4D. Deactivated Edits is now re-named as
Appendix 4A. Deactivated Edits
Preface
Page 6 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Chapter 1. Overview of Requirements and Systems for Risk Adjustment Data
1.1.
GENERAL SUBMISSION REQUIREMENTS APPLICABLE TO BOTH ED AND RAPS DATA............ 2
1.2.
OVERVIEW OF PROCESSING SYSTEMS FOR ENCOUNTER DATA AND RAPS DATA ................... 2
1.3.
ENCOUNTER DATA PROCESSING SYSTEMS......................................................................................... 3
1.4.
USE OF THIS GUIDE .................................................................................................................................... 4
1.5.
RESOURCES FOR RISK ADJUSTMENT DATA SUBMISSION ............................................................... 5
________________________________________
Chapter 1
Page 1 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
1.1. General Submission Requirements Applicable to Both ED and RAPS Data
The Centers for Medicare & Medicaid Services (CMS) requires organizations offering Medicare Advantage
plans and certain other Medicare private health plans to submit risk adjustment data that characterize the context and
purpose of each item and service provided to a Medicare enrollee, as described in regulation at 42 CFR Section
422.310. Risk adjustment data refer to data submitted under this regulatory provision; CMS collects this data in two
formats:
1.
Encounter data (ED): data representing each item and service provided to an MA enrollee and submitted in
the X12 837 5010 format. (ED is described at Section 422.310(d) as data that conform to CMS’ requirements
for data equivalent to Medicare fee-for-service data.)
2.
Risk Adjustment Processing System (RAPS) data: data submitted in an abbreviated format developed by
CMS.
This guide sets forth requirements for the submission of encounter data to CMS.
CMS intends for this guide to be all-inclusive and to describe the encounter data submission guidance at the
time it was published. However, certain guidance or information may have been inadvertently omitted and changes
may occur. There may be revisions and additions in the future.
Note: In this guide, references to the term MA organization or MAO should be read as including other
submitting organizations offering Medicare private health plans (cost plans and Programs of All-Inclusive Care for
the Elderly (PACE) organizations) and their third-party submitters, unless otherwise indicated.
1.2. Overview of Processing Systems for Encounter Data and RAPS Data
This section provides a brief overview of CMS’ systems that process encounter data. The Medicare Advantage
Encounter Data System (EDS) was implemented to receive encounter data beginning in 2012 and consists of two
main components: the Encounter Data Front-End System (EDFES), which receives EDRs and CRRs from MAOs
and other submitters, and the Encounter Data Processing System (EDPS), which performs detail editing of EDRs
and CRRs.
The Risk Adjustment Suite of Systems (RASS) was implemented in 2003 to receive RAPS data from MAOs
and other submitters and to calculate risk scores. The RASS consists of three main components: the Front-End Risk
Adjustment System (FERAS), which receives RAPS data from submitters; the Risk Adjustment Processing System
(RAPS), which performs detail editing on RAPS data; and the Risk Adjustment System (RAS), which executes the
risk adjustment models and calculates risk scores for each beneficiary using diagnostic data from both encounter
data and RAPS data.
Chapter 1
Page 2 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 1.1 presents an overview of these processing systems.
Figure 1.1. Risk Adjustment Processing Overview – CMS’ Encounter Data & RASS Data Systems
MAO = Medicare Advantage Organization; ED = encounter data.
1.3. Encounter Data Processing Systems
Each EDR must contain the loops, segments, and data elements from the X12 837 5010 format required to
report a particular encounter. Most of the requirements for MA ED submission are the national standards established
for the X12 837 5010, as set forth in the TR3 implementation guides. In addition, CMS has supplemental guidance
for a subset of loops, segments, and data elements for requirements unique to MA EDRs and CRRs. CMS’
supplemental requirements are described in Chapter 3, “MA Companion Guide for EDR and CRR Submissions” and
in Appendix 3A. “MA Companion Guide: CMS’ Supplemental Instructions for EDR & CRR Data Elements”
To process the loops, segments, and data elements necessary for ED submission, CMS’ EDS implements
several phases of processing for institutional, professional, and Durable Medical Equipment (DME) EDRs and
CRRs.
Records passing the final round of edits are sent from the EDFES to the back-end system EDPS for detail
processing and pricing.
Chapter 1
Page 3 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Finally, as shown in Figure 1.1, data processed through EDPS from EDRs and CRRs are sent to a CMS data
warehouse for storage. The subsystem RAS extracts accepted data from EDRs and CRRs from the data warehouse,
identifies (“filters”) risk adjustment eligible diagnoses for use in calculating encounter data-based risk scores (and
also extracts RAPS data to calculate risk scores based on RAPS data; see next section). The RAS generates an
MAO-004 report, which lists all diagnoses from accepted EDRs and CRRs, and identifies whether they are eligible
for risk adjustment.
Chapters 4 and 5 provide details on all phases of ED processing.
1.4. Use of this Guide
Guidance in this document regarding the submission of EDRs and CRRs for institutional, professional, and
DME services and items is not intended to be a stand-alone resource for requirements. To report an encounter in the
X12 837 5010 format, MAOs and other submitters must refer to the national Technical Report Type 3 (TR3) guides
listed below and must refer to CMS’ supplemental guidance discussed in this guide, particularly in Chapter 3, “MA
Companion Guide for EDR and CRR Submissions.”
• ASC X12 Standards for Electronic Data Interchange Technical Report Type 3, Health Care Claim: Institutional
(837)
• ASC X12 Standards for Electronic Data Interchange Technical Report Type 3, Health Care Claim: Professional
(837)
In addition, this guide must be used in conjunction with the following:
• The Medicare Advantage & Part D Communications Handbook (formerly called the EDFES User Guide), which
can be found at http://www.csscoperations.com, has instructions on connecting to and transferring files with
EDFES
• CMS’ 5010 & CCEM Edit Spreadsheets reflect Medicare’s supplemental instructions to the TR3 Guides. The
links to the spreadsheets are listed in Table 1.1.
Chapter 1
Page 4 of 6
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
1.5. Resources for Risk Adjustment Data Submission
Table 1.1. Encounter Data and RAPS Data Resources
Resource Name
Resource Description
Resource Link
Type 3 Technical
Report
The Washington Publishing Company (WPC)
has a grouping of documents that addresses
the 837-I and 837-P. It provides rules that
MAOs and other entities must support in
order to submit encounter data. It is intended
to comply with the data standards mandated
by the Health Insurance Portability and
Accountability Act of 1996.
http://www.wpc-edi.com/
CMS CEM 5010 &
CCEM Edit
Spreadsheets
CMS provides X12 5010 file format technical
edit spreadsheets for the 837-I and 837-P. The
edits included in the spreadsheet pertain to
requirements in the TR3 guides and also
reflect supplemental instructions specific to
Medicare. Users need to use the CMS 5010
Edit Spreadsheet in combination with
Appendix 4A of this guide to understand
which of the EDI edits apply to encounter
data.
https://www.csscoperations.com/internet/
csscw3.nsf/DID/54CKABNKVQ
MA & Part D
Communications
Handbook
Supplemental guide for connecting to the ED
& RAPS systems to submit data and receive
reports. (The Handbook is a consolidation of
the EDFES User Guide, the FERAS User
Guide, and the PDFS User Guide.)
http://www.csscoperations.com
ED Submission
and Processing
Guide
A consolidated technical guide on how to
populate and submit encounter data records
and RAPS data records that comply with
CMS guidance. In addition, the guide
provides information on how these records are
processed in CMS’ systems and what reports
submitters receive from CMS, and provides
tips on problem resolution in response to
system edits and reports.
http://www.csscoperations.com
User Group Slides
and Q&As
As an outreach method, CMS conducts User
Groups webinars to update the industry on
key issues of interest. Presentation slides and
post-webinar Questions & Answer documents
are maintained on the CSSC Operations
website.
http://www.csscoperations.com
CMS = Centers for Medicare & Medicaid Services; CEM = Common Edits and Enhancements Module;
CCEM = Combined Common Edits/Enhancements Module; MA = Medicare Advantage; ED = encounter data;
RAPS = encounter data; MAO = Medicare Advantage Organization; TR3 = Technical Report Type 3; EDFES =
Encounter Data Front-End System; FERAS = Front-End Risk Adjustment System; PDFS = Prescription Drug FrontEnd System; CSSC = Customer Service and Support Center.
Chapter 1
Page 5 of 6
This page left intentionally blank for double-sided copying.
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Chapter 2. Encounter Data Submission Requirements
2.1.
DEFINITION OF AN ENCOUNTER DATA RECORD ............................................................................... 2
2.2.
DEFINITION OF A CHART REVIEW RECORD ........................................................................................ 2
2.3.
LINKED AND UNLINKED CHART REVIEW RECORDS ......................................................................... 3
2.3.1.
Linked CRRs..................................................................................................................................... 4
2.3.2.
Unlinked CRRs ................................................................................................................................. 4
2.3.3.
Replacement CRRs ........................................................................................................................... 5
2.3.4.
Void CRRs ........................................................................................................................................ 6
2.3.5.
Submission of Data Collection Year Diagnoses on CRRs ................................................................ 6
2.4.
ENTITIES REQUIRED TO SUBMIT ENCOUNTER DATA ....................................................................... 6
2.5.
TERMINATED CONTRACTS – SUBMISSION REQUIREMENTS........................................................... 7
2.6.
REQUIRED X12 837 5010 FORMAT FOR EDR AND CRR SUBMISSIONS ............................................ 8
2.7.
ICD-9-CM AND ICD-10-CM DIAGNOSIS CODES .................................................................................... 8
2.7.1.
Encounters with Dates of Service Spanning the ICD-10 Transition Date......................................... 8
2.7.2.
Use of ICD-9-CM Codes E and V .................................................................................................... 8
2.7.3.
Use of ICD-10-CM Codes V, W, Y, & Z ......................................................................................... 9
2.8.
LEVEL II HCPCS S-CODES ......................................................................................................................... 9
2.9.
HEALTH INSURANCE PROSPECTIVE PAYMENT SYSTEM CODES FOR HOME HEALTH
AND SKILLED NURSING FACILITY EDRS .............................................................................................. 9
2.9.1.
Home Health Encounters and HIPPS Codes ................................................................................... 11
2.9.2.
SNF Encounters and HIPPS Codes ................................................................................................. 11
2.9.3.
HIPPS Codes Not Required for CAH Encounters .......................................................................... 13
2.10.
MEDICAID SERVICES ............................................................................................................................... 13
2.11.
ED MONITORING AND COMPLIANCE GUIDANCE ............................................................................. 13
________________________________________
Chapter 2
Page 1 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
2.1. Definition of an Encounter Data Record
MAOs and other entities are required to submit to CMS “the data necessary to characterize the context and
purposes of each item and service provided to a Medicare enrollee,” as described in Chapter 1.
An encounter data record (EDR) is a report from a Medicare Advantage Organization (MAO) or other
submitter to CMS about medical items or services a beneficiary received while enrolled in one of the MAO’s plans.
Thus, all information included on an EDR for an item or service must be related to the specific item or service about
which the encounter data record is reporting.
In operational terms, we use the term encounter data record or EDR to refer to the current Version 5010 of the
ASC X12 837 standard format, where X12 refers to healthcare transactions, 837 refers to an electronic format for
institutional (837-I) and professional (837-P) encounters, and 5010 refers to the most recent version. CMS requires
that MAOs and other entities submit EDRs using the X12 837 5010 format to fulfill the reporting requirements at 42
Code of Federal Regulations 422.310. When populating the 5010, MAOs and other submitters should populate data
fields in conformance with CMS submission requirements in order to complete successful submission to CMS’s
Encounter Data System. We remind MAOs that established risk adjustment rules apply to diagnoses submitted on
EDRs that are used for risk adjustment; for instance, these diagnosis codes must be documented in the medical
record and must be documented as a result of a face-to-face visit in the data collection period for the payment year
CMS expects that MAOs and other entities will submit EDRs for each service or item covered by the plan and
provided to an enrollee, regardless of the payment status of the claim (for example, accepted or denied for payment
by MAO). Because an EDR is a record of a service or item covered by the plan and provided to an enrollee while
enrolled in that plan, the MAO’s final adjudication status of a claim from a provider is not relevant to the MAO’s
submission of an EDR report to CMS.
Default data. See Chapter 3 regarding the limited set of circumstances where default data may be used for
certain fields in the X12 837 5010 EDR.
For additional information on risk adjustment eligibility rules, see Chapter 7 on Risk Adjustment in the
Medicare Managed Care Manual found at https://www.cms.gov/Regulations-andGuidance/Guidance/Manuals/downloads/mc86c07.pdf.
2.2.
Definition of a Chart Review Record
A chart review record (CRR) is distinct from an EDR. Similar to the role of a Risk Adjustment Processing
System (RAPS) data record, the role of a CRR is to allow MAOs to add risk adjustment eligible diagnoses or delete
diagnosis codes previously reported for plan enrollees, as noted in the April 9, 2018, Health Plan Management
System (HPMS) memo “Guidance for Chart Review Record (CRR) Submissions.” Accordingly, diagnosis codes
Chapter 2
Page 2 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
added through a CRR must be derived from a face-to-face visit and supported by a medical record, as discussed in
Chapter 7 on Risk Adjustment in the Medicare Managed Care Manual found at https://www.cms.gov/Regulationsand-Guidance/Guidance/Manuals/Downloads/mc86c07.pdf
Although existing guidance allows MAOs and other submitters to provide default values for Current
Procedural Terminology (CPT)/ Healthcare Common Procedure Coding System (HCPCS) codes on CRRs, default
data must be submitted consistent with the CMS filtering logic. In other words, diagnoses that are not risk
adjustment eligible should not be submitted with default HCPCS codes that would cause the diagnoses to be
allowed. For example, a diagnosis code resulting from a lab test that would have been excluded from risk adjustment
by the professional filtering logic because the CPT/HCPCS code for the lab visit was not included on the list of
allowable CPT/HCPCS codes for the service year should not be submitted on a CRR with an allowable default
CPT/HCPCS code.
Similarly, data elements such as beneficiary ID, beneficiary name, and the dates of service, should preserve the
ability to identify the associated encounter and medical record from which the CRR was created.
Specifically, there are two scenarios when a CRR may be submitted:
1.
The encounter generated more diagnosis codes than the maximum number of diagnosis code spaces on an EDR
(12 for professional, 25 for institutional). CRRs are intended to allow for the addition of risk adjustment-eligible
diagnoses if the additional diagnoses do not fit on the EDR.
2.
The MAO performed a medical record review and identified risk adjustment-eligible diagnosis codes that
should be added or diagnosis codes that must be deleted for a beneficiary, and these diagnosis codes are related
to an encounter that has already been reported on an EDR. In other words, if an encounter is identified from a
chart review, MAOs should submit the report of that encounter on an EDR, and if necessary, MAOs may use a
CRR to report diagnoses that were not included when the EDR was submitted.
MAOs should report items and services on an EDR, whether or not the items and services resulted in the
creation of a claim from the provider to the MAO. Items or services provided to an enrollee under the plan must be
reported on an EDR. A CRR should not be the only record with information about a healthcare item or service
provided to a plan enrollee. As stated above, a CRR may be used to add risk adjustment-eligible diagnosis codes or
delete diagnosis codes to a previously submitted and accepted EDR.
2.3.
Linked and Unlinked Chart Review Records
There are two ways to submit a CRR in a 5010 format: linked and unlinked. Linking a CRR to a previously
accepted EDR allows an MAO to associate risk adjustment-eligible diagnoses with specific items or services
provided to a beneficiary. Although we do not edit to ensure the linked CRR matches the encounter it is linked to,
identifying information, such as the beneficiary Health Insurance Claim Number or Medicare Beneficiary Identifier
(MBI), must match in order to associate the diagnoses on the CRR with the beneficiary who received the associated
services.
Chapter 2
Page 3 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
A linked CRR can be submitted to add diagnosis codes to a previously submitted and accepted EDR or CRR,
or it can be submitted to delete diagnosis codes from a previously submitted and accepted EDR or CRR. Any CRR
submitted to delete diagnosis codes from a previously accepted EDR or CRR must be linked.
An unlinked CRR may only be submitted to add risk adjustment-eligible diagnosis codes and does not
identify a previously submitted EDR that the submitted diagnoses should be associated with.
The REF02 data element can be used to link chart review records to encounter data records or to other chart
review records. To designate a record as a chart review record, use the PWK01 and PWK02 data fields in loop 2300.
PWK01 should be set to ‘09’ and PWK02 should be set to “AA”.
Note: EDRs cannot be submitted to replace CRRs, and CRRs cannot be submitted to replace EDRs.
Additional guidance specific to linked and unlinked CRRs is provided below.
2.3.1.
Linked CRRs
Although a single CRR is subject to the 837 5010 limit on the number of diagnosis codes, there is no limit on
the number of CRRs that may be linked to an EDR or CRR.
Linked CRR-Add
A Linked CRR-Add contains the Internal Control Number of a previously submitted and accepted EDR or
CRR. Further, the value in field CLM05-3 Claim Frequency Type Code (Loop 2300) must not equal 7 (replace) or 8
(void/delete), unless the intention is to replace (7) or void (8) another previously accepted CRR.
Linked CRR-Delete
A Linked CRR-Delete contains the Internal Control Number of a previously submitted and accepted EDR or
CRR and the patient medical record number equal to 8 in the Loop 2300 segment (REF01 = “EA”/ REF02 = “8”). If
an MAO wishes to delete one or more diagnosis codes from a previously accepted EDR or CRR, each diagnosis
code to be deleted must be listed on the Linked CRR-Delete record. The primary diagnosis on a chart review is not
required to match the primary diagnosis on the encounter to which it is linked.
For example, if diagnoses AAA and BBB were submitted on the EDR or CRR and are to be deleted, then the
CRR-Delete must also be submitted with diagnoses AAA and BBB.
A single linked CRR cannot both add and delete diagnoses. If both operations must be performed, separate
CRRs will need to be submitted.
2.3.2.
Unlinked CRRs
As noted above, Unlinked CRRs can only be used to add risk adjustment-eligible diagnoses. There is no limit
to the number of unlinked CRRs that may be submitted. An Unlinked CRR should not contain the Internal Control
Chapter 2
Page 4 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Number of a previously submitted and accepted EDR or CRR. Unlinked CRRs attempting to delete diagnoses will
be rejected with edit code 00805 – Deleted Diagnosis Code Not Allowed.
Unlinked CRRs may be used to submit additional diagnoses that had not been previously reported i.e.,
diagnoses found through a medical record review, as long as the additional diagnoses reported on a CRR meet CMS
filtering and risk adjustment criteria.
Table 2.1 Chart Review Records Summary Table
CRR Type
Linked
Unlinked
Add
PWK01/02 ='09'/'AA'
REF01/02 (Payer Claim Control Number) = 'F8'/
ICN of previously accepted record
CLM05-3 = '1' or '7' or '8'
HI01-1/2 ='BK'/ 'diagnosis code'
PWK01/02 ='09'/'AA'
CLM05-3 = '1'
HI01-1/2 ='BK'/'diagnosis code'
Delete
PWK01/02 ='09'/'AA'
REF01/02 (Payer Claim Control Number) = 'F8'/
ICN of previously accepted record
CLM05-3 = '1' or '8‘ (see note below)
HI01-1/2 ='BK'/ 'delete diagnosis code'
REF01/02 (Medical Record Number) = 'EA' / '8'
N/A
2.3.3.
Replacement CRRs
A Replacement CRR-Add contains the ICN of a previously accepted CRR and a Claim Frequency Type
Code = 7. Replacement CRRs can only be used to replace a previously accepted linked or unlinked CRR. When a
replacement is submitted for a CRR, the replacement record must also be a CRR. EDRs should not be submitted to
replace CRRs. Diagnoses on the replacement, but not on the previously accepted CRR will be added, and diagnoses
not on the replacement, but on the previously accepted CRR will be deleted.
A Replacement CRR-Delete submitted for a Linked CRR-Delete is not an acceptable submission. If a
Replacement CRR-Delete is submitted, it will be rejected by the EDS (please see Chapter 6 for detailed information
on selected edits). Submitters must void the previously accepted Linked CRR-Delete records to nullify the delete
action.
Table 2.2 illustrates the claim information necessary for replacing a previously submitted EDR or CRR.
Table 2.2 Claim information – replacing a previously submitted EDR or CRR
Loop 2300
•
CLM05-3 = ‘7’
•
REF01 = ‘F8’
Chapter 2
Page 5 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Loop 2300
•
REF02 = ICN of the original accepted encounter
2.3.4.
Void CRRs
A Void CRR-Add or Void CRR-Replacement submitted for a previously accepted Linked CRR-Add,
Replacement, or Unlinked CRR will void the previously accepted CRR.
A Void CRR-Delete submitted for a previously accepted Linked CRR-Delete will void the previously accepted
Linked CRR-Delete. By reversing the original Linked CRR-Delete, diagnoses that were previously not considered
for risk adjustment will again be considered.
Table 2.3 illustrates the claim information necessary for voiding a previously submitted EDR or CRR.
Table 2.3 Claim information – voiding a previously submitted EDR or CRR
Loop 2300
•
CLM05-3 = ‘8’
•
REF01 = ‘F8’
•
REF02 = ICN of the original accepted encounter
2.3.5.
Submission of Data Collection Year Diagnoses on CRRs
MAOs are able to submit diagnoses on chart review records from a date of service when the beneficiary was in
the contract of another parent organization, but not if they were in FFS. CMS modified the EDPS logic to bypass
edit 02240 for chart review records to accommodate this guidance.
This guidance in no way creates an obligation for any organization to provide diagnoses data to another
organization. MAOs should take into account any operational, burden, or legal considerations when determining
how to proceed. In addition, we remind MAOs that all risk adjustment and other applicable regulations and laws
apply to the submission of these diagnoses on CRRs, just as they do when submitting diagnoses for beneficiaries
who were enrolled in their own contract in the prior year.
2.4.
Entities Required to Submit Encounter Data
CMS requires organizations offering the following types of Medicare private health plans to submit encounter
data for plan enrollees. Table 2.4 summarizes the requirements by type of organization and plan.
Chapter 2
Page 6 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 2.4. Entities Required to Submit Encounter Data
Organization Type
Plan Types
Requirements
Medicare Advantage
Organizations
(MAOs)
1. Coordinated Care Plans (CCPs)*
• Health Maintenance
Organizations (HMOs)
• Local and Regional Preferred
Provider Organizations (PPOs)
2. Private Fee-for-Service (PFFS)
Plans
3. Medical Savings Account (MSA)
Plans
Effective January 2012, submit encounter data
records to report all items and services provided
under the plan, regardless of the payment status
of any claim—that is, regardless of whether a
claim is accepted or denied for payment, as long
as the item or service was received by the
beneficiary.
Submit encounter data records only for
Medicare services, not for Medicaid services.
Organizations
offering cost plans
Section 1876 Cost
HMOs/Competitive Medical Plans
(CMPs)
Section 1833 Health Care Prepayment Plans (HCPPs)
Effective January 2012, submit encounter data
records to report all Medicare-covered
items/services for which the plans claim
Medicare costs on their CMS Cost Reports.
Program of AllInclusive Care for the
Elderly (PACE)
Organizations
PACE plans
Effective January 2013, submit encounter data
records for Medicare-covered items and services
for which the organization collects claims.
Medicare-Medicaid
Plan (MMP)
demonstrations
MMPs
MMPs are not discussed in this guide. See the
August 10, 2016, Health Plan Management
System (HPMS) memos containing MMP
requirements regarding encounter data available
on the HPMS website at
https://www.cms.gov/Research-Statistics-Dataand-Systems/Computer-Data-andSystems/HPMS/HPMS-Memos-ArchiveAnnual.html.
* Special Needs Plans (SNPs) are a type of Coordinated Care Plan with enrollment open to beneficiaries with certain
statuses. That is, SNPs can be HMOs or PPOs.
2.5.
Terminated Contracts – Submission Requirements
In general, MAOs and cost plans with nonrenewing contracts are required to submit risk adjustment data and
attestations to CMS for the nonrenewing contracts. Risk adjustment data include both encounter data and RAPS
data.
Generally, CMS annually releases instructions for terminated contracts that ended December 31 of a given
calendar year, including deadlines for complying with the guidance. These letters include deadlines for data
submission for terminated contracts. HPMS memos regarding terminated contracts can be found at
https://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/HPMS/HPMS-MemosArchive-Annual.html.
Chapter 2
Page 7 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
2.6.
Required X12 837 5010 Format for EDR and CRR Submissions
For the submission of EDRs and CRRs, CMS has identified a subset of loops, segments, and fields from the
healthcare transaction format X12 837 5010 that must be submitted regardless of the source of data, that is,
regardless of whether the data regarding the encounter or chart review are taken from a 5010 record, a 4010 record,
a paper claim, a foreign claim, an electronic health record or medical record review process. Formerly, CMS
referred to this subset of 5010 837 field as Minimum Data Elements (MDEs).
Going forward, CMS will call this subset of 837 5010 fields the TR3 Fields Necessary for EDR & CRR
Submissions. In this context, the term field refers to 837 5010 combinations of loops, segments, and data elements.
For a discussion of CMS’ supplemental instructions regarding these necessary fields (for example, instructions on
how to submit EDRs and CRRs for services covered under capitated payment arrangements), see Chapter 3, “MA
Companion Guide for EDR and CRR Submissions,” and Appendix 3A, “MA Companion Guide: CMS’
Supplemental Instructions for EDR and CRR Data Elements.”
An MAO or other submitter may choose, but is not required, to submit additional fields (loops, segments, data
elements) from the 837 5010 format beyond the CMS “Fields Necessary” list. Note that MAOs electing to submit
loops, segments, and data elements not required by CMS must follow the TR3 guides and populate all related fields
required by the TR3 for these additional loops, segments, and data elements, to avoid having the files and/or record
fail CMS’ edits.
2.7.
ICD-9-CM and ICD-10-CM Diagnosis Codes
2.7.1.
Encounters with Dates of Service Spanning the ICD-10 Transition Date
For encounters with dates of service that span the ICD-10 transition date of October 1, 2015, MAOs are
required to “split” these EDRs and include ICD-9 codes for dates of service through September 30, 2015, and
include ICD-10 codes with “from” and “through” dates of service beginning October 1, 2015, and beyond.
2.7.2.
Use of ICD-9-CM Codes E and V
In ICD-9-CM Coding Guidelines, codes with a letter as first character in the coding sequence indicate a
supplemental code. E-codes (External Causes of Injury) are used as supplemental codes to describe the circumstance
causing an injury, not the nature of the injury. Therefore, based on ICD-9-CM rules, an E-code cannot be submitted
as the primary diagnosis code for any EDR.
If an MAO wishes to add an E-code (and/or Manifestation codes) through a CRR with such a code in the
primary diagnosis field, the CRR submitted must be linked to a previously accepted EDR, and the primary diagnosis
field on the CRR should be populated with the diagnosis code used in the EDR to which the CRR links. If an MAO
needs to delete an E-code, the MAO has two options: (1) submit a CRR that uses the primary diagnosis code as a
Chapter 2
Page 8 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
code other than the E-code and then lists the E-code, causing both codes to be deleted, then submit a second CRR
that adds the primary diagnosis code back to the beneficiary’s record, or (2) submit a replacement EDR that
excludes the E-code from the list of diagnosis codes. These options can be used in all situations in which certain
diagnosis codes cannot be used to populate the primary diagnosis code field.
ICD-9-CM V-codes (Factors Influencing Health Status and Contact with Health Services) are supplemental
codes used for coding services such as receiving a vaccination or having a history of an illness. When an ICD-9-CM
V-code is acceptable as a primary diagnosis on an EDR, the EDS also will accept that V-code as a primary diagnosis
on a CRR.
2.7.3.
Use of ICD-10-CM Codes V, W, Y, & Z
In ICD-10-CM, all codes have a letter as the first character in the code sequence. The E-code under ICD-10
CM is now used for Endocrine, Nutritional, and Metabolic Diseases. Supplemental codes for External Causes of
Injury under ICD-10 CM are classified under codes V through Y (External Causes of Morbidity) and are secondary
to codes for injury, poisoning, and certain other consequences of external causes (codes A through T). When an
ICD-10-CM Z-code (Factors Influencing Heath Status and Contact with Health Services) is acceptable as a primary
diagnosis on an EDR, the EDS also will accept the Z-code as a primary diagnosis for a CRR.
For information on ICD-10 coding, see the CMS website at https://www.cms.gov/Medicare/Coding/ICD10/.
2.8.
Level II HCPCS S-Codes
Level II HCPCS S-codes are primarily used by private insurers to report drugs, services, and supplies for
which there are no national codes but for which codes are needed by the private sector to implement policies,
programs, or claims processing. Their purpose is to meet the particular needs of the private sector. These codes may
also be used by Medicaid programs, but they are not payable by Medicare, as noted in CMS’ document “Healthcare
Common Procedure Coding System (HCPCS) Level II Coding Procedures,” which is available at
https://www.cms.gov/Medicare/Coding/MedHCPCSGenInfo/Downloads/2018-11-30-HCPCS-Level2-CodingProcedure.pdf.
MAOs may use S-codes on EDRs for any service types. The EDFES does not reject S-codes; that is, these
codes have been added to a reference table in the CCEM.
2.9.
Health Insurance Prospective Payment System Codes for Home
Health and Skilled Nursing Facility EDRs
Health Insurance Prospective Payment System (HIPPS) codes represent specific sets of patient characteristics
(or case-mix groups) on which payment determinations are made under several prospective payment systems. Casemix groups are developed based on research into utilization patterns among various provider types. Home Health
Chapter 2
Page 9 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Agency (HHA) HIPPS codes are determined based on assessments made using the Outcome and Assessment
Information Set (OASIS) data collection tools. Skilled Nursing Facility (SNF) HIPPS codes are determined based on
assessments made using the Minimum Data Set data collection tools.
Table 2.5. Summary of HIPPS Codes Submissions on SNF and HHA Encounter Data Records
SNF Encounter Data Records
HHA Encounter Data Records
TOB = 18X or 21
TOB = 32X
Claim From Date of Service (DOS) is equal to or
greater than 07/01/2014
Claim From DOS is equal to or greater than
07/01/2014
Revenue Code = 0022
Revenue Code = 0023
Claim From DOS is equal to or greater than
07/01/2014
Claim From DOS is equal to or greater than
07/01/2014
Revenue Code = 0022
Revenue Code = 0023
TOB = Type of Bill.
If MAOs do not have information from the initial assessment, they are encouraged to submit the HIPPS codes
from other comprehensive Omnibus Reconciliation Act (OBRA) assessments and/or Prospective Payment System
(PPS) assessments (for SNF encounters) or the HIPPS codes from any completed assessment (for HHA encounters).
HIPPS codes from SNF or HHA encounters with “from” dates prior to July 1, 2014, may be submitted (that is, they
will not be rejected). SNF and HHA encounters that are submitted without a HIPPS code “from” dates July1, 2014,
or after will be rejected.
SNF and home health encounters must be submitted in the 837-Institutional format. CMS encourages MAOs
and other entities to continue to work with SNF and HHA providers to meet this requirement. Medicare Fee-forService (FFS) has introduced new payment models for home health (HH) and SNF services. With the September 27,
2019 release of the Medicare Advantage Encounter Data System, CMS updated the HIPPS code sets used in the
Encounter Data System to incorporate the new HIPPS code sets. In order to allow providers and MAOs maximum
flexibility in the submission of HIPPS codes on encounter data, CMS accepts the existing HIPPS codes as well as
the new HIPPS codes.
•
SNF encounters with “from” dates on or after October 1, 2019 and HH encounters with “from” dates of
service on or after January 1, 2020 may be submitted using the existing HIPPS codes or the new HIPPS
codes.
•
SNF encounters with “from” dates of service prior to October 1, 2019 should continue to be submitted with
existing HIPPS codes.
Chapter 2
Page 10 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
•
HH encounters with “from” dates of service prior to January 1, 2020 should continue to be submitted with
existing HIPPS codes.
•
For SNF stays lasting 14 days or less in which an Admission assessment was not completed prior to
discharge, MAOs should follow the guidance outlined in the December 4, 2014 HPMS memorandum with
the subject line: “Additional Guidance Regarding Submission of Health Insurance Prospective Payment
System (HIPPS) Codes to Encounter Data System.” As noted in that memo, MAOs may submit the HIPPS
code from another assessment that took place during the stay or submit a default HIPPS code.
o
The default HIPPS code for encounters with a “from” date of service prior to October 1, 2019 is
“AAA00.” The default HIPPS code for encounters with “from” date of service on or after October
1, 2019 is “ZZZZZ.”
For additional information on HIPPS codes, see the May 23, 2014, HPMS memo “Submission of Health
Insurance Prospective Payment System (HIPPS) Codes to Encounter Data System” and the CMS website
https://www.cms.gov/Medicare/Medicare-Fee-for-Service-Payment/ProspMedicareFeeSvcPmtGen/
HIPPSCodes.html.
2.9.1.
Home Health Encounters and HIPPS Codes
For 2014 dates of service beginning on or after July 1, MAOs must submit a HIPPS code on an HHA
encounter that comes from the initial Outcome and Assessment Information Set (Start of Care assessment), or
OASIS. Applicable HHA Institutional encounters include TOB 32X (Home Health Inpatient Part B Services under a
Plan of Treatment). HIPPS codes are not applicable on TOB 034X (for example, the MAO is providing
supplemental benefits).
The OASIS assessments are federally mandated for all Medicare and/or Medicaid patients receiving skilled
care from HHAs. For 2014 encounter data submissions, CMS does not require MAOs to submit HIPPS codes from
any other assessments other than the initial assessment. Nevertheless, we encourage MAOs to submit the HIPPS
codes from any completed assessments when available from the providers.
2.9.2.
SNF Encounters and HIPPS Codes
For 2014 dates of service beginning on or after July 1, MAOs must submit a HIPPS code on a SNF encounter
that comes from the initial OBRA-required comprehensive assessment (Admission Assessment). Applicable SNF
Institutional Inpatient facilities include non-Critical Access Hospital facilities with Type of Bills (TOBs), such
as18X Hospital Swing Beds and 21X Skilled Nursing Inpatient (Medicare Part A).
SNF encounters that are submitted with the service line “from” dates July 1, 2014, or after and a revenue code
0022 and without a valid HIPPS code will be rejected. The OBRA-required tracking records and assessments are
federally mandated for all residents of Medicare and/or Medicaid certified SNFs and nursing facilities.
Chapter 2
Page 11 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
For 2014 encounter data submissions, CMS does not require MAOs to submit HIPPS codes from any other
OBRA-required comprehensive or noncomprehensive assessments other than the Admission Assessment. We also
do not require submission of HIPPS codes for any scheduled or unscheduled SNF PPS assessments. Nevertheless,
we do encourage MAOs to submit the HIPPS codes both from other OBRA assessments and from PPS assessments
when available from the providers. We especially encourage submission of the HIPPS code based on the Discharge
Assessment, which is based on an OBRA-required assessment.
When no Admission assessment was completed during the MA-covered stay, MAOs shall follow the following
guidance, originally released in a December 4, 2014, HPMS memo “Additional Guidance Regarding Submission of
Health Insurance Prospective Payment System (HIPPS) Codes to Encounter Data System”:
I.
Stays of more than 14 days. If the Admission assessment for a stay in the facility was completed prior to the
MA-covered portion of the stay, MAOs must submit to CMS a HIPPS code by following the guidance in the
order they are listed below.
A. Submit the HIPPS code from another assessment completed during the MA-covered portion of the
stay. If the OBRA Admission assessment was completed for the current stay prior to the MA-covered
portion of the stay, and another assessment (for example, Quarterly Assessment or any PPS assessment
required by the MAO) was completed during the MA-covered portion of the stay, the MAO shall submit
the HIPPS code generated from that other assessment on their encounter submissions to CMS.
B. Submit the HIPPS code from the most recent assessment that was completed prior to the MAcovered portion of the stay. If no assessment was completed during the MA-covered portion of the stay
from which a HIPPS code could be generated, the MAO shall submit to CMS the HIPPS code from the
most recent OBRA or other assessment that was completed prior to the MA-covered portion of the stay
(which may be the Admission assessment). 1
II.
Stays of 14 days or less. If there was no Admission assessment completed before discharge for a stay of less
than 14 days, MAOs must submit a HIPPS code to CMS by following the guidance in the order listed below.
A. When to submit the HIPPS code from another assessment from the stay. If no OBRA Admission
assessment was completed for a SNF stay of less than 14 days, the MAO shall submit to CMS the HIPPS
code from any other assessment that was completed during the stay that produces a HIPPS code. 2
1
CMS understands that some MAOs require providers to conduct assessments similar to those used under
traditional Medicare Part A PPS rules. Providers may submit to MAOs, and MAOs can submit to the EDS, HIPPS
codes derived from the same item set and data specifications as those used under the SNF PPS. We note that in such
cases, providers must not to submit these assessments through the traditional PPS assessment system.
2
CMS understands that some MAOs require providers to conduct assessments similar to those used under
traditional Medicare Part A PPS rules. Providers may submit to MAOs, and MAOs can submit to the EDS, HIPPS
codes derived from the same item set and data specifications as those used under the SNF PPS. We note that in such
cases, providers must not to submit these assessments through the traditional PPS assessment system.
Chapter 2
Page 12 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
B. When to submit a default HIPPS code of “AAA00”. MAOs may submit a default HIPPS code for SNF
encounter submissions to CMS only if (1) the SNF stay was less than 14 days within a spell of illness, (2)
the beneficiary has been discharged prior to the completion of the initial OBRA Admission assessment,
and (3) no other assessment was completed during the stay. 3 To submit a default HIPPS code to the
Encounter Data System, MAOs should use the default Resource Utilization Group code of “AAA” and
Assessment Indicator “00” on encounter data submissions starting with “from” dates of service July 1,
2014.
MAOs may not use this default code in other situations, such as to avoid collecting the proper
HIPPS code, or when the MAO’s systems are not prepared to submit the HIPPS code to CMS. HIPPS
codes are not applicable for SNF institutional outpatient encounters.
2.9.3.
HIPPS Codes Not Required for CAH Encounters
When MAOs report encounters from Critical Access Hospitals (CAHs), CMS does not require the inclusion of
HIPPS codes. Specifically, encounters for CAH swing bed services (using the code TOB 18X Hospital Swing Bed)
are exempt from our HIPPS Code submission requirement. For additional information on CAHs, see the CMS
website https://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/CertificationandComplianc/
CAHs.html.
2.10.
Medicaid Services
MAOs or other organizations that adjudicate Medicaid claims for their members may not submit Medicaid
claims to CMS’ encounter data systems. There is one exception: demonstration plans called Medicare-Medicaid
Plans (MMPs) can submit Medicaid claims to the EDFES. MMPs are not addressed in this guide. For information
on MMPs submission guidance, please refer to the CMS website https://www.cms.gov/Medicare-MedicaidCoordination/Medicare-and-Medicaid-Coordination/Medicare-Medicaid-CoordinationOffice/FinancialAlignmentInitiative/FinancialModelstoSupportStatesEffortsinCareCoordination.html.
2.11.
ED Monitoring and Compliance Guidance
As required under sections 422.310(b) and (d), MAOs must submit risk adjustment data that characterize the
context and purpose of each item and service provided to a Medicare enrollee, and must also conform to CMS’
3
Per the Assessment Management Requirements and Tips for Comprehensive Assessments (pp. 2–17, Resident
Assessment Instrument Manual): “If a resident is discharged prior to the completion deadline for the assessment,
completion of the assessment is not required.” Federal statute and regulations require that SNFs and Nursing
Facilities (NFs) promptly assess residents upon admission but no later than the 14th calendar day of the resident’s
admission (admission date + 13 calendar days).
Chapter 2
Page 13 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
requirements for submitting these data and to all relevant national standards. In addition, at section 422.504(l), CMS
requires MAOs to certify to the accuracy, completeness, and truthfulness of their encounter data (based on best
knowledge, information, and belief).
As noted in the calendar year 2018 Call Letter section “CMS Monitoring and Compliance Activities Regarding
Encounter Data,” CMS stated that we expect that MAOs are conducting self-assessments regarding the accuracy and
completeness of their encounter data submissions for each contract they have with CMS, and that each year MAOs
apply the findings from their self-assessments to improve the accuracy and completeness of their encounter data
submissions. In this Monitoring and Compliance section, CMS established a compliance framework, including
identification of initial metrics for assessing completeness and accuracy, which can be found on pages 130 to 135 in
the calendar year 2018 Call Letter, in Attachment VIII in the Announcement of Calendar Year (CY) 2018 Medicare
Advantage Capitation Rates and Medicare Advantage and Part D Payment Policies and Final Call Letter and
Request for Information, on the CMS website at https://www.cms.gov/Medicare/HealthPlans/MedicareAdvtgSpecRateStats/Downloads/Announcement2018.pdf.
CMS has initiated several efforts to support MAO compliance with ED submission requirements, including
one-on-one communication with plans to resolve technical issues and gather information about submission
challenges, monthly user group calls, and site visits to MAOs. On June 22, 2017, CMS released an HPMS memo,
“Best Practices for Encounter Data Submission,” with approaches organizations can implement to evaluate, selfassess, and improve encounter data submissions.
In addition, CMS developed and distributes quarterly ED Report Cards for each contract, to report the status of
encounter data submissions as the information relates to CMS’ established benchmarks and submission
requirements. CMS encourages MAOs and other entities to use the data provided in the Report Cards to self-assess
and improve submissions as necessary.
On August 20, 2018, CMS released an HPMS memo, “CMS Monitoring and Compliance of Encounter Data”
which finalizes the encounter data performance metrics and thresholds. This memorandum discusses seven
performance metrics and their respective thresholds for MA encounter data (see Table 2.6). The thresholds are
designed to identify performance issues that are substantially below reasonable expectations for submissions. For
additional information on encounter data monitoring and compliance, see the August 20, 2018 memo at
https://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-and-Systems/HPMS/HPMS-MemosArchive-Weekly.html.
Table 2.6. Finalized Medicare Advantage Encounter Data Performance Measures and Thresholds
Performance Metric
O1: Failure to Complete End-to-end
Testing and Certification
Chapter 2
Performance Threshold (measured at contract level)
Failure to complete end-to-end testing and certification for a
contract within four (4) months of the beginning of operations.
Page 14 of 16
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Performance Metric
Performance Threshold (measured at contract level)
O2: Failure to Submit Any Accepted
Records to the Encounter Data System
No accepted records submitted during the calendar year.
O3: Excessive Submission of Encounter
Data Records at End of Risk Adjustment
Submission Window
Twenty-seven (27) percent or more of encounter data and chart
review records for the applicable calendar year were submitted
in the last two months before the risk adjustment deadline. The
purpose of this evaluation is to ensure that CMS systems are not
overloaded and that plans are regularly submitting data over
time.
C1: Extremely Low Volume of Overall
Encounter Data Records
The number of encounter data records per enrollee is below the
threshold. The threshold is the lower bound, using an 80%
confidence interval around the mean number of records per
enrollee, within each peer group.
Contracts are categorized into three different peer groups based
on contract types: (MSAs, Local or Regional PPOs, PFFS).
C2: Extremely Low Volume of Inpatient
Encounter Data Records
The number of enrollees with an accepted inpatient record in
EDS falls at or below 40% of the number of enrollees with an
inpatient RAPS record.
For example, if beneficiary A has an inpatient record in RAPS,
then beneficiary A should also have at least one inpatient record
accepted in EDS. If a contract has 100 beneficiaries for whom
there is at least one inpatient RAPS record and fewer than 40 of
those enrollees have an accepted inpatient record in EDS, then
the contract would not meet the performance threshold.
C3: Extremely Low Volume of Professional
Encounter Data Records
The number of enrollees with an accepted professional record in
EDS falls at or below 90% of the number of enrollees with a
professional RAPS record.
C4: Extremely Low Volume of Outpatient
Encounter Data Records
The number of enrollees with an outpatient record in EDS falls
at or below 70% of the number of enrollees with an outpatient
RAPS record.
Chapter 2
Page 15 of 16
This page left intentionally blank for double-sided copying.
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Chapter 3. MA Companion Guide for EDR and CRR Submissions
3.1.
3.2.
CONTENTS OF THE MA COMPANION GUIDE ....................................................................................... 3
3.1.1.
CMS’ Supplemental Instructions ...................................................................................................... 3
3.1.2.
Retiring the Minimum Data Element List ......................................................................................... 3
X12N 837 5010 FORMAT.............................................................................................................................. 4
3.2.1.
Loops, Segments, and Data Elements ............................................................................................... 4
3.2.2.
How to Populate an EDR or CRR ..................................................................................................... 6
3.2.3.
Edits .................................................................................................................................................. 7
3.3.
TIER II TESTING ENVIRONMENT............................................................................................................. 8
3.4.
NEW MEDICARE CARD PROJECT – THE MEDICARE BENEFICIARY IDENTIFIER ......................... 9
3.5.
3.6.
3.4.1.
General MBI Information ................................................................................................................. 9
3.4.2.
Specific MBI-related Changes to Transaction Reports ................................................................... 10
SUBMITTER OPTIONS FOR POPULATING CERTAIN DATA ELEMENTS ........................................ 10
3.5.1.
Default Data Reason Codes ............................................................................................................ 10
3.5.2.
Other Circumstances ....................................................................................................................... 11
3.5.3.
Demographic Data .......................................................................................................................... 12
3.5.4.
Diagnoses ........................................................................................................................................ 12
3.5.5.
Ambulatory Surgery Center Bypass................................................................................................ 12
3.5.6.
Line-level Duplicates Bypass .......................................................................................................... 12
3.5.7.
More than One EDR for a Single Provider Claim........................................................................... 13
NATIONAL PROVIDER IDENTIFIER AND EMPLOYER IDENTIFICATION NUMBER
GUIDANCE .................................................................................................................................................. 13
3.6.1.
Atypical Providers .......................................................................................................................... 14
3.6.2.
Default NPI Guidance ..................................................................................................................... 14
3.6.3.
Default EINs for Atypical Providers ............................................................................................... 16
3.7.
PWK SEGMENT FOR SPECIAL CONSIDERATIONS ............................................................................. 16
3.8.
ITEMS AND SERVICES COVERED UNDER CAPITATED ARRANGEMENTS .................................. 17
3.9.
APPROPRIATE PROCEDURE CODES ON CRRS.................................................................................... 18
Chapter 3
Page 1 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3.10.
POPULATING “OTHER PAYER PAID” FIELDS ..................................................................................... 18
3.11.
DME GUIDANCE ........................................................................................................................................ 18
3.11.1. DME Services Incident to Submissions .......................................................................................... 19
3.11.2. DMEPOS Supplier Services Submissions ...................................................................................... 19
3.12.
AMBULANCE ENCOUNTER PROCESSING ........................................................................................... 20
3.13.
TELEHEALTH ENCOUNTER PROCESSING ........................................................................................... 20
________________________________________
Chapter 3
Page 2 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3.1.
Contents of the MA Companion Guide
Typically, companion guides can contain two types of information: (1) instructions for electronic
communications with the entity publishing the guide (communications or connectivity instructions) and (2)
supplemental instructions for creating transactions with the publishing entity (that comply with standards in the
associated Technical Report Type 3 [TR3] guides).
Regarding the first type of information, the Centers for Medicare & Medicaid Services (CMS) instructions for
electronic communications are in the MA & Part D Communications Handbook, found on www.csscoperations.com.
Regarding the second type of information, this chapter and Appendix 3A include CMS’ instructions on
requirements unique to Medicare Advantage (MA) plan submissions of encounter data reports in the X12 837 5010
format, which supplement the TR3 guides.
3.1.1.
CMS’ Supplemental Instructions
To reflect circumstances unique to Medicare health plans, CMS identified a subset of data elements (and their
loop and segment locations in the 837 5010 format) for which CMS has specific instructions—for example, what
values to use in certain data elements to submit encounter data records (EDRs) and chart review records (CRRs) for
services and items received from capitated providers.
Previously, CMS provided three Companion Guides with instructions specific to the MA program, for
institutional, professional, and DME encounter data submissions (found on the www.csscoperations.com website,
and last updated in July 2016). For example, CMS provided instructions on how to submit EDRs and CRRs for
services covered under capitated payment arrangements.
Going forward, CMS has streamlined the three Companion Guides for the MA program into a single file for
institutional, professional, and DME encounter data records: see Appendix 3A, “MA Companion Guide: CMS’
Supplemental Instructions for EDR & CRR Data Elements” for this consolidated listing of instructions specific to
populating institutional, professional, and DME EDRs and CRRs for the MA program. Also see Chapter 3 for
additional discussion of topics regarding EDR and CRR submissions in the X12 837 5010 format.
3.1.2.
Retiring the Minimum Data Element List
In addition to the three Companion Guides, previously CMS also released a Minimum Data Elements list to
assist submitters, which offered a selected combination of TR3 guide instructions and CMS instructions
supplemental to the TR3 guides.
With the release of this guide, CMS has retired the Minimum Data Element list. See Appendix 3B for a
crosswalk from the retired Minimum Data Element List to Appendix 3A, the consolidated MA Companion Guide.
Chapter 3
Page 3 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3.2.
X12N 837 5010 Format
CMS requires that MAOs and other submitters use the X12 837 5010 format for submitting EDRs and CRRs.
The acronym ANSI ASC X12N refers to a national set of inter-industry standards for electronic data
interchange of insurance transactions. The X12N insurance standards include the transaction set 837, Health Care
Claim, which is used for billing and encounter transactions from providers to payers, and for reporting health care
services.
•
Version 5010 of the 837 transaction set establishes the 837-I (institutional), 837-P (professional), and 837-D
(dental). CMS requires the 837-I and 837-P for MA encounter data transactions for institutional and
professional encounters.
•
DME transactions are provided in the 837-P format.
•
As noted in the preface to this guide, the national implementation guides (IGs) for the X12N 5010 837-I and
X12N 5010 837-P are known as the TR3-I and TR3-P, respectively, shorthand for Standards for Electronic
Data Interchange Technical Report Type 3, Health Care Claim: Institutional (837) and Standards for
Electronic Data Interchange Technical Report Type 3, Health Care Claim: Professional (837).
•
Version 5010 of the X12N 837 was implemented in 2006 and was labeled 5010 X223 and 5010 X222 for
institutional and professional standards, respectively.
•
Version identifier. In subsequent years, the Accredited Standards Committee (ASC) X12 made changes to the
TR3 implementation guidance for the X12N 837 transaction sets. To identify the current versions, alphanumeric
characters have been added. Currently, the TR3-I is labeled 5010 X223A2 and the TR3-P is labeled 5010
X222A1. (These identifiers are populated in the GS Functional Group field GS08, Version/Release, Industry
Identifier Code.)
3.2.1.
Loops, Segments, and Data Elements
The X12 standard is organized as follows: loops consist of ordered segments (that is, a set of ordered
segments that repeat); segments consist of data elements; and the data element is the smallest named unit of
information in the ASC X12 standard. Data elements and segments are separated by delimiters (for example, an
asterisk and a tilde). Each data element, segment, and loop have unique identifiers, described in the TR3-I and TR3P guides. Segments are terminated by a distinct character (different from the data element separator).
In X12, the same segment can be used for different purposes. Thus, the meaning of data in a segment can
change based on the loop in which a segment is located. For example, the NM1 segment is used for names; the
names populated in the data elements of the NM1 segment depend on the loop: for example, Loop 2010AA Billing
Provider Name, Loop 2010BA Subscriber Name, or Loop 2010BB Payer Name.
Finally, certain X12 segments are paired to form an X12 enveloping structure containing nested segments, as
depicted in Figures 3.1 and 3.2, and Table 3.1. The levels of structure are the Interchange Control envelope
Chapter 3
Page 4 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
(segments ISA, IEA), the Functional Group segments (GS, GE), and the Transaction Set segments (ST, SE). The
ST/SE Transaction Set is the smallest meaningful set of information exchanged between trading partners and
contains the detail segments that have information on the claim, billing provider, subscriber, and patient.
Figure 3.1. X12 837 Standard Format, Version 5010
Figure 3.2. Example of X12 837 5010 Submission Format
ISA01 – ISA16 Interchange Control Header
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80882
*120430*1144*^*00501*200000031*1*P:~
Detail Segment
Transaction Set
ST01 – ST03 Transaction Set Header
ST*837*0534*005010X222A1~
Functional Group
Interchange Control Group
GS01 – GS08 Functional Group Header
GS*HC*ENH9999*80882*20120430*1144*69*X*005010X222A1~
BHT01 – BHT06 Beginning of Hierarchical Transaction
BHT*0019*00*000000223*20140428*1615*CH~
Loop, segments, and data elements – Some of these elements are situational and dependent upon the
encounter type. If the situation applies, the situational elements are required.
SE01 – SE02 Transaction Set Trailer
SE*38*0534~
EDS reports
follow the
sequence of the
submission
envelope from
submission file
syntax through
detailed line
items.
GE01 – GE02 Functional Group Trailer
GE*1*69~
IEA01 – IEA02 Interchange Control Trailer
IEA*1*200000031~
Note:
The file structure overview populated in this figure is an example and does not provide full details for
submission of all situational loops, segments, and data elements in the 837-P or 837-I.
Chapter 3
Page 5 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 3.1. X12 837 Enveloping Format
Envelope
Interchange
Functional
Group
Transaction
Set
3.2.2.
Header
ISA – designates Header Segment of Interchange Envelope
Contains Sender and Receiver Information
16 data elements
Example:
ISA*00* *00* *ZZ*ENH9999*ZZ*80881
*181101*1102*^*00501*000000031*1*P*:~
GS – designates Header Segment of Functional Group
Begins Functional Group
8 data elements
Example:
GS*HC*ENH9999*80881*20181101*1102*123456*X*00
5010X222A1~
ST – designates Header Segment of Transaction and type of
transaction
3 data elements
Examples:
(1) ST*837*4801*005010X222A1~
(2) ST*837*4802*005010X222A1~
Trailer
IEA – designates Trailer Segment of
Interchange Envelope
Closes Interchange
2 data elements
Example:
IEA*1*000000031~
GE – designates Trailer Segment of
Functional Group
Closes Functional Group
2 data elements
Example:
GE*1*123456~
SE – designates Trailer Segment of
Transaction
2 data elements
Examples:
(1) SE*28*4801~
(2) SE*43*4802~
How to Populate an EDR or CRR
When populating fields on EDRs or CRRs for submission to CMS, MAOs and other submitters should base their
logic on the highest level of specificity.
•
First, consult the WPC/TR3 guides.
•
Second, consult the CMS 5010 Edit Spreadsheets.
•
Third, consult this guide.
If broader options are expressed in the WPC/TR3 or the CMS 5010 Edit Spreadsheets than the options
identified in this guide, MAOs and other entities must use the rules identified in this guide.
Finally, MAOs and other submitters must use the most current national standard code lists applicable to the
X12 837 5010 transaction. The TR3 guides and code lists are accessible through the Washington Publishing
Company (WPC) homepage at http://www.wpc-edi.com. The applicable code lists include, but are not limited to, the
following:
• Claim Adjustment Reason Code (CARC)
• Claim Status Category Codes (CSCC)
• Claim Status Codes (CSC)
Table 3.2 lists the control segments and data loops required by the TR3 guides and additional situational loops
listed in the MA Companion Guide (Appendix 3A) for example ambulance Loops 2310E and 2310F.
Chapter 3
Page 6 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Note: An MAO or other submitter may choose to submit data elements from loops and segments other than
those listed in Table 3.2 but must be sure to follow instructions in the TR3 guides, for example about which data
fields are required under situational and required loops.
Table 3.2. Loops and Segments Required by the TR3 Guides and MA Companion Guide
Loop or Segment ID
Loop or Segment Name
Control Segments
ISA
INTERCHANGE CONTROL HEADER
IEA
INTERCHANGE CONTROL TRAILER
GS
FUNCTIONAL GROUP HEADER
GE
FUNCTIONAL GROUP TRAILER
ST
TRANSACTION SET HEADER
SE
TRANSACTION TRAILER
Data Loops
BHT
BEGIN HIERARCHICAL TRANSACTION
Loop 1000A
SUBMITTER NAME
Loop 1000B
RECEIVER NAME
Loop 2000A
BILLING PROVIDER HIERARCHICAL LEVEL
Loop 2010AA
BILLING PROVIDER NAME
Loop 2000B
SUBSCRIBER HIERARCHICAL LEVEL
Loop 2010BA
SUBSCRIBER NAME
Loop 2010BB
PAYER NAME
Loop 2300
CLAIM INFORMATION
Loop 2310E**
AMBULANCE PICK-UP LOCATION
Loop 2310F**
AMBULANCE DROP-OFF LOCATION
Loop 2320
OTHER SUBSCRIBER INFORMATION
Loop 2330A
OTHER SUBSCRIBER NAME
Loop 2330B
OTHER PAYER NAME
Loop 2400
SERVICE LINE
Loop 2430
LINE ADJUDICATION INFORMATION
** Professional EDRs only.
3.2.3.
Edits
Required data elements are subject to edits in the Encounter Data Front-End System (EDFES) (see Chapter 4)
and Encounter Data Processing System (EDPS) (see back-end) (Chapter 5). Generally, situational segments and
situational data elements are not subject to CMS system edits other than front-end syntax edits. (Note that if an
Chapter 3
Page 7 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
MAO populates a situational loop or segment, all required data elements must be populated.) However, CMS
expects that if a situation exists for a particular encounter, the MAO and other submitters will populate the relevant
data elements, as specified in the TR3 guides and the Appendix 3A companion guide.
3.3.
Tier II Testing Environment
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.
While not required, MAOs and other entities are strongly encouraged 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 also utilize the Tier II testing environment to submit chart review, replacement
or void encounters 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 5010 Edits
Spreadsheets, and other guidance outlined within this guide. The following are requirements for submission of Tier
II test files:
•
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).
In addition, please note the following:
•
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 rejected and returned
Similar to production encounter data, MAOs and other entities will receive the TA1, 999, and 277CA
Acknowledgement Reports and the MAO-002 Reports to help with the testing process.
Chapter 3
Page 8 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3.4.
New Medicare Card Project – the Medicare Beneficiary Identifier
The Medicare Access and CHIP Reauthorization Act (MACRA; CHIP is the Children’s Health Insurance
Program) of 2015 (PL 114-10 s.501) included a mandate to remove the current Health Insurance Claim number
(HICN) from Medicare cards by April 2019. Beginning in April 2018, a new Medicare beneficiary identifier (MBI)
will replace the current Social Security number-based HICN. The new MBI numbers will be assigned to all
Medicare recipients. CMS began the process of mailing new Medicare cards to beneficiaries in April 2018.
Information related to the new Medicare card project, previously known as the Social Security Number
Removal Initiative (SSNRI), is available through the resources below:
•
Health Plan Management System (HPMS) memos: Search HPMS using key words: SSNRI, MBI, and
software releases
•
New Medicare cards homepage: https://www.cms.gov/medicare/new-medicare-card/nmc-home.html
3.4.1.
General MBI Information
As discussed in the December 22, 2017, HPMS memo “Updates to the Encounter Data System and Risk
Adjustment Suite of Systems to Accommodate the New Medicare Card Project,” CMS began issuing new Medicare
cards with the new MBIs to Medicare beneficiaries on April 1, 2018, and will continue through April 2019.
•
Generally, CMS systems will allow for a transition period from April 1, 2018, to December 31, 2019, during
which MAOs can submit to CMS either the beneficiary’s HICN or MBI in the same field that is currently used
to submit the beneficiary’s HICN.
•
The EDS and the Risk Adjustment Suite of Systems (RASS) will allow for a longer transition period; MAOs
can continue to include either the HICN or the MBI on EDRs and CRRs submitted to the EDS, as well as RAPS
data records submitted to the RASS past the end of the broader CMS new Medicare card project transition
period of December 31, 2019. We will determine and communicate the end of the MBI transitions at a later
date.
•
For RAPS data submissions, for the time being, MAOs must submit deleted items using the beneficiary
identifier that was used on the original add submission. This includes instances in which MAOs submitted
deletes that fell within the six-year overpayment look-back period and that were submitted using an HICN or
Railroad Retirement Board (RRB) number at the time of original submission.
•
For encounter data submissions, MAOs can submit both EDRs and CRRs, with either the MBI or HICN.
•
All EDS and RASS transaction reports reflect the beneficiary identifier submitted to CMS by the MAO, starting
April 1, 2018.
Chapter 3
Page 9 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
•
When the beneficiary identifier field on transaction reports refers to the HICN, the field will be renamed from
specific reference to the HICN to the use of a broader term, such as beneficiary identifier.
•
There will be no change to file formats as the beneficiary identifier will be reflected in the same field currently
used for HICNs.
3.4.2.
Specific MBI-related Changes to Transaction Reports
This subsection mentions several reports that CMS sends to MAOs and other submitters for encounter data and
RAPS data. Chapter 5 provides information on the MAO-001 report. Also see Appendix 3C for information on MBI
edits for ED and RAPS Data.
As described earlier, the file formats and beneficiary identifier field length and position will not change on
transaction reports. However, the field name containing the beneficiary identifier will change and the timing of this
change for each report will differ slightly for the reports as described next.
1. MAO-001 Reports
•
As of April 1, 2018, the field currently labeled “Health Insurance Claim Number” (position 107-118) was
renamed to “Beneficiary Identifier.”
•
As of April 1, 2018, the MAO-001 will return either the HICN or MBI, whichever was submitted by the MAO.
2. MAO-004 Reports
•
As of April 1, 2018, the field currently labeled “Beneficiary HICN field” (position 17-28) was renamed to
“Beneficiary Identifier.”
•
The MAO-004 report was updated to include the MBI, if received on a record, in the “Beneficiary Identifier”
field.
3.5.
Submitter Options for Populating Certain Data Elements
The EDR is a report from the MAO about medical items or services a beneficiary received while enrolled in one
of the MAO’s plans. Because the MAO is a report to CMS about items or services received, and not a provider bill,
examples of MAO options follow for populating certain data fields in the EDR (as described in the October 30, 2017,
HPMS memo “Guidance for Encounter Data Submission,” which is available at www.csscoperations.com.
3.5.1.
Default Data Reason Codes
For a limited set of situations, CMS had developed Default Data Reason Codes or DDRCs that should be
populated in Loop 2300, NTE01=’ADD’, NTE02, to indicate the specific circumstance for populating certain data
Chapter 3
Page 10 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
fields when an MAO did not have the required information from the provider or medical record. Table 3.3 lists the
seven situations for which DDRCs were developed.
Loop 2300, NTE02 allows for a maximum of 80 characters and one iteration, which limits the submission of
default data to one message per encounter.
To populate multiple default data messages in the NTE02 field, CMS will use a three-digit 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-digit DDRC. Multiple
DDRCs will be populated in a stringed sequence with no spaces or separators between each DDRC (that is,
036040048). Table 3.3 provides the specific circumstance and the CMS-defined DDRC.
Table 3.3. Default Data
Default Data
Default Data Message (NTE02)
DDRC
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 providers
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
3.5.2.
Other Circumstances
Submitters should follow the guidance given by CMS, with no DDRC needed, in the specific circumstances
when a plan does not know the following:
•
The facility admission date on a professional claim for a service performed in an inpatient setting
•
Whether the provider is a hospice employee on a professional claim for a service performed in a hospice setting
•
The provider’s address on a paper claim or a member reimbursement claim
•
The service unit counts on an institutional claim due the payment arrangement between the MAO and the
provider
Chapter 3
Page 11 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Note: CMS guidance uses the term default data when discussing circumstances under which MAOs populate
data fields on an EDR or CRR with a constant value, a value allowed by CMS guidance (for example, suggested
procedural code modifiers for preventing duplicate line-level edits), or with data from a source other than a claim
from a provider when certain situations apply. Here we clarify that CMS is not providing default data values for
populating data fields. Rather, MAOs and other submitters are responsible for identifying appropriate, accurate data
for populating EDRs and CRRs, in accordance with the guidance stated in this guide.
3.5.3.
Demographic Data
Populate the EDR with demographic information related to age, name, and sex using data that the MAO knows
to be correct, instead of submitting to CMS incorrect data that a provider submitted to the MAO on a claim for
payment.
3.5.4.
Diagnoses
Report to CMS the data the MAO knows to be correct relative to providing that specific item or health care
service being reported. Per CMS guidance (including Chapter 2 of this guide), diagnoses reported to CMS for risk
adjustment must meet risk-adjustment rules, including that the diagnoses must be supported by the medical record.
As with RAPS data, if an MAO determines that diagnoses have to be deleted because they are not supported by the
medical record, there are a number of ways to delete diagnoses from the EDS, including submitting a CRR – Delete
record, a replacement EDR with the unsupported diagnoses removed, or voiding the EDR and resubmitting.
Note: The diagnoses on a CRR can repeat diagnoses already submitted on a previously accepted EDR or CRR.
However, as CMS suggests in the June 22, 2017, HPMS memo “Best Practices for Encounter Data Submission,”
CRRs should be submitted only if there are new diagnoses or changes in diagnosis codes to ensure that duplicate
diagnosis information is not submitted, which reduces administrative burden for submitters and CMS.
3.5.5.
Ambulatory Surgery Center Bypass
There is an additional bypass condition for ambulatory surgery center fee schedule EDRs: populate the field
“Multiple Procedure Discount Indicator” with a value of “1” in order to bypass the duplicate line edit.
3.5.6.
Line-level Duplicates Bypass
When the MAO has determined that the lines represent distinct items or services, but will be identified as
duplicates by the CMS line-level duplicate logic, MAOs may report data on the EDR that were not submitted by a
provider. MAOs can use the CMS-specified procedure code modifiers so that the line-level duplicate logic is
bypassed. See Chapter 6, section on Edit 98325, for details on the bypass logic for line-level duplicates. Another
Chapter 3
Page 12 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
option for preventing a duplicate line rejection is to include the actual payment amount on each line (assuming the
actual payment amount for each line differs.
Note: the bypass logic described here is not intended to be instructions for how providers should bill the MAO.
When none of the data elements included in the EDPS duplicate logic check are changing, but other data
elements on a line (edit 98325) or record (edit 98300) may have changed, CMS recommends submitting the
subsequent EDR as a replacement or voiding the previously submitted and accepted EDR and resubmitting a new
original record to prevent rejection for duplicate submission.
3.5.7.
More than One EDR for a Single Provider Claim
If the provider has submitted only one claim to the MAO but, for example, the provider then had to submit
additional pre-authorization information, but the claim is still considered an original, or the MAO has to adjust the
EDR that it has sent to CMS but the provider did not submit a new claim, the MAO may adjust its EDR for this
encounter, as it is a report to CMS regarding a specific item or service received by the enrollee. We recognize that
plans might want to track their data sources for populating an EDR for data integrity purposes; in such cases, CMS
recommends as a best practice that MAOs track when and why provider-supplied information is modified for
submission to the EDS. See Chapter 6 regarding Edit 98300—“Exact Inpatient Duplicate”—for additional
information.
3.6. National Provider Identifier and Employer Identification Number
Guidance
CMS requires MAOs to follow the TR3 guides and use valid National Provider Identifiers (NPIs) and
Employer Identification Numbers (EINs) for submission of EDRs. There may be limited circumstances in which
MAOs and other entities are unable to obtain the provider’s NPI information, as summarized in Table 3.4 and
discussed in subsequent sections.
Table 3.4. Summary of Default NPI Guidance
NPI Scenario
No NPI on Member Reimbursement Claim
Member Received Medical Services Out of
the Country
No Referring Physician on DME Encounter
No Billing Provider
Chapter 3
NPI Solution
•
•
•
•
•
•
•
•
Look up the NPI in National Plan and Provider Enumeration
System (NPPES)
Otherwise, use the default NPI for the applicable record type
Use default NPI for the applicable record type
CMS expects low volume
Do not use default NPI
Use another NPI related to the DME encounter
Do not use Default NPI
Use NPI of another provider associated with the encounter
Page 13 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
NPI Scenario
Internal Billing Provider ID Maps to
Multiple NPIs
3.6.1.
NPI Solution
•
•
Do not use default NPI
Use any valid and current NPI associated with the internal
provider ID# for the billing provider
Atypical Providers
Providers who are not considered health care providers and do not provide health care services are referred to
as atypical service providers. An atypical provider is defined as an individual or business that bills for services
rendered but does not meet the definition of a health care provider according to the NPI Final Rule 45 CFR
160.103 (for example, providers of non-emergency transportation, Meals on Wheels, and personal care services).
MAOs and other submitters should follow the default NPI guidance in Section 3.6.2 when the provider is an
atypical provider. For information on acceptable physician specialty types for risk adjustment data submission
associated with a specific payment year refer to the file “Acceptable Physician Specialty Types Effective Payment
Year” available under References in the Encounter and Risk Adjustment Program section on
www.csscoperations.com.
3.6.2.
Default NPI Guidance
CMS released clarifying guidance on populating NPI fields in the December 21, 2017, HPMS memo
“Encounter Data Record Submissions—NPI Submission Guidance—Frequently Asked Questions (FAQ),” also
provided here.
Note: CMS expects the number of EDRs with default NPIs for providers who would otherwise have an NPI
(that is, providers that are not atypical providers) to be a very small percentage of an MAO’s total EDR submissions.
CMS is monitoring the level of default NPI use.
Foreign providers. For an EDR reporting a service or item an enrollee received while the enrollee was outside
of the United States, the MAO should use the default NPI applicable to the record type in question from Table 3.5
(that is, professional, institutional, or DME).
Question: Should a plan report encounters to CMS for which it reimbursed an enrollee for medical services
received that the enrollee has paid for out of pocket? If these encounters should be reported, what should we enter
for the NPI because enrollee reimbursement claims do not have the provider NPI?
Response: MAOs and other entities are required to submit an EDR for all items and services received by a
beneficiary under the contract, even when the beneficiary paid for the service directly. In the specific instance when
the MAO submits an EDR for an encounter for which the beneficiary paid out of pocket, and the claim submitted to
the MAO for reimbursement is not populated with a provider NPI, the MAO, in creating the EDR, should populate
fields requiring NPIs with actual NPIs, if available. Submitters can look up NPIs on the National Plan and Provider
Chapter 3
Page 14 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Enumeration System at https://www.cms.gov/Regulations-and-Guidance/AdministrativeSimplification/NationalProvIdentStand/DataDissemination.html.
Otherwise, the MAO should use the default NPI applicable to the record type in question from Table 3.5 to
populate fields requiring NPIs on EDRs.
Table 3.5. Default NPI Values, by Service Type
System
Institutional
Professional
DME
Payer ID
Default NPI Value
80881
80882
80887
1999999976
1999999984
1999999992
Question: If the Referring Physician NPI is not available for a DME encounter, can a plan substitute the
default NPI or the enrollee’s primary care provider’s NPI, if available, to resolve these errors?
Response: When the Referring Physician NPI is not available for populating the DME encounter, the
MAO cannot use the default NPI on the EDR reporting this encounter. The MAO should use another NPI related to
the DME encounter.
Question: When an EDR is being built from an electronic medical record (EMR), can the MAO substitute
the Servicing Provider ID in place of the Billing Provider ID to complete the requirements around billing provider
ID for the 837 record? If we cannot substitute, what is the recommended approach for us to use to submit EMR/EHR
data on an 837?
Response: When there is no Billing Provider NPI available for a service or item being reported, such as
when the data for an encounter are derived from an EMR, or when there is no encounter-specific bill, as with
services provided by providers under capitated payment arrangements with the MAO, the MAO can use the NPI of
another provider associated with the encounter in place of the Billing Provider NPI.
Question: When mapping an internal provider identification number from a claim to the NPI reference data
in the MAO’s system to populate the Billing Provider NPI data field for an EDR, we often find that an internal
provider identification number maps to more than one NPI. Which NPI should we use to populate the Billing
Provider NPI data field on an EDR?
Response: CMS guidelines related to NPIs do not specify which NPI to use to populate the EDR for
providers having multiple NPIs. Accordingly, when an MAO’s internal provider identification number maps to
multiple valid and current NPIs, the MAO can populate the Billing Provider NPI field with any valid and current
NPI that is associated with the internal provider identification number for the billing provider.
Also, when a submitter is using a default NPI, per our guidance, which is not due to the provider being
atypical, the submitter should not populate the NTE02 with a Default Data Reason Code (DDRC). The use of the
048 DDRC is specifically associated with the regulatory definition of an atypical provider.
Chapter 3
Page 15 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3.6.3.
Default EINs for Atypical Providers
When a default NPI is used, CMS strongly encourages MAOs and other entities to provide a valid EIN.
A default EIN should be submitted to the EDS only when the provider is considered atypical. MAOs and other
entities are required to populate the provider’s actual EIN of the provider when they submit a default NPI.
For atypical provider submissions, to submit a default EIN, MAOs and other entities should populate Loop
2010BB, REF01=EI, REF02=199999998 only if the provider’s actual EIN is not available.
Otherwise, the MAO should use the default EIN applicable to the record type in question from Table 3.6 to
populate fields requiring EINs on EDRs.
Table 3.6. Default EIN Values, by Service Type
System
Institutional
Professional
DME
3.7.
Payer ID
Default EIN Value
80881
80882
80887
199999997
199999998
199999999
PWK Segment for Special Considerations
For encounter data purposes, two fields from Loop 2300, PWK segment (Claim Supplement Information)
PWK01 and PWK02 must be populated under the following situations: CRRs, paper claim submissions, version
4010 submissions, and default ambulance zip codes. Table 3.7 presents CMS’ instructions on the values to use in
these two fields for each of these situations. This information is also available in Appendix 3A.
Table 3.7 CMS’ Instructions for Uses of Loop 2300 PWK Segment
Situation
Chart review records (CRRs)
Paper claims
Ambulance ZIP code default
4010 format submission
PWK01 Value
PWK02 Value
09
OZ
AM
PY
AA
AA
AA
AA
Paper claims. Whether submitted by providers or beneficiaries, paper claims must be converted to electronic
EDRs in the X12 837 format before submission to CMS. For example, some MAOs that have capitated payment
arrangements with providers do not require providers to submit claims for payment, instead allowing an image or
other representation of the item or service provided. MAOs and other submitters must convert these paper claims to
electronic EDRs.
Chapter 3
Page 16 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
See the Resources tab on www.csscoperations.com regarding the PC-ACE PRO32 software, which converts
paper claims to an electronic format.
Diagnoses from paper claim-generated EDRs can be eligible for risk adjustment.
3.8.
Items and Services Covered under Capitated Arrangements
CMS requires that submitters identify the EDRs associated with services covered under capitated payment
arrangements. MAOs can also elect to identify services offered under staff model arrangements using the flags for
capitated encounters. The following rules apply to submitted EDRs for these encounters for all service types.
Rule 1. Procedure codes. EDRs reporting encounters with capitated and staff model arrangements must
populate and submit valid Current Procedural Terminology (CPT)/ Health Care Procedural Coding System
(HCPCS) codes on the X12 837 5010.
Rule 2. Institutional Encounters
•
All lines capitated. If all services for an institutional encounter are paid on a capitated basis, the record should
be submitted with the field CN101 at the header level (LOOP 2300) set to “05”.
•
Mix of capitated and non-capitated service lines. If an institutional encounter contains services covered under
both capitated and non-capitated arrangements, the MAO should populate the EDR as follows:
-
Loop 2300: Populate the CN101 data field at the header level (Loop 2300) with “05”.
-
For capitated lines: Populate the CAS02 segment with a Line Adjustment Reason Code = “24” to indicate
-
a capitated service line
For non-capitated service lines: Populate the CAS02 segment with Line Adjustment Reason Codes using
the CAS codes on the 835 (RA).
Rule 3. Professional Encounters
•
All lines capitated. If all services for a professional encounter are paid on a capitated basis, the record should
be submitted with the field CN101 at the header level (LOOP 2300) set to “05”.
•
Mix of capitated and non-capitated lines. If a professional encounter contains services covered under both
capitated and non-capitated arrangements, the MAO should populate the record as follows:
-
Loop 2300: Populate the CN101 data field at the header level (Loop 2300) with “05”
-
For capitated lines, Loop 2400: Populate the CN101 data field with “05” for each capitated service line.
-
For non-capitated service lines: Do not use the CN101 data field.
Rule 4. Payment fields. Due to the capitated payment structure, amount fields on claims submitted by
capitated providers to MAOs do not always have per-service pricing information populated. For EDRs for items or
services covered under capitated (or staff model) arrangements, MAOs and other entities can populate payment
Chapter 3
Page 17 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
fields with ‘0.00’ if and only if no amount information is available. If billed and/or payment information is available,
it should be submitted as is.
3.9.
Appropriate Procedure Codes on CRRs
As discussed in Chapter 2, Section 2.2, existing guidance allows MAOs and other submitters to populate
CPT/HCPCS fields with codes that best reflect what happened in the encounters. However, in populating
CPT/HCPCS fields on CRRs, submitters must be consistent with the CMS filtering logic. In other words, diagnoses
that are disallowed for risk adjustment should not be submitted with HCPCS codes that would cause these diagnoses
to be allowed for payment purposes. For example, a diagnosis code resulting from a lab test that the professional
filtering logic would have excluded, because the CPT/HCPCS code for the lab visit was not included on the list of
allowable CPT/HCPC codes for the service year, should not be submitted on a CRR with an allowable default
CPT/HCPCS code. Similarly, other data elements, such as the dates of service, should preserve the integrity of the
associated encounter and medical record from which the CRR was created.
Note: CMS guidance has used the term default data when discussing CPT/HCPCS codes on CRRs. Here, we
clarify that CMS does not provide default data values for populating CPT/HCPCS codes on CRRs. Rather, MAOs
and other submitters are responsible for identifying appropriate CPS/HCPCS codes for populating their CRRs, in
accordance with the guidance stated in this guide.
3.10. Populating “Other Payer Paid” Fields
For the submission and processing of encounter data, CMS implements a payer-to-payer model of benefit
coordination within the X12 837 5010 (instead of the provider-to-payer-to-provider-to-secondary payer model of
benefit coordination). Under the payer-to-payer approach, CMS is treated as the secondary destination payer, and
MAOs and other submitters must submit all payments they made for an encounter in the “Other Payer Paid” fields
of the EDR. Specifically, MAOs need to populate:
Loop ID-2320 AMT02 = Other Payer Paid header
Loop ID-2430 SVD02 = Other Payer Paid line
For capitated or staff model arrangements submitting encounter data, MAOs and other entities must submit
zero dollars (0.00) only if billed and/or payment amount information is not available. If billed and/or payment
information is available, it should be submitted. EDPS will accept a zero dollar amount for the billed and paid
amounts for capitated encounter submissions (Loop 2300 CN101 = ‘05’).
3.11. DME Guidance
Currently, two types of DME submissions are acceptable for encounter data submissions:
1.
DME services that are incident to a provider (provided during a physician or institutional visit)
Chapter 3
Page 18 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
2.
Durable Medical Equipment, Prosthetics, Orthotics, and Supplies (DMEPOS) supplier services
A provider of service may include an institution or physician. A supplier is an entity other than a provider that
furnishes health care services under Medicare. A provider of supplies that enrolls as a DMEPOS supplier is
considered a DMEPOS supplier for encounter data submission. DME incident and DMEPOS supplier EDRs will
be validated according to the NPI and Payer ID only.
3.11.1.
DME Services Incident to Submissions
If the DME service is incident to a physician or institutional service, it should be submitted on the 837-P or 837I, using the appropriate Payer ID:
•
80881/80888 1—for DME encounters incident to an institutional service
•
80882/80889 2—for DME encounters incident to a professional service
The NPI on the EDR must be for a provider, physician, or institution and not for a DMEPOS Supplier.
When considered incident to a health care provider’s services, the following are part of the provider’s,
physician’s, or institution’s encounter: implanted DME, implanted prosthetic devices, replacement parts,
accessories, and supplies for the implanted DME.
3.11.2.
DMEPOS Supplier Services Submissions
DMEPOS supplier services must be submitted on an 837-P. MAOs and other entities should use the
following values on the EDR for a DMEPOS supplier service provided to a beneficiary:
•
ISA08 (Interchange Receiver ID) = 80887/80890 3
•
GS03 (Application Receiver’s Code) = 80887/80890
•
Loop 1000B, NM109 (Receiver’s Identifier) = 80887/80890
•
Loop 2010BB, NM109 (Payer’s Identifier) = 80887/80890
If an encounter is submitted with Payer ID 80887/80890 along with a DMEPOS supplier NPI, the HCPCS
from DMEPOS fee schedule must be used. If the submitted HCPCS does not exist in DMEPOS fee schedule, but is
found in the Medicare physician fee schedule, an informational edit ‘32070—Non-DME HCPCS Code’ will be
posted on the DME encounter.
1
Medicare-Medicaid Demonstration contracts use Payer ID 80888 for an institutional service.
2
Medicare-Medicaid Demonstration contracts use Payer ID 80889 for a professional service.
3
Medicare-Medicaid Demonstration contracts use Payer ID 80890 for a DMEPOS supplier service.
Chapter 3
Page 19 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3.12. Ambulance Encounter Processing
MAOs and other entities must submit professional ambulance data on the 837-P. Loop 2310E (Ambulance
Pick-Up Location) and 2310F (Ambulance Drop-Off Location) to have these encounters appropriately processed.
On professional records, ambulance services are identified by the Billing Provider Specialty Code of 59 (Ambulance
Service Provider) and procedure code(s) A0425, A0426, A0427, A0428, A0429, A0430, A0431, A0432, A0433,
A0434, A0435, A0436 or A0888. For line items reflecting these procedure codes, providers are required to report
one service unit for each ambulance trip provided during the billing period.
On institutional records, the criteria to identify ambulance services uses the following logic: 1) TOB is 12X,
condition code is not B2, revenue code is 0540 and procedure code(s) A0425, A0426, A0427, A0428, A0429,
A0430, A0431, A0432, A0433, A0434, A0435, A0436 or A0888, or 2) TOB is 13X, 22X or 23X, revenue code is
0540 and procedure code(s) A0425, A0426, A0427, A0428, A0429, A0430, A0431, A0432, A0433, A0434, A0435,
A0436 or A0888.
The EDPS validates ambulance services data on submitted encounters against reference files in the EDPS
database. The EDPS databases contain the ZIP Code 5 to Carrier Locality Table and the ZIP Code 9 to Carrier
Locality Table. When the EDPS receives an encounter, it reads the date of service, and the ZIP code from the
Ambulance Pick-Up Location address (Loop 2310E) to process the EDR.
If the true ambulance pick-up and drop-off locations are available from the provider, MAOs and other entities
must include the address line(s), city, state, and ZIP code in Loops 2310E and 2310F. If the true ambulance pick-up
and drop-off locations are not available from the provider, MAOs and other entities must abide by the following
operational guidance:
•
If the pick-up address is unavailable, populate the address, including the address line(s), city, state, and ZIP
code and populate this information in Loops 2310E and 2310F using the subscriber’s address information.
•
If the rendering provider differs from the billing provider, populate the rendering provider’s complete address,
including the address line(s), city, state, and ZIP code and populate this information in Loops 2310E and 2310F.
Use the billing provider’s complete address, including the address line(s), city, state, and ZIP code and populate
this information in Loops 2310E and 2310F.
3.13. Telehealth Encounter Processing
In order to report services to the EDS that have been provided through telehealth, MAOs must use place of
service code “02” for telehealth or use the CPT telehealth modifier “95” with any place of service.
Chapter 3
Page 20 of 20
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Chapter 4. EDFES Processing
4.1.
CONNECTING AND TRANSFERRING FILES ........................................................................................... 2
4.2.
FILE SIZE AND FILE FORMAT GUIDANCE ............................................................................................. 2
4.3.
4.4.
4.2.1.
File Size Rules .................................................................................................................................. 3
4.2.2.
File Format ........................................................................................................................................ 3
SUBMISSION FREQUENCY REQUIREMENTS ........................................................................................ 4
4.3.1.
Timing of Sequential Uploads .......................................................................................................... 4
4.3.2.
End-of-Year Submission Load .......................................................................................................... 5
OVERVIEW OF ENCOUNTER DATA FRONT-END SYSTEM PROCESSING AND
REPORTING .................................................................................................................................................. 5
4.4.1.
Naming Conventions for EDFES Acknowledgement Reports ......................................................... 8
4.4.2.
Report Restoration ............................................................................................................................ 8
4.5.
PRE-SCREENING VALIDATION AND INVALID REPORT ..................................................................... 8
4.6.
INTERCHANGE EDITS AND THE TA1 ACKNOWLEDGEMENT REPORT ........................................ 10
4.7.
4.8.
4.6.1.
Example: Reading the TA1 Acknowledgement Report .................................................................. 11
4.6.2.
Steps for Resolving the TA1 Error in Figure 4.4 ............................................................................ 11
FUNCTIONAL GROUP AND TRANSACTION SET EDITS AND THE 999
ACKNOWLEDGEMENT REPORTS .......................................................................................................... 12
4.7.1.
Example: Reading the 999 Acknowledgement Report for an Accepted Transaction Set ............... 14
4.7.2.
Example: Reconciling the 999 Acknowledgement Report for a Rejected Transaction Set ............ 15
CCEM TRANSACTION SET EDITS AND THE 277CA ACKNOWLEDGMENT REPORTS ................ 20
4.8.1.
CMS 5010 Edit Spreadsheets .......................................................................................................... 20
4.8.2.
Edits Deactivated for Requirements Unique to the Medicare Advantage Program ........................ 21
4.8.3.
277CA Acknowledgement Report .................................................................................................. 21
4.8.4.
Example: 277CA Acknowledgement Report .................................................................................. 22
4.9.
STRATEGIC NATIONAL IMPLEMENTATION PROCESS (SNIP) EDITS IN THE
TRANSLATOR AND CCEM....................................................................................................................... 24
4.10.
POST-SCREENING VALIDATION AND THE INVALID REPORT ........................................................ 26
Chapter 4
Page 1 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
The purpose of the Encounter Data Front-End System (EDFES) is to collect Medicare Advantage encounter
data records (EDRs) from Medicare Advantage Organizations (MAOs) and to ensure the integrity of EDR files and
records. The submitter prepares and submits files containing EDRs and chart review records (CRRs) to the EDFES
in the X12 837 5010 format. For information regarding segments and enveloping structure of the 5010 format, see
Chapter 3, Section 3.2. Also see Figure 4.2 in Chapter 4 for a graphical overview of how the EDFES is positioned in
relation to other Encounter Data Processing System components.
This chapter provides operational submission guidance for 5010 records and information on the reports the
EDFES returns to submitters.
4.1. Connecting and Transferring Files
MAOs and other submitters must first establish connectivity to CMS’ systems. For information on connecting
to CMS systems and accessing the EDFES and the Front-End Risk Adjustment System (FERAS) to upload files
with EDRs and RAPS records, and to download transmittals from CMS, please see the new file “MA & Part D
Communications Handbook,” found at https://www.csscoperations.com/. Note that this file is a consolidation of
three files previously found on the CSSC Operations website: EDFES User Guide, FERAS User Guide, and PDFS
User Guides.
4.2.
File Size and File Format Guidance
First, there are two basic definitions:
•
File size. A file begins at the ISA segment and ends at the IEA segment, and file size refers to the number of
ISA-IEA envelopes (also known as ISA-IEA Interchange Control Structure). The ISA-IEA envelope contains at
least one ST/SE transaction set 1.
•
ST/SE transaction set size. For all connectivity methods, the TR3 guides recommend a limit for each ST/SE
transaction set of no more than 5,000 claims. CMS adopts this recommendation, allowing a maximum of 5,000
records (EDRs and CRRs) per ST/SE transaction set.
See Chapter 3 for a discussion of ISA-IEA envelope(s) and ST-SE transaction set(s).
1
Transaction set is a general term referring to a set of encounter data interchange (EDI) standards or instructions
about how to structure information to be exchanged between trading partners, according to the relevant ANSI X12
format.
Chapter 4
Page 2 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
4.2.1. File Size Rules
For CMS, the number of records per file is dependent upon the connectivity method of the submitter.
Submitters should count both EDRs and CRRs when assessing counts. The following submission practices will help
prevent delays in the generation and distribution of EDFES Acknowledgement Reports.
As shown in Table 4.1, FTP/Connect:Direct users cannot exceed 85,000 professional EDRs and CRRs per file,
and 5,000 institutional EDRs and CRRs per file. Gentran/TIBCO MFT users cannot exceed 5,000 EDRs and CRRs
per file.
Due to system processing overhead associated with smaller numbers of EDRs and CRRs within the ST/SE
envelope, CMS highly recommends that MAOs submit at or close to the maximum number of EDRs and CRRs
within the ST/SE transaction set, not to exceed 5,000 records.
Table 4.1. File Size* Limitations for Encounter Data Record and Chart Review Record Submissions
Maximum Number of 837-P
Professional EDRs Per File
Maximum Number of 837-I
Institutional EDRs Per File
Maximum Number of
EDRs Per ST-SE
Transaction Set
FTP/C:D**
85,000
5,000
5,000
Gentran/TIBCO
MFT
5,000
5,000
5,000
Connectivity
*File size refers to the number of EDRs within a transaction set (ST/SE).
**C:D is Connect:Direct
4.2.2. File Format
Connect:Direct and Gentran/TIBCO MFT submitters must format all submitted files in an 80-byte fixed block
format. This means MAOs must upload every line in a file with a length of 80 bytes/characters. Segments must
consist of one continuous stream of information that continues to the next line every 80 characters.
•
Submitters should create files with segments stacked, using only 80 characters per line.
•
At position 81 of each segment, MAOs 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 are using a text editor to create the file, pressing the Enter key will create a new line. If MAOs
are using an automated system to create the file, create a new line by using a carriage return line feed or a line feed.
Chapter 4
Page 3 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 4.1. Sample ISA Interchange Control Header Code
For example, the ISA Interchange Control Header is 106 characters long:
The first line of the file will contain the first 80 characters of the ISA segment; the last 26 characters of the ISA
segment will continue on the second line. The next segment will start in the 27th position and continue until
column 80.
ISA*00*
*00*
*ZZ*ENH9999
*ZZ*80882
*120430*114 4*^*00501*000000031*1*P*:~
Note to 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, the EDFES will not store all of the
Acknowledgement Reports in the submitter’s system. To prevent this situation, Connect:Direct submitters should
establish a limit of 255 GDGs in their internal processing systems.
4.3. Submission Frequency Requirements
MAOs are required to submit encounter data to the EDPS on a frequency based on the contract’s enrollment
size, as shown in Table 4.2.
Table 4.2. Submission Frequency Requirements
Number of Medicare Enrollees in a Contract
Minimum Submission Frequency
Greater than 100,000
Weekly
50,000–100,000
Bi-weekly
Less than 50,000
Monthly
“Bi-weekly” means every two weeks.
The level of contract enrollment that CMS uses for this EDR submission frequency standard for a contract year
is the number of contract enrollees in February (as reported in the Health Plan Management System (HPMS)
enrollment file). MAOs and other entities may determine the cycle for submission of encounter data, as long as the
schedule adheres to the standards outlined by CMS for the MAO’s enrollment size. As a best practice, MAOs are
encouraged to submit EDRs daily.
4.3.1. Timing of Sequential Uploads
CMS recommends that FTP submitters’ scripts upload no more than one file per five-minute interval. Zipped
files should contain one file per transmission. MAOs should refrain from submitting multiple files within the same
transmission. Connect:Direct and Gentran/TIBCO MFT users may submit a maximum of 255 files per day.
Adhering to these guidelines will support maximum performance by the CMS’ encounter data systems.
Chapter 4
Page 4 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
4.3.2. End-of-Year Submission Load
CMS is concerned that some MAOs and organizations offering cost plans are submitting a substantial
percentage of their EDRs for a service year in the January right before the final risk adjustment data submission
deadline (that is, during the 13th month after the end of the service year). As CMS discussed in the July 26, 2016
HPMS memo “Encounter Data Submission Timing Guidance- Reminder and Update,” this generates a considerable
load on CMS’ systems. Further, although the frequency requirements discussed earlier in this section do not address
volume, their intent is to have EDR and CRR submissions spread evenly throughout the year.
To this end, CMS will identify contracts that submit 30 percent or more of the contract’s total EDRs for a
service year to CMS in the January prior to the final risk adjustment data submission deadline, and will contact those
organizations that have one or more contracts that do not meet this 30 percent monitoring standard (with the
exception of Programs of All-Inclusive Care for the Elderly (PACE) organizations and Medicare-Medicaid Plans
(MMPs)). The 30 percent rate will be calculated as follows, using calendar year 2014 as an example: the number of
EDRs for a contract with 2014 dates of service submitted to CMS by the organization in January 2016 divided by
the total number of EDRs for the contract with 2014 dates of service.
We recognize that there may be valid reasons for submitting a large proportion of EDRs in the month before
the risk adjustment deadline, and we believe the threshold of 30 percent reflects this recognition. However, to the
extent that organizations can plan their annual submissions process to meet this threshold (for example, the timing of
internal quality reviews of diagnosis data and other validation checks), CMS expects them to do so.
4.4. Overview of Encounter Data Front-End System Processing and Reporting
The Encounter Data Front-End System (EDFES) performs several phases of successive edits when processing
encounter data files and records. These phases are shown in Figure 4.2 and are discussed in the following sections:
•
Section 4.5: Pre-screening validation (applicable to files submitted by entities using Connect:Direct)
•
Sections 4.6 and 4.7: Translator edits
•
Section 4.8: Combined Common Edits & Enhancements Module (CCEM)
•
Section 4.9: Strategic National Implementation Process (SNIP) edits (occurs in the EDFES translator and the
CCEM)
•
Section 4.10 Post-screening validation – edits specific to the Medicare Advantage program
Chapter 4
Page 5 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 4.2. EDFES Processing Phases
COTS = Commercial Off-the-Shelf; SNIP = Strategic National Implementation Process; CCEM = Combined
Common Edits Module; EDPS = Encounter Data Processing System.
Figure 4.3 provides another view of the EDFES processing flow.
Figure 4.3. Flow of Encounter Data through the EDFES
EDS = Encounter Data System.
Chapter 4
Page 6 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 4.3 shows which validation edits are included in which EDFES Acknowledgement Report. Note that the
edits contained in the CMS 5010 Edit Spreadsheet include CCEM edits and Translator edits. Further, some
Translator edits are passed on from the Translator and displayed in the 277CA Report.
Table 4.3. Submission Frequency Requirements
Editing Environment
Type of Edits
Report
Pre-Screening Validation
Proprietary editing
Pre-screen Invalid Report for entities
connecting via Connect:Direct
Commercial off-the-shelf
(COTS) Translator
Syntax editing for Interchange
Envelope conformance (ISA/IEA
level)
TA1 Acknowledgement report, if the
transaction is rejected
Commercial off-the-shelf
(COTS) Translator
TR3 conformance editing for
functional groups (GS/GE) and
transactions sets (ST/SE)
Three possible reports:
999A = all Transaction Sets accepted
999P = Partially accepted (at least one
Transaction Set was rejected)
999R = Rejected syntax errors were noted
Combined Common Edits
Module (CCEM)
Medicare-specific edits at the record
and line levels
277CA: provides record-level info and
assigns an Internal Control Number for
each accepted record
Post-screening Encounter Data
Front-End System (EDFES)
validation
Medicare Advantage-specific edits
at the record and line levels; e.g.,
presence of contract ID
Post-screen Invalid Report (formerly
known as EDFES Notification)
* Refer to column L in the CMS 5010 Edit Spreadsheet to determine if the edit is reported on the 999 or
277CA acknowledgement report, found at https://www.cms.gov/Regulations-and-Guidance/Guidance/Transmittals/.
If a fatal error occurs in the ISA-IEA envelope, the entire file is rejected and the EDFES generates and returns
the TA1 Interchange Acknowledgement report within 24 hours of the submission. Other acknowledgement reports
are sent to MAOs within 48 hours of submission. Both at the 999 level and CCEM level of editing, a single edit can
result in the rejection of more than one record. At the 999 level, this is easy to understand because if there is an
error in a functional group header segment and that functional group contains a transaction set with 2,000
encounters, all of those records will be rejected as the result of a single error.
CMS provides a comprehensive list of edits in the CMS 5010 Edit Spreadsheets for Part A, Part B, and
Durable Medical Equipment (DME), which can be found at https://www.cms.gov/Regulations-andGuidance/Guidance/Transmittals/2017-Transmittals.html (see additional access instructions in Chapter 1, Table 1.1),
These spreadsheets include all of the 5010 Translator and CCEM edits applied to EDR and CRRs during the phases
of processing described above.
Chapter 4
Page 7 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
4.4.1. Naming Conventions for EDFES Acknowledgement Reports
File naming conventions were developed to allow MAOs identify Acknowledgement Reports. See the MA &
Part D Communications Handbook for instructions on file naming.
4.4.2. Report Restoration
The 999 and 277CA Acknowledgement Reports will not be restored if the files are older than 20 business days.
Restoration requests for more than 200 files, per single request, will not be accepted. Plan sponsors and submitters
can send multiple requests for report restoration over a span of time. CMS recommends that MAOs monitor their
files and submit requests appropriately. CMS reserves the right to deny requests that do not follow the guidelines.
4.5. Pre-screening Validation and Invalid Report
CMS performs edits prior to TA1-level editing in the Translator, for institutional, professional, and DME
EDRs and CRRs. These edits are referred to as “pre-screening” edits. When a file fails a pre-screening edit, the
submitter receives an Invalid Report, Table 4.4 lists the pre-screening edits that are performed. At this level, EDFES
checks for things like file size and record length.
Note: Pre-screening edits will not always be one-to-one; for example, claim type mismatch.
If a file fails the pre-screening validation edits, the submitter receives a Pre-Screening Invalid Report with the
following format:
1. File Name Record
Positions 1–10 = File Name
Position 11 = Blank Space
Positions 12–55 = Saved File Name
Positions 56–80 = Blank Spaces
2. File Message Record
Positions 1–63 = “File cannot be processed at this time for the following reason”
Positions 64–80 = Blank Spaces
3. Notification Message
Positions 1–80 = Notification Message
The report format example is as follows:
FILE NAME: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
FILE CANNOT BE PROCESSED AT THIS TIME FOR THE FOLLOWING REASON:
INVALID FILE SIZE EXPECTED: 80 ACTUAL: 3700
Chapter 4
Page 8 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 4.4 provides the list of pre-screening validation edits and examples of erroneous code.
Table 4.4. EDFES Pre-screening Validation Edits Applied to Files Submitted to the EDFES via
Connect:Direct
Edit
Notification Message
Examples Triggering
Edit
INVALID FILE SIZE
The file size is incorrect
EXPECTED: 80
ACTUAL: 3700
INVALID RECORD
SIZE
The first record size is not equal to 80 characters
EXPECTED: 80
ACTUAL: 79
SUBMITTER ID
MISMATCH ISA06
The Submitter ID in field ISA06 is not authorized to
submit Medicaid encounters
ISA06: ENC9994 FILE
NAME: ENC9996
SUBMITTER ID
MISMATCH GS02
The Submitter ID in field GS02 does not match the
Submitter ID in the file name
GS02: ENC9994 FILE
NAME: ENC9996
SUBMITTER ID
MISMATCH 1000ANM109
The Submitter ID in field NM109 in the 1000A loop does
not match the Submitter ID in the file name
1000A-NM109:
ENC9994 FILE
NAME: ENC9996
SUBMITTER ID
MISMATCH GS02
The Submitter ID in field GS02 does not match the
Submitter ID in field ISA06
GS02: ENC9994
ISA06: ENC9996
SUBMITTER ID
MISMATCH 1000ANM109
The Submitter ID in field NM109 in the 1000A loop does
not match the Submitter ID in field ISA06
1000A-NM109:
ENC9994 ISA06:
ENC9996
SUBMITTER ID
MISMATCH 1000ANM109
The Submitter ID in field NM109 in the 1000A loop does
not match the Submitter ID in field GS02
1000A-NM109:
ENC9994 GS02:
ENC9996
INVALID RECEIVER
ID ISA08
The Receiver ID in ISA08 is not a valid Medicare
Receiver
ISA08: 80888
RECEIVER ID
MISMATCH GS03
The Receiver ID in field GS03 does not match the
Receiver ID in field ISA08
GS03: 80881 ISA08:
80888
RECEIVER ID
MISMATCH 1000BNM109
The Receiver ID in field NM109 in the 1000B loop does
not match the Receiver ID in field ISA08
1000B-NM109: 80881
ISA08: 80888
RECEIVER ID
MISMATCH 1000BNM109
The Receiver ID in field NM109 in the 1000B loop does
not match the Receiver ID in field GS03
1000B-NM109: 80881
GS03: 80888
CLAIM TYPE
MISMATCH ISA08
The Receiver ID in ISA08 does not match the Claim
Type in field GS08
ISA08: 80881 CLAIM
TYPE: X222
CLAIM TYPE
MISMATCH GS03
The Receiver ID in GS03 does not match the Claim Type
in field GS08
GS03: 80881 CLAIM
TYPE: X222
CLAIM TYPE
MISMATCH 1000BNM109
The Receiver ID in field NM109 in the 1000B loop does
not match the Claim Type in field GS08
1000B-NM109: 80881
CLAIM TYPE: X222
CLAIM TYPE
MISMATCH GS08
The Claim Type in field GS08 does not match the Claim
Type in field ST03
GS08: 005010X223A2
ST03: 005010X222A1
Chapter 4
Page 9 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Edit
Notification Message
Examples Triggering
Edit
INELIGIBLE
SUBMISSION ISA08
The Submitter ID in field ISA06 is not authorized to
submit Medicare encounters
ISA08: 80888 NOT
AUTHORIZED FOR
ENCOUNTER
INELIGIBLE
SUBMISSION ISA08
The Submitter ID in field ISA08 is not authorized to
submit Medicaid encounters
ISA08: 80882 NOT
AUTHORIZED FOR
MMP
SUBMITTER NOT
CERTIFIED ISA06
The Submitter ID in field ISA06 is not authorized to
submit Medicaid encounters
ISA06: ENC9994
FILE DOES NOT
CONTAIN VALID X12
VERSION 5010 DATA
It could not be determined from the data that the file
contains X12 Version 5010 data
Not Applicable
INVALID SEGMENT
FORMAT
The ISA was less than the required 106 characters and an
invalid delimiter was detected
Not Applicable
MISSING SEGMENTS
LOOP
Missing segments in the 2000A loop
Not Applicable
4.6. Interchange Edits and the TA1 Acknowledgement Report
The next phase of edits for institutional, professional, and DME EDRs and CRRs is performed in the EDFES
Translator. The Translator analyzes the Interchange Control Structure (ISA-IEA envelope) for syntactical accuracy.
Errors detected by the Translator in the ISA/IEA interchange will cause the X12 837 file to be rejected. If the file is
rejected, there is no further processing. MAOs must correct and resubmit any file that is rejected.
The purpose of the TA1 Acknowledgement Report is to provide information about a file’s rejected Interchange
header (ISA) and trailer (IEA).
Note the following details regarding Interchange edits and the TA1 report:
•
The submitter will only receive a TA1 report if there are syntax errors in the file, causing the file to be rejected.
•
One TA1 Report is generated per file submission.
•
The TA1 is a single segment and is unique in that it is transmitted without the GS/GE envelope structure.
•
The notice of the file rejection and the specific error is within the TA1 segment.
•
The TA1 report includes 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 MAOs to associate the TA1 with a specific file previously submitted.
Interchange Acknowledgement Code TA104 indicates if 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 syntactical errors.
Interchange Acknowledgement Code TA105 notifies MAOs of the specific error.
Chapter 4
Page 10 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
4.6.1. Example: Reading the TA1 Acknowledgement Report
The string provided on line 2 in Figure 4.4 is a TA1 acknowledgement report. This string will allow MAOs to
identify the interchange error.
Figure 4.4. TA1 Acknowledgement Report Example
The Professional 837 file (value = 80882) was rejected because the Interchange header (ISA) of 003125081
and trailer (IEA) control numbers of 003125801 do not match:
Interchange Date: April 25, 2012
Interchange Time: 12:17 p.m.
Interchange Acknowledgement Code: R = Rejected
Interchange Note Code: 001 = Interchange Control Number in the Header and Trailer Do Not Match. The
value from the header is used in the acknowledgement.
4.6.2. Steps for Resolving the TA1 Error in Figure 4.4
The following steps should be taken to resolve error 001 in the example above.
1.
Locate the error on the TA1 Acknowledgement Report: 001 (Interchange Control Number in the header and
trailer do not match) is found in TA1 segment TA105.
2.
Look in the appropriate edit spreadsheet, (837-I CMS 5010 & CCEM Edit Spreadsheet) for the error.
3.
Locate the error on the edit spreadsheet: Search “001” in the Disposition/Error Code column.
Result: the 2nd row is the error.
Chapter 4
Page 11 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 4.5. Example of TA105 Error Lookup
Disposition / Error Code
5010 Edits
TA105 = 001: “The Interchange Control Number in the Header and Trailer Do
Not Match”
IEA02 must be present
TA105 = 001: “The Interchange Control Number in the Header and Trailer Do
Not Match”
IEA02 must = ISA13
1.
Access the 837 file with the Interchange Control Number of 012584687 .
2.
View the value populated in the data elements ISA13 and IEA02 (they must be identical).
3.
Correct the value populated in ISA13 and IEA02 by populating both data elements with an identical unused
value (not used within 12 months).
4.
Resubmit the 837 file.
If no errors are found during TA1-level editing process, the EDFES begins validation of EDRs and CRRs for
TR3 standards conformance editing (next section).
4.7. Functional Group and Transaction Set Edits and the 999
Acknowledgement Reports
After the Interchange passes the TA1 edits, the next stage of editing for institutional, professional, and DME
EDRs and CRRs is to verify the syntactical accuracy of the functional group(s) (GS/GE enveloping segments).
Functional groups allow for the organization of like data within an Interchange. A file may be populated with more
than one functional group containing multiple EDRs and CRRs within the functional group. If a file has multiple
GS/GE segments and errors occurred at any point within one of the syntactical and/or TR3 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 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.
In addition to checking the syntactical accuracy of functional groups, this phase of editing also checks the
detail segments and data fields within a transaction set.
A 999 Acknowledgement Report is generated for every file submission and is used to inform MAOs of the
processing status of the functional group and transaction sets included in the file. The report provides MAOs with
information on whether the functional groups were accepted or rejected, and whether the functional groups adhere to
TR3 (IG)-level edits and CMS standard syntax errors as depicted in the CMS 5010 Edit Spreadsheets for Part A,
Part B, and DME (see Section 4.8.). The CMS 5010 Edit Spreadsheet provides failure reasons that appear in 999
Reports.
Chapter 4
Page 12 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
The three possible acknowledgement values in 999 Reports are as follows:
“A” – Accepted: File is accepted and will continue processing
“R” – Rejected: Functional group(s) rejected and the file will not continue for processing
“P” – Partially Accepted: at least one transaction set was rejected
Note: When the 999R (rejected) or 999P (partial) Acknowledgement Report is received, MAOs must correct
and resubmit the file.
The 999 Acknowledgement Report is composed of segments nine key segments, listed in Table 4.6.
Table 4.6. Key Segments of the 999 Acknowledgement Report
Key Segments
Description of Key Segment
AK1
Functional Group Response Header
AK2
Transaction Set Response Header
IK3
Error Identification (Represents the Segment in Error)
CTX Segment Context
Related to IK3
CTX Business Unit Identifier
Related to IK3
IK4
TR3 Data Element Note (for the Data Element in Error within the Segment
noted in the IK3 loop)
CTX Element Context
Related to IK4
IK5
Transaction Set Response Trailer
AK9
Functional Group Response Trailer
Below we provide information on the key segments of the 999 Acknowledgement Report in Table 4.6.
IK3 and IK4 Segments
Segments such as the IK3 error identification are present only when there is a need to report a segment error.
The CTX context segment appears after the IK3 segment to describe the context within the segment.
•
The first element in the IK3 and IK4 indicates the segment and element that contain the error.
•
The second element in the IK3 and IK4 indicates the segment position in a transaction set.
•
The third element in the IK3 segment identifies the loop that contains the error.
•
The IK4 data element segment is present when there is a need to report an error at the data element level. If
required, there is a CTX context segment after the IK4 to describe the context within the segment. The third
element in the IK4 segment indicates the reason code for the error.
Chapter 4
Page 13 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
IK5 and AK9 Segments
The IK5 and AK9 segments are always present, noting the transaction set and and/or the functional group’s
accept or reject status.
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 requires correction so the interchange can be
resubmitted.
If a “P” is displayed in the IK5 and AK9 segments, this means only part of the file passed editing and at least
one transaction set was rejected. Only the passing data will continue to the next phase of processing.
4.7.1. Example: Reading the 999 Acknowledgement Report for an Accepted Transaction Set
The string provided in Figure 4.5, on lines 4 to 7, comprises a 999-A Acknowledgement Report.
Figure 4.5. 999-A Acknowledgement Report example
A Professional 837 file (value = 80882) with a Functional Group Control Number of 135 was submitted containing
one transaction set (ST/SE) with a control number of 000000135. Both the functional group and transaction set
passed 999 editing and were accepted. Fields in the 999 report segments are as follows:
AK1
999 Segment Identifier, Functional Group Response Header
HC
Functional Identifier Code (GS01)
135
837 Functional Group Control Number (GS06)
005010X222A1
TR3 Guide ID Health Care Claim: Professional (GS08)
AK2
999 Segment Identifier Transaction Set Response Header
837
Claim Transaction Set Identifier Code (ST01)
000000135
Transaction Set Control Number (ST02)
005010X222A1
TR3 Guide ID Health Care Claim: Professional (ST03)
IK5
999 segment Identifier, Transaction Set Response Trailer
Chapter 4
Page 14 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
A
Transaction Set Acknowledgment Code: Accepted – “A” in the IK501 segment indicates
there were no errors in the Transaction Set
AK9
999 Segment Identifier, Functional Group Response Trailer
A
Functional Group Acknowledgement Code: “A” in the AK9 segment indicates there were
no errors in the Functional Group
1
Number of Transaction Sets Included
1
Number of Received Transaction Sets
1
Number of Accepted Transaction Sets
4.7.2. Example: Reconciling the 999 Acknowledgement Report for a Rejected Transaction Set
Figure 4.6 and Table 4.7 present an example of a 999-R Acknowledgement Report. While lines 4, 5, and 17 in
Figure 4.6 are part of the 999 Report (segments AK1 and AK2), the black boxes around lines 6 to 16 and 18 to 23
highlight segments IK3 and IK4, which identify X12 837 segments and data fields in error, respectively. It is these
lines that are explained in Table 4.7. This example includes two transaction sets, where the first set has with two
EDRs (IDs 2012020399900522TC11 and 2012030799900224TC11); and the second transaction set has one EDR
(ID P2752560).
Chapter 4
Page 15 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 4.6. Example of 999R Acknowledgement Report
Table 4.7. Reference Table for Figure 4.6 999R, Acknowledgement Report Example
Data String
Line # in
Figure 4.6
Data Element
Description
6
IK3
999 segment Identifier, Error Identification
6
SBR
ID of segment containing the syntax error (SBR segment)
6
689
Position of the segment in error relative to the start of the
transaction set (SBR is the 689th segment from the “ST”
segment, which is counted as 1)
6
2430
Loop identifier Code
6
7
Syntax Error Code; 7 = Segment Not in Proper Sequence
7
CTX
999 segment Identifier, Segment Context
7
CLM01:2012020399900522TC11
Context Identification Context Name: Context Reference
Number
8
IK3
999 segment Identifier, Error Identification
8
AMT
ID of segment containing the syntax error (AMT segment)
Chapter 4
Page 16 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Data String
Line # in
Figure 4.6
Data Element
Description
8
698
Position of the segment in error relative to the start of the
transaction set (AMT is the 698th segment from the “ST”
segment, which is counted as 1)
8
2320
Loop identifier Code
8
8
Syntax Error Code, 8 = Segment has data element errors
9
CTX
999 segment Identifier, Segment Context
9
CLM01:2012020399900522TC11
Context Identification Context Name: Context Reference
Number
10
IK4
999 segment Identifier, TR3 Data Element Note
10
2
Position of the element in error inside of the segment
IK301(AMT)
+ IK401(2) = (AMT02)
10
7
Syntax error code, 7 = Invalid code value
10
000000000021
Copy of Data Element in error
11
IK3
999 segment Identifier, Error Identification
11
SBR
ID of segment containing the syntax error (SBR segment)
11
735
Position of the segment in error relative to the start of the
transaction set (SBR is the 735th segment from the “ST”
segment, which is counted as 1)
11
2430
Loop identifier Code
11
7
Syntax Error Code, 7 = Segment not in proper sequence
12
CTX
999 segment Identifier, Segment Context
12
CLM01:2012030799900224TC11
Context Identification Context Name: Context Reference
Number
13
IK3
999 segment Identifier, Error Identification
13
AMT
ID of segment containing the syntax error (AMT segment)
13
744
Position of the segment in error relative to the start of the
transaction set (AMT is the 744th segment from the “ST”
segment which is counted as 1)
13
2320
Loop identifier Code
13
8
Syntax Error Code, 8 = Segment has data element errors
14
CTX
999 segment Identifier, Segment Context
14
CLM01:2012030799900224TC11
Context Identification Context Name: Context Reference
Number
15
IK4
999 segment Identifier, TR3 Data Element Note
15
2
Position of the element in error inside of the segment
IK301(AMT) + IK401(2) = (AMT02)
Chapter 4
Page 17 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Data String
Line # in
Figure 4.6
Data Element
Description
15
7
Syntax error code, 7 = Invalid code value
15
000000000015
Copy of Data Element in error
16
IK5
999 segment Identifier, Transaction Set Response Trailer
16
R
Acknowledgement Code R = rejected
16
I5
Transaction Set Syntax Error Code I5 = Implementation
One or More Segments in Error
18
IK3
999 segment Identifier, Error Identification
18
SVD
ID of segment containing the syntax error (SVD segment)
18
31
Position of the segment in error relative to the start of the
transaction set (SBR is the 31st segment from the “ST”
segment, which is counted as 1)
18
2430
Loop identifier Code
18
8
Syntax Error Code, 8 = Segment has data element errors
19
CTX
999 segment Identifier, Segment Context
19
CLM01:P2752560
Context Identification Context Name: Context Reference
Number
20
IK4
999 segment Identifier, TR3 Data Element Note
20
1
Position of the element in error inside of the segment
IK301(SVD) + IK401(1) = (SVD01)
20
I12
Implementation Pattern Match Failure
20
H9999
Copy of Data Element in error
21
CTX
999 segment Identifier, Segment Context
21
SITUATIONAL TRIGGER
Context Identification
21
2330
Loop Identifier Code, the loop ID number for this data
element
22
IK5
999 segment Identifier, Transaction Set Response Trailer
22
R
Acknowledgement Code R = rejected
22
I5
Transaction Set Syntax Error Code I5 = Implementation
One or More
23
AK9
999 Segment Identifier, Functional Group Response Trailer
23
R
Acknowledgement Code R = rejected
23
2
Number of Transaction Sets Included
23
2
Number of Received Transaction Sets
23
0
Number of Accepted Transaction Sets
Chapter 4
Page 18 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
To properly reconcile the 999R Acknowledgement Report, using the example in Figure 4.6 and Table 4.7,
MAOs must locate and resolve the errors in the file. In the example, there are two transaction sets: 000000133 and
000020860.
Transaction set 000000133 has two EDRs, IDs 2012020399900522TC11 and 2012030799900224TC110, and
each EDR has two errors, for a total of four errors in this transaction set.
Transaction set 000020860 has one EDR, with one error.
In the transaction set 000000133, locate the four errors in the 999 Acknowledgement lines, and then look in the
appropriate edit spreadsheet (999 TR3 and CMS CEM 5010 Edit Spreadsheet, professional) for the explanation of
the error in the Disposition/Error Code column.
Errors in first transaction set 000000133, EDR # 2012020399900522TC11
Error 1: EDR Identifier Number 2012020399900522TC11, Error IK304 = 7, “Segment Not in Proper
Sequence.” was found in the 999 TR3, not the CMS CEM 5010 Edit Spreadsheet. As noted in Table 4.7, in the 2430
Loop, the SBR segment found in the 689th location from the “ST” segment is not in the proper sequence.
Resolution 1: Move the 2430 Loop, SBR segment to the correct sequence/location in the data string.
Error 2: EDR Identifier Number 2012020399900522TC11, Error IK304 = 8, “Segment has data element
errors.” The IK4 segment is required when the error described in IK3 applies to a data element. Thus, line 10 has an
IK403 value of 7, meaning “Invalid Code Value”, which line 8 of the Acknowledgement Report indicates error is
found in the AMT segment loop 2320.
Error IK403 = 7, “Invalid Code Value” for the AMT segment was found in the 999 TR3, not in the CMS
CEM 5010 Edit Spreadsheet. As noted in Table 4.7, in the 2320 Loop, the AMT segment found in the 698th location
from the “ST” segment has data element errors.
Resolution 2: Data element AMT02 = “00000000021” is an invalid value because leading zeroes are to be
suppressed.
Errors in first transaction set 000000133, EDR # 2012030799900224TC11
Error 3: EDR Identifier Number 2012030799900224TC11, error IK304 = 7, “Segment Not in Proper
Sequence.” was found in the 999 TR3, not the CMS CEM 5010 Edit Spreadsheet. As noted in Table 4.7, the
position of the segment is in error relative to the start of the transaction set (SBR is the 735th segment from the “ST”
segment, which is counted as 1)
Resolution 3: Move the 2430 Loop, SBR segment to the correct sequence/location in the data string.
Error 4: EDR Identifier Number 2012030799900224TC11, Error IK304 = 8, “Segment has data element
errors” was found in the 999 TR3, not the CMS CEM 5010 Edit Spreadsheet. The IK4 segment is required when
Chapter 4
Page 19 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
the error described in IK3 applies to a data element. Thus, line 15 has an IK403 value of 7, meaning “Invalid Code
Value”, which line 13 of the Acknowledgement Report indicates error is found in the AMT segment loop 2320. In
the 2320 Loop, the AMT segment is found in the 744th location from the “ST” segment.
Resolution 4: Data element AMT02 = “00000000015” is an invalid value because leading zeroes are to be
suppressed.
Error in second transaction set 000020860, EDR #P2752560
The example presents one error, affecting EDR #P2752560.
Error 5: EDR Identifier Number P2752560, Error IK304 = 8, “Segment has data element errors” and
IK403-I12 “Implementation pattern match failure” was found in the 999 TR3, not the CMS CEM 5010 Edit
Spreadsheet. As noted in Table 4.7, the position of the element in error inside segment IK is in the 31st location
from the “ST” segment on the 837 file.
Resolution 5: The values in the following data elements must match: 2430 Loop, data element SVD01 and
2330B Loop, data element NM109.
After all encounters in the transaction set are corrected, MAOs must resubmit both transaction sets.
4.8. CCEM Transaction Set Edits and the 277CA Acknowledgment Reports
After the file is accepted at the Interchange and functional group levels that is, passes 999 editing), the third
level of editing occurs at the transaction set level within the CCEM (header and line edits). The CCEM checks the
validity of the values within the data elements. The result of this editing is reported in the 277CA Acknowledgment
Report. For example, data element N403 must be a valid nine-digit ZIP code. If a non-existent ZIP code is
populated, the CEM will reject the encounter.
4.8.1. CMS 5010 Edit Spreadsheets
CMS provides 5010 file format technical edit spreadsheets for the X12 837-I, 837-P, and 837-DME modules
on the CMS website, referred to as the CMS 5010 Edit Spreadsheets. The edits included in the spreadsheets include
those reported in TA1, 999, and 277CA reports. CMS provides this spreadsheet to clarify the TR3 guide instructions
and to add Medicare-specific requirements, and it can be found at https://www.cms.gov/Regulations-andGuidance/Guidance/Transmittals/2017-Transmittals.html (see additional access instructions in Chapter 1, Table 1.1),
To determine the implementation date of the edits contained in the spreadsheet, MAOs and other submitters
should initially refer to the spreadsheet version identifier. The version identifier is composed of 10 characters, as
follows:
• Positions 1–2 indicate the line of business:
-
EA – Part A (837-I)
Chapter 4
Page 20 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
-
EB – Part B (837-P)
CE – DME/Part B Drugs
• Positions 3–6 indicate the year (for example, 2015)
-
Position 7 indicates the release quarter month
-
1 – January release
-
2 – April release
-
3 – July release
-
4 – October release
• Positions 8–10 indicate the spreadsheet version iteration number (for example, V01-first iteration, V02-second
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 date.
4.8.2. Edits Deactivated for Requirements Unique to the Medicare Advantage Program
Several edits currently active in the CMS 5010 Edit Spreadsheet are deactivated in the EDFES in recognition of
several unique requirements of the Medicare Advantage program. Deactivation of these edits ensures that
syntactically correct EDRs and CRRs pass front-edit editing. See Appendix 4A for a list of deactivated edits.
Appendix Table 4A.1 is organized as follows:
•
The Edit Reference column provides the exact reference for the deactivated edits.
•
The Edit Description column provides the Claim Status Category Code, the Claim Status Code, and the Entity
Identifier Code, when applicable.
•
The Notes column provides a description of the edit reason.
•
Columns “I”, ”P”, and “D” indicate if the edit is deactivated for Institutional, Professional, or DME encounters,
respectively.
MAOs and other entities should reference the WPC website at https://www.wpc-edi.com for a complete listing
of all Claim Status Category Codes and Claim Status Codes.
4.8.3. 277CA Acknowledgement Report
The 277CA is an unsolicited Acknowledgement Report from CMS to MAOs and other entities. The 277CA
Acknowledgement Report provides the status of each EDR or CRR as either accepted or rejected due to CCEM
edits.
The 277CA is used to acknowledge the acceptance or rejection of encounters submitted using a hierarchical
level (HL) structure. There are four hierarchical levels:
Chapter 4
Page 21 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
1) Information Source (HL Code = 20); Sender of the 277CA (for example, Palmetto GBA)
2)
Information Receiver (HL Code = 21); Submitter of data to CMS
3) Provider of Service (HL Code = 19); Billing Provider
4) Patient (HL Code = PT); Beneficiary
Acceptance or rejection at this level is based on the TR3 guides, and the CMS 5010 Edit Spreadsheets. 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 EDR, individual patient edits will not be performed.
When the EDR is rejected at any hierarchical level, the entire EDR will reject and the submitter will be
required to correct and resubmit the encounter until it is accepted. For example, if there is a problem with the Billing
Provider of Service submitted on the 837, individual patient edits will not be performed.
The STC03 data element value will indicate the status of the HL:
•
“WQ” if the HL was accepted
•
“U” if the HL was rejected
If an EDR is accepted, the 277CA will provide the Internal Control Number (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.
4.8.4. Example: 277CA Acknowledgement Report
Figure 4.7 and Table 4.8 present an example of a 277CA Acknowledgement Report.
Chapter 4
Page 22 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 4.7. Example of 277CA Report
Table 4.8. Reference Table for Figure 4.7 277CA Acknowledgement Report example
Data String
Line From
Figure 4.7
Data
Element
10
HL
10
HL
2
10
10
HL
HL
1
21
10
11
11
11
HL
NM1
NM1
NM1
1
41
2
11
NM1
WESTMORE
11
11
NM1
NM1
46
ENC9999
Chapter 4
Data Element
Value
Description
277CA segment identifier
Identifies this level as the 2nd level within this ST/SE transaction
set
Identifies this level as the subordinate to level "1" (HL 1 is parent
to this level)
Identifies this level as 21, which means Information Receiver
Identifies that there is at least one additional subordinate level
beyond this level (a child level follows)
277CA segment identifier
Entity Code, 41 = Submitter
Entity Type Qualifier, 2 = Non-Person Entity
Information Receiver Name (Submitter Name entered in Loop
1000A, data element NM103 on the 837)
Entity qualifier, 46 = Entity's ID Electronic Transmitter
Identification Number (ETIN)
Identifies the entity's contract number
Page 23 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Data String
Line From
Figure 4.7
Data
Element
12
12
TRN
TRN
12
14
14
14
26
26
26
26
26
27
27
27
28
28
28
TRN
QTY
QTY
QTY
STC
STC
STC
STC
STC
REF
REF
REF
DTP
DTP
DTP
Data Element
Value
Description
277CA segment identifier
2
DCED27494COE-49DD2AC01-87AED
90
1
A2:20:PR
20170620
WQ
56.1
1K
1717120010802
472
D8
Provider of Service information - Trace Identifier
277CA segment identifier
Entity Code, 90 = Acknowledged Quantity
Total Accepted Quantity
277CA segment identifier
Accepted Reason Code
Status Effective Date
Status Code Indicator
Total Claim Charge Amount
277CA segment identifier
Reference Identification Qualifier
Internal Control Number assigned to the claim by the payer
277CA segment identifier
Date/Time qualifier
Identifies the format as the date/time period format identifier
4.9. Strategic National Implementation Process (SNIP) Edits in the Translator
and CCEM
The Workgroup for Electronic Data Interchange (WEDI) was established in 1991 to coordinate within the
healthcare industry to identify practical strategies for reducing administrative costs in healthcare through the
implementation of EDI. WEDI helped secure the passage of the Health Insurance Portability and Accountability Act
of 1996 (HIPAA) and was acknowledged as the facilitator of industry consensus on the implementation and
fulfillment of the HIPAA mandate. In 2003, WEDI proposed expansion of EDI testing to include seven unique types
of testing. Table 4.9 provides the definition of the SNIP types and location within the EDS. Figure 4.8 illustrates the
SNIP types and their link to the EDS.
Chapter 4
Page 24 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 4.9. Strategic National Implementation Process Types of Testing
SNIP
Type
SNIP Type of Testing
SNIP Type Definition
SNIP Type
EDS Location
Type 1
Integrity Testing
Tests for valid segments, segment order, element
attributes, testing for numeric values in numeric
data elements, validation of X12 syntax and
compliance with X12 rules.
Translator
Type 2
Requirement Testing
Tests for HIPAA IG specific requirements, such as
repeat counts, used and not used codes, elements
and segments, required or intra-segment situational
data elements (nonmedical code sets as laid out in
the IG), and values noted by an X12 code list or
table.
Translator
Type 3
Balancing Testing
Note: Does not apply to
Medicare Advantage
encounter data
Tests the transaction for balanced field totals,
record or segment counts, financial balancing of
claims, and balancing of summary fields.
Translator
Type 4
Situation Testing
Tests the specific inter-segment situations
described in the HIPAA IGs such that: if ‘A’
occurs, then ‘B’ must be populated. This is
considered to include the validation of situational
fields given values or situations present elsewhere
in the file.
Translator
Type 5
Type 6
Code Set Testing
Line of Business Testing
Tests for valid IG specific code set values.
Specialized testing required by certain product
types/types of service such as chiropractic,
ambulance, durable medical equipment, etc.
CEM
CEM
Type 7
Trading Partner-Specific
Testing
Tests edits in the HIPAA IG that are unique and
specific to a payer/receiver.
Translator
EDS = Encounter Data System; HIPAA = Health Insurance Portability and Accountability Act of 1996; IG =
Implementation Guide; CEM = Common Edits and Enhancements Module.
Chapter 4
Page 25 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 4.8. Strategic National Implementation Process Types and the EDS
Note: All rejected lines must be removed from the EDR or CRR prior to submission. After receipt of corrected
data, the MAO or other entity may submit an adjustment encounter to the FERAS for processing.
4.10.
Post-screening Validation and the Invalid Report
Finally, the last stage of EDFES editing pertains to requirements for the Medicare Advantage program that are
not addressed in the other phases of editing described above (for example, checking the Plan-to-Submitter security
access credentials).
The EDFES distributes a Post-Screening Invalid Report, formerly known as the EDFES Notification Report, to
notify MAOs when a file failed. When a Post-Screening Invalid Report is generated, the file will not proceed for
further processing.
The Post-Screening Invalid Report has an 80 character record length and contains the following record layout:
1. File Name Record
Positions 1–7 = Blank Spaces
Positions 8–18 = File Name:
Positions 19–62 = Name of the Saved File
Positions 63–80 = Blank Spaces
2. File Control Record
Positions 1–4 = Blank Spaces
Positions 5–18 = File Control:
Positions 19–27 = File Control Number
Positions 28–80 = Blank Spaces
Chapter 4
Page 26 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
3. File Count Record
Positions 1–18 = Number of Claims:
Positions 19–24 = File Claim Count
Positions 25–80 = Blank Spaces
File Separator Record
Positions 1–80 = Separator (----------)
File Message Record
Positions 1–80 = FILE WILL NOT PROCEED FOR FURTHER PROCESSING FOR THE FOLLOWING
REASON(S)
The report format example is as follows:
FILE NAME: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
FILE CONTROL: XXXXXXXX NUMBER OF CLAIMS: 99,999
FILE WILL NOT PROCEED FOR FURTHER PROCESSING FOR THE FOLLOWING REASON(S)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Table 4.10 provides the Post-Screening Invalid Report file type, notification message, message description, and
indicator of applicability to institutional, professional, and DME CRRs. The messages do not occur in any other
Acknowledgement Reports.
Table 4.10. Post-Screening Invalid Report for Institutional, Professional, and DME Encounter Data
Records and Chart Review Records
Applies To
Notification Message
Notification Message
Description
INST
PROF
DME
All files
submitted
File ID (XXXXXXXXX) is a
duplicate of a file id sent within
the last 12 months
The file ID must be unique
for a 12 month period
Y
Y
Y
All files
submitted
Submitter not authorized to send
EDRs for this contract (Contract
ID)
The submitter is not
authorized to send EDRs for
this contract
Y
Y
Y
All files
submitted
Contract ID cannot be the same
as the submitter id
The Contract ID cannot be
the same as the Submitter
ID
Y
Y
Y
All files
submitted
At least one EDR is missing a
contract ID in the 2010BBREF02 segment
The Contract ID is missing
Y
Y
Y
Chapter 4
Page 27 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Applies To
Notification Message
Notification Message
Description
INST
PROF
DME
Production
files
submitted
Submitter not certified for
production
The submitter must be
certified to send EDRs for
production
Y
Y
Y
All files
submitted
See service type columns
The maximum number of
EDRs allowed in a file
File
cannot
exceed
5,000
EDRs
File
cannot
exceed
85,000
EDRs
File
cannot
exceed
85,000
EDRs
All files
submitted
Transaction set (ST/SE)
(xxxxxxxxx) cannot exceed
5,000 claims
There can only be 5,000
claims in each ST/SE Loop
Y
Y
Y
All files
submitted
Date of service cannot be before
2011
Files cannot be submitted
with a date of service before
2011
Y
Y
Y
All files
submitted
CAS adjustment amount must
not be 0
The CAS Adjustment
Amount cannot be zero (0).
Y
Y
Y
All files
submitted
Billing provider loop is missing
The Billing Provider Loop
must be present.
Y
Y
Y
End-to-End
Testing File 1
File cannot contain both
unlinked and linked test cases
The test cases from File 1
and File 2 cannot be in the
same file
Y
End-to-End
Testing File 1
Cannot send linked test cases
until all unlinked test cases have
been accepted
The test cases for File 2
cannot be sent before all
File 1 test cases are
accepted
Y
Tier 2 files
submitted
The interchange usage indicator
must equal ‘T’
The Institutional Tier 2 file
is being sent with a ‘P’ in
the ISA15 field
Y
Y
Y
Tier 2 files
submitted
The contract ID has (x,xxx)
claims in this file. Only 2,000
are allowed
The number of encounters
for a Contract ID cannot be
greater than 2,000
Y
Y
Y
End-to-End
Testing
See service type columns
See service type columns
File
cannot
contain
more
than 6
EDRs
File
cannot
contain
more
than 6
EDRs
File
cannot
contain
more
than 4
EDRs
End-to-End
Testing
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
Y
Y
Y
End-to-End
Testing
File contains (x) test case (x)
encounter(s)
The file must contain two
(2) of each test case
Y
Y
Y
Chapter 4
Page 28 of 30
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Applies To
Notification Message
End-to-End
Testing
Additional files cannot be
validated until an MAO-002
report has been received
Test
No test cases found in this file
Notification Message
Description
INST
PROF
DME
The MAO-002 report must
be received before
additional files can be
submitted
Y
Y
Y
This file was processed with
the Interchange Usage
Indicator = ‘T’ and the
Submitter is not yet
Certified
Y
Y
EDR = encounter data record; CAS = Claim Adjustment Segments; MAO = Medicare Advantage
Organization.
When EDRs and CRRs have been processed and accepted by the FERAS, they are passed to the back-end
EDPS, as described in Chapter 5.
Chapter 4
Page 29 of 30
This page left intentionally blank for double-sided copying.
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Chapter 5. EDPS Processing
5.1.
TERMINOLOGY ............................................................................................................................... 2
5.2.
OVERVIEW OF EDPS PROCESSING ................................................................................................ 2
5.3.
EDPS REPORTS TO SUBMITTERS................................................................................................... 3
5.4.
5.3.1.
MAO-001 Encounter Data Duplicates Report ...................................................... 3
5.3.2.
MAO-002 Encounter Data Processing Status Report ............................................. 4
REPORT RESTORATION ................................................................................................................. 6
________________________________________
Chapter 5
Page 1 of 8
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
5.1.
Terminology
(1) In various publications, the term Encounter Data System (EDS) is used to describe both the Encounter Data
Front-End System (EDFES) and the back-end Encounter Data Processing System (EDPS). In this guide, we have
separate chapters distinguishing the EDFES and the EDPS.
(2) To reduce the number of acronyms, CMS is retiring the following names and acronyms for processes
within the EDPS:
• Retired: Encounter Data Professional Processing and Pricing System (EDPPPS)
• Retired: Encounter Data Institutional Processing And Pricing System (EDIPPS)
• Retired: Encounter Data Durable Medical Equipment (DME) Processing and Pricing System (EDDPPS)
5.2.
Overview of EDPS Processing
Once an encounter data record (EDR) or chart review record (CRR) has successfully passed through the frontend EDFES edits (accepted on the 277CA acknowledgement report and assigned an Internal Control Number (ICN),
and moved through post-screening without triggering an Invalid Report), the record is then transferred to the backend EDPS for additional processing. During EDPS processing, EDRs and CRRs are subjected to additional recordand line-level edits that result in records and/or lines being rejected or accepted. Many of the edits apply to
institutional records and professional/DME records, whereas other edits are specific to the record type (institutional
or professional/DME).
There are two possible edit dispositions for edits applied in the EDPS: Informational and Reject.
• Informational edits: Informational edits are indicated by an “I” before the edit description; for example, the
description for edit 25000 would read ‘25000 I:CCI Error’ with the ‘I’ indicating that this is an informational
edit. An Informational edit results in an accepted record or line and will not cause processing to cease.
• Reject edits indicate that the submitter must resubmit the record through the EDFES. The resubmitted encounter
must then pass editing at the translator and Combined Common Edits Module (CEM) levels before being
transferred again to the EDPS.
-
If there is a reject edit at the header level, the encounter will reject.
-
If there is no reject edit at the header level but all lines reject, the record will reject.
-
If there is no reject edit at the header level and at least one of the lines is accepted, then the record will be
accepted.
A full list of edits that occur in the EDPS can be located in the “EDPS Edit Code Look-up Tool,” which is
available at https://www.csscoperations.com.
Two reports, the MAO-001 and the MAO-002, are generated that reflect the outcome of the EDPS editing
process. These reports are discussed in the following section.
Chapter 5
Page 2 of 8
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
5.3.
EDPS Reports to Submitters
The EDPS generates two reports on the outcome of the editing process: MAO-001, MAO-002 reports. These
data processing reports are delivered to submitters in a fixed-length format and distributed by two methods: flat file
and formatted. Flat file reports are categorized by header record, detail record, and trailer record. MAO-001 and
MAO-002 are posted to the SFTP mailbox within 5 business days of receipt of files. Please refer to the Medicare
Advantage & Part D Communication Handbook at www.csscoperations.com for information regarding access and
report retention.
Table 5.1 describes these production EDPS reports, which become available within five business days of
receipt from the EDFES (testing reports should be available within seven business days of receipt from the EDFES).
Table 5.1. EDPS Processing Status Reports
EDPS Report Type
Description
MAO-001 Encounter Data
Duplicates
Lists all encounters that received duplicate errors (98300, 98325, 98320, and 98315)
*Medicare Advantage Organizations and other entities will not receive the MAO001 report if there are no duplicate errors received on submitted encounters.
* Medicare Advantage Organizations and other entities will not receive the MAO001 report on test files. MAO-001 reports are generated for Production files only.
MAO-002 Encounter Data
Processing Status
5.3.1.
Lists the accepted and rejected status of all encounters at the claim (header) and line
levels, along with edit codes and brief edit descriptions.
MAO-001 Encounter Data Duplicates Report
The EDPS will generate and return the MAO-001 Encounter Data Duplicates Report. Medicare Advantage
Organizations (MAOs) and other entities will not receive the MAO-001 report if no duplicate errors are received on
submitted encounters. When the MAO-001 Encounter Data Duplicates Report is returned to an MAO or other entity,
it contains one or more of the following edits:
98300 – Exact Inpatient Duplicate Encounter
98315 – Linked Chart Review Duplicate
98320 – Chart Review Duplicate or
98325 – Service Line(s) Duplicated
Details on the MAO-001 report include the encounter ICN and service line that is rejected, along with record
type, the previously submitted and accepted encounter ICN and service line, plan id, date of service, error code, and
beneficiary ID.
The MAO-001 report is a fixed-length report available in flat file and formatted report layouts.
Chapter 5
Page 3 of 8
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 5.1. MAO-001 Record Data Duplicates Report
Figure 5.2. MAO-001 Report – Key Data Elements
5.3.2.
MAO-002 Encounter Data Processing Status Report
The MAO-002 Encounter Data Processing Status Report provides information on the disposition status
(accepted and rejected) and edit codes for all records and lines for each file submitted.
The MAO-002 Report reflects two disposition statuses at the record and service line levels: “accepted” or
“rejected.” Lines with a status of “accept” but containing an error code and a message in the Error Description
Chapter 5
Page 4 of 8
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
column have triggered informational edits. MAOs and other entities are not required to take further action on
informational edits; however, they are encouraged to review submissions to ensure accuracy of internal claims
processing data.
The “000” line on the MAO-002 report identifies the header level. If the header is rejected, the entire record is
considered rejected and MAOs and other entities must correct and resubmit the record. If the “000” header line is
accepted and at least one other line (that is, 001 002 003 004) is accepted, then the record is accepted. If all the lines
within the record are rejected, the “000” header line is rejected without error code and description.
To reconcile a rejected record identified on an MAO-002 report, the MAO must submit a new record after
applying corrections. If the record is accepted and the service line(s) is rejected, the MAO must submit a
correct/replace record, where CLM05-3 equals “7”. The final disposition of the record is determined based on the
submitter’s receipt of the MAO-002 report, with the assigned ICN.
00265 – Correct/Replace or Void ICN Not in EODS (Encounter Operational Data Store): If a submitter
attempts to submit an adjustment for a previously submitted record before receiving the MAO-002 report and the
EDPS has not completed processing of that previously submitted record, the submitter may receive the error 00265.
00760 – Adjusted Encounter Already Void/Adjusted (Reject): If a submitter submits an initial adjustment
EDR (ICN2) for a previously submitted EDR (ICN1) and then attempts to submit a subsequent adjustment EDR
(ICN3) with the same parent ICN (ICN1) before receiving the MAO-002 report for an initial adjustment EDR
(ICN2), the submitter may receive the error 00760.
00755 – Void Encounter Already Void/Adjusted (Reject): If a submitter submits an initial void EDR (ICN2)
for a previously submitted EDR (ICN1) and then attempts to submit a subsequent void EDR (ICN3) with the same
parent ICN (ICN1) before receiving the MAO-002 report for an initial void EDR (ICN2), the submitter may receive
the error 00755.
Chapter 5
Page 5 of 8
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 5.3. MAO-002 Encounter Data Processing Status Report
MAOs should wait for receipt of MAO-002 reports to properly reconcile any submissions before submitting
replacement records. MAOs should only submit adjudicated records with changes in data from the original record
data submission. Avoiding duplicate record submissions will allow the EDS to process all records more efficiently
and cost-effectively so that timely and accurate reporting can continue.
5.4.
Report Restoration
The MAO-001 and MAO-002 reports are stored in the CMS repository for a limited time. Under certain
circumstances, MAOs may need to request that reports be restored. For example, reports not retrieved from the
MAO’s mailbox within 14 days are deleted from the MAO’s mailbox. MAOs should always download reports after
initially opening them to avoid the need for report restoration. CMS will restore reports based on the date the report
was originally distributed to an MAO or other entity. EDPS reports will not be restored if the requested files are
older than 60 business days from the original distribution date. Requests to restore more than 200 files will not be
accepted.
CMS recommends that MAOs and other entities monitor their files and submit requests appropriately, and
CMS reserves the right to deny requests that manipulate the guidelines. If MAOs/ Medicare-Medicaid Plans are
Chapter 5
Page 6 of 8
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
uncertain if an MAO report has been generated, please do not resubmit the file. Contact the Customer Service and
Support Center Operations Help Desk for assistance.
Chapter 5
Page 7 of 8
This page left intentionally blank for double-sided copying.
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Chapter 6. Prevention and Resolution Tips for ED Submission Errors
6.1.
6.2.
6.3.
6.4.
6.5.
OVERVIEW OF EDIT CODES ..................................................................................................................... 2
SELECTED NEW AND UPDATED EDIT CHANGES ................................................................................ 2
New Edits: Edit 00820 – Diagnosis Code Must Exist on Parent Record..................... 2
6.2.1.
6.2.2.
New Edits: Edit 00825 – Chart Review Must Match Parent Record ........................... 3
6.2.3.
New Edits: Edit 01410 – Invalid Billing Provider NPI ............................................... 4
6.2.4.
Updated Edits: Edit 00699 – Void Must Match Original ............................................ 4
6.2.5.
Updated Edits: Edit 00845 – Adjustment Must Be a Chart Review ............................ 5
6.2.6.
Updated Edits: Edit 00850 – Void Must Be a Chart Review....................................... 5
SELECTED HEADER-LEVEL EDIT CODES – DETAILED INFORMATION AND
EXAMPLES .................................................................................................................................................... 6
6.3.1.
Edit 00265 – Correct / Replace or Void ICN Not in EODS ........................................ 6
6.3.2.
Edit 00760 – Adjusted Encounter Already Void/Adjusted .......................................... 6
6.3.3.
Edit 00780 – Adjustment Must Match Original .......................................................... 8
6.3.4.
Edit 00800 – Parent ICN Not Allowed for Original .................................................... 9
6.3.5.
Edit 02125 – Beneficiary DOB Mismatch ................................................................... 9
6.3.6.
Edit 02240 – Beneficiary Not Enrolled in MAO for Dates of Services..................... 10
6.3.7.
Edit 17330 – Request for Anticipated Payments (RAP) Not Allowed ...................... 12
6.3.8.
Edit 22355 – Inpatient Service Line Error ................................................................. 12
6.3.9.
Edit 22405 – Occurrence Code 55 & Date of Death Required .................................. 13
6.3.10.
Edit 30261 – Referring Physician NPI Required ....................................................... 13
6.3.11.
Edit 98300 – Exact Inpatient Duplicate Encounter.................................................... 14
6.3.12.
Edit 98315 – Linked Chart Review Duplicate ........................................................... 16
6.3.13.
Edit 98320 – Duplicate Chart Review ....................................................................... 17
SELECTED LINE-LEVEL EDIT CODES – DETAILED INFORMATION AND EXAMPLES ............... 20
Edit 02256 – Beneficiary Not Part C Eligible for DOS ............................................. 20
6.4.1.
6.4.2.
Edit 17310 – Rev Code 036X Requires Surg Proc Code........................................... 21
6.4.3.
Edit 98325 – Service Line(s) Duplicated ................................................................... 23
INFORMATIONAL EDIT CODES AND RESOLUTIONS: EDIT 00845 AND EDIT 00850 ................... 25
________________________________________
Chapter 6
Page 1 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
6.1.
Overview of Edit Codes
Edit codes are used throughout encounter data processing to indicate invalid or unacceptable data submitted in
an encounter data set. Note: In some places in this Guide, the term error code is also used, for example, in the
MAO-002 Report record layout and in Chapters 4 and 5.
Information on Encounter Data Front-End System (EDFES) edits can be found in the following locations:
•
Chapter 4, Table 4.4: EDFES Pre-Screening Validation Edits. These edits are text only, not numerical codes.
These edits only apply to Connect:Direct files
•
EDFES Edit Code Look-up Tool: This tool, available at https://www.csscoperations.com, includes edit
codes found in CMS’ 5010 Edit Spreadsheets – that is, Translator edits (837 5010 Interchange envelope and
Functional Group edits) and CCEM edits (837 5010 Transaction Set edits.)
•
Appendix 4A: Edits in CMS’ 5010 Edit Spreadsheets that have been deactivated.
•
Chapter 4, Table 4.10: Post-Screening Invalid Report. These edits are text only, not numerical codes.
Information on Encounter Data Processing System (EDPS) edits can be found in the EDPS Edit
Code Look-up Tool at https://www.csscoperations.com. In addition, online and downloadable listings of
all EDPS edit codes are available on the same website.
Both the EDFES and EDPS Edit Code Look-Up Tools are updated regularly, and it is the responsibility of the
Medicare Advantage Organization (MAO) to ensure its submissions comply with all editing and validation steps.
Currently, this chapter focuses on tips for a subset of the most frequently occurring edits in the EDPS. CMS
expects to add a section on tips regarding frequently occurring edits in the EDFES in future versions of this
document.
6.2.
Selected New and Updated Edit Changes
Since the March 2019 version of this guide, the following edits have been added or updated:
6.2.1.
New Edits: Edit 00820 – Diagnosis Code Must Exist on Parent Record
Encounter Data
Processing System
Edit Code
00820
Edit Code Description
Diagnosis code must exist on parent
record
Disposition
of Edit
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
R
ALL
Chart Review Record (CRR)-Deletes must be linked to another CRR or to an Encounter Data Record (EDR) in
order to ensure that the MAO identifies which EDR or CRR carried the diagnosis that the MAO now wishes to
Chapter 6
Page 2 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
delete. Edit 00820 validates that the diagnosis code(s) submitted on the CRR-Delete match the record to which the
CRR-Delete is linked.
This edit applies to all CRR-Deletes submitted on or after June 28, 2019, for dates of service (DOS) on or after
January 1, 2016.
6.2.2.
New Edits: Edit 00825 – Chart Review Must Match Parent Record
Encounter Data
Processing System
Edit Code
Edit Code Description
Disposition
of Edit
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
00825
Chart review must match parent record
R
ALL
For linked CRRs submitted on or after June 28, 2019, with a from DOS on or after January 1, 2016, this edit
validates the following data fields to ensure that they match the values provided on the record to which the CRR is
linked.
Professional and DME Chart Data Fields
1.
Linked Internal Control Number (ICN) – header level
2.
Member beneficiary identifier Number (HICN/MBI) – header level
3.
Beneficiary Last Name (first 5 characters) – header level
4.
Beneficiary First Name (first character) – header level
5.
Place of Service – header level
6.
Billing Provider NPI – header level
7.
Payer ID – header level
8.
Date of Service – header level
Institutional Data Fields
1.
Linked Internal Control Number (ICN) – header level
2.
Member beneficiary identifier Number (HICN/MBI) – header level
3.
Beneficiary Last Name (first 5 characters) – header level
4.
Beneficiary First Name (first character) – header level
5.
Bill Type – header level
6.
Billing Provider NPI – header level
7.
Payer ID – header level
8.
Date of Service – header level
Chapter 6
Page 3 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
6.2.3.
New Edits: Edit 01410 – Invalid Billing Provider NPI
Encounter Data
Processing System
Edit Code
01410
Edit Code Description
Invalid Billing Provider NPI
Disposition
of Edit
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
R
ALL
Edit 01410 enhances CMS’s validation of Billing Provider National Provider Identifiers (NPIs). For Encounter
and Chart Review Records, CMS validates the submitted Billing Provider NPI on all Institutional, Professional, and
Durable Medical Equipment encounter data for DOS from January 1, 2011 and forward against NPIs contained in
the National Plan and Provider Enumeration System (NPPES) database, and if the NPI is not found or is inactive,
the record will reject. The EDPS will utilize the data in the NPPES Full Replacement Monthly NPI File and the
Weekly Incremental NPI File to edit the Billing Provider Identification Code. This reference data is publicly
available on the CMS website (https://www.cms.gov/Regulations-and-Guidance/AdministrativeSimplification/NationalProvIdentStand/DataDissemination.html ). The NPI submitted in the header Billing Provider
Identification code field should be active in NPPES for the “from date of service” on the submitted record. The
EDPS will maintain a record of all enumeration and all deactivation dates for each NPI from January 1, 2011 going
forward.
6.2.4.
Updated Edits: Edit 00699 – Void Must Match Original
Encounter Data
Processing System
Edit Code
00699
Edit Code Description
Void must match original
Disposition
of Edit
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
R
ALL
Edit 00699 checks to ensure that when a Void encounter data record (EDR) or chart review record (CRR) is
submitted, the following subset of data fields on the Void record match the corresponding data fields on the
encounter data record that is to be voided:
•
ICN of record to be voided
•
Member beneficiary identifier (HICN/MBI)
•
Last Name
•
First Name
•
Place of Service (PROF/DME record only)
•
Submitted Charges
Chapter 6
Page 4 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
•
Date of Service
•
Number of Encounter Lines
•
Billing Provider NPI
•
Rendering Provider NPI (if applicable)
•
Payer ID
Due to a difference in storage of the submitted charges data in the legacy system (used prior to June 11, 2018)
and the current system (launched on June 11, 2018), CMS updated the edit to bypass the submitted charges
validation only for original and replacement EDRs and CRRs submitted prior to June 11, 2018 with a subsequent
void submitted after June 11, 2018. If you received a rejected void EDR/CRR that posted with edit 00699, and the
original or replacement record was submitted prior to June 11, 2018, it is recommended that you resubmit the
rejected void records. The submitted charges field remains a required field and no action is needed if the original or
replacement EDR/CRR was submitted after June 11, 2018 and subsequently a void EDR/CRR for that record was
also submitted.
6.2.5.
Updated Edits: Edit 00845 – Adjustment Must Be a Chart Review
Encounter Data
Processing System
Edit Code
00845
Edit Code Description
Adjustment must be a chart review
Disposition
of Edit
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
R
ALL
Edit 00845 ensures that a replacement record that is linked to a CRR is also a CRR. This edit was implemented
as an informational edit in September 2017. The disposition of this edit was changed from informational to reject
beginning June 28, 2019. If an EDR is submitted as a replacement and the linking ICN references a previously
submitted and accepted CRR, the replacement EDR will be rejected with Edit 00845.
As noted in Section 2.3 of the Encounter Data Submission and Processing Guide, EDRs cannot be submitted to
replace CRRs, and CRRs cannot be submitted to replace EDRs.
6.2.6.
Updated Edits: Edit 00850 – Void Must Be a Chart Review
Encounter Data
Processing System
Edit Code
00850
Chapter 6
Edit Code Description
Void must be a chart review
Disposition
of Edit
R
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
ALL
Page 5 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Edit 00850 ensures that a void record that is linked to a CRR is also a CRR. This edit was implemented as an
informational edit in September 2017. The disposition of this edit was changed from informational to reject
beginning June 28, 2019. If a void EDR is submitted and the linking ICN references a previously submitted and
accepted CRR, the void EDR will be rejected with Edit 00850
As noted in Section 2.3 of the Encounter Data Submission and Processing Guide, EDRs cannot be
submitted to replace CRRs, and CRRs cannot be submitted to replace EDRs.
6.3.
Selected Header-Level Edit Codes – Detailed Information and
Examples
6.3.1.
Edit 00265 – Correct / Replace or Void ICN Not in EODS
Encounter Data
Processing System
Edit Code
00265
Edit Code Description
Disposition
of Edit
Scenario Applies To:
(Institutional,
Professional, DME,
ALL)
R
ALL
Correct/Replace or Void Internal
Control Number ICN Not in EODS
Example scenarios
Example 1: Wednesday Health Services sent an original encounter to the (Encounter Data System) EDS and
received accepted Internal Control Number (ICN) 123456789. Dr. John May corrected the associated claim and
resubmitted to Wednesday Health Services. Wednesday Health Services submitted the replacement encounter to the
EDS using ICN 234567890. The encounter was rejected because the ICN was invalid for the replacement encounter
submission.
Example 2: Chance Medical Services submitted an encounter to the EDS and received an MAO-002 report
with an accepted ICN of 123456789. The encounter required an adjustment (void or replacement). Chance Medical
Services submitted a replacement encounter using ICN 234567899. The replacement encounter was rejected because
there was no original record in the EDS for this ICN with the same Submitter ID.
Prevention/resolution strategy: Replacement or void encounter data record submitted with an invalid ICN.
EDS does not store rejected ICNs. Verify the accuracy of the ICN on the returned MAO-002 report.
6.3.2.
Edit 00760 – Adjusted Encounter Already Void/Adjusted
Encounter Data
Processing System
Edit Code
00760
Chapter 6
Edit Code Description
Adjusted Encounter Already
Void/Adjusted
Disposition of
Edit
Scenario Applies To:
(Institutional,
Professional, DME, ALL)
R
ALL
Page 6 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Example scenarios:
Example 1: On 8/20/2012, Pragmatic Health submitted a replacement encounter for ICN 123456789 to correct
a Current Procedural Terminology (CPT) code. However, Pragmatic Health had already submitted a void for the
same ICN on 8/18/2012 but had not yet received the MAO- 002 report by 8/20/2012. Pragmatic Health received edit
00760 on a subsequent MAO-002 report because the EDPS had already processed the void encounter submitted on
8/18/2012.
Example 2: (Rejected records included ICNs for records that had been previously replaced): An original
record submitted and accepted in 2015 (ICN: 15152XXXXXXXX).
A replacement record (ICN: 17188XXXXXXXX) submitted on 7/8/2017 and successfully replaced the
original record. A second replacement record (ICN: 17192XXXXXXXX) submitted on 7/12/2017. The second
replacement rejected with Edit 00760 because the original/parent (ICN = 15152XXXXXXXX) has already been
replaced. The original/parent ICN should be 17188XXXXXXXX.
Example 3: (Rejected records included ICNs for records that had already been voided.): An original record
was submitted and accepted in 2015 (ICN: 15177XXXXXXXX).
A Void record (ICN: 17072XXXXXXXX) with claim frequency “8” was submitted on 3/15/2017 and
successfully voided the original record (ICN: 15177XXXXXXXX).
A replacement record (ICN: 17192XXXXXXXX) was submitted on 7/12/2017 with the ICN of the voided
record (ICN: 17072XXXXXXXX). The replacement record was rejected with Edit 00760.
Edit features:
•
Header-level edit
•
Applicable to both encounter data and chart review replacement records (Claim Frequency Code = 7).
•
Displayed on a replacement encounter data or chart review record (Claim Frequency Code = 7).
•
Displayed when the original/parent record whose ICN was submitted on the replacement encounter data or chart
review record has already been voided or replaced by a previous replacement or void encounter data record.
Prevention/resolution strategy: The submitter has previously voided an encounter data record and is
attempting to replace the same voided encounter OR the submitter has previously replaced an encounter data record
and is attempting to replace the same replaced encounter.
The submitter should review returned MAO-002 reports to confirm processing of the voided encounter data
record or replacement encounter data record before resubmitting the replacement.
Ensure that replacement records are submitted with the correct reference ICN of the most recently submitted
accepted record.
•
An accepted encounter record can only be replaced or voided once.
•
If a record has been successfully replaced by a replacement record and the submitter wants to send a subsequent
replacement record to modify additional data elements, the second replacement record must be submitted with
the ICN of the first accepted replacement record.
Chapter 6
Page 7 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
•
Do not submit a replacement record with an ICN of a voided record. If a voided record was submitted in error,
the submitter must resubmit the original encounter data record.
•
This new encounter data record must be submitted with claim frequency “1”, because the system will not allow
any replacements of voided records.
6.3.3.
Edit 00780 – Adjustment Must Match Original
Encounter Data
Processing System
Edit Code
00780
Edit Code Description
Adjustment Must Match Original
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Example scenario
Torchlight Healthcare submitted an encounter totaling $250 for services provided to Ciao Bella by Dr. Gavin
and received ICN 5555555555557. Dr. Gavin’s staff identified the need to adjust the payment amount and sent the
corrected amount, $205, to Torchlight Healthcare under a different billing National Provider Identifier (NPI) than
the billing NPI on the original encounter data record (EDR) (ICN 5555555555557). Torchlight Healthcare submitted
the replacement encounter to the EDPS with the corrected payment information and the new billing NPI. The EDPS
rejected the replacement encounter because the billing NPI on the adjustment record did not match the billing NPI of
the EDR that it was intended to replace.
Edit features:
•
Header-level edit
•
Applicable to both encounter data and chart review replacement records (Claim Frequency Code = 7).
•
Applicable to replacement records only
The seven key header-level data elements listed below from a replacement record must match the previously
submitted and accepted record that the newly submitted record is intended to replace:
-
Linked Internal Control Number
-
Beneficiary HIC Number (or Member Beneficiary Identifier (MBI))
-
Beneficiary Last Name (first five characters)
-
Beneficiary First Name (first character)
-
Place of Service (professional and DME records) / Type of Bill (institutional records)
-
Billing Provider NPI
-
Payer ID
CMS analysis: A CMS analysis demonstrated that the edit is posting accurately on replacement EDRs.
Observations from the analysis indicated that in most cases there was a mismatch of the billing NPI submitted on the
replacement record and in some instances there were mismatches with beneficiary last name or first name.
Chapter 6
Page 8 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Prevention/resolution strategy: When submitting a replacement encounter, MAOs must match the ICN,
Health Insurance Claim Number (HICN) or Member Beneficiary Identifier (MBI), Last Name, First Name, Billing
Provider NPI, Payer ID, and Type of Bill (TOB) (INST only), POS (PROF/DME only), of the EDR that is to be
replaced. Note: The EDPS will validate the beneficiary’s demographic data (HICN or MBI , Last Name, First
Name) according to the Medicare Beneficiary Database (MBD), as well as validate the beneficiary’s Billing
Provider NPI before posting edit 00780.
6.3.4.
Edit 00800 – Parent ICN Not Allowed for Original
EDPS Edit
Code
00800
Edit Code Description
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Parent ICN Not Allowed for Original
Example scenario:
Southwest Health Plan submitted an original, non-chart review encounter for Samuel Anderson. The original,
non-chart review encounter contained a reference to ICN 4561234561233. The EDPS rejected the encounter because
an original non-chart review encounter should not contain an ICN.
The original encounter should be resubmitted without the ICN.
Prevention/resolution strategy: An original non-chart review EDR will be rejected if an ICN or any other
data are populated in Loop 2300 REF02 along with REF01= F8. An original non-chart review encounter data record
should not contain a linked ICN.
Note: Although some MAOs use the ICN field for their own purposes, there are also cases where MAOs
intended to submit voids, replacements, or linked chart reviews, and did not submit the proper claim frequency code
or indicate a chart review record. To avoid having records with an unclear intent, we will reject records that are not
clearly original EDRs.
6.3.5.
Edit 02125 – Beneficiary DOB Mismatch
EDPS Edit
Code
02125
Edit Code Description
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Beneficiary DOB Mismatch
Example scenario:
Swan Health submitted an encounter to the EDS for Joe Blough that listed Mr. Blough’s DOB as 12/13/1940.
The CMS systems listed Mr. Blough’s DOB as 12/13/1937. The EDS returned the MAO- 002 report to Swan Health
with edit 02125 due to the year of birth exceeding the two-year variance.
Chapter 6
Page 9 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Edit features:
•
Header-level edit
•
Applicable to EDRs and chart review records (CRRs)
CMS analysis: A 2017 CMS analysis demonstrated, for the sample reviewed, that the enrollee information
submitted on the records differs significantly from the enrollee data in the EDPS reference tables. Specifically, in the
sample reviewed, the DOB submitted on the records was different than the DOB in the EDPS reference tables. The
day, the month, or both the day and month, of the DOB submitted did not match the day and month information in
the EDPS reference tables. In all instances, the year of the enrollee’s DOB submitted on a record was the same as
the year of the enrollee’s DOB in the EDPS reference tables.
Prevention/resolution strategy: This edit checks to make sure that the DOB submitted on the EDR matches
the MBD data in CMS’ encounter data system. CMS’ analysis of a sample of records failing these checks shows that
the DOB information submitted does not match the data in the MBD. CMS also checked to see if the MBD data had
changed recently and found that the data in the MBD match the data in the Monthly Membership Report (MMR)
and have not been changed for several years in most cases. MAOs have access to the correct data in their MMRs.
Verify that the DOB populated on the encounter matches the DOB listed in CMS’ systems. The EDPS will
accept these encounters within plus or minus two years from a beneficiary’s birth year. Note: CMS anticipates that
the change in this edit will be short term and expects plan sponsors to improve their submission of DOBs.
The edit will result in a rejection when the DOB on the record does not match the enrollee’s DOB in the CMS
enrollment reference data
Note: Currently, the day and month submitted on the EDR corresponding to the beneficiary/member’s DOB
must be an exact match to the day and month of the member’s DOB within the CMS enrollment reference data.
However, the year submitted for the member’s DOB on the EDR may differ with the member’s DOB year stored in
the CMS enrollment reference data by plus or minus two years.
6.3.6.
Edit 02240 – Beneficiary Not Enrolled in MAO for Dates of Services
Encounter Data
Processing System Edit
Code
02240
Edit Code Description
Beneficiary Not Enrolled in
MAO for dates of services
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Example scenario:
Gabrielle Boyd was admitted to Faith Hospital for an appendectomy on 6/11/2012 and was discharged on
6/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 7/12/2012. Ms. Boyd’s effective date with Adams
Chapter 6
Page 10 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Healthcare was 7/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.
Edit features:
•
Header-level edit for Institutional, Professional and DME records
•
Applicable to EDRs only. As of December 22, 2017, this edit is bypassed for chart review records. Please see
Health Plan Management System (HPMS) Technical Release Memo dated December 15, 2017.
•
The EDPS first validates if the contract ID submitted on the record for the enrollee matches the contract ID in the
CMS enrollment reference data. If the contract ID does not match the data in the CMS enrollment reference data,
the record will be rejected with edit 02240 posting.
•
If the contract ID matches the data in the CMS enrollment reference data, then the system validates if the dates of
service on the encounter are within the contract enrollment dates.
CMS analysis: A 2017 CMS analysis demonstrated, for the sample reviewed, the enrollee information
submitted on the records differ significantly from the enrollee data in the EDPS reference tables. Specifically, in the
sample reviewed, the enrollee was not enrolled in the contract for the dates of services (DOS) submitted on the
record. Examples include the following:
•
The enrollee has a date of death recorded in the EDPS reference table and is no longer enrolled in the contract
for the DOS submitted on the record.
•
In these instances, the DOS submitted are after the enrollee has been disenrolled from the contract.
•
(Note: An enrollee is automatically disenrolled from a contract at the end of the month based on his or her date
of death).
•
The enrollee was not enrolled in the contract submitted on the record for the DOS on the record. In these
instances, the enrollee was enrolled in a different contract for the DOS submitted. In some instances, the
beneficiaries’ enrollment in the contract ended.
The enrollee was not enrolled in a Medicare Advantage (MA) contract for the submitted DOS. In these
instances, the DOS submitted on the record are prior to the enrollee being enrolled in an MA contract.
Prevention/resolution strategy: Verify that the beneficiary was enrolled in contract during DOS on the
encounter. If the beneficiary was not enrolled in contract for the encounter DOS, do not submit the encounter.
Encounters should only be submitted for DOS in which the beneficiary was enrolled in your contract. Verify the
enrollees enrollment and demographic information using the reports distributed monthly through the Medicare
Advantage Prescription Drug System (MARx). Populate the correct enrollment and demographic information
accordingly on encounter data and chart review records.
Bypass conditions:
This edit is bypassed for unlinked or linked chart review records with dates of service outside of contract
enrollment periods.
For encounter data records, the bypass conditions are as follows:
Chapter 6
Page 11 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Professional records: If the “from date” on the header is the same as or before the enrollee’s disenrollment date
in the contract AND the “through date” is after the enrollee’s disenrollment date in the contract AND the Place of
Service value on the record is 21, 31, 32, 51, 55, 56, or 61.
Institutional encounters: If the “from date” on the header is the same or before the enrollee’s disenrollment date
in the contract AND the “through date” is after the enrollee’s disenrollment date in the contract AND the Type of
Bill value on the record is 11X, 12X, 18X, 21X, 22X, 41X, OR 85X.
DME encounters: If the “from date” on the header is the same or before the enrollee’s disenrollment date in the
contract AND the “through date” is after the enrollee’s disenrollment date in the contract.
6.3.7.
Edit 17330 – Request for Anticipated Payments (RAP) Not Allowed
Encounter Data
Processing System
Edit Code
17330
Edit Code Description
RAP Not Allowed
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
INST
Example scenario:
Magic Morning Health Plan submitted an encounter to the EDS for BackHome Health (a primary home health
agency) with TOB 322. The encounter was rejected because the EDS does not accept Request for Anticipated
Payment (RAP) encounters.
Prevention/resolution strategy: Requests for Anticipated Payment cannot be submitted for Home Health
encounters TOBs 322 or 332 (with DOS before 10/1/13).
6.3.8.
Edit 22355 – Inpatient Service Line Error
Encounter Data
Processing System
Edit Code
22355
Edit Code Description
Inpatient Service Line Error
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
INST
Example scenario:
On 6/28/2015, Care Bear Health resubmitted an encounter to the EDS with bill type 21X and a billed amount
of $240.00 on the Revenue Code 0022 service line. The EDS previously rejected the encounter and returned an
MAO-002 Report containing error code 21979, “Charges for Rev Code 0022 Must Be Zero“ because the Revenue
Code service line billed amount and noncovered charge amounts must be either blank or equal to zero. The adjusted
encounter received error code 22355 at the header level because it contained a reject error on the service line.
Chapter 6
Page 12 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Prevention/resolution strategy: CMS is posting error code 22355 along with error description “Inpatient
Service Line Error” to the Institutional inpatient encounter (TOB 11X, 18X, 21X, and 41X) header when a
submitted encounter contains a reject error on any service line.
Anytime a reject error is posted because of an error on an inpatient encounter service line, edit 22355 will post
on the header as necessary to reject the encounter. The whole encounter is rejected if any line on the encounter is
rejected for any reason. The submitter should re-submit the whole encounter afer applying the corrections to the
reject service line(s).
6.3.9.
Edit 22405 – Occurrence Code 55 & Date of Death Required
Encounter Data
Processing System
Edit Code
Edit Code Description
22405
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R/I
INST
Occurrence Code 55 & DOD
Required
Prevention/resolution strategy: The EDPS implemented Error Code 22405, “Occurrence Code 55 and DOD
Required” to validate the presence of Occurrence Code 55 and date of death when a patient discharge status code of
20 (expired), 40 (expired at home), 41 (expired in a medical facility), or 42 (expired – place unknown) is populated
on an encounter.
Informational: Without an Occurrence Code 55 and a date of death from date of service 10/1/12–12/31/12.
Reject: Without an Occurrence Code 55 and a date of death from date of service 01/01/13 – current DOS
6.3.10.
Edit 30261 – Referring Physician NPI Required
Encounter Data
Processing System
Edit Code
30261
Edit Code Description
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
I
DME
Referring Physician NPI Required
Edit features: Edit 30261 is currently being posted on DME encounters for the following conditions:
•
The Referring Provider NPI is not submitted on the encounter.
•
The Referring Provider NPI submitted on the encounter does not have a valid Medicare Enrollment.
Update to edit logic:
•
CMS will now validate the Referring Provider NPI received on DME encounters against National Plan and
Provider Enumeration System (NPPES).
•
The informational edit will now post if the Referring provider NPI is not submitted or not present in NPPES for
the submitted date of service.
Chapter 6
Page 13 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
6.3.11.
Edit 98300 – Exact Inpatient Duplicate Encounter
Encounter Data
Processing System
Edit Code
98300
Edit Code Description
Exact Inpatient Duplicate Encounter
Disposition
of Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
INST
Example scenario
On 8/3/2015, A Fine MAO submitted an encounter for Mayank Deshpande’s stay at Mercy Hospital from
6/15/2015 through 6/23/2015. On 8/10/2015, A Fine MAO resubmitted the same encounter as an original to the
EDPS with altered procedure modifiers. The EDPS rejected the encounter submitted on 8/10/2015 because the
header level (Loop 2300) HICN, DOS, TOB, and Billing Provider NPI data values matched those of the previous
encounter submitted on 8/3/2015. If the provider wishes to adjust the line level (Loop 2400) elements, they must
submit a replacement encounter or void the original encounter, then resubmit.
Edit features: This edit looks for duplicate inpatient submissions by matching on four key fields: HICN, DOS
(from and through), Billing Provider NPI, and TOB.
•
Applicable to Type of Bills 11X, 18X, 21X and 41X
•
Bypassed for CRRs
Figure 6.1. MAO-001 Report with Edit 98300
Chapter 6
Page 14 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
CMS analysis: The EDRs that were rejected as duplicates included several service lines compared to just one
line found on the previously submitted and accepted EDR. The EDRs that were rejected were also missing data
elements that were submitted on the previously accepted EDR – for example, Contract Information (2300 CN1), Other
Diagnosis Codes (2300 HI), Attending Provider (2310A NM1). The EDRs that were rejected included additional data
elements that were not submitted with the previously accepted EDR – for example, Remittance Date (2330B DTP).
Submitters have requested that we add additional fields to the logic for this edit. CMS conducted extensive
analysis on this edit and found that when edit 98300 fired, the services reported on the more recently submitted
record were in fact identical to the services reported on the previously submitted and accepted record, based on the
four-key duplication logic. CMS understands that data elements other than the four considered for the 98300
duplicate check may differ. However, if CMS adds data elements to the logic, we will be accepting two records
representing the same encounter. This situation compromises data integrity and shifts the responsibility of
identifying the most accurate data from the submitter to CMS or even to other users of encounter data, who would
need to make assumptions about the submitters’ intent regarding which record of the service to use.
Prevention/resolution strategy: MAOs must submit adjustment or void encounters when altering Inpatient
encounters. The EDPS will reject TOBs 11X, 18X, 21X, or 41X that contain duplicate header level (Loop 2300)
data elements for HICN, DOS (from and through), TOB, and Billing Provider NPI of an accepted encounter.
MAOs may wait to submit an inpatient EDR until an inpatient hospital stay has been fully adjudicated in the
MAOs’ systems.
If an MAO has submitted an inpatient EDR and would like to make changes to any of the data elements on the
record, the MAO can do one of two things:
1.
Void the original EDR by submitting with a claim frequency code of 8 AND submitting a new record
2.
Submit a replacement EDR with a claim frequency code of 7.
There are two options a submitter can use to make changes to the diagnosis codes on a previously submitted
and accepted inpatient EDR, but not other aspects of the data related to the encounter:
1.
The MAO may follow the guidance above regarding changing data elements on the record.
2.
The MAO may use a CRR to add diagnoses to the EDR or use a chart review delete record that is linked to the
EDR to delete diagnoses from the EDR.
Because an EDR is by definition a report to CMS from the MAO and not a provider claim, the MAO should
use the appropriate value for the claim frequency code on the EDR, even if it differs from the claim frequency code
of the claim submitted to the MAO by the provider.
Chapter 6
Page 15 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
6.3.12.
Edit 98315 – Linked Chart Review Duplicate
Encounter Data
Processing System
Edit Code
98315
Edit Code Description
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Linked Chart Review Duplicate
Example scenario:
Sequoia Health Plan conducted an audit of Langhorne Hospital and discovered that an encounter previously
submitted to the EDS contained an unnecessary diagnosis code. On 4/01/2014, Sequoia Health Plan submitted a
linked chart review encounter to the EDS containing the associated ICN of the original encounter to identify the
unnecessary diagnosis code. On 5/01/2014, 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.
Edit features:
•
Header-level edit
•
Chart Review Replacement Records only
Table 6.1. Data Elements Compared for Duplicate
Professional & DME Encounters
Institutional Encounters
Health Insurance Claim Number or Medicare
Beneficiary Identifier
Health Insurance Claim Number or Medicare
Beneficiary Identifier
Dates of Service – Header
Dates of Service – Header
Diagnosis Codes
Diagnosis Codes
Referenced Internal Control Number
Referenced Internal Control Number
Not Applicable
Type of Bill
Chapter 6
Page 16 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 6.2. MAO-001 Report with Edit 98315
CMS analysis: All of the data elements on the EDR that was rejected as a duplicate and the previously accepted
EDR were identical except for Service Line noncovered charges (2400 SV207) and Line Check or Remittance Date
(2430 DTP).
Prevention/resolution strategy: Linked Chart Review encounters cannot be submitted where the HICN,
Associated ICN, header DOS, diagnosis code(s) and TOB (TOB applicable to Institutional only) contain the exact
same values as another chart review encounter already present within the EODS. Submitters should use a
replacement CRR to replace diagnosis codes only on previously accepted chart review records. If you need to
correct data elements other than diagnoses codes on a previously accepted CRR, void the previously accepted chart
review record and resubmit a new record with the corrections.
6.3.13.
Edit 98320 – Duplicate Chart Review
Encounter Data
Processing System
Edit Code
98320
Edit Code Description
Duplicate Chart Review
Disposition of
Edit
Scenario Applies to:
(Institutional, Professional,
DME, ALL)
R
ALL
Example scenario:
Ohio Health Plan conducted an audit of Cincinnati City Hospital and discovered that an encounter not
previously submitted to the EDS required an additional diagnosis code. On 3/15/2014, Ohio Health Plan submitted
Chapter 6
Page 17 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
an unlinked chart review encounter to the EDS to include the additional diagnosis code. On 6/01/2014, 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.
Edit features: Edit 98320 is posted when a duplicate chart review record (linked or unlinked with claim
frequency other than 7 or 8) is received on the Professional, Institutional or DME.
•
Header-level edit
•
Original chart review records only (Linked and Unlinked)
•
Applicable to Professional, DME, and Institutional
A CRR is identified as a duplicate if it has the same values as an existing, accepted chart review record for the
fields in Table 6.2. The edit logic for Edit 98320 was updated on September 29, 2017, to include the Reference ICN
in the matching criteria to identify duplicate CRRs. Please see the HPMS Technical Release Memo dated August 8,
2017.
Table 6.2. Edit 98320 Institutional Matching Criteria Effective September 29th, 2017
Current 98320 Logic
Updated 98320 Logic
Health Insurance Claim Number or Member Beneficiary
Identifier
Health Insurance Claim Number or Member
Beneficiary Identifier
Header Dates of Service
Header Dates of Service
Diagnosis code
Diagnosis code
Type of Bill
Type of Bill
Not Applicable
Reference Internal Control Number
Table 6.3. Edit 98320 Professional and DME Matching Criteria as of October 1, 2017
Current 98320 Logic
Updated 98320 Logic
Health Insurance Claim Number or Member Beneficiary
Identifier
Health Insurance Claim Number or Member
Beneficiary Identifier
Header Date of Service
Header Date of Service
Diagnosis code
Diagnosis code
Not Applicable
Reference Internal Control Number
Chapter 6
Page 18 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Figure 6.3. MAO-001 Report with Edit 98320
CMS analysis: In most cases for professional EDRs, the EDR that was rejected as a duplicate is an unlinked
CRR and the previously accepted EDR is a linked CRR with a parent ICN. For institutional EDRs, the rejected and
the previously accepted EDRs were both unlinked CRRs. Other than the linking ICN, all of the data elements on the
rejected EDR and the previously accepted EDR were identical except for Patient Control Number (2300 CLM01),
Other Payer Claim Check or Remittance Date (2330B DTP), and Claim Identifier for transmission intermediaries
(2300 REF02 with D9 Qualifier).
Prevention/resolution strategy: Submitters should use a CRR only to add and delete diagnosis codes, but not
to change other data elements. If a submitter needs to correct a data element other than a diagnosis code on a
previously accepted CRR, the submitter should void the previously accepted CRR and resubmit a new CRR with the
corrected data elements.
Chapter 6
Page 19 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
6.4.
Selected Line-Level Edit Codes – Detailed Information and Examples
6.4.1.
Edit 02256 – Beneficiary Not Part C Eligible for DOS
Encounter Data
Processing System
Edit Code
02256
Edit code Description
Beneficiary Not Part C Eligible
for DOS
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Example scenario:
On July 4, 2012, Gail Williams had severe chest pains and went to the emergency room for a chest X-ray at
Underwood Memorial Hospital. At the time of the emergency room visit, Ms. Williams did not have Part C
Medicare coverage because her Part C coverage was not effective until 8/1/2012. Underwood Memorial submitted
the claim to AmeriHealth. AmeriHealth submitted an encounter to CMS and received error code 02256 because Ms.
Williams is not covered under Part C Medicare for the DOS.
Edit features:
•
Header-level edit for Institutional records
•
Line level edit for Professional and DME records
•
Applicable to EDRs and CRRs
Notwithstanding the bypass logic (described below), this edit will result in a rejection when both the “from”
and “through” dates on a record are not within the enrollee’s active enrollment dates in Medicare Advantage.
CMS analysis: A 2017 CMS analysis demonstrated, for the sample reviewed, the enrollee did not have active
enrollment in Medicare Advantage for the DOS submitted on the record as shown in the following examples:
•
The enrollee has a date of death recorded in the EDPS reference table and is no longer enrolled in any MA
contract for the DOS submitted on the record. In these cases, the DOS submitted are after the enrollee has been
disenrolled from MA.
•
The enrollee did not have an active Medicare Advantage enrollment for the DOS submitted on the record.
-
In these instances, the enrollee was enrolled in a Part D-only contract for the DOS submitted.
In some instances, the enrollee was disenrolled from an MA contract prior to the DOS submitted on the
record.
•
The beneficiary was not enrolled in MA for the submitted DOS. In these instances, the DOS submitted on the
record is before the enrollee’s participation in MA.
Prevention/resolution strategy: Verify that beneficiary was enrolled in Part C for DOS listed on the
encounter. Encounters should not be submitted for beneficiaries not enrolled with the contract for the DOS on the
received claim. Encounters should only be submitted for DOS for which the beneficiary is actually enrolled with the
Chapter 6
Page 20 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
contract. Submitters should make sure that the begin and end dates of the service fall within the Part C eligibility
begin and end dates. Verify the enrollee’s enrollment and demographic information using the reports distributed
monthly through MARx. Populate the correct enrollment and demographic information accordingly on EDRs and
CRRs.
Bypass conditions:
Professional records: If the “from” date on a service line is the same as or before the enrollee’s disenrollment
date in the contract AND the “through” date is after the enrollee’s disenrollment date in the contract AND the Place
of Service value on the record is 21, 31, 32, 51, 55, 56, or 61.
Institutional encounters: If the “from” date on the header is the same or before the enrollee’s disenrollment date
in the contract AND the “through” date is after the enrollee’s disenrollment date in the contract AND the TOB value
on the record is 11X, 12X, 18X, 21X, 22X, 41X, OR 85X.
DME encounters: If the “from” date on the service line is the same or prior to the enrollee’s disenrollment date
in the contract AND the “through” date is after the enrollee’s disenrollment date in the contract.
6.4.2.
Edit 17310 – Rev Code 036X Requires Surg Proc Code
Encounter Data
Processing System
Edit Code
17310
Edit Code Description
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
INST
Rev Code 036X Requires Surg
Proc Code
Example scenario:
Life and Health Associates submitted an encounter for Galaxy Suburb Hospital for a prostate cryosurgery
performed on 5/15/2012. They reported the Revenue Code of 036X but did not include the surgical CPT code of
55873 (Cryosurgical ablation of the prostate).
Edit features:
•
Line-level edit
•
Applicable to EDRs and CRRs
•
Applicable to Institutional Records with TOB 11X, 18X, or 21X
•
Edit 17310 will be posted if the following conditions are satisfied:
-
Revenue Code (2400 SV201) 036X is present on any of the service lines of an EDR or a CRR
-
ICD-9 or ICD-10 Principal (2300 HI01-2, where 2300 HI01-1 is BR/BBR) or Other Procedure Code (2300
AND
HI01-2, where 2300 HI01-1 is BQ/BBQ) is not submitted on the EDR.
Chapter 6
Page 21 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
•
Note: This edit will be bypassed if
-
The EDR contains ICD-9 diagnosis code(s) (2300 HI01-2, where 2300 HI01-1 is BK or BJ or BF) V641,
V642, or V643
OR
-
The EDR contains ICD-10 diagnosis code(s) (2300 HI01-2, where 2300 HI01-1 is ABK or ABJ or ABF)
Z5301, Z5309, Z531, Z5320, Z5321, Z5329, Z538, Z539, Z9911, Z9981 or Z993.
CMS analysis: CMS conducted an analysis of this edit code activity in 2017 and confirmed it posts correctly.
Prevention/resolution strategy: Ensure Institutional Inpatient EDRs (TOB 11X, 18X, or 21X) containing
Revenue code 036X are submitted at a minimum with one Principal or other Procedure Code. If the Principal or
Other Procedure Code is not available, the EDR should contain at least one diagnosis code that is included in the
bypass logic.
Table 6.4. Submission of ICD-10 Procedure Codes on 837-I 5010 EDRs
Scenario
Code
Principal Procedure Code X12 format for EDRs with DOS prior to
ICD-10 implementation dates (10/01/2015)
HI*BR:3121:D8:20051119~
Other Procedure Code X12 format for EDRs with DOS prior to ICD10 implementation date (10/01/2015)
HI*BQ:3121:D8:20051119~
Principal Procedure Code X12 format for EDRs with DOS on or after
ICD-10 implementation date (10/01/2015)
HI*BBR:0B110F5:D8:20151001~
Other Procedure Code X12 format for EDRs with DOS on or after
ICD-10 implementation date (10/01/2015)
HI*BBQ:02139Y3:D8:20151001~
Figure 6.4. Example of a Valid Submission Common Edits and Enhancements Module (CEM)
Chapter 6
Page 22 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
6.4.3.
Edit 98325 – Service Line(s) Duplicated
Encounter Data
Processing System
Edit Code
98325
Edit Code Description
Disposition of
Edit
Scenario Applies To:
(Institutional, Professional,
DME, ALL)
R
ALL
Service Line(s) Duplicated
Example scenario:
Sanford Health Systems submitted an encounter on 6/15/2015 for a claim received from Dr. Skye for an office
visit. Dr. Skye resubmitted the claim to correct the office point of contact. Sanford Health submitted a replacement
encounter to CMS and received error code 98325 because none of the data elements validated by the EDPS
duplicate logic were changed from the previously submitted encounter. To correct the office point of contact only,
Sanford Health Systems would need to void the previously submitted encounter and submit a new original encounter
or submit a replacement encounter data record against the original encounter data record to correct the inaccurate or
missing data elements.
Edit features: Edit 98325 is a line-level edit that identifies service lines that are duplicates of an existing
accepted encounter service line in history (previously submitted) or another service line within the same EDR. The
edit is not applicable for CRRs, Void EDRs, or adjustment EDRs against the previously submitted and accepted
EDRs.
For institutional outpatient encounters, the dates of service at the service line level are optional if header
from and through dates are the same. Therefore, EDPS uses the header-level statement “from” and “through” dates
for validation if the line-level DOS are missing. If the line-level DOS are submitted, the EDPS uses line-level DOS
for validation.
Table 6.5. Institutional Outpatient Fields Used for Duplicate Checking
Institutional – Outpatient
Health Insurance Claim Number or Medicare Beneficiary ID
Dates of Service
Procedure Code and up to 4 modifiers
Paid Amount (2320 AMT02/2430 SVD02)
Billed Amount
Type of Bill
Billing Provider NPI
Revenue Code
Chapter 6
Page 23 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
For professional/DME encounters: Use the service-line Rendering Provider NPI. If the Rendering Provider
NPI is not submitted on the service line, use the header-level Rendering Provider NPI. If the header-level Rendering
Provider NPI is not submitted, use the header-level Billing Provider NPI.
Table 6.6. Professional/DME Fields used for Duplicate Checking
Professional/DME
Health Insurance Claim Number or Medicare Beneficiary ID
Dates of Service
Procedure Code and up to 4 modifiers
Paid Amount (2320 AMT02/2430 SVD02)
Billed Amount
Place of Service
Rendering Provider NPI
Prevention/resolution strategy: When the original encounter data record is in “Accepted” status with all
accepted service lines and the MAO needs to correct a data element that is not part of duplicate check:
•
Void the Original encounter data record and resubmit a new encounter data record with the corrections
OR
•
Submit a “replacement” (Claim Frequency Code of 7) EDR against the original EDR to correct the inaccurate
or missing data elements.
When the original encounter data record is in “Accepted” status with accepted and rejected service lines and
the MAO needs to correct rejected lines only:
•
Void the Original EDR and resubmit a new EDR with both the previously accepted service lines, and with
corrections to the previously rejected service lines
OR
•
Submit an “Original” (Claim Frequency Code other than 7 or 8) EDR with the corrections and include only the
service lines that were previously rejected.
For repeated Procedure/Service, or a Distinct Procedural Service, include appropriate modifiers.
When an MAO-001 Report is returned with encounter service lines rejected with edit 98325:
•
Do make corrections to your rejected lines and resubmit them (see the two allowed approaches above).
•
Do not resubmit a new encounter file until the MAO Reports for previously submitted files have been received
and reconciled by your system.
•
Do incorporate duplicate line checks within your internal processing systems prior to submission.
Bypass conditions: The duplicate check is bypassed for encounters submitted with the following modifiers:
Chapter 6
Page 24 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
Table 6.7 Modifiers that will Trigger Edit 98325 Bypass
Institutional – Outpatient
Professional
59 - Distinct Procedural Service
59 - Distinct Procedural Service
62 - Two Surgeons
(Not applicable)
66 - Surgical Team
(Not applicable)
76 - Repeat Procedure by Same Physician
76 - Repeat Procedure by Same Physician
77 - Repeat Procedure by Another Physician
77 - Repeat Procedure by Another Physician
91 - Repeat Clinical Diagnostic Laboratory Test
91 - Repeat Clinical Diagnostic Laboratory Test
Edit 98325 is also bypassed for specific modifiers and specific Ambulatory Surgery Centers (ASC) procedures
EDPS bypasses posting edit 98325 on the Professional ASC encounter service line when the following conditions
exist:
•
The billing provider’s NPI submitted on the current encounter corresponds to the provider specialty ‘49’ in the
PECOS table in EDPS
•
The place of service (POS) ‘24’ is present on the current encounter
•
The procedure code submitted on the current encounter service line is present in the ASC Fee Schedule in
EDPS
•
The procedure code on the current encounter corresponds to a Multiple Procedure Discount Indicator ‘1’ in the
ASC Fee Schedule.
EDPS bypasses posting edit 98325on the ASC encounter service line for institutional and outpatient encounters
when the following conditions exist:
•
Type of bill (TOB) 83X is present on the current encounter
•
The procedure code submitted on the current encounter service line is present in the ASC Fee Schedule in
EDPS
•
The procedure code on the current encounter corresponds to a Multiple Procedure Discount Indicator ‘1’ in the
ASC Fee Schedule.
6.5.
Informational Edit Codes and Resolutions: Edit 00845 and Edit 00850
CMS created two new informational edits, effective September 29, 2017, to identify non-CRRs that replace or
void a CRR. This violates CMS operational policy, whereby only CRRs can replace CRRs, and only EDRs can
replace EDRs. See Chapter 2, Section 2.3. CMS is implementing these edits because we cannot determine the
submitter’s intent in these situations.
Notes:
1.
The new informational edits will be posted only when the previously submitted chart review record is in
accepted status.
Chapter 6
Page 25 of 26
ENCOUNTER DATA SUBMISSION AND PROCESSING GUIDE
VERSION 4.0
OCTOBER 2020
2.
If the data elements on the previously submitted chart review record do not match the data received on the
replacement or void EDR, the record will be rejected with edit 00699 or 00780.
Table 6.8. Informational Edits for CRRs, Effective September 29, 2017
Edit Code
Disposition
Description
Applies To
00845
Informational
Adjustment Must Be a Chart Review Record
ALL
00850
Informational
Void Must be a Chart Review Record
ALL
Chapter 6
Page 26 of 26
| File Type | application/pdf |
| File Title | Encounter Data Submission and Processing Guide: Medicare Advantage Program |
| Subject | ED, RAPS, CRR, EDR, Encounter Data Record, Chart Review Record, EDFES, EDP |
| Author | CMS |
| File Modified | 2020-10-09 |
| File Created | 2020-10-08 |