01Not loaded
Connect hospital laboratory feedAdd four encounters and observations, including a local HbA1c code different from the GP code. The existing structures accept the new source.
Lesson 1 of 7 · The problem
Why does healthcare need a flexible data layer?
Imagine an analyst is asked: How many patient encounters took place? Later, someone wants a patient’s sequence of results. A research team then wants a controlled extract containing measurements and their origins. These are different questions, often drawing on overlapping records.
Each source system was built to support its own work, not necessarily to answer every future question. Its identifiers, coding and data structures may differ from those of other systems. When new systems arrive or results are corrected, tightly coupled reporting pipelines may need changing.
The central idea
Keep a reusable, traceable record of what the sources supplied. Build different analytical views from that foundation, rather than imposing one permanent reporting shape on all incoming data.
A concrete healthcare example
Start with one laboratory result
A general practice sends a record of a glycated haemoglobin (HbA1c) measurement, commonly used in diabetes care. This is a synthetic example, not medical advice or a real patient record.
General practice feedOne incoming observation
Patient referencePAT-001
Encounter referenceGP-E01
Observation referenceGP-O01
MeasurementHbA1c
Reported value70 mmol/mol
Clinical date12 Jan 2026
The warehouse received this synthetic source assertion on 13 January 2026. The identifiers are invented and have already been reconciled for demonstration purposes.
What must we keep?
1
What is it about?
The patient, the encounter and the observation each have an identifier. We want stable points of reference.
2
How are they connected?
This encounter concerns that patient, and this observation belongs to that encounter.
3
What was reported?
The result, the measurement code and its dates describe the observation. These facts can later change or be corrected.
Report-by-report integration
Each report may need to find, match and reinterpret the source records again, with the risk of duplicating rules and history.
Reusable analytical foundation
Records can be loaded once into governed, historised structures, then transformed into different fit-for-purpose outputs. Reports still require their own definitions and controls.
What you will learn
01–02Understand
Begin with familiar records, then discover hubs, links and satellites.
03–04Experiment
Inspect the model, add sources and retain a correction.
05–07Apply judgement
Explore analytical outputs, trace changes and examine limitations.
Data Vault 2.0 is a broader approach to data warehousing, combining modelling patterns, delivery practices and architecture. This demonstrator concentrates on the modelling ideas, with selected examples of how they are used.
Lesson 2 of 7 · Guided example
Meet the three building blocks
Data Vault separates identities, relationships and descriptions over time. These are called hubs, links and satellites. Follow the same HbA1c result through each step.
Before modelling
One row contains several different kinds of information
The GP feed combines who the measurement concerns, when it happened and the value recorded. This is convenient for the GP system. A reusable warehouse needs to distinguish the elements that have different patterns of change.
PAT-001PatientGP-E01EncounterGP-O01Observation70 mmol/molResult
Notice
At this stage all the information is together. No Data Vault objects exist yet.
Building block 1 · Hub
A hub remembers which thing we are talking about
Hubs store business keys, meaning identifiers used to recognise a patient, encounter or observation. Each distinct key appears once within its defined hub. A hub normally also holds a technical key, when it was first loaded and where it came from.
HUB_PATIENTPAT-001HUB_ENCOUNTERGP-E01HUB_OBSERVATIONGP-O01
Notice
The hubs do not store the value 70. A corrected result should not require a new observation identity.
Building block 2 · Link
A link remembers how things relate
Links connect the identifiers held in hubs. The same patient can have many encounters, and an encounter can have several observations. The connections can be loaded without putting patient details into the observation hub.
PAT-001connected toGP-E01connected toGP-O01
Two link tables in this example: patient-to-encounter and encounter-to-observation. Real links normally store references to hub keys and their own load metadata.
Notice
A link is about the association, not about storing the clinical measurement value.
Building block 3 · Satellite
A satellite remembers what was said, and when
Satellites hold descriptive values and the history of changes for a hub or link. The observation satellite stores the local test code, the measured value, the unit, the clinical date and when the warehouse loaded that version.
| Observation | Result | Clinical event | Loaded |
|---|---|---|---|
| GP-O01 | 70 mmol/mol | 12 Jan 2026 | 13 Jan 2026 |
| A later correction can append another row, preserving this original assertion. | |||
Notice
Hub: GP-O01 stays the same. Satellite: a new version can be added when a reported value changes.
From building blocks to useful information
We can assemble different answers from the same underlying records
The data layer can join these keys, connections and values back together for particular needs. A service report counts encounters. A monitoring view selects suitable test results. A longitudinal view orders events for a patient.
Question AHow busy are services?
Count encounters by setting.
Question BWhat are the latest HbA1c results?
Apply agreed code mappings and select relevant values.
Question CWhat has changed over time?
Follow results and their successive source assertions.
Notice
Data Vault gives the reusable structure. It does not decide which results should count, whether different codes mean the same thing or who may see the output.
Plain English first · Technical details optional
How the layers fit together
1. Source systems
Existing GP, hospital and community software produces records.
2. Raw Vault
Hubs, links and satellites organise source assertions and loading history.
3. Business Vault
Controlled rules interpret, select and connect records for reuse.
4. Analytical outputs
Different purpose-built datasets support reports and research.
These are architectural layers, not four separate mandatory technologies. A Business Vault can contain point-in-time or bridge structures and derived rules; an analytical output is often called a data mart or data product.
For readers who want the technical detail
In a production Data Vault, hubs generally contain a surrogate or hash key, a source-qualified business key, a load timestamp and record source. Links include participating hub keys, their own key and metadata. Satellites contain payloads, change-detection information and load metadata. Table grain, key policy and temporal semantics must be defined explicitly. A hash key is a repeatable technical identifier, not a patient matching algorithm or a privacy guarantee.
Lesson 3 of 7 · Explore the model
See the building blocks working together
You have met hubs (identifiers), links (connections) and satellites (values and history). Here you can inspect their actual example rows. The left-hand stage contains incoming sources; follow the diagram towards reporting outputs on the right. Click any object to see what it contains.
How to explore
Start by clicking HUB_OBSERVATION, then ENCOUNTER ↔ OBSERVATION, then OBSERVATION_RESULT. Notice how each stores a different part of the same record. Only then move on to the Business Vault and reports.
Patient business keys4Source-reconciled synthetic keys
Encounter hubs9Distinct clinical events
Observation satellite versions9History, not replacements
Analytical endpoints4Same Raw Vault base
Important architectural distinction. This is a conceptual Data Vault 2.0 demonstration, not a working SQL warehouse, FHIR server, clinically validated model or certified Data Vault implementation. It deliberately models only a small part of a healthcare domain.
Schematic · click a model object to inspect
The layered model
Hubs anchor unique business keys; Links record relationships; Satellites preserve descriptive history. New feeds can populate existing objects or justify an additional satellite without rewriting existing historised records.
Source systems
Source-native identifiers are reconciled through an assumed governed pseudonymous crosswalk.
Raw Data Vault
Hubs · unique business keys
Links · assertions of association
Satellites · context and history
Business Vault
These are illustrative derived assets, not objects required in every physical deployment.
Analytics / delivery
Consumers can apply different grains, calculations and governance rules.
HubLinkSatelliteBusiness VaultEndpoint
Identity
Hubs
One row per distinct business key at the chosen grain, for example a source-qualified clinical observation identifier. Descriptive values do not sit in the hub.
Associations
Links
Connect patients, encounters, organisations and observations. Relationship change or correction requires explicit modelling of validity or status where applicable.
Historical attributes
Satellites
Append changed payloads, retaining provenance and load timestamps. Clinical event time is separately retained, enabling distinct temporal questions.
Model inspector
HUB_PATIENT
Stable, synthetic patient business keys. No clinical or demographic attributes are stored in the hub.
Grain: one reconciled pseudonymous patient key.
| Business key | Load timestamp | Record source |
|---|---|---|
| PAT-001 | 2026-01-01 | identity-register |
Surrogate hash keys are shown as readable tokens rather than computed digests.
Continue the learning journey
You have inspected the model. Now see how it handles change.
Lesson 4 of 7 · Try three real-world changes
What happens when the data changes?
Real healthcare data does not stand still. New systems are connected, results are corrected and additional details become available. Try the actions below. Observe what is added and what remains unchanged.
Suggested order
First connect the hospital feed. Then append the corrected GP result. Finally add community records and a device satellite. You can reset the example and try a different order.
02Not loaded
Connect community monitoringAdd four blood-pressure observations with their own source code. They become available for longitudinal and research-oriented views.
03Not appended
Receive a late correctionAppend a corrected HbA1c result (70 → 68 mmol/mol) for an existing GP observation. Keep both assertions and their respective load times.
04Not modelled
Add an observation-device satelliteIntroduce device/method metadata for community readings, without changing the original result satellite. This represents a new, independently loaded attribute group.
Baseline: only the GP feed is connected. The as-known-on date controls which loaded facts are visible, not whether a feed has been connected.
Ingestion event log
Baseline established
GP observations available. Additional source feeds and corrections await activation.
What stays stable, what evolves?
| Action | What is added | What stays stable |
|---|---|---|
| Connect a source | New keys, links and source-specific satellite rows | Pre-existing raw records |
| Correct a fact | Another observation satellite version | Observation hub key and prior assertion |
| Add a property | A new satellite and loading rule | Existing result satellite schema |
| Change interpretation | Versioned reference mapping and downstream transformation | Source-native values and their provenance |
Real installations still need schema deployment, orchestration, testing, security controls and consumer contract management.
Inspect the observation's two clocks
The clinical event date states when a measurement applied. The load timestamp states when the platform learnt about a source assertion. A late correction may carry an old clinical date and a newer load date.
| Observation | Clinical event | Known since | Raw code | Recorded value | Record source | Version |
|---|---|---|---|---|---|---|
| GP-O01 | 2026-01-12 | 2026-01-13 | GP:HBA1C | 70 mmol/mol | GP | Original |
The table shows all connected source assertions, including rows not yet visible at the selected as-known-on date, to make the time distinction inspectable.
Continue the learning journey
You have changed the inputs. Now inspect the outputs.
Lesson 5 of 7 · Different questions, different answers
One reusable layer can support several kinds of analysis
An analytical endpoint is a prepared dataset or view designed to answer a particular question. The source records do not have to be reshaped permanently into one universal report. Choose an output below, then return to Handle change to load another source and see what changes here.
Try this
Compare Service activity with HbA1c monitoring. They use overlapping data but answer different questions. A hospital result is not included in HbA1c monitoring until its different local code has a deliberately approved mapping in this synthetic example.
Operational intelligence
Service activity
Count encounters by source setting at the selected knowledge date.
Grain: one row per care setting.
| Care setting | Encounters |
|---|
Dependency path
Encounter and organisation hubs, links and encounter context satellite.
Consumer responsibilities
Activity definitions, coverage, duplicate events and applicable permissions must be agreed with service owners.
Business rule: terminology mapping
The GP's GP:HBA1C and hospital's HOSP:A1C are distinct source codes. No clinical equivalence is established by an identical-looking label alone. In this synthetic example, a reviewed mapping can enable their use in the same demonstration cohort.
Mapping is not yet approved. Hospital HbA1c records remain source-native and are excluded from the HbA1c monitoring endpoint.
Continue the learning journey
You have compared the reports. Next, follow the origin of a value.
Lesson 6 of 7 · Where did this value come from?
Follow a value from source assertion to consumer product
A Data Vault provides the structural basis for provenance and history, but useful analytical trust also requires controlled identities, data quality expectations, terminology governance, reproducible transformation rules and access decisions.
1 · SourceGP / hospital / community codes and event records
2 · Raw VaultHubs, links and immutable source assertions
3 · Temporal viewChoose observation version known at cut-off
4 · Business rulesGoverned mapping, deduplication, aggregation
5 · EndpointPurpose-specific data contract and access
Select an observation to view its lineage.
Corrective history is visible
With the late correction enabled, choose GP-O01 and compare February and August. The same source-qualified observation business key produces different results as known at those points in time, while the original version remains accessible.
Two different questions: “What was clinically effective in January?” and “What did the platform know in February?” must not be conflated. Bitemporal semantics require explicit rules, not just a load timestamp.
Illustrative SQL pattern
Conceptual query for the latest loaded version of each observation at a knowledge cut-off. Physical warehouse SQL, tie-breaking and satellite patterns will vary.
SELECT observation_bk, clinical_time, value, unit
FROM (
SELECT o.observation_bk, s.clinical_time,
s.value, s.unit,
ROW_NUMBER() OVER (
PARTITION BY s.observation_hk
ORDER BY s.load_dts DESC, s.version_seq DESC
) AS rn
FROM hub_observation o
JOIN sat_observation_result s
ON s.observation_hk = o.observation_hk
WHERE s.load_dts <= :known_by
) versions
WHERE rn = 1;The demo uses illustrative deterministic keys rather than real cryptographic hashes.
Data contracts around the Raw Vault
Semantic contract
Record code system, version, units, definition, allowed mappings and approved scope. A common warehouse key is not evidence that two clinical concepts match.
Quality contract
Assert completeness, validity, plausibility, timeliness and permitted use for each consumer. A preserved poor-quality assertion remains poor-quality data.
Governance contract
Define lawful purpose, access control, identity assurance, retention, erasure handling, clinical safety and approval of downstream transformations.
Continue the learning journey
You have followed the historical records. Finish by considering the limitations.
Lesson 7 of 7 · Understand the boundaries
What Data Vault can help with, and what it cannot do by itself
Data Vault is useful for preserving the lineage of analytical data and making extensions more manageable. But it is not a clinical record system, a terminology service, a master patient index or a guarantee that incoming data is suitable for a particular purpose.
Strong fit
Incremental integration and replayable history
Stable keys, independent satellites and provenance support extension, auditing and multiple purpose-specific marts. Source-specific attributes can evolve without forcing all consumers into one physical persistence schema.
Requires additional architecture
Semantics, identity and governed use
Record linkage, terminology, measurement comparability, data quality, authorisation, metadata management and permitted disclosure remain external or cross-cutting responsibilities.
Engineering trade-off
Join complexity and operational cost
Raw Vaults are not generally direct BI schemas. PITs, bridges and consumer marts reduce repeated joins, but introduce design, testing, refresh and infrastructure overhead.
Not the only valid pattern
Native repositories and federation
Data Vault is a pattern for historised analytical integration, not a clinical operational repository. It can coexist with FHIR, openEHR, preservation repositories, lakehouses and metadata-mediated federation rather than replacing them.
Keep this nearby
Plain-language glossary
You do not need to memorise these terms to follow the example. Expand any definition as needed.
Data warehouse
A data store organised to support reporting and analysis across one or more operational sources. It is distinct from the systems used to deliver care.
Data Vault 2.0
A wider method for developing adaptable analytical data platforms. Its familiar modelling pattern separates business identifiers (hubs), relationships (links) and descriptive history (satellites).
Business key and hash key
A business key is a source or governed identifier for something such as an encounter. A hash key is a technical value derived repeatably from a defined business key. Two different patient identifiers do not automatically become one person merely because hashes are used.
Hub, link and satellite
Hub: which thing? Link: how is it connected? Satellite: what is known or asserted about it, and when was that version loaded?
Raw Vault and Business Vault
The Raw Vault restructures and historises data received from sources. The Business Vault contains controlled derivations, reusable rules and query-assistance structures used when preparing specific analytical outputs.
Data mart or analytical endpoint
A dataset shaped to make a particular report, dashboard, study or analytical question straightforward. It is not necessarily the original format of the data.
Provenance, lineage and historisation
Provenance: where the data came from. Lineage: how it was transformed to reach an output. Historisation: keeping successive versions so earlier states can be examined.
Clinical event date versus warehouse load time
The clinical date describes when an event or measurement occurred. Warehouse load time says when its assertion reached the analytical platform. They answer different questions, particularly when a result arrives late or is corrected.
Code mapping and data quality
Mapping relates source codes to governed analytical concepts. Data quality refers to whether records are sufficiently complete, accurate, timely and appropriate for a particular use. Neither is assured simply by loading data into a vault.
Simulation checks
Checks test the internal consistency of this illustrative JavaScript dataset only. They are not conformance tests or assurance of a real deployment.
Key architectural decisions for a real healthcare programme
| Decision | Why it matters | Practical requirement |
|---|---|---|
| Business key policy | Duplicate and merged patient identities affect every downstream join | Governed identity-resolution evidence, source-key namespaces and change history |
| Event and load semantics | Corrections, late-arriving data and retractions change temporal reports | Distinguish source-effective, observed, received and warehouse-load timestamps |
| Clinical terminology | Codes, units and reference ranges may not be comparable | Terminology service, versioned mappings and clinical review |
| Access and minimisation | Historisation can conflict with erasure, retention and purpose limitation | Legal basis, least-privilege outputs, minimisation, retention and erasure strategy |
| Consumer data contracts | A model can be technically coherent while analytics remain unsafe or misleading | Measure definitions, quality thresholds, responsibility and release criteria |
| Platform operating model | Incremental modelling does not eliminate engineering or governance cost | Metadata-driven pipelines, automated tests, ownership and change management |
Method, scope and limitations
Method. The example uses synthetic pseudonymous identifiers, nine baseline GP observations and optional hospital/community observations. The model is a pedagogic schema demonstrating established Data Vault constructs and derives four browser-side outputs. Actions change in-memory state only; reloading resets the model.
Scope. The source records represent observations associated with encounters and organisations. No patient demographics, provider identities, sensitive attributes, diagnostic interpretations or real health records are loaded. The scenario assumes that a governed external process has supplied reconciled synthetic patient keys; it does not demonstrate patient matching.
Limitations. There is no physical database, parallel ingestion, incremental ETL, cryptographic key derivation, transactional constraint enforcement, consent management, data quality engine, semantic terminology service, genuine OMOP mapping or performance benchmark. The research endpoint is a staging extract, not a conformant OMOP Common Data Model. Demonstrated adaptability is not evidence of production effectiveness.
Source register
The demonstrator is an independent interpretation. Linked references provide definitions and constraints, not endorsement of the design or dataset. External links are optional; the file itself works offline.
WEB-01 · AutomateDV, Hubs. Used for business-key grain, load timestamp and record source.
WEB-02 · AutomateDV, Links. Used for hub-to-hub association and link provenance.
WEB-03 · AutomateDV, Satellites. Used for descriptive payload history and change detection.
WEB-04 · AutomateDV, Bridge tables, and PIT and bridge explanation. Used for query-assistance concepts. Implementation details are tool-version dependent.
WEB-05 · HL7 International, FHIR R4 Observation. Used to distinguish an observation's clinical effective time, source identity and encounter context. The demo is not a FHIR implementation.
WEB-06 · OHDSI, OMOP Common Data Model. Used to explain why a research staging view is not equivalent to a standardised OMOP implementation.