TRICARE Manuals - Display Chap 4 Sect 1.1 (Change 64, Feb 22, 2023)

TRICARE Duplicate Claims System (DCS) - TRICARE Encounter Data (TED) Version

Chapter 4

Section 1.1

Overview

Revision: C-64, February 22, 2023

1.0 Introduction

1.1 The TRICARE Duplicate Claims System (DCS) automates the resolution of duplicate claim payments. The system facilitates the identification of actual duplicate claims payments, the initiation and tracking of recoupments, and the resolution of duplicate records from the TRICARE Encounter Data (TED) database. The system also generates operational and management reports.

1.2 All data in the DCS is protected by the Privacy Act of 1974 (PL 93-579); Department of Defense (DoD) Health Insurance Portability and Accountability Act (HIPAA) Privacy Regulation; and the HIPAA Privacy Regulation.

1.3 All processes associated with the use of the system and all outputs and results generated by or associated with the system, including claims, encounters, dispositions, recoupments, collections, adjustments, and TEDs, are subject to audit by the Government. The DCS is the property of the United States (U.S.) Government.

Note: The Defense Health Agency (DHA) has a web-based DCS that runs on the Internet/Nonsecure Internet Protocol Router Network (NIPRNET). The web version will be accessed via a web browser (Microsoft® Internet Explorer (MSIE)) in accordance with the Chapter 1, Section 1.1.

2.0 System Functions

2.1 The DCS provides a broad range of user functions to support contractor and DHA activities and to ensure system integrity.

2.2 Additional System Functions

A number of other tasks and data handling procedures facilitate duplicate claims resolution and maintenance of system integrity. These tasks and data handling procedures include:

2.2.1 Verifying user authorization through the use of the Common Access Cards (CACs);

2.2.2 Displaying to each contractor only those potential duplicate claim sets associated with that contractor;

2.2.3 Displaying TED adjustments associated with duplicate institutional claims or duplicate non-institutional line items;

2.2.4 Providing capabilities to track user activities;

2.2.5 Providing system maintenance and data administration capabilities, e.g., automated support for reassigning claim sets upon contractor transitions;

2.2.6 Determining ownership of sets involving potential duplicate claims paid by two different contractors (i.e., multi-contractor sets);

Note: Although the owner designated by the system is the contractor who paid the latest claim, ownership can be switched to other contractors involved;

2.2.7 Highlighting claims that appear as potential duplicates in other sets;

2.2.8 Appending new TED claims to existing sets; and

2.2.9 Temporarily disabling sets involving provisionally accepted TEDs.

3.0 CONTRACTOR RESPONSIBILITIES

As specified in all Purchased Care contracts, contractors are responsible for both preventing and resolving duplicate claim payments. The DCS supports contractors in this responsibility by automating the resolution process. The automated process defines the rules under which the resolution of claim sets can be completed, provides users with screens to enter the results of duplicate payment research, and maintains the necessary interfaces with the TED database to ensure and verify correction of duplicate conditions.

3.1 For each regional contract for which a contractor is responsible, or for the TRICARE Dual Eligible Fiscal Intermediary Contract (TDEFIC), the contractor shall develop internal operating procedures for the DCS. These internal operating procedures shall designate the responsible areas for the various duplicate claims resolution functions and establish time lines. For example, one contractor may decide that the adjustment unit shall be responsible for scanning the DCS on a weekly basis for the appearance of adjustments submitted and for closing sets. Another contractor may decide that the unit responsible for researching potential duplicate claims should also be responsible for scanning for adjustments and closing the sets on a daily basis.

3.1.1 Contractor contract requirements for overpayment recovery, refunds and offsets, adjustments, etc., including timeliness requirements, apply to the operation of the DCS. As a result, operating procedures must be developed which are consistent with all applicable contract requirements. Procedures must be established to ensure that recoupments are initiated in a timely manner following the research determination that a duplicate payment had been made. In other words, procedures must specify that after a decision has been made by the person responsible for determining that a duplicate payment was made, recoupment must be initiated in a timely manner and must be consistent with all overpayment recovery timeliness standards.

3.1.2 Contractors shall develop these procedures within 60 days of the date of system implementation and have them available for DHA review.

3.2 Determine if a claim (or line item) does or does not represent an actual duplicate payment.

3.3 Identify and determine the reason code(s) for each claim identified as a potential duplicate, and enter a narrative description when prompted to explain why a claim does or does not represent an actual duplicate payment.

3.4 Identify the dollar amount identified for recoupment for each actual duplicate claim.

3.5 Identify the dollar amount actually received from the recoupment/offset action of each duplicate claim.

3.5.1 Submit the TED record(s) adjustment where required.

3.5.2 Apply any TED record(s) adjustments loaded to the DCS.

3.5.3 Coordinate with another contractor when potential duplicates identified involve multi-contractor claim sets. Use coordination method negotiated in the agreed upon communication form.

4.0 Contractor Performance Requirements

Each contractor shall move Open status potential duplicate claim sets to Pending, Validate, or Closed status on a first-in/first-out basis. To this end, contractor performance is measured by the percentage of claim sets in Open status moved with respect to the total inventory set count for the month. Specifically, contractors shall move at least 90% of sets in the monthly inventory from Open status by the end of a month. The monthly load will be run no later than the 10th day of the month. Contractors will have access to the sets from the monthly load the day following verification by the Government Designated Authority (GDA). The contractor compliance with this standard shall be determined from the Performance Standard Report generated by the DCS (see Addendum B, Summary Management Report titled “Performance Standards”, for a description and example of the Performance Standard Report). The standard becomes effective on the first day of the seventh month following the start of services or following system installation whichever is later.

5.0 Jurisdiction

5.1 Multi-Contractor Sets

5.1.1 Multi-contractor sets occur when two different contractors pay for the same billed service. In a multi-contractor set, only one contractor should have processed and paid the claim if the claim was in their jurisdiction.

5.1.2 Resolution of multi-contractor claim sets requires close coordination between the contractors involved to ensure that research efforts and resolution activities are conducted efficiently, appropriately, and in a timely manner. When researching a multi-contractor set, the contractor with jurisdiction must coordinate with the other contractor(s) involved to determine who is responsible for the duplicate payment(s) and for recouping the overpayment(s). The method of coordination must be negotiated between contractors and may take whatever form is agreeable, i.e., by telephone, fax, e-mail, or combination thereof. This coordination is a courtesy among contractors and should prevent indiscriminate transfers of sets back and forth. Multi-contractor sets shall not be resolved without communication and coordination among the involved contractors.

5.2 Determining Jurisdiction For Claim Sets

Duplicate claim sets assign jurisdiction in accordance with the TRICARE Operations Manual (TOM), Chapter 8.

6.0 Definition Of A Duplicate Claim Payment

6.1 A duplicate claim or encounter is a payment made for services for which reimbursement has already been made on one or more previous claims or encounters. In other words, two or more payments were made for the same service for the same beneficiary.

6.2 For the purposes of the DCS, when two or more payments are issued for the same service for the same beneficiary, the additional payments are considered actual duplicate payments, regardless of whether the additional payments were justified or made in error, recoupment of the additional payments initiated, or refunds already received.

6.3 The criterion to use in determining if a claim represents an actual duplicate payment is an affirmative answer to the following question:

Have any or all of the services paid on this claim been paid on a previous claim/encounter?

6.4 It must be noted that “claims” displayed in the DCS are in fact TED records the contractors submitted. The Government assumes that the TED records submitted by contractors accurately reflect the adjudication of the claims and the dollars paid. When a user works in the DCS, they are seeing records that reside on the TED database. They are seeing what appears to the Government to be duplicate payments. Users might think of TED records as entries in the Government’s checkbook. When a pair of TED records are displayed in the DCS, they are, in essence, representing two entries in the Government’s checkbook. If these entries are not cancelled or adjusted, they represent actual dollars spent. For the purposes of the DCS, an unadjusted or non-cancelled TED record on the TED database represents a claims payment even if the claim appears on the contractor’s claims processing system as having been adjusted or cancelled. All duplicate TED records displayed in the DCS must be flagged as actual duplicates, and must be corrected through adjustments and cancellations to remove the duplicate conditions from the TED database.

6.5 TED Dupes

6.5.1 The DCS identifies two kinds of duplicate TEDs:

• Those that represent actual overpayments (where two or more payments were actually made and recoupments must be initiated to recover the erroneous payments); and

• Those that were submitted but no actual payments were made (and therefore no recoupment actions need to be initiated).

6.5.2 It is this second kind of duplicate TED that we refer to as a “TED Dupe”. TED Dupes most often occur when claims are processed but for some reason are pulled before the checks are actually sent and then re-processed under different claim numbers. If the original claims processed to the point that TEDs were created, submitted, and accepted by DHA, and not subsequently cancelled, the TEDs representing the reprocessed claims (with different claim numbers) will “dupe out” with the original, uncancelled, TEDs residing on the TED database. In this instance, the Government is not able to determine if payments have been made.

6.6 System Objectives

6.6.1 The system was designed to meet the following objectives:

• To create a user-friendly, cost-effective application using web-based technology;

• To preserve TED data integrity and display only those potential duplicate claims records applicable to each contractor;

• To provide as much data as possible to assist contractors in their efforts to identify actual duplicate payments;

• To improve the detection of actual duplicate claims payments through the use of match criteria that have been found to be successful in identifying duplicate claim payments;

• To automate methods for grouping and displaying institutional and non-institutional potential duplicate TEDs to contractors for research and resolution;

• To automate and simplify methods for contractors to report their determinations as to whether the identified potential duplicate TEDs represent actual duplicate payments and, if they do, to report the corresponding amounts expected to be recouped;

• To automate and simplify methods for contractors to report actual recoupment amounts and provide a mechanism for verifying that TED adjustments/cancellations were submitted and accepted, thereby correcting the duplicate condition in the TED database;

• To automate methods to facilitate DHA and contractor audits and performance monitoring; and

• To provide the capability to generate user defined reports and graphs.

6.6.2 In meeting these objectives, the system provides the tools to monitor timely contractor research and accurate identification of actual duplicate payments and aids in diagnosing processing problems that cause duplicate payments.

7.0 Functional Capabilities Of The DCS

7.1 The DCS is an on-line, real-time, user-friendly system. The DCS employs five different TED-based, duplicate detection match criteria to identify potential duplicate claims. It also accommodates contractor transitions, financially underwritten/non-financially underwritten claims, and duplicate claims payments caused by jurisdictional processing errors. The DCS improves DHA and contractor accountability of actual duplicate payments through the tracking of the amounts identified for recoupment, amounts actually received in refunds or offsets, and TED adjustments or cancellations submitted on receipt of the refunded or offset overpayments. The functional capabilities of the DCS supports the claims resolution process.

7.2 User defined, pre-formatted reports are included in the DCS to help analyze trends, contractor performance, and processing or procedural problems in contractor operations.

7.3 Extracting TED Data To Create And Maintain The Duplicate Claims Databases

Using the duplicate claims detection criteria, the DCS identifies potential duplicate claims from TEDs residing in the TED database. Copies of these claims are extracted from the TED database. At the same time, data elements and values required for system operation are added and the data is loaded to tables on a DHA Database 2 (DB2) Server. These tables comprise the Duplicate Claims Databases. TED data and DCS data residing in the Duplicate Claims databases are accessible to users through the DCS application. See Section 1.2, paragraph 1.0 for details on the building of the Duplicate Claims databases.

8.0 System Design

The DCS is a web-based application that interfaces with a transaction-based “server” environment that processes transactions, maintains databases, and optimizes the access and transfer of data between the two environments.

8.1 Communications

The DCS uses two system platforms as shown in Figure 4.1.1-1 that operate independently. Data is transmitted from one platform to another through interfaces and a communications network. Users connect to this network and the DCS via contractor-supplied web communications.

Figure 4.1.1-1 System Platforms

- END -

DHA Address: 7700 Arlington Boulevard | Suite 5101 | Falls Church, VA | 22042-5101

Some documents are presented in Portable Document Format (PDF). A PDF reader is required for viewing. Download a PDF Reader or learn more about PDFs.