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

Six 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.

Serving

A FHIR UK Core read API for interoperability, plus direct SQL for analysts and BI. Any conformant client can consume the repository without bespoke integration work.

Control

Row-level security by role and organisation, 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.
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.
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.
Row-level security & audit	Working	Role and organisation policies; 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.
Write-back / task workflows	Not built	Read-only today by design.
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