RE: options for the CPP Repository address (in the registry)
Dick, I seem to have lost track of how Kepa's DNS model fits in with this registry/repository idea. Was this an alternative registry concept... another way to point to the same repository that we would use with an ebXML implementation? Not being familiar with DNS and MX record structure/function, I never did understand Kepa's proposal in great detail. If that is still on the table, can you re-explain it? Thanks, Chris At 07:47 PM 6/10/02 -0500, you wrote: Chris, Regarding: 1. Do we say that the CPP repository identification element in our CPP registry MUST be a URL? I think it depends on the model that's adopted. If Kepa's DNS model becomes the standard then I would expect a name service query to produce something like: ebXMLcpp http://b2b.mycompany.com/ebxml-cpp.xml /ebXMLcpp On the other hand, if the model follows ebXML Registry/Repository standards then I would expect a response like that found in section 8.x of: http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrs.pdf 2. Is URL sufficiently well-defined to encompass any form of document address that a registry-user might reasonably want? A URL certainly can contain enough information to identify a CPP document, for example: https://www.yourcompany.com/getdoc.jsp?companyname=Happy%20HealthcompanyI D=123456789planid=xdoctype=ebxml-cpp or https://www.mycompany.com/MYcpp.xml The inquirer can retrieve the document URL and would, of course, have to know how to interpret the document returned. Regards, Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com http://www.systrends.com Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 -Original Message- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 5:49 PM To: [EMAIL PROTECTED] Subject: options for the CPP Repository address (in the registry) Dear Group: It has been suggested that the CPP Registry could point to all sorts of information sources, in which a healthcare entity could list its EDI connection requirements... even including a 1-800 phone number to a payor's EDI Customer Service department. But for our official registry specification, can we require this to be a URL in the form http://regularwebaddress.something;? I'm not sure of the official definition of Uniform Resource Locator or what URLs might look like if they pointed directly to an XML document rather than to a conventional HTLM page. So I guess I'm asking two questions here: 1. Do we say that the CPP repository identification element in our CPP registry MUST be a URL? 2. Is URL sufficiently well-defined to encompass any form of document address that a registry-user might reasonably want? Thanks, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
RE: An Overview or Primer Document
I continue to be concerned about the lack of problem definition and lack of focus on some critical milestones for health care: 1. ASCA requires all covered entities which have submitted a plan and extension request to begin testing with external trading partners by April, 2003 2. ASCA requires all covered entities which have submitted a plan and extension request to be fully compliant with the Electronic Transaction Final Rule by October 16, 2003. 3. Covered entities which have NOT submitted a plan and extension request by October 15, 2002 must be fully compliant with the Electronic Transaction Final Rule by October 16, 2002. Question: how does/can any working paper covering these topics: (1) Identifiers (2) Addresses and delivery channels (3) Elements of the Healthcare Collaboration-Protocol Profile (CPP) (4) Discovery of Healthcare CPPs (i.e., the Registry) enable the industry to achieve any one or all of these milestones? And, what problem(s) that are currently seen as barriers/obstacles to achieving these milestones would any of these working papers address? Lastly, how would any working paper covering any or all of these topics provide any specificity to a problem not yet defined that any of the vendors could evaluate and incorporate into their solutions offerings? I'm all for being a visionarybut a vision without a starting point is just a wish. Rachel Foerster Principal Rachel Foerster Associates, Ltd. Professionals in EDI Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 8:59 AM To: WEDi/SNIP ID Routing Subject: An Overview or Primer Document Our near-term plan is to generate four working papers. These papers will eventually be combined into a white paper or recommendation containing implementable specifications for the Healthcare CPP electronic partner profile and Registry. The four working papers cover: (1) Identifiers (2) Addresses and delivery channels (3) Elements of the Healthcare Collaboration-Protocol Profile (CPP) (4) Discovery of Healthcare CPPs (i.e., the Registry) A little more background on the project and working papers is available at http://www.novannet.com/wedi/. Lynne Gilbertson's message reminds us that a primer (or Overview or Background) document is really necessary - something that says in plain English (or bloated, turgid English if I were to write it) just why we're going to all this trouble to build an electronic partner profile - and a Registry to point to it! This document would include background on the existing Healthcare EDI environment (where we are), the ideal (where we want to go), Identifiers as they relate to routing of transactions, a high-level description of an Electronic Partner Profile, a high-level description of the Healthcare Registry, along with some examples of how all this would look in practice. I propose that the first Working paper, Identifiers, simply be changed to an Overview document. Currently, Ron Bowron and I are assigned to the Identifiers document; if there's no objection to turning the working paper into a usable overview of the project, would there be anyone else who would like to volunteer to assist us in writing it? I anticipate that a large part of the document will be an organized and edited cut-and-paste of postings to the ID Routing mailing list over the last 4 months. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Lynne Gilbertson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 06 June, 2002 04:35 PM Subject: RE: registry and repository NCPDP has created a task group to assist in the routing registry endeavor. As the task group is made up of business and technical folks in the pharmacy industry, is there a primer document or something they can read to come up to speed with the work being done? thank you
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 individually [further] secure sections of the repository record, but would a dig. certificate be a reasonable way to secure the repository front door? My suggestion would be to include a data element in the repository (perhaps another URL) that pointed to a default access denied message created by the repository record owner. (I guess in the absence of an entity-specific access denied message that provided an alt. means like a cust. service phone #, the user would simply get a page not found error) More questions (assuming that we do want to secure the front door with a certificate): 1. How tough are these to obtain? Could Mr. Hacker apply for one and thereby have the keys to the kingdom? 2. Are there standard protocols (possibly in the ebXML CPP specifications) for implementing this type of auto-authentication when you attempt to access a URL? 3. How many data elements would be necessary in the repository record to handle auto-auth... and what would they be called? Regards, Chris Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
