Claude-Skills risk-management-specialist

install
source · Clone the upstream repo
git clone https://github.com/borghei/Claude-Skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/borghei/Claude-Skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/ra-qm-team/risk-management-specialist" ~/.claude/skills/borghei-claude-skills-risk-management-specialist && rm -rf "$T"
manifest: ra-qm-team/risk-management-specialist/SKILL.md
source content

Risk Management Specialist

ISO 14971:2019 risk management implementation throughout the medical device lifecycle.


Table of Contents


Risk Management Planning Workflow

Establish risk management process per ISO 14971.

Workflow: Create Risk Management Plan

  1. Define scope of risk management activities:
    • Medical device identification
    • Lifecycle stages covered
    • Applicable standards and regulations
  2. Establish risk acceptability criteria:
    • Define probability categories (P1-P5)
    • Define severity categories (S1-S5)
    • Create risk matrix with acceptance thresholds
  3. Assign responsibilities:
    • Risk management lead
    • Subject matter experts
    • Approval authorities
  4. Define verification activities:
    • Methods for control verification
    • Acceptance criteria
  5. Plan production and post-production activities:
    • Information sources
    • Review triggers
    • Update procedures
  6. Obtain plan approval
  7. Establish risk management file
  8. Validation: Plan approved; acceptability criteria defined; responsibilities assigned; file established

Risk Management Plan Content

SectionContentEvidence
ScopeDevice and lifecycle coverageScope statement
CriteriaRisk acceptability matrixRisk matrix document
ResponsibilitiesRoles and authoritiesRACI chart
VerificationMethods and acceptanceVerification plan
Production/Post-ProductionMonitoring activitiesSurveillance plan

Risk Acceptability Matrix (5x5)

Probability \ SeverityNegligibleMinorSeriousCriticalCatastrophic
Frequent (P5)MediumHighHighUnacceptableUnacceptable
Probable (P4)MediumMediumHighHighUnacceptable
Occasional (P3)LowMediumMediumHighHigh
Remote (P2)LowLowMediumMediumHigh
Improbable (P1)LowLowLowMediumMedium

Risk Level Actions

LevelAcceptableAction Required
LowYesDocument and accept
MediumALARPReduce if practicable; document rationale
HighALARPReduction required; demonstrate ALARP
UnacceptableNoDesign change mandatory

Risk Analysis Workflow

Identify hazards and estimate risks systematically.

Workflow: Conduct Risk Analysis

  1. Define intended use and reasonably foreseeable misuse:
    • Medical indication
    • Patient population
    • User population
    • Use environment
  2. Select analysis method(s):
    • FMEA for component/function analysis
    • FTA for system-level analysis
    • HAZOP for process deviations
    • Use Error Analysis for user interaction
  3. Identify hazards by category:
    • Energy hazards (electrical, mechanical, thermal)
    • Biological hazards (bioburden, biocompatibility)
    • Chemical hazards (residues, leachables)
    • Operational hazards (software, use errors)
  4. Determine hazardous situations:
    • Sequence of events
    • Foreseeable misuse scenarios
    • Single fault conditions
  5. Estimate probability of harm (P1-P5)
  6. Estimate severity of harm (S1-S5)
  7. Document in hazard analysis worksheet
  8. Validation: All hazard categories addressed; all hazards documented; probability and severity assigned

Hazard Categories Checklist

CategoryExamplesAnalyzed
ElectricalShock, burns, interference
MechanicalCrushing, cutting, entrapment
ThermalBurns, tissue damage
RadiationIonizing, non-ionizing
BiologicalInfection, biocompatibility
ChemicalToxicity, irritation
SoftwareIncorrect output, timing
Use ErrorMisuse, perception, cognition
EnvironmentEMC, mechanical stress

Analysis Method Selection

SituationRecommended Method
Component failuresFMEA
System-level failureFTA
Process deviationsHAZOP
User interactionUse Error Analysis
Software behaviorSoftware FMEA
Early design phasePHA

Probability Criteria

LevelNameDescriptionFrequency
P5FrequentExpected to occur>10⁻³
P4ProbableLikely to occur10⁻³ to 10⁻⁴
P3OccasionalMay occur10⁻⁴ to 10⁻⁵
P2RemoteUnlikely10⁻⁵ to 10⁻⁶
P1ImprobableVery unlikely<10⁻⁶

Severity Criteria

LevelNameDescriptionHarm
S5CatastrophicDeathDeath
S4CriticalPermanent impairmentIrreversible injury
S3SeriousInjury requiring interventionReversible injury
S2MinorTemporary discomfortNo treatment needed
S1NegligibleInconvenienceNo injury

See: references/risk-analysis-methods.md


Risk Evaluation Workflow

Evaluate risks against acceptability criteria.

Workflow: Evaluate Identified Risks

  1. Calculate initial risk level from probability × severity
  2. Compare to risk acceptability criteria
  3. For each risk, determine:
    • Acceptable: Document and accept
    • ALARP: Proceed to risk control
    • Unacceptable: Mandatory risk control
  4. Document evaluation rationale
  5. Identify risks requiring benefit-risk analysis
  6. Complete benefit-risk analysis if applicable
  7. Compile risk evaluation summary
  8. Validation: All risks evaluated; acceptability determined; rationale documented

Risk Evaluation Decision Tree

Risk Estimated
      │
      ▼
Apply Acceptability Criteria
      │
      ├── Low Risk ──────────► Accept and document
      │
      ├── Medium Risk ───────► Consider risk reduction
      │   │                    Document ALARP if not reduced
      │   ▼
      │   Practicable to reduce?
      │   │
      │   Yes──► Implement control
      │   No───► Document ALARP rationale
      │
      ├── High Risk ─────────► Risk reduction required
      │   │                    Must demonstrate ALARP
      │   ▼
      │   Implement control
      │   Verify residual risk
      │
      └── Unacceptable ──────► Design change mandatory
                               Cannot proceed without control

ALARP Demonstration Requirements

CriterionEvidence Required
Technical feasibilityAnalysis of alternative controls
ProportionalityCost-benefit of further reduction
State of the artComparison to similar devices
Stakeholder inputClinical/user perspectives

Benefit-Risk Analysis Triggers

SituationBenefit-Risk Required
Residual risk remains highYes
No feasible risk reductionYes
Novel deviceYes
Unacceptable risk with clinical benefitYes
All risks lowNo

Risk Control Workflow

Implement and verify risk control measures.

Workflow: Implement Risk Controls

  1. Identify risk control options:
    • Inherent safety by design (Priority 1)
    • Protective measures in device (Priority 2)
    • Information for safety (Priority 3)
  2. Select optimal control following hierarchy
  3. Analyze control for new hazards introduced
  4. Document control in design requirements
  5. Implement control in design
  6. Develop verification protocol
  7. Execute verification and document results
  8. Evaluate residual risk with control in place
  9. Validation: Control implemented; verification passed; residual risk acceptable; no unaddressed new hazards

Risk Control Hierarchy

PriorityControl TypeExamplesEffectiveness
1Inherent SafetyEliminate hazard, fail-safe designHighest
2Protective MeasuresGuards, alarms, automatic shutdownHigh
3InformationWarnings, training, IFULower

Risk Control Option Analysis Template

RISK CONTROL OPTION ANALYSIS

Hazard ID: H-[XXX]
Hazard: [Description]
Initial Risk: P[X] × S[X] = [Level]

OPTIONS CONSIDERED:
| Option | Control Type | New Hazards | Feasibility | Selected |
|--------|--------------|-------------|-------------|----------|
| 1 | [Type] | [Yes/No] | [H/M/L] | [Yes/No] |
| 2 | [Type] | [Yes/No] | [H/M/L] | [Yes/No] |

SELECTED CONTROL: Option [X]
Rationale: [Justification for selection]

IMPLEMENTATION:
- Requirement: [REQ-XXX]
- Design Document: [Reference]

VERIFICATION:
- Method: [Test/Analysis/Review]
- Protocol: [Reference]
- Acceptance Criteria: [Criteria]

Risk Control Verification Methods

MethodWhen to UseEvidence
TestQuantifiable performanceTest report
InspectionPhysical presenceInspection record
AnalysisDesign calculationAnalysis report
ReviewDocumentation checkReview record

Residual Risk Evaluation

After ControlAction
AcceptableDocument, proceed
ALARP achievedDocument rationale, proceed
Still unacceptableAdditional control or design change
New hazard introducedAnalyze and control new hazard

Post-Production Risk Management

Monitor and update risk management throughout product lifecycle.

Workflow: Post-Production Risk Monitoring

  1. Identify information sources:
    • Customer complaints
    • Service reports
    • Vigilance/adverse events
    • Literature monitoring
    • Clinical studies
  2. Establish collection procedures
  3. Define review triggers:
    • New hazard identified
    • Increased frequency of known hazard
    • Serious incident
    • Regulatory feedback
  4. Analyze incoming information for risk relevance
  5. Update risk management file as needed
  6. Communicate significant findings
  7. Conduct periodic risk management review
  8. Validation: Information sources monitored; file current; reviews completed per schedule

Information Sources

SourceInformation TypeReview Frequency
ComplaintsUse issues, failuresContinuous
ServiceField failures, repairsMonthly
VigilanceSerious incidentsImmediate
LiteratureSimilar device issuesQuarterly
RegulatoryAuthority feedbackAs received
ClinicalPMCF dataPer plan

Risk Management File Update Triggers

TriggerResponse TimeAction
Serious incidentImmediateFull risk review
New hazard identified30 daysRisk analysis update
Trend increase60 daysTrend analysis
Design changeBefore implementationImpact assessment
Standards updatePer transition periodGap analysis

Periodic Review Requirements

Review ElementFrequency
Risk management file completenessAnnual
Risk control effectivenessAnnual
Post-market information analysisQuarterly
Risk-benefit conclusionsAnnual or on new data

Risk Assessment Templates

Hazard Analysis Worksheet

HAZARD ANALYSIS WORKSHEET

Product: [Device Name]
Document: HA-[Product]-[Rev]
Analyst: [Name]
Date: [Date]

| ID | Hazard | Hazardous Situation | Harm | P | S | Initial Risk | Control | Residual P | Residual S | Final Risk |
|----|--------|---------------------|------|---|---|--------------|---------|------------|------------|------------|
| H-001 | [Hazard] | [Situation] | [Harm] | [1-5] | [1-5] | [Level] | [Control ref] | [1-5] | [1-5] | [Level] |

FMEA Worksheet

FMEA WORKSHEET

Product: [Device Name]
Subsystem: [Subsystem]
Analyst: [Name]
Date: [Date]

| ID | Item | Function | Failure Mode | Effect | S | Cause | O | Control | D | RPN | Action |
|----|------|----------|--------------|--------|---|-------|---|---------|---|-----|--------|
| FM-001 | [Item] | [Function] | [Mode] | [Effect] | [1-10] | [Cause] | [1-10] | [Detection] | [1-10] | [S×O×D] | [Action] |

RPN Action Thresholds:
>200: Critical - Immediate action
100-200: High - Action plan required
50-100: Medium - Consider action
<50: Low - Monitor

Risk Management Report Summary

RISK MANAGEMENT REPORT

Product: [Device Name]
Date: [Date]
Revision: [X.X]

SUMMARY:
- Total hazards identified: [N]
- Risk controls implemented: [N]
- Residual risks: [N] Low, [N] Medium, [N] High
- Overall conclusion: [Acceptable / Not Acceptable]

RISK DISTRIBUTION:
| Risk Level | Before Control | After Control |
|------------|----------------|---------------|
| Unacceptable | [N] | 0 |
| High | [N] | [N] |
| Medium | [N] | [N] |
| Low | [N] | [N] |

CONTROLS IMPLEMENTED:
- Inherent safety: [N]
- Protective measures: [N]
- Information for safety: [N]

OVERALL RESIDUAL RISK: [Acceptable / ALARP Demonstrated]
BENEFIT-RISK CONCLUSION: [If applicable]

APPROVAL:
Risk Management Lead: _____________ Date: _______
Quality Assurance: _____________ Date: _______

Decision Frameworks

Risk Control Selection

What is the risk level?
        │
        ├── Unacceptable ──► Can hazard be eliminated?
        │                    │
        │                Yes─┴─No
        │                 │     │
        │                 ▼     ▼
        │            Eliminate  Can protective
        │            hazard     measure reduce?
        │                           │
        │                       Yes─┴─No
        │                        │     │
        │                        ▼     ▼
        │                   Add       Add warning
        │                   protection + training
        │
        └── High/Medium ──► Apply hierarchy
                            starting at Level 1

New Hazard Analysis

QuestionIf YesIf No
Does control introduce new hazard?Analyze new hazardProceed
Is new risk higher than original?Reject control optionAcceptable trade-off
Can new hazard be controlled?Add controlReject control option

Risk Acceptability Decision

ConditionDecision
All risks LowAcceptable
Medium risks with ALARPAcceptable
High risks with ALARP documentedAcceptable if benefits outweigh
Any Unacceptable residualNot acceptable - redesign

Tools and References

Scripts

ToolPurposeUsage
risk_matrix_calculator.pyCalculate risk levels and FMEA RPN
python risk_matrix_calculator.py --help

Risk Matrix Calculator Features:

  • ISO 14971 5x5 risk matrix calculation
  • FMEA RPN (Risk Priority Number) calculation
  • Interactive mode for guided assessment
  • Display risk criteria definitions
  • JSON output for integration

References

DocumentContent
iso14971-implementation-guide.mdComplete ISO 14971:2019 implementation with templates
risk-analysis-methods.mdFMEA, FTA, HAZOP, Use Error Analysis methods

Quick Reference: ISO 14971 Process

StageKey ActivitiesOutput
PlanningDefine scope, criteria, responsibilitiesRisk Management Plan
AnalysisIdentify hazards, estimate riskHazard Analysis
EvaluationCompare to criteria, ALARP assessmentRisk Evaluation
ControlImplement hierarchy, verifyRisk Control Records
ResidualOverall assessment, benefit-riskRisk Management Report
ProductionMonitor, review, updateUpdated RM File

Related Skills

SkillIntegration Point
quality-manager-qms-iso13485QMS integration
capa-officerRisk-based CAPA
regulatory-affairs-headRegulatory submissions
quality-documentation-managerRisk file management

AI-Specific Risk Management (ISO 14971 + AI Risk Considerations)

AI/ML Medical Device Risk Categories

Traditional ISO 14971 hazard categories must be extended for AI/ML-based devices:

AI-Specific HazardDescriptionSeverity PotentialDetection Difficulty
Model biasDiscriminatory outputs across patient subgroupsS3-S5 (misdiagnosis)High — requires subgroup analysis
Data driftInput data distribution shifts from training dataS2-S4 (degraded performance)Medium — requires monitoring
Concept driftClinical ground truth changes over timeS3-S5 (outdated predictions)High — requires clinical validation
Adversarial inputsIntentionally crafted inputs to deceive modelS2-S5 (incorrect output)High — requires adversarial testing
Hallucination/confabulationPlausible but incorrect outputsS3-S5 (false diagnosis)Medium — requires output validation
Training data poisoningCorrupted training data leads to systematic errorsS3-S5Very High — requires data provenance
Automation complacencyUsers over-trust AI outputsS3-S5 (missed clinical findings)Medium — requires human factors study

AI Risk Analysis Methodology

Step 1: AI System Characterization
        → Define intended use, user population, clinical context
        → Classify: locked algorithm vs. adaptive vs. continuously learning
        → Map to SaMD risk framework (IMDRF)

Step 2: AI-Specific Hazard Identification
        → Apply standard ISO 14971 hazard categories
        → ADD: data quality hazards, algorithmic hazards, integration hazards
        → Consider: training data representativeness, edge cases, failure modes

Step 3: AI Failure Mode Analysis
        → Extend FMEA with AI-specific failure modes:
           - False positive/negative beyond acceptable rates
           - Performance degradation over time
           - Out-of-distribution input handling
           - Feature importance shift
        → For each failure mode: determine harm pathway to patient

Step 4: AI-Specific Risk Controls
        → Confidence thresholds (reject uncertain predictions)
        → Human-in-the-loop for high-risk decisions
        → Input validation and out-of-distribution detection
        → Continuous performance monitoring with drift detection
        → Automated model retraining safeguards
        → Fail-safe modes when AI system is unavailable

Step 5: AI Risk Monitoring Plan
        → Define performance metrics and acceptable thresholds
        → Establish monitoring frequency (real-time, daily, weekly)
        → Define retraining triggers and validation requirements
        → Plan for model versioning and rollback procedures

AI Risk Acceptability Considerations

Risk FactorAdditional Consideration for AI
ProbabilityInclude statistical confidence intervals for model performance
SeverityConsider both direct harm and harm from delayed correct treatment
DetectabilityFactor in opacity of AI decision-making (explainability)
BenefitQuantify clinical benefit vs. non-AI alternative
ALARPState-of-the-art includes current AI best practices (GMLP)

Cybersecurity Risk Integration (IEC 81001-5-1)

Health Software Cybersecurity Risk Management

IEC 81001-5-1:2021 establishes cybersecurity lifecycle requirements for health software. Integrate with ISO 14971:

ISO 14971 StageIEC 81001-5-1 IntegrationCombined Output
Risk Management PlanInclude cybersecurity scope, threat modeling methodologyCombined RM + cybersecurity plan
Hazard identificationAdd cybersecurity threat identification (STRIDE, attack trees)Extended hazard analysis with cyber threats
Risk estimationEstimate probability based on threat landscape and exploitabilityRisk register with cyber-specific likelihood factors
Risk controlImplement security controls as risk mitigationsControls traceable to both safety and security risks
Residual riskEvaluate residual cybersecurity riskCombined residual risk assessment
Post-productionMonitor threat landscape, CVE databases, incident reportsIntegrated PMS + security monitoring

Cybersecurity Threat Categories for Medical Devices

Threat CategoryExamplesISO 14971 Harm Pathway
Unauthorized accessCredential theft, privilege escalationModification of device settings → patient harm
Data breachPHI exfiltration, ransomwareLoss of data availability → delayed treatment
Denial of serviceNetwork flooding, resource exhaustionDevice unavailable → delayed diagnosis/treatment
MalwareRansomware, trojans, supply chain compromiseDevice malfunction → incorrect output
Data integrityMan-in-the-middle, data manipulationCorrupted clinical data → incorrect treatment
Supply chainCompromised dependencies, malicious updatesBackdoor access → any harm pathway

Cybersecurity FMEA Extension

Add these columns to standard FMEA for cybersecurity failure modes:

CYBERSECURITY FMEA EXTENSION

| ID | Component | Security Function | Threat | Attack Vector | Exploitability | Impact | S | O | D | RPN | Security Control |
|----|-----------|-------------------|--------|---------------|---------------|--------|---|---|---|-----|-----------------|
| CS-001 | Auth module | User authentication | Credential theft | Phishing | High (8) | Full access | 8 | 6 | 4 | 192 | MFA + session management |
| CS-002 | Data store | Data confidentiality | SQL injection | Network input | Medium (5) | Data breach | 9 | 4 | 3 | 108 | Parameterized queries + WAF |
| CS-003 | Update mechanism | Integrity | Supply chain | Compromised update | Low (3) | Malware install | 10 | 2 | 7 | 140 | Code signing + integrity verification |

Supply Chain Risk Management

Medical Device Supply Chain Risks

Risk CategoryDescriptionProbabilityImpactControl Strategy
Single-source componentCritical component from sole supplierMediumCriticalDual-source qualification, safety stock
Counterfeit componentsFraudulent parts entering supply chainLow-MediumCatastrophicSupplier audits, incoming inspection, chain of custody
Supplier quality failureSupplier QMS breakdownMediumHighSupplier qualification, periodic audits, quality agreements
Software dependencyVulnerable or unsupported open-source libraryHighMedium-HighSBOM management, vulnerability scanning, update policy
Geopolitical disruptionSanctions, trade restrictions, supply interruptionLow-MediumHighGeographic diversification, buffer inventory
Raw material shortageRare earth, specialty materials unavailabilityLowHighAlternative material qualification, forward contracts

Supply Chain Risk Assessment Workflow

Step 1: Supply Chain Mapping
        → Identify all direct suppliers (Tier 1)
        → Map critical Tier 2 and Tier 3 suppliers
        → Document component criticality (safety-critical, quality-critical, standard)

Step 2: Supplier Risk Scoring
        → Quality risk: past performance, certification status, audit results
        → Financial risk: stability, dependency on your business
        → Geographic risk: natural disaster, political stability
        → Cyber risk: supplier's information security posture
        → Concentration risk: single-source, regional concentration

Step 3: Risk Treatment
        → Critical suppliers: quality agreements, annual audits, dual-sourcing
        → High-risk suppliers: enhanced monitoring, contingency plans
        → Medium-risk suppliers: periodic review, performance metrics
        → Low-risk suppliers: standard purchasing controls

Step 4: Ongoing Monitoring
        → Supplier scorecard tracking (quality, delivery, responsiveness)
        → Annual supplier risk reassessment
        → Trigger-based reassessment (quality event, financial change, M&A)

Post-Market Risk Monitoring Automation

Automated Signal Detection

Data SourceAutomation ApproachAlert Threshold
Complaint databaseStatistical process control (SPC) charts on complaint rates>2 sigma deviation from baseline
Adverse event reportsNLP-based classification + trend analysisAny serious event; trend >3x baseline
Literature monitoringAutomated PubMed/regulatory database searchesNew publication on similar device adverse events
Field service dataAutomated failure rate trackingFailure rate exceeds design MTBF by >20%
Social media/forumsKeyword monitoring for device-related complaintsCluster of similar complaints in 30-day window
Regulatory databasesMAUDE, EUDAMED vigilance module, BfArM monitoringNew recall or safety communication for similar device

Risk Management File Update Automation

Automated Trigger → Risk Review Decision Tree

New complaint received
    → Classify by hazard category (auto or manual)
    → Check: Known hazard?
        YES → Update frequency data → Recalculate risk level
                → Risk level changed? → Flag for risk management review
        NO  → New hazard identified → Initiate risk analysis
              → Estimate initial risk → Determine controls needed
              → Update risk management file

Trend threshold exceeded
    → Generate trend report with statistical analysis
    → Convene risk management review within 30 days
    → Update risk management file with new probability estimates
    → Evaluate if additional risk controls needed
    → If safety issue: initiate FSCA/field action assessment

Cross-Reference: NIST Cybersecurity Framework Risk Assessment

Map ISO 14971 risk management to NIST CSF 2.0 for comprehensive risk coverage:

ISO 14971 ProcessNIST CSF 2.0 FunctionIntegration Point
Hazard identificationIdentify (ID.RA)Combine clinical and cyber threat identification
Risk estimationIdentify (ID.RA-03, ID.RA-04)Unified likelihood and impact scales
Risk evaluationIdentify (ID.RA-05, ID.RA-06)Single risk register with combined acceptance criteria
Risk controlProtect (PR), Detect (DE)Security controls as risk mitigations
Residual risk evaluationGovern (GV.RM)Combined residual risk statement
Post-production monitoringDetect (DE.CM, DE.AE)Unified monitoring for safety and security events

See also:

../information-security-manager-iso27001/SKILL.md
for ISO 27001 security controls that serve as risk mitigations.


Cross-Reference: DORA ICT Risk Management

For medical device companies operating as or supplying to financial entities in the EU, the Digital Operational Resilience Act (DORA, Regulation 2022/2554) adds ICT risk requirements:

DORA RequirementISO 14971 IntegrationAction
ICT risk management framework (Art. 6)Extend risk management plan to include ICT risksAdd ICT-specific risk categories to hazard analysis
ICT incident management (Art. 17)Align with post-production monitoringUnified incident classification and response
Digital operational resilience testing (Art. 24-27)Complement risk control verificationInclude penetration testing in verification activities
Third-party ICT risk (Art. 28-30)Extend supply chain risk managementAssess ICT service providers per DORA requirements
Information sharing (Art. 45)Enhance post-market information sourcesParticipate in threat intelligence sharing arrangements

Enhanced FMEA with Cybersecurity Failure Modes

Combined Safety-Security FMEA Template

COMBINED SAFETY-SECURITY FMEA

Product: [Device Name]
Subsystem: [Subsystem]
Date: [Date]

TRADITIONAL SAFETY FAILURE MODES:
| ID | Item | Function | Failure Mode | Effect | S | Cause | O | Detection | D | RPN | Control |
|----|------|----------|--------------|--------|---|-------|---|-----------|---|-----|---------|
| FM-001 | Sensor | Measure vital sign | Incorrect reading | Wrong diagnosis | 8 | Calibration drift | 4 | Self-test | 3 | 96 | Auto-calibration |

CYBERSECURITY FAILURE MODES:
| ID | Asset | Security Objective | Threat | Attack Vector | Exploitability (O) | Impact (S) | Detection (D) | RPN | Security Control |
|----|-------|-------------------|--------|---------------|-------------------|-----------|---------------|-----|-----------------|
| CS-001 | Sensor data | Integrity | Data manipulation | MITM attack | 3 | 8 | 5 | 120 | TLS + data signing |
| CS-002 | Firmware | Integrity | Malicious update | Supply chain | 2 | 10 | 6 | 120 | Secure boot + code signing |
| CS-003 | User interface | Availability | DoS attack | Network flooding | 5 | 6 | 4 | 120 | Rate limiting + redundancy |

AI/ML FAILURE MODES (if applicable):
| ID | Component | ML Function | Failure Mode | Clinical Effect | S | Cause | O | Detection | D | RPN | ML Control |
|----|-----------|-------------|--------------|----------------|---|-------|---|-----------|---|-----|-----------|
| AI-001 | Classifier | Diagnose condition | False negative | Missed diagnosis | 9 | Distribution shift | 4 | Performance monitoring | 5 | 180 | Drift detection + human review |
| AI-002 | Classifier | Diagnose condition | Biased output | Health disparity | 8 | Unrepresentative training data | 3 | Subgroup analysis | 6 | 144 | Fairness constraints + diverse data |

COMBINED RPN THRESHOLDS:
>200: Critical — Immediate action required (all categories)
100-200: High — Action plan within 30 days
50-100: Medium — Monitor and consider action
<50: Low — Accept and monitor

Cybersecurity-Safety Interaction Analysis

Safety ControlCybersecurity ImpactMitigation
Alarm systemAlarm suppression via unauthorized accessAccess control + alarm integrity monitoring
Fail-safe modeDenial of service forcing perpetual safe modeRate limiting + redundant communication
Software updateMalicious update compromising safety functionCode signing + dual authorization + rollback capability
Data loggingLog tampering concealing safety eventsAppend-only logs + cryptographic integrity
User authenticationLockout preventing emergency useBreak-glass procedures + local override

Enhanced Risk Management — AI, Cybersecurity & Cross-Framework Integration

AI-Specific Risk Management

When managing risk for AI/ML medical devices, extend ISO 14971 with:

  • AI Model Risk: Training data bias, model drift, adversarial attacks, explainability gaps
  • Performance Degradation: Monitor for distribution shift, concept drift, and data quality issues
  • Algorithmic Bias: Demographic parity, equalized odds, calibration across subgroups
  • Human-AI Interaction Risks: Over-reliance, automation bias, alert fatigue, trust calibration
  • Cross-reference: See
    eu-ai-act-specialist
    for EU AI Act risk classification

Cybersecurity Risk Integration (IEC 81001-5-1)

  • Health Software Cybersecurity: IEC 81001-5-1 extends ISO 14971 for cybersecurity
  • Threat Modeling: STRIDE methodology applied to medical device architecture
  • Cybersecurity FMEA: Failure modes include unauthorized access, data breach, ransomware, supply chain attack
  • Vulnerability Management: CVSS scoring integrated with ISO 14971 severity/probability matrix
  • Cross-reference: See
    infrastructure-compliance-auditor
    for technical security checks

Supply Chain Risk Management

  • Component Risk: Third-party software vulnerabilities (SBOM-based assessment)
  • Supplier Risk: Single-source dependencies, geopolitical risks, quality history
  • Cloud Risk: Data residency, service availability, vendor lock-in
  • Cross-reference: See
    nis2-directive-specialist
    for NIS2 supply chain requirements

Cross-Framework Risk Mapping

Risk AreaISO 14971NIST CSF 2.0DORANIS2
Risk AssessmentClause 4ID.RAArt. 6Art. 21.1
Risk TreatmentClause 7PR (all)Art. 9Art. 21.2
MonitoringClause 9DE.CMArt. 10Art. 21.2.f
Incident ResponseClause 9RS.MAArt. 17Art. 23
Continuous ImprovementClause 10ID.IMArt. 13Art. 21.2.f

Troubleshooting

ProblemLikely CauseResolution
Risk matrix calculator returns "Invalid probability"Probability value outside 1-5 rangeUse integers 1-5 for probability (
--probability
) and 1-5 for severity (
--severity
). Run
--list-criteria
to display the full scale definitions.
FMEA RPN calculation produces unexpected resultsSeverity, occurrence, or detection values outside 1-10 rangeFMEA mode (
--fmea
) requires
--severity
,
--occurrence
, and
--detection
values each in the 1-10 range. Values outside this range produce unreliable RPNs.
Risk level shows "Medium" but stakeholders expect "High"Risk acceptability criteria differ from the tool's default 5x5 matrixThe default matrix follows common ISO 14971 practice. If your organization uses a custom risk matrix, adjust the risk acceptability criteria in your Risk Management Plan and document deviations.
Post-production risk data not triggering file updatesReview triggers not defined or too narrowDefine explicit triggers: any serious incident (immediate), new hazard identification (30 days), trend increase (60 days), design change (before implementation), and standards update (per transition period).
AI-specific hazards not captured in FMEAStandard FMEA template lacks AI failure modesExtend the FMEA with AI-specific failure modes: model bias, data drift, concept drift, adversarial inputs, automation complacency. Use the AI Risk Analysis Methodology section as a guide.
Cybersecurity threats not integrated into risk assessmentThreat modeling methodology not aligned to ISO 14971Use STRIDE methodology for threat identification, then map each threat to an ISO 14971 harm pathway. Reference IEC 81001-5-1 for health software cybersecurity integration.
Benefit-risk analysis requested but no template availableThe tool calculates risk levels but does not generate benefit-risk documentsThe benefit-risk analysis is a narrative document per ISO 14971 Clause 8. Use the risk matrix outputs as quantitative inputs, then document clinical benefits vs. residual risks in the Risk Management Report.

Success Criteria

  • Risk Management Plan approved with defined scope, risk acceptability matrix, RACI chart, and post-production monitoring plan before design input phase
  • 100% of ISO 14971 hazard categories analyzed (electrical, mechanical, thermal, radiation, biological, chemical, software, use error, environmental) with documented rationale for each
  • All identified risks evaluated against the 5x5 acceptability matrix with no uncontrolled "Unacceptable" residual risks remaining
  • Risk controls implemented following the priority hierarchy (inherent safety first, then protective measures, then information for safety) with verification records for every control
  • Overall residual risk evaluated as acceptable or ALARP demonstrated, with benefit-risk analysis completed for any residual risks remaining in High territory
  • Post-production risk monitoring operational with defined information sources, review triggers, and a documented process for updating the Risk Management File
  • For AI/ML devices: AI-specific risk categories (bias, drift, adversarial inputs) assessed per BS/AAMI 34971:2023 or equivalent, with continuous performance monitoring thresholds defined

Scope & Limitations

In Scope:

  • ISO 14971:2019 risk management process implementation (planning, analysis, evaluation, control, residual risk, production/post-production)
  • 5x5 risk matrix calculation and FMEA RPN scoring
  • Hazard analysis methodology guidance (FMEA, FTA, HAZOP, Use Error Analysis, PHA)
  • Risk control hierarchy application and verification planning
  • Benefit-risk analysis framework
  • Post-production risk monitoring and risk file update triggers
  • AI/ML-specific risk management extensions (model bias, drift, adversarial inputs)
  • Cybersecurity risk integration per IEC 81001-5-1
  • Supply chain risk assessment methodology
  • Cross-framework risk mapping (ISO 14971, NIST CSF, DORA, NIS2)

Out of Scope:

  • Clinical investigation design or execution (risk management informs clinical strategy but does not execute studies)
  • Software hazard analysis per IEC 62304 (the skill references software risk but detailed software lifecycle management requires IEC 62304 expertise)
  • Biocompatibility testing or ISO 10993 evaluation (the skill identifies biological hazards but does not execute biocompatibility testing)
  • Cybersecurity penetration testing or vulnerability scanning (use infrastructure-compliance-auditor for technical security testing)
  • CAPA root cause analysis execution (use capa-officer for 5-Why, Fishbone, FTA, FMEA-based root cause investigation)
  • Regulatory submission of risk management files (use regulatory-affairs-head for submission strategy and packaging)

Integration Points

SkillIntegration
quality-manager-qms-iso13485Risk management (Clause 7.1) integrates with QMS product realization planning; risk file is part of the Design History File
capa-officerPost-market risk signals may trigger CAPA; CAPA root cause analysis methods (FMEA, FTA) overlap with risk analysis techniques
regulatory-affairs-headRisk management file is required for FDA submissions and EU MDR Technical Documentation; benefit-risk analysis supports clinical evaluation
quality-documentation-managerRisk management file and records must be controlled per document control procedures (Clause 4.2)
fda-consultant-specialistFDA cybersecurity guidance (2025 update) requires integration of security risks into ISO 14971 processes for premarket submissions
infrastructure-compliance-auditorTechnical security controls validated by the infrastructure auditor serve as risk mitigations for cybersecurity threats in the risk assessment
nist-csf-specialistNIST CSF risk assessment (ID.RA) maps to ISO 14971 hazard identification and risk estimation; unified risk register possible

Tool Reference

risk_matrix_calculator.py

Calculates ISO 14971 risk levels and FMEA Risk Priority Numbers.

FlagRequiredDescription
--probability
Yes (for ISO 14971 mode)Probability level (1-5): 1=Improbable, 2=Remote, 3=Occasional, 4=Probable, 5=Frequent
--severity
Yes (for both modes)Severity level: 1-5 for ISO 14971 mode, 1-10 for FMEA mode
--fmea
NoSwitch to FMEA RPN calculation mode (requires
--severity
,
--occurrence
,
--detection
)
--occurrence
Yes (for FMEA mode)Occurrence rating (1-10) for FMEA RPN calculation
--detection
Yes (for FMEA mode)Detection rating (1-10) for FMEA RPN calculation
--interactive
NoLaunch interactive mode for guided risk assessment
--list-criteria
NoDisplay probability, severity, and risk level criteria definitions