thumbnail_Group 1000001061.jpg

Group 1000001061.jpg

Expand your medical software knowledge with insights from specialists

Customer-personalisation-for-pharma's-growth-by-Revolve-Healthcare-cover

Customer-personalisation-for-pharma's-growth-by-Revolve-Healthcare-cover.webp

Pharma Engagement Omnichannel Software in Healthcare - cover

Pharma Engagement Omnichannel Software in Healthcare - cover.webp

mdr-rule-11.webp

why-DiGA-cover.webp

medical-software-certification-guide.webp

Medical Device Regulation (MDR) and its consequences for healthcare software development  Innovating in the healthcare industry means improving people’s lives through technology. But it also means adhering to regulations that ensure the solutions you create are safe for the patients – in many different ways. Medical Device Regulation (MDR) is probably the most important set of rules you need to follow when building a medical app which would be launched on the European market. The term medical app in this article means a medical app, a medical device, according to the MDR. Let’s dive into why it exists, what it means for the health tech sector, and why you should get familiar with it.  MDR, Medical Devices and their characteristics Before discussing how MDR influences software development, we should know what MDR itself and medical devices are. The Medical Devices Regulation (MDR) (EU 2017/745) is a regulation that details the requirements for the production of medical devices. Meeting these requirements allows for placing on your product the CE mark - only then can you sell it as a medical device within European countries. According to MDR, a medical device is “any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used (...) for the specific medical purposes” such as: diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation of, or&nbsp;compensation for disease, injury, or disability, investigation,&nbsp;replacement, or modification of the anatomy or a physiological or&nbsp;pathological process or state, providing information&nbsp;by means of in vitro examination of specimens derived from the&nbsp;human body, including organ, blood, and tissue donations, and which does not achieve its principal intended action by pharmacological, immunological, or metabolic means in or on the human body but may be assisted in its function by such means. In addition, medical devices are devices for the control or support of conception and products intended to clean medical devices.  Accelerating the health technologies Although embedded software, as well as desktop, web, and – more recently – mobile applications have been supporting medical professionals and patients for many years now, it has been the COVID pandemic that accelerated the medtech sector. These e-health apps range from calorie counters and pedometers (counting your steps) to blood glucose monitors and remote electrocardiogram (ECG) monitoring, which may also be connected to an electronic health record (EHR). Family planning apps (some use AI algorithms based on a woman’s menstrual cycle pattern, basal body temperature, and ovulation tracking with at-home ovulation tests) have gained popularity recently and there are several professional debates about whether they can be considered a form of contraception. Healthcare professionals often use apps with calculators, e.g. to estimate one’s risk of coronary artery disease or pre-eclampsia in pregnancy. There are several apps that support the diagnosis of skin diseases and help non-radiologists interpret imaging studies. And many, many more.  Mobile apps as medical devices It’s possible you’re using several medical apps every day without even realizing that many of them are now considered medical devices. As a user, you don’t exactly need to be aware of the consequences of this, but as a company creating an app that may fall into this category, you definitely should. So, how do you know if your medical app is a medical device and falls under the Medical Device Regulation? The main criterion to determine if your app is or not a medical device is its intended purpose. For example, an app collecting and analysing data on a person’s physical activity to maintain their general well-being, such as weight loss, is qualified as a general well-being app and falls out of the medical devices legislation. However, the same app collecting and analysing identical data for a medical purpose, such as controlling and managing eating disorders or diabetes, would be considered a medical app. The most important thing is to analyze whether your mobile application meets the definitions of a medical device or accessory for a medical device contained in MDR. If so, this application is subject to MDR regulations. If not – an in-depth analysis of the application features is required, for example, if your mobile apps drive or influence the use of medical device, etc., in accordance with the applicable guidelines of the European Commission and MDCG.   MDR and app classification You should be aware that the legal requirements for medical apps (considered in most cases as standalone software) have increased with the new MDR laws. The EU Medical Device Regulation (2017/745) has replaced the EU Medical Devices Directive (MDD) and established a regulatory framework for medical devices that safeguards public health and safety while supporting the market's competitiveness. The EU MDR came into force on May 26, 2021. However, the obligation for medical device manufacturers to comply with the new provisions of the MDR Regulation is valid from 26 May 2021. The classification of medical devices no longer depends solely on the labelled purpose of the device but also the inherent risks of the devices. This leads to significant implications for medical devices since many fall into higher classification rules. The new MDR classifications reflect a medical device's potential risk of harm. MDR divides medical devices into four classes of risk: I, IIa, IIb, and III. Class I devices are considered the lowest risk, whereas Class III are deemed high-risk devices. According to MDR, software may be a medical device of the highest-risk class (class III). Importantly, this includes stand-alone software (software that can work offline or is a portable application). For example, an app that helps users calculate drug doses would be a Class III medical device because the potential errors pose high risks for the app’s users. You can find more examples and see what Class your software falls into on our website here.    Rule 11 and risk assessment In the MDR (Annex VIII), we will find 22 rules for the classification of medical devices grouped into four categories: Rules&nbsp;1-4 consider non-invasive devices. Rules&nbsp;5-8 consider invasive devices. Rules 9-13 consider active devices (any device that depends on a source of energy other&nbsp;than any device that depends on a source of energy other than the human body). Rules 14-22 are so-called ‘special rules’ as they refer to medical devices which do not fit&nbsp;into the above categories. Every rule discusses how specific medical devices fit into new, stricter risk classifications. However, Rule 11 is most important for manufacturers of medical device software (MDSW). Rule 11 describes and categorises the risk of software based on the combination of the significance of the information provided by the software to the healthcare decision and the healthcare situation or patient’s condition. According to Rule 11, in general, software intended to provide information which is used to make decisions with diagnosis or therapeutic purposes is classified as class IIa – for example, software intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics. Of course, there are exceptions where the use of medical software may or must entail a greater risk for the patient or user. In situations where the effects of the decisions may result in death or an irreversible deterioration of a person's health, the software should be classified as class III. If decisions have an impact that may cause a serious deterioration of a person's state of health or surgical intervention, the software should be classified as class IIb. All other software, being medical devices, is classified as class I. If the software is independent of any other medical device, it shall be classified in its own right – it concerns most medical apps. On the other hand, software which drives a device or influences the use of a device shall fall within the same class as the device. You can read more about Rule 11 and risk classification here.  The impact of MDR on the medical devices services market Patients should feel confident that the medical devices are safe and effective. However, such a comfort state demands stricter regulations, like those included in MDR. MDR introduces many requirements that manufacturers must meet, such as: development and refinement of quality and risk management undergoing more rigorous demands for launching a medical device which will ensure&nbsp;that medical devices are safe for the patients providing their medical device with a UDI identifying code and registering it in the&nbsp;EUDAMED base, which makes it easier for authorities to monitor the device providing post-market evaluations and reports. What’s more, MDR sets a challenge for manufacturers whose medical devices used to be in class I due to MDD and now belong in class IIa or IIb. They had to CE mark their devices before May 26th, 2021, or use a transition period from MDD to MDR described in Article 120 of MDR. Nowadays, developing software as a medical device within the law of MDR might seem time-consuming, like a time-consuming process. Nevertheless, MDR provides more clarity to rules for providing CE certification. MDR brings more transparency into manufacturing medical devices and preparing the necessary documentation. Also, we should remember that those regulations bring the most important thing to people – safety.  Moving forward To sum up, for the proper classification of the software medical devices, it is necessary to consider the intended purpose, intended population, context of the use of the software and the information provided by the software, as well as the possible consequences of any taken decisions. MDR imposes stricter regulations on medical device services, reclassifying some devices, introducing new requirements for manufacturers, and emphasising safety. In this article, we’ve covered the basics of MDR and why it’s relevant for you if you’re building health-related software. In later articles, we will follow how MDR influences the software development process and what you should pay special attention to if you want your app to be MDR-compliant.

Medical Device Regulation (MDR) and its consequences for healthcare software development

Medical software certification – a guide for managers

How to build a SaMD: a step-by-step guide

The most popular

Medical Software Development Blog

Customer Personalisation for Pharma's Growth

Pharma Engagement: Omnichannel Software in Healthcare

Does outsourced software
development make sense in
healthcare?

Why digital health applications (DiGA) are the future – in conversation with ABAStroke

10 kinds of mobile healthcare apps medical specialists use

Top 5 digital health trends for 2022

The most popular

Medical Device Regulation (MDR) and its consequences for healthcare software development

Medical software certification – a guide for managers

How to build a SaMD: a step-by-step guide

Customer Personalisation for Pharma's Growth

Pharma Engagement: Omnichannel Software in Healthcare

Does outsourced softwaredevelopment make sense inhealthcare?

Why digital health applications (DiGA) are the future – in conversation with ABAStroke

10 kinds of mobile healthcare apps medical specialists use

Top 5 digital health trends for 2022

The most popular

Medical Device Regulation (MDR) and its consequences for healthcare software development

Medical software certification – a guide for managers

How to build a SaMD: a step-by-step guide

Does outsourced software
development make sense in
healthcare?