What Did Not Change
Over thirty years the technology moved from pipe-delimited messages to REST and JSON. The tools improved. The places where meaning gets lost stayed the same.
Technical clarification of 15 September 2026: the four patterns are phrased as a typical description, not as a complete catalogue for every transfer; the offer note points to the SILD Pilot with agreed review rules. Originally published on 5 June 2026.
HL7 v2: segments, fields, pipes. FHIR: resources, profiles, REST. The progress is real — better tooling, clearer models, a living ecosystem. But the points where integration fails in practice were never technical. So the change of technology did not carry them along — it translated them into a new syntax.
The same four losses
Four typical patterns we use to describe loss of meaning at system boundaries each have a counterpart in both worlds:
- Type Narrowing — back then the local in-house code in a free-text field, today the specific SNOMED code that ends up as an unspecific ICD entry. Precise becomes coarse.
- Temporal Collapse — back then the truncated timestamp, today the interval that becomes a single point in mapping. A course becomes a moment.
- Attribute Dropping — back then the lost unit of measure in the OBX segment, today the qualifying attribute (unit, status, negation) the resource no longer carries. A finding becomes a number.
- Reference Severing — back then the broken link between ORC and OBR, today the basedOn reference that does not resolve. Context becomes fragment.
What is genuinely new — and what is not
The means are new: FHIR offers cleaner ways to avoid these losses than HL7 v2 ever had. The decision behind them is not new. Whether the unit is carried along, whether “empty” is modelled as “not recorded” or “not present”, whether the reference holds — that was unresolved in v2 and remains so in FHIR, as long as no one settles it deliberately.
The point
These are not format problems. They are governance tasks. A new format does not solve them — it merely shifts them into a new syntax. Anyone who does not address these patterns risks rebuilding them in FHIR. The honest measure of a migration project is therefore not “does the FHIR API run?” but “have we made the decisions that HL7 v2 left open?”.
We support KIS→FHIR migrations at exactly these points. 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 review your migration that way: see the SILD Pilot or get in touch.
The formal foundation — AION, CAIRN and the SILD detector (FM-4) — is documented at aion-clinical.eu.