A blood pressure taken on a district nursing visit should be usable by a GP, a hospital clinician, and an analyst without anyone retyping it. That sentence is easy to agree with. Making it true across acute trusts, GP systems, community services, and social care, all procured in different years and running at different levels of digital maturity, is a data modelling problem before it is anything else. This article covers the standards worth anchoring to, how to design a canonical model, and the habits that keep it safe and usable once it is live.

Three layers, and where the model sits

Interoperability has layers. Syntactic interoperability means two systems can exchange a payload. Semantic interoperability means the receiver reads it exactly as the sender meant. Process interoperability means the data arrives in time, is trusted, and fits the receiver's workflow.

Most projects solve the first and assume the other two. The data model is where all three are decided. The shape of the data, and the codes chosen to give it meaning, either make each new connection routine or turn every hand-off into a bespoke mapping exercise.

There is also a human constraint. A model that is correct on paper and impossible to capture at the point of care will fail. A model that mirrors one local form too closely will fragment the wider system. Adopt national and international standards first, constrain them to UK practice where you must, and then check the result against how clinicians really work.

Standards worth anchoring to

Three sets of standards do most of the work in England.

FHIR R4 with the UK Core profiles is the structural layer. Where base FHIR allows several ways to express the same thing, UK Core narrows the choice. Treat UK Core as the first principle for any local schema, and deviate only where there is a demonstrable clinical need.

SNOMED CT is the clinical terminology for problems, findings, procedures, and observations. dm+d identifies medicines and packs. ICD-10 and OPCS-4 still matter for secondary uses such as coding and commissioning. A good model states which vocabulary applies to each field, and how cross-maps are maintained where two vocabularies meet.

Professional Record Standards Body (PRSB) information models describe what should be recorded and shared for specific pathways, such as discharge summaries, outpatient letters, and social care assessments. They carry clinical intent and cardinality, which makes them strong source material for designing and checking FHIR profiles. Anchoring to them means inheriting a clinical consensus you did not have to organise yourself.

Standards also reduce procurement risk. When commissioners ask suppliers for UK Core and PRSB-aligned payloads, the resulting systems are far more portable, and the same decision logic can be reused across sites instead of rewritten for each one.

Around the model sit the national services that provide identity and reference points. Use the NHS number as the patient identifier, validated against the Personal Demographics Service. Use ODS codes for organisations and sites. Use GP Connect, the Summary Care Record, and the National Record Locator where they fit, rather than recreating what they already provide.

The canonical model, and why the mappings are the hard part

A canonical data model is a practical answer to a mixed estate. Instead of every system mapping to every other system, each source maps into one shared model, and each consumer maps out of it. The integration burden grows linearly, not combinatorially.

Keep the canonical model small. It should be the minimum set of profiles and value sets that serve the pathway, aligned to UK Core and PRSB so that you are not inventing local meaning.

Start with an honest inventory. List which systems are the authoritative source for diagnoses, medications, allergies, results, care plans, observations, and referrals, and which services consume them. For each domain, decide the minimum safe dataset and the precision of coding it needs. An allergy needs the substance, the reaction, the severity, a date, and provenance. A laboratory result needs a numeric value, units, a reference range, and ideally the method.

The central schema is rarely where projects struggle. The inbound and outbound mappings are. A legacy system may hold a blood pressure as a free-text note, a row in an entity-attribute-value store, or a proprietary code. Some systems record the same fact twice, once on a problem list and once on a discharge summary. Handle this with rules that are deterministic wherever possible and clinically led where they cannot be. Version the mapping logic, test it, and trace it. Add automated checks that flag when a source starts sending unexpected values after an upgrade.

Treat identity and provenance as first-class parts of the model. Validate the patient against PDS and keep local hospital numbers as a convenience. Carry professional registration numbers where available. Attach to every resource the source system, the event time, the author, and the transformation steps. That provenance is what lets a clinical safety officer, an information governance team, and an analyst decide how far to trust a record that came from somewhere else.

Finally, version the model. Use semantic versioning for profiles and value sets, publish release notes that a clinician can read as well as an engineer, and keep a change process with clinical safety input. Backwards compatibility protects consumers, and a deprecation policy stops the model drifting.

Events, APIs, and data quality

Care is a sequence of events, not a snapshot, so event-driven design fits it. Admission, transfer, discharge, referral sent, referral accepted, medication prescribed, medication stopped, and a threshold breach are all transitions that other systems may need to hear about. In FHIR you can carry these through messaging with MessageHeader, or through RESTful notifications and Subscription. Pushing a change as it happens reduces polling and avoids large batch exchanges.

APIs remain the main integration surface. A good one has predictable paths, consistent errors, and explicit versioning. In a multi-provider setting it also has clear tenancy boundaries, usually expressed through ODS codes in scopes or headers, with authorisation tied to clinical roles so each caller sees the minimum needed. Rate limiting protects shared infrastructure, but clinical alerting endpoints may need exemption so they are not throttled at the worst moment.

If you stream events, keep the messages small. Carry a reference or a minimal payload, and let an authorised consumer fetch the full record by API. That keeps the signal separate from the substance. Treat analytics snapshots as derivatives. The point-of-care truth stays in the source systems and the canonical model that normalises them.

Data quality decides whether any of this works. A well-designed model does not rescue an estate full of incomplete or badly coded records. Automate three checks. Does the resource conform to the profile. Is the code permitted in the value set. Does the data obey business rules, such as a discharge date not preceding an admission date. Then show quality problems to the clinical teams who can fix them, such as missing allergy status, uncoded diagnoses, and observations without units. Quality presented as an IT metric gets ignored. Quality presented inside a clinician's own workflow gets fixed.

Test at the edges. Interoperability fails under real conditions, when clinic volumes spike, when an ambulance service sends a burst of updates during a major incident, or when a supplier patches on a Friday evening. Include data that breaks assumptions, such as patients with no fixed address, newborns without an NHS number yet, two people with the same name and date of birth, very long medication histories, and consent flags that differ by context.

Governance, privacy, and clinical safety

Every field in the model should be defensible in clinical and legal terms. Why is it needed, under what conditions, and who can see it. Combine role-based and attribute-based access so that a clinician's role grants general privileges, while care relationship, patient context, and consent narrow what is available in a given session.

Treat the data model as a safety-related system. Identify hazards, assess the risk of a mis-mapping or a misreading, and document the mitigations. Where a mapping is heuristic, the receiving interface should show that uncertainty, for example by requiring a clinician to confirm an inbound diagnosis before it is filed to a problem list. Put safety evidence into change control, so a re-coded field or an updated value set is assessed for clinical risk before release.

Ownership matters as much as design. An integrated care system needs a multi-disciplinary group that owns the model, the mappings, and the release process, with clinical leaders from acute, primary, and community care, information governance, architecture, supplier partners, and patient voices where relevant. Without it, local projects make sensible choices that diverge.

Build security into the design. Plan for encryption in transit and at rest, tamper-evident logging, and audit that answers "who saw what, and when" for a given patient within minutes. Use pseudonymisation for analytics so population insight does not require exposing identifiable data. For shared care records, use break-glass access that records a reason and notifies the right oversight role.

Be careful with sensitive domains. Mental health, children's services, and social care carry legal restrictions and sensitive concepts. Consider sensitivity labels, so that particularly sensitive entries need an explicit action to reveal and stay out of default views, and record patient sharing preferences at a granular level. Test those behaviours with service users and clinicians.

Modelling patterns that shorten time to value

• Design the profile first. Draft the FHIR profiles for the core resources in the pathway, such as Observation, Condition, MedicationRequest, Encounter, and EpisodeOfCare, and test them against real clinical notes and letters, not invented examples. Iterate with clinicians until the profile and an example match how they record and read the information. This avoids profiles that look elegant and fit no real workflow.
• Start with a narrow exchange. Pick the small set of elements that carries most of the value for the target pathway, and ship that end to end with good quality and governance. For a virtual ward, that might be demographics, care contacts, active problems, current medications, allergies, an escalation plan, and the latest observations with thresholds. Add fields as adoption grows. A narrow slice in live use teaches more than months of committee debate.
• Keep native resources and curated views separate for analytics. Store incoming FHIR resources as received, so you can trace and re-ingest them, and project them into a curated schema for performance. Keep the links back to patient identifiers, code systems, and provenance, and publish the definitions alongside, so every metric can be traced to source.
• Use a consistent event envelope. Carry who, what, where, when, and why on every event, along with the source identifiers, the mapping version used, and a checksum of the input. When a medication appears in one view and not another, or an allergy has been suppressed, that envelope is how your support team finds out why in minutes.

Model the pathway, not only the entities

A model succeeds when it serves the flow of care. Trace real pathways, such as maternity, falls prevention, end-of-life care, mental health crisis response, or long-term conditions, and define for each hand-off who needs what, how quickly, and at what fidelity. Maternity, for example, runs from GP referral through booking, scans, screening, antenatal care, birth, and health visiting, and each step passes specific information on. Modelling it end to end shows the shared elements, such as allergies and medications, and the specialised ones, such as parity and estimated due date.

Design for the screen as well as the API. If a community nurse needs three screens to record a structured observation, the structured data will degrade and the model will starve. Work with suppliers to put terminology pickers and unit checks inside the clinical workflow. Where free text is unavoidable, extraction can help, but only with confidence scores and human validation. The aim is not to remove narrative, because clinicians need it, but to capture the data a safe hand-off depends on beside it.

Think over time. Many decisions depend on trend. Carry method, body site, device, and position on observations where they matter, record context such as resting versus ambulatory blood pressure, and enforce UCUM units so trend charts never mix incompatible values. Represent status and verification on problems. For medicines, keep prescribed, dispensed, and administered distinct, and record why something changed or stopped.

Suppliers, conformance, and legacy systems

Publish a conformance pack. It should include the canonical profiles, example payloads, API expectations, error codes, and performance targets. Offer self-service validators, terminology checkers, and synthetic data, so suppliers can test before joint assurance.

Run conformance testing with objective criteria for each use case. Check which payloads are accepted and returned, how missing mandatory fields are handled, response times, subscription behaviour, and how a version upgrade is absorbed. Automate it, and publish the evidence so other projects can reuse it. Where a supplier falls short, negotiate a remediation roadmap rather than reopening the requirement.

For legacy systems that cannot emit FHIR or SNOMED today, use an edge adapter that translates their format into the canonical model. Treat it as a bridge. Put a roadmap for native support into the contract, and include the adapter in the clinical safety case. An ungoverned adapter is as risky as an unreviewed clinical device.

Go beyond payload validation. Check how interoperable features appear in the clinician's day. Does the GP system file an inbound document into the right template. Are allergies de-duplicated sensibly. Can a clinician see provenance and act on it. Those tests find problems that a schema check misses.

Measuring whether it worked

Interoperability exists to improve care. Tie the work to outcomes linked to the pathway, such as time from referral to triage, duplicate tests avoided, harm events from incomplete allergy data, and staff time saved on duplicate entry. Track the expected change when a profile or mapping goes live. Those numbers are the best argument for continued investment.

Document the profiles, mappings, and governance in a repository others can use. Publish incident reviews where a mapping issue contributed to a near miss, along with the fix. Invest in a proper terminology service that handles SNOMED CT and dm+d, including synonyms and subsumption, and use it in both data entry and validation. When new demands arrive, such as home monitoring data, genomic data, or AI-assisted documentation, extend the model deliberately and reuse emerging profiles, rather than adding ad hoc fields.

Where this connects to build work

We build this layer. The closest work we have delivered is a decoupled, event-driven integration layer on Azure for a UK healthcare services provider that needed to exchange patient demographics safely around a legacy ERP. It has a governed API front door, a workflow orchestrator for multi-step processes, queues with retry and dead-letter handling, a validation and matching layer with reason-coded reconciliation, and an idempotent write-back service, with security and monitoring around it.

The domain was patient demographics, and a clinical canonical model is a larger problem. The discipline is the same: agree what the fields mean, validate before you accept, keep an audit trail behind every decision, and hold that agreement steady while the systems underneath it change.