Agents on FHIR

Turning free text into FHIR queries, and building a knowledge graph the agent can navigate — Mar 19, 2026

Ilya Beda
Ilya Beda
HL7 FHIR expert
Nikolai Ryzhikov
Nikolai Ryzhikov
CTO at Health Samurai
Josh Mandel
Josh Mandel
Chief Architect for Microsoft Healthcare, Chief Architect for SMART Health IT
Arjun Sanyal
Arjun Sanyal
Principal Antidote Solutions
Mar 19, 2026
Add to your calendar:Every Thursday9:00 AM ET3:00 PM ET
Add your demo to the agenda

Magic search in Beda EMR

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 intersects 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.

The case for a FHIR knowledge graph

Nikolai Ryzhikov
Nikolai Ryzhikov
CTO at Health Samurai

Working from the model's own memory gets you hallucination. Dumping the spec or web search results into the context blows it up and makes the agent stupider. A knowledge graph is compression and guardrails at once.

A knowledge graph is not magic — it's a synopsis of the corpus: entities, short descriptions, and the relationships between them. It lets the agent see which concepts a question is built from, navigate, and only then follow a link into the underlying text.

Nikolai 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. A couple of Postgres tables have worked as well as SPARQL so far.

Where answers actually come from

The most interesting result was an evaluation of source contribution. For an in-flight R6 feature:

  • Zulip chat — single most valuable source (the topic is new and still under development, so that's where the thinking is)
  • Knowledge graph — supplied the exact attributes
  • Web search — only 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's 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 — 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.

Arjun Sanyal
Arjun Sanyal
Principal Antidote Solutions

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.