CHS DATA BUSINESS PROCESSES

Getting Started

Multiple PCC Visits for a Single EOC versus CHS FI Record "Bundle"

FI: Linking Multiple Encounters to a Single Encounter

FI Criteria for Encounters Sent to the IHS National Data Depositories

Are Undated Encounters Sent to the National Data Depository?

CHS638 Dental Records Sent without ADA Information

Different Data Element: PCC, CHS FI, and SHS 638 Exports, and the Process for Sending Modified Encounter Data

Getting Started

Section Three documents the business practices of the contract health system. Understanding of the meaning and use of all data elements in the three exports will yield clear business rules and more consistent reporting practices for all staff.

Multiple PCC Visits for a Single EOC versus CHS FI Record "Bundle"

CHS FI does not actually bundle records, but it does do something called "rolling up" of claim records. The rolling up of claims is performed only on inpatient claims for a single provider. For example, if a provider submitted a claim of 52 lines, with each line representing a service provided, the FI will roll up the claim for NPIRS. When NPIRS receives the information from the FI, it will receive only one line (i.e. record) from the claim and that one record will have the total cost for all 52 claim lines on the claim. However, if a patient had services provided by multiple providers, the FI does not roll up multiple claims from multiple providers into a single claim (see Appendix 3-A for an example of a rolled up claim sent to NPIRS).

Appendix 3-A [DOC-882KB]

While the CHS FI does not bundle records, some agencies do bundle records. An example of bundling is when a patient is anesthetized: whereas IHS sends separate CPT codes for the actual drug used to anesthetize the patient, the administering of the drug, and for the anesthetist's time spent monitoring the patient, other agencies might bundle all of these into a single CPT code

Another scenario that gives the appearance of bundling records is when the CHS FI sends a single record and PCC sends multiple records. Most often, the CHS FI has in its IHSCPS application the same records as those sent by PCC. However, the CHS FI's export programs include logic that filter or may exclude records from being sent to the data repository (i.e. NPIRS). PCC does not include this logic, so PCC potentially sends more records than the FI. In Example A (page 3-2), NPIRS received three records from PCC and one record from the CHS FI, whereas PCC sent three separate records because there were three separate claims from three separate providers. The CHS FI determined NPIRS had not receive the first two records from the CHS FI because they both had a Type of Service of 5 (Diagnostic Lab); the allowable values for CHS outpatient encounters are 1 (Medical Care), 2 (Surgery), or 3 (Consultation). The record the CHS FI sent to NPIRS (Example A, fourth record), had a Type of Service of 2 and 3, which are allowable values.

PCC may also send multiple records when a patient's encounter with a single provider had multiple procedures, as represented by CPT codes. The CHS FI will create one record for each procedure paid, versus the procedure for processing an encounter with multiple diagnoses, in which the diagnoses are sent with a single record. We may want to request to have the CHS FI to:

• begin sending the CPT codes, and
• send multiple procedures with a single encounter record.

Example A:¹

Throughout this document all patient identifiers (i.e. chart numbers, Social Security numbers, etc.) have been changed to protect patient identities.

In Example B, NPIRS did not receive the first two records from the CHS FI because the first one had a Type of Service of 5 and the second had a value of 7. The record the CHS FI sent to NPIRS had a Type of Service of 2, an allowable value.

Example B:

FI: Linking Multiple Encounters to a Single Encounter

Is there a single data element that can be used to link encounters, such as claim number or authorization number? According to CHS FI experts, there is no single data element, such as claim number or authorization number, that can be used to link all encounters related to an episode of care.

Authorization numbers, which are the purchase order numbers, may be duplicated if a facility is using blanket purchase orders, meaning the same authorization number could be used for multiple patients. Claim numbers may be duplicated if a provider sends a claim for multiple encounters, meaning encounters that occurred on the same or different dates for a single patient. However, according to the CHS FI, there should not be duplicate claim numbers for different patients.

FI Criteria for Encounters Sent to the IHS National Data Depositories

CHS Outpatient and CHS Inpatient Filters

A CHS Data Quality Work Group sub-committee reviewed two documents produced by the CHS FI describing the logic used for determining if records are to be sent to NPIRS.* The documents reviewed:

• Medical Statistical Record Filters and Other Considerations from IHS/CHS FI, dated 01/12/01, and
• Statistical Record Documentation, dated 02/16/01.

The following is a brief description of the logic the CHS FI is using for determining if an encounter should be sent to NPIRS.² The logic provided is based on the information discussed in sub-committee conference calls. However, there is additional logic that needs to be reviewed and researched, including logic from both CHS FI documents named above. Therefore the information contained in this section is subject to change. Many messages have been sent to the FI (Rhonda Nichols) regarding this subject. Nichols had previously provided to the referenced sub-committee information on the CHS FI filters. She later sent (Nov 2003) additional information, which conflicted with the information previously provided to the subcommittee. Sklepacki sent her a message dated 111403 with a subject of "Additional FI Filters on the Data" that included an attachment posing questions about the differences. As of 013004, no response has been received. IHS needs to decide if the logic needs to be replaced with the most recent logic Rhonda provided.

Filter 1

For a claim line with multiple adjustments, the logic looks at the last adjustment level only. Adjustments are normally made if payment was made to the wrong provider or if the incorrect amount was paid. Adjustments are always for financial reasons, not for medical adjustments, such as a change to a diagnosis code.

The CHS FI uses terminology such as "Line 1 Level 0" to represent a claim line with zero adjustments. Line 1 Level 2 represents a claim with two adjustments. The CHS FI could have sent a Line 1 Level 0 record to the national data repository and the FI would send it again if an adjustment was made as Line 1 Level 1.

Filter 2

Excludes the patient address information that is on the claim from being sent to NPIRS.

Filter 3

Excludes all rejected claims from being sent to NPIRS except for reject codes R192 and R193.

The R192 reject code represents hospital facility charges that have been paid on a separate claim. For example, if a patient was hospitalized for five days, was subsequently transferred to a rehabilitation facility, and then had to be readmitted to the hospital for the same problem, there may be a maximum amount the FI can pay for the hospital stay, so the claim for the second stay is rejected since the maximum charges were paid on a separate claim. However, these records are still sent to NPIRS so NPIRS will have the additional medical data for the second stay.

The R193 reject code represents an adjustment to a claim with an R192 reject code.

There are two types of rejected claims: final and interim.

• An example of a final reject is if the FI received a purchase order with a date of service of June 1-5 and then the FI received a claim from the provider with a date of service of June 1-10. The FI would pay only for the June 1-5 date of service and would reject the date of service of June 6-10. A final reject closes the purchase order.
• The second type of rejected claim is an interim reject, which leaves the purchase order open.

Filter 4

An obsolete filter having no impact on the records sent to NPIRS.

Filter 5

Inpatient Records: The discharge date is used to determine when an inpatient record should be sent to NPIRS. For example, if an inpatient stay occurred from May 1, 2002 to October 10, 2003, the record would be sent to NPIRS in the FI exports for fiscal year 2003, not 2002.

Outpatient Records: The date of service is used to determine when an outpatient record should be sent to NPIRS. Occasionally, the FI receives a claim for encounters other than the current or prior fiscal year. For example, the FI receives a claim requesting payment for two encounters during year 2003: one from 2001 and the other in 2003. NPIRS will not receive the 2001 encounter, but will receive the 2003 encounter since the FI only exports data for the current and prior fiscal year, depending on the quarter in which the record is exported. For additional information, refer to page five of the Statistical Record Documentation included in Appendix 3-B.

Appendix 3-B [DOC-62KB]

The files sent to NPIRS are cumulative files, meaning the same record may be sent in multiple exports, even if the record has not been changed since the last export. The CHS Workgroup may want to request a change for the CHS FI to send only new or modified encounters with each export in order to reduce the amount of processing time needed to process duplicate records.

Filter 6

Inpatient Records: Inpatient records are filtered based on their values for certain data elements:

• Value for Object Class Code (OCC), the Table Code value is retrieved from the Object Class Code table. The Table Code value must be equal to "II" (Institutional Inpatient), and
• The Purchase Order type must be equal to "43" (Institutional Inpatient), and
• The Provider Type must be equal to "01, 02, 03, or 04", and
• The Nature of Coverage (NOC) must be equal to "B" (Inpatient).

Outpatient Records: Outpatient records are filtered based on their values for certain data elements, as shown below.

Based on the value for Object Class Code, the Table Code value is retrieved from the Object Class Code table. The first letter of the Table Code value must not be equal to "D" (Dental) AND the second letter of the Table Code value must not be equal to "I" (Institutional). The possible acceptable combinations are: "IO, IE, PV, PO" or any Table Code value that has a single-letter value of "I." Some examples of OCCs that have single-letter Table Code values are: 263L (Hearing Aids), 252H (X-ray Service Outpatient Non-IHS), and 254A (Physician Inpatient IHS Facility).

• The Purchase Order type must be equal to "64" (Professional),and
• The Nature of Coverage (NOC) must be equal to "A, C, E, or F"
  • A=Professional Fees,
  • C=Outpatient,
  • E=Ancillary,
  • F=Non-specific Patient Information.

An outpatient record not meeting the conditions above, must meet the conditions below or it is not sent to NPIRS.

• Based on the value for OCC, the Table Code value is retrieved from the Object Class Code table. The Table Code value must be equal to "PI" (Professional Institutional), and
• The Purchase Order type must be equal to "64" (Professional), and
• The NOC must be equal to "A, C, E, or F"
  • A=Professional Fees,
  • C=Outpatient,
  • E=Ancillary,
  • F=Non-specific Patient Information.

Filter 7

Outpatient Records: Do not send the record to NPIRS if the Place of Treatment value is "1" (Inpatient Facility). As of June 26, 2003, awaiting written notification from Rhonda Nichols regarding the following items to see if they are being used as additional filters for the records that are sent to NPIRS:

• Type of Service
• CPT Codes
• Newborn Diagnosis Codes
• Whether or not Filter 7 should include logic for requiring inpatient records to have a place of treatment equal to 1 (inpatient facility).

In addition, Rhonda Nichols is going to provide clarification and/or new information on the following items:

• A full list of values and their definitions for Nature of Coverage and Type of Service.
• A definition of a face-to-face encounter and how it is being used for counting visits.
• If all Cause of Injury values are being converted to "9999."

CHS Dental Filters

Dental records are not filtered.

Are Updated Encounters Sent to the National Data Repositories?

CHS FI Encounters

Normally the only changes made to CHS FI encounters are financial adjustments, such as a paid amount, initially sent incorrectly, then corrected when the record is sent again to NPIRS.

CHS638 Encounters

Any changes made to a record after the final payment has been made and the record has been exported to NPIRS do not automatically result in the record being flagged for re-export to NPIRS. A clerk must make the changes to the record in the CHS/MIS application, and then manually flag it for re-export by selecting the final payment transaction.

PCC Encounters

The current version of PCC does not automatically flag a record for re-export to NPIRS if any changes are made subsequent to the last export to NPIRS. A clerk must manually flag the record for re-export-however, this will be changed in PCC Patch 6 and the new data warehouse (DW1) exports, in which updated CHS records would be flagged automatically for re-export.³ Per Lori Butcher of Cimarron Informatics DENRUN Encounters

DENRUN data is in the process of being evaluated and may be discontinued as comparable information is captured by the FI export, CHS638, and PCC export.

CHS638 Dental Records Sent without ADA Information

In the pilot data warehouse (PDW) project, it was noted some CHS dental records were sent without ADA (American Dental Association) codes. These records were sent in the CHS638 export files from tribally operated facilities. In Example C below, the PDW received what appears to be the same record twice, with both records having null values for the ADA codes and a dental cost of $0.00.

Example C:

The two visits⁴ in Example C represent a partial payment for services and an office visit where a treatment plan is developed and sent back for approval and no other service is provided at the visit.
Per Judy Cranford at the PITU Tribe

The visits were posted with an ICD diagnosis of V72.2 (Dental Examination) with a CPT code of D9430 (Dental Office Visit for Observation). PDW did not receive ADA code values because the facility posts by CPT codes. When the export does the conversion from CPT to ADA, it did not find the matching ADA code because of the "D" in the CPT code value of D9430 (the corresponding ADA code is 9430).

In the case of receiving the same encounter twice, one reason may be that the Tribe thought the export did not make it to NPIRS the first time and re-exported the file a second time. The facility is also posting ICD9 and CPT codes for dental visits, but no ADA codes-a practice that poses a significant problem because ICD9 and CPT codes currently are not sent to NPIRS in the CHS638 dental files. Further research found the exact place in the program where the problem occurs. When users want to enter an ADA code, the CHS user help instructs them to enter "ADA" followed by a period, followed by an ADA code. However, when a code such as "2150" is entered, the program should look for this code directly in the ADA file-but that is not happening. Instead, all possible matches in the CPT file are listed first, until it finally displays the ADA code match. If, instead of entering the ADA code, users enter a textual description such as "AMALGAM," the program looks up values in the CPT file first instead of the ADA file, most likely resulting in a match to a CPT code instead of an ADA code. The CHS/MIS application can store a legitimate CPT code or an ADA code but, when the CHS638 export to NPIRS is created, the data conversion looks for an ADA code. If the ADA code is not present, other visit information is nevertheless sent, resulting in records being sent without ADA information.

The CHS Data Quality Work Group needs to decide if NPIRS is only going to accept ADA codes on the CHS638 exports and not the CPT codes. However, even if it were to accept the CPT codes, this would require a change to the CHS638 export programs, as this information is not currently sent in the export.

To attempt to assess the extent of the problem, the NPIRS database (Dental Table) was queried for all CHS638 records with a date of service occurring between January 1, 2002 and May 13, 2003. The data was compared with the number of records sent with null or blank values for the first ADA code. As shown in Appendix 3-C, some of these facilities sent all or nearly all of their records with null or blank values for the first ADA code during this time period.

Appendix 3-C [XLS-56KB]

Two facility examples include:

• 757610 (YAKAMA TRIBAL PROGRAMS), which had 1,344 out of 1,364 (99%) records with null or blank values for all fifteen ADA codes, and
• 662710 (ROUND VALLEY), which had all 471 (100%) records with null or blank values for all fifteen ADA codes.

Not all of the facilities had the majority of their records sent without ADA codes, such as facility 758653 (COQUILLE TRIBAL HEALTH), which had only eight out of 316 records (3%) sent without ADA codes.

The issue was discussed at the May 13, 2003 CHS Data Quality Work Group conference call with respect to its potential impact on dental workload reporting. Paul Golis is going to determine if CHS dental records sent without ADA codes are excluded from certain dental workload reports and will report his findings to the CHS Workgroup members.

In the Examples D and E below, the PDW received a record from a CHS638 export and the same record from the DENRUN export. Once again, the CHS638 record contains no ADA information and $0.00 dental cost. However, the DENRUN record does contain ADA and cost information. Further investigation is needed to determine why the CHS638 visits are sent without any ADA codes.

Example D:

Example E:

Different Data Elements: PCC, CHS FI, and CHS638 Exports, and the Process for Sending Modified Encounter Data

Included in Appendix 3-C is a spreadsheet that compares the data elements sent in the PCC, CHS FI, CHS638 exports, and DENRUN export. Also depicted are the differences in the formatting of data elements sent by the exports. For example, CHS inpatient visits, the CHS FI, and CHS638 exports send the Cause of Injury ICD9 value without the "E" and the decimal (e.g. 9999), whereas PCC sends the value with the "E" and the decimal (e.g. E999.9). These differences require special extraction, transformation, and loading (ETL) logic when loading the data into a database that has standardized its values for a particular data element.

Appendix 3-C [XLS-56KB]

It should be noted that the CHS FI is in the process of implementing and testing changes to its exports to NPIRS, as requested by the CHS Project Officer and the Office of Program Statistics (see Appendix 3-D for project details). Implementation of these changes may reduce the differences between the data elements sent in the different exports (see Section Six).

Appendix 3-D [DOC-247KB]