Department of Health and Human Services 
 
 
OFFICE OF 
 
INSPECTOR GENERAL 
 
 
 
 
  M A
EDICARE  DVANTAGE 
 
 
E D  
NCOUNTER  ATA
 
 
S P
  HOW  ROMISE FOR 
 
 
P O ,  
ROGRAM  VERSIGHT  
B I A
UT  MPROVEMENTS  RE 
N  
EEDED
 
Suzanne Murrin 
Deputy Inspector General for 
Evaluations and Inspections 
 
January 2018 
OEI-03-15-00060   
   
Report in Brief 
January 201 8 
OEI-03-15-0 0060 
 
 
Medicare Advantage Encounter Data Show Promise for 
Why OIG Did This Review  
Program Oversight, But Improvements Are Needed 
For the Medicare Advantage (MA) 
program, the Centers for 
What OIG Found 
Medicare & Medicaid Services 
Overall, 28 percent of MA encounter records that we reviewed from the first quarter of 
(CMS) contracts with private 
2014 had at least 1 potential error, but CMS reported correcting the majority of these 
insurance companies, known as 
records.  According to CMS, most of these potential errors were created when CMS 
MA organizations (MAOs), to 
removed provider identifiers from records in its edit process.  With CMSs subsequent 
provide Medicare coverage for 
correction, only 5 percent of the records in our review would contain a potential error.  
18.6 million beneficiaries.  In fiscal 
Types of potential errors included inactive or invalid identifiers for billing providers; 
year 2016, MA expenses reached 
duplicated service lines; missing required data; inconsistent dates; and beneficiary 
$200 billion.  
information that did not match CMSs records.  Just 1 percent of MAOs submitted 
In 2012, CMS began collecting 
51 percent of the records with potential error(s).  Some of these errors may raise 
detailed information from MAOs 
concerns about the legitimacy of services documented in the data, such as records that 
regarding each service provided to 
lacked a beneficiary last name or a valid identifier for the billing provider.     
MA beneficiaries.  This       
information is known as MA 
Exhibit 1.  Percentage 
encounter data.  These data must  of MA Encounter  28% Potential Errors 
Identified 
be accurate for CMS to review the  Records With Potential 
5% 
medical care that beneficiaries are  Errors  Potential Errors After 
CMSs Subsequent 
receiving and use the data to  MA Encounter Data              Correction 
increase payments to MAOs for  January to March 2014 
beneficiaries in poorer health.  
 
Although MAOs must submit identifiers for billing providers, CMS does not require 
Ensuring the completeness, 
MAOs to submit identifiers for ordering or referring providers and requires identifiers 
validity, and timeliness of the MA 
for rendering providers only under certain circumstances.  Identifiers for ordering and 
encounter data is also critical to 
referring providersand in some cases, for rendering providerswere frequently 
safeguard program integrity and 
absent from encounter data, which limits the use of these data for vital program 
to ensure that MA beneficiaries 
oversight and enforcement activities.     
receive needed medical care.   
CMSs key control to ensure data integrity has been its edit process, which rejects data 
How OIG Did This Review 
that do not pass certain checks.  However, CMS has not tracked whether MAOs respond 
We analyzed 102 million MA 
when this process rejects data.  CMS has plans to implement additional compliance 
encounter records from the first 
activities to ensure data integrity, but it has not established performance measures that 
quarter of 2014 to determine the 
monitor MAOs submission of records with complete and valid data. 
extent to which data contained in 
CMSs Integrated Data Repository  What OIG Recommends  
were complete, valid, and timely.   We recommend that CMS take actions as appropriate to address potential errors in the 
In addition, to review the actions  MA encounter data; provide targeted oversight of MAOs that submitted a higher 
that CMS has taken to address  percentage of records with potential errors; ensure that billing provider identifiers are 
errors in MA encounter data, we  active and valid on all records; require MAOs to submit ordering and referring provider 
analyzed CMSs responses to  identifiers and ensure the submission of rendering provider identifiers for applicable 
a structured questionnaire and  records; track how MAOs respond to edits that reject data; and establish and monitor 
relevant policy and procedural  performance thresholds related to MAOs submission of records with complete and 
documentation.  valid data.  CMS concurred with four of our seven recommendations. 
Full report can be found at http://oig.hhs.gov/oei/reports/oei-03-15-00060.asp 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    1   
   
TABLE OF CONTENTS 
 
Objectives ....................................................................................................1 
Background ..................................................................................................1 
Methodology ................................................................................................6 
Findings........................................................................................................8 
Twenty-eight percent of MA encounter records contained  
potential errors in required data, but CMS reported correcting the 
majority of these records ..................................................................8 
Only a few MAOs submitted half of the encounter records that    
had a potential error ....................................................................... 11  
CMS does not require MAOs to submit certain provider  
identifiers used in program integrity reviews, and these were 
frequently absent from encounter data ...........................................12 
For the MA encounter data in our review, MAOs had submitted 
almost all records within CMSs specified timeframe ...................13 
CMS has addressed errors by notifying MAOs of edit results and 
rejecting some data, but it has not monitored MAOs responses to 
these actions ...................................................................................14 
Conclusion and Recommendations ............................................................16 
Agency Comments and Office of Inspector General Response .....19 
Appendices .................................................................................................22 
A: Methodology To Identify Potential Errors Related to the 
Completeness and Validity of Required Data Elements ................22 
B: Methodology To Identify Potential Duplication of Services ....27 
C: Methodology To Evaluate Identifiers for Ordering/Referring  
and Rendering Providers and Timeliness of Data Submission ......28 
D: Number of Encounter Records Affected by Each Potential  
Error, by Claim Type ......................................................................30 
E: Agency Comments ....................................................................33 
Acknowledgments......................................................................................37
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    1     
   
OBJECTIVES 
1.  To assess the extent to which the Centers for Medicare & Medicaid Services 
(CMSs) Integrated Data Repository (IDR) contains complete, valid, and timely 
Medicare Advantage (MA) encounter data. 
2.  To review the actions that CMS has taken to address errors in the MA 
encounter data.  
BACKGROUND  
In 2012, CMS began collecting detailed information from MA organizations 
(MAOs) regarding all services provided to MA beneficiaries.  This information is 
known as MA encounter data.  Before this effort, CMSs lack of comprehensive 
MA encounter data limited its ability to assess payment accuracy, safeguard 
program integrity, and monitor quality of care in the MA program.  Furthermore, 
CMS and Office of Inspector General (OIG) audits found vulnerabilities in the 
abbreviated data that CMS collected from MAOs before it began collecting 
MA encounter data.  Ensuring the completeness, validity, and timeliness of 
MA encounter data is critical for calculating accurate MA payments, improving 
Medicare program integrity, and using these data to improve the quality of care 
that beneficiaries receive. 
The Medicare Advantage Program 
Under Medicare Part C, CMS contracts with private insurance companies, known 
as MAOs, to provide services covered by Medicare Parts A and B under 
managed-care arrangements.1, 2  In fiscal year 2016, almost a third of Medicare 
beneficiaries18.6 millionelected to enroll in the MA program rather than the 
Medicare fee-for-service program.  In that fiscal year, the MA programs expenses 
were $200 billion of the total $641 billion in Medicare program/activity costs.3   
Using Encounter Data for Payments 
CMS relies on data that MAOs submit to determine MA payment amounts.   
CMS makes advanced monthly payments to MAOs for each beneficiary 
enrolled.4  CMS risk-adjusts these payments so that amounts are higher for 
 
1 Medicare Parts A and B include hospital care; skilled nursing facility care; hospice care; home 
health care; physician services; and durable medical equipment, prosthetics, orthotics, and supplies 
(DMEPOS).  Many MAOs also offer prescription drug coverage under Medicare Part D. 
2 For the purpose of this report, we use the term MAOs to refer to all managed-care 
organizations, coordinated care plans, private fee-for-service plans, Medicare medical savings 
account plans, cost plans, demonstration plans, and PACE organizations (programs of all-inclusive 
care of the elderly) that are required to report MA encounter data to CMS.  There were 716 MAOs 
that submitted MA encounter data for the first quarter of 2014.   
3 CMS, CMS Financial Report Fiscal Year 2016, November 2016, p. 45.  
4 This is different from the Medicare fee-for-service program, which reimburses providers that 
submit claims for services provided. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    1   
   
beneficiaries who are expected to use more costly services.  CMS bases risk 
adjustments on MA beneficiaries demographic information and diagnoses from 
the previous year.  To determine beneficiaries diagnoses, CMS uses data 
submitted by MAOs.  To estimate the expected health care costs associated with 
these diagnoses, CMS currently uses Medicare fee-for-service data.      
Situation prior to collection of the MA encounter data.  Since 2002, CMS has 
used the Risk Adjustment Processing System (RAPS) to collect from MAOs the 
data needed to determine beneficiaries diagnoses for risk adjustment.  However, 
the RAPS data include only select information (i.e., data elements) for services 
provided by a limited set of provider types.5  In addition to these limitations, 
several OIG audits have found that for a substantial portion of randomly sampled 
beneficiaries, the MAO-submitted diagnoses in the RAPS data were not 
supported by medical records.6  Similarly, CMS found that 10 percent, or 
$16 billion, of risk-adjusted payments made in 2014 were based on RAPS data 
that were not supported by medical records.7   
The MA encounter data.  In 2012, CMS began collecting from MAOs the more 
detailed, comprehensive MA encounter data.  When calculating risk-adjustment 
payments for payment year 2015, CMS began using MA encounter data with 
2014 dates of service as an additional data source to determine beneficiaries 
diagnoses.  Eventually, CMS plans to use the MA encounter data rather than the 
RAPS data to calculate payments.  CMS also plans to eventually use the MA 
encounter datarather than fee-for-service datato estimate the expected health 
care costs associated with MA beneficiaries diagnoses. 
Using Encounter Data To Safeguard Program Integrity and Review 
Quality of Care  
Before CMS collected MA encounter data, the lack of comprehensive MA data 
hindered efforts to safeguard program integrity and conduct broad reviews of the 
quality of care provided to MA beneficiaries.  For example, a 2013 OIG report 
found that the Medicare Drug Integrity Contractor (MEDIC)which is 
responsible for identifying and investigating MA fraud and abusereported that 
it was unable to conduct proactive data analyses because of the lack of a 
 
5 CMS requires MAOs to submit RAPS data.  The data elements submitted are beneficiary health 
insurance claim number (HICN), diagnosis/diagnoses, provider type, and date(s) of service for 
services provided by hospital inpatient facilities, hospital outpatient facilities, and physicians. 
6 OIG, Risk Adjustment Data Validation of Payments Made to PacifiCare of Texas for Calendar 
Year 2007 (Contract Number H4590), A-06-09-00012, May 2012; OIG, Risk Adjustment Data 
Validation of Payments Made to Excellus Health Plan, Inc., for Calendar Year 2007 (Contract 
Number H3351), A-02-09-01014, October 2012; OIG, Cigna Healthcare of Arizona, Inc. 
(Contract H0354), Submitted Many Diagnoses to the Centers for Medicare & Medicaid Services 
That Did Not Comply with Federal Requirements for Calendar Year 2007, A-07-10-01082, 
May 2013.   
7 Department of Health and Human Services, Agency Financial Report Fiscal Year 2016, 
November 2016, p. 213.   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    2   
   
centralized data repository containing records of all services provided to MA 
beneficiaries.8   
CMS now has centralized, encounter-level data to enable it to conduct reviews of 
program integrity and quality of care.  For example, to ensure proper payments, 
CMS has begun using the MA encounter data to identify Medicare  
fee-for-service claims that were also submitted as MA encounters.9  In addition, 
CMS has used the MA encounter data to assist with Federal disaster relief efforts 
by identifying MA beneficiaries who require respiratory services.  CMS also has 
plans to use the MA encounter data to develop quality metrics to measure how 
MA plans coordinate care. 
Submission Process for MA Encounter Data 
The process of reporting MA encounter data generally begins when a beneficiary 
receives a clinical service.10  The provider submits a claim to the MAO.  The 
MAO adjudicates the claim and submits it as an encounter record to CMS.  As 
shown in Exhibit 2, MAOs submit data to the Encounter Data Front-End System 
(EDFES).  The EDFES performs a series of automated checks, or edits, and 
transmits the data that pass these edits to the Encounter Data Processing System 
(EDPS).  The EDPS processes data by three types of claims:   
  durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) 
(e.g., wheelchairs and ventilators);  
  professional (e.g., physicians services); and  
  institutional (e.g., inpatient hospital stays and skilled nursing facility care).   
 
E xhibit 2.  MA Encounter Data Submission and Storage 
 
 
MAO   CMSs  CMSs 
      EDFES  EDPS  CMSs IDR 
    Submits  Perfo rms  Perfo rms   
    Stores 
PROVIDER   data  edits  edits and 
data 
Provides services and  formats  
  data 
submits data    
   
 
The EDPS performs additional edits, formats the data into the Integrated Data 
Repository (IDR) format, and sends the dataincluding data that do and do not 
 
8 OIG, MEDIC Benefit Integrity Activities in Medicare Parts C and D, OEI-03-11-00310,  
January 2013. 
9 Government Accountability Office (GAO), Medicare Advantage: Limited Progress Made to 
Validate Encounter Data Used to Ensure Proper Payments, GAO-17-223, January 2017, p. 18. 
10 CMS also allows MAOs to submit chart review records that delete or add diagnoses to the MA 
encounter data as a result of medical record reviews conducted by the MAO. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    3   
   
pass EDPS editsto the IDR.11  Once stored within the IDR, CMS accesses the 
data to calculate risk adjustments and conduct other data analyses. 
If an MAO determines that a previously submitted encounter record that passed 
CMSs edit process is incorrect, it may submit a replacement record that replaces 
the previously accepted encounter, or void the record.  If the MAO submits 
a replacement record, it must identify the original control numberi.e., the 
control number of the record being correctedon the replacement record.  If the 
MAO voids the record, it must identify the original control number on the voided 
record. 
Submission deadline.  From 2012 to June 2015, CMS provided timely filing 
guidance to MAOs through presentations, memos, and other documents 
instructing MAOs to submit encounter data within 13 months of the date of 
service.  However, CMS no longer provides the 13-month guidance to MAOs.   
Instead, CMS refers to the final risk adjustment data submission deadline as 
the date that MAOs must submit encounter data.  This deadline is announced 
each year by CMS, but is no earlier than January 31 of the year following the 
payment year.  Depending on when a service was provided during the year, the 
deadline is between 13 and 25 months later.12   
Required data elements.  For the MA encounter data, CMS does not require 
MAOs to submit every data element contained on a Medicare fee-for-service 
claim.  Instead, for each service provided to a beneficiary, CMS has designated a 
minimum set of required data elements, some of which are required across all 
services and some of which are situationally dependent.13  CMS based its 
selection of required data elements on research and comments from MAOs and 
other entities, considering administrative burdens both on MAOs and on CMS.  
These required data elements include information about beneficiaries, providers, 
MAOs, diagnoses, procedures, payment information, and dates of service.  
According to CMS, the Encounter Data Minimum Data Elements populate  
78 IDR data elements.   
Certification of data integrity.  CMS requires MAOs to certifybased on their 
best knowledge, information, and beliefthe accuracy, completeness, and 
truthfulness of their MA encounter data.14   
 
11 The EDPS also prices each encounter to ascertain the amount that CMS would have paid for 
the encounter had it been a Medicare fee-for-service claim.  CMS needs to price encounters to 
eventually use these data to establish a risk-adjustment model that estimates the expected health 
care costs associated with MA beneficiaries diagnoses.   
12 42 CFR  422.310(g)(2)(ii). 
13 CMS, Encounter Data Minimum Data Elements, March 2012; CMS, Encounter Data 
Minimum Data Elements, August 2014. 
14 42 CFR  422.504(l). 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    4   
   
CMSs Identification of Errors in MA Encounter Data 
To identify data errors, CMS performs edits during the submission process and 
analyzes the data contained in the IDR.15   
Reject edits.  CMS rejects encounter data that do not pass reject edits 
performed by the EDFES and EDPS.  CMS instructs MAOs to respond to edits 
that reject data by submitting new records with correct information.  CMS 
designates an edit as a reject edit if it identifies an error in a data element that 
CMS deems key to MA program payment.  For example, one such edit checks 
whether a newly submitted encounter record for a service matches specific data 
values on a previously accepted record.   
Informational edits.  When MAOs records do not pass informational edits 
performed by the EDPS, CMS notifies MAOs, but does not reject the records.  
CMS designates an edit as an informational edit if it identifies an error that does 
not align with best practices for submitting encounter data.  For example, 
one informational edit verifies that a beneficiarys sex is appropriate for the 
procedure code.  According to CMS, informational edits indicate to MAOs that 
they should review these errors for future submissions of encounter data.  
Informational suppressed edits.  The EDPS also performs what CMS calls 
informational suppressed edits.  These do not reject records, nor do they result 
in MAOs being notified.  For example, one informational suppressed edit 
verifies that the discharge time contains a valid hour number and a valid minute 
number.  CMS uses these edits for internal operational analytics. 
IDR validation edits.  When the EDPS sends MA encounter data to the IDR, 
CMS validates that the IDR received the data correctly.  Part of this process 
includes edits to check whether certain data elements are present and formatted 
correctly and whether records are inappropriately duplicated.  For example, 
one IDR validation edit verifies that a beneficiarys health insurance claim 
number (HICN) is present.  CMS does not load data that fail these edits into the 
IDR until it can resolve the identified errors. 
Analyses of MA encounter data integrity.  CMS reported that since the MA 
encounter data were first loaded into the IDR in 2014, it has conducted analyses 
to review and validate the data.  CMS also performs analyses that compare each 
MAOs volume of submitted records to regional and national averages across 
MAOs and across Medicare fee-for-service claims, which CMS may use to 
identify whether MAOs have submitted all required encounter records. 
 
15 As the MA encounter data become further integrated into the payment process, CMS also plans 
to subject diagnoses from the MA encounter data to medical record review. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    5   
   
METHODOLOGY 
Data Collection and Analysis 
MA encounter data.  We extracted MA encounter data from the IDR in  
August 2015 for all accepted, final action records of encounters from the first 
quarter of 2014 (January through March).  In total, we reviewed 102 million 
encounter records submitted by 716 MAOs for 13 million beneficiaries.16 
To identify potential errors, we assessed the completeness and validity of  
56 required data elements and determined whether encounter records contained 
potentially duplicated services.17  Appendix A contains a detailed description of 
the methods we used to identify potential errors related to the completeness and 
validity of required data elements.  Appendix B contains a detailed description of 
the methods we used to identify potential duplication of services.   
In general, our methods to identify potential errors related to the completeness 
and validity of required data elements included:  
  identifying missing values,  
  checking that a data elements range of values was within format 
specifications,  
  comparing values across related data elements to ensure consistency, and 
  comparing values against outside sources, such as the National Plan and 
Provider Enumeration System (NPPES) registry of national provider 
identifiers (NPIs).   
After identifying potential errors, we counted the number of instances of 
potential errors and summarized the number and percentage of encounter records 
that contained at least one potential error.  We also checked for variation across 
MAOs in the number and percentage of potential errors. 
In addition, we determined the extent to which certain encounter records 
contained NPIs for ordering/referring and rendering providers.18  The NPI for the 
ordering/referring provider is not a required data element, but MAOs may opt to 
include it.  CMS stated that it requires MAOs to submit the NPI for the rendering 
provider when it is different from that of the billing provider.  Therefore, when 
MAOs do not submit a rendering provider NPI, CMS considers the rendering 
 
16 The encounter records included in this review had (1) an accepted status in the code that 
indicates whether the header portion of the record was accepted or rejected in the EDPS, (2) an 
accepted status in the code that indicates the most recent status of the line portion of the record for 
at least one service line, and (3) an end date of service in the header portion of the record that was 
between January 1, 2014, and March 31, 2014.  We did not include chart review records (see 
footnote 10) in this review.   
17 These 56 required data elements are among the IDR data elements that CMS identified as being 
populated by Encounter Data Minimum Data Elements.   
18 Appendix C contains definitions of ordering/referring and rendering providers. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    6   
   
provider NPI to be the same as the billing provider NPI.  We also reviewed the 
timeliness of encounter data submissionsi.e., whether the data were submitted 
within 13 months of the date of service, which was the guidance for the time 
period under review.  Appendix C contains a detailed description of the methods 
we used in these analyses.   
CMS processes and procedures.  From CMS, we obtained and summarized 
responses to a structured questionnaire and reviewed documentation related to 
the instructions, procedures, and/or processes that CMS has in place to: 
  ensure that MA encounter data are complete and valid, and that they are 
submitted timely; 
  notify MAOs of data errors identified; and 
  take actions to ensure that MAOs address data errors identified. 
Limitations 
We did not determine whether the contents of required data elements were 
supported by documentation in medical records, nor did we determine whether 
each MAO had submitted all required encounter records.  In addition, our 
assessment of the timeliness of submissions for the first quarter of 2014 does not 
include records that had not been submitted by MAOs as of August 2015 (when 
we extracted data from the IDR).         
Standards 
This study was conducted in accordance with the Quality Standards for 
Inspection and Evaluation issued by the Council of the Inspectors General on 
Integrity and Efficiency.   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    7   
   
FINDINGS 
Twenty-eight percent of MA encounter records contained 
potential errors in required data, but CMS reported 
correcting the majority of these records  
Of the 102 million MA encounter records that we reviewed from the first quarter 
of 2014, 28 million records, or 28 percent, had at least 1 potential error related to 
the completeness or validity of a required data element, or a potential duplication 
of services.  According to CMS, 
an issue was created when CMS 
Exhibit 3.  Number of Potential Errors on Records 
removed identifiers from records  in the MA Encounter Data, By Error Type 
in its edit process.  With CMSs  Type of Error Category  Number of 
Errors1 
subsequent correction, only  
Missing valuesbilling provider identifiers  47,767,664 
5 percent of the records in our 
Duplicated services  2,388,875 
review would contain a potential 
Incorrect original control numbers  2,078,535  
error.19  The number of potential 
Inappropriate codes  309,307  
errors per record ranged from  
Missing valuesother data  252,347 
1 to 11, with most of the 
Inconsistent date values  161,951 
problematic records having 
Inactive/invalid billing provider identifiers  96,970 
2 errors.  As shown in Exhibit 3, 
the most prevalent type of error  Beneficiary data did not match CMS records  31,434 
was having missing identifiers  Total potential errors identified  53,087,083  
for billing providers.   Source: OIG analysis of MA encounter data for  
JanuaryMarch 2014 from CMSs IDR. 
Appendix D outlines each  1 If a record had more than one potential error, each error is 
included in these counts. 
potential error and provides the 
number of affected records by claim type.        
Missing values were the most prevalent type of potential error, but 
CMS reported resolving an edit problem that may have caused 
a substantial majority of the missing values identified   
Prior to CMSs data corrections, there were 48 million instances of potential errors 
in which required data elements were missing data.  Most of these were missing 
NPIs and names for billing providers.20  For all records, CMS has reject edits that 
check that the billing provider NPI is correctly formatted and not associated with a 
provider under sanction.  However, CMS identified an issue with the reference 
data used in its edit process.  When OIG asked CMS about missing NPIs for billing 
providers, CMS explained that it had removed MAO-submitted NPIs from records 
when the reference data used in the edit process could not validate the submitted 
NPI.  After our review, CMS resolved this issue by (1) updating the reference data 
 
19 Unless otherwise specified, the information provided in this report is based on our analysis of 
the encounter data before CMS made its corrections. 
20 All records that were missing a billing provider NPI were also missing a billing provider name. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    8   
   
that it used in its edit process, (2) leaving MAO-submitted NPIs untouched, and 
(3) repopulating the NPIs and provider names on records from which they had 
been erroneously removed for 2014 MA encounter data. 
Our review also identified missing values in required data elements for the 
beneficiary last name, admission date, discharge status code, place of service 
code, and procedure code.  Of these, the data elements most often missing 
values were the beneficiary last namemissing on 218,758 recordsand the 
admission datemissing on 31,846 records.21   
Thousands of encounter records had inactive or invalid NPIs for 
billing providers  
Of the 78 million encounter records that had a billing provider NPI, NPIs were 
inactive or invalid for 96,970 recordsless than 1 percent.  Although this is a 
very small percentage, the billing providers NPI is a key data element for 
ensuring the legitimacy of medical services documented in encounter data.  The 
MA encounter data are vulnerable to this type of potential error because CMS 
does not perform a reject edit on the data to ensure that billing provider NPIs are 
active and valid in the NPPES registry.   
As shown in Exhibit 4, there were 87,225 records with an inactive billing 
provider NPI, 1,139 of which had an NPI deactivated more than 2 years prior.  
Among the 9,745 records with an invalid billing provider NPI, 9,115 had 
a default value that was not allowable for the claim type.22  Another 630 records 
of these 9,745 had an invalid NPI value that did not match any NPI in the 
NPPES registry and was not an allowable default value for any claim type.  For 
example, the value 1234567893 appeared as a billing provider NPI.   
 
Exhibit 4.  Encounter Records with Inactive or Invalid Billing Provider Identifiers 
87,225
records had an 
9,115
96,970 inactive NPI records had a default value 
records had an  that was not allowable for 
inactive or invalid  the claim type
billing provider NPI 9,745
records had an 
invalidNPI
630
records had an 
invalid, nondefault value
Source:  OIG analysis of MA encounter data for JanuaryMarch 2014 from CMSs IDR. 
 
21 The admission date was missing on 31,846 institutional records. (An admission date is not 
applicable to DMEPOS records or professional records.)  See page 3 for more information about 
the three claim types. 
22 CMS allows MAOs to submit default NPI values for individuals or businesses that bill for 
services provided but do not meet the definition of a health care provider, such as providers of 
nonemergency transportation and providers of personal care services.  For example, CMS 
designates the values 1999999992 and 1999999984 as allowable default values for the 
provider NPIs in DMEPOS records and professional records, respectively.  However, these values 
incorrectly appeared on 8,573 institutional records.   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    9   
   
 
Other potential data errors included inconsistent date values, 
inappropriate codes, duplicated services, incorrect original control 
numbers, and beneficiary data that did not match CMSs records 
Inconsistent date values.  There were 161,951 instances in which required data 
elements contained inconsistent date values.  Examples of date inconsistencies 
include:  
  dates of admissions that were after the date of service or before the 
beneficiarys date of birth;    
  related-cause dates (i.e., the date of an associated cause of an illness, 
injury, or accident as reported on the claim) that were before the 
beneficiarys date of birth, such as in the years 1900 or 1901, or after the 
date of service; 
  claim bill dates (i.e., the date when the bill was created for the claim) that 
were before the date of service; and 
  procedure dates that were not within the records begin and end dates of 
service.  
In addition, 8 of the 20 required data elements for dates contained the values 
12/31/9999 or 12/31/8888.  It is possible that these values are being used by 
MAOs or CMS data programmers as defaults that signify a lack of data.  
However, CMS has not defined 12/31/9999 or 12/31/8888 as default values 
for these data elements in its written instructions to MAOs and users of 
MA encounter data.23     
Duplicated services.  Of the 59 million encounter records included in our review 
of duplication, 2.4 million, or 4 percent, contained a service line that appeared to 
be duplicated.  Since the time of our review of the encounter data, CMS has 
introduced a new edit to reject duplicates for certain inpatient records and 
recommends that users of MA encounter data apply similar criteria to remove 
duplicates for inpatient records submitted prior to October 1, 2015.24  Of the 
2.4 million records that we identified as containing a potentially duplicated 
service, 50,180 were inpatient records that would be captured by this new edit.   
Inappropriate codes.  There were 309,307 instances in which required data 
elements contained inappropriate codes.  Most of these were discharge status 
codes that did not conform to format specifications.  Other examples of 
inappropriate codes include, but are not limited to, procedure codes and revenue 
 
23 Appendix A contains a description of when we did and did not count these dates as potential 
errors in our review. 
24 CMS, Encounter Data Considerations, Version 2, March 2016, p. 7.  
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    10   
   
codes that were no longer valid.  These codes had been deletedone as early as 
2004from lists of valid codes.     
Incorrect original control numbers.  Each new record that passes EDFES edits 
receives a control number.  When an MAO identifies an error in a record that 
CMS has already accepted and the MAO submits a replacement record, CMS 
requires the MAO to include the original control numberi.e., the control 
number of the prior recordon the resubmission.  This original control number 
should appear only on records resubmitted by MAOs.  We identified 2 million 
records submitted for the first time that incorrectly contained original control 
numbers.  Since our review of the encounter data, CMS has introduced new edits 
that reject records that are submitted for the first time with an original control 
number.   
Mismatched beneficiary data.  There were 23,858 instances in which the 
beneficiarys birthdate did not match CMSs records in the Medicare Enrollment 
Database (EDB) for that beneficiary, and 7,576 instances in which the code for 
the beneficiarys sex did not match.  Since our review of the encounter data, 
CMS reported that it has updated the reference data used in its edit process to 
validate beneficiary birthdates and sex codes. 
Only a few MAOs submitted half of the encounter records 
that had a potential error  
Of the 716 MAOs that submitted the 102 million encounter records we reviewed,  
683 MAOs submitted a record that had at least 1 potential error.25  However,  
9 MAOs, or 1 percent of all MAOs, submitted half of the records that had 
a potential error (2.7 of 5.2 million).  Overall, these nine MAOs submitted 
12 percent of all of the encounter records that we reviewed.  One of these MAOs 
accounted for 33 percent of records with an error, largely driven by incorrect 
original control numbers.  For four of these nine MAOs, more than 90 percent of 
their submitted records had a potential error.   
For certain potential errors, a small number of MAOs had a high number of  
encounter records with the error: 
  Five MAOs submitted half of the records missing beneficiary last names. 
  Five MAOs submitted three quarters of the records with inactive or 
invalid billing provider NPIs. 
  Eight MAOs submitted a quarter of the records containing a potentially 
duplicated service. 
 
25 We did not include missing billing provider NPI or missing billing provider name as errors for 
this calculation because these billing provider identifiers may have been erroneously removed by 
CMS in its edit process. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    11   
   
  One MAO submitted 98 percent of records in which the claim bill date was 
before the date of service, and all had a claim bill date of March 28, 2011. 
CMS does not require MAOs to submit certain provider 
identifiers used in program integrity reviews, and these 
were frequently absent from encounter data 
CMS does not require MAOs to submit all of the data elements contained on 
a Medicare fee-for-service claim.  Instead, MAOs must submit at least a 
minimum set of required data elements for each service provided to a 
beneficiary.26  Although CMS requires MAOs to submit the NPI for the billing 
provider, CMS does not require MAOs to submit the NPIs for ordering/referring 
providers.  MAOs can submit these NPIs voluntarily, but CMS does not require 
them to do so.  CMS stated that when it designed the encounter data, it 
considered MAOs and CMSs resources and administrative burden and decided 
to not require NPIs for ordering/referring providers because these NPIs are 
required on Medicare fee-for-service claims only for certain types of services.   
CMS stated that it requires MAOs to submit the NPI for the rendering provider 
when it is different from that of the billing provider.  Therefore, when MAOs do 
not submit a rendering provider NPI, CMS considers the rendering provider NPI 
to be the same as the billing provider NPI.  NPIs for ordering/referring and 
rendering providers are vital to program oversight and enforcement activities.  
For example, these provider identifiers are critical for identifying questionable 
billing patterns and pursuing fraud investigations for ordering/referring and 
rendering providers.    
NPIs for ordering/referring providers were absent from 63 percent of 
records for DMEPOS, clinical laboratory, imaging, and home health 
services  
DMEPOS, clinical laboratory services, imaging services, and home health services 
are Medicare program areas that are vulnerable to fraud.  For example, a recent 
fraud investigation found that false orders/referrals for home health services led to 
more than $40 million in fraudulent Medicare payments.  In fee-for-service 
Medicare, CMS denies claims that lack a valid ordering/referring provider NPI for 
these types of services.  However, for the MA encounter data, CMS does not 
require MAOs to submit the ordering/referring provider NPI for any type of 
service.  In total, of the 37 million records for DMEPOS, clinical laboratory 
services, imaging services, and home health services in our review, 63 percent did 
not include an NPI for an ordering/referring provider.27  Specifically, the 
ordering/referring provider NPI was absent from the following types of records: 
 
26 CMS, Encounter Data Minimum Data Elements, August 2014. 
27 Appendix C contains a description of the encounter records included in this review. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    12   
   
  72 percent of DMEPOS records,  
  62 percent of clinical laboratory and imaging records, and  
  23 percent of home health records. 
Eight MAOs accounted for a quarter of the DMEPOS, clinical laboratory, imaging, 
and home health records that did not include an NPI for an ordering/referring 
provider.   
Rendering provider NPIs were absent from 13 percent of a subset of 
records for physician services  
Rendering providers are the providers who actually performedor rendered
the service.  They may or may not be distinct from billing providers, which are 
the individuals or organizations that bill for the services provided.  To review 
records that would have a rendering provider that was distinct from the billing 
provider, we selected records for evaluation and management services.  
Evaluation and management services are beneficiary visits to physicians and 
nonphysician practitioners to assess and manage their health, such as office visits 
and specialist visits.  Generally, when an evaluation and management record has 
an organization that billed for the service provided, the record needs a rendering 
provider NPI in order to identify the individual who actually saw the patient.  
Identifying the provider who performed the service is vital to certain program 
oversight activities.  For example, if records showed that a rendering provider 
performed more than 24 hours of services on the same day, this may indicate that 
some services were never actually performed. 
When an MAO does not submit an NPI for a rendering provider, CMS considers 
the rendering provider NPI to be the same as the billing provider NPI.  However, 
of the 23 million evaluation and management records that had an organization as 
the billing provider, 3 million (13 percent) did not include a rendering provider 
NPI.  Because the billing providers were organizations and not individuals, it is 
unlikely that the rendering provider NPIs were the same as the billing provider 
NPIs.  Five MAOs accounted for a quarter of the records that did not include 
a rendering provider NPI.   
For the MA encounter data in our review, MAOs had 
submitted almost all records within CMSs specified 
timeframe 
For the dates of service that we reviewed, CMS had instructed MAOs to submit 
MA encounter data within 13 months of the date of service.  CMS now directs 
MAOs to submit data by the final risk adjustment data submission deadline.28  
 
28 The final risk adjustment data submission deadline is no earlier than January 31 of the year 
following the payment year, whichdepending on when the service was performed during the 
yearis between 13 and 25 months from the date of service.   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    13   
   
Of the 102 million encounter records from the first quarter of 2014, we reviewed  
97 million that were submitted by MAOs for the first time.  Of these 97 million 
initial submissions, 93 million, or 96 percent, were submitted by MAOs within  
13 months of the service date.  The average number of days that elapsed between 
the service date and the submission date was 127 days.  Of the records submitted 
beyond 13 months of the service date, a quarter were submitted by five MAOs.   
CMS has addressed errors by notifying MAOs of edit 
results and rejecting some data, but it has not monitored 
MAOs response to these actions  
When CMS has identified data errors through reject edits, informational edits, or 
analyses of the MA encounter data, it has notified MAOs about these errors using 
a variety of mechanisms, including the following: 
  automated reports of edit results for individual encounter records;  
  webinar presentations, user group calls, technical instructions, newsletters, 
and memorandums that highlight and recommend ways to prevent errors 
that frequently occur across MAOs;  
  periodic report cards tailored to each MAO that specify the MAOs 
volume of submitted records and rate of rejected records compared to 
averages across MAOs; and 
  direct contact with specific MAOs regarding their respective frequently 
occurring errors.   
In addition, for some data errors that it has identified, CMS has introduced new 
reject edits to prevent incorrect data from being included in the MA encounter 
data.  However, CMS has not implemented any other compliance activities 
related to ensuring data integrity, such as issuing notices of noncompliance, 
warning letters, or corrective action plans to MAOs.   
CMS has not tracked how MAOs responded to edits that rejected 
data and has no means of doing so 
CMSs key control to ensure data integrity has been its edit process.  However, 
CMS has not tracked whether or how MAOs responded to edits that rejected 
data.  In fact, CMS instructs MAOs to respond to EDPS reject edits by 
submitting new records with correct information that do not identify the original 
control number, i.e., the control number of the rejected record that is being 
corrected.  Without the original control number, CMS has no means of tracking 
whether MAOs are resubmitting corrected versions of previously rejected 
records.  In contrast, when an MAO decides to modify a record that CMS has 
previously accepted, it may submit a replacement record and must identify the 
original control numberi.e., the control number of the accepted record that is 
now being modifiedon the replacement record.   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    14   
   
 
 
CMS has not established performance measures that monitor 
MAOs submission of records with missing or invalid data 
In 2016, CMS developed the MA Encounter Data Integrity and Monitoring Plan, 
which describes its strategy for ensuring the integrity of the encounter data.  This 
strategy outlines a range of activities, including plans to implement compliance 
actions based on key performance measures.  In its 2018 Call Letter, CMS 
identified seven measures that it will use to monitor and assess MAOs 
performance related to the integrity of the encounter data.29  CMS stated that it 
will issue notices of noncompliance, warning letters, and corrective action plans 
for MAOs that fail to satisfy certain performance thresholds based on these 
measures.  The seven performance measures that CMS has identified address 
whether MAOs completed a certification to submit data, submitted any records, 
submitted records on a timely basis, and submitted records for all services 
rendered.30  However, CMS has not yet identified performance measures related 
to the completeness of data within a submitted record (whether key data elements 
contain nonmissing values) and the validity of the data (whether the reported 
data reflect the information required to be shown in the data element).  In future 
years, CMS expects to revise its performance measures or include additional 
measures.   
   
 
29 CMS, Announcement of Calendar Year 2018 Medicare Advantage Capitation Rates and 
Medicare Advantage and Part D Payment Policies and Final Call Letter and Request for 
Information, April 2017.      
30 Examples of performance measures related to whether MAOs submitted records for all 
services rendered include whether an MAO had an extremely low volume of overall submissions 
and whether it had an extremely low volume of accepted records by service type. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    15   
   
CONCLUSION AND RECOMMENDATIONS 
In 2012, MAOs began submitting more detailed information regarding all 
services provided to MA beneficiaries.  This information is known as the MA 
encounter data.  Ensuring the completeness, validity, and timeliness of the MA 
encounter data is critical for calculating accurate MA payments and realizing the 
full potential of these data to improve MA program integrity and quality of care 
in the MA program.  With this being the case, potential errors in these datalike 
those identified in this reviewmay undermine these important efforts.  CMS 
reported that it has addressed many of the errors we identified.  However, some 
of the remaining types of errorssuch as encounter records that lacked 
a beneficiary last name or a valid identifier for a billing providermay raise 
concerns about the legitimacy of services documented in the data.  In addition, 
CMS does not require MAOs to submit identifiers for ordering or referring 
providers, and it requires identifiers for rendering providers only under certain 
circumstances.  We found that these were frequently absent, which limits the use 
of these data for vital program oversight and enforcement activities.     
CMSs key control to ensure data integrity has been its edit process.  However, 
CMS has not tracked whether MAOs responded to edits that rejected data, i.e., 
reject edits.  CMS has plans to implement additional compliance activities to 
ensure data integrity, but it has not identified performance measures that address 
MAOs submission of records with complete and valid data. 
In light of our findings, we recommend that CMS: 
Take actions as appropriate to address potential errors in the MA 
encounter data 
CMS should take actions, as it deems appropriate, to address potential errors in 
the MA encounter data, which could include, but are not limited to 
(1) introducing additional reject edits, (2) identifying why data were missing and 
restoring these data if they were inappropriately removed in the edit process, and 
(3) identifying why code values did not conform to format specifications and 
correcting these values.  In addition, OIG has provided CMS with a list of the 
required data elements that contained the dates 12/31/9999 and 12/31/8888.  
CMS should review these data elements and modify its instructions to MAOs 
and users of MA encounter data to indicate whether these are correct and 
appropriate default values for these data elements.   
Provide targeted oversight of MAOs that submitted a higher 
percentage of encounter records with potential errors  
Only a few MAOs submitted half of the records that contained a potential error 
in our review.  To prevent further submission errors, CMS should provide 
targeted technical assistance and guidance to MAOs that submitted a high 
percentage of records with potential errors.  OIG has provided CMS with a list 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    16   
   
of the MAOs that submitted encounter records that our review identified as 
having potential errors, as well as each MAOs percentage of encounter records 
that had potential errors. 
Ensure that billing provider identifiers are valid and active on all 
records in the MA encounter data 
CMS already performs reject edits to prevent the submission of billing provider 
NPIs that are incorrectly formatted or that belong to providers under sanction.  
CMS should extend these efforts to include a reject edit that rejects encounter 
records that contain a billing provider NPI that is not a valid and active NPI in 
the NPPES registry.   
Require MAOs to submit ordering and referring provider identifiers 
for applicable records  
CMS does not require MAOs to submit the NPIs for ordering and referring 
providers.  CMS should amend the Encounter Data Minimum Data Elements 
documentation to clearly delineate that ordering and referring provider NPIs and 
names are required for certain types of records, such as those for DMEPOS, 
clinical laboratory, imaging, and home health services.  CMS also should 
establish and implement reject edits that (1) reject encounter records in which the 
NPI and/or name for the ordering/referring provider is not present when required 
and (2) reject encounter records that contain an ordering/referring provider NPI 
that is not a valid and active NPI in the NPPES registry.   
Ensure that MAOs submit rendering provider identifiers for 
applicable records  
CMS stated that it requires MAOs to submit the rendering provider NPI when it 
is different from the billing provider NPI.  When MAOs do not submit a 
rendering provider NPI, CMS considers the rendering provider NPI to be the 
same as the billing provider NPI.  Our review identified missing NPIs for 
rendering providers on records in which it was unlikely that the rendering 
provider NPI was the same as the billing provider NPI.  CMS should amend the 
Encounter Data Minimum Data Elements documentation to clearly delineate that 
rendering provider NPIs and names are situationally required.  In addition, CMS 
should take any other steps that it deems necessary to ensure that MAOs submit 
rendering provider identifiers for applicable records.  For example, CMS could 
establish and implement reject edits that (1) reject encounter records in which the 
NPI and/or name for the rendering provider is not present when required (e.g., an 
evaluation and management record in which the billing provider NPI is for an 
organization) and (2) reject encounter records that contain a rendering provider 
NPI that is not a valid and active NPI in the NPPES registry.   
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    17   
   
Track MAOs response to reject edits  
Because CMSs key control to ensure the submission of complete and accurate 
data is its edit process, which results in rejected data, CMS should track the 
extent to which MAOs correct and resubmit (or void) rejected records.  To this 
end, CMS should require data from MAOs that would allow it to effectively 
track whether MAOs are responding to EDPS reject edits.  For example, CMS 
may consider requiring MAOs respond to such edits by submitting corrected 
replacement records and identifying the original control numberi.e., the 
control number of the rejected record that is being correctedon the resubmitted 
record.  It also may be necessary for CMS to require MAOs to void records that 
CMS had rejected and that MAOs will not be resubmitting, such as records that 
CMS rejected as duplicates. 
Establish and monitor MA encounter data performance thresholds 
related to MAOs submission of records with complete and valid data 
CMS is in the process of establishing performance thresholds for monitoring 
MAOs submission of MA encounter data.  CMS should establish and monitor 
performance threshold(s) related to the extent to which MAOs submit complete 
data (i.e., whether key data elements contain nonmissing values) and valid data 
(i.e., whether reported data reflect the information required to be shown in the 
data element).  In addition, CMS should identify MAOs that fail to meet these 
performance thresholds, and it should conduct compliance activitiessuch as 
issuing notices of noncompliance, warning letters, and corrective actions plans
as needed to improve performance. 
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    18   
   
AGENCY COMMENTS AND OFFICE OF INSPECTOR GENERAL 
RESPONSE 
In response to our draft report, CMS noted that ensuring the accuracy of the MA 
encounter data for payment purposes is an essential part of its commitment to 
combating fraud, waste, and abuse in Medicare.  CMS highlighted its efforts to 
improve the accuracy of the data, including its recent release of guidance on best 
practices that MAOs can implement to help with the process of submitting 
encounter data. 
In reference to our finding that 28 percent of MA encounter records contained 
potential errors on required data, CMS stated that this finding is incorrect 
because the majority of the errors resulted from data being loaded incorrectly 
into its system.  However, our analysis is based on the total percentage of 
potential errors that we identified in the MA encounter data that we extracted 
from CMSs IDR in August 2015.  The 28-percent figure reflects all potential 
errors that OIG found at that time, regardless of the cause.  We recognize that 
with the corrections that CMS reports as having made to that data since our 
review, only 5 percent of records would continue to contain a potential error.   
CMS concurred with four of our seven recommendations.  CMS agreed that it 
will: 
  work to address potential errors in the MA encounter data by reviewing 
submission instructions for consistency and assessing the validity of the 
highest priority data elements; 
  review the list of MAOs that submitted a higher percentage of the 
encounter records with potential errors identified and consider how to 
incorporate this information into its oversight activities; 
  create an edit to check the validity of billing provider NPIs and monitor 
MAOs with potential issues; and 
  continue its development and implementation of a plan for MA encounter 
data compliance (including performance thresholds) designed to validate 
the encounter data. 
CMS did not concur with our recommendations to require MAOs to submit 
identifiers for ordering and referring providers and to ensure that MAOs submit 
identifiers for rendering providers for applicable records.  For both 
recommendations, CMS noted that because MAOs do not always require these 
NPIs on their provider claims or encounter data, they often do not have this 
information available to report.  CMS stated that it seeks to balance 
administrative burden on entities that are subject to reporting requirements, but it 
will explore whether identifiers for ordering and referring providers and 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    19   
   
rendering providers are necessary for program integrity purposes and will 
consider requiring them in the future. 
OIG understands CMSs need to balance administrative burden and reporting 
requirements with the program integrity benefits.  With respect to requiring 
identifiers for ordering and referring providers, we believe that the program 
integrity benefits would be substantial.  For example, these provider identifiers 
are critical for identifying questionable billing patterns and pursuing fraud 
investigations for ordering and referring providers.  Collecting these identifiers is 
essential for MAOs to conduct their own oversight to prevent and detect fraud, 
waste, and abuse.  DMEPOS, clinical laboratory services, imaging services, and 
home health services have a history of being vulnerable to fraud.  If MAOs do 
not have information on NPIs for ordering and referring providers for these 
services, it is unclear how the MAOs are detecting and preventing fraud in these 
areas.  In addition, the availability of identifiers for ordering and referring 
providers enhances CMSs ability to perform its own oversight and hold 
providers accountable for fraudulent and abusive practices.  OIG continues to 
recommend that CMS require MAOs to submit ordering and referring provider 
identifiers for applicable records. 
Likewise, having the identifiers for rendering providers is essential for MAOs 
and for CMS to be able to perform basic oversight and fraud detection analyses.   
For example, if records showed that a rendering provider performed more than 
24 hours of services on the same day, this may indicate that some services were 
never actually performed.  CMS stated in its technical comments that it requires 
MAOs to submit the rendering provider NPI when it is different from the billing 
provider NPI.  We continue to recommend that CMS amend the Encounter Data 
Minimum Data Elements documentation to clearly delineate that rendering 
provider NPIs and names are required when they differ from those of the billing 
provider, and that CMS take any other steps it deems necessary to ensure that 
MAOs submit rendering provider identifiers for records when they are required. 
CMS did not concur with our recommendation for it to track MAOs response to 
reject edits.  CMS stated that modifying its systems and requiring that MAOs 
modify their systems in order to track rejected records would be administratively 
burdensome to build and maintain.  CMS believes that its plan for MA encounter 
data compliance, which prioritizes the overall completeness and volume of MA 
encounter data, is more comprehensive, more transparent, and less burdensome 
on CMS and MAOs. 
By tracking MAOs responses to reject edits, CMS could determine MAOs 
capacity to submit corrected records, address any specific barriers that MAOs 
may encounter when responding to such edits, and ensure the completeness of 
the data.  We support CMSs consideration of the most cost-effective ways to 
ensure the completeness and accuracy of the data. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    20   
   
In sum, OIG believes that implementation of our recommendations will improve 
the completeness and validity of the MA encounter data and greatly enhance the 
ability of MAOs, CMS, and OIG to combat fraud, waste, and abuse in Medicare.  
We look forward to updates from CMS on its efforts toward these ends. 
The full text of CMSs comments can be found in Appendix E. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    21   
   
APPENDIX A 
Methodology To Identify Potential Errors Related to the 
Completeness and Validity of Required Data Elements 
For 102,382,853 encounter records from the first quarter of 2014, we assessed 
the extent to which there were potential errors related to the completeness and/or 
validity of 56 required data elements.  Exhibit A-1 below outlines the required 
data elements included in our review and the three claim typesi.e., DMEPOS, 
professional, and/or institutional to which these data elements are applicable.   
 
Completeness of required data elements.  To identify potential errors related to 
completeness, we determined whether required data elements were missing 
values for encounter records in which the data element was always required to be 
submitted by MAOs.  For character variables, we considered the value to be 
missing if the data element was blank or contained the tilde (~) character, 
a default value that CMS uses to represent a lack of data or null values.  For 
numeric and date variables, we considered the value to be missing if the data 
element was blank.  Exhibit A-1 specifies whether required data elements were 
included in our completeness evaluation.  Generally, we did not assess 
completeness for any data element that we could not definitively determine to be 
always required to be submitted by MAOs.   
Validity of required data elements.  Exhibit A-1 also specifies the criteria we 
used to identify potential errors related to the validity of selected required data 
elements.  We identified potential validity errors for records in which these data 
elements contained nonmissing values.   
Exhibit A-1.  Methods Used To Identify Potential Errors on 56 Required Data Elements in MA Encounter Data1 
Required Data  Claim Type   Assessed 
Definition  Criteria Used To Identify Validity Error 
Element  Reviewed  Completeness 
Admission date  The date the beneficiary was  Institutional  Yes2  Date is before the beneficiarys birthdate or 
admitted to the medical facility  after the end date of service    
Admission source  The code indicating the  Institutional  No  Value does not match a valid value in 
code  source of the admission to the  CMSs IDR Data Dictionary  
medical facility 
Admission type code  The code indicating the type  Institutional  Yes2  Value does not match a valid value in 
and priority of the inpatient  CMSs IDR Data Dictionary 
admission associated with the 
service 
Begin date of service  The first day on the billing  All  Yes  Date is after the end date of service  
statement covering services 
rendered to the beneficiary 
Beneficiary birthdate  The beneficiarys date of birth   All  Yes  Value does not match birthdate in the  
Medicare Enrollment Database (EDB) for 
the Health Insurance Claim Number 
(HICN)3 
Beneficiary first  The beneficiarys first name  All  Yes  Validity not assessed 
name 
Beneficiary sex  The beneficiarys sex  All  Yes  Value does not match the beneficiarys sex 
code4  in the EDB for the HICN3 
Continued on next page 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    22   
   
Exhibit A-1.  Methods Used To Identify Potential Errors on 56 Required Data Elements in MA Encounter Data1 
(continued) 
Required Data  Claim Type   Assessed 
Definition  Criteria Used To Identify Validity Error 
Element  Reviewed  Completeness 
Beneficiary HICN  The number uniquely  All  Yes  Value does not match a HICN in the EDB or 
identifying the primary  CMSs IDR beneficiary records5 
beneficiary 
Beneficiary last  The beneficiarys last name  All  Yes  Validity not assessed 
name 
Beneficiary local  The beneficiarys sex  All  Yes  Value does not match the beneficiarys sex in 
sex code4  the EDB for the HICN3 
Bill frequency  The code indicating the  All  Yes  Value does not match a valid value in CMSs 
code  sequence of a claim during  Encounter Data Minimum Data Elements 
the current period of care  document 
Billing provider  The name of the billing  All  Yes  Validity not assessed 
name  provider on the claim 
Billing provider  The NPI number of the billing  All  Yes  Value does not match a valid NPI in the 
NPI   provider on the claim  National Plan and Provider Enumeration 
System (NPPES) registry or matches an NPI 
in the NPPES registry that was inactive 
between the begin and end date of service6 
Claim bill date  The date when the bill was  All  Yes  Date is before the begin date of service 
created for a claim 
Contract name  The name of the MAO  All  Yes  Validity not assessed 
Contract number7  The unique identification  All  Yes  Value does not match a contract number in 
number for the MAO  CMSs MA/Part D Contract and Enrollment 
Data files 
Diagnosis code  The code indicating the  All  Yes  Value does not match a valid ICD-9 diagnosis 
one8  diagnosis, condition, or other  code9 
reason that is chiefly 
responsible for the service 
provided 
Discharge date  The date the beneficiary was  Institutional  No  Date is before the begin date of service 
discharged from the facility or 
died 
Discharge status  The code indicating the status  Institutional  Yes2  Value does not match a valid value in CMSs 
code  of the patient as of the end  IDR Source to Target Mapping Spreadsheet 
date of service  or in the National Uniform Billing Committee 
(NUBC) UB-04 Data Specifications Manual  
Encounter filing  The code indicating the type  All  Yes  Value does not match a valid value in CMSs 
organization type  of organization, plan, or  Encounter Data Minimum Data Elements 
code  provider filing a claim  document 
End date of  The last day on the billing  All  No  Date is before the begin date of service 
service  statement covering services 
rendered to the beneficiary 
Line begin date of  The beginning date of a  All  Yes   Date is not within the begin and end date of 
service  service for the claim line  for DMEPOS &  service or is after the line end date of service 
Professional 
Line diagnosis  The code indicating the  DMEPOS   Yes  Value does not match a valid ICD-9 diagnosis 
code10  diagnosis supporting the claim  Professional  code9 
line 
Line diagnosis  The code indicating whether  DMEPOS   Yes  Value does not match a valid value in CMSs 
qualifier code10  the diagnosis is the primary or  Professional  IDR Source to Target Mapping Spreadsheet 
other diagnosis on the claim 
line 
Line end date of  The ending date of service for  All  Yes   Date is not within the begin and end date of 
service  the claim line  for DMEPOS &  service or is before the line begin date of 
Professional  service 
Line other  The code indicating the first  DMEPOS   Yes  Value does not match a valid ICD-9 diagnosis 
diagnosis   diagnosis supporting the claim  Professional  code9 
code one10  line 
Continued on next page 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    23   
   
Exhibit A-1.  Methods Used To Identify Potential Errors on 56 Required Data Elements in MA Encounter Data1 
(continued) 
Required Data  Claim Type   Assessed 
Definition  Criteria Used To Identify Validity Error 
Element  Reviewed  Completeness 
Line prescription  The date the prescription was  DMEPOS   No  Date is before the beneficiarys birthdate 
date  filled  Professional 
Line procedure  The code indicating the   All  Yes   Value does not match a valid Healthcare 
code  procedure, supply, product, or  for DMEPOS &  Common Procedure Coding System 
service that was rendered to  Professional  (HCPCS) code or a valid Health Insurance 
the beneficiary  Prospective Payment System (HIPPS) code  
Line procedure  The first code indicating more  All  No  Value does not match a valid HCPCS modifier 
code modifier one  specific procedure information  code 
for a procedure code 
Line revenue  The code indicating the  Institutional  No  Value does not match a valid value in the 
code   revenue code for each cost  NUBC UB-04 Data Specifications Manual  
center for which a separate 
charge is billed 
Occurrence span  The date when a specific  Institutional  No  Date is after the occurrence span end date, is 
begin date  event related to an  before the beneficiarys birthdate, or is after 
institutional claim began  the end date of service for which the 
occurrence span code is a prior stay date 
(i.e., occurrence span codes 71, 78, or 80)  
Occurrence span  The code indicating a  Institutional  No  Value does not match a valid value in CMSs 
code  significant event related to an  IDR Data Dictionary 
institutional claim; these codes 
are claim-related occurrences 
that are related to a time period 
Occurrence span  The date when a specific   Institutional  No  Date is before the occurrence span begin 
end date  event related to an  date, is before the beneficiarys birthdate, or is 
institutional claim ended   after the end date of service for which the 
occurrence span code is a prior stay date 
(i.e., occurrence span codes 71, 78, or 80)11   
Original control  The control number of the  All  Yes12  Value is not blank on records submitted for 
number  original record that has been  the first timei.e., records with a bill 
adjusted  frequency code of 1 (original claim) in the 
header portion of the record 
Patient control  The patients control number  All  Yes  Validity not assessed 
number  or the claim identifier used in 
the MAOs internal system 
Place of service  The code indicating the place  DMEPOS  Yes  Value does not match valid value in CMSs 
code  where the service was  Professional  Medicare Claims Processing Manual,  
performed  chapter 26 
Principal  The code indicating the  All  Yes  Value does not match a valid ICD-9 diagnosis 
diagnosis code8  diagnosis, condition, or other  code9 
reason that is chiefly 
responsible for the service 
provided 
Procedure date  On an institutional claim, the  Institutional  No  Date is not within the begin and end date of 
one  date on which the principal or  service13 
other procedure was performed 
Procedure date  On an institutional claim, the  Institutional  No  Date is not within the begin and end date of 
two  date on which the principal or  service13 
other procedure was performed 
Procedure date  On an institutional claim, the  Institutional  No  Date is not within the begin and end date of 
three  date on which the principal or  service13 
other procedure was performed 
Procedure date  On an institutional claim, the  Institutional  No  Date is not within the begin and end date of 
four  date on which the principal or  service13 
other procedure was performed 
Continued on next page 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    24   
   
Exhibit A-1.  Methods Used To Identify Potential Errors on 56 Required Data Elements in MA Encounter Data1 
(continued) 
Required Data  Claim Type   Assessed 
Definition  Criteria Used To Identify Validity Error 
Element  Reviewed  Completeness 
Procedure date  On an institutional claim, the  Institutional  No  Date is not within the begin and end date of 
five  date on which the principal or  service13 
other procedure was 
performed 
Procedure date  On an institutional claim, the  Institutional  No  Date is not within the begin and end date of 
six  date on which the principal or  service13 
other procedure was 
performed 
Procedure  The date on which the  Institutional  No  Date is not within the begin and end date of 
perform date  principal or other procedure  service13 
was performed 
Product type  The code indicating the type  All  No  Value does not match a valid value in CMSs 
code  of procedure or diagnosis  IDR Source to Target Mapping Spreadsheet 
category 
Provider accept  The code indicating the status  All  Yes  Value does not match a valid value in CMSs 
assignment code  of an assignment of benefits  Encounter Data Minimum Data Elements 
document 
Provider  An indicator showing whether  All  Yes  Value does not match a valid value in CMSs 
assignment of  the MAO has been authorized  Encounter Data Minimum Data Elements 
benefits switch  to pay the provider  document 
Provider  An indicator showing if a  DMEPOS  Yes  Value does not match a valid value in CMSs 
signature switch  provider signature is on file  Professional  IDR Data Dictionary  
Related-cause  The code indicating an  DMEPOS  No  Value does not match a valid value in CMSs 
code one  associated cause of an  Professional  IDR Data Dictionary 
illness, injury, or accident on a 
claim 
Related-cause  The code indicating an  DMEPOS  No  Value does not match a valid value in CMSs 
code two  associated cause of an  Professional  IDR Data Dictionary 
illness, injury, or accident on a 
claim 
Related-cause  The code indicating an  DMEPOS  No  Value does not match a valid value in CMSs 
code three  associated cause of an  Professional  IDR Data Dictionary 
illness, injury, or accident on a 
claim 
Related-cause  The date of an associated  DMEPOS   Yes14  Date is after the end date of service or is 
date  cause of an illness, injury, or  Professional  before the beneficiarys birthdate 
accident as reported on the 
claim 
Related condition  The code indicating a  Institutional  No  Value does not match a valid value in the 
code  condition related to a claim  NUBC UB-04 Data Specifications Manual or 
in CMSs Medicare Claims Processing 
Manual, chapter 25  
Related  The code indicating a  Institutional  No  Value does not match a valid value in CMSs 
occurrence code  significant event related to an  IDR Data Dictionary 
institutional claim; these 
codes are claim-related 
occurrences that are related 
to a specific date 
Related  The date associated with a  Institutional  No  Date is before the beneficiarys birthdate for 
occurrence date  significant event related to an  records in which the related occurrence code 
institutional claim   was not a birthdate of the insured (i.e., not 
related occurrence codes A1, B1, or C1) or is 
after the end date of service for records in 
which the related occurrence code was an 
accident date or a birthdate of the insured 
(i.e., related occurrence codes 01, 02, 03, 04, 
05, A1, B1, or C1)15 
Continued on next page 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    25   
   
Exhibit A-1.  Methods Used To Identify Potential Errors on 56 Required Data Elements in MA Encounter Data1 
(continued) 
Required Data  Claim Type   Assessed 
Definition  Criteria Used To Identify Validity Error 
Element  Reviewed  Completeness 
Submitter  The unique identification  All  Yes  Value does not match a contract number in 
contract number7  number for the MAO  CMSs MA/Part D Contract and Enrollment 
Data files  
Source: OIG analysis of MA encounter data for JanuaryMarch 2014 from CMSs IDR.  
1 Encounter records include a header portion of the record and one or more service lines.  In this Appendix, data elements that MAOs submit in 
the service line portion of the record begin with the word line.  We counted an encounter record as having a potential error related to a service 
line data element if the record had at least one service line with a potential error for that data element. 
2 We assessed whether this data element had a missing value for claim type codes 4011 (hospital inpatientincluding Medicare Part A), 
4012 (hospital inpatientMedicare Part B only), 4018 (hospital swing beds), 4021 (skilled nursing inpatientincluding Medicare Part A), 
4022 (skilled nursing inpatientMedicare Part B only), 4041 (religious nonmedical health care institutionshospital inpatient).  
3 We excluded records from this analysis if the beneficiary HICN was not contained in the EDB.  
4 In the data that we reviewed, the beneficiary sex code and beneficiary local sex code contained the same information using different codes. 
5 We excluded records from this analysis if the beneficiary HICN was a Railroad Retirement Board number. 
6 CMS has designated the values 1999999992, 1999999984, and 1999999976 as allowable default values for the NPI for DMEPOS, 
professional, and institutional claim types, respectively.  We excluded records from this analysis if the value on a given record was the allowable 
default value for that claim type. 
7 In the data that we reviewed, the contract number and submitter contract number contained the same information. 
8 In the data that we reviewed, the diagnosis code one and principal diagnosis code contained the same information. 
9 We considered diagnosis codes to be valid if they matched an ICD-9-CM diagnosis code effective 10/1/2013 through 9/30/2014. 
10 We evaluated data contained in (1) the line diagnosis code and (2) the line diagnosis qualifier code for the first diagnosis listed on a record (i.e., 
the diagnosis for which the line diagnosis sequence number was one).  In the data that we reviewed, the line diagnosis code for the first diagnosis 
listed on a record and the line other diagnosis code one contained the same information. 
11 We excluded records from this analysis if the occurrence span end date contained 12/31/9999 and the occurrence span from date was 
missing.  
12 We assessed whether the original control number was missing on replacement recordsi.e., records with a bill frequency code of 
7 (correct/replace) in the header portion of the record.  
13 We excluded records from this analysis if procedure dates contained 12/31/9999 and the corresponding procedure code was missing.  If 
a procedure date contained 12/31/9999 and the corresponding procedure code was not missing, we considered the procedure date to be after 
the records end date of service. 
14 We assessed whether the related-cause date had a missing value for records in which the related-cause code one, related-cause code two, or 
related-cause code three contained the codes AA (auto accident), AB (abuse), AP (another party responsible), or OA (other accident). 
15 We excluded records from this analysis if the related occurrence date contained 12/31/9999 or 12/31/8888 and the related occurrence code 
was missing.  If a related occurrence date contained 12/31/9999 or 12/31/8888 and the corresponding related occurrence code was not 
missing, we considered the related occurrence date to be after the records end date of service.   
 
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    26   
   
APPENDIX B 
Methodology To Identify Potential Duplication of Services 
As a part of our evaluation of the validity of MA encounter data, we determined 
the extent to which encounter records contained potentially duplicated services.  
We considered two service lines to be duplicated if they matched on service type, 
beneficiary, date, provider, diagnosis, and MAO.  To determine the number of 
encounter records with a duplicated service, we counted the number of encounter 
records that contained at least one duplicated service line.  Exhibit B-1 below 
outlines the data elements used in our evaluation of potential duplication by claim 
type.31 
If a service took place at an ambulatory surgical center (ASC), contained any 
procedure modifier codes, or contained a line procedure code that was 
a methodology-based molecular pathology stacking code, we did not include 
the service line in our evaluation of potential duplication.32  We also did not 
include encounter records that were missing a billing provider NPI.  Of the total 
102,382,853 encounter records from the first quarter of 2014, 58,982,385 had at 
least one service line included in our evaluation of potential duplication.33 
Exhibit B-1.  Data Elements Used To Identify Potential Duplication in MA Encounter Data 
DMEPOS and Professional Records  Institutional Records 
Claim type code  Claim type code 
Service type  Line procedure code  Line procedure code 
Place of service code  Service type  Revenue code 
Beneficiary HICN  Bill facility type code1 
Beneficiary 
Beneficiary last name  Bill classification code2 
Line begin date of service  Beneficiary HICN 
Date  Beneficiary 
Line end date of service  Beneficiary last name 
Billing provider NPI  Line begin date of service3 
Provider  Date 
Rendering provider NPI  Line end date of service3 
Diagnosis  Line other diagnosis code one  Billing provider NPI 
Provider 
MAO  Submitter contract number  Rendering provider NPI 
    Diagnosis  Diagnosis code one 
    MAO  Submitter contract number 
Source: OIG analysis of MA encounter data for JanuaryMarch 2014 from CMSs IDR. 
1 The bill facility type code is the first digit of the type of bill used to identify the type of facility that provided care to the beneficiary.   
2 The bill classification code is the second digit of the type of bill to indicate the classification of the type of service provided. 
3 If an institutional service line was missing a line begin date of service and/or a line end date of service, we matched on the begin 
date of service and/or end date of service from the header portion of the record.   
 
31 The edit that CMSs EDPS uses to reject duplicated services includes payment data elements 
that were not available to OIG at the time of our review. 
32 We excluded service lines in which the service took place at an ASC because ASCs that 
perform a procedure bilaterally in the same operative session may report it on two separate service 
lines with the same procedure code.  We excluded service lines that contained any procedure 
modifier codes or contained a line procedure code that was a laboratory stacking code because 
these may be used to indicate repeat or distinct procedures and tests.  
33 When we requested from CMS the logic necessary for differentiating service lines that were 
denied payment by the MAO, CMS was unable to provide this.  Therefore, it is possible that these 
service lines may have been included in our evaluation of potential duplication.   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    27   
   
APPENDIX C 
Methodology To Evaluate Identifiers for Ordering/Referring and 
Rendering Providers and Timeliness of Data Submission 
We used the methods outlined below to determine the extent to which encounter 
records contained NPIs for ordering/referring providers and rendering providers 
and to review the timeliness of data submissions. 
Completeness of ordering/referring provider NPIs.  Ordering/referring providers 
are all physicians and nonphysician practitioners who order and/or refer 
DMEPOS, clinical laboratory and imaging services, and home health agency 
services.  In fee-for-service Medicare, CMS denies claims that lack a valid 
ordering/referring provider NPI for these types of services.  For the 4.4 million 
DMEPOS records, 32 million clinical laboratory and imaging records, and 
395,022 home health records in our review, we identified missing values in the 
ordering/referring provider NPI data element.34, 35  
Completeness of rendering provider NPIs.  Rendering providers are the providers 
who actually performedor renderedthe service.  They may or may not be 
distinct from billing providers, which are the individuals or organizations billing 
for the services provided.  To determine the extent to which rendering provider 
NPIs were missing on records in which they would be distinct from the billing 
provider NPIs, we evaluated the subset of evaluation and management records 
that had a billing provider NPI registered in NPPES as entity type 2, i.e., 
an organization health care provider.  Evaluation and management services are 
beneficiary visits to physicians and nonphysician practitioners to assess and 
manage their health.  Generally, for evaluation and management records in which 
the billing provider is an organization, the rendering provider NPI is needed to 
identify the individual who saw the patient.36  For the 23 million evaluation and 
management records that had an organization billing provider (i.e., entity type 2), 
 
34 We considered all professional records with Berenson-Eggers Type of Service (BETOS) codes 
T1A through T1H to be clinical laboratory records.  We considered all professional records with 
BETOS codes I1A through I4B to be imaging records.  We considered all institutional records 
with claim type codes 4032 (home health and inpatient (Medicare Part B only)), 4033 (home 
health and outpatient), or 4034 (home health and laboratory services provided to nonpatients 
to be home health records.   
35 Data elements for the ordering/referring provider NPI are located in both the header and 
service line portion of the record.  For records for DMEPOS, clinical laboratory services, and 
imaging services, we counted an encounter record as having a missing ordering/referring 
provider NPI if it was missing an ordering/referring provider NPI from the header portion of the 
record and missing a line ordering/referring provider NPI from at least one service line.  For 
home health records, we counted an encounter record as having a missing ordering/referring 
provider NPI if it was missing an ordering/referring provider NPI, an attending provider NPI, and 
an other provider NPI from the header portion of the record.    
36 On records where the billing provider is registered in NPPES as entity type 1an individual 
or sole proprietorthe rendering provider would be the same as the billing provider. 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    28   
   
we identified missing values in the data element for the rendering provider 
NPI.37, 38 
Data submission timeliness.  To review the timeliness of data submissions, we 
evaluated records submitted by MAOs for the first timeinitial submissions.39 
For 97 million initial submission records, we calculated the length of time that 
elapsed between the last day covering services rendered to the beneficiary (the 
end date of service on the header portion of the record) and the date the MAO 
submitted the record to CMS (the submission date on the header portion of the 
record).     
 
 
   
 
37 We considered all professional records with BETOS codes M1A through M6 to be evaluation 
and management records. 
38 Data elements for the rendering provider NPI are located in both the header and service line 
portion of the record.  We counted an encounter record as having a missing rendering provider 
NPI if it was missing from the header portion of the record and missing from at least one service 
line. 
39 To identify encounter records submitted by MAOs for the first time, we identified encounter 
records with a bill frequency code of 1 (original claim). 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    29   
   
APPENDIX D 
Number of Encounter Records Affected by Each Potential Error, by 
Claim Type 
We assessed the completeness and validity of the MA encounter data for  
102,382,853 encounter records from the first quarter of 2014.  Exhibit D-1 
outlines the number of records affected by each potential error by claim type:  
DMEPOS, professional, and institutional.  We have categorized the potential 
errors that we identified into eight error types.  In total, there were  
4,409,353 DMEPOS records, 85,696,173 professional records, and  
12,277,327 institutional records included in our review, but not all records were 
included in each evaluation of potential errors.  Appendices A and B contain a 
detailed description of the methods used to identify potential data errors.  
Exhibit D-1.  Number of MA Encounter Records With Potential Errors, by Claim Type 
DMEPOS   Profes sional   Institutional  Total  
     
   
Potential Error Identified   
 
 
Records  Records   Records   Records     Records    Records   Records   Records 
Evaluated  with Error  Evaluated  with Error  Evaluated  with Error  Evaluated  with Error 
Inactive or invalid billing provider identifiers 
Inactive or invalid billing 
3,715,191  8,986  63,963,932  73,460  10,354,959  14,524  78,034,082  96,970 
provider NPI1 
Duplicated services 
Record contained duplicated 
674,198  32,912  48,892,031  1,688,478    9,416,156  667,485  58,982,385  2,388,875 
service line(s) 
Missing valuesbilling provider identifiers 
Missing billing provider NPI  4,409,353  685,036  85,696,173  21,301,561  12,277,327  1,897,235   102,382,853  23,883,832 
Missing billing provider name  4,409,353  685,036   85,696,173  21,301,561   12,277,327  1,897,235  102,382,853  23,883,832 
Missing valuesother data 
Missing beneficiary last name  4,409,353  9,844  85,696,173  186,238  12,277,327  22,676  102,382,853  218,758 
Missing admission date2  N/A  N/A  N/A  N/A  1,038,729  31,846  1,038,729  31,846 
Missing place of service code  4,409,353    5  85,696,173  1,242  N/A  N/A   90,105,526   1,247 
Missing discharge status 
N/A  N/A  N/A  N/A  1,038,729  371   1,038,729  371 
code2 
Missing line procedure code  4,409,353    66  85,696,173  59  N/A  N/A  90,105,526    125 
Inconsistent date values 
Claim bill date before begin 
4,409,353  10,907  85,696,173  54,258   12,277,327  15,025  102,382,853  80,190 
date of service 
Related occurrence date 
before birthdate or after end  N/A  N/A   N/A  N/A  5,573,532  27,318  5,573,532  27,318 
date  
Line end date not within begin 
4,409,353  0  85,696,173  0  10,125,345  16,166  100,230,871  16,166 
and end date of service 
Procedure perform date not 
within begin and end date of  N/A  N/A   N/A  N/A  439,832  9,756  439,832  9,756 
service 
Line begin date not within 
begin and end date of  4,409,353  0  85,696,173  0  10,125,345  9,401  100,230,871  9,401 
service 
  Continued on next page 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    30   
   
 
Exhibit D-1.  Number of MA Encounter Records With Potential Errors, by Claim Type (continued) 
DMEPOS   Profes sional   Institutional  Total  
     
   
 
Potential Error Identified 
 
 
Records  Records   Records   Records     Records    Records   Records   Records 
Evaluated  with Error  Evaluated  with Error  Evaluated  with Error  Evaluated  with Error 
Inconsistent date values (continued) 
Procedure date one not within 
N/A  N/A   N/A  N/A  439,825  6,943  439,825  6,943 
begin and end date of service 
Procedure date two not within 
N/A  N/A   N/A  N/A  272,742  4,443  272,742  4,443  
begin and end date of service 
Procedure date three not 
within begin and end date of  N/A  N/A   N/A  N/A  172,154  2,745  172,154  2,745 
service 
Procedure date four not within 
N/A  N/A   N/A  N/A  110,956  1,731  110,956  1,731 
begin and end date of service 
Procedure date five not within 
N/A  N/A   N/A  N/A  74,469  1,091  74,469  1,091 
begin and end date of service 
Procedure date six not within 
N/A  N/A   N/A  N/A  52,694  777  52,694  777 
begin and end date of service 
Admission date after the end 
date of service or before  N/A  N/A   N/A  N/A   2,150,555  680  2,150,555  680 
birthdate   
Related cause date after end 
date of service or before    9,580  5  649,714  656  N/A  N/A  659,294   661   
birthdate 
Occurrence span end date 
before birthdate or after end  N/A  N/A   N/A  N/A   94,386  27  94,386  27 
date of service  
Occurrence span begin date 
before birthdate or after end  N/A  N/A   N/A  N/A    94,386  21  94,386  21 
date of service 
Line prescription date before 
11,632  0  20,890  1  N/A  N/A  32,522   1 
birthdate 
Inappropriate codes 
Discharge status code not 
N/A  N/A   N/A  N/A  12,276,154    306,784  12,276,154  306,784 
formatted as two positions 
Invalid line procedure code 
3,608,211  1  28,426,934  1,064    3,290,608  9  35,325,753  1,074 
modifier one 
Invalid principal diagnosis 
4,409,353  2  85,696,173  129  12,277,327  202  102,382,853  333 
code 
Invalid diagnosis code one  4,409,353  2  85,696,173  129   12,277,327  202  102,382,853   333 
Invalid line procedure code  4,409,314  3  85,696,159  289  11,177,985  204  101,283,458  496 
Invalid line diagnosis code  4,409,353  2  85,696,173  136  N/A  N/A  90,105,526  138   
Invalid line other diagnosis 
 4,409,353    2   85,696,173    136  N/A  N/A  90,105,526   138 
code one 
Invalid admission source code  N/A  N/A  N/A  N/A  12,249,902  8  12,249,902  8 
Invalid line revenue code   N/A  N/A   N/A  N/A   12,276,069  3  12,276,069  3 
  Continued on next page 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    31   
   
Exhibit D-1.  Number of MA Encounter Records With Potential Errors, by Claim Type (continued) 
DMEPOS   Profes sional   Institutional  Total  
     
Potential Error Identified       
 
 
Records  Records   Records   Records     Records    Records   Records   Records 
Evaluated  with Error  Evaluated  with Error  Evaluated  with Error  Evaluated  with Error 
Incorrect original control numbers 
Original control number not 
4,215,403  56,891  81,327,465  1,816,867  11,193,503   204,777  96,736,371  2,078,535 
blank on initial submission 
Beneficiary data that did not match CMSs records 
Beneficiary birthdate does not 
4,375,889  967  85,034,239  20,362   12,180,900   2,529  101,591,028  23,858 
match CMS records 
Beneficiary sex code does not 
4,375,889  175  85,034,239  3,162  12,180,900  451  101,591,028  3,788 
match CMS records 
Beneficiary sex gender code 
4,375,889  175   85,034,239  3,162  12,180,900    451  101,591,028  3,788 
does not match CMS records 
Source:  OIG analysis of MA encounter data for JanuaryMarch 2014 from CMSs IDR.  
1 CMS has designated the values 1999999992, 1999999984, and 1999999976 as allowable default values for the NPI for DMEPOS, professional, and 
institutional claim types, respectively.  We excluded records from this analysis if the value on a given record was the allowable default value for that claim 
type. 
2 We assessed whether the admission date and the discharge status code had missing values for claim type codes 4011 (hospital inpatientincluding 
Medicare Part A), 4012 (hospital inpatientMedicare Part B only), 4018 (hospital swing beds), 4021 (skilled nursing inpatientincluding Medicare Part A), 
4022 (skilled nursing inpatientMedicare Part B only), 4041 (religious nonmedical health care institutionshospital inpatient).  
 
 
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    32   
   
APPENDIX E 
Agency Comments 
 
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    33   
   
 
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    34   
   
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    35   
   
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    36   
   
ACKNOWLEDGMENTS 
Joanna Bisgaier served as the team leader for this study.  Other Office of Evaluation and 
Inspections staff from the Philadelphia regional office who conducted the study include 
Jacqualine Reid, Emily Dieckman, Courtney Fanslau, Conswelia McCourt, Karolina Pater, 
and Amy Sernyak.  Central office staff who provided support include Eddie Baker, Jr., 
Mandy Brooks, Evan Godfrey, David Graf, Meghan Kearns, and Christine Moritz.  
This report was prepared under the direction of Linda Ragone, Regional Inspector General 
for Evaluation and Inspections in the Philadelphia regional office, and Tara Bernabe, Deputy 
Regional Inspector General.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
To obtain additional information concerning this report or to obtain copies, contact the 
Office of Public Affairs as Public.Affairs@oig.hhs.gov. 
   
MA Encounter Data Show Promise for Program Oversight, But Improvements Are Needed (OEI-03-15-00060)    37   
   
Office of Inspector General 
http://oig.hhs.gov 
 
The mission of the Office of Inspector General (OIG), as mandated by Public Law 95-452, as 
amended, is to protect the integrity of the Department of Health and Human Services 
(HHS) programs, as well as the health and welfare of beneficiaries served by those 
programs.  This statutory mission is carried out through a nationwide network of audits, 
investigations, and inspections conducted by the following operating components: 
Office of Audit Services 
The Office of Audit Services (OAS) provides auditing services for HHS, either by conducting 
audits with its own audit resources or by overseeing audit work done by others.  Audits 
examine the performance of HHS programs and/or its grantees and contractors in carrying 
out their respective responsibilities and are intended to provide independent assessments of 
HHS programs and operations.  These assessments help reduce waste, abuse, and 
mismanagement and promote economy and efficiency throughout HHS. 
Office of Evaluation and Inspections 
The Office of Evaluation and Inspections (OEI) conducts national evaluations to provide 
HHS, Congress, and the public with timely, useful, and reliable information on significant 
issues.  These evaluations focus on preventing fraud, waste, or abuse and promoting 
economy, efficiency, and effectiveness of departmental programs.  To promote impact, OEI 
reports also present practical recommendations for improving program operations.  
Office of Investigations 
The Office of Investigations (OI) conducts criminal, civil, and administrative investigations 
of fraud and misconduct related to HHS programs, operations, and beneficiaries.  With 
investigators working in all 50 States and the District of Columbia, OI utilizes its resources 
by actively coordinating with the Department of Justice and other Federal, State, and local 
law enforcement authorities.  The investigative efforts of OI often lead to criminal 
convictions, administrative sanctions, and/or civil monetary penalties. 
Office of Counsel to the Inspector General 
The Office of Counsel to the Inspector General (OCIG) provides general legal services to 
OIG, rendering advice and opinions on HHS programs and operations and providing all 
legal support for OIGs internal operations.  OCIG represents OIG in all civil and 
administrative fraud and abuse cases involving HHS programs, including False Claims Act, 
program exclusion, and civil monetary penalty cases.  In connection with these cases, OCIG 
also negotiates and monitors corporate integrity agreements.  OCIG renders advisory 
opinions, issues compliance program guidance, publishes fraud alerts, and provides other 
guidance to the health care industry concerning the anti-kickback statute and other OIG 
enforcement authorities. 
 
   
MA Encounter Data Show Promise for Program Oversight, But Imp rovements Are Needed (OEI-03-15-00060)    38