Skip to content

Clinical and patient safety: Regulation 28 evidence and DMICP

Two-page outline summary · evidence cut-off 15 July 2026

This outline translates the current Regulation 28 evidence into patient-safety learning and a DCB0129/DCB0160 clinical-safety lens, then cross-references the result with the Defence Medical Information Capability Programme (DMICP) and Programme CORTISONE. It does not use civilian PFDs to prove a DMICP defect, causation, compliance status or acceptable residual risk. The targeted corpus contains 71 included reports from 87 retained candidates, with 16 exclusions; overlapping counts show recurrence in this dataset, not prevalence or trend (SRC-013).

Notation: VIS, LOOP and similar labels are overlapping mechanism codes; CLM- denotes a controlled evidence claim, REQ- a candidate Defence requirement and AST- a designed but unexecuted assurance scenario.

Page 1 — Regulation 28 evidence through patient- and clinical-safety lenses

  • Patient safety concerns unintended or unexpected events, including omissions, that could or did cause harm, and the system-based learning that follows. The Patient Safety Incident Response Framework (PSIRF) resists simplistic single-cause explanations (SRC-135).
  • Clinical safety, in the DCB sense, is freedom from unacceptable clinical risk: identifying foreseeable Health-IT hazards, controlling and verifying them, accepting residual risk, monitoring operation and managing change (SRC-130, SRC-131).

A PFD is therefore a patient-safety scenario and hazard-discovery signal—not a DCB safety case. A future-risk concern need not be a finding that the digital mechanism caused the death, and a recipient response does not prove effective remediation.

Six recurring hazard themes

Signal in the corpus Clinical-safety interpretation and controlled trace
Visibility and decision support — VIS 45; ALERT 31 Critical information can exist without becoming perceptible or actionable. Rhodes CLM-001 and Thompson CLM-008 → REQ-004; AST-004; with Grant CLM-026 → REQ-009; AST-009.
Closed-loop work and ownership — LOOP 54 Viewing, filing or sending is not clinical closure; assure owner, deadline, acknowledgement, escalation and outcome. Stringer CLM-005 → REQ-005; AST-005.
Interoperability, identity and continuity — INT 39; IDPOP 7 Define users, interfaces, identity and visible missingness. Ross CLM-002 / Jordan CLM-010 → REQ-001, REQ-002; AST-001, AST-002; Jordan / Cassidy CLM-009 → REQ-003; AST-003; Reddington CLM-004 / Cassidy → REQ-006; AST-006.
Integrity, provenance and hybrid records — PROV 24 Reconcile paper/electronic records: King CLM-015, Drewell CLM-024 → REQ-007; AST-007. Preserve amendment provenance: Braund CLM-003, Lunt CLM-023 → REQ-008; AST-008. Expose endpoint state: Billings CLM-017, Gibson CLM-018 → REQ-011; AST-011.
Resilience, change and migration — RES 15 Analyse fault, restoration and replacement. Hughes CLM-016, Spencer CLM-022 → REQ-010; AST-010; Welch CLM-025, Price CLM-027 → REQ-012; AST-012.
Governance, assurance and human factors — GOV 60; HF 43 Workload, configuration, roles and organisational boundaries interact. Thornton CLM-019 and Binfield/Richards/Karbauskas CLM-020 partly support clinical–operational-boundary REQ-013 / AST-013.

Medicines/prescribing led the workflow groups (21 reports), followed by risk/care-planning/safeguarding (10), record access/continuity (10) and diagnostics/results (8); 38/71 reports crossed a care-setting boundary. These are non-comparative dataset descriptors.

DCB responsibility boundary

DCB0129 addresses each organisation acting as Manufacturer, including one assembling or adapting a system, across development/modification, release and post-deployment risk management. DCB0160 addresses the Health Organisation across procurement, deployment, use, local configuration, maintenance and decommissioning. Both require proportionate clinical-risk management, a qualified Clinical Safety Officer and maintained safety evidence (SRC-130, SRC-131, SRC-132). The 2018 editions remain current while a national review proceeds (SRC-134). Here they are the NHS benchmark lens. The sponsor cannot presently confirm DMICP's DCB0129/DCB0160 or Defence-equivalent regime, CSO, Hazard Log or Clinical Safety Case, so status is unknown—not absent or non-conformant (SRC-005). Manufacturer, adaptor, integrator and deployment responsibilities must be explicit; one party's assurance is not the other's.

Page 2 — DMICP cross-reference and assurance priorities

What open sources establish

  • Current service and product lineage: MOD calls DMICP its live electronic medical record in July 2026, and the sponsor confirms that its live clinical application is EMIS PCS/DPCS. A 2019 MOD notice identifies the then underlying platform as EMIS's legacy DPCS; CGI historically described an EMIS PCS-based service centrally hosted in a secure Wales data centre, with portal access and deployed synchronisation (SRC-145, SRC-005, SRC-146, SRC-139). Product family is therefore current sponsor-supplied context with dated public corroboration; the exact live version, adaptations and component baseline are not established by public evidence.
  • Access and network: The sponsor clarifies that MCN means MOD Core Network and that “on-premises hosted” means a centrally hosted DMICP service inside Defence/MCN infrastructure, accessed by medical-centre/user MCN/MODNet client terminals or devices—not practice-local servers. Parliament recorded configurable MODNet-terminal access in 2018, CGI's historical account is consistent with central hosting, and a separate personnel/HR contract independently uses the styling MoD Core Network. The sponsor clarification is current operational context, not independent architecture evidence; the exact DMICP service path remains open (SRC-005, SRC-137, SRC-139, SRC-147, SRC-142).
  • Very limited national-service connectivity: NHS England documents DMICP–Spine PDS integration, while a 2017 MOD answer records pathology messaging (SRC-148, SRC-149). The sponsor clarifies that e-RS is instead a separate HSCN/Spine web application used in a native browser; EPS, GP Connect, NHS App, Summary Care Record and the Scottish, Welsh and Northern Irish national platforms are unavailable to Defence (SRC-005). Isolated local systems and manual routes are not treated as national-platform availability. CQC's Brawdy findings remain a bounded service-access/resilience analogue, not proof of cohort-search failure (SRC-156).

Evidence-to-assurance crosswalk

PFD-derived question for DMICP/CORTISONE Controlled trace and minimum evidence
Can registration, support location, care responsibility or record source diverge and hide somebody from a search or recall? REQ-001, REQ-002; AST-001, AST-002. Reconcile representative mobile and wrongly registered cohorts. Across four facilities found unable to ensure effective care, CQC listed common concerns including inability to use DMICP for searches, recall assurance and monitoring, without stating how many had that issue or isolating its cause (SRC-141). Wrong-practice invisibility remains low-confidence hypothesis CLM-007.
Which home-nation, Defence and host-nation records/interfaces exist, and how is missingness shown? REQ-003, REQ-006; AST-003, AST-006. Obtain the current service/interface inventory, access cohort, acknowledgements, manual routes, failure modes and responsibility allocation.
Does every result, message, task and alert have severity, destination, owner, due time, acknowledgement, escalation and closure? REQ-004, REQ-005, REQ-009; AST-004, AST-005, AST-009. Test workload, absence, delay and disconnection, including administrative entry points.
Do live, paper, print, export and investigation views preserve provenance and reconcile after outage or transfer? REQ-007, REQ-008; AST-007, AST-008. Compare controlled amendments, fallback records and restored/exported views.
Can cancellation, correction, reissue or supply leave contradictory endpoint states? REQ-011; AST-011. Exercise partial failure, retry and duplicate action; verify idempotency, divergence detection and accountable resolution.
Are barriers preserved through degraded operation, updates, migration and retirement? REQ-010, REQ-012; AST-010, AST-012. Execute fault, restoration and source–transition–target regression scenarios.
Is the complete sociotechnical system inside an owned safety boundary, including proportionate clinical–operational sharing? REQ-013; AST-013. Where adopted/applicable, obtain DCB0129 Clinical Safety Case Reports from every Manufacturer/adaptor/integrator and the DCB0160 file, plan, Hazard Log, safety reports, incident log, CSO and residual-risk acceptance.

Priority sequence

  1. Baseline reality: exact EMIS PCS/DPCS version and adaptations, central/deployed hosting, MCN/MODNet path, trust boundaries, configurations, interfaces, manual routes and owners.
  2. Confirm the safety regime and roles: map the six themes into applicable manufacturer and deployment artefacts; an assurance-support contract is activity, not a clinical-safety case (SRC-154).
  3. Test work as done: all 13 REQ- items remain Defence-unvalidated and all 13 AST- scenarios remain unexecuted.
  4. Triangulate learning: link, but do not merge, DCB logs, incidents, help-desk/downtime data, complaints, audit, CQC findings and patient-safety learning.
  5. Assure transition: DMICP retirement was planned for March 2028 and SystmOne rollout is scheduled to begin in 2027. Subject to confirmed DMS adoption/applicability, use DCB0160 lifecycle controls as the NHS benchmark; programme statements are not safety acceptance (SRC-143, SRC-144, SRC-153).

Bottom line: the PFD corpus and bounded CQC evidence justify a configuration-specific DMICP hazard/control review. They do not predetermine its outcome.