I’m currently running four email apps on my iPhone. I’ll probably delete a couple of them as I figure out which one I like. My choice will be based on things like features, usability, and design aesthetics. What I didn’t do is proclaim to the world that I need an email application, request proposals from app developers, then spend months analyzing the responses only to choose one app that I will forever use until my hardware doesn’t support it and I have to go through the whole ordeal again.
A market is most efficient when a buyer accurately perceives the benefit of the product she’s purchasing. In health tech, buyers are rarely the recipient of the predicted benefits of our products. The upfront costs often prevent new products from being effectively evaluated for use. New entrants have to deal with real barriers:
- Waiting out the sales cycle
- Implementation and Integration
- End user adoption/Training
These risks can make health system buyers extremely risk averse and end up going with “safe” incumbent software built by huge companies charging 20x more than the new-entrant disruptors. That, combined with the inherently risky nature of new ventures, make it impractical for health system buyers to evaluate products from startups. Startups don’t even have a chance.
This is clearly a market failure: goods/services are not being efficiently allocated. Because of this, healthcare misses out on many of the efficiency gains that computers and the internet brought nearly every other industry. For instance, how many times have you heard a health tech startup say “Our company is the [pick your favorite modern tech: Uber, TurboTax, Google Hangouts, Facebook, Twitter, etc.] for healthcare.”
In the software world (up in the cloud), they’ve evolved past this market failure and have flipped the adoption process on its head:
- End user adoption – people adopt first, then choose later. (Training isn’t necessary because the software intuitive or training is built within.)
- Implementation and Integration – this is turnkey: sign in with Google, share your data. APIs keep things synced up and browsers and operating systems allow you to deploy quickly.
- Pay – if you like it, you end up upgrading to a paid version, moving past the trial, you put your credit card numbers in somewhere.
This applies to the B2B space as well as it removes friction in the buying process and pushes the buying decisions down the long tail. For instance, small teams purchase Basecamp, Trello, and Slack and get rocking. These decisions no longer require approval from centralized IT department because there’s effectively nothing to install. And it’s cheap enough to hit with a P-card or even pay out-of-pocket.
Could we remedy this market failure in land of health tech? The consumer space developed these solutions for a reason: the democratization of technology adoption creates opportunities for higher-quality, more specialized products offered at diminishing price points. (When was the last time you paid for an app?) To empower this, there are a few major technical hurdles to tackle:
Data access and privacy
Most health tech applications need access to patient data stored in the EHR. For apps supplemental to EHR functionality (analytics, pop health, telehealth, etc.) access can be granted through a Business Associate Agreement. This HIPAA requirement means that app developers must contract directly with the health system beast–back to square one: centralized IT decision making and committee meeting purgatory.
However, there’s a shining light out there, at least for patient-facing applications. One of the things we can all agree on is that the patient should control access to her data. After all, it is her data. That means, if an application can secure permission from the patient to access data, then access should be granted. The developer world came up with the concept of OAuth enabling a standard in which a user can authorize an application to access data without sharing her credentials. For instance, when you sign into an email app with Google, you’re simply letting Google know that it’s cool if they share your emails with them. That app never actually gets your Google credentials.
SMART is attempting to bring OAuth-style authentication into healthcare and has created a compelling, although academic, proof of concept. Unfortunately there doesn’t seem to be a clear incentive model to spread this technology. Additionally, just as with my email app, I need to authenticate with each of my email providers: Google, Outlook, Yahoo, AOL, etc. Within a given health system there will be many data sources that will also need individual authentication (Epic, Cerner, Labs, etc.) and patients will likely not know where their data resides.
I14Y (Interoperability)
Once access to data is granted, how will these software applications consume it? Currently, software vendors must work with integration teams to work through a peace-treaty-like negotiation on who’s going to adjust their specs. Because of their size and limited scope, startups almost always need to comply to the health system’s HL7 specification.
This is problematic for a few reasons. Modern app developers don’t know what “HL7” stands for, much less how to use it. And even if they did, they’d have to work with the customized implementation of the standard at each health system they sell to. Additionally, they’ll have to figure out a way to connect their cloud-based software to the EHR that’s in the basement of the health system lacking internet connectivity. I’ve seen some software vendors devote half of their development resources towards building and maintaining these custom point-to-point connections. It’s just not scalable.
This is where the exploding world of application programming interfaces (APIs) come in. Going back to my email app example, after you authorize the application to access your gmail (via OAuth), it uses Google’s API to programmatically pull in your messages. In healthcare, this is the talk of the town. Everyone from EHR vendors to health systems themselves are coming out with API layers to connect up to. This has created a lot of competing standards…
FHIR has set out to create a unifying way to format and exchange data. However, this requires a few big hurdles before it can feed an effective API for app development use. EHR vendors need to do development to support FHIR, health system needs to install/enable it, and then it needs to be documented and applications need to be given access to it. All three are huge hurdles in the world we live in now. Although there are projects in the works to help accelerate this, the lack of support from MU3 signals that we’re still years out. Even then, implementations of FHIR will likely be inconsistent as it leaves some ambiguity up to the implementor.
Enter the API aggregators
Since it doesn’t seem likely that the industry will agree on and implement a single API structure in the near future, new companies (myself included) are sprouting up to tackle the challenge. Hip startups are making new one-size-fits-all APIs and setting out to help other hip startups. They boast the agility to support a one-to-many data integration, each differentiating in their own way. Connect once through a modern JSON API, and these guys manage the rest. It’s similar to when website companies used to have to buy a server and maintain it in their office, spinning disks and all. Now they’ve moved to centralized, managed solutions (like AWS, Rackspace, etc.) that do the icky stuff for them.
Can we repair the market for health tech?
Yes, I believe we can. It’ll look quite different though. An efficient market will require the person benefitting from the technology to be as close as possible to the buying decision. That means we need to empower the doctor, nurse, department, and patient to be able to choose the tool that best suits them. Enabling that will require decentralized decision making on the health system side, and OAuth-style authentication on the patient side. Additionally, they’ll need to share data through the use of modern APIs supported by the EHR vendor, health system, or all of the above through the use of an API aggregation service.
This is happening right now. In health tech, it’s now common knowledge that if you want to get your product to market, you’ll need to figure out a sales strategy that sidesteps the CIO’s office and the endless committee meetings to get directly to the person who benefits. As these sales strategies are empowered through better technology infrastructure, we can expect to see a digital renaissance hit healthcare hard while dragging along efficiency gains that no regulation, innovative organizational structure, or payment model could ever dream of.