Re: FW: Dual 997's

Wed, 23 May 2001 13:46:59 -0700

Rachel and Jim,
The 997 will continue to be used as long as there are translators out there that
are immediately turning it around in the translation process and blasting it
back the other way. Until the mapping definitions are merged with the IG process,
(usually two separate processes today) then 997 will be the rule....
Setting the 997 is usually no more then configuring the desire into the trading partner
setup on the translator. On ours, it's a simple Y/N switch in each transaction map link
within the partner profile in our translator. The setting of the switch is a preverbal
no brainer where the 824 requires a little more work and for-thought.
Just a humble opinion
Mark
-----Original Message-----
From: Rachel Foerster [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 22, 2001 6:38 PM
To: [EMAIL PROTECTED]
Subject: Re: FW: Dual 997's
Jim,
The role filled by the 997 today can easily be filled by the use of the new
824. There is nothing magic about the 997 from a non-repudiation or legal
perspective. It's all about what the two trading partners agree to use for
these functions. As long as the 824 serves a dual role, why not use it for
the greater functionality and higher level of business information being
provided? The 997 is not magic nor is its use cast in EDI concrete. There's
nothing in the EDI standards or any state or federal regulation that
requires the use of the 997...it's only become a common business practice
and one that can easily be changed in order to adopt the use of the 824 for
its greater business value.
Rachel
>> the 997 becomes almost meaningless , and is just like the
> Block-ACK in an X-Modem data transfer.
I do not see the 997 this way and neither do the EDI Coordinators on this
list who spend too much time on Functional Acknowledgment Reconciliation.
The 997 is commonly part of the legal contract between the trading partners.
It impinges on non-repudiation & authentication of the business contract.
It serves as a tracking and batch reconciliation document for IT operations.
824s when used often report only error conditions, i.e., no news is good
news or exception reporting.(See CUBR or UIG.)
Of course, if two partners or an industry chooses not use the 997 that is
their prerogative. Nothing forces them to do so. I know a number of sites
that while they send and receive 997s totally ignore them. There is nothing
that says you can't implement your dual 824 solution today although all
involved might have to write new programs to handle exception handling and
reconciliation.
Good luck on your standards settings endeavors.
Jim Divoky
----- Original Message -----
From: "Jonathan Allen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 22, 2001 5:53 AM
Subject: Re: FW: Dual 997's
> Rachel,
>
> > Since the modified 997 to allow for reporting against an IG did not
achieve
> > final X12 approval, then in the given situation, the modified 824 would
> > appear to be the only alternative.
>
> Seems like it - the 997 cannot legally do what is needed, and any attempt
> to put useful code values into the 997 (usually code values are not
> contentious) will be met with suspicion and resistance. The 824 looks
> like the only way HIPAA can do what it wants.
>
> > In this situation, I would also always return a 997 and then the
> > appropriate 824.
>
> In that scenario, the 997 becomes almost meaningless, and is just like the
> Block-ACK in an X-Modem data transfer. The 824, which can do everything
> the 997 can and more, then becomes the real syntax/data ACK incorporating
> the real level of data checking. The 997 would be generated automatically
> with almost void content by the translator (or even a front-end VAN if the
> user system didn't want to be bothered with it) as soon as it started
> processing the TS, and the 824 would then come out of the same translator
> when it had finished the translation or at any time when it needed to
abort.
>
> It raises the interesting question of whether it would then be appropriate
> to send *two* 824s for a given inbound transaction: one which did the job
> previously done by the 997, saying for example that the claimant's account
> number contained valid characters in the right order; and the second one
> to say that "sorry" although valid, the account number doesn't match
> against the database.
>
> The whole point of off-loading syntax checking and data edit checking onto
> the translator is that it is better placed to do all the detailed checking
> while in the EDI detail, and doesn't required space in the user format for
> all the possible bad data which the application doesn't want anyway - then
> the application steps in and does the real application level checking and
> work (credit limit checking, eligibility control, part stock levels,
> shipping times and so on) but only on data that is know to be
syntactically
> correct.
>
> I suppose part of the issue revolves around what is syntax checking. To
> say that checking that a field contains only digits is syntax, whereas
> checking that a field contains 3 digits, a hyphen and four digits is not
> syntax seems contradictory. Clearly, looking such a field up in a
database
> to see if it is a known account number is not syntax, although there are
> translators that do that sort of thing.
>
> Jonathan
> -------------------------------------------------------------------------- ----
> Jonathan Allen | [EMAIL PROTECTED] | Voice:
01404-823670
> Barum Computer Consultants | | Fax:
01404-823671
> -------------------------------------------------------------------------- ----
>
> ======================================================================= > 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/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/

Reply via email to