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 places specific requirements on how you must develop and maintain your software. This applies both to stand-alone 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 avoid the IEC 62304 standard. And that’s a good thing: IEC 62304 is a useful tool for demonstrating the conformity of your software-supported 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 will take you through all the contents of IEC 62304 step by step. There are many articles on IEC 62304 on the Internet, but each article usually only covers one aspect. As a manufacturer, it is therefore difficult to get an overview of everything that needs to be considered. This article is intended to give you an overall picture. We will go through each section of IEC 62304 and summarize it in an understandable way with illustrative examples.

Overview of the IEC 62304 standard

A software/app that has a medical purpose is a regulated medical device according to MDR/MDD (read here whether this applies specifically to your software). Under the Digital Healthcare 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 the MDR or MDD. Use of the standard in the context 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 probably ultimately require more effort and persuasion on the part of the auditors. If you produce a software/app as a medical device, 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. The aim is to avoid things that are often found in other software projects, for example:

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 examples of scenarios that IEC 62304 tries to prevent. It is also important to mention that you have to buy the standard (like other ISO/IEC standards). You can purchase the standards e.g. from Beuth, iso.org or, much 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, you can see the table of contents of the standard at the top level here:

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

Scope of application (1.), normative references (2.) and terms (3.)

The actual main part of all the requirements of IEC 62304 is preceded by three short chapters: The first chapter specifies the application area 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 within 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 related activities that convert inputs into results).

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 according to 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). These standards are not covered in this article. The highly influential point of software safety classification is dealt with here:

Software safety 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. To a certain extent, you are free to decide how many systems you want to divide your software into. For the sake of simplicity, many medical apps consist of just one software system. However, if, for example, you have a non-safety-critical part and a very safety-critical part in your application, you could set up a class A software system and a class C software system for each. These systems must of course be technically separated and independent of each other. The classification rules are summarized in the following figure. If in doubt, you should take an additional look at the corresponding chapter (4.3) of IEC62304.

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

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:

It becomes apparent quickly that this process is strongly oriented towards 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. The manufacturer is free to choose whether to use a V-model, agile development or the waterfall model. In the V-model, the activities mentioned would be distributed over the entire development period of the medical app. In agile development, for example, each sprint would contain 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:

Software development planning (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.

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.

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 implement this graphically using UML or C4, for example. You can describe the software architecture itself using UML class diagrams, for example, and individual core processes using a sequence diagram, for example. A medical app or medical software rarely works 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 usually not developed by the company’s own team and were not documented within a suitable quality management system. You must therefore define 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 them. How detailed you have to do this depends on the security class of the system. Finally, you must also verify the software architecture and prove, for example, that it implements your software requirements.

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 depicts 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 therefore more detailed. In contrast to a software component, a software unit is defined as a “unit that cannot be further subdivided”. 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, free of contradictions.

Implementation of software units (5.5)

After detailed documentation of the points mentioned, now comes the part that every software developer has been waiting for: the actual implementation of the software units. For software systems of 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), for example. These define, for example, the maximum number of lines of code you allow per software method and software class (to ensure an overview), 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 highlights violations in the code for the developer) is ideal for checking compliance with your coding standards. Code reviews are also ideal for checking compliance with requirements, acceptance criteria and software metrics. A developer checks the other developer’s code before releasing it (or before each “Git merge”) and leaves comments with suggestions for improvements. These comments are ideal retrospective evidence to prove in writing that they are complying with the IEC 62304 processes. This is usually done with the help of code review functionalities on GitHub, GitLab or Bitbucket, for example.

Software integration and integration testing (5.6)

Once the individual software units have been implemented, they must of course end up in the same system. For security class B or C software systems, 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 problems have arisen, for example. Specifically, this can be done either by manual tests, e.g. by a QA expert (the title is not decisive), or by automated integration tests in the software itself.

Software system testing (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 generally describe your procedures for software system testing. These tests can of course include (human) manual tests as well as 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, test tools and the version of the tested software during the test, for example. It is also advisable to document the test steps to ensure repeatability. This can 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.

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 can be delivered. From a pragmatic point of view, one folder is sufficient for each newly released version: 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 of the specific version of the development environment). When delivering the software to your users, it must be ensured that no undesirable changes/corruptions to the software can occur along the way. In the case of software, this primarily implies security precautions so that hackers cannot manipulate your finished software release (and thus infiltrate malicious code, for example). Of course, your software and your quality management system may first have to be tested by a notified body before being released to users, e.g. as part of the MDR. This depends on the legislation of your target markets. IEC 62304 is independent of this and only suggests a process that you can implement to demonstrate conformity. For example, if your product is already on the European market, you must decide for each change whether it is “significant”. If it is a “significant change”, your notified body must approve the change before release. However, this requirement is part of the MDR or MDD and not part of IEC 62304.

Other IEC 62304 processes

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:

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 is to 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. A defined risk management process is also used during software maintenance (see below). Every change goes through risk management and is examined for potential hazards. You can see 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.

Software risk management process (7.)

The only other standard required by IEC 62304 is ISO 14971, which describes the risk management of medical devices. In summary, you must therefore examine your medical software for potential hazards (= sources of damage) and hazardous situations. The risk associated with these must be assessed. On this basis, it is then evaluated whether a risk is acceptable or whether it must be reduced, e.g. through risk control measures. ISO 14971 also applies to hardware medical devices and therefore does not explicitly address issues relating to software. IEC 62304 mainly refers to ISO 13485 for this process and does not make any significant additional requirements. Here you can see an overview of all processes and activities in the context of risk management in accordance with 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).

Software configuration management process (8.)

This process defines how changes and releases in the software are controlled and logged. This can be done using a software versioning tool such as Git, for example. Changes are recorded as individual “commits” (change packages) and released versions are marked as such (e.g. with a “release” tag). This section also requires that the system configuration and possible SOUPs are systematically documented. The second part of the process deals with so-called change control. Any changes may only be implemented after prior approval of a corresponding change request. Within this framework, you must identify all activities that need to be repeated for changes. These can be steps in the software development process or the software security classification of the software systems.

Problem-solving process for software (9.)

For each new problem that you identify in your medical software, you must create a problem report. This report will contain, for example, an assessment of how critical the problem is and any information that could help solve the problem (e.g. affected devices or instructions for reproducing the problem). You also need to identify root causes for each problem if possible. Risk management is re-initiated for the problem. And finally, a change request is made for the solution to the problem. Once 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.

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.

Conclusion

IEC 62304 basically requires many sensible things that a good software team should already be following 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 according to 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 lifecycle (more on this in our AI guide). In this article, we have tried to give you a complete overview of all points of IEC 62304. This overview is necessary when you start to deal with the development of medical software. Further requirements for the development of software as a medical device can be found in our guide to the development of 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 the DiGAV.

IEC 62304: Software life cycle processes for medical devices