Sunny, There is an old saying, 'Never say Never'. I think this applies to your comments. Implementing the HIPAA transactions will be an arguably painful evolution and we are still somewhat in the infancy which tends to be the most work. The healthcare industry has a mandate to move forward and GEFEG is working to help with its productivity tool, EDIFIX. We have been involved in a number of success stories in other industries and we look forward to being part of the healthcare/HIPAA success.
HIPAA is about more than ROI. In a nutshell it is about quality, accountability and moving forward with technology to help reduce soaring health care costs. Our tool is a leader in the ability to build semantic rules and we will support any industry standard for exporting implementation guides although we promote the use of W3C XSD Schemas. Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030 (P.S. Could we all try to follow the Zon rulebook and not cross post emails? Thanks.) -----Original Message----- From: Sunny Singh [mailto:[EMAIL PROTECTED]] Sent: Sunday, July 21, 2002 12:07 AM To: 'Falbowski, Ellen'; [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: RE: Testing for levels 3, 4, and 6 1. Machine Readable Guidelines: Providing IGs in machine readable formats is imperative for efficient implementation of trading relationships. I will explain how we at Edifecs have done so and that can be extended to other scenarios/ implementations of machine readable guidelines. Edifecs provides all HIPAA guidelines and any companion guidelines created in SpecBuilder in machine readable format called gXML (Guideline XML) and in XML Schema. Various mappers in the market have incorporated the ability to read gXML machine readable guidelines and thus prevent the duplicate entry in re-entering the guideline into the mapper (and thus create the half-maps). I think providing HIPAA guides in IMPDEF will be a positive. Eventually we see guidelines being exported to some standard XML flavor being the winner. But till we reach a point where a standard XML format is established that will be able to capture all details available in an EDI/ HIPAA guideline, users can leverage formats such as gXML or IMPDEF. 2. Semantic Rules: Semantic rules can be captured as business rules using some kind of standard scripting (and for that matter a proprietary scripting language) language. We at Edifecs have done so such that all the HIPAA business rules are available such that a validation engine can read those rules and thus check data files for compliance. I agree that semantic rules are more complex to program than the syntax rules. If there is subjectivity within semantic rules than the issue lies with cleaning up those semantic rules (lets tackle the root cause of the problem) and not with being able to identify ways to decipher those rules. 3. Interpretation & Certification: If you have rules within IGs that are non-programmable then I feel that such guidelines will never be adopted and implemented on a large scale as the total effort required to establish the business relationships around them cannot provide an quantifiable ROI in a fixed time frame. The problem does not stop with the first implementation but the fact that any guideline (base standard or customized) has to undergo constant implementations as business keep on evolving their operational processes. We feel that HCOs (Health care organization) will take the HIPAA guidelines and specialize them to clarify their interpretations and implementations over time (and off course black & white clarifications from X12 and standard organizations will assist in that process). Because of this and many other reasons Edifecs believes that industry-wide certification is not feasible, not implementable, not trackable in a n! (n combinatorial) relationship trading communities/ marketplaces and is a short-sighted approach where gains are short-terms without providing a long-term solution. Certification when applied and dictated by an organization or a trading community is a doable concept and has worked in the EDI world for dozens of years. 4. Table Data: We need to define the data content and business rules as black & white rather than providing shades of grey subject to interpretations. Once that happens companies providing validation & translations systems will do the needful to make their systems populate and support the rules properly. Thanks, sunny Edifecs Inc. www.edifecs.com -----Original Message----- From: Falbowski, Ellen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 1:07 PM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; Sunny Singh Subject: RE: Testing for levels 3, 4, and 6 Here is the most important point I've taken from Sunny Singh's and Chris Feahr's notes: it is much more difficult to test for semantic compliance with an implementation guide than it is to test for syntactic compliance, because the semantic notes are in text and the syntax rules are programmable. For example, a semantic note in the X098, page 248, reads "Required on all claims involving ambulance services." A syntax rule on the same page reads, "P0102 - If either CR101 or CR102 is present, then the other is required." The text note does not provide enough information to program; the "P0102" is unambiguous and programmable. Perhaps what we need to do in X12 is move our semantic "rules" in our standards and guides out of text and into unambiguous, programmable rules. These rules can then be loaded from the table data on wpc-edi into the translators, mappers, validators, and other tools that we all use, ensuring that we all share the same interpretation of these rules. Yes, some semantic rules will be harder to program than others, and perhaps some rules will never be programmable. (My semantic example above would require creating a rule that says a segment -- in this case, the CR1 Ambulance Transport Information segment -- must be present if any instance of a certain data element -- in this case, the SV101-2 Procedure Code -- contains a code value from a subset -- in this case, a list of ambulance services -- of an external code list -- in this case, HCPCS and/or CPT codes.) But that should not stop us from programming the ones we can. It may take slightly longer to do this in the standard or IG development process, but it should save us enormous amounts of time on the testing side, and eliminate a lot of ambiguity that currently plagues the production side. This e-mail, including attachments, is intended for the exclusive use of the person or entity to which it is addressed and may contain confidential or privileged information. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you think that you have received this e-mail in error, please advise the sender by reply e-mail of the error and then delete this e-mail immediately. Thank you. Aetna Inc. ********************************************************************** 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. Please note that it may take up to 72 hours to process your request. <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.
