If we're voting, I'm for generating a definitive solution to the identification & addressing issues (#1 on Rachel's list).
To populate Ron's actors and activities a bit more: Third Party is another licensed entity that interacts with Providers, Sponsors, and Plans, but is neither the Provider nor the Sponsor, nor the Plan. A Third Party must be an agent of the Provider, the Plan, or the Sponsor. <To aid understanding, the third party may be a captive licensed entity of one of the three, or a completely separate entity. For purposes of the functions performed during these transactions, however, they are always acting as an agent of one of the 3>. Provider Service Contract is the agreement between a Plan and Provider under which a Provider provides services. A Repricer is a type of Third Party whose function is to modify a claim's (bill's) stated prices based on a negotiated list in the Provider Service Contract. A Claim is a type of transaction originated by the Provider which provides a list of services performed and a billing amount for those services. An Authorization Request is a request originated by a Provider <do I need to get specific on the kind of Provider here? - it is usually the PCP or "gatekeeper" requesting a specific referral or procedure, but there are many other types of authorization requests> A Reviewer is a type of Third Party whose function is to review a Claim or an Authorization Request for medical necessity Plan Administration may include one or more of the actions of statistical tracking, claim adjudication, medical review, authorization, and eligibility notification. An Administrator (aka: Third Party Administrator) is a type of Third Party who is always an agent of either the Plan or the Sponsor and whose role Plan Administration. Other Transactions: Request For Eligibility - this transaction is originated by the Provider and sent to the Plan or the Third Party acting as the Plan's agent. <If a Third Party is involved, depending upon the terms of the agreement between the Plan and the Third Party, the Request for Eligibility may require a hit on the Plan's database> Request for Authorization - this transaction is originated by the Provider or a Third Party, and can be directed to another Third Party (e.g. a Reviewer) or the Plan. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 26, 2002 8:04 AM To: [EMAIL PROTECTED] Subject: RE: Requirements Gathering - Information Flows Ron, Thanks. I've been trying to get the message across that a systematic requirements analysis needs to be conducted before assuming that any one technology, or approach, should be adopted. It's not necessary to use or even have a UML modeling tool.....a systematic approach to business process requirements analysis is described in the UN/CEFACT UMM draft document.....this methodology is not dependent on any software tool to analyze process requirements. Quite frankly, any project must have a clearly stated objective.....thus far I'm not sure this group has such an objective or reached consensus on an objective. The first question to be answered, in my opinion is: Does this group wish to embark on a project to develop a technical specification for a health care EDI Addressing System? This is what was posed in Peter Barry's first draft document. William talks about a white paper for EDI Addressing. These two things are substantially different animals. Thus, is the goal of this group to develop: 1. A technical specification for a health care EDI Addressing System or 2. A white paper discussing issues, approaches, challenges for EDI Addressing of EDI interchanges These are vastly different. Rachel -----Original Message----- From: Ronald Bowron [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 11:48 PM To: [EMAIL PROTECTED] 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