Medical software certification – a guide for managers
Contents
Are you in the process of developing medical software? If so, you should learn about the medical software certification in the European Union. In today’s article, we will describe this procedure step by step.
TL;DR
In the following article, you will find a guide to medical software certification or – to use more professional language – a guide to the conformity assessment of the medical device software according to the MDR (Medical Device Regulation) and its successful placing on the EU market.
We start with the definition of the medical software and the MDR. Next, we describe all the steps of getting your medical software certified, such as writing down the intended purpose, classifying a medical device, conducting a clinical investigation, preparing Technical Documentation and going through the conformity assessment with the assistance of the so-called notified body.
In the article, you will also read why going through the conformity assessment process might be a good idea and what challenges you might meet during this time. Don’t worry – we will also propose some solutions to them.
What is medical software?
Medical software (or medical device software) is software “intended to be used alone or in combination for the purpose specified in the definition of a medical device”. Basically speaking, medical software is used for medical purposes such as diagnosing, treating, and alleviating a disease. Think about an app that helps people regain their abilities through exercise after a stroke.
When you read about medical software, you can come across two terms – software as a medical device (SaMD) and software in a medical device (SiMD).
SaMD is a Software as a Medical Device, meaning it is a standalone product, without being part of a hardware medical device. It can be an app which helps children with ADHD with their attention or a dietary app for people with diabetes.
On the other hand, there is SiMD – Software in a Medical Device, which is software used to operate the medical product (i.e. to run the hardware). For example, it can be software which works inside a glucometer.
In the MDR, you will find information on “medical device software” (MDSW) which includes both SaMD and SiMD. Today, we will talk about SaMD; however, in this article, we will primarily address it as medical software or medical device.
What regulates the medical software certification process?
Medical software is regulated by the Medical Device Regulation (MDR) – EU 2017/745. It’s an act valid in the European Union, which governs the requirements for manufacturing and placing medical devices on the EU market, including medical device softwares. In one of our articles, we write more about MDR's consequences for healthcare software development.
Another important document you might want to check out is MDCG 2019-11 (The Medical Device Coordination Group), the “Guidance on Qualification and Classification of Software in Regulation”. In this guidance, you will find crucial information on assessing whether your application meets the definition of medical device software and how to classify it based on the rules of MDR.
Take notice
MDCG has created many documents offering guidance for people interested in going through medical device assessment. You can find all of them here.
Do you need to CE mark your medical software?
If you want to sell your medical software as such, you have to go through the conformity assessment procedures described in MDR to mark your application with “CE” (Conformité Européenne). CE marking informs your clients and other stakeholders that your product is safe to use and meets EU requirements for medical devices. In other words, CE is your obligatory ticket to sell your app in EU countries.
There are a few questions you can answer to learn whether or not you should go through the CE marking process. To name some of them – is your app beneficial to the individual patients?; is it intended for diagnosis or treatment? You can find a flowchart with all the important questions here.
The crucial question is – what’s the intended purpose of your app? If its goal isn’t medical, there is no need for marking it with CE as a medical device. For example, not all the apps used to track daily sports activities are medical and should be considered medical device software.
What does the medical software certification process look like?
Placing ready medical device software on the market and its successful conformity assessment is a long process because the EU obliges the manufacturer to ensure that their medical device is safe for users and clinically effective.
Despite the demanding, long list of requirements, you shouldn’t worry. We will describe every step so you can go through the assessment process swiftly.
What is the intended purpose?
The first thing you will have to do is establish your medical device's intended purpose. What does it mean?
When you read about the certification of medical devices, you will come across the term “intended purpose”, which – according to the MDR regulation – means “the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales material or statements and as specified by the manufacturer in the clinical evaluation”.
Uf! That was quite an extended definition. In simpler terms, you should write down what your medical software can do to diagnose, treat or monitor a disease. What’s more, the intended purpose includes the definition of people who will use your medical software and a description of the environment in which this medical software will be used.
Remember
In the MDR regulation, you will find the term “intended purpose”, but yet some people use the term “intended use”, which is not used in the MDR. However, MDCG guidance 2020-6 explains that both concepts have the same meaning.
Classification of the medical software
Now that you have written down the intended purpose of your medical software, you will have to establish which class your medical software belongs to.
There are four classes of medical devices:
Class I (self-declaration),
Class IIa,
Class IIb,
Class III.
The explanation is simple – the higher the risk of using medical software, the higher the class. MDCG has created 22 rules for the classification of medical devices; however, in terms of standalone medical device software, we will focus on Rule 11.
Which class is medical device software?
First, we need to return to the SaMD and SiMD distinction. If the medical device is a SiMD, then it should be in the same class as the product in which it’s embedded. On the other hand, if you have created a SaMD, you must check out Rule 11, which concerns medical software.
We describe Rule 11 in detail in our separate article, which we encourage you to read. Here, we will only speak about this promptly.
Although there are chances of creating software of Class I, it’s hard to find an example of software that is considered Class I. Thus, it’s likely that your medical software will be of Class IIa, IIb or III.
Where does your medical software belong?
Class III – medical device software which can lead to “death or an irreversible deterioration of a person’s state of health”,
Class IIb – medical device software which can lead to “a serious deterioration of person’s state of health or a surgical intervention”,
Class IIa – “software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes”,
Class I – all other software (source: MDCG).
Developing medical software and clinical investigation
The next step is to plan manufacturing your device. You know the best way of doing so, but if you want to read more about the process of creating SaMD, we highly recommend reading our article on the medical software development process.
What happens after that? It’s time for clinical evaluation and maybe even clinical investigation.
What is the clinical investigation? It means “any systematic investigation involving one or more human subjects, undertaken to assess the safety or performance of a device”. We understand the clinical investigation as a clinical trial or clinical study.
What’s more, you are obliged to perform a clinical evaluation, which is a “systematic and planned process to continuously generate, collect, analyse and assess the clinical data pertaining to a device in order to verify the safety and performance, including clinical benefits, of the device when used as intended by the manufacturer”.
In other words, clinical evaluation should be a critical opinion based on the relevant scientific literature, results of performed clinical investigations and/or consideration of alternative treatment options relating to the safety, performance, design characteristics and intended purpose of your medical device.
It should be based on the data available for the so-called “equivalent” device. The details on the term of “equivalence” can be found in the guide for manufacturers and notified bodies (MDCG 2020-05).
There can be no need for clinical investigation for some of the low and medium-risk devices, and clinical evaluation will be sufficient to prove the clinical effectiveness and safety of your medical device. However, you should remember that clinical evaluation can sometimes lead to the need of clinical investigation – especially if there is little to no data on the equivalent device already placed on the market.
Through clinical evaluation, you want to establish clinical performance, which is “the ability of a device, resulting from any direct or indirect medical effects (...), to achieve its intended purpose as claimed by the manufacturer”. Moreover, the clinical performance should lead to clinical benefit, which is “the positive impact of a device on an individual's health”.
The result of the clinical assessment (and maybe additional investigation) is the CER – Clinical Evaluation Report, one of the most important parts of the Technical Documentation.
MDCG has created a Q&A on the clinical investigation, so if you have some questions after reading this part, you might find answers there. What’s more, in the MDR, Chapter IV, you will find all the necessary information on the specific situation of conducting clinical evaluation and clinical investigation (such as conducting clinical investigation on minors).
What is the Technical Documentation in the process of the medical software certification?
One of the crucial and mandatory steps of the conformity assessment process is preparing the Technical Documentation.
Technical Documentation (sometimes called Technical Files) is a list of documents required from the manufacturer when attempting to get a CE mark. The list is complex; however, it is necessary to maintain the highest levels of the app's safety. So what does conclude to the Technical Documentation?
Device description and specification, including variants and accessories
“Device description and specification” includes information such as product name, general description of the device, the intended patient population and medical conditions to be diagnosed, and description of the key functional elements or raw materials incorporated into key functional elements.
You should also include some information regarding previous and similar generations of your device. which will concern you if you are trying to place on the market a newer generation of your device.Information to be supplied by the manufacturer
This section concerns a demand for the set of labels on the device and its packaging. What kind of labels? Single unit packaging, sales packaging, etc. Moreover, you should provide instructions on using the app in the languages accepted in the Member States where the device is planned to be sold.Design and manufacturing information
In this part, you should prepare information on the design stages of the medical software. Also, you are supposed to include information on suppliers, sub-contractors, and other companies and places, where design and manufacturing were performed. To sum up, a manufacturer describes a manufacturing process, including information on people engaged in it.General safety and performance requirements
In Annex I to MDR, you will find general safety and performance requirements (GSPR) information. Meaning a manufacturer is obligated to prepare a risk management system.
In this part of the Technical Documentation, you are supposed to describe conformity with GSPR, such as general safety and performance requirements that apply to the device, methods used to demonstrate conformity with each GSPR and more.Benefit-risk analysis and risk management
Annex I also includes information on the benefit-risk analysis, the solutions adopted, and the risk management results. In this part of the Technical Documentation, you should refer to Sections 1, 3 and 8 or Annex I.Product verification and validation
The final part of the Technical Documentation should consist of pre-clinical and clinical data. However, it shouldn’t be only the results of tests regarding pre-clinical safety but also information on test design (such as protocols, methods, etc).
What’s more, your software might be a situation of “specific cases”; thus, we encourage you to read Annex II, point 6.2, where those specific cases are defined.
The requirements for Technical Documentation can be found in the MDR Annex II.
Also, you should prepare Technical Documentation on Post-Market Surveillance. What is this?
The manufacturer is obligated to prepare a plan which will include among other things:
“proactive and systematic process to collect information such as information concerning serious incidents, trend reporting, publicly available information about similar medical devices, and more”,
“effective and appropriate methods and processes to assess the collected data”,
“effective and appropriate methods and tools to investigate complaints”,
“methods and protocols to communicate effectively with competent authorities, notified bodies, economic operators and users”,
and more (source: MDR).
You will find a full list of Technical Documentation on Post-Market Surveillance in the Annex III.
Do you need ISO 13485 to go through the conformity assessment?
During the conformity assessment, you must prove you have successfully introduced in your company a Quality Management System (QMS). It is necessary for every medical device that is about to go through the conformity assessment.
ISO 13485 is an internationally recognised standard for preparing a QMS for medical devices (including medical software). Having QMS in your company will assure users that your product is safe and of the highest quality. And when there are changes – it provides information that your product will be ISO-compliant.
How to become ISO-compliant and certified? You can read more about this in our article on this topic.
What other standards should you meet?
When developing medical software, you should also consider IEC 62304, an internationally recognised standard that ensures that the software is safe and effective. This standard requires you to prepare a plan for developing your medical software and maintenance activities.
What’s more, you should read about the IEC 62366, which specifies “a process for a manufacturer to analyse, specify, develop and evaluate the usability of a medical device as it relates to safety”. What does it mean? The aim of the IEC 62366 is to minimise the risks of usage errors by patients.
We recommend manufacturing medical software compliant with IEC 62304 and IEC 62366. By meeting the requirements set by these standards, you will ensure a more straightforward medical device certification process.
How to go through the conformity assessment?
You are halfway through the process! You have already done much work, which will make your medical device CE-marked. So what do you do next? Well, now you have to go through the conformity assessment.
Conformity assessment means that you have to prove that your medical software complies with the MDR. Seems easy, right?
The conformity assessment rules are established in Annexes IX to XI.
Who conducts the conformity assessment?
There are two ways of going through this process. If your medical software is Class I, you will complete the self-assessment process. Thus, you will go through Annex IX (chapters I and III) and then Annex XI (part A). After preparing all the necessary documentation, you will prepare a declaration of conformity (Annex IV). And that’s it. However, as we already stated, in terms of medical software, it’s hard to have a medical device of Class I.
If you have classified your medical device as Class IIa, Class IIb, or Class III, then the “third party” (the notified body) must conduct the conformity assessment. The choice of the conformity assessment route is something you should include in the declaration of conformity (DoC). We will talk more about this document further on.
How to choose a notified body?
A notified body is an organisation the EU accredits to conduct a conformity assessment. However, not all notified bodies are responsible for all the devices. Thus, you should establish if your chosen notified body can conduct a conformity assessment of your medical software.
Also, we encourage you to read more about the company of your choice. What are the client’s opinions about them? What experience do they have? Have they ever conducted a conformity assessment for medical software? How long will it take for them to perform the evaluation? All information might be crucial when deciding to ask a notified body for conformity assessment.
You can find the list of notified bodies in the selected countries in the European Union here.
What does an audit by a notified body look like?
Depending on the medical device software class, the process will be slightly different regarding needed documentation. The flowcharts for all the conformity assessments for all the classes can be found here.
However, in general, the notified body will conduct two analyses. The first is the Technical Documentation audit, and the second is the Quality Management System audit. The role of the notified body is to analyse if the manufacturer has fulfilled the requirements established in the MDR.
What’s more, as we read on the website of one of the notified bodies, TÜV SÜD, when auditing, the notified body will go through all the information and report any deficiencies. Next, you, a manufacturer, will be responsible for addressing them.
By the end of the process (if successful), the notified body issues two certificates that will be valid for a maximum of five years. The first certificate confirms that the medical device manufacturing process complies with MDR requirements. The second certification, on the other hand, is issued for QMS and confirms compliance with ISO 13485.
The certificate includes:
unique number identifying the certificate,
date of issue,
date of expiry,
and more (source: MDR).
You can find all the information on certificates issued by a notified body in Annex XII of MDR.
What happens after the audit by the notified body?
After the notified body conducts a conformity assessment, some actions are required on your part: signing the declaration of conformity, final marking of the product with the CE mark and its registration, which allows you to place your medical software on the European market.
What is the declaration of conformity?
Declaration of conformity “states that the requirements specified in MDR have been fulfilled”.
According to Annex IV of MDR, it should include the following information:
“name, registered trade name or registered trademark,
a statement that the EU declaration of conformity is issued under the sole responsibility of the manufacturer,
the Basic UDI-DI (primarily identifier of a device model),
product and trade name, product code, catalogue number,
risk class of the device,
statement that the device is in conformity with the MDR,
references to any common specifications used and in the relation to which conformity is declared,
the name and identification number of the notified body,
place and date of issue of the declaration” (source: MDR).
Moreover, the declaration of conformity should be translated into an official Union language required by the Member States in which the device will be available.
Remember that the notified body also verifies the declaration of conformity issued by the manufacturer of the medical device during the audit, so you should have its template prepared in advance.
CE marking of conformity
After preparing the declaration of conformity, you can use the CE marking of conformity. This CE marking is placed in the visible place on the device or its packaging before the device is placed on the market.
What’s more, under the CE marking will be the notified body's identification number. You can find an example in the Annex V of the MDR.
Registration of the medical software
The final step is registering your medical software. In the future, the plan is for all the manufacturers to submit information in EUDAMED. This database will contain information on all the medical devices available in the European Union.
However, until it’s fully functional, according to the MDR, the European Commission doesn’t require you to put information on your medical software in EUDAMED.
So, where should you register your medical device? The place of registration depends on the country. Every member country of the European Union has a body responsible for keeping track of all medical devices. In Poland, it’s the Office for Registration of Medicinal Products, Medical Devices, and Biocidal Products.
The complete list of National Authorities and contact information can be found here.
What challenges might you come across when certifying your medical software?
We want you to go through the conformity assessment process as peacefully as possible. Thus, it would help if you learned about the challenges you might come across and what to do when facing them.
Going through the conformity assessment
Having CE-marked medical devices in your portfolio might not be easy if you don’t have the necessary knowledge about MDR requirements. Thus, we encourage you to read a lot about the conformity assessment process. The MDR is the best source of knowledge, so finding some time to analyse its content might be helpful.Maintaining the highest levels of security
Ensuring a high level of security in the age of widespread hacker attacks is not simple, but it’s achievable. When creating your medical software, make sure it stores data by the GDPR (General Data Protection Regulation), as well as ensure you protect your app against cybercriminals.Production and certification costs
For full disclosure – developing medical software and preparing its certification is expensive. Particularly given the length of these processes. Keeping your business running can be challenging, so we encourage you to schedule a detailed action plan for the coming years.
Where to start with the medical software certification?
After reading this article, you might wonder – where should I start to successfully bring my software as a CE-marked medical device to the market? We recommend some activities at the beginning of this challenging yet rewarding journey.
First of all, you should think about the team you have created. What kind of competencies do your employees have? What skills and knowledge do they possess? Also, think about who needs to join your team. Do you need to do additional recruitment before starting the conformity assessment?
Secondly, if you decide to outsource the software, it would be helpful to conduct some research. Analyse reviews and read case studies of similar projects done by the company of your interest. It will help you make the right decision about starting a cooperation.
Last but not least, don’t hesitate to ask for help from specialists who have spent years working with medical device conformity assessment. At Revolve, we have specialists in the Regulatory Affairs Team who help manufacturers like you prepare for the conformity assessment procedure.
Contact us if you want to discuss bringing your medical software to life. We will happily meet with you and prepare a plan for our potential cooperation.
