Chris,

A few thoughts/comments inserted inline to yours below.

Rachel

-----Original Message-----
From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 20, 2002 9:40 PM
To: William J. Kammerer; WEDi/SNIP ID & Routing
Cc: Rishel,Wes
Subject: Basic thoughts on ebXML's relationship to this project


William and Rachel,
I see what you mean about the CPP/A.

The CPP's chief value appears to lie in the ability to use it to
automatically negotiate the CPA, after which the two trading partners
[previously unknown to each other] could launch right into a supported
TRANSACTION.  Clearly, this completely automatic model won't work in
healthcare "out of the box", as you say.

<ref>Agree, it won't be accepted "out of the box", but it will work from a
technical perspective. What will be the barrier to overcome will be
acceptance to use it. Additionally, if you take a look at the ebXML
registry/repository specs you'll see that they support both a
human-to-registry interface as well as an automated machine-to-machine
interface. Thus, the combination of the ebXML CPP/CPA and
Registry/Repository accommodates much of what's been discussed here thus
far.</ref>

But, what if... instead of defining the Business Processes to be supported
as "claim submission", "eligibility query", etc... we defined one general
"HIPAA2002-2003" process as "sending a classic EDI message to
somebody"?  Then it would seem reasonable for CEs to move forward with the
creation of the ebXML "middleware" infrastructure... initially just to move
around "stinky old EDI messages", but eventually (when internal systems
have been redesigned to support it) to permit businesses to communicate
directly at the application level.  Presumably, HIPAA transaction rules
permitting ebXML as an alternative strategy will be in place by the time
partners are ready to begin testing ebXML-compliant applications.

<ref>I don't think the ebXML BPSS spec, etc. is yet ready for prime time
use. But the focus on business processes and their scenarios is essential.
This is also referenced in the GAO report on XML as well as the associated
comment letter from the CIO at the National Aeronautics and Space
Administration. A stepping stone to business processes for us now, I
believe, will be the analog of transactions rather than a business process
specification. I think your idea of a general one is much too broad, lacking
the granularity needed to "discover" how and where to send a real time
inquiry versus a batch.

Re communicating at the application level....that's what EDI is and has been
all about! The entire objective is to integration applications systems
seamlessly across organizational boundaries from day one 20 or more years
ago! But therein lies the rub, the heartburn, and the challenge. Systems
integration ain't a Sunday afternoon walk in the park when it's totally
internal to an enterprise and the enterprise, in theory at least, has total
control over the entire environment.</ref>

Is this the migration path that X12 envisions for the industry?  I realize
that the migration of healthcare from EDI to XML is a little off-topic for
this group, but ebXML does seem to represent a reasonable system for CEs to
find each other and establish a basic BUSINESS COMMUNICATION CHANNEL...
today.  That basic connecting part IS crying out for standardization, and
that does seem to be the central mission of this group.

<ref>This migration to a focus on business processes, structured
requirements analysis, and documenting that knowledge in a common language
is not only the focus of X12, (not just for health care) but the global
community as well. That's why hundreds of us have spent uncountable hours
and put forth excruciating effort over the last 7-8 years in all of the
initiatives for the next generation of EDI, e.g., the ISO Open-edi
Framework, BIM (business information modeling both within X12 and
UN/CEFACT), X12's Strategic Implementation Task Group (SITG), UN/CEFACT's
Techniques & Methodologies Work Group (TMWG), the initial ebXML imitative,
which is well into phase two with the technical specifications being the
responsibility of OASIS and the business specifications being the
responsibility of UN/CEFACT. A focus on business processes is also where all
of the leading enterprises in other industries are, since they all recognize
that data doesn't live and exist on its own....it exists only to serve the
business process so that the execution of the process can proceed to its
desired outcome. Health care administrative simplification hasn't yet
reached that level, and thus the focus on transactions only and not the
entire financial processes required for everyone involved in the delivery of
health care to get paid for what they do. That's why the HIPAA transactions
don't hang together cohesively either. But ultimately, the price and pain to
pay for the narrow focus on transactions will be too great and health care
too will make the leap forward to a focus on business processes.</ref>

I suppose that the relevance of this to the creation of list of "data
elements for the WEDI-SNIP CPP" would be that we might want to try to fit
that information into the format of the ebXML Process Specification
Document... whatever that is.

<ref>I agree that's where the initial focus for the CPP/CPA effort should
be. But, without also defining and documenting the **complete** end-to-end
process, it will fall short of the need. Thus my efforts to bring about a
focus on process, scenarios, rigorous requirements analysis, and the
documentation of that knowledge using a common and consistent
language.</ref>

until monday,
-Chris
For what it's worth:
I skimmed through the "4-4-2002" version of the CPP/A spec. and each CPP
record contains a PartyInfo element with one or more of the following child
elements:
PartyID (globally unique ID for the organization)
PartyRef (pointer to add'l trading partner info contained in an ebXML
registry, UDDI repository, LDAP directory, etc.)
ProcessSpecification (link to a document prepared in accordance with
Business Process Specification Schema (ebBPSS))
plus a bunch of other elements to describe business role, certificates,
delivery channels, message exchange protocol, etc.
I tried reading the description of the Business Process Specification
Schema (ebBPSS) and my brain sorta glazed over.

Christopher J. Feahr, OD
http://visiondatastandard.org
[EMAIL PROTECTED]
Cell/Pager: 707-529-2268

Reply via email to