Formula for successful CPOE = (People + Process + Technology) - Risk.

Abstract:

This article is part 2 in a series of 4 on computerized physician order entry (CPOE). Part 1 addressed getting the correct stakeholders identified and engaged in the project. This article addresses the processes to put in place that will support good design and build while also preparing the providers and environment for adoption of CPOE. It is time to organize them into functional groups and get them working on the right things and to put administrative reporting processes in place to address barriers to progress.

Part 2: Process

Once you have identified your team members, and they are committed to the computerized physician order entry (CPOE) project, what do you do with them? The next part of the formula for success is to put processes in place that will support good analysis, design, and build, while also preparing the providers and environment for adoption of CPOE. It is time to organize them into functional groups and initiate processes to address barriers to progress.

CPOE provides the biggest bang for the buck for improved communication, timeliness of care delivery, and patient safety features. Yet that same new functionality, such as alerts and reminders can be perceived as task interference; this may negatively impact user acceptance. It is imperative to quickly define a vision and scope, and repeat it often. The defined scope should include:

* How much standardization and adoption of any specific nomenclatures will be included?

* What alert and reminder functionality will be included?

* What implementation strategy will be used: Big Bang or a phased-in approach?

Be prepared to work hard to stay focused to avoid 'scope creep'!

You are going to need to determine not only what orders to build, but also to review/reengineer all the processes that support and spin off from the ordering process. This process is not just confined to requisition routing and departmental handoffs as the patient moves through the environment, but also involves results reporting, patient billing, and administrative audits/reporting. Whether you are trying to develop a 30,000-item order catalog to address the needs of every department or tackling a single department such as lab orders will greatly impact the complexity and speed of your project.

In addition to physicians, who else has ordering privileges at your organization? Think beyond the usual such as advance practice nurses, physician assistants, and surgical assistants. What about behavioral health therapists? How does your organization define dependent vs. independent ordering practices such as standing orders/protocols or interventions for care planning for registered nurses (RNs) and other disciplines? Does your organization have medical students who are allowed to write orders if cosigned? We highly recommend letting students use your system for as many functions as possible. It's a great way to "grow your own" users! Plan to become familiar with federal and state regulations, physician bylaws, as well as institutional and departmental policies.

With clinicians splitting their time between the project and their clinical work, it is imperative that you use their time efficiently. Plan to use email distribution groups for "just in time" communication and review of documents/drafts. Project files, setup in folders on shared access drives, can facilitate project work and communication. Set up a non-production domain for the application and give them login IDs so they can become familiar with the application and review designs and workflows as they are built. Be sure to send out agendas and minutes prior to meetings so they can come prepared. Be clear on assignments, expected deliverables, and due dates.

Define the "sponsor/owner" for each order/group of orders so you don't have multiple people working on the same orders. The sponsor is typically the performing department, such as Radiology for x-ray orders, or Dietary for diet orders. Each sponsor can be tasked with the initial design for their orders for the interdisciplinary team to review. Stress the concept that this is a "draft", until the team comes to consensus, and signs off on the design. Scrutinize the appropriateness of the mandatory information, and beware of requirements that the ordering clinician can't determine. Be prepared to determine how you will address orders for overlapping areas of practice; this typically occurs in the areas of point of care testing, respiratory care, and functional/mobility orders.

So, how did we tackle replacing a 25 year old legacy system, with a huge order catalog? We developed a multi-layered, semi-permeable team structure and decisionmaking process: a steering committee, a project manager, a project leadership team, a project management group, and multiple design/build teams. Most of the teams met weekly. We felt it was critical that work not occur in isolated departmental silos, so we had interdisciplinary design and build teams for the core functions of Assessment/Documentation, Registration/Admission-Discharge-Transfer, and Orders & Results. In addition, we had discipline/service specific teams for Emergency Services, Nursing & Patient Care, Physician (MD)/Provider, Pharmacy, and Information Systems Technical Platform. The Nursing & Patient Care team included representatives from Nursing, Pastoral Care, Respiratory Therapy, Physical Therapy/Occupational Therapy, and Food & Nutrition.

Our MD/Provider team was chaired by an attending physician, and consisted of four attending physicians, one housestaff physician, and three nurse practitioners (NPs). As many as 15 additional housestaff physicians were recruited at various times, primarily for confirming acceptability of design, and completion of test scripts. The Orders & Results team was chaired by a NP and membership consisted of a radiology analyst, respiratory therapist, physical therapist, dietitian, and several RNs. Patient accounting reps were involved in the design of all orders that generated charges. All orders design went to the MD/Provider team for final sign-off. If conflicts arose, department heads were invited to meetings. The MD/Provider team was responsible for the development of all training materials and communication that went out to the Medical Executive Committee and the physician/provider community.

Technical analysts, vendor reps, consultants, nurse analysts, and key clinicians covered multiple teams. Chairs of teams were members of the project management group and attended meetings as needed; they also "lurked" as ad hoc members on other teams' email distribution groups. This provided cross-pollination of ideas and faster, consistent communication among the teams. All team members had access to the project shared drive, and were issued position appropriate login IDs to our Build domain. As work was completed, these teams disbanded and the team leaders merged with the MD/Provider team to form our interdisciplinary Clinical Advisory Group (CAG) prior to go-live. CAG continues to meet biweekly, and provides direction and decision-making support for enhancements, new functionality, and other clinically related Information Technology projects.

Now that you've got your teams organized and processes in place to support the work and decision-making, what are the technical bells and whistles, do's and don'ts?

Watch for Part 3 of the formula -Technology- in the next issue of the CARING newsletter!

Recommended reading:

Katzenbach, J. R. and Smith, D. K. (1993). The wisdom of teams: Creating the high-performance organization. New York: HarperCollins.

Terry Lockhart, RN, MS and Dana Moriconi, RN, MBA 

Terry Lockhart is now a Senior Consultant with maxIT Healthcare, LLC Dana Moriconi is a Clinical Liaison at Virginia Commonwealth University Health System