MDR and Software as a Medical Device (SaMD)
Can you still self-certify?
tl;dr
New rules for the classification of medical software will push some apps into a higher risk categorisation than they would have previously received. Many that were in Class I will now be Class IIa or higher — this is particularly relevant for smaller companies: products in the higher categories cannot be self-certified so developers will have to engage with a notified body to conduct conformity assessment.
Update: Jan 2020
Since writing this article, the European Parliament looks likely to adopt a corrigendum that would extend the transition period for some Class I medical devices by up to an additional 4 years. This would take the pressure off to recertify before May 2020. I will provide a fuller update when the situation is clearer.
Medical Device Regulation
Change is afoot in medical device compliance. The EU Medical Device Regulation (MDR) came into force in 2017, and overhauls the existing Medical Device Directive (MDD). The three-year transition period ends on 26th May 2020.
Many Class I standalone software products will be pushed into a higher classification by MDR, and must be compliant by May 2020.
The MDR affects all manufacturers selling medical devices in Europe. The changes are quite wide-ranging, and include:
- expanded scope: some products without an intended medical purpose, will now be regulated as medical devices;
- reclassification of devices according to risk, (human) contact duration and invasiveness;
- requirement for more rigorous clinical evidence, potentially with more clinical investigations.
- new requirements for traceability and Unique Device Identification (UDI), and centralised/publicly accessible information via the EUDAMED database (not fully operational at time of writing)
Standalone software is considered as active medical device, if it is intended to be used for a medical purpose. Not all software used within a healthcare environment would be classified as a medical device, however — more information can be found in the MEDDEV 2.16 guidance documents.
It’s worth noting that the In Vitro Diagnostic Directive (IVDD — 98/79/EC) is also being overhauled, to be replaced by the In Vitro Diagnostic Regulation (IVDR — 2017/746). The transition period is longer, however, so IVDR doesn’t come into full force until May 2022. Some standalone software may fall under IVDR, rather than MDR.
Classification of standalone software
Under the old rules, most standalone medical software fell into the lowest risk category — Class I (MDD Annex IX, Section III Classification, Rules 9–12). Software only received a higher classification if it was used for specific activities related to diagnosis.
The MDR changes this, however. Rule 11 covers the risk classification of software — and its been reasonably controversial. The regulation is pretty specific that software with a diagnostic or therapeutic purpose should fall into Class IIa (or higher). That's significant because it mandates conformity assessment by a notified body, rather than self-certification. Here’s the text in full:
6.3. Rule 11 Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: - death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or- a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I.
So in general, software will only be Class I if it doesn’t contribute to diagnosis or therapeutic decisions, AND doesn’t monitor physiological processes. This doesn’t leave out much, although one example would be software intended solely to prevent disease.
Transition plan
Whilst many devices certified under the MDD can continue to be marketed up until 2024 (the period defined in Article 120 of MDR), that grace period is not available to Class I products or those that have been “up-classified” as a result of MDR — they must be compliant by May 2020.
The wording in the regulation (MDR Article 120, para 2–3) is slightly open to interpretation, but thankfully recent guidance by the CAMD (Q10, 13) has clarified — its all about CE mark certificate expiry dates. Products certified under MDD can continue until the expiry date on their CE-marking certificate (a soft transition, potentially up to 2024). There are some additional obligations, however, such as post-market surveillance (see below).
Class I products, however, are self-certified and so do not have a certificate with an associated expiry date. They must be compliant at the end of the transition period, on 26th May 2020. Some further discussion here.
Effect of higher classification
This higher classification brings a number of additional responsibilities, including engagement with a notified body to conduct conformity assessment. Software products that are Class I under MDR can still be self-certified.
Manufacturers are also required to more actively engage in post-market surveillance: there are also new obligations to monitor, collect data, and report after products in Class IIa and above are placed on the market. Periodic Safety Update Reports (PSUR) are required every year for Class III software, and every two years for Class IIa and b (non-implantable).
Courses of action
For manufacturers unsure of their position, the best course of action is probably to engage with a notified body to determine next steps. Similarly, conducting a gap analysis on the regulatory position should help clarify what is required to achieve MDR compliance.
The three year transition period has led to a faster pace of change in the market than many would like, and Competent Authorities and Notified Bodies are still adapting to the new rules. Not all of the systems required are fully operational (such as the EUDAMED database), although MDR is clear that relevant regulations will not come into force until after their launch (MDR Article 123).
One cause for concern is the shortage of notified bodies certified under MDR. At the time of writing, only five notified bodies across Europe have been approved for carrying out conformity assessment under MDR (compared to 56 certified for the previous directive). The only UK-based approved notified body is BSI. You can check the latest on the NANDO database.
Concluding remarks
Classification rules for software have undoubtedly become stricter, and many manufacturers of medical software will now have to engage with a notified body to conduct conformity assessment. It is still possible to self-certify low-risk medical software, such as apps that are intended to prevent rather than treat disease.
Are you developing standalone medical software or apps? What’s been your experience of certification under MDR? Leave your comments below!
Rupert Thomas is a technology consultant specialising in software engineering, machine learning, and building data-driven products. Rupert Thomas
