Agents on FHIR
Agents on FHIR — May 28, 2026
Arjun Sanyal
Arjun Sanyal
Principal Antidote Solutions
Nikolai Ryzhikov
Nikolai Ryzhikov
CTO at Health Samurai
May 28, 2026

Topics discussed:

  • Aleksandr's problem statement will be familiar to anyone doing long-running agentic coding: agents drift. They invent slightly different data models and slightly different implementations of the same feature every session, the schema grows fields nobody needs, and there's nothing to check the result against beyond 'does it compile'. Generic frameworks can't help because they know nothing about healthcare. FHIR arrives with 150+ resources, a validation framework, terminology and structured data capture already decided.
  • Generated types were the single biggest lever he found — typed classes generated from StructureDefinitions rather than hand-written interfaces. Without them the agent invents a couple of interfaces that then spread inconsistently across front end and back end; with them it never misses. The other tell that grounding works: ask for a patient summary feature and the agent reaches for Composition unprompted, because it already knows the model.
  • Bobby Kuzma raised the obvious objection from the integration side: FHIR has conformance testing and yet the variability across EHRs is enormous, and workflow tooling — tasks, messaging — almost always turns out to be some proprietary API even where a perfectly good FHIR structure exists. Nikolai Ryzhikov's answer was that a lot of FHIR's ambiguity is essential rather than accidental: the same clinical concept can legitimately be an Observation, a Condition or a flag depending on context, and no single answer exists. What the spec gives you is a decade of argument to draw on — whatever an engineer would hallucinate, an LLM will hallucinate too, and both hallucinate less when grounded in the same knowledge base.
  • The open question Aleksandr ended on: if the guardrails are good enough — skills, templates, components, SDKs — could you take engineers out of the loop entirely and let doctors build their own apps? Arjun Sanyal's counter was that this is a different risk from the one FHIR solves. If a clinician vibe-codes a risk score wrong, the resource still validates perfectly; the score is just wrong. Validation and evaluation are separate problems, and only one of them has tooling.
  • Ward Weistra demoed IG Gen, which breaks FHIR data modelling into seven stages — use case, logical model, map to resources, quality control, document, publish, collect feedback — and puts an agent on each stage rather than one agent on the whole job. A companion skill from Firely closes a gap in the earlier FHIR skills, which could generate resources but had no validator to run them through, so the loop never closed. Ward expects hand-writing FSH to feel antiquated within about six months, with humans reviewing agent output instead. That led into Arjun's request to the community: rebuild IG publishing agent-first, as small single-purpose composable tools rather than a monolith, on the argument that agents are good at bash precisely because it's a composable toolset they already understand.