The question for me has always been: Why is standardizing communications so hard to achieve? Healthcare providers, payors, EMR vendors, etc. have their own incentives and priorities with respect to interoperability. The following is based on my experiences as a medical device developer and has many similarities to the IoT world. As such, these observations are probably not applicable to many parts of the healthcare domain.
The Standard API
Let’s use a simple home appliance scenario to illustrate why interoperability is so important. Let’s say you have a mobile application that wants to be able to control your dishwasher. It may want to start/stop operation, show wash status, or notify you when a wash is complete. An App without and with interoperability are shown here:
- Without a standard API: The application has to write custom code for each dishwasher vendor. This is a significant burden for the App developer and prevents its use by a wider customer base.
- With a standard API: New dishwasher models that implement the “dishWasher API” will just work without having to change the application (ideally anyway). At the very least, integration of a new model is much easier.
Having a standard API that every App (and as importantly, other devices) can use to interoperate is critical for IoT (appliances and medical devices) growth. Besides all of the obvious benefits, in the healthcare industry the stakes are even higher (from Center for Medical Interoperability — Need for Change):
It will improve the safety and quality of care, enable innovation, remove risk and cost from the system and increase patient engagement.
The other important thing to note is that the API communication shown above requires full Semantic interoperability. This is the most rigorous type of interoperability because the App must understand the full meaning of the data in order to function properly. E.g., knowing that a temperature is in ºF as opposed to ºC has significant consequences.
Let me also point out that even though semantic interoperability is not easy, the barriers to achieving it are generally not technical. There may be points of contention on protocols, units of measure, API signatures, and functional requirements, etc., but when you’re working within a specific discipline these can usually be worked out. Non-healthcare industries (telecom, banking, etc.) have proven it can be done.
Cost of Standards
- The additional development and testing overhead required. On the development side, these interfaces are many times not ideal for internal communication and can have a performance impact.
- Some standards have a certification process (e.g. Continua Certification Process) that require rigorous testing and documentation to achieve.
- If you have a data element that the standard does not currently cover, you may be faced with having to deal with the standard’s approval process which can take a significant amount of time. For example, see the FHIR Change Request Tracking System which currently has thousands of entries. Again, this is not a technical issue. Having to deal with bureaucracy is just part of the overhead of conforming to a standard.
Now let’s try to understand what’s important to a company that’s trying to develop and market a product:
- Product differentiation. Provide vendor-unique features (a “niche”) that are not available from competitors.
- Time to market. Being there first is critical for brand recognition and attracting customers.
- One-stop shop (multi-product companies). “If you use our product family your experience will be seamless!”
The last item is particularly important. Following the appliance theme:
This strategy is of course how Apple became the largest company in the world. In most industries, the big companies have the largest market share. This “walled garden” approach is the most natural way to lock out both large and small competitors.
The First Hint of Problems
Notice is that the cost of interoperability can affect all three of the market goals a company is trying to achieve. Standards are:
- A “me too” feature.
- They take time to implement.
- They punch holes in the desirable closed platform.
The actual impact depends on a lot of factors, but it can be significant.
The Real Impediment
But the real elephant in the room is this: Return on Investment:
The ROI on interoperability is inherently very low and often negative (Gain < Cost). This is because:
- As noted above, conforming to an external standard has a significant cost associated with it.
- Lack of demand. Interoperability is not something a customer is willing to pay extra for (zero Gain).
I think companies really do care about patient safety, quality of care, and healthcare cost reduction. This is what motivates their business and drives innovation. The reality is that ROI is also a factor in every product decision.
Side note: If conforming to a standard was mandated as a regulatory requirement, then the ROI becomes moot and the expense would just be part of the cost of doing business.
I’m sure that interoperability is on every company’s feature backlog, but it’s not likely to become a primary actionable priority over all of the other higher ROI functionality. Those other features also contribute to improving healthcare, but the bottom line is hard to ignore.
Contributing resources and putting a logo on a standards organization’s sponsor website is not the same thing as actually implementing and maintaining real interoperability in a product.
Apologies for the cynicism. It’s just frustrating that nothing has really changed after all these years. Interoperability: Arrested Progress is close to four years old, and same old, same old (insanity) still prevails.
I think the reasons outlined here are a plausible explanation of why this is so. We’re all still waiting for that game-changer.