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/
- Dual 997's JONATHAN . SHOWALTER
- Re: Dual 997's Jim Divoky
- Re: Dual 997's Jonathan Allen
- Re: Dual 997's Michael Mattias
- Re: Dual 997's Glenn Smith
- Re: Dual 997's Jim Divoky
- Re: Dual 997's Weideman, Drake
- Re: Dual 997's Mark Kusiak
- Re: Dual 997's Glenn Smith
- Re: Dual 997's Jim Divoky
- FW: Dual 997's Rachel Foerster
- Re: FW: Dual 997's Jonathan Allen
- Re: FW: Dual 997's Jim Divoky
- Re: FW: Dual 997's Jonathan Allen
- Re: FW: Dual 997's Jim Divoky
- Re: Dual 997's Jonathan Allen
- Re: Dual 997's Jim Divoky
- Re: Dual 997's Jonathan Allen