By Barry P. Chaiken, MD, FHIMSS

Healthcare organizations implement clinical healthcare information technology (HIT) to improve the quality of care, enhance patient safety, and eliminate inefficiencies in order to reduce the cost of care. Irrespective of the technology solution selected, however, implementing an expensive, comprehensive clinical HIT system is nothing short of immensely disruptive to any organization. Senior management teams stake hard-earned reputations on the successful deployment of these very complex technology platforms. Failure not only wastes millions of dollars of scarce investment resources, but also poisons, for a period of time, the goodwill among clinicians needed to implement these critical information technology tools.

Current State Versus Future State Implementation
Most organizations choose to minimize disruptions caused by HIT implementation by applying new technology to the current state of how clinicians deliver care. "Current state" describes, through diagrams and descriptive text, what activities are presently done. Documentation of the current state comes from clinicians and staff, at every level, who perform these activities and follow the workflow of the current state.

Processes and workflows are redesigned once the technology is installed. Organizations often choose to implement before processes and workflows are revised for several reasons, including: desire for a shorter length of time to go-live, limited resources available to complete process redesigns, and unclear links between potential redesigns and overarching organization objectives.

A few organizations, however, decide to reengineer clinical processes based upon their desired future state before implementing the system. "Future state" defines what the current processes and workflows would look like after relevant changes take place in those current processes and workflows. This is usually developed with the involvement of those who participate in the current state, experts in any new technology introduced, and trained professionals in quality improvement and process redesign.

Organizations that decide to utilize current state for implementation must study their current processes and understand the impact new HIT tools will have on those processes. In this instance, processes are not actively changed in anticipation of the new capabilities afforded by the HIT tools, but the new tools are used to facilitate current processes. For example, pharmacy orders that were formerly handwritten are now — after implementation of clinical HIT — generated by an order entry system and printed at the nurse station for delivery to the hospital pharmacy. There is no electronic transfer of drug orders to the pharmacy.

An alternative approach is to study existing processes, but also creatively design new processes that best leverage the capabilities of the HIT tools to deliver better processes, workflows, and outcomes. Unfortunately, the development of these best processes and workflows cannot be universally applied across any healthcare organization. Each institution is different, requiring documentation of current state and development of a best future state that considers the realities of plant, people, and resources. Finally, an organization's choice of either a current or future state implementation is greatly driven by organizational goals, administrative leadership, and existing change management capabilities.

Implementation Strategies for Success
Through efforts assisting with the implementation of clinical HIT systems at several organizations located in North America and the United Kingdom, valuable insight was gained into best practices for HIT deployment. This experience included organizations that approached implementation utilizing current state and others utilizing future state. These strategies can be applied irrespective of the brand of clinical HIT system implemented.

Whether your organization chooses to reengineer its processes before or after implementation, successful deployment of clinical HIT depends upon three key factors: technology, training, and change management.

Develop an organization-specific clinical HIT implementation model. Before the implementation of a system, it is not obvious which clinical content and workflows, which appear to be appropriate across all clinics or departments, may not work well at all in practice. Customization should be expected at each site with clinicians providing effective solutions if engaged early in the process.

Identify potential implementation problems with a mock go-live. Effective training requires a realistic schedule of education, system testing under realistic conditions using a simulation (i.e., mock go-live), and processes to make changes before the actual go-live. Linking the education to a mock go-live helps identify unforeseen problems in processes and workflows, allowing them to be corrected before they can impact patient care. In addition, this approach builds confidence among users that the system will work. Participation of physicians, nurses, and other clinical and administrative personnel is essential to conducting a meaningful mock go-live.

Treat physicians and nurses equally. Regardless of setting, physicians and nurses work as a team, performing a ballet of activities that deliver care. Although the primary focus is often to secure physician adoption of clinical HIT, nurses play a very important role in securing and maintaining physician adoption. If HIT implementation puts an additional burden on nurse workflow, nurse adoption will surely suffer. In turn, this rejection of the technology impacts physician adoption. Effective workflows require both physicians and nurses to use the same system. Without nurse adoption of the HIT, physicians, no matter how positive their opinion of the HIT, are at a higher risk of abandoning it to remain in step with the workflow used by their nurses.

Prepare for unique demands that complex clinical systems place on IT staff. Clinical systems are orders of magnitude more complex than other hospital IT systems, such as financial programs. A typical clinical IT system incorporates multiple single system functionalities into one integrated application including scheduling, messaging, documentation, prescription writing, and results reporting. It takes much more time for an IT department to figure out how such a complex system fits into an already complex environment — i.e., the healthcare delivery setting — than the department would for a hospital accounting system.

Invariably it takes more time for users to learn and effectively use clinical systems than users of less complex systems. IT departments must expect to invest more time and resources bringing these systems up and maintaining them in production mode. In addition, experience with administrative HIT systems provides only a limited model for use when implementing and maintaining clinical systems.

Forge a strong partnership with the vendor. Implementation of a clinical HIT system requires an enormous investment of capital, professional resources, and clinical staff goodwill. Best viewed as a marriage, it is important to follow a measured pace of courtship before settling on a particular vendor. Once a clinical HIT system is deployed, it is terribly difficult to get divorced from it. Beyond the expense of purchasing a new system or re-investing in training, much of the valuable patient data that exists within a rejected system will be very difficult to transfer to the new system. Excellent and honest communication coupled with solid trust must exist between the healthcare organization and vendor. If this does not exist, "don't get married."

Practice patience to achieve a successful implementation. Healthcare organizations and vendors alike, excited about forging ahead with a new system, often allow their enthusiasm to overwhelm their professional judgment. In more rational moments, both know that extended and detailed planning greatly increases the likelihood that a deployment will end successfully. Although physicians and nurses, after viewing a demonstration of a clinical system, may be wowed by its capabilities, organizations need to realize that live production systems do not match the flexibility and response time of demonstration systems that are tweaked to deliver the best performance.

Budgeting a minimum of 4 to 5 months to plan a deployment is both prudent and necessary. During this time, information is collected to better understand how the clinical HIT system fits into the existing technology infrastructure, physical plant, and clinical processes. In addition to planning, this pre-implementation time can be used to stage the necessary equipment (e.g., computers, desks, electrical supply, etc.) while securing the additional IT services (e.g., data center for backup) to guarantee a reliable system. Last, when developing an implementation timeline, consider all forces that may be driving both your organization and the vendor at a particular speed down a deployment path.

Let users play with the system. Often IT departments are reluctant to make a system available for use in simulation mode due to concern about the resources required to support a non-production system. Although it appears that users are "playing" when using a system in simulation, in reality they are learning. Playing develops "super users" of the system, who then provide invaluable supplementary support to help desks assigned to provide assistance to users. In addition, these super users of the system become ambassadors working to convince their peers to both use the new system and showing them first-hand how to do so.

Align IT department goals with overall project goals. Due to their professional training, IT departments often become focused on getting the hardware and software "right" rather than the entire project. Successful deployments are not measured by installation timelines, response times or number of working systems, Measurements for successful deployment of clinical HIT systems must be linked to an organization's specific patient care goals and objectives. These invariably include quality of care, patient safety, and cost metrics.

Clinical departments may use medical error rates, clinician efficiency, and billing accuracy as their metrics. In parallel, IT departments may use percent of clinicians as users, user satisfaction, and average time using the system as surrogate metrics to measure success. The development of a comprehensive deployment plan that includes rework of clinical processes and revised workflow driven by HIT, in addition to the obvious hardware installation activities, greatly increases the likelihood of securing expected outcomes from clinical HIT deployment.

Outpatient Deployment Is Easier than Inpatient
Although a successful deployment of a clinical HIT system requires detailed planning that includes high quality clinician-user training, outpatient deployment invariably occurs more quickly and with fewer problems. Intuitively this is expected as outpatient settings are considerably less complex than inpatient settings. In addition, outpatient users interact with the clinical HIT system on a more regular basis utilizing fewer system functions. This creates an environment where the user learns a limited set of HIT system processes and is afforded the opportunity to regularly practice those skills. In the inpatient environment, clinical users are faced with a much broader set of HIT system processes and do not get to reinforce those processes through regular use.

Summary and Recommendation
Without question, successful deployment of a clinical HIT system requires comprehensive planning, exemplary team leadership, and organization-wide patience to coordinate all the people critical to the project. Nevertheless, establishing a project's overriding goals and objectives, and communicating those clearly to every person involved in the clinical HIT deployment, sets a meaningful direction for the project that can be followed by everyone.

Processes and workflows drive outcomes with or without HIT. Whether these processes and workflows are redesigned before or after deployment to take advantage of the capabilities of an HIT system, the processes and workflows will require revision. Therefore, it is recommended to include the revision of clinical processes and workflows in the pre-deployment planning so that a major change process occurs once rather than twice. Although this may extend the planning period, it decreases any post-deployment rework of clinical processes and workflows. In addition, this approach will prove less confusing to clinical users as they are required only to change their clinical habits once.

Organizations may be tempted to exclude the difficult task of revising clinical processes and workflows during the deployment planning, and schedule it for the post-deployment time period. Such a decision greatly increases the probability that this later revision will prove problematic or not get done at all. Therefore, when implementing a clinical HIT system, take a comprehensive, visionary approach, carefully plan the change management for revised processes and workflows, and stay focused on the overarching project goals and objectives linked to patient care.