I'm not a payer, but I'll butt in anyway: 1) - not doing any "compliance" checking at all - is almost impossible! Even if no validation beyond the X12 syntax level is done in the translator, surely the back-end system is doing some kind of editing and consistency checking! For example, maybe the translator is set up to just move diagnosis codes from the EDI HI segment into consecutive database or flat file fields. Surely the back-end would check the validity of the codes, ensure there are no duplicates and figure out whether they make sense in the context of the claim or the plan. Likewise for dates: it's possible the translator has no - or rudimentary - capability for editing for the syntax of DTP dates. Instead, the backend would check to make sure the dates are syntactically valid (e.g., CCYYMMDD) and they make sense in the context of the claim, subscriber or patient (i.e., the claim is not submitted before the date of service).
2) - Doing Compliance checks only during the development and testing stage. If this means using a third-party testing tool to validate EDI data in order to ensure that your maps and back-end logic are working, I would most emphatically agree. Even the pros like Doug Webb probably can't "eyeball" EDI data to make sure it's perfect! - a desktop or web-based checking tool is to EDI mapping like a debugger is to C++ programming! Note that even though "checking" is a by-product of an online certification service, it will be useful to have a desktop checker for programmer convenience. 3) - Do compliance on all incoming files, send out a 997, but don't reject anything. The translator will automatically generate positive or negative 997s depending on the absence or severity of X12 syntax errors. If there are X12 syntax errors, at a minimum the entire transaction set must be rejected, as translation will probably be rendered impossible (e.g., the translator would lose its way if a mandatory segment is missing). The 997 can't report on HIPAA compliance violations - e.g., there's no way for the 997 to say a diagnosis code is invalid or out of date. You must use an 824 or other application acknowledgment transactions for reporting most HIPAA "compliance" errors - or e-mail or fax. 4) - Reject the ST/SE pair that contained the compliance error and accept the rest of the file. You can do this, but it is somewhat drastic: do you really want to reject an entire 837 with thousands of claims in it, even though only one had an invalid diagnosis code? Again, a 997 can't be used for any but X12 syntax errors. The 824 or other application acknowledgment transactions give you finer-grained control over which pieces-parts you can report on as having been rejected. 5) - Reject the entire file - is a variant of 4). I would offer the same advice: use the 824 or other application acknowledgment transactions (see the WEDI/SNIP Business Issues Front-End Edits white paper) to reject only the pieces-parts with serious compliance errors in the data you actually map and use. 6) - Other. What "Other" is there? Note that commercial compliance checkers can't or shouldn't do anything with transactions that fail compliance - other than to issue errors and warnings in a report or a file that can be used to generate a subsequent 824. Generally, only your back-end can "reject" for HIPAA compliance errors (though the translator can handle X12 syntax errors with the 997). Some translators promise to do "compliance" editing, but I'd generally be loathe to trust it being done during translation. It's duplicative of what you're going to be doing in your front-end edits and back-end systems where you should be on the lookout for making sure stuff makes sense in the context of HIPAA. Your translator should stick to the knitting and simply translate. See my comments Re: Translator Validation Level from 29 Jan 2003 at http://www.mail-archive.com/[EMAIL PROTECTED]/msg01212. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Schmidt, Michael" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Monday, 31 March, 2003 05:34 PM Subject: HIPAA Compliance checks and compliance failures As I payor I'm interested in finding out how other entities are going to be handling transactions that are not HIPAA Compliant. There are commercial compliance checkers available out there, the question is what you do with the transaction that fail compliance. It seems to fall into several broad categories: 1) Don't do Compliance checks at all--if I can process the transaction through my back-end system I'm happy. 2) Do Compliance checks only during the development and testing stage with a given trading partner. 3) Do compliance on all incoming file, send out a 997, but don't reject anything. 4) Reject the ST/SE pair that contained the compliance error and accept the rest of the file. 5) Reject the entire file. 6) Other Where does your organization, and others you've worked with, fall on the above list? Thanks Mike Schmidt Ochsner Health Plan 504.219.8189 [EMAIL PROTECTED] --- 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
