# Arckit Uk Nhs Dcb0129 > [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. - Skill: `tractorjuice/arckit-uk-nhs-dcb0129` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tractorjuice/arckit-uk-nhs-dcb0129` - Raw SKILL.md: https://api.skillmd.com/api/skills/tractorjuice/arckit-uk-nhs-dcb0129/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: tractorjuice (https://skillmd.com/u/tractorjuice) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tractorjuice/arckit-uk-nhs-dcb0129 --- > ⚠️ **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 . 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 `$arckit-uk-nhs-dcb0160`. The output adopts Dr Marcus Baw's [SAFETY.md spec v2.0.0-draft](https://github.com/pacharanero/SAFETY.md) — 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 ```text $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: 1. **Clinical Risk Management Plan** (process) — covered briefly in `SAFETY.md`; can be expanded to a separate `SAFETY-PLAN.md` for Tier 3 / SaMD products 2. **Hazard Log** — `HAZARD-LOG.md` (YAML frontmatter + rendered table) 3. **Clinical Safety Case Report** — `SAFETY-CASE.md` (GSN-inspired argumentation) 4. **Clinical Risk Management File** — the repository itself (audit trail via Git history) **Authoritative anchors**: - NHS DCB0129 — - NHS Clinical Risk Management Standards — - Marcus Baw, SAFETY.md spec v2.0.0-draft — - ISO 14971:2019 (medical-device risk management) — referenced for severity / likelihood reasoning conventions - IEC 62304 (medical-device software lifecycle) — applicable if the product is also a medical device **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 1. **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` 2. **Read the templates** (four files): - **First**, check `.arckit/templates-custom/uk-nhs-dcb0129-*-template.md` (user overrides) - **Then**, `.arckit/templates-custom/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 `$arckit-customize` listing — do not write its content. 3. **Resolve the project**: use `scripts/bash/create-project.sh --json --name ""` if the project does not yet exist; otherwise locate `projects/{NNN}-/`. 4. **Ensure the clinical-safety subdirectory exists**: `projects/{NNN}-/clinical-safety/`. Use `mkdir -p` via the Bash tool if needed. All three Marcus files land in this directory. 5. **Resolve the Document Control block** for each file per `RENDERING.md`. **Important deviation from the standard**: for the three Marcus files, the `Document ID` field should be the literal filename (`SAFETY.md`, `SAFETY-CASE.md`, `HAZARD-LOG.md`) **not** an `ARC-NNN-CSCR-vX.Y` 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. 6. **Generate `SAFETY.md`** (front-door anchor) populating these required fields from upstream artefacts where possible: - `product-name`, `version` (from REQ / project metadata) - `standard` (`DCB0129` for this command's output; `both` if the deployer DCB0160 case will also live in the same repo) - `clinical-safety-officer` — populate as `[PENDING — CSO name and GMC/NMC/HCPC registration number]`; the CSO appoints themselves - `organisation` — manufacturer legal entity (substitute `${organisation_name}` where appropriate) - `safety-case-status` — `draft` - `hazard-log-url` — relative link `./HAZARD-LOG.md` - `last-reviewed` — today's date - **Summary** section (one to two paragraphs): what the product does, intended clinical context, scope of safety claim, summary of safety approach - **Documents** section: relative links to `./SAFETY-CASE.md` and `./HAZARD-LOG.md` (plus `./SAFETY-PLAN.md` if the user explicitly asked for a Tier 3 build) - **Applicable standards and assurance domains** and **Roles and responsibilities** tables: populate using the screening questions in `.arckit/references/duaa2025.md`. The CSO owns only the clinical-safety row; adjacent domains are cross-referenced, not annexed. 7. **Generate `SAFETY-CASE.md`** following the GSN-inspired six-section structure: 1. **Intended Use** — clinical purpose, indications, contraindications, intended user population (clinicians / patients / both), intended clinical context 2. **Scope** — what is in scope for this safety case; explicit out-of-scope statements; assumptions about deployment environment (the gap that DCB0160 fills) 3. **Safety Argument** — structured argument that the product is acceptably safe. Reference each major safety claim by H-ID from the Hazard Log. Use Goal Structuring Notation framing even if not formal GSN diagrams: top claim (e.g. "The product is acceptably safe for use by NHS clinicians in the intended context") supported by sub-claims, each linked to hazards and controls 4. **Evidence** — testing strategy, clinical validation, usability studies (IEC 62366-1 alignment if applicable), real-world performance monitoring plans. Cross-reference any V&V artefacts in the project 5. **Residual Risk** — summary of accepted residual risk after controls applied; explicit justification for each accepted residual risk 6. **CSO Sign-off** — name, GMC/NMC/HCPC registration, date, explicit statement of approval (left as `[PENDING]` for the human CSO to complete) 8. **Generate `HAZARD-LOG.md`** with YAML frontmatter + rendered Markdown table. The YAML frontmatter MUST contain: - `hazards:` array — at minimum 6 starter hazards drawn from the project's requirements and data model. Realistic starter examples for a typical NHS digital health product: - Incorrect identity matching (wrong patient context loaded) - Stale clinical data displayed (cache / sync failure) - Missing audit trail for clinical decision - Authorisation bypass (clinician sees data outside their scope) - Notification failure (urgent clinical alert not delivered) - Data integrity loss (clinical record corruption on write) - `controls:` array — at minimum the corresponding controls (C001+) referenced by the hazards - Render the human-readable Markdown table below the frontmatter showing ID, Description, Sev, Like, Risk, Controls, Residual Risk, Status - Each hazard MUST have `cso-reviewed: false` and `status: open` in the initial generation (the CSO transitions these during review) Before finalising, walk every hazard-archetype family in `.arckit/references/hazard-archetypes.md`. For each family, either raise at least one hazard or record in the safety case why the family is not applicable to this product. This makes hazard discovery coverage-led, not example-led. 9. **Adapt to the actual project**: the six starter hazards above are baseline. If the project's requirements suggest additional product-specific hazards (e.g. an AI-powered decision support tool has additional model-drift / model-bias hazards), add them. Do not pad with generic hazards just to hit a count. 10. **Populate the External References section** at the foot of `SAFETY-CASE.md` per `.arckit/references/citation-instructions.md`. NHS DCB0129 and the Marcus SAFETY.md spec MUST appear in the Document Register. 11. **Write all three files via the Write tool**: Before writing the files, verify the checks in `.arckit/references/nhs-clinical-safety-checklist.md` and resolve any failures. - `projects/{NNN}-/clinical-safety/SAFETY.md` - `projects/{NNN}-/clinical-safety/SAFETY-CASE.md` - `projects/{NNN}-/clinical-safety/HAZARD-LOG.md` 12. **Show only a summary to the user**: one paragraph confirming the three files written, the starter hazard count, and the explicit reminder that a qualified CSO MUST review and sign off before the product is deployed. Include the hazard log severity / likelihood / risk-level legend. ## 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 `$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 `$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 `$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 `$arckit-uk-mdr-classification` if classification is needed. ## Suggested Next Steps After completing this command, consider running: - `$arckit-uk-nhs-dcb0160` -- Deployer-side companion. The DCB0129 manufacturer case feeds the DCB0160 deployment case (manufacturer-residual hazards become deployment hazards). - `$arckit-uk-nhs-dtac` -- DTAC Section 1 (Clinical Safety) consumes the SAFETY-CASE.md and HAZARD-LOG.md outputs. - `$arckit-uk-mdr-classification` -- If the product is a medical device, DCB0129 hazards inform ISO 14971 risk file and classification rationale. - `$arckit-risk` -- Project-level risk register cross-references hazards by H-ID. - `$arckit-dpia` -- Privacy hazards in HAZARD-LOG.md cross-reference DPIA risks where they overlap.