MedDeV

Software as a Medical Device: Regulation and Standards

These days, software is essential in every area we can think of. It aids us in day-to-day, real-life activities, but treating software as a medical device is an entirely different matter altogether. Saving lives, boosting the quality of life and lowering healthcare costs are goals on a different scale.

Over the years, we’ve learned a lot, and measures to prevent risks posed by the use of medical devices and software were implemented all over the world. The FDA, EC, MHRA, TGA, BfArM, and other authorities have established regulations and compiled the best practices for a set of standards and guidelines; software development lifecycle devices, risk management, quality management systems, and useful and accessible guidelines are all part of a process for developing and maintaining safe medical software.

MDD – First Phase Requirements

The MDD (Medical Device Directive) only had one main purpose: allowing the marketing of medical devices only when manufacturers have demonstrated that the medical benefits of using the device outweigh the risks involved. The manufacturer has to answer the following questions:

  • Does the device meet the definition of a medical device or accessory?
  • What is the intended purpose of the device?
  • What is the risk classification?
  • Does the device meet the general safety requirements?
  • Does the use of the device outweigh the risk of using it before it is marketed?


It is different from the hardware device; it is difficult to verify and verify invisible work. When we test software, the technical portfolio is the product; the device is not the main thing.

Manufacturers have to invest a lot of effort into proving that the medical gains for the patient exceed the risks associated with using the medical device. This is possible only with a thick pile of papers proving that the device that will be manufactured at a later stage does indeed produce positive medical outcomes, and at a low risk to the patient. The product must meet all the essential MDD requirements. The technical file must answer all the questions asked above.

These standards need to be adopted to ensure that all the activities carried out before the device was introduced to the market were done. Through standards, we strive to prevent the recurrence of past mistakes that lead to dangers for patients.

Some of the most important standards and recommended guidelines to be followed are:

  • ISO 13485 – Medical devices – Quality management system
  • IEC 62304 – Medical device software – Software life cycle processes
  • IEC 82304 – Medical device software – Software life cycle processes Health software — Part 1: General requirements for product safety
  • ISO TS 25238 – Health informatics – Classification of safety risks from health software
  • ISO 14971 – Medical devices — Application of risk management to medical devices
  • IEC 62366 – Medical devices — Application of usability engineering to medical devices
  • IEC 60601 – Medical electrical equipment – Safety and essential performance of medical electrical equipment.
 

In this article, I do not aim to go into detail of every standard mentioned above. However, if you are in the medical software field, it is highly recommended that you go over them several times. My recommendation at this point is to discuss the matter with an expert consultant in the field. A few well-invested consulting hours can save you a lot of money and stress along the way.

Welcome the MDR (or: MDD on Steroids)

There are issues with MDD that have required intervention. MDR (Medical Device Regulation) is a lengthy regulatory action that sought to address the MDD pain areas and related guidelines. The MDR is significantly more comprehensive and detailed compared to the MDD. While the MDD comprises 23 Articles and 12 annexes over 60 pages, the MDR has 123 articles and 17 annexes over 175 pages.

MDR approved on May 26, 2017, MDD, IVD and AIMD approved devices can still be marketed until May 27, 2024. The date was May 2020, but due to the global COVID-19 crisis, it was postponed by a year and set for May 2021. Although a period of 5 years has been set until full entry into the enforcement of the regulation, we are currently awaiting publication of the EU report following the postponement. As of May 26, it is not possible to start and complete any certification process according to MDD regulations, IVD and AIMD; only MDR will be valid.

Evaluation of the manufacturer’s technical files, especially part of the clinical evaluation was, at times, absurd. There was no mention of any scientific claim to prove the medical benefits for the intended purpose.

Also, risk management was weak, and companies were unable to show a positive benefit/ risk ratio.

For this reason, the European Commission has requested that all competent bodies undergo a detailed audit to prove that they comply with the MDR.

Almost every NB has lost the right to assist manufacturers in their MDR efforts. At the moment there are less than ten NB for the EU, and two of them are in the UK. So the pressure on NB is tremendous, which means that now the time that has elapsed for certification is between 2-4 years.

The committee also introduced new classification rules that have affected more devices that have now entered a higher risk classification, and therefore need the assistance of NB.

It is important to note that there are products that are currently at a low risk level (Class I) that will rise to a high risk level (Class III) under the new regulation.

A lot of devices under MDD will not be considered medical devices; Type I medical devices could suddenly become a medium-risk medical device in Class II.

If a device has a medical benefit, then it is a medical device and must follow MDD or MDR; otherwise, it should not be on the market. Manufacturers, Notified Bodies, distributors, importers, suppliers and other involved parties who participate in design, development, production, distributing and maintaining medical devices in the EU will have a lot of work in the upcoming years, and this is all for a crucial reason.

So, what should we do towards the change in regulation?

Begin to prepare. Just like that. In the first stage, understand what it means in terms of product approval and that it is also desirable to contact the responsible body in Europe to ask for an opinion and a recommendation on how to proceed.

Also, we suggest again that one start working with an expert consultant in the field to adjust the technical file, quality system, evaluation and clinical plan and even address places where there is overlap between the new regulation and MDR medical equipment and other regulations, such as the GDPR, cyber and others.

The safety of patients must never be neglected as it was back in the ’80s. The device on the market must fulfil what was promised in terms of benefits and intended purposes at a minimum, reasonable risk for the patient.

Standards are there to help, not to inhibit you or keep you away from success. The regulative horizon is vast, an getting a consultant is a wise move.

Looking for that expert consultant?

Regulation is our specialty here at MedDev, so please don’t hesitate to reach out using the form below and we’d be happy to guide and consult you!

 

Related Articles

post 02_מאמר

התקנות החדשות ברגולציה לתחום המכשור הרפואי מבוסס בינה מלאכותית לשנת 2024

new_0009_Medical-Device-Cybersecurity-What-You-Need-to-Know

THE NEW FDA CYBERSECURITY GUIDANCE

2024blog

מה צפוי לקרות בעולם המכשור הרפואי ב-2024?

new_0000_ניהול-סיכונים-כתנאי-מקדים-לשימוש-בכלי-AI-ו-GAI-בתהליכי-פיתוח-מכשור-רפואי-ותוכנה-רפואית

ניהול סיכונים כתנאי מקדים לשימוש בכלי AI ו-GAI בתהליכי פיתוח מכשור רפואי ותוכנה רפואית

new_0003_הצורך-בבדיקות-תוכנה-ובתיעוד-בהתאם-להנחיות-הרגולטור-–-לא-מסתיים-לעולם!

הצורך בבדיקות תוכנה ובתיעוד בהתאם להנחיות הרגולטור – לא מסתיים לעולם!

new_0006_איך-הפכו-בודקי-התוכנה-(SQA)-לאחת-הפונקציות-החשובות-ביותר-בתהליך-הפיתוח

איך הפכו בודקי התוכנה (SQA) לאחת הפונקציות החשובות ביותר בתהליך הפיתוח?