arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/uk-nhs-dcb0129-hazard-template.md

@@ -0,0 +1,217 @@
+---
+hazards:
+  - id: H001
+    description: "Incorrect patient identity loaded into the product context (wrong-patient hazard)"
+    cause: "Identity lookup mismatches similar names / DOBs; failure to confirm NHS Number; clinician selects wrong record from a search result"
+    effect: "Clinical decisions or data entries applied to the wrong patient"
+    severity: 2
+    likelihood: 3
+    risk: high
+    controls:
+      - C001
+      - C002
+    residual-severity: 2
+    residual-likelihood: 5
+    residual-risk: low
+    status: open
+    cso-reviewed: false
+    date-raised: "[YYYY-MM-DD]"
+    date-closed:
+  - id: H002
+    description: "Stale clinical data displayed (cache or sync failure)"
+    cause: "Local cache served when upstream system has more recent data; eventual-consistency lag exceeds clinical-relevance window"
+    effect: "Clinician acts on out-of-date information, e.g. ordering a duplicate test or missing a critical result"
+    severity: 2
+    likelihood: 3
+    risk: high
+    controls:
+      - C003
+      - C004
+    residual-severity: 2
+    residual-likelihood: 4
+    residual-risk: medium
+    status: open
+    cso-reviewed: false
+    date-raised: "[YYYY-MM-DD]"
+    date-closed:
+  - id: H003
+    description: "Missing or incomplete audit trail of clinical decision"
+    cause: "Logging not enabled on a code path; log destination unavailable at time of write; PII redaction strips clinical context"
+    effect: "Inability to reconstruct what data the clinician saw at the time of decision; harms patient safety investigation and clinician indemnity"
+    severity: 3
+    likelihood: 3
+    risk: medium
+    controls:
+      - C005
+    residual-severity: 3
+    residual-likelihood: 5
+    residual-risk: low
+    status: open
+    cso-reviewed: false
+    date-raised: "[YYYY-MM-DD]"
+    date-closed:
+  - id: H004
+    description: "Authorisation bypass — clinician sees patient data outside their legitimate clinical relationship"
+    cause: "RBAC misconfiguration; role/permission mapping defect; legitimate-relationship check missing on a code path"
+    effect: "Confidentiality breach; potential GMC/NMC referral against the clinician; UK GDPR Article 5(1)(f) breach"
+    severity: 3
+    likelihood: 3
+    risk: medium
+    controls:
+      - C006
+      - C007
+    residual-severity: 3
+    residual-likelihood: 5
+    residual-risk: low
+    status: open
+    cso-reviewed: false
+    date-raised: "[YYYY-MM-DD]"
+    date-closed:
+  - id: H005
+    description: "Notification or alert failure (urgent clinical communication not delivered)"
+    cause: "Push notification provider outage; user opted out of notifications and not warned of clinical relevance; alert ranking buries critical alert in a queue"
+    effect: "Time-critical clinical action delayed or missed"
+    severity: 2
+    likelihood: 3
+    risk: high
+    controls:
+      - C008
+      - C009
+    residual-severity: 2
+    residual-likelihood: 4
+    residual-risk: medium
+    status: open
+    cso-reviewed: false
+    date-raised: "[YYYY-MM-DD]"
+    date-closed:
+  - id: H006
+    description: "Data integrity loss on write (clinical record corruption)"
+    cause: "Concurrent-write race condition; partial write under failure; ORM defect serialising clinical data; encoding mismatch"
+    effect: "Clinical record becomes inaccurate, incomplete, or unreadable; downstream clinical decisions based on corrupted data"
+    severity: 2
+    likelihood: 4
+    risk: medium
+    controls:
+      - C010
+      - C011
+    residual-severity: 2
+    residual-likelihood: 5
+    residual-risk: low
+    status: open
+    cso-reviewed: false
+    date-raised: "[YYYY-MM-DD]"
+    date-closed:
+
+controls:
+  - id: C001
+    description: "NHS Number is the canonical identifier on every clinical record; PDS lookup with demographic trace required for new-record creation; UI shows NHS Number + DOB + name + first line of address before any clinical action."
+  - id: C002
+    description: "Two-factor patient identification on search result selection — clinician must confirm NHS Number or scan a wristband/barcode before the patient context loads."
+  - id: C003
+    description: "Cache TTLs configured per data class with clinical-relevance windows (e.g. observations: 30s, allergies: 5min, demographics: 1hr). Cache age visible to clinician for any non-real-time data shown."
+  - id: C004
+    description: "Synchronous read-through cache for safety-critical data classes (current medications, active allergies, current observations); cache miss falls back to source-of-truth read, not silent stale return."
+  - id: C005
+    description: "Append-only audit log written before the clinical action is presented in the UI; log includes user, patient context, data class, action taken, and timestamp. Independent storage from the primary database with retention ≥ 8 years per NHS records management code of practice."
+  - id: C006
+    description: "Role-based access control enforced at the API layer (not only the UI); RBAC unit tests cover all roles × all resource types; periodic access review."
+  - id: C007
+    description: "Legitimate-relationship check (or sealed-envelope-style equivalent) on every patient-context load; non-relationship access permitted only via explicit break-glass with audit and notification."
+  - id: C008
+    description: "Critical clinical alerts use in-app delivery with synchronous acknowledgement, not only push notifications; non-acknowledged critical alerts escalate to a different recipient within a defined SLA."
+  - id: C009
+    description: "Alert ranking and presentation tested with clinical SMEs to avoid alert fatigue; critical alerts visually distinct and not collapsible."
+  - id: C010
+    description: "All clinical writes are transactional with optimistic concurrency control on a row-version field; conflicting writes return an explicit clinical-context error to the clinician (not a silent overwrite)."
+  - id: C011
+    description: "Daily integrity check across clinical record store with automated alerting on hash mismatch; backups verified by restore test on a recurring schedule."
+---
+
+# Hazard Log — [PRODUCT_NAME]
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:uk-nhs-dcb0129` | **Filename**: `HAZARD-LOG.md` (DCB0129 manufacturer)
+
+## Document Control
+
+| Field | Value |
+|---|---|
+| **Document ID** | `HAZARD-LOG.md` (Marcus Baw SAFETY.md spec convention; no ARC- prefix) |
+| **Document Type** | Hazard Log (DCB0129 manufacturer) |
+| **Project** | [PROJECT_NAME] (Project [PROJECT_ID]) |
+| **Classification** | [OFFICIAL / OFFICIAL-SENSITIVE] |
+| **Status** | DRAFT |
+| **Version** | [VERSION] |
+| **Created Date** | [YYYY-MM-DD] |
+| **Last Modified** | [YYYY-MM-DD] |
+| **Review Cycle** | Monthly (hazard logs are *living* documents) |
+| **Next Review Date** | [YYYY-MM-DD] |
+| **Owner** | [PRODUCT_OWNER_NAME_AND_ROLE] |
+| **Reviewed By** | [PENDING — CSO] |
+| **Approved By** | [PENDING — CSO] |
+| **Distribution** | [DISTRIBUTION_LIST] |
+
+## Risk scoring scales (DCB0129 convention)
+
+- **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`
+
+> ⚠️ DCB0129 inverts the usual Orange Book convention where 5 = highest. The numbers above carry the opposite meaning from the project risk register.
+
+---
+
+## Hazards
+
+*Rendered from the structured YAML at the top of this file. Keep in sync — edit YAML first, then re-render this table (the `/arckit:uk-nhs-dcb0129` command regenerates both together).*
+
+| ID | Description | Sev | Like | Risk | Controls | Residual Risk | Status |
+|---|---|---|---|---|---|---|---|
+| H001 | Incorrect patient identity loaded (wrong-patient hazard) | 2 | 3 | HIGH | C001, C002 | LOW | Open |
+| H002 | Stale clinical data displayed (cache / sync failure) | 2 | 3 | HIGH | C003, C004 | MEDIUM | Open |
+| H003 | Missing or incomplete audit trail of clinical decision | 3 | 3 | MEDIUM | C005 | LOW | Open |
+| H004 | Authorisation bypass — clinician sees data outside their relationship | 3 | 3 | MEDIUM | C006, C007 | LOW | Open |
+| H005 | Notification / alert failure (urgent communication not delivered) | 2 | 3 | HIGH | C008, C009 | MEDIUM | Open |
+| H006 | Data integrity loss on write (clinical record corruption) | 2 | 4 | MEDIUM | C010, C011 | LOW | Open |
+
+## Controls
+
+| ID | Description |
+|---|---|
+| C001 | NHS Number canonical; PDS lookup on new records; UI shows NHS Number + DOB + name + address before action |
+| C002 | Two-factor patient ID on search-result selection (NHS Number confirm or barcode scan) |
+| C003 | Per-data-class cache TTLs (observations 30s, allergies 5min, demographics 1hr); cache age visible |
+| C004 | Synchronous read-through cache for safety-critical data; cache miss falls back to source-of-truth |
+| C005 | Append-only audit log written before clinical action presented; independent storage; ≥ 8yr retention |
+| C006 | RBAC enforced at API layer (not only UI); RBAC unit tests cover all roles × resources |
+| C007 | Legitimate-relationship check on every patient-context load; break-glass explicit and audited |
+| C008 | Critical alerts use in-app sync acknowledgement; non-ack escalates to different recipient on SLA |
+| C009 | Alert ranking and presentation usability-tested; critical alerts visually distinct and non-collapsible |
+| C010 | Clinical writes transactional with optimistic concurrency control; conflicts return explicit error |
+| C011 | Daily integrity check with hash mismatch alerting; backups verified by recurring restore test |
+
+---
+
+## How to extend this hazard log
+
+- Add new hazards to the `hazards:` array in the YAML frontmatter
+- Add new controls to the `controls:` array
+- Re-render the Markdown tables (or re-run `/arckit:uk-nhs-dcb0129` which regenerates both)
+- Have the CSO review each new hazard before flipping `cso-reviewed: true`
+- Move hazards through statuses (`open` → `mitigated` → `closed`) as controls are evidenced
+- For accepted residual risks above `low`, capture the acceptance rationale in `SAFETY-CASE.md` §5
+
+---
+
+## Important
+
+The six hazards above are a **starter set** drawn from common patterns in NHS digital health products. They are not a substitute for project-specific hazard identification by the CSO and clinical SMEs. Many real products have 30–80 hazards in their log after a proper identification workshop. **A short hazard log is more often a sign of insufficient analysis than of a safe product.**
+
+---
+
+**Generated by**: ArcKit `/arckit:uk-nhs-dcb0129` command
+**Generated on**: [YYYY-MM-DD]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
+**Spec lineage**: [Marcus Baw SAFETY.md v2.0.0-draft](https://github.com/pacharanero/SAFETY.md)

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/uk-nhs-dcb0129-safety-template.md

@@ -0,0 +1,78 @@
+# Clinical Safety — [PRODUCT_NAME]
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:uk-nhs-dcb0129` | **Filename**: `SAFETY.md` (DCB0129 manufacturer anchor)
+
+## Document Control
+
+| Field | Value |
+|---|---|
+| **Document ID** | `SAFETY.md` (Marcus Baw SAFETY.md spec convention; no ARC- prefix) |
+| **Document Type** | Clinical Safety Anchor (DCB0129 manufacturer) |
+| **Project** | [PROJECT_NAME] (Project [PROJECT_ID]) |
+| **Classification** | [PUBLIC / OFFICIAL / OFFICIAL-SENSITIVE] |
+| **Status** | DRAFT |
+| **Version** | [VERSION] |
+| **Created Date** | [YYYY-MM-DD] |
+| **Last Modified** | [YYYY-MM-DD] |
+| **Review Cycle** | Quarterly (recommended for active products) |
+| **Next Review Date** | [YYYY-MM-DD] |
+| **Owner** | [OWNER_NAME_AND_ROLE] |
+| **Reviewed By** | [PENDING] |
+| **Approved By** | [PENDING] |
+| **Distribution** | [DISTRIBUTION_LIST] |
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---|---|---|---|---|---|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:uk-nhs-dcb0129` command | PENDING | PENDING |
+
+---
+
+## Required SAFETY.md fields (Marcus Baw SAFETY.md spec v2.0.0)
+
+| Field | Value |
+|---|---|
+| `product-name` | [PRODUCT_NAME] |
+| `version` | [PRODUCT_VERSION] |
+| `standard` | DCB0129 |
+| `clinical-safety-officer` | [PENDING — CSO name and GMC/NMC/HCPC/GPhC registration number] |
+| `organisation` | [MANUFACTURER_LEGAL_ENTITY] |
+| `safety-case-status` | draft |
+| `hazard-log-url` | [./HAZARD-LOG.md](./HAZARD-LOG.md) |
+| `last-reviewed` | [YYYY-MM-DD] |
+
+---
+
+## Summary
+
+[One to two paragraphs: what the product does, intended clinical context, scope of the safety claim, summary of safety approach. Plain English — this is the front door to the safety case for anyone reviewing the product (procurement, CSO, MHRA, NHS England, patients).]
+
+---
+
+## Documents
+
+- [Clinical Safety Case Report](./SAFETY-CASE.md) — the substantive safety argument
+- [Hazard Log](./HAZARD-LOG.md) — the YAML-frontmatter hazard register with rendered table
+- [Clinical Risk Management Plan](./SAFETY-PLAN.md) — *(optional, Tier 3 / SaMD products only — generate manually if needed)*
+
+---
+
+## Tier
+
+This product is assessed as Marcus Baw SAFETY.md **Tier 2** by default (3-file set). Adjust to Tier 1 (consolidate into this single file) for low-risk reference or information-only tools where the CSO judges a separate case + hazard log to be disproportionate. Adjust to Tier 3 (add `SAFETY-PLAN.md`) for SaMD products and any product where the manufacturer needs to evidence a separate Clinical Risk Management Plan to MHRA or a Notified Body.
+
+---
+
+## Important
+
+This document is **not** clinical, legal, or regulatory advice. It is a generated starting point that 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 placed into clinical use.
+
+---
+
+**Generated by**: ArcKit `/arckit:uk-nhs-dcb0129` command
+**Generated on**: [YYYY-MM-DD]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
+**Spec lineage**: [Marcus Baw SAFETY.md v2.0.0-draft](https://github.com/pacharanero/SAFETY.md)

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/uk-nhs-dcb0129-template.md

@@ -0,0 +1,13 @@
+# NHS DCB0129 Clinical Safety Case — Wrapper Template
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:uk-nhs-dcb0129`
+
+This wrapper exists only for `/arckit:customize list` and the documentation site. The actual generated outputs are three files:
+
+1. [`uk-nhs-dcb0129-safety-template.md`](./uk-nhs-dcb0129-safety-template.md) — renders to `clinical-safety/SAFETY.md`
+2. [`uk-nhs-dcb0129-case-template.md`](./uk-nhs-dcb0129-case-template.md) — renders to `clinical-safety/SAFETY-CASE.md`
+3. [`uk-nhs-dcb0129-hazard-template.md`](./uk-nhs-dcb0129-hazard-template.md) — renders to `clinical-safety/HAZARD-LOG.md`
+
+The three files together implement the NHS DCB0129 manufacturer-side documentation expected by NHS England under the Health and Social Care Act 2012 s250. They follow Dr Marcus Baw's [SAFETY.md spec v2.0.0-draft](https://github.com/pacharanero/SAFETY.md) for filenames and YAML-frontmatter structure, prefixed with an ArcKit Document Control block.
+
+To customise: run `/arckit:customize uk-nhs-dcb0129-safety` (or `-case`, or `-hazard`) to copy individual sub-templates into `.arckit/templates-custom/` for editing.

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/uk-nhs-dcb0160-deployment-case-template.md

@@ -0,0 +1,207 @@
+# Deployment Clinical Safety Case Report — [PRODUCT_NAME] at [DEPLOYING_ORGANISATION]
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:uk-nhs-dcb0160` | **Filename**: `DEPLOYMENT-SAFETY-CASE.md` (DCB0160 deployer)
+
+## Document Control
+
+| Field | Value |
+|---|---|
+| **Document ID** | `DEPLOYMENT-SAFETY-CASE.md` (Marcus Baw SAFETY.md spec convention) |
+| **Document Type** | Deployment Clinical Safety Case Report (DCB0160 deployer) |
+| **Project** | [PROJECT_NAME] (Project [PROJECT_ID]) |
+| **Classification** | [OFFICIAL / OFFICIAL-SENSITIVE] |
+| **Status** | DRAFT |
+| **Version** | [VERSION] |
+| **Created Date** | [YYYY-MM-DD] |
+| **Last Modified** | [YYYY-MM-DD] |
+| **Review Cycle** | Quarterly (or on any material deployment / workflow / training change) |
+| **Next Review Date** | [YYYY-MM-DD] |
+| **Owner** | [DEPLOYING_ORGANISATION_PROJECT_OWNER] |
+| **Reviewed By** | [PENDING — deploying-organisation CSO] |
+| **Approved By** | [PENDING — deploying-organisation CSO sign-off in §7 below] |
+| **Distribution** | [DISTRIBUTION_LIST] |
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---|---|---|---|---|---|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:uk-nhs-dcb0160` command | PENDING | PENDING |
+
+---
+
+## 1. Deployment Context
+
+| Field | Value |
+|---|---|
+| **Deploying Organisation** | [NHS Trust / ICS / GP federation / mental health trust / etc.] |
+| **Clinical Service Affected** | [e.g. Paediatric Outpatients, Emergency Department, Primary Care] |
+| **Sites** | [List of sites or sites-pattern; "all sites within X Trust"] |
+| **Patient Population** | [Demographic / clinical population affected] |
+| **Estimated Patient Volume** | [Patients per month / year affected] |
+| **Project Sponsor** | [Executive sponsor at deploying organisation] |
+| **Local Implementation Lead** | [Name / role] |
+| **CSO at Deploying Organisation** | [PENDING — name + GMC/NMC/HCPC/GPhC registration] |
+| **Caldicott Guardian Sign-off** | [PENDING] |
+| **SIRO Sign-off** | [PENDING] |
+
+---
+
+## 2. Scope
+
+### In scope
+
+[Which sites / services / user populations / use cases the deployment covers.]
+
+### Out of scope
+
+[Explicit out-of-scope statements — sites not in this rollout, use cases not in this rollout, legacy systems not being replaced.]
+
+### Phasing
+
+| Phase | Sites | Users | Patient cohort | Go-live | Go / No-Go criteria |
+|---|---|---|---|---|---|
+| Pilot | [site] | [users] | [cohort] | [date] | [criteria] |
+| Wave 1 | | | | | |
+| Wave 2 | | | | | |
+| Full rollout | | | | | |
+
+---
+
+## 3. Manufacturer Case Acceptance
+
+The deploying organisation has reviewed the manufacturer's DCB0129 case at [manufacturer SAFETY-CASE.md link] dated [YYYY-MM-DD] and:
+
+- ☐ Accepts the manufacturer's intended-use statement as applicable to this deployment
+- ☐ Accepts the manufacturer's residual-risk position as documented in §5 of the manufacturer case
+- ☐ Has identified the additional deployment-specific risks in §4 below
+
+If any of the above are NOT acceptable, the deployment is **not safe to proceed** until resolved. Document any disagreements with the manufacturer here, including the resolution path (additional local controls / configuration change / request product change from manufacturer / abandon deployment).
+
+---
+
+## 4. Deployment Safety Argument
+
+Top-level claim:
+
+> **G1: The deployment of [PRODUCT_NAME] at [DEPLOYING_ORGANISATION] is acceptably safe for the affected patient population and clinical workflows, given the manufacturer's case and the local controls documented below.**
+
+Sub-claims:
+
+### G1.1 — Clinicians using the system are adequately trained
+
+Evidence:
+
+- Training plan: [link or describe]
+- Super-user identification and training: [link]
+- Competence assessment before clinical use: [pass criteria]
+- Cross-references: D-HAZ-001 (inadequate training)
+
+### G1.2 — The product integrates safely with existing local clinical workflows
+
+Evidence:
+
+- Workflow mapping with clinical SMEs at the deploying organisation: [link]
+- Integration with parallel systems (EPR, results, prescribing): [list]
+- Handover-of-care points covered: [list]
+- Cross-references: D-HAZ-002 (workflow gap), D-HAZ-003 (integration failure)
+
+### G1.3 — The deployment has adequate business continuity if the product is unavailable
+
+Evidence:
+
+- Manual fallback workflow documented and tested: [link]
+- BC drill evidence: [date / outcome]
+- Cross-references: D-HAZ-004 (BC failure)
+
+### G1.4 — Transition risks from legacy systems are mitigated
+
+Evidence:
+
+- Parallel-running plan: [link]
+- Data migration plan and validation: [link]
+- Legacy decommission plan: [link]
+- Cross-references: D-HAZ-005 (parallel-running confusion), D-HAZ-006 (data migration error)
+
+### G1.5 — Local configuration is correct and verified
+
+Evidence:
+
+- Configuration document: [link]
+- Configuration verification process: [who verifies, against what reference]
+- Cross-references: D-HAZ-007 (configuration error), D-HAZ-008 (terminology/coding mismatch), D-HAZ-009 (RBAC misalignment)
+
+### G1.6 — Local incident reporting and post-deployment monitoring is in place
+
+Evidence:
+
+- Local incident reporting route into Datix / equivalent
+- Cadence of post-deployment monitoring
+- Trigger criteria for hazard log update / safety case revision
+- Cross-references: D-HAZ-010 (failure to learn from incidents)
+
+[Add or remove G-sub-claims to reflect the actual deployment. Each should reference real D-HAZ-IDs in the Deployment Hazard Log.]
+
+---
+
+## 5. Local Evidence
+
+### Local clinical user testing
+
+[Sessions held, clinical roles tested, outcomes summary.]
+
+### Super-user training records
+
+[Number of super-users trained, attendance, competence assessment outcomes.]
+
+### Integration test evidence
+
+[Local integration test plan and outcomes — interface engine, identity, results, prescribing.]
+
+### Parallel-running evidence
+
+[If parallel running with a legacy system, summary of issues found and resolved.]
+
+---
+
+## 6. Residual Deployment Risk
+
+| D-HAZ-ID | Residual Severity | Residual Likelihood | Residual Risk | Justification for acceptance |
+|---|---|---|---|---|
+| D-HAZ-001 | [N] | [N] | [low / medium / high] | [Why this residual risk is acceptable given clinical benefit at this organisation] |
+| ... |  |  |  |  |
+
+### Overall deployment residual risk position
+
+[Deploying organisation CSO's overall judgment that the deployment, with controls in place, is acceptably safe.]
+
+---
+
+## 7. Deploying-Organisation CSO Sign-off
+
+| Field | Value |
+|---|---|
+| **Deploying Organisation** | [DEPLOYING_NHS_ORGANISATION] |
+| **CSO Name** | [PENDING] |
+| **Registration** | [GMC / NMC / HCPC / GPhC number — PENDING] |
+| **Date** | [PENDING] |
+| **Statement** | I am the Clinical Safety Officer at [DEPLOYING_NHS_ORGANISATION]. I have reviewed this Deployment Clinical Safety Case Report and the associated Deployment Hazard Log, and the manufacturer's DCB0129 case it references. I am satisfied that the deployment of [PRODUCT_NAME] in our clinical context, with the local controls documented in this case, is acceptably safe for our patients and clinicians. I approve this deployment safety case. **— [PENDING]** |
+| **Signature** | [PENDING] |
+
+---
+
+## External References
+
+| Doc ID | Title | Source | Used in |
+|---|---|---|---|
+| DCB0160 | Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems | NHS England | This document, throughout |
+| DCB0129 | Manufacturer Clinical Risk Management for Health IT (cross-referenced manufacturer case) | NHS England | §3, throughout |
+| SAFETY-MD-SPEC | SAFETY.md spec v2.0.0-draft | Marcus Baw / pacharanero | Document structure |
+
+---
+
+**Generated by**: ArcKit `/arckit:uk-nhs-dcb0160` command
+**Generated on**: [YYYY-MM-DD]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]
+**Spec lineage**: [Marcus Baw SAFETY.md v2.0.0-draft](https://github.com/pacharanero/SAFETY.md)