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
Medicare Eligible
Program (
TMEP),
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
4.1 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.
4.2 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.3 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
|
|