Skip to main content
Back to articles

Protect Clinical Insights

A Simple Guide to DCB0129

DCB0129 is the clinical safety standard that health technology vendors must follow. Learn what it requires, why it matters for your practice, and what to request from suppliers.

Published · 6 January 2025Topics: Clinical Safety, DCB0129, Vendors
Health technology vendor presenting safety documentation

What is DCB0129?

DCB0129 is the NHS clinical safety standard that applies to manufacturers and suppliers of health IT systems. While DCB0160 places responsibility on the organisation deploying the system (your practice), DCB0129 places responsibility on the company building and selling the system.

In simple terms:

  • DCB0129: What the vendor must do to make their product safe as designed
  • DCB0160: What you must do to make that product safe as deployed in your specific environment

Both standards are required. A vendor complying with DCB0129 does not remove your obligation to comply with DCB0160, and vice versa.

Why DCB0129 Exists

When you buy a pharmaceutical product or medical device, it arrives with extensive safety testing, documentation, and instructions. The manufacturer has done the work to demonstrate the product is safe when used as intended.

Digital health technology should be no different. Before a supplier sells you a clinical system, they should have:

  • Identified what could go wrong with their product
  • Assessed the risks
  • Built controls into the design to reduce those risks
  • Documented their safety case
  • Appointed someone qualified to oversee clinical safety

DCB0129 makes this a legal requirement. It ensures that suppliers cannot simply build a product, sell it, and leave you to work out whether it is safe.

What Vendors Must Provide Under DCB0129

DCB0129 requires suppliers to produce three key documents:

1. Clinical Safety Case Report

This is a document (typically 10-50 pages depending on the system's complexity) that describes:

  • What the product does and how it is intended to be used
  • What hazards the supplier has identified (things that could go wrong)
  • What risks those hazards pose (likelihood and severity)
  • What safety features are built into the product to control those risks
  • What residual risks remain and why they are acceptable
  • Evidence that the product has been tested and reviewed

The safety case report is the supplier's evidence that they have thought systematically about safety and built it into their product.

2. Hazard Log

This is a detailed register (typically a spreadsheet or structured document) listing every hazard the supplier has identified, along with:

  • A description of the hazard
  • The likelihood and severity if it occurs
  • What controls are built into the product
  • What residual risk remains
  • The status of each hazard (open, closed, mitigated)

The hazard log is a living document. The supplier should update it whenever:

  • A new hazard is identified
  • The product is updated or changed
  • An incident is reported by a customer

3. Evidence of a Qualified Clinical Safety Officer

The supplier must appoint a Clinical Safety Officer (CSO) who is responsible for overseeing clinical risk management for their product.

The supplier's CSO must:

  • Be a registered healthcare professional (doctor, nurse, pharmacist, or equivalent)
  • Have completed accredited clinical safety training
  • Have the authority to stop product releases if safety concerns arise

The supplier should be able to provide evidence of their CSO's qualifications, training, and involvement in the safety case.

How DCB0129 Relates to DCB0160

DCB0129 and DCB0160 are complementary standards—both are required. DCB0129 makes the supplier responsible for ensuring their product is safe as designed, while DCB0160 makes you responsible for ensuring it is safe as deployed in your specific environment.

A common misconception is that vendor DCB0129 compliance removes your DCB0160 obligations. It does not. For a detailed comparison of supplier vs deployer responsibilities and why you need both, see Why DCB0129 is Not a Substitute for DCB0160.

What to Request from Vendors

Before procuring a digital health product, request the supplier's DCB0129 documentation. Specifically, ask for:

  1. The Clinical Safety Case Report
  2. The Hazard Log (or a summary if the full log is commercially sensitive)
  3. Evidence of their Clinical Safety Officer (name, qualifications, registration number, training certificate)
  4. The version number and date of the safety case (so you know it is current)
  5. A statement on how they handle updates (how they reassess safety when the product changes)

If the supplier cannot provide this documentation, or if they have never heard of DCB0129, that is a significant red flag.

How to Evaluate Vendor DCB0129 Compliance

Once you have the supplier's documentation, evaluate it. Your Clinical Safety Officer should review:

1. Is the Safety Case Current and Complete?

  • Does it describe the product you are procuring (not a different version or product)?
  • Is it dated recently (within the last 1-2 years)?
  • Does it cover the features and use cases you plan to deploy?
  • Does it identify hazards that seem credible and relevant?

2. Is the Hazard Log Comprehensive?

  • Are the identified hazards specific and detailed (not generic like "system failure")?
  • Are there risk scores (likelihood × severity)?
  • Are controls described clearly?
  • Are there any obvious hazards missing (e.g., risks related to AI, integration, or patient data)?

3. Is Their CSO Appropriately Qualified?

  • Is the CSO a registered healthcare professional?
  • Have they completed accredited clinical safety training?
  • Is there evidence of their ongoing involvement (e.g., they signed the safety case report)?

4. How Do They Handle Product Updates?

  • Do they reassess safety when releasing new versions?
  • Do they notify customers of safety-related changes?
  • Do they have a process for handling customer-reported safety incidents?

If the documentation is weak, incomplete, or raises concerns, do not assume the product is safe. Ask the supplier for clarification or additional evidence.

What If Vendor Compliance Is Missing or Poor?

If a supplier cannot provide DCB0129 documentation, or if the documentation is inadequate, you have three options:

Option 1: Request Improvement

Ask the supplier to produce proper DCB0129 documentation before you proceed with procurement. Many suppliers are willing to improve their documentation if customers request it.

Option 2: Conduct a More Detailed DCB0160 Assessment

If the supplier's documentation is weak, you will need to do more work yourself. This means:

  • Identifying hazards the supplier has missed
  • Assessing risks the supplier has not considered
  • Implementing stronger controls on your side to compensate

This increases your workload and risk. Document this clearly in your own safety case.

Option 3: Do Not Procure the Product

If the supplier has no DCB0129 documentation and is unwilling or unable to produce it, seriously consider whether you want to deploy their product. Lack of DCB0129 compliance suggests the supplier has not thought systematically about safety, which increases the risk of unidentified hazards.

Your Clinical Safety Officer has the authority to reject procurement on clinical safety grounds. If they recommend not proceeding, that decision should be respected.

Integrating DCB0129 into Procurement

Make DCB0129 compliance a standard part of your procurement process:

During Supplier Selection

  • Include DCB0129 compliance as a mandatory requirement in tenders and requests for proposals
  • Ask suppliers to provide their safety case, hazard log, and CSO evidence as part of their submission
  • Weight DCB0129 compliance in your scoring matrix (e.g., 10-15% of total score)

During Contract Negotiation

  • Require the supplier to provide updated safety documentation whenever the product changes significantly
  • Include clauses requiring the supplier to notify you of safety-related incidents or product recalls
  • Specify that the supplier must cooperate with your DCB0160 assessment (e.g., answering questions, providing technical details)

During Onboarding

  • Review the supplier's DCB0129 documentation as the first step in your DCB0160 assessment
  • Use the supplier's hazard log as the starting point for your own hazard identification
  • Identify gaps where the supplier's assessment does not cover your specific deployment scenario

Next Steps: Using DCB0129 Documentation in Your Assessment

Now you understand what DCB0129 is, what vendors must provide, and how to evaluate their compliance, you are ready to integrate this into your own clinical safety work.

When you conduct a DCB0160 assessment for a new system:

  1. Start by requesting and reviewing the supplier's DCB0129 documentation
  2. Use their hazard log as the foundation for your own hazard identification
  3. Identify additional hazards specific to your deployment (workflows, training, integration)
  4. Assess whether the supplier's built-in controls are sufficient, or whether you need additional controls
  5. Document your assessment in your own Clinical Safety Case Report

The supplier's DCB0129 work should save you time and effort. If they have done a good job, you can build on their foundation rather than starting from scratch.

Resources to Bookmark

Key Takeaways

DCB0129 is the clinical safety standard for suppliers and manufacturers of health IT systems. It requires them to identify hazards, assess risks, build safety into their products, and document their work.

As a deploying organisation, you should request DCB0129 documentation from every supplier before procuring their product. Review it to ensure it is current, comprehensive, and credible.

DCB0129 compliance by the supplier does not remove your DCB0160 obligations. Both standards are required because the supplier is responsible for safety as designed, while you are responsible for safety as deployed.

Use the supplier's DCB0129 documentation as the foundation for your own DCB0160 assessment. If their documentation is missing or poor, you will need to do more work yourself—or reconsider whether to deploy their product.