U.S. patent application number 13/720425 was filed with the patent office on 2013-05-02 for healthcare claim and remittance processing system and associated method.
This patent application is currently assigned to Optuminsight, Inc.. The applicant listed for this patent is OptumInsight, Inc.. Invention is credited to Darby W. Brown, James M. Sohr, Steven J. Yorjevich.
Application Number | 20130110539 13/720425 |
Document ID | / |
Family ID | 37805474 |
Filed Date | 2013-05-02 |
United States Patent
Application |
20130110539 |
Kind Code |
A1 |
Sohr; James M. ; et
al. |
May 2, 2013 |
HEALTHCARE CLAIM AND REMITTANCE PROCESSING SYSTEM AND ASSOCIATED
METHOD
Abstract
A system for processing healthcare claims and remittances
comprises a database and an electronic portal. The database
contains previously received healthcare claims from a plurality of
healthcare providers and previously received remittances from a
plurality of payers. The electronic portal, connected to the
database, receives a healthcare claim from a provider or a
remittance from a payer, and splits the received claim or
remittance into a plurality of data elements. The portal assigns a
unique identifier and a shared identifier to each of the data
elements of the received claim or remittance. The portal performs a
duplicate claim edit and/or a third party liability edit on the
received claim, or performs a duplicate remittance edit an/or a
third party payment edit on the received remittance. Based on the
result of the edits, the portal submits the received claim to a
payer or submits the received remittance to a provider.
Inventors: |
Sohr; James M.; (Nashville,
TN) ; Brown; Darby W.; (Belle Mende, TN) ;
Yorjevich; Steven J.; (Franklin, TN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
OptumInsight, Inc.; |
Eden Prairie |
MN |
US |
|
|
Assignee: |
Optuminsight, Inc.
Eden Prairie
MN
|
Family ID: |
37805474 |
Appl. No.: |
13/720425 |
Filed: |
December 19, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11511658 |
Aug 29, 2006 |
8364498 |
|
|
13720425 |
|
|
|
|
60712042 |
Aug 29, 2005 |
|
|
|
Current U.S.
Class: |
705/2 |
Current CPC
Class: |
G06Q 10/10 20130101;
G06Q 40/08 20130101 |
Class at
Publication: |
705/2 |
International
Class: |
G06F 19/00 20060101
G06F019/00 |
Claims
1. A system for processing healthcare claims and remittances, the
system comprising: a database containing previously received
healthcare claims from a plurality of healthcare providers and
previously received remittances from a plurality of payers; and an
electronic portal connected to the database, the electronic portal
configured to receive a batch of healthcare claims from a
healthcare provider and to split each received claim of the batch
of healthcare claims into a plurality of data elements, the data
elements comprising at least a patient identifier, a healthcare
provider identifier, a date of service, and an amount payable; the
electronic portal further configured to determine if any necessary
data is missing from the received claim and to send a missing data
request to the healthcare provider; the electronic portal further
configured to perform a batch of duplicate claim edits and a batch
of third party liability edits on the batch of received claims,
wherein the third party liability edit comprises determining if one
or more third party payers is responsible for paying at least a
portion of the amount payable associated with the received claim,
and wherein determining if the one or more third party payers is
responsible for paying comprises at least one of (a) comparing an
insurance carrier listed on the received claim to a stored list of
insurance carriers that exclusively function as third party payers,
and (b) searching the database for previously received healthcare
claims corresponding to the same patient identifier as the received
claim, and determining if any such previously received claims are
associated with a third party payer; and the electronic portal
further configured to, based on the result of the duplicate claim
edit or the third party liability edit, submit the received claim
to a payer.
2. The system of claim 1, wherein the electronic portal is further
configured to assign one or more error codes to the received
claim.
3. The system of claim 1, wherein the third party liability edit
further comprises determining if a third party liability indicator
exists on the received claim.
4. The system of claim 1, wherein the third party liability edit
further comprises querying other previously received claims with
the same patient demographic information that are stored in the
database to determine if prior claims corresponding to the same
patient identifier as the received claim involved third party
liability.
5. The system of claim 1, wherein the third party liability edit
further comprises analyzing a diagnosis code included in the
received claim in search of indications of third party
liability.
6. The system of claim 1, wherein the third party liability edit
further comprises comparing the insurance carrier listed on the
received claim against a database of insurance carriers who only
handle third party liability claims.
7. The system of claim 1, wherein the third party liability edit
further comprises using standard patient eligibility inquiry and
response transaction sets.
8. The system of claim 1, wherein the electronic portal is further
configured to receive a batch of healthcare claims from one or more
healthcare providers.
9. A method for processing healthcare claims and remittances, the
method comprising: providing a database, stored in a memory device,
of previously received healthcare claims from a plurality of
healthcare providers and previously received remittances from a
plurality of payers; receiving a batch of healthcare claims from a
healthcare provider; splitting each received claim of the batch of
received claims into a plurality of data elements, the data
elements comprising at least a patient identifier, a healthcare
provider identifier, a date of service, and an amount payable;
determining if any necessary data is missing from the received
claim and sending a missing data request to the healthcare
provider; performing a batch of duplicate claim edits and a batch
of third party liability edits on the received claim with a
computer processing unit, wherein the third party liability edit
comprises determining if one or more third party payers is
responsible for paying at least a portion of the amount payable
associated with the received claim, and wherein determining if the
one or more third party payers is responsible for paying comprises
at least one of (a) comparing an insurance carrier listed on the
received claim to a stored list of insurance carriers that
exclusively function as third party payers; and (b) searching the
database for previously received healthcare claims corresponding to
the same patient identifier as the received claim, and determining
if any such previously received claims are associated with a third
party payer; and based on the result of the duplicate claim edit or
the third party liability edit, submitting the received claim to a
payer.
10. The method of claim 9, further comprising receiving a batch of
healthcare claims from one or more healthcare providers.
11. The method of claim 9, further comprising assigning one or more
error codes to the received claim.
12. The method of claim 9, further comprising determining if a
third party liability indicator exists on the received claim.
13. The method of claim 9, further comprising querying other
previously received claims with the same patient demographic
information that are stored in the database to determine if prior
claims corresponding to the same patient identifier as the received
claim involved third party liability.
14. The method of claim 9, further comprising analyzing a diagnosis
code included in the received claim in search of indications of
third party liability.
15. The method of claim 9, further comprising comparing the
insurance carrier listed on the received claim against a database
of insurance carriers who only handle third party liability
claims.
16. The method of claim 9, further comprising using standard
patient eligibility inquiry and response transaction sets.
17. A computer program product for processing healthcare claims and
remittances, the computer program product comprising at least one
computer-readable storage medium having computer-readable program
code portions stored therein, the computer-readable program code
portions comprising: an executable portion capable of providing a
database of previously received healthcare claims from a plurality
of healthcare providers and previously received remittances from a
plurality of payers; an executable portion capable of receiving a
batch of healthcare claims from a healthcare provider; an
executable portion capable of splitting each received claim of the
batch of received claims into a plurality of data elements, the
data elements comprising at least a patient identifier, a
healthcare provider identifier, a date of service, and an amount
payable; an executable portion capable of performing a batch of
duplicate claim edits and a batch of third party liability edits on
the received claim, wherein the third party liability edit
comprises determining if one or more third party payers is
responsible for paying at least a portion of the amount payable
associated with the received claim, and wherein determining if the
one or more third party payers is responsible for paying comprises
at least one of (a) comparing an insurance carrier listed on the
received claim to a stored list of insurance carriers that
exclusively function as third party payers; and (b) searching the
database for previously received healthcare claims corresponding to
the same patient identifier as the received claim, and determining
if any such previously received claims are associated with a third
party payer; and an executable portion capable of, based on the
result of the duplicate claim edit or the third party liability
edit, submitting the received claim to a payer an executable
portion capable of determining if any necessary data is missing
from the received claim; and an executable portion capable of
sending a missing data request to the healthcare provider.
18. The computer program product of claim 17, further comprising an
executable portion capable of receiving a batch of healthcare
claims from one or more healthcare providers.
19. The computer program product of claim 17, further comprising an
executable portion capable of assigning one or more error codes to
the received claim.
20. The computer program product of claim 17, further comprising an
executable portion capable of determining if a third party
liability indicator exists on the received claim.
21. The computer program product of claim 17, further comprising an
executable portion capable of querying other previously received
claims with the same patient demographic information that are
stored in the database to determine if prior claims corresponding
to the same patient identifier as the received claim involved third
party liability.
22. The computer program product of claim 17, further comprising an
executable portion capable of analyzing a diagnosis code included
in the received claim in search of indications of third party
liability.
23. The computer program product of claim 17, further comprising an
executable portion capable of comparing the insurance carrier
listed on the received claim against a database of insurance
carriers who only handle third party liability claims.
24. The computer program product of claim 17, further comprising an
executable portion capable of using standard patient eligibility
inquiry and response transaction sets.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional
Application No. 60/712,042, filed Aug. 29, 2005, the contents of
which are incorporated herein in its entirety.
FIELD OF THE INVENTION
[0002] Embodiments of the invention relate generally to a
healthcare claims processing system. More specifically, embodiments
of the invention relate to a healthcare claims processing system
capable of identifying duplicate claims and remittances and third
party liability claims and remittances.
BACKGROUND OF THE INVENTION
[0003] It can be appreciated that automated clearinghouses (i.e.,
an establishment maintained by a third party with the purpose of
settling mutual claims and accounts; a central agency for the
transmission and distribution of claims information) have been in
use for some period of time, especially for the submission and
payment of healthcare claims (i.e., requests for payment for
healthcare services provided to a patient; commonly referred to as
"bills"). Healthcare claim submission and payment is a process that
many have attempted to refine by using some form of claims
management software. Specifically, software has previously been
offered that can receive claim information from a healthcare
provider (e.g., a physician, hospital, or medical laboratory),
break the data elements into a standard set, give each claim a
unique identifier, submit the claim information to a payer
(typically an insurance carrier or a government agency), accept
payment (also termed a remittance; a remittance, as is applicable
to healthcare, is the payment and explanation of that payment
produced by a payer and sent to a provider and comprising the
adjudication and payment information) for the claim from the payer,
and administer that payment back to the provider, all with limited
or even no human interaction.
[0004] One common problem with known methods for claims submission
occurs when a healthcare provider submits a claim to a payer and
does not receive payment of that claim in a timely fashion. The
provider, after a period of time, may send out another bill, or
"second notice" claim, to the payer. The payer, not realizing that
both claims are for the same service, often eventually pays both
claims in error, resulting in a duplicate payment to the provider.
This problem occurs because both parties (payer and provider) are
operating through many disparate systems and do not have access to
a transparent set of data. This problem also occurs because the
clearinghouse acts merely as a pass-through between the payer and
provider, meaning that the clearinghouse only passes information
back and forth, and generally does not store claim or remittance
information for any significant period of time. Further, these
problems also occur because the known methods of claims submission
generally include intensive human interaction, providing many
opportunities for errors to occur. These problems may also occur
due to various computer system (typically software) and/or human
errors that cause the same bill to be generated and submitted
multiple times in error, in conjunction with both the initial
billing and subsequent billings. The administrative cost incurred
by both parties to resolve these duplicate claims is significant
and raises the cost of healthcare. Duplicate payment may also occur
in the absence of duplicate billing--resulting instead from errors
in the payers' processing of payments. Duplicate payments remitted
via a clearinghouse are typically not detected until after the
provider has received the duplicate payment because the
clearinghouse has no method by which payments are stored and
validated for accuracy against the provider's original or adjusted
bill.
[0005] Another common problem in known claims management systems
involves errors in both claims submission and payment of a third
party liability-related claim (i.e., claims for which at least some
portion of the amount due is to be paid by a third party payer).
The payment of a healthcare claim may be the responsibility of the
patient alone, such as if the patient is uninsured or the service
provided is not covered by the patient's insurance. The payment of
a healthcare claim may be the responsibility of the patient's
medical insurance provider, which may be a private insurance
carrier or a government agency such as Medicare or Medicaid. The
payment of a healthcare claim may be the responsibility of a third
party payer, such as a homeowners insurance carrier (e.g., if the
patient is injured by falling on an icy sidewalk), an automobile
insurance carrier (e.g., if the patient is injured in a car
accident), a workers compensation insurance carrier (e.g., if the
patient in injured at work), or an excess/supplemental liability
insurance carrier (i.e., an insurance company that offers policies
that supplement a patient's primary insurance coverage). The
payment of a healthcare claim may be the responsibility of any
combination of the above-described payers.
[0006] The many complexities of the third-party liability claims
payment process complicate payment, and carriers often pay an
incorrect amount due to a lack of information regarding
coordination of benefits between insurance carriers (coordination
of benefits refers to a provision within a healthcare reimbursement
schedule that provides that, when a patient is covered under more
than one insurance plan, the patient is entitled to benefits up to,
but not exceeding, the total allowable expense). This breed of
administrative error can be much more complex to resolve than a
standard duplicate claim, as it is generally necessary to refund
and re-bill the claim to resolve the error. This sort of errant
claim can also be much more time consuming to resolve, as most
providers do not bill what is presumed to be the secondary carrier
until payment has been received from the primary carrier. If the
provider has submitted the bills in an incorrect coordination of
benefits, the provider may be waiting for a remittance from a payer
who does not intend to pay (generally because the payer is often
able to immediately recognize upon receipt of the claim that the
payer is not the primary payer). Additionally, the provider may
bill all payers at once and receive an incorrect payment from the
secondary payer who has paid as a primary payer due to the
incorrect billing. A refund and re-bill is generally required to
resolve such problems.
[0007] The above described problems result from the manual
processes and the lack of transparency between billing and
adjudication systems that exist today, and contribute to a
disjointed process which results in huge inefficiencies and
excessive, but avoidable, administrative costs. When a payer or
provider discovers that a claim has been paid incorrectly, either
as a duplicate or from incorrect third-party liability
reimbursement, the administrative costs incurred to resolve the
claim is significant. The standard process generally involves paper
letters to the provider from the payer requesting the payment to be
refunded, phone calls between payer and provider to resolve various
data elements, faxes between each party to provide documentation
for discrepancies, and often the usage of data mining and/or
collection agencies. Preventing incorrect reimbursement of claims
is important to keeping the administrative cost of post-payment
resolution of errant claims at a manageable and reasonable
amount.
[0008] These inefficiencies are graphically captured in FIGS. 1-4.
The illustrated flowcharts provide graphical examples of what
current claim and remittance processing entails, and they also
highlight representative problems that may occur during such
processing. FIG. 1 is a flowchart depicting the process in which a
provider submits a bill to be paid by the payer through a
clearinghouse. The flowchart of FIG. 1 also depicts the process in
which a payer submits a remittance back to the provider through a
clearinghouse. FIG. 2. is a flowchart depicting the process in
which a provider identifies third party liability. The flowchart of
FIG. 2 also depicts the cumbersome and time-consuming process in
which the provider refunds money to a misidentified primary
guarantor that has already adjudicated and paid on a claim. FIG. 3.
is a flowchart depicting the process in which a provider refunds a
duplicate payment to a payer for the same bill. The flowchart of
FIG. 3 also depicts the process in which the payer may deny the
refund and send the refunded money back to the payer. FIG. 4. is a
flowchart depicting the process in which a provider sends a bill to
the payer for adjudication and payment. The flowchart of FIG. 4
also depicts the process in which the provider may submit a
duplicate bill if the provider has not received an 835, remittance
and/or payment from the payer according to the provider standard
timeframes. As can be appreciated by reviewing FIGS. 1-4, the prior
art comprises a disjointed process which results in huge
inefficiencies and excessive, but avoidable, administrative costs.
The prior art figures only capture examples of prior art methods.
The figures are thought to be helpful in understanding the
applicant's invention and how it improves upon the prior art
techniques.
BRIEF SUMMARY OF THE INVENTION
[0009] The object of the present invention is to overcome the
aforementioned drawbacks and to provide a scalable healthcare claim
and remittance processing system that functions as a clearinghouse
and data warehouse portal, having the ability to identify and
prevent duplicate claims and duplicate remittances, and to identify
and correct errors in third-party liability claims and
remittances.
[0010] In one embodiment of the invention, a system for processing
healthcare claims and remittances comprises a database and an
electronic portal. The database contains previously received
healthcare claims from a plurality of healthcare providers and
previously received remittances from a plurality of payers. The
electronic portal, connected to the database, receives a healthcare
claim from a healthcare provider and splits the received claim into
a plurality of data elements. These data elements comprise at least
a patient identifier, a healthcare provider identifier, a date of
service, and an amount payable. The electronic portal may assign a
unique identifier and a shared identifier to each of the data
elements of the received claim. The electronic portal performs a
duplicate claim edit and/or a third party liability edit on the
received claim. Based on the result of the duplicate claim edit
and/or the third party liability edit, the electronic portal
submits the received claim to a payer. The electronic portal may
provide the plurality of data elements and associated unique and
shared identifiers to the database to be stored. The electronic
portal may set a status indicator for each of the plurality of data
elements of the received claim to indicate that the claim has been
submitted to the payer.
[0011] Performing the duplicate claim edit may comprise searching
the database for a previously received claim that has a same
patient identifier and a same date of service as the received claim
and that has a status indicator indicative of having been submitted
to the payer. The electronic portal may submit the received claim
to the payer only if the database does not contain a previously
received claim that has the same patient identifier and the same
date of service as the received claim and that has a status
indicator indicative of having been submitted to the payer. The
electronic portal may notify the healthcare provider if the
database contains a previously received claim that has the same
patient identifier and the same date of service as the received
claim and that has a status indicator indicative of having been
submitted to the payer.
[0012] Performing the third party liability edit may comprise
determining if one or more third party payers is responsible for
paying at least a portion of the amount payable associated with the
received claim. Determining if one or more third party payers is
responsible for paying may comprise at least one of: (a)
determining if the received claim contains a third party liability
indicator; (b) comparing an insurance carrier listed on the
received claim to a stored list of insurance carriers that
exclusively function as third party payers; (c) sending a third
party liability inquiry to a payer associated with the received
claim; or (d) searching the database for previously received
healthcare claims corresponding to the same patient identifier as
the received claim, and determining if any such previously received
claims are associated with a third party payer. If at least two
third party payers are responsible for paying a portion of the
amount payable associated with the received claim, the third party
liability edit may determine which of the third party payers is a
primary payer and which is a secondary payer. If at least three
third party payers are responsible for paying a portion of the
amount payable associated with the received claim, the third party
liability edit may determine which of the third party payers is a
tertiary payer. The received claim may then be submitted to the
primary payer.
[0013] The electronic portal may determine if any necessary data is
missing from the received claim and send a missing data request to
the healthcare provider. The electronic portal may receive missing
data from the healthcare provider and split the received missing
data into a plurality of data elements. The electronic portal may
then assign a unique identifier and the shared identifier to each
of the plurality of data elements of the missing data. By assigning
the shared identifier to the missing data elements, the missing
data elements are associated with the original claim.
[0014] The electronic portal may resubmit the received claim to the
payer and notify the healthcare provider of the resubmission if a
predetermined amount of time has elapsed since the received claim
was submitted to the payer.
[0015] The electronic portal may receive a remittance from a payer
and split the received remittance into a plurality of data
elements, the data elements comprising at least a patient
identifier, a healthcare provider identifier, a date of service,
and an amount being paid. The electronic portal may then assign a
unique identifier and the shared identifier to each of the
plurality of data elements of the received remittance. The
electronic portal may then perform a duplicate remittance edit
and/or a third party payment edit on the received remittance. Based
on the result of the duplicate remittance edit, the electronic
portal may submit the received remittance to the healthcare
provider. The electronic portal may store the plurality of data
elements and associated unique and shared identifiers in the
database. The electronic portal may set a status indicator for each
of the plurality of data elements of the received remittance to
indicate that the remittance has been submitted to the healthcare
provider.
[0016] Performing the duplicate remittance edit may comprise
searching the database for a previously received remittance that
has a same patient identifier and a same date of service as the
received remittance and that has a status indicator indicative of
having been submitted to the healthcare provider. The electronic
portal may submit the received remittance to the healthcare
provider only if the database does not contain a previously
received remittance that has the same patient identifier and the
same date of service as the received remittance and that has a
status indicator indicative of having been submitted to the
healthcare provider. The electronic portal may notify the payer if
the database contains a previously received remittance that has the
same patient identifier and the same date of service as the
received remittance and that has a status indicator indicative of
having been submitted to the healthcare provider.
[0017] Performing the third party payment edit may comprise
determining if any portion of the amount payable remains
outstanding after receiving the remittance and determining if one
or more third party payers is responsible for paying the
outstanding portion. If one third party payer is responsible for
paying the outstanding portion, the electronic portal may submit a
claim for the outstanding portion to the one third party payer
responsible for paying the outstanding portion. If two or more
third party payers are responsible for paying the outstanding
portion, the electronic portal may submit a claim for the
outstanding portion to the third party payer having primary
responsibility to pay the outstanding portion.
[0018] In addition to the system for processing healthcare claims
and remittances as described above, other aspects of the present
invention are directed to corresponding methods and computer
program products for processing healthcare claims and
remittances.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)
[0019] Having thus described the invention in general terms,
reference will now be made to the accompanying drawings, which are
not necessarily drawn to scale, and wherein:
[0020] FIG. 1 is a flowchart depicting a typical process in which a
provider submits a bill to be paid by the payer through a
clearinghouse and the payer submits a remittance back to the
provider through a clearinghouse;
[0021] FIG. 2 is a flowchart depicting a typical process in which a
provider identifies third party liability related to a claim, and
in which the provider refunds money to a misidentified primary
guarantor that has already adjudicated and paid on a claim;
[0022] FIG. 3 is a flowchart depicting a typical process in which a
provider refunds a duplicate payment to a payer, and in which the
payer may refuse the refund and return the refunded money to the
payer;
[0023] FIG. 4 is a flowchart depicting a typical process in which a
provider sends a bill to the payer for adjudication and payment;
the flowchart of FIG. 4 also depicts the process in which the
provider may submit a duplicate bill if the provider has not
received an 835, a remittance, and/or a payment from the payer
according to the provider standard timeframes;
[0024] FIG. 5 illustrates a block diagram of a healthcare claim and
remittance processing system, in accordance with one embodiment of
the invention;
[0025] FIG. 6 is a flowchart depicting the receipt and processing
of a claim, in accordance with one embodiment of the invention;
and
[0026] FIG. 7 is a flowchart depicting the receipt and processing
of a remittance, in accordance with one embodiment of the
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0027] The present invention now will be described more fully
hereinafter with reference to the accompanying drawings, in which
preferred embodiments of the invention are shown. This invention
may, however, be embodied in many different forms and should not be
construed as limited to the embodiments set forth herein; rather,
these embodiments are provided so that this disclosure will be
thorough and complete, and will fully convey the scope of the
invention to those skilled in the art. Like numbers refer to like
elements throughout.
[0028] Turning now to a more detailed description of the present
invention, there is first illustrated in FIGS. 1-4 embodiments of
known claim and remittance processing methods that are helpful in
understanding the present invention. The exact and full
methodologies for this type of manual claim and remittance
processing need not be described in extensive detail herein
inasmuch as such in-depth details are known to those skilled in the
art, and the details are evident given the illustrations. Moreover,
the processes illustrated by flowchart in FIGS. 1-4 are merely
exemplary. The present invention provides a system that simplifies
and improves upon a wide-range of prior art transactions and need
not be strictly associated with the illustrated prior art
embodiments.
[0029] FIGS. 1-4, being known techniques for resolving post-payment
claims, are thought to be self-explanatory. Overall, the flowcharts
of FIGS. 1-4 detail the inefficiencies in a traditional claim and
remittance processing system. A number of process steps are
illustrated in order to understand the refined process and system
of the present invention. These steps do not require further
discussion here. As illustrated, known techniques fail to detect
errors in claim and remittance processing prior to the submission
of the claim to the payer or the remittance to the provider. Thus,
errors in claim and remittance processing result in duplicative and
time-consuming administrative efforts to resolve.
[0030] Embodiments of the present invention, which will be
described subsequently in greater detail, provide a scalable claim
transmission and remittance system and associated method that
functions as a clearinghouse and data warehouse portal. Systems and
methods of embodiments of the invention have the ability to
identify duplicate claims and third-party liability claims and
automatically identify preventative action for errors in payment of
each for such claims, thereby resolving healthcare claim
discrepancies and disputes among multiple healthcare payers and
providers. Embodiments of the invention have many of the advantages
of the claims clearinghouse portals mentioned heretofore, as well
as novel features that result in storing data for the purpose of
identifying duplicate paid claims or claims involving inaccurate
third-party liability processing. The scalable solution provided by
embodiments of the invention can be applied in both a pre- and
post-adjudication model, greatly reducing the administrative cost
of claim submission, claim payment, and claim resolution.
[0031] Embodiments of the invention allow multiple healthcare
providers, payers, insurance companies, carriers, Health
Maintenance Organizations (HMOs), Independent Physician
Associations (IPAs), government entities, self-insured companies,
Third Party Administrators (TPAs), and other authorized entities to
participate in the resolution process related to medical claims in
a pre- or post-payment environment. Embodiments of the invention
allow these entities to view and work from a transparent set of
data, as the system records each account (as used herein, an
account refers to a unique patient encounter with a particular
provider) in a standard fashion by creating a unique identifier for
each claim data element and a shared identifier that links the
provider bill with the payer remittance. All claim and remittance
activity may be monitored for all related or duplicate accounts,
thereby automatically preventing claim and remittance processing
errors before they occur, both on the front end and the back end of
the adjudication process. All related entities are able to work
from a common set of data to take steps to quickly and concurrently
resolve financial transaction issues.
[0032] Embodiments of the invention function as a neutral
transaction platform, with a data warehouse portal that stores all
data elements with unique identifiers and operates as a common and
shared intermediary system between multiple payer and multiple
provider platforms. A data warehouse of claims information is
maintained that is extracted from multiple providers, multiple
payers, and other entities in order to streamline and improve the
workflow process. The term "data warehouse" is generally understood
to refer to a collection of computerized data, organized for
optimal reporting and analysis. The terms data warehouse and
database are used interchangeably herein. Embodiments of the
invention electronically collect and store relevant data in the
data warehouse from the provider bill and the payer remittance.
This relevant data generally is not stored as intact claims and
remittances (i.e., as submitted by providers and payers,
respectively), but rather as "objects," or separate data elements
that together comprise a claim or remittance.
[0033] Referring now to FIG. 5, a block diagram of a healthcare
claim and remittance processing system is illustrated, in
accordance with one embodiment of the invention. The system 10
comprises an electronic portal 12 and a data warehouse 14. A
plurality of healthcare providers 16 and payers 18 may be in
communication with the electronic portal.
[0034] The portal is typically Internet-based (also termed
web-based), such that communication between the portal and the
users (i.e., the providers and payers) occurs via the Internet,
although communication may also occur via any suitable secure
communications media, such as virtual private network (VPN). The
communication typically occurs over a browser-based connection
(i.e., Internet, Intranet, or Extranet) and will, therefore, have
inherent security measures. The portal of embodiments of the
invention receives provider claims and payer remittances. The
claims and remittances are preferably transmitted electronically,
although hard copy (i.e., paper) claims and remittances may be
received and processed. Hard-copy claims and remittances are
typically loaded into the system manually, such as by scanning and
performing optical character recognition (OCR). While the preferred
operation is "real time," upload processes such as "dialup" can
also be accommodated by embodiments of the invention. Moreover, the
present invention can accommodate individual claim entry as well as
batch processing. Once the data warehouse receives the raw data
from the provider, receipt of the claim or remittance may be
automatically confirmed.
[0035] Embodiments of the invention meet or exceed all current
state and federally mandated transaction requirements, including,
but not limited to, those requirements set forth pursuant to the
Health Insurance Portability and Accountability Act of 1996
(HIPAA). It is envisioned that the system could be modified to
conform to future statutory requirements.
[0036] The electronic claims submitted by the providers and the
electronic remittances submitted by the payers typically contain
standardized segments, data elements, and codes that designate
usage, reference destinations, name, and attributes that would be
used. Paper claims (e.g., a UB-92 or a HCFA 1500 form) typically
contain standardized fields with each data field identified by a
unique numeric identifier and title. Although, similar information
can be found on remittances, in general, remittance data formats
can vary between payer organizations and are typically identified
by a header row.
[0037] The claim that is generated by the electronic portal and
sent to a payer typically conforms to the 837 HIPAA Transaction Set
(termed by HIPAA as a "Health Claims & Equivalent Encounter
Information and Coordination of Benefits"). The remittance that is
generated by the electronic portal and sent to a provider typically
conforms to the 835 HIPAA Transaction Set (termed by "HIPAA as a
Health Care Payment/Remittance Advice" (EFT/ERA)). Herein, a claim
may be alternatively referred to as an 837, and a remittance may be
alternatively referred to as an 835. Claims and remittances that
are transmitted to the electronic portal from providers and payers,
respectively, may already conform to their respective HIPAA
transaction set. Alternatively, embodiments of the invention may
use the data elements received in non-standard claims and
remittances to create claims and remittances that conform to the
HIPAA standards for transmission to the providers and payers.
[0038] The electronic portal splits the claims and remittances into
separate data elements for input into the data warehouse. A unique
identifier is created for each claim data element, and a shared
identifier is created that links payer and provider and that
contains references to the individual payer, provider, and patient
encounter data elements for any individual transaction or group of
transactions for the same individual. Each data element will
typically be assigned a status identifier that reflects status of
the claim or remittance, in terms of action that have been
performed on the claim or remittance, such as the respective
submission and subsequent response from the other party (example
status identifiers may include "submission," "submission response,"
"status," and "status response"). Each data element will typically
be assigned a monetary amount associated with the particular
transaction. The data elements, along with the unique and shared
identifiers and the status identifiers, are stored in the database.
The individual data elements create standard packets of information
that, when re-compiled, can reproduce the claim or remittance.
[0039] Embodiments of the invention generally have the ability to
determine if any additional information is needed to generate an
837 HIPAA Transaction Set from the received claim or an 835 HIPAA
Transaction Set from the received remittance and to send a request
for additional information back to the entity that submitted the
claim or remittance. Upon receipt of the missing data, the system
will assign a unique identifier to the new data elements, link the
new data elements to the shared identifier, and store the new data
elements in the database. If the bill is received electronically,
the system will typically send an electronic request to the
provider for information detailing the missing data elements
necessary to generate the 837. If the bill is received as a hard
copy document, the system will typically send a hard copy request
to the provider detailing the missing data elements necessary to
generate the 837.
[0040] As used herein, the term "edit" refers to a predefined
procedure that is performed on the claim and/or remittance data in
which, for example, the format and content of the received and/or
stored data is checked to determine if the data conforms to the
requirements of the system, or the received and/or stored data is
analyzed to determine which subsequent procedure(s) should be
performed by the system. As described further herein, a plurality
of edits may be performed on the claim and/or remittance data to
ensure correct claim and remittance processing, thereby preventing
errors which may be time-consuming and expensive to remedy.
[0041] Embodiments of the invention may perform an edit on the
received claim to determine if any of the billed procedures are
procedures for which Medicare will not reimburse the providers
(these procedures are termed "Medicare defined disallowed
services"). If any of the billed procedures are not reimbursable by
Medicare, the system will typically notify the provider of the
incorrect bill and will not transmit the 837 to the payer.
[0042] Inefficiencies in known claims processing systems also exist
when a provider does not receive timely payment for a bill and must
send a request for claim status to the payer. Embodiments of the
invention may track the elapsed time since the 837 was sent to the
payer and, after a predetermined amount of time has passed,
automatically send a payment status request to the payer and notify
the provider that a payment status request has been sent.
[0043] Embodiments of the invention are able to link multiple
remittances from multiple payers to single or multiple bills for
the same service. When a provider submits a primary bill, secondary
bill, and tertiary bill for a given claim, the system generates a
separate, unique 837 for each bill but also creates a related
shared identifier that links those separate bills to the claim. For
the same claim, a primary payer remittance, a secondary remittance,
and a tertiary remittance may be received by the system and a
separate, unique 835 will be created for each remittance with the
same shared identifier assigned to the remittances to link them to
the same original claim. This capability allows for all 837s or
835s for a particular claim to be viewed when any one of the
primary, secondary, or tertiary 835s or 837s is viewed for that
particular claim, thereby reducing errant claims with respect to
third-party liability issues. The data warehouse element of the
system enables an erroneous claim to be corrected prior to
submitting an 837 to a payer and allows an erroneous remittance to
be corrected prior to submitting an 835 to the provider.
[0044] Embodiments of the invention function as a healthcare claim
tracking system through one central data warehouse, accessible
through an electronic portal. This system benefits both the
healthcare provider and the healthcare payer by performing one or
more edits on the received claim (e.g., a duplicate claim edit and
a third party provider edit, as discussed in detail below) and by
performing one or more edits on the received remittance (e.g., a
duplicate remittance edit and a third party payment edit, as
discussed in detail below), thereby reducing claim and remittance
errors and reducing administrative costs for payers and
providers.
[0045] Once the bill or remittance is broken down into separate
data elements, a number of different edits may be performed to
detect and correct errors. For example, a duplicate claim edit may
be performed that is capable of detecting a duplicate claim by
searching the database for a previously received claim having one
or more data elements in which the data is the same as that of the
newly received claim. For example, the duplicate claim edit may
search the database for a previously received claim having the same
patient number, the same date of service, the same procedure code,
and the same amount due (for the same procedure) as the newly
received claim, although it should be appreciated that the number
of data elements used may vary and the specific data elements used
may vary. If such a previously received claim is discovered, then
the newly received claim is marked as a duplicate. Although the
term "procedure code" is used herein, this code may in fact refer
to procedures or services performed for a patient or may refer to
products, supplies, or equipment used in the care of a patient. The
procedure code is an industry-standard numeric or alphanumeric code
indicative of the type of service or procedure performed by the
provider. One such procedure code is the "revenue code," and
another such procedure code is the "Current Procedural Terminology"
(CPT) code. (The CPT codes are also referred to as Level I of the
Healthcare Common Procedure Coding System (HCPCS). Level II of the
HCPCS also defines a different set of procedure codes which may be
used in embodiments of the invention.) Revenue codes are a set of
three-digit codes that identify hospital services. CPT codes are a
set of five-digit codes that identify medical services. If a
received claim is determined to be a duplicate, the claim is not
submitted to the payer and notification is sent to the provider
that submitted the duplicate claim. The system stores the duplicate
transaction through the same standard fashion of assigning unique
identifiers to the data elements as previously discussed. If
desirable, a human can intervene in the process and review a
"suspect" duplicate claim prior to notification through a "suspect"
duplicate work queue.
[0046] As an example of performing a duplicate claim edit, consider
a bill submitted by a provider on Aug. 1, 2006, with total charges
of $2,000.00 (Rev Code 123 for $1,500.00 and Rev Code 456 for
$500.00), for patient account number 987654321, and for dates of
service Jul. 15, 2006-Jul. 16, 2006. Upon successfully processing
the claim initially, an 837 is submitted to the payer, and the
status of each data element is recorded in the data warehouse as
being submitted. Consider if the provider then submits a bill on
Sep. 1, 2006, with total charges of $5,000.00 (of Rev Code 123 for
$1,500.00 and Rev Code ABC for $3,500.00), for patient account
number 987654321, and for dates of service Jul. 15, 2006-Jul. 16,
2006. Upon performing the duplicate claim edit, the system will
determine that Rev Code 123 for $1,500.00 has already been
submitted to the provider. Thus, this portion of the newly
submitted claim would be determined to be a duplicate and would not
be submitted to the payer. However, the bill for $3,500.00 for Rev
Code ABC would be determined to have not been previously submitted
to the payer, and an 837 for that service would be generated and
submitted to the payer.
[0047] As another example of edits that may be performed to detect
and correct errors, a third party liability edit may be performed
on a received claim. The third party liability edit may determine
if a received claim involves third party liability using several
different methods. For example, the third party liability edit may
determine if a third-party liability indicator exists on the
received claim. Certain third party liability indicators exist on a
providers' standard bill (such as a UB92 or HCFA 1500 form).
Alternatively, the third party liability edit may query other
previously received claim submissions with the same patient
demographic information that are stored in the data warehouse. If
prior claims for the same patient involved third party liability,
it is likely that new claims also involve third party liability.
Another method to determine third party liability is by referencing
a diagnosis code included in the claim, as the specific diagnosis
may be indicative of third party liability. For example, diagnosis
codes E813.0 and E819.0 indicate an injury resulting from a motor
vehicle traffic accident and thus may be indicative of third party
liability (i.e., coverage from an automobile insurance policy).
Another method to determine third party liability is to compare the
insurance carrier listed on the claim against a database of
insurance carriers who only handle third party liability claims
(e.g., a workers compensation carrier or an automobile insurance
carrier). By maintaining a database of carriers or any health
insurers that only administer third party liability coverage, the
system mitigates the provider error of not using a third party
liability indicator when appropriate on the bill. By utilizing a
database of carriers or any health insurers that only administer
third party liability coverage, the invention removes the need for
a third party liability indicator to trigger the coordination of
benefits (COB) process. Another method to determine third party
liability is to utilize standard "270/271 transaction sets," which
are typically used for patient eligibility inquiry and response.
The system may send a 271 (inquiry) to the payer on behalf of the
provider to determine if third party liability is involved. The
payer may send a 270 (response) back to confirm or deny third party
liability.
[0048] If any of the above methods indicate the involvement of
third party liability, the claim will be flagged for validation the
correct coordination of benefits (COB) for such claims, prior to
the claim being submitted for payment. As described above, COB
refers to a provision within a healthcare reimbursement schedule
that provides that, when a patient is covered under more than one
group insurance plan, the patient is entitled to benefits up to,
but not exceeding, the total allowable expense. Further, COB
involves determining which payer has primary liability for a claim,
which payer has secondary liability, which payer has tertiary
liability, and so forth. An 837 may then be submitted to the payer
determined to be the primary payer. As discussed below, submission
of an 837 to the secondary payer, if required, will typically occur
after a remittance is received from the primary payer, and
submission of an 837 to the tertiary payer, if required, will
typically occur after a remittance is received from the secondary
payer. Issues such as payment in the incorrect coordination of
benefits and zero-payment remittances, etc. can be avoided by
validating COB on the front-end.
[0049] As another example of edits that may be performed to detect
and correct errors, a duplicate remittance edit may be performed on
a received remittance. The duplicate remittance edit functions in a
similar fashion to the duplicate claim edit. For example, a
duplicate remittance edit may be performed that is capable of
detecting a duplicate remittance by searching the database for a
previously received remittance having one or more data elements in
which the data is the same as that of the newly received
remittance. For example, the duplicate remittance edit may search
the database for a previously received remittance having the same
patient number, the same date of service, and the same amount due
(for the same procedure) as the newly received claim, although it
should be appreciated that the number of data elements used may
vary and the specific data elements used may vary. If a received
remittance is determined to be a duplicate, the remittance is not
submitted to the provider and notification is sent to the payer
that submitted the duplicate remittance.
[0050] As another example of edits that may be performed to detect
and correct errors, a third party payment edit may be performed on
a received remittance. Upon receipt and validation of a primary
payer's 835, the third party payment edit will determine if there
is outstanding liability (i.e., a balance due) on the claim. If
outstanding liability still exists, the third party payment edit
may perform an additional validation of the secondary payer, or may
use the secondary payer determined during the third party liability
edit discussed above. The system will automatically create and
submit an 837 to the secondary payer, while also sending the
remittance received from the primary payer to the provider. The 837
that is submitted to the secondary payer would not request payment
for the full amount of the claim, but rather only for the amount of
the outstanding liability. Upon receipt and validation of the
secondary payer's 835, the system will perform the same series of
validation checks as previously described and automatically create
and submit an 837 to the tertiary payer, while also sending the
remittance received from the secondary payer to the provider.
[0051] The system is capable of sending a stop payment notice to
the payer if a remittance fails the duplicate remittance edit or
the third party payment edit. The system is also capable of
adjusting the remittance to correct any errors prior to issuance to
the provider. This capability of the system allows for duplicate
payment and third-party liability payment issues to be corrected
without having the payment sent to the provider and aides in
resolving healthcare claims discrepancies and disputes among
multiple payers and providers and reduces the overall cost of
healthcare.
[0052] Embodiments of the invention have the ability to provide
root cause analysis, error resolution, and detailed drill down
reporting. The system may assign error codes to individual claims
that will enable error resolution, as well as leading to root cause
analysis and error trending. Through the detailed drill down
reporting, the system may provide benchmarking for individual payer
and provider relationships, for single provider and multiple payer
relationships, for single payer and multiple provider
relationships, and for multiple provider and multiple payer
relationships.
[0053] Thus, the present invention allows common or shared payment
claim level tracking, as both providers and payers can identify an
account via a shared identifier through the electronic portal.
Because the present invention allows providers and payers to track
and resolve duplicate claims and third-party claims on the same
system through the portal, claim-level tracking is less time
consuming and less expensive. The invention enables earlier
identification of root cause problems related to duplicate claims
and third party claims on the front end and back end of the claims
process, and facilitates the correction of these problems resulting
in fewer billing or payment errors and lower administrative
costs.
[0054] FIGS. 6 and 7 illustrate typical claim and remittance
processing, using features of embodiments of the invention
described in detail above. FIG. 6 is a flowchart depicting the
receipt and processing of a claim, in accordance with one
embodiment of the invention. A healthcare claim may be received
from a healthcare provider by a clearinghouse. See block 30. The
claim may be received electronically via the electronic portal 12
of FIG. 5. Alternatively, a paper claim may be received and scanned
as described above. The claim will typically be checked to
determine if any information that is necessary to process the claim
is missing. See block 32. Regardless of whether information is
determined to be missing, the electronic portal splits apart the
claim into separate data elements and assigns unique and shared
identifiers to the data elements. See block 38. If information is
determined to be missing, a request for the missing information may
be sent to the provider. See block 34. The missing information
request would typically be sent electronically if the claim was
received electronically, and the missing information request would
typically be sent via hard copy if a hard copy claim was received.
When the missing information is received, see block 36, the
electronic portal splits apart the newly received information into
separate data elements and assigns unique and shared identifiers to
the newly received data elements. See block 38. Although not
illustrated, the received claim is stored as separate data elements
in the data warehouse. The electronic portal may then perform a
duplicate claim edit, as described in detail above, to determine if
the received claim is a duplicate of a previously received claim
that is stored in the data warehouse. See block 40. If the received
claim is determined to be a duplicate claim, the provider is
notified and the claim is not submitted to a payer. See block 42.
If the claim is not a duplicate, additional edits may be performed.
For example, a third party liability edit may be performed to
determine the appropriate primary, secondary, and tertiary payers.
See block 46. An 837 is created for the appropriated payer, see
block 48, and the 837 is submitted to the payer, see block 50.
[0055] FIG. 7 is a flowchart depicting the receipt and processing
of a remittance, in accordance with one embodiment of the
invention. A healthcare remittance may be received from a payer by
a clearinghouse. See block 70. The remittance will typically be
checked to determine if any information that is necessary to
process the remittance is missing. See block 72. Regardless of
whether information is determined to be missing, the electronic
portal splits apart the remittance into separate data elements and
assigns unique and shared identifiers to the data elements. See
block 78. If information is determined to be missing, a request for
the missing information may be sent to the payer. See block 34.
When the missing information is received, see block 76, the
electronic portal splits apart the newly received remittance data
into separate data elements and assigns unique identifiers to the
data elements and assigns the same shared identifier as was
assigned to the corresponding claim and to the originally received
remittance data. See block 78. Although not illustrated, the
received remittance is stored as separate data elements in the data
warehouse. The electronic portal may then perform a duplicate
remittance edit, as described in detail above, to determine if the
received remittance is a duplicate of a previously received
remittance that is stored in the data warehouse. See block 80. If
the received remittance is determined to be a duplicate remittance,
the payer is notified and the remittance is not submitted to the
provider. See block 82. If the remittance is not a duplicate,
additional edits may be performed. For example, a third party
payment edit may be performed. See block 86. The third party
payment edit will typically determine if there is an outstanding
liability remaining on the claim. If so, the third party payment
edit will determine if a subsequent payer is liable for the
outstanding liability. See block 86. For example, if the received
remittance is from a primary payer on the claim, then the third
party payment edit will determine if there is a secondary payer
liable for the outstanding liability. If the received remittance is
from a secondary payer on the claim, then the third party payment
edit will determine if there is a tertiary payer liable for the
outstanding liability. An 837 will then be created, see block 88,
and submitted to the appropriate subsequent payer, see block 90.
The electronic portal will process the remittance for submittal to
the provider. The electronic portal will typically determine if the
original claim was received from the provider electronically or via
hard copy. See block 92. If the original claim was received via
hard copy, the electronic portal will typically notify the payer to
send a hard copy remittance to the provider. See block 94. If the
original claim was received electronically, the electronic portal
will typically create an 835, see block 96, and submit the 835
electronically to the provider, see block 98.
[0056] The method of processing healthcare claims and remittances
may be embodied by a computer program product. The computer program
product includes a computer-readable storage medium, such as the
non-volatile storage medium, and computer-readable program code
portions, such as a series of computer instructions, embodied in
the computer-readable storage medium. Typically, the computer
program is stored by a memory device and executed by an associated
processing unit, such as the processing element of the server. With
respect to the above description, it is to be realized that the
computer program product for the elements of the invention is
deemed to be readily apparent and obvious to one skilled in the
art.
[0057] In this regard, FIGS. 6 and 7 are flowcharts of methods and
program products according to the invention. It will be understood
that each step of the flowchart, and combinations of steps in the
flowchart, can be implemented by computer program instructions.
These computer program instructions may be loaded onto one or more
computers or other programmable apparatus to produce a machine,
such that the instructions which execute on the computer or other
programmable apparatus create means for implementing the functions
specified in the flowchart step(s). These computer program
instructions may also be stored in a computer-readable memory that
can direct a computer or other programmable apparatus to function
in a particular manner, such that the instructions stored in the
computer-readable memory produce an article of manufacture
including instruction means which implement the function specified
in the flowchart step(s). The computer program instructions may
also be loaded onto a computer or other programmable apparatus to
cause a series of operational steps to be performed on the computer
or other programmable apparatus to produce a computer implemented
process such that the instructions which execute on the computer or
other programmable apparatus provide steps for implementing the
functions specified in the flowchart step(s).
[0058] Accordingly, steps of the flowchart support combinations of
means for performing the specified functions, combinations of steps
for performing the specified functions and program instruction
means for performing the specified functions. It will also be
understood that each step of the flowchart, and combinations of
steps in the flowchart, can be implemented by special purpose
hardware-based computer systems which perform the specified
functions or steps, or combinations of special purpose hardware and
computer instructions.
[0059] The system is capable of automatically detecting a duplicate
claim or an incorrect third-party claim. This prevents the
submission of duplicate claims and improper submitted third-party
claims to the payer. This in turn prevents duplicate claim payments
and improper third-party liability payments from being sent to the
provider. This prevention of errant claims and remittances reduces
healthcare claim discrepancies and disputes among multiple payers
and providers and reduces the overall cost of healthcare.
[0060] Many modifications and other embodiments of the invention
will come to mind to one skilled in the art to which this invention
pertains having the benefit of the teachings presented in the
foregoing descriptions and the associated drawings. Therefore, it
is to be understood that the invention is not to be limited to the
specific embodiments disclosed and that modifications and other
embodiments are intended to be included within the scope of the
appended claims. Although specific terms are employed herein, they
are used in a generic and descriptive sense only and not for
purposes of limitation.
* * * * *