Imagine a library consolidating decades of locally catalogued books into one shared catalogue.
The new catalogue is carefully designed. It has clearly defined fields, agreed categories and controlled terms. It specifies what information belongs where and which values may be used.
But the books were not originally described that way.
Some are recorded in old systems, others under local abbreviations or in free text. Some follow conventions that only the people working with that catalogue have learned to understand.
Before those records can be entered into the new catalogue, someone must interpret the original information and decide where each part belongs.
FHIR implementations face a similar challenge.
FHIR provides resources, elements, profiles and terminology bindings that make the intended structure and coded meaning explicit. It can define which type of information belongs in an element and which ValueSet should be used within that context.
It can also validate whether the resulting resource follows those agreements.
But validation can tell us that a selected code is permitted. It cannot always tell us whether it was the right concept to select from the original source.
If a local code was misunderstood, an ambiguous description was simplified too quickly or a legacy value was mapped to the closest available concept rather than a truly equivalent one, the FHIR resource may still be valid.
The data has arrived in the correct field.
The code may belong to the expected ValueSet.
But the meaning may still have been placed on the wrong shelf.
This is not a limitation of FHIR. It is a reminder that interoperability depends on the decisions made before the message is created. Mapping requires knowledge of both the source and the destination, as well as the context in which the original information was recorded.
FHIR can make the target explicit.
It cannot automatically recover meaning that was unclear, implicit or already lost in the source.
Perhaps the question is therefore not only whether our FHIR implementation is valid. It is whether the path into it was semantically sound.
The resource can be valid.
The meaning can still be misplaced.
.
Next week: ZIB’s
What have we actually agreed to mean before software implements it?
SemanticWeekly ConceptMap SemanticInteroperability HealthInformatics
