Termination of a Contract to Implement an Enterprise Electronic Medical Record System

Abstract

The development of integrated health care systems, the building of distributed computer networks throughout them, and the advent of easy-to-use electronic medical records for ambulatory practices combine to create a powerful argument for an enterprise electronic medical record. Potential customers need to learn from both successes and failures. Although the author could find in the literature only two reports of failures, a survey of family practice residencies revealed ten programs in which use of an electronic medical record had been discontinued. The author reports on a project that was terminated even though the technology was adequate to achieve the original project goals.

The parallel trends of development of integrated health care systems, the building of distributed computer networks throughout them, and the advent of easy-to-use electronic medical records (EMRs) for ambulatory practices combine to create a powerful argument for an enterprise EMR. The intuitive sense of this must be compared with practical experience. Vendors and enthusiasts proclaim how easy it should be,^1,2 but implementation is more like a long journey.3 Potential customers also need to learn from both successes and failures.^4,5 Although we could find in the literature only two reports of failures, a survey of family practice residencies⁶ revealed ten programs in which an EMR had been used but discontinued. We report here a project that was terminated even though the technology was assessed as being adequate to achieve the original goals of the project.

In August 1998, United Health Services initiated a project to implement an enterprise EMR that would use a distributed network to create a record for patients that was integrated throughout the enterprise. United Health Services is an integrated health care system in south central New York, which comprises three acute care hospitals, a 150+ member affiliated multispecialty group practice in more than 20 locations, nursing homes, home care agencies, and such. In February 2000, the enterprise EMR project was terminated.

This report is a summary of our experiences and an analysis of what we did right and wrong.

Planning Phase

Planning for an EMR began in June 1994 in the family practice residency, in response to limited space in the “chart room” and the emergence of a number of easy-to-use Windows-based EMRs designed for office use. A proposal was submitted to use the residency office as a pilot for the enterprise, to develop some expertise in EMR. The proposal was rejected because it did not adequately plan for deployment throughout the enterprise.

Instead, a planning committee was convened. The committee was composed of the top executives of the various entities in the enterprise and an equal number of middle managers who were responsible for the implementation of projects. This committee prioritized criteria for selecting a product. Realizing that no product on the market would meet all the criteria, major emphasis was placed on the ability to “partner” over time to develop the product and the interfaces with other products so that the full range of selection criteria could eventually be met.

While developing criteria, we had demonstrations of EMRs, ranging from very inexpensive products targeted at individual offices to moderately priced products targeted at medium-sized group practices and expensive products targeted at integrated health care systems. We judged current performance to be best in the mid-range products, giving up on our goal of having an integrated inpatient/outpatient record. However, the inability of vendors to guarantee their ability to scale up to meet the ambulatory needs of our small, integrated health care system and the technical difficulties of deploying an integrated record across our geographic area slowed our decision making.

At the 11th hour, an international technology company, styling themselves an “integrator” of health care solutions, brought to our attention a product that their research found to be the emerging technology that could support the scalability our project would require. It could also support the integration of inpatient and outpatient records. They were confident enough of the underlying technology to write into the contract performance requirements for deployment, which they coupled with payments.

Set-up Phase

Training

A project plan was developed that followed the standard approach of implementing or upgrading a commercial off-the-shelf product in use in an already automated industry. The staff was organized into “project implementation teams” on the basis of work processes that corresponded to different views of the product. Monthly meetings with senior management were planned to advise them of progress.

Training of the teams involved toiling laboriously through every function of the software, leaving them to reorganize the training to correspond to natural workflows. Consultants who had implemented other products were hired to support the work of the teams, but only one of them had implemented a part of the software elsewhere.

Reorganization

Early in the month of training, the teams recognized that the product was not mature enough to be considered “commercial off-the-shelf.” Around the same time, the lead person at the manufacturer's “beta test site” died unexpectedly, leaving us with a new role. Also, estimates of the cost to our enterprise of becoming Y2K compliant made it clear that we could not afford an aggressive plan for deployment in 1999. Rather than restructure the contract from the ground up, a decision was made to stretch out the contract, with us taking the lead in developing design specifications. The integrator picked up the cost of this added work.

Design Specification

Shifting from a work plan designed for implementation of an established product to developing specifications for development was a process for which neither we nor the integrator were prepared. Nevertheless, we were able to recognize a need for a productivity feature, which became the key enhancement for the next release of the product.

Working so closely with the software developer, we became aware of two serious problems—their under-capitalization and their failure to invest in quality processes for software development.

Re-evaluation

The upgrade of the software with our first design enhancements coincided with projections of the financial impact of the Balanced Budget Act. A regional nurse shortage and unionization effort created an inpatient environment intolerant of the stress of change. Faced with the prospect of having to shut down money-losing programs, financial officers cancelled almost all innovation initiatives. The EMR project was given the opportunity to find outside funding to keep it alive.

We invited the technical solutions officers of our hospital association to a demonstration of the newly released version of the software. Our demonstration convinced them that the product had significant advantages for an enterprise solution, compared with other products in the market. More important, it demonstrated to the teams the significant progress we had made toward acquiring the product we wanted. Unfortunately, the technical solutions officers stopped their program of investing in emerging technologies.

Bankruptcy of Software Developer

Without fresh investment, and with their largest customer unable to keep contracted funding flowing, the software developer was forced into bankruptcy.

What Went Wrong?

Financial Pressures

Financial pressures started almost as soon as the contract was signed. Financial losses at the rural hospital and the multispecialty group practice caused each to withdraw from their financial commitment to the early phases of the project. Higher costs of Y2K compliance and bigger cuts caused by the Balanced Budget Act erased the financial resources on which the project depended.

Unwillingness to Change Paradigm

Development and implementation work plans need to be fundamentally different. Development work plans need to focus on processes to arrive at consensus, whereas implementation plans need to focus on achieving defined milestones. Development contracts should be drastically cheaper in exchange for requirements development and testing. Although our integrator could have facilitated a development contract as well as an implementation contract, it took too long for the change to be recognized and addressed.

Failure to Task Senior Management

Having sold the project as an implementation, the integrator failed to recognize the extent of the work redesign efforts needed by the rest of the enterprise to enable the implementation of the technology. Senior management failed to recognize how the project is merely an enabling technology for fundamentally reorganizing the way we do business. When serious problems developed with the project, monthly meetings with senior management were cancelled, so the problems were not openly discussed.

Worse, from the start, senior managers were not held accountable for facilitating the change-management efforts needed for smooth implementation. Having not had to articulate the importance of this change management outside the context of the project, they lacked the personal investment in the objectives of the project that would have made it possible for the project to survive the budget cuts.

Failure to Empower Physician and Nurse Leads

Responsibility for implementing the project was given to a physician and nurse who did not have administrative positions in the organization. Although this was done to have people who could dedicate enough time to the project to make it work, it also meant that there was no one dedicated to the project to defend it during the budget bloodletting. When unrelated crises in the organization distracted those in positions of authority, crucial decisions were not made. This is the most important reason that the contract was not reworked when the implementation teams noted that the project was, in reality, a development project.

Integrator Inexperience in Health Care

Although several EMR products have been around long enough to be considered implementations for group practices, neither our integrator nor the consultants were able to read the signs quickly enough to make corrections. Although we and our integrator had done “due diligence” on the financial condition of the vendor, we were unprepared for the seriousness of their financial state. The integrator lost confidence in the product's ability to survive long-term. By the time our demonstration for outside funding renewed the integrator's confidence in the product, senior management's confidence had been damaged irreparably.

What Did We Do Right?

Planning Process

Although the planning committee took 18 months to do its work, this was time well spent. The vision of what we want to accomplish is pretty much intact, even if our sense of how to achieve it is somewhat dimmed.

Product Selection

Despite termination, if we had the resources to do this project now, we would, with broad consensus, go with the product we chose. Assuming that it was purchased by a competent developer, we are confident that it would meet our expectations.

Use of an Integrator

Although I was dubious about having an “integrator” involved in the project, they were able to provide a long list of specialized IT services that most vendors lack. Among other services, they could improve the efficiency of data structures from legacy systems, configure workstations in a variety of settings, evaluate and make recommendations for improving information technology infrastructure, design RF LAN, and organize the development of design specifications.

Slowing of the Initial Steps

The initial planning will take longer than you or the vendor think! The vendor of each product we evaluated told us it could be implemented faster than it was implemented at any site we visited. The critical pathway of the technology will always be shorter than the critical pathway of your change-management efforts.

Discussion

The Project Is Developmental

Perhaps the most important lesson to be learned is that all EMRs are “in development,” at least in regard to their ability to serve an integrated health care system. It is essential to note where development is needed, anticipate its cost, and make sure there is a mechanism to address it over time. Interfacing clinical data between disparate systems will be impossible until a robust standard nomenclature is in use. Until then, the best we can hope for is the capacity of a new “integrated” system to read information from the existing systems.

Technology Is the Easy Part

In considering the costs of the system, we did not adequately factor the cost of change management. The technology is no more than half the cost and represents much less of the effort of the implementing enterprise. Although the “implementation team” will be the obvious and budgeted personnel cost, the more important costs are those associated with the change management. Of course, the costs of not managing the change are probably greater. Not planning ways to deal with the change may create a barrier that an organization cannot negotiate.

If This Isn't the Core Strategic Project, Don't Start It

Although an empowered team will be needed to lead the customization and training for your enterprise, the managers who are running the enterprise during the implementation will necessarily be responsible for the change management. Therefore, they must be integrally involved with the implementation team to:

• Identify priorities, develop metrics, benchmark, and assess the success of the project

• Identify processes that need to be changed to institute the changes beforehand, so that the project is seen as the enabling technology, not as the cause of the change

Implementing an enterprise EMR is big. It involves, in a fundamental way, every part of an integrated health care system. It requires the active participation of the decision makers who drive the costs of the organization—the physicians. Therefore, it should not be seen as merely another information services project. It should be the strategic initiative for whatever period of time it takes.

It Will Take Time

Other technology problems will come up during the process and compete for both financial and human resources. Some of these “diversions” will add to the value of the whole, some may be resource neutral and integrate with the project, and some will just not be worth considering until it is accomplished. Someone in authority needs to have a clear vision of the goal and be able to clearly articulate this to the team of decision makers on a regular basis.

For most organizations this person will be the chief information officer. Vision and the charisma to inspire others with that vision are key requirements for this person. Technical brilliance is not necessary, although competence and eagerness to embrace innovations are. This person should be very skilled at understanding and measuring how technology improves the work of the enterprise.

Working with Integrators

Technical performance can be delivered either in-house or by an integrator who deals with enough of the information service applications of the enterprise that they truly understand how they combine to build a whole. Many organizations will not be able to attract the quality of people needed to evaluate the breadth of information technologies that are needed for an enterprise. This seems to be a ripe area for outsourcing to deliver better value than all but the largest and richest integrated health care systems can afford.

Working with Vendors

There are too many EMR vendors in the market for all to survive. All the viable ones must have an “internet strategy” that will radically change the look and performance of their product over the next few years. Therefore, most organizations will need to deal with at least one major change in the product they chose. Make sure that you learn and document your work redesign processes. Vendors should share their “long-term” development strategy (two years!) with you and assertively keep you up to date, at least annually. This will give you enough lead time to make the inevitable transitions smoothly.