Of course, another and improved document can replace the 997. Go for it.
Improvements can definitely be made to
current practices.
>> one that can easily be changed
As far as being cast in concrete, those of us who actually work in EDI operations know
that it might as well be. The
chain of events required to eliminate the 997 will take years. I just spent several
years doing Y2K upgrades. It
surprised me how many major organizations were still using V2000 & V2003 prior to Y2K
conversion. I believe they date
to late 80's-early 90's. One was Wal-Mart. That meant, of course, that their 57,000
suppliers also had to support
V2003.
I worked for two EDI software providers including Sterling and I can tell you from
experience that getting the changes
required to support the use of both the 824 and the 997 as functional acknowledgements
is a major re-work and will
only be done when large customers demand it. Simply specing a modified 824 will not
cause that to happen. If,
however, HIPAA requirements demanded it, we could expect support very quickly.
>>There's nothing in the EDI standards or any state or federal regulation that
> requires the use of the 997
Yes, 997's are mandated in at least some state regulations. They are required in all
states for the Retail Choice
deregulation for the utility industry.
----- Original Message -----
From: "Rachel Foerster" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 22, 2001 9:38 PM
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/
>
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
