Reference implementation · v0.1 · Source available

A Trust-native CDM repository, whatever happens to your FDP

Data as code — versioned, reviewable and reproducible

CDP — the Canonical Data Platform — is an open, Trust-owned data repository built on the published NHS Canonical Data Model, with a typed object layer over it. Objects, properties and relationships are generated from the same model definition as the tables, and reached through FHIR UK Core, a typed SDK, a machine-navigable tool surface or plain SQL. The canonical copy of your data sits in your estate, in a form your team can read, audit and move.

Open the live sandbox Take the guided tour

No sign-up for the sandbox · synthetic data only · nothing leaves your browser

GET /fhir/r4/Patient?identifier=944930451338 ms

{
  "resourceType": "Bundle",
  "type": "searchset",
  "total": 1,
  "entry": [{
    "resource": {
      "resourceType": "Patient",
      "meta": { "profile": [
        ".../UKCore-Patient"
      ]},
      "identifier": [{
        "system": "https://fhir.nhs.uk/Id/nhs-number",
        "value": "9449304513"
      }],
      "managingOrganization": {
        "identifier": { "value": "RJ1" }
      }
    }
  }]
}

200 OKSynthetic data only

Canonical tables: 72
Object types in the ontology: 80
Named link types: 159
Generated quality tests: ~400

The problem: FDP uncertainty, and no Trust-native CDM copy

Trusts are being asked to bet their operational analytics on a single federated data platform whose future is now publicly uncertain. Even if that platform continues, every Trust still needs its own canonical copy of data in the NHS CDM — otherwise the repository, not just the data, lives somewhere else.

FDP uncertainty is a planning risk

The future of the Palantir FDP arrangement is subject to public contract and policy review. Trusts need a technical option that works whatever the outcome, rather than waiting for the next announcement before they can plan.

You do not hold a Trust-native CDM store

Without your own repository in the published NHS Canonical Data Model, your operational data exists only inside a supplier platform — not in a form your analysts can query, audit or migrate independently.

Exit is theoretical without a canonical target

Contractual exit provisions describe a process, not a working repository you can switch to on day one. Without a canonical copy already in your estate, leaving means rebuilding the model, the logic and the evidence from scratch.

What CDP is

A boring, durable layer: the repository, the logic that fills it, the tests that prove it and the interfaces that let anything read it.

Canonical by construction

72 tables generated from the published NHS Canonical Data Model, so your repository speaks the same language as every other Trust that adopts it.

An object layer, not just tables

80 object types, 1,739 typed properties and 159 named relationships are generated from the same model definition as the tables. Callers traverse objects and links instead of writing joins.

Open interfaces, not exports

A FHIR UK Core read API, a typed object SDK and direct SQL. Any conformant tool can read the repository today — no bespoke connector, no negotiated extract.

Built to be queried in plain language

The object model is exposed as a machine-navigable tool surface with a natural-language query endpoint over it — read-only in v0.1, and permission-filtered by the database, not the model.

Quality you can evidence

Around 400 generated tests run on every load, and counts reconcile line by line against source. Variance is explained, never quietly dropped.

Sovereign by default

Deployed in the Trust's own tenancy, source available end to end. No proprietary format, no negotiated extract, and no egress fee for reading your own data.

Read the architecture in full

Prove it before you believe it

A working sandbox, not a slide deck

Browse the canonical model table by table, fire real queries at the FHIR UK Core API, open the RTT, cancer, UEC and diagnostics analytics and inspect the data-quality evidence — all against fully synthetic data, entirely in your browser. CDP is also built to receive data exported from an existing FDP instance and to align with the national FDP programme by design.

Open the sandbox Guided tour

Canonical model

Every table, column, key and relationship in the CDM subset.

FHIR playground

Six UK Core resources with live request and response.

Pathway analytics

RTT, 62-day cancer, four-hour UEC and DM01.

Quality evidence

Test suites and source reconciliation, line by line.

What this is not

Anything else would waste your team's time.

Not deployed in any NHS Trust today.
Tested against synthetic data only — never live patient data.
No clinical safety case, DSPT submission or independent penetration test.
No 24/7 support organisation or signed data-processing agreement.
Read-mostly: one specified encounter state transition, no general write interface and no clinical authoring in v0.1.
Object indexing and encoded actions are specified and reviewed, but not yet built.
Independent of NHS England and Palantir Technologies; no affiliation or endorsement.

What it is: a genuinely working reference implementation, and an argument that the canonical repository underneath your analytics should belong to you. See the full security and IG position.

The ask

Not a procurement decision. A technical evaluation by a named team, and permission to bring the findings back to the Board. If the evaluation is negative you will have spent a few analyst days and learned something useful about your own data estate. See the adoption path.

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