By: Charlie Harp
In March of 2009, I wrote a blog post called ‘Why is Interoperability Important?‘. At the time, I was sure that, like me, the rest of the industry could see that in order to accomplish the objectives being defined around meaningful use and care coordination, we would need to elevate our thinking. We would need to accept that quality patient care required a holistic view of information that could not be satisfied by a single application. This would require us to rethink how we share information and evolve our approaches to improve the fidelity of data being exchanged and reduce our dependence on human mappers. To that end, Clinical Architecture set about creating a platform that would address this problem, which would allow the industry to meaningfully interoperate, share data and focus on making the most of the bigger picture that this new level of awareness would provide. As it turns out, eight years later, not everyone thought like I did.
The 155 Million-dollar Cautionary Tale
If you work in the healthcare IT industry (and do not live in a cave) you have probably heard about the lawsuit and judgement against a prominent EHR vendor regarding their failure to truly satisfy EHR certification criteria.
If you have not, you can find the full text of the complaint here. The essence of the complaint was that their platform did not actually meet the criteria for several meaningful use requirements. Several of the specific issues described focus on semantic interoperability, concluding that the software had been hard-coded to address only the codes that were being tested. This kind of approach is colloquially referred to as ‘checking the box’.
I don’t know much about this vendor, as we have never worked directly with them. Unfortunately, their situation is something that I could have predicted would happen to someone, sooner or later. Allow me to explain why.
First, many people do not understand true interoperability, and those that do rarely give it the attention that is required to do it properly. So, let’s start there.
For the sake of definitions, let’s describe interoperability as the meaningful exchange of information between a sender and a receiver.
In order to interoperate as a sender, you need to do the following:
- Extract relevant patient data from your application for a given patient
- Translate the local codes used to represent patient data into coded information using an accepted “standard code system” – semantic interoperability
- Put the coded information into an accepted “standard message container” in this case a CCDA document – syntactic interoperability
- Push the data to a transport medium or through a transport mechanism – physical interoperability
In order to interoperate as a receiver, you need to do the following:
- Receive the data from a transport medium or via a transport mechanism– physical interoperability
- Parse the “standard message container” and extract the coded information– syntactic interoperability
- Translate the coded information into local codes that are recognized by your application– semantic interoperability
- Integrate the data into your application for provider review
Seems straightforward, right?
If we go back to the complaint, the issues that were highlighted relative to interoperability were not about physical or syntactic interoperability. It was not that they were not sending CCDs, nor was it that they were not formatting the CCDs correctly. The main issue was that they were not accurately transcoding the local terms to the standards code systems that are required for meaningful use data exchange. The failure was a lack of true semantic interoperability. Furthermore – when it comes to the facets of interoperability, physical and syntactic interoperability can be solved once (assuming the formats and medium remain constant). Semantic interoperability is not a ‘one and done’ type of problem. It requires an active, dynamic process and constant vigilance if you intend to do it well.
Why did this happen? More importantly, why is it likely that what happened to this vendor was not an isolated case? Allow me to share an interesting tangent that might provide some insight…
A Theory of Human Motivation
In 1943, a psychologist named Abraham Maslow wrote a paper about human motivation. In this paper, he described a hierarchical list of priorities that we know today as ‘Maslow’s Hierarchy of Needs‘. This hierarchy describes a prioritized scale of normal human motivation.
- The foundational and primary need is survival. Most humans will do what is necessary to survive before addressing other less critical needs.
- The second level of need is safety. Once you satisfy the basic needs of survival, you look for ways to secure yourself to increase the likelihood you will continue to survive tomorrow. This could range from shelter, to financial security and health and wellbeing.
- The third level of need is social belonging. This is the need to be part of a community. Humans are social animals and most of us feel the need for friendship, love and acceptance.
- The fourth level is esteem. This is the need and desire to feel good about yourself and valued by others.
- The fifth level is self-actualization. This is the need to ‘be all that you can be.’ In other words, realize your full potential.
- The sixth and final level is self-transcendence. This is the need to transcend beyond your needs and ‘make the world a better place’, so to speak.
For most of us these needs, and the priorities they are associated with, strikes a chord of truth. It is a fairly accurate portrayal of how humans operate in their daily lives.
I am no psychologist, but I would like to postulate the following empirical formula.
For any given perceived need, the probability of a human acting to satisfy the need it is relative to the Maslow level of need it satisfies, coupled with the cost of the task (in terms of money, effort or Maslow level risk to other needs).
As an illustration, a few summers ago I wanted to purchase a new motorcycle (which I still bucket under self-actualization…) but unfortunately a clay sewer pipe in my backyard collapsed, causing all the toilets in my house to cease to function… I assume you can guess which ‘need’ was ultimately satisfied.
If we are in general agreement to this point, then it stands to reason that software companies, which are made up of humans, would be motivated by the same needs, following the same priorities and our empirical formula should apply. Right?
Using this basis, let’s talk about where certain actions rate from the perspective of a hypothetical software application:
|Action||Perceived Maslow Need Level||Cost|
|Fix critical product issues||Survival||High|
|Enhancing software to compete with others||Safety, Social Belonging||High|
|Develop innovative features and capabilities||Safety, Esteem||High|
|Accurate lab result ingestion||Survival||Moderate|
|Accurate receiving CCD data from others||Self-Actualization||High|
|Accurate sharing CCD data with others||Self-Transcendence||High|
|Satisfying Meaningful Use Criteria – (pass test)||Survival||Moderate|
The problem we have in our industry is that true interoperability is not perceived as something that is critical to our survival. After all, sharing data with another application does not benefit the sending application directly. The application receiving it likely does not trust the information coming from other systems anyway. In addition, accurately sharing information with a competing application is an obvious risk relative to ‘security level need’ risk. Given the lack of perceived benefits relative to an application needs, it would be difficult to justify the high cost of true interoperability.
The Letter of the Law
When faced with an imperative, like MU certification, which may not be perceived as a high priority need and carries a prohibitive cost, it should not be a surprised that a human-driven entity might rationalize the ‘letter of the law’ as opposed to embracing the ‘spirit of the law’. I am not endorsing it or excusing it. I am just trying to understand and explain how it might happen. The question is, is what happened last week an isolated incident?
Considering that the individual that instigated the complaint is set to receive a $30 million dollar payout, we can expect that others are embarking on infraction treasure hunts as I write this post.
On a personal level, I am never happy when I see another person or company going through something painful, especially when it could have been avoided. You can’t build a complex product in healthcare without facing tough choices on a regular basis. We all struggle with the things we must do and the things we would like to do and it is always easy to see the issues when you have the benefit of hindsight.
Is there anything good that can come from this? Perhaps. If the industry’s perception of true interoperability is elevated in Maslow’s hierarchical needs to survival that would be good.
I still feel the way I did in 2009. If our collective goal is to do our part in providing an environment where providers and their organizations can provide optimal care for patients and improve outcomes, true semantic interoperability has always been about survival. Without semantic interoperability decision support, clinical aggregation, cohort analysis, population health and all other analytics are riddled with uncertainty. The patterns we see, the quality of the decisions we make and actions we take are dependent on the fidelity of the information collected.
We have been promising smarter systems, better coordination of care, reduced costs and improved outcomes for over a decade, and yet, interoperability is still healthcare’s Achille’s heel.
True interoperability is not just a map we look at once a year. It cannot be solved by mandating standards. It cannot be solved by the human beings toiling away in modern day sweatshops.
True interoperability is dynamically and accurately exchanging information with other applications based on the meaning of the terms being exchanged, not just a code. Like many things in the practice of medicine, it is not something you can cure but rather something that needs to be managed. Information in healthcare is a living thing. It changes. Concepts come and go, split and merge. We discover new concepts at the edges, not just the center. Our approach to interoperability needs to accommodate that.
At Clinical Architecture, we built Symedical® to manage semantic interoperability. Our goal was to enable partners to satisfy the survival need of semantic interoperability and allow them to focus on the other cool stuff that is possible when you have good information.
You may be able to manage interoperability on your own. But don’t take the easy way out. Accept that it takes a village to provide the best care for your patients and true semantic interoperability is the mechanism that allows the villagers to communicate with each other.
You can spend your time and resources trying to do this or you can contact us and we can help you do it. But you need to do it, your survival may depend on it.