Is a FHIR API enabled digital ecosystem the answer?

One of the aspects of FHIR® APIs we’ve been thinking about recently is the ability to support an ‘ecosystem’ approach to architecting healthcare systems. Wikipedia defines an ecosystem as:

A digital ecosystem is a distributed, adaptive, open socio-technical system with properties of self-organisation, scalability and sustainability inspired from natural ecosystems.

Another way to think of this is as a collection of components that are able to communicate with each other across standardised interfaces – perhaps requiring configuration to do so (which could be automated) but not alterations to the underlying component (by programming).

Take the example of an adverse reaction – perhaps a rash after using a pair of gloves or diarrhoea after taking a medication? Or it could be something more serious an adverse reaction to eating peanuts or an antibiotic, where an individual’s airway swells and they require medical assistance to breathe correctly. Is this an indicator of an allergy, a known side-effect of the substance, or an interaction of the substance with other compounds the person is taking?

And if it is an allergy, then it should be recorded somewhere against the patients record (wherever that may be).  

To determine this, we need a number of things:

  • What the substance in question was.
  • What else the person is taking (or other characteristics like significant conditions)
  • Some decision support capability (could be a human to start with, but we’d want to automate this at some point)
  • A place to store the patient allergy – if it is determined to be one. In fact, we’d want to store the reaction regardless as it may be useful to have a record for the future, for both the patient and medication side effect profiles.

And we assume that we also have:

  • A model for the information we need to exchange, and a way of expressing the information that all systems understand (potentially there could be more than one way to express it)
  • Interfaces between systems that can accept this model.

One way to approach this would be to create a single application that does all of this. But that’s a ‘monolithic’ approach that can only be used in one way. With ecosystem thinking, we instead break it down to its individual components (as described above) and then wire them together in different ways.

For example, we could have:

  • A web based application for use by clinicians that inputs the reaction information, stores it as anonymised data for subsequent analysis, calls the decision support service, saves any allergy in the patient record and returns Management Advice.
  • An extension to the above where the application can get clinical information from other patient sources – such as a National EHR – to add to the information being sent to the Decision Support Service.
  • A similar cloud application intended for consumers that simply calls the decision support service and returns advice to the consumer e.g. ‘This is an expected side effect’, or ‘stop the medication and see your doctor’.
  • An existing EMR (Electronic Medical Record) application that incorporates a call to the Decision support service it its usual operation (maybe using the CDS-hooks standard) and then updates internal records based on the reply.
  • A new mobile application for consumers that lists their medications (perhaps synchronising with a common data store) to remind them when to take it (and record that they have taken the medication) but it can also call on the Decision support service to check for any interactions between the medications.

And there are plenty of other alternatives.

So, by using FHIR APIs as the ‘glue’ between systems, we gain the ability to configure solutions in different ways to meet different requirements, yet re-using the common components that are needed.

Innovation, here we come!

Ecosystem thinking gives us the ability to achieve a truly open healthcare data system.