I am resending this note from yesterday afternoon. I apologize to those of you who have received multiple copies. I received a few "Out of Office" replies so I know the original note got to a few folks, but I don't believe it was sent to the entire distribution list. (For example, I didn't get a copy.)
-----Original Message----- From: Falbowski, Ellen Sent: Tuesday, July 16, 2002 4:07 PM To: [EMAIL PROTECTED]; '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED] 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.
