Creating an Enterprise-wide Allergy Repository At Partners HealthCare System

Abstract

A significant fraction of medication errors and preventable adverse drug events are related to drug-allergy interactions (DAIs). Computerized prescribing can help prevent DAIs, but an accurate record of the patient’s allergies is required. At Partners HealthCare System in Boston, the patient’s allergy list is distributed across several applications including computer physician order entry (CPOE), the outpatient medical record, pharmacy applications, and nurse charting applications. Currently, each application has access only to its own allergy data. This paper presents details of a project designed to integrate the various allergy repositories at Partners. We present data documenting that patients have allergy data stored in multiple repositories. We give detail about issues we are encountering such as which applications should participate in the repository, whether “NKA” or “NKDA” should be used to document known absence of allergies, and which personnel should be allowed to enter allergies. The issues described in this paper may well be faced by other initiatives intended to create comprehensive allergy repositories.

INTRODUCTION

The Institute of Medicine has identified a wide chasm between the current quality of health care in the country and what ideal quality could be.^{i ii} The IOM encouraged the use of information technology to close the gap, and specifically pointed to the use of automated decision support to help reduce preventable medication errors.

Drug-allergy interactions are one important cause of adverse drug events and are preventable in cases where the patient had a previous documented allergy to the drug that is prescribed. In a study by Bates, et al.,ⁱⁱⁱ 8% of inpatient medication errors were the result of medication orders for drugs that patients were previously allergic to. In an outpatient study, 13% of adverse drug events found on chart review were due to the patient receiving a medication to which they were known to be allergic.^iv

Automated drug-allergy interaction (DAI) checking embedded within prescribing applications (whether inpatient or outpatient) represent an appealing way to improve care with automation. In one study, the rate of allergy errors decreased by 56% (p=0.009) following the introduction of CPOE with a DAI checking feature.^v A DAI checking function requires the patient’s allergies to be stored in the patient database. A module within a prescribing application takes as input the medication being prescribed and the patient’s allergy list, decides whether an interaction is present, and informs the prescriber about the presence of the interaction before the prescription can be finalized. Even this seemingly straightforward functionality involves addressing such complex issues as medication and allergy terminologies, organization of medications into hierarchical and chemically related groups, categorization of the severity of allergic reactions (e.g., anaphylaxis, rash, hives, etc.), and user interface issues. User interface issues include deciding what data should be required upon allergy documentation, what data in the allergy record should be coded, and what information should be presented to the user on the alert screen.^vi

Partners HealthCare System is a $4B integrated delivery network in Boston, Massachusetts founded in 1994. Partners is comprised of 11 hospitals, including academic medical centers (Brigham and Women’s Hospital [BWH] and Massachusetts General Hospital [MGH]), community and specialty hospitals, and a network of about 1000 owned and affiliated primary care physicians. The clinical information systems at the academic centers -- including the computer physician order entry (CPOE) applications -- are internally developed. Also, the outpatient electronic medical record in widespread use at Partners (known as the Longitudinal Medical Record, or LMR) is internally developed.

The Partners clinical systems are used extensively to manage allergy data. For example, since the inception of BWH CPOE in May of 1993, 195,158 allergy records have been entered on 84,752 patients. Also, in a recent one-month period at the MGH (December 2002), 8345 allergy records were entered into the CPOE application on 4224 patients. At MGH, the top 22 unique allergy types accounted for 6739 (80.7%) of the entries (Table 1). Of the entries at MGH, 4080 were “NKA” and 667 of the entries were “Unknown” (some of the NKA and Unknown entries could later have been changed to true allergies). The most common medication allergies entered were penicillins, sulfa, and codeine.

Table 1.

Frequency table of allergy records entered into MGH CPOE in December 2002 (total =8345)

Allergy	N	% of 8345
NKA	4080	49.0%
Unknown	667	8.0%
Penicillin	663	8.0%
Sulfa	309	3.7%
Codeine	159	1.9%
Morphine	110	1.3%
Erythromycin	92	1.1%
Aspirin	88	1.1%
IV contrast	71	0.8%
Bactrim	70	0.8%
Latex	62	0.7%
NSAIDs	48	0.6%
Amoxicillin	47	0.6%
Cephalosporins	46	0.6%
Demerol	44	0.6%
Heparin	42	0.5%
Ciprofloxacin	33	0.4%
Percocet	33	0.4%
Tetracyclines	30	0.4%
Ativan	23	0.3%
Haldol	22	0.3%

Even though the BWH and MGH CPOE applications and the LMR were internally developed, each of these applications created its own allergy repository with its own structure for various organizational and technical reasons. As a result, a single patient might have allergy data stored in any or all of these applications.

This situation was deemed to be a safety problem from a variety of perspectives. First, it was possible for a patient to have allergy data stored in the outpatient LMR, but the allergy data would be unavailable to either of the CPOE applications if the patient was admitted as an inpatient. Of the 4224 patients who had allergy data entered into MGH CPOE in December 2002, 872 (20.6%) of these also had allergy data in the LMR database. Also, although many patients receive the majority of their care at either BWH or MGH, some patients do move between the institutions with high frequency, usually to seek care from a particular specialist. For example, 228,334 patients in the Partners enterprise master patient index (EMPI) have electronic data that originated from MGH as well as from BWH. This represents 18.40% of 1,241,022 MGH patients and 18.76% of 1,216,972 BWH patients (data as of 1/2/2003). Currently, if a patient has allergy data in the MGH CPOE database and then is admitted to BWH, the MGH allergy data is not available to the BWH CPOE application for display and decision support purposes. Of the 4224 patients who had allergy data entered into MGH CPOE in December 2002, 77 (1.8%) of these also had allergy data in the BWH CPOE database.

A project was initiated at Partners in early 2002 with the following goals:

• - Merge the allergy databases of the clinical applications (e.g., BWH CPOE, MGH CPOE, LMR, etc.) into a single enterprise-wide allergy repository

• - Going forward, have the clinical applications send a new allergy data to the repository so the repository can continue to be an accurate representation of the patient’s allergy list

• - Create a drug-allergy interaction checking service that would use the allergy repository (rather than any single application’s allergy database) as the source of truth for the patient’s allergy list

• - Require any feature that displays the patient’s allergy list to query the repository rather than the database of any single application

The goal of this paper is to outline some of the informatics issues that are being encountered as we pursue the above goals. We expect that future initiatives, whether on a local or national level, that attempt to create comprehensive repositories of patient allergy data will need to address similar issues.

CONCEPTUAL SYSTEM DESIGN

The detailed architecture of the common allergy repository and the manner in which it interacts with the other clinical applications at Partners is the subject of another paper that has been submitted to the proceedings of this conference.^vii Some of the concepts are provided here briefly.

Allergy data storage.

The distinction between the current approach to allergy management and the proposed approach is shown in Figures 1 and 2. As has been mentioned, currently each application creates its own allergy database. The new design calls for each application to send a copy of the allergy data to a common allergy repository. The applications may keep a copy of the allergy data in their local databases, because they may want to store application-specific data that would not make sense to store in a common repository.

Figure 1.

Current application specific architecture for managing allergy data at Partners HealthCare System.

Figure 2.

All applications write to a common allergy database, as well as to their own application-specific databases.

Common services.

Creating a common physical repository for allergies is not sufficient to achieve the goals of the project. Besides creating a common physical repository for allergy data, we also are creating a set of services to ensure that allergy data are treated consistently. The services we have created are:

• - Allergy lookup terminology services. This assures that selecting an allergy is done consistently across all applications.

• - Allergy filing service. This allows applications to file allergies to the common repository in a consistent manner.

• - Retrieve allergy list. Since no single application will have the complete list of patient allergies, a service has been created to retrieve these from the repository.

• - Drug-allergy interaction checking. Although not part of the repository per se, we have created a single drug-allergy interaction (DAI) checking service so that this feature behaves consistently across the applications. Although we use a vendor-supplied knowledge base of hierarchical groupings of ingredients and cross-sensitivity checking, we have customized this knowledge and want to assure that the customization is applied consistently across all clinical applications. The DAI checking service takes as input the current allergy list and a new medication and returns true (a drug-allergy alert is present) or false.

High level project plan.

To achieve the project goals, each application will be required to:

• - Embed the common allergy filer so that new allergies are posted to the common repository (in addition to its own application-specific database),

• - Replace their current drug-allergy interaction checking function with the common service, and

• - Implement the common allergy list retrieval service anywhere the complete list of patient allergies is required (e.g., if the application wishes to display the patient’s complete allergy list)

• - Make minor changes to the way an allergy is selected.

Also, to seed the repository, the application-specific allergy databases will be merged into a single allergy repository.

REFINING REQUIREMENTS

The project began in June 2002. As we have proceeded with the project, the high level goals have remained the same. However, we have had to address several important details that we did not appreciate at the start of the project. We discuss here some of the more important issues that have arisen.

Choice of participating applications.

When we began the project, the goal was to merge data from the inpatient and outpatient settings, specifically from MGH CPOE, BWH CPOE, and the LMR. It was quickly brought to our attention that other applications capture and use allergy data and should be part of the scheme. Currently, there are 11 participating applications including nurse charting, pharmacy applications, and non-LMR electronic medical record systems in use at Partners. Each participating application brings with it detailed requirements, so the project management effort has increased with the number of applications.

Consistent use of NKA and NKDA.

The concept representing known absence of allergies currently is used inconsistently across the applications. BWH CPOE allows the physician to document in coded form that the patient is “NKDA” representing “no known drug allergies”. MGH CPOE allows the physician to document that the patient is “NKA”, i.e., has “no known allergies”. The LMR allows the documentation of either, and also allows the concept “allergies unknown” to be documented. The use of a common repository dictates that these concepts must be used consistently across the participating applications. Much more than a technical discussion, this involved a clinical discussion about the use of these terms and proper allergy documentation procedures. The decision has been to promote only the use of the concept “no known allergies of any kind”. Patients who currently are documented as “NKDA” will remain as such, but no new such designations will be permitted. Interestingly, there was no single medical management committee at Partners who could make this decision. Consensus had to be reached with the BWH Drug Safety Committee, the MGH CPOE Committee, the LMR Leaders Group, and the Chemotherapy Drug Safety Committee. Medical informatics staff played a central role in obtaining consensus.

Who is authorized to enter allergies.

Currently, each application has policies for who is allowed to enter data. Thus, currently, each application is able to dictate who is authorized to enter/edit allergy data. For example, only clinicians with ordering privileges are currently allowed to enter/edit allergy data within CPOE, whereas doctors, nurses, and medical assistants can enter information into LMR. Going forward, anyone with authorization to any application that manipulates allergy data will be able to enter/edit data in the allergy repository. For example, in the future, a drug-allergy alert in CPOE might be triggered by an allergy that was entered by a medical assistant into the LMR.

There was concern on the part of some members of the application steering group that the policies of some applications regarding who is allowed to enter allergies might be too lenient. Specifically, to facilitate workflow, many outpatient practices authorize medical assistants to document allergy (and other) data. The CPOE applications (which currently can have allergy data entered only by physicians, nurses and pharmacists) were concerned that the quality control of the allergy data entered by the medical assistants might be poor. There was much discussion on this point. Eventually, every application agreed to “trust” every other application, recognizing that the benefit of having complete history data would be greater than the risk of having bad data potentially entered. In addition, allergy entry competencies will be designed for outpatient areas.

Notification of new allergies.

Some of the applications have specific workflow that occurs when new allergy data are entered. For example, when a new allergy is entered into CPOE, nurses and pharmacists are informed via specific functionality that relates to orders. In the case when a new allergy is entered in another application (e.g. the LMR) while a patient is hospitalized, there is no automatic mechanism that notifies the inpatient nurses and pharmacists that a new allergy has been posted to the common repository.

This situation could be remedied by creating software in CPOE that would identify when new allergies are posted to the repository and then communicate the information to nurses and pharmacists. The only proviso is that the CPOE communication methods are designed to work on “orders”, so the new allergy information entered via the LMR would need to be cast as an order.

CPOE is the only application that includes such notification methods, and the relevant scenario (i.e., that an allergy is entered into LMR while the patient is an inpatient) occurs very rarely, so we have not built software to address this scenario.

Applications need to keep local databases.

We spent much time discussing whether applications need to continue to keep application-specific allergy databases. For the time being, we have decided to keep the allergy records in the databases of the local clinical applications as well, because they may want to preserve functionality that treats allergy data as a local data type. For example, allergies entered via CPOE may need to be dis played in a “session” along with other “orders” entered in that session.

Legacy database issues.

The various application-specific allergy databases will need to be merged into the common repository. The Partners EMPI identifier will be used to identify patients in the various applications, and all the applications use the same allergy identifiers so the integration is relatively straightforward. The situation might exist however, where a patient has different allergies in the different applications. This gets to be tricky if the patient is documented as being allergic to “ampicillin” in one application and “nafcillin” in another. It would not make clinical sense to store 2 different allergies, and they would be grouped. Also, in different applications, the patient might have different reactions to the same allergen. For example, the patient might have a reaction of “hives” to penicillin in one application, and a reaction of “rash” to penicillin in another. In this case, both reactions will be stored with the allergen.

Allergy as orders.

In the CPOE applications, allergies are stored as orders. This is a carryover from the paper-based world where physicians document allergies in the order sheets. The Partners CPOE applications were conceived with allergies as an “order” data type. It probably would be more correct to store allergies primarily as a documentation item. Over time, we may evolve the model of allergies in CPOE to be documentation items.

LESSONS LEARNED

Allergies represent only one of myriad data types in the electronic clinical record; however, allergies play a central role in patient safety. Having a comprehensive database of patient allergies is a critical requirement for a health care institution that wishes to deliver high quality care. Appropriate attention to the identifiers and data structures of medications and allergies in the various clinical information systems with an eye towards a comprehensive allergy record will minimize the amount of rework later on. Our experience with NKA and NKDA has taught us that even what seems like the simplest difference can require extensive analysis and deliberation to resolve. In contrast, the fact that we have consistent patient, allergy, and medication identifiers across applications has greatly simplified our task.

Also, today, allergies are stored in clinical systems primarily as application-specific transactions (e.g., orders, records in a charting application, etc.). The ubiquitous nature of allergies dictates that they have a structure independent of any transactional application that is used to capture them. Applications may choose to keep an application-specific copy of the allergy record to serve local needs.

Also, the ubiquity of allergy documentation and the need to have a comprehensive repository demands that institutional policy regarding who can enter allergy data should not be intimately linked with one or another clinical application. Rather, authorization to enter allergy data should be made as a medical management decision and applied secondarily to clinical applications.