DELIVERABLES

This WEDI/SNIP Business Issues Special Working Group is currently working on four working papers to answer questions relevant to IDs and Routing:

• Identifiers. How do you identify the sender and receiver of a standard transaction on the ISA? How can the ISA be addressed in a consistent way so interchanges can be delivered via intermediaries like VANs or Healthcare Clearinghouses, 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? What's the relationship between the payer, plan and contract application identifiers and the identifiers used in the ISA?

• Addresses and delivery channels. How do we specify the destination technical address and its attributes? How do you specify type of security - e.g., login and password, or X.509 public key certificates? How would you accommodate scripting? How do you describe the multi-hop 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? and what sort of packaging techniques are used?

• Elements of the Healthcare Collaboration-Protocol Profile (CPP). Can a Trading Partner Agreement or "companion" document be made into a machine-processable form? Can we use the ebXML CPP? If not as it stands, then what changes would be needed to the CPP? How would EDI Addresses and Delivery Channels be represented in the CPP? Can a CPP completely supplant the need for paper TPAs?

• Discovery of Healthcare CPPs. How might electronic CPPs be automatically discovered for your trading partners? If we need a directory for "discovery" of Trading Partners, will UDDI or the ebXML Registry suffice? If not, can we devise our own? Who would maintain it?

The recommendations coming out of the ID & Routing group don't have to wait till you have "smart" auto-configurable software which can use the XML CPP. We will develop XSLT style-sheets to display CPPs which have been discovered via a directory, rendering them in a human readable fashion on a web browser.

The CPP - or Electronic Partner Profile - will contain all the standard setup information for your trading partner you'll ever need. It will include communications protocols, URLs, EDI contact addresses, "companion" document information (e.g., explanation of situational elements), supported transactions, security and acknowledgement requirements, and so on. The CPP will be located in the Registry, found simply by providing an identifier (like a NAIC Company code, Federal Tax ID or DUNS - or eventually the National Plan or Provider ID). So even if you have to copy and paste information from your web browser into your existing communication and translation software, it will sure beat paper documentation! And it will be in a consistent format, regardless of trading partner or software vendor.