Skip to content

Comprehensive Guide to IEC 62304:2015 Standard

Medical Device Software Lifecycle Processes

This standard is an international document that defines software lifecycle processes for medical device software. Its main goal is to ensure software safety and effectiveness through defined, systematic activities and tasks. The standard does not impose a specific development model (like Waterfall or Agile) but sets requirements based on the software safety class.

1. General Requirements and Standard Fundamentals

This section provides the basic foundation for compliance with the entire standard and explains processes required before development begins.

Quality Management System

  • Description: The manufacturer must demonstrate the ability to provide software that consistently meets customer and regulatory requirements.

  • Example: A company developing software for an insulin pump must have a quality management system compliant with ISO 13485. This system includes procedures for document control, change management, and staff training records.

Risk Management

  • Description: All software processes must follow a comprehensive risk management process compatible with ISO 14971. This helps the manufacturer identify, evaluate, and control potential hazards.

  • Example: The software development team for a cardiac monitoring device must identify potential hazards like incorrect heart rate display or sudden device shutdown and define measures to mitigate them, such as adding audio and visual alarms.

Software Safety Classification

  • Description: Each software system must be classified into one of three safety classes based on the potential risk to patients or users:

    • Class A (Lowest Risk): Software does not lead to a hazardous situation, or the risk is acceptable with external control measures (e.g., a safety hardware system).

    • Class B (Moderate Risk): Software can lead to a hazardous situation resulting in non-serious injury.

    • Class C (Highest Risk): Software can lead to a hazardous situation resulting in death or serious injury. This is the highest risk class and has the strictest requirements.

  • Default Rule: Until a safety class is assigned, Class C requirements are applied.

Legacy Software

  • Description: Provides guidance for compliance of software developed before the standard was applied.

  • Process: The manufacturer must perform a gap analysis to compare existing documentation and processes with the standard's requirements. Then, necessary activities are carried out to close gaps and properly document the software. The minimum deliverable is a record of system software testing.

  • Example: A company updating legacy imaging device software must perform a gap analysis to identify IEC 62304 requirements not followed during initial development, then address gaps through documentation and additional testing.

2. Software Development Process

This section is the core of the standard and describes all development stages in a logical sequence.

Software Development Planning

  • Description: A comprehensive development plan must be created and updated.

  • Importance: Planning should match the scope and safety class of the software. The plan must also specify standards, methods, and tools used, especially for Class C software.

  • Example: Developing an automated drug infusion pump (Class C) requires a detailed timeline, assignment of responsibilities, tools (like compilers and version control), and code review procedures.

Software Requirements Analysis

  • Description: System requirements are converted into precise, testable software requirements and documented.

  • Example: A system requirement for an insulin pump may state: "The device must deliver the correct insulin dose based on current blood sugar." The software requirement must translate this into: "The software must read the blood sugar sensor and calculate and display the insulin dose with 0.1-unit accuracy."

Software Architectural Design

  • Description: Requirements are translated into a documented architecture describing the software structure.

  • Risk Separation: Any separation between software items needed for risk control (e.g., running code on separate processors) must be identified and verified.

  • Example: The insulin pump architecture should define modules: dose calculation, sensor communication, user interface, and alarm management. For risk control, the dose calculation module may run separately from the UI module to prevent UI errors from affecting critical functions.

Software Detailed Design

  • Description: Each software item is broken into software units, and their detailed design for implementation is documented.

  • Example: The dose calculation module can be divided into smaller units like "Algorithm A dose calculation" and "Input validation function." Each unit’s design includes functionality and implementation details.

Software Unit Implementation & Verification

  • Description: Code is written for each software unit and verified against defined acceptance criteria.

  • Example: The "dose calculation function" is coded and then verified through unit tests and code review to ensure outputs match expectations for given inputs.

Software Integration & Integration Testing

  • Description: Software units are integrated and tested together.

  • Example: After unit verification, "dose calculation" and "sensor communication" modules are integrated and tested to ensure correct data transfer. Regression tests confirm integration does not disrupt other modules.

Software System Testing

  • Description: The entire software system is tested to confirm all software requirements are met.

  • Example: QA tests the insulin pump under various conditions (low battery, weak sensor connection) to ensure proper operation.

Software Release for Utilization

  • Description: Final software preparation and release.

  • Example: After all tests are complete and verified, the final software with documentation (test results, unresolved issues) is archived. A secure delivery process is used to install software on devices, preventing unauthorized changes.

3. Software Maintenance and Support Processes

These processes cover continuous activities throughout the software lifecycle.

Software Maintenance Process

  • Description: Handling post-release issues and changes.

  • Example: After releasing the insulin pump, a user reports the low battery alarm fails in a specific scenario. This feedback is logged, and the maintenance process begins to resolve it.

Software Risk Management Process

  • Description: Ongoing risk management throughout the software lifecycle.

  • Example: When reviewing the above issue, the development team evaluates the impact on device safety. If the defect can cause harm, a high-priority change request is raised and logged in the risk management file.

Software Configuration Management Process

  • Description: Organized control of software and documentation changes.

  • Example: Any code change (e.g., fixing the battery alarm) must be recorded in a configuration management system, including a new version number and traceability to the change request.

Software Problem Resolution Process

  • Description: Formal process for addressing identified problems.

  • Example: The low battery alarm issue is assigned to development. They investigate, modify the code, verify the solution, and close the problem report while maintaining records.

4. Software Risk Management Process

This section focuses on risk management throughout the software lifecycle, integrated with ISO 14971 for medical device risk management. The main goal is to identify and control hazards from software malfunction or failure.

4.1. Software Contribution to Hazardous Situations

  • Description: The manufacturer must identify software items that may lead to a hazardous situation and examine possible causes. This can result from direct software failure or inability to implement a control measure.

  • Example: In an X-ray device, a hazardous situation may be delivering excessive radiation. The cause could be a dose controller software bug or a module failure responsible for shutting off the X-ray. Both must be identified and documented.

4.2. Evaluating SOUP Anomalies

  • Description: When using SOUP (Software of Unknown Provenance), such as open-source libraries or commercial OS, all known anomalies or bugs must be evaluated to ensure they don’t cause hazardous situations.

  • Example: If an open-source graphics library is used to display images, the team must review reported bugs. If a bug could mislead a physician, it’s a hazardous situation and must be logged and controlled in the risk file.

4.3. Risk Control Measures

  • Description: Each software-related hazardous situation requires defined and documented control measures, which may be implemented in hardware, software, or user instructions.

  • Example: To prevent excessive radiation in an X-ray device, a hardware control could measure dose and cut power if the limit is exceeded. A software measure could verify input doses before execution.

4.4. Verification of Risk Control Measures

  • Description: Implementation of each control measure must be independently verified to prove effectiveness.

  • Example: For a software control, a dedicated test simulates invalid doses to verify the software rejects them correctly.

4.5. Managing Software Change Risks

  • Description: Any software change, even minor, must be analyzed for new risks or impact on existing control measures.

  • Example: Updating the insulin pump UI requires verification that the dose calculation module is unaffected and remains accurate.

5. Software Configuration Management Process

This process provides a framework to control changes to software and documentation, ensuring integrity and traceability.

5.1. Configuration Identification

  • Description: A plan must identify configuration items and their versions uniquely. These may include source code, design documents, and test results.

  • Example: For a blood pressure monitor, configuration items may include "Source code of BP measurement module (v1.2)" and "Software requirements document (v1.0)."

5.2. Change Control

  • Description: Changes to configuration items should only occur in response to approved change requests, preventing unauthorized modifications.

  • Example: To fix a bug, a change request is filed with details, approved, applied in code, and logged in version control (e.g., Git).

5.3. Configuration Status Accounting

  • Description: Maintain retrievable records of configuration item history, including changes and versions.

  • Example: A database keeps a record of all software changes: "On 2025/02/20, BP module updated from v1.2 to v1.3 to fix bug CR-0123."

6. Software Problem Resolution Process

This process provides a systematic approach for managing and resolving software problems (bugs and anomalies).

6.1. Prepare Problem Reports

  • Description: Every identified problem should have a report including severity, affected devices, and steps to reproduce the issue.

  • Example: A tester logs "BP High Alarm Not Displayed" with software version, device model, and reproduction steps.

6.2. Investigate the Problem

  • Description: The manufacturer investigates the problem, identifies the cause, and evaluates safety impact using risk management.

  • Example: Developers find the high BP alarm fails due to an unusual logical condition. They assess it as a medium safety risk and plan to fix it.

  • Description: Keep records of all problem reports and solutions, and analyze trends.

  • Example: If most issues come from a specific module, this indicates a design or coding problem needing deeper review.

6.4. Verify Software Problem Resolution

  • Description: Verify solutions to ensure problems are fully resolved, changes implemented, and no new issues are introduced.

  • Example: After code changes, QA re-tests the high BP alarm and performs regression tests to ensure no other functions are affected.

6.5. Test Documentation Contents

  • Description: After changes, document test results, anomalies, software version, and test configurations.

  • Example: A test report might state: "Test to fix BP high alarm completed," "Software version: 1.3.1," "Result: Successful," "Performed by: [Tester Name] on [Date]."

![[IEC62304_Software_62304.png]]