Consider Modularity When Selecting an EHR

October 10, 2011

Your kitchen and your EHR - they have more in common than you think.

A paradigmatic idea is one that it completely changes how you view the world. Think of the kitchen - an assortment of specialized devices are grouped together in one room for the purpose of cooking. There are “interfaces” that allow all these devices to be used cooperatively in the food preparation process. Electrical appliances plug into standard outlets. The pots and pans are sized to fit on the stove, baking dishes to fit into the oven. Most utensils fit in the sink which may have a spray hose to facilitate washing odd size containers. The kitchen is actually a food preparation system composed of components. Many are specifically selected by the cook to addresses specific requirements such as soufflés, omelettes, etc. Personally, I'd love to have a rice cooker but I can't interface it with my cupboards (translation: there is no more shelf space.) I'll bet you never thought of the kitchen that way before. Perhaps, having read this, you will never think of it the same way again. If so you have experienced a paradigm shift - the paradigm is modularity.

The modularity paradigm can be applied in many settings. One of our readers, William Braden, wrote “I am no more likely to forge a system from separate parts than I am to design my system myself. If a group of vendors puts something together and warrants that it will work, then I, as the customer, am looking at an integrated system.”

This reflects a practical, no-nonsense point of view that I share but I would respond that is worthwhile to view any action that is contemplated through the lens of the modularity paradigm because: 1) there may be unique needs that no organized group of vendors is willing or able to meet; and 2) there are good reasons to prefer a product forged from separate parts.

If you have unique needs, assembling a set of components that do exactly what you need may prove to require less effort and expense than buying an integrated product that was not designed to meet your specialized needs. The question of whether to prefer a system forged from components is a judgment call. My research leads me to believe that a product whose internal design enforces a degree of modularity and “separation of concerns” will be easier and less costly to modify as new requirements and expectations arise. Without the discipline enforced by modularity, developers have a tendency to interlink different features and create dependencies between different parts of the product that interfere with subsequent modification. As an example, the large hospital system used at my institution is being phased out after 20 years because the vendor has concluded that it is not practical to update it to qualify as an EHR.

When choosing an EHR, you have the opportunity to inquire into the design characteristics of the various products and identify those vendors that have consciously adopted an internal modular approach. Some may have even provided explicit mechanisms for incorporating external modules. Choosing a product that uses a modular approach does not mean that you, as the purchaser, have to do the work of connecting the components; a vendor can do that.

There is always something going on in the typical office that is not addressed by the EHR. Do you use a separate billing system? Does your EHR handle payroll services, time and attendance, and employee benefits? Do you have to connect to the clinical lab to print requisitions? Got a spirometer or a blood analyzer? If the answer to any of these questions is yes, than you have a system composed of components but the connections between them are not high-tech and automated, they are provided by the manual labor of your staff. This unfortunate situation is so common that if you have avoided it, you are truly exceptional.

Whatever EHR product one chooses, it is only the “system” if it encompasses every activity in which the practice must engage. If you have two or more components, your “system” is made up of those components plus glue. The reason for consciously opting for a component architecture is to increase the chance that the points of contact have been engineered to provide built-in glue.

There is something to be said for choosing a product that seems to do everything and deal with fitting it into the practice as issues arise. Regardless of which path you choose, you can be sure of two things. There will be unanticipated side-effects and some glue is going to need to be applied before the job is done. Thinking about modularity might help you avoid a pitfall or two.

For more on Dan Essin and our other Practice Notes bloggers, click here.