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 ------------------------------------------------------------------------------ --- 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
