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:

Notes:

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

There are a number of adoption hurdles for using standards (e.g. HL7, FHIR, etc.). The cost of implementing and maintaining compliance with a standard are non-trivial.

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.

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.

Company Motivations

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 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.

…little hope for open standards or a universal language for how they do that. It’s time for regulatory guidance to make that happen.

…one analyst observed that the industry seems to be forming “walled gardens” rather than a coherent network that encourages openness and interoperability.

Sound familiar? This is the same medical device interoperability struggle that has been going on for over 25 years. The IoT is still in its infancy and I sure hope they have better luck developing a “common carrier” than we did.

I’m sure ‘the kid in the garage without a degree’ is no dummy, but this premise:

And so that large percentage of medicine that is effectively being practiced by non-MDs is going to expand.

is simply ludicrous.

There’s a big difference between creating health and wellness appliances and mobile applications and diagnosing and treating patients. The distinction is outlined in FDA clarifies the line between wellness and regulated medical devices. If you claim your product acts like a doctor (treat or diagnose) or doesn’t fall into the “low risk” category, then your company will have to follow FDA regulatory controls.

Healthcare is the one industry that’s been the slowest to adopt the intelligent methods we have in most other parts of our lives. How did the communications revolution that transformed industries such as banking, entertainment and telecom somehow leave healthcare behind?

Great question!

Here’s the ‘Call to Action’ list:

Recognize that the lack of interoperability is a crisis and advocate for rapid change.

Frame the interoperability problem correctly: Everyone is in the business of gathering and sharing data to best serve patients.

Accelerate the full adoption of unambiguous, open standards for interoperability.

The trick will be whether hardware companies will push hard enough for standardization so they can capitalize on services revenue. Companies that see themselves as pure hardware manufacturers are likely doomed, but those that see beyond the “things” to instead focus on the services built on the “Internet,” the future is very bright.

Is this the new reality for the medical device industry as well? If data and interoperability are the future, maybe it should be!

The Internet of Things (IoT) is being propelled by the dramatic reduction in size, power consumption, and cost of networking and computing capability. Many of the devices listed in the Wolfram Connected Devices Project are health related. “Things” like weight scales and thermometers can make measurements from many objects, but when that object is a human body, they effectively become medical devices. The sensors that come standard on smart phones also fit into this category. All of these network-connected devices that record data from humans make up the Internet of Medical Devices (IoMD).

In most ways the invasion of technology in Healthcare is no different than how mobile digital capability is changing that way we all live. For Healthcare though, the potential benefits of applying these technologies to solve both the cost problem and to improve patient safety and outcomes are tremendous.

The number of technologies and innovations (health tracking apps and devices, home monitoring, medication management, etc.) that are contributing to these goals are too numerous to count. From a medical device perspective there are four primary areas of concern that need to be addressed as the IoMD grows.

1. Interoperability
As I’ve written about many times (e.g. Interoperability: Arrested Progress), health data interoperability is a key factor in realizing both cost reductions and improved patient outcomes. Unfortunately, medical data is notoriously complex, which makes effective communication between systems very difficult.

Another significant barrier to interoperability are EHR interfaces. The issue is that each EMR vendor has a propitiatory interface for consuming device data and associating it with a patient record. Without a direct device interface, data has to be manually transcribed into the record which is expensive and error prone.

This is a particular problem in the ambulatory EMR market because there are literally hundreds of vendors. Even if they all used a standard like HL7 there is still interfacing work that has to be done for each one. It is prohibitively expensive for any device company to develop and maintain that many interfaces.

Most medical software applications, like the ones you might download to your Apple or Android phone, will not be affected by these regulations.

3. Privacy
Even though PHI (Protected Health Information) is protected by Health Information Privacy (HIPAA) laws most people consider their health a very private issue. Privacy concerns are a significant psychological barrier that must be overcome before sharing of medical data becomes commonplace.

Pinging one device brought up a login screen that said: Welcome To Your Fridge. She typed in a default password—something like “admin” or “adminadmin,” Knight said—and suddenly had access to the heart of someone’s kitchen.

The interoperability issue is nota technical problem per se. It reminds me of the challenges associated with an object-relational impedance mismatch (“Deceptive Similarities, Subtle Differences”). Also, not only are our models of human-derived data imperfect, but two models created for the same thing will most likely be different.

The IoMD must convince the public that their data is safe and secure.

If mobile medical applications and connected health monitoring devices are going to contribute to a more effective Healthcare delivery system they must be able to reliably and securely communicate the data they collect to an appropriate care provider.

FDA intends to apply its regulatory oversight to only those mobile apps that are medical devices and whose functionality could pose a risk to a patient’s safety if the mobile app were to not function as intended.

There are six categories of mobile applications listed that the FDA intends to exercise enforcement discretion:

Help patients/users self-manage their disease or condition without providing specific treatment suggestions;

Provide patients with simple tools to organize and track their health information;

If a mobile application is considered a medical device it will be classified as such — class I (general controls), class II (special controls in addition to general controls), or class III (premarket approval) — and the manufacturer will be required to follow Quality System regulations (which includes good manufacturing practices, §820.30) in the design and development of that application.

For any organization that is not already under FDA regulatory control, this is a big deal. Given that there are 1000’s of medical applications already out there, even this limited scope approach will likely affect many companies. More information is here: Mobile Medical Applications.

The guidance includes many examples (including mobile apps that are notmedical devices) and an FAQ.

published a list of recognized standards for interoperability intended to assist manufacturers who elect to declare conformity with consensus standards to meet certain requirements for medical devices.

When it comes to the state of interoperability in the medical device industry there couldn’t be a better metaphor than Arrested Development*. A dysfunctional family made up of eccentric well-meaning personalities each doing their own thing, oblivious to each other and the rest of the world.

Nevertheless, it’s clear that electronic medical records is the future in healthcare data management. The down-side of this growth from an interoperability point of view is that there are that many more systems out there that don’t talk to each other!

Initiatives like CommonWell and Healtheway are moving in the right direction but are just getting off the ground. Also, these types of efforts are often far removed from the medical device industry and have little impact on software development and interface decision making.

… success depends upon a single large vendor assuming leadership. Interoperability will follow, but it won’t be designed by committee.

The distress of a well-focused cloud computing API involving a hand-full of vendors makes the outlook for HIT interoperability look particularly bleak. To make matters worse, the use of OSS in FDA regulated products face additional challenges that are not even seen in most other industries (seeOpen Source Medical Device Connectivity).

This is all good news for businesses that provide products and services that fill the connectivity gap. Companies like Capsule, iSirona, and Nuvon are many times the only effective way to provide an integration solution to a large number of customers.

I should note that there are some bright spots in the interoperability landscape. For example, the Continua Health Alliance has successfully pulled together over 200 companies to create a vision for inter-operable personal connected health solutions. Also, the West Health Institute is building standardized communication protocols into their embedded software for medical devices. These and numerous other successes provide hope, but are still just the tip of a very large iceberg.

Our years of work on medical device interoperability have led us to see the barriers (including technical, business, liability, standards, and regulatory factors) as “wicked problems,” in which there is little agreement about “the problem,” no agreement on a solution, and problem solving is complex because of external constraints.

Same old, same old. This is essentially Einstein’s definition of insanity: doing the same thing over and over again and expecting different results.

Federally enforced standards and regulations. Dr. Goldman’s suggestion to require manufacturers to fully disclosure their communication interfaces? Given the current anti-regulatory environment and budget restrictions, this seems unlikely to happen.

A hegemon, like OpenStack above? The healthcare industry is too diverse and complex. There is no single player that could even begin to tip the scales.

At least for the foreseeable future it looks like #1 (insanity) is going to prevail. If I’m missing some huge game-changer, please let me know.

In the mean time, let another episode begin!

*No deep meaning here. Certainly not like Arrested Criticism. I’m just comparing the medical device industry to a bunch of fictional crazy people.