4.0: Medical Device Software
Case Study: Infusion Pump Control Software
Project Overview
Project: Software for IV (Intravenous) Infusion Pump Customer: MedTech Solutions Inc. (Medical Device Manufacturer) Regulatory Standards:
- IEC 62304:2006+A1:2015 (Medical device software lifecycle)
- ISO 14971:2019 (Medical device risk management)
- FDA 21 CFR Part 820 (Quality System Regulation)
- EU MDR 2017/745 (Medical Device Regulation)
Target Markets: USA (FDA 510(k) clearance), EU (CE Mark) Software Safety Class: Class C (can cause death or serious injury if fails) Duration: 18 months (design, development, FDA submission, clearance) Budget: €1.2M Team Size: 10 FTE
Device Description
Infusion Pump System
Purpose: Controlled delivery of intravenous medications/fluids to patients
Key Functions:
- Drug Delivery: Precise flow rate control (0.1 - 999 mL/hr)
- Safety Monitoring: Detect air bubbles, occlusions, empty bags
- Alarm Management: Audible/visual alarms for critical events
- Drug Library: Pre-configured dose limits (hard/soft limits)
Hardware Platform:
- Processor: ARM Cortex-M7 (216 MHz, real-time OS)
- Display: 5" color touchscreen (resistive)
- Pump Mechanism: Peristaltic pump with stepper motor
- Sensors: Pressure sensor, air-in-line detector, drop sensor
- Connectivity: WiFi (802.11ac) for EMR integration (optional)
Software: 45,000 SLOC (C99 + FreeRTOS)
SOUP Count: This project uses 3 SOUP items: FreeRTOS (RTOS kernel), ARM CMSIS (hardware abstraction), and mbedTLS (WiFi encryption). Each requires qualification per IEC 62304 Clause 8.1.2. See Section 27.01 for SOUP qualification example.
Regulatory Context
IEC 62304 Software Safety Classes
Classification Criteria (IEC 62304, Clause 4.3):
Based on hazard severity if software fails:
| Class | Severity | Probability of Harm | Example |
|---|---|---|---|
| Class A | No injury or minor injury | Low | Data logging error (no patient impact) |
| Class B | Non-serious injury | Medium | Alarm delay (nurse can intervene) |
| Class C | Death or serious injury | High | Drug overdose (incorrect flow rate) |
Infusion Pump Classification: Class C
Rationale:
- Software controls drug delivery rate
- Failure scenario: Over-infusion of potent drug (e.g., insulin, chemotherapy)
- Consequence: Severe hypoglycemia (insulin), cardiac arrest (potassium)
- Historical precedent: 2010 Baxter infusion pump recall (software defect, 13 deaths)
Result: IEC 62304 Class C → Most rigorous development requirements.
Class Reclassification: IEC 62304 allows reclassification to a lower class if hardware risk control measures effectively mitigate software failures. Example: Battery monitoring (initially Class B) reclassified to Class A because backup battery provides hardware mitigation. Document reclassification rationale in the Risk Management File.
FDA Regulatory Pathway
Submission Type: 510(k) Premarket Notification
510(k) Process:
- Identify predicate device (legally marketed equivalent device)
- Demonstrate substantial equivalence (same intended use, technological characteristics)
- Submit 510(k) application to FDA (includes software documentation)
- FDA review: 90 days (average, can extend to 180 days with deficiency letters)
- FDA clearance letter → Device can be marketed in USA
Predicate Device: Baxter Colleague CX Infusion Pump (FDA K103456)
Substantial Equivalence Justification:
- [PASS] Same intended use: IV drug/fluid delivery
- [PASS] Same fundamental technology: Peristaltic pump, pressure sensors
- [PASS] Similar performance: 0.1-999 mL/hr flow rate
- [WARN] New feature: WiFi EMR integration (requires additional testing)
EU MDR Compliance
EU Market: CE Mark required under Medical Device Regulation (MDR) 2017/745
Classification (MDR Annex VIII, Rule 11):
- Software for controlling drug delivery → Class IIb (high risk)
- Notified Body assessment required (TÜV SÜD, BSI, etc.)
Conformity Assessment:
- Design Dossier (IEC 62304 documentation)
- Risk Management File (ISO 14971)
- Clinical Evaluation Report (literature review, post-market data)
- Notified Body audit → CE Mark issued
Technology Stack
Software Architecture
Operating System: FreeRTOS 10.4.3 (real-time, open-source)
Programming Language: C99 (MISRA C:2012 compliant)
Compiler: ARM GCC 10.3 (qualified for IEC 62304 Class C)
Development Tools:
IDE: STM32CubeIDE (Eclipse-based, ARM Cortex-M7 support)
Debugger: ST-Link/V3 (JTAG)
Static Analyzer: PC-lint Plus (MISRA C checker)
Unit Testing: Unity Test Framework + CMock (mocking)
Requirements Management: Jama Connect (FDA-compliant traceability)
Version Control: Git + GitLab (21 CFR Part 11 compliant audit trails)
CI/CD: GitLab CI (automated builds, tests, MISRA checks)
Software Modules:
Infusion Pump Software (45,000 SLOC)
├── Application Layer (25,000 SLOC)
│ ├── Drug Delivery Control (PID controller for flow rate)
│ ├── Drug Library (1,200 drug profiles, hard/soft limits)
│ ├── Alarm Manager (30 alarm types, priority-based)
│ ├── User Interface (touchscreen, navigation)
│ └── Network Interface (WiFi, HL7 FHIR for EMR)
├── Safety Monitoring Layer (10,000 SLOC) [Class C]
│ ├── Air-in-Line Detection
│ ├── Occlusion Detection (pressure sensor)
│ ├── Flow Rate Verification (independent watchdog)
│ └── Battery Monitoring (prevent mid-infusion power loss)
├── Hardware Abstraction Layer (8,000 SLOC)
│ ├── Motor Driver (stepper motor for peristaltic pump)
│ ├── Sensor Drivers (pressure, air detector, drop sensor)
│ ├── Display Driver (touchscreen, graphics)
│ └── Communication (UART, SPI, I2C, WiFi)
└── FreeRTOS Kernel (2,000 SLOC, pre-qualified)
ASPICE Integration for Medical Devices
ASPICE ↔ IEC 62304 Mapping
Overlap: ~60-65% (medical devices less process-mature than automotive)
| IEC 62304 Requirement | ASPICE Equivalent | Gap |
|---|---|---|
| 5.1 Software Development Planning | MAN.3 Project Management | [PASS] Direct mapping |
| 5.2 Software Requirements Analysis | SWE.1 Software Requirements | [PASS] Direct mapping |
| 5.3 Software Architectural Design | SWE.2 Architecture Design | [PASS] Direct mapping |
| 5.4 Software Detailed Design | SWE.3 Detailed Design | [PASS] Direct mapping |
| 5.5 Software Unit Implementation/Verification | SWE.3 + SWE.4 | [PASS] Direct mapping |
| 5.6 Software Integration/Testing | SWE.5 Integration Test | [PASS] Direct mapping |
| 5.7 Software System Testing | SWE.6 Qualification Test | [PASS] Direct mapping |
| 6. Software Maintenance | - | [WARN] IEC 62304 specific (post-market surveillance) |
| 7. Software Risk Management | - | [WARN] IEC 62304 specific (ISO 14971 integration) |
| 8. Software Configuration Management | SUP.8 Configuration Mgmt | [PASS] Direct mapping |
| 9. Software Problem Resolution | SUP.9 Problem Resolution | [PASS] Direct mapping |
Additional IEC 62304 Requirements:
- SOUP Management (Software of Unknown Provenance, e.g., FreeRTOS)
- Software Risk Control Measures (integration with ISO 14971 risk analysis)
- Post-Market Surveillance (complaint handling, field failures)
Project Metrics
Timeline (18 Months)
| Phase | Duration | IEC 62304 Activities | FDA/EU Milestones |
|---|---|---|---|
| Planning | Month 1-2 | Software Development Plan, Risk Mgmt Plan | - |
| Requirements | Month 3-4 | SWE.1 (500 requirements in Jama) | Design Review (internal) |
| Design | Month 5-7 | SWE.2 Architecture, SWE.3 Detailed Design | Design History File (DHF) started |
| Implementation | Month 8-12 | SWE.3 Coding, SWE.4 Unit Tests | - |
| Integration | Month 13-14 | SWE.5 Integration Testing | V&V Testing (SWE.6) |
| Verification | Month 15-16 | SWE.6 System Testing, SOUP Validation | DHF Complete |
| FDA Submission | Month 17 | 510(k) application submitted | FDA review starts |
| FDA Clearance | Month 18 | - | 510(k) clearance received [PASS] |
Team Structure
| Role | FTE | Responsibility |
|---|---|---|
| Project Manager | 1.0 | IEC 62304 compliance, FDA liaison |
| Regulatory Affairs | 0.5 | 510(k) preparation, EU MDR compliance |
| Software Architect | 1.0 | SWE.2 Architecture, safety design patterns |
| Senior Embedded SW Engineer | 3.0 | C programming, FreeRTOS, device drivers |
| Junior SW Engineer | 1.5 | UI development, testing |
| Test Engineer | 1.0 | SWE.4-6 Testing, test automation |
| Quality/Compliance | 1.0 | ASPICE/IEC 62304 evidence, DHF maintenance |
| Risk Manager | 0.5 | ISO 14971 risk analysis, FMEA |
| Clinical/Biomedical Engineer | 0.5 | Clinical evaluation, usability testing (IEC 62366) |
Total: 10 FTE
Budget Breakdown
| Category | Cost | Notes |
|---|---|---|
| Engineering Labor | €720,000 | 10 FTE × 18 months × €4,000/FTE/month |
| Hardware (Prototypes) | €80,000 | 20x prototype units for V&V testing |
| Software Licenses | €35,000 | Jama Connect, PC-lint, STM32Cube |
| Testing (Lab Equipment) | €60,000 | Pressure calibrators, oscilloscopes, IV fluid simulators |
| FDA 510(k) Submission | €75,000 | FDA user fee ($12k) + regulatory consultant |
| Notified Body (CE Mark) | €90,000 | TÜV SÜD assessment for EU MDR |
| Clinical Evaluation | €50,000 | Literature review, clinical data analysis |
| Contingency | €90,000 | 8% buffer (FDA deficiency letters, retesting) |
Total: €1,200,000
Software Size and Complexity
Code Metrics
| Metric | Value | Notes |
|---|---|---|
| Total SLOC | 45,000 | C99 (42,000) + Python test scripts (3,000) |
| Class C Code | 10,000 SLOC | Safety monitoring, drug delivery control |
| Class B Code | 15,000 SLOC | Alarms, UI, logging |
| Class A Code | 20,000 SLOC | Network, non-critical features |
| SOUP (FreeRTOS) | 8,000 SLOC | Pre-qualified RTOS kernel |
| Requirements | 500 | Functional (300), Safety (50), Performance (50), Interface (100) |
| Test Cases | 1,200 | Unit (600), Integration (350), System (250) |
| MISRA Compliance | 98% | 12 justified deviations (documented) |
| Cyclomatic Complexity | Avg 4.2 | Max 15 (safety-critical functions kept simple) |
Key Challenges
1. SOUP Management (FreeRTOS)
Problem: IEC 62304 requires risk analysis for "Software of Unknown Provenance" (SOUP)
Definition: Off-the-shelf software (FreeRTOS) developed outside IEC 62304 lifecycle
Requirements (IEC 62304, Clause 8.1.2):
- Document SOUP item (name, version, manufacturer)
- Identify known anomalies (bugs, limitations)
- Evaluate SOUP for intended use (risk analysis)
- Define SOUP verification criteria
Solution: See Section 27.03 (SOUP qualification example)
2. FDA Software Documentation Expectations
Challenge: FDA expects comprehensive software documentation (per FDA Guidance on Software Validation)
Required Documents (Design History File):
- Software Requirements Specification (SRS)
- Software Design Specification (SDS)
- Traceability Matrix (Requirements → Design → Tests)
- Risk Analysis (software hazards)
- Verification & Validation Reports
- SOUP Qualification
- Software Bill of Materials (SBOM)
Volume: ~800 pages for 45,000 SLOC software
AI Contribution: Auto-generate 40% of documentation (see 27.02)
3. Cybersecurity (FDA Guidance 2023)
New Requirement: FDA Cybersecurity in Medical Devices (2023 guidance)
Mandates:
- Software Bill of Materials (SBOM)
- Vulnerability management plan
- Security risk assessment
- Secure development lifecycle
Impact: +15% project effort (150 hours for SBOM, threat modeling)
AI-Assisted Development Impact
Productivity Gains (Preliminary)
| Activity | Traditional Time | AI-Assisted Time | Improvement |
|---|---|---|---|
| Requirements Extraction | 120 hours | 70 hours | 42% faster |
| C Code Generation | 400 hours | 260 hours | 35% faster |
| Unit Test Generation | 250 hours | 90 hours | 64% faster |
| Documentation | 300 hours | 120 hours | 60% faster |
| Regulatory Writing | 200 hours | 130 hours | 35% faster |
Overall: 1,270 hours → 670 hours (47% reduction)
Caveat: AI-generated code for Class C safety functions requires extensive manual review (compliance burden).
Success Criteria
Project Outcome: [PASS] Successful (FDA 510(k) clearance, CE Mark obtained)
- [PASS] On Time: 18 months (as planned)
- [PASS] On Budget: €1,180,000 (€20k under budget)
- [PASS] FDA 510(k) Clearance: K254321 (granted Month 18)
- [PASS] CE Mark: Issued by TÜV SÜD (EU MDR compliant)
- [PASS] IEC 62304 Class C: Fully compliant
- [PASS] Defect Density: 1.2 defects/KLOC (acceptable for medical devices)
- [PASS] ASPICE: CL2 partial (62304 supersedes for medical devices)
Chapter Structure
This chapter explores medical device software development across 4 sections:
- Chapter 27.1: IEC 62304 Requirements: Software safety classes, lifecycle processes, SOUP management
- Chapter 27.2: Regulatory Documentation: FDA 510(k) submission, EU MDR, Design History File
- Chapter 27.3: Risk-Based Approach: ISO 14971 integration, FMEA, lessons learned
Message: Medical device software development is highly regulated (FDA, EU MDR). ASPICE provides a foundation, but IEC 62304 and ISO 14971 add significant regulatory overhead. AI tools help with documentation (60% faster), but safety-critical code (Class C) requires rigorous manual review.