Enhancing an ePrescribing System By Adding Medication Histories and Formularies: the Regenstrief Medication Hub

Abstract

Medication histories improve health care quality and safety; formularies serve to control costs. We describe the implementation of the Regenstrief Medication Hub: a system to provide both histories and formularies to the Gopher ePrescribing application. Currently the Medication Hub aggregates data from two sources: the RxHub consortium of pharmacy benefit managers, and Wishard Health Services. During one month, the system generated 53,764 queries, each representing a patient visit. RxHub responded with 4,012 histories; Wishard responded with 23,421 histories. The Medication Hub aggregated and filtered these histories before delivering them to Gopher. However, clinician users accessed the histories during only 0.6% of prescribing sessions. The Medication Hub also managed drug benefit eligibility data, which enabled formulary-based decision support. However, clinicians heeded only 41% of warnings based on the Wishard Formulary, and 16% of warnings based on commercial formularies. The Medication Hub is scalable to accommodate additional pharmacy data sources.

Introduction

In recent years there has been increased focus on health care quality and safety. One important means to this end is the documentation of a medication history: a list of all current, and past, medicines which a patient is taking.¹ The disaster of Hurricane Katrina demonstrated the confusion caused when medication histories are lost, and the success of efforts to recreate those histories from diverse sources.²

Concurrently, there has been increased focus on cost control. Prescription drug costs accounted for $201 billion in national health expenditures in 2005, and continue to grow.³ Payors attempt to control costs by excluding some medicines from coverage, suggesting preferred alternatives, requiring tiered co-payments from patients, or demanding prior authorization. These restrictions are specified in formulary tables.

Both histories and formularies are important data that can be provided to an ePrescribing application. While a physician using ePrescribing may have easy access to the prescriptions she has written, she may not know which of those prescriptions were actually filled. A “dispensing history” can reveal unexpectedly excessive use, or insufficient use, that a “prescribing history” can not. In meta-analysis, the non-adherence rate to medication regimens was 25% on average.⁴ Of course, an electronic history should only supplement – not substitute for – a patient interview. But even the process of obtaining a medication history from the patient leads to inaccuracies and errors.⁵

Physicians face a similar problem with formularies. The relevant formulary table may not be available at the time of prescribing. Even in physician practices using ePrescribing, more than half did not have access to formulary data.⁶

Gopher: Computerized Prescribing System

Clinicians affiliated with Indiana University have been using the “Gopher” system to enter orders since 1984. Previous studies have documented the successes of Gopher order entry on reducing errors⁷ and decreasing costs.⁸

Wishard Health Services is a division of the Marion County Department of Health and provides health care to the economically disadvantaged population of Marion County. Gopher was initially implemented in Wishard clinics and thus was closely linked to the Wishard Pharmacy information system. Gopher allowed physicians to view the list of medications dispensed by the pharmacy. Wishard Pharmacy has a single formulary, and Gopher allowed physicians to see which medications were approved.

Because it was successful in Wishard Clinics, the Gopher application was introduced into other Indiana University Medical Group (IUMG) practices as well. IUMG practices include five sites that, unlike Wishard clinics, treat a mixture of patients with commercial health insurance. Such patients may have no history of dispensing events at Wishard Pharmacy – instead, they may use a chain pharmacy close to home. Likewise, such patients may be restricted by complex commercial formularies.

Thus we sought a process to obtain dispensing histories for patients who received medications from sources other than Wishard pharmacy. Nevertheless, we needed to integrate such commercial histories with the Wishard data, as patients could have medications dispensed from either of these sources. We needed a scalable system, ready to accept data from additional pharmacy sources, if these became available. We also needed to obtain formulary data for patients who were not eligible for Wishard subsidies, but had a medication plan through a commercial payor.

Regenstrief Medication Hub: Implementation

We developed the Regenstrief “Medication Hub” to serve as a central point for pharmacy data flowing into our system from various sources. It aggregates and filters this data, and then provides it to a calling application. (See Figure 1.) Currently it receives data from two sources: Wishard Pharmacy and RxHub; but it is scalable, and can – and will – receive data from additional sources.

Figure 1.

Overview of Medication Hub implementation.

RxHub is a consortium of Pharmacy Benefit Managers (PBMs). It is a key source of commercial drug benefit eligibility and formulary data for over 200 million persons.⁹ RxHub can identify which of its member PBMs has eligibility data and an applicable formulary for these persons. Each PBM publishes multiple formularies, and RxHub makes all of them available in a central location. RxHub is a rich source of dispensing histories as well, because it provides records of medication claims adjudicated by PBMs.

The process begins when a patient arrives for a visit to one of the 16 outpatient clinics using Gopher ePrescribing. As the clinic staff registers the patient’s arrival, an electronic HL7 ADT (Admission Discharge Transfer) message is sent to an INPC (Indiana Network for Patient Care) server port. This ADT message is forwarded to the Medication Hub to trigger the assembly of eligibility and history data.

In a first exchange of communication, the Medication Hub sends an “Eligibility Request” to RxHub’s PRN service interface. This request is transmitted using the 270 message of the Accredited Standards Committee (ASC) X12. This request message must contain four identifiers: patient’s name, date of birth, gender, and zip code. RxHub uses these identifiers to search for the patient among its participating PBMs. RxHub returns an “Eligibility Response” (X12/271 message) to the Medication Hub, indicating whether the patient was recognized by one (or more) PBMs, and if so, which formulary files are applicable for that patient. The formulary files themselves are not part of this interchange; instead, they have been downloaded by our system as a batch on a weekly schedule.

A second exchange of communication immediately follows: Medication Hub sends a “History Request” to RxHub’s PRN interface. This request is transmitted using the NCPDP (National Council for Prescription Drug Programs) Script 8.1 protocol. RxHub returns a “History Response”, with a list of all the medications dispensed for that patient (specifically, the medication claims adjudicated by the PBM).

The Medication Hub sends a simultaneous request to Wishard Pharmacy. This requires only one round of communications to request and receive a medication history. (Wishard Pharmacy only has one formulary; that file is already available to the Gopher system.)

Data from both sources are mapped (see discussion of mapping below) to the local terminology used by the Regenstrief Medical Record System (RMRS), and aggregated into a single list. A configuration file specifies filters that can be applied to modify this list. The Medication Hub then exports this summary as an HL7 message, and sends it to the Gopher system for each patient (who has completed registration at the clinic’s front desk). Thus, when a clinician starts using Gopher to write prescriptions, the medication history is available for viewing and ordering.

Gopher uses the eligibility data to retrieve the appropriate formulary for that patient. When the clinician writes a computerized prescription, Gopher decision support rules check it against the formulary, and display a warning if that prescription is restricted by the formulary.

The Regenstrief Medication Hub went into production in August 2006. We first implemented it as a VMS BASIC application with an HL7 interface, but more recently redesigned it as a Java application with a Web Services interface.

We undertook an evaluation of this system to understand its strengths and weaknesses. We analyzed one month of eligibility and history data flowing into the Medication Hub, as well as the formulary files downloaded weekly from RxHub. We studied two months of Gopher usage. We counted each time that a Gopher user accessed the dispensed history, and prescribed history. We studied formulary warnings generated by Gopher decision support, and user responses. We also surveyed and interviewed 31 clinical users. IRB approval was obtained.

Medication Histories

We analyzed all queries generated by the Medication Hub during the one-month evaluation period. 53,764 HL7 ADT registration messages (each representing a patient visit) were received for 39,080 distinct patients. 74% of patients occurred only once, while 26% of patients occurred in more than one message.

Of the 53,764 queries sent to RxHub, 2555 (5%) obtained a medication history with one or more medications; another 1457 (3%) obtained a history with zero medications (RxHub identifies the patient, but reports no known dispensing events). The same queries were sent to Wishard: 23,421 (44%) obtained a history with one or more medications. There was some overlap: 319 (0.6%) of queries obtained medication histories from both RxHub and Wishard.

The Medication Hub is currently configured to apply two filters: a Date Filter, which excludes any dispensing events older than 13 months; and a Repetitive Results Filter, which reports only the most recent dispensing event for each medication. The maximum number of dispensing events counted for a single patient was 132 (all reported by RxHub). After filtering, this patient’s history contained 48 medications. Most histories contain only a few entries; see histogram, Figure 2. (It is possible that incomplete data may be the reason for histories with only a few entries.)

Figure 2.

Distribution of the counts of medications in histories.

The Gopher system allows the clinician easy access (one keystroke) to the dispensing history provided by the Medication Hub; it also allows equally easy access to the list of all prescriptions written in Gopher. Clinicians can simply view these lists, or can select any of the drugs to create a new or revised prescription. During a two month period, the Gopher system was used for 62,715 prescription-writing sessions (either visits or telephone orders). The dispensing history was reviewed during only 376 (0.6%) of these sessions. The prescribing history was reviewed during 3564 (5.7%) of these sessions.

We surveyed 31 clinicians to understand their use of these Gopher features. All 31 reported that they knew how to use the list of prescribed medications which Gopher provides. However, only 25 knew that there was a list of dispensed medications also. Furthermore, only 17 understood that a source other than Wishard’s pharmacy used in the list of dispensed medications.

Drug Benefit Eligibility and Formulary Data

RxHub responded to all 53,764 of the queries with 53,907 eligibility segments. 4190 of these eligibility segments (7%) carried information from a PBM. 49,717 (93%) reported that RxHub failed to identify the patient. This is not a negative comment on RxHub; rather, it reflects the reality that our clinics serve a disproportionate number of patients without commercial insurance. We attempted to control for this reality by restricting the analysis to five IUMG sites not managed by Wishard Health Services (i.e., treating patients with a mix of commercial and public insurance). In this subset, 1,646 (22%) of 7344 eligibility segments carried information from a PBM.

A few (4%) RxHub responses contained more than one eligibility segment: i.e., the patient was eligible for more than one formulary. 156 responses contained 2 eligibility segments; 9 contained 3 or more. Manual inspection of these records revealed marked differences in employer descriptions. A probable explanation was that some patients have coverage from their own employer, as well as their spouse. Thus our decision support rules needed to accommodate a prescription that is not covered by one of the formularies, but is covered by another.

The number and size of formulary files makes them very cumbersome to work with. In a recent and typical week, 1,826 formulary files were downloaded, representing the Formularies managed by nine PBMs. These files contained a combined total volume of 51,754,810 National Drug Codes (NDCs) which could be grouped into 159,187 distinct NDCs. They were 1.56 GB in size. When first downloaded, they are too large for the Gopher system to import in a timely manner. Therefore, we pre-process the files before sending them to Gopher.

First, the formulary files are mapped to the RMRS Terms which our applications use for indexing. Second, they are compared against the formulary files from the previous weekly update, to extract only those records that have changed. The resulting “delta” files reduce the size of the formulary data by a factor of 3 or 4 (variable, because some formularies change weekly, others change only a few times a year). Finally, Gopher imports the formulary files, and adds the changed records to its own formulary tables, while still keeping them available for clinical use.

When a clinician writes a prescription, the Gopher system compares the prescribed medication against the medications listed in the appropriate formulary. If a drug has any formulary constraints (e.g., maximum quantities, prior authorization, gender or age restrictions), then a warning message is displayed. The clinician can decide whether to continue prescribing the same drug, or to switch to an approved alternative. During a two month period, 429 order sessions (0.7% of all Gopher prescribing sessions) generated a formulary warning, which was displayed to the prescriber. 262 (61%) of warnings were triggered by the Wishard Formulary; 167 (39%) were triggered by two commercial PBMs.

We manually inspected these 429 order sessions, in order to determine how often physicians responded to formulary warnings. We defined a warning to be “overridden” when, at the completion of the order session, the problematic drug was ordered anyway. We defined a warning “heeded” if one or more alerts were generated and, at the completion of the order session, the problematic drug was not ordered. Clinicians heeded 107 (41%) of warnings based on the Wishard Formulary, and 27 (16%) of warnings based on a commercial formulary.

We analyzed each of these warnings in order to understand why the compliance rate was low. We discovered that some over-the-counter medications (e.g., aspirin) were generating off-formulary warnings, since they were not included in formulary files. In addition, not all NDCs in formulary files were being recognized by our mapping tables. Nevertheless, in some cases (e.g., levofloxacin) the clinician appeared to be making a deliberate decision to override an intended formulary restriction.

Mapping NDCs to Local RMRS Terms

A crucial link for the success of this project has been the mapping between NDCs and Regenstrief drug Terms. This mapping has two stages. First, NDCs are translated to Medi-Span Generic Product Identifier codes (GPIs). Regenstrief licenses the Medi-Span drug knowledge base from WoltersKluwer Health, Inc. Second, GPIs are translated to 2283 Regenstrief Terms, relying on a local GPI-Term mapping table created by Regenstrief personnel. Construction of this mapping table was facilitated by simple text string matching, but required thorough manual review of each map entry, because of subtle differences in the representation of doseforms and strength units. This compromise allows us to continue using our local terminology, while we outsource the difficult work of updating NDC mappings.

We undertook to evaluate the success of this mapping strategy. During the one-month evaluation, a total of 19,409 dispensing segments, each carrying an NDC, were received in RxHub histories (3314 distinct NDCs). A total of 150,292 dispensing segments were received from Wishard (1482 distinct NDCs). 94.9% of the RxHub NDC volume was successfully mapped to Regenstrief Terms; 89.2% of distinct codes. The corresponding numbers for Wishard are: 97.3% of NDC volume; 92.4% of distinct codes. Thus the success rate of translating NDCs to Terms is better, when analyzed on the basis of total volume, rather than when analyzed on the basis of distinct NDCs. Total NDC volume may be the more accurate metric, because it assigns greater weight to those medications that physicians commonly prescribe for their patients.

Discussion

We implemented the Regenstrief Medication Hub to aggregate medication history and eligibility data from two sources. This framework is scalable, and can accommodate additional sources. We hope to add a third source shortly: Indiana Medicaid. A possible fourth source is the SureScripts Pharmacy Health Information Exchange; this provides data on drugs sold by pharmacy chains, and includes the cash transactions which PBMs may not be aware of. As we aggregate these complementary sources, we develop a more complete medication profile for each patient.

Researchers at other institutions, such as Partners HealthCare, have also demonstrated the feasibility of an automated solution to support the process of medication reconciliation by collecting medication histories from multiple sources.¹⁰

Correct identification of a patient is a crucial feature of any automated solution that attempts to bring together pharmacy data from different sources, where the same person may be given different identifiers. For example, there is the possibility that the algorithm described above may misidentify two persons with the same name, date of birth, and zip code. Such risk makes it important that the clinician always validate an aggregated medication history with the patient.

In order for a system to be successful, it must present information in a way that is usable by clinicians. For this project, a key design decision was to use Regenstrief Terms, and not NDCs, in order to maintain a clinician-centered perspective. When the Regenstrief order entry system was introduced two decades ago, physicians chose a clinically-oriented local terminology for prescription writing. Even now, we revise or add to this terminology, relying on input and feedback from clinician-users. Thus, when a physician prescribes “oral Amoxicillin”, her prescription is indexed by a single Regenstrief Term. All decision support and database queries depend on this code.

However, both formularies and dispensing histories reflect the reality of pharmacy inventory systems, as they are indexed by NDCs. We believe that NDCs are too granular to use when developing a clinical application. For example, we identified at least 587 different NDCs which represent “oral Amoxicillin” (i.e., capsules or tablets).

Therefore, when displaying the medication history, we decided not to show drugs on the level of individual NDCs. Instead, we display each drug on the level of Regenstrief Terms. Thus several different dispensing events, with several different NDCs, may be grouped together as one record. Likewise, the formulary decision support rules are triggered by Regenstrief Drug Terms. This requires a strategy for converting the NDC-based formularies into Term-based tables, and identifying the correct restriction when a prescription is entered.

As described above, some gaps remain in our mapping process. We anticipate a better result when RxNorm codes enter common use. If we include RxNorm codes with each listed medication, we can use them for sorting the list or for triggering decision support rules. We look forward to receiving dispensing histories from external sources which include RxNorm identifiers, or formularies that specify their restrictions on the level of the RxNorm Clinical Drug Code. Unfortunately, the recent evaluation of initial standards for electronic prescribing determined that RxNorm is not yet able to qualify as a Medicare Part D standard.¹¹

Despite our efforts, clinician usage was lower than expected. Clinicians viewed a medication history rarely, even when it was only a keystroke away. Interviews suggested that we may need to advertise this feature better to our users. Alternatively, clinicians may need to see more (than two) data sources aggregated, with a higher success rate, before they perceive value. The regional health information organization in Massachusetts, MA-SHARE, which is also seeking to provide physicians with medication histories, has also documented barriers to their adoption.¹²