William,
>(2) Agreement that the ZZ qualifier is not to be used on the ISA. This
necessarily eliminates the use of proprietary payer or CH assigned
provider IDs.
While it ok to "recommend" that ZZ qualifier not be used, I think there has
to be a plan to address ZZ as well since it's use is quite well spread, in
my opinion. May be somebody from VAN can provide some statistics on
percentage of ZZ users as opposed to non-ZZ users. I don't think Payer's
will be too fussy to use ZZ though.
>(3) And possibly, agreement on how the GS is to be used for internal
routing or selection between alternate "EDI addresses."
Use {ISA SENDER ID, ISA RECEIVER ID, GS SENDER ID, GS RECEIVER ID, GS
VERSION AND INDUSTRY CODE, ST MESSAGE ID} to index into the agreement table
and get routing information.
I have included GS VERSION AN INDUSTRY CODE to distinguish between various
837(s) (Institutional (X096), Dental (X097), Professional (X098)) since the
same "may" be processed by different application subsystems.
I have included ISA and GS SENDER ID, in case the Payer's application system
wish to "distribute" load onto different systems (PCs) for the same type of
transaction.
Looking at the diagram on Page 13 of 30 of the white paper "Transaction
Sequencing 2.0", I think the above information is enough for routing.
Ajay
Ajay K Sanghi
Managing Director
ABO Software Private Limited
B102 Gulmohar Park, New Delhi 110049
Tel: +91 11 6968976, 6512822 Fax: 6518873
Website: http://www.abosoftware.com
email: [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of William J. Kammerer
Sent: Thursday, April 11, 2002 6:59 PM
To: 'WEDi/SNIP ID & Routing'
Subject: Re: A proposed work plan for this group
We need consensus on the following issues:
(1) Agreement that global IDs are to be used for all parties (providers,
payers, TPAs, repricers, billing agents, clearinghouses, etc.). One or
more IDs - from one or more of the supported domains on the ISA - may be
used, chosen by the party being identified.
(2) Agreement that the ZZ qualifier is not to be used on the ISA. This
necessarily eliminates the use of proprietary payer or CH assigned
provider IDs.
(3) And possibly, agreement on how the GS is to be used for internal
routing or selection between alternate "EDI addresses."
Aren't these the highest priority issues to resolve? Because if we
don't have a consistent way of addressing partners (based on IDs),
there's really no good way to do anything else, such as the lookup of
partners' information in a directory. And it's that directory (whether
a DNS lookup, ebXML Registry or UDDI) that contains the CPP which has
all the good stuff for automatic trading partner hook-up.
William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320
----- Original Message -----
From: "Rachel Foerster" <[EMAIL PROTECTED]>
To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]>
Sent: Saturday, 06 April, 2002 02:37 PM
Subject: A proposed work plan for this group
The dominant business model in health care is:
1. For the most part, only health care claims are submitted
electronically by providers to the party they've determined is the
financially responsible party for reimbursement.
2. The format used for electronic claims is most often the NSF batch
file format, or some variant thereof.
3. It's not typical that a provider submits claims directly to the
financially responsible party. Rather, intermediaries are more likely
than not to be in the picture. Intermediaries can be clearinghouses,
TPAs, repricers, billing services, and so on.
4. These intermediaries typically determine the financially responsible
party by interrogating data contained with the batch file.
5. While the NSF batch file has batch header and trailer records which
start/end the batch, the records in the batch are fixed field/fixed
record multiple record types.
6. The industry does not use the typical EDI VAN store and forward
model. Thus, it has not built an infrastructure that uses an identifier
from a batch header record to "mailbox" files for the receiver.
7. The industry model is one of the provider always have to "push"
electronic claims to the financially responsible party through an
intermediary and to then "pull" any return messages.
8. Other types of information exchanges, queries, referral requests,
etc., are most often performed via phone, IVR, DDE, or fax. Thus,
today's application systems do not typically support nor enable batch
file transfers for these types of information exchanges.
As you know, the model which most other industries use for
standards-based EDI exchanges is one where the receiver of the
interchange maintains a mailbox at some "post office" - most often
called a VAN. Thus, both parties to the information exchange maintain
their own mailboxes (or multiple mailboxes) at a post office(s) of their
choosing. It's this model that the current X12 control structures enable
and support.
It's my opinion that the urgent problem to be addressed and solved
**before April, 2003** is how to complement the current business model
**using the X12 Interchange control envelope** for the submission of
claims and without forcing the entire industry on its head...there are
sufficient challenges with just adopting a new set of formatting rules
and standard data. Coming up with a "down and dirty" (if necessary)
solution that will enable the industry to become operational today
should be the urgent priority of this group.
It's my perspective that there has been excellent brainstorming and
discussions over the last several months on a variety of issues for EDI
addresses, identifiers, etc. on this list. But, the clock is ticking and
time is fast running out for this group to provide direction to the
industry to solve the immediate problem. It's now time to turn to:
1. Developing a clear and succinct statement of the problem(s) to be
solved. Prioritizing the identified problems.
2. Developing a set of functional requirements that will solve the
problems identified using today's tools.
3. Transforming the problem statement(s) and requirements into a
document that can be provided to the industry fast so that the industry
can use it now.
I propose that this group spend no more than the next 2 weeks to reach
consensus on the problem(s) that must be solved now. Following that
develop a set of functional requirements for **each** problem
identified - spend no more than 2 weeks on this task. These two tasks
should be completed by May 3rd. During May the
recommendations/specifications/guidance document can be developed...I
would certainly expect that the final draft of this document could be
completed by the end of May.
Comments?
Rachel Foerster
Rachel Foerster & Associates, Ltd.
Phone: 847-872-8070
