This information is for reference purposes only. It was current when produced and may now be outdated. Archive material is no longer maintained, and some links may not work. Persons with disabilities having difficulty accessing this information should contact us at: https://digital.ahrq.gov/contact-us. Let us know the nature of the problem, the Web address of what you want, and your contact information.
Please go to digital.ahrq.gov for current information.

Computerized Provider Order Entry - Inpatient

Introduction

Computerized Provider Order Entry (CPOE) allows physicians and other authorized care providers to enter patient-specific orders (e.g., medications, laboratory work) for communication to other health care team members (e.g., pharmacists, respiratory therapists).  CPOE has been shown to improve health care efficiency and patient safety [1,2].  However, many organizations have struggled to adopt CPOE.  As of 2003, fewer than 5 percent of U.S. hospitals have fully implemented CPOE [3], and the Leapfrog Group estimates that it will take more than 20 years for CPOE to achieve "maximum penetration," defined as 80-percent adoption within urban hospitals [4].

Most evidence related to inpatient CPOE has been from large, academic medical centers.  It is unclear whether the lessons learned from these centers can be generalized to other types of hospitals.  Among the projects funded through the Agency for Healthcare Research and Quality (AHRQ) Transforming Healthcare Quality through Health Information Technology (THQIT) program, nine projects studied the adoption and use of CPOE in small, medium, and large acute care hospitals.  In summer 2007, discussions were held with leadership from seven of the grants that contributed to this report.

The characteristics of those seven facilities are listed in Table 1.

Table 1. Characteristics of Profiled Projects

Site #

Community

# of Beds

Teaching Status

Project Status

1

Rural

110

Non-Teaching

Went live in 2007

2

Rural

193

Teaching

Went live in 2005

3

Rural

74

Non-Teaching

Went live in 2003

4

Rural

350

Teaching

Planning to go live in Spring 08

5

Urban

250

Teaching

Went live in 2008

6

Urban

211

Teaching

Went live in 2004

7

Rural

183

Non-Teaching

Went live in 2004

Some implementations took place in rural communities, while others occurred in inner-city areas.  This summary highlights the early lessons from those projects as reported to the AHRQ National Resource Center for Health IT.  These findings have been divided into the following categories:

  • Preimplementation findings,
  • Implementation considerations, and
  • Post-implementation Issues

More lessons from the AHRQ portfolio (PDF, 112 KB, HTML) .

Preimplementation Findings

Lesson 1:  Training all stakeholders (providers, implementers, and so on) in the benefits and principles of health IT, retaining qualified personnel on staff who understand the intersection between clinical care and health IT, and employing knowledgeable human resources people are critical success factors.  It is often difficult to locate these individuals, especially in rural communities.

Including medical informaticians who understand both the clinical and IT domains improve the chances of success when planning for, implementing, and evaluating health IT and need to be in place during the planning process, before implementation begins.  Such personnelare scarce in both urban and rural areas, although rural areas are often most affected. 

Training and education are important strategies that must be incorporated into implementation schedules to avoid delays. These training efforts must be directed toward the expected workflow and process changes, preparing the provider community for these changes and planning for contingencies.

  • One rural AHRQ grantee lacked local health IT expertise; this required them to hire an outside consultant, which added expenses to the project.
  • A chief information officer (CIO) working on an AHRQ-funded project reported that his organization had difficulty filling vacant health IT positions because of a lack of competitiveness within the corporate sector.
  • Several AHRQ projects provided health IT training and education to clinical staff so they could acquire the skills necessary to lead and manage a health IT project.  Some personnel went through training during implementation, while others took classes prior to implementation.  Some projects needed to delay their implementation timetable to accommodate the need to train internal staff on health IT fundamentals and the selected CPOE solution. This training was critical because it helped these individuals understand the terminology of health IT. It also helped them communicate with and educate the provider base more effectively about health IT and how technology can affect process change in a positive way.

Lesson 2:  Understanding workflows and redesigning inefficient processes are critical steps in the successful adoption of CPOE.

The AHRQ-funded project stressed the need for process redesign at the outset of the project.  Process redesign helps CPOE stakeholders and end-users understand how their workflow will change and provides opportunities for them to provide input into designing future workflows. All of the projects invested heavily in process redesign while planning their inpatient CPOE implementations. Each project mapped "current state" and CPOE "future state" processes during the implementation planning process.  Though time consuming, process redesign allowed projects to identify weaknesses in existing processes, make corrections, and effectively integrate CPOE into clinical workflow. 

  • There is no substitute for a needs assessment and requirements gathering phase to determine product and workflow needs prior to the selection of a CPOE solution.   CPOE efforts should be conducted prior to product selection.
  • Some AHRQ-funded projects used manual processes (e.g., pencil and paper) whereas others used mapping software (e.g., Microsoft(R) Visio) to outline existing processes and recommended changes.  Mapping software can assist in providing end-users and project implementation teams with visual representations of workflow needs during system design and training. 
  • AHRQ-funded projects reported that it is essential to include all stakeholders, such as clinicians, clinical managers, organization executives, and staff, in the redesign process.
  • Do not automate a manual process that does not work. Understand the full cycle of how an order is tracked through a system from inception to completion and notification. Realize that some tasks may be reassigned to different personnel or eliminated, and some new tasks may be added.
  • Grantees indicated that the use of a CPOE system significantly affected unit clerk workflow.  This needs to be considered in the redesign process.  When using a paper-based system, unit clerks were able to track and manage the ordering process (e.g. whether a resident ordered a duplicate test); when using an electronic system the unit clerk may not have the same visibility, and the order recipient will be effected.
  • CPOE does not replace face-to-face or direct communication that may be needed (e.g., STAT orders).

Lesson 3: Organizations must allocate extensive resources and time to review available information, such as current provider ordering practices and vendor-provided order templates, to develop customized order sets relevant to the organization.

Many of the AHRQ-funded projects spent vast amounts of time developing standardized order sets for their institutions.  CPOE requires the configuring of hundreds of orders and order sets in the system.  This was a cumbersome process that required the participation of every department in the grantee institution.  At the time many of the AHRQ projects started their inpatient CPOE efforts, the availability of established order sets was minimal outside of what was available from the vendors.  Recently, some projects have noted that vendors are developing reasonable order sets that are available for purchase.  However, the grantees note that there is no single, definitive source for baseline order sets and that they must be tailored to the organization's needs.

  • Developing order sets requires buy-in from every department in the hospital that will be using the CPOE tool.  Getting clinicians on board with CPOE can be difficult, but the order set developing process can be a way that clinicians can provide input about how the tool is implemented and customized for their personal workflows and data entry needs.  The projects reported that this involvement encouraged stronger clinician adoption postimplementation.
  • Several AHRQ projects spent between 6 and 8 months, at varying levels of effort, developing order sets.  Many projects did not initially expect the process to take as long and therefore had to extend their implementation timeline. The work involved meeting with clinicians to understand the ordering process, customizing order sets to specialty or clinician preferences, re-engineering workflows to accommodate the order sets and troubleshooting the process, from both a cultural and technology perspective (i.e., could the software handle the orders properly and in a granular enough way--for example, will it handle an order such as "CBC qam" to mean order a CBC every morning until the order is stopped. In some systems you have to manually order the CBC every morning).
  • Once order sets are designed, considerable resources and time are required to "build and configure" the system.  For example, one AHRQ-funded project found that it took 8 hours on average to load each order set into the CPOE tool.   After the initial build (when the order set and how it will function in the system has been specified) the project plan must provide sufficient time to test the functionality of the order set, its integration into the workflow, and its usability. One AHRQ project reported that it had more than 600 order sets at go-live.
  • The benefit of working with an external vendor for order sets is that the vendor may be able to provide consistent evidence-based medicine content that represents current best practices for drug recommendations, testing, and so on and content that is refreshed regularly. 
  • One AHRQ grantee believed that the cost of obtaining external order sets for customization may have been less than the cost of developing them internally.  External, purchased order sets that can be viewed electronically or printed for team members can shorten the process of developing customized order sets for the organization.  For example, it has taken some organizations 6 to 9 months to develop and obtain approval from its clinical design team and clinical leadership for an order set for a coronary artery bypass graft (CABG) admission.  Providing a project team with existing order sets that can be quickly reviewed, modified, and customized can therefore improve the speed in which these ordersets are implemented and accepted. It also fosters an environment where collaboration and buy-in from the "end-users" (the clinicians) can be facilitated as they feel they have some control over how these order sets are put in place.
  • One project used internal staff for all required customization, which took approximately 18 to 20 months with up to three full-time employees at times. Other projects were able to shorten implementation times by completing the customization and build using a combination of internal and vendor staff.
  • To speed the adoption of clinical decision support system (CDSS) rules, reminders, and alerts in CPOE tools, a few AHRQ projects recommended developing a national repository of standardized order sets that would allow hospitals to download new and updated order sets when implementing CPOE, saving time and resources during the planning phase.

Lesson 4:  Delays in vendor product delivery, product updates, and product integration were common.  These critical transitions must be closely managed to minimize overall project delays.  The vendor needs to be provided with incentives to meet milestones in a timely manner.

AHRQ-funded projects reported implementation delays ranging from 6 to 18 months.  Much of this was due to delayed product deliveries from vendors, but several projects reported problems integrating delivered products with existing systems and errors when delivered systems were turned on. AHRQ-funded project investigators emphasized the need for the use of an effective and experienced project management team to help avoid delays.

  • System selection took up to 6 months for some AHRQ-funded projects.  The system selection was then followed by a contract negotiation period prior to starting the implementation process.
  • Grantees recommended including delay and negligence penalties in vendor contracts.
  • Vendor contracts also should include provisions for receiving updated content and software releases at no additional cost for a specified amount of time, such as during implementation or up to 6 months after go-live.
  • Several projects advocated for smaller organizations to band together when negotiating contracts with vendors. These projects were able to form an alliance with provider organizations that allowed for financial discounts on products and services as well as lobbying power to influence future design and customization releases.
  • Projects should prepare and set expectations for an implementation schedule based on whether they will be employing an enterprise-wide or phased roll-out strategy.  In an enterprise-wide roll-out, the system is activated for all of the "units" of the hospital ward simultaneously, as opposed to a phased roll-out where some units will pilot the system and fix problems before it is released to everyone in the enterprise. Projects planning for an enterprise-wide implementation spent 2 to 3 years preparing for the roll-out. This time was spent ensuring all problems were addressed as completely as possible before the roll-out. Phased roll-outs often had a longer implementation cycle than did enterprise-wide rollouts, because problems were addressed on a location-by-location basis rather than in parallel in all units.
  • Maintaining good relationships with vendors via regular and open communication can result in shorter delays and fewer implementation challenges.

Lesson 5:  A demonstration system that potential users can test prior to go-live can assist in early identification of implementation issues and training needs.

Several of the AHRQ-funded projects created demonstration systems they termed "playgrounds," in which clinicians could interact with a system that was physically separate from the planned production system.  These systems were located outside of clinical areas so clinicians could use the "playgrounds" in private settings.

  • A preproduction environment enabled projects to employ "just-in-time" training before implementation.  Although grantees conducted training prior to system go-live, they expressed adoption and training benefits of developing contingencies and strategies for retraining for providers immediately prior to go-live.
  • Projects using "playgrounds" reported higher CPOE adoption rates by providers of the CPOE system.
  • Costs for demonstration systems or preproduction environments need to be considered because additional equipment and staffing is often required.

Lesson 6:  Grantees employed "clinical steering committees" that provided project direction and leadership.

Many AHRQ-funded projects employed a "clinical steering committee" to organize, lead, and resolve problems related to planning and implementation. Clinical steering committees helped drive the organization toward CPOE adoption goals, resolve issues quickly, and serve as clinical champions for their peers.  Members included all stakeholder types including physicians, nurses, units clerks, pharmacists, other allied health personnel, and executives.  Projects indicated that it is important to form these committees early in the preimplementation process.  However, these committees will need to remain in existence during all phases (pre- through postimplementation) to address issues that arise during all phases of the project.

  • The steering committees were usually "volunteer" efforts that involved significant time commitments from clinicians.
  • The steering committees provided a neutral ground to make key decisions.

Implementation Considerations

Lesson 7:  Careful consideration is required to assess the benefits and potential impact of available feature requirements or changes in scope beyond the initial specification during the implementation. For example, adding new functionality to a system (such as better user interfaces), which is not deemed "essential" but is "nice to have," can delay projects beyond the initial implementation schedule. This "scope creep" should be avoided, if possible.

The health IT field is rapidly changing, and there can be a tendency to delay CPOE implementation to incorporate the "latest-and-greatest" system that will soon be available.  The grantees recommended that projects be wary of "scope creep and feature enhancements that may not be critical to the initial roll-out of the CPOE project."

  • As stakeholders gain a more comprehensive understanding of CPOE capabilities during implementation, it is common for users to be tempted to modify or increase user requirements.  This change usually results in additional delays and costs that must be considered and prioritized by the project team. 
  • AHRQ grantees recommended that projects adhere to the original requirements and scope for the contracted vendor system and institute a process to evaluate additional organizational needs and changes in scope. 
  • The potential impact of scope changes during implementation underscores the importance of a comprehensive requirements development process that is addressed during the vendor scoping and contracting process.  If custom vendor development is needed or the needed capability is in a future product release, the implementation timing and cost may be impacted.

Lesson 8:  There is no "out of the box" solution for inpatient CPOE.  A considerable amount of customization and systems integration is required for implementation.

Vendors may suggest that their systems can be used "as is" as soon as the systems are delivered and installed; however, customization, setup, and integration with other systems is needed for all implementations before CPOE is ready for use.  Organizations should seek expertise from other customers of the vendor, experienced team members, or outside resources to assist in determining the time and effort needed to implement CPOE at their institution(s).

  • Effective CPOE implementation requires tight integration with existing hospital information systems such as registration, pharmacy, laboratory, and electronic medical record systems.  All of the AHRQ-funded projects experienced challenges in connecting their CPOE tools to other internal hospital systems.
  • Many of the AHRQ-funded projects also implemented an electronic medical record (EMR) system at the same time, extended their existing EMR system with the CPOE, and/or implemented a bar-coded medication administration (BCMA) and electronic medication administration record (eMAR) system.  Integrating the CPOE with these systems requires a significant amount of effort.

Lesson 9:  In designing orders and order sets, it is important to minimize the amount of order details a user must complete, utilize default values where appropriate, and standardize placement of similar elements across order sets. 

CPOE is intended to be a tool that facilitates consistent clinician ordering practices by providing templates and minimizing the amount of end-user input.  AHRQ projects recommended careful consideration when creating default values, free text fields, and cross-departmental order sets.     

  • One project noted that it is acceptable to have default values for a specialty or role, but decided to minimize the use of default values because end-users tended to view default values as "recommended values." 
  • All orders within an order set should be in the same place, regardless of order type.  For example, when a user opens an order set, orders for labs, medications, and diet should be located in the same area and use the same format, regardless of order type, to minimize confusion.

Postimplementation Issues

Lesson 10: Continuous and frequent training and retraining, in addition to ready access to technical support, are keys to success of inpatient CPOE initiatives.

Organizations can expect that users will have many concerns and questions about the CPOE tool during and after implementation.  Because of the nature of inpatient care, organizations will need technical support resources that are accessible 24 hours a day, 7 days a week.  This level of support should be factored into the training process as well as the development and planning for internal technical support resources

  • One AHRQ-funded project did not have any hospitalists on staff, so providers use the tool only periodically when they take inpatient calls.  This project has found that frequent retraining is necessary because these providers did not use the tool very often.
  • One AHRQ grantee, a large facility that is part of an integrated delivery system, reported that approximately 3,000 hours of provider training were logged in preparation for CPOE go-live.  About 10,000 hours of training were logged for nursing, ancillary services, and other staff.

Lesson 11:  Ready and immediate access to support during the initial go-live period is critical to success for CPOE.

During initial implementation, many projects staffed round-the-clock experienced super-users, technical resources, and vendor resources available on the floors and within a "command center" nearby.

  • Rapid capture and support for issues during go-live facilitates quick resolution and can help drive end-user adoption.  One project provided four methods for entering issues and requesting support during the initial go-live period: (1) an intranet portal, (2) the ability to send and receive email from help desk staff, (3) a command center with support and technical resources staffed for the first 3 weeks of go-live, and (4) 24-hour shadowing support for the first 6 weeks of go-live, with two to three people shadowing per unit.
  • For the first few days of go-live, this project also instituted a rapid response team that identified and resolved problems with orders that were confusing or unclear to providers.  By resolving issues immediately, the project was able to limit end-users? tendency to implement workarounds that may adversely affect workflow or user perceptions.
  • This project reinforced optimal workflows by sending daily updates with helpful hints and monitoring provider ordering patterns with real-time order tracking.

Lesson 12:  Even though a thorough review and customization of alert classes should be performed prior to implementation, some degree of alert fatigue should still be expected and closely monitored postimplementation to determine updates to CDSS rules.

Alert fatigue can result from an abundance of medically inconsequential CDSS alerts being displayed when providers place orders via CPOE.  Alert fatigue can lower adoption rates of CPOE use because provider frustration with excessive trivial alerts. 

  • In one AHRQ-funded project, the behavioral health department turned off alerts for anti-anxiety drug interactions with common over-the-counter sleep aids, since the providers were fully aware of the minimal risks these combinations pose.
  • One AHRQ-funded project assigned a staff member to round with providers so that alert fatigue complaints (and other issues) could be identified promptly.
  • After providers dismissed multiple drug-allergy alerts within the CPOE system, one AHRQ-funded project used that alert fatigue to provide a platform to discuss "Whatis an allergy?"  This resulted in an updated design of the drug-allergy alerts to reduce the number or severity of certain alerts.  Many clinicians viewed discussions such as these as a positive process for their medical community.

AHRQ-Funded Inpatient CPOE Projects

The following AHRQ-funded projects were funded under the Transforming Healthcare Quality through Health Information Technology (THQIT) program. Seven of these projects contributed to this summary.

References

  1. Committee on Quality of Health Care in America, Institute of Medicine. Crossing the Quality Chasm: A New Health System for the 21st Century. National Academies Press: Washington, DC; 2001.
  2. Committee on Quality of Health Care in America, Institute of Medicine. To Err is Human: Building a Safer Health System. National Academies Press: Washington, DC; 2000.
  3. Cutler DM, Feldman NE, Horwitz JR. U.S. adoption of computerized physician order entry systems. Health Aff (Millwood) 2005 Nov-Dec;24(6):1654-63.
  4. Ford EW, McAlearney AS, Phillips MT, Menachemi N, Rudolph B.  Predicting computerized physician order entry system adoption in US hospitals: Can the federal mandate be met? Int J Med Inform 2008 Aug;77(8):539-45.

Authors

Brian E. Dixon, M.P.A., Regenstrief Institute, and
Atif Zafar, M.D., Indiana University School of Medicine

The information on this page is archived and provided for reference purposes only.