The Untapped Potential of Modular EHR Design

Implementing an EHR is a lot like running a relay race. Each lane is assigned to a different team and the baton is passed from one team member to the next at the end of each lap.

In healthcare, the race should not be to win an incentive payment. It should be to get an organization to a finish line far in the future having met the clinical and business needs of all stakeholders including the patients - and to do it in a way that does not drive healthcare costs up and the staff crazy.

Figuratively, each lane in the EHR race is occupied by a system or module that the organization has implemented or intends to implement. The end of each lap signals the point at which a system or module must phased out and replaced with something different (better?)*. In this race some teams start with a handicap but it is not like the ones in sports - here, low-priority teams (functions) are forced to delay their start, sometimes for years, while the high-priority functions are given a head start so they can be "stabilized" (meaning that you finally understand their true capabilities and have either given up, reconfigured, or worked around their limitations).

It is the negative impact that these handicaps have on the effectiveness of the organization, and on the morale of those teams that are forced to delay their run, that distinguishes organizations installing monolithic, integrated systems from those that have opted for a modular approach.

There are three major advantages to a modular approach - a term that refers to the design of any system composed of separate components that can be connected together - and one drawback.

Implementing function-specific modules allows work to proceed in parallel that would otherwise be forced to wait for all the high-priority functions to be completed. This avoids permanently handicapping parts of the organization that will always be low priority because of size, etc.

Modularity makes it possible to upgrade one module without being required to abandon an entire system (and forcing the low-priority functions back to the starting line). We all know that appealing gadgets, and first dates, can quickly lose their luster. When that happens it may be time to try again but, with an integrated system, that option is precluded.

Modularity lowers the impact of a failed module or one that proves to be useless. One can try again without disrupting the racers in the other lanes.

The drawback to modularity, like the drawback to the "ultimate driving machine," is that you have to do the driving and navigating. Choosing an integrated system is more like taking a plane. You pick a destination, sit back and hope the pilot (vendor) gets you there safely and on time. Their agenda becomes your agenda, their priorities become your priorities, their business processes become your business processes. If the ride is bumpy, the plane malfunctions or the pilot is forced to land at a different airport well ...that's life.

In order to get the most out of any technology, the management must understand its strengths and weaknesses. Goethe said: "He who does not know the mechanical side of a craft cannot judge it." I've heard too many CEOs mouthing the platitudes fed to them by vendors for me to believe that the typical CEO has a technology-driven vision for the future. By choosing an integrated EHR, an organization effectively delegates decision-making authority over numerous subsidiary decisions to the vendor that would otherwise merit careful consideration. Short-circuiting that process denies the organization the opportunity to discover other changes to the organization might need to make to fully leverage an EHR's potential.

The importance of modularity has been appreciated for a long time and by people with diverse interests because it makes possible what software people call "Separation of Concerns".

In the United States, separation of concerns underlies our federated system in which some power is exercised centrally and the rest is reserved for the states. As "separation of powers," it gives each branch (executive, legislative, judicial) certain duties and substantial independence from the others.

Robert Frost said: "Something there is that doesn't love a wall... but … Good fences make good neighbors."

Microsoft says (and they ought to know): "When getting started with your design, keep in mind the key principles that will help you to create an architecture that adheres to proven principles, minimizes costs and maintenance requirements, and promotes usability and extendibility." The key principles are:

•Separation of concerns. Divide your application into distinct features with as little overlap in functionality as possible. The important factor is minimization of interaction points to achieve high cohesion and low coupling... .

•Single Responsibility principle. Each component or module should be responsible for only a specific feature or functionality, or aggregation of cohesive functionality.

•Principle of Least Knowledge. A component or object should not know about internal details of other components or objects.

•Don’t repeat yourself (DRY). Specific functionality should be implemented in only one component; the functionality should not be duplicated in any other component.

•Minimize up-front design. Only design what is necessary... If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. "

Today's EHRs were either designed when separation of concerns was not feasible or by those that should, by now, know better. I'm reminded of a popular song with the refrain: "Oh, when will they ever learn?"

* It's not too soon to start working on your exit strategy from what you have now. Better yet (if possible) defer your next purchase until you have clarified what needs to be done to decommission it.