U.S. patent application number 13/895609 was filed with the patent office on 2013-09-19 for medical services claim management system and method.
This patent application is currently assigned to Encoda LLC. The applicant listed for this patent is Encoda LLC. Invention is credited to Mark R. Cruise.
Application Number | 20130246094 13/895609 |
Document ID | / |
Family ID | 48365403 |
Filed Date | 2013-09-19 |
United States Patent
Application |
20130246094 |
Kind Code |
A1 |
Cruise; Mark R. |
September 19, 2013 |
Medical Services Claim Management System and Method
Abstract
Methods for managing requests by a medical services provider for
payment from a payer are described. In one embodiment, claims are
aggregated into a single file and submitted for payment
electronically. If a file level rejection occurs, rejected claims
are removed and the single file reformed and resubmitted. This is
repeated as necessary until the file is accepted. In another
embodiment, claims are assigned first unique identifiers and line
items in claims are assigned second unique identifiers. The unique
identifiers are used to track every transaction. In another
embodiment, an explanation of benefits relating to a claim is
received and processed. Copayments are reallocated to line items
according to the explanation of benefits. Writeoffs and transfers
to next payers are performed automatically according to
adjudication codes in the explanation of benefits.
Inventors: |
Cruise; Mark R.; (Berwyn,
PA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Encoda LLC |
Plymouth Meeting |
PA |
US |
|
|
Assignee: |
Encoda LLC
Plymouth Meeting
PA
|
Family ID: |
48365403 |
Appl. No.: |
13/895609 |
Filed: |
May 16, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12253871 |
Oct 17, 2008 |
8447627 |
|
|
13895609 |
|
|
|
|
60980714 |
Oct 17, 2007 |
|
|
|
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 computerized method of managing requests by a health care
service provider for payment, the method comprising: electronically
submitting, by a computer system operated on behalf of the
provider, multiple claims in a single file to a computer system
operated on behalf of a payer; responding electronically to any
file level rejection by storing a record of the rejection and
re-creating the multiple claim file without the rejected claims in
the computer system operated on behalf of the provider; and
automatically repeating the acts of submitting and responding, as
necessary, until the single file is accepted.
2. The computerized method of claim 1, further comprising:
associating, by the computer system operated on behalf of the
provider, a first unique identifier with each claim submitted for
payment; placing, by the computer system operated on behalf of the
provider, the first unique identifier in a field required by
standards to be preserved in the course of processing; and for each
claim, in connection with any transaction involving the claim,
storing the transaction in association with the first unique
identifier for the claim.
3. The computerized method of claim 2, further comprising:
associating, by the computer system operated on behalf of the
provider, a second unique identifier with each line item of a claim
to be submitted for payment; placing, by the computer system
operated on behalf of the provider, the second unique identifier in
a field required by standards to be preserved in the course of
processing; and for each line item, in connection with any
transaction involving the line item, storing the transaction in
association with the second unique identifier for the line
item.
4. The computerized method of claim 2, further comprising:
receiving, over a network at the computer system operated on behalf
of the provider, an explanation of benefits for at least one of the
claims, wherein each explanation of benefits contains the first
unique identifier associated with the corresponding claim; and
storing the explanation of benefits in association with the first
unique identifier for the claim.
5. The computerized method of claim 3, further comprising:
receiving, over a network at the computer system operated on behalf
of the provider, an explanation of benefits for at least one of the
claims, wherein each explanation of benefits contains: the first
unique identifier associated with the corresponding claim; and the
second unique identifiers associated with the line items in the
claim; and storing the explanation of benefits in association with
the first unique identifier for the corresponding claim and the
second unique identifiers for the line items of the corresponding
claim.
6. The computerized method of claim 5, wherein the explanation of
benefits further contains a co-payment allocation for each line
item to which the payer applied a co-payment, the method further
comprising: reversing any co-payment allocation in the health care
service provider system for any line item referenced in the
explanation of benefits; and re-allocating the co-payment in the
health care service provider system to the line item to which the
co-payment was allocated in the explanation of benefits.
7. The computerized method of claim 5, wherein the explanation of
benefits further contains a co-payment allocation for each line
item to which the payer applied a co-payment, the method further
comprising: comparing the line item to which a co-payment is
allocated in the explanation of benefits and the line item to which
the health care service provider system allocated the co-payment;
and if the line item allocations are not the same: reversing the
co-payment allocation in the health care service provider system;
and re-allocating the co-payment in the health care service
provider system to the line item to which the co-payment was
allocated in the explanation of benefits.
8. The computerized method of claim 5, wherein the explanation of
benefits further contains: a set of adjudication codes for each
line item, wherein each adjudication code in the line item relates
to a portion of the associated charge; the method further
comprising: for each line item in the explanation of benefits,
looking up the adjudication codes in a table of associated actions;
if any actions associated with the line item are transfer actions
and no actions associated with the line item are suspend actions,
transferring any balance remaining in association with the line
item to a next payer; if any actions associated with the line item
are write-off actions, writing off the portions of associated
charge to which the actions relate; and if the line item received
any unfavorable adjudication codes, creating an entry for the line
item in a denial management queue.
9-30. (canceled)
31. A computerized method of managing requests by a health care
service provider for payment, the method comprising: electronically
submitting, by a computer system operated on behalf of the
provider, multiple claims to a payer in a single file, wherein for
each claim a first unique identifier associated with the claim and
a second unique identifier associated with each line item of the
claim are placed in fields required by standards to be preserved
during processing; responding electronically, by the computer
system operated on behalf of the provider, to any file level
rejection by storing a record of the rejection and re-creating the
multiple claim file without the rejected claims; automatically
repeating the acts of submitting and responding, as necessary,
until the single file is accepted; receiving, over a network at the
computer system operated on behalf of the provider, an explanation
of benefits for at least one of the claims, wherein the explanation
of benefits contains: the first unique identifier associated with
the corresponding claim; the second unique identifiers associated
with the line items in the claim; a check number; and a set of
adjudication codes for each line item, wherein each adjudication
code of the line item relates to a portion of the associated
charge; for each line item referenced in the explanation of
benefits, looking up the adjudication codes in a table of
associated actions; if any actions associated with the line item
are transfer actions and no actions associated with the line item
are suspend actions, transferring any balance remaining in
association with the line item to a next payer; if any actions
associated with the line item are write-off actions, writing off
the portions of the line item to which the actions relate; if the
line item received any unfavorable adjudication codes, creating an
entry for the line item in a denial management queue; identifying a
deposit to a health care service provider's bank account, wherein
the deposit has the same check number as the explanation of
benefits; and associating the deposit with the claim referenced in
the explanation of benefits.
32. A computerized method of managing requests by a health care
service provider for payment, the method comprising: electronically
submitting multiple claims of the health care service provider in a
single electronic file to a computer system operated on behalf of a
payer, wherein for each claim a first unique identifier associated
with the claim is placed in a field required by standards to be
preserved during processing; receiving, over a network at a
computer system operated on behalf of the provider, from the
computer system operated on behalf of the payer, explanation of
benefits records responsive to the electronically submitted claims,
wherein each explanation of benefits record responsive to a given
claim contains the first unique identifier corresponding to the
given claim; storing each explanation of benefits record in
association with its corresponding first unique identifier;
receiving a settlement check associated with a plurality of the
submitted claims of the health care service provider, wherein the
computer system operated on behalf of the provider contains a
database of claim data and payment data; for each associated claim:
associating in the database a portion of the settlement check with
the claim according to a distribution strategy; recording in the
database a partial payment of the claim in the amount of the
associated portion of the settlement check; and applying a
settlement adjustment in the database to remaining unpaid balance
for the charges associated with the claim.
33. The computerized method of claim 32, wherein the distribution
strategy comprises: calculating a total of all outstanding charges
associated with the plurality of claims; calculating a ratio of a
value of the settlement check to the total of all outstanding
charges; and for each of the plurality of claims, associating in
the database a portion of the settlement check equal to the
outstanding charge associated with the claim reduced by the ratio
of the value of the settlement check to the total of all
outstanding charges.
Description
[0001] The present application claims priority from U.S.
Provisional application Ser. No. 60/980,714, filed Oct. 17, 2007,
the full disclosure of which is hereby incorporated by reference
herein.
TECHNICAL FIELD
[0002] The present invention relates to computerized methods and
systems, and more particularly to methods and systems for medical
services claim management.
BACKGROUND ART
[0003] Computerized handling of claims and payments in the
healthcare field has been around since the early 1980's or late
1970's. At that time, various Blue Shield entities and Medicare
already were handling claims and payments internally with computer
systems, and between their internal computer systems, and they were
exchanging claims and payment data with the computer systems of
medical practices. Although Medicare is a governmental payment
system, the processing of claims and payments for Medicare is
handled by nongovernment intermediaries, traditionally dominated by
Blue Shield entities. So the Blue Shield entities were said to have
two lines of business-one was private (the commercial Blue Shield
line of business) and the other was Medicare. Thus Medicare and the
Blue Shield private line of business became computerized at about
the same time. (Medicaid, which, like Medicare, is a governmental
payer handled by intermediaries, was computerized at a later date.)
The practices of most doctors in the United States are small. A
decade ago there were approximately 500,000 doctors in the United
States. As of September 2005 there were about 800,000. According to
the report entitled Medical Group Practices in the US, published by
the AMA in 2006, reflecting data as of Sep. 30, 2005, only 1,265
physician practices have more than 25 doctors. If you define a
group as 3 or more physicians, only 240,773 (about 30%) of the
total number of physicians are in groups. Clearly, just due to
size, the resources available to doctors to mount effective
technology-based tactics to defend against inappropriate
adjudication and reimbursement by insurance companies is limited as
compared to the resources of the payers. Back in the early 1980's,
the average size of a medical practice was even smaller. In 1982
only about 15% of doctors were computerized at all. Those doctors
depended on expensive minicomputers, each of which ran proprietary
CPUs which, in turn, required individual proprietary operating
systems, and only the largest of the practices could afford them.
Typically software for these physician practices was provided by
vertical market application software vendors. Typically each
software vendor had to make a deal with a particular hardware
manufacturer and usually resigned himself to programming for one
specific platform hardware/operating system combination. Thus
software offerings for these computerized physician practices,
constituting the first 15% of all the doctors to computerize, were
balkanized into a series of proprietary hardware/software vendor
combinations. Change the hardware; you had to change the software.
Change the software; you had to change the hardware. The division
between hardware and software was blurred. One example in the
medical field was Contel. Another is MUMPS. MUMPS based application
programs also controlled the hardware. Thus your application was
also your operating system.
[0004] As the era of the minicomputer wound down, the era of the
microcomputer emerged. The advent of the microcomputer involved
really not just the notion of the microcomputer per se (a computer
on a chip) but also an adoption of only a few standard CPU chips,
memory, and operating systems. Thus the microcomputer ushered in an
era of standardized computer hardware and standardized operating
systems. As these first two layers of the onion became
standardized, many new medical application software companies were
formed to offer software running in standard operating system
environments such as CP/M, MP/M, DOS, Xenix (a small memory model
Unix) and PC networks communicating through Novell. In this way the
application developers could spend all their time writing new
application level features and benefits rather than chasing the
incessant changes being made to proprietary hardware and their
twinned proprietary operating systems. Using the onion metaphor,
the operating system companies made sure their operating system
dealt on the inside with the changes in hardware while maintaining
a constant interface on the outside to the higher layer of the
application.
[0005] The idea of standard databases was brand new then, too.
Relational databases had only been brought to market in the latter
1970's. Prior to that, all databases were hierarchical in nature
and were by definition proprietary. MUMPS is a hierarchical
database. Further, all the vendors wanted to provide to their
clients a high financial barrier (a stick, not a carrot method, of
creating what in the Internet world is called a "sticky" client)
for defecting to a competing software system. Thus, despite the
presence of standardized hardware and standardized operating
systems, almost all healthcare software vendors offered a system
that was incompatible with all other systems at the doctor office,
and the technical specifications of the data and everything related
to it were top secret. The balkanization of physician software thus
remained a business fact during the transition from minicomputers
to microcomputers, each software system incompatible with the
next.
[0006] The bigger PMS ("Practice Management Software") companies
got together with the bigger insurance companies (which we
sometimes call here the "payers") and agreed on what each insurance
company needed in the way of data. The strategy of the PMS
companies was to get in the critical path of the transactions
between the medical providers and medical payers in order to
monetize their strategic position. It was said that the PMS vendors
"controlled" the doctors. They could aggregate the claims from the
medical providers and distribute to payers and do the same thing on
the payments back from the payers to the medical providers. Under
this PMS vendor strategy the system of each physician's practice
group creates a superset claim file (one with many data
elements--more than were needed) and then this claim file is
shipped directly to the software vendor or to a third party
organization (called a clearinghouse) that would then convert those
proprietary-to-the-vendor claim files into the formats that were
proprietary to-the-payer. Thus changes did not have to be done at
the edges of their client networks but could be accomplished in the
PMS vendor core--either in house or farmed out. This was not only
more economical and efficient for the PMS vendor, it perpetuated
the state in which what the doctor had on his server was not in
compliance with what the payer needed.
[0007] The software vendors, which we will sometimes call "PMS
vendors" ("Practice Management Software vendors") had created
standard meta formats at their client sites, and were sending data,
either to themselves or to clearinghouses with which they had made
lucrative deals, with their in-house proprietary format. At that
point the vendors had the data converted into
proprietary-to-the-payer formats for each of the major payers. In
those days, the clearinghouses, whether in-house at the PMS vendor
or independent, were making significant money on every transaction.
The clearinghouses were charging the payers to aggregate, normalize
and submit claims to them electronically and feed back payments to
the PMS vendors. The clearinghouses were paying PMS vendors a
percentage of that, about 35 cents for each transaction sent
through them, a small fraction of what it cost to handle those
transactions manually (The cost to handle manual claims is very
much higher than the cost to handle electronic claims.) Finally,
the PMS vendors were also charging their doctor clients for the
service. The revenue stream to PMS vendors was not based on the
dollar amount of the claim for payment but rather the number of
claims. For the clearinghouses, pediatrician clients were much more
lucrative than brain surgery clients because the former had (for
example) 20 times the number of transactions.
[0008] It is now required that if you sell health insurance that
you must offer standard format electronic data interchange. This
standard, promulgated under the auspices of the Accredited
Standards Committee (ASC) of the American National Standards
Institute (ANSI) of Washington, D.C. (headquarters) and New York,
N.Y. (operations), is known as ANSI ASC X12. The ANSI ASC X12
Standard and its related implementation guides are hereby
incorporated by reference herein and can be found at
www.wpc-edi.com. Three such implementation guides are attached
hereto as Appendices A, B and C. X12 messages are not intended to
be readable by humans. There are no spaces, carriage returns or
line feeds in the messages. Yet, current law says the only data
points sent back to the provider that are the legal basis for
appeal and review are the X12 data points.
[0009] Medicare, Medicaid and Blue Shield became a large portion of
medical business. For the most part, each computer system evolution
at the payer level was put out to the bid and the lowest bidder got
the business. The structural impact of this situation was further
balkanization of claims and payments processing software. Within a
payer, like Blue Shield of Pennsylvania, the adjudication system
could have been programmed by one company, the claims-in system
programmed by another company and the payment-out system programmed
by yet a third company. Furthermore, the maintenance of a software
system was not always performed by the same vendor as the one that
developed the system and the maintenance vendors also changed
frequently.
[0010] The balkanized software development environment of these
systems caused the payers to wind up with enterprise systems that
even within their own enterprise were not integrated. They were
interfaced. An interface can be understood as a chasm between two
systems that is a quarter inch wide and a million miles deep. The
reason, as we have explained, is that each aspect of a payer system
was typically developed independently of any other aspect.
[0011] Another thing that happened was, in all conversations
between PMS vendors and payers, the details of what happened
internally at the payers were deemed to be of no concern to the PMS
vendors, and the details of what happened inside the PMS software
was deemed of no concern to the payers. This circumstance implies
the definition of an "interface." When dealing with an interface,
you define everything that has to flow between two environments,
but you do not deal with what happens inside each of the end
environments.
[0012] In this minimalistic world of sharing, only the basics were
covered. A claim was sent by a PMS vendor. The payer did not care
if a claim was actually sent or not, nor was a record generated at
the PMS side documenting that a claim was sent (or received) or
not. The notion of what the payer did not get--but should have--was
not dealt with. The PMS software of a physician's practice simply
recorded the date on which the PMS system marked the item as
billed. The PMS would send it to a clearinghouse or a payer. The
payer may or may not have acknowledged to the submitter that they
got a file. Where there was a clearinghouse sometimes the
clearinghouse would receive this payer acknowledgement, reprocess
it, thus destroying its integrity in the sense of evidence custody,
and send its own formatted-for-printing rendering to the practice.
And sometimes not. More often the practice would get an
acknowledgement that the clearinghouse got the file.
Acknowledgements were messy affairs. They were not defined in the
PMS at the provider office as a data element. They were not
charges; they were not payments; they were not adjustments. They
were files and PMS software pretty much viewed the world as
charges, payments and adjustments. The process of sending and
receiving data streams was necessary for input and output to occur
but almost nothing about those processes was recorded in a
meaningful way within the PMS. Provider clerks would dial in to
receive formatted reports via download processes, suitable for
printing, which would tell a human being who caused the claim file
to go out that the file had been received. The human being received
a piece of paper--a "report"--that said "file #XYZ was received." A
line item had a certain claim number and that claim number was
billed on such and such a date and there was only one file for that
date, so the "report" that said "items had been received from a
specific company for that date" must have included that claim
number. But that "report" was a piece of paper. Even if you file it
in a physical cabinet, it is electronically inaccessible.
[0013] Most insurance companies have a strict first gate process in
which they decide if they are accepting the file, if it is
syntactically correct, if it contains claims from providers they
recognize, etc. This system, employed by a payer, determines
whether the whole file of claims should be accepted or rejected for
processing. This evaluation generates an acknowledgement. This
acknowledgment is not a part of the charge line item history record
in the normal PMS database. And as stated previously, there is no
guarantee that this acknowledgement gets to the medical
practice.
[0014] Then the accepted claim goes to a second system, which
determines for each claim if the patient is covered under the
insurance policy. The second system has output that says "yes,
there is coverage" or "no, there is not coverage" for each claim
and contains the specific reason for the denial. All payers known
to the applicant herein say they generate such a coverage
determination. They make it available to the clearinghouse.
[0015] Following the coverage determination, there is an
adjudication leading to a flat-out denial, a partial payment or a
full payment. Rarely is there a full payment. 99% of payments
involve a partial payment. The payer sends back a file that
explains the payments and the denials. The PMS systems were
programmed to read this file (generically called an "electronic
EOB", short for "Explanation of Benefits") and make the payments
and adjustments that were outlined in this file.
[0016] In other words, the transactions between the medical
practice provider and the payer (whether through a clearing house
or not) involve the following sequence, from the point of view of
the medical practice:
[0017] 1. Claims generation.
[0018] 2. Claims submission.
[0019] 3. Claims receipt.
[0020] 4. Eligibility receipt
[0021] 5. EOB back to provider
[0022] 6. Payment to provider
[0023] Yet although the transactions involved these six distinct
activities, the only reasonably accessible electronic records
generated for use by the average PMS system are:
[0024] 1. Claims generation.
[0025] 5. EOB back to provider
[0026] Finally, as we have discussed, the payers have different
systems in their own enterprise that are interfaced. The claim
comes into one system and is then accepted or rejected. It then
goes to another system for the eligibility phase and it is accepted
or rejected and it then goes to another system for the adjudication
process where it is accepted and paid in full or part or denied. If
a medical practice sends in claims by paper it hits one system. If
it sends in claims electronically in one format the claims hit a
different system. If it sends in claims using the X12 standard, the
claims could hit another system.
[0027] The model of current PMS software is to seek redress one
claim at a time. The tools developed by the PMS vendors and the
insurance payers support this approach, and the published
procedures by which the providers are supposed to contact the
payers support this approach. And prior to X12, providers did not
even have the actual codes by which the payer had to legally defend
its position.
[0028] This "appeal one claim at a time" model that all PMS systems
known to the applicant use seems improbable until one examines the
process by which PMS vendors developed the functionality of their
software. The PMS vendor programmers got their input from the PMS
vendor salespersons. The PMS vendor salespersons got it from the
medical provider office managers. And the medical provider office
managers got it from the insurance payers. Thus the payers drove
the development of the PMS functionality and that is why all PMS
software works similarly.
[0029] These systems do not scale. The larger the medical practice
the higher the expense to seek payment from the payers. Systems
that do not scale do not have fixed cost to revenue expense ratios;
they have adverse ratios. They have adverse economies of scale.
Thus, the larger the medical practice gets using tools that do not
scale to seek payment from payers, the more expensive per
transaction it becomes to seek that payment.
[0030] This is part of the reason there are so few large practices.
The frenzied mergers of medical practices in the 1990's, all
seeking to achieve economies of scale and negotiation muscle with
payers have largely been undone. The sheer amount of data, the
quasi-automation ("manu-mation") work flow systems, the missing
data elements necessary to manage appropriate payment, all
conspired to make the larger units even less efficient than the
smaller component parts, and the cost to handle each transaction
went up, not down.
[0031] Following adoption of the ANSI X12 standard, software
systems used by payers have been modified to accept claims for
delivery of medical services that use the X12 format. However, for
reasons described previously, the X12 format has not been
universally rolled out. In most cases, even though the insurer must
accept claims in the X12 format, clearinghouses, by arrangement
with the PMS vendors, continue to accept proprietary formats from
medical providers, and then translate claims aggregated from
multiple physician practices into X12 or an agreed proprietary
format worked out with the insurer. The reverse happens for any
transactions that get back to the medical provider using the
traditional PMS. We illustrate in FIG. 1 a typical prior art scheme
pursuant to which doctors' services are paid. A claim may originate
from a physician practice through a health care service provider
system 20, using some proprietary PMS system generating a claim in
a proprietary format. This claim goes to clearinghouse 22, where
the claims are processed into some format (which may typically be a
format developed under agreement with the insurer, but may
alternatively be in X12 format) for communication with the payer
proprietary reimbursement processing system 14 of the insurer.
Accordingly, the physician practice communicates only via the
clearinghouse with the insurer and never has a direct link with
processes going on at the insurer, and does not know how the
reports from the clearinghouse mesh with processes that are
followed by the insurer in handling claims from the physician
practice.
[0032] The clearinghouses typically give the health care service
providers a printed report identifying claims that will not or have
not been accepted by the insurer. This report may or may not be an
analog to an X12 file level rejection (an X12 997 transaction). The
clearinghouse may or may not give more detail, such as the reason
for the rejection. The health care service provider must then
unbill the entire file of claims, then locate and fix or remove the
offending claims and rebill, transmitting the revised file to the
clearinghouse. This process is performed iteratively by hand until
the file gets accepted.
[0033] The insurer then sends back to a clearinghouse a File 277 or
proprietary file, which is an eligibility determination prior to
adjudication. The clearinghouse may or may not read and/or process
the determination and may or may not notify the physician practice.
Without the forwarding to the PMS of this determination, from the
point of view of the traditional PMS and interchange arrangements
between the provider and payer, claims that have been filtered out
by this determination simply disappear from the final payer
response. The only clue that something is amiss is that the items
on the doctors' medical billing system age. Such aging claims
require manual attention and this requirement for manual attention
acts adversely to economies of scale. Recently payers and
clearinghouses have taken to making available on a website issues
like this. But this, as are most all current state of the art
systems, is also outside the PMS system and not part of an
actionable data element within the PMS.
SUMMARY OF THE INVENTION
[0034] In accordance with an embodiment of the present invention,
the computerized method of managing requests by a health care
service provider for payment includes submitting multiple claims
electronically in a single file and responding to any file level
rejection by re-creating the multiple claim file request without
the rejected claims. A denial record is created for every rejected
claim. The acts of submitting multiple claims in a single file and
responding with a re-created file are repeated automatically, as
necessary, until the single file is accepted. These acts are
performed by the computer system without requiring human
intervention.
[0035] An embodiment of the present invention further includes
associating with each claim for payment, a unique identifier. The
identifier is placed in a field required by standards to be
preserved by the payer in the course of processing. Thereafter, in
connection with any transaction involving a rejection for payment
of a given claim, that transaction is stored in association with
the identifier for the given claim. Unique identifiers are also
advantageously associated with each line item of a claim. Again,
the identifier is placed in a field required by standards to be
preserved in the course of processing, so that a record of all
transaction events may be maintained for each line item. In one
embodiment, partial payments to line items are compared to expected
payments and are processed in the same way as rejected line items
if the partial payment is unsatisfactory.
[0036] An embodiment of the present invention further includes
receiving, over a network, an explanation of benefits. The
explanation of benefits contains the unique identifiers associated
with claims and line items, a check number, and procedure codes
associated with the line items. The explanation of benefits is
stored in association with the unique identifiers.
[0037] A co-payment processing method of the invention operates on
the explanation of benefits received from the payer. In one
embodiment, all co-payments previously collected by a medical
provider are reversed to a suspense account in the healthcare
service provider system for all line items referenced in the
explanation of benefits. In another embodiment, the co-payment
allocations in the explanation of benefits and the health care
service provider system are compared, and only those line items
with differing allocations are reversed. Then the co-payment is
re-allocated from the suspense account in the health care service
provider system to the line item to which the allocation was made
in the explanation of benefits so that the PMS data exactly mirrors
the payer allocations. In this way time is not wasted in attempting
to reconcile different handlings of the data. The PMS and the
payers systems are brought into conformity. The payer can not avoid
or delay payment by stating that the provider system is
inaccurate.
[0038] Adjudication codes received in the explanation of benefits
are mapped to associated actions. Action codes of Suspend,
Write-Off, Transfer, and Null are assigned in the map-to look up
table so that the adjudicated amounts can be handled accordingly.
The Write-Off action will cause the system to make an adjustment
for the adjudication amount as specified in the explanation of
benefits. The Transfer action will cause the system to transfer the
balance of the line item to a next payer and does not adjust the
adjudication amount. Suspend will neither adjust the adjudication
amount nor cause a transfer. Furthermore, it will prevent or
suspend any other Transfer action on the line item from taking
effect. The Null action has no effect.
[0039] Check numbers received in the explanation of benefits are
used to identify deposits to the health care service provider's
bank account and associate the deposits with the appropriate claims
and line items in the explanation of benefits. A user is
periodically notified electronically of all deposits received since
the previous notification. In one embodiment, this is done by
electronically accessing the health care service provider's bank
account transaction history and processing the transaction history
using a screen scraper. This enables posting dates within the PMS
and actual deposit dates to be identical.
[0040] Procedure codes used in the explanation of benefits are
associated with line items. Procedure codes and the amounts paid to
their associated line items over a large history of transactions
are stored in a relational data base configured according to a star
schema. The payments are subjected to statistical analysis. A model
set of expected payments for the procedure codes is also generated
and analyzed. The two statistical analyses are then used to
calculate a metric relating payments received to the expected
payments. The actual payments, the expected payments, and the
metric are displayed in a table, graph, or any other convenient
format. If the metric is outside of a predetermined range for one
of the procedure codes, the user is alerted of the procedure
code.
[0041] An embodiment of the present invention further provides a
denial management system. A denial management operator selects a
plurality of line items. The denial management system presents a
denial management operator with a screen showing the plurality of
line items. The denial management system allows the denial
management operator to then select any particular one of the line
items, and provides a screen wherein data fields associated with
the line item can be edited. The denial management operator may
also change the status of the line item in the claims management
system directly through the screen.
[0042] An embodiment of the present invention further provides an
automated claim resolution system. Rejected claims are
automatically selected that have data fields containing the same
values as each other. If the common data value is incorrect, a user
corrects the value by means of a single manual edit, and the system
automatically applies the change to each of the selected claims.
The claims are then marked as partially resolved, and once a claim
has no remaining unresolved denials it can be resubmitted.
[0043] An embodiment of the present invention further provides an
automated settlement posting function. A check is received from a
payer as part of a settlement agreement covering a plurality of
claims. The settlement check must then be distributed across the
plurality of claims. First the total disputed payment amount across
all the claims covered by the settlement is calculated, and then
the user may choose a rule by which to apply the settlement amount,
the simplest being a ratio calculated by dividing the amount of the
settlement check by the total disputed payment amount and then
reducing each outstanding charge by this ratio and marking it as
paid in the database.
[0044] The foregoing features of the invention will be more readily
understood by reference to the following detailed description,
taken with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0045] FIG. 1 is a schematic block diagram of a medical claims
management system of the prior art.
[0046] FIG. 2 is a schematic block diagram of a medical claims
management system in accordance with an embodiment of the present
invention.
[0047] FIG. 3 is a flow chart of actions performed by a medical
claims management system in accordance with an embodiment of the
invention.
[0048] FIG. 4 is a flow chart of a file submission process in a
medical claims management system in accordance with an embodiment
of the present invention.
[0049] FIG. 5 is a flow chart of a pre-adjudication handling
process in a medical claims management system in accordance with an
embodiment of the present invention.
[0050] FIGS. 6A-B are flow charts of payment reconciliation
processes in a medical claims management system in accordance with
two embodiments of the present invention.
[0051] FIG. 7 is a flow chart of an adjudication code handling
process in a medical claims management system in accordance with an
embodiment of the present invention.
[0052] FIG. 8 is a flow chart of a deposit verification process in
a medical claims management system in accordance with an embodiment
of the present invention.
[0053] FIG. 9 is a flow chart of a statistical payment analysis
process in a medical claims management system in accordance with an
embodiment of the present invention.
[0054] FIG. 10 is a flow chart of a settlement posting process in a
medical claims management system in accordance with an embodiment
of the present invention.
[0055] FIG. 11 is flow chart of a simultaneous claim resolution
process in a medical claims management system in accordance with an
embodiment of the present invention.
[0056] FIG. 12 is a user interface illustrating management of a
co-payment in accordance with an embodiment of the present
invention.
[0057] FIG. 13 is a schematic block diagram of a medical claims
management system in accordance with an embodiment of the present
invention.
[0058] FIG. 14 is a user interface illustrating a screen in a
denial management system in accordance with an embodiment of the
present invention.
[0059] FIG. 15. is a user interface illustrating a screen in a
denial management system in accordance with an embodiment of the
present invention.
DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
[0060] Definitions. As used in this description and the
accompanying claims, the following terms shall have the meanings
indicated, unless the context otherwise requires:
[0061] A file 835 is an ANSI ASC X12 file that provides an
explanation of benefits from the payer. It itemizes the charge
received from the health care service provider, the amount paid by
the payer, and then for each part of the charge that it does not
pay it itemizes that amount and associates it with an adjudication
code. It may be accompanied by one or more checks.
[0062] A "payment" as used herein is a payment transaction
described in an explanation of benefits from the payer. It
identifies an amount of money for a specific charge.
[0063] A "check" as used herein is a set of related payments
associated with an explanation of benefits, such as a file 835. The
payments may be provided by a paper check, electronic funds
transfer or any other commercially accepted manner.
[0064] A "health care service provider" as used herein is a person
or entity that provides services to customers and seeks at least
part of the payment for those services from a payer by submitting
claims according to a standard for health care claims, such as the
ANSI ASC X12 standard.
[0065] Referring now to FIG. 2, a medical claims payment system in
accordance with an embodiment of the invention is shown. A claims
management system 30 has been added in connection with the health
care service provider system 20. The connection can be made over a
network or a direct hardwired connection or the two systems might
be integrated into a single system. The network may be any of a
number of communication channels including but not limited to the
Internet, a wide area network, a local area network, a wireless
network, a cable connection, a satellite connection, or a telephone
line connection. The medical claims management system 30 performs
several unique functions directly in the X12 environment to assist
the health care service provider in obtaining its rightful payment
for medical charges. Moreover, it is desired that the claims
management system 30, accelerate and simplify the processing of
claims between the health care service provider and the payer. For
example, the claims management system may aggregate claims into a
file for electronic submission over a network to the payer
proprietary payment processing system 14. As set forth above a
network may be any of a number of communication channels including
among others the Internet. To accelerate acceptance of the claims,
the claims management system may be programmed to automatically
respond to a file level rejection. For example, by removing
rejected claims from the claim submission file, a new file may be
sent out with the remaining claims. Should the file be rejected
again at the file level, the claims management system automatically
performs this process again until a file level acceptance of the
claims file is obtained. In addition, to provide the health care
service providers with better information for challenging the
rejection of medical charges, the medical claims management system
30 of embodiments of the present invention may uniquely identify
each line item charge. This unique identification is preferably one
that is preserved in the X12 system so that a complete longitudinal
record of all electronic transactions relating to that charge may
be maintained by the claims management system.
[0066] In addressing issues of denials in the medical claims,
misallocated co-payments by the health care service provider can be
handled by the claims management system 30. By "misallocated
co-payments," we mean only that the allocation of the co-payment by
the health care service provider differs from the line item to
which the payer allocated the co-payment. To avoid this, the
medical claims management system 30, for all line items addressed
in an explanation of benefits received over a network from the
payer system, moves the allocation of co-payments in the health
care service provider's system to a suspense account and then
reallocates the co-payment from the suspense account in accordance
with the co-payment adjudication that was made by the payer's
proprietary payment processing system. This unallocation and
reallocation of the co-payment is made possible by the ability to
track all transactions relating to a unique identifier for each
line item charge.
[0067] Each line item charge may result in a variety of actions by
the payer system. For example, a payment may be made for a portion
of the charge, another portion of the charge may be subject to a
co-payment and the total charge may be reduced due to a capitation.
Each of these actions by the payer system is accompanied by an
adjudication code. In the past such codes were known as HCFA codes,
but a claims management system of the present invention may be
programmed for operation with any such system of known codes. These
codes may be translated by the claims management system. In
accordance with an embodiment of the invention, the translation may
include an indication of whether the adjudication code is favorable
or unfavorable. It is recognized that some adjudication codes are
not necessarily favorable, such as when the payer has indicated the
patient was not covered. If any of the adjudication codes
encountered with respect to a line item is unfavorable then that
line item will be added to the denial management queue. If no
adjudication code is encountered that is considered unfavorable for
a line item, the system can automatically proceed with the actions
associated with the line item. Thus, the claims management system
maps the adjudication codes to codes that allow the system to
automatically complete the processing of those line items that have
been favorably resolved and send to denial management those claims
that require further attention. A denial management operator will
then be provided with an opportunity to review the items in the
queue to resolve any denials of payment that are not properly
substantiated or that are properly substantiated and require
corrective action on the part of the health care service provider.
Given that the claims management system in accordance with
embodiments of the invention provides a longitudinal record of the
dates, content and payer file names of all electronic transactions
relating to each line item, a denial management operator has access
to all the information he or she needs to challenge an improper
denial with the payer.
[0068] The medical claims management system 30 runs on a computer
system. Program code runs on the computer system that performs,
inter alia, some or all of the actions set forth in FIG. 3. These
computer programmed aspects of the medical claims management system
of an embodiment of the present invention will now be described.
The charges that a health care service provider wishes to submit
for payment to the payer are obtained by the medical claims
management system. Information as to the charges may be provided to
the payer directly over the network by the health care service
provider 20, or alternatively, the health care service provider and
payer may make use of a clearinghouse 22, whose system would
interface with the medical claims management system to provide to
the payer the information as to the line item charges.
[0069] In accordance with an embodiment of the present invention, a
processing flow begins 100 by entering the file submission phase
200. The file submission phase will now be described with reference
to FIG. 4. In accordance with an embodiment of the present
invention, a unique identifier is generated from data from the
health care service provider system 20 for each claim 210. With
respect to the ANSI X12 electronic claims submissions standard, the
field CLM01 will be found useful for this purpose. In preferred
embodiments, the unique identifier for CLM01 is created as a
combination of data including whatever database element the
provider practice management system uses to identify the charges
that will be aggregated into one claim and additional data elements
such as the account number, dataset number identifying the payee,
policy holder's number or other identifying data of the medical
charge. Further in accordance with embodiments of the present
invention, a unique identifier may be associated with each line
item in a claim 220. In accordance with the ANSI X12 electronic
claims submissions standard, the field REFER may be found to be
particularly useful for this purpose. In accordance with the ANSI
X12 standard, the data fields CLM01 and REF6R are required to be
preserved in the transactions sent back and forth electronically
between a payer and the representatives of the medical
provider.
[0070] Multiple claims once uniquely identified are aggregated into
a single file submission 230. In accordance with the ANSI X12
standard, the outgoing claims file is known as a file 837. The
payer system first reviews the 837 on a file level. Either the file
will be accepted or rejected at this level 240. The acknowledgement
response from the payer in accordance with the ANSI X12 standard is
known as a 997. Rejections at this level typically relate to the
credentials of the health care service provider and syntactical
errors. If there is an error then a file 997 rejection may be
appropriate. Rather than simply print out a record of the rejection
and await manual intervention, embodiments of the present invention
make a record 250 of the 997 in association with the unique
identifiers of the affected claims and underlying line items. The
medical claims management system 30 then automatically re-generates
a claims submission file without the offending claims 260. The
maintenance of the denial record and the resending over the network
of a claims submission file (such as a file 837) continue
iteratively until an acceptance is received.
[0071] After file level acceptance is received, the payer may
conduct a pre-adjudication review. In this review, claims are
either passed on to the adjudication system or may be denied for a
number of reasons. Typically though at this level denials relate to
the patient credentials. Perhaps the patient policy number, name or
address has been misspelled or mistyped. The pre-adjudication
processing 300 is now described with reference to FIG. 5.
Pre-adjudications, both acceptances and denials, sent from the
payer are received by the medical claims management system 30 and
recorded in association with the related claims and underlying line
items 310. In accordance with the ANSI X12 standard, the
pre-adjudication is a file 277 and the unique identifiers in the
fields identified as CLM01 and REF6R are included in the 277. Thus,
for any line item the claims management system 30 knows right away
if the claim in which it appeared made it through this
preadjudication phase or was denied and, thus, not passed on the
adjudication system. If the line item was denied 320, the item is
passed to a denial management queue 330 where the pre-adjudication
denial can be immediately addressed by the health care service
provider 1000.
[0072] Claims that pass file level and pre-adjudication reviews are
submitted to full adjudication in the payer's system. Adjudication
produces an explanation of benefits which is received over the
network and recorded 400 by the medical claims management system
30. The explanation of benefits is stored in association with the
unique identifiers relating to the claim and line items it
references. At this point in the processing flow, it is
advantageous to provide a payment reconciliation process 500, which
is now described with reference to FIG. 6A. In accordance with an
aspect of an embodiment of the present invention, after receiving
an explanation of benefits over the network, for all line items
addressed in the explanation of benefits any patient payments
including co-payments are reversed 510, removing them from their
respective line items and putting the payments or co-payments into
a suspense account associated with the patient.
[0073] It is preferable that the claims management system 30 have
access to the health care service provider system 20 for making all
required payments and adjustments. There are several ways to
interact with any computer database system. Some health care
service provider systems may employ proprietary tools designed for
exactly this purpose. Other systems also have proprietary tools
that allow other programmers to write applications that hit the
billing system in real time, just as the native billing system
routines do. More modern systems are built on SQL compliant
databases. There is also a standard called ODBC (Open Database
Connectivity) that certain health care service provider systems may
require. So an application makes calls to a database server for
records to read and sends data to the database server to write.
[0074] The claims management system 30 locates the line item to
which the payer allocated the co-payment (or other payment) and
similarly allocates the co-payment (or other payment) to that line
item from the suspense account 520. Again, this reallocation of the
co-payment or other payment is preferably entered into the health
care service provider system 20. The money is thus taken out of the
suspense account and allocated to the line item consistent with the
payer's allocation. The records of the payer and health care
service provider are thus advantageously aligned, so that
discrepancies can be more easily found and sorted out.
[0075] Because not every patient payment will be assigned
inconsistently with the assignments in the explanation of benefits,
it is further desirable to avoid reversing those payments that are
assigned consistently with the explanation of benefits. A payment
reconciliation process 500 in accordance with another embodiment of
the present invention is here described with reference to FIG. 6B.
The claims management system 30 compares the line items to which a
payment was assigned in the health care service provider system 20
and by the payer 515. For only those payments that were assigned
differently, the payments are reversed into the suspense account
525. Then the claims management system 30 allocates the co-payment
(or other payment) to the line item to which the payer assigned it
from the suspense account 520.
[0076] The explanation of benefits provides adjudication codes for
each adjudication decision made by the payer with respect to a line
item. It is helpful in evaluating and resolving denials for the
adjudication codes to be translated into mnemonic terminology that
can be more easily understood by human operators reviewing the
records. It is also helpful that multiple similar payer
adjudication codes be grouped by concept into fewer user friendly
mnemonic codes. Moreover, the system can be programmed to respond
to certain adjudication codes by taking certain automatic actions.
An example of a configurable look-up table that may be stored in a
database accessible to the medical claims management system is
provided in Appendix A. For each payer adjudication code, the
medical claims management system 30 allows the entry and storage of
a narrative description, an action, a translated code, its
narrative description and, if desired, a favorability indicator.
For example, the payer adjudication code 1 (which in this case is a
HIPAA Claim Adjustment Reason Code) means Deductible Amount.
Medical insurance policies typically include a deductible amount
that must be paid by the patient before the insurance company will
assume liability. The action corresponding to adjudication code 1
is "Transfer." To carry out a transfer, the medical claims
management system 30 would apply any credits dictated by the
explanation of benefits and then automatically transfer the balance
of the line item which would include the deductible amount to the
next payer (another insurance company or the patient) as specified
in the health care service provider system 20 so that a bill can be
sent out by the health care service provider to the next payer. The
health care service provider typically maintains a list of payers
applicable to the patients therein. Thus, payment for the
Deductible may be sought from a secondary payer. If there are no
additional insurers on the list, the charge could be sent to the
patient for payment. This whole process happens automatically. A
Deductible adjudication code was considered favorable in this table
because it does not present a reason for insertion into the denial
management work queue for human review. The two letter translated
code (under column header Den) is more easily recognizable than the
numerical adjudication code. The letters are selected as an
abbreviation or mnemonic code. For example, for Deductible
adjudication codes the translated code is DE and there are multiple
Deductible codes that translate to DE (see adjudication code 126).
The message is a description of the translated code. Finally, the
last field under column Dny is the favorability indicator.
[0077] A Transfer action has just been described above. A Write-Off
action is performed by reducing the amount of the charge by the
amount specified in the explanation of benefits. A Suspend action
will take no action on the amount specified for the adjudication
code that is mapped to Suspend and will, further, suspend any and
all Transfers on the same line item, thereby preventing the balance
from transferring to the next payer. A Null action will have no
effect, so that effectively an adjudication code that is mapped to
Null will be ignored. The use of a unique identifier with each line
item when the claim was submitted by the medical claims management
system to the payer forced the payer to use the unique identifiers
in the explanation of benefits it sent back to the health care
service provider. Thus, the medical claims management system can
reliably identify the line item for all adjudications
received--even if in the explanation of benefits the payer has
changed data elements like account number or procedure code.
[0078] One process flow for performing the actions specified by the
lookup table 600 is given in FIG. 7. The medical claims management
system is programmed to look up in the lookup table 610 the
adjudication codes listed in the explanation of benefits. The
action corresponding to the adjudication code will be performed by
the system. If no adjudication with a Suspend action is encountered
on the line item 620 and an adjudication code with a Transfer
action is encountered on the same line item a Transfer 630 to next
payer will be performed. If an adjudication code with a Write Off
action is encountered 640 then a Write Off action is performed 650
by reducing the amount of the charge by the amount specified in the
explanation of benefits. If an unfavorable adjudication exists for
a line item 660, as specified by the Dny field in the lookup table
then the line item will be added to the denial management queue
670. Because no action is taken for Null actions, the step of
processing adjudication codes mapped to the Null action is not
shown in FIG. 7.
[0079] In some embodiments the claims management system 30 may
perform the further step of evaluating any partial payment to
determine whether or not the partial payment is too low 680. In
very many cases, partial payments are what is expected and
accepted, such as when a proper capitation is taken, for example.
But in other circumstances, the partial payment may be much lower
than expected, and it will be advantageous to allow an operator to
examine the circumstances of the partial payment. A variety of
methods are available for evaluating whether a partial payment is
satisfactory or unsatisfactory. A schedule of minimum satisfactory
payments may be developed relating to a set of medical procedure
codes included in the explanation of benefits. Analysis of payments
and procedure codes is discussed in greater detail below. Also, a
minimum satisfactory payment per generic charge may be set, such
that, e.g., any payment below $50 will be held over for denial
management. Additionally, limits could be placed on the amount of a
charge that can be reduced in association with a given adjudication
code without triggering denial management. For instance, a
"Prompt-pay discount" (currently code 44, see Appendix A) is
associated with a Write-Off action. But a limit could be set such
that, e.g. more than 20% of a charge cannot be written off in
association with this code. If a payment is unsatisfactory because
it is lower than expected, the transaction is added to the denial
management queue 690 and stored in association with the unique
identifiers.
[0080] Because the explanation of benefits has described a payment
there will also be a check associated with the payment, and so the
additional step of verifying the deposits 700 can still be
performed. The use of a unique identifier with each line item when
the claim was submitted by the medical claims management system
forces the payer to use the unique identifiers in the explanation
of benefits. Thus, the medical claims management system 30 can
unerringly identify and reliably examine all adjudications
corresponding to each line item.
[0081] When an explanation of benefits provides information
regarding amounts of payments assigned to line items, it also
includes at least one check number. This check number can be used
advantageously to verify that the payments described in the
explanation of benefits have actually been received. It is further
advantageous to perform the verification automatically, without the
need for costly manual processing. A deposit verification process
700 in accordance with an embodiment of the present invention is
now described with reference to FIG. 8. The medical claims
management system 30 can be advantageously configured to identify
deposits that are received in the health care service provider's
bank account 710. One way of achieving this is to access the health
care service provider's bank account transaction history over the
network. The bank account transaction history may be displayed on a
screen and processed with a screen scraper to extract the needed
information. Once a deposit has been identified, it can be
associated with a claim in an explanation of benefits 720 and
recorded in the claims management system 30. This is preferably
done by identifying a deposit and a payment to a claim in an
explanation of benefits having the same associated check number.
The system can notify a user periodically of the identified
deposits. In an embodiment of the present invention, an electronic
notification, such as an e-mail, text message, or electronic report
accessible via an intranet portal, is delivered to the user every
morning, describing all transactions that were processed the
previous day. This allows the health care service provider to
monitor payments received without ever having to query the bank
account and without having to perform a tedious and costly process
of manually examining the bank account transaction history and then
manually entering each individual payment received into the claims
management system 30. Once a deposit is received and verified, the
line item in question exits this section of the dynamic processing
flow according to an embodiment of the present invention 1000 to
await static processing, such as statistical analysis or denial
management.
[0082] One difficulty facing health care service providers is the
inefficiency of the classical dispute resolution model, wherein if
a health care service provider believes that a payer is
consistently underpaying claims, it is not feasible for the health
care service provider to appeal each individual underpayment, where
the value of the individual underpayment may be very small, while
the number of disputed transactions is very large. Therefore, it is
advantageous to be able to track and analyze payment patterns over
a great number of claims, such that a comprehensive analysis can be
performed on the data as part of a settlement negotiation with a
payer. Such a statistical payment analysis process in an embodiment
of the present invention is now described with reference to FIG. 9.
Payment data is assembled 1110 from a plurality of previously
processed claims. Claims may be selected by date, payer, health
care provider, medical procedure, and/or other data fields. From
the claims, the data preferably contains a procedure code
identifying for what medical procedure the charge was made. The
data also preferably contains the amount paid by the payer
associated with the procedure code. Because it is preferred that a
very large volume of data is analyzed together, it is preferred to
store the data in a relational database or data warehouse. In one
embodiment of the present invention, a relational database is
arranged according to a star schema. Use of star schema relational
databases is known in the art to involve a space-time tradeoff,
wherein greater redundancy is built into the data model, meaning
that greater storage space is required, but processing of existing
data entries is faster and easier. Because the present process does
not involve the data entry process, this tradeoff is preferred as a
method of decreasing processing times.
[0083] Having the payment data available in a star schema database,
the payment data containing the unique identifiers associated with
all transactions for the claims and their respective line items, it
is now possible to analyze the payment data 1120 to determine
long-term patterns. The claims or subsets of the claims may be
viewed and analyzed according to data filters such as date ranges,
procedure codes, doctor providing care, or any filter on any of the
data fields represented in the payment data. In one embodiment, the
history of a claim, i.e., its longitudinal record can be made
accessible through a cross-tab (called a pivot table in EXCEL) so
that the operator can click on an item and get the detail to pop
up. In another embodiment of the present invention this analysis
includes the step of calculating an average payment received from a
payer in association with each procedure code. A set of expected
payments is also generated 1130. According to an embodiment of the
present invention, the expected payments may be generated using
standard Medicare reimbursement values. The standard Medicare
reimbursement values may be adjusted by an across-the-board premium
factor, where, for example, a health care service provider could
set the expected payments to be 110% of the Medicare schedule for
each procedure code on the schedule. In another embodiment of the
present invention, the expected payments could be generated from
historical payment data relating to a payer. The payer may be a
different payer from the payer represented in the payment data in
1110, or the payer could be the same payer, in which case the
historical payment data would preferably relate to a different time
period than the payment data in 1110. The expected payment data may
then be analyzed 1140 to identify trends or anomalies. For example,
historical payment data from a different payer could be compared to
historical payment data from a third payer, or it could be compared
to the Medicare schedule, and notable differences, such as specific
procedure codes achieving significantly different average payments,
could be recorded for further analysis. Once actual payment data
and expected payment data have been assembled, generated, and
individually analyzed, they may finally be analyzed together to
calculate a metric 1150 relating the two data sets. In one
embodiment of the present invention this metric may be a ratio
between the actual payment data for a procedure code and the
expected payment data for the procedure code. Other metrics could
include, for example, a difference in total payment amounts between
the two data sets, or a count of how many procedure codes are
underperforming and overperforming compared to their expected
payments. The results of this process can then be reported to the
user in a variety of ways. The payment data and expected payment
data may be displayed together with the calculated metric in a
table or a graph. The report to the user could also be in the form
of an alert, wherein the system periodically calculates the metrics
and generates an alert whenever the metric relating to a particular
procedure code falls outside a predetermined acceptable range. The
alert could be in the form of an email, text message, etc.
[0084] A settlement posting process in accordance with an
embodiment of the present invention is now described with reference
to FIG. 10. In some cases, a health care service provider may
dispute a very large number of claim payments with a payer and
successfully negotiate a settlement with the payer in resolution of
all the disputed claims. For example, the statistical payment
analysis process described above may be useful for this purpose,
allowing the health care service provider to present the payer with
the selected claims and the statistical analysis in support of a
settlement campaign. In such a case, the health care service
provider may receive a single check covering the entire settlement
1310. It is advantageous to be able to process this check and
resolve the disputed claims automatically in accordance with the
principles of this invention. We have seen that in the case where
the claims management system 30 receives an explanation of
benefits, the claims management system 30 can automatically process
any associated checks and associate the payments with the proper
claims and line items in the database. Because the system already
has an electronic record from the statistical payment analysis
process of what claims were disputed, it is possible to post these
payments to the claims automatically. The system may also treat the
value of the settlement check as if it were divided into individual
payments to the individual claims covered by the settlement 1320. A
user may select a rule for applying the settlement check to the
claims. One rule the user may select includes dividing the value of
the settlement check by the total outstanding value of all claims
covered by the settlement, thereby calculating a ratio. That ratio
may then be multiplied by the outstanding value of each relevant
claim, and a payment can be made to the claim from the settlement
check for that amount. Other rules could include applying a fixed
amount, such as $10, to each claim. For each claim, the amount of
the payment from the settlement check is applied to the outstanding
charge as a partial payment 1330. Because the health care service
provider has agreed to settle the claims with the payer, any
unaccounted for remainder of the charge is then subject to a
settlement adjustment 1340, and the claim is considered to be fully
paid, with respect to the settling payer. The system may take
further actions on the amounts receiving a settlement adjustment,
including writing some or all of the amount off, or transferring
some or all of the amount to a next payer, such as the patient. The
fact that the charges are marked as having received a settlement
adjustment 1340 will allow the Provider to recognize in the future
that this line item received final adjudication through settlement
negotiations, and thus the other, standard adjustment codes will
not fully reflect the correct amounts that were paid and
rejected.
[0085] Operators accessing the medical claims management system can
get directly to any denied claims through the denial management
queue. Many denials will be easily resolved by correcting data
errors such as patient name, policy number, sex, date of birth or
medical provider and the corrected charges can be automatically
resubmitted to the insurer for payment, written off, transferred
and billed to another payer, or voided and optionally re-entered as
a new charge transaction directly from the denial management queue.
Other claims will be determined to be incorrectly denied. Such
denials may be collected and in aggregate and detail presented to
the insurer along with the complete stored record of all actions
taken by the insurer with respect to that claim. This longitudinal
record that precisely mirrors the output of the payer system and
contains what was paid, what was not paid, why, and when these
events took place, all tied to the unique identifier of a denied
line item charge, gives the clearinghouse or medical provider
significant leverage in getting a nonpayment resolved more quickly.
In the case of X12 electronic transactions, the actual files 997,
277 and 835 can be pulled up easily and presented to the payer
showing a command of the information relevant to the claim denial.
The true point of contention can be quickly focused upon making
efficient resolution of the matter more likely.
[0086] A denial management system is now described with reference
to FIGS. 14-15. A denial management operator selects a plurality of
line items. The plurality of line items may be selected by
specifying any variety of data elements including, but not limited
to, date range, payer, procedure codes, types of denials, status,
denial category, etc. The denial management system presents the
denial management operator with a screen showing the plurality of
line items 1400. The denial management system allows the denial
management operator to then select any particular one of the line
items, and the denial management system provides a screen wherein
data fields associated with the line item can be edited 1500. These
fields may include, for example, provider NPI, referring doctor
NPI, patient date of birth, patient SSN, patient insurance policy
ID, etc. In one embodiment of the present invention, adjudication
codes associated with the line item are associated with specific
data fields, and only the associated data fields may be edited by
the denial management operator through this screen 1500. The denial
management operator may also change the status of the line item in
the claims management system directly through the screen 1500. From
this one screen, the denial management operator also may post a
financial adjustment to the line item, transfer the line item to a
different payer, rebill the line item, void and optionally reenter
the line item, put the line item on hold, or push the line item to
a supervisor for review.
[0087] In some cases, a particular type of error will occur across
many claims. For example, a policy number may be entered into the
system incorrectly, leading to a series of rejected claims relating
to an incorrect policy number. It is advantageous to be able to
correct these kinds of errors quickly, without the need for an
operator to manually fix the same error over and over. A process of
simultaneous claim resolution in accordance with an embodiment of
the present invention is now described with reference to FIG. 11. A
plurality of rejected claims in the denial management queue may be
automatically selected according to a shared value in a field 1210.
The operator may then select a new value for the field 1220, such
as the correct policy number in the above example. The claims
management system 30 may then automatically edit the contents of
the field in each of the rejected claims 1230 from the previous
incorrect value to the new, user-defined value.
[0088] In many common cases, such as with incorrect demographic or
insurance coverage information, the adjudication code associated
with the line item can be associated with the data field that needs
to be resolved. Partial resolutions from editing these data fields
can then be associated with the appropriate adjudication codes. For
example, an adjudication code may indicate that a diagnosis for a
patient was inconsistent with the recorded gender of the patient.
This adjudication code could thus be associated with the patient
gender field. When the process above is used to edit the data field
for patient gender, the system can then record that the related
adjudication code has been addressed. If a line item no longer has
any unaddressed adjudication codes, in some embodiments the system
may be programmed to automatically resubmit 1250 the line item
and/or its claim to the payer, without the need for human
intervention. The edited line items are marked as partially
resolved or in some other way to indicate that a change has been
made. These items may remain in the denial management system for
any further handling to complete their resolution.
[0089] Referring now to FIG. 12, an example of a user interface
displaying a portion of the longitudinal record for a given charge
is shown. One can see in this screen shot, the record of payments
unallocated and reallocated by the system. The system identified a
mismatch between the line items to which the payer applied the
co-payment and the line item to which the health care service
provider applied the co-payment. The system unapplied the
co-payment that was applied in the medical provider's system. In
accordance with the allocation specified by the payer system, the
medical claims management system took $10 from the patient account
and reallocated it to the line item charge to which the payer had
assigned the $10. The same unallocation and reallocation was
applied to five dollars of the co-payment as per the allocation of
that amount by the payer. One may scroll down through the remaining
record to see the entire history of payments corresponding to the
line item. As seen in the lower right, the total of credits from
this record is $99.56. This leaves the balance shown in the screen
of $47.44.
[0090] To gain a greater understanding of the overall structure of
the claims management system designed in accordance with principles
of the present invention, we now turn to FIG. 13. The medical
claims management system requires access to data identifying the
payers with whom it will be communicating to request payments. An
operator can enter payer information through an interface generated
by a payer information program 70. Information regarding payers
entered through the payer information program 70 is stored for
access by the computer. The payer information may be stored in the
form of a payer information table 72.
[0091] A claims file generation module 74 generates outgoing ANSI
X12 837 files. The claims file generation module 74 has access to
the payer information table 72 for retrieving information about the
payer. This might include an IP address and other information that
may be required. All electronic data interchange ("EDI") activity
is logged into the claims table 76. Thus, a complete longitudinal
record of all transactions relating to a claim or line item can be
retrieved from the claims table 76. An outgoing file 837 file is
made up of one or more claims, each claim having one or more line
items of medical service charges. Aspects of the present invention
make full use of the field CLM01 by including a unique identifier
in this field to identify a claim. The ANSI X12 standard requires
that the field CLM01 be maintained throughout the processing
between payer and payee. Thus, even if later transactions otherwise
lack sufficient application system information to associate a
payment or a rejection with a claim, the CLM01 can serve the
purpose of enabling the longitudinal record of transactions between
the payee and payer to be stored and accessible with respect to any
claim. In preferred embodiments, the unique identifier for CLM01 is
created by the claims file generation module 74 as a combination of
data including the claim number and any of the account information
including account number, dataset identifying the payee, insurance
policy number or other identifying data in a transaction. The CLM01
will, by force of the ANSI standard, be included in EDI from the
payer so that the medical claims management system can then use the
CLM01 to track and store responses to this claim.
[0092] In accordance with further aspects of the present invention,
use is made of the REF6R field. The REF6R field is also required by
the ANSI standard to be preserved in the course of processing the
claims transactions. Thus, even if later transactions lack
sufficient information to associate a payment or a rejection with a
line item, the REF6R field can serve the purpose of enabling a
longitudinal record of transactions between the payee and payer to
be stored and accessible with respect to any line item. In
preferred embodiments, the unique identifier for REF6R is created
by the claims file generation module 74. The uniqueness of the
REF6R id is determined by the health service provider's practice
management system. In accordance with one embodiment, REF6R is a
combination of the account number and a sequence number. In other
embodiments, it may simply be a transaction or record number. The
REF6R will, by force of the ANSI standard, be included in EDI from
the payer so that a system can then use the REF6R to maintain a
longitudinal record of all actions taken with respect to the line
item.
[0093] In order to generate a claims file, the claims file
generation module 74, needs access to the medical charges. These
may be stored in a data set of a medical provider's computer
system. The data set is not shown in the data flow for the medical
claims management system. The medical claims management system is
in connection with the health care service provider system 20. The
claims files can be accessed and the data records of the provider
can be amended to better conform with the payers' records for ease
of resolving discrepancies.
[0094] An 837 claim submission file is generated with one or more
claims. It has been found to be most efficient to post claims
during the day while using evening hours for submitting the 837 to
the payers, medical insurers typically. In accordance with ANSI
X12, the computer systems of the medical insurers will respond to
the 837 with an acknowledgement referred to as a file 997. The file
997 acknowledgement may include either an acceptance or a file
level rejection.
[0095] Incoming transactions are received and handled by an
incoming advice processing module 78. Rather than simply printing
out a report of a rejection or preparing an image for display on a
terminal and awaiting manual intervention, embodiments of the
present invention make data records of the file 997s. The records
are stored in a payments and denials table 86. Upon receiving a
file level rejection, the claims file generation module 74 is
instructed by the incoming advice processing module to re-generate
a file 837 without the offending claims noted in the rejection.
Thus, the 837 is automatically re-generated. The maintenance of the
denial record and the resending of an 837 continues iteratively
until an acceptance is received or all claims are removed. Thus,
following a series of iterations beginning at the close of
business, by morning the next day, the offending line items will
wind up in a denial record for interactive electronic review by
human operators. Such review takes place through the denial
management module 80. The accepted file 837 claims data will enter
the two-stage adjudication process at the payer.
[0096] Before completing adjudication, it is possible that the
payer's computer system will send a file 277. The file 277 is a
potential pre-adjudication denial. It typically relates to the
patient insurance credentials. Perhaps the patient policy number,
name or address has been misspelled or mistyped. Any such file 277
denials are received over the network by the incoming advice
processing module 78, and recorded to a table for later interactive
electronic review and processing in the denial management module
80. The file 277 denials are preferably stored in the payments and
denials table 86, but in other embodiments may have their own table
or find space within the claims table 76. Taking advantage of the
fact that the ANSI standard requires the CLM01 field to be included
in the file 277 denials, the 277 denials may be recorded by the
incoming advice processing module 78 in the payment and denials
table 86 in association with each of the included unique
identifiers for the affected claims. Thus, embodiments of the
invention do not lose track of any claims. The 277 will be
retrievable for any claim that will go unpaid for a
pre-adjudication reason.
[0097] Upon adjudicating a claim, a payer computer system generates
a file 835. The file 835 is generally known as an explanation of
benefits. It will include payments in whole or in part for certain
line items and may include one or more reasons for partial or
complete denial of other line items. One or more payments may be
aggregated in a check. (As previously mentioned, a "check" as used
herein relates to payments to be provided by electronic funds
transfer or check or other commercially acceptable method including
one or more of the payments in the 835.) The incoming advice
processing module 78 receives the 835 and saves it to the claims
table 76. Payments and denials are thus maintained in association
with their associated CLM01 and REFER.
[0098] The incoming advice processing module 78 stores a summary of
the check information in a received funds table 82. The received
funds table 82 maintains details as to how the check is distributed
across multiple payees. The table details how much of the check has
been posted. An operator may have access to received funds table 82
through a funds entry module 84. The operator may indicate which
835 checks have been deposited. The operator may further reconcile
the check payment posting done automatically in the medical claims
management system. The claims management system can be enhanced by
further embodiments of the invention. Each night for example it can
run a screen scraper program to review the bank account(s) of the
health care service provider to identify all checks that were
deposited that day through electronic funds transfer (EFT) or
otherwise.
[0099] The individual payments in the 835 are stored by the
incoming advice processing module 78 in the payments and denials
table 86. The payments are marked with a status indicating whether
or not the payment is ready for posting. If the status indicates
the payment does not have an error and the check is indicated as
being deposited in the received funds table 82 then the payment is
ready for posting. When a settlement check is received, that also
is entered in the payments and denials table 86 for processing. The
amount of the settlement check is distributed across the claims,
and the amounts distributed are marked as Settlement Adjustments as
described previously.
[0100] In accordance with a further aspect of embodiments of the
present invention, the incoming advice processing module 78
performs special handling for co-payments. As previously described,
it is often the case that a patient visiting a health care service
provider will make a payment by cash, credit card or check to the
health care service provider for a portion of the medical
treatment. This co-payment is required by the patient's health
insurance policy. The health care service provider will receive the
co-payment and apply it to one of the line item charges that
comprise the treatment received by the patient. The line item
selected by the staff at the health care service provider is often
not the same as the line item to which the payer or health insurer
applies the co-payment. The amounts are often not in agreement. In
order to make discussions with the insurer more fluid, the incoming
advice processing module 78 includes program code for inspecting
the 835 and for any line item in the 835, reversing any patient
payments or co-payments in the medical provider system. The patient
credit for the co-payment goes into a temporary suspense account
attributable to the patient. Then it reallocates the credit to the
same line item to which the co-payment or payment was applied in
the 835.
[0101] To simplify the tasks for the operators, the numerical codes
used to represent an adjudication code are mapped into
user-friendly translated codes or abbreviations as discussed above
with regard to FIG. 4. The adjudication map-to table 90 contains
the translated codes and actions associated with the adjudication
codes. The map-to table is user programmable through a program
referred to herein as the deny code module 92.
[0102] A payments processor 94 allows for manual processing of
payments with an error status by assigning them to the correct
charge or removing them. The automatic payment processing of the
payments processor 94 will post payments, provided there is no
error status on the payment and the payment check has been marked
as deposited in the received funds table 82. The checks each have a
control number that also appears in the 835 so that received funds
can automatically be matched to the payments expected according to
the 835. Moreover, given the unique identifiers for line items, the
payments are automatically, through actions of the automatic
payments processing program, associated with the line item
charge(s) corresponding to the payment. An update module 96
automatically updates the received funds table with payment posting
totals done by the automatic payments processing. Based on actions
from the map-to table 90, the payments processor 94 may
automatically perform Write-Offs and Transfers.
[0103] By maintaining a longitudinal record of all transactions
pertaining to any claim or line item, wrongful claim denials can be
more easily resolved. An operator reviews the denied claims through
use of the denial management module 80. An administrator can
control who has access to perform denial management with respect to
a variety of factors, such as payee, payer or type of rejection.
The access rights of each operator are given in an operator access
table 88. The administrator enters data and adjusts rights through
use of an operator administration module 98. The denial management
module 80 allows an approved operator to review the entire history
for a denied claim and determine if a correction can be made such
that the claim can be resubmitted. Some denials may seem
appropriate, in which case the operator can write off all or some
portion of the charge, transfer the charge, rebill the charge, and
close out the denial. Other denials may require pursuing a dispute
with the initial payer. As to these, the longitudinal record of all
transactions following the claim submissions through to the 835
responses will significantly help reach a resolution with the
payer.
[0104] The present invention may be embodied in many different
forms, including, but in no way limited to, computer program logic
for use with a processor (e.g., a microprocessor, microcontroller,
digital signal processor, or general purpose computer),
programmable logic for use with a programmable logic device (e.g.,
a Field Programmable Gate Array (FPGA) or other PLD), discrete
components, integrated circuitry (e.g., an Application Specific
Integrated Circuit (ASIC)), or any other means including any
combination thereof.
[0105] Computer program logic implementing all or part of the
functionality previously described herein may be embodied in
various forms, including, but in no way limited to, a source code
form, a computer executable form, and various intermediate forms
(e.g., forms generated by an assembler, compiler, linker, or
locator). Source code may include a series of computer program
instructions implemented in any of various programming languages
(e.g., an object code, an assembly language, or a high-level
language such as Fortran, C, C++, JAVA, or HTML) for use with
various operating systems or operating environments. The source
code may define and use various data structures and communication
messages. The source code may be in a computer executable form
(e.g., via an interpreter), or the source code may be converted
(e.g., via a translator, assembler, or compiler) into a computer
executable form.
[0106] The computer program may be fixed in any form (e.g., source
code form, computer executable form, or an intermediate form) in a
tangible storage medium, such as a semiconductor memory device
(e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable memory), a
magnetic memory device (e.g., a diskette or fixed disk), an optical
memory device (e.g., a CD-ROM), a PC card (e.g., PCMCIA card), or
other memory device. The computer program may be distributed in any
form as a removable storage medium with accompanying printed or
electronic documentation (e.g., shrink wrapped software), preloaded
with a computer system (e.g., on system ROM or fixed disk), or
distributed from a server or electronic bulletin board over the
communication system (e.g., the Internet or World Wide Web).
[0107] Hardware logic (including programmable logic for use with a
programmable logic device) implementing all or part of the
functionality previously described herein may be designed using
traditional manual methods, or may be designed, captured,
simulated, or documented electronically using various tools, such
as Computer Aided Design (CAD), a hardware description language
(e.g., VHDL or AHDL), or a PLD programming language (e.g., PALASM,
ABEL, or CUPL).
[0108] Programmable logic may be fixed either permanently or
transitorily in a tangible storage medium, such as a semiconductor
memory device (e.g., a RAM, ROM, PROM, EEPROM, or
Flash-Programmable memory), a magnetic memory device (e.g., a
diskette or fixed disk), an optical memory device (e.g., a CD-ROM),
or other memory device. The programmable logic may be distributed
as a removable storage medium with accompanying printed or
electronic documentation (e.g., shrink wrapped software), preloaded
with a computer system (e.g., on system ROM or fixed disk), or
distributed from a server or electronic bulletin board over the
communication system (e.g., the Internet or World Wide Web).
[0109] The embodiments of the invention described above are
intended to be merely exemplary; numerous variations and
modifications will be apparent to those skilled in the art. All
such variations and modifications are intended to be within the
scope of the present invention as defined in any appended
claims.
* * * * *
References