DCB0129 clinical safety hazard log: what to include
What NHS buyers actually check in your hazard log
A DCB0129 clinical safety hazard log is a living record of every patient safety risk your health IT software could contribute to. Rather than a static document you write once and file away, it must be maintained across the product’s entire lifecycle. For every hazard, the log tracks the root causes, potential patient harm, existing clinical controls, and the risk ratings both before and after those controls are applied. Naq’s Hazards module automatically structures these entries to meet exact DCB0129 expectations, routing them directly to a named Clinical Safety Officer for seamless sign-off.
What does a DCB0129 hazard log need to include?
Per hazard, DCB0129 expects the hazard description, at least one cause, the potential patient harm, the clinical safety controls, and two risk ratings: one before controls and one after. The log is a living record, updated as the product changes and as new hazards surface across its life.
DCB0129 is the NHS England information standard titled "Clinical Risk Management: its Application in the Manufacture of Health IT Systems". It is a statutory standard set under section 250 of the Health and Social Care Act 2012, and the 2018 release is current. A national review of the DCB0129 and DCB0160 standards is under consultation through 2026, so the 2018 version remains the one you build against today.
In Naq, each hazard is a record with a readable ID, a Patient Harm field, and a link to the specific Product it relates to. Causes sit underneath as their own child records, at least one per hazard, each with a name, a description of the initiating event, and the effect that follows. The detail page holds sections in the order an assessor reads them: Info, Causes, Initial Rating, Treatment, Controls, Residual Rating. Nothing is hard-deleted; superseded entries are archived, so the log stands as a full record when a buyer or auditor asks to see the history.
DCB0129 or DCB0160: which one applies to you?
DCB0129 is the manufacturer's duty, the organisation that designs and builds the health IT system. DCB0160 is the deploying organisation's duty, the NHS trust or care provider putting that system into live use. Both are required under the Health and Social Care Act 2012, and each needs its own Clinical Safety Officer, hazard log and safety case.
The two are complementary and they do not substitute for one another. As the manufacturer, you own DCB0129: proving the product is safe as designed and built. The trust owns DCB0160: proving it is safe as configured, integrated and used in their setting. When a buyer's assurance team asks for your clinical safety documentation, they are asking for your DCB0129 evidence, the manufacturer's side of the case.
Naq's Hazards module serves the DCB0129 manufacturer obligation. It gives your product team the hazard log, the causes, the ratings and the sign-off trail that back your side of the clinical safety case. For more on the standard itself, see DCB0129.
Who signs off a DCB0129 hazard log?
A nominated Clinical Safety Officer signs off the hazard log. Under DCB0129 the CSO is a suitably qualified and experienced clinician with current registration with a professional body such as the GMC or NMC, trained in clinical risk management, and accountable for the clinical safety of the product.
This is where many healthtech companies stall. You cannot sign your own clinical safety case, and a developer or product lead does not meet the DCB0129 bar. You need a registered clinician in the role, which is hard to hire for a single product line.
Within Naq, the Clinical Safety Officer is the default approver on every hazard. The module uses an Owner-to-Approver workflow with mandatory comments at each step, so the person who drafts a hazard is never the person who signs it off, and the reasoning behind each decision is captured on the record. Where you do not have a registered clinician in post, Naq's in-house Clinical Safety Officers can hold the named CSO role for your product, so the platform and the clinical sign-off arrive together, without a separate consultancy retainer.
How is each hazard scored under DCB0129?
Each hazard is rated on a five-by-five matrix: likelihood against severity. Likelihood runs Very Low, Low, Medium, High, Very High. Severity is described in patient-harm terms: Minor, Significant, Considerable, Major, Catastrophic. Every hazard is rated twice, before controls and after, and residual risk must be reduced As Low As Reasonably Practicable.
The first rating is the initial risk, with only the controls already in place. You then record the controls that reduce the hazard and rate it again as residual risk. As Low As Reasonably Practicable means the CSO judges that no further reasonable control would meaningfully lower the residual risk, and records that judgement on the log.
Naq derives a hazard rating of 1 to 5 from the two axes you set, at both the initial and residual stage, and carries an ALARP flag on the residual rating. The export includes the matrix definitions and the version history, so the scale you scored against stays attached to the log itself, not a separate spreadsheet. Because clinical safety hazards use severity and a clinical sign-off, Naq keeps them in a register separate from organisational risks, which use impact and a different approver; the reasoning is set out in how to run a compliance risk register.
What does a worked hazard entry look like?
Take an illustrative hazard: a patient's medication record shows an out-of-date allergy status in the clinician's view. The cause is a sync delay between the pharmacy feed and the app. The potential harm is a clinician prescribing a drug the patient is allergic to. That single entry carries a cause, a harm, controls and two ratings.
Recorded as HAZ-001, the cause names the initiating event, a delayed refresh of the allergy feed, and the effect, stale allergy data shown to the clinician. The patient harm is set out plainly. The initial rating reflects the risk with no added controls: a Medium likelihood against a Major severity puts it in the higher part of the scale, because the harm is serious even if the timing gap is uncommon.
The controls follow. A visible "last updated" timestamp on the allergy record, a hard block on prescribing when the record is older than a set threshold, and an alert prompting the clinician to re-check. With those in place the residual rating drops: the same Major severity, since the potential harm is unchanged, against a Low likelihood. The CSO then decides whether further reasonable control would lower it, and sets the ALARP flag once satisfied it would not. The example is illustrative, not a real customer case.
Is the hazard log the same as a clinical safety case report?
No. The hazard log is the running record of hazards and their controls. The Clinical Safety Case Report is a point-in-time argument, backed by evidence, that the product is safe to release. The hazard log is evidence within the safety case, alongside the Clinical Risk Management System and Clinical Risk Management Plan, not a replacement for it.
DCB0129 asks a manufacturer to produce four things: a Clinical Risk Management System describing how you manage clinical safety, a Clinical Risk Management Plan for the specific product, the hazard log, and the Clinical Safety Case Report at each release. The log is the one that never stops moving; the report is a snapshot drawn from it.
Naq holds the hazard log as that living evidence base, with every change captured on a per-record activity stream showing what moved and who moved it. When you assemble a Clinical Safety Case Report for a release, the log, its ratings and its approval history are already in one place to draw from. The audit qualities that make a log defensible are covered in what makes a compliance audit trail audit-ready.
Do you need a DCB0129 hazard log to sell software to the NHS?
In practice, yes. To clear NHS procurement, a health IT supplier is asked to show a maintained hazard log and a named Clinical Safety Officer. The clinical safety section of the NHS supplier assurance process, DTAC, asks you to evidence exactly this. A missing or stale hazard log stalls the deal at the assurance gate.
DCB0129 is self-declared. You comply by producing and maintaining the documentation, and there is no third-party DCB0129 certificate to obtain, so any offer to "get you certified" against the standard misreads how it works. What a buyer wants to see is a current hazard log, a qualified CSO who has signed it, and a safety case that holds together.
That is the commercial point of keeping the log in one platform rather than scattered files. When an NHS buyer's assurance team asks for your clinical safety evidence mid-deal, you produce a current log and a named sign-off in the moment, instead of reconstructing months of decisions under deadline. Naq gives product and sales leads that record, and the in-house CSO to stand behind it, so clinical safety clears the procurement gate on time.
FAQ
Who signs off a DCB0129 hazard log?
A nominated Clinical Safety Officer. DCB0129 requires the CSO to be a suitably qualified and experienced clinician with current registration with a professional body such as the GMC or NMC, trained in clinical risk management, and accountable for the product's clinical safety. In Naq the CSO is the default approver on every hazard.
What is the difference between DCB0129 and DCB0160?
DCB0129 is the manufacturer's duty to show the health IT system is safe as designed and built. DCB0160 is the deploying organisation's duty to show it is safe as used in their setting. Both are required under the Health and Social Care Act 2012, and each needs its own CSO, hazard log and safety case.
Is a hazard log the same as a clinical safety case report?
No. The hazard log is the living record of hazards, causes, controls and ratings. The Clinical Safety Case Report is a point-in-time argument that the product is safe to release, and the hazard log is evidence within it.
What does ALARP mean in DCB0129?
ALARP stands for As Low As Reasonably Practicable. After controls are applied, residual clinical risk must be reduced to the point where no further reasonable control would meaningfully lower it. The Clinical Safety Officer makes and records that judgement on the hazard log.
Can you get DCB0129 certified?
No. DCB0129 is self-declared. You comply by producing and maintaining the required documentation, including the hazard log and Clinical Safety Case Report. No body issues a DCB0129 certificate, so treat any "certification" offer with caution.
What does a DCB0129 hazard log record for each hazard?
The hazard description, at least one cause with its initiating event and effect, the potential patient harm, the clinical safety controls, and a likelihood-by-severity rating both before and after controls, with an ALARP judgement on the residual rating.
