Hey! I have one for you all! Take a look at the 837 Professional IG (004010X098) - it uses a loop (2440) at the end of the transaction which IS NOT in the underlying 004010 standard! What would you do in this case? Send back a negative 997 indicating an X12 syntax error if the 2440 loop were actually used? See if you can make hay with that!!
I agree with Ajay that the 997 *could have* been made to report elegantly on IG errors, but as Rachel has informed us, the DM to change the 997 failed - though I wouldn't have used her term "resoundingly disapproved." The 997 DM was actually approved by the full X12 membership, but X12 constitutional legerdemain was used by X12F Finance to find new votes (pregnant chads) after the fact in order to kill it. Anyway, X12N Insurance was apparently interested in trying to resurrect the 997 capable of reporting on the IGs. The battles are now heating up between X12N and X12F: we actually witnessed a scene last February at the X12 meeting where X12F accused X12N of bastardy. Well, actually, to be truthful, the term liberally used was "illegitimate": "in the illegitimate 835 implementation guide...", "...the illegitimate 'DSMO' process...," and "specific Implementation Conventions (such as those illegitimately published by Insurance)." Finance wants the 997 left as it is, for X12 syntax reporting only. Further, X12F isn't even all that wild about X12N's proposed changes to fully support IG reporting in the 824! After all the mutual anathemas were cast about, the only "compromise" countenanced by the X12F patriarchs is for someone to build an entirely new transaction set modeled on the 997 for reporting on IG syntax errors: the eschatologically monikored "666" - the Mark of the Beast. Finance didn't like a 997 which could report on implementation guide errors. Banks thought for some reason they could be exposed to some kind of liability if they received a negative IC-specific 997 from the payee in response to an 820 (or 835) - the payee bank would not be prepared to handle the "tuned" 997. I didn't understand all the scenarios, which involved dealing with parties not customers of the bank: 820 RAs travel through the ACH network, but there would be no way to get the IG-specific 997 back to the original sender, or something like that. And because the funds had already been transferred, one or both banks wouldn't know what to do. Of course, if banks didn't kludgily send remittances through ACH, the problem wouldn't exist. And they can't do this anyway with the advent of HIPAA because EOBs contain PHI. Payment shouldn't be confused with remittance. The 835, like the 820, seems to have been designed to mimic the old paper remittance, which included the check under a perforation. This document paradigm has been carried over to the electronic arena. An EFT payment is an order to one's own bank (with whom you already have a relationship) to deposit funds in another account, usually at another bank. The payee has no (necessary) relationship with the payer's bank - though the banks themselves have a relationship through the ACH system. The remittance, or EOB, on the other hand, explaining the payment (and containing PHI), is none of any bank's business - payer's or payee's. It's strictly between the payer and payee. Banks are not CEs and can't even legally look at the stuff: it has to be encrypted. But if the 835 were encrypted, how would the bank read the BPR? Why the two - EOB and dollars - should ever travel together is beyond me, unless to slavishly mimic the paper remittance. And so banks can bill themselves as "Value Added Banks," Unfortunately, this practice has caused all this ruckus over the innocuous IG-reporting 997. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Ajay K sanghi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, 22 April, 2002 08:36 AM Subject: RE: questions on the appropriate way to reply when there are error in a transaction request Rachel, Thanks for your response. I guess, for a translator vendor, it means, support "both" ways of doing it, since some customers will probably use only 997 while some will use combination of 997 and 824 to report HIPAA guide errors, especially in absence of clear guidelines mandated by HIPAA. Regards, Ajay ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, 21 April, 2002 01:17 PM Subject: RE: questions on the appropriate way to reply when there are error in a transaction request The implications are, in my mind, that forward thinking EDI management systems vendors will see the opportunity to add new capabilities to their product offerings that serve the needs of a very large potential market. Just because current EDI systems don't automatically generate an 824 today like they can for a 997, doesn't mean that they couldn't if they wanted to. The X12 standards neither require nor prohibit either approach. Furthermore, other industries beyond health care also have this need. And, several of the country's leading EDI management systems vendors are actively involved in the current work being done at X12N on adding new codes, etc. to the 824 to support the insurance industry's needs, but also, as Ruben has pointed out, are hard at work developing an impelemtation guide for the industry to use for the 824. These companies include IBM, Sybase, Unisys...and my apologies to others whose names I can't immediately recall. Lastly, the pioneers that created our X12 standards also recognized that standards must be able to change to meet new needs. Thus, if the issues you mentioned relative to the 824 prevent it from supporting the needs of the users, changes will be proposed and modifications made to meet the new requirements. That's why the current body of X12 standards includes hundred's of transactions, technical reports and guidelines over the first version of the X12 standards in 1983 which contained 6-10 transactions only, no technical reports or guidelines. Rachel ----- Original Message ----- From: "Ajay K sanghi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, 21 April, 2002 01:13 AM Subject: RE: questions on the appropriate way to reply when there are error in a transaction request Rachel, You wrote: >The need for the 824 is crucial to effectively managing the HIPAA error reporting environment. Possibly, even though at this time I am not convinced. Looking at 824 (particularly OTI segment), it seems that "unlike" 997, 824 is "not meant" to be generated directly by the translator (Translators will still be able to directly generate it, is a separate issue). Reason for this is because fields like "transaction/group control numbers", which are "not" normally communicated to business application are "optional" in 824 (mandatory in 997). Rather, business identification fields (please see OTI02, OTI03) are mandatory. What implications would this have? You wrote: > While the 997 can be kludged to report guide syntax errors, such as missing mandatory segment or element or an invalid ***X12*** code, it cannot report an invalid medical code, for example, nor any semantic errors, nor inter-segment dependency errors. I respectfully disagree. Please reject 997 (and use 824 instead) for right reasons and not wrong reasons. For example, (a) invalid medical code (I assume you mean codes from external code sets). This can be "easily" reported using AK403[7]. Even non-coded data elements, where a certain "pattern" of text is desired, can "also" be reported using AK403[7] (b)inter-segment dependency errors All these errors, ultimately boils down to a "situational" element/segment being "required" or "not used". This can also be "easily" reported. Use AK304[3] (Mandatory Segment Missing) for "situational" segments, which are "required" in certain situations. Use AK304[2/7] (Unexpected Segment/Segment not in proper sequence) for "situational" segments, which are "not used" in certain situations. Ditto for other situations, there's no problem. Please tell me situations, where there is difficulty in reporting such errors. Is there a document, which list situations that cannot be reported using 997 but can be reported using 824 (related to compliance of HIPAA messages only)? Please note, in 997 we can also report sequence number (exact position of the segment in the interchange file, which triggered this error) Some situations for which there is difficulty in reporting errors using 997, possibly cannot not be reported even by 824! For example, "a situational element is required if the corresponding value was already received (I think this was in relation with 2nd 837P being generated to a secondary payer in response to 835 received from the primary payer)". I re-iterate from my earlier email: There was no difficulty in generating a corresponding 997 for following cases: (a) Inter-element dependencies within segment. (b) Inter-element dependencies between two different segments of same hierarchy. (c) Inter-element dependencies between elements of different hierarchy. (d) Inter-segment dependencies in the same hierarchy within a loop. (e) Inter-segment dependencies between segments in different hierarchy. (f) Dependencies on external code set for certain elements (both simple and qualifier based (SV101)). (g) Dependencies on certain "patterns" of text in some elements." Ajay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster Sent: Friday, April 19, 2002 10:00 PM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are error in a transaction request Ajay, Absolutely not! The 824 is the only transaction that can effectively support semantic non-compliance errors with a guide. While the 997 can be kludged to report guide syntax errors, such as missing mandatory segment or element or an invalid ***X12*** code, it cannot report an invalid medical code, for example, nor any semantic errors, nor inter-segment dependency errors. The need for the 824 is crucial to effectively managing the HIPAA error reporting environment. There is a snowball's chance in Hell of the X12 Committee membership to agreeing to modifying the 997 to report implementation guide and semantic errors. This has already been attempted and the voting members resoundingly disapproved, with me being one of them. Rachel Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request. ====================================================== The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
