Separation of Concerns: The Second Step to Modular EHR

In our daily lives, we "separate concerns" all the time. For example, Los Angeles County operates a public library, an art museum, and a high-security jail. These activities could all be run out of a single, integrated facility with a single manager. It would be massive and the public might be concerned about reading a book or looking at art in close proximity to dangerous criminals. It makes more sense to keep these functions, which have very little in common, separated both physically and administratively.

With software, once the data is a separate resource, isolated from the apps (see last week's post), the next step is separate concerns. Create application modules (apps) that don't behave like nosy neighbors or mothers-in-law. To do that, think about computer applications as contracts that, among other things, specify deliverables and delineate responsibilities. These are what define the boundaries between modules.

For example, consider the hospital admissions office. Its primary deliverables are:

• Accept, admit, and transfer requests and find every patient an appropriate bed

• Discharge when requested

• Produce a census for every shift

• Respond to patient location requests with the current location

While requests may originate from multiple locations, only a few people do the actual clerical work. In our 600-bed facility, it's five or six people on days and fewer at night. The screens these six people use are, however, part of the hospital information system (HIS). It is an integrated module not because 1,000 clerks will be assigning patients to beds but because the data describing the patients and the beds is stored in a proprietary internal format and is not sharable. The only to way to access the data is to incorporate admitting into the HIS.

Most EHRs integrate computerized physician order entry (CPOE) for the same reason - it's the easiest way to have access to the data. But the primary purpose of CPOE is not data collection, it is to "automate" the requesting of what the patient needs (what were previously paper request forms), routing them more quickly and reliably to nursing, lab, radiology, pharmacy, etc., and facilitating their tracking and retrieval. Each request, which is simply a chunk of data, can be thought of as a small, self-contained database holding the requested items. That chunk, like one of your photos, can be used by a variety of apps, each designed to process a particular kind of request or step in the process.

The Pareto Principle suggests that approximately 80 percent of orders will be simple and routine - we just can't predict which ones. The other 20 percent will be unpredictable in both complexity and occurrence. Why not use a simple order-generation module for the 80 percent and a different module, aimed at the unexpected, for the 20 percent? This approach is common in many non-healthcare businesses such as restaurants and boutiques.

President Obama doesn’t eat at giant culinary institution with 600 tables distributed among 25 concessions, all linked to a billion-dollar, tightly integrated computer system that also runs the Strategic Air Command and the EPA. If he did, his lunch would probably cost $6,000. He eats at the Taylor Deli, a small community-based institution that has eight "wards" in the Washington area.

As with hospital wards, order entry and fulfillment are core activities. The cost to equip each of Taylor's "wards" with a CPOE (computerized patron order entry) system is about $10,000-15,000. The installation in each "ward" is capable of functioning as a complete, freestanding standing system (good in a disaster) that can send data to, and get data from, a shared database. John Gularson, executive vice president of MICROS eCommerce (Taylor's IT vendor) believes that the low price is partly because "a restaurant doesn't have the same HIPAA concerns as does a hospital." I believe that it relates directly to the single-minded focus of the system (think module) and the lack of entanglements with unrelated concerns. Worry about HIPAA neither invalidates the concept of modularity nor the possibility of providing something like an inexpensive, easy-to-use restaurant system for physician order entry.

If you doubt that large, integrated systems have inherent problems, consider what Computerworld and the Standish Group have to say:

"[T]he success rate for large, multi-million dollar commercial and government IT projects is very low." The Standish Group, which has a database of some 50,000 development projects, looked at the outcomes of multimillion dollar development projects and ran the numbers for Computerworld. Of 3,555 projects from 2003 to 2012 that had labor costs of at least $10 million, only 6.4 percent were successful. The Standish data showed that 52 percent of the large projects were "challenged," meaning they were over budget, behind schedule or didn't meet user expectations. The remaining 41.4 percent were failures - they were either abandoned or started anew from scratch."

To summarize, most of the details of running an admitting office, ordering, and many other aspects of running a healthcare organization concern only the small number of people who do the work, although many are affected by the products of that work. Physicians want something easy and fast that gets their orders routed, tracked, and fulfilled appropriately. There is absolutely no reason why a single large system should be saddled with meeting the needs complex requirements of every group that has special needs around which a clear boundary can be delineated. Separating concerns is critical if one wants to keep complexity manageable and costs under control. Remember, needs and, therefore, apps will change but it is the information that must live on - immutable - for decades.