-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 18, 2001 5:56 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Dual 997's
Mark,
While your explanation below is fine and can be generalized to most
industries, it really doesn't address Jonathan Showalter's question
regarding one vs two 997s and the circumstance surrounding the question.
The issue for the health care industry vis a vis compliance with HIPAA
transaction sets and codes is that in order to be "in compliance" the
"covered entity" must use the standard data as defined by the HIPAA IG as
well as the standard transaction format. The HIPAA regs stipulate that a
health plan/payer cannot reject an health care claim transaction, the 837
for example, if it complies with the standard.
The issue is that one can reject the asserted HIPAA transaction if it DOES
NOT COMPLY with the standard data AND the standard transaction format. This
has nothing to do with actually taking the claim data from the EDI system
and passing it to the claim adjudication system for further processing,
where the claim can be rejected, payment denied, pended, etc. for a variety
of reasons, none of which have anything to do with the HIPAA mandated
standard data and/or transaction format.
The real question is that the value of a 997 in the case of HIPAA standard
transactions which reports ONLY against the full X12 standard is
insuffficient. Rather, the question and the need is for a 997 to report
compliance not only against the X12 standard but ALSO the appropriate HIPAA
IG.
My personal opinion is that the 997 that will be of most value would be one
reporting against the HIPAA IG and not just against the standard.
I was under the impression that X12C and ultimately the X12 membership had
approved modifications to the 997 to allow and support reporting against
IGs - at the request of the U.S. gov. But, Jonathan Allen's comments lead me
to believe that this failed.
If in fact the 997 has been modified and approved to report against an IG
then in my mind there is another issue for the HIPAA impacted entities: The
HIPAA transaction sets are based on V4010. If the 997 was modified and
approved as requested, then that version would be a more current version,
such as V4030 or V4040, but certainly V4010 997 would not have the needed
functionality. The question then is can one process a transaction again
V4010 but return a 997 using a newer Version? I think this is highly suspect
and problematic.
Rachel Foerster
----------------------------------------------------------------------------
---
Jonathan,
There are two implementations of the 997 that I have
seen in practice. These
are based on where the 997 actually gets created in
the process of receiving the
data, translating it and loading it to a back end
application. The timing will
reflect the completeness of the information being
provided. Standard 997 provides
for validity checking all the way down to the element
level. This is pretty detailed,
but not well supported in translation packages. It
requires going into the source data
received to really determine the cause of the problem
if an error or reject is received.
Reporting of each of these possible outcomes is
supported in most commercial translators
on the market.
In one instance, the 997 gets created immediately
after the translation process has
occurred that reflects the transaction was received
and translated on the receiver's
system. This is the most common method used because
the translation program usually
produces this automatically for you. It's the easier
way out.
The problem with this is that the viability of the
data in the receiver's application
is unknown at this point and the receipt of the 997
has not guaranteed that the data
will be able to be loaded and used by the receiver.
It can be assumed that the data
load was tested during implementation, but this may
not incorporate all the possible flavors
that one may see of a transaction as production data
is received and processed.
In the second instance, the translator's automatic
feature to produce the 997 is disabled
and the load process provides for the generation of
997 data which is passed back to the
translator much like any other transaction. The
issues with this are self explanatory.
While this is the "more work" method of approaching
this, it is the more inclusive and
safer way to go. It guarantees that the data actually
loaded to the receiver's application
with no errors.
There are issues such as the transaction that fails
during translation will not be
acknowledged. This requires that the trading partner
monitor 997's for their outbound
transactions to ensure that all send are acknowledged.
It is incumbent on you to ensure where your trading
partner is actually sourcing the 997.
Where they source the information will provide insight
as to how complete the information
is that your getting as well as the integrity of the
data sent.
The common fallacy here is that I got the 997,
therefore, there is no problem with the data.
Dependent on where the 997 is created, this could be a
false statement. I do not agree with
producing two 997's, one at each point. It almost
sounds as if your trading partner has
not disabled the automatic feature in the translator
and also written logic into the application
in-load backend process to produce it after the data
is loaded. You really might want to
ask a question here.
Under either of these approaches, the 997 must be
syntactically correct in order to be processed
on your system. A 997 that crashes in translation is
as pesky as any other transaction.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 9:33 AM
To: [EMAIL PROTECTED]
Subject: Dual 997's
A topic came up in the course of conversation about
whether 997's should
reflect the Standard or the Imp Guide (IG)... to
narrow it down a bit this
would be for transactions that fall under HIPAA. This
means that the US Govt
has built the IG's for a set of transactions and all
parties using these
transactions will all use the same IG.
Now the questions... should the 997 reflect the
Standard or the IG. I believe
that creating a 997 from the standard is not very
useful when it comes to
syntax checking... there could be a valid
qualifier/element/segment but
because it's not in the IG I can't use it and will
error out the transaction
because I can't map the data. For example, if there
were 5 relationship codes
in the IG but the transaction being sent contains 6
(the 6th one valid
according to the standard) but one not in the IG and
therefore doesn't map.
Second question. Has anyone ever seen two 997's being
sent. The first one to
reflect the standard and the second to reflect the IG.
I think this is a bad
idea because if the first one says all syntax is
correct and then the second
one says there is a syntax error base on the IG....
the first one is of very
little or no value.
I have never seen this put in place but because I
could have lived a sheltered
life up to this point I thought I would ask the world
of experts on EDI-L
Thanks!
Jonathan Showalter
Omaha NE USA
[EMAIL PROTECTED]
=======================================================================To
contact the list owner:
mailto:[EMAIL PROTECTED]
Archives at
http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
--3796298-13368-990124251=:1704
Content-Type: TEXT/html; CHARSET=US-ASCII
Content-ID: 0
Content-Language: en-USA
<html><head></head><body>
<font size=2 >Jonathan,</font><div>
<font size=2 ></font><div>
<font size=2 >There
are two implementations of the 997 that I have seen in practice. These
</font><div>
<font size=2 >are
based on where the 997 actually gets created in the process of receiving the
</font><div>
<font size=2 >data,
translating it and loading it to a back end application. The timing will
</font><div>
<font size=2 >reflect
the completeness of the information being provided. Standard 997 provides
</font><div>
<font size=2 >for
validity checking all the way down to the element level. This is pretty
detailed, </font><div>
<font size=2 >but
not well supported in translation packages. It requires going into the
source
data </font><div>
<font size=2 >received
to really determine the cause of the problem if an error or reject is
received.
</font><div>
<font size=2 >Reporting
of each of these possible outcomes is supported in most commercial
translators
</font><div>
<font size=2 >on
the market.</font><div>
<font size=2 ></font><div>
<font size=2 >In
one instance, the 997 gets created immediately after the translation process
has </font><div>
<font size=2 >occurred
that reflects the transaction was received and translated on the receiver's
</font><div>
<font size=2 >system.
This is the most common method used because the translation program usually
</font><div>
<font size=2 >produces
this automatically for you. It's the easier way out.</font><div>
<font size=2 ></font><div>
<font size=2 >The
problem with this is that the viability of the data in the receiver's
application </font><div>
<font size=2 >is
unknown at this point and the receipt of the 997 has not guaranteed that the
data </font><div>
<font size=2 >will
be able to be loaded and used by the receiver. It can be assumed that the
data
</font><div>
<font size=2 >load
was tested during implementation, but this may not incorporate all the
possible
flavors</font><div>
<font size=2 >that
one may see of a transaction as production data is received and
processed.</font><div>
<font size=2 ></font><div>
<font size=2 >In
the second instance, the translator's automatic feature to produce the 997
is
disabled </font><div>
<font size=2 >and
the load process provides for the generation of 997 data which is passed
back
to the </font><div>
<font size=2 >translator
much like any other transaction. The issues with this are self
explanatory.</font><div>
<font size=2 >While
this is the "more work" method of approaching this, it is the more inclusive
and </font><div>
<font size=2 >safer
way to go. It guarantees that the data actually loaded to the receiver's
application</font><div>
<font size=2 >with
no errors.</font><div>
<font size=2 ></font><div>
<font size=2 >There
are issues such as the transaction that fails during translation will not be
</font><div>
<font size=2 >acknowledged.
This requires that the trading partner monitor 997's for their outbound
</font><div>
<font size=2 >transactions
to ensure that all send are acknowledged. </font><div>
<font size=2 ></font><div>
<font size=2 >It
is incumbent on you to ensure where your trading partner is actually
sourcing
the 997.</font><div>
<font size=2 >Where
they source the information will provide insight as to how complete the
information </font><div>
<font size=2 >is
that your getting as well as the integrity of the data sent.</font><div>
<font size=2 ></font><div>
<font size=2 >The
common fallacy here is that I got the 997, therefore, there is no problem
with
the data.</font><div>
<font size=2 >Dependent
on where the 997 is created, this could be a false statement. I do not
agree
with </font><div>
<font size=2 >producing
two 997's, one at each point. It almost sounds as if your trading partner
has
</font><div>
<font size=2 >not
disabled the automatic feature in the translator and also written logic into
the application </font><div>
<font size=2 >in-load
backend process to produce it after the data is loaded. You really might
want
to </font><div>
<font size=2 >ask
a question here. </font><div>
<font size=2 ></font><div>
<font size=2 >Under
either of these approaches, the 997 must be syntactically correct in order
to
be processed </font><div>
<font size=2 >on
your system. A 997 that crashes in translation is as pesky as any other
transaction.</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >-----Original
Message-----</font><div>
<font size=2 >From:
[EMAIL PROTECTED]</font><div>
<font size=2 >[mailto:[EMAIL PROTECTED]]</font><div>
<font size=2 >Sent:
Thursday, May 17, 2001 9:33 AM</font><div>
<font size=2 >To:
[EMAIL PROTECTED]</font><div>
<font size=2 >Subject:
Dual 997's</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >A
topic came up in the course of conversation about whether 997's
should</font><div>
<font size=2 >reflect
the Standard or the Imp Guide (IG)... to narrow it down a bit
this</font><div>
<font size=2 >would
be for transactions that fall under HIPAA. This means that the US
Govt</font><div>
<font size=2 >has
built the IG's for a set of transactions and all parties using
these</font><div>
<font size=2 >transactions
will all use the same IG.</font><div>
<font size=2 ></font><div>
<font size=2 >Now
the questions... should the 997 reflect the Standard or the IG. I
believe</font><div>
<font size=2 >that
creating a 997 from the standard is not very useful when it comes
to</font><div>
<font size=2 >syntax
checking... there could be a valid qualifier/element/segment but</font><div>
<font size=2 >because
it's not in the IG I can't use it and will error out the
transaction</font><div>
<font size=2 >because
I can't map the data. For example, if there were 5 relationship
codes</font><div>
<font size=2 >in
the IG but the transaction being sent contains 6 (the 6th one
valid</font><div>
<font size=2 >according
to the standard) but one not in the IG and therefore doesn't
map.</font><div>
<font size=2 ></font><div>
<font size=2 >Second
question. Has anyone ever seen two 997's being sent. The first one
to</font><div>
<font size=2 >reflect
the standard and the second to reflect the IG. I think this is a
bad</font><div>
<font size=2 >idea
because if the first one says all syntax is correct and then the
second</font><div>
<font size=2 >one
says there is a syntax error base on the IG.... the first one is of
very</font><div>
<font size=2 >little
or no value.</font><div>
<font size=2 ></font><div>
<font size=2 >I
have never seen this put in place but because I could have lived a
sheltered</font><div>
<font size=2 >life
up to this point I thought I would ask the world of experts on
EDI-L</font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 ></font><div>
<font size=2 >Thanks!</font><div>
<font size=2 ></font><div>
<font size=2 >Jonathan
Showalter</font><div>
<font size=2 >Omaha
NE USA</font><div>
<font size=2 >[EMAIL PROTECTED]</font><div>
<font size=2 ></font><div>
<font size=2
>=======================================================================</fo
nt><div>
<font size=2 >To
contact the list owner: mailto:[EMAIL PROTECTED]</font><div>
<font size=2 >Archives
at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/</font><div>
<font ></font></body></html>
--3796298-13368-990124251=:1704--
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
