|Home | About | Journals | Submit | Contact Us | Français|
Confusion about patients’ medication regimens during the hospital admission and discharge process accounts for many preventable and serious medication errors. Many organizations have begun to redesign their clinical processes to address this patient safety concern. Partners HealthCare, an integrated delivery network in Boston, Massachusetts, has answered this interdisciplinary challenge by leveraging its multiple outpatient electronic medical records (EMR) and inpatient computerized provider order entry (CPOE) systems to facilitate the process of medication reconciliation. This manuscript describes the design of a novel application and the associated services that aggregate medication data from EMR and CPOE systems so that clinicians can efficiently generate an accurate pre-admission medication list. Information collected with the use of this application subsequently supports the writing of admission and discharge orders by physicians, performance of admission assessment by nurses, and reconciliation of inpatient orders by pharmacists. Results from early pilot testing suggest that this new medication reconciliation process is well accepted by clinicians and has significant potential to prevent medication errors during transitions of care.
Hospital admissions and discharges are complex events, characterized by multiple handoffs among health care providers and numerous changes to the patients’ therapeutic plan. The intended medication regimen before, during, and after the hospital stay often becomes a point of confusion for patients and clinicians during care transition points across the hospital and outpatient settings. Much of this confusion is fueled by multiple changes to medication regimens, 2 discontinuity of care, 3 short hospitalizations, and inadequate patient education. 4,5 Recent research strongly suggests that such confusion is a major cause of medication errors and adverse drug events (ADEs). 6–12 A recent systematic review on errors on medication history at admission estimated that 54–67% of all admitted patients have at least one discrepancy between the medication history obtained by the admitting clinicians and the actual pre-admission regimen and that, in 27–59% of those cases, such discrepancies have the potential to cause harm. 13–15 A study of hospitalization-related ADEs also found that medication discrepancies were the most common drug-related problems at the time of discharge and the cause of half of all preventable adverse drug events 30 days after discharge. 16 These discrepancies represent an important target for patient safety interventions.
In response to this patient safety concern, the Joint Commission for Accreditation of Healthcare Organizations (JCAHO) mandated, with full implementation in 2006, the development of a process to “accurately and completely reconcile medications across the continuum of care.” 17 The challenges associated with building a robust medication reconciliation process are daunting, as providers would need to piece together an accurate medication history using information from multiple sources, including the patient, her/his caregiver, primary care physician, medical specialists, outpatient medical records, hospital discharge summaries, and community pharmacies. In addition, each of the major disciplines involved, including physicians, nurses, and pharmacists, typically uses separate tools and protocols for obtaining the medication history from the patient. This uncoordinated set of activities often leads to either unnecessary redundancy (e.g., patients being interviewed about their medication multiple times during the first few hours of admission), or missed opportunities for collaboration (e.g., the inpatient pharmacist not knowing the home medication regimen as she or he approves the admission medication orders). In response to these challenges and the new regulatory requirements, many institutions have developed formal processes for medication reconciliation. However, while there are isolated examples of successful paper-based efforts, 9,18,19 adoption has been slow, and the best ways to implement medication reconciliation remain unclear. In addition, acute-care institutions that have implemented computerized physician order entry (CPOE) face even greater challenges as the CPOE system may not support the iterative steps involved in documenting the pre-admission medication list or multi-disciplinary communication around the medication reconciliation process.
At Partners HealthCare in Boston, Massachusetts, a multidisciplinary team of clinicians and information-technology professionals decided in early 2005 to tackle these challenges by developing an information technology (IT)-supported process of medication reconciliation for patients admitted to and discharged from its two major academic medical centers. This manuscript discusses the process, workflow, and informatics challenges we encountered and our approaches to addressing these challenges. We will also present the design of our solution and discuss the results of early piloting efforts.
Partners HealthCare was formed in 1994 through the financial merger between the Massachusetts General Hospital (MGH) and Brigham and Women’s Hospital (BWH). Since its initial inception, the integrated delivery network has grown to include three community hospitals, four rehabilitation and long-term care facilities, and a large network of primary care and specialty physicians. Our master patient index now contains 3.5 million patients. Institutions within Partners HealthCare currently support approximately 160,000 medical, surgical, and obstetrical admissions per year and 4 million outpatient visits. The two academic medical centers have fully implemented computerized physician order entry (CPOE) for more than 5 years, with essentially all orders at both institutions entered by the ordering clinician using separate and internally developed CPOE systems. Other community hospitals have either fully adopted or are in the process of adopting CPOE using vendor-based systems. In addition, Partners HealthCare has internally developed a full-featured electronic medical record (EMR), called the Longitudinal Medical Record (LMR), for use in the outpatient setting in 60 primary care and 59 specialty practices across the network. As with most EMRs, the LMR allows physicians to maintain a medication list for each patient and to generate prescriptions. At MGH, an additional electronic medical record, On-Call, with similar capabilities for electronic prescribing, was constructed before the Partners HealthCare was formed and continues to be fully used by six practices at MGH. Inpatient documentation (beyond order entry) at both institutions, including the documentation of medication history, was largely paper-based before the start of this project.
Spurred by the JCAHO mandate and a number of sentinel events caused by medication discrepancies around the time of discharge, the enterprise-wide leaders in patient safety at Partners HealthCare began in the summer of 2004 to investigate ways to support the clinical processes associated with medication reconciliation throughout the enterprise. At the same time, as both MGH and BWH faced the January 2006 compliance deadline with the JCAHO mandate, each had set up a task force to examine its existing medication reconciliation processes, identify gaps, and learn from other institutions tackling the same issues. Leaders at the enterprise and site levels all saw the extensive IT infrastructure and rich sources of clinical data at Partners as an opportunity to improve the efficiency of the information-intensive and time-consuming activities involved in medication reconciliation. With a sense of urgency, Partners HealthCare launched, in February 2005, an enterprise-wide project to leverage IT to support medication reconciliation. Based on the review of the literature and sentinel events, the project team, in conjunction with its sponsors, decided to focus first on the transitions during inpatient admission and discharge.
The project involved many stakeholders, with whom the core project team of informaticians and software developers needed to interact regularly to ensure that the deliverable would support the workflow and data needs for diverse groups of clinicians. In addition, while the project was sponsored by an enterprise-wide patient safety program, the design and implementation effort had to be coordinated with the patient safety, inpatient CPOE and outpatient EMR teams at each of the two teaching institutions. To facilitate consensus-building, manage expectations, and coordinate resources among the stakeholder groups, we formed a working group comprised of informaticians, patient safety officers and clinicians to represent stakeholders at the enterprise and site levels. This group met biweekly to shape the ongoing design and development work executed by the project team. The working group was in turn overseen by a steering committee of patient safety and information systems leaders that set overall direction for the project, managed scope, and arbitrated disagreements across stakeholder groups.
One of the first tasks for the project team was to fully describe the process of medication reconciliation. While there was widespread consensus that medications needed to be reconciled when patients moved from one setting to another, the lines of responsibility across the clinical disciplines were blurry and best practices remained to be fully defined. Fortunately, the project team had several resources to draw on. First, several national organizations, including JCAHO (www.jcaho.org) and the Massachusetts Coalition for the Prevention of Medical Errors (www.macoalition.org), had begun to outline the key principles involved in building a robust medication reconciliation process. Second, one of the two academic medical centers had already conducted small-scale paper pilots to understand the challenges of implementing medication reconciliation in a CPOE environment. Using these resources, the project team drafted a generic medication reconciliation process without regard to the roles assigned to the various tasks, as outlined in . This process during inpatient admission consists of i) gathering information from multiple sources on patients’ pre-admission medication regimens; ii) verifying this regimen against trustworthy information sources; iii) recording the verified information and updating it if new information emerges; iv) deciding whether each medication on the regimen should be continued upon admission, and if so, whether the dosage or frequency needs to be changed; and v) generating appropriate inpatient orders. During patient discharge, clinicians need to i) compare the current inpatient medication list with the verified pre-admission medication list to generate the appropriate discharge orders; and ii) highlight and explain to patients (and/or their caretakers at the next phase of care) how the discharge orders differ from the pre-admission outpatient medication list.
Having reached consensus among stakeholders that captured the major tasks associated with medication reconciliation, the project team focused on defining the first set of deliverables that would facilitate and add value to the process of medication reconciliation. Using , we identified the pre-admission medication list (PAML) as the lynchpin of the medication reconciliation process, since information on this list informs several decision-making points during patient admission and discharge. 1 Historically, the PAML had been collected on paper at various points of the patient’s hospitalization, most notably in the physicians’ admission history and physical and on the nurses’ admission assessment. However, our paper pilot revealed that even when the PAML was completed accurately on paper, the information was often not fully utilized at major decision points, including i) during patient admission, when nurses performed the admission assessment and when pharmacists reviewed the admission orders; and ii) at patient discharge, as the paper-based PAML often was not readily accessible when physicians wrote admission and discharge orders on CPOE systems. The project team realized that supporting the consistent construction of the PAML and making it available during critical points in the workflow of physicians, nurses, and pharmacists would significantly facilitate the process of medication reconciliation. In order to facilitate PAML creation, we looked to sources of electronic medication data that were readily available within our existing IT infrastructure. We first looked to the significant number of patients admitted to the two academic medical centers who were seen in the outpatient setting by physicians who used one of the two EMRs (LMR and OnCall), each of which allowed clinicians to maintain electronic outpatient medication lists. In addition, a significant number of patients admitted to our two academic medical centers had previous hospitalizations, at the end of which they had their discharge medication lists documented in electronic format in the discharge modules of the CPOE systems. While we recognized that none of these information sources was completely reliable, the presentation of these data sources to the clinicians could greatly facilitate the creation of the PAML by supporting medication history-taking. Furthermore, if these data sources did not agree with one another or conflicted with the medication history offered by the patient (or family), the discrepancy itself might prompt the clinicians to conduct further investigations, e.g., by asking the family to bring in the medication bottles or by calling the local pharmacy. Because of the tight time-line of the project and the complexities involved with sharing data with external entities, we deferred the use of pharmacy and claims data to a later phase in the project. With these high-level goals in mind, the core project team designed and constructed an IT solution to meet these goals. We will first present the solution we delivered and discuss how it is used. We will then discuss several informatics challenges the team encountered and our approaches for addressing them in the near and long term.
Our first set of project goals focused on the design and construction of i) a user interface to facilitate the building of the PAML, called the PAML Builder; ii) a repository for storing information collected through the PAML Builder; iii) services to mediate access to the repository; and iv) a relational data-mart to support the analytical and reporting needs of this project.
After iterative rounds of design, construction, usability testing, and functional testing, we released our first solution set in November 2005.
Our clinical leaders determined that, in most cases, the admitting clinician—often a member of the housestaff but perhaps a nurse practitioner or a physician assistant—would be primarily responsible for the construction of the PAML for each patient. To facilitate this process, the PAML Builder was designed as a browser-based application so that it could be invoked by the admitting clinician from multiple points in his or her workflow during the patient’s admission process. For example, the PAML Builder can be invoked i) as a stand-alone application on the Windows Desktop before the clinician has invoked the CPOE application; or ii) as an application embedded within the CPOE application while the clinician is writing, reviewing or renewing orders. illustrates two examples of how the PAML Builder can be invoked.
A and B illustrate the appearance of the PAML Builder for a sample patient. The application is organized into three columns. The left column contains the ‘medication source list’ (MSL), which lists medication information from multiple data sources that may inform the user about what the patient was taking before admission. The middle column contains action buttons that allow the user to use information on the MSL to build the PAML, and the right column houses the PAML for the patient.
The medication source list (MSL), labeled ‘Meds from Electronic Sources,’ aggregates medication information that resides in four electronic sources: the current medication lists from the two outpatient EMRs and the most recent discharge medication orders stored within the two CPOE systems. Each medication is tagged with the date at which the data were last updated. For medications on the outpatient medication lists, that date corresponds to the date the medication was last reviewed by a physician or the date the last prescription was generated; for medications on discharge orders, that date corresponds to the date of the patient’s previous discharge.
Since the four medication sources may contain repetitive information, we organize the list to facilitate review by the user. However, the different medication terminology systems used by each data source make this organization challenging. As a first step toward displaying information from multiple non-interoperable sources, we use empirically developed text-based heuristics to attempt to group medications together by the generic name. This grouping is accomplished, where possible, by first mapping each medication back to its generic name using its native medication dictionary. We then strip certain strings off the name of each medication so that only the principal ingredient of the medication (the ‘core’ generic name) remains. Last, all the medications from the four sources are sorted by their corresponding ‘core’ generic names and medications with common ‘core’ generic names are listed together under the same generic name. For example, prescriptions for ‘Zestril,’ ‘Prinivil,’ and ‘lisinopril HCl’ from different sources are listed together under the generic name ‘lisinopril.’ We recognized early during the project that heuristic matching of the ‘core’ generic names might occasionally cause medications to be misgrouped. We employed three approaches to mitigate this risk. First, we made the explicit decision not to hide medication entries even if they were grouped under the same ‘core’ generic name, so that clinicians could still decide whether all the medications listed under each group referred to the same medication the patient had actually been taking in the outpatient setting or represented separate medication orders. For example, a diabetic patient with the two entries ‘NPH insulin 40u SC qam’ and ‘NPH insulin 20u SC qhs’ from the outpatient EMR would have both entries grouped under ‘NPH insulin’ on the MSL, but because both entries would be visible in the MSL, clinicians would be prompted to consider both entries as active entries. Second, we recruited clinicians to review matched medication lists on 100 real patients to ensure that our matching algorithm would not cause any confusion. Third, on-site trainers monitored the use of the MSL closely during our pilots. To accommodate the usual workflow of medication history-taking, we encourage the users of the PAML Builder to print the MSL before they start interviewing the patient and to use the MSL as a starting point to collect medication history from the patient. The application also allows users to review outpatient progress notes and discharge summaries of the patient, as users may want to understand the rationale behind the medication regimen or to uncover medications that are not included on the MSL.
Once the clinician responsible for building the PAML has collected the necessary information, she or he can use the application to do so electronically. If a medication a patient has been taking before admission appears on the MSL, the responsible clinician has two ways to build the corresponding entry on the PAML. If no changes in dose, strength/form, and frequency are necessary, the clinician moves the medication from MSL into the PAML without changes. If changes are required, the user specifies that an entry from the MSL should be moved to the PAML with modifications, and the user interface then prompts the user to enter the appropriate dose and frequency for the medication. If a medication a patient has been taking does not appear on the MSL, the user can build an entry on the PAML de novo by specifying the medication name, route, dose, and frequency of the medication. Since the dose and frequency information may not be available when the user is building the PAML, the dose and frequency fields are not mandatory. In addition, since some patients may only be able to describe the medication by color, shape, or indication, we allow users to specify the name of the medication in free-text and update the PAML later when the medication is fully identified. The time when the patient last took the medication can also be optionally recorded.
To facilitate interdisciplinary communication among physicians, nurses and pharmacists, the intent of the admitting physician to continue or discontinue a medication upon admission can be easily recorded on the PAML. Any entry on the PAML can be marked as i) ‘continue at pre-admission dose and frequency’; ii) continue at different dose and frequency’; iii) ‘discontinue’; iv) ‘substitute with different medication’. In addition, if the admitting clinician suspects patient non-adherence before admission for a particular medication or if the medication has been temporarily held before admission, a notation can be made under the ‘medication details’ column. If the admitting clinician is unsure about the accuracy of a particular entry on the PAML (e.g., if the patient can only identify a pill by color or is unsure of its dose), the entry can be marked as ‘need to clarify.’
Information for each entry on the PAML can be changed or deleted by any clinician with access to the application (with an audit trail of all changes permanently stored in the PAML repository). For example, if new information about a patient’s outpatient regimen emerges after the initial attempt at building the PAML, the responsible clinician can update the information in the PAML. Once changes to the PAML are saved, the information becomes available to other clinicians who need that information for the medication reconciliation process. The application also allows the user to save a PAML as ‘in progress’ until she or he decides it is ready for review by other clinical disciplines, at which point the clinician will save the PAML as ‘ready for review.’
After completing the PAML, the admitting clinician uses the information to construct the admission medication orders using the local CPOE system. Depending on the design of the order-entry screens, the CPOE application displays the PAML as a static list to facilitate decision making (). The PAML Builder application can be summoned on demand if information on the PAML needs to be modified.
We heard early during the requirement gathering process that clinicians wanted to turn entries in the PAML into admission orders ‘with a click.’ We held off supporting this feature during the first phase of the project for several reasons. First, colleagues around the country who had allowed physicians to turn entries on the paper-based PAMLs into inpatient orders uncovered several issues with this potentially time-saving strategy. For example, they found that physicians would make direct annotations to the paper-based PAML after the initial set of orders were processed, leading to ambiguity as to the actual active orders. We therefore decided that it would be important to use the pilot process to increase understanding of the timing and frequency of changes being made to the electronic PAML before we used the PAML to create inpatient medication orders. Second, recent literature on the unintended consequences of information technology 20,21 suggests that workflow automation may introduce opportunities for new errors if the technology makes it easy for its users to bypass the necessary safety checks. Therefore, our clinical leaders did not want to over-automate the process of medication ordering using the PAML without first understanding how users would use the PAML Builder application. Third, turning outpatient medication entries encoded with different medication terminologies and non-interoperable information models (for orders and prescriptions in terms of dose, strength, frequency, and instructions) into inpatient orders would require a robust normalization and mapping approach. At the time of this project, the infrastructure to support this normalization and mapping was only in its infancy. Given these issues, the project team deferred the on-demand automatic transformation of outpatient medication entries into full-fledged inpatient medication orders to a later project phase.
At the time of patient discharge, both CPOE systems at the two academic medical centers support a discharge module that allows users to create the discharge medication orders using the active inpatient medication list. With the use of the PAML Builder application, the PAML can be juxtaposed with the active inpatient medication list at the time of patient discharge so that both lists can be considered in the writing of discharge orders ().
Robust medication reconciliation processes at admission and discharge require collaboration across different clinical disciplines. , , and are cross-functional flowcharts (‘swim lane diagrams’) that depict how our solution set can be used by physicians, nurses and pharmacists to achieve that goal.
depicts how clinicians use these tools during the admission process for patients admitted through the emergency room to the inpatient medical services. illustrates how clinicians may use the PAML Builder application to handle elective surgical patients who are evaluated days to weeks before the admission and are then admitted formally by the surgical housestaff after the surgery has been completed. describes how the discharging physician and nurse use the information collected through the PAML Builder to ensure that the patient is discharged on the appropriate medication regimen. All 3 figures illustrate how the various clinical disciplines contribute to the process of medication reconciliation and how the PAML Builder application facilitates communication and information sharing across clinical disciplines.
The PAML Builder application was piloted at both academic medical centers in several rounds between December 2005 and April 2006. During each round of piloting, a single patient care floor was selected by local clinical leaders to pilot for 10–14 days the use of the PAML Builder in the admission and discharge processes for all patients admitted to that unit. Each of these pilots involved different clinical areas (two general medicine, one cardiology, one general surgery and one orthopedics unit) so that the role of the PAML Builder across different types of workflow could be validated. All housestaff, nurses, and pharmacists participating in the pilots were offered training in the use of the PAML Builder application before the pilot. IT analysts provided on-site support, and clinical leaders conducted post-pilot focus groups with the staff to encourage feedback about any flaws in either software or workflow implementation.
Forty-one physicians, 310 nurses, and 75 pharmacists participated in the pilots. Of the 216 patients admitted to the pilot teams, 166 of them (78%) had a PAML created from the PAML Builder application. The 166 PAMLs contained 1316 medications, of which 853 (65%) were transferred to PAML from the MSL and 463 (35%) were added de novo. The MSLs of all patients in the pilots contained 2816 medication records, of which 1687 (60%) were pulled from the outpatient electronic health record systems (LMR and OnCall) and 1128 (40%) from the discharge medication orders in the inpatient CPOE systems. Of the 853 medications transferred to the PAML from the MSL, 471 (56%) were from the outpatient electronic health records and 372 (44%) from the inpatient discharge orders.
Clinical leaders and project members also conducted feedback sessions with clinicians who participated in the pilot. IT staff members who were responsible for training clinicians also collected feedback on-site. Overall, about 25 housestaff and 50 nurses participated in various feedback sessions, which revealed that most users found the interface intuitive and many were able to use it without any training. Clinicians found electronic juxtaposition of the PAML with admission and or discharge order screens helpful and anecdotally reported that the new system has helped avert several medication errors. Some clinicians found it so useful that they felt uncomfortable when moving to a floor that did not have the PAML available. However, users remarked on the incompleteness and/or inaccuracy of medication lists in the outpatient EMRs, which often required the users to enter the medication information manually into the PAML rather than transferring an entry from the MSL to the PAML with a single click of the mouse. In addition, users wanted to minimize rework and strongly expressed the desire (as expected) to transfer medication entries in the PAML into orders in the CPOE system. These comments have shaped the future development plans for the PAML application, including the extension of medication reconciliation efforts to the outpatient setting so that the medication list in the outpatient electronic medical record is kept as up-to-date as possible.
Based on the feedback from users and clinical leaders at both institutions, the steering committee decided to proceed with the floor-by-floor rollouts of the PAML Builder in the spring and summer of 2006. Studies to evaluate the impact of this application on medication errors and to draw lessons learned from the large-scale rollout are currently underway.
The pilots were a very valuable tool in assessing both the new application and its effect on clinical workflow. They have clearly demonstrated the potential of an IT-based solution for medication reconciliation: two-thirds of the medication records on the pilot patients’ PAMLs were transferred from other electronic health record systems—both in- and outpatient. This result was possible only because of the close integration of the PAML Builder with multiple electronic medical record systems. Our pilot also revealed that in spite of different workflow across clinical disciplines, the pre-admission medication list is an appropriate focal point for medication reconciliation efforts, and our findings validate our efforts to build an application to facilitate the building of this list.
However, the pilots also clearly demonstrated that IT was but one component of the medication reconciliation solution. Support from clinical leadership played a crucial role in the adoption of the new application. We found that many of the patients who did not have a PAML created were cared for by clinicians who had not heard the mandate from their clinical leaders to use the PAML Builder to document patients’ pre-admission regimen. Even though these clinicians were prompted by the CPOE system to build a PAML and the interface itself was sufficiently intuitive to allow them to do it without being trained, the computer prompts were ignored in these cases. In subsequent rollouts, we took care to ensure a comprehensive outreach to potential users of the application to minimize the “delinquency” rates.
Despite the apparent simplicity of the PAML Builder application, we encountered three significant informatics challenges during the development of our solution. We will discuss three of these major challenges, and present our approaches for addressing them.
The major clinical applications at Partners HealthCare have evolved over time to support the workflow preferences of their own user bases. While the different development teams have learned from one another over time, the inpatient CPOE and outpatient EMR applications within Partners have often taken divergent paths in user interface design, data presentation, terminologies, workflow management, and decision support. In addition, as software technology has evolved, these applications have been built on different platforms. Furthermore, with the exception of a common repository for medication allergies 22 and clinical testing data, 23 data for individual applications (including medication identifiers and orders) have been stored in separate databases, often using non-interoperable and internally-developed terminologies and data models. Early in the project, the team saw the common need to address medication reconciliation across the enterprise as an opportunity to prevent the unnecessary divergence of data models, terminologies, and data repositories. However, clinicians at the various sites had significant concerns that a monolithic application might not support the unique workflow needs of the various clinical disciplines in different institutions.
Challenge 1 reflects the complexity of integrating legacy software systems at Partners, a commonplace challenge for the IT word at large. 24 To address this challenge, our organization is adopting the principles of service-oriented architecture to deal with the problems of complexity, non-reusable programming, and lack of system interoperability, 24 and the medication reconciliation project closely follow these principles. For example, our project team decided early on that its deliverables would include a set of services in addition to an application to support medication reconciliation. Specifically, we decided to build a common data repository to store PAML information on patients and to provide common services to allow the various applications within Partners to access data in this common repository. This approach allowed the development teams at the two academic medical centers to utilize, at their own pace, a set of common resources that only needed to be developed once. This approach also conferred maximal flexibility to the individual CPOE development teams in terms of workflow, as illustrated by . While both institutions finally used the browser application that the project team built, its use was not a requirement, and other institutions within our integrated network will be free to develop their own user interfaces in the future if those sites have workflow and data display requirements that cannot be supported by the common PAML Builder application. Those sites that choose to build their own user interface can still use the set of services we have built for the entire enterprise, so that all sites can benefit from the ability to review data sources stored across the same set of applications.
To our knowledge, we are one of the first few institutions to embark on an effort to use HIT to address medication reconciliation across different CPOE environments. Moreover, best practices for reconciling medications in the hospital setting were only beginning to emerge 25 when we embarked on the project. As a result, we had to “learn on the go” during the project.
Several strategies mitigated the risks associated with exploring this novel informatics area. First, the IT project team worked closely with the clinicians as the latter group defined the best practices and workflow for reconciling medications. Second, in designing the user interface of the PAML Builder application, we iterated through a series of low- and high-fidelity prototypes. We held biweekly meetings with clinical representatives from our stakeholder institutions and used those meetings to solicit feedback on the prototypes to ensure that the user interface would be as intuitive as possible. Third, we subjected our design to a critical review by usability experts within our organization, leading to further simplification and increased the visual appeal of the user interface. Fourth, we avoided the pitfall of ‘over-anticipation’ when the requirements from the users were unclear. For example, since the various clinical disciplines had trouble anticipating the communication patterns that would ensue if nurses or pharmacists discovered errors on the PAML built by the admitting physician, we elected not to design a new messaging mechanism within the first release of the PAML Builder application and impose it on our users. Instead, we will use the pilots to understand communication patterns, help the various disciplines arrive at the best communication practices, model these practices, and then support the best practices with future enhancements to our application and services. These enhancements might include allowing role-based editing rights within the application, automatic messaging of the responsible clinicians when changes to the PAML are made, and transparency to the audit trails showing what changes have taken place and when and by whom.
When the four applications that housed the outpatient medication lists (i.e., EMRs) and discharge orders (i.e., CPOE systems) were built, standardized vocabularies for orderable medications were not available. As a result, three of the applications (BWH CPOE, MGH CPOE, and LMR) used a common medication terminology initially developed for the CPOE system at BWH in the early 1990s, while one of the applications, OnCall, used another medication terminology based on the legacy EMR COSTAR. 26 As our pilot has indicated, it will be desirable in the future to incorporate additional data sources in the MSL, such as medication dispensing data collected by retail pharmacies. The presence of different medication terminologies is inevitable, and our team needed to develop short-term and long-term strategies to address this challenge.
Before embarking on the construction of the enterprise wide repository to store PAMLs built using the PAML Builder, we recognized the need to describe the information model that would support the needs of the repository. The information model delineates the types of facts that are to be tracked in the repository and expresses the semantics behind them. Using the Object-Role Modeling (ORM) method 27 an informatician analyzed the requirements of the medication reconciliation process and designed the information model for the repository ().
For the first phase of the project, we had no robust way to map the medication data stored in different data sources and terminologies against a reference medication terminology or normalized order structure. Therefore, we adopted a permissive but extensible data strategy for storing medication entries in the PAML repository. In other words, as medication entries in the MSL were transferred to the PAML by the user, we stored the PAML entry using the terminology native to the source application.
As part of our ongoing work to migrate Partners-centric terminologies toward universally accepted data standards, we have embarked on an extensive data-mapping effort for medication terminologies currently used at Partners. Specifically, we are building a set of mapping services called the Medication Mapping and Interchange Data Layer (MMIDL) that will allow our pharmacy informaticians to map medications stored in Partners-built applications to a common, externally maintained medication terminology. Once the MMIDL effort is complete, subsequent versions of the PAML Builder and its associated services will be able to offer its users additional features. First, rather than grouping medications on the MSL using the text-based sorting approach described above, we will be able to group medications by their therapeutic classes and active ingredients. Second, we will be able to perform meaningful comparisons between medication information on different lists. For example, clinicians responsible for writing discharge orders will be able to ask for a comparison between medications on the active inpatient medication list and those on the PAML, so that the user can be alerted to medications that the patient took before hospitalization but that were discontinued during the hospital stay (e.g., because the outpatient medication was not on the hospital formulary). Perhaps most important, this ability to generate a ‘difference report’ between two medication lists will allow the discharge summary to contain an explicit report of how the discharge medications are different from those taken before admission.
Beyond comparing just the medications from various medication lists, it will be clinically useful to compare the details of each prescription from different lists. Such features in the medication reconciliation solution set will be feasible once the industry has agreed on a standard for the Standardized Common SIG format, 28 which will fully describe a common and interoperable information model for each prescription. At that point we will be able to normalize all elements of orders and prescriptions stored in the PAML repository, allowing us to detect changes in the frequency, dose, or formulation as the patient’s regimen changes across different care settings.
We have built a novel application and set of services to support the information needs of clinicians as they reconcile medication histories during the care transition points of inpatient admission and discharge. Initial pilots of the application show that these new tools support the users’ information needs and have significant potential to reduce adverse events due to medication discrepancies. This project has illuminated many key lessons for future HIT-related projects (). In addition, this project has illustrated how medication data standards and exchange of medication data will enhance users’ workflow and minimize the dangers of miscommunication as patients navigate our increasingly complex medical system.