Last week a handful of Redoxers headed over the big pond to take in 2023 HL7 FHIR DevDays. We loved connecting and reconnecting with the world’s foremost FHIR enthusiasts in Amsterdam. While it is hard to beat last year’s experience, no matter how hard it tries, Cleveland will just never be Amsterdam.
If you were not able to make the trip, here are a few things that stood out to us this year:
- FHIR adoption has been primarily focused on expanding capabilities. While FHIR is largely adept at modernizing and standardizing many healthcare use cases it is getting the most traction where it offers net-new capabilities that were not previously possible. For example, there is healthy demand to implement FHIR-based queries (e.g., “find all blood pressure observations for patient X in the last 5 days”) as they are well defined by FHIR REST APIs and are generally unavailable or incomplete in earlier HL7v2 and HL7v3 standards. Conversely, there is limited demand to implement event-driven write-backs to EHRS (e.g. “send information from a lab test back to an EHR”) as there are well-functioning implementations for this using HL7v2.
Based on this, we expect the continuation and expansion of a heterogeneous standards implementation landscape, especially in the instances where FHIR overlaps with functioning legacy standards.
- FHIR’s promise as a programable standard is being delivered. Building on #1, we are starting to see more and more things that were impossible with legacy standards. In 2020, Redox’s Nick Hatt proclaimed that “FHIR is a groundbreaking standard, not because it is RESTful, not because it is new and hot, but because it is programable.” It is clear that its potential is now being realized as a variety of new tools built on the FHIR spec were showcased at DevDays:
- TestScript resources
- Microsoft CodeGen
- SQL on FHIR
- Sync for Science data quality
- Google analytics toolchain
This pivot towards tooling suggests that the base FHIR spec doesn’t solve all of healthcare’s problems out of the box, but at the same time solidifies its core value proposition as a tentpole standard.
- The future requires FHIR (but also HL7v2, CDA, X12, DICOM, and more). While the adoption of FHIR is certainly taking off, it seems unlikely that it will ever fully replace older standards. As mentioned in #1, there is a lack of enthusiasm to insert FHIR where other standards are competently doing a job. Further, many legacy standards are written into and reinforced by regulation. In Nick Hatt’s talk on the X12 standard, he discussed how X12 is required by HIPAA, and under new CMS-proposed prior authorization regulations, both X12 and FHIR will be required to maintain compliance. Finally, some legacy standards, like DICOM are so ingrained in clinical practice that it seems unimaginable to replace them. Garrett Rhodes’ talk on mapping the DICOM standard to FHIR showcased how developers can use DICOM images and metadata in FHIR workflows without having to learn the DICOM standard.
All of these takeaways really roll into one big takeaway which is the reinforcement that a lack of skilled human resources is the biggest threat to continued FHIR adoption and implementation. The threat is two-fold:
- FHIR is becoming more robust, but also more challenging: First, a robust and growing toolchain comes with the cost of added complexity. One of the opening sessions asked chatGPT what the major flaws of FHIR were, and complexity is #1. For those new to FHIR or healthcare data it is even more overwhelming than ever to master.
- Knowing FHIR isn’t enough (and won’t be): Because legacy standards persist and will continue to persist, healthcare IT teams must know FHIR, but also a variety of legacy standards. Without both, they will sacrifice either the component maintenance of existing workflows or future innovation. Alternatively, you can work with Redox to map all legacy standards to FHIR. Learn the why and how in our Fanning the Flames Guide to accelerated FHIR adoption.