What You need to know about IEC 62304: Medical Software Lifecycle

 
IEC 62304 is the standard by the International Electrotechnical Commission (IEC) that governs the lifecycle processes for medical device software.

This standard provides a framework to ensure that software used in medical devices is developed and maintained in a way that is safe, reliable, and aligned with regulatory expectations. IEC 62304 applies to software that is a medical device in its own right, as well as to software embedded in or driving a physical medical device. 

This includes everything from pacemaker firmware to mobile health (mHealth) apps. It’s a harmonized standard recognized by regulators like the U.S. FDA and European Commission under the Medical Device Regulation (MDR).

IEC 62304 Explained

IEC 62304 defines the software lifecycle framework for medical device software.

IEC 62304:2006 (with Amendment 1 from 2015) sets out a structured approach to the safe design, development, maintenance, and decommissioning of software in medical devices. Developed by the International Electrotechnical Commission (IEC), this standard is harmonized under both the EU Medical Device Regulation (MDR) and recognized by the U.S. FDA, making it a foundational requirement for global market access.

The standard doesn’t dictate your methods, but it requires clear documentation, risk management, and traceability at every lifecycle stage. It’s meant to ensure that patient safety is not compromised by poor software design, inadequate testing, or untracked changes.

IEC 62304 applies to:

• Standalone software that qualifies as a medical device (e.g., a mobile ECG app)
• Embedded software controlling a hardware device (e.g., insulin pumps)
• Software used in diagnostics, therapy, or monitoring functions

The core of the standard is built around five key process groups:

• Software development
• Software maintenance
• Risk management
• Configuration management
• Problem resolution

Each of these areas includes mandatory activities and artifacts, particularly as software risk increases. In this way, IEC 62304 enforces a proactive, documented, and traceable process that ensures medical software does not put patients or users at risk.

Software Safety Classification 

IEC 62304 categorizes medical software by risk into three classes.

To tailor development rigor to risk, IEC 62304 requires software to be classified into one of three safety classes, A, B, or C, based on the potential harm it could cause if it fails. 

Each class drives the level of documentation, verification, and testing required throughout the lifecycle:

To determine the classification:

• Identify hazards where software failure could lead to harm.
• Assess the severity and probability of that harm.
• Assign the class based on the worst-case failure mode.

Note that this classification must be documented, justified, and approved, usually in alignment with ISO 14971, the risk management standard for medical devices. If a software component can cause serious harm, the whole system may be considered Class C unless robust containment strategies are proven.

Misclassifying software, especially underestimating its risk, can lead to audit failures, product recalls, or patient safety events. Getting this step right is foundational to IEC 62304 compliance.

1. Software Development Process (Clause 5)

IEC 62304 requires a planned and documented software development lifecycle.

Clause 5 outlines the heart of IEC 62304: the structured software development process. It ensures that every function in medical device software is implemented with clear requirements, traceability, verification, and validation. The rigor of these activities scales with the safety classification (A, B, or C).

Key steps required in the development process:

• Software Development Planning
  Define activities, roles, and responsibilities. Plans must account for risk class and document how compliance will be demonstrated.
• Software Requirements Analysis
  Identify and document functional and performance requirements. These should be traceable to system-level specifications.
• Software Architectural Design
  Decompose the system into software units and document their interactions. High-risk systems (Class B/C) must isolate safety-critical elements.
• Software Detailed Design
  Define logic, data flow, and interfaces for each software unit. This becomes the blueprint for developers.
• Software Unit Implementation and Verification
  Develop code based on the detailed design. Verify each unit through testing, inspection, or static analysis, based on classification.
• Software Integration and Integration Testing
  Combine units and test interfaces between them. Confirm the assembled system behaves as expected.
• Software System Testing
  Test the fully integrated software against the original requirements. Document and resolve any failures.
• Software Release
  Ensure all verification steps are complete and documented. Class B and C systems require a final safety checklist and release authorization.

2. Software Maintenance Process (Clause 6) 

IEC 62304 mandates a maintenance plan for released software.

Once medical device software is released, the development team must be prepared to support it throughout its operational life. Clause 6 ensures that updates, bug fixes, and post-market changes are handled with the same rigor as the initial development, especially when patient safety is involved.

Key requirements in the maintenance process include:

• Establishing a Maintenance Plan
  The plan must define how software problems will be received, evaluated, tracked, and resolved. It should also specify roles, responsibilities, and update procedures.
• Problem and Change Evaluation
  Every issue, whether a bug report, user complaint, or performance anomaly, must be assessed for potential safety impacts. Even minor issues in low-risk systems can have regulatory implications if mishandled.
• Risk Management During Maintenance
  All changes must be evaluated through the lens of IEC 62304 and ISO 14971. For example, introducing a new feature could unintentionally increase risk exposure if not properly tested.
• Verification of Modifications
  Any changes to Class B or C systems must be verified and documented through testing. For Class C, regression testing is also required to ensure no safety-critical functions are disrupted.
• Configuration Control for Updates
  All updates must be version-controlled, with clear traceability from the issue or change request to the release package. This is especially critical for audit readiness and incident investigation.
• Communication and Release
  If a change affects user documentation or safety information, those updates must be distributed accordingly. For Class C systems, formal release approvals are often required.

In practice, IEC 62304 expects that software support doesn’t end at launch. Post-market updates, cybersecurity patches, and performance improvements must follow a formal, risk-informed process that aligns with the original development strategy.

3. Risk Management Process (Clause 7) 

IEC 62304 integrates risk management per ISO 14971.

Clause 7 ensures that software-related risks are systematically identified, assessed, controlled, and verified throughout the lifecycle. Rather than treating risk as a one-time task, IEC 62304 embeds it into all phases of development and maintenance.

The standard doesn’t replace ISO 14971, it aligns with it. IEC 62304 focuses on the software-specific elements, ensuring traceability between software behavior and potential patient harm.

Key risk management activities include:

• Link to ISO 14971 Risk Framework
  Start by identifying hazards and hazardous situations where software could contribute to harm. This can include functional failures, incorrect outputs, or even user interface issues.
• Determine Software Contributions to Hazards
  Analyze how the software could cause or fail to prevent a hazardous event. Examples include:
  • Missed alarm signals
  • Incorrect dosage calculations
  • Inaccurate sensor readings
• Assign Safety Class
  Based on the identified hazards, determine whether the software should be classified as A, B, or C. The class dictates the level of rigor for all lifecycle activities.
• Implement Risk Control Measures
  These may include:
  • Redundancy or cross-checks
  • Fail-safes and alarms
  • Error handling and logging
• Verify Risk Control Effectiveness
  Controls must be tested and documented. For Class C systems, the bar is high, evidence must show the risk has been mitigated to acceptable levels.
• Document and Maintain Risk Traceability
  Every requirement, design decision, and test must be traceable back to a specific risk. This creates an audit trail that can be used to justify design choices during regulatory reviews.
• Continually Update the Risk File
  As the software evolves, whether due to updates, bug fixes, or customer feedback, the risk file must be updated accordingly. Risk management is a living process.

IEC 62304 doesn’t allow teams to “fire and forget.” Risk analysis must be woven into every change, enhancement, and release, ensuring that safety remains a constant priority.

4. Configuration Management (Clause 8) 

IEC 62304 requires traceable control over software and artifacts. 

Clause 8 outlines the expectations for configuration management, a discipline that ensures the integrity, consistency, and traceability of software throughout its lifecycle. This is critical in regulated environments where untracked changes or unclear versioning can compromise safety and non-compliance can lead to audit failures.

Key configuration management requirements include:

• Identify Configuration Items
  All software-related artifacts must be tracked, including:
  • Source code
  • Requirements and specifications
  • Test cases and results
  • Risk and hazard documentation
  • SOUP (Software of Unknown Provenance) components
• Establish a Baseline
  At various stages, such as design freeze or release, you must capture a “snapshot” of the current state of all configuration items. These baselines serve as reference points during audits, maintenance, or problem resolution.
• Change Control Procedures
  Every modification, whether to code, documentation, or test scripts, must follow a documented process that includes:
  • Change requests and justifications
  • Risk assessments
  • Approval records
  • Verification and validation activities
• Version and Status Tracking
  For every item under configuration control, you must be able to answer:
  • What is the current version?
  • What changes have been made, and why?
  • Who approved the change?
  • What impact does it have on safety?
• Configuration Audits
  Periodic audits must be conducted to verify that all software versions and artifacts are correctly identified, approved, and consistent with the project’s documentation and risk management file.
• Software of Unknown Provenance (SOUP) Documentation
  Special attention is required for third-party or open-source software (SOUP). The version, source, verification status, and rationale for use must be documented, especially in Class B and C systems.

Without strong configuration management, it becomes impossible to prove that released software was tested properly, aligns with risk controls, or complies with regulatory expectations. Clause 8 ensures that every change is traceable, reviewable, and accountable.

5. Problem Resolution Process (Clause 9) 

IEC 62304 requires formal problem reporting and resolution. 

Clause 9 ensures that every identified software problem, whether discovered during development, testing, or post-market use, is handled through a structured, auditable process. This applies not just to bugs, but also to anomalies, performance issues, or complaints that could impact safety or effectiveness.

Here’s how the problem resolution process works under IEC 62304:

• Problem Identification
  Problems may arise from internal testing, user feedback, customer complaints, or post-market surveillance. Each issue must be logged in a centralized system. 
• Problem Evaluation
  Each problem must be evaluated for its potential to cause harm. If the issue is linked to a safety-related function, it must be escalated, risk-assessed, and tracked accordingly.
• Document Investigation Results
  The team must analyze the root cause of the issue, whether it’s a code bug, requirements gap, misconfiguration, or integration error. The analysis must be documented, particularly for Class B and C systems.
• Define and Implement Corrective Actions
  The fix may involve code changes, documentation updates, process changes, or design corrections. These must be controlled via the configuration management process and verified through testing.
• Verification and Regression Testing
  Ensure the problem is fully resolved and that no new risks or regressions have been introduced. For Class C, comprehensive regression testing is required.
• Tracking and Trend Analysis
  Maintain a problem resolution log to identify recurring patterns or systemic issues. These insights should feed into risk management and process improvement activities.
• Communicate Resolutions
  If the issue has user-facing implications, such as updated user manuals, warnings, or software updates, ensure that customers and regulators are notified appropriately.

Problem resolution is a safety-critical process that must be consistent, well-documented, and integrated with your risk and change control workflows. Clause 9 reinforces the principle that software safety is not a one-time achievement, it’s a continuous responsibility.

Takeaway

IEC 62304 provides a robust framework for developing safe, compliant medical software.
For organizations developing software for diagnosis, monitoring, or treatment, IEC 62304 serves not just as a regulatory requirement but as a blueprint for delivering safer, higher-quality products.

Following its lifecycle processes allows you to systematically manage risk, ensure traceability, and develop software that meets global standards for safety and performance. With medical software becoming more embedded in patient care and diagnostics, IEC 62304 is foundational. 

But with the right processes, people, and tools, compliance can evolve from a burden into a strategic enabler of safety, market access, and innovation.

Get a Free SD Elements Demo     Take the Product Tour