Architecture Index

This page defines the wiki's architecture hierarchy and the route diagrams used to interpret NHS App continuation and/or adoption evidence.

The sequence diagrams below are logical route models, not confirmed implementation traces. Arrows show the dependencies, routing questions, or evidence gates that must be resolved before a claim can be promoted. Treat an arrow as a live service call only where a source proves that exact interface and operational state.

Page Contracts

Page	Contract	Use
NHS App Service Architecture	Service model	Shows how account access, GP-linked services, and national / provider services relate from the NHS App user's perspective.
Component Architecture	Component inventory	Tracks named NHS, supplier, MOD, and CORTISONE components that may affect a feature route.
Interface and Assurance Layer	Lower implementation layer	Records interfaces, APIs, supplier routes, onboarding, assurance, and route-specific controls.
NHS App Integration Route	Implementation route catalogue	Lists the practical NHS App, GP-linked, national, provider, and candidate Defence Primary Healthcare (DPHC) integration routes.
Guidance Decision Model	Decision surface	Converts architecture and evidence into guidance-facing status by cohort, feature, route, and evidence state.

Route Taxonomy

Route family	Examples	Current DPHC interpretation
Account and identity	NHS account, NHS login, own access, linked profiles, proxy access	Public baseline is clear; DPHC Firmbase, DPHC(O), split-family, minor, and proxy behaviour need direct evidence.
GP-linked feature route	GP records, repeat prescriptions, GP permissions, GP appointment dependencies, and registered-GP transition effects	Depends on Personal Demographics Service (PDS), PCRM where registration changes, Organisation Data Service (ODS), GP clinical system, GP Connect Patient Facing APIs, Interface Mechanism 1 (IM1) where relevant, and practice enablement.
Secondary-care route	e-RS, Patient Care Aggregator / Wayfinder appointment summary, Patient Engagement Portal (PEP) appointment or booking functions, trust booking systems	Strong for NHS Secondary healthcare (SHC) routes; not proof of DPHC Primary healthcare (PHC) appointment visibility or management.
PEP appointment or booking function	Appointment detail, booking, change, cancellation, deep links	Provider / PEP appointment evidence only; not proof of documents, results, or DPHC PHC appointment management.
SHC provider document route	Appointment letters, outcome letters, discharge summaries, questionnaires, provider-held correspondence	Provider document evidence only; not proof of test-result release, PEP results-release, or GP-filed document access.
PEP document route	Portal-held letters, forms, questionnaires, discharge summaries, outcome letters, or other correspondence	PEP document evidence only; not proof of appointment functions, test-result release, or GP-filed document access.
Provider results system	Provider-held test results, source systems, and release controls	Provider results evidence only; not proof of clinical correspondence, GP-filed result access, or CORTISONE publication.
PEP results-release route	Provider-held results released through a PEP or NHS App-connected digital route	PEP results-release evidence only; not proof of clinical correspondence, GP-filed result access, or CORTISONE publication.
Direct NHS App web integration	NHS App launches a partner or provider service	Relevant only if a Defence Medical Command (DMedC) / DPHC service is onboarded and assured as an NHS App integration.
Messaging route	NHS Notify API, Message Exchange for Social Care and Health (MESH), NHS App messages, SMS, email, letter fallback	Useful for messages or reminders; not appointment inventory or booking by itself.
DPHC Firmbase reminder route	Defence Medical Information Capability Programme (DMICP) appointment event/feed, controlled adapter, identity and organisation checks, NHS Notify, initial App and SMS parallel operation, and approved exception/fallback channels	Candidate bounded route only. It does not create appointment inventory or write-back, and it does not authorise App-first delivery or routine SMS replacement.
DMICP / CORTISONE candidate route	DMICP feed, controlled adapter, Programme CORTISONE / Health Connect as one candidate, HealthShare HealthShare Unified Care Record (UCR), Enterprise Master Patient Index (EMPI)	Candidate architecture only until direct implementation evidence proves the source, component, route, and operational state.
Prescription route	GP Connect PFS prescriptions, GP prescribing workflow, Electronic Prescription Service (EPS), pharmacy services	Needs DPHC prescribing model, supplier route, EPS use, and NHS App feature evidence.

Route Sequence Diagrams

Each route diagram includes direct links to the component, interface, or synthesis pages needed to interpret it. Keep the Mermaid nodes as logical model labels; use the Markdown links for navigation so the diagram remains readable and source-controlled.

Account and GP-Linked Feature Route

Relevant pages: NHS Account and Login, Linked Profiles and Proxy Access, Personal Demographics Service, Organisation Data Service, NHS API Platform, GP Connect Patient Facing APIs, and GP Records and Patient Services.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as "Patient / proxy user"
  participant App as "NHS App"
  participant Account as "NHS account / NHS login"
  participant PDS as PDS
  participant ODS as "ODS / SDS"
  participant PFS as "GP Connect Patient Facing APIs"
  participant GP as "GP clinical system"
  Patient->>App: Sign in and request GP-linked feature
  App->>Account: Authenticate user and access context
  App->>PDS: Resolve patient and registered GP context
  App->>ODS: Resolve organisation identity and endpoint context where required
  App->>PFS: Request GP-linked feature through relevant route
  PFS->>GP: Request record, prescription, permission, or appointment data if enabled
  GP-->>PFS: Provider response if practice and capability are enabled
  PFS-->>App: Patient-facing result
  Note over PDS,GP: DPHC evidence must prove registration state, ODS identity, supplier route, and practice enablement.

Direct NHS App Web Integration Route

Relevant pages: NHS App Integration Route, Interface and Assurance Layer, and NHS Account and Login.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as Patient
  participant App as "NHS App"
  participant Login as "NHS login"
  participant Partner as "DMedC / DPHC or partner service"
  participant Onboarding as "NHS App onboarding / assurance"
  Patient->>App: Select integrated service
  App->>Login: Confirm identity and launch context
  Login-->>Partner: Pass authenticated user context where approved
  Partner-->>Onboarding: Must satisfy accessibility, usability, clinical safety, data protection, technical assurance, and information security before live use
  Partner-->>App: Return or display service journey
  Note over Partner,Onboarding: No current source proves a DMedC / DPHC direct NHS App web integration.

Secondary Healthcare Appointment Route

Relevant pages: Appointments, Referrals, and Waiting Lists, Patient Care Aggregator and PEPs, Interface and Assurance Layer, and NHS App Adoption and Implementation.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as Patient
  participant App as "NHS App"
  participant PCA as "Patient Care Aggregator / Wayfinder"
  participant ERS as "e-RS"
  participant Booking as "Secondary-care booking system"
  participant PEPAppointments as "PEP appointment or booking function"
  Patient->>App: View hospital or specialist appointments
  App->>PCA: Request referral / booking summary
  PCA->>ERS: Resolve referral context where present
  PCA->>Booking: Resolve connected provider booking data where onboarded
  PCA->>PEPAppointments: Resolve appointment detail or deep-link where provider route supports it
  PCA-->>App: Return summary list
  App-->>Patient: Display summary and deep links
  Note over PCA,PEPAppointments: Strong SHC evidence, not proof of DMICP / DPHC PHC appointment visibility.

Provider Document and PEP Document Route

Relevant pages: Patient Care Aggregator and PEPs, NHS App Adoption and Implementation, GP Records and Patient Services, and Interface and Assurance Layer.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as "Patient / proxy user"
  participant App as "NHS App"
  participant ProviderDocs as "SHC provider document route"
  participant PEPDocs as "PEP document route"
  participant Documents as "Provider document source"
  participant Controls as "Access and release controls"
  Patient->>App: Open clinical correspondence or SHC provider documents
  App->>ProviderDocs: Resolve provider document route where onboarded
  alt Direct provider document route
    ProviderDocs->>Controls: Apply authentication, age, proxy, and access rules
    Controls->>Documents: Retrieve eligible document metadata or view
    Documents-->>App: Return display or deep-link summary
  else PEP document sub-route
    ProviderDocs->>PEPDocs: Request document list or document deep link
    PEPDocs->>Controls: Apply authentication, age, proxy, and access rules
    Controls->>Documents: Retrieve eligible document metadata or view
    Documents-->>PEPDocs: Return available document route
    PEPDocs-->>App: Return display or deep-link summary
  end
  App-->>Patient: Show document route
  Note over ProviderDocs,PEPDocs: PEP is an optional sub-route. Document evidence does not prove result release or GP-filed access.

Provider Results and PEP Results-Release Route

Relevant pages: Patient Care Aggregator and PEPs, NHS App Adoption and Implementation, GP Records and Patient Services, and Interface and Assurance Layer.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as "Patient / proxy user"
  participant App as "NHS App"
  participant ProviderResults as "Provider results system"
  participant PEPResults as "PEP results-release route"
  participant Controls as "Clinical release controls"
  participant Results as "Provider results source"
  Patient->>App: Open test results route
  App->>ProviderResults: Resolve provider results system where onboarded
  alt Direct provider results route
    ProviderResults->>Controls: Apply review, timing, suppression, and override rules
    Controls->>Results: Retrieve eligible released result
    Results-->>App: Return display or deep-link summary
  else PEP results-release sub-route
    ProviderResults->>PEPResults: Request released result
    PEPResults->>Controls: Apply review, timing, suppression, and override rules
    Controls->>Results: Retrieve eligible released result
    Results-->>PEPResults: Return released result route
    PEPResults-->>App: Return display or deep-link summary
  end
  App-->>Patient: Show released result route
  Note over PEPResults,Results: PEP is an optional sub-route. Result evidence does not prove correspondence, GP-filed access, or CORTISONE publication.

DPHC Firmbase Appointment Reminder Candidate Route

Relevant pages: Messaging and Notifications, Appointments, Referrals, and Waiting Lists, NHS App Adoption and Implementation, Personal Demographics Service, Organisation Data Service, and Interface and Assurance Layer.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant DMICP as "DMICP appointment source"
  participant Adapter as "Controlled adapter"
  participant Checks as "Patient and organisation checks"
  participant Notify as "NHS Notify"
  participant App as "NHS App message"
  participant Fallback as "Approved fallback channel"
  DMICP-->>Adapter: Candidate appointment event or reminder feed
  Adapter-->>Checks: Candidate identity, ODS, timing, suppression, and template checks
  Checks-->>Notify: Candidate assured reminder submission
  alt NHS App message available
    Notify->>App: Deliver reminder
  else fallback required
    Notify->>Fallback: Deliver SMS, email, or letter
  end
  Note over DMICP,Checks: Pre-Notify route is unproven. No appointment inventory or write-back is created.

The candidate route should run alongside current DMICP SMS reminders during initial testing. App-first delivery or replacement of routine SMS for defined cohorts requires a separate decision after delivery, reconciliation, accessibility, support, safety, cost, exception and fallback evidence is available.

DMICP PHC Appointment Visibility Candidate Route

Relevant pages: NHS App Adoption and Implementation, DMedC and DPHC Context, Personal Demographics Service, Organisation Data Service, Patient Care Aggregator and PEPs, and Interface and Assurance Layer.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant DMICP as "DMICP appointment / diary source"
  participant Transform as "Controlled adapter"
  participant Identity as "PDS / ODS / EMPI mapping"
  participant Route as "NHS-facing display route"
  participant App as "NHS App or linked portal"
  DMICP-->>Transform: Candidate read-only appointment feed if documented
  Transform-->>Identity: Candidate matching of patient, organisation, status, and suppression rules
  Transform-->>Route: Candidate publication of appointment summary if route is assured
  Route-->>App: Display summary or launch portal view
  Note over DMICP,Route: CORTISONE / Health Connect is one possible adapter. No source proves the feed, adapter, or onboarding.

DMICP PHC Appointment Management Candidate Route

Relevant pages: NHS App Adoption and Implementation, Interface and Assurance Layer, GP Connect Patient Facing APIs, GP Connect Professional APIs, NHS API Platform, and Component Architecture.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as "Patient / proxy user"
  participant App as "NHS-facing route"
  participant Route as "GP Connect / IM1 / direct web route"
  participant Transform as "Controlled adapter"
  participant DMICP as "Authoritative DPHC appointment book"
  Patient->>App: Request booking / cancellation / change
  App->>Route: Submit managed appointment action
  Route->>Transform: Validate identity, permission, slot, and audit state
  Transform-->>DMICP: Candidate write-back only if supported and assured
  DMICP-->>Transform: Accept, reject, or conflict response
  Transform-->>App: Return outcome and fallback instruction
  Note over Route,DMICP: CORTISONE may be one adapter. Current public evidence makes management likely not available.

CORTISONE / InterSystems Enablement Candidate Route

Relevant pages: NHS App Adoption and Implementation, DMedC and DPHC Context, Component Architecture, Interface and Assurance Layer, Linked Profiles and Proxy Access, and Guidance Decision Model.

This diagram is warranted because the current CORTISONE / InterSystems question spans several route layers. It is a logical route model, not an implementation trace or proof of live NHS App publication.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
flowchart TD
  Boundary["Direct DPHC practice-level\nNHS App evidence boundary"] --> Candidate["CORTISONE / InterSystems\ncandidate enablement route"]
  Candidate --> Sources["Source-system coverage\nDMICP / TPP CORTISONE\nDPHC Firmbase / DPHC(O)\nNHS providers"]
  Sources --> Components["Component mapping\nHealthShare UCR / IRIS\nEMPI / Integration Platform\ncandidate"]
  Components --> Identity["Identity and organisation\nmatching\nNHS number / PDS / ODS\nSDS / EMPI"]
  Identity --> Routes["NHS-facing route selection"]
  Routes --> PFS["GP Connect Patient Facing APIs"]
  Routes --> IM1["IM1 or supplier route"]
  Routes --> Web["Direct NHS App web integration"]
  Routes --> Notify["NHS Notify messaging only"]
  Routes --> Provider["PCA / PEP\nwhere provider route\nis onboarded"]
  PFS --> Assurance["Onboarding and assurance\nclinical safety\ndata protection\ntechnical assurance\ninformation security"]
  IM1 --> Assurance
  Web --> Assurance
  Notify --> Assurance
  Provider --> Assurance
  Assurance --> Cohort["Cohort and access-mode tests\nFirmbase / DPHC(O)\nminors / dependants\nproxy / linked profiles"]
  Cohort --> Decision["Guidance decision\nRoute and cohort tests\nrequired"]

NHS Notify Message Route

Relevant pages: Messaging and Notifications, Personal Demographics Service, Interface and Assurance Layer, and Component Architecture.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Sender as "DMedC / DPHC or provider sender"
  participant Notify as "NHS Notify"
  participant PDS as "PDS contact / restricted-status checks"
  participant App as "NHS App message channel"
  participant Fallback as "SMS / email / letter fallback"
  Sender->>Notify: Submit message through API or MESH
  Notify->>PDS: Resolve contactability and restrictions
  alt NHS App message available
    Notify->>App: Deliver NHS App message
  else fallback needed
    Notify->>Fallback: Deliver fallback channel
  end
  Note over Sender,Notify: DPHC claims need sender eligibility, onboarding, templates, audit, and fallback evidence.

Prescription Route

Relevant pages: Prescriptions and Pharmacy, Electronic Prescription Service, GP Connect Patient Facing APIs, NHS API Platform, and Component Architecture.

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
sequenceDiagram
  participant Patient as "Patient / proxy user"
  participant App as "NHS App"
  participant PFSRx as "GP Connect Patient Facing Prescriptions"
  participant GP as "GP practice workflow"
  participant EPS as "Electronic Prescription Service"
  participant Pharmacy as "Pharmacy / dispensing route"
  Patient->>App: Request repeat prescription or manage prescription journey
  App->>PFSRx: Submit patient-facing prescription request where enabled
  PFSRx->>GP: Route request to GP clinical system / workflow
  GP->>EPS: Issue electronic prescription where EPS applies
  EPS->>Pharmacy: Make prescription available for dispensing
  Note over PFSRx,EPS: DPHC claims need supplier support, practice enablement, prescribing model, EPS use, and proxy limits.

Architecture Rules

Use the service model first, then component inventory, then interface / assurance checks.
Read sequence arrows as logical route dependencies unless source evidence proves a live implementation path.
Keep mobile access, standard national services, NHS-side provider routes, Firmbase reminders, PHC inventory, and PHC management as separate architecture claims.
Use controlled adapter for an architectural role. Name Programme CORTISONE / Health Connect only as a candidate until direct component mapping selects it.
Do not promote a component to an availability claim unless the route, cohort, feature, supplier/practice configuration, and operational state are evidenced.
Treat integrates with the NHS as an unresolved statement until it maps to a named route in this index.
Keep route diagrams on this index while they remain compact logical models. Split a route into its own page when it needs more than one implementation variant, more than eight participants, more than ten message arrows, or mobile rendering requires horizontal scrolling. Current mobile review keeps the routes here; DMICP appointment management is the first split candidate if new evidence adds write-back variants.
Feed route conclusions into Guidance Decision Model and evidence gaps into Evidence Work Packages.