Clinical data exists in silos. An electronic health record system in one institution uses different codes, different field names, and different data models than the system used by a collaborating research centre. A clinical data management system uses different nomenclature than the pharmacovigilance database that needs to import its adverse event data. These are not merely technical inconveniences — they represent a fundamental barrier to research at scale.
The Three Levels of Interoperability
In health informatics, interoperability is described at three levels. Technical interoperability means systems can exchange data — the network connection works, the APIs respond. Syntactic interoperability means the structure of the exchanged data is consistent — both sides agree on the schema and field names. HL7 FHIR resources provide syntactic interoperability for many clinical data elements. Semantic interoperability means both sides agree on the meaning of the exchanged data — that "blood pressure systolic" in system A refers to exactly the same clinical concept as "SBP" in system B, measured under the same conditions, in the same units. Achieving this requires a shared reference ontology.
Why Syntactic Interoperability Is Not Enough
Many organisations have invested heavily in syntactic interoperability and discovered — often painfully — that it does not solve their actual problem. Two systems can exchange HL7 FHIR bundles without difficulty and still produce contradictory analytics because one system codes hypertension as a chronic condition and the other codes it only when it affects a current encounter. The structure is the same; the semantics differ. This is particularly damaging in federated research settings where data from multiple sites is aggregated for analysis.
The classical solution is to create formal mappings between each local coding system and a shared reference ontology. Queries are expressed in the shared ontology and translated at each site into local terms before execution. Results return in the shared representation, making them semantically comparable. Maintaining those mappings as both local systems and the reference ontology evolve requires governance, version control, and regular review processes that are as important as the initial mapping effort.
