Everyone wants digital health systems that interoperate. Virtually every day I see some article about the subject. They all speak to the challenges and offer some solutions, but we have not been able to truly crack open the core of the problem. Why is that? How should we think about this differently? In my view, the challenge of interoperability among digital health systems is akin to a grocery store trying to predict the multitude of permutations and combinations its items can be used for to create a personalized meal.
One of the most referenced definitions of interoperability is from the Institute of Electrical and Electronics Engineers (IEEE). It is the “Ability of two or more systems or components to exchange information and to use the information that has been exchanged.”1 I truly admire the standards work to modernize our approaches to interoperability, particularly the HL7 FHIR standard. It is a great advance over HL7 v2 and v3 including HL7’s Clinical Document Architecture (CDA). The FHIR documentation on the HL7 web site has the following: “[FHIR] leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.”2 Notice that in both references you will find the word exchange. That one word is not only the solution to interoperability it is also part of the problem. There are many times when our digital health systems must exchange data as message(s) or document(s). The challenge is that exchange requires a well-defined, pre-packaged definition of the information exchanged between systems (e.g., interoperability specification). The key issue with pre-packaged interoperability is that we cannot anticipate and design for all of the possible use cases in health care.
For that reason, we need to rethink the paradigm for interoperability and embrace others that don’t constrain us to an exchange of information via messages or documents. I often like to refine my solution to an issue using real world metaphors. For this issue, we need to think like a grocery store and how it caters to the needs of the consumer.
The primary role of a grocery store is to sell food. It puts food products on the shelves and in bins, refrigerators and freezers. As consumers we go into the store (physical or virtual) with our list and fill our cart with the things we want to eat. There is one thing a grocery store does very well — it curates and makes available food products to its consumers which form the basis for their food consumption and recipe needs. The food products come in standardized forms and with standardized labels that can be brought together in many ways to satisfy different consumer needs.
One food type in grocery stores is the prepared meal — I just heat and serve or use it “out of the box.” This is akin to the exchange model of interoperability where I want systems to connect “plug and play” but using the data I pre-package in anticipation of a use case’s need. Just like the prepared meal, exchange-based interoperability requires a well-defined specification that has to be defined in advance often by consensus, then curated, adopted and tested.
As a “foodie” my needs are more complex. My grocery store selections need to be personalized based on each of my recipes. The grocery store’s prepared meal offerings will not suffice. I need specific fresh ingredients to create the multi-course dinner that I am planning. No grocery store can anticipate all of the possible permutations and combinations of these core ingredients, or how they will be used. For example, flour is used to make pancakes, bagels, bread, croissants, pizza, etc., and hundreds of variations of these. Grocers do not know in advance when these ingredients will be needed or how much will be needed. So what do they do? They stock the shelves with the basic ingredients.
So what does this metaphor have to do with interoperability? It illustrates a new interoperability paradigm we need to embrace and implement—an access model. An access model is one where the system(s) that need information get just what they need, when they need it, from the original source system or an intermediary.
One of the best ways to implement this approach is via a data platform of patient-centric personal health information. Data platforms are ideally suited to support a data access paradigm. They are a modern way of bringing producers and consumers together for new value creation. In this case the core ingredient for value creation is personal health information. Health oriented data platforms are emerging as products and should be considered as enablers for this new approach to our systemic interoperability challenges. The data platform is analogous to the “grocery store shelf space” for all of the standardized clinical information one needs to have accessible about a person over time, in other words the longitudinal record of key clinical information that has value over time. Digital health solutions use the platform’s standardized application programming interface (API) to access just the ingredients (e.g. data) it needs to do its job, when they are needed. Using this paradigm one can support virtually any clinical use case’s data needs. This approach does not require one to pre-define an interoperability specification.
For an access paradigm to work we need the “grocery store shelves stocked.” We must curate and make available clinical information, just like the grocery store does with food. When it comes to interoperability in health care the most important thing, in my opinion, is the clinical content. We need standardized clinical information (e.g., detailed clinical models) that we all agree on, that experts (e.g., clinicians) curate. Therefore, solutions which are the original source of data need to either make it accessible directly or need to write it into the data platform for authorized access when needed. That clinical content forms the basis for the information utilized by inter-connected digital health solutions, for both the exchange or access interoperability paradigms.
As designers and implementers we have to pick the interoperability approach that is most fit for purpose. Many health care use cases are best supported by the exchange of information. One example that comes to mind is order entry which often has to be facilitated across information systems. Let’s say I want to order a diagnostic test. The clinical and demographic information of the patient for that order needs to be exchanged between systems. It is typically a well framed use case. Therefore it can be defined as an interoperability specification with associated standards, developed in advance by experts, trusted by the marketplace, implemented in systems, tested for conformance and used seamlessly by end users.
On the other hand, solutions as wide ranging as chronic disease management, clinical decision support tools, risk calculators, predictive analytics, precision medicine, just to name a few, are all like different recipes requiring their own unique ingredients. A health information exchange paradigm will never be able to support all of these needs in a timely fashion because one can never anticipate or design specifications for all of them. No international standards body or national digital health interoperability-setting agency can anticipate all of the possible combinations of the core ingredients (i.e., standardized clinical information) that are needed. I suggest they focus more of their efforts on establishing well-defined clinical models, with strong terminology bindings and APIs to read and write that information to and from data platforms or between systems.
In conclusion, what is the right paradigm for your digital health solution that requires information that it does not currently hold? Is it most like the “prepared meal” model? That one is akin to the exchange paradigm which requires a well-defined interoperability specification. Or is it more like a list of ingredients for the multi-course meal which may be a once in a lifetime use case? That one is akin to the data access paradigm. Both are made possible if the “shelves are stocked” with high quality and standardized clinical information. The time is right to start enabling the new data access paradigm using a standards-based data platform to support a broader set of emerging needs. This approach will alleviate the interoperability challenges we have been facing for decades and are still struggling to solve.
Have a comment about this post? We’d love to hear from you.
1IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990
Dennis Giokas is Chief Technology Officer for Infoway and heads up the Innovation Ecosystem Group. The group is chartered with establishing the vision, thought leadership and investment in digital health ecosystems and solutions in new areas of opportunity.