I think that the assumption about clearinghouses never needing to aggregate
claims when the provider submits an 837 is not true. There is still the
role of a clearinghouse outside of the HIPAA clearinghouse definition.
The 837 allows for one transaction to contain claims for multiple payers.
The clearinghouse would receive an interchange containing one or more 837s
with claims for multiple payers. The clearinghouse would open the
transactions, sort, possibly combine with claims from other providers,
create new 837s and send in new interchanges.
I agree that issues here are not our concern, but we must differentiate
between the clearinghouse function which will probably involve aggregation
and the VAN function of passthrough and routing.
Bob
"William J.
Kammerer" To: "WEDi/SNIP ID & Routing"
<[EMAIL PROTECTED]>
<wkammerer@nov cc:
annet.com> Subject: The ISA may only be one part of
the problem.
01/22/2002
12:04 PM
Earlier, Kepa Zubeldia reminded us that the "actual full name of the
[WEDi/SNIP ID & Routing] group should be something like 'Trading partner
identification and transaction routing' but it is way too long... Don't
get confused with NPI or PayerID or PlanID issues, and that is not the
topic. The 'identification' discussed in this group is the
identification of the EDI trading partners represented in the ISA
segment of the transactions."
To echo Kepa, we're only responsible for making recommendations for
getting standard transactions from here to there based on the
information in the ISA.
The complications Ronald Bowron refers to, "...each claim within the
transaction may have different receiver/payer data," are fortunately (I
believe) not ours to deal with. If a Clearinghouse is performing
aggregation, it's the CH's problem to know how to get hold of (and make
itself accessible to) the providers being aggregated. We're only
concerned here with the identification and routing of HIPAA standard
transactions.
Note that I'm making the assumption that aggregation of HIPAA standard
transactions would never be done (is that correct?) - instead, the CH is
taking whatever slop the (many non-HIPAA compliant) providers give it
and auto-magically producing the required HIPAA standard transactions
for each payer. If a provider were capable of producing HIPAA standard
transactions himself (from the ISA to the IEA and the ST to SE), he
would simply use the CH as a pass-through or go point to point - there'd
be no reason to "aggregate."
On another of Ronald Bowron's matters: is it our problem to address the
authorization component between trading partners? Regardless whether
one is or is not authorized to submit 837 claims to Medicare and
Medicaid, why should we lose any sleep over it? If we did, would that
be "scope creep"? We've done our job if we devise recommendations saying
how you use the ISA to identify trading partners - and suggesting to
intermediaries ways of handling routing and interconnection, along with
devising specifications for advertising transport and security
capabilities (for point to point).
William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320
----- Original Message -----
From: "Ronald Bowron" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, 21 January, 2002 05:31 PM
Subject: Re: Payor identification codes for 837I
Before attempting to apply technology to the problem, we first need to
understand the existing business processes that are required to be
managed and the problem we are trying to solve.
It is my understanding that the ISA may only be one part of the
problem. The ISA only manages sender and receiver, or point to point
data transfer. Where this gets complicated further is that each claim
within the transaction may have different receiver/payer data.
Therefore, I believe the routing issue needs to address file, batch and
transaction level routing issues.
Once the appropriate levels for which routing criteria are identified,
then we can discuss how each level should be managed.
It is my belief that a properly defined Trading Partner table or
directory could address these issues, how that table is managed or
stored and accessed during processing (SQL-RDBMS, LDAP-X.500, DSML-XML
Directories, ebXML Repository, .etc) should be left to the organizations
to define as part of their development requirements. But the means of
publicly publishing that information should be standardized (i.e.
potentially via UDDI).
What I'd like to see come out of this discussion list is the basic set
of elements or attributes necessary to ensure the proper routing of data
within the EDI framework (i.e. What should the table or directory
structure contain).
Another issue that needs to be addressed is the authorization component
between trading partners. Medicare and Medicaid may accept 837 claims,
but that doesn't mean everyone has been authorized to submit such data.
Regards,
Ronald Bowron
