Skip to main content

Medical Devices: Insulin Delivery System

Overview​

This sample project demonstrates NirmIQ features for IEC 62304 Class C medical device software. The Automated Insulin Delivery System project shows how to manage software requirements for a life-sustaining medical device, integrate risk management (ISO 14971), and maintain regulatory traceability for FDA 510(k) submission.

Project Details​

  • Domain: Medical Devices
  • System: Automated Insulin Delivery System (Insulin Pump)
  • Compliance Standards:
    • IEC 62304 (Medical Device Software Lifecycle) - Class C
    • ISO 14971 (Risk Management for Medical Devices)
    • IEC 62366 (Usability Engineering)
    • FDA 21 CFR Part 820 (QMS)
  • Regulatory Pathway: FDA 510(k) (Premarket Notification)
  • Lifecycle Phase: Design Verification & Validation
  • Organization: Sample - Medical Device Manufacturer
  • Custom ID Prefix: IDS

Features Demonstrated​

Requirements Management​

The project uses a 4-level requirement hierarchy following IEC 62304:

  1. User Needs (UN) - Stakeholder and patient needs

    • Example: "Device shall deliver insulin accurately within ±5% of prescribed dose"
    • Custom IDs: IDS-UN-001, IDS-UN-002, etc.

  2. System Requirements (SYS) - System-level specifications

    • Example: "System shall deliver basal insulin at programmable rates 0.05-30 U/hr"
    • Custom IDs: IDS-SYS-001, IDS-SYS-002, etc.

  3. Software Requirements (SWR) - Software functional requirements

    • Example: "Dose calculation algorithm shall compute insulin delivery based on current glucose, carb intake, and correction factor"
    • Custom IDs: IDS-SWR-001, IDS-SWR-002, etc.

  4. Risk Control Measures (RCM) - Safety mitigations as requirements

    • Example: "Software shall implement maximum daily dose limit to prevent overdose"
    • Custom IDs: IDS-RCM-001, IDS-RCM-002, etc.

Total Requirements: ~85 requirements covering:

  • Insulin dose calculation algorithms
  • Continuous glucose monitoring (CGM) integration
  • User interface (display, buttons, alarms)
  • Basal and bolus delivery modes
  • Occlusion detection
  • Low insulin detection
  • Battery monitoring
  • Alarm and alert management
  • Data logging and export

Risk Management Integration (ISO 14971)​

Process FMEA (PFMEA) Focus:

  • Drug delivery mechanism failures
  • Sensor input errors
  • User interaction errors
  • Software defects
  • Battery and power failures

Risk Control Effectiveness:

  • Each FMEA failure mode linked to Risk Control Measures
  • Residual risk assessment after mitigations
  • Verification of risk control effectiveness

Example Risk Analysis: "Insulin Over-Delivery PFMEA"

  • Function: Calculate and deliver insulin bolus
  • Failure Mode: Software calculates excessive dose
  • Hazard: Hypoglycemia (low blood sugar)
  • Severity: 9 (Serious injury possible)
  • Occurrence: 3 (Low, with software validation)
  • Detection: 5 (User may not notice immediately)
  • RPN: 135 (High priority)
  • Action Priority: High (S ≥ 9)
  • Risk Controls:
    • Maximum single dose limit (IDS-RCM-003)
    • Maximum daily dose limit (IDS-RCM-004)
    • User confirmation required for large doses (IDS-RCM-005)
    • Extensive software testing (IDS-RCM-012)

Usability Engineering (IEC 62366)​

Use Error Analysis:

  • Common user interaction errors identified
  • Risk mitigations for use errors
  • Usability requirements derived from use errors

Example Usability Requirements:

  • Large, high-contrast display for elderly users
  • Audio + visual alarms for critical alerts
  • Simple 3-button interface
  • Step-by-step bolus wizard
  • Lockout to prevent accidental dose delivery

Software Safety Classification​

IEC 62304 Class C (highest level):

  • Device can cause death or serious injury if software fails
  • Applies to insulin dose calculation, delivery control
  • Requires rigorous software development lifecycle

Class-Specific Requirements:

  • Detailed software design documentation
  • Unit testing for all software units
  • Software integration testing
  • Software system testing
  • Regression testing for all changes
  • Static analysis of source code
  • Traceability to risk analysis

Regulatory Traceability​

FDA 510(k) Requirements:

  • Substantial equivalence to predicate device
  • Design controls per 21 CFR 820.30
  • Risk analysis per ISO 14971
  • Clinical evaluation or literature review

Design History File (DHF):

  • User needs and design inputs
  • Design outputs (requirements, specifications)
  • Design verification (test results)
  • Design validation (clinical validation)
  • Risk management file
  • Change history

How to Use This Project​

1. Explore Requirements-Risk Integration​

  1. Open the project:

    • Select "Medical Insulin Delivery System" from project list

  2. Navigate requirement types:

    • User Needs (IDS-UN-xxx): What patients/clinicians need
    • System Requirements (IDS-SYS-xxx): Device capabilities
    • Software Requirements (IDS-SWR-xxx): Software functions
    • Risk Controls (IDS-RCM-xxx): Safety mitigations

  3. Follow a requirement chain:

    • Start with UN-001: "Deliver insulin accurately"
    • Trace down to SYS-003: "Basal delivery accuracy ±5%"
    • Continue to SWR-015: "Basal rate calculation algorithm"
    • See linked RCM-007: "Validate basal rate inputs"

  4. See risk linkage:

    • Open any Software Requirement
    • Click "Links" tab in right panel
    • See connections to FMEA failure modes
    • Understand which risks it controls

2. Review Process FMEA​

  1. Open FMEA module:

    • Click "FMEA" tab → "Advanced FMEA"
    • Focus on PFMEA (Process FMEA for manufacturing/use)

  2. Examine drug delivery failures:

    • Find "Insulin Bolus Delivery PFMEA"
    • Review failure modes:
      • Over-delivery (hypoglycemia risk)
      • Under-delivery (hyperglycemia risk)
      • No delivery (missed dose)
      • Delayed delivery (timing error)

  3. Check risk controls:

    • For each high-severity failure mode
    • See linked Risk Control Measures
    • Verify controls reduce risk to acceptable level

  4. Use Risk Heatmap:

    • Visualize high-risk areas
    • Prioritize design improvements
    • Focus testing on critical failure modes

3. Verify Requirements Coverage​

  1. Check test coverage:

    • Analytics → Coverage Analysis
    • See percentage of requirements with tests
    • IEC 62304 Class C needs 100% coverage

  2. Review test cases:

    • Select a critical requirement (e.g., dose calculation)
    • See linked test cases in right panel
    • Verify normal, boundary, and error cases tested

  3. Validate risk control effectiveness:

    • For each Risk Control Measure
    • Ensure linked to verification test
    • Demonstrates control is effective

4. Generate Regulatory Submissions​

  1. Requirements Traceability Matrix (RTM):

    • Analytics → Traceability Matrix
    • Export to Excel
    • Submit as part of 510(k) package

  2. Risk Management Report:

    • Compile FMEA analyses
    • Show risk control measures
    • Demonstrate residual risk acceptability
    • Meets ISO 14971 requirements

  3. Design Verification Report:

    • Export test coverage data
    • Link all tests to requirements
    • Evidence of complete verification

  4. Design History File (DHF):

    • Organized by requirement type
    • Includes all supporting documentation
    • Ready for FDA inspection

Key Learning Points​

IEC 62304 Software Lifecycle​

  • Class C rigor: Most stringent level of documentation
  • Risk-based approach: High-risk software gets more scrutiny
  • Traceability mandatory: Requirements → Design → Code → Tests
  • Change control: Every modification must be documented

ISO 14971 Risk Management​

  • Hazard identification: FMEA required for critical functions
  • Risk estimation: Severity + Probability = Risk level
  • Risk control: Mitigations captured as requirements
  • Residual risk: Must be acceptable and documented

FDA Regulatory Strategy​

  • 510(k) pathway: Demonstrate substantial equivalence
  • Design controls: Complete V-model from needs to validation
  • Essential performance: Define and verify critical parameters
  • Usability testing: Required for most combination products

Medical Device Best Practices​

  • Patient safety first: Design with failure modes in mind
  • Redundant safety: Multiple layers of protection
  • User-centered design: Minimize use errors
  • Clinical validation: Verify device works in real-world conditions

Common Medical Device Hazards​

This project demonstrates how to analyze and mitigate typical insulin pump risks:

HazardExample ScenarioSeverityRisk Control
HypoglycemiaSoftware over-delivers insulinSerious Injury (9)Max dose limits, user confirmation
HyperglycemiaSoftware under-delivers insulinModerate (6)Alarms for missed doses, CGM alerts
OcclusionTubing blocked, no insulin deliveredSerious Injury (8)Pressure sensor, occlusion alarm
Battery FailurePump stops mid-deliveryModerate (5)Low battery warning, user replaceable
Use ErrorUser enters wrong doseSerious Injury (9)Confirmation screen, max dose check
Sensor ErrorCGM reports wrong glucoseSerious Injury (8)Sensor calibration, range checks

Tips for Adapting to Your Medical Device​

  1. Safety Classification: Determine IEC 62304 Class (A/B/C) based on risk
  2. Risk Analysis First: Start with hazard analysis before requirements
  3. Risk Controls as Requirements: Capture mitigations explicitly
  4. Usability Requirements: Don't overlook human factors
  5. Regulatory Pathway: Align documentation to submission type (510(k), PMA, CE Mark)

Regulatory Submission Checklist​

Use this project to see what's needed for regulatory submission:

  • User Needs documented (IDS-UN-xxx)
  • System Requirements complete (IDS-SYS-xxx)
  • Software Requirements detailed (IDS-SWR-xxx)
  • Risk Analysis performed (FMEA)
  • Risk Controls defined (IDS-RCM-xxx)
  • Traceability Matrix generated
  • Verification Tests linked to requirements
  • Validation Tests linked to User Needs
  • Risk Control effectiveness verified
  • Residual risk assessed
  • Design History File compiled
  • Software documentation per IEC 62304
  • Usability evaluation per IEC 62366

Clinical Context​

This sample project shows software requirements for an automated insulin delivery system similar to:

  • Medtronic MiniMed 670G (hybrid closed-loop)
  • Tandem t:slim X2 with Control-IQ
  • Insulet Omnipod 5

These devices use algorithms to:

  1. Monitor glucose via CGM
  2. Calculate insulin needs
  3. Automatically adjust basal delivery
  4. Provide bolus recommendations
  5. Prevent hypoglycemia and hyperglycemia

The project demonstrates how to manage requirements for such a complex, life-sustaining system.

Next Steps​

  1. Explore risk-requirements linkage to see how FMEA drives design
  2. Review test coverage for Class C software rigor
  3. Clone for your device and adapt to your hazard analysis
  4. Map to your standard (IEC 62304, ISO 13485, FDA guidance)
  5. Generate submission docs using automated traceability

This sample project shows the end-to-end lifecycle for a high-risk medical device. Use it as a reference for your own FDA or EU MDR submissions.