ElectronicHealthcare

ElectronicHealthcare 1(4) October 2002 : 3-4

The Editor's Focus: Building on a Legacy

Michael Guerriere

Abstract

As we ponder the task of implementing electronic health records for the Canadian population, the challenge of integrating legacy systems quickly takes centre stage. Billions of dollars have been spent over the past couple of decades implementing clinical systems of various descriptions. They use every architecture, operating system, developmental environment and vendor platform imaginable. Add to that the absence of standard nomenclatures in common use for most clinical information and you have the electronic equivalent of the Tower of Babel.
The Canadian Standard railroad gauge (distance between the rails) is 4 feet, 8.5 inches. That's an exceedingly odd number. Why was that gauge used? Because that's the way they built them in England, and the U.S. railroads were built by English expatriates.

Why did the English people build them like that? Because the first rail lines were built by the same people who built the pre-railroad tramways, and that's the gauge they used.
Why did "they" use that gauge then? Because the people who built the tramways used the same jigs and tools that they used for building wagons, which used that wheel spacing.
Okay! Why did the wagons use that odd wheel spacing? Well, if they tried to use any other spacing the wagons would break on some of the old, long-distance roads, because that's the spacing of the old wheel ruts.

So who built these old rutted roads? The first long-distance roads in Europe were built by Imperial Rome for the benefit of their legions. The roads have been used ever since. And the ruts? The initial ruts, which everyone else had to match for fear of destroying their wagons, were first made by Roman war chariots. Since the chariots were made by Imperial Rome they were all alike in the matter of wheel spacing.

Thus, we have the answer to the original question. The Canadian standard railroad gauge of 4 feet, 8.5 inches derives from the original specification (Military Spec) for an Imperial Roman army war chariot.
Now note that Imperial Roman chariots were made to be just wide enough to accommodate the back-ends of two war horses. So, the next time you are handed a specification and wonder what horse's ass came up with it, you may be exactly right.

As we ponder the task of implementing electronic health records for the Canadian population, the challenge of integrating legacy systems quickly takes centre stage. Billions of dollars have been spent over the past couple of decades implementing clinical systems of various descriptions. They use every architecture, operating system, developmental environment and vendor platform imaginable. Add to that the absence of standard nomenclatures in common use for most clinical information and you have the electronic equivalent of the Tower of Babel.

It is very tempting to want to sweep away all of this confusion in favour of a single integrated system. Rather than taking on the challenge of integrating all of these disparate systems, why not start again and "do it right"? As attractive as this option seems, it is impractical for a whole host of reasons. First and foremost, it is impossible to replace every system in operation simultaneously. Hence, you deal with a heterogeneous environment for the duration of the replacement process, likely a period lasting several years. During this time, existing functionality is being replaced by the new system. Users are retrained, databases are ported between applications and large amounts of capital are expended, all without significant increases in functionality. Several years down the road, when existing systems are replaced, attention can be turned to adding functionality. In the end, a great deal of an organization's resources is spent without meaningful improvement in functionality. Hence system replacement is difficult to justify in terms of costs when compared with projects that immediately improve the functionality available to users.

The second weakness of the single-system strategy is the overwhelming dependence on a single vendor. In the fast-paced world of software development, vendors come and go as new technology innovations wash across the industry. From an overall health system point of view, a multi-vendor environment represents a lower risk strategy as the failure of a single vendor affects only part of the information infrastructure. As vendors fail, systems are replaced with leading, commercially available products. This process of renewal allows the health system to upgrade its systems in a gradual and manageable way. This would not be possible if only one vendor predominated.

The third weakness of a single-vendor approach is that no vendor does it all. The spectrum of clinical system functionality needed by the health system is vast and rapidly evolving. Different care-delivery environments, such as primary, acute, palliative, rehab, chronic, community and specialty, all have different system needs. Also, different diagnostic departments have substantial, specialized requirements to support their operations. Given their choice, each would choose a different "single solution" vendor.

Note that I am not arguing that we should not attempt to rationalize the myriad systems that exist in healthcare today. Some simplification of platforms and vendors would greatly assist in our efforts to establish population-based EHRs. Rather, I am arguing that existing systems with acceptable functionality and strong support from financially healthy vendors should not be replaced to avoid addressing the integration challenge.

And this challenge, so difficult to address in recent years, is starting to look a lot more manageable. We can thank the Internet and associated web technologies for a whole host of tools that will help us to accomplish this task. The CareConnect article in this edition outlines how the Vancouver Coastal Health Authority (VCHA) plans to use these tools to improve clinical practice in the region. It is an excellent summary of the various strategies available to address the integration challenges inherent in constructing a regional EHR. This approach will allow the VCHA to leverage their substantial investments to date while moving toward a more comprehensive view of clinical information for all clinical professionals.

As vendors fail, as they inevitably will, we will have to replace current systems with newer technologies and architectures. This will give us an opportunity to move to common systems, reducing the total number of vendor systems we have to manage and support. This will happen fast enough. In the meantime, we should go about improving functionality with the systems we have available and integrating them to achieve the EHR vision.

As the rail gauge story shows, established infrastructure has a way of constraining your freedom to plan future development. But look at the progress that has been made! Despite the surprising constraining influence of the wheel ruts created by Roman chariots on modern railway standards, society nevertheless moved from horse-drawn power to the locomotive! The cost of each incremental development is much less if you don't have to go back and rebuild the infrastructure installed before. Although our legacy systems will challenge us to innovate and build, they will become pillars of the integrated EHR, courtesy of the Internet.

Comments

Be the first to comment on this!

Note: Please enter a display name. Your email address will not be publically displayed