A message about this topic quite a long time ago. Best regards, Jim Driscoll Business Analyst-Software Development Sloans Lake Managed Care 1355 South Colorado Blvd. Denver, CO 80222 303.504.5367 direct 303.504.5367 fax 1.800.457.2345 >>> <[EMAIL PROTECTED]> 09-Apr-01 09:33:00 AM >>> You may or may not have see Kepa's comments on HIPAAlive but I think he brings up a very good point.. that is.. what does situational really mean. Have we or will we include this in any white papers? Including Kepa's comments would help to further educate those reading the papers. "Stuart, The answer to this is a long story... get your popcorn. When the Implementation guides were being drafted we used to have the typical X12 terminology of "Mandatory" and "Optional" elements. The problem was that the Optional elements were actually at the option of the submitter, just like you describe in your message. There was little predictability from submitter to submitter as to what "optional" really meant. So, we were given some guidance from HCFA to tighten these guides and specifically define every single element as a "not used" or "required" element. Of course, life is not black and white, so we asked for a little flexibility. As a compromise we ended with the "Situational" elements. What "Situational" is supposed to mean is that there is a specific situation where the element must be used, and if that situation is not present, then the element must not be used. So, there are no more "optional" elements, they are either "required" or "not used", and the requirement could be dependent on a specific "situational" clause. Supposedly the situations have been clearly defined in the guides and there is no ambiguity... but the trick is in how the situation is defined. So, if the situation says "Required when ... " it also means "Must not use unless..." This is a not well understood topic, and I am sure will cause much controversy. Now, having said all that, and to appease your heartburn, take a look at page 479 of the professional guide for a creative situation: "Used at discretion of submitter" This one goes back to the "optional" concept. The NTE segment on page 488 says something like "Required for NOC procedure codes. Acceptable in other cases at provider's discretion." This one is a "mostly optional" type of concept. So, going back to your question... the answer is that you really should not send the line item in loop 2400 if it matches something you already sent in loop 2300. If you do send it in both places, and they are both the same, you are technically in violation of the guide. For something like the POS, you could either send it in loop 2300 and suppress it in loop 2400 if it is the same POS, or not send it in loop 2300 at all and only send it in each service line. But, between you and me, I suspect that no payer will reject a claim because it has redundant data, but there could be some exceptions. The safest thing to do is to stick as close as possible to the implementation guides. Any shortcuts today could backfire tomorrow. I hope you are enjoying your transaction mapping. Kepa Zubeldia Claredi" Thanks! Jonathan Showalter Omaha NE USA 402-343-3381 [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. ********************************************************************** 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.
