Skip to content

Transferability and limitations

The civilian PFD evidence supports questions about hazard mechanisms. It does not establish the prevalence of those mechanisms, their current product behaviour, or their presence in Defence systems. Every Defence requirement in this wiki is therefore a candidate analytical translation pending Defence validation.

Transferability assessment

Level Mechanisms Basis What remains unknown
Strongest direct analogue Mobile record-source selection; screening/population visibility; critical-result ownership; inaccessible transfer record; message routing; amendment visibility Featured PFDs directly describe the underlying information or workflow failure, with dedicated claim rows Whether DPHC/DMICP/CORTISONE has the same workflow, control or failure rate
Moderate analogue Hybrid paper-digital operation; minimum transfer dataset; actionable alerts; source completeness; safety-control migration; distributed transaction integrity Case-linked claims support the underlying mechanism, but the proposed Defence control broadens the source setting, architecture or control design Required military dataset, roles, thresholds, operational constraints and acceptable residual risk
Partial-scope hypothesis Conflict-safe offline synchronisation; purpose, proportionality and access-control facets of clinical-operational exchange Case-linked claims support fragile degraded workflows and missing cross-boundary risk signals; the additional Defence control scope is an analytical extension Whether the extended hazard exists in scope, its causal pathway, architecture and proportionate control

The requirements register exposes these differences through validation_status and a traceability note rather than assigning one undifferentiated confidence score.

Reasons translation may fail

  • Different populations and duties: DPHC supports occupational, readiness and operational functions as well as personal healthcare.
  • Mobility and command relationships: posting, attachment, embarkation, deployment, evacuation and coalition care can separate physical location, administrative registration and clinical responsibility in ways not reproduced by one civilian case.
  • Architecture and connectivity: DMICP and CORTISONE interfaces, offline modes, identity services and data flows require direct technical evidence.
  • Governance and access: military clinical-operational information exchange has distinct purpose, proportionality, security and command considerations.
  • Workflow and staffing: roles, workload, training, fallback and escalation paths can change whether the same technical feature becomes a safety barrier or a hazard.
  • Historical evidence: a PFD records the systems and practices examined at that time; it does not prove current vendor or NHS behaviour.
  • Selection: the focused case series is not an exhaustive census and provides no denominator for incidence, prevalence or trend.
  • Causation: a coroner's concern can identify future risk without isolating the contribution of interface, staffing, policy, training or workload.

Validation pathway

Before promoting a REQ- item into a programme baseline:

  1. Define the DPHC/CORTISONE workflow, population, interfaces, roles and safety boundary.
  2. Verify the mechanism using architecture, configuration, workflow, incident, data-quality and user-research evidence.
  3. Map the candidate to existing requirements and clinical-safety hazards; identify duplication, conflict and residual risk.
  4. Agree measurable acceptance criteria and execute the linked AST- scenario with representative users and conditions.
  5. Record the evidence owner, configuration, result, deviations and authorised clinical-risk decision.
  6. Update the requirement's validation status without erasing its original civil-case trace.

Failure to find a mechanism should be recorded as a tested non-finding for the configuration examined, not as proof that it cannot occur elsewhere or later.