Background

For those of you who are new to healthcare interoperability, FHIR® (Fast Health Interoperable Resources) is a recent standard that finally brings RESTful APIs to healthcare. Along with this API, healthcare is beginning to accept OAuth2, a scaleable way to authorize apps on behalf of patients through the SMART protocol. OAuth2 + a standard API will help bring healthcare into the future.

But why would historically data-greedy vendors want to adopt openness in an environment where lock-in creates stikiness and regulations incent high security? Traditionally, EHRs and other health tech vendors discouraged data liquidity for legal and marketing reasons, at the expense of flexibility and patient access. It’s similar to Facebook hindering access to competing social networks.

But healthcare is fundamentally different from online social networks. Health systems often refer patients between hospitals for services they do not offer. Data goes with the patient, but rarely in the same a digital format. Without this data, costs increase due to repeat procedures, and people die from incomplete information.

So providers are now increasingly asking for custom workflows and clinical decision support tools that can benefit from external data, and government is beginning to mandate patient access to data via an API. Health tech vendors have become more amicable to the idea as well, now that they see the parallels in the Operating System space, where the EHR is not everything, but it’s the container in which applications can run safely.

The Future

An environment in which inaccessible health data becomes available will create space for innovation in healthcare. Those who want to access data en masse will be able to request it from a patient or doctor and build on it using a singular format.

We will see any imaginable application on top of this data, but the standards won’t solve all the problems with interoperability, so and services that support these apps will sprout up. The entire healthcare technology space may change from a monolithic EHR to an unbundled set of applications built on top of an API platform. FHIR® will need analogues in spaces where it’s unfit. Analytics, genetics, imaging, machine learning, security, and auth services will be growing platform needs in healthcare to support FHIR. A single health tech company will not prioritize all the esoteric needs of each provider, so the industry must find a way to move to a more federated model calling on internal team and external app developers for solutions.

A few movements from the tech industry may be paralleled in healthcare.

1. An app marketplace (one for each of the EHRs) is already underway
2. Competing operating systems in which these apps can run
3. Platforms like AWS that support health care needs specific to these standards and computationally intensive use cases like imaging, genetics, and machine learning.
4. Bring your own tech to work: we may see docs use their own selection of health applications on top of health system data with their own devices
5. EHRs will move to the cloud, as this is surprisingly still not the norm.
6. Bring your own data: patients may have some service that enables holistic access to their health data via an ID & secret key.
7. The sharing economy may offer doctor consults on demand as improved data access enables patients to see a doctor over tele-health platforms. “Click button, see doc.”