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
|