A Comparison Between IVDR and MDR Software

The term Software as a Medical Device is defined by the International Medical Device Regulators Forum (IMDRF) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." 

But not all of the software used in healthcare can be qualified as medical devices. Software intended to process, analyze, create or modify medical information may be qualified as medical device software only if it is provided with a well-defined medical intended purpose.  

In particular, to be qualified as a medical device, the device must meet both the definition of software and the definition of "medical device" (MD) in accordance with Article 2(1) of Regulation (EU) 2017/745 (MDR) or alternatively, the definition of "in vitro diagnostic medical device" (IVD) of Article 2(2) of Regulation (EU) 2017/746 (IVDR). 

Medical device means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes:  

• Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; 
• Diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability; 
• Investigation, replacement or modification of the anatomy or of a physiological or pathological process or state; 
• Providing information by means of in vitro examination of specimens derived from the 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 which may be assisted in its function by such means.  

In vitro diagnostic medical device means any medical device which is a reagent, reagent product, calibrator, control material, kit, instrument, apparatus, piece of equipment, software or system, whether used alone or in combination, intended by the manufacturer to be used in vitro for the examination of specimens, including blood and tissue donations, derived from the human body, solely or principally for the purpose of providing information on one or more of the following: 

• Concerning a physiological or pathological process or state; 
• Concerning congenital physical or mental impairments; 
• Concerning the predisposition to a medical condition or a disease; 
• To determine the safety and compatibility with potential recipients; 
• To predict treatment response or reactions; 
• To define or monitor therapeutic measures. 

So, the first step is to qualify the software as "medical". And then? At this point, it is important to understand which regulation the software can refer to. 

In this particular case, MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR can come in support since the guidance indicates the decision stages for the qualification of a software or as a medical device or in-vitro diagnostic medical device.  

In the guidance, it is clear that if the information provided by the software is based on data obtained from an in vitro diagnostic medical device, then the software is an in vitro diagnostic medical device. Otherwise, if the data analyzed are obtained from medical devices and medical devices-in vitro diagnostics, the manufacturer should weigh the data sources against the information necessary to achieve the intended purpose for determining whether the software falls under the regulation of medical devices or under that of the in-vitro diagnostic medical device. 

Now, there is the funny part, which means, classification rules. 

According to Regulation (EU) 2017/745, if software is defined as an active device, for the classification of active (hardware) devices, the following rules of Annex VIII should be considered: 

• Rule 9 is applied for active therapeutic devices intended to administer or exchange energy, as well as active devices intended to control/monitor/directly influence certain devices;  
• Rule 10 is applied for active devices for diagnosis and monitoring or intended for diagnostic or therapeutic radiology; 
• Rule 11 is applied for software for decisions with diagnosis or therapeutic purposes or software intended to monitor physiological processes; 
• Rule 12 is applied for active devices intended to administer and/or remove substances; 
• Rule 13 is applied when the other rules do not apply; 
• Rule 15 is applied to devices used for contraception; and  
• Rule 22 is applied to a closed-loop system. 

Conversely, in the case of software that falls under the qualification of in vitro diagnostic devices, all the classification rules of Annex VIII of Regulation (EU) 2017/746 should be considered.  

Note that, in both cases, the classification rules shall be governed by the intended purpose of the device. Remember that the software qualified with a well-defined medical intended purpose can be placed on the market in two different ways: as a medical device or in-vitro diagnostic medical device in its own right, or as an integral component or part of a hardware device. 

Following are some examples of software that can be classified according to IVDR: 

• Standalone software able to combine a number of IVD results to calculate and report an additional result to be used for clinical purposes;  
• Software driving or influencing the use of an IVD instrument; 
• Software that is built into an IVD medical device (e.g. instrument or analyzer); 
• Standalone software intended for use in staging or predicting severity of disease by means of an algorithm based on a combination of anthropometric measures and non-invasive biomarkers. 

In addition, some examples of software are reported below that can be classified according to MDR: 

• Software that displays MRI and other types of medical imaging on mobile devices; 
• Software which interprets patient input data to develop a plan of treatment for the patient; 
• Software that analyzes and monitors the performance or functioning of a medical device. 

In this scenario, it is important to have state-of-the-art (SOTA) standards to be followed when developing software as Medical Devices.  

For example, for both MDR and IVDR software, IEC 62304:2006+A1:2015 Medical Device Software – software life-cycle processes must be followed. This standard covers the software development, software maintenance, risk management and configuration management processes for a SaMD. 

Also, IEC 62366-1:2015+A1:2020 Medical Devices Part 1: Application of usability engineering to medical devices must be followed for both MDR and IVDR software. This standard is used to verify the degree to which a product can be used by particular users to achieve certain objectives with effectiveness, efficiency, and satisfaction in a specific context of use.  

If the software is also a “Health Software”, an additional SOTA to follow is IEC 82304-1:2017 Health Software Part 1: General Requirements for Product Safety because this standard covers the Product Validation activities necessary for the SaMD.  

Note that other standards may apply for a particular software (IVD or MD) based on its intended purpose or based on its characteristics/functionalities.  

In conclusion, to understand if software is regulated as a medical device or as an in vitro diagnostic medical device, it is important and fundamental to define its intended purpose. This concept is what defines its scope and therefore what regulations and standards should follow.  

Of course, it is important that the intended purpose matches the functionality of the software.