arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/.arckit/templates/uk-mdr-classification-template.md

@@ -0,0 +1,307 @@
+# UK MDR + EU MDR Software-as-Medical-Device Classification — [PRODUCT_NAME]
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:uk-mdr-classification`
+
+## Document Control
+
+<!-- DOC-CONTROL-HEADER -->
+<!-- Resolved at command-execution time per _partials/RENDERING.md. -->
+
+## Revision History
+
+| Version | Date | Author | Changes | Approved By | Approval Date |
+|---|---|---|---|---|---|
+| [VERSION] | [YYYY-MM-DD] | ArcKit AI | Initial creation from `/arckit:uk-mdr-classification` command | PENDING | PENDING |
+
+---
+
+## Statutory currency
+
+This assessment is pinned to:
+
+- UK MDR 2002 as amended through the Medical Devices (Amendment) (Great Britain) Regulations 2024 (and any subsequent published amendments at the assessment date below)
+- EU MDR 2017/745 (current text)
+- MHRA Software and AI as a Medical Device Programme — work packages published as of the assessment date below
+
+**Assessment date**: [YYYY-MM-DD]
+
+> The MHRA AIaMD Programme is publishing work packages incrementally. Re-run `/arckit:uk-mdr-classification` when material MHRA updates are published. UK MDR reform is in train — verify the legal text against legislation.gov.uk before reliance.
+
+---
+
+## Executive Summary
+
+| Field | Value |
+|---|---|
+| **Is this product a medical device?** | [Yes / No / Borderline — see §1] |
+| **UK MDR 2002 class (if yes)** | [I / IIa / IIb / III / N/A] |
+| **EU MDR 2017/745 class (if yes)** | [I / IIa / IIb / III / N/A] |
+| **Marking pathway** | [UKCA only / UKCA + UKNI / UKCA + UKNI + CE / CE only via NI / N/A] |
+| **Conformity-assessment route** | [Self-declaration / Approved Body / Notified Body / N/A] |
+| **Quality Management System expectation** | [ISO 13485 / N/A] |
+| **Standards alignment expected** | [ISO 14971, IEC 62304, IEC 62366-1, ISO/IEC 27001, others] |
+
+[One paragraph: classification rationale in plain English, what this means for product placement, recommended next regulatory step.]
+
+---
+
+## 1. Scope determination — is this a medical device?
+
+### 1.1 Intended-purpose statement (verbatim from upstream artefacts)
+
+> [Quote the intended-purpose / intended-use statement from the project's REQ / SAFETY-CASE / similar. This is the load-bearing input. Small wording changes materially change the classification.]
+
+### 1.2 UK MDR 2002 regulation 2 definition test
+
+The product is a medical device if it is intended by the manufacturer to be used for human beings for the purpose of:
+
+- diagnosis, prevention, monitoring, treatment or alleviation of disease
+- diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap
+- investigation, replacement, or modification of the anatomy or of a physiological process
+- control of conception
+
+…and which does not achieve its principal intended action by pharmacological, immunological or metabolic means.
+
+| Test point | Applies? | Notes |
+|---|---|---|
+| Diagnosis / prevention / monitoring / treatment / alleviation of disease | [Yes / No] | |
+| Diagnosis / monitoring / treatment / alleviation / compensation for injury / handicap | [Yes / No] | |
+| Investigation / replacement / modification of anatomy or physiological process | [Yes / No] | |
+| Control of conception | [Yes / No] | |
+| Principal action NOT pharmacological / immunological / metabolic | [Yes / No] | |
+
+### 1.3 MHRA stand-alone software decision tree
+
+| Decision point | Outcome |
+|---|---|
+| Does the software perform an action on data different from storage, archival, communication, simple search? | [Yes / No] |
+| Is the action performed for the benefit of an individual patient? | [Yes / No] |
+| If both Yes → likely medical device (continue to §2). If either No → likely not a medical device (skip to §5). | |
+
+### 1.4 Borderline rationale (if applicable)
+
+[If the case is borderline, document the rationale here, citing the MHRA Borderline Manual examples that are closest. Recommend MHRA pre-submission borderline review. State explicitly that the assessment proceeds on the assumption [Yes / No], and the consequences if MHRA reaches a different conclusion.]
+
+### 1.5 Determination
+
+> **Determination**: This product **[IS / IS NOT / IS BORDERLINE]** a medical device under UK MDR 2002 and EU MDR 2017/745.
+
+If **IS NOT**: skip to §5 (Not-a-medical-device closure).
+If **IS** or **IS BORDERLINE**: continue.
+
+---
+
+## 2. UK MDR 2002 classification
+
+### 2.1 Classification rules applied
+
+[Identify which classification rules from UK MDR 2002 Schedule 9 (as amended) apply. For SaMD, this is typically driven by the corresponding rule on stand-alone software. State the rule + reasoning.]
+
+### 2.2 Determination
+
+> **UK MDR 2002 Class**: [I / IIa / IIb / III]
+
+### 2.3 Subclass flags
+
+| Flag | Applicable? | Rationale |
+|---|---|---|
+| Sterile | [Yes / No / N/A for SaMD] | |
+| Measuring function | [Yes / No] | |
+| Reusable surgical instrument | [Yes / No / N/A for SaMD] | |
+
+### 2.4 Self-certification eligibility
+
+| Eligibility | Status | Notes |
+|---|---|---|
+| Self-certification permitted (Class I, non-sterile, non-measuring) | [Yes / No] | |
+| If self-certified, manufacturer registration with MHRA required | [Yes / N/A] | |
+
+---
+
+## 3. EU MDR 2017/745 classification (for NI placement and EU market access)
+
+### 3.1 Rule 11 application (software)
+
+[Apply Rule 11 with explicit reasoning. Walk through the decision points: does the software provide information used to take decisions with diagnostic / therapeutic purposes? Could those decisions cause death / irreversible deterioration → Class III. Could they cause serious deterioration or surgical intervention → Class IIb. Otherwise → Class IIa. Or: software intended to monitor physiological processes → Class IIa, except monitoring of vital physiological parameters where variations could cause immediate danger → Class IIb. All other software → Class I.]
+
+### 3.2 Other rules considered
+
+[If any other classification rule applies (e.g. rule for software intended to drive or influence active device, rule for software involving liquids in contact with human body), state the rule and outcome.]
+
+### 3.3 Determination
+
+> **EU MDR 2017/745 Class**: [I / IIa / IIb / III]
+
+### 3.4 Divergence from UK MDR
+
+| | UK MDR 2002 | EU MDR 2017/745 |
+|---|---|---|
+| Class | [Class] | [Class] |
+| Conformity route | [Route] | [Route] |
+| Marking | UKCA | CE (or UKNI for NI) |
+
+[If the two classifications diverge, explain why and which is more conservative.]
+
+---
+
+## 4. Marking pathway
+
+| Pathway | Required? | Conditions |
+|---|---|---|
+| **UKCA marking** (Great Britain placement) | [Yes / No] | MHRA registration; Approved Body involvement if Class IIa+ |
+| **UKNI marking** (Northern Ireland placement of GB-manufactured) | [Yes / No / N/A] | Notified Body involvement required; UKNI alone not valid in rest of EU |
+| **CE marking** (NI placement under Windsor Framework + EU market access) | [Yes / No] | Notified Body in NI or EU; EUDAMED registration |
+| **Recognition of CE marking in GB** (transitional) | [Applicable / Not applicable] | Transitional arrangements have moved repeatedly — verify against MHRA |
+
+### 4.1 Recommended routing
+
+[State the practical routing for this product given its intended markets. E.g. "UKCA + CE for full UK + EU coverage", "UKCA only for GB-only product", "UKCA + UKNI for UK-only product including NI".]
+
+### 4.2 Registration obligations
+
+| Obligation | Status | Notes |
+|---|---|---|
+| MHRA Device Online Registration System (DORS) | [In place / PENDING] | |
+| EUDAMED registration (if CE-marked) | [In place / PENDING] | |
+| UK Responsible Person (if non-UK manufacturer) | [Appointed / PENDING / N/A] | |
+| EU Authorised Representative (if non-EU manufacturer with CE) | [Appointed / PENDING / N/A] | |
+
+---
+
+## 5. Conformity-assessment route
+
+| Class | UK route | EU route |
+|---|---|---|
+| Class I (non-sterile, non-measuring) | Self-declaration | Self-declaration |
+| Class I (sterile / measuring / reusable surgical) | Approved Body | Notified Body |
+| Class IIa | Approved Body | Notified Body |
+| Class IIb | Approved Body | Notified Body |
+| Class III | Approved Body | Notified Body |
+
+| Conformity item | Status | Notes |
+|---|---|---|
+| Technical documentation prepared | [PASS / FAIL / PENDING] | Annex II / Annex III equivalents |
+| Quality Management System (ISO 13485) | [PASS / FAIL / PENDING] | Required for non-Class I; signposted not generated here |
+| Clinical evaluation | [PASS / FAIL / PENDING] | Literature route / clinical investigation / PMCF |
+| Declaration of Conformity | [PASS / FAIL / PENDING] | |
+
+### Not-a-medical-device closure (only if §1 reached IS NOT)
+
+[Provide the explicit reasoning that this product is not a medical device, citing the MHRA Borderline Manual example closest to this product. Identify the responsible person at the manufacturer who signs off this determination. Record that the manufacturer will not place this product as a medical device and will not represent it as such in marketing or instructions.]
+
+---
+
+## 6. MHRA SaMD / AIaMD Programme considerations
+
+| MHRA AIaMD Programme Work Package | Applicable to this product? | Status / commitment |
+|---|---|---|
+| WP1 Software | [Yes / N/A] | |
+| WP2 Risk classification | [Yes / N/A] | |
+| WP3 Innovative devices | [Yes / N/A] | |
+| WP4 Cyber Security | [Yes / N/A] | |
+| WP6 AIaMD | [Yes / N/A — if AI/ML] | |
+| WP9 Cyber Security (AI specific) | [Yes / N/A] | |
+| WP11 Best Practice for Manufacturers | [Yes / N/A] | |
+
+[Update WP list and status from the MHRA SaMD/AIaMD page at assessment date; the programme is publishing incrementally.]
+
+---
+
+## 7. Standards alignment
+
+| Standard | Applicable? | Status | Notes |
+|---|---|---|---|
+| ISO 14971 (risk management) | Yes | [PASS / FAIL / PENDING] | Cross-reference DCB0129 hazard log at `clinical-safety/HAZARD-LOG.md` |
+| IEC 62304 (software lifecycle) | Yes | [PASS / FAIL / PENDING] | Software safety class A / B / C from hazard analysis: [class] |
+| ISO 13485 (QMS) | [If Class IIa+ or chosen for Class I] | [PASS / FAIL / PENDING] | Signposted only |
+| IEC 62366-1 (usability engineering) | [If safety-critical UI] | [PASS / FAIL / PENDING] | |
+| ISO/IEC 27001 (information security) | Yes | [PASS / FAIL / PENDING] | Cross-reference `/arckit:secure` output |
+| ISO/IEC 25010 (software quality) | Recommended | [PASS / FAIL / PENDING] | |
+| ISO/IEC TR 24028 (AI trustworthiness) | [If AIaMD] | [PASS / FAIL / PENDING] | |
+| BS EN 82304-1 (health software) | Recommended | [PASS / FAIL / PENDING] | |
+
+---
+
+## 8. Post-market obligations
+
+### 8.1 Post-market surveillance (PMS) plan
+
+[Outline the PMS plan: data sources, cadence, escalation triggers, reporting cadence. Required for all classes; depth scales with class.]
+
+### 8.2 Vigilance reporting
+
+| Event | Reporting timeline | Recipient |
+|---|---|---|
+| Serious incident (UK) | Within 10 days (15 for non-serious public health concern) | MHRA |
+| Serious incident (EU) | Within 15 days (10 for serious public-health threat; 2 for death/serious deterioration) | Competent Authority via EUDAMED |
+| Field Safety Corrective Action (FSCA) | Without undue delay | MHRA / Competent Authority |
+
+### 8.3 Periodic Safety Update Report (PSUR)
+
+| Class | Cadence |
+|---|---|
+| Class III | Annual |
+| Class IIa / IIb | Biennial (Class IIa, on request); biennial (Class IIb) — verify against EU MDR Article 86 |
+| Class I | Not required (but PMS report under EU MDR Article 85 is) |
+
+### 8.4 Trend reporting
+
+[State the trend-reporting approach for statistically significant increases in non-serious incidents.]
+
+### 8.5 AIaMD substantial-change handling (if AI)
+
+[For AI products, the line between "expected adaptation" and "substantial change requiring reassessment" is regulator-defined. State the threshold, the monitoring approach, and the change-control process.]
+
+---
+
+## 9. Substantial change triggers
+
+| Trigger | Action | Notes |
+|---|---|---|
+| Change of intended purpose | Reassess classification | Material risk of class change |
+| New clinical indication | Reassess classification and clinical evaluation | |
+| Change of risk profile | Reassess risk file (ISO 14971) and clinical evaluation | |
+| Change of intended-user population | Reassess usability evaluation and clinical evaluation | |
+| Change of intended patient population | Reassess clinical evaluation | |
+| Change of operating principle (e.g. rule-based → ML) | Reassess software safety class and AIaMD applicability | |
+
+---
+
+## 10. Open regulatory risks
+
+| Risk | Status | Mitigation |
+|---|---|---|
+| MHRA reform of UK MDR is in flight | Active | Pin assessment date; subscribe to MHRA news; re-run on material change |
+| CE-marking recognition in GB has moved repeatedly | Active | Verify against MHRA news at every product release |
+| MHRA AIaMD Programme publishing incrementally | Active | Re-run on each new WP publication that may apply |
+| Windsor Framework arrangements may change | Monitor | Check NI placement route at each release |
+
+---
+
+## External References
+
+| Doc ID | Title | Source | Used in |
+|---|---|---|---|
+| UK-MDR-2002 | Medical Devices Regulations 2002 (as amended) | legislation.gov.uk | Throughout |
+| EU-MDR-2017-745 | EU MDR 2017/745 | EUR-Lex | §3 |
+| MHRA-SAMD | MHRA Guidance on Medical Device Stand-Alone Software | MHRA | §1 |
+| MHRA-AIAMD | MHRA Software and AI as a Medical Device Programme | MHRA | §6 |
+| MHRA-BORDERLINE | MHRA Borderline Manual | MHRA | §1.4 (if borderline) |
+| ISO-14971 | Application of risk management to medical devices | BSI | §7 |
+| IEC-62304 | Medical-device software lifecycle | BSI | §7 |
+| ISO-13485 | Medical-device QMS | BSI | §7 |
+| IEC-62366-1 | Usability engineering for medical devices | BSI | §7 (if applicable) |
+
+---
+
+## Important
+
+This classification assessment is **not** regulatory advice. The output MUST be reviewed and signed off by a qualified Regulatory Affairs Specialist or notified-body / approved-body advisor before being used to make product, procurement, or market-access decisions. Misclassification has material legal, commercial, and patient-safety consequences.
+
+---
+
+**Generated by**: ArcKit `/arckit:uk-mdr-classification` command
+**Generated on**: [YYYY-MM-DD]
+**ArcKit Version**: [VERSION]
+**Project**: [PROJECT_NAME]
+**Model**: [AI_MODEL]

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

@@ -0,0 +1,214 @@
+# Clinical Safety Case Report — [PRODUCT_NAME]
+
+> **Template Origin**: Community | **ArcKit Version**: [VERSION] | **Command**: `/arckit:uk-nhs-dcb0129` | **Filename**: `SAFETY-CASE.md` (DCB0129 manufacturer case)
+
+## Document Control
+
+| Field | Value |
+|---|---|
+| **Document ID** | `SAFETY-CASE.md` (Marcus Baw SAFETY.md spec convention; no ARC- prefix) |
+| **Document Type** | Clinical Safety Case Report (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** | Quarterly (recommended); on every material product change |
+| **Next Review Date** | [YYYY-MM-DD] |
+| **Owner** | [PRODUCT_OWNER_NAME_AND_ROLE] |
+| **Reviewed By** | [PENDING — CSO] |
+| **Approved By** | [PENDING — CSO sign-off in §6 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-dcb0129` command | PENDING | PENDING |
+
+---
+
+## Risk scoring scales (DCB0129 convention)
+
+| Scale | 1 | 2 | 3 | 4 | 5 |
+|---|---|---|---|---|---|
+| **Severity** | Catastrophic | Major | Considerable | Significant | Minor |
+| **Likelihood** | Very High | High | Medium | Low | Very Low |
+
+**Risk levels**: `unacceptable` · `high` · `medium` · `low`
+**Hazard status**: `open` · `mitigated` · `accepted` · `closed`
+
+> ⚠️ DCB0129 inverts the usual Orange Book convention where 5 = highest. Read carefully when cross-referencing project risk registers.
+
+---
+
+## 1. Intended Use
+
+[State the product's clinical purpose, indications, contraindications, intended user population (specific clinical roles, patient populations), and intended clinical context. Be precise — the intended-use statement is load-bearing for medical-device classification (`/arckit:uk-mdr-classification`) and for clinical-safety scope.]
+
+### What this product is
+
+[Describe the product in plain English. One paragraph.]
+
+### What this product is not
+
+[Explicit out-of-scope statements. Lists what this product does *not* do, *not* claim, and is *not* intended for. Pre-empts misuse claims.]
+
+### Intended users
+
+[Specific clinical roles — e.g. "registered medical practitioners in NHS secondary care", "registered children's nurses in NHS paediatric inpatient settings". Avoid "any clinician".]
+
+### Intended patient population
+
+[Specific patient population — age range, condition, care setting.]
+
+### Intended clinical context
+
+[Specific clinical setting — inpatient / outpatient / community / home; acute / chronic / preventive; emergency / planned.]
+
+---
+
+## 2. Scope
+
+### In scope for this safety case
+
+[What clinical activities and product features are covered by this safety case.]
+
+### Out of scope for this safety case
+
+[What is explicitly NOT covered. Often includes: deployment-specific arrangements (covered by DCB0160), third-party integrations not maintained by the manufacturer, off-label clinical uses.]
+
+### Deployment assumptions
+
+[What the manufacturer assumes about the deployment environment. These assumptions become the obligations on the deploying organisation's DCB0160 case.]
+
+---
+
+## 3. Safety Argument
+
+Top-level claim:
+
+> **G1: [PRODUCT_NAME] is acceptably safe for use by [intended users] in [intended clinical context] when used as intended.**
+
+This claim is supported by the sub-claims below. Each sub-claim references hazards (H-ID) from the [Hazard Log](./HAZARD-LOG.md) and the controls (C-ID) that mitigate them.
+
+### G1.1 — Clinical hazards are systematically identified and managed
+
+Evidence:
+
+- Hazard identification workshops with clinical SMEs ([list dates / participants])
+- Hazard Log [HAZARD-LOG.md](./HAZARD-LOG.md) maintained as a living document
+- Cross-referenced with the project risk register and DPIA where overlap exists
+
+### G1.2 — Identified hazards are reduced to acceptable residual risk
+
+Evidence:
+
+- Each hazard in the Hazard Log has documented controls (C-IDs)
+- Residual-risk severity × likelihood reassessed after controls
+- Residual `unacceptable` and `high` risks have explicit CSO acceptance with justification
+
+### G1.3 — Clinical decisions made by users of the product are based on accurate, current, and relevant data
+
+Evidence:
+
+- [Identity-matching controls — reference H-IDs]
+- [Data-currency controls — reference H-IDs]
+- [Source-of-truth controls — reference H-IDs]
+
+### G1.4 — The product fails safely
+
+Evidence:
+
+- [Graceful-degradation behaviour — reference H-IDs]
+- [Fallback to safe states under failure — reference H-IDs]
+- [Notification of failure to clinicians — reference H-IDs]
+
+### G1.5 — Misuse is mitigated by design
+
+Evidence:
+
+- [Usability engineering evidence per IEC 62366-1 if applicable]
+- [Authorisation / role-based access design]
+- [In-context warnings and decision support]
+
+### G1.6 — Clinical workflow integration is safe
+
+Evidence:
+
+- [Workflow analysis with clinical SMEs]
+- [Integration test evidence]
+- [Training-and-deployment guidance to deploying organisations]
+
+[Add or remove G-sub-claims to reflect the actual product. Each should reference real H-IDs in the Hazard Log.]
+
+---
+
+## 4. Evidence
+
+### Testing strategy
+
+[Summary of the testing approach: unit / integration / system / clinical-acceptance. Reference the V&V plan if one exists.]
+
+### Clinical validation
+
+[Clinical evaluation evidence: literature review, retrospective evaluation, prospective study, clinical investigation. State the level of evidence available.]
+
+### Usability evidence (IEC 62366-1 alignment, if applicable)
+
+[Formative and summative usability evaluation evidence.]
+
+### Real-world performance monitoring
+
+[Post-deployment monitoring plan — what metrics, what cadence, what triggers a hazard log update.]
+
+---
+
+## 5. Residual Risk
+
+### Accepted residual risks
+
+| H-ID | Residual Severity | Residual Likelihood | Residual Risk | Justification for acceptance |
+|---|---|---|---|---|
+| H001 | [N] | [N] | [low / medium / high] | [Why this residual risk is acceptable given clinical benefit] |
+| ... |  |  |  |  |
+
+[Each accepted residual risk above `low` requires explicit CSO sign-off with justification proportionate to the residual severity.]
+
+### Overall residual risk position
+
+[CSO's overall judgment that the product, with controls in place, is acceptably safe for its intended use. One paragraph.]
+
+---
+
+## 6. CSO Sign-off
+
+| Field | Value |
+|---|---|
+| **CSO Name** | [PENDING] |
+| **Registration** | [GMC / NMC / HCPC / GPhC number — PENDING] |
+| **Date** | [PENDING] |
+| **Statement** | I have reviewed this Clinical Safety Case Report and the associated Hazard Log. I am satisfied that the clinical hazards have been systematically identified and that residual risks are at an acceptable level given the intended clinical benefit of the product. I approve this safety case. **— [PENDING]** |
+| **Signature** | [PENDING] |
+
+---
+
+## External References
+
+| Doc ID | Title | Source | Used in |
+|---|---|---|---|
+| DCB0129 | Clinical Risk Management: its Application in the Manufacture of Health IT Systems | NHS England | This document, throughout |
+| SAFETY-MD-SPEC | SAFETY.md spec v2.0.0-draft | Marcus Baw / pacharanero | Document structure, hazard-log YAML format |
+| ISO-14971 | Application of risk management to medical devices | BSI | §1, §3, §5 (cross-referenced with `uk-mdr-classification` if applicable) |
+| IEC-62304 | Medical-device software lifecycle processes | BSI | §1, §4 (cross-referenced with `uk-mdr-classification` if applicable) |
+| IEC-62366-1 | Application of usability engineering to medical devices | BSI | §3 G1.5, §4 |
+
+---
+
+**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)