Generalized Claims Data Call Submission

Generalized Claims Data Call Submission

November 2016

OMB # 0938-1251/Expiration Date: XX/2020

Contents

Introduction 1

Use of Partner Data 2

Detailed Instructions 2

Appendix A: Instructions for Data Submission Template 4

Appendix B: Data Elements 5

Appendix C: Reengineering TTP Input Processes 13

Current Input Method 13

New CSRA Capabilities 13

Reengineering the Input Process 14

Introduction

This document provides information regarding the Generalized Claims Data Call Submission for

November 2016, and future generalized submissions. CSRA, the Healthcare Fraud Prevention Partnership (HFPP), Trusted Third Party (TTP), has developed a new process and expanded the set of data elements for submission by partners in order to make it easier for partners to share their data and to strengthen the analytic capability for studies. Appendix C: Reengineering TTP Input Processes contains a summary of the new input process.

The new data elements and input processes will provide partners with a more advantageous means of providing claims data by:

• Incorporating procedures aimed at reducing the time and effort involved in retrieving claims data elements.

• Accepting a wide range of input formats for the claims to leverage work that many partners already perform compiling claims data on a regular basis.

• Refreshing data on the partner’s schedule: weekly, monthly, quarterly or every 6 months.

• Requesting additional data to include protected health information (PHI) and personally identifiable information (PII) to allow studies to identify suspect activities not previously available to HFPP partners.

• Operating multiple studies with a goal of providing study outcomes more rapidly and with more current actionable results.

If you have any questions about this process, please contact Tim Carrico, the TTP Study Manager, at 301-219-8557, or by email at [email protected]. Emails may also be submitted to [email protected].

Use of Partner Data

CSRA plans to use the general data submissions from the partners for all of its studies. Specific claims data calls, which target only selected Current Procedural Terminology (CPT) codes, will only be made under special circumstances.

CSRA will perform three different types of studies: new studies that target specific areas of fraud; screening studies where partner data is compared to the latest list of excluded, revoked, or sanctioned providers; and recurring studies which will repeat successful past studies with new iterations of data.

The TTP will maintain a list of planned studies on the portal that will cover all three study types. Studies will also be noted in monthly newsletters and discussed at General Assembly meetings.

Partners who do not want their data used in a particular study may “opt-out” by notifying the TTP Study Team by email at least 5 business days prior to the start date of the study. The opt-out can identify new or recurring studies by name. The partner can also opt-out of the screening studies; this choice will remain in effect until rescinded. If a new study is initiated on short notice, all partners who submit general data will be notified by email at least 15 business days prior to the start of analysis to give them sufficient time to decline to participate.

Detailed Instructions

• Because of the new flexibility, each partner will need to complete a Data Submission Template for the TTP describing any customizations to the default submission process. The information provided in the Data Submission Template will remain in effect indefinitely, so the partner will only need to submit a new one when information changes. An Excel template for the worksheet is attached. Appendix A: Instructions for Data provides instructions for completing the template.

  • Please submit the completed Data Submission Template to [email protected] as soon as can, but at least two weeks prior to the date that you plan to upload your data. This will allow the TTP to prepare for appropriate mapping of data to preclude errors or other complications which may arise during data ingestion. The CSRA Technical Team will notify the partner when they are ready to receive their claims data.

• Appendix B: Data Elements contains a list of data elements and their default formats. Partners will be able to document differences between their submission and the defaults in the Data Submission Template.

• An HFPP partner can securely upload claims data into the CSRA infrastructure through the HFPP Portal or via encrypted physical media.

  • The HFPP Collaboration Portal User’s Manual Guide, located on the main dashboard of the portal (at: https://portal.hfpp-ttp.org), provides details on using the General Data Submission tab, which is also located on the main dashboard.  The name of the uploaded file should be:

GDS_Partner_YYYYMMDD_Seq#

The date in the filename is the last day of the month for which claims are being submitted. The sequence number will be “01” for initial files. If resubmissions or replacements are necessary, the Technical Team will provide the sequence number to be used.

• Note: the new HFPP portal does not have file size restrictions so files do not need to be broken into multiple sub-files for the upload.

• Alternatively, partners may submit Generalized Claims Data by means of an encrypted and password protected media such as a CD, DVD, flash drive, or external drive.

  • The shipping address for the media and a TTP point of contact will be provided after the partner’s Data Submission Template is received and processed. The partner will provide the media password to the point of contact in a separate email.

• This first data call request is to include paid claims only for service dates beginning 11/01/2014. All data submissions will end on the last day of the month, so your submission will depend on when and how it is assembled. Follow-on submissions will begin with the first day of the succeeding month.

• The default format for the file is a Comma Separated Value (CSV) text document with pipe-delimited (“|”) separators for the data elements. We will also accept formats such as JavaScript Object Notation (JSON), Extensible Markup Language (XML), or Excel. Files may be zipped before transmission, if desired. The input format must be described on the Data Submission Template.

Appendix A: Instructions for Data Submission Template

The Data Submission Template is an Excel template attached to this email.

Please provide the contact information for the primary person(s) who will be responsible for processing partner data into the HFPP portal.

The partners will have the latitude to adjust the data submission to best fit their situation. The information should be recorded in the template.

Table 1. File Submission Characteristics

Field	Instructions
Data Submission Media	Default method will be to upload data through the secure HFPP Portal. For very large files, the partner can submit the data on encrypted CD/DVD/hard drive. Note: the new HFPP portal does not have file size restrictions for uploads.
Data Submission Update Frequency	Based on partner discussion, a default will be monthly updates to the initial set of 2 years of claims. Partners may also submit quarterly or semiannually if desired.
Estimated Date of 1st Data Submission	Initial data loads will begin after November 15, 2016. Partners will be notified when their Data Submission Template has been processed and the portal is available for uploading data.
Data Format	The default format for submission will remain the same as it has been in the past, a pipe-delimited CSV format. Other formats are also available: JavaScript Object Notation (JSON), Extensible Markup Language (XML), or Excel.
Data Element Differences	The default data elements are identified in Appendix B: Data Elements. If you have format differences or will not be including particular data elements, please indicate them on the worksheet.
Member Identification	Please specify whether the Member ID # will be the actual ID or deidentified. If the Member ID is deidentified, the beneficiary cannot be tracked across multiple submissions from the partner nor across payers (unless the full SSN is provided).
Social Security Number	Please specify whether you will use a full SSN, a partial SSN, or no SSN. The full SSN is the only way of identifying an individual across multiple payers.

In Appendix B, data elements such as #19, Rendering Provider Specialty, allow partners to provide their specialty code definitions if necessary. These can be added as a new tab on the Data Submission Template.

Appendix B: Data Elements

Table 1 contains the data elements requested for professional claims. Additionally, data element formats listed in the following table are provided as a guideline as formats may vary.

Table 2. CSRA Data Elements and Formats

eq	Professional Data Element	Data Element Description	Format	Expected Values
1	Payer Name	Name of entity Providing source data	VARCHAR(40)
2	File Type	The type of file being reported. (i.e. professional; Institutional; Pharmacy, Dental)	CHAR(2)	Professional=P Institutional-I Pharmacy =RX Dental=D
3	Line of Business	Payer Identifier and Line of Business	VARCHAR(40)	e.g., Medicare, Medicaid, Private, P&C
4	Claim Number	A unique number assigned by the payment system that identifies an original claim or an adjusted claim.	VARCHAR(20)
5	Claim Line Number	Line number on the claim	INTEGER(3)
6	Member ID	A unique identification number for the member.	VARCHAR(20)
7	Member Social Security Number	Member's social security number (full 9, last 4 numbers, or none).	INTEGER
8	Member Sex	The sex of the member	CHAR(1)	Male= M Female=F Unidentified=U
9	Member Date of Birth	Member’s Date of Birth.	DATE	MM/DD/YYYY

eq	Professional Data Element	Data Element Description	Format	Expected Values
10	Member State	Member’s state	CHAR(2)	State Abbreviation
11	Member Zip Code	Member’s zip code	INTEGER(5)
12	Member DOD	Member’s Date of Death.	DATE	MM/DD/YYYY
13	Rendering Provider Legal Business Name	Official name of rendering provider organization or if individual, in format LAST SUFFIX, FIRST MIDDLE	VARCHAR(100)	Example: Smith, John Allan for an individual
14	Rendering Provider Doing Business As Name	Name provider renders services under or is known to public by for organizations or if individual, in format LAST SUFFIX, FIRST MIDDLE	VARCHAR(100)	Example: Smith, John Allan for an individual
15	Rendering Provider NPI	The NPI for the provider who treated the member (as opposed to the provider “billing” for the service).	INTEGER(10)
16	Rendering Provider TIN	Taxpayer Identification Number for provider who treated the member	INTEGER(10)
17	Rendering Provider EIN	The EIN for the provider who treated the member	INTEGER(10)
18	Rendering Provider Taxonomy	The taxonomy code for the provider who treated the member (as opposed to the provider “billing” for the service).	VARCHAR(10)

eq	Professional Data Element	Data Element Description	Format	Expected Values
19	Rendering Provider Specialty	Code that describes the area of specialty for the provider treating the member	VARCHAR	Please provide your specialty code definitions
20	Rendering Provider Practice Address Line 1	US Address line 1 at which provider renders service	VARCHAR(100)
21	Rendering Provider Practice Address Line 2	US Address line 2 at which provider renders service	VARCHAR(50)
22	Rendering Provider Practice City	US City in which provider renders service	VARCHAR(50)
23	Rendering Provider Practice State	US State in which provider renders service	CHAR(2)	State Abbreviation
24	Rendering Provider Practice Zip	USPS Zip Code in which provider renders service	INTEGER(5)
25	Billing Provider Legal Business Name	Official name of billing provider organization or if individual, in format LAST SUFFIX, FIRST MIDDLE	VARCHAR(100)	Example: Smith, John Allan for an individual
26	Billing Provider Doing Business As Name	Name billing provider is known to public by for organizations or if individual, in format LAST SUFFIX, FIRST MIDDLE	VARCHAR(100)
27	Billing Provider TIN	Billing Provider Taxpayer Identification Number	INTEGER(10)

eq	Professional Data Element	Data Element Description	Format	Expected Values
28	Billing Provider Address Line 1	US Address line 1 that represents the entity billing address	VARCHAR(100)
29	Billing Provider Address Line 2	US Address line 2 that represents the entity billing address	VARCHAR(50)
30	Billing Provider City	US City for billing entity	VARCHAR(50)
31	Billing Provider State	US State for billing entity	CHAR(2)	State Abbreviation
32	Billing Provider Zip	USPS Zip Code for billing entity	INTEGER(5)
33	Referring Provider Legal Business Name	Official name of referring provider organization or if individual, in format LAST SUFFIX, FIRST MIDDLE	VARCHAR(100)	Example: Smith, John Allan for an individual
34	Referring Provider Doing Business As Name	Name referring provider provides services under or is known to public by for organizations or if individual, in format LAST SUFFIX, FIRST MIDDLE	VARCHAR(100)	Example: Smith, John Allan for an individual
35	Referring Provider NPI	NPI of Referring provider	INTEGER(10)
36	Referring Provider TIN	Referring Taxpayer Identification Number	INTEGER(10)
37	Referring Provider EIN	The EIN for the provider who referred the member	INTEGER(10)

eq	Professional Data Element	Data Element Description	Format	Expected Values
38	Referring Provider Practice Address Line 1	US Address line 1 at which provider referred service	VARCHAR(100)
39	Referring Provider Practice Address Line 2	US Address line 2 at which provider referred service	VARCHAR(50)
40	Referring Provider Practice City	US City in which provider referred service	VARCHAR(50)
41	Referring Provider Practice State	US State in which provider referred service	CHAR(2)	State Abbreviation
42	Referring Provider Practice Zip	USPS Zip Code in which provider referred service	INTEGER(5)
43	Service/Procedure Code	The code per CPT, HCPCS or NDC used to indicate the service provided during the period covered by this claim.	VARCHAR(11)
44	Service/Procedure Code Modifier	The modifier for the service code on this claim record. Modifier can be used to enhance the Service Code	VARCHAR(2)
45	Modifier (2)	The 2nd modifier for the service code on this claim record. Modifier can be used to enhance the Service Code	VARCHAR(2)
46	Modifier (3)	The 3rd modifier for the service code on this claim record. Modifier can be used to enhance the Service Code	VARCHAR(2)

eq	Professional Data Element	Data Element Description	Format	Expected Values
47	Modifier (4)	The 4th modifier for the service code on this claim record. Modifier can be used to enhance the Service Code	VARCHAR(2)
48	Total Units/Quantity of Service	The number of units of service received by the recipient or units dispensed as shown on the claim record.	DECIMAL (5,2)
49	Diagnosis Code 1	The ICD-9-CM/ ICD-10 code for the primary principal diagnosis for this claim. The principal diagnosis is the condition established after study to be chiefly responsible for the admission.	VARCHAR(8)
50	Diagnosis Code 2	Second ICD-9-CM/ ICD-10-CM code found on the claim.	VARCHAR(8)
51	Diagnosis Code 3	The third ICD-9-CM/ ICD-10 -CM codes that appear on the claim.	VARCHAR(8)
52	Diagnosis Code 4	The fourth ICD-9-CM/ ICD-10-CM codes that appear on the claim.	VARCHAR(8)
53	Diagnosis Type Code	Indicates if diagnosis code is ICD9-CM or ICD-10-CM	VARCHAR(8)	ICD9-CM or ICD10-CM
54	Place of Service	Code indicating where the service was performed	VARCHAR

eq	Professional Data Element	Data Element Description	Format	Expected Values
55	Beginning Date of Service	The first date of services received during an encounter with a provider, the date the service covered by this claim was received.	DATE	MM/DD/YYYY
56	Ending Date of Service	The last date of services received during an encounter with a provider, the date the service covered by this claim was received.	DATE	MM/DD/YYYY
57	Type of Service	A code indicating the type of service being billed. (if available-i.e. Transportation Services; Hospice, PCS etc. represented by a code)	VARCHAR	Please provide code definitions
58	Charged Amount	The total charge for this claim as submitted by the provider.	INTEGER
59	Amount Paid	The amount paid on this claim or adjustment.	INTEGER
60	COB Amount	Coordination of Benefits amounts paid	INTEGER
61	Claim Submission Date	The date on which the claim was submitted for payment	DATE	MM/DD/YYYY
62	Payment Adjudication Date	The date on which the payment status of the claim was paid	DATE	MM/DD/YYYY
63	Adjustment Indicator	Code indicating the type of adjustment record claim represented. (i.e. original claim, void,	VARCHAR	Please provide code definitions
eq	Professional Data Element	Data Element Description	Format	Expected Values
		resubmittal, credit adjustment, debit adjustment, gross adjustment)

Appendix C: Reengineering TTP Input Processes

The CSRA study team is in the process of streamlining and improving the entire study process for the TTP and the partners. The first phase of the reengineering is the input process from the partners: the data elements, the transmission, and the timing of the data that will be used in studies. The premise of our reengineering is to design TTP processes that will produce enhanced results by making participation in studies as easy and productive for the partners as we can. We will minimize the imposition of standards to those that prove necessary, and will accommodate partners who are comfortable with the current approach.

Prior Input Method

During the HFPP prototype phase, the partners submitted data to MITRE for analysis by sending a Comma Separated Value (CSV) file, using a special “pipe” character to separate the fields. Each claim line is sent to the TTP as one long text string. Most partners upload the data in segments to the HFPP Portal or mail encrypted files. Originally, participating entities in a study supplied data with specific Current Procedural Terminology (CPT) codes selected for that study. In July 2015, partners were allowed to respond to a “general data submission call” that contained all CPT codes, and saved the partner the work of a separate data gathering effort for each individual study. The current process does not allow for the collection of Personal Health Information (PHI) nor Personally Identifiable Information (PII) data elements in either the specific or the general requests.

In discussing the process with partners at the April 2016 General Assembly, CSRA identified two problems: first, the pipe-delimited file format is difficult to collect and to properly format as it is not commonly used by other information technology (IT) processes in the Special Investigations Units (SIU). Second, the process is prone to error for specific studies and takes considerable time to get all the data collected and transmitted, delaying the actual start of analysis. The result is a significant lag between the dates of the claims in a study and the current fraud problems facing the SIUs.

New CSRA Capabilities

CSRA, as the TTP production contractor, is using a Cloud environment and resources that will allow us to consider alternatives to the current input method. Rather than load data into a predefined relational database, CSRA will use an approach designed for “big data”: that is, it can analyze data that is stored in many different formats in the same file structure. CSRA has received its ATO from CMS with all of the security controls in place that will allow it to safely store and use PHI and PII data.

With the new security and resources, CSRA plans to expand the MITRE data elements from 32 to 63. New elements include diagnosis codes, beneficiary information, and additional provider information. We are introducing the new data elements with the November 2016 data call, the first data call under the CSRA contract.

Reengineering the Input Process

We are exploring three specific areas of the input process for improvement.

• Allow multiple input methods: we will let partners choose how to assemble and provide the data; we will extract from your fields for analysis.

• Obtain data that are more current: we want to include your recent claims in the studies by receiving data more frequently but on a schedule of each partner’s choosing.

• Bring in additional types of claims for analysis: we will expand to institutional, dental, and other type of claims, and we will let the partners decide which claims types are most important to start with.

We will continue to allow the pipe-delimited format for partners who favor that format, but we anticipate that other file formats may be easier to submit. In particular, we want to take advantage of files, formats, and processes that the partners’ IT departments are using, either with the SIU, other internal components or with third parties. If the file is suitable, we could simply be copied when it is distributed.

If we are receiving one of your files created for other customers or vendors, we recognize that the data elements may not be exactly as those we are looking for. We will work with you, and if some elements are not available, we may be able to take the data without them; however, there will need to be a minimum set for analytic purposes. We will decide on the minimum set after discussions with the partners.

In order to get more current data into our study analytics, we want to obtain the data on your schedule, not ours. If you submit monthly data to a third party, the minor work of bringing data in more frequently is more than offset by having the latest data available.

When we begin a study, we will work with the data that is present and not wait for more data to arrive--that means our results will be much more current and useful for you. We are planning to rerun studies periodically, so data submitted after a study is in progress will simply be picked up in the next iteration of analysis.

Finally, we plan to bring in different types of claims record, e.g., institutional, dental, pharmacy, or durable medical equipment (DME). There was lively interest in all of these at the April 2016 General Assembly. We want the partners to indicate which claims type they believe is most important, particularly for helping us reach the HFPP’s One Billion Dollar goal. We will also explore how the partners want to submit the additional data—some may want to use separate files because of the way their data is stored; others may prefer to submit intermingled claims records.

According to the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of information unless it displays a valid OMB control number. The valid OMB control number for this information collection is 0938-1251. The time required to complete this information collection is estimated to average 120 minutes per response, including the time to review instructions, search existing data resources, gather the data needed, and complete and review the information collection. If you have any comments concerning the accuracy of the time estimate(s) or suggestions for improving this form, please write to: CMS, Attn: PRA Reports Clearance Officer, 7500 Security Boulevard, Baltimore, Maryland 21244-1850.

The following disclaimer applies: Regarding all Healthcare Fraud Prevention Partnership communications and activities, this is a purely voluntary activity. The committees regarding data sharing and analysis; information sharing; and the Executive Board, are to be used solely as discussion groups where the individual members can share facts or information or individual input. No group or consensus advice or recommendations will be given by the partners in the committees or the Executive Board. In addition, no policy-making or decision-making will be performed by the committees or the Executive Board. The Secretary and the Attorney General or their designees will make the final policies or other decisions.

11/23/16 Page 7 of 10 OMB # 0938-1251