Ecosystem Thinking Based on FHIR APIs

How Can This Accelerate Innovation in Health IT?

One thing we’ve been talking about for some time now is how “ecosystem” thinking, based on FHIR APIs, has the potential to accelerate innovation in the health IT space. Ecosystem thinking gives us the ability to achieve a truly open healthcare data system, by enabling healthcare information to be made available where and when it is needed.

Electronic health information is made accessible through the collection and manipulation of data, but it has also created complexity. This is evident with the amount and type of data that is available, the growing number of sources where it is captured and stored, and the more specialised ways in which it is being used. There is the emergence of personalised medicine, where advanced analytics can be applied to this information–including the person’s genome-giving management advice that is tailored to the individual rather than what has previously worked within a similar population. Following that advice often requires access to highly specialised services, but finding them can be a challenge.

This is a complicated area and requires a deep understanding of specialised domains, vast quantities of information about both an individual and a population and the development of complex algorithms. With machine learning, facts are gleaned from this morass of data requiring powerful computing, more than a standard Electronic Health Records (EHR) application can provide. FHIR APIs or HL7® FHIR® or Fast Healthcare Interoperability Resources can enable this ecosystem which will support access to, and manipulation of, healthcare data and services by many different applications.

How can FHIR APIs accelerate innovation in health IT? Let’s take a closer look

Having standardised interfaces between systems (whether real-time REST, more complex Operations, or even derivative standards like SMART or CDS-Hooks) along with a standardised way of representing that data (i.e. the resources) will allow vendors and providers to focus on creating applications that meet real business needs, rather than on the necessary infrastructure to support secure exchange. There is promising development underway and this was worked on at the recent FHIR Connectathon at the HL7 Working Group Meeting in New Orleans.

The actual track worked on was Consumer Centred Data Exchange, and we were exploring ways that the consumer can control who has access to their data–and for what purpose. Consumers may be happy to share all their data with their care deliverer, but only a subset of that data (perhaps excluding mental health data) with a researcher.

As you can imagine, this can be very complex as there are a numerous moving parts involved, these can include:

• A way of expressing their preferences – and a place to store them.
• Being able to ‘tag’ or ‘categorise’ data so that the sharing rules can be applied.
• An identification system for the participants – consumers, providers, organisations, roles and more e.g. a Provider Directory.
• Engines that can apply these rules when delivering data to a recipient.

Below is a diagram of the components that we put together at the Connectathon. It’s important to appreciate that, for most of the components, there was more than one vendor and/or organisation that had a system that we tested. In fact, seven organisations and vendors were part of this track.

Looking at the components we had:

• A Consent service, that held the consumers sharing preferences as a FHIR Consent resource.
• We used a terminology service to tag the data items with the agreed tags – such as sensitivity or ‘type’ (e.g. Mental health, Drug use).
• There was an EHR that stored the data. In our case, there was a single EHR – but there is no reason why there couldn’t be more.
• A ‘privacy engine’ that applies the consent rules.
• An audit server that recorded access.
• A couple of applications that consumed the data – both provider and consumer.

It’s important to appreciate that all the interfaces between systems were based on FHIR (and derivatives)–or at least we were working towards that goal. This means that we can effectively swap out individual implementations to use a different provider, as long as they supported the interface.

What we were able to demonstrate was that a consumer could create a Consent resource and save that on the Consent service. Then the applications could operate with different users and roles (e.g. Provider or Researcher) for different organisations and would receive a different set of data based on their role and the patient’s Consent.

There is a way to go before this is all working as smoothly as we need, but it’s a great example of using ecosystem thinking and demonstrates how multiple vendors and organisations can work together to support that thinking.

Read my white paper, where we will look at how FHIR and several derived standards could underpin such an ecosystem, and the types of services or components that will be needed.