Skip to content

NHS App Service Architecture

This page gives the NHS App Service section a service-layer architecture view. It sits between the NHS App Service Overview and the component-level Component Architecture page: the first frames the service groups, this page shows how those groups relate, and the component page tracks named national services and technical dependencies. Use Interface and Assurance Layer for the lower implementation layer: supplier interfaces, onboarding, testing, assurance, and route-specific controls.

Use Architecture Index for the full architecture reading order and route-specific sequence diagrams.

Service-Layer View

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
  User["Patient, dependant, or proxy user"] --> Account["NHS account / NHS login"]
  Account --> AccessGate["Mobile access and cohort eligibility gate"]
  AccessGate --> App["NHS App"]
  App --> Identity["Account and identity services"]
  App --> Core["Core national services"]
  App --> Registration["Registration transition"]
  App --> GPLinked["GP-linked NHS App services"]
  App --> National["National or provider services"]
  Identity --> OwnAccess["Own access"]
  Identity --> LinkedProfiles["Linked profiles / proxy access"]
  Core --> Advice["Health A to Z\nand Find services"]
  Core --> Urgent["NHS 111 online"]
  Core --> Choices["Organ donation / data choice\nresearch / vaccination"]
  Registration --> ChangeGP["View / change GP surgery"]
  GPLinked --> Records["GP records and patient services"]
  GPLinked --> Prescriptions["Repeat prescriptions"]
  GPLinked --> GPAppointments["GP appointments and permissions"]
  Records --> GPDocs["GP-filed document view"]
  Records --> GPResults["GP-filed result view"]
  National --> Messaging["Messages and notifications"]
  National --> Referrals["SHC appointments, referrals,\nand waiting-list information"]
  National --> ProviderDocuments["SHC provider document route"]
  National --> ProviderResults["Provider results system"]
  National --> Pharmacy["Prescription status\nand pharmacy services"]
  Referrals --> PCA["Patient Care Aggregator\n/ Wayfinder"]
  Referrals --> ERS["e-RS"]
  PCA --> PEPAppointments["PEP appointment or\nbooking function"]
  ProviderDocuments -. "optional sub-route" .-> PEPDocuments["PEP document route"]
  ProviderResults -. "optional sub-route" .-> PEPResultRelease["PEP results-release route"]

The key split is between the user's NHS App account experience, core national services, GP-linked services, and national or provider services. Eligibility, minors, dependants, and linked profiles sit first in the account and identity layer because they determine whether a user is acting for themselves or through a proxy / linked-profile route. Use Core National Services and Roadmap for the public web, authenticated web, national API, and strategic detail.

DMedC / DPHC Registration Lens

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
  Patient["DMedC / DPHC-registered patient"] --> Account["NHS account / NHS login"]
  Account --> AccessGate["DPHC mobile access and<br/>cohort eligibility gate"]
  AccessGate --> App["NHS App"]
  App --> Identity["Account and identity services"]
  App --> Core["Core national services"]
  App --> Registration["Registration transition"]
  App --> GPLinked["GP-linked services"]
  App --> National["National / provider services"]
  Identity --> MinorRules["Minor age bands"]
  Identity --> ProxyRules["Proxy / linked-profile rules"]
  Core --> PublicWeb["Public web\nHealth A to Z / Find services"]
  Core --> AuthWeb["Authenticated web\n111 / research / vaccines"]
  Core --> NationalAPI["National API\norgan donation / choices"]
  Registration --> PCRM["PCRM registration"]
  PCRM --> PDS
  GPLinked --> PDS["Personal Demographics Service"]
  GPLinked --> ODS["Organisation Data Service"]
  GPLinked --> PFS["GP Connect Patient Facing APIs"]
  PFS --> GPSystem["GP clinical system"]
  GPSystem --> IM1["Interface Mechanism 1\nsupplier interface"]
  National --> Notify["NHS Notify"]
  National --> Aggregator["Patient Care Aggregator\n/ Wayfinder"]
  National --> ProviderDocuments["SHC provider document route"]
  National --> ProviderResults["Provider results system"]
  ProviderDocuments -. "optional PEP sub-route" .-> PEPDocuments["PEP document route"]
  ProviderResults -. "optional PEP sub-route" .-> PEPResults["PEP results-release route"]
  National --> EPS["Electronic Prescription Service"]
  Aggregator --> ERS["e-RS"]
  Aggregator --> PEPAppointments["PEP appointment or\nbooking function"]
  GPLinked --> GPDocs["GP-filed document view"]
  GPLinked --> GPResults["GP-filed result view"]
  DPHCSystem["DPHC practice / MOD system"] -. "evidence gap" .-> GPSystem
  DPHCSource["DMICP appointment event<br/>or feed"] -. "candidate" .-> Adapter["Controlled adapter"]
  Adapter -. "candidate" .-> Notify
  Cortisone["Programme Cortisone"] -. "candidate adapter or data route" .-> Adapter
  Cortisone -. "integration scope unresolved" .-> GPLinked

For DPHC Firmbase, DPHC Overseas [DPHC(O)], dependants, minors, and proxy users, the practical question is not whether the NHS App exists. It is whether the relevant access route and service dependency treat the Defence Primary Healthcare (DPHC) registration context in the same way as an ordinary NHS GP registration context.

Supporting Interface Layer

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
  App["NHS App service surface"] --> Web["Direct web integration"]
  App --> NotifyRoute["Notifications and Messaging"]
  App --> PCA["Patient Care Aggregator\n/ Wayfinder"]
  App --> PFS["GP Connect Patient Facing APIs"]
  Web --> AppStandards["NHS App integration standards"]
  NotifyRoute --> Notify["NHS Notify"]
  Notify --> NotifyAPI["NHS Notify API / MESH"]
  Notify --> PDS["PDS contact and\nrestricted-status checks"]
  PCA --> ERS["e-RS"]
  PCA --> BookingAPI["Get Appointments API"]
  PCA --> RecordAPI["Record Service API"]
  BookingAPI --> PEPAppointments["PEP appointment or\nbooking function"]
  RecordAPI --> PEPAppointments
  App --> ProviderRoutes["Provider portal routes"]
  ProviderRoutes --> ProviderDocuments["Direct provider document route"]
  ProviderRoutes --> ProviderResults["Direct provider results route"]
  ProviderDocuments -. "optional PEP sub-route" .-> PEPDocuments["PEP document route"]
  ProviderResults -. "optional PEP sub-route" .-> PEPResults["PEP results-release route"]
  PFS --> APIPlatform["NHS API Platform"]
  APIPlatform --> PDSGP["PDS registered GP lookup"]
  APIPlatform --> ODS["ODS organisation lookup"]
  ODS --> SDS["Spine Directory Service\nendpoint lookup"]
  SDS --> GPSystem["GP clinical system"]
  GPSystem --> IM1["Interface Mechanism 1 pairing"]
  AppStandards --> Onboarding["Partner onboarding / assurance"]
  NotifyAPI --> Onboarding
  PCA --> Onboarding
  IM1 --> Onboarding
  DPHC["DMedC / DPHC route"] -. "must identify exact interface" .-> Onboarding

This lower layer determines whether a service route is only a public NHS capability, a supplier-specific GP-system interface, an NHS App partner integration, or a live assured service. For DPHC analysis, the exact route matters as much as the visible NHS App feature.

Interpretation Rules

Service route What to test Why it matters for DPHC
Account, access, and identity DPHC mobile access enablement, cohort, age band, identity proofing, own access, linked profiles, proxy access, and same-practice assumptions Determines whether the user can reach the mobile App, sign in, act for themselves, or act for someone else.
Core national services Public or authenticated web route, national API, NHS login hand-off, age/proxy rules, eligibility, NHS number or source-of-record dependency, accessibility, support, and fallback May deliver urgent advice, trusted information, service finding, health choices, research, prevention, or vaccination value without a DPHC GP-system integration. Each service still needs its own entitlement and task test.
Registration transition Practice application and acceptance, Primary Care Registration Management (PCRM) completion or exception, before/after Personal Demographics Service (PDS) registered-GP state, GP2GP or other record transfer, proxy exclusion, continuity, and post-change feature tests PCRM's stated scope includes Defence Medical Services (DMS), but service coverage does not prove a named DPHC practice configuration, successful transition, record transfer, or mobile NHS App access.
GP-linked services Registered GP context, GP clinical system, Personal Demographics Service data, Organisation Data Service (ODS) identity, Spine Directory Service (SDS) endpoint lookup, GP Connect Patient Facing APIs, Interface Mechanism 1 (IM1), supplier pairing, practice enablement, GP-filed document views, and GP-filed result views Most likely to determine records, repeat prescriptions, GP appointments, and GP-facing patient services. Documents and results still need separate filing-state and release-control evidence.
National or provider services NHS Notify, Patient Care Aggregator / Wayfinder, e-RS, Patient Engagement Portal (PEP) appointment or booking functions, PEP document routes, PEP results-release routes, Electronic Prescription Service (EPS), provider systems, NHS App integration, and partner onboarding May work independently of the DPHC GP system, or may depend on separate national / provider onboarding evidence. PEP appointment, document, and results functions must not be collapsed into one provider-portal claim.

Treat generic statements that a MOD or DPHC service "integrates with the NHS" as unresolved until they can be mapped to a specific NHS App route, NHS account route, GP-linked route, or national / provider route.