This year marked my inaugural voyage to HL7® FHIR® DevDays, alongside my Redox colleagues, Autumn Ike, and Mike Paetz. This blog represents our collective Top 5 takeaways from this year’s 4-day affair.
I work with FHIR daily and consider myself to have an intermediate understanding of it, including:
- Formats
- Terminologies
- Data types and domains
- Associated protocols
- The legislation that’s led to its accelerated adoption (for some pointed use cases)
This intermediate knowledge is enough for me to understand and share the “consensus” vision of FHIR’s future potential — including greater accessibility and usability of healthcare data via interoperability between internal and external systems.
Heading into the conference, the list of things that lacked in-depth knowledge was slightly longer:
- The relationship between resources and profiles
- How to utilize profiles outside of US Core
- FHIR’s range of extensibility
- The different workgroups associated with HL7 and FHIR
- The associated implementation guides (IGs) the community is creating and amending (PAS, DEQM, HRex, CDex, CQL, etc.)
- The intent and implementation of those IGs
- How we get to a vision where FHIR is the de facto standard for all healthcare data exchange
Attending sessions at FHIR Dev Days and networking with players in the community helped to shed light on a few of the unknowns, but also provided me with an interesting perspective coming out of FHIR Dev Days that I didn’t have before…
While it is probably not the answer to all of the woes that plague healthcare data, FHIR is here to stay. This expert community built around FHIR is as collectively passionate as they are incredibly knowledgeable. There is a true inherent belief among attendees that FHIR is the ultimate standard and there should/will be a shift to FHIR as the go-to standard.
1. An international standard for an international audience.
Working for a company that collaborates primarily with organizations in the US or Canada, I must confess I had a bit of tunnel vision when it came to healthcare data exchange. My focus has been laser-sharp on the challenges faced by the US healthcare system. Little did I know that there was a whole world of FHIR adventures waiting to be discovered beyond my borders!
I never thought much about how FHIR was used in other countries, if at all. Or how our big goal of making healthcare data useful and accessible in the US, might translate internationally.
Looking back now, I feel a bit silly for not asking those questions or spending time learning about international FHIR use and adoption. The international FHIR community was out in full force in Minneapolis! There was a huge European presence, with participants from Germany, Switzerland, Italy, the Netherlands, Russia, and more. Asia was also well-represented, with folks from Japan, India, and Singapore. South America was there too, with participants from Brazil, and even our friends from down under in Australia sent a strong contingent. Grahame Grieve even called in live from a walkabout in the Australian outback via Starlink.
Victor Chai from Synapxe gave a great presentation highlighting Singapore’s Healthier SG program, which uses FHIR APIs to track end-to-end patient care journeys across all public healthcare providers. Data in a central repository is available to all public healthcare providers. The goal is to shift Singapore’s healthcare approach from reactive to proactive, focusing on prevention for its aging population. (*HL7 FHIR Implementation for Singapore National Healthier SG Programme). It was exciting to see what can happen in a region where (it seems) less operational red tape exists than it does here in the US. He noted he and his team had a 2-month roadshow to the participating organizations to get IT teams up to speed on FHIR use. They had hefty goals and expedited timelines that left me in awe of how Synapxe is revolutionizing healthcare in Singapore. It left us hopeful for what can happen in the US, and also overwhelmingly frustrated by the hurdles we face here that aren’t relevant in other areas of the world.
Paolo Testa from Italy presented on a similar repository with an accompanying implementation guide for all organizations in a specific district within his home country. Paolo and Victor were both nominated for the first FHIR implementer award. They demonstrated the real-world impact and clinical value of FHIR APIs in their communities, with case studies that outshone US applicants.
It was exciting to see global enthusiasm for FHIR and its potential to improve healthcare data exchange both nationally and internationally. Adoption within the states is a huge task in itself, so any seeds planted internationally to gain alignment to a specific standard can only be good news for the future of FHIR as the de-facto data exchange mechanism in the space.
2. Gen AI’s ability to invoke a crisis of confidence in FHIR’s promise (but not really).
Is there a world where data doesn’t need to be within a structured format for external systems to automatically parse and make sense of the data? Imagine sending a photo of a prescription to an external system — the system reads the prescription text, down to the provider signature, and stores each individual element on that prescription as a discrete element within a data lake, ready to use for subsequent tasks or send discretely to other systems or services. How compelling is that? Especially when extrapolating out to additional use cases like imaging reports, device readings, pre-visit data gathering, clinical interpretations, and transcriptions.
Will Rosenfeld and Vivian Neilley from Google gave a keynote, “Garbage In, Good Out?” focused on the pros and cons of different data storage and interaction methods, from storing data in a purely Deterministic fashion (store in FHIR and search via SQL on FHIR), to a Generative approach (raw data in and using LLM models to parse data into a structured format for subsequent tasks). They concluded that for now, and likely for the foreseeable future, a fully generative approach does reduce mapping/merge burden and allows for multimodal ingestion into the cloud store, BUT the approach is not human-ready and incorporates some level of “hallucination risk”, (i.e, the generative approach is best where there is still a professional on the other side reading and making sense of the data output).
Is there a world where LLM models get to a point where structured data exchange is a thing of the past? Maybe. But, it’s more likely that we’ll always need some structured data for parsing and exchange. This suggests a future where structured data elements are available alongside documents that include robust data elements to be parsed through AI.
TLDR: 100% generative AI, with no human in the loop is still years (if not a decade) off.
In the meantime, my colleagues and I are excited about hybrid approaches that use AI to build a traditional deterministic query, and then feed the results into an LLM to answer natural language questions. Raquel Izquierdo, also from Google, did a demo on their new Vertex AI Search product that takes this hybrid approach. You can see the results of the AI output right in line with the actual FHIR resources returned by the generated search and how the response is grounded in the data.
3. FHIR adoption continues to expand, slowly
FHIR adoption has made some real strides since the 21st Century Cures Act was signed into law. Many EHRs and Payers were pushed to adopt FHIR APIs in compliance with the USCDI standard and the CMS Interoperability and Patient Access final rule, respectively, to avoid hefty fines of non-compliance. Since an initial surge, we’ve seen the scope of adoption to be relatively narrow against the data domains that FHIR supports as well as within the workflows that FHIR supports with FHIR notifications, subscriptions, and messaging specifically seeing little uptake from the big-name EHR players. I was disappointed by the lack of discussion on the current state of FHIR support in EHRs. There was little talk about how widespread adoption of FHIR could happen beyond regulatory pressure and the potential benefits of less popular frameworks like FHIR messaging for EHRs. This is especially relevant since legacy standards like HL7v2 and X12 are well-established and function effectively in many workflows.
Keith Figlioli from LRVHealth gave a very gutsy presentation entitled “Technology Has Not Transformed Healthcare, Will That Change With AI?” that centered around a similar topic. The healthcare spend the US and other countries have seen over the past decade has very little correlation to ROI in the space. Much of the discussion focused on the challenges of measuring ROI:
- A vast majority of healthcare executives polled in one survey (71%) stated their respective organizations have not captured a clear ROI from digital health technology investments.
- Measuring ROI is incredibly complex and can be difficult to quantify financially, especially if cost-savings is seen or accrued within other entities.
- It can take 5 – 10 years to fully realize and demonstrate the ROI of an investment in healthcare technology, similar to that of investing in and realizing value from an newly implemented EHR system.
This is the one session I recall that clearly pointed out the abundant waste within the HIT ecosystem, given the clear lack of return from many investments, and what could be done to shift the narrative to one where waste is minimized, and ROI is more accurately and clearly determined. Keith’s concluding point was centered around the promise of Gen AI and it’s ability to make use of much of the data within healthcare, which is abundantly available in an unstructured way. If Gen AI and LLMs can reliably and efficiently analyze healthcare data, we may not need the strict data standards currently used to ensure accurate information sharing between organizations.
4. IGs, IGs, IGs.
“Implementation Guides” or IG is quite the buzzword among the FHIR community. The IG is the output of months, sometimes years, of discussion among community members specific to a unique workflow and how it’s supported via the FHIR standard. I loved to see the work the community has put into these implementation guides, but there was little discussion that I was a part of that focused on the actual “implementation” part of the guide. What is the value to organizations to follow a specific implementation guide or pull one off the shelf for a use case that could be supported via a mechanism IT teams are more familiar with? What is the business strategy for organizations to adopt? How does the community change the notion that FHIR will continuously evolve, making any workflow supported through an implementation guide require perpetual maintenance to remain in compliance?
I will note there were many sessions during the week centered around the evolution of FHIR to subsequent versions and how to ensure future IG versions are compatible with historical versions, though the issue remains that implementation of such guides would require continued support, maintenance, and iterations over the lifecycle.
5. Legacy standards are here to stay
FHIR is cool. I often (and likely inappropriately) refer to FHIR as “sexy.” There is a prevailing zeitgeist within the community, for those just learning about FHIR or those that have been involved for over a decade, that FHIR is the data standard of the future and will unify how all organizations in the healthcare technology space interact with external and internal systems.
The reality (at least in the short and medium term) is likely something closer to the reality we exist within today. Modernization efforts are long, expensive, and resource-intensive. Investment in innovative technologies is far below it’s unsustainable levels of 2020 and 2021. And the fact continues to remain that some standards that are widely adopted today, work relatively well; or at least well enough not to warrant a huge modernization effort to incorporate only FHIR as your integration standard. HL7v2, for example, is highly valuable for organizations looking to send snapshots at specific points in time to external systems. X12 is another example of a widely adopted standard by most provider and payer organizations for claims reimbursement and eligibility confirmation. It’s even required by regulations like HIPAA’s Administrative Simplification – Standard Transaction rule for certain transactions, such as prior authorizations, where the data must be in X12 format at some point. This is why the PAS implementation guide uniquely specifies the need for an intermediary to normalize X12 information to FHIR and vice versa for organizations exchanging in this mechanism. However, the most recent CMS legislation suggests that the requirement may not be enforced going forward so long as FHIR is used.
In the spirit of continuing to work with older standards alongside FHIR, Mike Paetz closed out the conference with his talk on Mapping HL7v2 events to FHIR (and back). Many healthcare workflows require the ability to receive data, but also need write data back to an EHR. Designing an API to handle both push events and writebacks comes with significant challenges. For more on HL7v2 to FHIR here at Redox, check out our recent blog or last year’s webinar.
To Wrap It Up
Ultimately, FHIR’s journey is one of continuous evolution, collaboration, and incremental progress, aiming to enhance interoperability and data exchange within the global healthcare landscape. I left FHIR Dev Days feeling much more informed and very optimistic about the future of healthcare data exchange. That said, I didn’t leave with a very clear picture of HOW FHIR becomes the ultimate defacto standard in healthcare data exchange, which ultimately, remains elusive for many (most?, all?,) within the industry. FHIR certainly isn’t the sole answer to many of the challenges we face in HIT data exchange, and there are many technologies on the horizon (Gen AI, LLMs, among others) that will have their chance to dramatically impact the landscape in years to come.
FHIR® is a registered trademark of Health Level Seven (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.