"use strict";
/**
 * 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
 */
Object.defineProperty(exports, "__esModule", { value: true });
exports.ISO_IEC_80001_PACK = exports.ISO_IEC_80001_CATEGORY_CLASSIFIERS = void 0;
/**
 * 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
 */
exports.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)
 */
exports.ISO_IEC_80001_PACK = {
    categoryClassifiers: exports.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