DCB0129 and DCB0160 for Healthcare Websites: What NHS Digital Teams Actually Need to Know

The simplest way to understand the standards is to separate the organisation building the system from the organisation deploying and using it.

NHS England describes DCB0129 as the standard for manufacturers of health IT systems and DCB0160 as the standard for healthcare organisations deploying and using those systems.

For a supplier building a clinical web application, DCB0129 therefore sits within the manufacturer's clinical risk management process. For an NHS Trust, ICB, GP organisation, or other care organisation deploying that application, DCB0160 governs its own assessment and management of clinical risk.

During healthcare implementations, one of the most useful early decisions is identifying which product functions create clinical consequences before development begins.

DCB0129 applies to the organisation responsible for manufacturing or developing the health IT system.

The manufacturer must establish a clinical risk management process that identifies potential hazards, assesses their clinical impact, defines appropriate controls, and documents the resulting safety argument.

The practical mistake is treating DCB0129 as a document produced immediately before procurement. Clinical risk decisions should instead influence requirements, workflows, testing, release decisions, and subsequent changes.

A supplier should therefore involve its Clinical Safety Officer early enough to review intended functionality rather than simply signing documents after development has finished.

For a deeper explanation of manufacturer responsibilities, see our related guide on what DCB0129 requires from manufacturers.

DCB0160 applies to the healthcare organisation deploying and using the health IT system.

The deploying organisation must consider how the product operates within its own clinical environment. That includes local workflows, users, configuration, implementation arrangements, and risks that may not exist in the manufacturer's original environment.

A supplier's DCB0129 documentation does not remove the NHS organisation's responsibility for its own deployment assessment. NHS England specifically describes DCB0160 as the mechanism through which healthcare organisations assure the clinical safety of their deployed systems.

That distinction becomes important when a product is deployed across multiple Trusts or care settings. Each organisation may need to assess how its own implementation affects clinical risk.

Procurement teams often ask a supplier for DCB0129 evidence while assuming that this completes clinical safety assurance.

It does not.

The supplier's clinical safety case provides evidence about the product and its identified risks. The deploying organisation still needs to assess those risks against its own operational environment through DCB0160 where the standard applies.

For an overview of how these requirements sit within the wider framework, see our NHS digital compliance standards.

This separation also explains why clinical safety documentation can become a procurement blocker. If the supplier has no usable DCB0129 evidence, the NHS organisation may lack the information needed for its own deployment assessment.

Not every healthcare website requires formal DCB0129 or DCB0160 clinical safety assurance.

NHS England states that not all digital solutions are subject to formal clinical safety assurance, and an applicability assessment should determine whether the standards apply.

The important question is not whether the product is called a website. The question is whether its functionality can influence patient safety or clinical care.

Clinical functionality can introduce hazards even when the product looks like an ordinary web application.

Examples include:

NHS England states that health IT with the potential to affect patient safety needs clinical safety consideration, including systematic hazard identification and mitigation.

During healthcare implementations, teams often identify the need for clinical safety assurance too late because they classify the project by its visual interface rather than its functional behaviour.

A better approach is to assess clinical impact during requirements discovery.

A standard marketing website generally does not become subject to DCB0129 or DCB0160 simply because it belongs to a healthcare organisation.

Examples can include:

An appointment listing is different from a digital workflow that decides urgency, eligibility, routing, or clinical priority.

For organisations building patient-facing platforms, our NHS compliant website design and development service can help assess clinical functionality alongside the wider technical requirements.

Forms require more careful assessment because their clinical significance depends on what happens after submission.

A basic contact form that sends a general enquiry to an administrative inbox may not create the same clinical risk as a structured symptom assessment that automatically determines a patient's next step.

Consider a form asking patients about symptoms, medication, urgency, or clinical history. If those responses influence triage, referral, prioritisation, prescribing, or clinical decision-making, the associated workflow deserves clinical risk assessment.

The implementation question is therefore simple: what decision does the information trigger after the patient submits it?

Across NHS organisations in England, 70.1% of digital health technologies in use had no documented clinical safety assurance against DCB0129 or DCB0160 in a national cross-sectional study. The study examined NHS organisations across England and identified a substantial gap between deployment and documented assurance. Source: Journal of Medical Internet Research, national cross-sectional study, 31 October 2025.

For a typical NHS Trust, the study found that only 24.5% of deployed digital health technologies held both DCB0129 and DCB0160 assurance. Source: Journal of Medical Internet Research, national cross-sectional study, 31 October 2025.

These figures do not mean every unassured system presents the same level of clinical risk. They do show that documented clinical safety assurance can remain incomplete after digital technologies enter operational use.

The study assessed digital health technologies deployed across NHS organisations in England and examined their documented assurance against the 2 clinical safety standards.

Its findings highlight a practical governance problem. Clinical safety assurance can be missed during procurement, deployment, or management of legacy systems.

For digital leads, this means the absence of documentation should not be treated as a minor administrative issue. It can indicate that responsibility, risk ownership, or evidence has not been clearly established.

"Unassured" does not automatically mean that a system has caused patient harm.

It means there is no documented evidence of the relevant clinical safety assurance in the dataset examined by the study. The underlying clinical risk of an individual system therefore requires its own assessment.

NHS England describes clinical safety assurance as a clinical risk management activity involving hazard identification, mitigation, evaluation, and documented evidence.

Clinical safety work can become expensive when it begins after procurement requirements have already been established.

If a Trust requests a Clinical Risk Management File during a procurement gate, a supplier without established documentation may need to revisit requirements, architecture, workflows, testing, and evidence.

Based on our healthcare IT experience, early clinical risk assessment reduces the likelihood that safety documentation becomes a late-stage delivery dependency.

Both DCB0129 and DCB0160 require a Clinical Safety Officer role within the relevant clinical risk management process. NHS England describes the CSO as a senior clinician with current professional registration, such as with the GMC or NMC, alongside appropriate clinical safety knowledge and training.

The role is not simply an administrative sign-off function. The CSO provides clinical judgement within the risk management process and supports the development of the safety case.

The CSO should be an appropriately qualified senior clinician with current professional registration and suitable clinical safety training.

The relevant organisation must ensure the individual has the competence and authority needed to perform the role.

For suppliers, the CSO supports the DCB0129 process. For deploying healthcare organisations, the CSO supports the DCB0160 process.

An in-house CSO can provide strong organisational context, particularly where the organisation already has established clinical governance structures.

An outsourced CSO can provide specialist support where the organisation does not have the required capability internally.

The key consideration is not simply where the CSO sits. The person must have enough access to the product, clinical workflows, risk evidence, and decision-makers to perform the role properly.

Across recent compliance projects, coordinating the CSO with developers early has been particularly important because the Hazard Log needs to reflect functional changes as the product evolves.

Clinical safety should begin during planning rather than after development.

The CSO should have visibility into clinically significant requirements, workflows, hazards, mitigations, testing evidence, and material changes.

NHS England describes clinical risk management as an iterative process that requires systematic assessment and documentation.

For example, changing a triage question can alter the information available to a clinical workflow. That change may require the corresponding hazard analysis and safety evidence to be reviewed.

A Clinical Risk Management File brings together the evidence supporting your clinical safety process.

The exact contents depend on the applicable standard and system, but the Hazard Log and Clinical Safety Case are central components of the process described by NHS England.

The Hazard Log records identified hazards, their potential clinical impact, controls or mitigations, and the resulting risk assessment.

It should remain a working document rather than a static file prepared for procurement.

A useful implementation practice is to connect significant product changes with a review of the relevant hazards. That creates a practical link between agile development and clinical risk management.

The Clinical Safety Case provides a structured argument supported by evidence that the system can be considered safe for release within its intended use.

It should explain how hazards were identified, how risks were assessed, what controls were introduced, and what evidence supports the resulting conclusion.

The CSO's involvement gives the safety case clinical governance authority rather than making it simply a technical document.

DCB0129 and DCB0160 do not replace other NHS compliance requirements.

DTAC provides a broader assessment framework covering areas including clinical safety, data protection, technical security, interoperability, and usability and accessibility. NHS England identifies DCB0129 and DCB0160 as part of this wider digital assurance environment.

DSPT addresses a different area of organisational and information governance assurance.

For related guidance, see how DSPT fits alongside clinical risk management.

Based on our healthcare IT experience, sequencing clinical safety, DTAC, and DSPT work early helps prevent one compliance stream from becoming a procurement dependency for the others.

Clinical safety should be treated as one workstream within a wider NHS assurance programme.

The standards overlap in the broader goal of safe digital health technology, but each requirement addresses a different area of risk or governance.

DTAC is broader than clinical safety.

Its assessment areas include clinical safety alongside data protection, technical security, interoperability, and usability and accessibility.

DCB0129 therefore provides the manufacturer's clinical safety evidence required within the broader assessment process.

Treating the DCB0129 file as the entire DTAC submission creates gaps because the remaining assessment areas require separate evidence.

DCB0160 belongs to the organisation responsible for deploying and using the system.

The Trust or other deploying organisation must consider how the technology operates within its own workflows and governance environment.

NHS England states that organisations remain responsible for clinical safety and compliance with DCB0160 when deploying and using health IT.

A practical sequence starts with applicability assessment and clinical risk identification.

Then establish the CSO role, develop the Hazard Log, build the safety case evidence, and align the clinical safety work with DTAC, DSPT, data protection, security, and procurement requirements.

The goal is not to complete every document simultaneously. The goal is to identify dependencies early enough that a missing evidence stream does not stop procurement.

The regulatory context is changing, which makes it important to distinguish current requirements from proposals under review.

Section 121 of the Data Use and Access Act 2025 came into force on 5 February 2026 and expanded the scope of section 250 powers so that IT providers can be brought under a formal duty of compliance with applicable information standards. Source: NHS England, National review of clinical risk management standards DCB0129 and DCB0160, supporting information.

NHS England notes that the current position should be understood alongside the amended statutory framework and anticipated future revisions to the standards.

For suppliers, the practical implication is clear. Clinical safety documentation should not be treated as optional procurement paperwork that can be assembled after the product is complete.

NHS England opened a public consultation on DCB0129 and DCB0160 on 29 June 2026, with the consultation scheduled to close on 11 September 2026. Source: NHS England Digital, Review of digital clinical safety standards: DCB0129 and DCB0160.

The consultation is considering the scope, content, implementation guidance, and wider support associated with the standards.

Because the review remains active, organisations should avoid building compliance processes around assumptions about future changes. Maintain clear documentation and adaptable clinical risk management processes instead.

Use the following checklist before development reaches a procurement or deployment gate.

Qrolic Health supports this type of work by combining healthcare web development with practical NHS compliance planning. For projects involving clinical workflows, we can help your technical and governance teams identify clinical safety dependencies before they become procurement blockers.

DCB0129 and DCB0160 are not interchangeable certificates attached to a healthcare website.

DCB0129 addresses clinical risk management for manufacturers, while DCB0160 addresses the organisation deploying and using the technology. The distinction becomes particularly important when a healthcare website includes triage, symptom assessment, referral logic, prescribing, or clinical decision support.

The 2025 national study also shows why documented assurance deserves attention, with substantial gaps identified across NHS digital health technologies. Source: Journal of Medical Internet Research, national cross-sectional study, 31 October 2025.

With NHS England reviewing both standards during 2026, early documentation and clear ownership provide a more reliable foundation for procurement and deployment.