Illustrated guide to IEC 62304 & medical device software development

In this guide, we will explain the role of IEC 62304 in safe and compliant medical device software development. IEC 62304 is not merely a documentation standard. It is a risk-based framework for managing the entire software life cycle of medical devices. Notably, medical device software is defined by its intended medical purpose and not the platform it operates on. The standard emphasizes risk management throughout the software life cycle to protect patient safety. Software development activities must be planned, documented, verified, and traced to demonstrate compliance. Moreover, the standard works closely with ISO 14971, thereby making risk management central to software safety. Notably, higher safety classifications require more rigorous development, testing, and documentation activities. Furthermore, IEC 62304 also supports ongoing maintenance, problem resolution, and cybersecurity considerations throughout the software life cycle.

We will focus on how medical device software should be planned, developed, tested, maintained, and monitored throughout its life cycle. The aim is to ensure patient safety and regulatory compliance.

What is medical device software?

Medical device software is a software that is intended to perform a medical purpose, either independently or as part of a medical device. The software may be embedded within a medical device, such as a pacemaker or infusion pump, or function as standalone software, including Software as a Medical Device (SaMD). Examples include diagnostic imaging software, patient monitoring applications, treatment planning systems, and clinical decision support tools.

As such software can directly influence patient diagnosis, treatment, or monitoring, failures may lead to patient harm. Therefore, medical device software requires a structured development approach compliant with standards, such as IEC 62304.

IEC 62304 is the globally recognized standard for medical device software lifecycle processes. The standard applies to medical devices containing embedded software components. It also applies to standalone software, commonly known as Software as a Medical Device (SaMD). The standard establishes lifecycle processes to ensure software is developed, verified, maintained, and controlled throughout its use. As software becomes increasingly central to healthcare delivery, IEC 62304 provides the framework needed to demonstrate safety, effectiveness, and regulatory compliance.

Medical device software development evolution & the role of IEC 62304 in it

Medical device software has evolved from simple embedded functions to complex systems that support diagnosis, treatment, monitoring, and clinical decision-making. Modern devices increasingly rely on software to perform critical healthcare functions. As software complexity increased, regulators and manufacturers recognized the need for a structured development framework. IEC 62304 was developed to address this need by establishing standardized software lifecycle requirements. The standard helps ensure software is developed consistently, safely, and effectively throughout its lifecycle.

How medical device software has evolved?

Early medical devices contained limited software functionality and lower development complexity. Today’s devices often include advanced algorithms, connectivity features, cloud integration, and artificial intelligence capabilities. Software has become a primary driver of device performance rather than a supporting component.

Examples include:

• Diagnostic imaging software.
• Patient monitoring systems.
• Infusion pump software.
• Clinical decision support applications.
• Software as a Medical Device (SaMD).

As software capabilities expanded, the potential impact of software failures also increased.

Why did a standardized development approach become necessary?

Historically, software development practices varied significantly between manufacturers. Inconsistent processes increased the risk of defects, failures, and patient harm. Several high-profile incidents demonstrated that software errors could have serious clinical consequences.

Key challenges included:

• Inadequate software testing
• Poor requirements management
• Limited traceability
• Uncontrolled software changes
• Weak risk management practices

These challenges highlighted the need for a globally recognized software lifecycle standard.

The Role of IEC 62304

IEC 62304 establishes a framework for managing the entire medical device software lifecycle. Rather than prescribing specific technologies, it defines the processes manufacturers should follow.

The standard covers:

• Software development planning
• Requirements management
• Software architecture and design
• Software implementation
• Verification and testing
• Software release activities
• Maintenance activities
• Problem resolution processes
• Configuration management

This process-based approach helps manufacturers produce safe and reliable software consistently.

Integration of risk management

One of IEC 62304’s most important contributions is its integration with risk management principles. Software development activities must consider potential hazards and patient safety impacts throughout the lifecycle.

The standard works closely with ISO 14971 by:

• Identifying software-related hazards
• Evaluating potential harms
• Implementing risk control measures
• Verifying the effectiveness of controls
• Managing residual risks

This ensures safety remains a continuous consideration rather than a final-stage activity.

Benefits for manufacturers

Implementing IEC 62304 helps manufacturers establish a disciplined software engineering process.

Benefits include:

• Improved software quality
• Better traceability
• Stronger risk control
• More effective change management
• Greater regulatory confidence
• Enhanced patient safety

The standard also facilitates compliance with regulatory expectations in multiple global markets.

Why does standardized medical device software development matter?

Medical device software continues to grow in complexity and clinical importance. Without structured lifecycle controls, software defects may affect device safety and performance. IEC 62304 provides the foundation for developing, maintaining, and improving medical device software throughout its lifecycle. It has become a key benchmark for demonstrating that software is safe, effective, and suitable for its intended medical purpose.

Thus,IEC 62304 emerged as the industry’s response to increasing software complexity. It provides a structured lifecycle framework that promotes software quality, patient safety, risk management, and regulatory compliance.

The main processes in IEC 62304

IEC 62304 is organized into five main lifecycle processes, each containing specific activities and requirements. These processes work together rather than following a strict sequence. Together, these processes provide a framework for developing, maintaining, and controlling medical device software throughout its lifecycle. However, the standard does not prescribe a specific lifecycle model. Manufacturers may use Agile, Waterfall, V-Model, or hybrid approaches, provided all IEC 62304 requirements are fulfilled and justified. We have presented the five main processes:

1. Software development process

This process covers activities from planning through software release.

Key activities typically include:

• Software development planning
• Requirements analysis
• Architectural design
• Detailed design
• Implementation
• Verification and testing
• Software release

The goal is to ensure software requirements are correctly translated into a safe and functional product. Each stage provides evidence that the software performs as intended.

2. Software maintenance process

Software responsibilities continue after product release. Devices require updates, bug fixes, enhancements, and cybersecurity improvements.

Key objectives include:

• Assessing proposed changes
• Evaluating safety impacts
• Implementing modifications
• Verifying updated software

Maintenance ensures software remains safe and effective throughout its market life.

3. Software risk management process

Risk management is embedded throughout the software lifecycle rather than treated as a separate activity.

Typical activities include:

• Hazard identification
• Risk analysis
• Risk control implementation
• Verification of controls
• Residual risk evaluation

This process works closely with ISO 14971 and helps reduce the likelihood of software-related harm.

4. Software configuration management process

Configuration management ensures control over software artifacts throughout development and maintenance.

Key controls include:

• Version management
• Change control
• Configuration identification
• Release management
• Traceability maintenance

Without configuration management, manufacturers may struggle to identify which software version was tested or released.

5. Software problem resolution process

Problems may arise during development, testing, or post-market use.

This process focuses on:

• Problem identification
• Root cause investigation
• Impact assessment
• Corrective actions
• Verification of fixes

A structured approach helps prevent recurring issues and supports continuous improvement.

IEC 62304 does not require a specific development methodology

A common misconception is that IEC 62304 dictates a fixed development sequence. The standard explicitly states otherwise. Users are responsible for selecting an appropriate lifecycle model and mapping IEC 62304 requirements to that model. Agile methodologies are acceptable if compliance can be demonstrated. Manufacturers can use Agile, Scrum, Waterfall, V-Model, or Hybrid methodologies. The key requirement is demonstrating that all relevant IEC 62304 activities have been performed and documented.

Therefore, IEC 62304 is built around five lifecycle processes that manage software development, maintenance, risk, configuration, and problem resolution. The standard allows flexible development methodologies and focuses on evidence-based compliance rather than prescribed documentation formats.

Hence, IEC 62304 should not be viewed as a checklist or rigid workflow. Instead, it provides a flexible lifecycle framework that can be integrated into different development methodologies. The focus is on ensuring medical device software safety, effectiveness, traceability, and regulatory compliance through well-controlled processes. 

Understanding the relationship between IEC 62304 and other standards

IEC 62304 does not function as a standalone standard. It is part of a broader medical device regulatory framework and relies on several complementary standards. While IEC 62304 focuses on software lifecycle processes, other standards address risk management, quality systems, usability, product safety, and cybersecurity. Together, these standards help manufacturers demonstrate that their software is safe, effective, and compliant throughout its lifecycle.

• IEC 62304 and ISO 14971: Risk Management: The strongest relationship exists between IEC 62304 and ISO 14971. IEC 62304 requires manufacturers to incorporate risk management activities throughout software development. However, it does not provide a complete risk management methodology. ISO 14971 fills this gap by defining how risks are identified, evaluated, controlled, and monitored.
• IEC 62304 and ISO 13485: Quality Management Systems: ISO 13485 establishes requirements for a medical device Quality Management System (QMS). IEC 62304 operates within this quality framework.
• IEC 62304 and IEC 62366-1: Usability Engineering: IEC 62366-1 addresses usability engineering and complements software development activities defined in IEC 62304.
• IEC 62304 and IEC 82304-1: Health Software Products: IEC 62304 focuses on software development processes. IEC 82304-1 takes a broader product perspective and addresses the safety and quality of health software products.
• IEC 62304 and IEC 60601-1: Medical Electrical Equipment: IEC 60601-1 addresses the safety and essential performance of medical electrical equipment, while IEC 62304 addresses the associated software.

What is Software of Unknown Provenance (SOUP)?

Software of Unknown Provenance (SOUP) refers to software components that were not originally developed specifically for a medical device or whose development history is not fully known. Examples include operating systems, third-party libraries, open-source software, databases, middleware, and commercial software components. Since manufacturers often have limited visibility into how these components were designed, tested, or maintained, they can introduce safety, performance, and cybersecurity risks. IEC 62304 does not prohibit the use of SOUP. However, it requires manufacturers to identify SOUP components, evaluate associated risks, implement appropriate controls, and monitor them throughout the software lifecycle. Proper SOUP management helps ensure that externally sourced software does not compromise the safety, effectiveness, or regulatory compliance of the medical device.

Using SOUP in medical devices requires risk analysis and robust software design practices. The goal is to ensure that the reliability of SOUP components does not compromise the device’s safety, performance, or effectiveness. Manufacturers must also implement appropriate risk controls, verify their effectiveness, and monitor SOUP-related issues throughout the software lifecycle.

Legacy software

Legacy software refers to medical device software that was developed before the organization adopted IEC 62304 or before compliance evidence was established. In many cases, the software may already be commercially available and functioning as intended. However, objective evidence demonstrating compliance with current IEC 62304 requirements may be incomplete or unavailable. The challenge is not necessarily that the software is unsafe. However, its development history, documentation, testing records, or risk management activities may not meet current expectations. IEC 62304 acknowledges the existence of legacy software and provides guidance for evaluating and managing it within a compliant software lifecycle framework. If you want to bring legacy software into compliance with IEC 62304, here is the required process:

Security

As medical devices become increasingly connected, cybersecurity has become a critical consideration in software development. Notably, IEC 62304 contains very few explicit security requirements and was developed before cybersecurity became a major industry concern. Nevertheless, manufacturers must ensure software is developed with appropriate security measures to protect the confidentiality, integrity, and availability of data and systems. Security-related risks should be considered alongside safety risks, particularly because cybersecurity vulnerabilities can directly affect device performance and patient safety. Moreover, IEC 81001-5-1 is a more recent standard that provides detailed guidance for secure health software development and complements IEC 62304’s lifecycle requirements.

Software system, items, and units

IEC 62304 organizes software into a hierarchy of software systems, software items, and software units to help manage complexity during development. A software system represents the complete medical device software. A software item is a major component within that system. Whereas, a software unit is the lowest-level element that can be individually implemented and tested. This structure helps manufacturers break large software applications into manageable parts, making development, verification, maintenance, and traceability more effective. By defining software at different levels, IEC 62304 supports a systematic approach to architecture, testing, and risk management throughout the software lifecycle.

IEC 62304 medical device software safety classification

One of the most important concepts in IEC 62304 is medical device software safety classification. The standard recognizes that not all medical device software poses the same level of risk to patients. Therefore, the amount of development rigor, testing, documentation, and process control should be proportional to the potential harm that could result from a software failure. Rather than focusing on software complexity or functionality, IEC 62304 classifies software based on the severity of possible injury that could occur if the software fails.

IEC 62304 defines three software safety classes:

• Class A: Class A software cannot contribute to a hazardous situation that could result in injury or damage to health. Examples: Administrative software functions and non-clinical information displays. Since the risk is lowest, Class A software has the fewest lifecycle requirements.
• Class B: Class B software failures could result in non-serious injury to a patient, user, or other person. Examples: Software controlling non-critical device functions and systems where failure could lead to temporary or reversible harm. Class B requires more rigorous development and verification activities than Class A.
• Class C: Class C software failures could result in death or serious injury. Examples: Life-supporting device software and critical therapy delivery systems. Class C software directly controls functions essential to patient safety. This class requires the highest level of process control, documentation, and verification.

The three essential steps in the classification process

These are the three key questions that manufacturers should evaluate when classifying software.

• Step 1: Determine whether the software can contribute to a hazardous situation: The first step is to assess whether a software failure could contribute to a hazardous situation. If no hazardous situation can occur, the software may be classified as Class A.
• Step 2: Evaluate possible harm: If a hazardous situation exists, the next step is to determine the severity of potential harm. The manufacturer should evaluate whether the failure could result in non-serious injury, serious injury, or death.
• Step 3: Consider existing risk control measures: The final step is to assess whether external risk control measures can prevent the hazardous situation from causing harm. These controls may exist outside the software itself and can influence the final classification.

Why is medical device software classification important?

The medical device software classification determines which IEC 62304 requirements apply to the software. Higher classifications require more extensive planning, risk management, verification, testing, and documentation activities. As a result, safety efforts remain proportionate to the level of patient risk.

Common mistakes and misunderstandings of medical device software classification to avoid

Medical device software safety classification is often misunderstood because people focus on the wrong factors when assigning classes. IEC 62304 uses classification to determine the rigour of the development process and not to declare whether a product is safe or unsafe. Higher-risk software receives more stringent development, verification, and documentation requirements.

1. Software safety classification does not determine how safe your product is

A common misconception is that Class C software is automatically less safe than Class A software. In reality, the classification only determines the level of process rigor required during development. IEC 62304 leaves the definition of product requirements and risk control measures to the manufacturer. Therefore, a well-designed Class C product can still be safe if risks are properly controlled.

2. The benefits of the software cannot be used to lower the classification

Software classification is not based on how beneficial the software is to users or patients. Benefit-risk analysis is an ISO 14971 concept used only when additional risk controls are not feasible. Therefore, manufacturers cannot reduce a software safety class simply because the software provides significant clinical benefits.

3. Risk control measures within the software do not lower the classification

Another common misunderstanding is that implementing software-based risk controls can reduce the software safety class. IEC 62304 assumes software can fail at any time. As a result, risk controls implemented within the software itself cannot be used to lower the classification. They remain important for reducing risk. However, they do not change the assigned safety class.

4. Getting the probability of software failure wrong

Many organizations incorrectly estimate software failure probability during classification. For software safety classification, manufacturers should assume the software could fail at any time and treat the probability of software failure as 100%. However, the overall probability of harm may still be low because the hazardous situation may not necessarily result in patient harm. Understanding the relationship between probability of failure and probability of harm is therefore critical when classifying software correctly.

Therefore, these misconceptions often lead to over-classification or under-classification of software. An incorrect classification can create unnecessary compliance burdens or insufficient lifecycle controls. Hence, medical device software classification should be driven by potential patient harm and the IEC 62304 decision process, rather than assumptions about software complexity, benefits, or internal risk controls.

Moreover, software safety classification determines the rigor of the development process and not the safety of the final product. Manufacturers should avoid using software benefits, internal risk controls, or incorrect probability assumptions to justify a lower classification.

Risk management in the IEC 62304 standard

Notably, risk management is a fundamental part of IEC 62304 and cannot be separated from the software development lifecycle. Rather than treating risk management as an independent activity, the standard integrates it throughout software planning, development, verification, maintenance, and problem resolution. However, IEC 62304 does not provide a complete risk management framework. Instead, it relies heavily on ISO 14971, which serves as the primary standard for medical device risk management. Together, these standards help manufacturers identify software-related hazards, implement risk controls, and ensure that software remains safe throughout its lifecycle.

Risk management and IEC 62304

IEC 62304 requires manufacturers to consider risks at multiple stages of the software lifecycle.

This includes:

• Identifying software-related hazards
• Evaluating potential hazardous situations
• Implementing risk control measures
• Verifying the effectiveness of risk controls
• Managing risks associated with software changes

Risk management activities influence many software development decisions, including architecture, requirements, testing, and maintenance. Hence, IEC 62304 should not be used alone for risk management. The standard depends on ISO 14971 to provide the methodology for identifying, evaluating, controlling, and monitoring risks.

Software risk control measures

In the context of IEC 62304, software risk control measures are intended to reduce the probability of software failure. Unlike risk controls implemented by software, these measures focus on making the software itself more reliable and less likely to contribute to hazardous situations. We have presented three main areas where software risk control measures can be applied.

1. Development process: Following a disciplined development process can reduce the likelihood of software failures. The underlying principle is that better development practices generally result in fewer software defects.
2. Software system: Risk control measures can also be implemented at the software architecture level through design decisions. An operating system can be used to prioritize critical tasks as a software risk control measure.
3. Software items and units: At the lowest software levels, risk control measures become closely aligned with good engineering practices. These controls help identify or prevent failures before they affect the software system.

Impact on probability of failure

Combined effect of all software risk control measures can be used to justify a reduction in P1, which represents the probability of software failure contributing to a hazardous situation.

Assessing the efficacy of software risk control measures

Determining the probability of medical device software failure is extremely difficult. Similarly, quantifying exactly how effective a software risk control measure is can be challenging. To address this, there is a two-step approach.

• Step 1: Verify that the risk control measure works as intended: Manufacturers should provide objective evidence that the control performs its intended function. Verification confirms the measure actually works before relying on it for risk reduction.
• Step 2: Work with relative probability: Assume the probability of software failure is 100% when no risk controls exist. After implementing risk controls, manufacturers should estimate how much the probability has been reduced relative to the uncontrolled situation.

Hence, medical device software risk control measures are not limited to code-level checks. They can be implemented through the development process, software architecture, and software units. Thus, effective risk reduction is usually achieved through a combination of controls across all three levels rather than relying on a single measure.

Software risk control measures aim to reduce the probability of software failure. IEC 62304 encourages controls at the development process, software system, and software unit levels, while requiring manufacturers to verify their effectiveness and justify any claimed reduction in failure probability.

Software causes

A software failure itself is generally not considered the root cause of harm. Instead, manufacturers should identify the specific software causes that could lead to a hazardous situation. A software cause is the mechanism by which the software contributes to the hazard. Understanding software causes helps manufacturers determine where risk control measures should be applied and how software-related risks can be effectively reduced.

IEC 62304 focuses on understanding how software contributes to risk, not simply acknowledging that software can fail. Identifying software causes allows manufacturers to implement targeted controls and demonstrate a systematic approach to software safety.

How do you document software risk management?

IEC 62304 does not prescribe a specific format for documenting software risk management. Instead, manufacturers must ensure that sufficient objective evidence exists to demonstrate compliance. Documentation should clearly show how software-related hazards were identified, evaluated, controlled, and verified throughout the software lifecycle. The documentation should demonstrate:

• Identified software-related hazards
• Software causes contributing to hazards
• Implemented risk control measures
• Verification of risk controls
• Residual risk evaluations
• Traceability between hazards, controls, and verification activities

Manufacturers may use risk management files, requirements management tools, traceability matrices, issue tracking systems, and electronic quality management systems.

The specific format is less important than the ability to demonstrate that risk management activities were performed and maintained.

Regulators and auditors expect clear evidence that software risks have been systematically managed. Well-structured documentation supports compliance with both IEC 62304 and ISO 14971 while making software changes easier to assess throughout the product lifecycle.

Common mistakes and misunderstandings of medical device software risk management

We have presented two common mistakes that organizations make when implementing medical device software risk management under IEC 62304. These mistakes often result in unnecessary work or ineffective risk management activities. Understanding them can help manufacturers create a more efficient and safety-focused software development process.

1. Duplication of system hazard trace matrix: IEC 62304 uses a bottom-up approach to identify software-related risks. A common mistake is duplicating activities already performed within the system risk management process. For example, some organizations identify hazards and harms separately in both system risk management and software risk management processes. This creates unnecessary duplication because hazards and harms only need to be identified once at the system level.
2. Working with software risk management retrospectively: Another common problem: treating software risk management as a late-stage compliance activity. Many projects focus heavily on developing impressive functionality while giving insufficient attention to risk management. In some cases, risk management is performed only shortly before product release to satisfy regulatory expectations.

However, we must remember the primary goal of medical device development is protecting patients from harm. Risk management should therefore be integrated from the beginning of the project and remain an ongoing activity throughout the software lifecycle.

IEC 62304 software development

The software development process is the largest process within IEC 62304 and includes activities ranging from planning to software release. The standard defines what activities must be performed, but it does not specify how they should be performed. Therefore, manufacturers are free to choose the software development methodology that best suits their organization and product.

A notable common misconception is that IEC 62304 requires a specific development approach. Manufacturers may use different lifecycle models as long as all IEC 62304 requirements are addressed and appropriate evidence is maintained.

Waterfall approach

The Waterfall model can be used as a software development approach.

In the Waterfall model:

• Activities are performed sequentially
• Requirements are defined first
• Design follows requirements
• Implementation follows design
• Testing occurs after development

This approach aligns naturally with the structure of IEC 62304 because lifecycle activities are clearly defined and documented.

Agile approach

Agile development can also be used with IEC 62304.

Key characteristics include:

• Iterative development
• Frequent software releases
• Continuous feedback
• Incremental implementation of requirements

Although Agile differs from Waterfall, manufacturers must still demonstrate compliance with all applicable IEC 62304 activities.

Medical device software development activities defined by IEC 62304

Regardless of the lifecycle model used, IEC 62304 requires activities covering:

• Software development planning
• Software requirements analysis
• Software architectural design
• Software detailed design
• Software unit implementation and verification
• Software integration and integration testing
• Software system testing
• Software release

These activities provide a structured framework for developing medical device software safely and effectively.

Therefore, IEC 62304 is process-based rather than methodology-based. Whether a manufacturer chooses Waterfall, Agile, or another lifecycle model, compliance depends on demonstrating that all required software development activities have been performed and appropriately documented.

IEC 62304 does not require Waterfall, Agile, or any other specific development methodology. It defines the lifecycle activities that must occur while allowing manufacturers flexibility in how those activities are implemented.

How to plan medical device software development?

Software development planning is the first activity in the IEC 62304 medical device software development process. The purpose of the plan is to define how the software will be developed and controlled throughout its lifecycle. The plan should establish the processes, deliverables, traceability activities, configuration management approach, change management process, and problem resolution activities required for the project. A well-structured plan helps ensure that development activities are performed consistently and in compliance with IEC 62304.

Processes

One of the first planning decisions is determining which development process will be used. Manufacturers can reference existing processes within their Quality Management System (QMS) or define project-specific processes in the software development plan.

Possible approaches include:

• Extreme Programming (XP)
• Scrum
• Kanban
• Test-Driven Development (TDD)
• Waterfall
• Hybrid approaches

The important consideration is demonstrating how the chosen approach satisfies IEC 62304 requirements rather than selecting a specific methodology.

Deliverables

The development plan should clearly define what outputs will be created and when they will be produced.

Deliverables include more than just:

• Executable software
• Software binaries

They should also include required documentation such as:

• Software requirements
• Design documentation
• Verification records
• Test documentation
• Risk management records

The plan should establish expectations for both software outputs and supporting documentation.

Traceability

Traceability is essential for demonstrating that software performs as intended.

Manufacturers should establish traceability between:

• Software requirements and their source
• Requirements and software design
• Requirements and verification activities
• Requirements and test results

Strong traceability helps demonstrate compliance and supports impact assessments when changes occur.

Configuration and change management

The development plan should define how software versions will be identified and controlled.

Key considerations include:

• Version numbering strategy
• Configuration identification
• Management of multiple software components
• Control of software changes

Splitting the medical device software into multiple components with separate version numbering may simplify regression testing. If a change affects only one component, other components may not require extensive retesting, provided the architecture supports sufficient separation.

The plan should also define how changes will be managed throughout development and after release.

Examples include:

• Using a ticket system to manage development bugs
• Implementing formal reviews for post-release changes
• Assessing the impact of proposed modifications

Problem resolution

Software problems, bugs, and anomalies are inevitable during development.

The plan should describe:

• How problems are identified
• How they are reviewed
• How corrective actions are determined
• When affected parties should be informed
• How issues are tracked to closure

In many cases, an existing ticketing system can support problem resolution activities, provided it captures the information required by IEC 62304.

Therefore, the medical device software development planning should be practical rather than administrative. A well-defined plan establishes how development, documentation, traceability, change management, and problem resolution will be handled before development begins. This creates a structured foundation for the entire software lifecycle.

A software development plan should define the development process, deliverables, traceability approach, configuration management strategy, change management activities, and problem resolution process. These elements help ensure software is developed in a controlled, traceable, and compliant manner throughout its lifecycle.

IEC 62304 medical device software requirements specification

Medical device software requirements specification is a critical activity because it establishes what the software must do before design and implementation begin. These requirements become the foundation for architecture, detailed design, implementation, verification, and maintenance activities. Well-defined requirements help ensure that the final software behaves as intended and that safety risks are appropriately controlled throughout the lifecycle.

• Sources of software requirements: Software requirements are not created in isolation. They are typically derived from multiple sources and should be traceable to their origin. Maintaining traceability helps demonstrate why a requirement exists and how it contributes to the software’s intended function.
• Functional and performance requirements: Software requirements should define the software’s expected functionality and performance.Requirements should be sufficiently detailed to support design and testing activities.
• Requirements related to risk control: Notably, medical device software risk control measures often become software requirements. These requirements are particularly important because they help reduce software-related risks identified during risk management activities.
• User interface requirements: User interface requirements should be considered as part of the software requirements specification. Poorly specified user interface requirements can lead to usability issues and use-related risks.
• Requirements needed for verification: A requirement should be written so it can later be verified. If a requirement cannot be tested, demonstrating compliance becomes difficult.
• Traceability requirements: Traceability provides evidence that the software performs as intended.

However, if you create vague requirements, they cannot be objectively verified. A requirement should clearly define expected behavior so that developers know what to build and testers know what to verify.

Software requirements drive every subsequent development activity. Missing, unclear, or poorly controlled requirements can introduce design flaws, testing gaps, and safety issues. Establishing complete and traceable requirements helps ensure software is developed in a controlled and compliant manner.

Therefore, software requirements should define functionality, performance, user interactions, and software risk controls. Requirements must be clear, testable, and traceable so they can support design, verification, and regulatory compliance throughout the software lifecycle.

Architectural design

Architectural design is one of the most important software development activities in IEC 62304. A well-designed architecture establishes the foundation for implementation, testing, maintenance, and future software changes. Decisions made during architecture design can significantly influence software quality, safety, maintainability, and development effort throughout the lifecycle. IEC 62304 identifies several critical activities that should be addressed during this stage.

Transform requirements into an architecture

The first step is converting software requirements into a logical software architecture. Sound engineering practices should be used when deciding how to structure the software.

Key considerations include:

• How many software items should be created
• How functionality should be distributed across items
• Whether frequently changing functionality should be isolated within specific items
• How the architecture can support future maintenance and modifications

A well-structured architecture can make software easier to understand, test, maintain, and update throughout its lifecycle.

Develop architecture for the interfaces of software items

Software items rarely operate independently. The architecture should therefore define how software items communicate and interact with each other. In some cases, standard interfaces may be sufficient. In others, a more advanced mechanism may be required to ensure reliable communication between software items. The objective is to create clear, well-defined interfaces that support predictable software behavior.

Specify requirements for SOUP items

If SOUP (Software of Unknown Provenance) is used, the architecture should clearly define what is expected from those components. There are two important considerations:

• Define expected behaviour: Manufacturers should specify what the SOUP component is expected to do, which functions will be used, and how the SOUP component contributes to the software system.
• Identify prerequisites: Manufacturers should also identify conditions required for the SOUP to function correctly, dependencies on other software components, required operating environments, and supporting services or resources. This information can subsequently be used during testing to demonstrate that the SOUP component is suitable for its intended purpose within the software system.

Identify segregation necessary for risk control

Notably, segregation is an important architectural consideration, particularly for Class C medical device software. Segregation involves separating critical functionality from non-critical functionality within the architecture.

Potential benefits include:

• Preventing failures from propagating between software items.
• Isolating safety-critical functions.
• Simplifying risk management activities.
• Reducing the impact of software defects.

Furthermore, even though segregation is only an explicit Class C requirement, it may be beneficial for all software classes. An effective architecture may enable some software items to be classified to lower safety classes. This can potentially reduce development, verification, and documentation effort for those items.

Documenting the software architecture

There is no single prescribed method for documenting medical device software architecture. However, architecture diagrams are commonly used because they help visualize:

• Software items
• Relationships between items
• Interfaces
• Data flows
• System structure

The documentation approach should make the architecture understandable and support implementation, testing, maintenance, and regulatory review activities.

Software detailed design

Software detailed design is the activity where the software architecture is refined further until it is represented by individual software units. While architectural design focuses on software items and their relationships, detailed design focuses on how each software unit will be constructed and interact with other units. The objective is to think through the implementation before coding begins, thereby reducing the likelihood of ad-hoc development decisions. This activity is one of the areas where Class C medical device software differs most from Class A and Class B software. This is because IEC 62304 introduces specific requirements for detailed design activities.

• Detailed design for each unit: For Class C software, manufacturers should establish a detailed design for each software unit before implementation begins. The purpose is to define how the unit will work, describe the intended behaviour, support consistent implementation, and reduce ambiguity for developers. Thus, investing time in design before coding helps reduce development errors and rework later in the project.
• Detailed design for interfaces: The design should also define how software units communicate with one another. This includes inputs and outputs, data exchanged between units, interactions between software units, behaviour at the interface boundaries. Well-defined interfaces help ensure units integrate correctly during later development activities.
• Verification of detailed design: IEC 62304 also requires verification of the detailed design for Class C medical device software. The purpose is to confirm that the design meets the intended requirements and supports the software architecture. Additionally, the aim also confirms potential design issues are identified before implementation. Hence, this isas an important mechanism for encouraging engineering review and reflection before coding starts.

How should detailed design be documented?

There is no single correct way to document detailed design. The primary goal is to create documentation that supports implementation work and helps developers understand how the software should be built. An important consideration is that detailed design documentation may be reviewed during regulatory submissions. Therefore, manufacturers should consider how the design can be presented in a printable format, such as a PDF document.

Example 1: Write medical device software detailed design documents

One approach is to create traditional design documents. Examples include word documents, formal design specifications, wiki-based design documentation. These documents describe the software units, their behaviour, and their interfaces.

Example 2: Capture design information in a ticket system

 Organizations using Agile approaches may document design activities directly within their ticketing systems. For example, user stories, development tasks, engineering work items. Relevant design decisions can be captured within these tickets as part of the development workflow.

Example 3: Use the source code

The source code as a potential design documentation mechanism. Using a structured commenting approach design information can be captured within source files and developers can create a skeleton structure before implementation. Then, skeleton can then be populated with actual code during development. This approach allows design information and implementation details to remain closely linked.

Software implementation

Software implementation is the stage where the actual coding work begins. IEC 62304 requires manufacturers to focus on unit verification. The goal is not only to write code but also to demonstrate that each software unit performs as intended before moving to integration activities.

• Unit verification: Unit verification confirms that individual software units have been implemented correctly.Unit testing frameworks are commonly used for this purpose. However, unit testing is not the only acceptable method.

Integration and integration testing

Integration is the process of assembling software units into software items and software items into a complete software system. Once integration is performed, testing is needed to confirm that the integrated components work together correctly. Integration testing verifies that software units can be assembled without errors, software items interact correctly, interfaces function as intended, communication between components works properly. The focus is on identifying problems related to interfaces and interactions among integrated modules.

Why separate integration testing from system testing?

Some organizations may consider combining integration testing with system testing. However, keeping them separate offers important advantages. Interface and interaction issues can be difficult to identify during system-level testing. Integration testing helps isolate these problems before testing the complete software system.

The “Brickman” example

We will use the Brickman example to illustrate this concept. Rather than testing the entire Brickman system immediately, it may be beneficial to perform integration testing on individual items first. This allows their capabilities and interactions to be evaluated thoroughly before progressing to full system testing.

System testing

Software system testing verifies that the software works as intended and is safe to use. Testing can be challenging because software may be used in different ways and on different hardware platforms. The goal is to demonstrate that the complete software system satisfies its specified requirements. IEC 62304 requires manufacturers to establish and perform tests covering all software requirements. The purpose is to ensure every software requirement is verified through testing.

IEC 62304 contains several tasks during system testing. Together, these tasks form a structured process for demonstrating that the complete software system performs as intended.

Medical device software release

After development and testing activities are completed, the software enters the release stage. Manufacturers must determine whether the software is ready for release and document what is included in the release. This assessment should occur before distributing the software. The release decision should be supported by documented evidence.

Furthermore, manufacturers should document what is included in the software release. Notably, IEC 62304 allows software to be released with residual anomalies, sometimes referred to as bugs. This is acceptable when the anomalies do not contribute to hazardous situations, negatively affect software functionality, and have been evaluated and accepted.

Examples of acceptable residual anomalies are typos, misalignment of graphical elements, or bugs with acceptable workarounds. These issues may remain open if they do not create unacceptable risk.

How to maintain medical device software according to IEC 62304?

Notably, medical device software development does not end when the product is released. Medical device software must be maintained throughout its lifecycle to ensure it remains safe, effective, and suitable for its intended use. Maintenance activities address defects, enhancements, changing user needs, cybersecurity concerns, and other software changes. IEC 62304 therefore includes a dedicated software maintenance process that helps manufacturers manage software after release in a controlled manner. Maintenance activities are typically triggered by problems discovered in the software, customer feedback, new requirements, product improvements, regulatory changes, and cybersecurity concerns. When a problem or change is identified, manufacturers must evaluate its impact before modifying the software.

Problem resolution

Problems are an inevitable part of software development and maintenance. Problems may be discovered during testing, after release, through customer complaints, or during routine maintenance activities.

The first step is to identify and document the problem. Important activities include reviewing the reported problem, determining the cause, assessing the impact, and deciding whether corrective action is necessary.

Manufacturers should evaluate whether the problem could contribute to a hazardous situation. If safety is affected, additional actions may be required. A problem-resolution process is often managed within a ticketing system. However, the system should contain the information required by IEC 62304, including actions taken and whether affected parties need to be informed.

Change control

Once a change is proposed, it should not be implemented immediately. Instead, manufacturers should evaluate the potential impact of the change before modifying the software.

Key considerations include:

• What parts of the software are affected?
• Does the change introduce new risks?
• Are existing risk controls affected?
• What testing will be required?
• Will documentation need updating?

The purpose of change control is to ensure that fixes and enhancements do not unintentionally introduce new defects or safety issues. Moreover, different levels of review may be appropriate depending on the nature of the change. For example, a development bug may be managed through a ticketing system, while a post-release change may require a more formal assessment.

Therefore, medical device software maintenance should be a controlled and risk-based activity. Every problem and change should be reviewed to determine its potential impact on safety and performance. Simply fixing software without assessing risks can create new hazards.

How to implement the IEC 62304 standard successfully?

Successful IEC 62304 implementation is not about producing large amounts of documentation. Instead, it is about establishing effective processes that support software quality, safety, and compliance throughout the lifecycle. A successful implementation integrates software development, risk management, testing, traceability, change management, and maintenance into everyday development activities. The objective is to build compliance into the development process rather than treating it as a separate regulatory exercise.

Manufacturers should avoid creating unnecessary work. Activities should be integrated wherever possible, documentation should be meaningful, and processes should support both compliance and efficient software development.

Understanding Agile in the context of IEC 62304

Agile practices can play an important role in implementing IEC 62304 effectively. Agile focuses on iterative and incremental development while emphasizing transparency, flexibility, collaboration, and responsiveness to change. These characteristics can work well alongside IEC 62304 requirements when managed appropriately.

Rather than conflicting with IEC 62304, Agile can help organizations satisfy many of the standard’s requirements.

1. Excellent for software risk management: Agile supports continuous risk management throughout development. Agile encourages early risk identification, continuous risk assessment, frequent risk mitigation activities, and risk management throughout the software lifecycle. This aligns closely with IEC 62304’s expectation that risk management should be performed continuously rather than retrospectively.
2. Promotes clear requirements: Agile relies on regular communication and feedback. It helps clarify requirements, improve understanding among team members, support verification activities, and reduce misunderstandings during development. However, records must still be maintained to demonstrate compliance with IEC 62304 requirements.
3. Early detection of design flaws: Agile encourages continuous integration, frequent testing, and early feedback. These practices help identify design and implementation issues sooner. Early detection can reduce rework and support the software testing expectations of IEC 62304.
4. Integral change management: Agile is designed to accommodate change. This flexibility aligns well with IEC 62304 by allowing teams to manage changing requirements, update software designs, maintain traceability, and control development changes. This helps ensure that modifications remain visible and well-controlled throughout the lifecycle.

Agile must still be adapted for medical devices

Agile does not automatically result in compliance. Manufacturers remain responsible for:

• Meeting regulatory requirements
• Maintaining traceability
• Managing risks
• Producing required evidence
• Demonstrating compliance with IEC 62304

Therefore, agile practices should be adapted to operate within the regulatory environment of medical device software development.

For organizations using Agile methods, AAMI TIR45 can be a valuable resource. It provides guidance on applying Agile practices within medical device software development while maintaining compliance expectations.

Take a holistic view of your medical device software development process

Medical device software development does not exist in isolation. Software teams often work with different processes, milestones, and deliverables. When these processes are poorly aligned, organizational performance can suffer. Therefore, when implementing IEC 62304, manufacturers should take a holistic view of the entire medical device software development process rather than focusing only on software activities.

It is recommended to perform a practical exercise by simulating the preparation of a future product release and its technical documentation. This helps determine whether your development process produces the evidence needed for compliance and maintenance activities.

Questions to ask

How easy is it to identify relevant deliverables?

You should be able to quickly locate deliverables produced during software development. Examples include:

• Requirements documentation
• Design documentation
• Test records
• Risk management records
• Release documentation

If these outputs are difficult to find, maintaining products and preparing regulatory submissions becomes more challenging.

Can you find evidence of risk control measures?

It is important to demonstrate that software risk controls were:

• Implemented
• Verified
• Tested

Manufacturers should be able to show clear evidence that identified risks have been addressed through the software development process.

Can you establish traceability easily?

Traceability should not require significant effort to reconstruct. You should be able to trace:

• High-level requirements
• Software requirements
• Verification activities
• Verification evidence

Strong traceability simplifies compliance activities and demonstrates that software performs as intended.

Decide how you want to document

IEC 62304 requires numerous documents and records. However, these do not always need to be traditional paper documents. The important requirement is that information can be identified, maintained, and kept under version control. Therefore, manufacturers have flexibility in how they manage documentation. What matters is that the information is controlled and retrievable when needed. A practical approach is to use the same tools already employed for software version control. These tools can help maintain:

• Documentation
• Test records
• Traceability information
• Configuration history

This keeps development evidence close to the software being developed.

Make information presentable

Although documentation may be maintained electronically, records should be formatted so they can be easily presented when needed.

A good practice is ensuring information can be:

• Reviewed easily.
• Exported when required.
• Converted into formats such as PDF.

This can be particularly useful during audits, inspections, and regulatory submissions.

What are the consequences of not adhering to the IEC 62304 standard?

Failing to follow IEC 62304 can have serious consequences for both manufacturers and patients. The standard exists to promote the development of safe and effective medical device software. When software lifecycle processes are not properly implemented, the risk of software defects, safety issues, and regulatory challenges increases significantly.

• Increased risk to patients: Software failures can contribute to hazardous situations and negatively affect device performance. This increases the risk of patient harm and adverse clinical outcomes.
• Regulatory challenges: Manufacturers may struggle to demonstrate software safety and effectiveness without IEC 62304 processes. This can complicate regulatory submissions and compliance activities.
• Poor software quality: A lack of structured lifecycle processes often leads to more defects and rework. It can also create inconsistencies across development activities.
• Difficult maintenance and updates: Software changes become harder to evaluate when maintenance processes are poorly controlled. This increases the risk of introducing new defects during updates.
• Loss of traceability: Without traceability, it becomes difficult to connect requirements, design, testing, and risk controls. This can hinder change assessments and regulatory reviews.

Challenges when implementing IEC 62304

Implementing IEC 62304 is not usually difficult because of the standard itself. The real challenge is integrating the standard into existing development processes while maintaining efficiency, traceability, and compliance. Organizations often struggle when software development practices, quality systems, and regulatory requirements are not well aligned.

• Integrating IEC 62304 into existing processes: Many organizations already have established development processes before adopting IEC 62304. Aligning those processes with the standard’s requirements can require significant effort. Development teams should focus on adapting existing processes where possible rather than creating entirely new workflows.
• Managing documentation and records: IEC 62304 requires numerous documents and records throughout the software lifecycle. The challenge is ensuring information remains controlled, traceable, and accessible without creating unnecessary administrative burden.
• Maintaining traceability: Traceability is often one of the most challenging implementation areas. Manufacturers must demonstrate links between requirements, design, risk controls, testing, and verification evidence.
• Integrating risk management: Risk management should be embedded throughout software development rather than treated as a separate activity. Many organizations struggle when risk management is performed retrospectively instead of being integrated into daily development activities.
• Managing change effectively: Software is constantly evolving through bug fixes, enhancements, and maintenance activities. Organizations must establish effective change management processes to ensure modifications remain controlled and properly assessed.
• Balancing compliance and efficiency: A common challenge is avoiding unnecessary bureaucracy. Manufacturers should focus on generating useful evidence rather than creating documentation solely for compliance purposes.
• Keeping different functions aligned: Software development often operates differently from other product development functions. When processes do not work well together, organizational performance can become slow and inefficient. Hence, a holistic view of the entire product lifecycle should be taken rather than focusing only on software activities.

Drop an email at [email protected] or call/Whatsapp on 9996859227 for any queries on regulatory compliance for medical device software development.