Blog · Data quality

What FHIR Validation Does NOT Check

A FHIR bundle passes validation. That means it meets the rules that were checked. On its own, that does not show that the meaning of the source has arrived.

Technical clarification of 15 September 2026: validators check more than structure (including profiles, terminology bindings and invariants) and can flag problems — the text previously said they only see the form. The four patterns are now phrased as a non-exclusive description (“can” instead of “any”), and the offer note points to the SILD Pilot instead of a quantified audit of production exports. Originally published on 9 June 2026.

A FHIR bundle passes validation. That means it meets the rules that were checked. On its own, that does not show that the meaning of the source has arrived.

Conformant is not interpretable.

What validation checks

A validator answers one precise question: does this resource comply with the profile’s rules? It checks structure and data types, cardinalities, bound terminologies, slices, constraints and invariants. If everything fits: green. That is valuable and necessary — and it is exactly one level.

What it does not check

Whether the information of the source survived the transfer. The validator sees the resource that arrives — not the one that should have arrived. It can flag problems, for example a missing mandatory element or a code outside the bound value set. But if what remains is rule-conformant, a loss relative to the source usually stays invisible to it, because the source is not part of a typical target validation. Project-specific rules or tests can add this comparison. In our work on SILD we describe such losses with four patterns; a single finding can involve several of them at once:

  • Type Narrowing — a precise concept is mapped onto a coarser one (the specific SNOMED code ends up as an unspecific ICD entry). The target element is valid; the precision of the source is no longer in the target.
  • Temporal Collapse — a time interval is reduced to a single point in time (a course from 08:12 to 11:47 becomes an all-day entry). The date is formally correct; the temporal reference is lost.
  • Attribute Dropping — a qualifying attribute is missing: unit, status or negation. Depending on the profile, “no known allergy” and a missing entry can be equally permissible to the validator.
  • Reference Severing — a link between resources breaks, and the context that carries the statement is lost. The finding remains, its order reference does not.

Each of these losses can occur inside a technically successful, formally valid transfer.

Why “validated” misleads

Validation checks whether the result meets the chosen rules — structure, profiles, terminology bindings, invariants. On its own, target validation does not compare it with the source. Anyone measuring data quality by the green check alone mistakes rule conformance for preservation of information.

What it takes instead

A second layer of inspection with a different question: did the meaning survive? To answer it, the information to be preserved and the comparison rules have to be agreed explicitly. That links technical checking with domain responsibility. This is where SILD comes in: it compares source and target against agreed review rules and the four patterns from the FM-4 model (self-archived, not peer-reviewed preprint), as part of CAIRN. Next to “green” there is then a traceable finding — with the limit that a sample without findings does not prove general freedom from loss.

About ISCaD

In the SILD Pilot we review one defined data transfer against review rules agreed in writing — using released test data or effectively anonymised data, with a report and a findings list. If you want to know what arrives on your transfer: see the SILD Pilot.

The formal foundation is documented at aion-clinical.eu; the detector is open source at github.com/fmatten/SILD.

← Back to the blog