Nouveauté ! Développez votre produit SxMD avec un eQMS structuré comprenant des modèles SxMD prêts à être audités et conformes aux normes EU et US. En savoir plus !
Navigating Classification of Software as a Medical Device in the European Market
As in many other industries too, Software as a Medical Device (SaMD) solutions have become an integral part of the medical device industry. While the previous years and decades focused mostly on firmware and interfacing solutions, medical device software (MDSW) is now ubiquitous. From a technological standpoint, mobile applications, AR/VR solutions and machine learning supported medical devices are just a few examples of this growing domain. Almost every modern medical device integrates some kind of software, except for purely mechanical tools like scalpels and bandages.
While the technological advances are evident, medical device manufacturers in the European Union (or the ones that want to enter the EU market) are faced with special challenges. It is true that more or less every country and territory regulate SaMD, but since the introduction of the Medical Device Regulation 2017 / 745 (MDR), European manufacturers are faced with unique challenges.
It is important to mention that many rumors and myths have been created around MDSW and the MDR and this article intends to separate the facts from the myths. Even though it has become more complicated to certify MDSW, several manufacturers have already received their certificates, thus proving that while it may be difficult, it is possible.
What are the main Challenges Regarding MDSW and the MDR with SaMD
When dealing with a new or existing MDSW, manufacturers mainly encounter two types of challenges.
The first challenge is to decide whether a certain software even falls into the scope of the MDR or not. For certain cases, such as diagnostic standalone software or mobile applications making therapeutic decisions, the answer is clear. But what about medical databases for searching or medical calculators? The Medical Device Coordination Group (MDCG) provided an infographic and also a guidance document on this topic.
While these provide some clarification (such as simple data transfer and search do not make a software a MDSW), it is still necessary to check each individual case.
In the EU, whether software qualifies as a MDSW is determined not by its general risk but by specific criteria such as symptoms, diseases, and keywords outlined in the MDR Article 2 Section 1. This contrasts with the US approach, where certain low-risk software solutions are classified as wellness devices rather than SaMD.
The second challenge is the classification itself. During the previous Medical Device Directive (MDD), most MDSW were classified as class I devices. This had multiple advantages: No need for a Notified body, much faster time-to-market, no necessity for an ISO 13485 Quality management system etc.
While the implementation of the MDR presents new challenges, transforming many previously class I devices into class IIa or higher categories and necessitating a more comprehensive clinical evaluation and quality management systems even for class I manufacturers, it's important to recognize these changes as manageable. Despite some concerns and misconceptions – such as the exaggerated claim that mobile app MDSW manufacturers must certify each smartphone and operating system, or that achieving class I MDSW status is now impossible – the industry is adapting and finding pathways to successful certification under the new regulations.
Are the rumors about SaMD classification true?
As with any myth and rumor, there are true parts and fictional parts. It is definitely true that most MDSW will have to be reclassified in a higher class than previously under MDD. Many class I manufacturers now have to apply for certification procedures at Notified bodies. This is also partially the reason why the current bottleneck with Notified bodies exists. The main reason for this is rule 11 of Annex VIII of the MDR.
Therefore, it can be confirmed that most harmless and moderate-risk MDSW will have to choose a conformity assessment procedure including a Notified Body, because it will not be possible to stay at class I.
On the other hand, certifying class IIa or higher MDSW might take longer and will need more resources, but it is far from impossible. Notified Bodies dealt with MDSW before MDR, so many of them can handle most solutions (AI might be a special challenge). At the same time, the basic requirements for MDSW haven’t changed. Standards, such as ISO 14971 (risk management), IEC 62304 (SaMD processes) and IEC 62366-1 (Usability) still apply. In the case of IEC 62304, the current accepted version is still from 2005 (with amendments), so it might be a challenge to combine the partially outdated requirements with state-of-the-art tools, such as JIRA.
What exactly is rule 11 of MDR?
Probably the most feared classification rule within the MDR framework is definitely rule 11. This new rule is explicitly dedicated to software and did not exist in the previous MDD.
First of all, it is necessary to state that this rule applies to all types of software with a medical claim. It does not matter if it is a Web application, a mobile app, a firmware or a hardware + software combination. If the software is part of a medical device, or it is a medical device itself, then the rule applies.
Rule 11 addresses two main topics, and it will be necessary to read the rule multiple times before making a decision about what class might be applicable.
The first part focuses on “Software intended to provide information which is used to make decisions with diagnosis or therapeutic purposes”. When reading this part, the question might arise, “Aren’t most MDSW used to support diagnosis or treatment in some way?”. The answer is yes and therefore, this part is mostly responsible for a higher classification. It does not matter if the MDSW is making a diagnosis on its own or if it's providing supporting data for doctors, who then make a diagnosis. If the intended purpose contains such claims, the MDSW will be at least class IIa, if the patient is threatened by critical or lethal harms, rule 11 even demands class IIb or class III.
The second part focuses on “Software intended to monitor physiological processes” and classifies such MDSW as class IIa; in certain cases, such as the monitoring of vital physiological parameters, where variations could cause immediate danger, even class IIb is applied.
The main challenge here is that neither physiological processes nor vital physiological parameters are properly defined within the MDR. This creates a huge debate and there are often two factions: Faction one declares that everything the human body does is a physiological process and this goes way beyond heart rate, blood pressure etc. The other faction claims that a differentiation has to be made. As an example, what about human tremor caused by Parkinson’s disease? While physiological tremor could be seen as a physiological process, what about pathological tremor? Is it still a physiological process, or the effect of physiological processes
Is class I software (SaMD) even possible?
After interpreting rule 11, the question arises if class I MDSW is even possible within the MDR framework. The short answer is: Yes. A first piece of evidence can be found in the MDCG guidance on medical device classification, where the authors take a fertility monitor as an example for a class I software. Furthermore, article 2 section 1 provides additional keywords, such as prognosis, prevention and prediction that could lead to a lower classification.
The main question here is if a MDSW with harmless claims and class I can even provide relevant benefits to patients. Again, the answer is yes. Just by taking the example of Germany and the DiGA approach, their list of accepted technologies contains multiple examples of class I MDSW under MDR.
However, it is not recommended to artificially reduce the claims, just to avoid the additional challenges of higher classes. A MDSW always has to provide evidence that the clinical benefit is given, and it outweighs the risk. If there is no real benefit, then a market entry will not be possible.
What are the biggest challenges with classes IIa and higher?
If it turns out that class IIa or higher is unavoidable, then manufacturers will face the following challenges:
The necessity to cooperate with a Notified Body
Waiting times of multiple months and sometimes over a year to receive certification
The need to find a Notified Body that is willing to deal with state-of-the-art software
Probably the certification of one’s QMS
Yearly surveillance audits
Other aspects, such as the clinical evaluation And the introduction of a QMS are not mentioned, because they apply to all manufacturers, irrespective of the class.
6 Top Tips and hacks to optimize one’s journey with SaMD
While it is not possible to circumvent the MDR and the requirements, it is still possible to use certain shortcuts and optimizations to reduce the time-to-market. Here are some recommendations to make it possible:
Be very sure that your software falls within the scope of MDR. An excellent intended purpose documentation is the basis for any delimitation. What if you come to the conclusion that you have a class IIb MDSW, while the MDR doesn’t even apply to that certain software?
If possible, try to separate the MDSW into medical and nonmedical modules. The MDR only applies to parts of the software that has medical claims. This is not always possible, but in a larger software solution, a separation can vastly reduce costs and times.
If in doubt, let the classification be double-checked by consultants, lawyers and competent authorities. Especially competent authorities can provide a legally binding statement about the MDSW class and this can provide more clarity. However, the decision is final and if the result is not the expected class, then it will not be possible to argue any other classes.
Choose Notified Bodies wisely. The auditors and product reviewers have to have good experience and knowledge about MDSW, so that no unnecessary discussions arise. You have the freedom of choice, therefore it is important to approach multiple Notified Bodies.
Be careful with agile development and modified requirements. A single new requirement might reclassify your MDSW into an even higher class. Therefore, it is necessary to analyze each new wish or requirement carefully during development.
Check the manual on borderline cases for the MDR. The number of MDSW examples are still limited, but they might provide guidance. Also, check the EU market for similar devices and analyze their classifications to have a benchmark.
Summary and Conclusions
As it can be seen, the new requirements implemented by the MDR are causing headaches for many MDSW manufacturers. The higher risk classes, the increased amount of regulatory requirements and also the legal uncertainty due to the lack of enough precedent cases.
Nevertheless, it is still possible to place MDSW on the EU market and being the second largest MedTech market in the world, this is only one motivational factor to comply with the additional requirements.
The most important aspect (as with any other regulatory aspect) is to invest most of the available time into the initial analysis and interpretation. An early mistake at the beginning will cause 10X or even 100X costs down the development path, but proper planning will safe time and resources.
Matrix Requirements GmbH is a global software leader helping innovative Medical Device companies remain focused on developing safer products faster. The MatrixQMS (QMS) Quality Management System reduces the regulatory burden by bridging the gap between agile & compliance teams to ensure quality across the entire product lifecycle. We are also very proud to be EN ISO 13485 and ISO/IEC 27001 certified.
Our 200+ clients, medtech leaders such as Medtronic, GE Healthcare, Stryker, Roche Diagnostics, and B.Braun, as well as startups and scale-ups such as Proscia, Element Biosciences, Clue, MindMaze and Diabeloop, are saving time in documenting product development and quality processes with our intuitive platform. Matrix Requirements was founded in 2015 by medical device developers, and has a team of 40 distributed between Germany, United States, France, UK, Belgium, and Spain.
About the Author:
Tibor Zechmeister is an entrepreneur in the medical device sector with over a decade of experience. He specializes in regulatory compliance and quality management systems. His role as an external auditor and founder in the HealthTech space has equipped him to adeptly guide startups and established companies through the complexities of European regulations like the 2017/745 MDR, ensuring their successful market entry and enhanced patient outcomes.