William,
I know I sound like a broken record, but I doubt very much that many
providers will be dumping transactions into any VAN. The norm will be to
dump the transactions into a clearinghouse. Providers will probably have
direct connects to a few payers with whom they do a large amount of
business, but the rest will be via a clearinghouse. In many cases, that
pre-packaged practice management system will send only to one place, the
vedor/vendor's-selected clearinghouse. The software will force a
submission route that guarantees a revenue stream for the vendor (not that
I like it - it is reality - I have been in touch with at least 1 MAJOR
vendor with that plan).
I believe that there are two probable solutions for the batch/realtime
issue. The majority of the solutions will either use separate channels for
the batch and realtime (different mailboxes), or different values in GS02
as suggested in the 270/271 guide. I believe that you are correct that the
health plan should make sure that they handle the priorities, but I think
the solutions will fall into these 2 main categories.
I haven't looked at the ISB to determine its viability as a technical
solution. The fact that it is not part of the HIPAA guides is not an
impediment, in my opinion. The 997 and TA1 are in the guides, but
specifically not required as part of HIPAA. The unsolicited 277 is not a
HIPAA transaction but at least some are planning to implement it as a claim
pre-adjudication edit report. If willing trading partners wanted to
implement the ISB as a batch/realtime solution, that is outside of the
current scope of HIPAA and not a problem. The only issue would be that a
health plan would not be able to require the ISB in order to accept an
otherwise compliant interchange.
Bob
"William J.
Kammerer" To: "'WEDi/SNIP ID & Routing'"
<[EMAIL PROTECTED]>
<wkammerer@nov cc:
annet.com> Subject: Re: Batch vs. Real Time
transactions
01/30/2002
11:28 AM
I hear what you're saying, Rachel. But to put the burden on the (many
small) providers for solving a programming problem better handled by the
(fewer and bigger) payers and their (expensive) EDI translator vendors
would put another roadblock in the way of universal adoption of the
HIPAA standard transactions. I envision the many (plebian) providers,
with their pre-packaged practice management systems, generating standard
transactions and dumping them into one funnel at their VAN. It's too bad
the ISA doesn't have flags or what-not for indicating batch vs.
real-time processing is requested - but it's the card we're dealt.
Instead, the payer's translator should be parallel enough, with multiple
threads handling any number of concurrent translations, so the issue of
a "276 or a 270 ....queued behind another interchange containing an 837
with hundreds of claims" is not a problem; once the translator
determined it was dealing with a task involving a real-time inquiry, the
priority of that thread could be elevated. There are all sorts of
programming ways to take care of these problems, and I don't think the
provider should be called on to perform gymnastics to avoid them for the
payer. And it would not be just the provider who would be penalized -
how would the VAN know how to interpret entity addresses if a receiver
code could really be a receiver code, plus, you know,...well, special
flags?
The ISA06 and ISA08 sender and receiver "addresses" should be unique and
not overloaded with extra duty. That's the only way they can be
interpreted unambiguously by all intermediaries. In addition, all the
information needed for correct processing should be contained within the
interchange itself - between the ISA and the IEA - as a self-contained
package because it's too much to expect PM systems to support alternate
"channels" for conveying information to the payer. And besides, the
provider can be anticipated to only have a single "conduit" to the
outside world - his VAN - the simplest model for supporting
inter-company exchange.
Actually, X12.5 does provide for the ISB - Grade of Service Request -
segment, which can be used as sort of an "addendum" to the fixed length
ISA; I think relying on the ISB for differentiating batch from
real-time would be an acceptable compromise. The ISB occurs before the
functional group is encountered. Unfortunately, the HIPAA IGs don't
support it.
William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320
----- Original Message -----
From: "Rachel Foerster" <[EMAIL PROTECTED]>
To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]>
Sent: Tuesday, 29 January, 2002 07:12 PM
Subject: RE: Batch vs. Real Time transactions
William,
I believe that trying to distinguish batch vs real-time processing in
the transaction or even at the GS level is too late. Say, for example,
that one's real-time interchange containing a 276 or a 270 was queued
behind another interchange containing an 837 with hundreds of claims or
even a full 834 audit. Depending on the file access/database access
methods used by the translator, as well as the throughput performance of
the translator being used, your real-time 276 or 270 could get stuck in
this queue.
Therefore, I think it's critical that the detection of an interchange
for real-time processing be done before the interchange is sent to the
translator. Absent a different comm line or other mechanism which
providers would use for routing real-time interchanges separate from
batch, what would you propose.
That's why it might be worthwhile - if one intends to process HIPAA
transactions in both batch and real time to consider running another
copy of the translator dedicated to real-time processing and the other
copy dedicated to batch processing - to signal this at the ISA receiver
id level. As you know, many companies in the supply chain routinely use
multiple ISA receiver ids in order to separate priority interchanges
from lower priority interchanges.
Lastly, I also question whether suffixing the GS version identifier
would be valid under HIPAA since the IG is quite explicit as to the
total value of this element.
Rachel Foerster
Rachel Foerster & Associates, Ltd.
Phone: 847-872-8070
-----Original Message-----
From: William J. Kammerer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 29, 2002 1:13 PM
To: 'WEDi/SNIP ID & Routing'
Subject: Batch vs. Real Time transactions
The 270/271 implementation guide makes some recommendations on how to
distinguish between Batch and Real Time transactions:
If trading partners are going to engage in both real time
and batch eligibility, it is recommended that they identify
the method they are using. One suggested way of identifying
this is by using different identifiers for real time and
batch in GS02 (Application Sender's Code) for the 270
transaction. A second suggested way is to add an extra
letter to the identifier in GS02 (Application Sender's Code)
for the 270 transaction, such as "B" for batch and "R" for
real time. Regardless of the methodology used, this will
avoid the problems associated with batch eligibility
transactions getting into a real time processing environment
and vice versa.
Overloading the GS sender code (using solely for internal routing by the
recipient) is certainly preferable to requiring different sender or
receiver IDs in the ISA, depending on Batch or real-time. But unless we
come up with specific recommendations that apply across the board - for
every provider and payer - stuff like what's in the IG will require a
TPA (or "companion document"). We want to remove the need for TPAs,
right?
Anybody have specific ideas for differentiating batch from real-time?
How about keying in on BHT03 - the Submitter Transaction Identifier?
It's required to be used (in the 270) if the transaction is processed in
Real Time - and since it can only be returned in a real-time 271
response, it seems like a most excellent marker. I do realize that
makes it tougher for the payer to distinguish between batch and
real-time inquiries, in that you have to drill into the bowels of the
transaction set before knowing which queue to insert the request - but
is that any more difficult than relying on the GS?
William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320
