Dear Group: (I apologize for the length.. but I think this is one of our most important issues at the moment)
If I understood Mark Lott's basic premise, it seemed to be oriented toward *providers* testing their claim generation systems. Since there is no standard format for the data before it becomes a "claim", I would think that each PMS vendor will have to create a test bed of typical encounter data, recognizable to his system.... perhaps by de-identifying several thousand sets of real encounter data from a client's working system. Even so, the PMS vendor must still somehow determine if he is creating defective transaction sets out of this data... i.e. he must apply the 7 types of scrutiny being proposed by WEDI testing group. This leads to a core issue that continues to pop up and was a theme of a mini (un-official) "white paper" circulated recently on the testing listserve. Ultimately, CEs want to compare their test transactions directly to the *IG*. But since the logic of the IG is only represented in human-readable form, we are forced to build validation engines that (to the best of each builder's knowledge) faithfully represent the logic of the IG. Lots of people are building these engines... some offered as independent testing services and others simply as a component of the local "translator" application. THE PROBLEM THAT WON'T GO AWAY, however, is that none of these transaction-validation engines can be ABSOLUTELY determined or "certified" to be working correctly.... for several reasons, including: 1. You cannot reliably map human *understanding* of a complex, narrative description of a methodology into a hard computer application. By its very nature, such mappings are ALWAYS going to be a little fuzzy, and will become clearer and more accurate with each revision... much like mapping a collection of human-understandable business requirements into a business application . 2. Inconsistencies and ambiguities certainly do exist within and among the present IGs. In fact, TG3 has a committee combing through the IGs, documenting these as we speak. 3. The situational elements that are dependent on simply whether or not a payor wants the data, will require thousands of "companion guides" that would be impractical to try to program into standard/independent testing engines. These will still require testing by each trading pair. All of this seems to cry out for machine-readable IG formats. Until those exist, however, it would seem to be "every man for himself" with regard to "testing"... with the "buck stopping" ultimately at the level of each individual set of trading partners. Several folks have "done the math" on testing each trading pair and determined (correctly) that there aren't enough testing-hours available to do that... assuming that at least some of our resources have be reserved for delivering health care! Even if we DO agree on ONE common validation engine... perhaps based on some open-source logic-model that neutralized all the "anti-competitive" issues... it could still have a logic flaw that was not discovered until thousands of CEs had already been "certified" with it. Given the complexity of the logic and the almost infinite variety of data conditions, I would imagine that flaws are more or less guaranteed. I can't visualize a short-term (i.e., before H-day) solution for this, but one thing has become very clear to me: Standards CONCEPTS for a machine-based information system MUST be accompanied by a STANDARD, MACHINE-READABLE methodology for REPRESENTING those concepts. As long as the primary representation of the standard remains in an exclusively human-readable form (e.g., a .pdf document), then the standards concepts will necessarily have to be filtered through a SECOND committee of human brains, before they are incorporated into EACH business application. This second pass through a brain-committee (the SDO, being the initial pass) introduces unnecessary interpretive error and should be eliminated. Wherever possible, the SDO committee should deliver the initial standard/IG in a machine readable form that has been examined for internal consistency and checked for conflict with other standards. Besides being horribly expensive to understand and implement, our present paper-based IGs will be a NIGHTMARE to maintain and keep harmonized with other IGs. Maintenance and IG-harmonization could be vastly streamlined with machine-readable IGs. I think this needs to have a very high priority assigned to it. In fact, a methodology capable of eliminating this much basic implementation and maintenance expense across an entire industry, deserves a professional (i.e., paid) development team and serious funding. Folks, we have the domain experts... we have the IT experts... we have the excellent (albeit, human readable) IGs that have been carefully hammered out in over a decade of discussion... we at least have the money that we are poised to spend on implementing and maintaining this the "hard way". All we need is the will to spend that money today on a fast-track implementation of the BETTER WAY to represent standards. I don't see how we can lose with such an investment... unless the task of making IGs machine readable is a lot harder than I think it is. But when you think about it, we are ultimately doing that anyway... although in a non-standard way, one user-application at a time. Essentially, each translator vendor is making his/her best guess at a "machine readable representation of the IG". I realize that, to some extent, this suggestion pushes the "standards committee" toward something that looks more like a "software development house", but I think this is an unavoidable course for standards development/maintenance... if we expect standards to keep up with the state of the art in business applications, or (perhaps more importantly) if we do not want standards to become a burden that slows down the development of innovative business applications. The present volunteer-driven SDO model will continue to be the optimal "incubator" environment for standards. To sustain what I'm suggesting here, however, we will need to add a non-profit, revenue-based wing, in which licenses fees from sophisticated, machine-readable standards fuel a more organized and efficient SDO model. This entity can also handle registries and many other industry-wide components. (What was that? Did somebody say, "Get a rope!"?) Best regards, Chris At 04:24 PM 7/13/2002 +0530, Ganesh Bhat wrote: >David, > >The real "trick" is to create finite test cases out of almost infinite >test cases possible. >It would rather be too simplistic to assume that a single generic test bed >of data will be good enough for every system.I guess a set of generic test >beds of data will evolve. This is far better than purpose-less random test >files. > >Regards, > >Ganesh Bhat >Transaction Group >Advent Software Ltd. > >-----Original Message----- >From: David Frenkel >[<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] >Sent: Friday, July 12, 2002 03:53 AM >To: [EMAIL PROTECTED] >Subject: RE: Testing for levels 3, 4, and 6 > >Mark, >Test data has been a difficult subject and even more difficult to >create. With all the different adjudications systems it is difficult to >create a solution that works for everybody. Are you suggesting a >generic test bed of data that should work for everybody? > >Regards, > >David Frenkel >Business Development >GEFEG USA >Global Leader in Ecommerce Tools >www.gefeg.com >425-260-5030 > >-----Original Message----- >From: Mark A Lott >[<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] >Sent: Thursday, July 11, 2002 1:56 PM >To: [EMAIL PROTECTED] >Subject: RE: Testing for levels 3, 4, and 6 > >David, > >Thank you, I was on the testing calls and have reviewed the white paper. >It >does not address test data or test files in regards to quality assurance >based methodologies and practices. It is this topic that my note was >referring to.... > >Regards, > >Mark A Lott >President >HIPAA Testing, Inc. > >www.hipaatesting.com > >Office: 480-946-7200 >Cell: 480-580-4415 >Fax: 877-825-8309 > > "Advanced Testing and Certification of HIPAA Transaction Compliance" > >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: David Frenkel >[<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] >Sent: Thursday, July 11, 2002 12:42 PM >To: [EMAIL PROTECTED] >Subject: RE: Testing for levels 3, 4, and 6 > >Mark, >There will be 'final draft' of the updated Wedi testing white paper >coming out tomorrow. You might take a look at it. > >Regards, > >David Frenkel >Business Development >GEFEG USA >Global Leader in Ecommerce Tools >www.gefeg.com >425-260-5030 > >-----Original Message----- >From: Mark A Lott >[<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]] >Sent: Thursday, July 11, 2002 12:24 PM >To: [EMAIL PROTECTED] >Subject: RE: Testing for levels 3, 4, and 6 > >Greetings, > >Thoughts for the group..... > >I wanted to respond in more detail regarding what is among the largest >issues facing the industry in relation to testing initiatives, namely >1)covered entities trying to decompose IG's to configure test conditions >and >2)creating valid test data in EDI, instead of analyzing the problem from >a >true business perspective. > >The paradigm: Giving organizations the ability to continue testing >applications with test data they are knowledgeable and proficient using >(i.e. - UB92, NSF,ERA, HCFA, etc.) as opposed to trying to create EDI >files >from scratch, and not fully comprehending the correlation between >proprietary >data and EDI data. > >The scenario: A business stakeholder is asked for sign-off for HIPAA >transaction compliance of their application system. The test files and >test >conditions were created in a language (EDI) and a process they are >unfamiliar with and are unsure of what functionality was tested or not >tested. How can they give sign-off? Certainly not just by examining >reports >stating that files passed an EDI compliance tool or trust that their >translator must be working properly. How would they sign-off on any >other >system remediation project outside of HIPAA? > >A case study: Business Analysts and Test Analysts would have an >easier and more intelligent test approach if they could create test >conditions in proprietary formats and as a benefit they would also know >the >applicable test condition and expected result of such a test case. >Thinking >in terms of creating and running data according to "testing levels" is >causing the need for additional staff, learning unfamiliar tools, >working >long hours, test case rework and unclear test conditions. This is >creating >an undue burden placed upon the business stakeholders and test teams to >create in "unfamiliar" terms, the massive amounts of test data to >validate >that translators, >applications systems and trading partners are in compliance. If you look >at >most any organization currently in the testing phase, you will find a >team >struggling to determine all the appropriate EDI test conditions and >subsequent >test data to prove systems are functioning properly and in compliance. > >We believe it is time for a new testing paradigm, especially as it >relates >to proper test data. >One that will help covered entities to achieve true quality assurance >and >meet compliance >regulations much faster than current methods and one that takes into >consideration >well-established quality assurance methodologies and techniques to >determine >test cases, test data and EDI compliance validation criteria. We are in >process of building a >consortium of quality assurance firms, consulting organizations and >covered >entities that truly understand the benefit with this new approach. This >is >an open >invitation for quality assurance professionals and business stakeholders >that would >like to assist us in this new education initiative, EDI validation >through >rose-colored >QA glasses... > >Mark A Lott >President >HIPAA Testing, Inc. > >www.hipaatesting.com > >Office: 480-946-7200 >Cell: 480-580-4415 >Fax: 877-825-8309 > > "Advanced Testing, Test Data and Certification of HIPAA Transaction >Compliance" > >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 > > > >********************************************************************** >To be removed from this list, send a message to: >[EMAIL PROTECTED] >Please note that it may take up to 72 hours to process your request. > >====================================================== >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/>http://snip.wedi.org/tracking/. >Posting of advertisements or other commercial use of this listserv is >specifically prohibited. > > > >********************************************************************** >To be removed from this list, send a message to: >[EMAIL PROTECTED] >Please note that it may take up to 72 hours to process your request. > >====================================================== >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/>http://snip.wedi.org/tracking/. >Posting of advertisements or other commercial use of this listserv is >specifically prohibited. > > > >********************************************************************** >To be removed from this list, send a message to: >[EMAIL PROTECTED] >Please note that it may take up to 72 hours to process your request. > >====================================================== >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/>http://snip.wedi.org/tracking/. >Posting of advertisements or other commercial use of this listserv is >specifically prohibited. > > >********************************************************************** >To be removed from this list, send a message to: [EMAIL PROTECTED] >Please note that it may take up to 72 hours to process your request. > >====================================================== >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/>http://snip.wedi.org/tracking/. > >Posting of advertisements or other commercial use of this listserv is >specifically prohibited. > > >********************************************************************** >To be removed from this list, send a message to: [EMAIL PROTECTED] >Please note that it may take up to 72 hours to process your request. > > >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. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268 ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request. ====================================================== 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.
