NHS based Patient/ Appointment messaging - Prototyping

API Platform
,
1

I’m a software developer working on the early stages of designing our integration capability for NHS-based systems as a prototyping.

Our initial focus is patient or appointment-related messaging (for example: New patient registration, booking, rescheduling, cancellation, notifications), with the intention of building this in a way that is future-proof, standards-based, and compliant with NHS expectations.

I’m reaching out to this community to learn from those who have already navigated this space and to ensure we start with the right architectural and integration decisions.

Specifically, I would really appreciate guidance or pointers on the following areas:

1. Integration & API Standards

  • What are the recommended NHS standards for appointment-related integrations today?

  • Is FHIR (R4) the preferred approach for appointments, or are there other patterns still commonly used?

  • Are there specific NHS APIs or services we should be designing around from day one?

2. Messaging & Eventing

  • For appointment events, is there a preferred messaging model (request/response vs event-driven)?

  • Are there commonly adopted messaging platforms or patterns (e.g. MESH, async messaging, webhooks)?

  • Any lessons learned when dealing with event ordering, retries, or idempotency in NHS integrations?

3. Data Formats & Interoperability

  • Recommended message formats and payload structures for appointment data?

  • Any common pitfalls when mapping internal models to NHS/FHIR resources?

4. Authentication & Security

  • What authentication mechanisms are typically expected (e.g. OAuth 2.0, NHS Identity, Spine-related auth)?

  • Any best practices around certificate management, environments, and access separation?

5. Compliance, Licensing & Assurance

  • What registrations, licences, or onboarding processes should we plan for early (e.g. NHS Digital, API subscriptions)?

  • How early should we be thinking about DSPT, DTAC, clinical safety (DCB0129/0160) in relation to integrations?

6. Developer Resources & Communities

  • Are there forums, Slack/Teams groups, GitHub repos, or documentation hubs you’d recommend?

  • Any real-world examples or reference implementations that helped you early on?

Our goal is to build something that aligns with NHS interoperability principles, avoids rework later, and respects both clinical safety and operational realities.

Any advice, links, war stories, or even “things you wish you’d known earlier” would be hugely appreciated.

Thank you in advance for your time, and I’m really looking forward to learning from the community.

2

Hi Senthil,

Thanks for getting in touch via the NHS API Developer Community.

The following is a NHS-aligned view based on how national and local integrations work.

1. Integration & API Standards:

FHIR R4 is the strategic and recommended standard for new NHS integrations, including appointments and patient-related workflows. That said, the NHS landscape is mixed with:

GP systems: FHIR via GP Connect
National services: FHIR APIs (PDS, eRS, messaging, etc.)
NHS Trust systems: Often HL7 v2/v3 internally, sometimes fronted by FHIR APIs

The Design recommendation would be to model your internal domain around FHIR R4 resources and use adapters at the edges for non-FHIR systems. Depending on your scope, you should ideally look to design around the existing APIs that are LIVE on the NHS England API and integration catalogue - NHS England Digital.

2. Messaging & Eventing

While most NHS APIs are primarily synchronous REST, it is recommended to use them as systems of record to trigger internal event-driven architectures that manage retries and domain events independently - whilst Handling retries, reconciliation, and replay internally.

Messaging platforms you’ll encounter within NHS are MESH – asynchronous, document-oriented (not real-time appointments) and REST + polling. Given the reliance on MESH and polling, developers should design for resilience by implementing idempotency and handling duplicate, out-of-order, or missing events.

3. Data Formats & Interoperability

Use FHIR R4 JSON aligned with NHS profiles for resources like Appointment, Patient, and Practitioner, treating FHIR as your canonical contract rather than just a wire format.
Ensure internal models map cleanly to FHIR and avoid losing clinically important state transitions (e.g. cancelled vs DNA)

4. Authentication & Security

Adhere to the NHS Digital security guidance by implementing OAuth 2.0—utilising application-restricted or user-restricted patterns (via NHS Login or CIS2) and mTLS where required.

Follow best practice and maintain separate credentials across environments, automate key and certificate rotation, and do not assume Sandbox behaviour perfectly mirrors in DEP, INT or Prod environments.

5. Compliance, Licensing & Assurance

Plan early for NHS Digital onboarding and API subscriptions to ensure all registrations and licenses are secured. Simultaneously, integrate DSPT, DTAC, and clinical safety standards (DCB0129/DCB0160) to ensure there is legal basis and conformance to clinical and IG, as these assurance frameworks are critical to a successful architecture and integration to any NHS APIs.

6. Developer Resources & Communities

https://digital.nhs.uk/developer
https://digital.nhs.uk/developer/guides-and-documentation
https://digital.nhs.uk/developer/api-catalogue

Use the above and GitHub repos for technical foundations, while relying on the developer community to ask queries on technical implementation or documentation/guidance.

Important: Having an NHS sponsor (ICB, Trust, or national programme) dramatically accelerates progress.

Thanks,

NHS England API Platform team

Please note: The API Platform team can only address queries relevant to the NHS England API platform, including security, rate limiting, logging, monitoring and alerting. For any API, CIS2, NHS Login specific queries, please reach out the relevant API / Service teams.