Interoperability Is a Governance Problem, Not a Data Model Problem
Executive Summary
Interoperability discussions almost always start in the wrong place.
They focus on:
- data models,
- schemas,
- vocabularies,
- formats.
And when systems fail to interoperate, the conclusion is predictable:
“We need a better data model.”
This post argues the opposite:
Most interoperability failures are governance failures, not technical ones.
OMOP, FHIR, CDISC, and related standards address a large part of the syntactic problem. What they do not solve on their own is ambiguity, drift, ownership, revision policy, and accountability (Gazzarata et al. 2024; Arvanitis 2014).
The Comfortable Myth: “If We Map It, It Will Work”
Interoperability is often treated as a one-time technical task:
- map source fields to standard concepts,
- load data,
- declare success.
This works only if:
- everyone agrees on definitions,
- meanings do not change,
- documentation practices are stable,
- and use cases are aligned.
In real clinical and operational systems, none of these are guaranteed.
What Interoperability Actually Means (In Practice)
Operational interoperability requires agreement on:
- meaning (what does this variable represent?)
- context (when and why was it recorded?)
- timing (what was known at the moment of use?)
- revision (can this value change later?)
- intent (what decisions will rely on it?)
No data model can fully enforce these.
Only governance can.
That is why semantic interoperability is more than syntax. It depends on preserving context and meaning across systems, not merely moving values from one table to another (Arvanitis 2014).
Why “OMOP-Compliant” Datasets Still Don’t Interoperate
It is common to see two datasets that are both:
- OMOP-formatted,
- vocabulary-mapped,
- syntactically valid,
and still analytically incompatible.
Why?
Because:
- one site records “SBP” at triage,
- another records it post-resuscitation,
- one revises values,
- another freezes them,
- one encodes missingness explicitly,
- another silently drops it.
Same concept IDs. Different realities.
Vocabulary Alignment Is the Easy Part
Controlled vocabularies solve:
- naming,
- hierarchy,
- semantic reference.
They do not solve:
- operational definitions,
- timing rules,
- abstraction practices,
- revision policies.
Assuming vocabularies guarantee interoperability is a category error.
The OHDSI vocabulary system is extraordinarily powerful, but it was built to standardize concepts and relationships, not to eliminate local ambiguity about how values were produced or updated (Reich et al. 2024).
Interoperability Breaks at the Value Level
Most interoperability failures occur at the value level:
- what counts as “severe”?
- what time window applies?
- what units are implied?
- what does “unknown” mean?
Without value-level governance:
- harmonization becomes guesswork,
- analytics diverge,
- trust erodes.
This is why value-level metadata matters more than table structure.
Drift Is the Default State
Even perfectly aligned systems drift over time:
- documentation practices evolve,
- clinical protocols change,
- software updates alter fields,
- abstraction rules shift quietly.
Without governance:
- mappings become stale,
- comparisons become invalid,
- analyses quietly break.
Interoperability is not a state you reach. It is a condition you maintain.
Governance Questions Interoperability Depends On
Every interoperable system must be able to answer:
- Who defines this variable?
- Who approves changes?
- Who documents revisions?
- Who communicates drift?
- Who validates downstream impact?
- Who arbitrates disagreements?
If the answer is “the data model,” you have a problem.
Why Technical Fixes Keep Failing
Common responses to interoperability failure include:
- more mapping rules,
- more transformation logic,
- more metadata fields,
- more code.
These help — temporarily.
But without governance:
- ambiguity accumulates,
- assumptions diverge,
- pipelines rot.
You cannot code your way out of an ownership problem.
What Good Interoperability Governance Looks Like
Effective governance includes:
- clear variable ownership,
- documented operational definitions,
- versioned value-level dictionaries,
- change-control processes,
- audit trails for revisions,
- explicit use-case alignment.
None of this is glamorous. All of it is necessary.
These practices also align with broader FAIR principles, which emphasize that reuse depends on well-described, context-rich, and responsibly managed data rather than mere availability (Wilkinson et al. 2016).
Interoperability Without Governance Creates False Confidence
The most dangerous state is:
- cleanly mapped data,
- polished dashboards,
- confident cross-site comparisons,
- unexamined assumptions.
This is where decisions get made on illusory alignment.
Governance prevents false equivalence.
How to Talk About This Without Alienating Engineers
Try this framing:
“Data models tell us where things go.
Governance tells us what they mean and when they can be trusted.”
Most engineers understand this immediately.
FHIR, for example, has become a central interoperability standard precisely because it offers a robust exchange structure. But the literature around FHIR repeatedly shows that implementation guides, validated datasets, and shared governance remain essential for trustworthy reuse (Gazzarata et al. 2024).
A Simple Interoperability Test
Ask this:
If two sites report the same OMOP concept, can we explain why their values differ — and which difference matters?
If not, interoperability is superficial.
The interoperability governance problem is directly blocking military health AI at scale — a predictive model that performs well on MHS GENESIS data at one MTF cannot be validated across MTFs without a data sharing agreement, a common data model, and agreed-upon concept mappings. OHDSI’s network model — where each site runs analyses locally on locally-mapped data and shares only aggregate results — is the governance template most compatible with DoD data security requirements for MAVEN federated analytics. When governance is treated as a technical afterthought rather than a precondition, teams build models that cannot be independently validated and cannot be deployed beyond the site where they were trained. The resulting AI systems are perpetually research-grade regardless of their algorithmic sophistication.
Series Callout
This post is part of a broader Observational Medical Outcomes Partnership Common Data Model applied to a Trauma Registry Series:
- OMOP Was Built for Longitudinal Care — Trauma Breaks That Assumption
- Interoperability Is a Governance Problem, Not a Data Model Problem
- Why Trauma Registries Need Value-Level Metadata (and How OMOP Enables It)
- From Research Database to Operational System: Making OMOP Trauma-Ready
- OMOP as a Translation Layer Between Civilian and Military Trauma Systems