What Comes After FHIR?
Redox is live with an actual FHIR integration. I’m pretty sure I predicted it would happen in 2017, but sadly I didn’t blog about it. In the spirit of being a prognosticator, I’m going to predict what I think the future of FHIR will look like.
Acting on resources with HTTP verbs will be a thing of the past.
Virtually all meaningful FHIR implementations right now (Epic, Cerner) expose a handful of resources from the Argonaut project and are limited to the GET operation. I see developers wanting to move away from these REST-ful API of FHIR in favor of what FHIR calls “Bundles”.
FHIR is a natural fit for graph APIs.
One potential challenge of FHIR is the amount of querying that needs to be done. Let’s say I want to find a patient’s current medications with the prescriber. This is what has to be done in order to do so:
- Get the Patient
- Get a list of MedicationStatements for the patient
- For each MedicationStatement, fetch the Medication associated with the MedicationStatement
- For each MedicationStatement, find the MedicationRequest that created it
- For each of those MedicationRequests – find the Practitioner that prescribed it.
Woof. This is how Medications are organized in the latest version of FHIR, and if a patient has 3 medications, I need to make (1 + 1 + 3 + 3 + 3 = 11) requests to get all information I need.
The same problem exists in other APIs, which is why Redox created “Data Models”, which we think contain all the relevant information you’d need for a particular workflow. Another possible solution is a graph API, and these are gaining traction—Github recently launched their v4 API which is based on GraphQL.
With a graph API, I can write a query for all five steps I listed above, and have it be one request. This helps me because I can keep all my logic in one nice place, and it helps the server because they can go and grab information in batches, rather than doing it eleven separate times.
While FHIR does provide specifications for each Resource’s available search parameters, not all of them will be supported by all EHRs. To impose a query language on top of the existing search is even more of a burden on server implementers, and inconsistencies will inevitably arise.
Even if some kind of graph API doesn’t make it into the FHIR specs, it’s something Redox is already looking into offering.
Writing graphs with FHIR.
The second area where traditional REST will not be as important to FHIR is writing data back to an EHR. The problem is very much the same as reading data above: how do I push multiple related resources back in the right order?
Let’s say I want to send a DiagnosticReport (Redox Results). Just like above, a DiagnosticReport can point to a lot of things, most notably all the Observations that make it up. What happens if I send the DiagnosticReport before the Observations? Most databases with some kind of referential integrity will balk at this. What if I want to include a QuestionnaireResponse? Suddenly, I need to start thinking a lot about not just the structure of what I’m sending, but the order I send it in.
Bundles provide a built-in solution for this, but so far, no one has really put forth an implementation path for how to send or receive bundles. GraphQL provides solutions for updating (Mutations) as well, but again the burden on implementers would be huge.
FHIR fidelity across vendors will be a problem.
In interoperability, there are inherent trade-offs: the more time a human spends mapping data from one system to the other, the more trust is developed between the two systems. This is exemplified in HL7v2 integrations—a low level of conformance to standards combined with a high level of integration work means that the end product can write data directly with minimal human interaction.
CDA provides a counterpoint—high conformance to standards means a lower overall implementation time, but less of the data is trusted. Most opt to only display the human readable portion of the document. This is exactly the point of CDA, but how will this translate to FHIR?
FHIR provides support for a narrative for all resources: a human readable form. There are very few rules about how to format these, other than valid XHTML must be supplied. If FHIR follows the HL7v2 path, where there is high trust between the parties, then the narrative doesn’t matter so much—the raw data can be filed discretely. If FHIR ends up like CDA, though, the narrative becomes critically important.
If a vendor doesn’t send the right code for an AllergyIntolerance, what should the EHR do? For patient safety, it makes the most sense to display the narrative in absence of a valid code. The EHR gets to pick how the XHTML is displayed, though, adding another layer of complexity to the FHIR client’s job.
Questions and concerns will obviously arise for those looking to integrate with EHRs—do I need a narrative for my FHIR resource? What should it look like? Will it look dope inside the EHR? In attempting to be helpful, FHIR still prompts more questions than it answers.
How Redox fits in.
I’ve outlined a few of the challenges with FHIR—reading multiple nested resources, writing data back to an EHR, and consistency when sending data back (if it ever happens).
Redox is uniquely positioned to solve all of these problems, even as scattered and distinct implementations of FHIR pop up across our ecosystem. We’re always going to be pushing the cutting edge and listening to our customers to find easier, faster, and cheaper ways to integrate.
I hope you continue reading our blog for exciting product updates! Subscribe below to get Shift6 posts delivered to your inbox so you don’t miss out.