IEC 62304
Medical device software — Software life cycle processes
Overview
Scope
IEC 62304 specifies life cycle requirements for the development of medical device software and software within medical devices. The standard applies to the development and maintenance of medical device software. It covers software that is itself a medical device (SaMD) and software that is embedded in or used as part of a medical device. The standard defines software safety classes (A, B, C) based on the potential for software to contribute to a hazardous situation.
Why It Matters
IEC 62304 is the international standard for medical device software development and is required by FDA, EU MDR, Health Canada, and other regulatory bodies. With the increasing use of software in medical devices, proper software lifecycle management is critical for patient safety and regulatory compliance. The standard helps manufacturers develop reliable, safe software through systematic processes, risk management, and validation. Software failures can lead to patient harm, product recalls, and regulatory action.
Key Concepts
- Software safety classification (Class A, B, C)
- Software development lifecycle processes
- Software development plan (SDP)
- Software requirements specification (SRS)
- Software architecture and detailed design
- Software unit implementation and testing
- Software integration and integration testing
- Software system testing
- SOUP (Software of Unknown Provenance) management
- Software risk management (integrated with ISO 14971)
- Software maintenance and configuration management
Software is increasingly the differentiator in medical devices. Well-documented software development accelerates your entire regulatory pathway.
IEC 62304 defines how you develop and maintain medical device software. The key decision that drives everything: software safety classification (A, B, or C). Get this wrong, and you're either over-engineering Class A software or under-documenting Class C. For laser control software? Almost always Class C. The software directly controls energy delivery to patients.
🔑 Key Takeaways
- →Classify based on risk analysis, not device class. Software in a Class I device can still be Class C.
- →SOUP (third-party libraries) management catches many teams off guard. Document everything you use.
- →Requirements traceability is non-negotiable—use tools like DOORS, Jira, or Polarion.
- →Unit test coverage targets: 80% for Class B, 100% for Class C safety-critical paths.
— ER | medev.ai
Building better devices, together.
Key Requirements Overview
Software Safety Classification (Clause 4)
Software must be classified as Class A (no injury possible), Class B (non-serious injury possible), or Class C (death or serious injury possible). Classification determines the rigor of development processes required. Classification is based on the potential for software to contribute to a hazardous situation, considering both the severity of harm and the probability of occurrence.
Software Development Process (Clause 5)
Manufacturers must establish a software development plan (SDP) that defines the software lifecycle model, activities, tasks, and deliverables. The SDP must be appropriate for the software safety class. For Class B and C software, more rigorous processes are required including formal design reviews, verification, and validation.
Software Requirements Analysis (Clause 5.2)
Software requirements must be specified, documented, and reviewed. Requirements must be traceable to system requirements and risk control measures. For Class B and C software, requirements must be verified for completeness, correctness, consistency, testability, and feasibility.
Software Architectural Design (Clause 5.3)
Software architecture must be designed and documented. For Class B and C software, architectural design must be verified and reviewed. The architecture must support software safety requirements and facilitate verification and validation.
Software Detailed Design (Clause 5.4)
Detailed design must specify software units, their interfaces, and algorithms. For Class B and C software, detailed design must be verified and reviewed. Design must be traceable to software requirements.
Software Unit Implementation and Testing (Clause 5.5)
Software units must be implemented according to the detailed design. Each unit must be tested to verify it meets its requirements. For Class B and C software, unit testing must be documented and reviewed. Code must follow coding standards and be reviewed.
Software Integration and Testing (Clause 5.6)
Software units must be integrated incrementally and tested. Integration testing must verify interfaces and interactions between units. For Class B and C software, integration testing must be documented and reviewed.
Software System Testing (Clause 5.7)
Complete software system must be tested to verify it meets software requirements. System testing must include functional testing, performance testing, and safety testing. Test results must be documented and reviewed.
SOUP Management (Clause 5.8)
Software of Unknown Provenance (SOUP) includes commercial off-the-shelf (COTS) software, open-source software, and legacy software. SOUP must be evaluated for suitability, documented, and managed. Risk analysis must be performed for SOUP used in Class B and C software.
Software Development Implementation Guide
Determine Software Safety Class
Classify software based on potential to contribute to hazardous situations. Consider the device's intended use, user population, and risk analysis (ISO 14971). Class A: No injury possible (e.g., data logging). Class B: Non-serious injury possible (e.g., incorrect display). Class C: Death or serious injury possible (e.g., incorrect drug dosing, laser power control). Document classification rationale.
Create Software Development Plan (SDP)
Document the software lifecycle model (waterfall, V-model, agile with medical device adaptations), development activities, tasks, deliverables, and responsibilities. Define coding standards, design standards, and review processes. Link SDP to design and development plan (ISO 13485) and risk management plan (ISO 14971).
Develop Software Requirements Specification (SRS)
Document functional requirements, performance requirements, interface requirements, and safety requirements. Ensure requirements are traceable to system requirements and risk control measures. For Class B and C, verify requirements for completeness, correctness, consistency, testability, and feasibility. Use requirements management tools for traceability.
Design Software Architecture
Create architectural design showing software components, their interactions, and interfaces. For Class B and C, verify architecture supports safety requirements and facilitates verification. Conduct architectural design review. Document design decisions and rationale.
Create Detailed Design
Specify software units (modules, functions, classes), their interfaces, algorithms, and data structures. For Class B and C, verify detailed design is traceable to requirements and architecture. Conduct design review. Use design patterns and coding standards.
Implement and Test Software Units
Code software units according to detailed design. Follow coding standards (MISRA C, CERT C, etc.). Perform unit testing for each unit. For Class B and C, document unit tests and conduct code review. Use static code analysis tools. Achieve code coverage targets (typically 80-100% for Class C).
Integrate and Test Software
Integrate software units incrementally. Perform integration testing to verify interfaces and interactions. For Class B and C, document integration tests and review results. Use integration test frameworks. Verify integration meets architectural design.
Perform Software System Testing
Test complete software system against SRS. Include functional testing, performance testing, boundary testing, and safety testing. For Class B and C, document all test cases and results. Conduct test review. Verify software meets all requirements including safety requirements.
Manage SOUP
Identify all SOUP components (operating systems, libraries, frameworks). Evaluate SOUP for suitability, security vulnerabilities, and maintenance support. Document SOUP inventory and versions. For Class B and C, perform risk analysis for SOUP. Monitor SOUP for security updates and patches.
Release Software
Complete software release documentation including release notes, known limitations, and installation instructions. Verify all development activities are complete. Conduct final review. Release software according to configuration management procedures.
Common Challenges & Solutions
Incorrect software classification
Base classification on risk analysis (ISO 14971), not just device class. Consider all potential hazardous situations software could contribute to. When in doubt, classify higher (more rigorous). Document classification rationale clearly.
Inadequate requirements traceability
Use requirements management tools (DOORS, Jira, Polarion) to maintain traceability from user needs through system requirements to software requirements to design to code to tests. Review traceability regularly.
SOUP security vulnerabilities
Regularly scan SOUP for known vulnerabilities (OWASP, CVE database). Establish SOUP update procedures. Document security risk analysis. Consider alternatives if SOUP has critical vulnerabilities.
Insufficient testing coverage
Define code coverage targets (80% for Class B, 100% for Class C). Use code coverage tools. Test boundary conditions, error handling, and safety-critical paths. Document test coverage and justify any gaps.
Poor integration with risk management
Link software requirements to risk control measures. Include software-related hazards in risk analysis. Verify software risk controls through testing. Update risk management file when software changes.
Medical Laser System Example
Laser control software is typically Class C (safety-critical) because software failures can lead to uncontrolled laser emission, incorrect power delivery, or safety interlock bypass, resulting in serious eye injury or burns. The software controls laser power, safety interlocks, beam delivery, user interface, and data logging. Rigorous development processes, comprehensive testing, and SOUP management are essential.
Laser Power Control Software (Class C)
- Safety-critical: Software controls laser power output. Failure can cause overexposure or underexposure.
- Requirements: Power accuracy (±5%), power monitoring, automatic shutoff on error, calibration procedures.
- Architecture: Separate safety-critical power control module with watchdog timer, redundant power monitoring.
- Testing: 100% code coverage, boundary testing (min/max power), fault injection testing, safety testing.
- SOUP: Real-time operating system (RTOS) must be evaluated for determinism and safety certification.
- Risk management: Software failures linked to optical radiation hazard (Severity 9-10) in ISO 14971 risk analysis.
Safety Interlock Software (Class C)
- Safety-critical: Software monitors safety interlocks and prevents laser operation if interlocks fail.
- Requirements: Continuous monitoring of interlock states, fail-safe behavior, redundant monitoring paths.
- Architecture: Independent interlock monitoring module with hardware watchdog, separate from power control.
- Testing: Fault injection (simulate interlock failures), timing analysis, worst-case execution time (WCET) analysis.
- Verification: Formal verification may be required for Class C interlock software.
- Documentation: Software safety case demonstrating interlock software reliability and fail-safe behavior.
User Interface Software (Class B)
- Moderate risk: UI errors can lead to use errors (wrong settings) but software itself doesn't directly cause harm.
- Requirements: Clear display of power settings, confirmation prompts for high-power operations, error messages.
- Testing: Usability testing, display accuracy verification, error message clarity.
- Integration: UI software must correctly communicate with power control software (Class C).
- SOUP: UI framework (Qt, .NET) must be evaluated for stability and security.
Related Standards
ISO 14971
Application of risk management to medical devices
Software risk management must follow ISO 14971. Software classification based on risk analysis.
ISO 13485
Quality management systems
Software development must be part of design controls (ISO 13485 Clause 7.3)
IEC 60601-1
Medical electrical equipment — General requirements
Software in medical electrical equipment must comply with IEC 62304
IEC 62366
Application of usability engineering
Usability engineering applies to software user interfaces
Resources
Official Resources
Implementation Tools
Copyright Notice: IEC 62304 is copyrighted by IEC. This page provides implementation guidance and educational content only. The standard itself must be purchased from the official IEC website.