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
