Thanks to Ronald Bowron for looking into the subject of modeling Information Flows. Ronald says he'd "...like to see if we can get some clarification around the different business processes that occur before a HIPAA transaction occurs. This may help clear up many of our issues regarding routing, addressing and TPA's."
Rachel Foerster and Kepa Zubeldia have already emphatically stated that Healthcare automation is a "huge complex mess" - their words, not mine - and I have no reason to doubt them. Perhaps the 837 should or shouldn't have been designed the way it is, what with allowing claims for multiple payers - or aggregating multiple providers' claims for a single payer. Maybe clearinghouses shouldn't be able to "drop to paper" just because they've never seen the provider before. Or maybe payers shouldn't assign a provider a different provider ID for each plan. It's a little more definite that the 835 remittance containing PHI shouldn't be sent through a bank (see my previous tirade against mixing payments and remittances), but that actually touches on the issue of transaction routing, and besides, I'm not the one who's going to get in trouble for doing that! Sure enough, when you have a simplistic messaging system - with multiple parts needing multiple actions performed by different parties - the system becomes weird. As Rachel has said, "this whole effort is crying for a good process analysis effort rather than just discrete and disjointed message exchanges." That may be, but these aren't issues we're going to solve in this group. I'd recommend that if the way the current transactions are put together bothers anyone, he should take a look at the ASC X12N Business and Information Modeling Task Group 3 (X12N/TG3); also, take a look at http://www.wpc-edi.com/models/, especially the Health Care Business Model. So I think we definitely want to keep Ronald's flows under "Assuming an Electronic transaction to a Plan" (or to a provider, or a bank, or a Third Party Administrator, or a Reviewer) - and we will want to fill in the missing detail. We are looking at complete transactions as they flow between parties, and how those parties are identified for the purposes of routing. Modeling where Trading Partner Agreements (especially electronic TPAs) fit in the scheme of things is also appropriate to our charter. But the other actions Ronald has illustrated may not be as relevant to our investigations (though they certainly may be to X12N/TG3) since we're only dealing with how and where to move X12 interchanges between the (various) parties. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Ronald Bowron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, 26 February, 2002 12:48 AM Subject: RE: Requirements Gathering - Information Flows I'd like to see if we can get some clarification around the different business processes that occur before a HIPAA transaction occurs. This may help clear up many of our issues regarding routing, addressing and TPA's. This is where I believe Rachel was trying to leverage the UML and business requirements gathering techniques to reduce the amount of misunderstanding about how things happen today. So, with that in mind. It appears that Routing and Addressing may be dependant upon the existence of some Trading Partner Agreement. Whether it be in writing or not - I would assume a verbal agreement to use the X12N standards is a form of a TPA (although I'm not a lawyer). Taking a simplified approach to understanding how identifiers are gathered/created (The IG covers much of this, and I'm sure we're all too familiar with this), but lets put it on the table: Provider is a Provider/Institution. Provider obtains License to Practice Plan obtains License to Insure Providers Participate/Register in Plan Provider requests/submits Electronic Billing Authorization Plan establishes TPA with Provider Sponsors Participate/Register in Plan Members Join (Individuals and Families) Sponsors notify Plan of new Members Members pay Plan Premium Member becomes Patient Patient visits Provider Provider requests Patient/Member Plan Eligibility Provider requests/submits Electronic Billing Authorization Plan establishes TPA with Provider Provider diagnose Patient Provider identifies Procedure Provider requests Procedure Authorization (from Patient and/or Plan) Provider services Patient Provider requests/submits Electronic Billing Authorization Plan establishes TPA with Provider Provider bills Member/Plan for Patient services Member may pay Provider for services Plan pays Member/Provider for services Assuming an Electronic transaction to a Plan: Provider submits electronic transaction to Plan (Different delivery/processing methods- CH, Re-Pricer, Third Party, fit here) Plan receives Transaction request Plan verifies ISA Submitter has Electronic Authorization Plan acknowledges request to ISA Submitter (Different delivery/processing methods - CH,Re-Pricer, Third Party, fit here) Plan verifies transaction (Provider and Member) identities Plan responds to transaction (Provider) request (Different delivery/processing methods - CH,Re-Pricer, Third Party, fit here) Provider receives Plan Acknowledgment and Response While I may not have gotten all the steps involved, clearly there are dependant, conditional and optional steps here. Also, throughout each step, information could be gathered that will determine the appropriate identifiers for routing or addressing of a given transaction, before the transaction is to occur. Eventually, we should be able to define the Authoritative Sources of the significant identifiers for addressing (hope I'm appropriately using the terms identifier and address). Once we begin defining sources of identifier information, we can then determine how to use or standardize those sources to assist in determining addressing. I would like to see this list flushed out into a UML that helps identify the process more clearly. I don't have any UML applications that would model this, so any volunteers? Regards, Ronald Bowron
