The following list of issues related to computerized prescriber order entry (CPOE) was developed by a group of pharmacy practitioners actively involved in the implementation and maintenance of CPOE systems at their respective institution. The information provided here is an expression of lessons learned by these practitioners and is not intended to capture all the relevant issues related to CPOE. The American Society of Health-System Pharmacists is pleased to provide such valuable and timely information to its members and would appreciate feedback on how the content in this document can be improved over time.
Special thanks to Sandi Mitchell, Bruce Chaffee, Rita Shane, and Toby Clark for sharing their expertise and insights and for their work in developing this document.
Pharmacy’s Role Throughout the CPOE Process
- Pharmacy should take a proactive leadership role in the CPOE process from the beginning. Pharmacists have the most experience with order-entry and electronic clinical-decision-support systems and, as such, can contribute significantly to a CPOE project. Further, the medication part of a CPOE system is by far the most complex.
- Pharmacy needs to be involved in some of the key decisions that will need to be made early:
- (1) Is the CPOE system to serve solely as an ordering system that might, at some later time, perform other activities, such as charting? Or is it intended to be an “end-to-end” system that includes features such as medication charting, results reporting, and an electronic medical record?
- (2) Will the CPOE system have decision-support features? If so, to what extent?
- (3) Will the CPOE system interface with the pharmacy information system? Or will the hospital use a system that requires replacement of the current pharmacy information system with the vendor system or another system?
- Allocate the time. Decisions about CPOE will determine the direction of the pharmacy department and pharmacy practice and affect everyone’s work and life.
- Pharmacy department members need to be active members of many of the CPOE-related committees—even those, such as nursing and order-set committees, in which other people may not believe pharmacy has a role.
- Educate yourself on the basics. The Information Systems staff and the clinical staff need to use a common language when discussing the project. A formal glossary can be a very useful tool for both staffs when discussing such issues as the basics of an orders interface, triggers, and messages compatible with the Health Level Seven [HL7] messaging standard).
- Create a flow chart of the current medication-use processes for prescribing, transcription, dispensing, and administration and determine the workflow for these processes after implementation of the CPOE system. Establish a multidisciplinary team to create the flow chart.
- Involve the pharmacy and therapeutics (P&T) committee, where appropriate. It may be desirable to establish a subcommittee to focus on CPOE. Many of the decisions about the system’s structure and functionality will result in the establishment of new policies or the enforcement of existing policies that may or may not have been followed in the past. These systematic changes can significantly affect workflow, safety, quality, and productivity. Involve nurses in this decision-making process because CPOE will also impact the medication administration process. Remember that the P&T committee of the medical staff is responsible for the medication system, regardless of whether a computerized system is used. All changes to the medication system need to have support from the medical and clinical affairs committees.
- Project goals need to be clearly defined. Baseline data should be obtained by using appropriate, valid measures (e.g., rate and type of pharmacists’ interventions to prevent prescribing errors, rate of medication errors, time measurements satisfaction surveys) that can be assessed again after implementation of the CPOE system. User survey data should be captured before and after implementation. Potential issues to survey include patient safety, clinical benefits, resource utilization, and cost benefits.
- Pharmacy resources should be planned carefully. Pharmacy directors need to be involved in preparing for CPOE and should plan on spending as much as 40% of their time on CPOE-related activities before and after system conversion. A recent group POE survey indicated that at least two full-time equivalents (FTEs) are needed for building and testing the new system and one to two FTEs are needed after the conversion. These figures do not include time spent planning a clinical decision-support system, or dealing with building and operations issues.
Vendor-Review Process
- A request for information (RFI) and request for proposal (RFP) are the initial documentation generated by the site to request functionality listings, responses, and additional materials from the vendors. These request processes vary from state to state and site to site. Their importance is to provide a structure for comparing the vendors’ ability to match their product with the site’s functionality requirements.
- On-site vendor demonstrations provide an opportunity to learn more about the software, clarify vendor responses to the RFI or RFP, assess true functionality, and contrast competing vendors. A scenario is a very powerful evaluation tool for assessing the capabilities of application software. By requesting placement of specific order-entry scenarios in the product, one can begin to determine how well the product fits the site’s clinical practice. Illogical and inappropriate scenarios should be included to test the logic of the software. For example, if the software accepts an order calling for diazepam injection to be given rectally at a rate of 100 ml/hour with a “prn” schedule, the CPOE workgroup should be concerned.
- Peer contacts are very important. Much can be learned not only about the application’s functionality and environmental requirements, but also about the system’s functionality and vendor’s customer service. Sources of peer contacts include personal interviews, conference calls, and professional society meetings.
- Site visits should be conducted to observe the performance of the software. Visits should be conducted at peer institutions and include the clinical and technical staffs from the host and guest hospitals. If possible and in order to obtain candid information, the vendor’s representatives should not be present during the site visit.
- Contracts need to specify the incentives for the vendor meeting deadlines and performance standards and the penalties for failing. Hospitals should be especially vigilant in including contractual language to cover situations in which a required functionality is not present but is promised by the vendor.
- In addition to the pharmacy and medical literature, other resources are available to help with the process. These resources include:
Patient Care Environments
- Increasingly, the continuum of patient care is blurring. The CPOE system must be able to support many patient care environments in a health system. Connectivity with inpatient areas, outpatient clinics, physician offices, pharmacies, emergency rooms, infusion centers, and surgery centers is essential at many institutions. Though the requirements are different for each setting, a strong system architecture can be modified to handle all of these situations.
- It is essential that the medication formularies for the CPOE system and the pharmacy system be the same.
- In a CPOE–pharmacy interfaced environment, the CPOE system’s medication order contains data fields that must map clearly to the pharmacy data fields. For example, the pharmacy data field for the IV route of administration may not map directly to the CPOE system’s field for IV type. Detailed discussions among vendors, the interface support team, and the pharmacy will shed light on potential inconsistencies.
- The CPOE system must provide an effective process to build, maintain, and implement the parent/child relationship for medication data. (The parent/child relationship is the passing of older information necessary to creating new information.) Order messages inbound to the pharmacy system should directly match a pharmacy inventory item in a high percentage of cases, with few orders needing manual entry in the pharmacy. This is an ongoing developmental process that will continue to increase the percentage of direct matches over time.
- In a CPOE–pharmacy integrated system, the items that a prescriber can order and the products that the pharmacy can provide should be considered in concert so that situations do not arise in which an ordered product cannot be processed by the pharmacy system.
- Protocols, order sets (personal, departmental, and standardized hospital), and investigational drug processes must be considered as part of the project. Often these business processes shed light on new functionality requirements of the CPOE system.
- There are numerous considerations in the creation of medication orders in the CPOE system. Each part of the drug order—drug name, dose, route, frequency, duration if appropriate, and special considerations—needs to be carefully and explicity defined in order to ensure the safety of the system.
- Medication orders for populations—such as pediatric, oncology, and neonatal patients—and complex regimens, such as a tapered dosage of a corticosteroid and patient-controlled analgesia—will require special consideration and diligence.
Nursing
- The nursing staff’s workflow will be one of the areas most affected by the CPOE system. A careful review should be conducted to assess the current work processes and compare them to the alternative functionalities offered by the vendor.
- The manner by which nurses receive notification that a new medication order exists, verify new orders, and retrieve medications in settings with decentralized automated dispensing cabinets needs to be determined.
- Pharmacy and nursing staffs must work closely to define the requirements of the medication administration record (MAR).
- Workflow options range from hard-copy MARs generated electronically and completed manually to online MARs completed online to bar-code-assisted systems. The vendor should be able to clearly distinguish between the CPOE’s current functionality and vaporware (i.e., a nonexistant functionality that is anywhere on the continuum from imagination to development).
Interfaces
- The interface between the CPOE system and a new or legacy pharmacy information system must be robust, fully functional, and bidirectional. The site needs to be able to control the triggers for the generation of messages in both systems (e.g., pharmacy should be able to modify an order for operational reasons without generating a message to the CPOE and MAR systems), and these triggers need to be available at multiple points during the order entry and medication administration processes.
- When a table in another system is updated, a master file interface should transmit a message, written in accordance with the HL7 messaging standard, from the originating system to the CPOE system (e.g., when the pharmacy system updates its “dose form” table, an HL7 message is transmitted to the CPOE system to initiate an immediate update to the corresponding table;when the admission–discharge–transfer (ADT) system updates its “patient beds” table, an HL7 message is transmitted to the CPOE system to initiate an immediate update).
- The CPOE system must provide a clear method for building, maintaining, and implementing the parent/child relationship for medication data (e.g., the physician using the CPOE system sees the generic medication name [parent], which is transmitted in the HL7 message, and the CPOE system maintains a mapping architecture to transmit the information on medication package size [child] in a separate segment of the HL7 message).
- Interfaces with automated systems need to be carefully planned to reduce the need for redundant work.
Clinical Decision Support
- An initial decision needs to be made on how the new clinical decision-support functionality will work with the preceding decision-support functions provided by the pharmacy system. This must be done to prevent duplication of efforts or lapses in the CPOE system, especially if the CPOE and pharmacy systems use different commercial clinical databases. The institution should determine which clinician is responsible for each type of clinical alert and how the two systems should communicate.
- A balance needs to be achieved between the amount of clinical decision support that can be provided by the CPOE system and the amount that the clinician will use. During initial implementation, when people are becoming accustomed to the system, it is probably best not to provide the full level of clinical decision support. Prioritization of the clinical decision-support options should be the responsibility of the P&T committee.
- To ensure that the alerts generated through clinical decision support improve the safety of the medication-use process, it is essential to continually monitor how clinicians use the support and to give them feedback.
- Multiple levels of clinical decision support are required to develop a robust CPOE system. The first level begins with the field edits; at this level, the builder writes a “rule” that establishes the high and low acceptable ranges for data in each field. Additional levels include order sets, exception reports, and automated interventions. The Leapfrog Group provides a diagram detailing the many levels of clinical decision-support functionality. The development of rules is complex and includes field-level edits and medical logic modules.
- The language of decision support includes the terms include active rule and passive rule. An active rule is a defined set of circumstances that is integrated throughout the order-entry process and causes things to happen (e.g., a window pops up with clinical information relevant to the order-entry process). A passive rule runs in the background, usually does not interfere with the order-entry process itself, and may gather information for a report that will be generated.Synchronous and asynchronous methods are also part of clinical decision support. A synchronous event (e.g., dose checking) occurs as part of the order-entry process, while an asynchronous process(e.g., a request by the P&T committee for a report on a specific medication or laboratory test) occurs well after the initial event.
- Coding allergy information is a seemingly simple process, but the underlying architectural issues are complex. Because there is no industry standard for allergy codes, each commercially available medication list has a proprietary allergy-code scheme. If the CPOE system and the pharmacy system have different allergy-code schemes, a map to integrate the codes needs to be manually built and maintained. The allergy codes pass between the CPOE and pharmacy systems on the ADT message segment. Rules on the gold standard for the allergy data need to be established and publicized. Mapping one set of allergy codes to another not only increases the performance needs, but increases the risk of error.
- Communication of an event alert to a clinician can take many forms. Current technologies include interactive pagers, alpha pagers, cell phones, emails, and wireless units, with many more technologies in development. The application’s ability to be flexible with the communication, tracking, and auditing components are of critical importance.
Reporting
- Reporting tools at multiple levels must have access to the entire architecture. With some databases, the user can access only a subset of the tables while the vendor can access all of the tables. To be effective with reporting, the site must have access to every table. Vendors often can provide a database diagram and data dictionary (customers may want to make this a contractual requirement). If not, it might be useful to develop a chart that details the system’s tables as information is made available.
- Departmental use of reports is vital to achieving optimal usage, so access must be granted at multiple levels. Many times a user will need to generate a simple report to respond to a question. Sometimes this can be supported with prebuilt reports containing user-defined criteria that can be set before the report is generated. Other times, users may need to access data from multiple tables. This will require users to understand the relationships among tables in order to access the appropriate data and obtain the appropriate response from the system.
- Reporting tools can range from a call from another clinical system for a specific piece of information (an application programming interface) to sophisticated rogramming levels to the end-user ad hoc level. (Note: many systems use a central data repository or clinical data repository for reporting and rely on a standard report writer, such as Crystal Reports [by Crystal Decisions], Microsoft SQL Server, or BrioQuery [Brio Software]).
- It is highly desirable to have a wide variety of reporting outputs, including hard copy, graphics, spreadsheets, and data exports.
Technology Environment
- The Information Systems (IS) staff should be part of the interdisciplinary team. The IS staff is the group best able to answer questions about the system’s architecture, security, operating systems, hardware, network environments, and requirements for various desktops and wireless systems relative to the institution’s information technology strategy.
- As the complexity of systems increases, new issues arise related to system downtime. Aside from the restoration of hardware after a hardware-related problem, there are issues of data synchronization that come into play. There must be a sophisticated planning team to design the restoration plan among the multitude of servers and interfaces.
Financial
- A review of the application billing capability is important. There are products that create batch files and transmit real-time interactive HL7 messages to the billing system. Many institutions will leave billing functions to the various departmental systems unless an integrated solution is planned. There may be instances when miscellaneous patient charges are not captured by any current system; the CPOE system has the potential to capture these charges. Special attention is needed to ensure the accurate coding of bills for Medicare and Medicaid outpatients.
Quality Improvement
- As with any new system, it is essential to monitor the system to ensure that it performs as it was designed. A CPOE system will introduce new errors, especially during initial implementation. Computerization with clinical decision support can create complacency among the clinicians; therefore, diligence by the pharmacy staff will be essential to reducing the risk of significant medication errors arising from CPOE. Errors involving the wrong drug or wrong patient have been reported with CPOE systems.
- Most CPOE systems are designed to provide pharmacists with a screen that lists new and revised medication orders. In contrast to the paper system, in which the pharmacist receives a direct copy of all the orders for a patient, a CPOE system directs only the medication orders to the pharmacist. The problem with this approach is that the pharmacist must make an extra effort to review the entire set of orders for each patient. The review of all orders should be required as the standard of practice to ensure that the progress pharmacists have achieved in the provision of pharmaceutical care is not jeopardized by CPOE systems.
