4.3: Risk-Based Approach

ISO 14971 Risk Management Process

Integration with IEC 62304

ISO 14971:2019: Application of risk management to medical devices

Relationship to IEC 62304:

• IEC 62304 Clause 7: Software Risk Management Process
• Requires ISO 14971 risk management for software hazards
• Bidirectional integration: Software hazards → Risk controls → Software requirements

Risk Management Lifecycle: The following diagram illustrates the ISO 14971 risk management process integrated with ASPICE, showing hazard identification, risk estimation, risk evaluation, risk control, and residual risk assessment stages.

Software Hazard Analysis

Example: Over-Infusion Hazard

Hazard Identification (ISO 14971, Clause 5.3):

Hazard ID: RISK-002 Hazard: Over-infusion of insulin (10× intended dose)

Hazardous Situation:

1. Nurse enters flow rate 10 mL/hr (intended)
2. Software error: Interprets as 100 mL/hr (10× error)
3. Insulin over-infusion → Severe hypoglycemia (blood glucose <30 mg/dL)
4. Patient: Loss of consciousness, seizure, potential death

Severity: S=5 (Death or irreversible harm) Probability (before risk control): P=3 (Occasional, ~1 in 1,000 uses) Risk Score: 5 × 3 = 15 (HIGH) → Not acceptable, requires risk control

Risk Control Measures

Risk Control Strategy (ISO 14971, Clause 6.2):

Control Measure 1: Drug Library with Hard Dose Limits

/**
 * @brief Validate user-entered flow rate against drug library limits
 * @implements Risk Control for [RISK-002] Over-infusion
 * @safety_class C
 */
typedef struct {
    char drug_name[50];        // e.g., "Insulin Regular"
    float hard_limit_min;      // mL/hr (absolute minimum, enforced)
    float hard_limit_max;      // mL/hr (absolute maximum, enforced)
    float soft_limit_min;      // mL/hr (warning threshold)
    float soft_limit_max;      // mL/hr (warning threshold)
} DrugProfile_t;

// Drug library (1,200 drugs, stored in flash memory)
static const DrugProfile_t drug_library[1200] = {
    {
        .drug_name = "Insulin Regular (100 units/mL)",
        .hard_limit_min = 0.1,     // Minimum: 0.1 mL/hr
        .hard_limit_max = 10.0,    // Maximum: 10 mL/hr (hard limit)
        .soft_limit_min = 0.5,     // Warning if < 0.5 mL/hr
        .soft_limit_max = 5.0      // Warning if > 5 mL/hr (typical max)
    },
    // ... 1,199 more drugs
};

/**
 * @brief Validate flow rate against drug library
 * @param[in] drug_index Index into drug_library array
 * @param[in] flow_rate_mlhr User-entered flow rate (mL/hr)
 * @return 0=OK, 1=Soft limit warning, -1=Hard limit violation (REJECT)
 */
int DrugLibrary_ValidateFlowRate(uint16_t drug_index, float flow_rate_mlhr)
{
    if (drug_index >= 1200) {
        return -1;  // Invalid drug index
    }

    const DrugProfile_t* drug = &drug_library[drug_index];

    // Hard limit check (REJECT if violated)
    if (flow_rate_mlhr < drug->hard_limit_min ||
        flow_rate_mlhr > drug->hard_limit_max) {
        // Display error: "FLOW RATE EXCEEDS HARD LIMIT FOR INSULIN"
        // Prevent infusion start until corrected
        return -1;  // REJECT
    }

    // Soft limit check (WARNING if violated)
    if (flow_rate_mlhr < drug->soft_limit_min ||
        flow_rate_mlhr > drug->soft_limit_max) {
        // Display warning: "Flow rate outside typical range, verify order"
        // Nurse can override after confirmation
        return 1;  // WARNING
    }

    return 0;  // OK
}

Effectiveness: Prevents 100 mL/hr insulin entry (hard limit max = 10 mL/hr) → REJECT

Control Measure 2: Independent Watchdog (Dual-Channel Architecture)

Architecture: Main CPU + Independent Watchdog CPU

┌──────────────────────────────────────────────────────────────┐
│           Dual-Channel Safety Architecture                   │
├──────────────────────────────────────────────────────────────┤
│                                                               │
│  Main CPU (ARM Cortex-M7)                  Watchdog CPU      │
│  ┌──────────────────────┐                  ┌──────────────┐ │
│  │ Drug Delivery Control│                  │ Independent  │ │
│  │ • Calculate flow rate│───────────────►  │ Flow Rate    │ │
│  │ • Control motor speed│   (Expected flow)│ Monitor      │ │
│  └──────────────────────┘                  │              │ │
│           │                                 │ • Reads drop │ │
│           │                                 │   sensor     │ │
│           ▼                                 │ • Calculates │ │
│  ┌──────────────────────┐                  │   actual flow│ │
│  │ Motor Driver (PWM)   │                  └──────────────┘ │
│  └──────────────────────┘                         │         │
│           │                                       │         │
│           ▼                                       ▼         │
│  ┌──────────────────────┐             ┌─────────────────┐  │
│  │ Peristaltic Pump     │             │ Comparator:     │  │
│  │ (Fluid delivery)     │             │ If actual flow  │  │
│  └──────────────────────┘             │ > expected + 20%│  │
│           │                            │ → ALARM & STOP  │  │
│           ▼                            └─────────────────┘  │
│  ┌──────────────────────┐                                   │
│  │ Drop Sensor          │                                   │
│  │ (Optical, counts drps│                                   │
│  └──────────────────────┘                                   │
│                                                               │
└───────────────────────────────────────────────────────────────┘

Implementation:

/**
 * @brief Independent watchdog monitors actual flow rate
 * @safety_class C (independent verification)
 */
void Watchdog_MonitorFlowRate(void)
{
    float expected_flow = MainCPU_GetTargetFlowRate();  // From main CPU
    float actual_flow = DropSensor_MeasureFlowRate();   // Independent measurement

    float error = fabs(actual_flow - expected_flow);
    float tolerance = expected_flow * 0.20f;  // ±20% tolerance

    if (error > tolerance) {
        // Flow rate mismatch detected!
        // Example: Expected 10 mL/hr, but actual 100 mL/hr (90 mL/hr error > 2 mL/hr tolerance)
        Alarm_Trigger(ALARM_FLOW_RATE_ERROR, PRIORITY_HIGH);
        Motor_Stop();  // Emergency stop
        EventLog("WATCHDOG: Flow rate error detected, pump stopped");
    }
}

Effectiveness: Detects 100 mL/hr over-infusion (vs 10 mL/hr expected) → STOP within 1 minute

Risk Re-Estimation (After Controls):

Combined Probability: P = 3 × 0.05 × 0.10 = 0.015 (approx P=1, Rare)

Residual Risk: S=5 × P=1 = 5 (LOW) [PASS] Acceptable

Risk Control Verification: Verify risk control effectiveness through: (1) Unit testing of control logic, (2) Integration testing (watchdog + main CPU interaction), (3) Fault injection testing (simulate over-infusion, verify watchdog response). Document verification evidence in Risk Management File.

FMEA (Failure Modes and Effects Analysis)

Software FMEA Example

FMEA for Drug Delivery Control Module

RPN (Risk Priority Number): S × O × D (1-125 scale)

• RPN ≥ 40: High priority, requires risk control
• RPN 20-39: Medium priority, recommended control
• RPN < 20: Low priority, acceptable

Actions:

• Watchdog FMEA (RPN=40): Add independent code review by safety engineer, increase HIL test coverage

Usability Engineering (IEC 62366)

Use Error Analysis

IEC 62366-1: Application of usability engineering to medical devices

Goal: Prevent use errors (user mistakes leading to harm)

Example Use Error: Nurse confuses mg/hr with mL/hr

Scenario:

1. Physician orders: "Morphine 2 mg/hr" (dose in milligrams per hour)
2. Nurse enters: "2 mL/hr" (confuses units, enters volume instead of dose)
3. Morphine concentration: 10 mg/mL
4. Actual dose delivered: 2 mL/hr × 10 mg/mL = 20 mg/hr (10× overdose)
5. Consequence: Respiratory depression, potential death

Risk: S=5 × P=3 (occasional nurse error) = 15 (HIGH)

Risk Control: User Interface Design

Control Measure: Dose-Error Reduction Software (DERS)

UI Redesign:

┌──────────────────────────────────────────────┐
│        SmartFlow Infusion Pump Display      │
├──────────────────────────────────────────────┤
│                                              │
│  Drug: Morphine Sulfate 10 mg/mL            │
│  ──────────────────────────────────────────  │
│                                              │
│  DOSE (mg/hr): [ 2.0 ]  ← Primary unit      │
│                                              │
│  Volume (mL/hr): 0.2    ← Auto-calculated   │
│                 (read-only, grayed out)      │
│                                              │
│  [PASS] WITHIN SAFE RANGE (0.5-5 mg/hr)          │
│                                              │
│  [START INFUSION]  [CANCEL]                 │
│                                              │
└──────────────────────────────────────────────┘

Key Design Features:

1. Dose entry in clinical units (mg/hr, not mL/hr) → Matches physician order
2. Volume auto-calculated (mL/hr = dose / concentration) → Eliminates conversion errors
3. Real-time range check (green checkmark if within 0.5-5 mg/hr) → Immediate feedback

Usability Testing (IEC 62366-1, Clause 5.9):

• Participants: 15 nurses (5 novice, 5 experienced, 5 expert)
• Tasks: Program 20 drug infusions (various drugs, doses)
• Results: 0 use errors (all doses entered correctly) [PASS]
• Conclusion: DERS effective, risk reduced to P=1 (rare)

Residual Risk: S=5 × P=1 = 5 (LOW) [PASS] Acceptable

Lessons Learned

What Worked Well [PASS]

1. ISO 14971 Risk Management from Day 1

Success: Risk analysis completed Month 2 (before coding started)

Benefit:

• 25 software hazards identified early
• Risk controls designed into architecture (not bolted on later)
• 15 safety requirements derived directly from risk analysis

Example:

• Hazard: Air embolism → Requirement: [SWE-SAFE-001] "Detect 50 µL air within 2 seconds"
• Hazard: Over-infusion → Requirement: [SWE-SAFE-002] "Drug library with hard dose limits"

Time Saved: 200 hours (no late-stage redesign to add safety features)

2. Dual-Channel Architecture (Independent Watchdog)

Success: Watchdog detected 3 over-infusion bugs during integration testing

Evidence:

• Bug 1 (Month 13): PID controller divide-by-zero error (flow rate calculated as infinity)
  • Watchdog detected: Actual flow 999 mL/hr, expected 50 mL/hr → STOP
  • Fix: Added input validation (prevent dt=0 in PID calculation)
• Bug 2 (Month 14): Integer overflow in motor speed calculation
  • Watchdog detected: Actual flow 250 mL/hr, expected 100 mL/hr → STOP
• Bug 3 (Month 15): Drug library corruption (CRC check failed, hard limits disabled)
  • Watchdog detected: Flow rate 150 mL/hr (exceeds soft limit) → ALARM

Lesson: Independence is key (watchdog on separate CPU, separate sensor)

3. AI-Assisted FMEA

Success: ChatGPT-4 generated initial FMEA table from component list

Process:

1. Provide ChatGPT-4 with software architecture (10 modules)
2. Prompt: "Generate FMEA table for each module, identify failure modes, effects, causes"
3. AI output: 50 failure modes (draft)
4. Engineer review: 8 hours (vs 40 hours manual FMEA creation)

Example AI Output:

Component: Drug Library
Failure Mode: Database corruption (bit flips in flash memory)
Effect: Hard dose limits not enforced → Over-infusion possible
Severity: 5 (death)
Cause: Flash memory wear-out, cosmic ray bit flip
Occurrence: 1 (rare)
Detection: 3 (CRC check at startup)
RPN: 5 × 1 × 3 = 15 (medium priority)
Risk Control: Implement CRC-32 check on drug library every startup

Time Saved: 40h → 8h (80% reduction)

What Didn't Work [WARN]

1. Usability Testing Too Late (Month 15)

Problem: Usability testing revealed 5 use errors (nurses confused by UI)

Impact:

• UI redesign required (2 weeks, Month 16)
• Re-testing with 15 nurses (1 week)
• Delayed FDA submission by 3 weeks (Month 17 instead of Month 16)

Root Cause: Usability testing scheduled after system testing (too late)

Fix: Should have conducted formative usability testing at Month 10 (during UI development)

Recommendation: IEC 62366 formative testing early (iterative UI design, not one-shot testing)

2. SOUP Anomaly Analysis Underestimated (FreeRTOS)

Problem: FreeRTOS v10.4.3 release notes: 120 pages, dense technical content

Underestimation: Assumed 8 hours to review, actual: 25 hours

Challenge:

• Identify which anomalies apply to our use case (static allocation, no heap)
• Evaluate security vulnerabilities (CVE database)
• Determine acceptable vs unacceptable risks

Solution: AI assistance (ChatGPT-4 summarized 120 pages → 5-page summary, 8 hours → 2 hours)

Lesson: SOUP analysis is time-consuming (allocate 20% of SOUP integration effort)

3. Cybersecurity (FDA 2023 Guidance) Added Late

Problem: FDA published new cybersecurity guidance (2023) midway through project (Month 10)

New Requirements:

• Software Bill of Materials (SBOM)
• Threat modeling (STRIDE)
• Vulnerability scanning

Impact: +150 hours effort (Month 11-16)

• SBOM generation: 20 hours (Syft tool setup, verification)
• Threat model: 80 hours (STRIDE analysis for WiFi attack vectors)
• Penetration testing: 50 hours (ethical hacker, fix 3 vulnerabilities)

Lesson: Monitor FDA guidances continuously (cybersecurity is evolving rapidly)

Recommendation: Build in 10% contingency for regulatory changes

Project Metrics Summary

Final Results

AI Contribution Summary

Overall: 845 hours → 441 hours (48% reduction)

ROI: AI tools cost €5,000 (licenses), saved 404 hours × €80/hour = €32,320 (6.5× ROI)

AI Tool Cost Breakdown: The €5,000 includes ChatGPT-4 API costs for FMEA/documentation (€2,000), Claude API for technical writing (€1,500), GitHub Copilot licenses (€1,000), and SBOM tools (€500 for enterprise Syft/Grype). The higher medical device ROI (6.5x vs 8x automotive) reflects greater manual review overhead for Class C code.

Recommendations for Future Projects

For IEC 62304 + ISO 14971 Compliance

1. Risk Management from Day 1

   • Conduct hazard analysis Month 1-2 (before architecture design)
   • Derive 40% of safety requirements from risk analysis
   • Integrate risk controls into architecture (not bolted on later)

2. Dual-Channel Safety Architecture

   • Independent watchdog on separate CPU (detects main CPU failures)
   • Use different sensor technology (e.g., optical + ultrasonic for air detection)
   • Budget 15% extra effort for dual-channel design (worth it for SIL 3 / Class C)

3. Usability Engineering (IEC 62366) Early

   • Formative testing at UI prototype stage (Month 6-8, not Month 15)
   • 3-5 iterative rounds with nurses (rapid feedback)
   • Summative validation at end (Month 15-16, confirms no use errors)

For FDA/EU Regulatory Compliance

1. Monitor FDA Guidances Continuously

   • FDA website: Check monthly for new/updated guidances
   • Example: Cybersecurity guidance (2023) added SBOM requirement
   • Build in 10% contingency budget for regulatory changes

2. Engage Regulatory Affairs Early

   • Pre-submission meeting with FDA (Month 6) → Clarify substantial equivalence
   • Notified Body pre-audit (Month 12) → Identify MDR gaps early
   • Saves 3-6 months in submission review time

3. AI for Documentation (60% Faster)

   • ChatGPT-4: Draft 510(k) device description, GSPR tables
   • Claude Sonnet: Summarize requirements for FDA reviewers
   • Syft: Auto-generate SBOM (SPDX format)
   • Engineer review: Always required (AI is assistant, not replacement)

Conclusion

Medical Device Software Development: Regulatory Success

• [PASS] FDA 510(k) Clearance: K254321 (granted Month 18)
• [PASS] CE Mark: TÜV SÜD certificate (EU MDR compliant)
• [PASS] IEC 62304 Class C: Fully compliant (rigorous lifecycle)
• [PASS] ISO 14971: 25 residual risks, all acceptable
• [PASS] IEC 62366: 0 use errors in usability validation

Key Differences from Automotive/Industrial (Chapters 25-26):

• Regulatory Complexity: FDA + EU MDR (vs automotive: ISO 26262, industrial: IEC 61508)
• Focus: Patient safety + usability (vs automotive: functional safety, industrial: process safety)
• AI Impact: 48% productivity gain (documentation heavy, AI excels at drafting)

Message: Medical device software development is the most regulated domain (FDA, EU MDR, IEC 62304, ISO 14971, IEC 62366). ASPICE provides 60% foundation, but medical-specific standards add significant overhead. AI tools shine in documentation (60% faster), but Class C safety-critical code requires rigorous manual review. Risk management (ISO 14971) must start Day 1, not as afterthought.

Chapter 27 Complete: Medical device software development demonstrates IEC 62304 + ISO 14971 + FDA/EU regulatory compliance.

Next: ML-enabled ADAS systems (Chapter 28) - AI in safety-critical perception.