[Hardhats-members] RBRVS_AR II - Integrated systems

[Thurman Pedigo]

Question of the day: Do you disagree with any statement below?   1. While programming for an effective medical record is remarkably challenging, the programming of a practice management product is relatively easy.   2. Medical practice management software matured 20 years ahead of the medical record products.   3. Not much new has happened with medical practice management systems in the past 15 years.   Elaboration below: FileMan: (FM) The strength of FM is it’s flexibility for creating and modifying design. AR discounting has created some concerns about how to have multiple prices for one code.  Discounting, used in business for ages, is today, a common method of doing business. Today that discounting occurs in various flavors. It may be in restaurant, fast food, Xmart, electronic stores and take the form of  two for one, 50% off, mail in rebates, and a list limited only by the creativity of the seller.  Not long ago I head a promotional speaker say “ Doctor’s can’t do two for the price of one – its unprofessional..”  I recalled the going rate for MRI around here is $1700, and a large radiology group in town will do it on discount for $375. Somehow, that seems better than four for the price of one.   The point - discount manages price adjustments and “multi-pricing” complicates the effectiveness of AR management. Medicare has for years had a law one could not charge any other entity less than Medicare – a policy with little relevance today. Therefore, today, the pricing is appropriately the highest fee the provider expects from anyone and discounts take care of adjusting other “prices.” If there is any situation this doesn’t work, discussion is welcomed to clarify and search for corrective methodology.   Anyone designing a practice management application today is remiss if not dealing with the RBRVS. This is a concept that allows automatic adjustment of 10,000 charge codes with the simple change of one number – the conversion factor. One resource for an idea of the structure may be found at:  http://www.wisent.com/c_med_mrv01.htm   An element that seems to generate consternation is the electronic media claims (EMC), and the electronic media remittance (EMR). I mention these items of concern, because of the usual confusion surrounding the difficulty of programming EMC/EMR. The confusion usually arises from lack of programmer awareness of the requirements and vendors desire to present it as a challenging task. In the early days of EMC there were several formats and a separate program was required for every company a practice contracted with. HIPAA is stipulated to consolidate all the formats into a single format for all users. The interesting part of that pre (and post)-HIPAA environment was many of the insurance carriers were not able do the electronic processing and contracted with “clearing houses” to print the of the EMC files to HCFA1500 of other format they dealt with before they could process the claim manually.   Imagine this scenario – provider renders a service and bills via HCFA1500; clearing house1 contracts with provider to convert HCFA1500 to EMC and sends to carrier; carrier contracts with clearing house2 to print the EMC to HCFA1500; carrier processes HCFA1500 manually and sends check to provider.   I know off no specific instances where the above happened, however, it was the scenario I heard in some of the earlier HIPAA conferences, and I have no information, regarding carriers, that would cause me to doubt the reports. Final installment carries my practice PROCFILE applicable RBRVS elements.