Jonathan,
At this point I can now envision (!!!!) the 824 being re-designed as an HL
transaction with various context levels for reporting for a different
context, e.g., HL1 could be just syntax reporting against the base standard,
HL2 could be reporting against an industry IG, HL3 could be reporting
against a company-specific IG, and then finally, HL4 reporting against
pre-application edits.
Wouldn't this be fun! Wouldn't it also be great fun developing the IG for
the new 824....give us all something to do to keep us off the streets at
night!
It would give X12C and TAS something to do besides fretting about XML!!!
I also stand corrected...using the new 824 does make the current 997
redundant and not useful....why not submit a DM to deimplement the 997 in
favor of the 824???!!!!
Rachel
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/
