Three codegen demos, and the standoff over FHIR validation — Apr 2, 2026
Codegen demo #1 — types from any IG (Aleksandr Kislitsyn)
Aleksandr demoed a skill that generates FHIR types without being told how — it detects the project language, installs the open source codegen package, writes the config and runs it. The config decides which IG packages and profiles to pull from, with tree-shaking, so you get US Core Patient and the types it actually touches rather than all of R4.
The generated classes carry helpers for extensions, conversion between a profile and a plain resource in both directions, and the validation you can derive straight from a profile — such as required extensions.
Codegen demo #2 — SQL dialect linter (John Grimes)
John built a skill on SQL Glot, a Python transpiler that knows 31 SQL dialects: it takes a query, transpiles it to every dialect, and reports where the meaning drifted. On a query he had written to populate an OMOP table from SQL on FHIR views it correctly guessed Postgres and flagged two things:
::datecasts — other engines don't understandIFNULL— a MySQL/SQLite word whereCOALESCEworks everywhere
The bulletproof check is still running against every engine you care about, and John wants to get there by spinning up real databases and SQL on FHIR runners. This is the cheap version until then.
Codegen demo #3 — BabelFire TS + ProxySmart (Max Nussbaumer)
Max's BabelFire TS also generates types and validators from StructureDefinitions, but the interesting part was how he measures it — parity tests against the Firely .NET SDK, the HL7 validator and his own generated Zod schemas, on the theory that where three implementations disagree, someone has a bug worth finding.
The goals have to be worked in order — empty-resource parity, then random-data parity, then valid-resource parity. An agent left alone will maximise whichever metric moves easiest.
He also showed ProxySmart, an open source proxy that puts SMART auth in front of any FHIR server, with an MCP endpoint so an agent can register apps instead of a human filling in forms.
The standoff — does FHIR validation need a schema?
The real argument was Nikolai Ryzhikov against Brian Kaney.
Validation is an algorithm. Only a couple of people in the world fully understand how it should work. FHIR schema exists to make the algorithm explicit enough for anyone to implement fully — running the spec's narrative through it surfaced five bugs in the spec itself.
Code generation is free now, so a machine-readable schema buys little. The layer worth agreeing on is a semi-structured narrative you can check for logical completeness and conflicts.
Josh Mandel pressed Brian to pin down that he meant constraints over what resources may look like. Neither moved.
Arjun's proposal — stop arguing, measure
A public matrix of validators against a shared test suite — the way SQL on FHIR has one for its implementations. Behaviour is comparable and transparent instead of living in a few people's heads.
Steve Munini put the FHIR schema effort forward as a candidate single source of truth for what validation even means.