@connexum/ai-governance 1.0.0-beta.11

package/dist/esm/packs/iso-iec-80001.js

@@ -0,0 +1,993 @@
+/**
+ * ISO/IEC 80001 Medical IT Network Risk Management Compliance Pack
+ *
+ * ISO/IEC 80001 (multipart family) addresses the application of risk management
+ * to IT-networks incorporating medical devices. This is distinct from IEC 62304
+ * (which governs medical-device SOFTWARE DEVELOPMENT lifecycle) — 80001 governs
+ * the DEPLOYMENT, OPERATION, and MAINTENANCE of medical devices on hospital and
+ * health-system IT networks throughout their operational lifecycle.
+ *
+ * Multipart family structure:
+ *   80001-1:2021  — General principles + risk management process (main part;
+ *                   4th edition supersedes 80001-1:2010)
+ *   80001-2-1:2012 — Step-by-step risk management application guide
+ *   80001-2-2:2012 — Guidance for the communication of medical device security
+ *                   needs, risks, and controls (SECURITY capabilities template)
+ *   80001-2-3:2012 — Guidance for wireless networks
+ *   80001-2-4:2015 — General implementation guidance for healthcare delivery
+ *                   organizations
+ *   80001-2-5:2014 — Application guidance — Guidance for distributed alarm
+ *                   systems
+ *   80001-2-6:2014 — Application guidance — Guidance for use of the IHE
+ *                   Audit Trail and Node Authentication (ATNA) Profile
+ *
+ * Jointly published by ISO/IEC JTC 1 (Information technology) and IEC TC 62/SC 62A
+ * (Common aspects of electrical equipment used in medical practice). Recognized by:
+ *   - US FDA (Medical Device Cybersecurity guidance — aligns with 80001-2-2 SECURE)
+ *   - MHRA (UK Medicines and Healthcare products Regulatory Agency)
+ *   - Health Canada (Medical Devices Directorate)
+ *   - TGA (Australian Therapeutic Goods Administration)
+ *   - BSI (British Standards Institution)
+ *   - National health-system regulators in EU/EFTA states (aligned with NIS2 for
+ *     health sector)
+ *
+ * Alignment with sister standards:
+ *   - ISO 14971:2019 — Medical devices: Application of risk management (the
+ *     foundational medical device risk standard; 80001 extends 14971 from device-
+ *     intrinsic risk to NETWORK-mediated risk)
+ *   - ISO 27799:2016 — Health informatics: information security management
+ *     (implements ISO/IEC 27002 in health context; pairs with 80001-2-2)
+ *   - IEC 62304:2015 — Medical device software lifecycle (device-side software;
+ *     complementary, not overlapping)
+ *   - FDA 21 CFR 820 (QMSR) — quality system requirements for medical devices
+ *   - HIPAA 45 CFR §164 — Protected Health Information (US context)
+ *   - GDPR Art. 9 — special-category health data (EU context)
+ *
+ * THREE KEY PROPERTIES that risk management must preserve (§4.2):
+ *   1. SAFETY       — protection from patient harm caused by network-mediated failure
+ *   2. EFFECTIVENESS — medical purpose (device's intended function) still achieved
+ *   3. DATA + SYSTEM SECURITY — integrity, availability, and confidentiality of
+ *                    clinical data and system function (often abbreviated D&SS)
+ *
+ * Per the standard's core principle: every medical device added to the medical IT
+ * network requires a formal risk assessment documenting the impact on all three KEY
+ * PROPERTIES, residual risk documentation, and ongoing monitoring through the
+ * device's operational lifecycle on the network.
+ *
+ * Roles defined in 80001-1:2021 §5:
+ *   Responsible Organization (RO) — the health delivery organization (hospital /
+ *     health system) that deploys and operates the medical IT network. Bears
+ *     ultimate accountability for risk management.
+ *   Medical IT-Network Risk Manager (MITN-RM) — designated individual within the
+ *     RO who owns the risk management process and has documented authority over
+ *     change management decisions. Required by §5.
+ *   Medical Device Manufacturer — provides device-specific security capabilities
+ *     documentation per 80001-2-2 (the MDS2 form / SECURE template).
+ *   IT Operator — the IT department or MSP operating the network infrastructure.
+ *
+ * Responsibility Agreements (§6):
+ *   Formal documented agreements between the RO, the medical device manufacturer,
+ *   and the IT operator covering: risk ownership boundaries, security capabilities
+ *   communication, change notification obligations, and incident notification.
+ *
+ * Patient-record retention:
+ *   20-year baseline (7300 days) — medical-device network records must be retained
+ *   for the lifetime of clinical decisions supported by devices on the network.
+ *   Aligned with cross-jurisdictional medical record retention: US HIPAA/CMS
+ *   (minimum 10 years; some state laws require 20 years for adult records);
+ *   EU GDPR + national law (10-30 years for clinical records depending on
+ *   jurisdiction — NHS England 20 years, Germany §630f BGB 10 years, France
+ *   20 years); Australia Health Records Acts (7-10 years adults). Conservative
+ *   20-year cross-jurisdictional baseline for health-system clinical-network records.
+ *
+ * Incident notification:
+ *   72-hour baseline (3 days) — cross-jurisdictional most-restrictive baseline for
+ *   medical-device network incidents: GDPR Art. 33 (72h supervisory authority
+ *   breach notification for health data); HIPAA 45 CFR §164.412 (60 days but
+ *   most state breach laws require 30-72h; FDA adverse event reporting
+ *   MDR — 30-day routine / 5-day if immediately needs corrective action);
+ *   NIS2 Art. 23 (24h early warning, 72h notification for health-sector incidents);
+ *   ISO/IEC 80001-1:2021 §9 (incident management — notify medical device
+ *   manufacturer + RO patient safety officer without undue delay). 72h is the
+ *   most-restrictive cross-jurisdictional formal notification baseline.
+ *
+ * @connexum/ai-governance
+ */
+/**
+ * ISO/IEC 80001 Medical IT Network Risk Management category classifiers.
+ *
+ * Covers medical IT network risk management artefacts:
+ *   - Key property impact events (safety / effectiveness / data+system security)
+ *   - Medical device network change records requiring pre-change risk assessment
+ *   - Responsibility Agreement records between RO, device manufacturer, IT operator
+ *   - Medical device network incident records
+ *   - Security capabilities (MDS2/SECURE template) records per 80001-2-2
+ */
+export const ISO_IEC_80001_CATEGORY_CLASSIFIERS = {
+    /**
+     * KEY_PROPERTY_IMPACT_EVENT — Impact to any of the three KEY PROPERTIES
+     * (Safety, Effectiveness, Data + System Security) on the medical IT network.
+     * Any key property impact event is an ABSOLUTE CRITICAL BLOCK on all network
+     * changes until formally resolved by MITN-RM + patient-safety-officer
+     * attestation. Triggers immediate escalation to all 6 required recipients.
+     */
+    KEY_PROPERTY_IMPACT_EVENT: {
+        references: [
+            'ISO/IEC 80001-1:2021 §4.2.1 — Key Property: Safety',
+            'ISO/IEC 80001-1:2021 §4.2.2 — Key Property: Effectiveness',
+            'ISO/IEC 80001-1:2021 §4.2.3 — Key Property: Data + System Security',
+        ],
+        classifier: (input) => {
+            if (/\b(?:key[_\s-]property[_\s-]impact|safety[_\s-]key[_\s-]property|effectiveness[_\s-]key[_\s-]property|data[_\s-]system[_\s-]security[_\s-]impact)\b/i.test(input))
+                return true;
+            if (/\b(?:network[_\s-]mediated[_\s-](?:failure|harm|risk)|medical[_\s-]device[_\s-](?:connectivity[_\s-]loss|network[_\s-]failure|alarm[_\s-]failure))\b/i.test(input))
+                return true;
+            if (/\b(?:key_property_impact|safety_key_property|effectiveness_key_property|d_and_ss_impact|mitn[_\s-]rm[_\s-]escalation)\b/i.test(input))
+                return true;
+            if (/\b(?:iso80001[_\s-]impact|80001[_\s-]safety[_\s-]event|80001[_\s-]key[_\s-]property)\b/i.test(input))
+                return true;
+            return false;
+        },
+    },
+    /**
+     * MEDICAL_DEVICE_NETWORK_EVENT — Medical device connectivity events, device
+     * integration records, and device inventory changes on the medical IT network.
+     * New device integrations require pre-change risk assessment and MITN-RM
+     * approval before connection. Device connectivity events are monitored for
+     * key property impact signals.
+     */
+    MEDICAL_DEVICE_NETWORK_EVENT: {
+        references: [
+            'ISO/IEC 80001-1:2021 §7 — Medical device inventory',
+            'ISO/IEC 80001-1:2021 §8 — Change management on the medical IT network',
+            'ISO/IEC 80001-2-2 — Security capabilities communication',
+        ],
+        classifier: (input) => {
+            if (/\b(?:medical[_\s-]device[_\s-](?:network|integration|inventory|connectivity)|medical[_\s-]it[_\s-]network)\b/i.test(input))
+                return true;
+            if (/\b(?:mitn[_\s-]rm|mitnrm|medical[_\s-]it[_\s-]network[_\s-]risk[_\s-]manager|responsibility[_\s-]agreement)\b/i.test(input))
+                return true;
+            if (/\b(?:mds2|secure[_\s-]template|80001[_\s-](?:device|network|change|incident)|iso80001[_\s-]record)\b/i.test(input))
+                return true;
+            if (/\b(?:hospital[_\s-]it[_\s-]network|clinical[_\s-]network[_\s-](?:change|event|incident)|biomedical[_\s-]engineering[_\s-]network)\b/i.test(input))
+                return true;
+            return false;
+        },
+    },
+};
+/**
+ * ISO/IEC 80001 Medical IT Network Risk Management Compliance Pack.
+ *
+ * Pack ID: 'iso-iec-80001'
+ * Jurisdiction: International — ISO + IEC joint standard; recognized by FDA (US),
+ *   MHRA (UK), Health Canada, TGA (AU), national health-system regulators (EU/EFTA).
+ *   Aligned with ISO 14971 (medical-device risk), ISO 27799 (health informatics
+ *   security), and NIST SP 800-82 (OT cybersecurity).
+ *
+ * Guard-layer wiring:
+ *   - G1-G4 (audit, logging, classification, session): always active
+ *   - G5 (supply-chain): always active — PRC provider blocks; medical device vendor
+ *       qualification via Responsibility Agreements; network integrator qualification
+ *   - G6 (approval-queue): always active — pre-change risk assessment approval;
+ *       network change management gate (§8); key property impact resolution
+ *       approval (MITN-RM + patient-safety-officer sign-off mandatory)
+ *   - G7 (attestation): always active — MITN-RM attestation for change management
+ *       decisions; medical device vendor attestation for security capabilities
+ *       (80001-2-2 SECURE template); Responsibility Agreement counter-signatures
+ *   - G8 (anomaly-detector): always active — key property impact detection
+ *       (safety / effectiveness / security degradation signals); immediate CRITICAL
+ *       escalation to patient-safety-officer when key property impact detected;
+ *       network monitoring + event handling per §9 + 80001-2-2 §6
+ *   - G9 (transparency): always active — AI-generated network risk assessments
+ *       must be disclosed + reviewed by MITN-RM + biomedical-engineering-lead;
+ *       AI-assisted distributed alarm system monitoring must disclose model
+ *       provenance (80001-2-5 alignment)
+ *
+ * Human-in-loop tier:
+ *   - T1: Routine network monitoring events, device inventory updates, standard
+ *         risk register updates (MITN-RM + clinical-network-engineer review)
+ *   - T2: Responsibility Agreement changes, security capability updates (80001-2-2),
+ *         wireless network configuration changes (80001-2-3), new device classes
+ *         (biomedical-engineering-lead + MITN-RM + cybersecurity-incident-coordinator)
+ *   - T3: Key property impact events (any of safety / effectiveness / security
+ *         degraded — immediate: MITN-RM + patient-safety-officer + hospital-cio +
+ *         medical-device-vendor-liaison + cybersecurity-incident-coordinator)
+ */
+export const ISO_IEC_80001_PACK = {
+    categoryClassifiers: ISO_IEC_80001_CATEGORY_CLASSIFIERS,
+    /**
+     * Key property impact events and medical device network events are subject-keyed
+     * per device identifier / network segment — traceability to specific medical
+     * devices and network segments is mandatory for ISO/IEC 80001-1:2021 §7
+     * inventory accuracy and §8 change management audit trail accountability.
+     */
+    subjectKeyedCategories: [
+        'KEY_PROPERTY_IMPACT_EVENT',
+        'MEDICAL_DEVICE_NETWORK_EVENT',
+    ],
+    id: 'iso-iec-80001',
+    aliases: ['iso80001', 'medical-it-network', 'hospital-it-risk'],
+    name: 'ISO/IEC 80001 Medical IT Network Risk Management',
+    version: '1.0.0',
+    description: 'ISO/IEC 80001 multipart family — risk management for IT-networks incorporating medical ' +
+        'devices. Distinct from IEC 62304 (medical-device SOFTWARE development lifecycle) — 80001 ' +
+        'governs DEPLOYMENT, OPERATION, and MAINTENANCE of medical devices on hospital/health-system ' +
+        'IT networks. Multipart structure: 80001-1:2021 (general principles + risk management process), ' +
+        '80001-2-1:2012 (step-by-step risk management), 80001-2-2:2012 (security capabilities — ' +
+        'SECURE template / MDS2 form), 80001-2-3:2012 (wireless networks), 80001-2-5:2014 (distributed ' +
+        'alarm systems). Three KEY PROPERTIES that risk management must preserve per §4.2: (1) SAFETY — ' +
+        'no patient harm from network-mediated failure; (2) EFFECTIVENESS — medical purpose still ' +
+        'achieved; (3) DATA + SYSTEM SECURITY — integrity, availability, confidentiality of clinical ' +
+        'data + system function. Every medical device added to the network → formal risk assessment ' +
+        'of impact on all three KEY PROPERTIES → residual risk documentation → operational lifecycle ' +
+        'monitoring. Required roles: Responsible Organization (RO — the hospital/health system), ' +
+        'designated Medical IT-Network Risk Manager (MITN-RM per §5), Medical Device Manufacturer ' +
+        '(security capabilities provider per 80001-2-2), IT Operator. Responsibility Agreements §6: ' +
+        'formal documented agreements covering risk ownership, change notification, incident obligations. ' +
+        'CRITICAL behavioral validator for key-property-impact detected — immediate escalation, no ' +
+        'compensating control path. 20-year patient-record retention (7300 days). 72h cross-jurisdictional ' +
+        'incident notification deadline. Reviewer tier: AAMI / ISA / HIMSS-CPHIMS / health-system ' +
+        'biomedical-engineering qualified. Pack pairings: IEC 62304 (device software dev), FDA 21 CFR ' +
+        '820 (QSR/QMSR), ISO 14971 (medical-device risk), ISO 27799 (health informatics security), ' +
+        'HIPAA (US PHI), GDPR (EU patient data), NIST SP 800-66 (HIPAA Security Rule implementation), ' +
+        'NIST SP 800-82 (OT — for industrial-class hospital systems). PRC providers blocked: ' +
+        'ISO/IEC 80001-2-2 security-capabilities requirements for clinical IT networks handling PHI ' +
+        'are incompatible with PRC data localisation law (CSL/DSL/PIPL).',
+    authority: 'ISO + IEC joint technical committee (ISO/IEC JTC 1 + IEC TC 62/SC 62A); recognized by FDA, ' +
+        'MHRA, Health Canada, TGA + national health-system regulators; aligned with ISO 14971 ' +
+        '(medical-device risk management) + ISO 27799 (health informatics security)',
+    industries: [
+        'hospital-it',
+        'health-system-network',
+        'integrated-care-delivery',
+        'biomedical-engineering',
+        'medical-device-system-integrator',
+        'connected-care',
+        'clinical-network-engineering',
+    ],
+    requiredModules: [
+        {
+            name: 'governance-runtime',
+            required: true,
+            reason: 'ISO/IEC 80001-1:2021 §4.2 (Three KEY PROPERTIES) enforcement mandatory for all AI ' +
+                'operations on medical IT networks: SAFETY (no patient harm from network-mediated failure), ' +
+                'EFFECTIVENESS (medical purpose still achieved), DATA + SYSTEM SECURITY (integrity, ' +
+                'availability, confidentiality). Any AI agent operating on or monitoring a medical IT ' +
+                'network must enforce immediate escalation when a key property impact is detected — no ' +
+                'compensating control path, no bypass. Designated Medical IT-Network Risk Manager (MITN-RM) ' +
+                'per §5 must be actively configured and accessible for all risk management decisions. ' +
+                'Responsibility Agreements §6: formal agreements between RO, device manufacturer, and IT ' +
+                'operator must be in place before new devices are connected — AI-assisted network change ' +
+                'management must verify agreement existence before approving integration. Pre-change risk ' +
+                'assessment §8: every network change affecting medical devices requires pre-change risk ' +
+                'assessment with MITN-RM approval before implementation. ISO 14971 alignment §4.4: ' +
+                'risk management process must align with ISO 14971 (probability × severity × detectability ' +
+                'risk estimation). Monitoring and event handling §9 + 80001-2-2 §6: continuous monitoring ' +
+                'of the three KEY PROPERTIES with event detection and escalation routing.',
+            reference: 'ISO/IEC 80001-1:2021 §4.2 Key Properties; §5 Roles + Responsibilities (MITN-RM); ' +
+                '§6 Responsibility Agreements; §7 Network device inventory; §8 Change management; ' +
+                '§9 Incident + monitoring; 80001-2-2 Security capabilities; 80001-2-3 Wireless; ' +
+                '80001-2-5 Distributed alarm systems; §4.4 ISO 14971 alignment',
+        },
+        {
+            name: 'audit-integrity',
+            required: true,
+            reason: 'Tamper-evident records for medical IT network critical artefacts: risk management ' +
+                'records for every medical device on the network (80001-1 §7 — device inventory + risk ' +
+                'assessment records + residual risk acceptability decisions; required for accreditation ' +
+                'inspection and regulatory audit by FDA / MHRA / Health Canada / TGA); Responsibility ' +
+                'Agreement records (§6 — signed agreements between RO, medical device manufacturer, ' +
+                'IT operator; version history required); change management records (§8 — pre-change ' +
+                'risk assessment, approval chain, implementation record, post-change verification); ' +
+                'incident records (§9 — incident reports, root cause analysis, corrective action, ' +
+                'closure verification; key property impact incidents require auditable chain from ' +
+                'detection through resolution + vendor liaison confirmation); security capabilities ' +
+                'records per 80001-2-2 (MDS2 / SECURE template submissions from device manufacturers; ' +
+                'version history as device software is updated); distributed alarm system configuration ' +
+                'records per 80001-2-5 (alarm routing logic, escalation paths, test records). ' +
+                '20-year baseline (7300 days) for cross-jurisdictional health-system record retention.',
+            reference: 'ISO/IEC 80001-1:2021 §6 Responsibility Agreement records; §7 Device inventory records; ' +
+                '§8 Change management audit trail; §9 Incident records; ' +
+                '80001-2-2 Security capabilities documentation; 80001-2-5 Alarm system records; ' +
+                'HIPAA 45 CFR §164.530(j) records retention; GDPR Art. 5(2) accountability records',
+        },
+        {
+            name: 'data-classifier',
+            required: true,
+            reason: 'Medical IT network PHI and clinical-signal classification: patient-identifiable data ' +
+                'transmitted over the medical IT network (HIPAA PHI — 45 CFR §164.514; GDPR special- ' +
+                'category health data — Art. 9; classification required to enforce 80001-2-2 security ' +
+                'capabilities and data flow controls); KEY PROPERTY impact signal classification ' +
+                '(SAFETY / EFFECTIVENESS / DATA+SYSTEM SECURITY degradation signals — CRITICAL immediate ' +
+                'escalation trigger on detection; classification determines escalation path and blocking ' +
+                'action per §4.2); change management risk classification (§8 — low/moderate/high impact ' +
+                'on key properties; classification gate determines whether pre-change assessment is ' +
+                'required and at what tier); distributed alarm signal classification (80001-2-5 — ' +
+                'alarm condition severity classification; loss of alarm system function is a SAFETY ' +
+                'key property impact); wireless network event classification (80001-2-3 — RF interference ' +
+                'events, coverage loss, roaming failure — effectiveness key property signals); ' +
+                'security event classification (80001-2-2 — cybersecurity events on medical IT network ' +
+                'classified against D&SS key property impact).',
+            reference: 'ISO/IEC 80001-1:2021 §4.2 Key Property classification; §8 Change risk classification; ' +
+                '§9 Incident severity classification; 80001-2-2 Security event classification; ' +
+                '80001-2-5 Alarm severity; HIPAA 45 CFR §164 PHI; GDPR Art. 9 special-category data',
+        },
+        {
+            name: 'supply-chain',
+            required: true,
+            reason: 'ISO/IEC 80001-1:2021 §6 (Responsibility Agreements) supply-chain requirements: formal ' +
+                'documented Responsibility Agreements with each medical device manufacturer connected to ' +
+                'the network covering security capabilities disclosure (80001-2-2), change notification ' +
+                'obligations, and incident reporting; IT operator qualification for all network ' +
+                'infrastructure components touching medical devices; medical device system integrator ' +
+                'qualification for integration and middleware vendors. Third-party AI vendor qualification: ' +
+                'any AI/ML system monitoring or operating on the medical IT network must be qualified ' +
+                'against 80001-2-2 security capabilities requirements. PRC-jurisdiction LLM provider ' +
+                'blocking: ISO/IEC 80001-2-2 security-capabilities requirements for clinical IT networks ' +
+                'handling PHI are incompatible with PRC data localisation law (Cybersecurity Law Art. 37 + ' +
+                'Data Security Law Art. 36 + PIPL Art. 38-46) — routing clinical network telemetry and ' +
+                'patient safety events through PRC-jurisdiction AI services creates government access ' +
+                'obligations irreconcilable with HIPAA, GDPR, and ISO/IEC 80001-2-2 security-capabilities ' +
+                'requirements. HIPAA Business Associate Agreement required for any external AI vendor ' +
+                'processing medical IT network data that may contain PHI.',
+            reference: 'ISO/IEC 80001-1:2021 §6 Responsibility Agreements; 80001-2-2 Security capabilities; ' +
+                'HIPAA 45 CFR §164.308(b) BAA; PRC CSL Art. 37 / DSL Art. 36 / PIPL Art. 38-46; ' +
+                'FDA Medical Device Cybersecurity supply-chain guidance',
+        },
+        {
+            name: 'approval-queue',
+            required: true,
+            reason: 'ISO/IEC 80001-1:2021 requires formal approval gates for: network change management ' +
+                '(§8 — every change affecting medical device integration requires pre-change risk ' +
+                'assessment approval by MITN-RM before implementation; high-impact changes require ' +
+                'patient-safety-officer co-approval); new device integration (§7 — every new medical ' +
+                'device added to the network requires inventory registration + risk assessment approval ' +
+                'before connection); key property impact resolution (§4.2 — when a key property impact ' +
+                'event is resolved, MITN-RM + patient-safety-officer approval of corrective action ' +
+                'required before normal operations resume); Responsibility Agreement execution (§6 — ' +
+                'new or amended agreements require MITN-RM + hospital-cio + legal approval before ' +
+                'execution); wireless network configuration changes (80001-2-3 — RF changes near ' +
+                'medical devices require biomedical-engineering-lead approval); distributed alarm ' +
+                'system changes (80001-2-5 — alarm routing and escalation changes require patient- ' +
+                'safety-officer + clinical-network-engineer approval).',
+            reference: 'ISO/IEC 80001-1:2021 §5 MITN-RM responsibility; §6 Responsibility Agreement approval; ' +
+                '§7 Device inventory approval; §8 Change management approval; §9 Incident resolution approval; ' +
+                '80001-2-3 Wireless change approval; 80001-2-5 Alarm system change approval',
+        },
+        {
+            name: 'attestation-manager',
+            required: true,
+            reason: 'ISO/IEC 80001-1:2021 attestation requirements: MITN-RM attestation for all risk ' +
+                'management decisions (§5 — designated MITN-RM must personally attest pre-change risk ' +
+                'assessment conclusions and residual risk acceptability; no proxy without documented ' +
+                'delegation); medical device manufacturer attestation for security capabilities ' +
+                '(80001-2-2 — SECURE template / MDS2 form must be attested by manufacturer ' +
+                'representative; AI-generated security capability assessments require manufacturer ' +
+                'co-attestation); biomedical-engineering-lead attestation for wireless network ' +
+                'assessments (80001-2-3 — RF impact assessment sign-off); patient-safety-officer ' +
+                'attestation for key property impact corrective action closure (§4.2 + §9 — PSO must ' +
+                'attest that corrective action adequately addresses the safety/effectiveness/security ' +
+                'impact before normal operations resume); cybersecurity-incident-coordinator attestation ' +
+                'for D&SS incident closure (80001-2-2 §6 — security incident corrective action must be ' +
+                'attested before network returns to normal monitored state).',
+            reference: 'ISO/IEC 80001-1:2021 §5 MITN-RM attestation; §6 Responsibility Agreement attestation; ' +
+                '§9 Incident resolution attestation; 80001-2-2 Security capabilities attestation; ' +
+                '80001-2-3 Wireless assessment attestation; 80001-2-5 Alarm system attestation',
+        },
+        {
+            name: 'session-persistence',
+            required: true,
+            reason: 'ISO/IEC 80001-1:2021 mandates long-term record retention for all risk management ' +
+                'artefacts: medical device network risk assessments (§7 — retained for the operational ' +
+                'lifetime of each device on the network plus audit window; cross-jurisdictional 20-year ' +
+                'baseline for health-system clinical-network records); Responsibility Agreements (§6 — ' +
+                'retained for the period of the agreement plus audit window; amendment history required ' +
+                'for regulatory inspection); change management records (§8 — pre-change risk assessments, ' +
+                'approvals, implementation records, post-change verification; retained for the operational ' +
+                'lifetime of the change plus audit window); incident records (§9 — incident log, root ' +
+                'cause analysis, corrective action, manufacturer notifications, closure attestations; ' +
+                '20-year patient-record baseline applies to all network incidents involving patient ' +
+                'data or patient safety events); security capabilities documentation (80001-2-2 — ' +
+                'MDS2 / SECURE template version history for each device; each version retained for ' +
+                'the period of device operation); distributed alarm system records (80001-2-5 — ' +
+                'alarm routing configuration history + test records + incident logs).',
+            reference: 'ISO/IEC 80001-1:2021 §6 Responsibility Agreement retention; §7 Device inventory retention; ' +
+                '§8 Change management record retention; §9 Incident record retention; ' +
+                '80001-2-2 Security capabilities version history; 80001-2-5 Alarm system records; ' +
+                'HIPAA 45 CFR §164.530(j); GDPR Art. 5(2) accountability; 20-year (7300 days) baseline',
+        },
+        {
+            name: 'anomaly-detector',
+            required: true,
+            reason: 'Real-time detection of ISO/IEC 80001 key property impact events: KEY PROPERTY SAFETY ' +
+                'impact detection (§4.2.1 — network-mediated failure modes that could cause patient harm: ' +
+                'device connectivity loss during active clinical use, alarm delivery failure, medication ' +
+                'pump communication interruption, imaging device network partition during procedure; ' +
+                'CRITICAL immediate escalation to patient-safety-officer + MITN-RM + medical-device-vendor- ' +
+                'liaison; no delay, no compensating control); KEY PROPERTY EFFECTIVENESS impact detection ' +
+                '(§4.2.2 — network conditions preventing the device from fulfilling its medical purpose: ' +
+                'latency exceeding device tolerance, bandwidth starvation, QoS degradation on clinical ' +
+                'traffic; HIGH escalation to MITN-RM + clinical-network-engineer + biomedical-engineering- ' +
+                'lead); KEY PROPERTY DATA+SYSTEM SECURITY impact detection (§4.2.3 + 80001-2-2 §6 — ' +
+                'cybersecurity events impacting clinical data integrity, availability, or confidentiality: ' +
+                'unauthorized access to medical devices, ransomware indicators, rogue device detection, ' +
+                'medical device firmware anomaly; CRITICAL escalation to cybersecurity-incident-coordinator ' +
+                '+ MITN-RM + medical-device-vendor-liaison); distributed alarm system anomaly detection ' +
+                '(80001-2-5 — alarm delivery failure, alarm flooding, silent alarm suppression).',
+            reference: 'ISO/IEC 80001-1:2021 §4.2.1 Safety key property; §4.2.2 Effectiveness key property; ' +
+                '§4.2.3 Data + System Security key property; §9 Monitoring + event handling; ' +
+                '80001-2-2 §6 Security event detection; 80001-2-5 Alarm system anomaly detection',
+        },
+        {
+            name: 'transparency-injector',
+            required: true,
+            reason: 'AI-generated medical IT network output provenance disclosure to hospital CIOs, ' +
+                'biomedical engineering leads, MITN-RM, clinical network engineers, and AAMI/ISA/ ' +
+                'HIMSS-CPHIMS qualified reviewers. Required for: AI-assisted network risk assessments ' +
+                '(§4.2 — key property impact analysis; AI-generated conclusions must be labelled and ' +
+                'reviewed by MITN-RM + biomedical-engineering-lead before any risk management decision); ' +
+                'AI-generated pre-change risk assessments (§8 — AI involvement in change risk analysis ' +
+                'must be disclosed; MITN-RM review required before approval); AI-assisted distributed ' +
+                'alarm monitoring (80001-2-5 — where AI assists in alarm condition detection or ' +
+                'escalation routing, model provenance must be disclosed to patient-safety-officer and ' +
+                'clinical-network-engineer reviewing alarm events); AI-generated security capabilities ' +
+                'analysis (80001-2-2 — AI-assisted analysis of MDS2/SECURE template data must disclose ' +
+                'AI provenance; cybersecurity-incident-coordinator review required); AI-assisted wireless ' +
+                'network performance analysis (80001-2-3 — RF impact modelling by AI must be disclosed ' +
+                'to biomedical-engineering-lead before changes are approved).',
+            reference: 'ISO/IEC 80001-1:2021 §5 MITN-RM oversight of risk management decisions; ' +
+                '§8 Change management transparency; 80001-2-2 Security capabilities AI provenance; ' +
+                '80001-2-3 Wireless assessment disclosure; 80001-2-5 Alarm monitoring provenance',
+        },
+        {
+            name: 'event-bus',
+            required: true,
+            reason: 'ISO/IEC 80001 lifecycle event routing: KEY PROPERTY SAFETY impact event (§4.2.1 — ' +
+                'CRITICAL immediate escalation: patient-safety-officer + MITN-RM + hospital-cio + ' +
+                'medical-device-vendor-liaison + cybersecurity-incident-coordinator + clinical-network- ' +
+                'engineer; network change and new device integration blocked until resolved); KEY ' +
+                'PROPERTY EFFECTIVENESS impact event (§4.2.2 — HIGH escalation: MITN-RM + clinical- ' +
+                'network-engineer + biomedical-engineering-lead; device operations review triggered); ' +
+                'KEY PROPERTY DATA+SYSTEM SECURITY impact event (§4.2.3 — CRITICAL escalation: ' +
+                'cybersecurity-incident-coordinator + MITN-RM + medical-device-vendor-liaison + ' +
+                'hospital-cio; FDA MDR / GDPR Art. 33 notification chain triggered if PHI involved); ' +
+                'network change approval event (§8 — MITN-RM routing for pre-change risk assessment ' +
+                'review + approval; patient-safety-officer routing for high-impact changes); new device ' +
+                'integration event (§7 — biomedical-engineering-lead + MITN-RM routing for risk ' +
+                'assessment + inventory registration); Responsibility Agreement execution event (§6 — ' +
+                'hospital-cio + MITN-RM + medical-device-vendor-liaison routing); incident closure ' +
+                'event (§9 — MITN-RM + patient-safety-officer attestation routing for key property ' +
+                'impact incidents); distributed alarm system event (80001-2-5 — patient-safety-officer ' +
+                '+ clinical-network-engineer routing for alarm delivery failures).',
+            reference: 'ISO/IEC 80001-1:2021 §4.2 Key Property impact events; §6 Responsibility Agreement events; ' +
+                '§7 Device integration events; §8 Change management events; §9 Incident events; ' +
+                '80001-2-2 Security events; 80001-2-5 Alarm system events',
+        },
+    ],
+    moduleConfig: {
+        'governance-runtime': {
+            keyPropertySafetyTrackingRequired: true,
+            keyPropertyEffectivenessTrackingRequired: true,
+            keyPropertySecurityTrackingRequired: true,
+            designatedMedicalItNetworkRiskManagerRequired: true,
+            responsibilityAgreementsRequired: true,
+            medicalDeviceInventoryRequired: true,
+            networkChangeManagementApprovalRequired: true,
+            preChangeRiskAssessmentRequired: true,
+            monitoringAndEventHandlingActive: true,
+            iso14971AlignmentRequired: true,
+            keyPropertyImpactImmediateEscalationRequired: true,
+        },
+        'approval-queue': {
+            preChangeRiskAssessmentApprovalRequired: true,
+            newDeviceIntegrationApprovalRequired: true,
+            keyPropertyImpactResolutionApprovalRequired: true,
+            responsibilityAgreementExecutionApprovalRequired: true,
+            wirelessNetworkConfigurationApprovalRequired: true,
+            distributedAlarmSystemChangeApprovalRequired: true,
+            humanInLoopTierRoutine: 'T1',
+            humanInLoopTierResponsibilityChange: 'T2',
+            humanInLoopTierKeyPropertyImpact: 'T3',
+        },
+        'attestation-manager': {
+            mitnRmRiskManagementAttestationRequired: true,
+            manufacturerSecurityCapabilitiesAttestationRequired: true,
+            biomedicalEngineeringWirelessAssessmentAttestationRequired: true,
+            patientSafetyOfficerKeyPropertyCorrectionAttestationRequired: true,
+            cybersecurityIncidentCoordinatorSecurityClosureAttestationRequired: true,
+        },
+        'supply-chain': {
+            medicalDeviceManufacturerResponsibilityAgreementRequired: true,
+            itOperatorQualificationRequired: true,
+            medicalDeviceSystemIntegratorQualificationRequired: true,
+            prcProviderBlockRequired: true,
+            hipaaBusinessAssociateAgreementRequired: true,
+            securityCapabilitiesTemplateRequired: true,
+        },
+        'anomaly-detector': {
+            keyPropertySafetyImpactDetectionRequired: true,
+            keyPropertyEffectivenessImpactDetectionRequired: true,
+            keyPropertyDataSystemSecurityImpactDetectionRequired: true,
+            distributedAlarmSystemAnomalyDetectionRequired: true,
+            wirelessNetworkPerformanceAnomalyDetectionRequired: true,
+            rogueDeviceDetectionRequired: true,
+        },
+        'transparency-injector': {
+            aiGeneratedNetworkRiskAssessmentDisclosureRequired: true,
+            aiGeneratedPreChangeRiskAssessmentDisclosureRequired: true,
+            aiAssistedAlarmMonitoringDisclosureRequired: true,
+            aiGeneratedSecurityCapabilitiesAnalysisDisclosureRequired: true,
+            aiAssistedWirelessNetworkAnalysisDisclosureRequired: true,
+            mitnRmReviewBeforeRiskDecisionRequired: true,
+        },
+        'event-bus': {
+            keyPropertySafetyImpactEventsActive: true,
+            keyPropertyEffectivenessImpactEventsActive: true,
+            keyPropertyDataSystemSecurityImpactEventsActive: true,
+            networkChangeApprovalEventsActive: true,
+            newDeviceIntegrationEventsActive: true,
+            responsibilityAgreementExecutionEventsActive: true,
+            incidentClosureEventsActive: true,
+            distributedAlarmSystemEventsActive: true,
+        },
+    },
+    providerPolicy: {
+        blockedProviders: ['deepseek', 'baidu', 'alibaba'],
+        requiredCapabilities: [
+            'MEDICAL-IT-NETWORK-READY',
+            'ISO-IEC-80001-COMPLIANT',
+            'CLINICAL-NETWORK-PHI-GOVERNANCE',
+        ],
+        blockReasons: {
+            deepseek: 'PRC-jurisdiction LLM providers cannot meet HIPAA + GDPR + ISO/IEC 80001-2-2 security- ' +
+                'capabilities requirements for clinical IT networks handling PHI. Medical IT network ' +
+                'telemetry, device connectivity events, alarm system data, and network risk assessments ' +
+                'processed by AI systems on the medical IT network constitute Protected Health Information ' +
+                'under HIPAA 45 CFR §164 and special-category health data under GDPR Art. 9 when ' +
+                'associated with patient care events. ISO/IEC 80001-2-2 requires that security capabilities ' +
+                'for medical IT networks include data confidentiality and integrity controls. PRC data ' +
+                'localisation law (Cybersecurity Law Art. 37, Data Security Law Art. 36, PIPL Art. 38-46) ' +
+                'creates government access obligations to clinical network data that are irreconcilable ' +
+                'with HIPAA minimum-necessary standards, GDPR adequacy requirements, and ISO/IEC 80001-2-2 ' +
+                'DATA + SYSTEM SECURITY key property requirements. FDA Medical Device Cybersecurity guidance ' +
+                'and MHRA Medical Device Cybersecurity guidance would flag PRC-jurisdiction processing of ' +
+                'medical IT network data as a security-capabilities non-conformity under 80001-2-2.',
+            baidu: 'PRC-jurisdiction LLM; HIPAA + GDPR + ISO/IEC 80001-2-2 security-capabilities requirements ' +
+                'for clinical IT networks handling PHI cannot be met. Medical device network telemetry ' +
+                'and patient safety event data are special-category health data (GDPR Art. 9) and PHI ' +
+                '(HIPAA). ISO/IEC 80001-1:2021 §4.2.3 (DATA + SYSTEM SECURITY key property) requires that ' +
+                'confidentiality of clinical data and system function be preserved — PRC government access ' +
+                'obligations under CSL Art. 37 and DSL Art. 36 are incompatible with this requirement. ' +
+                'HIPAA BAA cannot be executed with PRC-jurisdiction AI vendors in a manner that satisfies ' +
+                'HIPAA minimum-necessary and offshore-access prohibitions. ISO/IEC 80001-2-2 Responsibility ' +
+                'Agreement obligations cannot be met if AI processing routes through PRC-jurisdiction ' +
+                'services subject to PRC law. Hospital CIO + CISO due diligence for clinical IT networks ' +
+                'prohibits routing patient safety event data through PRC-jurisdiction AI services.',
+            alibaba: 'PRC-jurisdiction LLM; clinical IT network PHI (patient device connectivity events, ' +
+                'alarm system data, medication pump telemetry, clinical imaging network traffic) cannot ' +
+                'be processed through PRC-jurisdiction AI systems under HIPAA, GDPR, and ISO/IEC 80001-2-2. ' +
+                'Health systems also handle genomic data (molecular diagnostic device network connectivity ' +
+                'events) subject to GDPR Art. 9 (genetic data special category). PRC PIPL Art. 38-46 ' +
+                'cross-border data transfer restrictions and DSL Art. 36 government access obligations are ' +
+                'incompatible with ISO/IEC 80001-2-2 DATA + SYSTEM SECURITY key property requirements, ' +
+                'HIPAA minimum-necessary and breach notification rules, and GDPR data localisation + ' +
+                'adequacy requirements for health data. NIS2 Art. 23 incident notification obligations ' +
+                'for health-sector essential services would be complicated by PRC-jurisdiction processing ' +
+                'of clinical IT network incident data. HIMSS CPHIMS standards and AAMI guidelines for ' +
+                'health technology management prohibit routing clinical network telemetry through ' +
+                'jurisdictions lacking adequate data protection frameworks.',
+        },
+    },
+    dataPolicy: {
+        scanCategories: [
+            'MEDICAL_DEVICE_NETWORK_EVENT',
+            'KEY_PROPERTY_IMPACT_EVENT',
+            'CLINICAL_NETWORK_PHI',
+            'RESPONSIBILITY_AGREEMENT_RECORD',
+            'NETWORK_CHANGE_RECORD',
+        ],
+        categoryActions: {
+            // Key property impact: BLOCK — network change and new device integration blocked until resolved
+            KEY_PROPERTY_IMPACT_EVENT: 'BLOCK',
+            // Medical device network events: REVIEWED — MITN-RM + clinical-network-engineer review
+            MEDICAL_DEVICE_NETWORK_EVENT: 'REVIEWED',
+            // Clinical network PHI: REVIEWED — patient-safety-officer review for PHI events
+            CLINICAL_NETWORK_PHI: 'REVIEWED',
+            // Responsibility Agreement records: REVIEWED — hospital-cio + MITN-RM sign-off
+            RESPONSIBILITY_AGREEMENT_RECORD: 'REVIEWED',
+            // Network change records: REVIEWED — MITN-RM pre-change risk assessment
+            NETWORK_CHANGE_RECORD: 'REVIEWED',
+        },
+        encryptionRequired: true,
+        encryptionStandard: 'AES-256-GCM',
+        minimumClassification: 'RESTRICTED',
+    },
+    retentionPolicy: {
+        /**
+         * 20-year patient-record retention baseline (7300 days).
+         *
+         * Medical IT network risk management records must be retained for the full
+         * operational lifetime of devices on the network plus an audit window. The
+         * cross-jurisdictional conservative baseline is 20 years:
+         *   US: HIPAA 45 CFR §164.530(j) — 6 years from creation or last effective
+         *       date (minimum); CMS CoP hospital records — 10 years; state law varies
+         *       (California: 7 years; New York: 6 years; most range 7-10 years for
+         *       adults). FDA medical device records: 21 CFR 820.180 life-of-device
+         *       plus 2 years (devices may be in service 10-20 years).
+         *   EU: GDPR Art. 5(2) accountability + NIS2 audit retention;
+         *       NHS England: 20 years for clinical records post last contact;
+         *       Germany §630f BGB: 10 years; France: 20 years clinical records;
+         *       GDPR storage limitation balanced against medical record obligations
+         *       (Art. 9(2)(h) + Recital 65).
+         *   AU: Health Records Acts typically 7-10 years for adults; MBS records
+         *       (Medicare) 7 years; state health records 7-10 years.
+         *
+         * 20-year conservative baseline applied for cross-jurisdictional compatibility
+         * with ISO/IEC 80001 health-system deployments spanning US, EU, UK, and AU
+         * simultaneously. Device operational lifetimes on hospital networks commonly
+         * exceed 10 years; risk management records must outlast the device.
+         */
+        sovereignty: ['us', 'eu', 'gb', 'au'],
+        auditLogRetentionDays: 7300, // 20 years — patient-record retention baseline
+        sessionRetentionDays: 7300,
+        incidentRetentionDays: 7300,
+        reference: 'ISO/IEC 80001-1:2021 — risk management records retained for device operational lifetime + audit window. ' +
+            'HIPAA 45 CFR §164.530(j): 6-year minimum; CMS CoP: 10-year hospital records. ' +
+            'EU NHS England: 20 years post last contact; Germany §630f BGB: 10 years; France: 20 years. ' +
+            'FDA 21 CFR 820.180 life-of-device plus 2 years. ' +
+            'Conservative 20-year (7300 days) cross-jurisdictional baseline for health-system clinical-network records.',
+    },
+    incidentPolicy: {
+        /**
+         * 72-hour incident notification baseline (3 days).
+         *
+         * Cross-jurisdictional most-restrictive baseline for medical-device network
+         * incidents involving clinical data or patient safety:
+         *   GDPR Art. 33: 72-hour notification to supervisory authority for personal
+         *     data breaches (applies to all clinical network events involving EU patient
+         *     data including medical device telemetry).
+         *   NIS2 Art. 23: 24-hour early warning + 72-hour notification for significant
+         *     incidents affecting health-sector essential services.
+         *   HIPAA 45 CFR §164.412: 60-day breach notification window; however most US
+         *     state breach laws require 30-72 hours for healthcare breaches; HIPAA
+         *     incident response best practice is 72 hours for initial notification.
+         *   FDA MDR 21 CFR §803: 30-day routine MDR; 5-day if immediately corrective
+         *     action needed. MDR is for device malfunction / adverse events — network
+         *     incidents causing device malfunction trigger MDR obligations.
+         *   ISO/IEC 80001-1:2021 §9: notify medical device manufacturer + patient
+         *     safety officer "without undue delay" — 72h is the cross-programme baseline.
+         *   MHRA Yellow Card adverse event: 15 calendar days for serious events;
+         *     72h for NIS2 network-incident notification under UK NCSC guidance.
+         *
+         * 72h (3 days) is the most-restrictive cross-jurisdictional formal notification
+         * baseline. Key property SAFETY impact events require IMMEDIATE internal response
+         * — 72h governs external/formal regulatory notification, not internal escalation.
+         */
+        notificationDeadlineHours: 72,
+        reference: 'ISO/IEC 80001-1:2021 §9 — incident management: notify manufacturer + PSO without undue delay. ' +
+            'GDPR Art. 33: 72-hour supervisory authority notification for health data breaches. ' +
+            'NIS2 Art. 23: 72-hour notification for health-sector essential service incidents. ' +
+            'HIPAA 45 CFR §164.412: 60-day window; cross-state 72-hour best practice. ' +
+            'FDA MDR 21 CFR §803.53: 5-day immediate / 30-day routine. ' +
+            '72h is the most-restrictive cross-jurisdictional formal notification baseline.',
+        requiredRecipients: [
+            'hospital-cio',
+            'biomedical-engineering-lead',
+            'patient-safety-officer',
+            'cybersecurity-incident-coordinator',
+            'medical-device-vendor-liaison',
+            'clinical-network-engineer',
+        ],
+        formalNotificationRequired: true,
+    },
+    validators: [
+        {
+            id: 'iso80001-key-property-safety',
+            description: 'KEY PROPERTY: SAFETY — Risk management ensures no patient harm from network-mediated ' +
+                'failure per ISO/IEC 80001-1:2021 §4.2.1. Safety risk assessment documented for every ' +
+                'medical device on the network: network failure modes that could harm patients identified ' +
+                '(device connectivity loss during active clinical use, alarm delivery failure, medication ' +
+                'pump communication interruption, imaging device partition during procedure, infusion pump ' +
+                'command loss); probability × severity risk estimation (ISO 14971 alignment per §4.4); ' +
+                'risk control measures implemented and verified (network redundancy for safety-critical ' +
+                'devices, QoS prioritisation for clinical traffic, fallback communication paths); ' +
+                'residual safety risk documented and accepted by patient-safety-officer + MITN-RM; ' +
+                'safety risk monitoring continuous (network performance metrics against safety thresholds, ' +
+                'device connectivity health monitoring); ANY safety key property impact detected triggers ' +
+                'IMMEDIATE CRITICAL escalation — no delay, no bypass, no compensating control path; ' +
+                'safety risk register reviewed at each change management cycle and annually.',
+            reference: 'ISO/IEC 80001-1:2021 §4.2.1 (Key Property: Safety)',
+            check: 'iso80001_key_property_safety',
+            failSeverity: 'CRITICAL',
+        },
+        {
+            id: 'iso80001-key-property-effectiveness',
+            description: 'KEY PROPERTY: EFFECTIVENESS — Risk management ensures medical purpose of each device ' +
+                'is still achieved on the network per ISO/IEC 80001-1:2021 §4.2.2. Effectiveness risk ' +
+                'assessment documented for every medical device: network performance requirements for ' +
+                'each device\'s medical purpose identified (latency, bandwidth, jitter, packet loss ' +
+                'tolerances); network conditions that would prevent device from fulfilling intended ' +
+                'medical function identified (bandwidth starvation, QoS degradation, DNS failure, NTP ' +
+                'drift, DHCP failure); effectiveness performance monitoring operational (network ' +
+                'performance metrics verified against device manufacturer specifications from 80001-2-2 ' +
+                'SECURE template); effectiveness risk control measures implemented (network segmentation ' +
+                'per VLAN/SSID, QoS class-of-service, reserved bandwidth for critical clinical traffic); ' +
+                'residual effectiveness risk documented and accepted by MITN-RM + biomedical-engineering- ' +
+                'lead; effectiveness degradation triggers HIGH escalation to MITN-RM + clinical-network- ' +
+                'engineer + biomedical-engineering-lead.',
+            reference: 'ISO/IEC 80001-1:2021 §4.2.2 (Key Property: Effectiveness)',
+            check: 'iso80001_key_property_effectiveness',
+            failSeverity: 'CRITICAL',
+        },
+        {
+            id: 'iso80001-key-property-security',
+            description: 'KEY PROPERTY: DATA + SYSTEM SECURITY (D&SS) — Risk management ensures integrity, ' +
+                'availability, and confidentiality of clinical data and system function per ' +
+                'ISO/IEC 80001-1:2021 §4.2.3. D&SS risk assessment documented for every medical device: ' +
+                'cybersecurity risks to clinical data integrity (tampering with device readings or ' +
+                'commands), availability (ransomware, DoS impacting device function), and confidentiality ' +
+                '(patient data leakage from device network traffic) identified; security capabilities ' +
+                'per 80001-2-2 (MDS2 / SECURE template) received from each device manufacturer and ' +
+                'verified against network security requirements; network security controls implemented ' +
+                '(network segmentation, port-based access control, device certificate management, ' +
+                'encrypted device communication where supported); D&SS monitoring operational (SIEM ' +
+                'integration for medical device network traffic, rogue device detection, anomalous ' +
+                'traffic pattern detection per 80001-2-2 §6); cybersecurity incident on medical IT ' +
+                'network triggers CRITICAL escalation to cybersecurity-incident-coordinator + MITN-RM ' +
+                '+ medical-device-vendor-liaison.',
+            reference: 'ISO/IEC 80001-1:2021 §4.2.3 (Key Property: Data + System Security)',
+            check: 'iso80001_key_property_security',
+            failSeverity: 'CRITICAL',
+        },
+        {
+            id: 'iso80001-medical-it-network-risk-manager',
+            description: 'Designated Medical IT-Network Risk Manager (MITN-RM) established and empowered per ' +
+                'ISO/IEC 80001-1:2021 §5. MITN-RM appointment documented with: named individual with ' +
+                'relevant qualifications (biomedical engineering, clinical informatics, or equivalent ' +
+                'health IT network expertise; AAMI / ISA / HIMSS-CPHIMS recognized qualification ' +
+                'preferred); documented authority over medical IT network change management decisions ' +
+                '(§8) — MITN-RM must be able to block or approve any network change that could affect ' +
+                'medical devices; documented authority to convene Responsibility Agreement negotiations ' +
+                '(§6) between the responsible organization, medical device manufacturers, and IT ' +
+                'operators; documented accountability for maintaining the medical device inventory (§7) ' +
+                'and risk register; formal delegation of authority documented when MITN-RM is unavailable ' +
+                '(must not reduce risk management oversight capability); MITN-RM accessible for immediate ' +
+                'escalation on key property impact events (not just during business hours for safety-critical ' +
+                'networks); MITN-RM role reviewed annually + after significant organizational changes.',
+            reference: 'ISO/IEC 80001-1:2021 §5 (Roles + Responsibilities — designated MITN-RM)',
+            check: 'iso80001_medical_it_network_risk_manager',
+            failSeverity: 'CRITICAL',
+        },
+        {
+            id: 'iso80001-responsibility-agreements',
+            description: 'Responsibility Agreements established and maintained per ISO/IEC 80001-1:2021 §6. ' +
+                'Formal documented Responsibility Agreement in place for each medical device manufacturer ' +
+                'and IT operator contributing to the medical IT network, covering: risk ownership ' +
+                'boundaries (which party owns which risk management obligations for each device class); ' +
+                'security capabilities communication obligations (manufacturer provides MDS2 / SECURE ' +
+                'template per 80001-2-2 for each device and updates on security-relevant changes); ' +
+                'change notification obligations (manufacturer notifies of device software updates, ' +
+                'firmware changes, and security patches affecting network risk profile; IT operator ' +
+                'notifies MITN-RM of network infrastructure changes affecting medical devices); incident ' +
+                'notification obligations (manufacturer notified of device-related network incidents; ' +
+                'IT operator notifies MITN-RM of network events affecting medical device connectivity); ' +
+                'Responsibility Agreement version history maintained; amendments require MITN-RM + ' +
+                'hospital-cio co-approval; agreements reviewed annually and at each significant ' +
+                'change to the network or device portfolio.',
+            reference: 'ISO/IEC 80001-1:2021 §6 (Responsibility Agreements)',
+            check: 'iso80001_responsibility_agreements',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-risk-management-process',
+            description: 'Step-by-step risk management process established and operational per ' +
+                'ISO/IEC 80001-2-1:2012. Formal risk management process documented covering: ' +
+                'risk management plan (scope, criteria, risk acceptance policy, review schedule); ' +
+                'hazard identification for each medical device on the network (network failure modes ' +
+                'that could affect the three key properties); risk estimation (probability of occurrence ' +
+                'of harm + severity of harm for SAFETY; probability of performance degradation + impact ' +
+                'on medical purpose for EFFECTIVENESS; probability of security event + impact on ' +
+                'data/system for D&SS); risk evaluation against acceptance criteria (risk acceptability ' +
+                'decision by MITN-RM + patient-safety-officer for SAFETY risks); risk control (technical ' +
+                'controls: network segmentation, QoS, redundancy; procedural controls: change management, ' +
+                'monitoring, incident response); residual risk evaluation and acceptance; risk monitoring ' +
+                '(continuous operational monitoring against the three key properties); ISO 14971 ' +
+                'alignment verified (probability × severity framework consistent with device risk ' +
+                'management per §4.4).',
+            reference: 'ISO/IEC 80001-2-1:2012 (Step-by-step risk management)',
+            check: 'iso80001_risk_management_process',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-medical-device-inventory',
+            description: 'Medical device inventory established and maintained per ISO/IEC 80001-1:2021 §7. ' +
+                'Comprehensive inventory of all medical devices on the IT network maintained, including: ' +
+                'device identification (manufacturer, model, software/firmware version, unique device ' +
+                'identifier where available); network identification (IP address, MAC address, VLAN, ' +
+                'network segment, connectivity type — wired/wireless); clinical use context (department, ' +
+                'clinical function, patient populations served, criticality classification); risk ' +
+                'assessment status (risk assessment completed and accepted; residual risk level; ' +
+                'last review date; review trigger events); Responsibility Agreement reference (which ' +
+                'agreement covers this device); security capabilities reference (80001-2-2 MDS2/SECURE ' +
+                'template version on file); asset lifecycle status (active / pending decommission / ' +
+                'decommissioned — decommissioning requires network risk assessment update); inventory ' +
+                'updated within 24h of any new device connection, device change, or device removal; ' +
+                'inventory reviewed at each change management cycle; MITN-RM accountable for inventory ' +
+                'accuracy.',
+            reference: 'ISO/IEC 80001-1:2021 §7 (Network device inventory)',
+            check: 'iso80001_medical_device_inventory',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-network-change-management',
+            description: 'Change management process for the medical IT network established and operational per ' +
+                'ISO/IEC 80001-1:2021 §8. Formal change management process covering: change request ' +
+                'intake (all proposed network changes affecting medical devices submitted through formal ' +
+                'change request process); pre-change risk assessment (MANDATORY for all changes: assess ' +
+                'impact of proposed change on each of the three KEY PROPERTIES for all affected devices; ' +
+                'MITN-RM conducts or reviews the assessment); risk assessment approval gate (MITN-RM ' +
+                'approval required before any change implementation; patient-safety-officer co-approval ' +
+                'required for changes with non-negligible SAFETY key property impact; hospital-cio ' +
+                'approval required for changes affecting Responsibility Agreements); change implementation ' +
+                'controls (change window communication to clinical stakeholders; rollback plan documented; ' +
+                'monitoring heightened during and immediately after implementation); post-change verification ' +
+                '(verify three KEY PROPERTIES preserved after implementation; incident escalation if any ' +
+                'key property impact detected post-change); NO UNILATERAL NETWORK CHANGES — emergency ' +
+                'changes still require MITN-RM notification within 1 hour and retrospective risk assessment ' +
+                'within 24 hours.',
+            reference: 'ISO/IEC 80001-1:2021 §8 (Change management on the medical IT network)',
+            check: 'iso80001_network_change_management',
+            failSeverity: 'CRITICAL',
+        },
+        {
+            id: 'iso80001-incident-management',
+            description: 'Incident management process established and operational per ISO/IEC 80001-1:2021 §9. ' +
+                'Formal incident management process covering: incident detection (monitoring triggers ' +
+                'for key property impact events; network events impacting medical device connectivity, ' +
+                'performance, or security reported to MITN-RM); incident classification (SAFETY impact: ' +
+                'CRITICAL — immediate escalation; EFFECTIVENESS impact: HIGH — same-business-day ' +
+                'response; D&SS impact: CRITICAL — immediate escalation for active cybersecurity events); ' +
+                'incident notification (medical device manufacturer notified of device-related incidents ' +
+                'without undue delay per Responsibility Agreement; patient-safety-officer notified of ' +
+                'all incidents with potential SAFETY key property impact; hospital-cio notified of ' +
+                'significant D&SS incidents; formal regulatory notification within 72h per applicable ' +
+                'law — GDPR Art. 33, NIS2 Art. 23, FDA MDR where applicable); incident investigation ' +
+                '(root cause analysis; identification of which key property was impacted and how; ' +
+                'corrective action plan development); corrective action (implementation + verification ' +
+                'that key property impact is resolved; MITN-RM + patient-safety-officer attestation ' +
+                'for SAFETY impact incidents before normal operations resume); incident records retained ' +
+                '20 years.',
+            reference: 'ISO/IEC 80001-1:2021 §9 (Incident handling)',
+            check: 'iso80001_incident_management',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-monitoring-event-handling',
+            description: 'Monitoring and event handling operational per ISO/IEC 80001-1:2021 §9 and ' +
+                'ISO/IEC 80001-2-2:2012 §6. Continuous monitoring of the medical IT network ' +
+                'against the three KEY PROPERTIES established: SAFETY monitoring (device connectivity ' +
+                'health for safety-critical devices — alerts on connectivity loss, packet loss ' +
+                'exceeding safety thresholds, alarm delivery failure; integration with biomedical ' +
+                'engineering monitoring systems where available); EFFECTIVENESS monitoring (network ' +
+                'performance metrics for each device class against manufacturer-specified thresholds ' +
+                'from 80001-2-2 SECURE template — latency, bandwidth, jitter; QoS compliance ' +
+                'monitoring; DHCP/DNS resolution health for medical devices); D&SS monitoring ' +
+                '(SIEM integration for medical device network segment; anomalous traffic detection; ' +
+                'rogue device detection; device certificate validity monitoring; vulnerability ' +
+                'intelligence integration for known medical device CVEs per 80001-2-2); monitoring ' +
+                'events routed to MITN-RM + relevant stakeholders per event severity classification; ' +
+                'monitoring reports reviewed by MITN-RM at defined intervals (minimum monthly); ' +
+                'monitoring coverage verified at each change management cycle.',
+            reference: 'ISO/IEC 80001-1:2021 §9 + 80001-2-2 §6 (Monitoring + event handling)',
+            check: 'iso80001_monitoring_event_handling',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-security-capabilities',
+            description: 'Security capabilities communication established per ISO/IEC 80001-2-2:2012 (SECURE ' +
+                'capability template / MDS2 form). For each medical device on the network: MDS2 / ' +
+                'SECURE template received from device manufacturer documenting: automatic logoff, audit ' +
+                'controls, authorization controls, configuration of security features, cybersecurity ' +
+                'product upgrades (patches / software updates), data backup and disaster recovery, ' +
+                'data integrity, data storage confidentiality, emergency access, hardware controls, ' +
+                'malware detection/protection, network controls, person authentication, physical locks, ' +
+                'private key management, remote access controls, system and application hardening, ' +
+                'third-party components in software bill of materials (SBOM), transmission ' +
+                'confidentiality/integrity; template version tracked against device software version; ' +
+                'manufacturer notified of security events involving their device per Responsibility ' +
+                'Agreement §6; security capability gaps identified and risk-managed (compensating ' +
+                'controls documented where device cannot implement native security capability); ' +
+                'security capabilities reviewed at device software updates and annually.',
+            reference: 'ISO/IEC 80001-2-2 (Security capabilities communication)',
+            check: 'iso80001_security_capabilities',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-wireless-network-controls',
+            description: 'Wireless network controls established per ISO/IEC 80001-2-3:2012 (Wireless networks). ' +
+                'For all wireless medical devices on the network: RF site survey conducted before ' +
+                'wireless medical device deployment (coverage, interference, roaming performance); ' +
+                'wireless network architecture designed to preserve three KEY PROPERTIES for wireless ' +
+                'medical devices (dedicated SSID / VLAN for medical device traffic, WPA3-Enterprise ' +
+                'or equivalent, EAP-TLS device certificates preferred over pre-shared keys, QoS ' +
+                '802.11e/WMM enabled for clinical traffic prioritisation); roaming performance verified ' +
+                '(seamless handoff for mobile clinical devices — patient monitoring, infusion pumps, ' +
+                'portable imaging); RF interference management (channels reserved for medical devices, ' +
+                'interference detection and remediation process); wireless performance monitoring ' +
+                '(signal strength, roaming events, packet loss for wireless medical device segments); ' +
+                'wireless network changes affecting medical devices subject to standard change management ' +
+                'process §8 with biomedical-engineering-lead review; wireless security controls ' +
+                'reviewed at each 80001-2-2 security capabilities update cycle.',
+            reference: 'ISO/IEC 80001-2-3 (Wireless networks)',
+            check: 'iso80001_wireless_network_controls',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-distributed-alarm-systems',
+            description: 'Distributed alarm system controls established per ISO/IEC 80001-2-5:2014 ' +
+                '(Distributed alarm systems). Risk management for alarm system components on the ' +
+                'medical IT network: alarm system architecture documented (alarm sources — patient ' +
+                'monitoring, infusion pumps, nurse call; alarm aggregators; alarm notification paths — ' +
+                'wired, wireless, pager, mobile app); SAFETY key property analysis for alarm delivery ' +
+                '(failure modes that could result in missed alarms or delayed alarm delivery; network ' +
+                'path redundancy for critical alarm delivery); alarm delivery performance monitoring ' +
+                '(latency from alarm generation to notification, delivery confirmation rates, ' +
+                'failure-to-deliver detection); alarm system testing (periodic testing of end-to-end ' +
+                'alarm delivery path including network components; test records retained); alarm ' +
+                'flooding management (network bandwidth and processing capacity for simultaneous ' +
+                'alarm conditions; QoS for alarm traffic prioritisation); alarm system changes subject ' +
+                'to change management §8 with patient-safety-officer + clinical-network-engineer ' +
+                'review; any alarm delivery failure triggers immediate SAFETY key property impact ' +
+                'escalation — CRITICAL block on affected network segment changes until resolved.',
+            reference: 'ISO/IEC 80001-2-5 (Distributed alarm systems)',
+            check: 'iso80001_distributed_alarm_systems',
+            failSeverity: 'HIGH',
+        },
+        {
+            id: 'iso80001-iso14971-alignment',
+            description: 'ISO 14971 alignment verified per ISO/IEC 80001-1:2021 §4.4. The medical IT network ' +
+                'risk management process is aligned with ISO 14971:2019 (Medical devices — Application ' +
+                'of risk management to medical devices): risk management plan for the medical IT network ' +
+                'references and is consistent with device manufacturer ISO 14971 risk management files ' +
+                '(network-mediated risks not captured in device-intrinsic risk files are documented in ' +
+                'the network risk management file); risk estimation methodology consistent (probability ' +
+                'of occurrence of harm × severity of harm framework from ISO 14971 applied to network- ' +
+                'mediated scenarios); risk acceptability criteria aligned with device manufacturer risk ' +
+                'acceptance criteria from ISO 14971 files where known; risk/benefit analysis for ' +
+                'network-integrated devices consistent with manufacturer benefit-risk analysis; ' +
+                'risk management review triggered by: new device connection to network, device software ' +
+                'update (potential new network-mediated risks), network architecture change, incident ' +
+                'with key property impact (post-incident review mandatory), and annually; ISO 14971 ' +
+                'alignment documented and reviewed by MITN-RM at each annual risk management review.',
+            reference: 'ISO/IEC 80001-1:2021 §4.4 + ISO 14971 alignment (Risk management for medical devices)',
+            check: 'iso80001_iso14971_alignment',
+            failSeverity: 'MEDIUM',
+        },
+        {
+            id: 'iso80001-behavioral-validator-key-property-impact-detected',
+            description: 'Behavioral validator: detects ANY impact to the three KEY PROPERTIES (Safety, ' +
+                'Effectiveness, Data + System Security) of the medical IT network as defined in ' +
+                'ISO/IEC 80001-1:2021 §4.2. When a key property impact is detected on the medical ' +
+                'IT network, any network change operations (new device integrations, infrastructure ' +
+                'changes, configuration modifications) are an ABSOLUTE CRITICAL BLOCK with NO ' +
+                'compensating control path until the key property impact is formally resolved. ' +
+                'KEY PROPERTY SAFETY impact triggers IMMEDIATE escalation — no time-pressure override, ' +
+                'no MITN-RM bypass, no emergency-change-only exception — patient safety on the network ' +
+                'is the overriding concern. The key-property-impact event triggers immediate notification ' +
+                'to: hospital-cio, biomedical-engineering-lead, patient-safety-officer, cybersecurity- ' +
+                'incident-coordinator, medical-device-vendor-liaison, and clinical-network-engineer. ' +
+                'No AI agent operating on or monitoring the medical IT network may approve a network ' +
+                'change while a key property impact event is open and unresolved. The impact event ' +
+                'remains open until: (a) root cause is identified; (b) corrective action is implemented ' +
+                'and verified; (c) all three KEY PROPERTIES are confirmed restored; (d) MITN-RM + ' +
+                'patient-safety-officer formally attest to resolution. This is the highest-severity ' +
+                'medical IT network governance event — patient safety depends on network integrity ' +
+                'as the primary clinical infrastructure signal.',
+            reference: 'ISO/IEC 80001-1:2021 §4.2 Key Properties; §8 Change management block on open impact events; ' +
+                'behavioral validator: key-property-impact immediate-escalation',
+            check: 'behavioralValidator_iso80001_key_property_impact_detected',
+            failSeverity: 'CRITICAL',
+        },
+    ],
+};
+//# sourceMappingURL=iso-iec-80001.js.map