Rapid and foundational change is underway in health jurisdictions around the world as they adopt electronic medical records, interdisciplinary teams and jurisdictional electronic health records (EHRs) to mitigate the intense care needs and health risks brought on by an aging population. The Canadian province of Alberta is no exception. Alberta has encountered adverse events because of a lack of coordination in its EHR software operations. Alberta's EHR implementation team adopted the Information Technology Infrastructure Library, which uses best practice concepts for managing information technology operations to mitigate such risks. The team has learnt several lessons that are applicable to the adoption of health information systems in other care domains. A cautious approach, using pilots, standards and input from non-physician clinical and administrative staff, facilitates system adoption. This paper illustrates the software operations issues encountered by the EHR implementation team and the approaches taken to address these issues, and extrapolates these lessons to adopters of health information technology.

Introduction

The Canadian province of Alberta is implementing strategies to assist healthcare providers in delivering care to an aging population. Alberta is managing the disparity between healthcare demand by an aging population and the capacity to supply care by adopting interdisciplinary team approaches to care (known as primary care networks [PCNs]) (Primary Care Initiative n.d.), electronic medical records (EMRs) and a provincial electronic health record (EHR). Such approaches imply significant change to the healthcare system and the role of physicians.

The purpose of this case study is to report the authors' experiences of implementing the Information Technology Infrastructure Library (ITIL) software operations management framework for provincial EHRs. The lead author, who now manages a PCN, has realized that the lessons learned at the provincial level also apply to the implementation of PCNs and EMRs. The implementation of EHRs, PCNs and EMRs involves team-based change-management concepts. This article does not advocate for the adoption of software operations management in physician offices, but rather extends the experience of implementing operational change at the provincial level to implementing information technology adoption in other domains of care.

Background

Alberta chose to implement the architectural design recommended by Canada Health Infoway (Canada Health Infoway 2006), starting with the laboratory and drug information systems. However, Alberta Health and Wellness (AHW) realized that the Infoway model of large, complex and interdependent applications was too big for any single organization to deliver. AHW therefore decided to partner with regional health authorities (RHAs), the Physician Office System Program (which is responsible for EMR adoption in the province) and EMR vendors to deliver the other EHR info-structural components. Its goal was to have an EHR for every Albertan by 2008 (Strating 2006).

An EHR is a patient-oriented, aggregated, longitudinal system that assembles health information about a patient over a wide area network. Source systems are geographically dispersed, point-of-service healthcare systems such as pharmacy systems, laboratory information systems and EMRs, among others. An EHR assembles a secure, private, lifetime record a of patient's key health history and care within the health system, and shares encounter information with authorized healthcare providers in support of high-quality care (Canada Health Infoway 2006).

On the other hand, an EMR is a computerized health information system that is used in clinical offices to record detailed encounter information such as patient demographics, encounter summaries, medical history, allergies, intolerances and laboratory test histories. Some EMRs may support order entry, results management and decision support (Rehm and Kraft 2001; Tang 2003). EMRs feed patient health information data to EHRs so that this information can be accessed by other clinicians at other points along the care pathway. Thus, an EHR is a patient-oriented information system that allows patient data to be accessed by many providers in the delivery of care. An EMR is a provider-oriented system that allows providers to manage the care of many patients.

A PCN is a joint venture between an RHA and a group of family physicians who agree to provide diverse healthcare services tailored to their community's needs. Most of the province's 30 PCNs leverage an interdisciplinary team of healthcare workers to complement the work of local physicians (Primary Care Initiative n.d.). While the province rolls out more PCNs, the Physician Office System Program continues to facilitate the adoption of EMRs in primary care. These two modes of reform - both employing teams - imply significant concurrent change to the physician's role. When implemented properly, EMRs and PCNs can help physicians to become more efficient and effective in the care that they provide (Ludwick and Doucette 2008, 2009).

Coordinating Software Operations

In 2004, AHW delegated the delivery of EHR info-structural components to the RHAs to take advantage of their human resource capacity and their experience in implementing health information systems. The RHAs had previously implemented integration engines, master patient indices and laboratory and diagnostic imaging repositories in their regional health information systems. In the early days of this eager partnership, each organization delivered its component applications through separate and isolated business plans. With no significant coordination of application development across organizations, a continuous stream of ongoing production updates materialized in the EHR production environment.

Weekly production updates meant that the production configuration continuously changed. A large number and ever-changing combination of production configurations needed testing. However, the EHR implementation team (a team of architectural, software development, quality assurance and project management experts from AHW and the RHAs) had a limited number of test resources. As a result, the test teams were unable to completely evaluate new releases. There was too much planned outage because of weekly outage windows. There was too much unplanned outage because of breakages in production caused by insufficient inter-application testing (Ludwick and Doucette 2007). The partner organizations were unaware of the number of updates delivered into production.

Adverse medical events resulted from insufficient inter-application design and testing. In 2004, one partner organization made an application change that resulted in patient data being inserted into the wrong patient records. Root-cause analysis revealed that the upgrade was unanticipated by the other partner organizations, who would have needed to modify their applications to accommodate the changes made in the new version. In 2006, more upgrades resulted in more adverse events. In this case, a different partner organization used healthcare data in a manner for which they were not designed. It did not communicate how it was using the data to partner organizations. Even after root-cause analysis had been completed, the partners continued to operate in their traditional application delivery practices without realizing the need to adapt their practices to accommodate the team approach.

Best Practice Software Operations Management

In 2006, the EHR implementation team adopted a simple approach to address its production management issues. Instead of having a continuous weekly stream of ongoing software upgrades, a packaged approach was adopted. The packaged approach groups application upgrades into quarterly release packages. Limiting the number of release windows minimizes outages and maximizes clinical usage time. The packaged approach gives architects time to make changes to applications to maintain integration. Test departments have time to anticipate the new production configuration and execute the test plans needed to assure the operability of the EHR.

An important element of the release management strategy is communication. Release packages are communicated to stakeholders through a change advisory board (CAB; members are from the various EHR partners) so that partners can modify their applications to maintain integration. Release packages are categorized by major and minor releases, in addition to high-priority releases. Major and minor releases differ by the degree of technical complexity of the software updates. High-priority releases are only used to make immediate changes to applications without which patient safety or privacy would be compromised.

To minimize production outages, new releases are implemented on off-line, mirrored servers and then swapped with the online servers, making the cut-over to the new release much faster. The new release model is based on the ITIL software operations model, which incorporates a world-renowned set of best practice concepts and techniques for coordinating information technology infrastructure, development and operations across multiple, interdependent organizations (itSMF Canada 2008).

Lessons for adopters of health information systems

It is not obvious that lessons from adopting operational processes are applicable to the adoption of EMRs by physician offices. However, both experiences offer strong case studies in team-based change management. Healthcare organizations are social entities - clinicians need to interact with each other to provide care. Over a long period of time, this ongoing interaction turns into workflows and can even become an entrenched organizational culture.

System Fit Within the Culture

In our recent review (Ludwick and Doucette 2009), socio-technical interactions between the technical features of a health information system and the social dynamics of a healthcare work environment (Ash et al. 2007; Reddy et al. 2003) were found to have the greatest impact on systems implementation success. These concepts contend that there is a relationship (Ash et al. 2007; Garg et al. 2005; Rosenbloom et al. 2006) between the tools that facilitate the healthcare processes and the interpersonal interactions needed to carry out the day-to-day clinical tasks of a care facility (Reddy et al. 2003). In other words, when implementing EMRs, physician leaders need to consider the system's "fit" within the culture and workflow (Ludwick and Doucette 2009). If there is a poor fit then the health information system, the workflow or both must be modified to optimize fit.

Adopting the ITIL model was not easy because it required changes to entrenched organizational processes. The ITIL model changed the way in which organizations delivered their EHR software. Organizations were no longer permitted to implement software upgrades according to their own schedules, but needed to coordinate their releases through the CAB. Organizations initially resisted, portraying the CAB as a layer of bureaucracy that slowed down projects and added little value to the release process. Although ITIL brought greater awareness of inter-application dependencies, better quality assurance and the confidence that clinical incidents can be avoided, it also brought more process, more paperwork and less business freedom to make ad-hoc updates. It took many months of inter-organizational discussion to integrate the model into the organizations' workflows. Such discussions allowed staff in all organizations to share their perspectives and feel included in process development. The discussions spread the word of the proposed approach, harvested feedback and allowed process proponents to modify the model in ways suggested by stakeholders.

Welcoming Contributions

When an organization undergoes significant organizational change, individuals need to feel that they have control over their future. Furthermore, different individuals have different perspectives on the circumstances within an organization. AHW's implementation of ITIL showed that it is not always necessary to completely develop new processes or concepts prior to their installation. In fact, when ideas are brought forward in an incomplete form, others gain an opportunity to contribute to their evolution. The EHR implementation team's adoption of ITIL was an example of this experience. ITIL was implemented without all of the process issues worked out, which frustrated some stakeholders because it appeared that process advocates were unprepared for the real-world pressures of building the EHR. However, by leaving room for others to contribute, process advocates gave stakeholders a chance to influence the implications of upcoming change and to contribute to their development.

The experience taught the team that stakeholders need room to contribute, partially because they need to feel that they have some control over their future, but also because stakeholders from different parts of the organizations may hold valuable information that might enrich a new process or system. In physician offices, physicians are usually the owners of the clinic. Since these physicians bear all of the financial risk of the business, they rightly have a significant influence over changes. When it comes to EMR implementation in physician offices, physicians are strongly advised to consider including their clinical and administrative staff in the project. Even though physicians own and run their clinics, their staff may have different perspectives on office operations (Miranda et al. 2001).

Pilots

The lead author's experience with implementing ITIL has shown that strong coordination is required to avoid adverse events. The EHR implementation team uses pilots, called limited production rollouts (LPRs) (Alberta Netcare 2006), to allow stakeholders to practise coordination prior to going live with the EHR at new sites. A pilot of an EMR in a physician office or an LPR in a hospital will allow employees to become familiar with the new tools without the risk of an adverse event or the personal risk implied by having to learn a new technology. Physicians rarely take the time to become properly familiar with the available products, select an EMR, implement it and then train to use it, even though their colleagues may have invested time and realized great benefit (Ludwick and Doucette 2009). However, pilots (often implemented at clinics where the leaders are considered early adopters and whose clinics have satisfied an organizational and technical readiness assessment) sponsor trial, error and learning from mistakes, while still allowing project managers to acknowledge progress towards an implementation milestone. Pilots take time and cost money; however, physician leaders are encouraged to consider running a pilot to avoid long-term implementation issues that can prove more costly than the lost revenue incurred during a pilot.

The Implementation Process

Popular opinion holds that general applications of health systems improve patient safety, improve physician office efficiency and mitigate shortages in health human resources (Canadian Broadcasting Corporation 2007; Health Canada 2007). However, such systems have been found to compromise short-term physician office efficiency (Bossen 2007; Gamble 2006; Schuster et al. 2003), intimidate physicians and their office staff (D.A. Ludwick, personal observations and conversations with Sherwood Park, Strathcona County PCN primary care physicians, October 2007 to March 2008) and, on occasion, increase medical errors (Han et al. 2005; Koppel et al. 2005). Previous analyses (Ammenwerth et al. 2006) have shown that the implementation process is as important as the system itself. Adverse events were experienced in the early days of the Alberta EHR because EHRs change the way that organizations "speak" to each other about patient data. Similar events have happened in other care circumstances (Ammenwerth et al. 2006; Del Beccaro et al. 2006; Han et al. 2005), where a large number of concomitant process and systems changes have led to dramatic adverse events.

Similarly, EMRs change the way that clinicians communicate with each other about patient care. Where feasible, EMR implementers might wish to limit the amount of change taken on at once. This will give clinicians the chance to adjust to one change (Doctor's Office Quality n.d.; Pilling 2002; Protti et al. 2007) before an adverse event results from misunderstandings created by many other system or process changes. Do not try to use all of the new EMR features at the start. Take an incremental approach. Get billing right, then move to scheduling, then graduate to encounter notes, order entry and contraindication management. A measured approach to change allows clinicians and administrative staff to adjust to one change without being confused by the impact of another (Ball et al. 2003; Boaden and Joyce 2006; Ferris 2005; Tractenbarg 2007; Wears and Berg 2005).

Standardization and Training

Standardizing the software operations process and training staff to use those standards helped EHR organizations to capitalize on the benefits of ITIL. The training created a base level of common knowledge of best practices in software operations. By extension, standardization of clinical terminology, laboratory test result ranges, the way EMRs are used and the type of information saved in EMRs can help to realize the benefits of an EMR across an interdisciplinary team of caregivers in a physician office (Didham and Martin 2004; Elvitch 2005; Health Canada 2007; Protti 2007). Standardization and training ensure that all system users know how to use a system in a consistent manner, permitting them to anticipate what others in the organization are doing with the system.

Conclusions

The EHR, PCNs and EMRs are recent and rapid changes with significant impacts on primary care providers. These changes are challenging physicians' abilities to lead interdisciplinary teams because their long careers in small practices may not have offered them the opportunities to develop those skills. Physicians are now project managers, selecting, buying and implementing EMRs, even though they have no previous systems procurement experience. They are now computer users, software operations managers, IT network experts and privacy managers. Physicians are also leaders of PCNs, a new role that requires them to define and then execute a business plan.

Are physicians prepared to take on these roles? Certainly some are, but many are not. Do physicians see these "overhead" roles as distractions from taking care of patients, which was the original reason why they chose primary care as a career path? More lessons are expected to be learned as primary care matures through its adolescence with these reforms. Physicians might consider leaving room for their clinical colleagues to contribute to their clinics, as well as standardizing terminologies as they adopt EMRs through pilots.

Comments

Be the first to comment on this!