I am speaking only for myself. Muttering aloud. Also I refer to the 270/271 complex, since I havn't studied the 278 (though I hear wondrous things about it) > Simpleton Inquiry: > Regarding the "You must not give incentives of any kind to make partners use > Inet Solutions". This is Leagalese. For lawyers and not for techies. The creators of Administrative Simplification knew very well that without mandatory compliance there is no way to change a whole industry's way of doing business. So they decided that whatever you do in your endavours to provide online interaction with your business partners, you can't do it at the expense of your Standard X12N HIPAA support. Both have to be equally developed.
In the case of the 270/271 Benefit Eligibility Inquiry I would say: HIPAA Minimum is just : "Yeah, person is covered on the day you asked" or "Sorry, no dice!" Really modest. 270/271 allow you of course to go a whole lot deeper. You can as a provider list each individual procedure with all applicable modifiers, who is going to do it and when and why and how much you intend to charge. 271, the answer, unfortunately has shortcomings. For example, if you as provider made several lines of inquiry, the answer cannot be traced back to the specific question or line. Unlike claims, for example, where a claim line can be referenced in all transactions (837,834,276,277), the benefit inquiry does not do that. Also, the 271 has not been used to inform a provider back on how much you, as a payer, are going to pay, how much the patient has to cover him/herself and most of all, how much you think this procedure is worth to you in the first place and what is UCR (Usual, Customary or Resonable). Still the 271 can contain a whole lot of detail information. For example:" How many treatments a quarter of this treatment are covered, how many pills of 'miracle drug #1' are covered during each period, if there is a deductible, how much, per subscriber, per family, per year .......... So, to make a long story short, If you support a very evolved Benefit verification, you will have to provide the same level through X12. > If one of the end in mind goals of Administration Simplification via Inet & > EDI solutions is to lower the overall cost of health insurance and the > provision of health services. Why would "government" prohibit a payor form > incenting a provider? Look, you can only bring the horse to the water, you can't make it drink. If you provide 270/271 communications and your business partners, through thought processes unbeknownst to you, decide that your web interface is preferrable, then so be it. You've done all that is required. There won't be a HIPAA police shutting you down because your are in violation of HIPAA codex 3-41 Paragraph 3.4.145.16, subparagraph 13, second sentence, in parenthesis, small print. Not yet at least. On the other hand, you better take a damn good stab at HIPAA compliance, or it will hunt you forever. Just like your IRS filing, I think you have to present a well defensible strategie for compliance. Picking a fight with the Feds can be dangerous to your (business) health. But once you play by the rules, they leave you pretty well alone. Martin Scholl Scholl Consulting Group, Inc. 301-924-5537 Tel 301-570-0139 Fax [EMAIL PROTECTED] www.SchollConsulting.com "If you don't move you don't feel your shackles" Rosa Luxemburg, 1917 ----- Original Message ----- From: "Todd Leeders" <[EMAIL PROTECTED]> To: "Martin Scholl" <[EMAIL PROTECTED]>; "Scott Barley" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, June 20, 2002 3:15 PM Subject: RE: Online Authorization / Referrals > > Martin, > > I'm very new to the industry, in that I am returning to it after 8 years of > being away, so please excuse the simpleton inquiries. I do however possess > 15+ years of IT Experience, so feel free to be technical in your response. > > Simpleton Inquiry: > Regarding the "You must not give incentives of any kind to make partners use > Inet Solutions". > > If one of the end in mind goals of Administration Simplification via Inet & > EDI solutions is to lower the overall cost of health insurance and the > provision of health services. Why would "government" prohibit a payor form > incenting a provider? > > Taking a common sense approach there are only two ways to get a provider to > use such a system and lower overall industry costs: > 1. Payor or Government (Incentives) > 2. Government Non-Compliance (Punishment) > > If you have insight into the reasoning, would you please pass it along? > > Sincerely, > > Todd Leeders > > > -----Original Message----- > From: Martin Scholl [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 20, 2002 10:45 AM > To: Scott Barley; [EMAIL PROTECTED] > Subject: Re: Online Authorization / Referrals > > > NO, > You don't have to convert to X12. but..... > 1.) you have to provide and process the same data content that the standard > transaction has > 2.) you still have to provide a standard system, even though your internet > solution may be faster, more elegant and well appreciated. > 3.) You must not give incentives of any kind to make your partners use the > Internet solution over the standard one. > > Hope this helps > > Martin Scholl > Scholl Consulting Group, Inc. > 301-924-5537 Tel > 301-570-0139 Fax > [EMAIL PROTECTED] > www.SchollConsulting.com > > > > ----- Original Message ----- > From: "Scott Barley" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, June 20, 2002 11:17 AM > Subject: Online Authorization / Referrals > > > > Question: > > > > A payor is providing an internet based product to their providers for the > > submission of referral/authorization requests directly into the payor's > > system. The provider manually enters a request for an authorization > within > > the web application and the info is inserted directly into the database > from > > the web application. Since this is an extension to the payor's system > > application and is not a system to system transaction, is their any need > to > > convert to ANSI 278 before placing into the system? > > > > > > Thanks in advance for any info on this! > > > > Scott Barley > > >
