I think this entire thread points up a potential gray area that's going to make HIPAA compliance and cooperation a little more difficult: 824 is not mentioned in any of the published IGs (draft or final) while the 997 is mentioned in all of them. Since there's no recommendation for a common implementation of 824, there's going to be...well...chaos...
Issues for the error reporter (creating 824s): > Which version of 824 should I use? > Which types of problems should I catch or not catch? > How much human intervention will this require? (I love the TED (technical description) segment...it includes 60 bytes of free-form message to help describe the problem!!!) > How detailed should the error reporting be for any given incursion? Issues for the error report recipient (created the original data in error): > Which version of 824 did trading partner X use? > How much of the error fixing can I automate (and how much time will that take)? > E-gads! Yet another transaction set to deal with...I'm already underwater with the rest of the HIPAA ballast! These are things that everyone needs to think about. I am not saying the 824 should not be used--far from it! I'm just saying that the lack of a HIPAA specific IG leaves the field open so that every trading partner can do their own thing--and I'm sure they will! 8-) Finally, if an 824 IG that fit the HIPAA world could be created (a big if and an arduous task no doubt), would that be under the auspices of X12N or some other subcommittee? Best regards, Bill Chessman Peregrine Systems, Inc. -----Original Message----- From: Sujay Pidara [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 7:47 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are error in a transaction request In the same vein of separation, it will be helpful to keep the communication of syntactical errors separate from Application pre-edit errors/semantic errors. From what I read in the "Front-end edits" white paper on SNIP-WEDI, it also recommends separating IG level results from the Application pre-edit results. X12 also provides communication for syntactical errors separately through 997. Compliance to the IG syntax is necessary under HIPAA. Application pre-edit errors at the moment are payer specific. Lately, I read that 820 version is geared more towards semantic and maybe also application pre-edit errors. If that is the case then it will mix syntactical errors with application pre-edit errors. Sujay Pidara Radicle Incorporated >>> [EMAIL PROTECTED] 04/16/02 10:13PM >>> Don, All things being equal (and when does that ever occur!) I would tend to agree with you. On the other hand, HIPAA is especially unique in that there are federal economic penalties that apply for covered entities that conduct non-standard transactions. Now, we've all heard that HHS/CMS isn't anxious to wield the economic ax, but if/when penalties will apply (and I would contend that legally that would be either on/after 10/16/02 or 10/16/03) then there must be a clear, unambiguous boundary between X12 standards compliance and HIPAA compliance. Mixing some HIPAA "syntax" into the 997 does not give either the receiver, which applies the edits, nor the originator, which created the non-complying transaction, a clear statement of whether the transaction fails X12 compliance or HIPAA compliance. I can argue that X12 non-compliance would not subject the covered entity to any federal penalties, but most certainly HIPAA non-compliance would. It's for these reasons that I continue to argue strongly for keeping the boundary clear and unequivocal. If we don't, the lawyers will have a wonderful day in court when some of this gets there....and I would bet a day's consulting fee that it will....sooner or later. If this gets "mushed" together (that's a technical term!!!) sorting it out becomes quite costly. Why not bite the bullet now, develop the necessary enabling functions in the EDI management systems and move on. As a former software developer I could even see where it could be a strong competitive advantage for an EDI management system's vendor to offer a two-pass validation totally within the EDI interpretation/generation function, automatically applying two maps with the first one being vanilla X12 compliance and the second HIPAA guide compliance. This is not rocket science program design nor logic.....it's actually not that much different from the old two-pass code compilers in the old days. To me, this would be a no-brainer added new HIPAA feature that could blow my competitors away....if I was an EDI management system developer, that is. 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 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 4:08 PM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are erro rs in a transaction request Well, not to be too controversial, but I think there is a reasonable compromise here. I agree with Rachel that 997 should be limited to X12 syntax and code set lists, and so on. I agree that when we start to introduce X12N Implementation Guide edits it will be hard to know where to stop. But, I suggest there are some very reasonable Implementation Guide edits that could be added to the 997. In fact, I believe the 997 would be a better place to handle some edits because it will be done on the front end rather than the back end of processing and wouldn't require a new implementation guide to implement, which will be needed for the 824. My suggestion is where X12N transactions have limited (reduced) the code set list for certain data elements within certain segments or transaction loops, that translators could easily do this edit and report errors with the 997. We're still reporting what code values are permitted, but we're restricting the list to a subset of what X12 permits. This seems reasonable to me. This would not really enter into situational as much as just what the health care industry has defined to be a logical set of values for our industry. Don [EMAIL PROTECTED] on 04/16/2002 01:20:41 PM Please respond to <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> cc: Subject: RE: questions on the appropriate way to reply when there are erro rs in a transaction request Ditto -- Bruce Bill Chessman <bill.chessman@pere To: "'[EMAIL PROTECTED]'" grine.com> <[EMAIL PROTECTED]> cc: 04/16/2002 11:39 AM Subject: RE: questions on the appropriate way Please respond to to reply when there are erro rs in a transactions transaction request I think the big question is, once you start, where do you stop? The idea of situational and required elements being flagged as missing in 997 seems reasonable to me, but once we start adding these things, there'll always be something else. I think that Rachel's guideance was right on target. I know that there's a lot of resistance to 824 vs. 997, but there's a legitimate distinction between application-specific (ie., HIPAA) problems and mechanical EDI problems (IMHO). I also note that there's an implementation of 997 included in the appendices of each of the HIPAA IGs. I haven't spent a lot of time, but I imagine they're all pretty much the same (boilerplate, I hope). This presents the potential that, at some point going forward--if it should be decided to report HIPAA IG failures via 997, the IGs might start to vary their implementations of 997...that would be no fun. Best regards, Bill Chessman Peregrine Systems, Inc. -----Original Message----- From: Ajay K sanghi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 3:42 AM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are errors in a transaction request My view is that to the maximum extent possible, translators should handle HIPAA guide validation failures using 997 and not stick to just X12 "standard" syntax validation. If a "situational" element/segment, which is "required" in certain condition is missing, 997 should generate "Mandatory Data Element/Segment Missing" code for such elements/segments and likewise. Ajay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster Sent: Tuesday, April 16, 2002 4:11 AM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are errors in a transaction request Jim, When and on what basis to reject is basically a business/risk decision on the part of the receiver. However, I take the following view: 1. The entire interchange must pass the full X12 syntax validation. If errors, fail and report via 997. 2. If interchange passes X12 syntax then apply HIPAA guide validation rules. If a transaction within the interchange does not comply with guide, fail the transaction and report via the 824. Keep in mind that validation also includes validating medical and non-medical codes as being valid within the referenced code set. 3. If transaction passes HIPAA guide validation, pass transaction data to internal application and apply internal business rules. Report pass/fail using various mechanisms, i.e., 271 response to 270, 277 response to 276, and so on. But that's just one person's viewpoint. 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 -----Original Message----- From: Jim Moores [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 7:55 AM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there areerrors in a transaction request Hi Rachel, I agree. However, do you just reject the one claim in error or do you just reject the entire batch of claims in the transmission (assuming that you have gotten other transactions in the transmission) or do you reject the entire transmission? In some cases, I think that the entire transmission is appropriate... like when the loop structure is so corrupt that you can't parse it. But, what about the area between that and the perfect transmission? Jim Moores - HIPAA Team Leader - Privacy Antares Management Solutions 23700 Commerce Park Road Beachwood, Ohio 44122-5832 [EMAIL PROTECTED] Phone: (216)292-1605 Fax: (216)292-1619 >>> [EMAIL PROTECTED] 04/13/02 08:30PM >>> Connie, If the incoming transactions contains X12 standards syntax errors it must be rejected. The correct way to report this rejection is via the 997 Functional Acknowledgment transaction. 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 -----Original Message----- From: Connie Lagneaux [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 1:06 PM To: '[EMAIL PROTECTED]' Subject: questions on the appropriate way to reply when there are errors in a transaction request 1. If there are actual syntax errors in an incoming X12, what exactly is the correct way to respond? By this I mean it is not a valid X12 at all. We are unclear as to whether it is appropriate to respond with a 997 vs something, for example, in a 271 or 277). 2. If there are "logical" errors in an incoming X12, what exactly is the correct response? By this I mean it is a valid X12 but it does not meet the HiPAA specs. Examples: If 276 - IG 54, 98 - is not set to the code "PR" for payor but to something else, what do we do? (if we would be receiving requests only from payors) A 997 response? If 276 - IG 67, 98 - is not set to "1P" for provider but to something else, what do we do? (if we are only expecting 1P) A 997? 3. If there are "business" errors in an incoming X12, what exactly is our response? By this I mean that the request is both a valid X12 and a valid HIPAA transaction but contains other errors. Examples would be an unknown information source (payor), and unknown provider, etc. Also I think this would include issues like the dependent given is not a dependent of the given subscriber. It appears that each level of a 271 has request validation segments / reject reason codes in the 270 request. Are these codes used for business errors while a 997 is used for other errors? Since the 277 lacks these codes, are all errors handled using 997s? If so doesn't this stop all further processing of the 276 transactions in the transmissions? <<...OLE_Obj...>> Connie Lagneaux, RN, BSN, MBA Senior Business Analyst 5151 E. Broadway Boulevard, suite 1050 Tucson, AZ 85711 Phone (520) 571-1988 ext. 153 Fax (520) 571-1927 <mailto:[EMAIL PROTECTED]> ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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. ---------------------------------------------------------------------------- -- CONFIDENTIALITY NOTICE: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this communication. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You, Antares Management Solutions. ============================================================================ == ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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. ---------------------------------------------------------------------------- --- This message and any included attachments are from Siemens Medical Solutions Health Services Corporation and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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.
