Jonathan, You conveniently dropped my comments on Uniform Billing in order to make my comments support your arguments. HIPAA does not dictate billing and payment policies because there is too much diversity between payers especially when you include Medicare and Medicaid in the mix. HIPAA places a significant financial burden on all impacted parties to ensure providers can bill for the services they render, and payers pay appropriately for those services. Standardizing transactions is the first step, and if you have been following the listservs for a while, you should have seen that this step alone is far more costly than initial HHS projections.
Had HIPAA dictated Uniform Billing in this round, most payers would likely be facing bankruptcy or would have chosen to not participate because the penalties likely would be less than the cost of compliance. If we have any hope for HIPAA to succeed, we can not expect Uniform Billing in the near term, and we need to focus our attention on the things we can affect. Since payers can not reject transactions because of the existence of data they do not need to adjudicate the claim, and since payers are required to pass the claim on to other payers without changing anything on the claim other than the elements they are supposed to change, is there any reason why providers can not include situational data elements regardless of the need of the payers in the chain of a single claim? If we accept this premise, then providers aught to be able to minimize changes to elements sent for individual service codes by starting with a set of elements that are required by any of their payers and bill those elements all the time. If we accept this approach, providers have a way to bill most service codes in a standard way. The providers will still need to meet payers requirements to bill services on different forms (transactions) or different service codes, but they should be able to bill each code on a transaction the same way in most cases. Note: the reason I am not committing fully to this is because of the varied approaches to the elimination of Local Code. This part of the rule requires Medicaid payers to use national codes to define their services, and because the service needs to be uniquely identified for special payment policies and Federal reporting requirements, Medicaid agencies have to use additional data elements to ensure their systems can identify the one service from another, e.g., a waiver service from a normal Medicaid service that is billed using the same form and base service code. Many are using combinations of modifiers and taxonomy to ensure this uniqueness, and because of this, standardized billing for individual service codes can not be fully achieved. Uniform Billing aught to be our final target, but it is unachievable at this time. Payers are not unaware of the providers' plight as witnessed by some of the early surveys used to assess the feasibility of Uniform Billing. Those surveys established an awareness of the issues, but the findings indicated significant valid reasons for most of the differences in payment policies. The surveys also gave us an indication of the difficulties we would face in deciding how to bill each service uniformly and the potential costs needed to implement the changes. Walt ----Original Message----- From: Jonathan Allen [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2003 11:35 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Situational segments/elements and payer-specific edits Walt, > The principal reason for the HIPAA rule is to make claims transactions > more consistent. Absolutely. Any provider should only ever have to send one format of claim: the HIPAA format. All payers should accept and process all data from that one format, discarding anything that they themselves don't want or need. > Providers have to bill payers based on the payer's payment policies > (keeping within the HIPAA guidelines), and these policies differ. This is what defeats HIPAA, just it has also defeated the DoD and other 800lb gorillas who have attempted to introduce standardisation across a range of EDI transactions. > If we require providers to bill each payer differently when the service > code and other basics are the same but the situational elements needed > differ between payers, then we have fully defeated the reason for HIPAA. With the greatest possible respect, you are looking at the symptoms, not the diagnosis. The allowance for different payer policies to alter the content of a standard HIPAA transaction is the root problem. HIPAA is and was always intended to be standard, not variable. > It makes sense to me that providers should develop their claims submission > systems to support all payer needs and that payers accept claims regardless > of what data is in elements that they do not need. That sounds exactly right - and fits the HIPAA model. Perhaps it all comes down to the meaning of the word 'need' ? You are talking about the payer's needs, whereas I was talking about the HIPAA rule's needs. Sending situational data that the HIPAA IG says is not to be situationally sent is a compliance failure, regardless of what any payer may think they want. > Kepa, in an earlier message, cited a segment from the IGs that providers > should send the data if the situation applies. I take this to mean that the situation is defined by the IG and has nothing whatsoever to do with the payer or their policies. If an ambulance service code is quoted, then a code must be present to say why it was needed. > Extending this argument, rather than requiring providers to determine which > payers are in the chain, wouldn't it be more practical for payers to ignore > any data that they do not need so that providers can bill individual > services codes in a way that all payers who pay for that service code will > accept? Again, you are talking (and quite correctly, I recognise) about the needs of individual payers, rather than the HIPAA compliance needs which is the direction that I was coming from when answering the original question. As you describe it, any receiving payer has to accept a variety of data that they do not want in order to pass it on down the chain. But their input database or file layout must have space allocated for that data so that it can be replayed later - so it cannot get silently dropped on the floor. In other words, the payer has taken a conscious business decision to examine, store and ignore-for-themselves the data that they don't need so that they can regurgitate it for a secondary/tertiary payer. Any data that shouldn't be in the input stream (at all) will cause rejection. So no-one should get sued for not seeing/processing any data. Does that make sense ? Jonathan ---------------------------------------------------------------------------- -- Jonathan Allen | [EMAIL PROTECTED] | Voice: 01404-823670 Barum Computer Consultants | | Fax: 01404-823671 ---------------------------------------------------------------------------- -- Please Note The information in this E-mail message may contain legally privileged and confidential information intended only for the use of the individual(s) named above. If you, the reader of this message, are not the intended recipient, you are hereby notified that you should not further disseminate, distribute, or forward this E-mail message. If you have received this E-mail in error, please notify the sender immediately and delete the original. --- 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
