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.
Walter,
I would say that informally, the goal of the Argonauts (w/r to FHIR profiles) was to get as much agreement as was practical under the tight timeframes necessary to meet release of production code that meets the ONC “2015 Edition” Certification specifications.
The profiles produced by Argonaut are fairly “shallow”, but they do add substantial value in constraining the open-ended space enabled by “raw” FHIR. Even getting agreement on how to represent vital signs required substantial vendor effort.
There is no easy consensus on what the “right” level of Profile specificity is, or on how deep conformance should go, across the vendors. If profile design was easy and obvious, we wouldn’t have a hundred thousand LOINC codes to choose from!
I believe that Argonaut work represents a significant start, but the process will need to continue for a long time to come.
Meanwhile, agreement on OAuth and SMART (also completed and vetted by Argonauts) opens the door to realistic markets for the “side car” apps that Wes describes.
–david
(David McCallie / Cerner)
Thanks, Wes. Terrific summary of your learnings from the development conference and your value-added insights. Question: I have heard through the grapevine that implementations of the FHIR resources by even the largest vendors are not consistent with each other, i.e., some vendors are routinely populating certain optional data elements in a FHIR resource and others are populating different data elements (although there is certainly significant overlap). Did you get a sense whether that is the case? If so, this would complicate the fielding of sidecar applications at customer sites with different EHRs, since those applications could not count on the same data elements being available for analysis, decision support, etc. across EHRs. Did the EHR vendors you spoke with indicate that they are working to reconcile such discrepancies among each other (e.g., via conformance testing against a single, tightly constrained profile of FHIR)? Do you feel that current versions of the SMART FHIR and/or FHIR-Argonaut profiles are sufficiently constrained to serve as the basis for such conformance testing? Obviously, the FHIR community of EHR vendors and sidecar apps must walk before it can run, but I’d be interested on your take as to whether the trajectory is in the right direction regarding cross-EHR standardization. Thanks!
Walter, this issue did not come up and I did not think to raise it. Considerable work has been done in the last two releases of FHIR to support automated conformance testing and both Mitre and Aegis have established conformance testing platforms. I have heard that the Argonaut work has been a bit slow and still focused pretty basic. To a certain extent the vendors may also have difficulties associated with idiosyncratic implementations of their products.
I believe that the vendors I identified are working in good faith towards the most consistent implementations of at least the Argonaut specs across their products. Given the accelerating interest in and tooling for automated conformance testing it wouldn’t be surprising to see 2018 as the “year of conformance” for FHIR.