# Limitations and validation queue ## Evidence request pack, limitations and maintenance ### Minimum evidence bundle to request | Evidence | Why needed | Likely responsible party | |---|---|---| | Capability/Epic declaration, contract, adopted standards versions and assurance conditions | Establish real applicability and effective baseline | Supplier / buyer | | DCB0129 plan, hazard log, safety case report, release configuration and safe-use instructions | Evaluate manufacturer controls and transferred duties | Supplier CSO | | DCB0160 plan/log/case, local workflows, configurations and acceptance records | Evaluate deployment risks and implementation | Deployer CSO / management | | Risk matrix, acceptance policy, competency and approval records | Interpret ratings and authorised decisions | Both separately | | Architecture/data-flow/interface inventory | Identify dependencies and boundaries | Technical leads | | Integrity/audit demonstrations and support-access controls | Verify amendments through all relevant paths | Supplier / IG / technical assurance | | Clinical, integration, fault, load, accessibility and regression test evidence | Support specific control effectiveness claims | Supplier and deployer | | Migration extracts, reconciliation, exceptions and sign-off | Verify meaning, completeness and outstanding-work continuity | Source/target suppliers and deployer | | Downtime, restoration and reconciliation exercises | Verify continuity beyond a backup policy | Supplier / support provider / practice | | Current DSPT, security testing, DPIA, agreements and role/access model | Evaluate security/privacy obligations and safety dependencies | Relevant legal entities / IG | | Medical-device intended-purpose/status and applicable lifecycle evidence | Resolve regulatory scope per function | Manufacturer / regulatory lead | | Local training, safe-use competence and operating procedures | Verify operational controls and transferred actions | Deployer / supplier | | Service-specific specifications, hazard logs and approval/onboarding records | Assess actual national-service integrations | Interface owner / supplier | ### Explicit coverage limitations / unresolved items - **U01 — metadata resolved:** Live canonical API confirms S30 v7.0.0, Effective 23 October 2026. Product adoption remains unassessed. - **U02 — metadata resolved:** Live canonical API confirms C15 v1.3.1, Effective 13 October 2026. Product adoption remains unassessed. - **U03:** The seed's exact GP operating-model v6.02 / 3 September 2026 metadata was not independently reconfirmed: direct access returned a bot challenge. Official search located v6 May 2026 and related agreements. Full operating-model and ICB/practice documents were not audited clause by clause. Obtain the controlled applicable versions before contractual findings. - **U04:** Interface schemas, embedded legacy attachments and supplier-specific IM1 specifications are not fully reproduced. A family-level checklist cannot prove payload conformance. - **U05:** Restricted S29 hosting-security attachment was identified but not obtained. Security requirements behind it remain SOURCE DETAIL REQUIRED where applicable. - **U06:** The catalogue contains F rows for some capabilities and standards; these intentionally require local normative detail for formal findings. - **U07:** Licensed ISO/IEC standards are applicability topics only; exact clauses/editions require authorised copies. - **U08:** Product configuration, actual contract, assurance record, risk matrix and workbook remain unassessed. No real compliance gaps have been established by producing this reference. - **U09:** National requirements change. The offline cut-off is fixed; the model must not claim knowledge of later changes. - **U10:** DAPB4019 landing metadata says Amd 24/2025, but its directly inspected requirements PDF is Amd 41/2025 v2.0 Final, dated 30 November 2025 and published 19 December 2025. PDF §9 confirms phase-two/full conformance by 30 September 2026. The landing mismatch remains; pin the approved specification/ISN, organisation and API/NCRS route before formal findings. Only selected requirements were inspected [SRC-051](https://dsic-clinical-safety.pages.dev/sources/index.md#src-051), [SRC-078](https://dsic-clinical-safety.pages.dev/sources/index.md#src-078). - **U11:** Patient-facing, communications, diagnostics, online consultation and unified-record pages were identified with limited detailed transcription; use the F controls to request adopted criteria. - **U12:** Defence, Scotland, Wales and Northern Ireland: establish local policy, contracts, national-service entitlements and record-transfer architecture. England commissioning obligations are not automatically universal UK obligations. An unresolved source/version question prevents a definitive finding on the affected requirement, not useful screening of the whole log. Keep the open dependency and proceed with unaffected topics. The 28 October 2026 refresh retrieved all 44 original DSIC source entries in scope (45 pages because [SRC-017](https://dsic-clinical-safety.pages.dev/sources/index.md#src-017) has two) and checked the listed selected clauses. It did not exhaustively verify every linked attachment, API profile, acceptance criterion or all 170 original controls. Metadata conflicts were checked against the live public Confluence content API; readable cached web pages can lag the live page. Supplier/deployer contracts, implementations and the workbook remain unassessed. ### Offline maintenance procedure Appoint a reference owner and review before each procurement/deployment baseline, material change or scheduled governance refresh. While connected, verify canonical source pages, change notices and adopted contract versions; record superseded and future requirements separately. Have the CSO and relevant assurance leads approve material interpretation changes. Then transfer the version-controlled single file through the organisation's approved import process. For each update record: document version; research date; source/version/status; changed GP-IDs; reason; applicability impact; reviewer; approval. Preserve old baselines for historical assessments. An optional SHA-256 file hash can help verify the transferred file against an independently retained reference; it is a packaging control, not proof of correctness or a national approval. ## Parked evidence-dependent work | Work | blocked_by | reopen_when | last_checked | |---|---|---|---| | Actual Hazard Log assessment | Workbook intentionally resides only in closed network | Local reviewer supplies it to that Copilot instance with this reference | 2026-10-28 | | Product applicability and accepted residual risk | Contract, build, configuration and authorised safety decisions absent | Evidence becomes available to the local review team | 2026-10-28 | | Restricted hosting, supplier IM1 and licensed clauses | Authorised detailed copies unavailable | Approved copies are obtained within relevant environment | 2026-10-28 | | Copilot execution validation | No access to target session | User tests intake and synthetic probes in that session | 2026-10-28 | These dependencies do not imply defects or noncompliance. They do not block use of the reference for conditional evidence screening.