Mark states: "When we begin to put all the various HIPAA technology pieces together, we will find a very startling truth."
The startling truth is that vendors are intrepreting the IG Guides differently. These differences may be very minor and difficult to discern (to impossible) the source of the error. Thus, the need for public comment and clear definition on the meaning of HIPAA compliance as related to the IG Guides. Enter the HCCO..... Julie From: "Mark A Lott" <[EMAIL PROTECTED]> Reply-To: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, "Hipaa Certification - Yahoo \(E-mail\)" <[EMAIL PROTECTED]> Subject: RE: Certifications Date: Sat, 31 Aug 2002 14:04:27 -0700 Greetings, I would like to elaborate on the discussions over the past few days concerning certification, its apparent value and my argument that given the current climate it is completely unusable in its current proposed format. Certification of any kind must be based upon an agreed upon set of conformance specifications, not any one organization's interpretation, unless of course the entire country all flows through that vendor. When software vendors use different methodologies and different outcomes to determine the desired specifications you have completely lost any possible baseline from which to base a valid, portable 3rd party certification. Interoperability is also lost, which means every trading partner would have to test with every other trading partner, only to find the same discrepancies in every single community. Imagine if you will, an enormous JADD session with every single covered entity in the country trying to determine how each community would interpret the rules? Sound like an impossible task? It is, therefore it is in the best interest of the industry to solve this impending hardship on covered entities. IT Development 101: (apologize for the simplicity but need to document as a reference point) Every IT project starts with a set of business requirements in this case it is a combination of X12, IG's, Companion Guides, covered entities internal requirements, etc... The next step would be walkthrough of the business requirements to determine that all parties agree with the requirement definitions. Many business requirements start out as vague and are refined through a change control process (hopefully) resulting in an agreed upon clarification. Test conditions are then developed to prove business requirements are successfully achieved. During this initial test planning phase, business requirements undergo additional changes because if a specific test case cannot be generated to prove a given business requirement then the requirement is still considered vague and not testable. The same applies for the actual testing phase in order to determine the direct course of action for resolving any defects found. Using the previously mentioned methodology, let's examine transaction testing through this completely fictitious but very realistic case study: Software vendor #1 follows this methodology to create their software to validate transactions. This process is completed internally among their IT staff and their software is built based upon their internal understanding of the business requirements. Vendor #2 follows the same process to create their software to validate transactions based on their understanding. Vendor #3 follows their process, etc. Each vendor has publicly released their criteria to the industry to show their interpretations of the business requirements. The industry now has 3 vendors all offering the same service for transaction validation, unfortunately for the covered entity, all vendors provide different feedback as to transaction readiness. Which one is right? Are any of them right? This same example applies for translation software with built-in edits, billing software validated by any of the software validators, etc., multiplied exponentially. Covered entities will be purchasing all three vendors products and using them to determine their readiness levels. Since the vendors do not agree, the covered entity is now left exposed and in essence, the vendors have pushed the responsibility for the correct interpretation to the end user. Of even greater impact, is the fact that even though a covered entity believes their transactions are "compliant" based on a vendor's determination, the covered entity will not be able to achieve interoperability with any other trading partner that didn't use the exact same vendor readiness check. Therefore without a baseline from which to determine and code validation software, the process is not portable across infrastructures. Nor, can we expect covered entities to build hundreds of "special" edits to adjust for the various software vendors interpretations of the transaction requirements. This topic is starting to gain consensus, the vendors realize it, the translators realize it, and now it is time for the covered entities to realize the implications that this will have on their ability to perform HIPAA transactions come this or next October. This should be the single most important aspect that needs to be resolved otherwise covered entities are better off going back to paper or the old transaction standards, at least that way they can still conduct business and generate revenue. Another analogy for the group: My Physics professor asks me to write a theoretical paper describing how to launch a rocket to the moon using a new method never tried before. I did my research and based on several different vendors products and their schematics, I proposed a new solution and on paper it looked like a great idea. My Applied Physics professor then requests that I take what I proposed and implement it. Much to my dismay, that while each vendors idea and product seemed like a great idea independent of each other, when I tried to combine them into a propulsion system I found that each piece was incompatible with the others. When we begin to put all the various HIPAA technology pieces together, we will find a very startling truth. Ideas will only work after you have proven that they can be implemented. My point - This isn't rocket science, just common sense. So my question to the group - what good is a certification if it is only valid within a vacuum? Therefore to say you can deterministically validate Transactions to be in HIPAA compliance is a vacuum statement. Covered entities do not operate in a vacuum. Although, you can say that according to vendor #1, the transactions are compliant according to vendor #1's methodology and are a direct representation of vendor #1's internal development and testing staff in accordance with vendor #1's interpretations of the requirements. The same goes for vendors #2 & #3. In this case what are we saying to the covered entity, besides best of luck? I am still unclear as to what benefit that has to covered entity, who cannot take that 3rd party certification and use it anywhere else without much rework for each community only to find out the changes they made now no longer work in the previous community they just tested with. I have spoken with many experts in the HIPAA IT industry and they are keenly aware that his is a major problem. Unfortunately there are many covered entities not so technically savvy and they will be at the mercy of opportunistic marketing efforts and promises that cannot be achieved, by the time they find this out, it will be too late and their budget will be spent. Note: Regardless of a one paragraph or twenty page disclaimer, when an organization promises HIPAA Compliance or HIPAA Certified, they denote to the covered entity, expectations that can never be met. Ethically speaking, we should completely stop using these phrases. They will only bring harm to the industry and to the organization that promises it, unless of course on October 17, 2003 they plan on closing shop and taking the money and running. I am not sure how much longer we need to continue to belabor this point, instead our energies must be spent moving forward with solutions to solve this problem. 3rd party certification is very important and has enormous value to all covered entities, we just have to make sure we are using a common approach for it to be implemented and successful. Regards, Mark A Lott Executive Co-Chair HCCO - Transactions Group HIPAA Conformance Certification Organization CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 10:39 PM To: David W. Loewy; [EMAIL PROTECTED]; 'Meyer, Perry'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Certifications David, Tim, Before you keep going too far on that line, there is a significant difference between "certifying" an entity or a product to "be" HIPAA compliant (personally I don't see how this would happen) and certifying that a specific set of transactions is in compliance with the HIPAA transaction implementation guides. To verify whether a transaction is in compliance with the HIPAA Implementation Guide is a process that is totally deterministic and objective, and can be verified and validated by a number of third parties. In any case, the process must be disclosed and verifiable by third parties and by the relying parties. An entity relying on the certification of a transaction as being compliant should be able to know what was the exact content of the transaction that was certified. And the certification of a transaction as compliant does not automatically extend to the software that generated the transaction in a generic mode. While you can say that the software is capable of generating HIPAA compliant transaction(s), you cannot say that all the transactions generated by that software will always be compliant. However, if the sample size is sufficiently large and representative of the business of the provider or payer that generates these transactions, then you could establish a level of confidence that future transactions will also be compliant. But, again, this does not extend to the software or the entity in as generic way. For instance, the fact that you can generate compliant office visits does not mean much when you need to generate DME claims. For this reason it is important that the certification of transactions as compliant be well documented and publicly disclosed. So, lets qualify the statements. When organizations claim to "be" HIPAA Certified, or to offer "certified" training, or to have certified HIPAA transactions they should try to "prove it". I bet they will not be able to prove they "are" compliant, or that their software or training is certified, but we can prove their TRANSACTIONS are or are not compliant. The testing and certification of TRANSACTIONS for HIPAA compliance is documented in the SNIP white paper on that topic. There is a new version that has been approved for publication (version 3.0) that should be posted in the web site in the next few days. Please understand that it does not address certification of entities, software, systems or training programs, only certification of transactions. Kepa Zubeldia Claredi PS: cross posting of messages like this is spam. On Friday 30 August 2002 11:19 am, David W. Loewy wrote: From: "David W. Loewy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>, "'Meyer, Perry'" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> > I agree as well, I am constantly amazed when I see organizations > referring to being either HIPAA Certified or offering HIPAA > Certification!! And there are more than a handful I've seen recently! > > > David W. Loewy > President > Health Providers Practice Management, LLC. > Publishers of The HIPAA Survival Kit for Providers > 617.739.6665 (voice) > 601.415.0007 (mobile) > > > <http://www.hipaacertification.org/> > www.hipaacertification.org > NOTE: The information contained in this message is intended only for use > by the individual or entity to which it is addressed. This message may > contain information that is privileged, confidential, and exempt from > disclosure under applicable law. If you are not the intended recipient, > you are hereby notified that any dissemination, distribution, or copying > of this information strictly prohibited. If you have received this > communication in error, please notify us immediately and delete the > original message. > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 30, 2002 12:58 PM > To: Meyer, Perry; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Certifications > > > Perry, your point is very valid! > > As stated by the agencies, it isn't the role of the government to > "Certify" a product, service, or process relating to HIPAA. > Certifications by their nature certifications require a process of > accreditation, credentialing, and ideally broad support. I have no > knowledge of what the vendor in question bases their "certification" on, > and without full disclosure of that basis I view its claim as suspect, > however there is at least one validly certified training/education > product in the market - certified/credentialed by a State University > System. > > However, this specific problem has resulted in the creation of a > separate body to address this issue of developing HIPAA conformance > certification standards. This activity is complementary to the work of > the other HIPAA bodies, and recognizing the urgency of this for covered > entities and industry alike, has begun and hopes to publish a > significant body of work rapidly. > > This also raises another important point - full disclosure. Some on > this listserv express offense at participants including their company > names in their replies and messages. Personally, I want to know who it > is that is expressing their opinions and who they represent, and in what > capacity. I appreciate a weblink also, making it easy to view their > context. Without this disclosure, we do not have the ability to > properly weight their credentials or perspective in these issues. Each > of us needs to be able to evaluate each posted statement and not simply > take everything said as fact or legal opinion - this one included. So I > would encourage all to be candid in their signatures for these reasons > and recognize the difference between spam commercialism and simple > honest disclosure. > > Tim McGuinness, Ph.D. > President, > HIPAA Help Now Inc. > [EMAIL PROTECTED] > www.hipaahelpnow.com > > Executive Co-Chairman for Privacy, > HIPAA Conformance Certification Organization (HCCO) > www.hipaacertification.org > > > > > -----Original Message----- > From: Meyer, Perry [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 8:24 AM > To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: WEDI SNIP Forum to be Rescheduled!!! > > > Just curious, but does CMS or OCR recognize "certified" HIPAA training? > I see no mention of this in the regs. I think we need to be very > careful in promoting something as "certified" when it comes to HIPAA. > > Perry Meyer > Senior Vice President > Iowa Hospital Association > To be removed from this listserv, please email [EMAIL PROTECTED] <P>The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited. To be removed from this listserv, please email [EMAIL PROTECTED] <P>The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To be removed from this listserv, please email [EMAIL PROTECTED] <P>The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
