A practical guide to understanding which healthcare information models belong where. Distinguish concepts from clinical content, exchange structures from persistence, and operational records from analytical common data models, then govern the transformations between them.
The strongest architecture separates conceptual meaning, reusable clinical content, use-case constraints, exchange representations, persistence and secondary-use models. Translation between these layers is expected. The risk arises when a transformation is treated as semantically neutral or when one successful model is promoted beyond the purpose for which it was designed.
Information requirements should exist independently of the exchange technology. A FHIR profile can express a computable implementation contract, but it should not be the only place where the clinical requirement is defined.
openEHR archetypes, CDA documents, FHIR resources, DICOM objects, OMOP tables and CDISC study models make different trade-offs because they serve different purposes. That is a strength, not evidence of standards failure.
Mapping from a source record into a profile, common data model, classification or analytical mart can alter meaning. Preserve the source semantics, mapping rationale, terminology versions and provenance.
The supplied Health Data Operability material provides the central argument: information models bind data elements into clinically coherent structures, metadata and terminology are complementary layers, and operability can be lost when context is flattened during exchange, migration or reuse. Current authoritative specifications were then used to verify the scope and current status of individual model families.
Direct standards claims are recorded as facts. Suitability and architecture choices are analytical or professional inferences. Current-use and strategic-potential scores are qualitative navigation aids, not measured adoption statistics.
Real implementations may combine them, but governance becomes clearer when each layer has a named purpose and owner.
Defines the care concepts, data-element meanings, relationships, terminology bindings and enterprise definitions that should survive individual implementations. Examples: ISO 13940, ISO/IEC 11179, terminology concept models.
Structures clinically coherent information for capture and longitudinal use. Examples: PRSB information models, openEHR archetypes/templates, ISO 13606 archetypes.
Represents information for a particular interoperability contract or persistent artefact. Examples: FHIR resources/profiles/logical models, CDA documents and DICOM information objects.
Normalises or reshapes source information for reporting, cohort discovery, observational research or clinical trials. Examples: OMOP, i2b2, CDISC ODM/SDTM and dimensional models.
Retains the source models, versions, mappings, terminology context and representation information needed to understand records after systems and models change.
Clinical documents preserved authored context; archetype approaches separated stable technical models from evolving domain content; FHIR made structured information accessible through mainstream developer tooling; common data models normalised heterogeneous data for reproducible analysis. Each step addressed a different problem.
A national architecture can legitimately use ISO 13940 for concepts, ISO/IEC 11179 for governed data definitions, PRSB-style content requirements, FHIR for exchange, openEHR for longitudinal persistence, DICOM for imaging and OMOP for research. The governance challenge is the mapping, not the coexistence.
The schematic places representative models from conceptual to implementation-specific and from direct-care information to secondary-use normalisation. Select a node to open the corresponding catalogue entry.
Select a use context to make suitability, current use and strategic potential context-sensitive. A model with excellent research utility can correctly score poorly for direct clinical capture without that being a criticism of the model.
The recommendations deliberately combine models at different layers. The distinction between primary and supporting models matters more than selecting a single winner.
These transitions are normal architectural work. The assurance requirement is to make the semantic change explicit.
Check that every important business/clinical concept remains traceable into the content model rather than being inferred from field names.
Record cardinality changes, extensions, terminology bindings and elements that cannot be represented without approximation.
Preserve authorship, effective time and narrative context; do not treat the document as automatic current truth.
Record source-to-standard concepts, derived dates and loss of workflow or uncertainty context.
Retain source model definitions, terminology versions, reference tables and provenance alongside archived records.
Make the canonical model's scope explicit and retain reversibility where clinically significant distinctions would otherwise disappear.
Clinicians, social-care professionals, analysts, terminologists, records specialists and software teams see different aspects of the same information. A model becomes fragile when any one group can define it without the others, or when supplier configuration is the only surviving expression of meaning.
Own clinical and operational meaning close to the profession and service that creates it.
Publish shared definitions, value sets, model identifiers and mappings through governed registries and terminology services.
Validate profiles, templates and schemas mechanically, but do not mistake structural validation for complete semantic assurance.
A mature architecture should be able to trace a concept from its business definition through clinical content models, exchange profiles, persistence structures and analytical derivatives. That chain is more valuable than an enterprise model that claims to eliminate translation but merely hides it.
Terms such as “data model”, “canonical model”, “clinical model” and “logical model” are routinely used without specifying their abstraction or purpose. Requirements should say whether they mean a concept system, information requirement, logical content model, exchange profile, persistence model or analytical common data model.
“FHIR will be the national data model.”
Problem: does not say whether FHIR is the exchange contract, persistence model, clinical content model or analytical representation.
“National clinical information requirements will be governed independently and mapped to FHIR profiles for specified exchange use cases.”
“Every transformation shall retain traceability to the source model, model version, terminology version and mapping used at the time.”
Evidence type distinguishes direct source facts from analysis. Severity indicates the consequence of a modelling error rather than the quality of a particular standard.
| ID | Dimension | Finding | Evidence type | Severity | Confidence | Sources |
|---|
Require every model artefact to state its purpose, abstraction level, owner, version, lifecycle status and intended consumers.
Record mappings centrally with semantic-loss notes rather than burying them in interface engines, ETL code or supplier configuration.
Keep clinically agreed information requirements durable even when FHIR, CDA, openEHR or another implementation technology changes.
Longitudinal data cannot be interpreted safely if the definitions and terminology versions that governed its creation are discarded.
Where canonical mediation is useful, define its bounded scope and do not allow it to become the unexamined enterprise source of semantic truth.
For critical transformations, test whether information can be reconstructed with clinically important distinctions intact, not merely whether schemas validate.
It is a professional architecture guide rather than a formal conformance specification. Individual standards contain substantially more detail than can be represented here. Model adoption varies by jurisdiction, specialty and vendor. CDISC SDTM v3.0 is still shown as resolving public-review comments on the current CDISC site, and ISO 13606-1 Edition 3 remains under development, so those items are explicitly treated as evolving rather than settled.
