NHS App adoption and implementation executive summary
The recommended approach is to enable mobile NHS App access and existing NHS services for Ministry of Defence (MOD)-registered patients, while commissioning concept design for MOD appointment reminders. Later reminder delivery and MOD general practice (GP) record information exchange would need separate approvals.
This summary follows the retained R41 paper of 21 September 2026, its evidence limits and the Board paper evidence brief (internal reference). The version history (internal reference) holds the paper and matching Word export. Board approval remains to be obtained. The named Senior Responsible Owner, funding, staffing and delivery dates remain unconfirmed.
Executive position
NHS guidance excludes patients registered with Defence Medical Services (DMS) from using the mobile NHS App (SRC-116; rechecked 23 October 2026). Resolving access with NHS England is the first task. It would allow patients to use available NHS advice and self-service functions and receive information from participating NHS hospitals and specialist services, alongside existing communication channels.
The Board is asked to:
- Approve NHS App access and existing NHS services. Introduce healthcare advice, service information and self-service functions, alongside NHS hospital and specialist appointment information, notifications and automated reminders from participating providers in England, where available. Access remains subject to NHS England agreement and service testing for the intended patient groups.
- Commission concept design for Defence Medical Information Capability Programme (DMICP) appointment reminders. Establish how the Defence Medical Information Capability Programme (DMICP) could supply one-way reminders equivalent to current Short Message Service (SMS) reminders. Require a costed proposal covering the appointment feed, integration, operation and delivery plan. This decision would not authorise development, delivery or any reminder pilot.
- Reserve MOD GP record information exchange for a separate decision. Require a proposal when the replacement MOD GP system and relevant interfaces are available. It must define the patient benefit, information, direction of exchange, NHS route and delivery conditions. Appointment management, prescribing and other clinical integration remain outside the current decision.
Option 3: deliver NHS services and design DMICP reminders is recommended. It provides earlier patient benefit and a costed basis for considering the next stage. A resourced plan must cover NHS delivery, DMICP design and continuing support. Expenditure requires approved funding and spending authority; no funding allocation is assumed.
NHS England route and UK reach
The project-owner registration baseline is that MOD patients retain their first NHS England registration throughout MOD registration. Secondary registration in Scotland or Wales, where applicable, does not replace it; Northern Ireland secondary registration is intended but not yet in place. The proposed scope includes MOD patients across the UK and when posted overseas or on operations, for the duration of MOD registration.
This registration position does not itself remove the App access restriction or establish access to devolved NHS clinical services. Agree the initial patient groups with NHS England and Defence Primary Healthcare (DPHC), then test age, identity, location, permitted proxy access and service-specific conditions. NHS appointment information depends on the participating providers in England relevant to each patient's care.
What implementation requires
NHS England and DPHC need to agree access, the initial patient groups and support arrangements. Each function must then be tested independently. Existing NHS hospital connections do not depend on a new DMICP feed, but availability varies by provider and service.
DMICP concept design must establish the appointment feed, integration adapter and NHS Notify connection, with costs and an operating plan. The proposed reminder service would not provide booking, cancellation, rescheduling or clinical-record updates. Future MOD GP information exchange depends on the replacement system and its interfaces; product capability alone does not establish a working NHS App route.
Delivery sequence
%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
flowchart TB
Decision["Present decision sought"]
Decision --> Initial["Deliver mobile access<br/>and applicable existing NHS functions"]
Decision --> Design["Commission DMICP reminder<br/>concept design"]
Design --> Approval["Return for approval of<br/>development, delivery and any pilot"]
Approval --> Reminder["If approved: develop and test<br/>one-way reminders alongside SMS"]
Interfaces["Relevant MOD GP system<br/>and interfaces available"] --> Proposal["Define GP-record information exchange<br/>and seek separate approval"]Following approval, agree access arrangements and select initial patient groups and participating services. Introduce each service after testing confirms that patients can use it and obtain help. Useful NHS services need not wait for future MOD integration. DMICP concept design can proceed alongside this work and should produce the costs and evidence for a later Board decision.
Existing telephone, text-message and other channels must remain usable during introduction and whenever the App is unavailable or unsuitable. Any later approved DMICP reminder pilot should run alongside current text messages. Making the App the main reminder channel or replacing routine text messages requires a separate decision supported by delivery, safety, accessibility, cost and fallback evidence.
Initial NHS provider validation
Start with participating NHS providers relevant to MOD patients' actual referrals. For each proposed service, record the provider, patient group, information offered, route into the App and evidence from the complete patient journey. Check new appointments, changes and cancellations, notification behaviour, support and alternative communication. Keep national coverage figures separate from evidence that a named service works for MOD patients.
Test patients' own accounts separately from permitted proxy access. The R41 proxy review records that family and carer access does not allow carers to manage hospital appointments or specialist referrals, or send or view messages in the cared-for person's profile. Agree usable alternatives and support for affected patients; do not assume a successful patient test also proves proxy access.
Use the initial NHS provider validation requirements to record the required evidence and introduction decision. Measure successful access, receipt of appointment information and support demand. Establish baselines before claiming fewer missed appointments, staff savings or clinical benefits.
Phase 0-6 technical reference
The detailed NHS App adoption and implementation page retains Phases 0–6 as stable technical references. They classify capability and evidence requirements; they are not a compulsory delivery sequence.
| Reference | Capability | Relationship to R41 |
|---|---|---|
| Phase 0 | Initial mobile access | First-stage proposal, subject to access agreement and patient-group tests. |
| Phase 1 | NHS hospital and specialist appointments | First stage where the named provider service is available and validated for the patient journey. |
| Reminder workstream | DMICP one-way reminders | Concept design only in the present decision; independent of Phase 2 appointment inventory. |
| Phase 2 | DMICP primary-care appointment visibility | Separate future proposal; an accepted inventory and display route is not evidenced. |
| Phase 3 | DMICP appointment management | Separate future proposal requiring source-system capability and an approved route. |
| Phase 4 | Clinical correspondence | Existing NHS provider documents may be available in the first stage; MOD GP information needs the later proposal. |
| Phase 5 | Test results | Existing NHS provider results depend on release rules; MOD GP information needs the later proposal. |
| Phase 6 | Programme Cortisone patient data | Potential future components; not evidence of delivered MOD interfaces or NHS App publication. |
See Messaging and Notifications for the NHS Notify application programming interface (API) and Message Exchange for Social Care and Health (MESH) routes considered for DMICP design.
Decision gate
Before describing a capability as available, link its evidence to the patient group and service tested:
%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
flowchart LR
Cohort["Cohort and location"] --> Access["Access mode"]
Access --> Outcome["Patient outcome"]
Outcome --> Source["Source system"]
Source --> Route["NHS-facing route"]
Route --> Assurance["Assurance and support"]
Assurance --> Test["Named-cohort test"]
Test --> Status["Guidance status"]Service test results inform the proposal; they do not provide spending authority or approve a later integration stage.
Read next
- Board paper evidence brief (internal reference) for the Board proposal, options and evidence limits.
- Initial NHS provider validation for the evidence needed before introducing a provider service.
- NHS App adoption and implementation for the detailed technical reference.
- Guidance decision model for current status by patient group and capability.
- Architecture index for logical route diagrams.
- Evidence Validation Queue for unresolved implementation evidence.