Documentation that holds up
Clinical safety cases and hazard logs
A clinical safety case is an argument, supported by evidence, that a product is acceptably safe for its intended use. This page explains how the argument is structured, what makes it credible, and where cases most often fall down under review.
The idea
A safety case is an argument, not a form
The purpose of a clinical safety case is to let a reader who did not build your product reach their own view about whether it is acceptably safe in its intended use. That means it has to make a claim, present evidence, and be honest about what remains uncertain.
Reviewers in NHS organisations read a lot of these. They can tell within a few pages whether a document reflects work that actually happened or a template completed to satisfy a procurement question. The difference is specificity: real hazards from your product, real controls with owners and evidence, and residual risks that are named rather than smoothed away.
Claim, evidence, argument
- Claim — the product is acceptably safe for this intended use, in this version.
- Evidence — the hazard log, test results, clinical review, field data, controls.
- Argument — why that evidence supports the claim, and where its limits lie.
Report structure
- 1Product and intended useWhat the product is, who uses it, in what clinical setting, for what purpose — and explicitly what it is not intended for.
- 2Scope and versionThe version, configuration and release the case applies to, and what changed since the previous issue.
- 3Clinical risk management processThe process followed, who was involved, the risk matrix and acceptability criteria used.
- 4Hazard identificationHow hazards were identified — workshops, incident data, literature, prior versions — and who contributed.
- 5Hazard analysis and controlsThe significant hazards, their causes and effects, controls applied, and initial versus residual risk.
- 6Testing and evidenceThe verification and validation evidence relied on, and its limits.
- 7Residual risk and acceptabilityThe remaining risk, why it is acceptable, and who accepted it.
- 8Assumptions and deployment guidanceWhat the deploying organisation must do for the controls to hold. This is where DCB0160 work begins.
- 9Post-market monitoringHow field issues, near misses and performance are monitored and fed back into the hazard log.
- 10Approval and change controlWho approved it, when, and what triggers reassessment.
The working record
What a hazard log entry contains
Each entry should stand on its own: what could go wrong, how, what harm could result, what stops it, and what is left.
Illustrative example only
These rows are generic worked examples showing the structure of a hazard log. They are not findings about any real product and must not be copied into a live hazard log — your hazards must come from your own product, workflow and clinical context.
| Hazard | Cause | Potential harm | Existing controls | Additional controls | Owner | Status |
|---|---|---|---|---|---|---|
| Clinician views an appointment list that is out of date | Scheduled sync between the product and the host system fails silently | A review appointment is missed and follow-up is delayed | Sync failures are logged and retried automatically | Visible 'last updated' timestamp on the list; alert to the service desk after two failed syncs | Engineering lead | Control agreed |
| A user acts on a draft summary that has not been checked | Draft and confirmed content look alike in the interface | Incorrect information is carried forward into the record | Drafts are labelled in the document header | Distinct visual treatment for drafts; explicit confirmation step before a draft can be filed | Clinical Safety Officer | In review |
| Product is used outside its stated intended use | Intended use is not visible at the point of use and onboarding is inconsistent | Decisions are made in a context the product was not designed or tested for | Intended use is documented in the user manual | In-product statement of intended use and limitations; role-based access; deployment checklist for the customer | Product lead | Open |
Scoring risk
Most clinical risk matrices combine a severity rating for the potential harm with a likelihood rating for the hazard occurring, producing a risk level against defined acceptability criteria. The specific scales and thresholds should be set out in your clinical risk management plan and applied consistently.
Score the hazard twice: initially, before controls, and residually, after them. The gap between the two is where you demonstrate that your controls do meaningful work.
Making controls real
A control is only credible if it is specific, owned, implemented and verifiable. “Improve the interface” is not a control. “Display the sample time next to every result, with values older than the configured threshold shown as stale, verified by test case CS-114” is.
Where a control depends on the deploying organisation, say so explicitly and carry it into your deployment guidance so it is not quietly lost.
Under review
Where safety cases most often fall down
These are the patterns that cause questions, delay procurement and, more importantly, mean genuine risk has not been addressed.
Generic hazards
Hazards copied from a template that could apply to any product tell a reviewer nothing about yours.
Controls that are really hopes
"Users will be trained" is not a control unless someone owns it, it is specified, and its effectiveness is checked.
No clinical voice
A hazard log written entirely by engineers and product managers misses how clinicians actually behave under pressure.
Residual risk always acceptable
If every hazard lands neatly in the green band, the scoring is being worked backwards from the conclusion.
Stale documents
A safety case describing a version from eighteen months and forty releases ago is worse than none — it misleads.
Hidden assumptions
Assumptions the deploying organisation must satisfy, left implicit, become uncontrolled risks at go-live.
No traceability
A safety case report that cannot be traced back to entries in the hazard log and to test evidence cannot be verified.
Untouched by incidents
Field issues and near misses that never appear in the hazard log show the process is not actually running.
Maintenance
Keeping the case alive
A clinical safety case is versioned against the product. If your product ships every two weeks and your safety case is issued once a year, the two have parted company and the document no longer describes what your customers are running.
The practical answer is triage. Define in advance which changes are logged only, which need clinical review, and which trigger hazard reassessment and a reissued report. Then make that triage part of your release process rather than a separate governance activity someone has to remember.
Handover
What your customers need from it
Deploying organisations use your safety case as an input to their own DCB0160 work. The most valuable sections for them are the intended-use statement, the assumptions you are making about their environment, and the residual risks you are passing across.
Writing those clearly is not an admission of weakness. It is the thing that lets a trust’s clinical safety team do their job — and it markedly shortens implementation.
How we help
Safety case and hazard log support
We work on the substance, not the formatting. The aim is documentation you can defend in a room with a trust's clinical safety team.
Gap review
An honest read of your existing hazard log and safety case against what reviewers look for.
Hazard workshops
Facilitated sessions with clinical, product and engineering input to find hazards that matter.
Drafting support
Structuring the report so the argument is traceable from claim to evidence.
Ongoing maintenance
Change triage and periodic review so the case stays current as you ship.
The hazard extract on this page is illustrative and generic. It is not a template to copy, and nothing here is legal, regulatory or clinical advice. Accountability for clinical safety remains with your organisation.
FAQ
Safety case and hazard log questions
Keep going
Related reading
DCB0129 for suppliers
The standard that requires the safety case and defines the process behind it.
Clinical Safety Officer support
Who approves the case, and what that role genuinely requires.
AI clinical safety
Additional hazard classes when the product uses AI or machine learning.
DTAC readiness
Where clinical safety evidence sits within the wider NHS assessment.