Agents on FHIR
Agents on FHIR — March 19, 2026
Mar 19, 2026

Topics discussed:

  • Ilia demoed magic search in Beda EMR: free text goes in, and the agent emits two things — a FHIR search query and a list of FHIRPath expressions to build the results table on the fly. It handles chained search and sorting, so "oldest male patient with a stroke" becomes a condition filter plus a birth date sort. Both outputs are validated rather than trusted: search parameters are checked by firing the request at the server and assuming they're fine if nothing errors (his word for it: lazy), and FHIRPath goes through an MCP wrapper around an existing validation engine that catches semantic nonsense like patient.firstName, not just syntax. Worth noting on the safety side: the agent never touches patient data — searches run with _count=0 and access policies keep it out of the records entirely.
  • Terminology is where the naive version breaks. "Stroke" happens to match SNOMED, so expansion works and you get results; "twisted ankle" returns an empty list, because SNOMED calls it a sprained ankle. The fix is a semantic matcher that searches SNOMED with synonyms to get ranked candidate terms, then intersecting those against the expansion of the value set you actually intend to use. The gap still open: the model reliably produces a SNOMED code, but real data isn't always coded in SNOMED — vaccines being the example — and the proposed direction is to read the relevant profiles and pick the right value set from there, or feed statistics about the actual data into the context.
  • Nikolai argued the case for a FHIR knowledge graph from the failure modes either side of it: working from the model's own memory gets you hallucination, and dumping the spec or web search results into the context blows it up and makes the agent stupider. A knowledge graph is not magic — it's a synopsis of the corpus, entities and short descriptions and the relationships between them — and it acts as both compression and guardrails, letting the agent see which concepts a question is built from, navigate, and only then follow a link into the underlying text. He extracted concepts page by page (blind, then merged: exact match, then rules, then an LLM judging candidate duplicates, then a human), kept the ontology deliberately small and strict, and loaded it into Postgres, where the agent just writes its own SQL — no endpoints needed. Tim raised the obvious objection: FHIR already has an OWL ontology in the RDF part of the spec. The answer: that one is generated from StructureDefinitions and is only half the picture — this half comes out of the spec prose, where concepts like CDA live that never appear in machine-readable form, and a couple of Postgres tables have worked as well as SPARQL so far.
  • The most interesting result was an evaluation of where answers actually come from. For an in-flight R6 feature, the Zulip chat was the single most valuable source — the topic is new and still under development, so that's where the thinking is — the knowledge graph supplied the exact attributes, and web search only contributed a top-level overview; chat and graph between them covered about 95%. The graph is also much faster than web search, because it's local and small. A side finding: extraction done by very small models running on a laptop produced concepts close to what a frontier model gave, and averaging several small models closes most of the remaining gap.
  • Josh Mandel showed an interview agent for community spec work. The problem he's attacking is social: on a call with 5 to 20 people, the most vocal get the most attention, and boiling the question down to a few multiple-choice items in a form gives you a very thin picture. So a no-login agent interviews each participant instead — it asks about their role, explains the proposal, then probes where it fits their workflow and what trade-offs they'd accept, mixing free text with checkboxes where the answer really does collapse to a list. A dashboard synthesises across responses for common themes and tensions. The prompt is deliberately visible in the UI. As Arjun noted, the payoff isn't just breadth — agents follow the same instructions reasonably consistently from subject to subject, which is more than the usual process manages.