NHS App Adoption and Implementation
This page is the detailed implementation reference for introducing mobile NHS App access and selected functions for Defence Primary Healthcare (DPHC)-registered patients. It separates immediate mobile provision, existing NHS secondary-healthcare routes, a bounded DPHC Firmbase reminder workstream, DPHC primary healthcare (PHC) appointment routes, clinical correspondence, test results, and later Programme Cortisone / InterSystems patient-data opportunities.
NHS England states that people registered at a Defence Medical Services (DMS) surgery cannot currently use the mobile NHS App. Use this page as a planning model for changing that position, not as proof that a DPHC Firmbase, DPHC Overseas [DPHC(O)], dependant, minor, or linked-profile user already has a particular feature.
All DPHC patients are registered as NHS England patients, irrespective of where they live in the UK. The implementation scope therefore includes DPHC patients resident in Scotland, Wales and Northern Ireland. Applicable core national services remain subject to their own location, age, identity and eligibility rules; appointment information from participating NHS providers in England is relevant where those providers deliver the patient's care.
Use Guidance Decision Model for the current guidance-facing status produced from this phased model. Use Architecture Index for route sequence diagrams and architecture-page contracts.
On this page, Defence Medical Information Capability Programme (DMICP) is the DPHC source-system term for the primary healthcare appointment route, and primary healthcare (PHC) means the DPHC primary-care route rather than NHS secondary-care appointments.
Known NHS interfaces provide a candidate pattern for a bounded DMICP appointment reminder route, but current open sources do not expose the DMICP event/feed contract or prove NHS onboarding. A 2025 MOD Total Triage announcement confirms the DPHC Primary healthcare (PHC) access context and SMS appointment reminders, but it does not name the source interface, sender service, or NHS App route. Treat the source event/feed and onboarding as implementation gates while keeping reminder delivery through NHS Notify separate from appointment visibility through an accepted Patient Care Aggregator / Patient Engagement Portal (PEP) or other NHS App route.
Public sources are unlikely to expose full DPHC practice-level Personal Demographics Service (PDS), Organisation Data Service (ODS), GP Connect, Interface Mechanism 1 (IM1), proxy, and feature-test evidence. Keep those gaps explicit and use controlled service tests and accountable implementation evidence to close them. Programme Cortisone / InterSystems remains one candidate enabler through HealthShare / IRIS for Health, Enterprise Master Patient Index (EMPI), Health Connect / Integration Platform, GP Connect, IM1, or another assured NHS-facing route; it is not the assumed design.
Delivery Horizons
The numbered phases below are stable technical route references, not a mandatory dependency chain.
- Initial delivery: enable mobile access for DPHC patients across the UK, validate applicable core national services independently, and test relevant NHS-side Secondary healthcare (SHC) journeys through participating providers in England.
- Bounded development: design, onboard, assure, and pilot one-way DPHC Firmbase appointment reminders through a documented DMICP event or feed, a controlled adapter, NHS Notify, and fallback channels. Run the initial pilot alongside current SMS and require a separate evidence-based decision before App-first delivery or routine SMS replacement.
- Future funded capability: investigate PHC appointment inventory and management, records, prescriptions, clinical correspondence, test results, and Programme Cortisone-enabled publication as separately scoped capabilities.
Initial delivery should not wait for the later clinical-system work unless a named service dependency requires it. The bounded reminder route is independent of Phase 2 appointment visibility: a reminder message neither creates nor proves an appointment inventory.
Phased Adoption Model
| Phase | Patient-facing capability | Primary route | DPHC implementation question | Evidence boundary |
|---|---|---|---|---|
| 0. Initial provision | NHS App and NHS account access, profile, notifications, linked profiles, and proxy baseline | NHS account, NHS login, PDS, ODS, GP-practice setup, and local adoption support | Can the patient register, sign in, act for themselves, or act through a linked profile when the registration context is DPHC Firmbase or DPHC(O)? | Current DPHC mobile NHS App access is not available. Public NHS eligibility and proxy rules are the ordinary baseline, but they do not by themselves establish DPHC provision. |
| 1. Secondary healthcare (SHC) appointments | Hospital and specialist appointment visibility and management | Patient Care Aggregator / Wayfinder, e-RS, connected trust PEP appointment or booking functions, trust booking systems, and NHS App integration | Do DPHC referrals into NHS SHC produce e-RS, trust, or PEP appointment records visible through the NHS App for the relevant patient and age band? | This is the critical initial provider-connected function. Every acute trust was connected and 64% of hospital appointments were visible nationally by April 2026, but DPHC cohort behaviour, appointment coverage, age limits and route-specific participation still require testing. It is not DMICP PHC evidence (SRC-049 to SRC-053, SRC-069, SRC-132). |
| 2. DMICP PHC appointment visibility | Read-only DPHC primary-care appointment inventory and display where a visibility route is accepted | Proposed DMICP appointment feed through a controlled adapter; Patient Care Aggregator Record Service and Get Appointments APIs plus a PEP, direct web integration, or another accepted NHS-facing display route | Can DMICP provide a stable appointment inventory and satisfy patient matching, NHS login, route onboarding, display, suppression, and assurance requirements? | NHS Notify reminder delivery is separate and does not prove inventory. Current PCA/PEP onboarding is framed for secondary care. No public source confirms a DMICP appointment feed or DPHC PHC acceptance into PCA. |
| 3. DMICP PHC appointment management | Booking, cancellation, rescheduling, slot search, appointment change requests, and triage-linked management | A bidirectional DMICP / CORTISONE appointment-management interface with slot state, write-back, conflict handling, permissions, audit, supplier/practice enablement, and a validated NHS-facing route such as GP Connect Appointment Management, GP Connect Patient Facing Appointment Management, IM1 Pairing, or direct NHS App web integration | Can DMICP support safe bidirectional appointment management rather than read-only visibility, and can the chosen NHS-facing route write back to the authoritative DPHC appointment book? | Likely not available at this stage on current public evidence. DMICP evidence supports record-source relevance but not an appointment-management API; CQC evidence records DPHC information-system and appointment-search constraints; NHS Notify cannot manage appointments, and PEP/PCA evidence does not prove PHC booking. |
| 4. Clinical correspondence | Appointment letters, outcome letters, discharge summaries, questionnaires, and provider-authored documents | SHC provider document route, PEP document route where used, and GP-filed document view where filed into the GP record | Which correspondence is generated by the NHS provider, surfaced through an SHC provider document route, surfaced through a PEP document route, filed into the GP record, or held outside an NHS App route? | Correspondence evidence does not prove test-result availability, GP-filed result release, provider results-system availability, PEP results-release, or CORTISONE patient-data publication. |
| 5. Test results | Some GP or hospital-ordered test results, provider-released results, and GP-filed result views | GP-filed result view, GP clinical-system controls, clinical release processes, provider results system, and PEP results-release route where used | Which results are generated by the GP or NHS provider, held in a provider results system, released through a PEP results-release route, visible in the GP health record, or held outside the NHS App route? | Test-result evidence must distinguish GP-filed result views, provider results systems, PEP results-release routes, and later CORTISONE-held data. |
| 6. CORTISONE patient data | Later patient-data availability through Programme Cortisone and InterSystems-connected records | Programme Cortisone, HealthShare Unified Care Record (UCR), Health Connect / Integration Platform evidence, IRIS for Health, EMPI, IM1, GP Connect Patient Facing APIs, and NHS API Platform routes | Does CORTISONE become an NHS App-visible GP-linked data provider, a consumer, a shared-record source, an integration layer, or a separate professional interoperability layer? | Current evidence supports programme, supplier, IP / EMPI, licence-package, and GP Connect supplier-progress tracking, but not NHS App feature availability. |
Delivery Model Diagram
%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
Authority["NHS England route<br/>UK-wide DPHC reach"] --> Immediate["Initial delivery"]
Authority --> Bounded["Bounded reminder development"]
Authority --> Future["Future funded capability"]
Immediate --> Access["Phase 0<br/>mobile access and core national services"]
Immediate --> SHC["Phase 1<br/>SHC appointments and messages"]
Bounded --> Event["DMICP appointment event or feed"]
Event --> Adapter["Controlled adapter"]
Adapter --> Notify["NHS Notify<br/>App message and fallback"]
Future --> Visibility["Phase 2<br/>PHC appointment visibility"]
Future --> Management["Phase 3<br/>PHC appointment management"]
Future --> Documents["Phase 4<br/>clinical correspondence"]
Future --> Results["Phase 5<br/>test results"]
Future --> Cortisone["Phase 6<br/>CORTISONE candidate enablement"]
Notify -. "does not create inventory" .-> Visibility
Cortisone -. "may enable several routes" .-> Visibility
Cortisone -. "may enable several routes" .-> Documents
Cortisone -. "may enable several routes" .-> ResultsStage Detail
0. Initial Provision
Initial provision is the adoption floor. It covers the baseline work needed to move from no current DPHC mobile NHS App access to a position where a person can create or use an NHS account, access the NHS App, retain their account after moving into DPHC registration, receive messages or notifications, and use a linked-profile / proxy route where applicable.
For this wiki, initial provision must be tested separately for DPHC Firmbase adults, DPHC(O) patients, dependants, minors, and proxy users. The public NHS baseline is age, NHS account, GP registration, and GP-practice proxy setup; the open question is whether the MOD DPHC registration context satisfies the same service assumptions.
Initial Provision Cohort Matrix
| Cohort | Ordinary NHS baseline | DPHC-specific question | Current boundary |
|---|---|---|---|
| DPHC Firmbase adult | Own NHS account / NHS App access depends on age, NHS account state, GP registration, and enabled GP-linked services. | Is a DPHC Firmbase practice represented to NHS App dependencies as a registered GP practice with usable PDS, ODS, supplier, and practice-capability state? | Direct DPHC operational evidence still required. |
| DPHC(O) patient | NHS App access may depend on whether the user remains in an ordinary NHS GP registration context and whether the feature depends on England GP registration. | Does DPHC(O) / Defence Global Practice registration preserve, replace, or sit outside ordinary NHS App GP-linked feature assumptions? | DPHC(O) NHS App feature behaviour remains unresolved. |
| Minor under 13 | Own NHS App access is outside the ordinary public own-account baseline; parent / guardian access depends on GP-practice proxy setup. | Was the reported DMS under-13 appointment-booking issue caused by age, proxy setup, DPHC registration, GP-system configuration, or a route-specific appointment limitation? | Source-defined issue exists; resolution and cause are not yet evidenced. |
| Young person aged 13 to 15 | Own GP online access can exist where the GP surgery sets it up and checks understanding; proxy access remains governed by consent, capacity, safeguarding, and GP-practice rules. | Can a DPHC practice perform the equivalent setup, and does the NHS App treat DPHC registration as eligible for own access and linked-profile behaviour? | Needs DPHC practice-process and supplier evidence. |
| Dependant | Access follows the dependant's own age, account, GP registration, and proxy state; "dependant" is not a standalone NHS App eligibility category in current public NHS sources. | Is the dependant registered with ordinary NHS GP, DPHC Firmbase, DPHC(O), or split from the service person's registration route? | Analyse the dependant directly, not by association with the service person. |
| Proxy / linked-profile user | Proxy access is GP-practice configured, feature-limited, and subject to same-practice and age-review rules in the reviewed NHS route. | Can proxy and cared-for user relationships be configured where one or both parties are DPHC-registered, DPHC(O), or split across ordinary NHS GP and DPHC contexts? | Same-practice interpretation and DPHC setup remain evidence gaps. |
1. SHC Appointments
SHC means secondary healthcare: NHS hospital and specialist care. In the NHS App, this phase concerns hospital referrals and specialist appointments, not DMICP / DPHC PHC appointment visibility or management.
The strongest current route evidence is Patient Care Aggregator / Wayfinder plus e-RS and connected trust PEP appointment or booking functions. The implementation question is whether a DPHC patient's NHS secondary-care referral, booking, or waiting-list event appears in those provider systems in a way the NHS App can display or deep-link. This phase should also record trust participation, product coverage, age restrictions, PEP appointment behaviour, and paperless communication settings. It should not be used as evidence for PEP document routes or PEP results-release routes unless the source explicitly covers those functions.
This is the critical initial provider-connected capability for the IRTB(P). NHS England reported in April 2026 that every acute trust was connected, 64% of hospital appointments were visible nationally, and around half of trusts could send appointment reminders through NHS App push notifications. The project-owner-validated DMSR finding about Defence-related causes in reviewed external-referral delay cases supports the appointment-communication priority within its defined scope. The implementation test should start with real DPHC referral and booking journeys through named participating NHS providers in England, where relevant to the patient's care, rather than assume a new MOD interface is needed for NHS-originated SHC data.
Bounded Firmbase Appointment Reminder Workstream
The bounded reminder is a current-development workstream, not part of Phase 2 appointment visibility. Its patient outcome is a timely one-way reminder with an NHS App message where available and an approved fallback channel where needed. Initial operation should run alongside current DMICP SMS reminders. The NHS App could later become the primary reminder route and replace routine SMS for defined cohorts only after delivery, reconciliation, accessibility, support, safety, cost, exception, and fallback evidence supports a separate recorded decision. It does not provide an appointment list, booking, cancellation, rescheduling, or write-back.
The reviewed NHS catalogue has no national product named Appointments Reminder API. The proposed Defence source is a DMICP appointment event or reminder feed. A controlled adapter would transform the event, apply patient, organisation, suppression, and routing controls, then submit it through NHS Notify. Programme Cortisone / Health Connect is one candidate adapter, not the selected design.
Current public evidence confirms NHS Notify's messaging pattern and that MOD introduced SMS appointment reminders in the Total Triage context. Project-owner direction records the current GOV.UK Notify workflow and the intended parallel-to-App-first decision model. This does not prove the DMICP event/feed, Defence Medical Command (DMedC) sender eligibility, NHS Notify onboarding, adapter, matching, templates, callbacks, replacement case, approval, or end-to-end DPHC route. The workstream is therefore a candidate route requiring design, assurance and measured channel-transition evidence, not a demonstrated capability.
2. DMICP PHC Appointment Visibility
Phase 2 is the later read-only DPHC primary-care appointment-inventory and display problem. DMICP means Defence Medical Information Capability Programme. The public source set supports DMICP as an electronic integrated healthcare record source for Defence primary healthcare and some MOD specialist care, but it does not name an appointment inventory feed or an NHS-facing display route.
Visibility Route
A visible appointment summary and detailed page require a separate NHS-facing route. Patient Care Aggregator / Wayfinder uses a Record Service relationship, a Get Appointments API, NHS login and a PEP/deep link. Current public onboarding is written for eligible secondary-care booking systems, so DMedC must obtain NHS England acceptance before using this model for DPHC Firmbase PHC appointments.
A plausible visibility model has four evidence gates:
- source extraction: DMICP appointment / diary events would need a documented API, feed, or data-export contract covering patient identity, appointment identifier, appointment status, time, location, service, team or clinician context, triage link, audit, provenance, and minor/proxy restrictions;
- identity and organisation normalisation: the feed would need to map DPHC identity to NHS number / PDS context, DPHC organisation identity to ODS, and endpoint or service routing to Spine Directory Service (SDS) where an NHS route requires it;
- transformation layer: a controlled adapter would need to transform DMICP PHC appointment data into an accepted NHS-facing display format. Programme Cortisone / Health Connect is one candidate, but current public evidence does not prove that Health Connect is the named CORTISONE Integration Platform component or that it receives appointment feeds;
- NHS-facing route: NHS Notify provides reminder/status messages and fallback; Patient Care Aggregator / Wayfinder plus a PEP provides the candidate summary/detail route; direct NHS App web integration or a future supplier route remains an alternative. Each requires its own onboarding and assurance evidence.
Visibility is materially narrower than management. It can be modelled as appointment summaries, reminder messages, or a read-only portal view. NHS Notify is relevant for reminders, status messages, and fallback communications, but it is not an appointment inventory, slot-management, booking, cancellation, or rescheduling service by itself. Patient Care Aggregator / Wayfinder and PEP appointment or booking function evidence is currently secondary-care appointment evidence; use it for DPHC PHC only if a source shows that the DPHC PHC service is onboarded into that appointment route rather than inferred from secondary-care architecture.
Visibility Data Contract
| Data element | Why it matters | Evidence needed |
|---|---|---|
| Patient identity | NHS App display must match the right patient and account / linked-profile context. | NHS number, PDS matching, EMPI / CORTISONE matching if used, and minor/proxy handling. |
| DPHC organisation identity | The route must know whether the appointment belongs to DPHC Firmbase, DPHC(O), Defence Global Practice, or another provider context. | ODS code or equivalent organisation identity, plus the relationship to NHS App and GP-linked service assumptions. |
| Appointment identifier | Read-only display still needs a stable event identifier for deduplication, updates, and audit. | Source appointment ID, transformed ID, provenance, and update/delete semantics. |
| Status | Patients need to know whether the appointment is booked, changed, cancelled, completed, or pending. | DMICP status values and any mapping into NHS-facing status values. |
| Time and location | Basic visibility requires date, time, care setting, and attendance route. | Appointment time zone, clinic/site, virtual/telephone/face-to-face flag, and location display rules. |
| Service / team / clinician | The patient-facing label determines whether the appointment is understandable and safe to display. | Service, team, clinician, sensitivity suppression rules, and specialty / clinic naming rules. |
| Triage context | DPHC appointment visibility may be linked to triage or total-triage workflow rather than a simple GP slot. | Whether triage outcome, urgency, or contact channel should display, and what must be suppressed. |
| Message / reminder state | Reminders can be delivered separately from appointment inventory. | NHS Notify onboarding, fallback channel policy, restricted-record handling, and contact-data source. |
This table defines what would need to be known; it does not imply that DMICP currently exposes these fields. Open sources do not confirm whether DMICP can publish a read-only feed, whether CORTISONE / Health Connect can transform it, or whether an adapted/evolved route is planned.
3. DMICP PHC Appointment Management
This phase records booking, cancellation, rescheduling, slot search, appointment-change requests, and any triage-linked appointment management. On the current public evidence, it should be treated as likely not available or not implementable at this stage, rather than as the next practical delivery step.
The reason is architectural. Appointment management is not only a display problem. It needs an authoritative writable appointment book, slot and schedule state, conflict handling, cancellation and rebooking rules, patient and proxy permissions, audit, clinical-safety controls, supplier/practice enablement, and write-back to the DPHC source system. Current DMICP evidence establishes record-source relevance and constraints, not a safe bidirectional appointment-management interface; CQC evidence records DPHC information-system and appointment-search issues that strengthen the need for direct proof before making management claims.
The likely format question depends on the chosen NHS-facing route. GP Connect Appointment Management is a FHIR appointment-management standard for managing GP practice appointments between systems; the patient-facing appointment route adds search, booking, retrieval, details, and cancellation assumptions and includes registered-GP and NHS login P9 requirements in the reviewed catalogue evidence. NHS England Digital referrals-and-bookings guidance also states that NHS App and third-party software options use IM1 Pairing for GP-system integration in the relevant GP booking context. Direct NHS App web integration could launch a DPHC / CORTISONE appointment or triage service, but that would still need bidirectional DMICP / CORTISONE write-back evidence before being treated as PHC appointment management.
Record this phase in tables and validation queues because it is a patient-significant target. Do not merge it with visibility: visibility asks whether the patient can see DPHC PHC appointment information; management asks whether the patient can change the DPHC appointment book.
Management Blockers
| Blocker | Why it blocks management | Evidence needed to move it |
|---|---|---|
| Authoritative appointment book | Management changes must update the system that DPHC staff rely on operationally. | DMICP or successor source-of-truth statement, write API, or supplier appointment-book architecture. |
| Writable slot and schedule model | Booking and rescheduling require slot search, availability, locks, and race-condition handling. | Slot/schedule data model, reservation semantics, conflict rules, and transaction behaviour. |
| Cancellation and change rules | A patient-facing cancellation or change request may be unsafe or operationally invalid for some DPHC appointment types. | Rules by appointment type, triage state, age/proxy status, clinician/service, and notice period. |
| Write-back and audit | Every patient action must be attributable, reversible where appropriate, and visible to clinical and administrative users. | Audit trail, provenance, patient/proxy identity, staff visibility, and error-handling evidence. |
| Proxy and minor permissions | Appointment management through linked profiles may differ from visibility. | Permission model by age band, proxy relationship, same-practice status, and restricted services. |
| Clinical safety and fallback | Failed or partial appointment changes can cause missed care or unsafe duplication. | Clinical safety case, downtime handling, user messaging, fallback contact route, and support model. |
| NHS-facing route assurance | GP Connect, IM1, direct NHS App web integration, or another route needs formal onboarding and conformance. | Partner onboarding, technical assurance, data protection, information security, supplier/practice enablement, and live-service evidence. |
Because open sources do not describe DMICP appointment-management capabilities, the adaptation/evolution option remains unknown. It may be solved by CORTISONE, by a supplier adapter, by a DPHC portal, by a future GP Connect / IM1 route, or by no patient-facing management route at all; the wiki should not prefer one without evidence.
4. Clinical Correspondence
Clinical correspondence means provider-authored documents such as appointment letters, outcome letters, and discharge summaries. These may appear through an SHC provider document route, through a connected PEP document route, or through a GP-filed document view where the correspondence has been filed into the GP record.
Clinical correspondence is a document route, not a generic patient-data route. Do not use correspondence evidence to prove test-result availability, DMICP PHC appointment behaviour, or CORTISONE patient-data publication.
Correspondence Routes
%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
Correspondence["Clinical correspondence"] --> ProviderDocs["SHC provider document route"]
Correspondence --> PEPDocs["PEP document route"]
Correspondence --> GPDocs["GP-filed document view"]
ProviderDocs --> AppDisplay["NHS App display or deep link"]
PEPDocs --> AppDisplay
GPDocs --> GPControls["GP clinical-system release\nand practice controls"]
AppDisplay --> CohortGate["DPHC cohort, age,\nproxy, and provider-route gate"]
GPControls --> CohortGate
CohortGate -. "does not prove" .-> Results["Test results"]
CohortGate -. "does not prove" .-> CortisoneBoundary["CORTISONE patient data"]| Route | Content type | NHS App relevance | DPHC boundary |
|---|---|---|---|
| SHC provider document route | Appointment letters, outcome letters, discharge summaries, questionnaires, and provider-held correspondence attached to hospital or specialist care. | Can appear through hospital / specialist appointment journeys or a connected SHC provider document route where the NHS App integration supports it. | Relevant to DPHC patients only when their NHS SHC provider document route is connected and the patient is eligible for that display. |
| PEP document route | Provider-held letters, questionnaires, forms, or messages surfaced through a patient engagement portal. | May be surfaced through a PEP or NHS App-connected portal route where the PEP document route supports it. | PEP document route evidence must identify the provider, product, wider SHC provider document route where applicable, and integration route; it is not proof of GP-record result availability or CORTISONE data publication. |
| GP-filed document view | Documents filed into the GP record and visible through GP health-record access. | Depends on GP clinical system controls, release settings, and registered-GP context. | DPHC equivalence depends on DPHC GP-system supplier, PDS/ODS state, and practice capability; not proven by ordinary NHS GP evidence. |
5. Test Results
Test results need their own phase because the release route, clinical controls, and evidence boundary are different from correspondence. NHS App GP health-record evidence supports some GP and hospital-ordered results appearing in the GP health record, subject to GP-system controls and clinical review / release processes. PEP results-release guidance is a separate provider-portal route. CORTISONE patient data is a later Defence healthcare record route. Do not use evidence for one route as proof for the others.
Test Result Routes
%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
Results["Test results"] --> GPResults["GP-filed result view"]
Results --> PEPResults["PEP results-release route"]
Results --> ProviderResults["Provider results system"]
GPResults --> ReleaseControls["GP system and clinical\nrelease controls"]
PEPResults --> ReleaseControls
ProviderResults --> ReleaseControls
ReleaseControls --> CohortGate["DPHC cohort, age,\nproxy, and route gate"]
CohortGate -. "does not prove" .-> Correspondence["Clinical correspondence"]
CohortGate -. "does not prove" .-> GPDocs["GP-filed document view"]
CohortGate -. "does not prove" .-> CortisoneBoundary["CORTISONE patient data"]| Route | Content type | NHS App relevance | DPHC boundary |
|---|---|---|---|
| GP-filed result view | Some GP or hospital-ordered test results filed into the GP record and visible through GP health-record access. | Depends on GP clinical system controls, release settings, clinical review, and registered-GP context. | DPHC equivalence depends on DPHC GP-system supplier, PDS/ODS state, practice capability, and release controls; not proven by ordinary NHS GP evidence. |
| PEP results-release route | Provider-held results released through a patient engagement portal. | May be surfaced through a PEP or NHS App-connected portal route, with clinical release controls and timing rules. | PEP results-release route evidence must identify the provider results system, provider, product, integration route, and release controls; it is not proof of GP-record result availability or CORTISONE data publication. |
| CORTISONE patient-data route | Defence healthcare record data that may later include results through HealthShare / CORTISONE / integration components. | Could become relevant if CORTISONE acts as a source, consumer, or integration layer for patient-facing data. | Current public evidence supports programme relevance, not NHS App publication, feature availability, or DMICP adaptation/evolution capability. |
6. CORTISONE Patient Data
The later implementation question is whether Programme Cortisone can support NHS App-visible patient data through IM1, GP Connect Patient Facing APIs, or another assured NHS route.
The InterSystems sibling wiki now supports a stronger cross-deck reading than the original vendor announcement alone. Carried-over primary sources support MOD performance-row evidence for Programme CORTISONE IP and EMPI, an FY25-30 InterSystems licence award for IP&EMPI and DMS-IX covering HealthShare / IRIS for Health licences, and NHS GP Connect supplier-progress rows naming InterSystems IRIS For Health middleware and source-spelled InterSytems Healthshare. That strengthens the candidate enablement route, but it still does not prove NHS App publication.
For NHS App purposes, the evidence gate is narrower than product fit or licence evidence. The wiki still needs proof of whether CORTISONE is the registered GP provider source, a shared-care-record source, an integration layer, or a professional interoperability consumer; whether Health Connect is the named Integration Platform component or only an adjacent product fit; whether DPHC records are exposed through IM1 and/or GP Connect Patient Facing APIs; and whether NHS England partner onboarding, clinical safety, data protection, technical assurance, information security, and practice/capability enablement are complete.
The Architecture Index now gives Phase 6 a single logical route model. Read it as a route-layer check, not as a live implementation trace.
Phase 6 Route-Layer Check
| Route layer | Current Phase 6 reading | Evidence effect |
|---|---|---|
| Programme layer | Programme Cortisone / CORTISONE is the relevant MOD programme strand. | Supports roadmap framing, not patient-facing availability. |
| Component role | HealthShare UCR, IRIS for Health, EMPI, and possible Health Connect / Integration Platform roles are plausible CORTISONE components. | Supports component mapping; still needs direct production architecture and role evidence. |
| Source-system coverage | DMICP, TPP CORTISONE records, DPHC Firmbase, DPHC(O), NHS provider systems, or other sources must be named. | Prevents CORTISONE product evidence from being treated as cohort or feed evidence. |
| Identity and organisation | NHS number, PDS, ODS / SDS, and EMPI relationships must be proven. | Keeps identity matching separate from NHS App eligibility, GP registration, and proxy permission. |
| NHS-facing route | GP Connect PFS, IM1, NHS App web integration, NHS Notify, PCA, or PEP must be selected and evidenced by feature. | Determines whether Phase 6 can ever move from Not evidenced to Conditional. |
| Cohort and access mode | DPHC Firmbase, DPHC(O), minors, dependants, proxy users, and linked profiles need separate tests. | Prevents CORTISONE enablement from becoming blanket feature parity. |
| Assurance | Clinical safety, data protection, technical assurance, information security, fallback, and support must be evidenced. | Separates plausible architecture from guidance-ready implementation. |
Cross-Deck InterSystems Reading
| InterSystems component or concept | Cross-deck reading | NHS App implementation use | Boundary |
|---|---|---|---|
| HealthShare Unified Care Record | Shared-care / longitudinal-record product that aggregates, normalises, and deduplicates data; CORTISONE carry-over evidence strengthens the HealthShare / IRIS for Health IP&EMPI licence reading. | Possible CORTISONE patient-data record layer or source for harmonised patient context. | Product, performance-row, and licence evidence do not prove NHS App data publication. |
| Health Connect / integration tooling | Healthcare integration engine and standards-support route. | Possible analogue for CORTISONE Integration Platform evidence and interface transformation. | Current evidence does not separately name Health Connect as the CORTISONE Integration Platform component. |
| Enterprise Master Patient Index | Identity-resolution concept named in CORTISONE / InterSystems evidence. | Important for matching DPHC / NHS identities before any patient-facing data route can be trusted. | EMPI does not replace PDS or NHS account evidence unless a source states that relationship. |
| IM1 and GP Connect Patient Facing APIs | NHS routes for GP-system or GP-linked patient-facing functions; NHS supplier-progress evidence names InterSystems rows for GP Connect supplier progress. | Candidate routes for NHS App-visible GP record, appointments, prescriptions, and permissions if CORTISONE is acting in the relevant provider role. | Supplier-progress evidence does not prove DPHC practice enablement, CORTISONE deployment, NHS App exposure, or patient cohort availability. |
| DMICP PHC appointment visibility feed | Candidate source route from DPHC PHC appointment / diary data through a controlled transformation adapter for read-only NHS App visibility. Programme Cortisone / Health Connect is one candidate adapter, not the selected design. | Would need a documented API/feed, identity matching, appointment-status contract, display model, and NHS-facing onboarding path. | No current public source confirms a DMICP appointment API/feed, transformation implementation, or NHS App publication. |
| DMICP PHC appointment management interface | Candidate bidirectional route for booking, cancellation, rescheduling, slot search, and appointment-change requests. | Would need writable slot/schedule state, conflict handling, permissions, audit, write-back, FHIR or IM1 mapping, supplier/practice enablement, and NHS-facing onboarding path. | Likely not available at this stage on current public evidence; record as a target and evidence gap, not as a currently supported route. |
Implementation Evidence Gates
Before marking any phase as available for DPHC patients, capture:
- patient cohort: DPHC Firmbase, DPHC(O), dependant, minor age band, proxy / linked-profile user, or mixed ordinary NHS GP / DPHC family registration;
- visible NHS App feature: own access, linked profile, SHC appointment, DMICP PHC appointment visibility, DMICP PHC appointment management, PEP document route, GP-filed document view, PEP results-release route, GP-filed result view, GP record, prescription, message, or other service;
- source system: NHS provider system, e-RS, PEP appointment or booking function, SHC provider document route, PEP document route, provider results system, PEP results-release route, GP clinical system, DMICP, Programme Cortisone, HealthShare Unified Care Record, Integration Platform, or other supplier system;
- interface route: NHS App web integration, Patient Care Aggregator / Wayfinder, NHS Notify, IM1, GP Connect Appointment Management, GP Connect Patient Facing APIs, Message Exchange for Social Care and Health (MESH), PDS, ODS, Spine Directory Service, Electronic Prescription Service (EPS), or another named route;
- DMICP visibility feed contract: source events, identifiers, appointment status, triage linkage, coded/free-text limits, audit, and provenance;
- DMICP management interface contract: slot / schedule / status transitions, booking / cancellation / rescheduling permissions, write-back, conflict handling, patient/proxy permissions, audit, and provenance;
- assurance state: partner onboarding, clinical safety, data protection, technical assurance, information security, connection agreement, supplier pairing, and practice/capability enablement;
- fallback and exclusion handling: age limits, trust coverage, restricted records, paperless settings, GP-system release controls, proxy-service limits, and offline or non-NHS App alternatives.