William, You are correct when discussing an "837" as opposed to an atomic claim. My "flows" analysis was meant to show the routes that an atomic claim/payment or eligibility request/response traverse in our health system today, whether electronic or paper or phone. In fact, even when on paper, we tend to print / accumulate paper claims for a specific payer in a sequence that allows stuffing them into a single envelop when mailing (roughly equivalent to an 837). When the envelop reaches the payer, they open it and the "integrity" of that 837 grouping is lost the moment that the individual paper claims flow into their intake process (e.g. they are scanned into their electronic applications).
The 997 / TA1 is a concept that has no equivalence in the paper world, but does in the telephone inquiry - it is the acknowledgement that our admission & A/R follow-up people manually record when they call a payer to check on eligibility & claim receipt. What you bring to light is the difference between what I am describing as the atomic "flows", wherein a certain event such as a claim would be expected to elicit a payment (or at least an RA) response, and the communication of that event between trading partners. As you correctly point out, an 837 (which I would look at as a package of 1 or more atomic claims), could elicit any number of responses: a 997, several 835s, 277s, and even 278s to TPAs and 837s to COB payers. These "response" events are temporally disconnected and unrelated to the original 837. What they each do have, however, is a specific relationship back to the atomic events that were gathered in the original 837 package. Getting back to the "business requirement" here, I need to determine (using a definition here for "transaction" as the single atomic event that needs communication): 1) the final destination for each transaction to be sent; then, 2) based on that final destination (through some mechanism that will be engineered from the business requirements) discover the entry point address for each transaction to be sent; then 3) group the transactions by entry point address; then 4) create the electronic packages by entry point address; then 5) send the packages using methods described in my trading partner profile for each entry point address. For the packages sent, I would expect to get (depending on the trading partner profile) a 997 for each package sent (regardless of destination). >From that point on, each atomic transaction sent out is monitored individually, without regard to the "package" it was sent in. In fact, we should not care at all how the transactions are repackaged and re-routed by the intervening parties as long as each transaction arrives expeditiously (I'd like to define that term at some point...) at the final destination. When we receive a package of transactions from wherever, a 997 would be sent as an acknowledgement of receipt. Again, other than our sending of a 997 to the sender of the package, we would assume that the contents of the package have no particular relationship to each other. The package would then be parsed into its atomic transactions, each transaction attached to its initiating event, and each would finally be distributed to the originating application for automatic processing. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 3:26 PM To: WEDi/SNIP ID & Routing Subject: Re: Requirements Gathering - Information Flows 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
