DCB0129 — Clinical Safety Case

Clinical Safety Statement

Version 1.0 — Effective 6 April 2026 — Prepared by Clinical Safety Officer, Clarifia Ltd

Notice: This document constitutes the Clinical Safety Case for Clarifia 1.0 (SDEC Signposting) as required by NHS Digital DCB0129: Clinical Risk Management by Manufacturers of Health IT. It must be read in conjunction with the Clinical Risk Management Plan (CRMP) and the Hazard Log.

1. DCB0129 Clinical Safety Compliance

Clarifia Ltd operates a formal Clinical Risk Management System (CRMS) in full compliance with NHS England DCB0129 Issue 5 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems). This standard mandates that all health IT manufacturers establish, implement, and maintain a documented clinical risk management process throughout the product lifecycle.

Our Clinical Safety Officer (CSO) holds the qualifications and competencies specified in DCB0129 §4.2 and has confirmed that:

A Clinical Risk Management Plan (CRMP) has been established and approved prior to first deployment.
A Hazard Log has been created, maintained, and reviewed by a clinically qualified assessor.
A Clinical Safety Case Report (CSCR) has been produced for Clarifia 1.0 and is available to NHS deploying organisations on request.
All identified clinical hazards have been assessed using the NHS risk matrix and mitigated to a level As Low As Reasonably Practicable (ALARP).
A post-deployment monitoring programme is in place as required by DCB0129 §8.

2. Clinical Risk Management Plan (CRMP)

The CRMP defines the processes, responsibilities, and methods Clarifia uses to identify, evaluate, control, and monitor clinical risks. Key components are summarised below.

2.1 Scope

The CRMP applies to Clarifia 1.0 (IDST Signposting module), which provides clinical decision support for Same Day Emergency Care (SDEC) triage pathways within NHS acute and community trusts. It does not replace clinical judgement; all outputs are advisory.

2.2 Roles & Responsibilities

Clinical Safety Officer (CSO): Responsible for the CRMS, Hazard Log, and CSCR. Clinically qualified per DCB0129 §4.2.
Development Team: Responsible for implementing controls identified in the Hazard Log and evidencing their effectiveness.
Deploying Organisation CSO: Responsible for local risk assessment per DCB0160 prior to deployment.

2.3 Hazard Identification Methodology

Hazards are identified through structured HAZOP (Hazard and Operability Study) sessions, clinical walkthrough reviews with practising SDEC clinicians, and analysis of reported incidents from comparable systems. Severity and likelihood are scored using the NHS England clinical risk matrix (1–5 scale).

2.4 Hazard Log Summary

The following table is an extract of the current Hazard Log. The full log is available to NHS deploying organisations on request.

ID	Hazard	Severity	Likelihood	Control Measure	Residual Risk
H-001	Incorrect SDEC pathway suggested due to incomplete patient data entry	4	2	Double-String validation (see §3) requires two independent data points before any pathway recommendation is surfaced	Low
H-002	Clinician acts on stale or cached pathway data	4	1	Cache TTL set to 0 for all clinical output routes; timestamp displayed prominently on all recommendations	Low
H-003	System unavailability during active SDEC triage	3	2	Graceful degradation mode displays 'System Unavailable — use local protocol' banner; 99.9% SLA monitored	Low
H-004	Incorrect rejection of a patient who should be seen in SDEC (false negative)	5	1	Double-String validation; mandatory clinician override with documented justification; all rejections logged for audit	Low
H-005	PII data exfiltration via insecure data transfer	5	1	TLS 1.3 enforced; AES-256-GCM at rest; AWS eu-west-2 only; zero-PII logging; CSP blocks external connections	Low
H-006	Wrong Patient — Double-String criteria satisfied using data from two different patients (context-switching error during concurrent session)	5	2	Patient Identity Binding (see §3.4): both String 1 and String 2 must carry the same verified NHS Number before the AND gate can close. NHS Number is cryptographically bound to the session token at login via NHS CIS2. Any mismatch voids both strings and forces clinician re-confirmation.	Low
H-007	Clinical access blocked by region-lock middleware during satellite or MPLS link routing anomaly — clinician cannot use system during active triage	4	1	Break-Glass Procedure (see §5): clinician falls back to local trust paper/EPR protocol. System displays trust-specific fallback contact number. All region-lock rejections trigger a real-time alert to the on-call Infrastructure Lead who can invoke the Break-Glass bypass within 15 minutes.	Low

3. Double-String Validation — SDEC Referral Error Prevention

The Double-String rule is Clarifia’s primary clinical safety control for preventing information loss in SDEC referral decisions.

A “Double-String” (2-point) justification is required before the system will surface any SDEC rejection recommendation. This means the algorithm must identify at least two independent, clinically validated criteria that support the rejection — it is not sufficient for a single criterion to be met.

3.1 Why This Matters

In SDEC triage, an incorrect rejection (false negative) carries the highest clinical risk: a patient who should receive same-day emergency care is turned away. Single-criterion logic is vulnerable to incomplete data entry, edge cases, and coding errors. The Double-String rule creates a logical “AND gate” that requires corroboration before a rejection is asserted.

3.2 How It Works

String 1 — Primary Clinical Criterion: The presenting complaint, vital signs, or clinical flags do not meet SDEC acceptance criteria as defined in the local trust pathway (e.g., NEWS2 score below threshold, no qualifying diagnosis code).
String 2 — Corroborating Criterion: A second, independent data point confirms the same conclusion (e.g., triage category, referral source, or a validated exclusion code from the FHIR UK Core R4 Condition resource).
Rejection Gate: Only when both strings are independently satisfied will the system output a rejection recommendation. If String 2 is absent or contradicts String 1, the system defaults to “Refer for Clinician Review” — never to an automatic rejection.
Mandatory Override Logging: If a clinician overrides a system recommendation (in either direction), the override reason is captured, time-stamped, and written to the immutable audit log. This supports DCB0129 §8 post-deployment monitoring.

3.3 Audit & Traceability

Every Double-String evaluation is written to the clinical audit log in FHIR AuditEvent format, recording both string values, the outcome, the clinician ID (pseudonymised), and the timestamp. This provides full traceability for DCB0129 Hazard Log review and NHS incident investigation.

3.4 Patient Identity Binding — Wrong Patient Prevention

The Double-String AND gate contains an additional prerequisite that is evaluated before either String is assessed: Patient Identity Binding. Both strings must reference the same verified patient identity or the gate cannot close.

NHS Number Binding: At session login via NHS CIS2, the clinician’s identity token is bound to a specific patient context identified by their verified NHS Number. The NHS Number is a cryptographic claim within the session token — it cannot be altered without re-authentication.
Cross-String Assertion: Before the AND gate evaluates String 1 and String 2, the system asserts that both data points carry an identical NHS Number. If the NHS Numbers differ — indicating data from two different patients has been loaded — both strings are immediately voided and the system displays a “Patient Context Mismatch — Re-confirm Patient Identity” warning. No recommendation is surfaced.
Ward/Location Verification: The ServiceRequest FHIR resource includes a performer field referencing the destination SDEC unit by ODS code. The system validates this ODS code against the deploying organisation’s registered SDEC locations before surfacing a referral recommendation. A referral to an unregistered or incorrect ward location is blocked with a mandatory clinician confirmation step.
Audit Trail: Every identity binding check — pass or fail — is written to the FHIR AuditEvent log with the NHS Number hash (not plaintext), the session token reference, the outcome, and the timestamp.

4. Post-Deployment Clinical Monitoring

In accordance with DCB0129 §8, Clarifia operates a continuous post-deployment monitoring programme:

All SDEC rejection recommendations and clinician overrides are reviewed monthly by the CSO.
Deploying organisations are required to report adverse events and near-misses to governance@clarifia.ai within 24 hours.
The Hazard Log and CSCR are reviewed and re-issued with each major software release and at minimum annually.
Critical safety issues trigger an immediate incident response; the system will display a mandatory safety notice to all active users within 1 hour of a P1 safety event being declared.

5. Break-Glass Procedure — Clinical Access Continuity

This procedure applies when Clarifia is inaccessible to a clinician during an active SDEC triage episode — including access blocked by the region-lock infrastructure control (Hazard H-007).

Clarifia is a decision support tool, not a system of record. Clinical responsibility always rests with the treating clinician. If the system is unavailable for any reason, the following procedure applies:

Immediate Fallback: The clinician falls back to their trust’s local SDEC protocol (paper pathway or EPR). Clarifia’s absence does not delay or prevent patient care. All trusts deploying Clarifia are required to maintain a paper fallback pathway as a condition of deployment.
Region-Lock Specific: If the block is specifically a REGION_LOCKED error, the system additionally displays the trust’s designated on-call infrastructure contact number. The on-call Infrastructure Lead is empowered to invoke a time-limited Break-Glass bypass (maximum 4-hour window) without requiring CSO approval, using a pre-issued signed override token stored in the trust’s sealed emergency envelope.
Notification: All region-lock rejections trigger an automated PagerDuty alert to the on-call Infrastructure Lead within 60 seconds. The Lead must assess and either resolve or invoke Break-Glass within 15 minutes of the alert firing.
Logging: Every Break-Glass invocation is time-stamped, attributed to the Infrastructure Lead’s CIS2 identity, and written to the immutable audit log. All invocations are reviewed by the CSO within 2 working days and reported in the monthly post-deployment monitoring review.
Post-Incident: A root cause analysis is completed within 5 working days of any Break-Glass invocation. If the root cause is a Vercel routing anomaly, the incident is reported to Vercel with an SLA demand for lhr1 affinity correction.

Important: The Break-Glass bypass disables the middleware region check only. All other security controls (TLS 1.3, AES-256-GCM, MFA, CSP, RBAC) remain fully active during a Break-Glass window. The bypass does not reduce data security; it only permits Vercel to serve from a non-lhr1 edge node in a time-bounded emergency.

6. Clinical Safety Contact

To request the full Clinical Safety Case Report, Hazard Log, or CRMP, or to report a safety concern:

Clinical Safety Officer: governance@clarifia.ai
Response SLA: 2 working days for information requests; 24 hours for reported safety incidents.