Of course, whatever changes are made to the usage of 997 (if such decisions came to pass) would have to be reflected in the IGs. Seems to me there's been another thread running with similar intensity over the issues involved in making changes to IGs... 8-)
Best regards, Bill Chessman Peregrine Systems, Inc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2: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.
