The Postmodern EHR: What are the Enablers?

In my previous article, The Postmodern EHR: What can Health IT Learn from the Evolution of the ERP Market?, I stated that the best-of-breed approach had failed mostly due to the difficulty and cost of integrating disparate systems. Integration was initially achieved using point-to-point connections to exchange data increasing costs and complexity exponentially as new systems were added. Enterprise application integration topologies like hub-and-spoke were introduced to tackle this problem. Finally, web services, messaging and the enterprise service bus emerged and are still the norm today. Despite these advances, the cost of integration is still prohibitive and the reality is that most systems exchange only a small subset of data.

This becomes apparent when looking to tap into clinical data in a provider’s messaging infrastructure only to realize that most of the data being exchanged is administrative. But exchanging data is only one piece of the puzzle since solving integration at this level alone is not enough. For postmodern electronic health record (EHR) systems to replace monolithic solutions, applications must enable integration at several levels. To see how we can make integration between systems easier, we need to take a closer look at the architecture of the applications themselves.

Traditional monolithic EHR architectures focus on stability and standardization at the expense of agility. Along with innovation, cloud based deployment and integration of things, agility is the main differentiator when describing the requirements of application architecture for the Postmodern EHR. Achieving agility is impossible for the vast majority of healthcare applications today as they are an inseparable mix of code for user interface, decision logic, workflows and data definitions.

New architectures promote agility and reuse by turning the applications inside out and layering the four types of programming into portals, rule engines, process engines and XML data. Let’s look at some examples, layer by layer:

User interface: There are several compiling arguments as to why the user interface should be a separate layer. Portals and user experience on the web have replaced single-function user interfaces as the primary means of delivering user access. For example, a portal can aggregate the services and data into a single patient view. It also allows several implementations of the user interface based on different use cases and end-user devices while reusing the layers below.

Decision Logic: – Rule engines allow easy access to decision points in a system that might need to change from time to time. The rules themselves are easier to understand and change allowing for centralized governance while exposing them through interfaces enables reuse. For healthcare, think of clinical decision support functionality which can be developed and coded by clinical staff and made available to all applications.

Workflows: Using Business Process Management (BPM) engines, workflows can be defined, managed and modified by people who understand them best. Explicit process engines allow us to form multiple process flows to solve a given set of problems. Healthcare is heavily dependent on the coordination of workflows, activities and tasks, which is precisely what process engines do best.

Data: Decoupling data from the rest of the application enables the reuse of this data within and among applications. It allows domain experts to define the way data is modeled and done right, it enables data services that are vendor-neutral. Think about PACS systems today – all follow standards making it possible for any application to access an image regardless of which application produced it.

To summarize, separating application code into these four layers offers several advantages.

First, each layer can use the most appropriate tools and technology to develop the required functionality. This allows for better use of experts in each of the domains producing better software. It speeds up development by making code easier to develop, understand and change.

Second, layering enables better reuse of functionality while at the same time helping to centralize governance. Together, this is what enables agility – simply that the more options you have for altering the way a system works without making it too fragile, the more likely you are to be able to make the proper changes when they are necessary.

Finally, when each layer exposes its interfaces (APIs), it makes it possible to integrate not just with the other layers, but with other applications as well. This is key, since a postmodern ERP will have to allow easy integration at each layer in order to be successful!