What, no gravy for the goose? Walt, I follow your logic and agree with most of it, in principle, but I think the implications of your assertions illustrate exactly why the coming transition needs to be approached with a more liberal interpretation of the standards.
On the one hand, you assert: "it will be too difficult for payers to determine whether these situations apply (to do so would require payers to understand other payers needs);" on the other, you say, "providers would only have to change the way they bill when two payers have different billing requirements." So you're saying that it's too much to expect 5,000 payers to know what each of them is expecting in the situational data elements, but it's NOT too much to expect 500,000 providers to know that same arcane knowledge? And situational data elements, though seen by some as the "terrain of flexibility" that will get us through the coming storm, is really just an outlying province. Those of us who are trying to please the 5,000 are finding that no two agree on what "HIPAA compliant" really means.... I applaud your perception of the need for flexibility, but the problem is one we all face, not just the payer whose zeal for defining "nonstandard" transactions exceeds its knowledge of its competitors' requirements.... -----Original Message----- From: Troidl, Walt [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 07:39 To: WEDI SNIP Transactions Workgroup List Subject: RE: Situational segments/elements and payer-specific edits Jonathan, We probably did talk past each other, and probably because there are two types of situational data elements - data elements that are required when an another data element indicates that the value will be there, and data elements that are required based on conditions outside of the claim. In the first case, compliance checks can (and most do) enforce the existence or non-existence of the data, but in the second, compliance checks can not determine whether the data should be there. My discussions focused on the second condition. NDCs, taxonomy and other data elements were originally required, but because of the change control process, they were made situational. These changes allow the purists to say that if the situation doesn't apply, then the transaction should be rejected due to non-compliance. My concern is that it will be too difficult for payers to determine whether these situations apply (to do so would require payers to understand other payers needs), so my expectation is that they can only ignore anything they do not need. They will, however need to be able to pass that information on to the next payer (both are required by the rule.) Because of this, providers should be able to determine what situational data elements are required by any of their payers, and send those elements on every transaction they produce. Then, the providers would only have to change the way they bill when two payers have different billing requirements for the same service. Walt -----Original Message----- From: Jonathan Allen [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 10:51 AM To: WEDI SNIP Transactions Workgroup List Cc: [EMAIL PROTECTED] Subject: Re: Situational segments/elements and payer-specific edits Walt, I think we just talked past each other. If you had commented in-line, then my text would have appeared next to yours and we would have seen that we are saying the same thing. > You conveniently dropped my comments on Uniform Billing in order to > make my > comments support your arguments. I didn't intend to create that effect. I agree that Uniform Billing is not a financially viable option at this stage. JA> As you describe it, any receiving payer has to accept a variety of JA> data that they do not want in order to pass it on down the chain. JA> But their input database or file layout must have space allocated JA> for that data so that it can be replayed later - so it cannot get JA> silently dropped on the floor. In other words, the payer has taken a JA> conscious business decision to examine, store and JA> ignore-for-themselves the data that they don't need JA> so that they can regurgitate it for a secondary/tertiary payer. Any data JA> that shouldn't be in the input stream (at all) will cause rejection. JA> So no-one should get sued for not seeing/processing any data. WT> Since payers can not reject transactions because of the existence of data WT> they do not need to adjudicate the claim, and since payers are WT> required to WT> pass the claim on to other payers without changing anything on the WT> claim other than the elements they are supposed to change, is there WT> any reason why WT> providers can not include situational data elements regardless of WT> the need WT> of the payers in the chain of a single claim? If we accept this premise, WT> then providers aught to be able to minimize changes to elements sent WT> for individual service codes by starting with a set of elements that WT> are required by any of their payers and bill those elements all the WT> time. Those two paragraphs seem to match content fairly well to me although written from different points of persepctive. Providers send data that each individual payer may not need so that it can be passed on to others; payers have agreed to store and hold data that they don't need to pass it on to others thus keeping the system going. The only area of concern is that payers have to take a conscious decision to support the through-passage of data that they themselves don't actually require in their own business model. If they are not aware that this decision needs to considered and taken, then data can get lost/dropped and providers may have to bill separately. I had taken Dave's original question to be talking about the transmission of situational data for which the situation didn't apply. Are we together now ? Jonathan ---------------------------------------------------------------------- ------ -- Jonathan Allen | [EMAIL PROTECTED] | Voice: 01404-823670 Barum Computer Consultants | | Fax: 01404-823671 [snip] IMPORTANT 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 and exempt from disclosure under applicable law. If you have received this message in error, you are hereby notified that we do not consent to any reading, dissemination, distribution or copying of this message. If you have received this communication in error, please notify the sender immediately and destroy the transmitted information. --- 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
