UK Core conformance in practice: what it means for your NHS integrations

UK Core is the NHS's set of FHIR R4 profiles: nationally maintained constraints that turn permissive base FHIR into something two NHS systems can actually agree on. Being conformant means your resources validate against the specific UK Core profiles in play, at a pinned version of the implementation guide, including the terminology bindings, not just the structural shape. In practice that requires three habits: treat the implementation guide as the versioned contract, read the profiles for mandatory and must-support elements from your side of the exchange, and validate with terminology included, at design time and at runtime boundaries rather than only at the end.

Base FHIR R4 is deliberately loose: most elements optional, most codes unconstrained, because the core standard must work everywhere on earth. A profile removes that looseness for a context, and UK Core is the NHS's nationally agreed profile set: which elements are mandatory, how the NHS number is carried and verified, which value sets each coded element must draw from, which extensions carry UK-specific concepts.

So "UK Core conformant" is a precise, testable claim: for each resource type exchanged, instances validate against the named UK Core profile, at a stated implementation guide version, terminology included. Anything vaguer than that ("we support UK Core", "our model is aligned with UK Core") is a statement of sympathy, not conformance, and the difference is exactly what surfaces in the first week of testing.

UK Core ships as an implementation guide: a versioned package containing the profiles themselves, the value sets they bind to, the UK-specific extensions, and worked examples. Three working consequences follow.

First, pin the version. The guide evolves, and "conformant" is only meaningful against a stated release; two parties building against different versions can both be right and still fail integration. Put the version in the spec, the test plan and the contract. Second, consume the guide as a package, not as a website. The package is machine-readable, which means your tooling can import it wholesale: profiles for validators, value sets for terminology services. (WeHub Term imports implementation guide packages today, UK Core value sets included, which puts the terminology half of conformance on tap; full profile validation against a guide is the job WeHub Proof is being built for.) Third, read the examples last, not first. Examples show one legal instance; the profiles define the space of legal instances, and building to the example is how systems end up conformant with the sample and nothing else.

Opening a UK Core profile, two markings deserve most of your attention. Mandatory elements are the hard floor: an instance missing one simply fails. The canonical example is identity: UK Core specifies how the NHS number travels (in a defined identifier slot, with its verification status carried the agreed way), and getting that wrong is the single most common first-test failure in NHS FHIR work.

The subtler marking is must-support, and it means different things depending on your seat. As a producer, must-support elements are ones you populate whenever you hold the data; silently dropping them is a conformance failure even though the instance validates. As a consumer, they're elements you must be able to receive and process without falling over. Reading the profiles from your side of the exchange (what must I send, what must I survive receiving) is the practical discipline that turns the guide from documentation into a build checklist. UK-specific extensions (concepts base FHIR doesn't carry) follow the same logic: the profile tells you which apply and when.

Here is where most "conformant" systems actually fail. Every coded element in a UK Core profile is bound to a value set, with a stated strength: a required binding means the code must come from that value set, full stop; an extensible binding means the value set is the default and departures need justification the exchange partners accept.

The consequence is that structural validation alone proves half a claim. A resource can be perfectly shaped and still non-conformant because a diagnosis, an ethnicity, a medication code sits outside the bound value set. That's why conformance testing has to include terminology: every bound element validated against the guide's value sets, at the pinned version, using a terminology service rather than a frozen list someone exported once. It's also why local codes need the mapping and governance machinery covered elsewhere on this blog before they ever reach a UK Core boundary; the boundary is precisely where ungoverned codes get caught, or worse, don't.

Validation is cheap insurance, and its value depends almost entirely on when it runs. At design time, validate your own examples against the pinned guide before any partner sees them; finding your own gaps is free, and finding them in joint testing costs a workshop. In build, put validation in the pipeline so a profile regression fails a check rather than a deployment. And at runtime, validate at the boundaries: inbound resources checked as they arrive, outbound checked before they leave, with failures routed to an owned exception queue rather than a log. Runtime validation is what turns conformance from a certification-day event into a standing property of the integration, and it's the difference between discovering drift in a dashboard and discovering it in a partner's incident report.

UK Core conformance isn't a badge; it's a testable relationship between your instances and a pinned version of the implementation guide, terminology included. Three habits carry almost all of the value: pin the version everywhere, read the profiles from your side of the exchange, and validate early and at the boundaries. The step to take this week costs an afternoon: take one resource type you exchange today, validate a handful of real instances against its UK Core profile at your pinned version, terminology and all. Whatever fails is your conformance backlog, discovered on your terms instead of a partner's.