IEC 62304: Software Life Cycle Processes for Medical Devices

IEC 62304 specifies processes and activities that you must observe when developing software as a medical device. It sets out specific requirements for how you must develop and maintain your software. This applies both to standalone software (e.g., medical apps) and to software that is part of a medical device (e.g., embedded software).

If you want to develop a medical app or medical software for the European market, it is difficult to ignore the IEC 62304 standard. And that’s a good thing: IEC 62304 is a useful tool for demonstrating the conformity of your software-based medical device with the MDR (Medical Device Regulation) or MDD (Medical Device Directive).

If you are planning to develop a medical app or medical software, you will find a guide here that takes you step by step through all the contents of IEC 62304. There are many articles on IEC 62304 on the internet, but most of them only cover one aspect. As a manufacturer, it is therefore difficult to get an overview of everything that needs to be taken into account. This article aims to give you a complete picture. We go through each section of IEC 62304 and summarize it in an understandable way with illustrative examples.

1. Overview of IEC 62304
2. Scope (1.), Normative references (2.) and Definitions (3.)
3. General requirements (4.)
- 3.1 Software security classification (4.3)
4. Software development process (5.)
5. Other processes of IEC 62304
6. Other important standards
7. Conclusion

1. Overview of IEC 62304

According to MDR/MDD, software/apps that serve a medical purpose are regulated medical devices (read here to find out if this applies specifically to your software). Under the Digital Care Act (DVG), your digital health application (DiGA) must even be a medical device.

IEC 62304 can be used for regulated medical device software to demonstrate compliance with requirements such as those of the MDR or MDD. The application of the standard within the framework of the MDR/MDD is theoretically voluntary. You are not legally obliged to do so. However, demonstrating compliance with the requirements of the MDR/MDD without such a standard is difficult and will ultimately probably require more effort and persuasion on the part of the auditors. If you manufacture software/apps as medical devices, it is therefore advisable to make use of IEC 62304.

The aim of IEC 62304 is to ensure that the developed medical app or medical software is implemented within a well-thought-out process. This involves avoiding issues that are often encountered in other software projects, such as:

Changes to the software are implemented without sufficient testing
Implications of certain software functions are not examined for risks. The implications only become clear when used by real users.
There is no well thought-out software architecture. Subsequent changes therefore usually lead to unexpected problems.
Due to a lack of documentation and an unstructured way of working, developers no longer understand the code themselves. They therefore make more mistakes during development.
The software versions are not maintained within a versioning system. It is therefore very difficult to subsequently determine which change caused a particular error. It is not possible to reset the software to previous versions.
Software requirements are not planned. The developers implement the wrong functions and do not implement them in the interests of the user. In the end, the product does not fulfill its intended purpose.

These are just a few example scenarios that IEC 62304 attempts to prevent.

It is also important to note that you must purchase the standard (as well as other ISO/IEC standards). You can purchase the standards from Beuth, iso.org, or, significantly cheaper, from evs.ee (approx. 10% of the price compared to Beuth/iso.org).

To give you an overview of all the contents of IEC 62304 in advance, here is the table of contents of the standard at the top level:

Application area
Normative references
Terms
General requirements
Software development process
Software maintenance process
Software risk management process
Software configuration management process
Problem-solving process for software

In the following chapters, we summarize each of these sections and the associated requirements concisely for you.

2. Scope (1.), Normative references (2.) and Definitions (3.)

The main body of all requirements in IEC 62304 is preceded by three short chapters:

The first chapter specifies the scope of IEC 62304. In summary, the standard applies to the development and maintenance of medical device software. The software can either be a stand-alone medical device or an embedded component of another medical device (e.g., embedded software).

The second chapter contains normative references. Normative here means that the referenced documents are required for the application of IEC 62304. Only ISO 14971 (Risk management of medical devices) is mentioned here. More on this later.

The third chapter defines the most important terms used in IEC 62304. These are important for the correct interpretation of the standard. For example, what distinguishes an “activity” from a “process” may not be clear to every reader (process = series of connected activities that convert inputs into outputs).

3. General requirements (4.)

Before we look at the core aspect of IEC 62304, the software development process, we should take a look at the so-called general requirements.

The manufacturer must …

… operate a quality management system. This can be demonstrated, for example, by applying ISO 13485 (standard for quality management systems for medical devices). (4.1)
… apply a risk management process in accordance with ISO 14971. (4.2)
… assign a software security class (A, B or C) to each software system (4.3)

With regard to the quality management system and the required risk management, you should take a look at the respective referenced standards (ISO 13485 and ISO 14971). We do not cover these standards in this article.

We will address the highly influential issue of software security classification here:

3.1 Software security classification (4.3)

You must assign a safety class (A, B, or C) to each software system. Depending on the safety class, IEC 62304 requires more (safety class B or C) or less (safety class A) from you and your processes.

In a sense, you are free to decide how many systems you want to divide your software into. For simplicity’s sake, many medical apps consist of only one software system. However, if, for example, your application has a non-safety-critical part and a very safety-critical part, you could set up a Class A software system and a Class C software system for each of these parts. These systems must, of course, be technically separate and independent of each other.

The classification rules are summarized concisely in the following figure. If in doubt, please refer to the relevant section (4.3) of IEC 62304.

Decision tree for software safety class according to IEC 62304: Click to enlarge

4. Software development process (5.)

The central content of IEC 62304 is the requirement for a defined software development process. This process consists of a number of activities, which we explain in more detail here.

The required activities are shown in the following figure:

Software development process according to IEC 62304: Click to enlarge

The software development process therefore consists of the following core activities:

Software development planning (5.1)
Analysis of software requirements (5.2)
Software architecture design (5.3)
Detailed software design (5.4)
Implementation of software units (5.5)
Software integration and integration testing (5.6)
Software system testing (5.7)
Software release (5.8)

It quickly becomes apparent that this process is strongly based on the V-model of software development. However, it is important to note that IEC 62304 does not explicitly require a specific process model during software development. Manufacturers are free to choose whether to use a V-model, agile development, or the waterfall model.
In the V-model, you would distribute the activities mentioned above over the entire development period of the medical app. In agile development, for example, each sprint would include the activities mentioned (at least some of them). Each sprint would then be its own small V.

In the following sections, we provide an overview of each of the activities mentioned:

4.1 Planning software development (5.1)

You need to create a software development plan. This plan basically describes how exactly the software development is to be carried out. The software development plan describes the following points (or references them in other documents):

Software development processes
Results and documents to be provided
Description of traceability between requirements, checks and risk control measures (keyword: traceability)
Configuration and change management
Troubleshooting and solutions
Software integration and integration testing
Software verification
Software risk management
Documentation

It is therefore a kind of manual for the entire software development process.

4.2 Analysis of software requirements (5.2)

You must document all requirements for your software. This includes functional requirements as well as non-functional requirements. More specifically, you must document the following, among other things:

Functionality and performance requirements
Software system inputs and outputs
Interfaces between the software system and other systems
Software-controlled alarms, warnings and user messages
Data security requirements
User interface requirements
Data definition and database requirements
Installation and acceptance requirements
Operation and maintenance requirements
Requirements regarding IT network aspects (e.g. handling when network is not available, network protocols, etc.)
Regulatory requirements
Inclusion of risk control measures (to reduce or eliminate identified risks)

These points may also overlap with each other. All documented software requirements must be verified (after implementation). Verification can be summarized as checking whether all requirements are fulfilled. To this end, all requirements must be formulated in such a way that a check is possible using defined test criteria.

4.3 Software architecture design (5.3)

Within software systems of security class B or C, you must document the planned software architecture before implementation. This also includes interfaces between individual software components and, for example, external systems. You can do this graphically using UML or C4, for example. You can describe the software architecture itself using UML class diagrams and individual core processes using sequence diagrams, for example.

Medical apps and medical software rarely function without dependencies on external software packages (e.g., for displaying or storing data). These software packages (or software components) are referred to as SOUP (Software Of Unknown Provenance). Such components were not normally developed by your own team and were not documented within a suitable quality management system. You must therefore define the functional and performance requirements for the SOUP component yourself. Specifically, you write a list of all dependencies and specify for each dependency whether and how you have checked it. How detailed you need to be depends on the security class of the system.

Finally, you must also verify the software architecture and, for example, prove that it implements your software requirements.

4.4 Detailed software design (5.4)

Software design is not design in the sense of the user interface (user input/output), but rather documentation of the software units at a technical level (similar to software architecture). In contrast to software architecture, which maps the software components, detailed software design shows all software units and their relationships to each other. Software design therefore exists at a lower level of abstraction and is thus more detailed.

In contrast to a software component, a software unit is defined as a “non-subdivisible” unit. A software component can consist of several software units. A software system consists of software components. As a rule of thumb, it could be defined as follows:
Software system ≥ Software component ≥ Software unit

This design must be detailed enough to enable correct implementation. It must also, of course, be in harmony with the software architecture and free of contradictions.

4.5 Implementation of software units (5.5)

After detailed documentation of the above points, we finally come to the part that every software developer has been waiting for: the actual implementation of the software units.

For software systems in security classes B or C, all software units must also be verified individually and acceptance criteria must be defined. For verification, you can also refer to your coding standards (coding guidelines). These define, for example, the maximum number of lines of code you allow per software method and software class (to ensure clarity), the unit test coverage to be achieved, and other programming language-dependent regulations. A tool for static code analysis (in combination with a linter that immediately flags violations in the code for the developer) is a good way to check compliance with your coding standards.

Code reviews are also ideal for checking compliance with requirements, acceptance criteria, and software metrics. One developer reviews another developer’s code before release (or before each “Git merge”) and leaves comments with suggestions for improvement. These comments are ideal for providing written proof of compliance with IEC 62304 processes. This is usually done using code review functionalities on GitHub, GitLab, or Bitbucket, for example.

4.6 Software integration and integration testing (5.6)

After implementing the individual software units, they must of course be integrated into the same system. For software systems in security classes B or C, you must integrate them into the overall system according to a documented integration plan. You must then check whether the integration was successful or whether any problems arose, for example.

Specifically, this can be done either through manual testing, e.g., by a QA expert (the title is not important), or through automated integration testing within the software itself.

4.7 Testing the software system (5.7)

You must define and perform a series of tests that cover all software requirements. To do this, you specify input values and expected output values, set pass/fail criteria, and describe your software system testing procedures in general terms.

These tests can, of course, include both manual (human) tests and automated tests (UI tests, integration tests, unit tests, etc.) of any kind.

At the same time, these tests must be documented in such a way that they can be repeated. To do this, you must document your hardware and software configuration, testing tools, and the version of the tested software during the test. It is also advisable to document the test steps to ensure repeatability.
This could look like this, for example:

Open the app – Expected result: Start screen with “Measure” button is visible
Click on the “Measure” button – Expected result: the camera opens. The “Record” button is visible.
Click on the “Record” button – Expected result: A loading bar opens.
…

You can either document such test procedures in Word documents or use tools such as Jira (each ticket is a test case) or TestRail.

4.8 Software release (5.8)

Once the software has been successfully verified, it can be released. It is compiled into an executable format. Any remaining anomalies are documented. The finished software is archived together with the associated documentation and is ready for delivery. From a pragmatic point of view, one folder for each new released version is sufficient: source code, compiled executable code (e.g., as an APK file for Android systems), and all build tools required to recreate this executable software version (e.g., the installation file for the specific version of the development environment).

When delivering to your users, you must ensure that no unwanted changes/falsifications of the software can occur along the way. For software, this primarily implies security measures to prevent hackers from manipulating your finished software release (and thus, for example, introducing malicious code).

It may, of course, be the case that your software and quality management system must first be reviewed by a notified body, e.g., within the framework of the MDR, before being released to users. This depends on the legislation in your target markets. IEC 62304 is independent of this and only suggests a process that you can implement to demonstrate conformity.

If your product is already on the European market, for example, you must decide whether each change is “significant.” If it is a “significant change,” your notified body must approve the change before it can be released. However, this requirement is part of the MDR and MDD, and not part of IEC 62304.

5. Other processes of IEC 62304

The software development process is by far the most comprehensive part of IEC 62304, but you also need to set up four other processes: for software maintenance, software risk management, software configuration management and problem resolution. We will briefly discuss each of these processes below:

5.1 Software maintenance process (6.)

A software maintenance process must be defined for the operation of the software. To do this, a software maintenance plan is first drawn up. This describes how feedback from users or other parties should be handled after the medical app or medical software has been released. For example, criteria are defined for when feedback should be considered a problem. In the event of a problem, the problem-solving process is used.

In addition, every change request to the software must be analyzed and approved. Once the change has been approved, it is implemented as usual using the software development process.

During software maintenance, a defined risk management process continues to be used (see below). Every change goes through risk management and is examined for potential hazards.

You can find an overview of the software maintenance processes and activities here:

Software maintenance process according to IEC 62304: Click to enlarge

As you can see, the software maintenance process is merely a slight modification of the software development process.

5.2 Software risk management process (7.)

The only other standard required by IEC 62304 is ISO 14971. This describes risk management for medical devices. In summary, you must therefore examine your medical software for potential hazards (= sources of damage) and hazardous situations. The associated risk must be assessed. On this basis, an evaluation is then made as to whether a risk is acceptable or whether it needs to be reduced, for example, by means of risk control measures. ISO 14971 also applies to hardware medical devices and therefore does not explicitly address issues related to software. IEC 62304 mainly refers to ISO 13485 for this process and does not impose any significant additional requirements.

Here you can see an overview of all processes and activities within the scope of risk management according to ISO 14971:

Software risk management process according to ISO 14971: Click to enlarge

As part of risk management, you will then, for example create a failure mode and effect analysistable (FMEA) or perform a fault tree analysis (FTA).

5.3 Software configuration management process (8.)

This process defines how changes and approvals are controlled and logged in the software.

This can be done, for example, using a software versioning tool such as Git. Changes are recorded as individual “commits” (change packages), and approved versions are marked as such (e.g., with a “release” tag). This section also requires that the system configuration and possible SOUPs be systematically documented.

DThe second part of the process deals with change control. Any changes may only be implemented after prior approval of a corresponding change request. In this context, you must identify all activities that need to be repeated when changes are made. These can be steps in the software development process or the software security classification of the software systems.

5.4 Problem-solving process for software (9.)

For every new problem you identify in your medical software, you must create a problem report. This report should include, for example, an assessment of how critical the problem is, as well as any information that could help solve the problem (e.g., affected devices or instructions for reproducing the problem).

In addition, you must identify the causes of each problem wherever possible. Risk management is restarted for the problem. And finally, a change request is submitted to solve the problem. After this change request has been implemented, it must of course be verified again:
Has the problem been solved or does it persist? Has this caused additional problems?
You must ask yourself such questions after every change request.

6. Other important standards

This was an overview of all sections of IEC 62304. If you want to bring a medical software or app to the European market, you should also take a look at the following standards:

IEC 62366 (suitability for use)
ISO 13485 (quality management)
ISO 14971 (risk management)
IEC 82304 (Health software product safety – useful extension of IEC 62304)

You can also find out more about these standards in our guide to the development of medical apps.

7. Conclusion

IEC 62304 basically requires many sensible things that a good software team should already be doing anyway. Nevertheless, a team will have to be prepared to create significantly more documentation and records than with conventional “non-medical device” software. Many software developers are also not used to working according to very strictly defined processes. Developing medical software in accordance with IEC 62304 therefore entails far-reaching changes. If you are also planning to integrate artificial intelligence (AI), you should take this into account in your software life cycle (more on this in our AI guide).

In this article, we have attempted to provide you with a comprehensive overview of all aspects of IEC 62304. This overview is essential when you begin to explore the development of medical software. Further requirements for the development of software as a medical device can be found in our guide to developing medical apps. If you are planning a digital health application (DiGA) within the framework of the DVG, you will find all the requirements in our guide to DiGAV.

IEC 62304: Software life cycle processes for medical devices

Table of contents