Re: An Overview or Primer Document
Rachel: I hadn't really thought of that before: using the critical timelines to sell the concept of the Healthcare CPP and Registry. But now that you bring it up, the overview should definitely include verbiage on how the CPP especially facilitates the industry achieving these critical milestones. Would you mind doing that part of the overview? Obviously, most folks are going to continue using Clearinghouses to help them become HIPAA compliant, but as we've long said, the CPP and Registry are useful to intermediaries also. With Internet connections to clearinghouses and CMS, there are the new HIPAA mandated security rules to deal with which require signatures and encryption - and the CPP is the ideal mechanism for sharing and disseminating certificates. And though it's a given that payers have to support all the standard transactions, the CPP is critical for broadcasting the capabilities of individual providers, avoiding onerous manual interaction as standard transactions are brought online one at a time. Though I'm no big fan of *mandatory* certification, certification is still a good thing to have: the CPP is the most efficient means of conveying your certified capabilities to your partners. And though it could be left unsaid - after all the discussion of the last couple of weeks - I'll say it again: I think Open-EDI is going to spring on many payers as a surprise by H-day, and only an automated infrastructure provided by the CPP and the Registry will make that at all possible. Thanks again, 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: Tuesday, 11 June, 2002 06:45 PM Subject: RE: An Overview or Primer Document No, William. I'm not at all suggesting that the CPP or any ebXML registry needs to address any filing submission under ASCA. That would be something that should be determined as part of a requirements analysis and management effort. I was identifying critical timelines by which the health care industry must comply with various aspects of HIPAA and trying to determine how any of these proposed working papers either facilitate the industry achieving these critical milestones and/or remove barriers and obstacles to the industry achieving these milestones. Rachel
HIPAA Privacy, Security and the Intersection with EDI
Fact 1: Almost all (if not all) of the currently mandated HIPAA EDI transactions contain protected health information Fact 2: Today's business model supports and enables protected health information to be stored redundantly by many intermediaries between a health care provider and payer at substantial cost Fact 3: It is highly probable that today's business model will continue for a substantial period of time unchanged following the HIPAA drop-dead compliance dates for either or all of privacy, security, EDI Fact 4: Data at restis substantiallymore vulnerable to disclosure/access than data in transit...regardless of whether the dataat rest is in asecured or unsecuredenvironment Fact 5: HIPAA requires the implementation of appropriate safeguards for protected health information - today and tomorrow Question:Given these facts, howdoes one evaluate the effort of this group to developing a series of working papers on the topics of identifiers,addresses and delivery channels,elements of the Healthcare Collaboration-Protocol Profile (CPP), discovery of Healthcare CPPs via a Registry, address, solve or mitigate any of the issues and/or problems inherent in the current business model which I believe can reliably be predicted to continue for a substantial period of time into the future surrounding the electronic exchange of health information? Comments: It seems to me that this is a highly visionary model (one which has not yet been implemented in any other industry to date) only serves to add further complexity and confusion to an already highly complex and confused industry. There are solutions already commercially available and affordable that address these issues. So please, I'd appreciate some succinct words of explanation that one could use when talking to industry participants about how identifiers,addresses and delivery channels,elements of the Healthcare Collaboration-Protocol Profile (CPP), discovery of Healthcare CPPs via a Registry help any one or all of them implement an EDI capability that enables compliance with HIPAA by either April 14, 2003 (privacyand security), October 16, 2002, or testing by April, 2003, and full implementation by October 16, 3003. Rachel FoersterPrincipalRachel Foerster Associates, Ltd.Professionals in EDI Electronic Commerce39432 North AvenueBeach Park, IL 60099Phone: 847-872-8070Fax: 847-872-6860http://www.rfa-edi.com
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. Rachel Foerster wrote: Oh Lordy, Lordy! Are we going down a rabbit hole with Alice or what! I understand authentication is part of the CPA spec, but how is this relevant to getting the industry up and running with EDI by the HIPAA compliance dates? Rachel -Original Message- From: joe mcverry [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 11, 2002 4:13 PM To: WEDi/SNIP ID Routing Subject: Re: digital certificates for access to CPP repository Authentication has been addressed in several levels. For example a snippet from the ebXML CPA documents reads quote 8.4.13.5 isAuthenticated attribute - The isAuthenticated attribute has the possible values of none, transient, persistent, and persistent-and-transient. If this attribute is set to any value other than none, then the receiver MUST be able to verify the identity of the sender. In general, transient authentication can be implemented using a secure transport protocol like SSL (with or without the use of basic or digest authentication); persistent authentication can be implemented using a digital signature mechanism. Secure transport information is further provided in the TransportSender (see Section 8.4.24) and TransportReceiver (see Section 8.4.32) elements under the Transport element. Persistent authentication information is further provided in the SenderNonRepudiation element under DocExchange/ebXMLSenderBinding (see Section 8.4.42) and the ReceiverNonRepudiation element (under DocExchange/ebXMLReceiverBinding (see Section 8.4.53). The CPA would be inconsistent if isAuthenticated is set to transient or persistent-and- transient, while isSecureTransportRequired is set to false. 8.4.13.6 isAuthorizationRequired attribute The isAuthorizationRequired attribute is a Boolean with possible of values of true and false. If the value is true then it indicates that the delivery channel MUST specify that the sender of the Message is to be authorized before delivery to the application /quote Source: Collaboration-Protocol Profile and Agreement Specification Version 1.11 Author: OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee Date: April 4 2002 URL: http://www.oasis-open.org/committees/ebxml-cppa/documents/working_drafts/ebC PP-1_11.pdf William J. Kammerer wrote: 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,
RE: An Overview or Primer Document
No, William, I'm not interested in taking on this task since I do not believe that a CPP registry is either critical or facilitates the industry's march to compliance by the various drop-dead dates. Comments from CMS re electronic signatures indicate they will not be required under the final HIPAA security rule. Sharing and using digital certificates has much more complexity to it that many people realize.especially across a diverse and fragmented population like health care. The current security NPRM requires encryption only when using an open network, such as the internet. And, please stop beating the drum on Open-edi. It's not on the near term horizon for health care and no other industry has adopted it entirely or in part either. Businesses do business with other businesses with which a prior relationship has been established for the most part. Receiving a claim from a previously unknown provider is an exception and not the rule. Rachel -Original Message- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 10:46 AM To: 'WEDi/SNIP ID Routing' Subject: Re: An Overview or Primer Document Rachel: I hadn't really thought of that before: using the critical timelines to sell the concept of the Healthcare CPP and Registry. But now that you bring it up, the overview should definitely include verbiage on how the CPP especially facilitates the industry achieving these critical milestones. Would you mind doing that part of the overview? Obviously, most folks are going to continue using Clearinghouses to help them become HIPAA compliant, but as we've long said, the CPP and Registry are useful to intermediaries also. With Internet connections to clearinghouses and CMS, there are the new HIPAA mandated security rules to deal with which require signatures and encryption - and the CPP is the ideal mechanism for sharing and disseminating certificates. And though it's a given that payers have to support all the standard transactions, the CPP is critical for broadcasting the capabilities of individual providers, avoiding onerous manual interaction as standard transactions are brought online one at a time. Though I'm no big fan of *mandatory* certification, certification is still a good thing to have: the CPP is the most efficient means of conveying your certified capabilities to your partners. And though it could be left unsaid - after all the discussion of the last couple of weeks - I'll say it again: I think Open-EDI is going to spring on many payers as a surprise by H-day, and only an automated infrastructure provided by the CPP and the Registry will make that at all possible. Thanks again, 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: Tuesday, 11 June, 2002 06:45 PM Subject: RE: An Overview or Primer Document No, William. I'm not at all suggesting that the CPP or any ebXML registry needs to address any filing submission under ASCA. That would be something that should be determined as part of a requirements analysis and management effort. I was identifying critical timelines by which the health care industry must comply with various aspects of HIPAA and trying to determine how any of these proposed working papers either facilitate the industry achieving these critical milestones and/or remove barriers and obstacles to the industry achieving these milestones. Rachel
Re: digital certificates for access to CPP repository
Chris Rachel, I've been holding back on this message for awhile, and some of my information has already been addressed by Rachel or Joe, but I've kept it in this response anyway. Chris' asks: 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 I've interpreted Joe's response correctly, he has provided the technical basis for how information can be shared with trusted and unknown entities. Not having the opportunity to read all the technical functions of the ebXML work, I'd like to believe they've got much of the functionality figured out to allow an entity the ability to protect their digital assets. But with regards to our efforts, my suggestion would be that anyone requesting access to the Healthcare CPP should be required to be fully registered with the Healthcare CPP. So if you don't provide your information including a valid digital certificate, you don't have access to others. I also think this initial registration should only allow access to Testing requirements or publicly known business requirements and each entity would have the freedom to define what others can access based upon a level of trust. This may be over complicating the situation, but it only makes sense to me that an entity would not release certain information to just anyone. From Joe's response, I would assume this is all possible. Also, by requiring entities to register, they could select whether or not they want active membership to be notified of their entry. If so, a receiving entity could develop the ability to automate the Trading partner agreement process (workflow). Otherwise, new CPP entities could notify each individual business that they are interested in an electronic relationship. The new business should not have to forward a bunch of TPA documents, but simply pull CPP for the information, and then provide documents that can be digitally signed using a trusted digital signature, or printed and then manually signed and returned. And, in response to Rachel's request for a real problem definition document. We all know that most of larger organizations have the resources in place to assess and plan for HIPAA, as demonstrated in the latest HIMSS surveys. The issues arise when the medium to smaller businesses attempt to determine where to start, what to do, and how long it will take. If I remember the HIPAA statistics correctly, there are slightly over 6000 Hospitals in the U.S. and over 80% of institutional claims are now electronic. Which means the institutions have already built the necessary relationships and have established much of the connectivity. Most likely the remaining players are the smaller facilities and the smaller insurance plans that haven't yet automated claim entry, adjudication or payment/posting systems. On the other hand, from the HIPAA statistics there are over 750,000 physicians, and I believe it was only 35% of professional claims (Physician Services, Dental, Optical, etc.) are electronic. These are the little guys... There are also many business associates that have yet to figure out where they fit as well. If the little guys are willing to out source their EDI compliance to a Clearinghouse, this could significantly improve the numbers, but arguably (ClaimsNet and others may disagree) even some of the Clearinghouses don't want to be bombarded by every 1-5 physician practice for EDI services - support costs are simply too high for the 20-150 claims per day they might see, or the physicians are not willing to pay the setup costs and ongoing support/transaction fees. So, once a physician upgrades or buys a HIPAA TC compliant office/admission billing management system, and is ready to hook it up to the EDI world, where does he begin? How long would it take to get all of the plans he participates with to approve his transaction interfaces? Or is the clearinghouse his only hope? Even if every covered entity was able to demonstrate that they can produce or process the HIPAA Transactions and Code Sets, determining how to Route transactions to the appropriate covered entity or business associate for processing will be challenging. So, establishing a standard method for discovering how and where to send EDI documents, what identifiers to use to ensure proper routing, seems to be the issue this group is attempting to resolve. If a Standard Service was available for any registered healthcare organization to lookup the business and technical requirements for conducting electronic data/document interchanges with any other registered healthcare organization, I think that could significantly reduce the barriers for organizations to become connected. Especially if the process can be fully automated such that the applications can discover and determine the Interchange and
