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
adjustment where required.
3.5.2 Apply any TED adjustments loaded to the
DCS.
3.5.3 Coordinate with other contractors
when potential duplicates identified involve multi- contractor claim
sets. Coordination method shall be negotiated between contractors
in the agreed upon communication form.
4.0 Contractor
Performance Requirements
4.1 Contractors shall use the TRICARE
DCS to resolve DHA identified potential duplicate claims payments.
Performance standards are effective the first day of the seventh
month following the start of health care delivery (SHCD).
4.2 Contractors
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
will be measured against the percentage of claim sets in
Open status
at the end of a month with Current Load Dates over 30 days old. No
more than 10% of the potential duplicate claim sets remaining in
Open status
at the end of a month shall have Current Load Dates over 30 days
old. 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 10% standard becomes effective on the first day of
the seventh month following the start of services or following system
installation whichever is later.
4.3 Contractors shall not be responsible
for meeting the performance standard during any month in which availability
of the DCS is prevented for two working days due to failure of any
system component for which the Government is responsible. The Government
is responsible for: DHA servers on which the DCS data resides; Government-supplied
communications lines, if any; Government-supplied routers, if any;
Government-supplied Channel Sending Unit (CSU)/Data Sending Unit
(DSU) equipment that connect the routers to the communication lines,
if any; and the DCS application software.
4.4 All overpayment recovery, refund, offset
collection and adjustment requirements, including timeliness standards,
are applicable to the operation of the DCS.
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
|
|