Title: RE: Testing for levels 3, 4, and 6


Everyone,

Recent emails to this thread seem to be in violation of the "Posting of advertisements or other commercial use of this listserv is specifically prohibited."  While the emails are creative, they nonetheless boil down to advertisements.  We all represent our own companies and would like the free publicity but must refrain from wearing our company hats in all areas of our participation in SNIP in order to promote fairness and cooperation throughout the industry.

Please adhere to the rules for the listserv or we all will suffer.

Your cooperation is appreciated!

Lin Quinkert
Transactions Co-chair

-----Original Message-----
From: David Frenkel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 23, 2002 12:00 AM
To: [EMAIL PROTECTED]
Subject: RE: Testing for levels 3, 4, and 6



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.


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.

Reply via email to