Evidence Work Packages
This page turns the Evidence Validation Queue into prioritised work packages. Each package is tied to the decision it would unlock in the Guidance Decision Model.
The current packages pass the stop/go check because each one reduces repeated traversal across the queue, matrix, and synthesis pages and names a decision it would unlock. Do not split a package into a separate evidence request pack unless a live assurance, delivery, research, procurement, or implementation claim needs a concrete request artefact. Otherwise, keep the gap as a queue item or acceptance criterion here.
Work Package Table
| Priority | Work package | Objective | Source targets | Pages affected | Decision unlocked | Status |
|---|---|---|---|---|---|---|
| 1 | Mobile access, cohorts, and service baseline | Establish the controlled UK-wide mobile-access route through NHS England, then test core national services independently for DPHC Firmbase, DPHC(O), dependants, minors, proxy users, linked profiles, split registrations, and transition states. Keep GP-linked registration and supplier evidence as cross-cutting criteria rather than a reason to delay lower-dependency services. | NHS and Defence Medical Command (DMedC) access-route agreement, NHS App account and technical guidance, core national service rules, cohort/access-mode tests, Primary Care Registration Management (PCRM) / Personal Demographics Service (PDS) / GP2GP / Organisation Data Service (ODS) evidence where a service depends on them, GP-practice setup, supplier configuration, or an explicit boundary where direct evidence is unavailable. | Registration State Model, Guidance Decision Model, Primary Care Registration Management, Core National Services and Roadmap, Eligibility and Registration, Linked Profiles and Proxy Access. | Whether mobile access and each core national or GP-linked service can move from Not currently available / Not evidenced to Conditional or Available for each cohort. |
Needed |
| 2 | Appointment communications and route separation | Use the validated, scoped DMSR finding as supporting rationale, then keep relevant appointment information from participating NHS providers in England, Defence Medical Information Capability Programme (DMICP) Primary healthcare (PHC) reminders, DMICP PHC visibility, and DMICP PHC management separate. Introduce App reminders alongside current SMS and treat any later channel replacement as a separate service decision. | Current NHS App Secondary healthcare (SHC) route evidence, participating England-provider evidence, Patient Care Aggregator / Wayfinder, Patient Engagement Portal (PEP) appointment or booking functions, DMICP appointment event/feed evidence, current SMS workflow, NHS Notify API and onboarding, parallel-run and channel-transition measures, GP Connect Appointment Management, Interface Mechanism 1 (IM1), NHS App integration, and Defence Primary Healthcare (DPHC) onboarding. | NHS App Adoption and Implementation, Appointments, Referrals, and Waiting Lists, Messaging, Notifications, and NHS Notify, Architecture Index, Interface and Assurance Layer. | Whether England-provider appointments are conditional for DPHC cohorts, a bounded DMICP PHC reminder route is implementable alongside SMS, evidence supports a later App-first or routine-SMS replacement decision, read-only visibility has an accepted NHS-facing route, and management remains Likely not available. |
Needed |
| 3 | Document and result route separation | Keep clinical correspondence and test results separate, and validate each document or result route on its own evidence. | NHS App SHC provider document route evidence, PEP document route evidence, GP-filed document views, GP-filed result views, provider results systems, PEP results-release route evidence, and clinical release controls. | NHS App Adoption and Implementation, Guidance Decision Model, GP Records and Patient Services, Patient Care Aggregator and PEPs. | Whether clinical correspondence and test results can be treated as conditional routes for a named DPHC cohort and source route. | Needed |
| 4 | CORTISONE / InterSystems integration | Validate whether Programme CORTISONE can enable NHS App adoption where direct DPHC practice-level evidence is unavailable: GP-provider source, shared-record source, integration layer, professional-only route, or patient-facing data route. | MOD CORTISONE architecture, InterSystems primary/vendor sources, carried-over sibling primary source IDs, HealthShare HealthShare Unified Care Record (UCR), Health Connect / Integration Platform, IRIS for Health, Enterprise Master Patient Index (EMPI), IM1, GP Connect PFS, NHS API Platform, partner onboarding. | Cross-Deck Evidence Carry-Over, DMedC and DPHC Context, NHS App Adoption and Implementation, Guidance Decision Model. | Whether CORTISONE patient data remains Not evidenced or can become a conditional patient-facing route. |
Needed |
| 5 | Assurance and onboarding | Identify clinical safety, data protection, technical assurance, information security, connection agreement, supplier pairing, practice enablement, fallback, and exclusion evidence for each proposed route. | NHS England partner onboarding, API onboarding records, IM1 pairing / PIP / Service Conformance Assessment List (SCAL) / Model Interface Licence (MIL) evidence, supplier documentation, DPHC service-management evidence. | Interface and Assurance Layer, Architecture Index, Evidence Matrix, Guidance Decision Model. | Whether a documented route is merely plausible or guidance-ready for a specific cohort and feature. | Needed |
| 6 | Source freshness and roadmap recheck | Keep time-sensitive NHS App, NHS login, NHS API, roadmap, live-partner, MOD programme, and vendor evidence current. | Current NHS England Digital pages, NHS public pages, API catalogue, standards directory, GOV.UK annual-report collection, MOD programme pages, supplier/vendor pages. | Source Freshness, Source Register, Evidence Matrix, all affected synthesis pages. | Whether previously high-confidence source readings remain safe to use in guidance or implementation decisions. | Needed |
Work Package 1 Acceptance Criteria
Work Package 1 can close only when each registration and access dimension has direct evidence, an explicit boundary, and an updated decision outcome. Partial evidence can update individual rows in the Guidance Decision Model, but it should not close the package.
| Dimension | Acceptance criterion | Evidence required | Decision effect |
|---|---|---|---|
| Registration context | Each relevant person is classified as ordinary NHS GP, DPHC Firmbase, DPHC(O) / Defence Global Practice, or unknown, with split family/proxy relationships captured under the family / proxy dimension. | DMedC / DPHC registration model, Defence Medical Services (DMS) / DPHC registration semantics, PCRM registration outcome, PDS registered-GP state, ODS identity, GP-practice status, and NHS App / NHS account interpretation. | Determines whether initial provision stays Not currently available / Not evidenced, becomes Conditional, or can move to Available for a named cohort. |
| Transition state | Continuation and restoration are tested separately for transition into DPHC, transition out of DPHC, overseas posting, and return from DPHC(O). | PCRM completion or exception state, before/after PDS evidence, GP2GP or other medical-record transfer outcome, NHS App feature continuity tests, and user-account behaviour. | Prevents steady-state availability from being inferred from transition evidence, or vice versa. |
| Age band | Under-13, 13-to-15, 16+, and adult handling is evidenced for each relevant DPHC registration context. | Public NHS age rules, DPHC GP-practice setup process, capacity / consent / safeguarding checks, and age-milestone review evidence. | Splits own access, child proxy, young-person own access, and adult/proxy transition decisions. |
| Access mode | Own access, parent / guardian proxy, adult proxy, linked profile, and informal account sharing are classified separately. | NHS account state, proxy setup evidence, permitted-service configuration, audit/withdrawal evidence, and invalid-sharing boundary. | Prevents proxy evidence from being treated as own-access evidence, and prevents informal sharing from being treated as an acceptable route. |
| Family / proxy relationship | Same-practice, split ordinary NHS GP / DPHC practice, dependant ordinary NHS GP registration, dependant DPHC registration, and carer/proxy relationships are tested separately. | GP-practice relationship evidence for both parties, same-practice rule interpretation, dependant's own registration, and linked-profile setup tests. | Determines whether dependant or family access is ordinary, conditional, not evidenced, or blocked by split-registration assumptions. |
| Core, profile, and national service entitlement | Public web, authenticated web, link-out, profile, connected national, and national API services are tested independently after mobile account enablement and are not made dependent on a GP-system route unless the official architecture requires it. | Account and identity outcome, exact user-visible capability, integration style, field/data source, age/proxy rule, eligibility, NHS-number or other data dependency, registration-transition effect, location permission, accessibility, fallback, support, and task-completion result for each cohort. | Determines whether NHS Health A to Z, Find NHS services near you, NHS 111 online, NHS number/profile basics, view/change GP surgery, organ donation, National Data Opt-Out, research, vaccination, health-check, or messaging functions can be guidance-ready independently of GP-linked services. |
| Organisation and supplier enablement | The registration dimensions are mapped to PCRM, PDS, ODS role semantics, GP clinical system, supplier, GP Connect PFS, IM1, and local practice capability where a GP-linked feature depends on them. | Named-practice PCRM / NHAIS GP Links state, PDS registered-GP state, practice-level ODS code and role, supplier configuration, GP Connect / IM1 enablement, practice capability settings, proxy setup, and feature test results. | Prevents national PCRM DMS coverage, account eligibility, high-level MOD / DMS ODS identifiers, DGP guide postcode evidence, or ODS name-search non-findings from being overread as GP-linked feature availability. |
For each accepted criterion, update Registration State Model, Eligibility and Registration, Linked Profiles and Proxy Access, Guidance Decision Model, Evidence Matrix, and Evidence Validation Queue together.
Current public evidence partially satisfies the context and infrastructure sides: it supports DMS / DPHC and DPHC(O) registration framing, and official PCRM material includes DMS in the registration service's stated scope. It does not provide named-practice PCRM configuration, post-transition PDS state, GP2GP outcome, ODS role, supplier, GP Connect / IM1, proxy, or feature-test evidence needed to close the package (SRC-025, SRC-087, SRC-091, SRC-122 to SRC-124). If direct DPHC practice-level evidence is unavailable, do not keep deepening this package; keep the boundary explicit and use Work Package 4 to test whether CORTISONE / InterSystems supplies a separate implementation route.
Work Package 2 Acceptance Criteria
Work Package 2 contains current delivery gates and later funded discovery. It can close only when each route has its own evidence outcome; one route must not wait for or be used to prove another.
Current delivery gates: preserve the validated DMSR finding's reviewed-case scope, test relevant appointment journeys through participating NHS providers in England, define the DMICP event/feed, and establish NHS Notify onboarding, initial parallel App/SMS operation, fallback, support, reconciliation, and reminder assurance.
Later funded discovery: investigate PHC appointment inventory/visibility, appointment management/write-back, and any Programme CORTISONE-enabled route.
| Queue item / route family | Acceptance criterion | Evidence required | Decision unlocked |
|---|---|---|---|
| Patient Care Aggregator / Wayfinder | SHC appointment visibility is tested as an England-provider appointment route relevant to the patient's care, not as DPHC PHC appointment proof. | Patient Care Aggregator / Wayfinder source, e-RS or secondary-care booking-system relationship, onboarded England-provider evidence, NHS App display behaviour, age/proxy handling, and DPHC registration effect. | Whether relevant England-provider appointment visibility can be marked Conditional or remains Not evidenced for each DPHC cohort. |
| PEP appointment or booking function | PEP appointment detail, booking, change, cancellation, and deep-link behaviour are separated from PEP document and results-release evidence. | Provider, PEP product, appointment action, authentication route, NHS App connection, supported cohort, age/proxy behaviour, and provider onboarding. | Whether a named PEP appointment or booking function supports SHC appointment management or only appointment visibility / deep link. |
| DMICP PHC appointment reminder | A one-way reminder route is evidenced separately from appointment inventory, visibility, and management. App delivery begins alongside current SMS; App-first delivery or routine SMS replacement for defined cohorts is a later decision. | DMICP appointment event/reminder feed, event timing and update semantics, patient/NHS-number and organisation matching, controlled adapter, NHS Notify sender onboarding, template/routing configuration, PDS contactability, suppression and opt-out rules, fallback channels, delivery receipts, parallel-run reconciliation, channel-performance and cost measures, exception cohorts, approval threshold, audit, support, and clinical safety. | Whether the bounded first DPHC-specific appointment outcome can move from Not evidenced to a named Conditional parallel implementation route, and whether later evidence supports a separate App-first or routine-SMS replacement decision. |
| DMICP PHC appointment visibility | A read-only DMICP PHC appointment route is evidenced separately from SHC appointments, reminder delivery, and management. | DMICP appointment / diary inventory feed, patient and organisation matching, controlled adapter, suppression rules, audit, and a named NHS-facing display route. PCA/PEP use requires explicit NHS England acceptance of the DPHC PHC source and route. | Whether the visibility outcome can move from Not evidenced to a named Conditional candidate route. |
| DMICP PHC appointment management | Bidirectional appointment management is evidenced separately from visibility. | Booking, cancellation, rescheduling, slot search, change request, conflict handling, patient/proxy permissions, write-back, audit, supplier/practice enablement, and NHS-facing route assurance. | Whether Phase 3 remains Likely not available or can move to a named Conditional route. |
| NHS Notify appointment delivery | The reviewed national interface is named as NHS Notify API, and its delivery function is not described as an appointment inventory or management API. Successful App delivery does not by itself authorise routine SMS withdrawal. | Sender eligibility and ODS identity, onboarding, API/Message Exchange for Social Care and Health (MESH) route, template, PDS contactability, restricted-status handling, suppression/opt-out rules, fallback-channel behaviour, delivery receipts, parallel reconciliation, failure handling, transition measures, approval, audit, support, and funding. | Whether NHS Notify can deliver a DMICP-derived reminder alongside SMS without implying PEP/PCA visibility, booking, management, or authority to replace the established reminder channel. |
For each accepted route family, update NHS App Adoption and Implementation, Appointments, Referrals, and Waiting Lists, Guidance Decision Model, Architecture Index, Evidence Matrix, and Evidence Validation Queue together.
Work Package 3 Acceptance Criteria
Work Package 3 can close only when clinical correspondence and test results have been validated as separate route families. A source can support one route without supporting the other. Partial evidence should update the relevant row in Guidance Decision Model, but should not close the package unless every route family has an explicit decision or boundary.
| Route family | Acceptance criterion | Evidence required | Decision effect |
|---|---|---|---|
| SHC provider document route | Appointment letters, outcome letters, discharge summaries, questionnaires, and provider-held correspondence are classified as clinical correspondence, not as test results. | SHC provider document route, Patient Care Aggregator / Wayfinder relationship if any, PEP document route if any, NHS App display or deep-link behaviour, age/proxy handling, and DPHC registration effect. | Allows a clinical-correspondence decision to move from generic Conditional to a named SHC provider document route condition. |
| PEP document route | A PEP document route is separated from PEP appointment or booking functions and PEP results-release routes. | Portal supplier or trust source, document type, authentication route, NHS App deep-link or embedded display behaviour, document availability rules, and patient cohort restrictions. | Prevents general PEP evidence from being overread as results-release, appointment booking, or GP-record access. |
| GP-filed document view | Documents filed into a GP record are separated from provider-held documents and from GP-filed result views. | GP clinical-system source, filing state, release settings, NHS App GP health-record display behaviour, PDS/ODS/supplier state, and DPHC practice equivalence evidence. | Determines whether the correspondence decision depends on ordinary NHS GP evidence or unresolved DPHC GP-system evidence. |
| GP-filed result view | GP and hospital-ordered results visible through a GP record are classified as test results, not as correspondence. | Result source, GP filing state, clinical review / release control, GP clinical-system setting, NHS App GP-record display behaviour, and DPHC practice equivalence evidence. | Allows a test-result decision to be tied to GP-record release controls rather than to generic document evidence. |
| PEP results-release route | Provider-held results released through a PEP are separated from SHC provider document routes, PEP document routes, and GP-record result views. | Results-release guidance, provider / PEP source, provider results system where identified, release timing and clinical-control evidence, NHS App or PEP access route, age/proxy handling, and DPHC registration effect. | Allows a test-result decision to become route-specific without implying GP-record availability or CORTISONE publication. |
| CORTISONE-held patient data | Any later result or document data held by CORTISONE is kept as a separate patient-data route until NHS App exposure is evidenced. | CORTISONE source role, HealthShare / Health Connect / EMPI mapping, IM1 or GP Connect PFS route, NHS onboarding / assurance, patient-facing publication evidence, and cohort tests. | Keeps Phase 6 CORTISONE patient data from proving Phase 4 correspondence or Phase 5 test-result availability. |
For each accepted route family, update NHS App Adoption and Implementation, Guidance Decision Model, Patient Care Aggregator and PEPs, GP Records and Patient Services, Evidence Matrix, and Evidence Validation Queue together.
Work Package 4 Acceptance Criteria
Work Package 4 can move a CORTISONE route from Not evidenced only when the candidate InterSystems route is connected to a named patient-facing route and cohort. Product fit and licence evidence are useful, but not sufficient.
| Route gate | Acceptance criterion | Evidence required | Decision effect |
|---|---|---|---|
| Component role | CORTISONE component roles are mapped to HealthShare UCR, Health Connect / Integration Platform, IRIS for Health, EMPI, portal, terminology, provider directory, or another named component. | MOD architecture, contract schedule, service design, supplier documentation, or primary carried-over source that names the component role. | Distinguishes record layer, integration layer, identity layer, and portal layer before NHS App claims are made. |
| Source-system coverage | The route identifies whether data comes from DMICP, CORTISONE, TPP-delivered records, DPHC Firmbase, DPHC(O) / DGP, NHS providers, or another source. | Source-system catalogue, feed/API contract, data-processing design, or authoritative programme statement. | Prevents CORTISONE product evidence from being treated as DPHC cohort or DMICP feed evidence. |
| NHS-facing route | The route identifies whether patient-facing exposure is through GP Connect PFS, IM1, NHS App web integration, NHS Notify, Patient Care Aggregator / Wayfinder, PEP, MESH, or another NHS-facing route. | NHS onboarding / API evidence, supplier-progress evidence, assurance artefacts, route design, and route-specific feature scope. | Determines whether the decision can become Conditional for a named route or stays Not evidenced. |
| Cohort and feature test | The evidence names the DPHC cohort, access mode, feature, and test result. | Feature tests for DPHC Firmbase, DPHC(O), minors, dependants, linked profiles, or proxy users. | Prevents a generic CORTISONE route from becoming feature parity. |
| Assurance state | The route has clinical safety, data protection, technical assurance, information security, supplier/practice enablement, and support/fallback evidence. | Partner onboarding, safety case, DPIA, conformance, operational support, and live-service evidence. | Separates plausible architecture from guidance-ready implementation. |
Work Package 4 Candidate Route Map
This map narrows the current CORTISONE gap. It does not close Work Package 4 because no current source proves a live NHS App publication route or DPHC cohort feature test.
| Route layer | Current mapped candidate | Supported by | What it enables | Boundary / evidence still needed |
|---|---|---|---|---|
| Programme layer | Programme CORTISONE / CORTISONE as the MOD digital medical-record programme strand. | MOD programme and annual-report sources, plus carried-over InterSystems programme evidence (SRC-027, SRC-035 to SRC-039, SRC-072, SRC-092). | Frames CORTISONE as the active implementation hypothesis where direct DPHC practice-level NHS App evidence is unavailable. | Programme evidence is not NHS App publication, feature availability, GP-provider role, or cohort coverage evidence. |
| Component role | HealthShare Unified Care Record, IRIS for Health, Integration Platform / Health Connect candidate, Enterprise Master Patient Index, portal, terminology, and provider-directory roles. | InterSystems vendor evidence and carried-over licence / IP / EMPI evidence. | Separates record layer, integration layer, identity layer, and portal layer before a patient-facing claim is made. | Need direct MOD, service-design, contract-schedule, or supplier architecture evidence mapping each named component to CORTISONE in production. |
| Source-system coverage | DMICP, TPP-delivered CORTISONE records, DPHC Firmbase, DPHC(O) / Defence Global Practice, NHS provider systems, or another source. | DMICP FOI, MOD CORTISONE announcement, DPHC(O) / DMS-registration evidence, and provider-route evidence where relevant. | Prevents product fit from being treated as proof that a specific cohort, feature, feed, or source system is in scope. | Need source-system catalogue, feed/API contract, data-processing design, cohort coverage, and coded/free-text handling. |
| Identity and organisation layer | NHS number, PDS registered-GP state, ODS / Spine Directory Service (SDS) organisation context, and EMPI matching. | PDS, ODS, NHS API, and CORTISONE EMPI evidence. | Tests whether CORTISONE can safely match DPHC people and organisations before patient-facing exposure. | Need proof of DPHC Firmbase and DPHC(O) PDS / ODS representation, EMPI-to-NHS identity relationship, restricted-status handling, and same-practice / proxy interpretation. |
| NHS-facing route | GP Connect Patient Facing APIs, IM1, NHS API Platform route, direct NHS App web integration, NHS Notify messaging, Patient Care Aggregator / Wayfinder, or PEP route where applicable. | NHS App integration, API, IM1 / GP Connect, NHS Notify, PCA, PEP, and GP Connect supplier-progress evidence (SRC-054, SRC-056, SRC-063 to SRC-068, SRC-084, SRC-085, SRC-094). | Identifies the route that could turn CORTISONE data into a visible NHS App or linked service feature. | Need route-specific onboarding, assurance, capability pairing, patient-facing publication evidence, and proof that the route supports the intended feature. |
| Cohort and access-mode gate | DPHC Firmbase, DPHC(O), dependants, minors, own access, proxy access, and linked profiles. | NHS App age / proxy sources and DPHC registration-context evidence (SRC-021, SRC-059 to SRC-062, SRC-091). | Keeps CORTISONE route evidence from bypassing NHS App access, age, and proxy controls. | Need feature tests by cohort and access mode, including same-practice or split-registration proxy outcomes. |
| Assurance and operational gate | Clinical safety, data protection, technical assurance, information security, support, fallback, and change control. | NHS App onboarding / API assurance sources and route-specific standards evidence (SRC-054, SRC-063 to SRC-068). | Separates plausible route architecture from guidance-ready implementation. | Need safety case, DPIA, conformance, connection agreements, operational support, fallback, exclusion handling, and live-service evidence. |
Route-Family Queue-to-Decision Map
| Evidence Validation Queue item | Work package | Decision it unlocks |
|---|---|---|
| Patient Care Aggregator / Wayfinder | 2 | SHC appointment visibility through a national / secondary-care provider appointment route for a named DPHC cohort. |
| PEP appointment or booking function | 2 | Whether a connected PEP appointment or booking function supports appointment detail, booking, change, cancellation, or deep-link behaviour without implying document or result access. |
| DMICP PHC appointment reminders | 2 | Whether a one-way DMICP-derived appointment reminder can be delivered through NHS Notify with safe fallback and audit. |
| DMICP PHC appointment visibility | 2 | Whether a DPHC PHC appointment source can support read-only NHS App visibility. |
| DMICP PHC appointment management | 2 | Whether DPHC PHC appointment management remains likely not available or has a directly evidenced bidirectional route. |
| NHS Notify | 2 and 5 | Whether appointment or service messages can be sent without implying appointment inventory, visibility, or booking capability. |
| Clinical correspondence | 3 | Whether correspondence is available through SHC provider document routes, PEP document routes, GP-filed document views, or another named route. |
| PEP document route | 3 | Whether provider-held documents are visible or deep-linked through a named PEP document route. |
| GP-filed document view | 3 | Whether documents filed into a GP record are visible through NHS App GP health-record access for a named DPHC cohort. |
| Test results | 3 | Whether results are available through GP-filed result views, provider results systems, PEP results-release routes, or later CORTISONE patient data. |
| PEP results-release route | 3 | Whether provider-held results are released through a named PEP results-release route with clinical release controls. |
| GP-filed result view | 3 | Whether GP or hospital-ordered results filed into a GP record are visible through NHS App GP health-record access for a named DPHC cohort. |
Package Rules
- A package should be closed only when the decision it unlocks is updated in Guidance Decision Model.
- Evidence that affects more than one package should be recorded once in the Source Register, then mapped to every affected claim in Evidence Matrix.
- Do not close a package using local synthesis alone. Use direct MOD, DMedC / DPHC, NHS, NHS England Digital, supplier, regulator, FOI, standards, or implementation evidence.
- Do not promote acceptance criteria into a new request pack unless the stop/go rule is satisfied; where a reusable pattern or queue entry is enough, keep the structure here.