HIT Perspectives – February 2016
Cutting Through the Confusion Surrounding Electronic Formulary and Benefit Checks
By Tony Schueth, Editor-in-Chief
Research indicates that much of the value proposition for electronic prescribing (ePrescribing) lies in providing formulary information at the point of prescribing. Despite the value of point-of-care formulary validation, the current process is significantly underused due to a variety of issues. While slow progress has been made in addressing those issues, the industry has moved on a separate track toward developing a new technology being considered as a replacement for the current process — real-time benefit inquiry (RTBI). So, we now have a process with standards that are not providing sufficient value with disparate pilot projects and one-off, proprietary products based on interim standards that have not been finalized. The situation reminds me of the title of an old Temptations song: “Ball of Confusion (That’s What the World Is Today).” Let’s clear some things up.
The current process. There is confusion and consternation around the current formulary standard because of related implementation issues and how it is used. As a result, prescribers often ignore this valuable resource when ePrescribing or rely on the pharmacist to navigate the patient’s formulary requirements after he or she attempts to get paid. This is unfortunate because it prevents providers from ordering the most appropriate and cost-effective medication options for patients at the point of care. There’s a fairly long list of reasons why prescribers don’t use existing formulary validation capabilities.
Granularity. First, there are problems with data granularity. Presently, payers use the National Council for Prescription Drug Plans’ (NCPDP) Formulary and Benefits (F&B) standard to provide formulary information generally at the “plan” level, sometimes at the “group” level, but never at a “patient-specific” level. (Examples: “plan level” would be General Motors, “group level” salaried employees in Detroit and “patient level” Jane Doe, plant manager.) The fact is there could be formulary variances depending on level. As a result, the formulary may just not be precise enough.
Data latency. Formulary information in a prescriber’s electronic health record (EHR) system may be stale. There are lags between the time when the formulary information is published to intermediaries, the largest of which is Surescripts, and the frequency by which EHR vendors incorporate formulary updates into their systems. Prescribers also may add to the data latency problem by not regularly installing the latest information into their system.
Data representation. Formulary status data in an ePrescribing system may be difficult for prescribers to decipher because of the way they are presented. Formulary design is complex, and ePrescribing systems attempt to simplify formulary status using colors or tier designations that are open to interpretation. For example, many ePrescribing systems limit display of formulary benefits to three tiers; however, there are four-, five- and six-tier plans that need to fit into a three-tier display. Also, terms like “nonformulary,” “not covered” and “nonpreferred” can mean one thing to the payer but may be interpreted as something else by the prescriber.
Prior authorization. Then there’s the issue of prior authorization (PA). Formulary files used in ePrescribing arent always complete; for example, one common deficiency is they don’t always have indicators that PA is required. Lacking such indicators, the ePrescribing system may show that PA is indicated (based upon the plan level) even though it is not required by the patient’s group or individual coverage. These challenges may be magnified when providers manually try to match patients with a formulary if their ePrescribing systems do not conduct eligibility-driven formulary matches. So, doctors throw up their hands (who could blame them?) and patients end up with an alternative treatment that may not be optimal for them as providers try to avoid prescribing a drug listed as requiring PA.
Co-pay Information. There also are cost implications for patients because copay information usually is not available in the formulary data, even though the current NCPDP F&B standard can accommodate it. Why? Most payers do not provide it because of the complexity in calculating copays, including days’ supply and deductibles. Copays also are difficult to calculate precisely without knowing when and where the prescription will be dispensed.
A “shiny new thing” emerges: RTBI. Given the challenges with the existing formulary validation process, the industry is looking toward a new standard to address the issues. RTBI is the latest “shiny new thing” to grab people’s attention. Its value lies in its ability to provide almost real-time, patient-specific formulary and benefits information at the point of care, including patient-specific utilization management programs (such as PA and step therapy), true out-of-pocket costs for a medication (specific copay/coinsurance amount and deductible information), and which pharmacy will be most cost effective in light of the patient’s insurance coverage and available pharmacy benefit. On one hand, this should result in a cleaner prescription before it hits the pharmacy, which would increase efficiency. On the other, there are concerns that using it would add too much time to the ePrescribing work flow, which would serve as a barrier to adoption.
So, is RTBI really a better mousetrap? Eventually, perhaps. For one thing, RTBI was originally designed to be a secondary check of the current F&B transaction, not a substitute. It also is used in a different place in the ePrescribing process and work flow. While it adds value, it is not a replacement.
Pilots are under way. Several RTBI pilots are currently under way, each using different standards. Some pilots are using the NCPDP claims standard (NCPDP SCRIPT), which pharmacy benefit managers (PBMs) and payers have not yet integrated at the appropriate point in their claims adjudication process. Others are using the NCPDP telecommunications standard, which will require significant development and cost for integration into EHRs. Especially for the EHRs, its not a question of standards so much as of prioritization of development, which is generally simplified to what the government is requiring or what business model is being used. Both PBMs and EHRs have expenses and a lot on their plates, so fitting in new ways of communicating formulary information must be prioritized and placed in the development queue. Frankly, it’s not a priority for either PBMs or EHRs because there is no prescriber demand for it. Yet.
What about eBenefit verification? Adding to the confusion, people may think that electronic benefit (eBenefit) verification is the same as formulary verification. It’s not. eBenefit verification is used in the rarified world of specialty pharmacy by “hubs,” which were created to make it easier for patients to acquire biologics and other types of life-saving or enhancing, but sometimes expensive, specialty medications. Hubs use eBenefit verification to determine how much a payer will cover for a particular drug and then seek additional funding for the balance. Its an entirely different transaction in an entirely different world based on an entirely different set of standards.
Going forward. So, where do we go from here? Is there a real need for RTBI? Should we just make better use of the current F&B standard? Both? We have some thoughts.
We think the answer is both. The current F&B standard can and should be improved. We hope the industry will continue work on both in 2016, but development of RTBI should proceed.
While RTBI is attractive, we do not anticipate it being truly ready for prime time in the marketplace before 2020. More developmental work, pilots and testing are needed, and the driver – be it business model or regulation – needs to be identified and put into place.
Pilots yield valuable information and feedback. We hope the pilot phase is not skipped or truncated to prematurely rush standards into the market.
PBMs and EHR developers need to keep their eye on whats happening with RTBI. The push-pull of the marketplace could create demand for which they may be unprepared.
Potential sponsors should be wary of vendors promoting one-off products based on their proprietary implementation of RTBI. Getting behind such products could end up for naught. Standards need to be finalized and diffused into the market. Embracing an early proprietary solution could be counterproductive and expensive. Remember Betamax?
We believe the confusion involving the mechanics and usage of RTBI will sort itself out. As a leader in eMedication management, Point-of-Care Partners is closely monitoring how all of this is developing and where it is going. Let us keep you updated.