Architecture

A repository your Trust owns, built on the model the NHS already publishes

CDP is not an analytics product with a proprietary core. It is the boring, durable layer underneath one: a canonical data repository, the transformation logic that fills it, the tests that prove it and the interfaces that let anything read it.

Open the sandbox Take the guided tour

Canonical tables: 72
Generated columns: ~1,600
Data-quality tests: ~400
Licence: BSL 1.1

Eight layers, no proprietary middle

Each layer is replaceable on its own. That is the whole design goal: nothing in the stack can hold the others hostage.

Ingestion

Source extracts from PAS, ED, theatres, pathology and radiology land in a raw zone with the file, batch and timestamp recorded. Nothing is transformed before it is captured.

Transformation

dbt models map source shapes onto the canonical model. Logic is version-controlled SQL that a Trust analyst can read, review and change — not a black box.

Canonical repository

72 tables generated directly from the published NHS CDM, with consistent keys, value sets and relationships across every clinical and operational domain.

Quality gates

Roughly 400 generated tests run on every load. Blocking failures stop publication; warnings are surfaced with a named owner. Counts reconcile line by line against source.

Ontology

80 object types, 1,739 typed properties and 159 named link types, generated from the same model definition that generates the tables. One source, no shadow model to drift.

Serving

A FHIR UK Core read API, a typed object SDK where callers traverse objects and links instead of writing joins, and direct SQL for analysts and BI.

Machine-navigable surface

The object model is published as a tool surface an agent can navigate, with a natural-language query endpoint over it. Read-only in v0.1, and filtered by the database's own policies.

Control

Row-level security by role and organisation that fails closed, an append-only audit log of every access, and pseudonymisation applied at the boundary between identifiable and analytical layers.

The repository is defined as code, end to end

Nothing about the repository lives only in a console, a spreadsheet or a supplier's head. Every artefact that defines it is a file in a Git repository your Trust holds.

Artefact	Form	What it means in practice
Canonical schema	Generated DDL	The 72-table structure is generated from the published NHS CDM definition, not hand-drawn. Regenerate it and you get the same schema, byte for byte.
Object model	Generated object registry	Object types, typed properties and named link types come from the same model definition as the tables, so the object layer and the physical layer cannot disagree about what a field is.
Typed access	Generated SDK	Callers ask for objects and follow relationships. An unknown field is rejected before any query is built, and identifiers are allowlisted again at the database boundary.
Transformation logic	dbt SQL models	Every mapping from a source field to a canonical column is readable SQL in version control, with lineage from raw extract to published table.
Data-quality rules	Generated dbt tests	Uniqueness, referential integrity, value-set conformance and volume expectations are declared alongside the model that they guard.
Access control	Policy definitions in SQL	Row-level security by role and organisation is declared in migration files and reviewed like any other change.
Infrastructure	Terraform & Docker Compose	The environment itself is described in code — rebuild the whole repository in your own tenancy from a clean account.
Change history	Git commits & pull requests	Who changed which definition, when, why and who approved it, is answerable from the repository rather than a supplier ticket.

Reproducible

A clean environment plus the repository plus your source extracts reproduces the same canonical dataset. No manual configuration step sits between the two.

Reviewable

A definition change is a pull request. Clinical, IG and analytics colleagues can read the diff and see exactly which figures it affects before it is merged.

Portable

Because the definitions are files rather than platform state, the whole repository moves between environments — or suppliers — without a rebuild.

What ships in v0.1

An honest inventory of the reference build as it stands today.

Component	Status	Detail
Canonical schema generator	Working	Produces the full DDL from the published NHS CDM definition.
Object model generator	Working	80 object types, 1,739 typed properties and 159 link types from the same definition.
Typed object SDK	Working	Object lookup and link traversal with field validation and identifier allowlisting.
dbt transformation project	Working	Source-to-canonical models with generated tests.
FHIR UK Core read API	Working	Six resource types with UK Core profiles and OAuth2.
openEHR archetype projection	Working	Read-side representation onto four CKM archetypes; no template-conformance claim.
Agent tool surface & plain-language queries	Working	Read-only navigation of the object model with a natural-language endpoint.
Encounter discharge transition	Working	One specified, role-scoped state change with an append-only audit trail.
Row-level security & audit	Working	Role and organisation policies that fail closed; append-only access log.
Docker deployment	Working	One command brings the whole stack up locally.
AWS / Terraform target	Working	Deploys into a Trust's own tenancy.
IG starter pack	Draft	DPIA skeleton, data flow map, retention positions.
Exit & cutover runbook	Draft	90-day plan with reconciliation gates.
Encoded actions beyond discharge	Specified	Design reviewed, permission model written; not yet built.
Object index for object-shaped reads	Specified	Design reviewed, including read-time permission filtering; not yet built.
General write interface / clinical authoring	Not built	Deliberately out of scope for v0.1.
Clinical safety case (DCB0129)	Not started	Requires a partner Trust to be meaningful.

Sits alongside any FDP, national or commercial

CDP is not a rip-and-replace. It is designed to hold the canonical copy your Trust already needs.

Holds your existing FDP data

If your Trust already has data in an existing FDP instance, CDP can receive and hold that data in canonical form in your own tenancy. Because it uses the same NHS Canonical Data Model, migration is reconciliation, not a model rebuild.

Compatible with the national FDP by design

Built on the published NHS Canonical Data Model and FHIR UK Core — the same interoperability standards used by the national FDP programme — CDP aligns structurally with the national instance. No proprietary adapter is required.

The point of the design

A Trust that holds its own canonical repository can change analytics supplier, add a second one, or bring work in-house without moving a single row of data. The repository is the asset; everything above it becomes a competitive market rather than a dependency.

Next step

See it before you commit to anything

Open the synthetic sandbox to see the canonical model, the FHIR API and the pathway analytics working — or request evaluation access to the reference build itself.

Open the live sandbox Request evaluation access