Skip to content

Context Map

The wiki topic is Defence Medical Command (DMedC) NHS App continuation and/or adoption and NHS App architecture. Its purpose is to inform DMedC / Defence Primary Healthcare (DPHC) NHS App guidance; that guidance is the intended output of the evidence base, not a research priority.

Current Domain

The current focus is continuation and/or adoption of the NHS App by MOD Defence Medical Command / Defence Primary Healthcare-registered patients, with special attention to the Guidance Decision Model, Registration State Model, phased adoption and implementation, NHS App architecture, the canonical user-facing capability catalogue, NHS Health A to Z, Find NHS services near you, NHS 111 online, NHS number and profile functions, current/change GP-surgery journeys, organ donation, National Data Opt-Out, research participation, prescriptions and pharmacy, GP medical and administrative requests, provider journeys, personal health records, Defence Medical Information Capability Programme (DMICP) Primary healthcare (PHC) appointment visibility, DMICP PHC appointment management, NHS account/login, GP Connect Patient Facing APIs, Interface Mechanism 1 (IM1), Message Exchange for Social Care and Health (MESH), partner onboarding, Patient Care Aggregator / Wayfinder, Patient Engagement Portals (PEPs), NHS Notify, Spine services, Spine Directory Service (SDS), Personal Demographics Service (PDS), Primary Care Registration Management (PCRM), GP2GP, Organisation Data Service (ODS), Electronic Prescription Service (EPS), the CORTISONE programme, HealthShare Unified Care Record (UCR), Health Connect / Integration Platform evidence, Enterprise Master Patient Index (EMPI), DPHC Firmbase, DPHC Overseas [DPHC(O)], dependants, minors, and the capability-based IRTB(P).

Evidence Clusters

  1. NHS App service scope and eligibility: official NHS App and NHS account pages establish the public service and the age 13+ / GP surgery in England boundary.
  2. Minors, dependants, and proxy / linked profiles: official NHS and NHS England pages define ordinary child age bands, age 13+ own-access setup, 16+ proxy transition, GP-practice proxy configuration, same-GP-practice requirement, service limits, and formal proxy governance. They do not define DPHC behaviour.
  3. NHS App capability catalogue and roadmap: official current-feature, navigation, technical, user-journey, release, NHS.UK, medium-term planning, and Ten Year Health Plan sources provide time-sensitive evidence for NHS Health A to Z, Find NHS services near you, urgent-care triage, Profile and current/change GP-surgery functions, health choices, GP records, prescriptions and pharmacy, medical and administrative requests, appointments, referrals, waiting-time information, provider documents and questionnaires, messages, personal health records, linked profiles, and digital-front-door direction. Keep the user-visible capability distinct from its source system or integration component.
  4. GP Connect Patient Facing APIs: official service and API pages define patient-facing record, prescription, and permission APIs.
  5. NHS architecture components and interfaces: PDS, PCRM, GP2GP, ODS, Spine, Spine Directory Service, Spine Secure Proxy (SSP), NHS API Platform, professional GP Connect, Interface Mechanism 1, MESH, partner onboarding, EPS, Patient Care Aggregator / Wayfinder, PEPs, and NHS Notify pages provide component-level and interface-layer architecture evidence. PCRM's stated coverage includes Defence Medical Services (DMS), but named DPHC practice and patient outcomes remain unproven.
  6. DMedC / DPHC context: MOD and GOV.UK sources establish Defence Medical Command, Defence Medical Services, Defence Global Practice, DPHC Firmbase, DPHC(O), armed-forces medical care, and Programme Cortisone / CORTISONE source variants.
  7. Armed Forces Covenant annual reports: the report series provides an official evidence strand for one direct 2024 NHS App appointment-booking access issue, Programme CORTISONE / Op CORTISONE and MOD digital-health material from 2020 onward, and wider DPHC/NHS record-transfer, health-identifier, NHS Digital data-matching, service-family mobility, DPHC(O) return, and pre-2020 Defence Medical Information Service / Programme context.
  8. Adoption evidence gaps: direct DPHC NHS App guidance, ODS/practice model, supplier assurance, exact interface route, partner-onboarding status, minors/proxy access, dependant split-registration behaviour, DPHC(O) access, Patient Care Aggregator / Wayfinder visibility for DPHC secondary-care journeys, DMICP PHC appointment visibility feed evidence, DMICP PHC appointment management write-back evidence, DPHC NHS Notify onboarding, and CORTISONE programme integration scope.
  9. Adoption and implementation phases: docs/knowledge-base/modules/nhs-app-adoption-implementation.md is the context anchor for future related passes. It frames initial provision, Secondary healthcare (SHC) appointments, DMICP PHC appointment visibility, DMICP PHC appointment management, clinical correspondence, test results, and later CORTISONE patient data through IM1 and/or GP Connect Patient Facing APIs where directly evidenced.
  10. Decision and status layer: docs/knowledge-base/modules/guidance-decision-model.md is the guidance-facing answer surface; docs/knowledge-base/modules/registration-state-model.md supplies the composable registration context, transition state, age band, access mode, and family / proxy relationship dimensions that drive those decisions.
  11. Architecture and evidence governance: docs/knowledge-base/modules/architecture-index.md defines route taxonomy and logical route diagrams; docs/evidence-work-packages.md, docs/source-freshness.md, and docs/cross-deck-evidence-carry-over.md operationalise the validation queue, time-sensitive source handling, and InterSystems cross-deck controls. Work Package 1 has dimension-level acceptance criteria for registration context, transition state, age band, access mode, family / proxy relationship, and organisation / supplier enablement.
  12. IRTB(P): docs/knowledge-base/modules/irtbp-evidence-brief.md is the human capability/options synthesis, docs/knowledge-base/modules/irtbp-construction.md defines the body and annex construction rules, and docs/llm-wiki/irtbp.md is the machine-readable build contract. R41 uses a brief Issue, direct Recommendations, Timing, supporting Background with four options, and Presentation. The proposed approval covers NHS-functions delivery and DMICP concept design; DMICP development, delivery, any pilot and GP-record integration return for approval. Programme owner and funding remain unconfirmed. The Executive Summary follows R41; initial NHS provider validation defines evidence for each provider, service, function and patient group without claiming readiness. Target no more than four body pages plus four initial annexes, verified from the Word render. The IRTB(P) must not reproduce internal wiki planning labels.

Confidence

NHS and MOD service definitions are high-confidence within their scope. DPHC-specific NHS App feature availability is not yet validated. The wiki should describe it as an evidence boundary until direct service-owner or implementation evidence is added. Do not treat dependants as a single eligibility category; analyse the dependant's own age, registration, account, and proxy / linked-profile state. Promote guidance statuses only through the Guidance Decision Model.