[ebxml-cppa] CPPA goes to the hospitals, maybe

[James Bryce Clark <jamie.clark@mmiec.com>]

I thought the group would find the attached excerpt interesting.  It 
discusses possible application of our CPP/A or CPP/A-like work to a 
specific healthcare setting.

It is hard to evaluate the plans from this snippet.   I do have some 
questions about the apparent embrace-and-extend lock-in plans for standards 
and registry functions.   Still, it seems interesting.    My company used 
to participate actively in WEDI before its focus changed, and the HIPAA 
domain is my day job, so I plan to follow up.  I will report back if there 
is some potential for ".next" CPPA team outreach or domain-specific mapping.

>From: "William J. Kammerer"
>To: "XMLEDI Group" <xmledi-group@disa.org>
>Subject: Re: Topics
>Date: Fri, 10 May 2002 09:40:35 -0400
>
>Walt:
>I don't know if there's much going on within the XML EDI workgroup - we'll 
>have to wait for David RR Webber or Alan Kotok to tell us more. But I see 
>that you, being from an "innovative BCBSFL and Humana joint venture" and 
>also involved in WEDI,  may very well be interested in what we're doing in 
>the WEDI/SNIP ID & Routing group with respect to ebXML.
>
>We're developing recommendations for the "auto-discovery" of trading 
>partners (payers, providers, third-party administrators, etc.) and their 
>technical capabilities. Borrowing from ebXML, we plan to devise an XML 
>schema for an electronic Healthcare Collaboration-Protocol Profile (CPP). 
>CPPs will be located by Trading Partner ID of any participant
>involved in HIPAA Health Care EDI - either through a DNS-based "directory" 
>of our own design, or possibly UDDI or the OASIS ebXML Registry.
>
>I'll be in Denver at the WEDI 2002 National Conference next Wednesday to 
>present a short slideware overview of the Healthcare CPP and Registry.
>
>Please join the WEDi/SNIP ID & Routing group by going to 
>http://snip.wedi.org/listserv/ and signing up for "Routing." Postings are 
>sent to the mailing list at routing@wedi.org. We need volunteers who can 
>contribute requirements and perspectives from all stakeholders:
>payers, providers, clearinghouses, and third party administrators and 
>other intermediaries. Project documents and archives of the 
>routing@wedi.org mailing list are available at the WEDi/SNIP ID & Routing 
>Group Web page at http://www.novannet.com/wedi/.
>
>This project will publish implementation guidelines for (1) the CPP to 
>mechanically configure communication and translation software, and (2) 
>automatic "discovery" mechanisms for locating trading partners' CPPs on 
>the Internet based on their business identifiers.
>
>These recommendations and specifications may someday make it easier for 
>your automated software - or *your* clearinghouse - to "discover" that 
>payer X is reached via a particular Clearinghouse B, or at a particular 
>FTP or SMTP e-mail address. One scenario is how the provider will use the 
>(future) National Plan ID on the patient's insurance card to
>"discover" the EDI address of the payer to whom claims and eligibility 
>requests should be sent. The insurance card will contain the card issuer 
>number which includes the (National) plan ID; using our recommendations, 
>this Plan ID would be the (preferred) key to searching for the EDI 
>address(es) of the ultimate payer.
>
>The group is currently working on four "working" papers to answer 
>questions relevant to IDs and Routing:
>
>* * *
>(3) 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?
>
>(4) "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?
>
>Ancillary to our technical recommendations, we're also working on the 
>problem getting rid of paper Trading Partner Agreements (TPAs): if the TPA 
>"problem," or onerous manual EDI enrollment procedures, cannot be gotten 
>out of the way, then automated trading partner "discovery" has less value. 
>Payers' requirements for paper TPAs are a real impediment to
>enrollment of providers for EDI at the moment.  The recommendations coming 
>out of the ID & Routing group don't have to wait till you have "smart" 
>auto-configurable software that can use the XML CPP. We may develop XSLT 
>style-sheets for displaying CPPs that have been "discovered" via a 
>directory which can render them in a human readable fashion on a web 
>browser. The CPP will contain all the standard trading partner setup 
>information of 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, etc. The CPP will be located in the Registry 
>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.
>
>William J. Kammerer
>Novannet, LLC.

~ James Bryce Clark
~ VP and General Counsel, McLure-Moynihan Inc.
~ 1 818 597 9475   jamie.clark@mmiec.com  (www.mmiec.com)
~ Chair, ABA Business Law Subcommittee on Electronic Commerce
~ (www.abanet.org/buslaw/cyber/ecommerce/ecommerce.html)