Dave:
Thanks much for starting the ball rolling on the Information flows! One
thing that's striking is you've portrayed each scenario as a single
business process, as if the interactions are all unitary and reciprocal
queries and responses. To take a single, simple example:
P-->A-->P (paper & electronic Claims & RA)
In other words, the Provider sends the 837 claim to the pAyer, who in
turn acknowledges the claim with a remittance advice (835). That's kind
of the common sense, and informal, interaction: an 837 elicits an 835.
But does it really? Multiple 837s could result in a single 835,
couldn't they? Claims could be sent throughout the day to the payer,
with the payer waiting to process them in one run, resulting in a single
835 which the provider has to reconcile with any number of claims (sent
in any number of 837s).
The 837 ceases to exist by the time it gets to adjudication: it has
decomposed into any number of atomic claims. There's nothing to say an
835 reflects only claims from one 837 - and there's really no reason for
the payer to retain any notion that a particular claim came from any
particular 837. And this is in the direct point-to-point scenario
between provider and payer, with no intervening Clearinghouse which may
be munging claims together from multiple providers for the payer! Bob
Poiesz has emphatically taught us that the 837 is nothing but an
ephemeral package encapsulating any particular claim - only until the
next moment when it is possibly captured in another 837's orbit.
But fortunately, I don't think we have to peer at the atomic level for
solving our routing problems. We're only concerned with the physics of
moving intact X12 transactions. The interaction P-->A-->P should
really be decomposed into two separate (and possibly unrelated)
sequences:
Provider ->(837) Payer
Payer ->(835) Provider
We can't afford to ignore the technical acknowledgements in our
information flows involving the 997 and the TA1 (and maybe even the
824). In the simplest cases where individual 837s are packaged in a
single interchange, diagramming the interaction might be simple:
Provider ->(837) Payer ->(997) Provider
But what about when multiple transactions (and multiple transaction
types - i.e., a mixture of 837s and 270s) are packaged in a single
interchange? I don't think that really complicates things, in that all
we really wanted to demonstrate is that the 997s (plural) go back to
whoever sent the original interchange.
William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320
----- Original Message -----
From: "Dave Minch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, 14 February, 2002 02:19 PM
Subject: RE: Requirements Gathering - Information Flows
Here's a first cut at the paths we traverse today whether in paper form,
phone, or electronically (I've probably missed a few - I'll keep
checking):
I'm going to use a coding scheme to make it quicker to do these:
P=Provider
A=pAyer (endpoint that creates the EOB)
E=Employer
T=Third party administrator
R=Reviewer
I=reprIcer
C=Clearing House
F=Fiscal intermediary (MediCal & Medicare)
Benefits Eligibility:
P-->F-->P (DDE & phone)
P-->E-->P (phone)
P-->T-->P (phone)
P-->R-->A-->P (phone)
P-->T-->E-->P (phone)
P-->T-->A-->P (electronic)
P-->T-->A-->T-->P (phone)
P-->A-->P (phone & electronic)
P-->C-->A-->C-->P (NCPDP transactions)
P-->C-->T-->C-->P (NCPDP transactions) - this may also have a stop at A
after T, but I can't determine that from the end result.
Claims & RA:
P-->F-->P (paper & electronic)
P-->A-->P (paper & electronic)
P-->T-->A-->E-->P (this may be P-->T-->A-->P
\->E - I'm checking) (paper)
P-->T-->A-->P (paper)
P-->I-->A-->P (paper)
P-->R-->I-->A-->P (paper)
\->R
P-->C-->F-->P (electronic)
P-->C-->F-->C-->P (electronic)
P-->C-->I-->C-->A-->C-->P (electronic)
P-->C-->I-->C-->A-->C-->C-->P (electronic)
P-->C-->T-->C-->A-->P (electronic claim, paper check & RA)
P-->C-->A-->P (electronic claim, dropped to paper, paper check & RA)
P-->C-->A-->P (electronic claim, paper check & RA)
I've not included requests for information & status checking since these
transactions are entirely manual now (excepting DDE with the FIs).
As I'm looking at the functions of the review agency, it appears to me
to befunctionally the same as a third party administrator, so i'd assume
for scenario building that T=R.
Dave
