Re: CPP and COB, was The use of Supplemental IG's
It seems that I've touched the third rail of HIPAA EDI: companion guides! Nonetheless, I have to reiterate again that companion guides are relevant to our work devising the CPP electronic trading partner profile. Peter Barry, our senior executive co-chair, had recently summarized on 05-30 two types of information entailed within the term EDI documentation: (i) connectivity attributes, which are the primary subject of the CPP suggesting there might be a more efficient way to let provider computers know the terms for connectivity, and (ii) transaction requirement profiles, the subject of companion guides, which might become electronic profiles, the 7-level edit subjects. If these subjects cannot eventually be reduced to computer-readable information, we will have lost a lot in the goals of standardization. And Peter is just repeating what was agreed upon when the Project Purpose scope was enlarged in early March. The scope was broadened [to allow us] to investigate ways not only of describing EDI addresses and attributes, but also mechanical representations of companion documents, in the formation of electronic Trading Partner Agreements. See Electronic Trading Partner Agreements - 3/5 Conversation with DWT (03-07) at http://www.mail-archive.com/routing%40wedi.org/msg00305.html. Now, if there were an objection to including machine readable companion guide information in the CPP at the time it was proposed, I must have missed it. There's no doubt that we can include in the CPP URL links to PDF or Word renditions of companion guides; but it was also our intention to investigate the possibility of reducing all or parts of these companion guides to XML'ized computer-readable information for the automatic configuration of maps. Larry Watkins has now informed us that the Transactions WG is already considering how to proceed with the issue of companion guides. That's good to hear, and some of us look forward to giving our input into the process. And ID Routing will use any results to guide the design of machine-readable companion document information within the CPP, which is clearly within our charter. But I suspect that by the time a careful evaluation of companion documents is made, we'll find out that there isn't much that can be made machine-readable. Most of what could have been made so - the things that go into an implementation guide like allowable delimiters, maximum repeat counts, acceptable code sets and the like - are probably illicit under HIPAA. We'll be left mostly with just textual information describing the adjudication process, which can be accommodated with URL pointers or text strings within the CPP. If my suspicions are correct, we've greatly reduced the amount of work we'll have to do. Further, I was very clear that the deepest we'll have to get into business analysis is to analyze what the HIPAA IG business models already say. We have no need to analyze Healthcare Administration from the ground-up for anything we're doing in ID Routing, as we can use what's already illustrated in the HIPAA IGs. This will probably be true of COB, an issue which has been repeatedly raised by Dave Minch over the course of months, but as recently as 06-13: I do have a further question for Bruce regarding development of trading agreements with other payers or third parties regarding COB claims. I'm trying to determine business requirements for payer--payer CPP elements, and i'm completely in the dark on how you do it today, or how you plan on forwarding COBs from standard transactions. I was only able to speculate, for Dave's benefit, on the symmetricity of CPPs - i.e., certainly payers will be able to discover other payers, just as providers and payers can discover each other. But that's only part of the answer, and probably something Dave already knew; I'm guessing that he really wanted to know how the CPP could advertise COB capabilities (to either providers or other payers). Unfortunately no one has deigned to come forth with any suggestions on his very pertinent question - if only to say it's not relevant because it's not a problem (which I think Kepa's Myth #233: COB claims might be saying). Telling us Dave's concern is out of scope is no answer whatsoever. I am asking that folks be extended the simple courtesy of letting them make their points and ask their questions. The co-chairs will decide what's within scope if distractions become a problem. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Saturday, 06 July, 2002 01:28 PM Subject: RE: CPP and COB, was The use of Supplemental IG's William, I disagree with your interpretation of both the Electronic Transaction Final rule preamble and the HHS FAQ. First, the FAQ: You quoted the following: It is the health plan's decision as to
Re: digital certificates for access to CPP repository
Somehow, during the discussions of SPAM, anti-SPAM, Kennedy's bill, invitations to testing webinars, etc., we must have lost track of Chris Feahr's Registry authentication questions (below). Though this is indeed a big can of worms, fortunately we have folks on board who take special interest in such things - namely, our friends from US NIST. The OASIS ebXML Registry Technical Committee is also looking at these kinds of problems within its Security Services sub-committee. Maybe I can persuade Lisa Carnahan to take our requirements back to the Security Services people. Lisa is both a member of the OASIS ebXML Registry TC and of our group, and she has volunteered to be our Registry expert and co-author our working paper on Discovery of Healthcare CPPs. As an aside, Joe Rosmann has reminded me that there is an ebXML paper - the ebXML Registry Security Proposal - that gives some background on authentication, integrity and confidentiality with respect to the ebXML Registry; it's a little dated and rough, but still available at http://www.ebxml.org/specs/secREG.pdf. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'joe mcverry' [EMAIL PROTECTED]; 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 12 June, 2002 02:05 PM Subject: RE: digital certificates for access to CPP repository Joe, I understand. On the other hand, how else would you authentic an entity attempting to access a CPP reposistory? Furthermore, even assuming authentication, it's not at all clear to me that all entities would want their CPP info to be accessible to all parties accessing such a registry. This is a big can of worms and without any business case and business requirements, I believe that details of this type are much too premature. My concern is about the complexity that is ensuing as a result of these discussions and that I don't believe this (CPP/A, registry, etc.) is at all essential for health care to achieve compliance with HIPAA by the various drop-dead dates. Rachel -Original Message- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 9:42 PM To: [EMAIL PROTECTED] Cc: 'WEDi/SNIP ID Routing' Subject: Re: digital certificates for access to CPP repository If authentication is in place then there should be no need to worry about digital certificates for access to CPP repository. - Original Message - From: William J. Kammerer [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 11 June, 2002 04:18 PM Subject: Re: digital certificates for access to CPP repository In the current version of the OASIS ebXML Registry specification, there are no provisions for confidentiality of Registry content. All content submitted to the Registry may be discovered and read by any client - which means anybody can find out that an entity is accessible via the registry, and where their CPP is located. On the other hand, only authorized submitters who have been authenticated using digital signatures can publish data in the registry. I am assuming that this means there exists a fine-grained mechanism whereby only the owner (or his agent) of information (e.g., the CPP) can submit or change his own information - as opposed to having to submit his information through a central authority for inclusion in the Registry. The CPP owner may have some means of obfuscating his own CPP, or parts thereof - revealing information only to authorized users- since the CPP itself could very well reside on his own server. Of course, I'm making a lot of assumptions. The details have to be ferreted out by the folks responsible for the working paper on Discovery of Healthcare CPPs: Peter Barry, Joe McVerry, and Dick Brooks! I think Joe only volunteered to look into UDDI. That leaves Peter and Dick to be the experts on the ebXML Registry. Maybe I could add Lisa Carnahan to the list, too. Does anyone else want to volunteer? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Christopher J. Feahr, OD [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, 10 June, 2002 06:31 PM Subject: digital certificates for access to CPP repository Dear Group: I would like to know if we have agreement (or could agree) on the following requirements regarding access to the CPP registry/repository data: 1. Allow any party to access the CPP registry, thus obtaining the URL that points to an entity's repository record(s). 2. Require a standard mechanism for entrance to the CPP repository record that somehow looks for a valid digital ID certificate If every CPP repository user was required to have a valid ID certificate somewhere (e.g., the AMA/Verisign deal that was mentioned once) then requiring that certificate as the entry pass to the repository would seem to be a way to keep the riff-raff out. I think we may still need ways to
