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
