Mark: To summarize... your last paragraph, which said:
"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 usinga common approach for it to be implemented and successful." The last sentence above is exactly what the new version of the white paper is recommending/suggeting... that certification is defined as third party assesment, recommended and NOT mandated, and... that all the vendors, which includes the suppliers of the translator software, software that does HIPAA transactions straight away and the testing software and or services all of whom will have to use compliance checks basically form a consortium. Here is my analogy: This is NOT any different from different vendors providing ANSI C (HIPAA X12N is the standard) native C compliers (of different vendors) which has say syntax and semantics checking. One example where vendors have formed consortiums to all agree to produce software conforming to some standard that all can use is... OPEN GL. While HIPAA is likened to Y2K for using some of the lessons learned, it different in that the date is not hard and that is the bottom line. So there is LOT MORE to worry about than just one date field, where ever it occurs. Regards, Rama. -- ---- "Mark A Lott" <[EMAIL PROTECTED]> wrote: > 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. > > 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.
