Glenn,
I agree it would be a better world if your TP never sent data that you
cannot interpret. Unfortunately, in the real world you will always receive
data you did not expect. The traditional way and, not necessarily the best,
way of handling unexpected data is as follows:
Error Type Action
Result
Syntactical Validation against standard by translator
Functional Acknowledgement(997)
Semantic Validation by application map
Ignore, modify, or Human intervention
Business Rule Validation by business application Human
Intervention or Error Message(824)
You also need to determine where the logical point to validate data is. The
reason for the above hierarchy is that, first, the 997 was designed to be a
syntax checker only. It is not meant to report semantic or business rule
errors. It's not that you can't do what you suggest, it's just that that is
not what the 997 was designed for and as a result many EDI translators do
not support what you are asking for. No translator I'm aware of has any way
of documenting the standards tables changes you may make. Secondly,
maintaining IGs within the EDI standards tables provided with your
translator is a long-term maintenance nightmare. It seems like a good idea
at first but changes in the IGs as well as product upgrades will quickly
dissuade you from that idea. Thirdly, EDI translators are not programming
tools and have none of associated tools for creating, sharing, maintaining,
and documenting code. Therefore, my recommendation based on a lot of
experience is that you choose the right tool for the job. Keep the EDI
translator's job as simple as possible and you will not go prematurely gray.
The 997 is a Functional Acknowledgement not an Application Acknowledgement.
It was designed to acknowledge receipt and syntactical status. Nothing
more.
What you suggest is a fine idea. The issue is that the volatility of IGs
rule against it and neither the 997 nor EDI translators are designed to
support it.
Regards, Jim Divoky
----- Original Message -----
From: "Glenn Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 2:15 PM
Subject: Re: Re: Dual 997's
Jim:
why just have a client/vendor send you data that you can not use? The
standards are great to start but everyone add to them for their own business
needs. Therefore you must ack the data for your use and not the standard.
Glenn K. Smith
[EMAIL PROTECTED]
Senior EDI Systems Analyst
Re:SOURCES EDI Department
248-458-8175
>>> "Jim Divoky" <[EMAIL PROTECTED]> 5/17/01 2:00:52 PM >>>
In twelve years in several industries at perhaps 50 clients, I have never
seen a 997 that was based on an IG. The 997 capability ships with
commercial EDI translators and, while they may offer the capability of
making the 997 conform to an IG, I have never seen it done.
The sending and receiving of 997s is standard policy in the utility, retail,
consumer electronics, automotive, and computer manufacturing industries with
which I am familiar. Now, what the practice is in the healthcare industry I
cannot say.
Since 997s are supported by commercial EDI translators there is little
effort required in sending, receiving, and reconciling 997s. Well, maybe a
little. It is commonly part of the Trading Partner Agreements.
Jim Divoky, EC Solutions
----- Original Message -----
From: "Glenn Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 1:00 PM
Subject: Re: Dual 997's
In most cases the 997 is a result of the IG. The 997 should be based on the
map you use to translate the data. I have never heard of sending 997's and
would complain like hell if I had to do it or if I was asked to send or
receive.
Glenn K. Smith
[EMAIL PROTECTED]
Senior EDI Systems Analyst
Re:SOURCES EDI Department
248-458-8175
>>> <[EMAIL PROTECTED]> 5/17/01 12:33:00 PM >>>
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/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
