Retired Healthcare IT Nerd

I had the good fortune to attend HSPC FHIR-SMART Development Conference, March 30-31 in NOLA. It provided a unique opportunity to understand the business and technical dynamics of third-party projects offered as adjuncts to EHRs. FHIR and SMART APIs are helping sidecar app vendors “over the humps” of some basic business challenges. Speakers also affirmed a basic rule of life, the main thing one finds in overcoming a challenge is the next challenge.

Sidecar Applications

I describe sidecar apps at FHIR, SMART and Sidecar Applications. Like a motorcycle sidecar, these apps can significantly enhance the functions of an EHR, but the engine and overall steering remains with the motorcycle (or EHR).

Current examples of sidecar apps are often GUI extensions of an EHR. For example, an EHR user can invoke an app from an EHR screen that provides assistance in diagnosing skin condition or a diabetic patient might include information from his providers’ EHRs in the diabetic lifestyle program on her smartphone. View examples here.

It is easy to visualize sidecars in terms of GUIs and personal devices, but many other architectures are possible. For example, products that offer knowledge bases could run in their own clouds, acquire data about patients, and offer clinical decision support,  connection to clinical trials or other helpful content.

Business Humps to Get Over

I have worked with vendors of sidecar apps since the 90s. Generally, these vendors were concerned with crossing two business humps: an attitude from the EHR vendors that was indifferent bordering on hostility and the lack of a standard interface that addressed security, standardized structured data, and a more interactive workflow than HL7 messaging.

A lot has happened since the 90s. Business models based on app stores have bloomed. The largest buyers of EHR in the marketplace have moved their vendors’ thinking away from “we do it all” to “we provide the central engine and highly integrated apps while enabling the EHR customer to supplement us through sidecars.” In the U.S., federal policy demands that EHRs have “an API” although it does not yet require a specific standard.

Another change in the business environment has been the aggregation of institutional EHR business among a few vendors. Nominally this works to reduce the sidecar vendor’s reliance on standard interfaces. It is easier to customize to three vendors’ idiosyncratic APIs then, say, a dozen.

Progress Over the Humps

Cerner, Epic and Allscripts played prominent roles at the conference. At least these market leaders have demolished the indifference hump. They each offer a menu of relationships with third-party vendors and revenue sharing models to ensure their business interests align with the sidecar vendor. The menu starts with no-cost access to documentation, a support forum and the vendor’s testing “sandbox”. Higher cost options include training and collaboration based on up-front payments from the third party.

They also showed progress on the second hump, FHIR standard interfaces. The SMART Health IT API supplements FHIR for deploying sidecar apps. It now works with the three vendors. This is important because the security model used by Smart is based on Oauth2. This is the predominant model for enabling the users of sidecars to be authorized to access a person’s data, even though the sidecar app is hosted separately. (Think of apps that let you log in with your Facebook or Google credentials.) Smart sidecars may be deployed on a range of devices, from a window within the EHR’s GUI to a smartphone or even a medical device.

As the EHR vendors roll out support for FHIR, they are at different stages in their support for creating or updating data in the EHR. Cerner supports it for certain resources, but Epic and Allscripts are not there yet. Accepting data is complex. In the meantime, these vendors offer third parties the ability to introduce data into the EHR through their proprietary APIs.

More Humps

The speakers highlighted these new challenges.

• Institutional customers are shy of any third-party relationships.
• Large institutions are very reluctant to do business with small vendors. They cannot lay off liability for data breaches or count on the continued viability of the vendor.
• Duplicate data entry is anathema to potential customers. Being able to retrieve data from the EHR helps, but until the app enables reports, suggested orders or other data to be entered into the EHR, the non-duplicative challenge persists.

I would add another concern. Investors are reluctant to fund products that do not have a sustaining competitive advantage. If the value-add of a sidecar app is based on a creative way of displaying EHR data, a successful product will quickly by emulated by other third parties. Very large vendors may have the ability to protect their intellectual property in the courts, but small vendors do not.

Making a Successful Sidecar App

It is extremely encouraging find the big humps are leveling. And it is not a surprise to see that challenges remain. If APIs allow a thousand flowers to bloom, only the hardy ones will survive the cold winter of business reality.

Here is some survival advice:

• So far, there is no reason to expect practical support from any but a few of the largest ambulatory EHR vendors. Other vendors will likely provide nominal compliance with Federal API requirements. You can’t build a business on nominal. It would be wise to focus apps on integrated healthcare delivery organizations.
• Create apps that have widespread impact across a healthcare delivery organization. Business conditions do not support users adopting sidecar apps with the freedom that we have buying a $5 app for our smartphones.
• Create apps that don’t require duplicative entry of orders, even if this means using custom APIs for another couple of years.
  Be a big company, sell through a big company or fund your startup for a multiyear marketing campaign to get on the radar of large healthcare delivery organizations.
• One kind of sidecar product that will get the attention of large healthcare delivery organizations, pass their vendor size sniff tests, and have sustaining competitive advantage, is one that derives value from large caches of data housed at the vendor’s organization. More about this in a subsequent post on “CDS-Hooks”.

As always, I would be delighted to have your comments.