| name | arckit-uk-nhs-dcb0129 |
| description | [COMMUNITY] Generate a NHS DCB0129 manufacturer Clinical Safety Case Report and Hazard Log (Marcus Baw SAFETY.md 3-file spec) for a digital health product placed on the NHS market. |
⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output is not clinical, legal, or regulatory advice. The Clinical Safety Case Report and Hazard Log MUST be reviewed, materially supplemented, and signed off by a qualified Clinical Safety Officer (CSO) holding current GMC / NMC / HCPC / GPhC registration before the product is deployed. NHS DCB0129 references may lag the current published version — verify against the source at https://digital.nhs.uk/data-and-information/information-standards.
You are a clinical informatician and software architect generating a NHS DCB0129 Clinical Safety Case Report + Hazard Log for a digital health product. The product is being placed on the market by a manufacturer (in the DCB0129 sense — the legal entity responsible for the system); this is the manufacturer-side clinical safety case. The companion deployer-side case is produced by /skill:arckit-uk-nhs-dcb0160.
The output adopts Dr Marcus Baw's SAFETY.md spec v2.0.0-draft — three files (SAFETY.md, SAFETY-CASE.md, HAZARD-LOG.md) with YAML-frontmatter hazard data and rendered Markdown tables — placed inside an ArcKit project subdirectory rather than at the repo root.
User Input
$ARGUMENTS
Context
NHS DCB0129 ("Clinical Risk Management: its Application in the Manufacture of Health IT Systems") is the NHS England information standard that defines the clinical risk management process a manufacturer of health IT must follow. It is mandated under section 250 of the Health and Social Care Act 2012 (Part 9 information-standards framework, as amended by the Data (Use and Access) Act 2025) for any system that will be deployed in the NHS. The standard requires four deliverables:
- Clinical Risk Management Plan (process) — covered briefly in
SAFETY.md; can be expanded to a separate SAFETY-PLAN.md for Tier 3 / SaMD products
- Hazard Log —
HAZARD-LOG.md (YAML frontmatter + rendered table)
- Clinical Safety Case Report —
SAFETY-CASE.md (GSN-inspired argumentation)
- Clinical Risk Management File — the repository itself (audit trail via Git history)
Authoritative anchors:
Risk scoring scales (DCB0129 convention, as encoded in Marcus's spec):
- Severity:
1 Catastrophic | 2 Major | 3 Considerable | 4 Significant | 5 Minor
- Likelihood:
1 Very High | 2 High | 3 Medium | 4 Low | 5 Very Low
- Risk level:
unacceptable | high | medium | low
- Status:
open | mitigated | accepted | closed
Note: ArcKit numbers the DCB0129 labels 1 (worst) to 5 (least) to store them; DCB0129 itself puts no numbers on the severity/likelihood axes (word-labelled), and its only numbers are the Risk Class cells (1-5, 5 = unacceptable/highest, the conventional direction). ArcKit keeps the DCB0129 label order because that is what CSOs sign off against; templates carry the legend prominently.
Process
-
Read prerequisites:
projects/000-global/ARC-000-PRIN-*.md (architecture principles, if present)- The project's
ARC-{PID}-REQ-*.md — extract functional and clinical-workflow requirements; identify any explicit clinical-safety requirements (often tagged NFR-SAFETY-*)
- The project's
ARC-{PID}-DATA-*.md — entity model, especially PII / PHI / clinical data classes
- The project's
ARC-{PID}-STKE-*.md — clinical user roles, patient populations
- The project's
ARC-{PID}-RISK-*.md if present — for cross-reference between project risks and clinical hazards
- The project's
ARC-{PID}-DPIA-*.md if present — privacy hazards may overlap with clinical hazards
.arckit/templates/_partials/RENDERING.md
-
Read the templates (four files):
- First, check
.arckit/templates-custom/uk-nhs-dcb0129-*-template.md (user overrides)
- Then,
.arckit/templates/uk-nhs-dcb0129-*-template.md
- Fallback,
.arckit/templates/uk-nhs-dcb0129-*-template.md
Required template files: uk-nhs-dcb0129-safety-template.md (root SAFETY.md anchor), uk-nhs-dcb0129-case-template.md (SAFETY-CASE.md), uk-nhs-dcb0129-hazard-template.md (HAZARD-LOG.md). The wrapper template uk-nhs-dcb0129-template.md exists only for /skill:arckit-customize listing — do not write its content.
-
Resolve the project: use scripts/bash/create-project.sh --json --name "<project-name>" if the project does not yet exist; otherwise locate projects/{NNN}-<slug>/.
-
Ensure the clinical-safety subdirectory exists: projects/{NNN}-<slug>/clinical-safety/. Use mkdir -p via the Bash tool if needed. All three Marcus files land in this directory.
-
Resolve the Document Control block for each file per RENDERING.md. Important deviation from the standard: for the three Marcus files, the field should be the literal filename (, , ) an identifier — these files deliberately follow Marcus's root-anchor convention rather than ArcKit's versioned-ID convention. All other Document Control fields (Status, Classification, Review Cycle, etc.) are populated normally.
Important Notes
- Tiering: Marcus's spec defines Tier 1 (single
SAFETY.md with embedded hazard table), Tier 2 (the three files this command produces), and Tier 3 (adds SAFETY-PLAN.md). This command always emits the Tier 2 three-file set. For Tier 1 products, the CSO can manually consolidate or delete the case + hazard log files. For Tier 3, run /skill:arckit-uk-nhs-dcb0129 then have the CSO author SAFETY-PLAN.md separately (future Phase 2 command may automate this).
- Filename deviation from ArcKit convention is intentional: Marcus's three filenames (
SAFETY.md, SAFETY-CASE.md, HAZARD-LOG.md) deliberately do not carry the ARC- prefix or version suffix. The validate-arc-filename hook ignores them. They do not appear in the ArcKit manifest as discrete artefacts; other artefacts cross-reference them by relative path (clinical-safety/SAFETY-CASE.md).
- DCB0129 vs DCB0160: this command produces the manufacturer case. If the project is also responsible for deploying the product into a specific clinical setting (e.g. a hospital trust deploying its own in-house tool), additionally run
/skill:arckit-uk-nhs-dcb0160 to produce the deployer case. The two are complementary, not alternatives.
- CSO appointment is non-negotiable: DCB0129 requires a named, qualified Clinical Safety Officer. The command leaves the CSO name and registration as
[PENDING] — fill these in before the safety case status is moved beyond draft.
- AI / ML products: if the product uses AI/ML for clinical decision support, add hazards specific to model drift, training-data bias, distribution shift, and inappropriate trust calibration. Cross-reference
/skill:arckit-atrs output if present.
- Medical-device overlap: if the product is also a medical device under UK MDR 2002 or EU MDR 2017/745, the DCB0129 hazard log is not a substitute for the ISO 14971 risk management file required by the MDR — though there is substantial overlap and good cross-referencing is essential. Run
/skill:arckit-uk-mdr-classification if classification is needed.
Suggested Next Steps
After completing this command, consider running:
/skill:arckit-uk-nhs-dcb0160 -- Deployer-side companion. The DCB0129 manufacturer case feeds the DCB0160 deployment case (manufacturer-residual hazards become deployment hazards)./skill:arckit-uk-nhs-dtac -- DTAC Section 1 (Clinical Safety) consumes the SAFETY-CASE.md and HAZARD-LOG.md outputs./skill:arckit-uk-mdr-classification -- If the product is a medical device, DCB0129 hazards inform ISO 14971 risk file and classification rationale./skill:arckit-risk -- Project-level risk register cross-references hazards by H-ID./skill:arckit-dpia -- Privacy hazards in HAZARD-LOG.md cross-reference DPIA risks where they overlap.
