How do I actually decide whether my product is a medical device? Where do I start when I want to determine its risk class? And what statements can I use to promote my product in the end? The answers to these and many other questions can be answered on the basis of your intended use (or intended purpose) – which you as the manufacturer write yourself. This article provides you with practical instructions for creating your intended use in accordance with the MDR. We focus on software products such as mobile apps and web applications. However, the concepts and definitions are transferable to any other medical device.
Contents
- With 3 questions to the intended use
- Intended use – the foundation of your medical device
- Conclusion
Before you rush headlong into your new project, put together a development team and start thinking about marketing, let’s take a step back and start from the beginning: with the purpose. After all, you will only know what regulatory requirements you will face and how you can ultimately advertise your product once this has been finalized. The intended use lays the foundation for (almost) everything. At the very beginning of a software project, you can answer the most important question of all: is your app a medical device and do you therefore have to comply with the requirements of the Medical Device Regulation (MDR)?
Example
Suppose you want to develop an app that increases people’s physical agility by creating an individual training program based on user input. The training content consists of information about the musculoskeletal system and various stretching exercises. A possible (very simplified) intended use could be:
The app is intended to increase the mobility of healthy adults.
In this case, the software would not qualify as a medical device because it does not meet the definition of the MDR. Roughly summarized, it states that only apps that pursue a purpose in connection with an illness or disability are considered medical devices. These include diagnosis, therapy and compensation (you can find the exact definition in our article on the topic: Guidelines: Is your app a medical device?). According to this, the situation for your software changes if you slightly modify the intended purpose:
The app is intended to increase the mobility of people after a leg amputation and to develop strategies for compensating for the disability.
It can happen that fast! By changing a single sentence, you have turned your app into a medical device. This did not even require any changes to the software.
With 3 questions to the intended use
You do not need years of experience in the regulatory field to write a purpose statement. With sufficient expertise in relation to your product and your target group, you can write them on your own without much prior knowledge. However, it is best to have their intended purpose checked again by a regulatory expert at the end. The MDR defines the intended purpose as follows:
“Intended use” means the use for which a device is intended according to the manufacturer’s information on the labeling, in the instructions for use or promotional or sales material or promotional or sales information and its information in the clinical evaluation.
This definition gives rise to three questions that are central to the content of the intended purpose:
- “What should be on my product website?”: Put yourself in your end customer’s shoes and think about what information they need to clearly know that your product is suitable for them and what added value it can provide.
- “What promises can the product keep?”: Empty promises are taboo. Therefore, you may only mention those points that you can prove within the clinical evaluation.
- “What can’t the product do?” (if necessary): Sometimes it is also necessary to address the limitations of the product. This includes, for example, the information that a product can only be used once.
What the intended use does not contain
The MDR understands the intended purpose as part of the product description and specification (MDR Article 1, Annex II). In addition to the intended purpose, this also contains other points that are closely related:
- the intended patient group (e.g. ICD codes, demographic data, contraindications)
- the principles concerning the operation of the product and its mode of action (description of the functionalities and how the purpose is to be achieved)
Many manufacturers mix these points together. This is inevitable, as a strict separation of these topics is not possible. Nevertheless, the intended purpose should not go into too much detail about the patient group and the functionality of the product. The following questions can help you to differentiate:
- Intended purpose: WHAT is the purpose of the product?
- Patient group: WHO should use the product?
- Principles concerning the operation of the product and its mode of action: HOW does the product work and how should it fulfill its purpose?
How long must an intended use be?
Is it wrong to explain the patient group and the functionalities of the app in detail in the purpose statement? No, but it may be unwise. This is because an intended purpose can no longer be changed retrospectively without further ado. As a general rule, the purpose should be written as precisely as possible. The difficulty lies in separating relevant information from irrelevant information. After all, you will probably want to develop your product further and add features once it has been launched on the market. Certain adjustments may even be necessary to increase product safety. In these cases, it can be problematic if your intended purpose already explains how the app works in detail. The same applies if you subsequently want to expand your patient population or are forced to narrow it down. It is therefore an art to mention all relevant aspects in the purpose statement without going too far.
Note: There is no single correct way to formulate the intended purpose. The intended use of your product can take many forms, which are potentially permissible.
The length of the intended use depends very much on the product. It is as long as necessary to avoid misinterpretation, but should not describe the product in too much detail. Some purpose statements contain only two sentences, others are much more detailed. At this point, a few examples of existing medical devices will certainly help to give you some orientation.
Examples
Intended purpose for scalpel blades:
- “Sterile scalpel blades are intended to be incorporated into reprocessed scalpel handles. Sterile scalpels are intended for skin surface incisions (skin incision) on the human body.”
Intended purpose for a balloon catheter:
- “Balloon catheters are intended for routine or post-operative drainage of the bladder. The use of balloon catheters is only suitable for urological purposes. The products are approved for single use only and the recommended maximum retention time for transurethral silicone catheters is 30 days. The product may only be used by qualified specialist personnel.”
Intended purpose for DiGA:
- The intended purpose of all currently listed DiGA, which are also medical devices, can be found in the BfArM directory. If you are unsure whether your app is a DiGA, you can find the answer here: Is your app a DiGA? Definition criteria of digital health applications
Intended use – the foundation of your medical device
The MDR does not contain a specific list of contents that should be included in the intended purpose. However, the purpose is mentioned in many chapters and is listed as the basis for numerous activities within the software lifecycle. 
Figure 1: Areas of influence of the intended purpose according to MDR (no claim to completeness) The following are key points that are influenced by the intended purpose and must therefore be taken into account when formulating it.
Qualification as a medical device
The intended purpose must clearly indicate that the product has a medical purpose. According to the MDR definition, this includes the diagnosis, monitoring and prediction of diseases, as well as the compensation of disabilities. You can find the exact definition in this article: Guide: Is your app a medical device?
Risk classification of the medical device
Once you have qualified the product as a medical device, the risk class is evaluated. This article provides specific information on the correct risk class. To determine the risk class as clearly as possible, the intended purpose must be formulated with appropriate precision. Exclusions (purposes for which the product is not intended) can also be specified if necessary. This is the case if a different interpretation of the intended purpose could lead to a higher risk class.
Example of exclusion: The product does not provide any information to the attending physician and is not a diagnostic tool.
Therefore, you may also need to address certain functionalities of the software if these influence the risk class of the product. If misinterpretations are possible that change the risk class, discussions with the notified bodies or supervisory authorities are inevitable.
Note: If you want to develop a digital health application (DiGA), your product must fall under class I, IIa or IIb. So make sure that the product cannot fall under class III according to its intended purpose. Further information on DiGA can be found here, for example: Guide to the DiGAV: Digital Health Applications Ordinance
Risk analysis
As part of risk management, you must carry out a risk analysis for your product. The intended purpose also provides decisive input for this. The key question is how critical the tasks are that your product performs and how sensitive the area of application is. If your app is intended for the early detection of heart attacks, for example, malfunctions or incorrect use can cause serious damage. While an app to increase the ability to concentrate in ADHD patients is not expected to cause as much damage. The potential damage should be derived from the intended purpose so that it can be evaluated in the risk analysis.
Software safety class
If you are planning a software product, you will inevitably have to deal with IEC 62304. This standard can be used to assign your application to a software safety class. The fundamental question here is: “What is the extent of the damage that can occur if your software malfunctions or even fails completely?” Among other things, Software Safety Class describes how granularly your software must be tested during the development process and can therefore mean additional effort. Since the software safety class is often derived from the risk analysis, this classification is also related to your intended use.
Clinical evaluation and post-market surveillance
Only if a product also has a clear intended purpose, it can be shown in the course of a clinical evaluation that it also fulfills this purpose. The intended purpose therefore lays the foundation for the safety and performance requirements that are taken into account in the course of the clinical evaluation. In some cases, manufacturers want to avoid the expense of a clinical trial and therefore refer to “similar products”. A central point for the similarity of two products is an identical intended purpose (MDCG 2020-5). Find out more about clinical evaluation and the criteria for product equivalence here: MDR-Guide: Clinical Evaluation of Software Medical Devices. For more information on validation in general, you should read our article on this topic: Validation of medical device software according to MDR. If a clinical investigation is planned, it also depends on your budget which effects are to be demonstrated. Only performance characteristics for which there is evidence may be specified in the intended use. Data on the product is also collected in the post-market surveillance phase. The data to be taken into account is derived from the intended purpose (e.g. quality of life, duration of rehabilitation, etc.).
Conclusion
The intended purpose is the central element in the development of software as a medical device. Among other things, it lays the foundation for the following points:
- Qualification as a medical device
- Risk class & software safety class
- Risk analysis
- Clinical evaluation & post-market surveillance data
The purpose statement for your app should be written at the beginning of the development process if possible. Care should be taken to include all the necessary information, but not to go into too much detail. If you are planning a medical app or DiGA and need support with the development, please get in touch with us and we will discuss the whole thing together without obligation. We develop medical apps for companies and research institutions on a contract basis. Any further questions? Please feel free to call us (+49 (0) 89 54998380) or send us an email (kontakt@quickbirdmedical.com).
