Edit this page

Clinical Safety - Digital PEWS¶

Status: draft, initial hazard identification. This file supports clinical safety work but is not evidence that the component is approved, compliant, or safe for clinical deployment.

Summary¶

Product boundary¶

Stewardship changed to the OHTF continuation after RCPCH paused PEWS work indefinitely. Existing attribution and historical clinical-review evidence are retained; the change of maintainer does not transfer an organisational clinical approval, appoint a CSO or alter any release limitation. The first OHTF v0.1.0 is a development source snapshot only.

The authoritative product and compliance boundary limits this repository to a composable scoring and charting component. The host clinical system owns data entry, patient identity, validation, persistence, provenance, audit, user access, alerts, acknowledgement, reporting, and operational clinical workflow.

This repository does not independently claim complete National PEWS compliance. A deployer must assess the integrated system, transferred controls, local workflow, and residual risks. The public demonstration uses synthetic data and is not a clinical service.

Current safety position¶

The component has automated evidence for canonical scoring-configuration freshness, selected source-derived scoring behaviour, exact calendar age-band transitions, and FHIR score conformance. Important safety evidence remains incomplete:

• Explicit host-supplied Clinical Intuition, Carer Question, and Specific Concern levels participate in escalation, but automatic derivation from raw responses, AVPU, temperature, and sepsis is incomplete.
• Browser interaction and deterministic Canvas visual-regression tests have not been established.
• Component lifecycle limitations can leave controls or renderer state unreliable after data reassignment, reconnection, or multiple instances.
• Missing or malformed required data is not yet covered by a complete validation and failure-presentation contract.
• The patient.ageBand fallback used without DOB is not suitable for assured clinical scoring.
• The FHIR adapter uses interim repository-local codes where national canonical codes remain unresolved.
• No formal hazard workshop, agreed risk-scoring method, residual-risk acceptance, DCB0129 safety case, or regulatory assessment has been completed.

There is therefore no approved clinical release. The component must not be used for direct patient care without supplier and deployer clinical-safety assessment, completion of applicable controls, and explicit release approval.

Safety roles¶

Applicable assurance domains¶

The project has access to a gitignored patient-derived ED resource for controlled analysis. It is not part of the component or public demo and will be replaced by independently generated fixtures. See spec/patient-derived-data-assessment.md.

Assumptions and transferred controls¶

The component safety argument depends on the integrating system satisfying these controls:

Initial hazard log¶

Risk ratings are deliberately not assigned yet. Severity, likelihood, acceptability criteria, and residual-risk approval require an agreed method and review by a competent Clinical Safety Officer. Open means further controls or evidence are required; Controlled, unreviewed means controls exist but have not received formal CSO effectiveness review.

Safety controls and evidence¶

Safety change and release expectations¶

• A change to scoring, age-band selection, escalation, clinical colours, plotted geometry, line continuity, data mapping, or safety-relevant options must update the relevant specification, tests, and hazard/control evidence in the same change.
• Generated scoring artifacts must remain current and all automated tests must pass.
• Intentional visual changes require comparison with the authoritative NHS reference and explicit human review; regenerating a baseline is not approval by itself.
• Known limitations and transferred controls must accompany any component release or integration handover.
• No version may be designated for clinical deployment until a competent CSO has reviewed the intended use, hazard analysis, control effectiveness, residual risks, and release evidence.
• Deployment approval and local residual-risk acceptance remain the responsibility of the integrating healthcare organisation under its own governance.

Incident and concern reporting¶

Report suspected patient-safety defects privately to pews@openhealthtechnology.org. Do not include patient-identifiable data. Security vulnerabilities should follow SECURITY.md; a security issue with possible clinical impact must also be treated as a safety hazard.

For each confirmed safety incident or near miss, the maintainers must preserve the report, assess immediate containment, link or add the relevant hazard, identify affected versions, record corrective actions and evidence, and communicate residual risk to known integrators where possible.

Open safety actions¶

• Appoint and record a competent Clinical Safety Officer before clinical deployment.
• Agree the risk-scoring and acceptability method, then clinically review and rate every hazard.
• Determine manufacturer/supplier roles and the applicability of DCB0129 and medical-device regulation for the intended release model.
• Complete R9 requirement allocation and traceability.
• Complete controls planned under R11-R19 and R25-R27 where required for the intended release.
• Run a multidisciplinary hazard workshop and decide whether to create a Tier 2 HAZARD-LOG.md, SAFETY-CASE.md, and SAFETY-PLAN.md file set.
• Define release configuration identification, safety sign-off, review cadence, and residual-risk communication.

Review log¶