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/

Reply via email to