Skip to content

Interface and Assurance Layer

This page is the layer under the NHS App Service Architecture and Component Architecture pages. It records the implementation routes, supplier interfaces, onboarding controls, and assurance checks that sit between a user-facing NHS App function and a live provider or GP-system capability.

Use Architecture Index for route taxonomy and sequence diagrams. Use this page for route inventory and assurance checks.

Interface Map

%%{init: {"themeVariables": {"fontSize": "11px"}, "flowchart": {"nodeSpacing": 18, "rankSpacing": 24}, "sequence": {"actorFontSize": 11, "messageFontSize": 11, "noteFontSize": 11}}}%%
graph TD
  App["NHS App"] --> Account["NHS account / NHS login"]
  App --> WebIntegration["Direct NHS App web integration"]
  App --> Messaging["Notifications and Messaging"]
  App --> Aggregator["Patient Care Aggregator\n/ Wayfinder"]
  App --> PFS["GP Connect Patient Facing APIs"]
  PFS --> APIPlatform["NHS API Platform"]
  APIPlatform --> PDS["PDS registered GP lookup"]
  APIPlatform --> ODS["ODS organisation\nand endpoint context"]
  ODS --> SDS["Spine Directory Service\nendpoint lookup"]
  SDS --> GPProvider["GP provider system endpoint"]
  GPProvider --> GPSystem["GP clinical system"]
  GPSystem --> IM1["Interface Mechanism 1\nsupplier interface"]
  IM1 --> GPSupplier["Principal GP system supplier"]
  Messaging --> Notify["NHS Notify"]
  Notify --> NotifyAPI["NHS Notify API / MESH"]
  Notify --> PDS
  Aggregator --> ERS["e-RS"]
  Aggregator --> GetAppointments["Get Appointments API"]
  Aggregator --> RecordService["Record Service API"]
  GetAppointments --> BookingSystem["Secondary-care booking system"]
  RecordService --> BookingSystem
  BookingSystem --> PEPAppointments["PEP appointment or\nbooking function"]
  PEPAppointments --> Account
  App --> ProviderRoutes["Provider portal / provider routes"]
  ProviderRoutes --> ProviderDocuments["SHC provider document route"]
  ProviderRoutes --> ProviderResults["Provider results system"]
  ProviderDocuments -. "optional sub-route" .-> PEPDocuments["PEP document route"]
  ProviderResults -. "optional sub-route" .-> PEPResults["PEP results-release route"]
  DMICP["DMICP appointment / diary source"] -. "event or feed evidence needed" .-> Adapter["Controlled adapter"]
  CortisoneLayer["Programme CORTISONE /\nHealth Connect candidate"] -. "possible implementation" .-> Adapter
  Adapter -. "reminder payload evidence needed" .-> ReminderRoute["Appointment reminder\nsubmission"]
  ReminderRoute -. "NHS Notify API" .-> Notify
  Adapter -. "display route evidence needed" .-> VisibilityRoute["Read-only NHS App,\nPCA / PEP, or portal visibility"]
  Adapter -. "write-back evidence needed" .-> ManagementRoute["Appointment management"]
  ManagementRoute -. "likely not available on current evidence" .-> PFS
  ManagementRoute -. "likely not available on current evidence" .-> IM1
  Adapter -. "portal route if onboarded" .-> WebIntegration
  WebIntegration --> Onboarding["Partner onboarding / assurance"]
  NotifyAPI --> Onboarding
  Aggregator --> Onboarding
  IM1 --> Onboarding
  Onboarding --> Assurance["Clinical safety\ndata protection\ntechnical assurance\ninformation security"]
  DPHC["DMedC / DPHC\nor Programme Cortisone"] -. "must map exact interface" .-> Onboarding
  DPHC -. "evidence gap" .-> GPSystem

Route Inventory

Route or interface What it supports Implementation control DPHC interpretation
Direct NHS App web integration Patient-facing services launched from the NHS App NHS login integration, NHS App integration standards, accessibility, usability, clinical safety, and data privacy requirements Relevant only if a Defence Medical Command (DMedC) / Defence Primary Healthcare (DPHC) service is intended to appear directly inside the NHS App.
Notifications and Messaging NHS App messages and notifications NHS Notify onboarding for NHS App Notifications and Messaging Relevant if DMedC / DPHC needs to send patient messages through NHS App messaging or fallback channels.
NHS Notify API / Message Exchange for Social Care and Health (MESH) Message submission to NHS Notify for NHS App, email, SMS, or letter channels NHS Notify onboarding, sender / Organisation Data Service (ODS) identity, templates and routing, Personal Demographics Service (PDS) contact-detail and restricted-record checks, API or MESH technical route, delivery receipts, fallback, and audit The reviewed national interface is the NHS Notify API; no reviewed official source names a separate national “Appointments Reminder API”. This route does not prove DMedC / DPHC sender onboarding, appointment inventory, visibility, or management.
Patient Care Aggregator / Wayfinder appointment summary Secondary-care referral and booking summaries, with deep links to e-RS or connected Patient Engagement Portal (PEP) appointment or booking functions for details and supported actions Get Appointments API, Record Service API, NHS-styled Patient Engagement Portal, NHS login, NHS App integration, sandbox/integration/end-to-end testing Strong for secondary-care journeys; not proof of Defence Medical Information Capability Programme (DMICP) / DPHC Primary healthcare (PHC) appointment visibility or management, clinical correspondence, test results, or GP-record access.
PEP appointment or booking function Provider-portal appointment detail, booking, change, cancellation, or deep-link behaviour where supported Portal owner, provider scope, authentication, NHS App deep-link rules, supported actions, clinical safety, data protection, and route-specific onboarding Appointment-function evidence does not prove Secondary healthcare (SHC) provider document routes, PEP document routes, provider results systems, PEP results-release routes, or DPHC PHC appointment management.
SHC provider document route Secondary-care provider route for appointment letters, outcome letters, discharge summaries, questionnaires, and provider-held correspondence Provider/trust scope, integrated product, document type, NHS App display or deep-link route, authentication, retention/display rules, clinical safety, data protection, and age/proxy handling Supports Phase 4 only when the SHC provider document route and patient cohort are known. It is not proof of PEP results-release, GP-record result visibility, GP-filed document visibility, or CORTISONE publication.
PEP document route Provider-held documents surfaced through a PEP or NHS App-connected portal route Portal owner, provider scope, document types, NHS App display or deep-link route, authentication, retention/display rules, clinical safety, data protection, and age/proxy handling PEP document route evidence is a sub-route of the wider SHC provider document route. It is not proof of PEP results-release, GP-record result visibility, or CORTISONE publication.
Provider results system Provider-held test-result source and release-control context Provider scope, source system, result type, release policy, clinical review process, suppression/override controls, clinical safety, authentication, patient-facing display route, age/proxy handling, and audit Supports Phase 5 only when the provider results system and release route are known. It is not proof of SHC provider document routes, PEP document routes, GP-record result visibility, appointment management, or DPHC availability.
PEP results-release route Provider-held test-result release through a PEP or NHS App-connected digital route Provider scope, PEP product, result type, release timing, suppression/override controls, clinical safety, authentication, patient-facing display route, age/proxy handling, and audit PEP results-release is a sub-route of the wider provider results system route. It is not proof of SHC provider document routes, PEP document routes, GP-record result visibility, appointment management, or DPHC availability.
GP-filed document view Documents filed into the GP record and exposed through GP health-record access GP clinical-system source, filing state, document type, PDS/ODS/supplier route, practice capability, release setting, NHS App display behaviour, and age/proxy handling Ordinary NHS GP-record evidence is a baseline; DPHC GP-system equivalence remains unproven.
GP-filed result view GP or hospital-ordered results filed into the GP record and exposed through GP health-record access Result source, GP filing state, clinical review / release control, GP clinical-system setting, PDS/ODS/supplier route, NHS App display behaviour, and age/proxy handling Ordinary NHS GP-record result evidence does not prove DPHC GP-system equivalence, PEP results-release, or CORTISONE publication.
DMICP PHC appointment reminder feed into NHS Notify One-way DPHC Firmbase appointment reminders delivered through NHS App messaging with SMS, email, or letter fallback where configured Documented DMICP appointment event/reminder feed, patient/NHS-number and organisation matching, event timing and update semantics, controlled adapter, NHS Notify sender onboarding, templates/routing, suppression/opt-out rules, fallback, delivery receipts, audit, support, and assurance Bounded candidate first DPHC-specific appointment route. Programme CORTISONE / Health Connect is one possible adapter, not the selected design. No current public source confirms the DMICP feed, adapter, DPHC NHS Notify onboarding, or live delivery. It does not require PEP/PCA merely to send a reminder and does not prove appointment visibility or management.
DMICP PHC appointment visibility feed through a controlled adapter DPHC primary-care appointment / diary source extraction, transformation, and possible NHS App-visible read-only appointment publication Documented DMICP API/feed, patient and appointment identifiers, appointment-status model, PDS / ODS / Spine Directory Service (SDS) mapping, adapter component mapping, named display-route selection, onboarding, and assurance Candidate implementation route only. Programme CORTISONE / Health Connect is one possible adapter, but no current public source confirms the DMICP appointment feed, Health Connect appointment transform, or NHS App publication. PCA/PEP use would additionally require NHS England acceptance of the DPHC PHC source and route.
DMICP PHC appointment management interface Booking, cancellation, rescheduling, slot search, appointment-change requests, and write-back to the DPHC appointment book Bidirectional DMICP / CORTISONE interface, writable slot/schedule state, conflict handling, patient/proxy permissions, audit, FHIR / Interface Mechanism 1 (IM1) / web-integration route selection, supplier/practice enablement, onboarding, and assurance Likely not available at this stage on current public evidence. Treat as a recognised target and evidence gap, not a supported route.
GP Connect Patient Facing APIs GP record, repeat-prescription, and user-permission functions for patient-facing services NHS API Platform route, PDS registered-GP lookup, ODS / Spine Directory Service endpoint lookup, provider system processing, supplier/practice enablement Most relevant to NHS App GP-linked features. ODS and DGP evidence now provide registration / organisation context only; they do not change the route assumption or prove DPHC Firmbase or DPHC(O) practice enablement, supplier support, or feature availability.
GP Connect professional APIs Professional direct-care and provider/consumer routes Spine Secure Proxy (SSP), MESH, or API Platform patterns depending on product Do not use professional API availability as proof of patient-facing NHS App availability.
Interface Mechanism 1 Supplier-specific interface into principal GP clinical systems Supplier pairing, Pairing and Integration Pack, Service Conformance Assessment List (SCAL), Model Interface Licence (MIL), test and assurance stages Relevant to GP supplier integration and some patient-facing GP-system functions. Defence Medical Services (DMS) / DGP registration context and ODS candidate records do not prove supplier pairing, PIP / SCAL / MIL status, patient-facing IM1 scope, or NHS App availability.
Interface Mechanism 1 PFS Auth In-development authentication route for IM1 sessions to Patient-Facing APIs API catalogue status and onboarding/assurance Treat as time-sensitive and not proof of current DPHC availability.
Partner onboarding Route for NHS England API/service assurance Clinical safety, data protection, technical assurance, information security, connection agreements, service-specific questions Any DMedC / DPHC route must identify the exact service and onboarding/assurance path.

Assurance Checklist

Use this checklist before treating any route as available for DPHC patients.

Route Minimum assurance evidence Current DPHC / DMICP boundary
NHS App direct web integration NHS login integration pattern, user journey, accessibility, usability, clinical safety, data protection, information security, support model, and NHS App onboarding. No current source shows DMedC / DPHC or CORTISONE has a direct NHS App web integration for PHC appointments or patient data.
NHS Notify Sender eligibility, NHS Notify onboarding, message templates, channel fallback, PDS contact handling, restricted-record handling, audit, and failure handling. Useful for reminders or status messages only; it cannot prove appointment inventory, visibility feed, booking, cancellation, or rescheduling.
Patient Care Aggregator / Wayfinder appointment summary Secondary-care provider onboarding, Get Appointments API, Record Service API, PEP/deep-link behaviour, NHS login, end-to-end testing, and age/coverage constraints. Strong secondary-care evidence; not proof of DPHC PHC appointment visibility or management.
PEP appointment or booking function Portal owner, provider scope, NHS App connection state, authentication, deep-link rules, supported appointment actions, clinical safety, and data protection. Appointment-function evidence is not document-route or results-release evidence. A DPHC PHC portal route would need direct onboarding evidence.
SHC provider document route Provider/trust scope, integrated product, document types, NHS App display/deep-link route, access controls, age/proxy behaviour, clinical safety, and data protection. Provider-document evidence must identify the SHC provider document route and must not be generalised to results-release or GP-record access.
PEP document route Portal owner, provider scope, document types, NHS App display/deep-link route, access controls, age/proxy behaviour, clinical safety, and data protection. Generic PEP evidence is not enough; document-route evidence must identify both the document function and the wider SHC provider document route where applicable.
Provider results system Provider/trust scope, source system, result types, release policy, clinical review / override controls, suppression rules, patient-facing route, age/proxy behaviour, audit, and clinical safety. Provider results evidence is not SHC provider document evidence, PEP document evidence, or GP-record result evidence.
PEP results-release route Portal owner, provider scope, result types, release timing, clinical review / override controls, suppression rules, patient-facing route, age/proxy behaviour, audit, and clinical safety. Results-release evidence must identify the PEP sub-route and the provider results system; it is not GP-record result evidence and not provider-document evidence.
GP-filed document view GP clinical-system supplier, PDS/ODS state, document filing state, release setting, practice capability, NHS App display behaviour, age/proxy controls, and audit. Ordinary NHS GP-record document evidence is not DPHC feature availability without DPHC supplier/practice evidence.
GP-filed result view GP clinical-system supplier, result filing state, clinical review / release controls, PDS/ODS state, practice capability, NHS App display behaviour, age/proxy controls, and audit. Ordinary NHS GP-record result evidence is not DPHC feature availability without DPHC supplier/practice evidence.
GP Connect Appointment Management / patient-facing appointment route Registered-GP assumptions, FHIR or catalogue route, supplier support, practice enablement, NHS login level, slot/search/book/cancel scope, conformance, and audit. Relevant to possible management only if DPHC/CORTISONE can act in the required provider role and write back safely.
Interface Mechanism 1 / IM1 Pairing Supplier interface, Pairing and Integration Pack, SCAL, Model Interface Licence, test/assurance status, live rollout, and patient-facing function scope. Official IM1 evidence does not show DMICP capability, DPHC supplier use, or CORTISONE appointment write-back.
Controlled adapter, including a possible CORTISONE / Health Connect implementation Confirmed component role, source and target systems, transformation logic, identity matching, audit/provenance, operational support, and NHS-facing interface route. CORTISONE / InterSystems evidence supports an IP / Enterprise Master Patient Index (EMPI) and HealthShare / IRIS licence-package boundary and GP Connect supplier-progress touchpoints, but does not select Health Connect as the adapter, confirm any DMICP appointment feed, or prove NHS App publication.
DMICP reminder feed Source event/feed contract, update and cancellation semantics, patient/NHS-number and organisation matching, template/payload mapping, suppression and opt-out rules, NHS Notify sender/onboarding evidence, parallel App/SMS operation, fallback channels, delivery receipts, reconciliation, channel-transition measures, audit, support, and clinical safety. This is a candidate architecture, not a proven live route. NHS Notify delivery evidence cannot substitute for the missing DMICP source feed, controlled adapter, DPHC sender onboarding, or evidence and approval needed before App-first delivery or routine SMS replacement.
DMICP visibility feed Source data contract, appointment identifier, status mapping, patient matching, organisation identity, suppression rules, update semantics, audit, and display route. Open sources do not expose DMICP appointment feed capability; adaptation/evolution remains unknown.
DMICP management interface Bidirectional write API, slot/schedule model, conflict handling, write-back, cancellation/rescheduling rules, permissions, audit, clinical safety, and fallback. Likely not available at this stage on current public evidence; do not infer from visibility, Notify, PEP, PCA, GP Connect, or IM1 evidence alone.

DPHC Analysis Rules

  • Map every claimed DMedC / DPHC integration to a named route: NHS App web integration, NHS Notify, Patient Care Aggregator / Wayfinder, PEP appointment or booking function, SHC provider document route, PEP document route, provider results system, PEP results-release route, GP Connect Patient Facing APIs, GP Connect professional APIs, Interface Mechanism 1, Electronic Prescription Service (EPS), e-RS, PDS, ODS, Spine Directory Service, Spine Secure Proxy, MESH, or another named API.
  • Keep Primary Care Registration Management (PCRM) registration completion, PDS registered-GP state, and GP2GP record transfer separate. PCRM's stated DMS coverage proves national registration-service scope, not a named DPHC practice configuration, completed transfer, or NHS App feature outcome.
  • Keep GP Connect Patient Facing APIs separate from Interface Mechanism 1. Both can relate to GP-system supplier capability, but they are different evidence routes and assurance models.
  • Keep Patient Care Aggregator / Wayfinder separate from DMICP / DPHC PHC appointment visibility and management. It is strongest for secondary-care referral and booking summaries and deep links; documents and questionnaires need separate SHC provider document route and PEP document route evidence.
  • Keep PEP appointment or booking functions, PEP document routes, and PEP results-release routes separate. A PEP source must identify the function it supports before it can be used for Phase 1, Phase 4, or Phase 5.
  • Keep GP-filed document views separate from GP-filed result views. Both can sit under GP health-record access, but they have different filing-state and release-control evidence gates.
  • Keep NHS Notify separate from NHS App messaging. NHS App messaging is one channel; NHS Notify is the message-sending service and onboarding route.
  • Keep DMICP PHC appointment reminders separate from appointment inventory and visibility. A reminder route needs a DMICP event/feed plus NHS Notify onboarding, templates, initial parallel App/SMS operation, fallback, delivery receipts, reconciliation, channel-transition measures, and audit; it does not require PEP/PCA merely to deliver the reminder. Do not treat successful App delivery as authority to withdraw routine SMS.
  • Use ODS, DMS registration, and Defence Global Practice evidence as identity and registration context only. Do not use high-level MOD / DMS ODS identifiers, DGP-postcode candidate records, or ODS name-search non-findings as a substitute for PDS registered-GP state, practice-level ODS role, supplier/practice enablement, GP Connect / IM1 onboarding, proxy setup, or feature tests.
  • Where direct DPHC practice-level evidence is unavailable, do not infer feature availability from the absence. Keep the registration gap as a boundary and test any CORTISONE / InterSystems route through component role, source-system coverage, NHS-facing route, assurance, and cohort feature tests.
  • For DMICP PHC appointment visibility claims, require both sides of the route: a DMICP appointment / diary feed contract and an NHS-facing display route. NHS Notify can support messages, and PEP/PCA can support secondary-care routes, but neither is sufficient proof of PHC visibility by itself. A PCA/PEP PHC route additionally needs explicit NHS England acceptance and onboarding evidence.
  • For DMICP PHC appointment management claims, require more than the visibility feed: a bidirectional appointment-management interface, write-back, slot/schedule state, conflict handling, permissions, audit, supplier/practice enablement, and completed NHS-facing route assurance.
  • Do not treat "integrates with the NHS" as enough evidence for NHS App feature availability. The claim must identify the exact interface, patient cohort, feature, supplier/practice configuration, and operational state.