A practical guide to choosing and combining health data architecture patterns without confusing operational records, interoperability, analytics, semantics and preservation. Start with the purpose and lifecycle of the data, then assemble an architecture that preserves meaning, provenance and accountability.
The navigator takes a federated, lifecycle-aware position. Operational systems, clinical repositories, interoperability services, analytical models and archives solve different problems. They should be connected through shared identity, terminology, metadata, provenance and governance rather than collapsed into one universal model.
A FHIR resource, an openEHR composition, an OMOP row, a Data Vault satellite and a dimensional fact table can all be legitimate representations of the same underlying event because they serve different purposes.
Identity, terminology and shared definitions benefit from authoritative coordination. Clinical source data and contextual accountability often benefit from remaining closer to where they are created.
Architecture is not only where data resides. Every mapping, derivation, profile, semantic layer and analytical model changes how the data can be interpreted. Those transitions require lineage and governance.
The map is schematic rather than a taxonomy. Select a node to open the corresponding pattern in the catalogue.
Current use and strategic potential are qualitative professional assessments rather than adoption statistics. They change with the selected use context because a pattern can be mature and valuable in one domain while inappropriate in another.
The recommendations deliberately combine patterns. The result is an architecture starting point, not a procurement specification.
The distinction is architectural and governance-based rather than ideological. A health system may deliberately combine central coordination, local custody, selective replication and federated access.
Ask what would be lost if the central service disappeared tomorrow. If an organisation could no longer state what its own data means because the semantic model exists only inside a supplier platform, the architecture has created semantic dependence even if every row of data remains exportable.
The safer target is portable data plus portable meaning: definitions, mappings, value sets, provenance, process state, business rules and model documentation should remain governable by the health system.
The planes interact continuously. The diagram is deliberately technology-neutral and should not be read as a mandatory deployment topology.
Forcing operational, exchange, analytical and archival needs into one model hides legitimate differences and pushes translation problems downstream.
A lakehouse, EHR, FHIR server or operational platform becomes the assumed answer to storage, integration, semantics, analytics and preservation simultaneously.
Contracts guarantee data export while the models, mappings and object semantics needed to interpret those exports remain supplier-controlled.
Near-raw data is retained without the representation information, provenance and workflow context required to reconstruct its original meaning.
A strong interoperability representation is used as the answer to operational persistence, research, analytics and long-term preservation without separate architectural judgement.
More records are brought together without resolving authority, workflow state, provenance or semantic differences among sources.
Curated warehouse or lakehouse outputs are allowed to drive live care processes without acknowledging latency, transformation and purpose-specific semantics.
Historical data survives technically but cannot be interpreted confidently because code systems, reference tables, authorship and original context have disappeared.
The navigator combines the supplied Health Data Operability framework with authoritative architecture and standards sources. Pattern assessments are analytical judgements, not claims made by the cited organisations.
Primary conceptual source. Used for the federated semantic architecture, distinction between centralising coordination and centralising clinical data, metadata independence, preservation, trust, process context and architecture anti-patterns.
Used as a contemporary public-sector reference architecture source for modular, standards-based national health infrastructure, shared building blocks and architectural coherence. The WHO consultation opened 9 July 2026 and closed 6 September 2026; the guidance remains draft at the date of this navigator.
Used for the characterisation of openEHR as a model-driven architecture separating domain semantics from software and using archetypes/templates with versioned EHR structures.
Used to position FHIR principally as a healthcare interoperability and application architecture rather than as a universal persistence or analytical model.
Used for the document repository/registry and federated document-sharing pattern.
Used for the characterisation of OMOP as an open community standard for standardising observational data to support reliable analyses and network research.
Used for the four data-mesh principles: domain ownership, data as a product, self-serve platform and federated computational governance.
Used for Data Vault 2.0 as a combined modelling, architecture and methodology approach focused on historised, extensible analytical integration.
Used for the general lakehouse pattern combining lake-style storage with warehouse-style data management and analytical capabilities.
