Technically, this group is a WEDi/SNIP Business Issues SIG (Special Interest Group) for the purpose of developing a white paper to address the standard transaction routing problem. When I say we're going to develop a "White Paper," I'm just parroting what the BI leadership says we're to do. I would imagine they (BI) want a White Paper which describes the perceived problems, if any, with regard to identification and routing, and some suggestions for solving these problem(s).
Peter Barry's notion of a white paper probably includes not only the problem statement and suggested solution approaches, but also some detailed technical specifications which can be used to implement "discovered" solutions. This is certainly a little more ambitious than what I would have started out to do, but I have no objections to doing so. I don't think these work products are "vastly different." Anything in a White Paper would be a prerequisite for doing a complete technical specification. You might even think of the White Paper as the requirements document for the latter - and has to be done regardless whether we develop detailed specifications. Peter's document entitled "6320 EDI Addr Bus Case & Reqmts," at http://www.novannet.com/wedi/, describes the Proposed Work of this group, in Section 7.0: a. Write technical specifications for syntax and code structure for the EDI Address including its associated attributes. The sequence is to begin with the easier and continue to the more difficult. b. Define attribute code tables. c. Determine required changes, if any, in X12 and other standard transactions. d. Coordinate with WEDI-AFEHCT Health Care Communications Security and Interoperability project. Coordination between the two projects is critical. In addition, Peter's document "6010 Project Organization" defines our Deliverables in section 3: "The project will write implementation guidelines and specifications with technical specificity suitable for implementation," just confirming what he said in the 6320 document. I can see the White Paper describing the problems which have been elicited through our discussions: How do you identify the sender and receiver of a standard transaction on the ISA? How can this be done in a consistent way so interchanges can be delivered via intermediaries like VANs or CHs, or point-to-point? Who are the trading partner entities involved in exchanging standard transactions? What kind of identifiers are available for describing these entities? How do you describe the path traversed between trading partners through intermediaries and business associates? How do you describe the different "in-boxes" used depending on transaction type? What do you have to know about a trading partner's technical capabilities before you can send them a standard transaction?What information does a Trading Partner Agreement contain to answer any of these questions? What sort of communication protocols are in use today that need to be supported? What sort of packaging techniques are used? Can a Trading Partner Agreement be made into a machine-processable form? If so, how might those electronic TPAs be "discovered" for your trading partners? Can this "discovery" be made automatic? What's the relationship between the payer, plan and contract application identifiers and the routing identifiers used in the ISA? And ad infinitum. And there are sub-questions: e.g., if we know we're going to need an Electronic Trading Partner Agreement (e-TPA), then can we use the CPP? If not as it stands, then what changes would be needed to the CPP? What about the 838? Should we consider our own XML version of an e-TPA? Or if we need a directory for "discovery" of Trading Partners, will UDDI or the ebXML RegRep suffice? If not, can we devise our own? Who would maintain it? If we can ask those questions - and if we agree that they're relevant - then we can go on to develop Peter's specifications, including specific recommendations for changes to the CPP, if needed. Or if we can't use UDDI or ebXML RegRep, then we might have specifications for implementing Kepa's suggested DNS "directory." Let's not bite Kepa's heels simply because he came up with a simple solution for finding a trading partner based on identifiers before we had any UML diagrams. None of the questions I've posed above are mysterious or new - they've been asked (though not necessarily answered) on this list one or more times. Questions lead to more questions. Isn't that how you come up with a list of requirements? Honing the requirements might even lead to a change in direction or scope, or even our SIG name: I can see us changing it from "ID & Routing" to "Electronic Trading Partner Agreements" to better describe where we're heading. But we can't develop a list of requirements in a vacuum: specificity is required. Am I missing something here? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, 26 February, 2002 11:04 AM 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
