Clinical safety case report: what goes in it, with a worked example

A clinical safety case is a reasoned argument that a health IT system is acceptably safe for a defined use, version and setting. The clinical safety case report (CSCR) records that argument so someone outside the project can examine the evidence and its limits. It is not a certificate or a generic statement that a product is safe.

NHS England's clinical safety training on safety cases asks practitioners to treat safety cases as living documents and to evaluate test evidence against stated requirements.

A practical report structure

1. Scope and intended use. Name the product, version, users, patient group, setting and decisions the system supports. State important exclusions.
2. Clinical risk management approach. Explain who identified hazards, how risk was assessed, the acceptability criteria and the Clinical Safety Officer's role.
3. Hazard analysis. Summarise material hazards and link each claim to the controlled hazard log.
4. Controls and verification. Say what was changed or put in place, who owns each control and what test or operational evidence shows it works.
5. Residual risk. Identify what remains after controls. Explain assumptions and any action required of a deploying organisation.
6. Conclusion and approval. Record the reasoning behind the conclusion, unresolved limitations, decision owner, date and release scope.
7. Maintenance. Specify what changes, incidents or new evidence require reassessment.

Illustrative example: a stale patient list

Imagine a fictional care-coordination system that imports appointments overnight. Its stated use is to show a clinician which patients need follow-up. If an import fails silently, a patient may be absent from the list and a review may be delayed.

The safety argument cannot stop at “the import is reliable”. It should identify the failure mode, record how the system detects it, show a visible freshness indicator, describe a fallback process and cite tests for failed and delayed imports. The hazard log would retain the initial and residual risk assessments and identify who owns each control. The report would explain why the remaining risk is acceptable for this release and use, including any condition the deploying service must meet.

This is a teaching example, not a completed hazard assessment or reusable risk rating. A real assessment must reflect the actual product, pathway and local workflow.

What reviewers tend to challenge

Ask whether the report matches the version being bought; whether the most serious hazards are visible; whether controls have owners and evidence; and whether supplier assumptions have been handed to the organisation doing local DCB0160 work. An attractive report with no trace from hazard to evidence does not solve those questions.

The underlying standards are DCB0129 for manufacturers and DCB0160 for deploying organisations. If you need to assess an existing document, see our clinical safety case support and indicative fees.