Executive summary

This Wiki is an evidence-linked review of how electronic records, digital workflows, interoperability and health-IT design appear in England and Wales Prevention of Future Deaths (PFD) reports. It has two purposes: to identify recurring sociotechnical safety mechanisms in the reviewed reports, and to translate those mechanisms into questions, candidate controls and assurance scenarios for Defence Primary Healthcare (DPHC) and Programme CORTISONE.

Bottom line

The central finding is that information being present in a system is not the same as it being available, understood, owned and acted on in care. Across the included reports, safety risk commonly arises at the seams between people, organisations, records and representations:

• clinically important information can be stored but not visible or salient in the view being used;
• a result, message, recommendation or referral can be sent or filed without a named owner, deadline, escalation path or closure state;
• technically successful transfer can still attach information to the wrong person, lose meaning or fail to enter the receiving workflow;
• paper–digital boundaries, exports and ordinary record views can omit prompts, amendments or richer source information;
• outages, delay, after-hours work and migration can weaken safeguards or force fragile manual workarounds; and
• configuration, governance, workload, interface design and professional expectations determine whether a digital feature acts as a safety control in practice.

The practical implication is to assure the whole information-to-action loop, not just data storage or transport. Controls need to remain effective across identity, workflow, organisational, representation and degraded-operation boundaries.

Evidence at a glance

The current non-exclusive coding shows recurrence within the included series: governance and assurance (GOV, 101 reports); action ownership and closed-loop work (LOOP, 79); human factors and usability (HF, 71); information visibility (VIS, 68); interoperability and continuity (INT, 58); decision support and alerting (ALERT, 47); data quality, provenance and auditability (PROV, 45); resilience and degraded operation (RES, 28); and identity, registration and population management (IDPOP, 9). Reports can receive several codes, so these figures overlap and must not be added or treated as rates.

What was established about provenance

The authority chain is deliberately one-way:

primary source → included report → traceable claim → hazard mechanism → candidate requirement → assurance test

The source register records provenance and reliability limits; the screening log and included-case dataset define the reviewed series; and the canonical claims register, with its generated human-readable view, preserves structured mappings where explicit claim traceability is needed. Generated report pages, catalogues, maps, repository graphs, LLM discovery files and publication outputs help readers navigate or reuse the work, but they do not create new evidence authority.

The supplied 400-page Reg 28 PFD Reference material.docx was therefore audited as secondary discovery material, not accepted as evidence. Its 60 nominal profiles all map to reports already in the Wiki, while the Darren Carrington and Valerie Gibson profiles contain substantive wrong-case narratives. The current Wiki contains 52 primary-sourced reports absent from the document, so absence from that document is not evidence of hallucinated Wiki content. Conversely, primary-source rechecking found and corrected two genuine Wiki metadata errors: the coroner areas for Sebastian Daniels and Jennifer Trigger. The full document audit records the checksum, link inventory, bidirectional case reconciliation and conflict dispositions.

The same update work added 41 eligible official-primary-source PFDs. Split internal primary-source quality assurance corrected several proposed extractions before integration, while preserving qualifications about causation, formal concern wording and recipient accounts. It did not close the independent second-reviewer gap. No case mechanism was accepted on the authority of the supplied document alone.

Findings and Defence application

The findings synthesis groups the evidence around seven reader questions: visibility and decision support; closed-loop work and ownership; interoperability, identity and continuity; record integrity and provenance; resilience and degraded operation; governance and assurance; and human factors as a cross-cutting lens. These are mechanisms seen in the bounded corpus, not claims that one technology caused each death.

For Defence, the transferability assessment identifies the strongest direct analogues as mobile-population record sources, population safety searches, critical-result closure, transfer-record availability, message routing and amendment visibility. More extended controls—such as conflict-safe offline synchronisation or clinical–operational information exchange—remain partial-scope hypotheses. The candidate requirements, assurance scenarios and DMICP evidence gaps make those boundaries explicit.

Before any candidate control enters a programme baseline, Defence needs to define the actual workflow and safety boundary, verify the mechanism against current architecture, configuration, incidents and user evidence, agree measurable acceptance criteria, execute the linked scenario in representative conditions, and record the authorised clinical-risk decision.

Limits and open assurance work

The Wiki should support hazard discovery, design challenge and assurance planning—not frequency estimates or declarations of compliance. The principal open release and evidence gates are:

• a final search rerun to the submission closing date and fuller contextual dispositions for the 343 other rows in the 2018 publication-cohort manifest;
• independent second-reviewer checks of inclusion, extraction, mechanism coding, source lineage and care-pathway facets;
• fuller 2019–2024 discovery and later-migrated 2018-page retrieval, plus follow-up for the 49 reports without a registered response letter or verified implementation evidence;
• resolution of item-level discrepancies retained in the validation queue; and
• current DPHC/DMICP/CORTISONE workflow, architecture, integration, clinical-safety, incident and user evidence sufficient to validate—or reject—the candidate requirements and tests.

Where to go next