Another way to think of this is as a collection of components that are able to communicate with each other across standardized 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 diarrhea after taking a medication. Or it could be something more serious, like an adverse reaction to eating peanuts or to 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 patient's record, wherever that may be.
To determine this, we need to know 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 anonymized 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 in 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 synchronizing 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-use the common components that are needed.
Innovation, here we come!
Learn how Phoenix Children's Hospital became ready to accommodate its first vendors using FHIR: Read the case study now!