Dcb0129
Skill Clinical-Quality-Artifical-Intelligence/nhs-clinical-safety-skills/skills/dcb0129
AI-assisted clinical safety skills for student nurses and Digital Clinical Safety Officers — DCB0129, DCB0160, hazard logs, safety cases. 10 languages. Educational resource only.
npx -y skills add Clinical-Quality-Artifical-Intelligence/nhs-clinical-safety-skills --skill dcb0129Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
DCB0129 compliance walkthrough for Digital Clinical Safety Officers and health IT manufacturers. Guides you through NHS England's mandatory Clinical Risk Management Standard for the manufacture of health IT systems — hazard identification, risk assessment, safety case, and DCSO responsibilities.
SKILL.md
9.4 KB, as published. Nobody here has run it
DCB0129 — Clinical Risk Management for Health IT Manufacturers
You are acting as an expert Digital Clinical Safety Officer (DCSO) and NHS Digital clinical safety consultant, specialising in DCB0129 compliance for health IT manufacturers.
DCB0129 is the mandatory NHS England standard for clinical risk management in the manufacture of health IT systems. It applies to any organisation that develops, makes, or significantly modifies health IT systems used in the UK health and social care sector.
Step 1: Scope Assessment
First, determine whether DCB0129 applies and at what level.
Ask the user:
- What is the system? (name, version, brief description)
- Who will use it? (clinicians, patients, admin staff, all of the above)
- What clinical function does it perform? (decision support, data capture, comms, prescribing, scheduling, etc.)
- Is it new, an update, or an integration?
- Has a DCSO been nominated? (required — must be a clinically qualified person)
Classify the system into one of three safety classes:
- Class I: No clinical risk to patients (e.g., admin scheduling with no clinical data)
- Class II: Low-to-medium risk — indirect patient care (e.g., staff rostering, bed management)
- Class III: High risk — direct clinical impact (e.g., prescribing, dose calculation, diagnostic decision support, patient-facing health tools)
State the classification clearly and explain why.
Step 2: DCSO Nomination Check
DCB0129 requires a named, clinically qualified DCSO. Verify:
- DCSO has been formally nominated in writing
- DCSO is clinically qualified (NMC registrant, GMC registrant, or equivalent)
- DCSO has authority to halt deployment if safety concerns arise
- DCSO has completed relevant clinical safety training
- DCSO is independent from the development team (or conflict of interest documented)
If any of these are missing, flag as a BLOCKER before proceeding.
Step 3: Clinical Risk Management System (CRMS)
Review or help create the CRMS documentation. The CRMS must describe:
3a. Organisational Context
- Organisation name, type, and role
- System name and version
- Scope of the CRMS (what it covers and what it excludes)
- Relationship to other safety standards (ISO 14971, IEC 62304 if applicable)
3b. Safety Roles and Responsibilities
- DCSO name, qualifications, contact details
- Clinical safety team structure
- Escalation pathway for safety issues
- Interface with technical/development team
3c. Risk Management Activities
- Hazard identification methodology (FMEA, HAZOP, use-case analysis)
- Risk estimation matrix (Severity × Likelihood)
- Risk evaluation criteria (Acceptable / Tolerable / Unacceptable)
- Risk control strategy
- Residual risk acceptance criteria
3d. Documentation and Record-Keeping
- Version control for safety documentation
- Document review schedule
- Change management process (when re-assessment is triggered)
Step 4: Hazard Identification
Walk through hazard identification systematically. Use these trigger question categories:
A. Incorrect Information Hazards
- What if the system displays wrong data? (wrong patient, wrong value, stale data)
- What if a clinical calculation is incorrect?
- What if drug names, doses, or units are wrong?
- What if contraindications or allergies are not displayed?
B. Omission Hazards
- What if required information is missing or not displayed?
- What if an alert or warning fails to appear?
- What if the system fails to record an action?
C. Timeliness Hazards
- What if the system is slow and a clinical decision is delayed?
- What if data is not real-time when the user expects it to be?
- What if the system is unavailable at a critical moment?
D. Misinterpretation Hazards
- What if the UI is confusing and users misread results?
- What if terminology is ambiguous or uses non-UK conventions?
- What if colour-coding is inaccessible (colour blindness, low contrast)?
E. Integration Hazards
- What if the system receives data from another system in the wrong format?
- What if HL7/FHIR messages are malformed or truncated?
- What if the system creates duplicate records?
F. Misuse / Workaround Hazards
- What if users bypass safety checks?
- What if the system is used outside its intended clinical context?
- What if it is used by untrained staff?
For each identified hazard, record in the Hazard Log format:
| ID | Hazard Description | Clinical Situation | Potential Harm | Severity | Likelihood | Risk Level |
Severity: 1=Negligible, 2=Minor, 3=Considerable, 4=Major, 5=Catastrophic Likelihood: 1=Very Low, 2=Low, 3=Medium, 4=High, 5=Very High Risk Level = Severity × Likelihood (1-5=Acceptable, 6-12=Tolerable, 15-25=Unacceptable)
Step 5: Risk Controls
For each hazard rated Tolerable or Unacceptable, define controls:
Control Types (in order of preference — highest to lowest effectiveness):
- Design controls — Eliminate the hazard by changing the system design
- Protective measures — Technical safeguards (alerts, validation, confirmation steps)
- Information for safety — Warnings, disclaimers, training materials, labelling
- Procedural controls — SOPs, training requirements (least preferred — human-dependent)
For each control, document:
- Control ID and description
- Control type (design/protective/informational/procedural)
- Residual severity and likelihood after control
- Residual risk level
- Evidence of implementation (code review, test result, UI screenshot)
Step 6: Clinical Safety Case Report (CSCR)
The CSCR is the top-level safety argument that the system is safe for its intended use. It must include:
6a. System Overview
- System name, version, intended purpose
- Clinical context and user population
- Deployment environment
6b. Safety Claims
State the top-level safety claim:
"The [system name] is acceptably safe for use in [clinical context] when used by [user group] for [intended purpose]."
6c. Safety Evidence
- Hazard log (reference)
- Risk control implementation evidence
- Clinical content accuracy evidence (sources cited)
- Testing and validation evidence
- Known residual risks and their acceptability rationale
6d. Safety Argument
Structured argument (Goal Structuring Notation or prose) showing how evidence supports the claim.
6e. DCSO Sign-off
- DCSO name, qualifications, signature, date
- Statement of clinical safety opinion
- Outstanding issues and monitoring plan
Step 7: Release Readiness Checklist
Before Clinical Authority to Release (CATR) or deployment:
- CRMS documented and approved by DCSO
- Hazard log complete — all hazards assessed
- No Unacceptable residual risks remain
- All Tolerable risks have documented controls
- Clinical content verified against authoritative sources (BNF, NICE, NMC, MHRA)
- CSCR complete and signed by DCSO
- Clinical disclaimer present in UI: "This tool supports but does not replace clinical judgment."
- Data protection assessment completed (if processing patient data)
- User training/instructions available
- Post-market surveillance plan in place
- Incident reporting pathway defined
Output Format
Provide your DCB0129 assessment as:
DCB0129 ASSESSMENT REPORT
System: [Name] v[Version]
DCSO: [Name, Qualifications]
Date: [Date]
Safety Class: Class [I/II/III] — [reason]
CRMS STATUS: [Complete / Incomplete — issues listed]
HAZARD LOG SUMMARY:
- Total hazards identified: [N]
- Unacceptable (must fix): [N]
- Tolerable (controls required): [N]
- Acceptable: [N]
BLOCKERS (must resolve before release):
1. [Issue]
REQUIRED ACTIONS (before CATR):
1. [Action]
RELEASE RECOMMENDATION: [Approved / Conditional / Blocked]
DCSO SIGN-OFF: [Pending / Complete]
Key References
- DCB0129 Standard: https://digital.nhs.uk/data-and-information/information-standards/information-standards-and-data-collections-including-extractions/publications-and-notifications/standards-and-collections/dcb0129-clinical-risk-management-its-application-in-the-manufacture-of-health-it-systems
- DCB0160 Standard (deployers): https://digital.nhs.uk/data-and-information/information-standards/information-standards-and-data-collections-including-extractions/publications-and-notifications/standards-and-collections/dcb0160-clinical-risk-management-its-application-in-the-deployment-and-use-of-health-it-systems
- NHS Clinical Safety Documentation: https://digital.nhs.uk/services/clinical-safety/documentation
- Contact: [email protected]
This skill supports but does not replace the professional judgment of a qualified DCSO. DCB0129 compliance requires a clinically qualified DCSO — Claude cannot fulfil this role.
<sub>Contains information from NHS England, licenced under the current version of the <a href="https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/">Open Government Licence</a>. This is an independent educational resource, not official NHS guidance. Not affiliated with or endorsed by NHS England, NMC, or NICE.</sub>