How FHIR APIs enable healthcare data to be available where it is needed

How could thinking about interoperability as an ecosystem help? I have spoken about FHIR® enabled ecosystems on a number of occasions – most recently at HIMMSS18 where I presented on A FHIR-Enabled Ecosystem for Health Information Sharing. The term ‘ecosystem’ has become widely used in a number of different ways – the Wikipedia description is one I like:

A digital ecosystem is a distributed, adaptive, open socio-technical system with properties of self-organisation, scalability and sustainability inspired from natural ecosystems. Digital ecosystem models are informed by knowledge of natural ecosystems, especially for aspects related to competition and collaboration among diverse entities.

For this blog, I thought I’d discuss ecosystems in the context of a real project – the Adverse Reactions project in New Zealand. This project defines a standardised approach for collecting information about medical adverse reactions – such as a drug allergy – for the purposes of improving patient care delivery, and for reporting and analytics.

At this stage of the project, we have defined the information we want to capture – now we need to create the real FHIR artefacts, and as a part of that to consider a ‘reference implementation’ – one way that this could work in real life for implementers to consider.

One approach would be to simply create examples of messages and a server implementation, but a more interesting approach would be to think how we could do this if there were a digital ecosystem available. What are the services that we would need/want when creating an adverse reactions report?

  1. An identity service – unambiguous ways of referring to the patient, the reporter, and the source of the data. Of course, this is likely to be in multiple services – in New Zealand we have the NHI (National Health Identifier) for patients and the HPI (Health Practitioner Index) for providers. Work is required to improve access to them, but this is a good start.
  2. An authentication service – proving that the person submitting the report is who they say they are – and what their credentials are. Naturally, we’d use SMART for this as the interface, but we do need to work out the supporting infrastructure.
  3. A shareable EHR – There is supporting clinical ‘context’ data required that we’ve defined – including the current problem list, current allergies, and medications. We could include them in the message, but if there was a shareable EHR available, then we wouldn’t need to. The system processing the report can look this up. It doesn’t really need to be a single national source (though that would be easier) – as long as we can reliably (and safely) gather and expose this information, respecting patient privacy. Even if we wanted to include the information anyway (for example if we considered the report to be a Document) being able to access the data at the time of the report creation would be invaluable. There are a number of options we are exploring.
  4. A terminology service – There is a lot of coded data in our report – for example the substance, the nature of the reaction, and outcomes. The person creating the report will have an easier job (and we’ll get a better report) if there is a terminology service that can supply this coded data in real-time as the report is being completed, and from common ValueSets that we have defined. You can imagine all sorts of User Interfaces (mobile and desktop) that could utilise such a service.

Read our white paper, Enabling the Ecosystem with FHIR, where I discuss how healthcare information can be made available where and when it is needed.

Go to White Papers