Will AI replace FHIR?
Spicy takes on FHIR DevDays 2024
Note: we’ve corrected sections of the original publication of this article to better reflect the content of the event.
Mea culpa for the Betteridge’s headline.
HL7 FHIR DevDays 2024 — the largest FHIR-only event in the world — is a wrap. DevDays has a reputation for being at the cutting-edge of healthcare interoperability and gives us a look into major health IT themes for 2024 and beyond.
We've compiled the highlights from our view.
TLDR:
How to build a payer patient access API network. Flexpa's community talk and complement to our The State of Payer Patient Access APIs report.
What opportunities are there for LLMs and FHIR? A few presentations had us thinking about the possibilities.
Cutting-edge analytics, schema, and code generation. Someone actually wrote a C++ implementation of FHIR Path.
EHI Export is b-b-broken. But Epic's database schema is wild.
A new FAST project on Consent. New Provider and Payer APIs in CMS-0057-F both have to deal with consent.
Payer Patient Access APIs
This is the second year Flexpa has attended and provided a community talk.
This year we presented a technical summary of the some of the data synchronization challenges we've had to overcome in building the largest payer patient access API network in existence. This talk is a technical complement to The State of Payer Patient Access APIs report we released in May.
Payers continue to be very interested in our work because for many we are the only outside source of feedback. Vendors like 1upHealth continue to cite the report in public marketing. This proved true at DevDays, where attendees from some of the largest payers requested access to our report.
AI and FHIR
DevDays had presentations on LLMs with multimodal health records and RAG approaches too.
One such example of feeding multimodal health records - text, audio, video, images - and leaving it to the LLM to "figure it out" will clearly have some application in summarization and Q&A use cases. Gemini 1.5 can do this with synthetic records today due to a very large context window of 2 million tokens.
Could LLMs be an “anything to anything” interoperability bridge? What would the future of healthcare interop look like with an "anything bridge"? Would we even need FHIR as a standard?
It left me thinking that maybe we end up in a future where:
The process / workflow of Implementation Guides become less useful, as LLMs effectively layer over and encase existing processes. Maybe this happens with prior authorization — maybe the provider portals and phone-lines continue to be used by LLM agents, and the modernization of electronic exchange becomes irrelevant.
The schema, validation, and REST features of FHIR become more useful — because making the "anything bridge" work well will require RAG for the destination schema, and providing
$validateas a tool function an LLM to create an automatic feedback loop for error correction.
The day before this talk, and unmentioned at the event, Google released two papers Towards a Personal Health Large Language Model and Transforming Wearable Data into Health Insights using Large Language Model Agents. Obviously this will continue to be a popular subject.
EHI Export is Broken
Josh Mandel expanded on his recent Twitter thread on the subject and spoke about his trials and tribulations in trying to take advantage of ONC’s EHI Export certification requirement. The promise of this requirement is that a patient should be able to create “an export file(s) with all of a [their] electronic health information stored at the time of certification by the [EHR]”.
Turns out this is totally broken in the wild.
Part of the requirement is that certified products must make publicly available a documentation link that describes the structure and syntax of the export. A schema definition basically. Without a schema, processing the data will be challenging to say the least.
Josh’s talk covered his frankly herculean data efforts to make sense of his personal EHI export from an Epic system. After waiting 21 days, and an Epic employee manually intervening after seeing his Twitter thread, Josh obtained hundreds of TSV files.
Epic sort of publishes a reasonable schema, but when you dive into the details as Josh did, it’s clear that interpretability is challenging to say the least.
There was some speculation after the talk that maybe ONC could at least change the testing for this requirement from mere attestation to something tangible.
SQL, Schemas, and Types
SQL on FHIR was a major topic across multiple sessions, including an implementation showcase with participation from Health Samurai, Google, NCQA, and CSIRO’s Pathling. Community presenters think that a summer tagged release is possible.
Alex Walley, of NCQA, announced having written a C++ FHIR SDK with FHIR Path support (an implementation requirement of SQL on FHIR). This is very exciting.
Nikolai Ryzhikov of Health Samurai showcased a visual ViewDefinition Designer that you can try out for yourself. This demo was particularly impressive because the View Definition is transpiled into an SQL `SELECT` statement.
The basic idea of SQL on FHIR is to define a process for projecting FHIR Resources into a tabular format. That process is actually quite simple — you define a structured list of columns for your projection that maps a FHIR Path on a Resource to a column name. This is called a View Definition.
Then, a View Runner is an implementation which is capable of taking Resources from some input (could be a database, NDJSON, or even the FHIR REST API), executing the FHIR Paths for each column in the projection, and then returning an output (again, could be anything from raw SQL statements to CSV lines to Parquet files).
Relatedly, Nikolai also presented on FHIR Schema — a hidden feature of his SQL on FHIR demo. Implementing a validator from scratch for FHIR is difficult. There are only a few implementations in the wild today — it’s hard and requires esoteric knowledge. Most implementations end up converting StructureDefinitions into some intermediate nested data structure. The goal of FHIR Schema is to define that intermediate data structure.
My take is that this is an extremely high leverage effort. Having a FHIR Schema DSL would enable better code generation tools, FHIR Path implementations, and even impact the quality of output of LLMs. I’d like to see a community call begin here now that a reference implementation has been published on Github.
FAST: Consent
FHIR at Scale Task Force’s David Pyke announced a new FAST project for managing patient consent at scale. Consent management is going to become a bigger deal with CMS-0057-F’s Provider Access and Payer to Payers APIs.
Provider Access requires allowing a patient to opt-out and Payer to Payer requires a patient to opt-in. Both of these operations will involve the exchange of consent information.
During Q&A Mark Scrimshire noted that the latest build of DaVinci PDex, the core IG for the Payer to Payer API, includes a Consent profile. This is welcome news because the “simple consent” described by CMS-0057-F is a head-scratcher when it comes to what implementation means.
Consent is a critical part of health information exchange, and at Flexpa we’re excited to join the FAST project and help provide patient-first perspectives.
Thanks to Josh Mandel, Will Rosenfeld, Scot Bly, Wayne Williams, Daniel Speroni, Gino Canessa, David Pyke, Linda Michaelson, Nikolai Ryzhikov, Alex Walley, and Vadim Peretokin for great conversations and presentations.
Additional thanks to Vadim Peretokin and Brendan Keeler for submitting corrections.