All you need to know about IEC 62304 compliant software development

First of all, what is IEC 62304?

IEC 62304 is an international standard for medical device software which defines the framework for software lifecycle processes. It was first released in 2006, and an amendment was released in 2015.

IEC 62304 covers the safe design and maintenance of software, and ensures product safety from the very start of development. It applies if the software itself is a medical device, or if the software is an embedded part of the medical device.

Versions of IEC 62304

In this guide, we will focus on the original 2006 version of IEC 62304. However, in 2015, an amendment was released. There are some differences between the original version and the 2015 amendment. We will be sure to tell you when something important has been changed or added in the 2015 amendment.

Harmonisation

IEC 62304:2006 is harmonised internationally, being recognised by regulatory authorities worldwide, including the European Commission, the FDA in the U.S., Health Canada, and many more.

Is IEC 62304 mandatory?

Being certified to IEC 62304 is not mandatory, and it is also possible to be compliant without being certified.

However, companies adhering to IEC 62304 are more likely to have an easier path to obtaining regulatory clearance. Thus, it is highly recommended that companies who produce medical device software follow its requirements.

This is not only because it helps ensure the highest safety standards for the products, but also because many regulatory organisations participate in the writing of the standards, and many of the regulations are based on industry standards.

Additionally, the MDR (Medical Device Regulation) and the IVDR (In Vitro Diagnostic Regulation) explicitly state that using harmonised standards should be a means for manufacturers to demonstrate conformity with the general safety and performance requirements and other legal requirements.

Although the use of harmonised standards remains voluntary, and manufacturers are free to choose another means of demonstrating compliance to the mandatory legal requirements, using them still puts manufacturers at a significant advantage. IEC 62304 needs to be applied in conjunction with ISO 13485 and ISO 14971.

In practice, you will almost certainly be looking to implement IEC 62304.

---

What are the steps to becoming IEC 62304 compliant?

There are 9 chapters to IEC 62304. We go over these in the order that they appear in the official IEC 62304 standard, as this makes the most sense.

We will cover the first three chapters in a more brief manner, as these are more or less introductory chapters to the standard, that yield little to no practical information. It is, however, important that you take note of these chapters before reading the other chapters.

The remaining 6 chapters, we'll dive a bit deeper into. Especially chapter 5, which is about the Software Development Process. If you would like a visual overview, please check attachment 1 at the bottom of this page.

---

The scope

In chapter 1 of the IEC 62304 standard, the scope of the standard itself is discussed. It is here, for example, that the standard is telling us that it applies to companies that develop or maintain medical device software, regardless of whether the software itself is a medical device, or if the software is an embedded part of the medical device.

Another important element is compliance: if you want to be compliant with this standard, you will need to implement all of the processes, activities and tasks that are identified throughout the standard in accordance with the corresponding software safety class.

---

Normative references

This section lists all of the referenced documents. The only normative reference in IEC 62304 is to ISO 14971.

It is important to note that IEC 62304 does not cover the validation and final release of the medical device, even if the medical device consists of medical software only. The validation stage is part of other standards, such as ISO 13485 and IEC 82304-1.

---

Terms and definitions

This chapter lists all of the terms and definitions that apply to IEC 62304. You should always refer to these definitions when dealing with matters relating to IEC 62304.

Two very important definitions to remember here are medical device vs. medical device software. It is very important that you are aware of the difference between the two definitions, as IEC 62304 only addresses medical device software.

---

General requirements

In order to be compliant with the IEC 62304 standard, there are 3 general requirements that you will need to adhere to:

• You will need a QMS (Quality Management System).
• You will also need to perform risk management with regards to patient safety, adhering to ISO 14971.
• You must assign a software safety class to your product.

4.1 QMS (Quality Management System)

It is essential to have a Quality Management System (QMS) in order for a device to be compliant with IEC 62304. Having a good QMS is proof that your company is quality-oriented, and therefore indicates that your product can be trusted in situations which may entail a risk to patients and/or users.

A company can demonstrate this ability by using a quality management system that complies with ISO 13485, a national quality management system standard, or a quality management system required by national regulation.

A quality management system (QMS) is a formalised system that documents the relevant processes, procedures and responsibilities for meeting the regulatory and customer requirements related to a product. A good QMS helps a company ensure that continuous improvements are made to their products, provides a baseline for training staff, and enables correction action to take place for any problems that arise.

If you do not have a QMS in place, you increase the risk of your employees using the wrong requirements documents, outdated test plans, and unvalidated tools. Having a QMS is also a requirement under article 10 of the MDR, which means you must have a QMS in order to receive a CE marking.

4.2 Risk Management

The manufacturer of the medical product must apply a risk management process that complies with ISO 14971.

The goal of risk management in IEC 62304 is to reduce harm to patients or users of the medical device. A risk can be defined as a combination of the probability of harm and the severity of that harm. Typically, a risk is the result of a harmful situation that needs some kind of risk control measure to be resolved or contained. In this case, the risk is caused by the software. Traceability is another important part of risk management, as it's important to understand how risks originated.

Risk management does not only incorporate software. It can also include risk controls for things like hardware, or user error. The ISO 14971 standard is a document that describes the terminology, principles and processes for the risk management of medical devices, including software as a medical device and IVD medical devices.

4.3 Software Safety Class

The manufacturer must assign a software safety class to their product. These safety classes are according to possible side effects on the patient, resulting from a hazard that the software system can contribute to.

When a hazard can arise from the failure of your software system, you must assume the probability of the failure to be 100%. Therefore, you must always assume the worst-case scenario. If you cannot 100% guarantee that your software cannot cause serious injury or death, your software will be either class B or class C.

Information regarding the software safety class of each software system must be documented in your risk management file. A risk management file (RMF) is a file where you keep records of all of your risk management activities, including all documents, files and records produced during the risk management process.

The higher the safety class of your product, the more of the IEC 62304 criteria you will need to comply with. For example, for software class C, you need to document the design with enough detail to allow the correct implementation of each software unit. However, this is not a requirement for class A or class B.

---

Software Development Process

In this stage, we will tackle all of your software development planning. This section has 8 subchapters, which we'll break down into easy-to-understand chunks.

5.1 Software Development Planning

First, you must produce your software development plan. Your software development plan is a document containing highly-detailed descriptions of all of the processes used in order to create your medical device software. It is also allowed, and even recommended, to have multiple development plans for different systems in the medical device.

It is important that you create an initial software development plan before you develop any software. If you do not have an initial development plan in place, regulators will not be convinced that you have considered factors such as risks, and the environment in which the software will be run.

Remember, it is important to keep your software development plan updated as development proceeds.

What should be included in your software plan:

• The processes to be used in the development of the software system
• The deliverables (including documentation) of the activities and tasks
• Traceability between system requirements, software requirements, software system tests, and risk control measures implemented in software
• Software configuration and change management, including SOUP configuration items and software used to support development
• Software problem resolution for handling problems detected in the software products
• The software life cycle model that will be used

5.2 Software Requirements Analysis

The software requirements analysis is very important in terms of traceability, and also offers significant benefits to your company.

Clear traceability means that errors are spotted early on. The earlier an error is discovered, the cheaper it is to fix it. This can save your company significant time and money. Performing software requirements analysis activities is also helpful in terms of disaster recovery.

As errors can be easily traced back to the requirements, this means that it will be easier to determine why something went wrong, how you can improve this, and how the product can be fixed.

This traceability element also comes in useful when your software is subject to audits. Auditors are focused on the risk to patients, and which requirements influence the risk to patients. As the software requirements analysis shows a clear trace of software items and requirements, this means that you can easily show auditors where in the software system that the risk originates, and how you make sure that the software doesn't make these errors.

For each software system of your medical device, you must define and document the software system requirements. These requirements should be re-evaluated and updated as appropriate.

The full list of requirements can be found in chapter 5.2.2 of the IEC 62304 standard. Additionally, there must be risk control measures implemented in your software to address any possible hardware failures, software defects, or human errors.

5.3 Software Architectural Design

Please note that this step is not required for Class A devices.

In the IEC 62304 standard itself, software architecture refers to: "the organisation and structure of your software system. It encompasses all of the fundamental components of your software, how they all interact with each other, how they were designed, and the environment in which they operate."

Manufacturers must take the requirements for their medical device software and transform these into a thoroughly-documented software architecture. In this software architecture, you must also document the interfaces between different software items, and between software items and any external components.

If a software item is classified as SOUP, you must specify the functional and performance requirements that are necessary for the intended use of the product. You must also specify the system hardware and software needed to support the operation of the SOUP item.

An example of SOUP is any kind of third-party software that has already been developed and was not initially designed for use in medical applications. Examples include operating systems (e.g. Windows, MacOS, Android), hardware drivers (e.g. Bluetooth drivers), software libraries (e.g. TensorFlow), and more.

Why are we required to list SOUPs?

Not listing SOUP items can lead to dangerous and even fatal situations. If sufficient documentation is not produced for a SOUP item, this can mean critical issues can be missed by your development team.

5.4 Software Detailed Design

Please note: for this section, there are more requirements for software Class C than there are for Class A and Class B.

Now, the manufacturer must refine their software architecture so that it is represented by software units. The design of each software unit should be properly documented.

Another thing that must be documented is the design of any interfaces between the software units and any external components (e.g. hardware or software) and also between other software units.

Your documentation must verify that your software detailed design:

• implements the software architecture;
• is free from contradiction with the software architecture.

An interface is a declaration of how two components will communicate. The interface documents how the communication will happen. These interactions can be between two pieces of software, or between software and external components.

5.5 Software Unit Implementation and Verification

Now, it's time to ensure your software units are successfully implemented and verified. As a manufacturer, you are responsible for developing strategies, methods and procedures for verifying each of your software units. These methods can include things like source code reviews and unit tests.

You are also responsible for setting out acceptance criteria for your software units — the set of conditions that a software unit must meet in order to be accepted by the user.

Here are 3 examples of acceptance criteria provided in the IEC 62304 standard itself:

• Does the software code implement the desired requirements, including risk control measures?
• Is the software code free from contradiction with the interfaces documented in the detailed design of the software unit?
• Does the software code conform to programming procedures or coding standards?

Additionally, you must add acceptance criteria if any of these features are present in your software design:

• Proper event sequence
• Planned resource allocation
• Data and control flow
• Fault handling
• Self-diagnostics
• Initialisation of variables
• Memory management and memory overflows
• Boundary conditions

Having thoroughly documented software unit implementation and verification has many advantages, including:

• Fewer bugs, which means your software is less likely to suffer from unexpected, potentially patient-harming problems.
• It helps software engineers to follow processes, as the documentation acts as a useful guidance tool for engineers.
• It helps you to create better documentation, because having clearly documented procedures makes it easier for engineers to create the level of documentation needed for your product.

5.6 Software Integration and Integration Testing

Next up, you will need to take the software units that you implemented and verified in the last step, and integrate these into your integration plan.

Your integration plan describes the process of integrating your software units into the larger software system. It ensures that all of your software units work together properly.

Your integration plan must verify that:

• The software units have been integrated into software items and the software system
• The hardware items, software items, and support for manual operations of the system have been integrated into the system.

When you go on to test your integrated software items, you will need to conduct this testing according to the integration plan, and document the results. Here are a few examples of what to consider during the testing stage:

• The required functionality of the software
• Specified timing and other behaviour
• Implementation of risk control measures
• Specified functioning of internal and external interfaces
• Testing under abnormal conditions including foreseeable misuse

5.7 Software System Testing

Now, we move on to the software system testing stage. This stage is vital, as it helps you to prove that all software requirements are covered.

You must establish and perform a set of software system tests, which take into account the following factors:

• Input stimuli
• Expected outcomes
• Pass/fail criteria and procedures

The goal of performing software system testing is to test the software system without external components. For software system testing, it is allowed to mock external devices. Any anomalies identified during the software system testing process must also be entered into the software problem resolution process.

It is incredibly important that retesting takes place when changes are made, in order to make sure the changes were effective. Furthermore, it is not only important to retest your software, but also to verify your testing procedures. And last but not least, you must keep thorough software system test records.

5.8 Software Release

Before your software is officially released, it is very important to make sure that all software verification has been completed and that the results have been evaluated. Any problems must have been documented properly, and these must be assessed to make sure that they do not contribute to an unacceptable risk.

Archive requirements:

• The software product and configuration items
• The documentation

How long these archives will need to be kept depends on factors such as the lifetime of your device and regulatory requirements.

What you must do when releasing your device software:

• Document the version of the software that is being released.
• Document the procedures and environment used to make the software.
• Ensure all activities and tasks are complete, including the associated documentation.

There are also other things that will need to be considered when releasing your product into the market. You will need to make sure you have procedures in place to ensure that your product can be delivered to the user without any corruption or unauthorised changes.

---

Software Maintenance Process

The first step of the software maintenance process is to establish your software maintenance plan, which contains plans for the maintenance process of your software. These range from procedures for documenting and resolving issues that occur after the release of the software, to procedures that evaluate and implement upgrades, bug fixes and patches.

At the problem and modification analysis stage, we monitor any feedback received about the released software product. This feedback may come from users, or from within your own organisation. All feedback must be documented properly, and evaluated to determine whether there is a problem or not. If a problem is identified, this must be recorded in the form of a problem report.

Problem reports should contain the following information:

• Actual or potential adverse events
• Any deviations from specifications

If it is determined that a change is needed to address the problem, then a change request will be made. A change request is a documented specification of what changes need to be made to a software product in order to address an existing or potential problem with the product.

Based on this analysis, manufacturers will need to approve or reject the change request. If approved, you must inform the users of the consequences of unchanged use. You also have obligations as the manufacturer to inform users and regulators about:

• Any problems in released software products and the consequences of continued unchanged use
• The nature of any available changes to released software products and how to obtain and install the changes

---

Software Risk Management Process

When building a software product, the importance of risk management should never be underestimated. In order to protect users and reduce harm, manufacturers must identify any potential hazardous situations and manage these accordingly.

You should consider potential causes of hazardous situations:

• Incorrect or incomplete specification of functionality
• Software defects in the identified software item functionality
• Failure or unexpected results from SOUP
• Hardware failures or other software defects that could result in unpredictable software operation
• Reasonably foreseeable misuse

You must also verify your risk control measures, and document this properly. When a risk control measure is implemented as a software item, you must evaluate the risk control measure in order to identify any possible new sequences of events that could lead to a hazardous situation.

You must also apply this same process to any SOUP items you may have used. If a hazardous situation is identified to be caused by SOUP, you must then evaluate the anomaly list published by the SOUP item supplier to determine whether any anomalies have led to a chain of events that has resulted in a hazardous situation.

For any change to your medical device software, you must perform an analysis to determine if additional potential causes contributing to a hazardous situation are introduced, and if additional software risk control measures are required. You should do an initial risk assessment at the beginning, and then each time you make a change, you should do a risk assessment of the change.

---

Software Configuration Management Process

As a manufacturer, you will need to establish a scheme for the unique identification of configuration items, as well as controlling their versions.

When it comes to SOUP, each configuration item being used must have the following information documented:

• The title
• The manufacturer
• The unique SOUP designator

Configuration items must only be changed in response to an approved change request. The change should be made exactly as specified in the change request.

Changes must then be verified. You must also repeat any verifications that have been invalidated by the change. With changes, there must always be traceability — you must produce an audit trail for any changes, including:

• Change request
• Relevant problem report
• Approval of the change request

As a manufacturer, you must also keep records of the history of controlled configuration items, including the system configuration.

---

Software Problem Resolution Process

Now we've reached the final section — the software problem resolution process. This is where you address any problems identified in your medical device software. This is an extremely important step, and if it is not handled properly, you could miss something that could cause harm to users of your medical device software.

A problem report is a record of actual or potential behaviour of a software product that a user or other interested person believes to be unsafe, inappropriate for the intended use, or contrary to specification.

For each problem identified, you must prepare a problem report, classified according to:

• Type
• Scope
• Criticality

Before you tackle the problem itself, the problem needs to be properly investigated, and if possible, the causes need to be identified. Then, using your software risk management process, you must evaluate the problem's relevance in terms of safety. The outcome of this investigation and evaluation must be thoroughly documented.

After this has been done, the next step is to create a change request for actions needed to fix the problem. It is essential that relevant parties are informed about the problem with the software. You must keep detailed records of the resolution and verification of all problem reports and their solutions, and update your risk management file as appropriate.

These records should be analysed to detect any possible trends in problem reports. Finally, you must determine whether:

• The problem has been resolved and the problem report has been closed
• Adverse trends have been reversed
• Change requests have been implemented in the appropriate software products and activities
• Additional problems have been introduced

---

To summarise

Why is it important to adhere to IEC 62304?

IEC 62304 is the gold standard for medical software development, covering the safe design and maintenance of medical device software. Being IEC 62304 certified helps you gain the trust of your customers, as it reassures them that your product meets the highest safety standards — something that is extremely important in the medical device software field.

The stringent QMS requirements of IEC 62304 also reassure customers that you are committed to making continuous improvements to your products, and that any problems will be dealt with quickly. Likewise, the risk management aspect of IEC 62304 reassures users that any risks are dealt with in a timely manner.

Also, as IEC 62304 is harmonised internationally, it means your product will be recognised by regulatory authorities worldwide. This vastly improves the overall marketability of your medical device software product, and makes it easier to enter international markets.

---

Attachments

Attachment 1: Process overview

In this figure, you can see exactly how chapters 5 through 9 can be visualised for your understanding. Although the figure below visualises the activities in a waterfall model, there is no strict requirement that states you need to perform the activities in a particular order. As long as the activities are sufficiently documented and you can show it will result in a quality product, you can perform the activities in any order you like.

Attachment 2: Requirements table

In this table, you can find an overview of all the IEC 62304 requirements, according to the amended 2015 version, for each of the 3 software safety classes.