Catching AI-induced FHIR regressions with Records' continuous validation gates — Oct 22, 2026
Register to get the calendar and joining links for the weekly calls
One registration covers every upcoming Agents on FHIR call.
Loading your registration…
Don't have an account? Signing in creates one in seconds.
André Sheydin joined from Germany to demo Records, the FHIR data quality layer he builds at MedVertical. The core demo: Claude Code edits a synthetic Observation on an Aidbox project, and Records re-reads the resource to check both required profiles after every change. The pitch underneath it: FHIR data should be treated like code and validated continuously, not snapshotted at implementation and forgotten. Nikolai Ryzhikov hosted; Gino Canessa pressed on how profiles get selected.
Live demo: catching regressions after each AI edit on Aidbox
André started from a synthetic Observation - oxygen saturation at 82% from the SYNDERAI EHDS release - sitting on a Health Samurai Aidbox project. The resource has to satisfy two profiles at once: Oxygen Saturation and EU Laboratory. The initial validation flagged a missing vital-signs category plus an unrelated finding on a server-added creation-time extension.
Claude Code was then prompted to add vital-signs alongside laboratory. After revalidation, the category finding dropped off; the extension finding stayed exactly where it was. The negative test followed: Claude removed laboratory while keeping vital-signs. Records picked up the regression immediately - checking only the oxygen profile would have missed it entirely. Restoring both categories closed the loop.
Claude's explanation is not validation evidence. It's only the confirmation that the operation has been done.
The point André wanted to leave on the table: AI-generated FHIR can look convincing in JSON while silently violating another required profile. Every write needs an independent read-and-validate pass against the full set of requirements, not just the one you had in mind when you prompted.
From designer frustration to a data quality layer
André is a software designer, not a developer. He started Records as a personal viewer after a forms project where developers kept telling him that some clinical data points couldn't be mapped to FHIR. Reading the raw JSON wasn't enough to design the form: he needed to see what constraints each profile added and where a resource fell short.
The viewer grew into a validation layer, then into a data quality platform aimed at QA people who need to assess FHIR data without first becoming FHIR experts. He runs MedVertical as a startup of two, with an architect reviewing the shape of the system from time to time; LLMs do most of the implementation.
FHIR is not only for FHIR experts. Many of the complex concepts, if represented in a proper UI, let you outsource some of the tasks to roles where deep FHIR knowledge is not necessary.
Quality gates: continuous integration for FHIR data
Records' top level is environments, each holding one or more FHIR servers. Every validation run produces a pass or fail signal that a pipeline can act on - stop a deployment, flag for review, or let it through. Thresholds are configurable per environment: pass score, warn score, hard minimum score.
The reason it has to be continuous, not snapshotted-at-implementation, is that FHIR data can drift without the data itself changing. A new terminology version or a new profile version silently moves what counts as valid.
FHIR data quality should be regarded as code. It can - just like programming code - drift even if the data doesn't change.
Nikolai framed it directly:
It's like continuous integration for your data.
André extended the argument to the AI side: letting agents write invalid FHIR is bad, but letting them read invalid FHIR is worse, because hallucinations get amplified by bad input. Records also tracks triage items that auto-resolve on the next run once a fix removes the error, so recurring findings don't drown out new ones.
A TypeScript rewrite of the HAPI validator - in a month
The validation engine inside Records is an open-source TypeScript re-implementation of HAPI, written against the official FHIR validator test fixtures. XML resources and legacy FHIR versions are out of scope; JSON cases have parity, checked on every release. The core is open source; the batch logic that compares runs, skips unchanged resources via last-updated deltas, and feeds the triage queue is the commercial surface.
The reason to rewrite at all was speed and portability: HAPI needs to warm up before it validates, and Java isn't welcome in a lot of production stacks. André was candid about the economics:
Before LLM times it would be a complete overkill. Nobody would do it. With the right strategy and different LLMs I was able to achieve 100% parity in about a month of work.
Records is validator-agnostic - the HAPI engine can be swapped back in from the UI when it's available on the host. Nikolai pointed to Health Samurai's own open-source TypeScript FHIR Schema validator as a compatible alternative worth comparing against.
Which profiles get validated against
Gino Canessa asked whether the profiles that Records checks come from the resource instance or from the user. Both, as it turns out. By default a resource is validated against the profile it declares, with installed profile packages cached locally so air-gapped environments work. Users can then add up to five additional profiles per resource or per batch run - handy for smoke-testing a new German ISiK version, or seeing what an R4 payload would break against R6 before anyone touches production.
Pilots, EHDS, and bringing Records to the FHIR community
Records is in pilot with two customers. The public one is work on synthetic data generation for the European Health Data Space, in collaboration with HL7 Germany's SYNDERAI project - Records validates the EHDS synthetic bundles and has flagged issues HAPI caught too, plus some HAPI missed. Several interested customers didn't have a continuous validation problem on their radar until André described one to them.
The business bet behind the EHDS angle: once hundreds of data holders start shipping FHIR into a central store for secondary use, the center can't afford to revalidate everything. Each data holder needs to produce a reproducible, comparable report on its own quality before delivery.
You want each data holder, before sending the data, to validate it themselves on a comparatory basis that is reproducible - so you can trust the report and don't need to retest it yourself.
A public demo lets anyone browse single resources and run validation; batch validation needs an account, and account creation is currently closed while things stabilise. André plans a limited free-token tier aimed at IG implementers rather than opening the gates completely. A Claude plugin covers the local-validation subset for free today.
Nikolai invited André to FHIR Camp in Portugal in November and offered promotion help in the FHIR community. André asked for an offline follow-up on where Records and Health Samurai might cooperate - there's overlap in both directions, and he'd rather map it out before showing up in Cascais.