Evidence Matrix
This matrix links claims to sources so the wiki can distinguish guidance-ready statements from boundary claims and unresolved implementation questions.
Rows marked Source required are deliberate evidence gaps, not validated support.
Use Guidance Decision Model for the current decision status produced from these claims, and Evidence Work Packages for prioritised evidence gaps.
Route-family labels are retained only where they change confidence, applicability, evidence required, assurance requirements, or guidance status. Otherwise, keep the claim at the wider provider-route or general Patient Engagement Portal (PEP) level and avoid creating a separate label.
| Claim | Evidence Type | Confidence | Limits | Next Evidence Needed |
|---|---|---|---|---|
| The NHS App is the patient-facing digital access route for a range of NHS services, with NHS account used for access. The current experience groups Home, Messages, and Profile, with unlike GP, provider, public-web, account, and national-service routes presented through one interface. | Official NHS service, public, technical, feature-catalogue, and navigation pages | High | A shared screen location does not prove a shared source system, entitlement, integration route, or availability for a local GP practice or special-registration case. | Recheck NHS App feature, navigation, and technical pages before any operational decision; map each displayed capability to its actual route. |
| People registered at a surgery provided by Defence Medical Services (DMS) cannot currently use the mobile NHS App. | Official NHS England Digital user-journey guidance | High for the current DMS exclusion | The source establishes the current access position. It does not identify the enabling route, future policy, named Defence Primary Healthcare (DPHC) practice configuration, age/proxy behaviour, or feature availability after access is introduced. | Obtain NHS and Defence Medical Command (DMedC) agreement on the enabling route, cohort handling, support, assurance, and feature tests. |
NHS App-presented services use different integration patterns: API, responsive web, and link-out. The mobile apps use a hybrid architecture, so native code must not be used as a synonym for every service visible through the NHS App. |
Official NHS roadmap and technical specification | High | Architecture pattern evidence does not prove a specific service is available to a DPHC cohort. | For each feature, identify the source service, integration style, identity route, eligibility rules, and DPHC access test. |
| NHS Health A to Z and Find NHS services near you are the current user-visible labels for public health information and NHS Service Search. Find NHS services near you can use postcode or device location to find dentists, pharmacies, hospitals, urgent-care services, GP surgeries, and other NHS services. NHS login is not required at the public-content integration layer. | Official NHS technical specification, roadmap, navigation, and user-journey guidance | High for current route, labels, and roadmap direction | Public web availability and search results do not prove mobile App access, entitlement, acceptance, capacity, service accuracy, DPHC representation, or a local care pathway. Device location adds a permission/privacy consideration. | Test mobile App navigation, postcode and location-permission behaviour, accessibility, assisted-digital alternatives, overseas boundary, result accuracy, and service-specific eligibility for each DPHC cohort. |
| NHS 111 online is a live urgent-care triage service for people in England aged 5 or over, available through the public website and the NHS App. It uses NHS Pathways clinical triage and the Directory of Services for locally commissioned service signposting. | Official NHS technical and service pages | High | It is not a diagnostic service, 999 replacement, DPHC Total Triage route, or evidence of DPHC appointment booking. The in-App route still depends on NHS App/account access. | Test mobile account hand-off, age/proxy behaviour, England/postcode handling, fallback, accessibility, and clinical-safety/support boundaries for DPHC cohorts. |
| The NHS App can make, check, confirm, or change an organ donation decision through the NHS Blood and Transplant Organ Donation API; the NHS Organ Donor Register is the authoritative record. | Official NHS technical/public pages, service-owner material, privacy notice, and release record | High | Current user-journey and release evidence does not prove DPHC mobile App access, age/consent handling, or successful identity matching for every cohort. | Test account/identity, API entitlement, age/consent, privacy, failure handling, and support by DPHC cohort. |
| The National Data Opt-Out is a national choice service presented through the NHS App and other channels, with the choice recorded against the NHS number on Spine. Own digital choice and proxy routes are age- and authority-specific. | Official NHS technical and service pages | High | It is not a GP-linked feature, and mobile App access is not the only channel. Under-13 and formal proxy choices use different routes in the reviewed guidance. | Test account/identity, NHS-number/Spine match, age/proxy handling, channel availability, and confirmation by DPHC cohort. |
| Be Part of Research, vaccination services, and the digital NHS Health Check are NHS App-presented national services using web integrations and, where applicable, NHS login or NHS App messages. | Official NHS integration/technical pages and official NIHR service | High for service taxonomy; conditional for service entitlement | Vaccination campaigns, pilots, eligibility, and local availability must not be generalised. Research participation remains voluntary and service-specific. | Identify the named service, eligibility, age/proxy rules, account hand-off, consent/privacy, accessibility, and task-completion outcome. |
| NHS App Profile can expose NHS number, contact details, home address, current GP surgery, health choices, App settings, family/carer access, and care plans where an integrated service supplies them. | Official NHS current-navigation, user-journey, and live-partner pages | High for feature taxonomy; conditional for each field and partner function | View, correction and change permissions differ. Address change is in limited rollout; care plans are integrated-partner functions; proxy users do not receive every service. | Map each profile field to its source, correction/change route, rollout, age/proxy behaviour, DPHC registration effect, accessibility, and support outcome. |
| The NHS App can show a current GP surgery and connect users to Register with a GP surgery. The registration service uses practice acceptance/catchment and NHS-record matching; Primary Care Registration Management (PCRM) manages the formal registered-GP change in Personal Demographics Service (PDS), while GP2GP handles the related record transfer. Primary Care Registration Management (PCRM)'s stated service coverage includes DMS. | Official NHS current-feature, service, integration, and registration-guide pages | High for ordinary NHS connected-service and national registration-process scope | DMS service coverage does not prove that a named DPHC practice is represented as an ordinary NHS GP practice, that a DPHC patient should change registration, that record transfer completed, or that the route is available through proxy access. It is a transition and continuity control as well as a potential convenience. | Test DPHC transition scenarios, current-GP display, practice search and catchment, application outcome, PCRM completion, before/after Personal Demographics Service (PDS) state, GP2GP record transfer, exceptions, continuity/safety-netting, policy ownership, and proxy exclusion. |
| Current NHS App capability also includes online GP medical and administrative requests, nominated-pharmacy and prescription status/barcode journeys, waiting-time information, provider documents/questionnaires, and integrated personal-health-record or care-plan functions where the named supplier and organisation support them. | Official NHS technical, feature-catalogue, navigation, and live-partner pages | High for capability taxonomy; conditional for implementation | These functions span GP systems, Electronic Prescription Service (EPS)/PDS, online-consultation suppliers, e-RS, Patient Care Aggregator / Wayfinder, Patient Engagement Portals (PEPs), provider systems, and personal-health-record partners. No item is universal merely because it appears in the catalogue. | Route-tag the named function, supplier, organisation, age/proxy state, source/release control, onboarding, fallback, and DPHC test result. |
| NHS App, NHS.UK, NHS planning, and the Ten Year Health Plan align around trusted advice, digital triage, self-service, prevention, provider communication, and a fuller digital front door. This strengthens the strategic case for DPHC mobile access but does not prove implementation. | Official NHS roadmaps, planning framework, and government strategy | High for strategic direction | Roadmaps and plans are time-sensitive and do not establish MOD authority, DPHC entitlement, resources, delivery dates, or supplier commitments. | Recheck before formal decision; obtain DMedC ownership, cohort scope, options, benefits baseline, resources, assurance, and delivery evidence. |
| A proportionate DPHC NHS App business case should state the case for change, business as usual, objectives, alternative options, one selected option, benefits, disbenefits, risks, uncertainty, resources, commercial/technical feasibility, delivery, assurance, and evaluation. Public MOD sources confirm the IRTB format family and its Issue, Recommendation, Timing, Background and Presentation sequence. MOD digital-content guidance also requires GOV.UK content principles for internal digital services and links plain English to accessibility, acronym/terminology control and security marking. The retained project document provides the continuous layout and visual treatment. The Five Case Model is a completeness framework, not the IRTB(P) heading structure. | Official UK government and MOD guidance/review material, NHS adjacent guidance, historical Defence templates, current public digital-content/accessibility guidance, and retained local format | High for current Treasury method, public MOD digital-content principles, and existence of the MOD format family; moderate for historical examples; local for retained visual design | Public evidence does not confirm the current general-purpose internal JSP 101 template, classification, local staffing route or approval chain. Digital-service writing guidance supports the paper but does not replace its approved internal staff-work format. SRC-119 is not current new-procurement policy; SRC-120 and SRC-121 are historical; SRC-130 is a legacy acronym lookup only. | Confirm current internal Defence writing guide/template, security marking, staffing route, approval authority, resource evidence and document owner. Keep complete options before the recommendation, select one preferred option, and apply the Defence digital content and writing standard to the wiki and issued document. |
| Internal DMSR analysis identified Defence-related causes in 84% of the external-referral delay cases reviewed, including inaccurate contact details and delays passing appointment information to patients. | Project-owner-validated internal finding | Moderate-high for the scoped internal finding | The primary artefact is not retained in the repository. The figure applies only to the reviewed delay cases and must not be generalised or used as the sole case for change. | Preserve the reviewed-case scope and supporting-evidence role whenever the figure is used. |
| The corrected programme-planning baseline is 89 of 103 UK DPHC Medical Centres in England, or 86.4% (approximately 86%). | Project-owner-validated internal estate baseline | High for the current programme-planning context | The underlying estate artefact is not retained in the repository. The corrected figure supersedes the earlier project-owner counts of 91 and the earlier denominator of 106; SRC-086 is a separate public 105-centre denominator for the April 2025 Total Triage context. | Recheck when the estate changes or before using the figure outside the current decision context. |
| All MOD-registered patients retain their first NHS England registration throughout MOD registration, irrespective of UK residence. Secondary registration in Scotland or Wales, where applicable, does not replace it. Secondary registration in Northern Ireland is intended but is not yet in place. The proposed enablement includes MOD-registered patients across the UK for that period through their continuing NHS England registration. Applicable core national services, appointment information from participating NHS providers in England where relevant to their care, and a future assured Defence Medical Information Capability Programme (DMICP) reminder route are the intended benefit set. | Project-owner-validated internal registration baseline | Moderate-high for current cohort-scope planning | Supporting PDS, Organisation Data Service (ODS), registration-policy and representative cohort artefacts are not retained. This does not prove mobile NHS App entitlement, service-specific availability, consistent registration representation, provider participation or reminder implementation. | Confirm the registration model and resulting NHS App behaviour through retained policy, PDS / ODS evidence and representative Firmbase, DPHC(O), age and proxy cohort tests; test each intended service route separately. |
| The current IRTB(P) service description states that the NHS number and registered GP practice display for a DPHC-registered patient uses the civilianised Medical Centre name and address. | Official PDS field definition plus project-owner-reported DPHC display baseline | High for the PDS field scope; internal-reported for the DPHC patient-facing value | No patient screenshot, PDS extract or cohort test artefact is retained. This does not prove mobile NHS App access, ordinary NHS GP-practice equivalence or GP-linked feature enablement. | Confirm the displayed practice name and address in representative Firmbase cohorts and registration-transition states before issuing estate-wide guidance. |
| A 2022 draft MOD DHDO Patient Access Statement of Requirements recorded limited digital patient access and desired advice, NHS App, appointment-management, reminder, record, prescription, triage, and communication capabilities. | Officially published but uncontrolled draft procurement artefact | Moderate for historical intent; low for current state | The draft could be retained, amended, or deleted and does not prove procurement outcome, current requirement, approval, or implementation. | Use only as historical problem framing; obtain current DMedC requirements and ownership before making delivery claims. |
| Public NHS App eligibility, rechecked on 18 September 2026, covers users aged 13 or over with GP registration in England or the Isle of Man and retains the DMS-registration exclusion. | Official NHS public pages | High | This is a public eligibility statement; it does not establish an enabling route for DPHC Overseas [DPHC(O)] or DPHC Firmbase, or service-specific availability. The earlier SRC-002 review dated 15 June recorded the England GP-registration boundary. | Add MOD/NHS operational guidance for DPHC-registered patients and dependants. |
| Public NHS child-access guidance separates own NHS App access from parent, guardian, or carer proxy access. Under-13 children are outside the ordinary own-account baseline; 13-to-15-year-olds can have own GP online access if the GP surgery sets it up and checks understanding; parent or guardian proxy access is subject to age, capacity, consent, safeguarding, and review rules. | Official NHS public pages | High for ordinary NHS rules | Does not define DPHC Firmbase, DPHC(O), or DMS primary-healthcare behaviour. | Add MOD/NHS service-owner evidence for DPHC minors and the under-13 DMS appointment-booking issue. |
| NHS App proxy / linked-profile access is GP-practice configured, feature-limited, and subject to a same-GP-practice requirement for the reviewed route. A proxy user acts through their own NHS App account; GP practice setup selects available services. Guidance rechecked 21 September 2026 excludes managing hospital services and sending/viewing messages through the cared-for profile. | Official NHS and NHS England Digital guidance | High for ordinary proxy model | Does not prove that DPHC practices can configure the same route, that split NHS GP / DPHC family registrations satisfy the same-practice rule, or that every NHS App feature is available through proxy access. | Validate DPHC GP practice setup, GP IT system support, same-practice interpretation, and service limits for dependants and carers. |
| NHS App roadmap material links future and current GP-linked app capability to GP Connect Patient Facing APIs, including GP record access, repeat prescriptions, and linked-profile improvements. | Official NHS roadmap and API/service pages | High for NHS direction | Roadmap content is time-sensitive; API availability does not prove every GP system, DPHC practice, or patient group is enabled. | Track roadmap changes and supplier rollout by GP system / ODS organisation. |
| GP Connect Patient Facing APIs are a patient-facing route for viewing GP records, requesting repeat prescriptions, and retrieving GP practice user permissions. GP Connect architecture places the patient-facing products on the NHS API Platform route, with PDS registered-GP lookup, ODS/endpoint lookup, provider-system processing, and practice/capability enablement controls. | Official NHS service, API catalogue, architecture, and non-functional requirement pages | High | Describes NHS API capability and enablement controls, not local DPHC configuration or availability. | Map DPHC GP system supplier, ODS organisation type, GP Connect PFS onboarding status, and practice/capability enablement. |
| Published NHS support guidance separates practice/supplier configuration, NHS login sign-in and identity, and NHS App feature issues. Sign-in troubleshooting includes receipt of security codes overseas. | Official operational guidance, checked 21 September 2026 | High for published support routes | Does not assign Defence support responsibilities or prove overseas eligibility or service availability. | Agree first-stage support ownership and test sign-in, changed phone numbers and onward help for the selected patient groups. |
| NHS login and NHS account are critical identity and access dependencies for NHS App continuation and/or adoption, including linked-profile and proxy-access experience. | Official NHS public, roadmap, and proxy-access pages | High | Public and roadmap sources do not define MOD-specific identity-proofing or proxy-access edge cases. Successful account sign-in does not prove GP-linked feature access or linked-profile availability. | Add NHS login operational material for DPHC / armed-forces cohorts if available. |
| PDS, ODS, and Spine Directory Service (SDS) are core architecture dependencies because patient identity, registered GP practice, NHS number, organisation identifiers, and endpoint lookup affect NHS App and GP-linked service routing. | Official NHS service pages, GP Connect architecture overview, and developer guidance | High | This is an architecture reading from service roles, not a full NHS App internal architecture document. | Add architecture diagrams, DPIAs, service standards, or supplier onboarding material for exact flows. |
ODS evidence now confirms relevant MOD / DMS identifiers, DGP-postcode candidate records, and role semantics, but not DPHC Firmbase or DPHC(O) GP-linked NHS App equivalence. The ORD query signal includes DDG Defence Medical Services as an Independent Sector Healthcare Provider, DMS-operated sites, XDM Ministry of Defence as a Government Department, S22029 Ministry of Defence as a Scottish GP Practice, and active prescribing-cost-centre records at the DGP guide postcode WS14 9PY; literal Defence Global Practice, DGP, DPHC, and Central European Practice name searches did not return a directly named active DGP practice record in the current pass. |
Official ODS API, MOD guide, reference data catalogue, and data dictionary evidence | High for ODS identifier boundary | This narrows the ODS model but does not prove a DPHC Firmbase or DPHC(O) patient has an ordinary PDS registered-GP state, RO76 GP Practice non-primary role, GP-system supplier, GP Connect PFS / Interface Mechanism 1 (IM1) enablement, proxy setup, practice capability, or NHS App feature availability. The ODS non-finding is not proof of absence. | Obtain DPHC Firmbase and DPHC(O) practice-level ODS list, PDS registered-GP examples or service-owner statement, GP supplier / capability evidence, GP Connect / IM1 onboarding status, and feature tests by cohort. |
| GP Connect architecture spans different integration patterns: professional APIs can use Spine Secure Proxy (SSP), messaging routes can use Message Exchange for Social Care and Health (MESH), and patient-facing APIs use the NHS API Platform route with registered-GP and endpoint lookup dependencies. | Official NHS architecture, API, and developer guidance pages | High | Pattern-level architecture only; exact API route and security controls vary by capability. | Map each NHS App feature to its actual API and assurance path. |
| Interface Mechanism 1 is a supplier-specific interface route into principal GP clinical systems. Official IM1 evidence includes supplier pairing, Pairing and Integration Packs, Service Conformance Assessment List (SCAL), Model Interface Licence (MIL), patient APIs for appointments, repeat medication, prescription requests, medical-record viewing, and GP communication, plus in-development IM1 PFS Auth. | Official NHS API standards, service, API catalogue, and developer guidance | High for interface definition; time-sensitive for in-development PFS Auth | IM1 evidence does not prove NHS App or DPHC availability; supplier-specific APIs and practice configuration remain decisive. | Identify whether any DPHC GP supplier route uses IM1, GP Connect PFS, both, or another interface; obtain PIP, assurance, and practice-enablement evidence where appropriate. |
| NHS England partner onboarding is an assurance layer for APIs and services including GP Connect, IM1 Auth Proxy Service, NHS App, NHS App notifications and messaging, NHS Notify, Patient Care Aggregator / Wayfinder, e-RS APIs, PDS APIs, and MESH. | Official NHS England Digital service page | High for onboarding model | Does not prove a DMedC / DPHC service has completed onboarding or is permitted to send data or messages. | For every proposed DMedC / DPHC route, obtain onboarding status, connection agreement, clinical-safety, data-protection, technical-assurance, and information-security evidence. |
| EPS is a distinct prescription infrastructure and API context that must be separated from GP Connect patient-facing repeat-prescription request flows. | Official NHS API catalogue pages | High | Does not map the full NHS App prescription journey from request to nomination to EPS dispensing. | Add NHS App prescription journey documentation and EPS app-facing implementation detail. |
| NHS Notify can deliver NHS App messages as one channel and route to configured email, SMS or letter fallback. NHS Notify may use GOV.UK Notify as one communication supplier, while direct GOV.UK Notify use supplies email, SMS or letters rather than the NHS App channel. NHS Notify is therefore the correct public NHS transport for a proposed DPHC NHS App appointment-reminder service. Initial App delivery should run alongside current DMICP SMS reminders; App-first delivery or routine SMS replacement for defined cohorts is a later service decision. | Official NHS and GOV.UK service, feature, integration, API, technical-specification and campaign pages plus project-owner workflow and design-direction evidence | High for messaging-service scope, service boundary and general reminder value; internal-reported for the current DPHC workflow and transition intent | NHS Notify is not appointment inventory, visibility or management. Project-owner direction reports current DPHC GOV.UK Notify use and a parallel-to-App-first intent, but no retained implementation, pilot, channel-performance, replacement-case or approval artefact confirms them. The sources do not prove a DMICP appointment trigger/feed, DMedC NHS Notify sender eligibility/onboarding, suitable PDS contact data or attributable Defence outcomes. | Obtain the current GOV.UK Notify service/configuration evidence, DMICP source trigger/feed and DMedC NHS Notify ODS/sender, routing, template, callbacks, parallel-run baseline, channel-transition measures, exception/fallback routes, restricted-record controls, support, cost, funding, approval and end-to-end test evidence. |
| e-RS is a national digital platform for referral management, making it relevant to NHS App referral and waiting-list journeys. | Official NHS roadmap and service pages | High for e-RS service scope | Does not define every patient-facing NHS App referral feature or DPHC impact. | Map NHS App referral/waiting-list features to e-RS and provider-system evidence. |
| Patient Care Aggregator / Wayfinder is the NHS App route for a single secondary-care referral and booking view. It retrieves e-RS and connected secondary-care booking-system summaries, returns them to the NHS App, and deep-links users to e-RS or PEP appointment or booking functions. Every acute trust was connected and 64% of hospital appointments were visible nationally by April 2026. | Official NHS service, technical, integration, requirements and current implementation pages | High for architecture and national implementation route | This is secondary-care appointment/referral evidence, not proof of every appointment, DPHC-specific access, DMICP Primary healthcare (PHC) eligibility, PEP document/results routes or GP-record access. | Confirm whether DPHC Firmbase and DPHC(O) referrals/bookings flow through e-RS, participating trusts and connected PEP appointment or booking functions; separately obtain an NHS England eligibility decision before proposing DPHC PHC onboarding. |
| Patient Engagement Portals are a distinct provider/supplier layer, not the NHS App itself. In Wayfinder they provide appointment data and deep-link destinations; in wider NHS guidance PEP can also mean document, results-release, eForms, PIFU, and provider-specific patient-interaction routes. | Official NHS implementation and clinical guidance | High for terminology distinction | PEP evidence is broad and must not be generalised into NHS App feature availability unless the function is route-tagged and specifically connected to NHS App, Wayfinder, NHS Notify, or another integration. | Tag each PEP claim only to the narrowest route needed to preserve confidence, applicability, or decision status; otherwise retain it as general PEP / provider-portal context. |
| DMS registration and DPHC(O) / Defence Global Practice registration are registration contexts for NHS App analysis, not feature-availability evidence. MOD statistics define DMS registration as MOD-provided primary care / GP services rather than NHS provision. The current DGP guide describes DGP as a registered UK General Practice and DPHC(O) practice, but also as an overseas support and record-management service where local or host-nation providers usually deliver care. | Official MOD guide and official statistics / background quality report | High for registration-context boundary | This supports the registration-state model and DPHC(O) baseline, but does not prove NHS App eligibility, PDS registered-GP representation, ODS route, GP Connect PFS, IM1, proxy setup, or any GP-linked NHS App feature. | Obtain DPHC Firmbase and DPHC(O) service-owner evidence for PDS registered-GP state, ODS organisation identity, supplier / GP-system setup, GP Connect / IM1 enablement, proxy setup, and feature tests. |
| Initial provision for DPHC NHS App continuation and/or adoption must be analysed by cohort rather than as a single eligibility question. DPHC Firmbase adults, DPHC(O) patients, minors, dependants, proxy users, linked-profile users, and split NHS/DPHC family registrations can each fail at different account, registration, practice, proxy, or feature-dependency points. | Official NHS public and proxy-access guidance plus DPHC evidence boundary | High for ordinary NHS baseline; boundary for DPHC behaviour | Public NHS sources define ordinary account, age, GP-practice, and proxy rules but not DPHC equivalence. | Obtain DPHC service-owner evidence for each cohort and registration state. |
| NHS App implementation for DPHC should be analysed across delivery horizons: mobile access and core national services, appointment information from participating NHS providers in England where relevant to the patient's care, a bounded Firmbase reminder workstream introduced alongside current SMS, and later DPHC clinical integration. The Phase 0-6 model remains a detailed technical reference within those horizons. | Official NHS, NHS England Digital, MOD, regulator, and vendor / cross-deck evidence plus project-owner scope and transition direction | Boundary for DPHC implementation model | Delivery horizons and phases are planning and evidence models, not proof of feature availability for any DPHC cohort. Each outcome needs direct cohort, source-system, interface, assurance, fallback and, where relevant, channel-transition evidence. | For each outcome, capture patient cohort, age/proxy state, source system, interface route, onboarding/assurance status, fallback path, channel-transition state, and exclusions. |
| NHS App hospital and specialist appointment evidence supports Secondary healthcare (SHC) appointment visibility using e-RS, Patient Care Aggregator / Wayfinder, connected trust PEP appointment or booking functions, and trust booking data. The current national connection and visibility level make appointment information from participating NHS providers in England the critical initial provider-connected DPHC test where relevant to the patient's care. | Official NHS England Digital service, integration, requirements, feature and implementation pages | High for public NHS App secondary-care route | This is not proof of every appointment, DMICP / DPHC PHC appointment visibility or management, DPHC cohort visibility, PEP document route availability or PEP results-release. | Test named DPHC Firmbase and DPHC(O) secondary-care referrals, appointments, messages and waiting lists through participating trusts and PEP appointment or booking functions in England where relevant to the patient's care, including age/proxy and fallback behaviour. |
| DMICP is relevant to DPHC patient-service analysis because public MOD evidence describes it as the electronic integrated healthcare record source for primary healthcare and some MOD specialist care, while regulator evidence records DPHC information-system, interface, coding, appointment-search, and performance-data issues. Project-owner direction reports that DMICP cannot currently provide the approved connections needed for NHS App access to GP health records; repeat-prescription requests and nominated-pharmacy changes; appointment and referral information, notifications and tracking; secure provider messages; or clinical documents and test results. | Official MOD FOI and CQC regulator reports plus project-owner capability baseline | High for relevance; internal-reported for the current connection boundary | Public sources do not expose DMICP interface contracts, detailed current capability, CORTISONE / Health Connect transformation, NHS App publication, or adaptation / evolution options. SRC-139 does not establish permanent infeasibility or select a future solution. | Obtain retained current-state architecture and interface evidence, then define the technical, information-governance, Defence-security, cost and deliverability positions for each proposed service and any adaptation/evolution route. |
| A DPHC Firmbase appointment-reminder service can be modelled as a proposed DMICP appointment event/feed, an assured controlled adapter, and NHS Notify delivery to the NHS App with fallback. Initial delivery should run alongside current DMICP SMS reminders. App-first delivery or replacement of routine SMS for defined cohorts requires a separate evidence-based service decision. Programme Cortisone / Health Connect is one candidate adapter, not the selected design. | Official NHS messaging/integration/onboarding evidence, official MOD appointment-context evidence and project-owner transition direction | Conditional implementation target; source, onboarding, transition evidence and approval not yet proven | No public source confirms the DMICP event/feed, field contract, adapter implementation, DMedC sender onboarding or live route. No retained artefact establishes the parallel-run baseline, replacement case or approval. A reminder is not appointment inventory, visibility, management or write-back. | Obtain source contract, patient/ODS matching, minimum safe data, NHS Notify onboarding, routing/templates, restricted-record controls, callbacks, parallel-run baseline, channel-transition measures, exception/fallback routes, reconciliation, cost, funding, assurance, approval and end-to-end test evidence. |
| DMICP PHC appointment visibility would need a read-only source contract plus an accepted NHS-facing display route. Patient Care Aggregator / Wayfinder requires Record Service and Get Appointments integrations, NHS login and a PEP/deep-link route. | Official NHS integration, onboarding and API evidence plus MOD source-system context | Boundary / candidate architecture | Current public PCA onboarding is framed for eligible secondary-care systems. It does not establish DPHC Firmbase primary-care eligibility, a DMICP feed or live visibility. | Obtain the DMICP feed contract, identity/organisation mapping, NHS England PCA/PEP eligibility decision, portal, NHS login, onboarding, assurance and end-to-end display evidence. |
| DMICP PHC appointment management is a separate and harder phase than visibility because it requires booking, cancellation, rescheduling, slot search, appointment-change requests, and write-back to the authoritative DPHC appointment book. | MOD FOI, CQC regulator reports, and official NHS booking / appointment-management route evidence | Boundary; likely not available at this stage | Current public evidence does not show a safe bidirectional DMICP appointment-management API, CORTISONE write-back route, supplier/practice enablement, or NHS App onboarding. CQC DPHC system findings and DMICP constraints mean management should be recorded as a target/evidence gap rather than assumed feasible. | Obtain bidirectional DMICP / CORTISONE appointment-management interface evidence, slot and schedule model, conflict handling, write-back rules, permissions, audit, clinical-safety controls, and NHS-facing API/onboarding proof. |
| MOD Total Triage evidence describes a DPHC primary-healthcare access route using online form or phone requests that are triaged to advice, face-to-face appointment, or remote consultation. | Official MOD / Strategic Command news page | High for current DPHC Total Triage context | This narrows the DPHC PHC appointment-access model but does not prove NHS App appointment booking, DMICP API/feed capability, Patient Care Aggregator onboarding, GP Connect, IM1, PEP, or CORTISONE integration. | Identify whether Total Triage has any NHS App-facing integration, whether its source system writes to DMICP or another appointment book, and whether it affects the under-13 DMS NHS App issue. |
| NHS App SHC provider document-route evidence supports clinical correspondence only when the SHC provider document route, document type, NHS App display or deep-link behaviour, age/proxy state, and DPHC registration effect are known. | Official NHS App feature and live-partner pages | High for public SHC provider document route distinction | SHC provider document evidence does not prove PEP results-release, GP-filed result views, GP-filed document views, CORTISONE publication, or DPHC-specific availability. | Identify provider/trust, integrated product, document type, display/deep-link route, patient cohort, age/proxy state, and DPHC registration effect. |
| PEP document-route evidence must be kept separate from PEP appointment or booking functions and PEP results-release route evidence. | Official NHS patient-portal, Wayfinder, and NHS App feature pages | High for route distinction | A PEP can support different functions; evidence for one PEP function does not prove another. PEP document route evidence does not prove GP-record result visibility, PEP results-release, appointment booking, or CORTISONE-held patient data. | Tag each PEP claim by provider, product, PEP document route, NHS App deep-link/display route, authentication route, age/proxy state, and patient cohort. |
| GP-filed document-view evidence supports documents filed into the GP record and visible through GP-record access, separate from provider-held documents and result views. | Official NHS App GP health-record feature guidance | High for ordinary NHS GP-record scope | Ordinary NHS GP-record evidence does not prove DPHC GP-system equivalence, SHC provider document routes, PEP document routes, or test-result release. | Obtain DPHC GP-system supplier, PDS/ODS, practice capability, filing state, release setting, and document-display evidence. |
| GP-filed result-view evidence supports some GP and hospital-ordered results visible through GP-record access, subject to GP-system and clinical release controls. | Official NHS App GP health-record feature guidance | High for ordinary NHS GP-record scope | GP-filed result evidence does not prove PEP results-release, SHC provider document route availability, PEP document route availability, CORTISONE-held data publication, or DPHC GP-system equivalence. | Obtain result source, GP filing state, clinical review/release control, DPHC GP-system setting, patient-facing display route, and age/proxy effect. |
| PEP results-release route evidence supports provider-held results release only where the source identifies the provider results system, PEP / NHS App digital route, release timing, safety controls, and override process. | Official NHS England clinical guidance | High for clinical controls and route distinction | PEP results-release evidence does not prove GP-record result visibility, SHC provider document route availability, PEP document route availability, appointment management, or DPHC-specific availability. | Identify provider, PEP product, provider results system, result type, release schedule, suppression/override rule, NHS App or PEP access route, age/proxy handling, and DPHC registration effect. |
| CORTISONE-held document or result data remains a later patient-data route until NHS App publication, provider role, and interface route are directly evidenced. | MOD programme publication and vendor programme evidence | Boundary for patient-facing use | CORTISONE programme relevance does not prove Phase 4 clinical correspondence, Phase 5 test results, GP-record filing, PEP release, or NHS App feature availability. | Obtain CORTISONE source role, HealthShare / Health Connect / Enterprise Master Patient Index (EMPI) mapping, IM1 or GP Connect PFS route, NHS onboarding / assurance, patient-facing publication evidence, and cohort tests. |
| HealthShare Unified Care Record (UCR), Health Connect / integration tooling, IRIS for Health, and InterSystems GP Connect supplier-progress evidence are relevant to the CORTISONE enablement hypothesis, but current evidence does not prove NHS App publication or that Health Connect is the named CORTISONE Integration Platform component. | MOD programme publication, InterSystems product/vendor pages, official MOD performance / procurement evidence, NHS supplier-progress evidence, and local cross-deck synthesis | Moderate-high for CORTISONE / InterSystems fit; boundary for NHS App implementation | Primary carry-over strengthens supplier, IP / EMPI, licence-package, and GP Connect supplier-progress evidence. It does not establish live DPHC feature availability, NHS App integration, GP Connect Patient Facing API onboarding for DPHC, IM1 pairing, or patient cohort access. | Treat missing DPHC practice-level evidence as a boundary and test the CORTISONE route: component role, source-system coverage, HealthShare / IRIS / Health Connect mapping, IM1 or GP Connect PFS route, PDS/ODS matching, NHS App exposure, onboarding / assurance, and cohort feature tests. |
| Defence Medical Command was established as the successor public command identity for HQ Defence Medical Services in 2026. | Official MOD pages | High | Does not describe DPHC GP system configuration or NHS App service entitlement. | Add DMedC / DPHC operating model and primary-care digital system documentation. |
| Armed Forces Covenant annual reports provide an official DPHC / NHS continuity evidence series, including medical-record transfer, Defence Medical Information Service / Programme, Programme CORTISONE / Op CORTISONE source wording, DMS primary care, health identifiers, NHS Digital data matching, service-family mobility, DPHC(O) return, and information-transferability issues. | Official MOD annual-report series | High for reported issues and programme statements | The reports are not NHS App feature specifications; most findings are NHS App-adjacent rather than direct app evidence. | Track new annual reports and add service-owner evidence that connects reported issues to exact NHS App feature behaviour. |
| Pre-2020 Armed Forces Covenant annual reports do not provide direct NHS App, NHS account, or NHS login evidence in the current review, but they do contain general digital-health and MOD/NHS interoperability evidence. | Official MOD annual reports | Boundary | Absence of terms in the reviewed text is not proof that no operational NHS App issue existed; it only bounds the annual-report evidence. | Add direct MOD/NHS App implementation evidence and confirm whether Defence Medical Information Service / Programme maps to later CORTISONE governance. |
| Government armed-forces evidence records an NHS App appointment-booking access issue for DMS primary-healthcare registration; the source-defined cohort is children under 13. | Official MOD annual report | High for existence of reported issue | The report is cohort-specific and does not establish adult DPHC patient access, current resolution, proxy behaviour, or all NHS App features. | Find follow-up NHS/MOD resolution evidence and affected age, ODS, GP-system, proxy, and feature-configuration detail. |
The MOD CORTISONE programme is intended to deliver a new digital medical-record system for armed forces personnel and integrate with the NHS; earlier annual reports show the same broad medical-record-transfer problem space under Defence Medical Information Service / Programme language. Source wording varies by date and source, including Programme CORTISONE, Programme Cortisone, and Op CORTISONE. |
Official MOD news and annual reports | High for programme statement; moderate for lineage framing | Does not itself prove NHS App enablement, GP Connect PFS onboarding, or feature parity for DPHC patients. Annual-report timelines and programme naming are time-sensitive. Treat Op CORTISONE as source wording for the same programme strand unless evidence distinguishes a separate operation. |
Add contract, technical architecture, GP Connect, NHS App, PDS/ODS, and supplier assurance evidence. |
| DPHC-registered patients do not currently have mobile NHS App access. Evidence gaps concern the enabling route, cohort and proxy handling, service-specific dependencies, and operational assurance rather than whether the current access gap exists. | Direct official NHS exclusion plus adjacent NHS and MOD context | High for current no-access position; boundary for implementation | The exclusion does not define the future enabling route or prove the status of every service after access is introduced. | Obtain direct NHS/DMedC route approval and test named cohorts, access modes, services, and operational states. |