Rachel: I spoke to Mark who came up with 5 "things" to look for when testing (and rightly so) and not 5 "Levels", where in Kepa added one more Level and later on changed it to "Types" as "Level" implies a heirarchy and added on more 'Type' and I was one of the people who agreed with Kepa when "Levels" (there was originally no intention to imply any heirarchy when they were first introduced, BTW) to "Types" but all of this really Testing 101 and NOT ROCKET science and there is no need to jump up and down about this 101 thing as if it is some great contribution to save mankind and the planet earth ;). You know this don't you? All this evolution of things is good.
There is a need to revise the white paper and no need to include this history. The history can be provided via an FAQ on the listserv/website. White papers are about problems and soggested solutions, espeially about when it comes to testing software and there is no room for more irrelevant verbiage. It is already heavy with voluminous verbiage with too much focus on Certification without saying what is Certification properly when it is actually Validation that is really recommended. Kepa who says they are synonymous can help us calling it Validation (which is what it is), if he thinks they are really synonimous. I can reproduce some of your emails to list serv a couple months ago that, like someone said, it is Testing, Testing, Testing and not Certification. This peice of information about the history is NOT going to change the importance of Testing or the fact that the improperly defined Certification and the recommendation via the white paper needs to go and hence the NEED to revise it. But before we do that, we need to adapt and adopt a well defined and widely used word in other walks of life in industry, namely, "CERTIFICATION" and NOT redefine or adjust it's meaning to suit a small subset of people. Industry can be informed about the agendas otherwise... and not through the white paper. The purpose of the white paper is to provide guidance to the industry. The obfuscation and confusion around this issue need to be cleared up. If it takes up energy and effort, those who are contributing to the obfuscaiton and confusion can and should help those who are trying to clear up the issue and NOT waste asnybody's time and not the other way around. Thanks. Best Regards and Happy Holidays, --Rama. -----Original Message----- From: "Rachel Foerster" <[EMAIL PROTECTED]> Sent: Sun, 22 Dec 2002 10:55:24 -0600 To: "WEDI SNIP Testing Subworkgroup List" <[EMAIL PROTECTED]> Subject: RE: Institutional Memory (was: Recommendations, noise, agenda) Kepa, Thank you for this very informative historical perspective on this topic. Given the history on this, especially though the regulatory process and resulting comments from industry, it would seem to me that the current white paper is not off the mark at all. Where does this leave us then? Do we revise the current white paper by removing discussion of certification? Given the history on this, my opinion at this time is, no. Perhaps we revise the white paper by inserting more of the history of this topic so that the industry in general will have more insight into it. Or...perhaps we just agree to drop this issue and move on to something else? My personal opinion is that the better approach is to more broadly and definitively inform the industry so that the rancor and debate of perceived vendor agendas, etc. can be put to rest. There is much too much valuable effort and energy being put into a debate that doesn't well serve the industry. Rachel Foerster -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 21, 2002 7:09 PM To: WEDI SNIP Testing Subworkgroup List; Rachel Foerster Subject: Institutional Memory (was: Recommendations, noise, agenda) Rachel, It goes back much further. On May 7, 1998, the transactions PROPOSED rule says (Page 25297) the following: A. Compliance Testing. We have identified three levels of testing that must be addressed in connection with the adoption and implementation of the standards we are proposing and their required code sets: Level 1 -- Developmental testing -- This is the testing done by the standards setting organization during the development process. [more text, omitted for brevity] Level 2 -- Validation Testing -- This is testing of sample transactions to see whether they are being written correctly. We expect that private industry will provide commercial testing at this level. This level of testing would give participants a sense of whether they are meeting technical specifications of structure and syntax for a transaction, but it may not necessarily test for valid data. This type of testing would inform individuals that the transaction probably meets the specifications. These edits would be less rigorous than those that might be applied by a health plan before payment (in the case of a claim) or by a health care provider prior to posting (in the case of a health care claim payment/advice). The test conditions and results from this level are generally shared only between the parties involved. Level 3 -- Production Testing -- This tests a transaction from a sender through the receiver's system. The test information is exposed to all of the edits, lookups, and checks that the transaction would undergo in a production situation. The test conditions and results from this level are generally shared only between the parties involved. The proposed rule continues discussing the desirability for "pilot production" projects, with results posted on a web site. Then the proposed rule, in the next section, solicits input from the industry thusly: We are at this time, however, soliciting input on appropriate mechanisms to permit independent assessment of compliance. We are particularly interested in input from those engaging in health care EDI as well as from independent certification and auditing organizations addressing issues of documentary evidence of steps taken for compliance; need for/desirability of independent verification, validation, and testing of systems changes; and certifications required for off-the-shelf products used to meet the requirements of this regulation. One of the reasons for this particular text was because earlier that year, in the spring of 1998, EHNAC had announced the creation of the STFCS service: Standard Transaction Format Compliance System. The EHNAC had been working on this system for a couple of years prior to the 1998 announcement. The government was trying to get some industry feedback on this concept. And they did get some feedback during the NPRM. As a result of this, the Final Rule on Transactions published August 17, 2000, says on page 50342 under "Comments and Responses on Compliance Testing" the following: Several commenters suggested that all HIPAA standards projects be posted and that the government should provide funding or at least publicly advertise the results of all compliance testing projects. It was suggested that the Electronic Healthcare Network Accreditation Commission (EHNAC) could host a bulletin board or web site in which tests results could be published. Several commenters asked whether entities providing validation testing will need to be certified. They stated that validation testing is only useful if certification is obtained. Several commenters recommended that the Secretary endorse the Standard Transaction Format Compliance System (STFCS) process established by EHNAC for validation testing, suggesting that EHNAC certification lends credibility and reliability to the process. However, other commenters wanted certification for compliance to be voluntary. Several commenters recommended that WEDI, X12, or some other group further develop the various types of testing situations which might occur as well as tentative protocols for handling such tests. [ more text omitted for brevity.] Response: We agree that posting of results for any HIPAA standard should be voluntary. As long as the transactions are successfully implemented in production, posting of the results is more of a marketing, advertising, and sales issue than a technical concern. Since the HIPAA provisions do not require the Secretary to certify compliance with HIPAA standards, the Secretary is not conducting certification reviews or recognizing private organizations that have decided to conduct such reviews. Therefore, any certification of commercial entities performing validation testing will remain in the private domain and be voluntary. While receivers of transactions are likely to test whether a vendor that claims to be HIPAA compliant is, in fact, producing compliant transactions, this is a matter of business practice, and such tests are not being mandated in this rule. Following the spirit of this regulatory text, and the recommendations of commenters to the NPRM, when SNIP was formed, one of the workgroups took the task of writing a white paper on testing and certification. This white paper was led by Dave Moertel (Mayo Foundation) and Mark McLauglin (McKesson/HBOC) and the very first draft of this paper already had the first 5 "levels" of testing. In the Fall of 2000, the sixth level was added. This was my first contribution to the white paper, so I know it first hand. At the time I was still working for Envoy. In my past 18 years working with (leading, rather) clearinghouses, I had run into numerous testing problems that were specific to different specialties and unique to different lines of business, so testing for these unique conditions was a requirement of any test environment. At Synaptek (pre-Envoy) we had developed a testing process that allowed us to test, very effectively, the EDI files from tens of thousands of providers and payers that came to our clearinghouse. It seems that if we ignore the history, we end up repeating the same things over and over. So, I hope this historical summary helps us to not waste much time reinventing these wheels. Kepa Zubeldia Claredi On Saturday 21 December 2002 09:27 am, Rachel Foerster wrote: > I'm getting real tired and annoyed of the comments that suggest the concept > of certification is an attempt by some to steal market share, emanate from > some hidden agenda, etc. It simply is just NOT true. The origin of the > concept of certification was written into the white paper in mid-2000 and is > a concept that came out of AFEHCT, WEDI, and EHNAC in 1997 or earlier, long > before the current vendors were involved in HIPAA transaction testing. It > came out of a search for a solution to the mass deployment of testing > problem that was, and is, looming in the HIPAA future." > > Now...can we please move off this non-productive discussion and get on to > developing a consensus statement/definition of the concept of certification > that will be useful to the industry during this extremely challenging stage > of actually implementing the HIPAA EDI transaction sets? > > Rachel Foerster --- 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-testing as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org --- 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-testing as: [email protected] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
