If you are developing software that qualifies as a medical device under the Medical Device Regulation (MDR), validation is one of the most critical issues. Successful validation of your software is an absolute prerequisite for bringing your medical device to market.
But what exactly is meant by software validation? Which software needs to be validated at all? And what does this validation look like in practice? Our guide gives you concrete answers to all aspects of these questions.
Types of validation in relation to software medical devices
When we talk about “validation” in relation to software medical devices, this can refer to completely different things. We must therefore first fundamentally understand the context in which this term is used.
There are generally the following categories in which the term “software validation” is used:
- #1 Validation of the computer software used: Computer Systems Validation (CSV)
- #2 Validation of the software medical device itself
- #2a Validation of the intended purpose of your software medical device: clinical evaluation
- #2b Validation of the requirements of all stakeholders for the software medical device: User Needs or Stakeholder Requirement Validation
- #2c Validation of the usability of your software medical device according to IEC 62366
In most cases, “software validation” refers to either category #1 or category #2a. But of course it depends on the context. A holistic understanding of these aspects is therefore important. In the following, we go into all categories and explain them in detail.
#1 Validation of the computer software used: Computer Systems Validation (CSV)
In the context of medical device software validation, there is often talk of validating the computer software used. A manufacturer of an MDR medical device must validate computer software that is used within quality management.
This is further specified in ISO 13485 4.1.6: “The organization shall document procedures for the validation of the use of the computer software in the quality management system.”
The computer software used does not refer to your actual software medical device. This refers to any software tools used that have an impact on your quality management system or the safety or performance of your medical device.
We therefore also like to speak of “software tools” because it better expresses the difference to your actual software medical product and the libraries used. Important: Software libraries and frameworks that you incorporate into your software medical device are none software tools, but SOUP (Software of Unknown Provenance) in accordance with IEC 62304. These SOUPs do not have to go through the validation of the software tools, but are part of a separate SOUP evaluation process, which we will not explain in detail here. Find out more about SOUPs in this article: IEC 62304: Software life cycle processes for medical devices
Examples of relevant software tools that need to be validated could be
- Documentation software: Confluence, Word, Google Docs usw.
- Task management software: Jira, Todoist etc.
- Development environments (IDE) for your product: Xcode, Android Studio, WebStorm, Eclipse etc.
- Document storage software: Dropbox, Google Drive, OneDrive etc.
- etc.
The list of tools you use will be very long, as a lot of third-party software is used for the efficient development of modern software.
The good thing is that you don’t have to validate each of these software tools extensively. The validation process follows a risk-based approach. Accordingly, you focus on the software tools that have the greatest (indirect) influence on the quality of the product and patient safety. A malfunction in a version management system is therefore relatively serious because a user may receive an incorrect software version. A malfunction in an applicant management system, on the other hand, usually has little impact on product quality.
In a future article, we will describe in more detail how this tools validation works. Please register here for the newsletter if you would like to be notified:
#2 Validation of the software medical device itself
#2a Validation of the intended purpose of your software medical device: clinical evaluation
To place your software medical device (SaMD) on the market in the EU, you must validate that it fulfills its intended medical purpose. In order to do this, a so-called clinical evaluation of your medical device is necessary, among other things. The aim of this clinical evaluation is to demonstrate the clinical benefit of your product, which is defined in its intended purpose – this is known as “validation of the intended purpose“. Clinical evaluation can include, for example, a literature search and conducting your own studies.
However, before you can validate the intended purpose of your medical device, certain requirements must be met, as described in the next chapter.
Basic work to validate the intended purpose
The first step is to define the intended purpose of your product. This is of course the basis for their validation. You can find out exactly how to find and define the intended purpose of your medical device in our comprehensive guide: Phrasing of the intended purpose for (software) medical devices. Of course, you should also check whether your software with the stated purpose is a medical device at all in accordance with the MDR (see also our guide: Is your app a medical device?). If this is the case, the next step is to determine the risk class of your SaMD (see also our guide to risk classification according to MDR), as this has a strong influence on the design of the validation.
Clinical evaluation
After you have finished developing your software, it is time for the clinical evaluation or validation of your product. In this context, you prove that your product fulfills its intended purpose and is safe to use and does not pose any unacceptable health risks.
Let’s assume you have a product whose intended purpose is the treatment of severe depression. To do this, you would have to prove that the application/use of your software leads, for example, to the alleviation of depression symptoms. At the same time, you must prove that no unacceptable health risks arise from the application (e.g. suicide of the user due to incorrect treatment). Further information can be found in our comprehensive MDR guide: Clinical evaluation of software medical devices
#2b Validation of the requirements of all stakeholders for the software medical device: User Needs or Stakeholder Requirement Validation
In addition to the clinical evaluation of your product, you must identify and validate the requirements of the relevant stakeholders in accordance with IEC 82304. Stakeholders in a patient-centered application are e.g:
- Patients as the main users of the app
- Doctors who communicate with the patient via video chat in the app
- Content administrators who enter text, images and video
- Super administrators who operate user management
- Legal representatives (e.g. BfArM, the supervisory authority or notified body)
The terms stakeholder requirements, user needs and user requirements are usually used synonymously. Examples of stakeholder requirements can be divided into the following categories:
- Functional requirements (“As a user, I would like to carry out exercises in the app to improve my quality of life.”)
- Non-functional requirements
- Fulfillment of the medical purpose of the application
- Patient safety (health)
- Cyber security requirements and data security requirements
- Legal requirements, such as labeling (CE mark in the app with manufacturer information) for MDR products or the GDPR for data protection issues
- User-friendliness of the application
- etc.
Once all requirements have been identified and described in a structured manner, they must be validated at the latest after completion of the development. A validation plan must be drawn up and a validation report must be produced once the validation has been completed. This can look different for each user need. Some examples of the validation of stakeholder requirements could be
| Stakeholder requirement | Validation plan | Validation report |
| “As a user, I want to do exercises in the app to improve my quality of life.” |
|
|
| “As a user, I want my data to be stored and processed securely and thus protected against unauthorized access and manipulation” |
|
|
#2c Validation of the usability of your software medical device according to IEC 62366
For the successful approval of your software medical device, you must validate the usability of your software. The IEC 62366 standard defines specific requirements for this validation.
The design of an application’s user interface should therefore not only be appealing, but also help to avoid errors during use. One example would be an app for controlling an insulin pump: it must be clearly communicated to the patient which button triggers an insulin injection, as an overdose can even be fatal in the worst case.
IEC 62366, a standard for the usability of medical devices, deals with precisely this topic. Deaths from medical devices are often not due to technical malfunctions, but to poor usability and incorrect use. Usability engineering, i.e. ensuring usability, is also part of risk management. To ensure that a product is suitable for use, you may need to carry out a usability study as part of a summative evaluation.
Verification vs. validation
The distinction between verification and validation is a source of confusion for many manufacturers. To better understand the difference, there is a simple rule of thumb:
- Verification: “Has the product been implemented correctly?”
- Validation: “Has the right product been implemented?” or “Does the product fulfill its purpose and the requirements placed on it?”
The verification of the software medical device can be carried out, for example, through software system tests in which the result is compared with the clear product specifications. For example, you could check whether an app displays therapy recommendations as described in the requirements.
The validation , on the other hand, focuses on the effectiveness of the product and, in the case of medical devices, can be carried out through clinical studies, for example. For example, you could check whether the therapies recommended by an app actually alleviate the condition.
Conclusion on the validation of medical device software
When we talk about validation in the context of software as a medical device, we do not always mean the same thing. Validation is used in various application areas during the development of your medical product.
It is particularly important to understand the distinction between the validation of the software used and the validation of the software medical device itself.
As a rule of thumb, the more critical a software is for your quality management system, the more stringent its validation must be.
The intended purpose and stakeholder requirements play a central role in the validation of the medical software product itself.
The above overview will hopefully help you to better understand which aspects are relevant for the validation of software and how they work.
If you are planning medical device software, please get in touch with us (To the form). We specialize in the development of such products and implement your software in compliance with regulatory requirements.
