--- Begin Message ---
Rachel,
Let me stir the pot a little, because this is a very important topic.
It used to be, pre-HIPAA... oh, well, it is the case today... that the
clearinghouses have proprietary formats between them and their trading
partners, both payers and providers. And I mean proprietary in the best
sense of the term. The format accommodates the needs of the
clearinghouse to send the data and provide added value "edits" to their
customers. Most clearinghouses base their formats on the NSF or UB92,
but they add their own requirements, indicating which fields are
required and when. In some cases they add their own fields to the NSF
or UB92 base.
But most clearinghouses also accept other "open" formats, such as their
competitor's formats (no surprise here, I hope) or "print image" files.
In these cases the "edits" applied may be slightly different. Also,
these cases may require the change of codes (e.g. patient relationship)
or additions of data (e.g. provider identifier) by the clearinghouse.
In today's environment the clearinghouses have substantial freedom in
accepting transactions from the providers even though they may not have
all the data exactly right. As long as the claim meets certain
integrity minimums, they just pass the data to the payer at the other
end and let the payer deal with irregularities. The thinking is that if
the payer can deal with a paper claim, with all its peculiarities, the
payer should also be able to deal with an electronic representation of
the same paper claim, with the same peculiarities.
So, today, the clearinghouse acts as an aggregator, but also as a filter
(rejecting very bad claims back to the provider) and as a homogenizer by
combining all the claims that pass through the "edits" sieve into one
stream for the payer. Not only it is easier for the payer to deal with
only one file (or one giant X12 transaction) but also provides some
sense of "protection" to the clearinghouse, as the payer does not know
and cannot find the path back to the provider, except by going back
through the same clearinghouse.
But HIPAA brings some problems to the clearinghouses. For example, the
format and the rules for the "edits" are no longer in the hands of the
clearinghouse. The HIPAA IGs specify very strict data requirements.
Orders of magnitude stricter than anything we have seen in the past. And
the clearinghouses cannot "relax" them for certain clients (e.g. print
image providers) like they are doing today. The result is that the
clearinghouses will have to choose to operate under HIPAA as:
1) Implement ALL the HIPAA "edits" specified in the IGs, and reject back
to the provider any claim that is not HIPAA-perfect. My guess is that
about 20% of today's claims would fail. Or,
2) Not implement all the HIPAA "edits" specified in the IGs, with the
risk that some claims that are not HIPAA-perfect may go through the
clearinghouse filter and into a payer.
If the payer did not implement all the HIPAA "edits" there is a good
chance that the less than HIPAA-perfect claims will get through the
payer's system also, and into adjudication. This is the sort of
permissive operation that happens today.
But, if the payer did implement all the HIPAA "edits" in the IGs, then
the less than HIPAA-perfect claims in the clearinghouse stream will be a
nightmare. Even one single rotten claim in the stream will cause the
entire X12 transaction to reject at the payer, potentially affecting
thousands of providers that had HIPAA-perfect claims to begin with. Not
pretty.
And, as I understand the HHS responses to the FAQ, the payers are
required to implement all the HIPAA "edits" in the IGs because they
should not be conducting non-standard transactions.
The problem of one bad rotten apple corrupting the entire X12
transaction has been well documented by now. What is even worse, is
that even if you find the offending claim, and even if you can bring it
up with a tool to modify its contents and fix the error, should you do
this? Keep in mind that you would be modifying the original data
stream, probably in violation of all sorts of business practices against
tampering with original data. Most people are saying they cannot just
"fix" the problem, that the billing provider must fix the problem and
resubmit the transaction.
So, how can a clearinghouse work around this and still accept and
process most claims under HIPAA? Because, 20% rejection rate (my guess)
is not good business...
One possibility is for the clearinghouse to not "blend" the data stream.
So, if a provider sends a file with 20 claims and each is for a
different payer, the clearinghouse could create 20 different X12
transactions for the 20 different payers on behalf of that provider.
And not mix claims from other providers into those transactions. That
way, if one of those claims is bad, no other provider will be affected.
The bad claim may end up causing the rejection from the provider to one
payer, including all the other good claims that were destined for that
same payer in the same X12 transaction the same day, but it will not
cause the rejection for other providers, and will not cause the
rejection of the claims for other payers. The disadvantage of this mode
of operation is the additional overhead of having thousands of ST-SE
transactions to each payer each day, rather than the single X12
transaction used today with thousands of claims in it. Some times, tens
of thousands to each payer. This can get taxing on the EDI translators
for large payers. A large payer could get submissions from 20,000+
billing providers per day, each one in its own ST-SE envelope. I am not
sure there are many translators that will handle this well.
Now, if you consider that under HIPAA the clearinghouses are charged
with converting from non-standard formats (NSF, UB92, print image, etc.)
into a standard format, and consider that most of the non standard
formats are not in X12 and therefore do not have the ISA/GS/ST/SE/GE/IEA
envelopes, the clearinghouses are going to have to either create those
out of thin air on behalf of each separate provider/payer, or blend the
data stream together and create the envelope on behalf of the
clearinghouse itself. Neither solution is optimal.
There is a completely different approach taken by UHIN and perhaps
others. In the case of UHIN, they are more a "switch" or a VAN than a
clearinghouse as HIPAA describes it. They require the provider to send
separate transactions, one per payer, with separate ST-SE envelopes.
Then UHIN breaks the functional group into X12 transactions, and
re-groups the transactions into groups for each payer. Technically they
don't "open" the envelope. They do the transaction aggregation and
distribution function, but the provider is responsible to break the
stream up into distinct packets, one per payer. And the payer gets
those packets intact from UHIN. The same process works in reverse. From
talking to the UHIN payers, they are VERY happy with the system, because
it provides true accountability for the content of the transaction.
But, of course, UHIN is not translating data from/to different formats
like a HIPAA clearinghouse will do. It is the responsibility of each
one of the providers to get their act straight and to be HIPAA
compliant, rather than UHIN's responsibility.
Now, going back to the clearinghouses, I suspect they are going to have
to look at each one of their provider separate, rather than looking at
the "blended" data stream. There will be some HIPAA-perfect providers
in the blend. There will be some sour grapes in the blend. The
clearinghouses have to look at each one of these and decide whether the
provider needs to migrate to a "better" or more complete format (e.g.
ambulance companies will probably have to migrate from print spool files
to at least NSF or perhaps to a HIPAA X12 version) but not all providers
will need to migrate. I can see how a general practitioner or a
pediatrician may be perfectly happy with a print spool file for a few
more years. Each one is different. The clearinghouse may be able to
help with a "transaction data gap" analysis but at the end the
responsibility to be compliant rests with the provider, as
clearinghouses don't have silver bullets.
At Claredi we are under constant pressure from clearinghouses to certify
their "blended" data stream as HIPAA compliant. We can do that, but
what does that mean? The problem is that it is "blended", and the fact
that the blend may have certain HIPAA compliant transactions from
certain providers does not mean that all the providers in the blend are
in compliance. So, instead of knowing that the clearinghouse does have
the capability to produce HIPAA compliant transactions (relatively easy
to do for a clearinghouse) what providers and payers should be asking
from their clearinghouse is: Can you produce HIPAA compliant
transactions with MY data? Anything short of that is pretty much
useless. Of course, if the clearinghouse cannot produce HIPAA compliant
transactions at all, that is a different story.
So, we have put in place the mechanism to look into either the "one
provider per X12 transaction" or into the "blended" data stream (that
was the fun part) to identify and extract the HIPAA compliant
capabilities of each provider coming from a clearinghouse. We can get
certification (or non-certification data analysis) for thousands of
providers out of a single blended data stream. The results are just
amazing. Some pass with flying colors, some fail miserably. Out of the
same blended data stream!
Now we need to educate the industry on this very important topic.
Comments?
Kepa Zubeldia
Claredi
-------- Original Message --------
Subject: [hipaalive] Re:TP Validation
Date: Wed, 26 Dec 2001 15:51:58 -0600
From: "Rachel Foerster" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: "HIPAAlive Discussion List" <[EMAIL PROTECTED]>
Margaret,
I think the scenario you describe below could occur....probably much
more
frequently than we now anticipate. Thus, if you're receiving the 837
transactions via multiple paths, you'll have to establish business rules
and
logic to validate your trading partner. The challenge becomes defining
who
the actual trading partner is. In your scenario, it could be either your
clearinghouse or the provider or both.
Typically the ISA identifiers have been used in other industries to
identify
the originating sender and the final receiver (usually called trading
partners). Trading partners use a variety of methods to exchange the EDI
interchange: direct connections, value-added-networks (VANs), the
Internet,
possibly other intermediaries. The common business practice is to use
the
ISA identifiers as EDI addresses for mailboxing and forwarding. When two
VANs are involved (a VAN for each trading partner) the VANs establish
the
mechanism/mode by which they'll exchange the various EDI interchanges
for
their respective customers. Thus, the original ISA Sender and Receiver
IDs
remain intact as specified by the trading partners.
One of the issues for health care, as I see it, is what appears to be
the
practice by clearinghouses to receive claims from hundreds of providers,
in
some cases apply front-end edits on behalf of a payer, group (batch)
claims
for each payer and forward the batches of claims to the respective
payers.
>From the payer's viewpoint, the claim(s) are received from the clearinghouse
and not the providers.
It may be that this practice will have to change as the industry
transitions
to using the EDI standards. By that I mean that rather than batching
claims
from many providers into a single X12 interchange, the clearinghouses
will/can still perform their typical function of being an
aggregator/front-end edit point, etc. but rather than batching claims
from
multiple providers into a single X12 interchange, they fully envelope
all of
the claim(s) from a single provider into a full X12 interchange using
the
appropriate sender ID for each provider and payer. Alternatively, they
could
also batch claim(s) from many providers into Functional Group envelopes
(GS/GE) and enclose them into a single X12 interchange.
However, neither approach solves the problem of having to previously
establish these identifiers (both at the ISA and GS level) in one's
translator so that the translator can apply appropriate validation at
the
envelope levels. So, what's the alternative if the ISA and GS sender
identifiers have to be known in advance? If one receives transactions
directly from the providers, etc., no problem. But in the case of the
clearinghouse scenario, it becomes more problematic with actual provider
(trading partner??) validation occurring during the transaction
processing
step rather than the envelope validation steps.
There is continuing extensive discussion of the issue of routing,
identification, transport, identifiers to support the business process,
etc.
on an X12N health care list. It appears that a work effort will start
soon
to begin the challenge of coming up with solutions and guidance. My
personal
option is that the first activity of this new work effort should be
first to
clearly identify the requirements in all of these areas and then
determine
appropriate and recommended solutions and approaches. Right now it
appears
that a mixture (mish/mash) approaches are being implemented, none using
a
consistent set of rules, thus creating more confusion and ultimately
inoperability.
Sorry I don't have the single one right answer. The reality is that
adopting
the X12 standards will impact many processes that have developed over
time
in the industry and many of these processes may have to change.
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
--- End Message ---
