The Postmodern EHR: The Data Layer

When it comes to health data interoperability, there are two schools of thought. The first believes that since there are so many systems already in place, we should agree on the exchange format (and recently the APIs) and convert the proprietary data into that format as needed. This is the preferred approach today when faced with a large installed base of megasuite solutions. The focus here is on the applications.

The second approach is standardising the health data first, building the new systems on top and avoiding the interoperability issues altogether. Sure, sometimes this is not possible. But when looking at projects spending billions of dollars, euros or pounds on new systems, I firmly believe it is a much wiser path to take. For a detailed discussion on the two approaches, see Wolandscat blog.

This second approach entails defining a data layer, which is the most important aspect of the Postmodern EHR architecture from my previous post. Why is this the most important layer? Most healthcare organisations are beginning to realise that their data is more valuable than their applications. Data has become a key asset, since good data is key to improving outcomes, managing chronic disease and enabling population health management. And it needs to be managed for the lifetime of the patient. Which application is going to last that long? What happens to health data when we switch applications?

Turning the focus from applications to data is key. Imagine if the NHS National Program for IT, instead of deciding to build a single application, set out to standardise health data? While it was unrealistic to expect that an application could cover the requirements of very diverse organisations that make up the NHS, it would have been possible to define a common data layer to support several different solutions. This would have provided trusts with the choice of application and vendor while at the same time delivering on the goal of making health data interoperable.

It would also prevent vendor lock-in by making applications easier to replace. Due to the costs of data migration, introducing a new application often means starting fresh with a nearly empty database. This is true even of well funded projects like the ongoing US DoD EHR implementation.

I tried to show why in healthcare, data is more important than applications. Now let’s see what defines the data layer:

• First, a set of common, open application programming interfaces (APIs). They need to cover the breadth of health data required by health applications, including systems as complex as EHRs. They need to be vendor-neutral and technology neutral as well.
• Second, common, open data models that are multi-lingual, comprehensive, semantically correct and modelled by clinicians. They need to be governed, enable versioning and querying. This is best achieved if they support multi-level modeling, where an underlying maximal data set can be constrained and customised for a specific use case at a higher level of the model.
• Third, support for clinical terminologies ensuring the computability of health data.
• Finally, all of the above specifications must be published and freely available for use.
• More details are available here.

Several examples are demonstrating how decoupling health data from applications by introducing a health data layer allows a multi-vendor project to succeed in building a coherent system. Three years ago, Moscow City decided to comission a few vendors to build a solution supporting the delivery of primary care to the city’s 12 million patients. By providing a single health data platform with open APIs they prevented each vendor building their own full stack, eliminating the need for data integration. The approach prevented vendor lock-in and also made it easier to add new applications as they were needed.

A more recent example is Karolinska Institute. Building their new flagship hospital in Stockholm, they understand the need of procuring a health data platform before selecting applications, including their EHR. Being a research institution they know their key asset is data, not applications.

In summary, tying data to applications makes it hard to share data between applications. This creates monolithic, single-vendor systems, incurring large integration costs and limiting agility, choice and innovation. In a recent paper named “The Future of Applications – Three Strategies for the High-velocity, Software-driven Business”, Accenture states: “What’s needed is a new way to build software—faster, flexible and more liquid—with reusable components that allow for rapid assembly of applications in support of dynamic business needs. This approach requires modular architectures…”

Decoupling data from applications by introducing a common health data layer is a big step towards such modular architectures. Remember to focus on the data first!