Messaging and Notifications
NHS App messaging is a patient-facing channel in the NHS App service set. NHS Notify is the wider message-sending service: it allows organisations and services to send NHS App messages, emails, texts, and letters. It uses the Personal Demographics Service (PDS) to find contact details and manage contactability, and accepts requests through the NHS Notify application programming interface (API) or NHS Notify Message Exchange for Social Care and Health (MESH) route.
NHS App Notifications and Messaging integrations are now described as part of the NHS Notify onboarding route. NHS England Digital's NHS App integration guidance says organisations that want to send notifications and messages through the NHS App need to onboard through NHS Notify.
Partner onboarding evidence places NHS App notifications and messaging, NHS Notify, MESH, and related APIs inside an assurance process covering clinical safety, data protection, technical assurance, and information security. For Defence Medical Command (DMedC) / Defence Primary Healthcare (DPHC), this means a messaging claim needs both a channel statement and a sender/onboarding statement.
GOV.UK Notify Boundary
GOV.UK Notify and NHS Notify are related but distinct services. GOV.UK Notify sends email, SMS and letters through manual, bulk or API routes; it does not itself provide the NHS App message channel. NHS Notify accepts an NHS service request, can select the NHS App as a channel and may use GOV.UK Notify as one of its communication suppliers for email, SMS or letter delivery.
Project-owner direction reports that the current DPHC SMS reminder workflow uses GOV.UK Notify. That is useful implementation intelligence, but a retained service configuration, API integration or supplier artefact is still needed before the wiki treats it as confirmed implementation evidence. Existing GOV.UK Notify use would not by itself establish NHS Notify onboarding or NHS App delivery.
DPHC Appointment-Reminder Use
Appointment reminders are a high-value DPHC use case because they can give patients a clear, timely communication through a preferred channel with fallback where needed. The project-owner-validated DMSR finding links reviewed external-referral delays to inaccurate contact details and delays passing appointment information to patients. Use it within that reviewed-case scope as supporting evidence for the communication priority. NHS England's 2026 campaign independently supports the general administrative value of App notifications and reminders, but it is not DPHC-specific evidence.
The proposed Firmbase route is:
- the current SMS reminder workflow as the candidate source, supported by an authoritative Defence Medical Information Capability Programme (DMICP) appointment trigger or feed;
- transformation and validation through a controlled integration adapter, with InterSystems Health Connect as one candidate subject to selection;
- submission through NHS Notify API, or NHS Notify MESH if selected, using an approved sender, routing plan and template;
- delivery to the NHS App message channel, with configured email, SMS or letter fallback; and
- delivery-status reconciliation, support and incident handling.
The IRTB(P) decision commissions concept design for this route. Development, delivery and a live pilot require further approval. The current SMS workflow is a candidate source; the DMICP feed, chosen adapter and live NHS connection remain to be evidenced.
The national service is called NHS Notify API, not Appointments Reminder API. An internal DMICP API or event feed may be described as an appointments reminder provision, but it is the source-side trigger rather than the NHS message transport.
Named technical components
The design should name the components below and confirm who provides and operates each one. Official NHS guidance was rechecked on 19 September 2026.
| Component | Required role or selection decision |
|---|---|
| DMICP appointment feed | Supply the authoritative appointment trigger, patient NHS number and safe reminder content. Confirm access, changes, cancellations and duplicate handling; an available feed is not yet evidenced. |
| Controlled integration adapter | Validate and transform the source data into NHS Notify requests and reconcile delivery status. InterSystems Health Connect is a candidate implementation, not a selected or proven deployment. |
| NHS Notify API connection | One submission option. Register the application on the NHS API Platform and configure signed JSON Web Token (JWT) authentication, protected signing keys and environment-specific access. Complete NHS Notify onboarding before live use. |
| NHS Notify MESH connection | Alternative submission option. For an automated feed, provide a MESH Client or MESH API integration, integration and production mailboxes, and the credentials and certificates required by the selected integration. The MESH API requires a mailbox ID and password, Transport Layer Security (TLS) certificate and shared secret. |
| Organisation Data Service (ODS) sender identity | Agree the organisation code and NHS App sender name during onboarding. An override for another organisation's sender identity requires NHS Notify agreement. |
| PDS contact and restricted-record checks | NHS Notify uses recipients' NHS numbers to perform these checks through PDS, a Spine service. This does not require the MOD sender to build a separate PDS connection for the same lookup. Any additional source-side identity check must be designed separately. |
| NHS Notify routing plan and message templates | Configure the NHS App message, safe appointment details and agreed fallback channels. Test content and delivery before live use. |
| Delivery-status reconciliation | Use API status queries or authenticated callbacks for the API route, or MESH reports for the MESH route. Link outcomes to source requests and manage failed, duplicated or superseded reminders. |
NHS Notify is the recipient of the submission; the NHS App is the patient channel. MESH is a possible Spine messaging transport and PDS is a supporting Spine service. The design should not treat “send to Spine” as a single generic interface, or assume that Spine Directory Service (SDS) and Spine Secure Proxy (SSP) are required for NHS Notify. Those components apply to other service-specific routes.
Use the official NHS Notify API specification, NHS Notify MESH setup guidance, MESH API specification and NHS App sender-name guidance to select and define the route.
Reminder Channel Transition
Any subsequently approved NHS App reminder pilot should run alongside current DMICP SMS reminders. This protects patients while the programme measures App delivery, failure and reconciliation behaviour, accessibility, support demand, cost, fallback completion, patient outcomes and administrative effect.
NHS App messages may later become the primary reminder route and replace routine SMS for defined cohorts, but this is not an automatic consequence of successful technical delivery. It requires a recorded service decision, an approved exception population, and an effective SMS or other fallback route for patients who cannot use the App, do not have the service enabled, or experience a failed digital journey.
Architecture Note
Messaging is not always a GP practice feature. Some messages may originate from national services, NHS England services, local providers, screening programmes, or other organisations. DPHC analysis should therefore distinguish:
- NHS App inbox/message capability.
- NHS Notify or other message-sending service.
- NHS Notify API or MESH submission route.
- NHS App API notification use in specific integration routes such as Patient Care Aggregator / Wayfinder.
- PDS contact-detail and restricted-status checks.
- Whether DPHC or MOD services are onboarded as message senders.
NHS Notify can use multiple channels and suppliers. It can send NHS App messages where that channel is available, but it may also send email, SMS, or letters. NHS Notify also does not send to recipients with PDS flagged records, restricted statuses, or deceased flags.
NHS Notify does not provide appointment inventory, appointment detail, booking, cancellation, rescheduling or write-back. A Patient Care Aggregator / Patient Engagement Portal (PEP) route is separately required where the desired outcome is a visible appointment summary or detailed appointment page.
Evidence Needed
- Determine whether DMedC / DPHC can or should use NHS Notify, NHS App messaging, or another channel for patient communications.
- Obtain the current GOV.UK Notify service/configuration evidence, DMICP appointment trigger or feed contract, minimum safe data, patient/ODS matching, duplicate and cancellation semantics, supplier rights and source reconciliation.
- Confirm DMedC sender eligibility, ODS identity, Digital Onboarding Service route, routing plan, templates, restricted-record policy, delivery callbacks, fallback, cost, support and clinical safety.
- Define the parallel-run baseline, channel-transition measures, exception population, authority and stop/go criteria for any later App-first delivery or replacement of routine DMICP SMS reminders.
- Determine whether DPHC Firmbase or DPHC Overseas [DPHC(O)] patient contact restrictions, PDS flags, or non-PDS contact data create special handling requirements.
- Separate Patient Care Aggregator appointment notifications from general NHS Notify messaging.