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

Reply via email to