Sujay, Thank you! I totally agree...but there are many others who want to muddy the waters by putting some IG non-compliance errors in the 997. I guess I'm just an old structured programming mainframe legacy programmer who was disciplined on modular approaches and independence of functions.
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: Sujay Pidara [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 6:09 PM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there areerror in a transaction request It will be helpful to have one standard transaction in the future to report all and only HIPAA implementation guide errors including inter segment situations and external code set testing (medical codes). Pretty much the standard transaction should be able to handle any errors coming out of the six level of testing as recommended by SNIP white paper. To report some IG errors in 997 and some in 824 or report IG errors as well as application/business errors in 824 will be confusing. Reporting to the trading partner that the transaction is not HIPAA compliant separately in a standard transaction will simplify the communication. Just my opinion Sujay Pidara Radicle Incorporated >>> [EMAIL PROTECTED] 04/22/02 07:36AM >>> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster Sent: Sunday, April 21, 2002 10:47 PM To: [EMAIL PROTECTED] 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 [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 21, 2002 12:13 AM To: [EMAIL PROTECTED] 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 -----Original Message----- From: Ajay K sanghi [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 11:13 PM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are error in a transaction request Rachel wrote: >I will reverse my earlier conclusion about X12 vs HIPAA compliance as it relates to potential penalties, since you're right. If the purported HIPAA transaction doesn't comply with the X12 standards, then it most certainly couldn't comply with the HIPAA IG. Thanks. Don't you think that case for 824 is weaker now? I really hope that 997 is modified to handle HIPAA guide edits. Ajay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster Sent: Friday, April 19, 2002 7:07 AM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are error in a transaction request Mike, There are a couple of good reasons to separate the boundaries and associated error reporting. The reason for error reporting is to identify the problem with sufficient specificity such that the problem can be corrected. I will reverse my earlier conclusion about X12 vs HIPAA compliance as it relates to potential penalties, since you're right. If the purported HIPAA transaction doesn't comply with the X12 standards, then it most certainly couldn't comply with the HIPAA IG. A lot of the discussion on this issue here and elsewhere seems to be based on the assumption that a good EDI system/translator will be in play. I have a strong fear that many of the smaller vendors that offer practice management systems to providers will try to write their own EDI software without a full understanding of the rules and then try to create "compliant" HIPAA transactions.....I think this is another train wreck waiting to happen and the train will be coming full speed at the payers who will have to deal with the wreckage. I'm not at all concerned about the 824 not being a HIPAA transaction now....there are several other transactions that are playing key role in the information exchanges here that are not HIPAA transactions, e.g., unsolicited 277, 271 roster, 811 service billing, etc. What difference does it make if the transaction is not a HIPAA one as long as it improve the quality and timeliness of the data and improves (takes cost out of) the process. That's the real goal here, not just the limited number of HIPAA transactions adopted to date. More are on the way in any case. So, it behooves everyone to implement a robust flexible infrastructure on which to build for the near term and the future. If implementers of this transactions don't focus on process improvement now as part of the implementation strategy, they will incur only additional expense, no administrative simplification, and certainly no cost reduction. Lastly, none of this HIPAA transaction stuff addresses the entire issue of routing, tracking, reporting errors, etc. That entire activity is left up to the implementers to figure out. The HIPAA electronic transaction rule only address what data and how to format it....once that's done one could conceivably put it in a bottle and send it down the river to the ocean. Thus, there's a huge gap here in the entire process of successfully "exchanging" standardized electronic data consistently and reliably. Without this, you have nada..... 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: Augustine, Mike [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 2:17 PM To: '[EMAIL PROTECTED]' Subject: RE: questions on the appropriate way to reply when there are error in a transaction request Rachel, I think I follow what you are proposing and it makes sense to a point, but I don't totally get it. I would have to also contend that the HIPAA IGs are a subset of X12. If you can't get the X12 right, you're non-compliant, right?. You may be able to distinguish, but what real value is there in doing so? Also, the large scale translation software that my client has purchased has HIPAA compliancy checking built in as an optional feature. An incoming or outgoing transaction will be compliance checked and either pass or fail. I'm not thoroughly proficient with the process yet, but I do not believe there is any room for separating X12 compliance from HIPAA compliance. I also believe that the idea is if the compliance check fails, the transaction will be rejected with a 997. And finally, although your scenario with the 824 in the middle may be correct EDI-wise, isn't a little ironic that the method of reporting HIPAA non-compliance would be with a non-HIPAA mandated transaction? Since there is no HIPAA IG, then you would have to negotiate with each trading partner that you are going to use the 824, and then specifically how it will be populated, and that leads to details in a companion guide, which leads to accepting or sending different 824 configurations for different trading partners... It seems to continue some of the problems that having the industry standard are supposed to reduce or eliminate. Perhaps the 824 should have been included in HIPAA, but since it hasn't should we really move to standardize on it? I may be just missing some of the big picture. Please help me out with where the flaws are in my reasoning. Mike Augustine Principal, SILC, Incorporated -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 11:13 PM To: [EMAIL PROTECTED] Subject: RE: questions on the appropriate way to reply when there are error in a transaction request 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 ********************************************************************** 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. ********************************************************************** 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. ********************************************************************** 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.
