Microservices for Health IT?

Hospitals and doctors offices are busy places. When computer systems are used in the delivery of patient care, any unreliability or lapse in availability is a serious problem. There are always backup procedures (such as paper records), but they are just that: a backup. Looking at it a different way, the electronic health record (EHR) must never be a hindrance to the health care professional. In a recent post, I discussed how systems that are time consuming or difficult to use can cause problems rather than solve them. But if a system is unavailable when it is needed, or if it fails to work correctly, it is most certainly getting in the practitioner’s way! Worse, unreliability can lead to errors, and can be a patient safety issue. Lapses in availability can potentially delay care, or at the very least, impose an additional burden on healthcare professionals.

So, what is to be done? It is tempting to think that trying to nail everything down, demanding that every system be specified in excruciating detail, with centralized control being maintained at all stages of the process, is the answer. Unfortunately, we’ve tried this and it just doesn’t work. For simple systems it is feasible, but as they grow in complexity, the top down approach to design starts to break down. Eventually, we burner into the proverbial million dollar hammer. A simple component that becomes so expensive that no one will want or use it. Worse, the cost is an artifact of the process: it’s not something that its really justifiable, no matter how tight the specifications, or the potential for catastrophic failure if we get them wrong.

We’ve talked about the dangers of tight coupling and low cohesion: the phenomenon in which individual components of a system become progressively more intertwined (coupling), and are cease to have a single, well-defined purpose (cohesion). The better we are able to stick to the principles of loose coupling and high cohesion, the more reliable our software will be.

But wait. Isn’t it true that a medical record system will have to integrate ADT, workflow, terminology, billing, and so forth. Worse, all of these systems are linked together. Is it even possible to build a loosely coupled EHR?

To approach this question, let us consider another concept: the property of being monolithic. A system is said the be monolithic if it is conceptually one piece. From one perspective, monolithic systems can be tightly integrated, and this can be a good thing when the integration occurs at the logical (“from the outside”) level. But monolithic systems can easily become brittle. A failure at one point can lead to cascading errors that will eventually bring the whole system down. This is not to say that a monolithic system cannot be well designed, but over time it will grow, problems will be corrected, new features added, and changes in technology and healthcare may require that the system be used in ways that the original designers never imagined. This is how problems begin to creep in, and even the best of systems will become increasingly difficult to maintain. 

Software architecture has seen several attempts to address this problem. Each building on the ideas introduced by its predecessors. 

The oldest is structured programming and top down design. Here, the idea is to decompose a system by building subsystems that may consist of smaller subsystems, and so forth. Conceptually, each component will delegate tasks to its subsystems, and they “report up the chain”, creating a top down delegation of responsibility. This approach worked well for many years, but eventually started to break down out of sheer complexity. 

This led to the next approach, object-oriented programming ( OOP), and the design approach known as object-oriented design (OOD). Here, the idea is that a program is broken up into “objects” that include both data and logic. Objects may come into existence and disappear during program execution. Moreover, they communicate with one another through a process known as sending messages (also known as method calls). In a typical healthcare system, objects may represent patients, progress notes, orders, lab tests, results, family history, problem lists, entire charts, and more. It all sounds chaotic, but it works, and object-oriented programming has proved to be a highly successful methodology. 

It does start to run into trouble, though, when the entire system cannot feasibly be built at once or run on a single computer. This leads to an approach where different system components provide services to other systems of which they may not even be aware. A good example is a master patient index (MPI) which maintains an authoritative list of patients and their associated medical record numbers. The MPI will create new records when previously unknown patients are registered, and will allow systems to look up a patient’s MRN in various ways. Obviously, this all requires authentication and authorization, but beyond that, the MPI may not have much built in knowledge of the rest of the EHR system. Another example is a terminology server that is able to accept a description of a concept (e.g., viral meningitis) or an ICD-10 or SNOMED CT code, and return matching codes and other information. 

When services services are independently implemented, possibly even running on entirely different machines, this is an example of what’s come to be called sevice oriented architecture (SOA), and it can rightly considered to be an extension and generalization of object orientation. There are several possible mechanisms for communication in SOA (for example, message passing, CORBA, SOAP, and REST), but the specific technology used is less important than the conceptual approach, and is not part of the definition of SOA. 

Microservices are where agility meets SOA. Individual services under SOA can be very complex, and difficult to implement and manage. The idea behind microservices is to develop independent services of very narrow scope. Ideally, it should be possible that develop a microservice in one or a few weeks (a sprint), and the microservices should be easy to replace or reimplement. Teams working on different microservices ought to be able to work independently. 

That almost sounds too good to be true, but companies like Netflix and Spotify have successfully deployed microservice strategies, so it can be done, and to good effect. Agile development probably sounds utopian t those steeped in the waterfall approach to software development, too. But, to my knowledge, microservices haven’t really caught on in healthcare – at least not yet.