This blog will guide you through the steps for categorising your software application and identifying the relevant regulations under the EU Medical Device Regulation (MDR) 2017/745 and In Vitro Diagnostic Regulation (IVDR) 2017/746.
Understanding Software as a Medical Device (SaMD)
Software is inherently dynamic and flexible. Its features and functions can evolve rapidly, sometimes shifting its intended use or risk profile. A software application not originally qualified as a medical device may, after updates or redefinitions, fall within the scope of MDR or IVDR.
Software as a Medical Device (SaMD) refers to standalone software that is not embedded in hardware. In contrast, Medical Device Software (MDSW) is defined as any software with a medical purpose, regardless of its deployment—whether in the cloud, on a mobile device, or on a desktop. According to MDCG 2019-11, MDSW is software intended for purposes outlined in the definitions provided by the MDR and IVDR.
Determining Whether Your Software Is an MDSW
MDCG 2019-11 provides two useful decision trees:
- The first helps determine whether the software qualifies as MDSW.
- The second determines whether it falls under MDR or IVDR.
These decision trees guide manufacturers through regulatory obligations based on the software’s intended use and clinical relevance.
Once you have determined the status of your software as MDSW, the second decision tree guides you on whether your MDSW falls under the EU MDR or IVDR.
Case Studies: MDSW vs. Non-MDSW
Example of Non-MDSW:
A hospital IT application used to schedule in-vitro diagnostic tests, handling only patient identity and appointment data, is not considered MDSW. It doesn’t process clinical outcomes or affect diagnosis/treatment, so it supports administrative efficiency rather than clinical decision-making.
Example of MDSW:
An ECG system used by paramedics to transmit patient data to remote physicians may become an MDSW if new features are added—such as modules that generate treatment recommendations. In this case, the software directly impacts patient care and must be regulated as a medical device.
The Impact of Software Changes on Classification
Any change to a software application’s functionality, intended use, or integration with other devices can alter its regulatory status. Adding a new module could independently qualify as an MDSW. Therefore, software updates must undergo rigorous evaluation to determine if they trigger reclassification or new compliance obligations.
Do You Need to CE Mark the Whole System or Just the Software?
When an MDSW module is integrated with other non-medical software or hardware, the entire system must be validated to ensure safety and performance. The manufacturer must clearly define the interface boundaries and document the intended use of each component. If any part of the software falls under MDSW, then appropriate CE marking is required.
MDR Classification Under Rule 11
Rule 11 of MDR Annex VIII sets out the criteria for software classification:
- Class III includes software used for diagnostic or therapeutic decisions that may result in death or irreversible health deterioration.
- Class IIb applies when decisions could lead to serious health deterioration or require surgical intervention.
- Class IIa is for software supporting diagnosis or treatment where outcomes are less severe.
- Class I applies to all other software not fitting into the above categories.
The classification directly affects the level of regulatory scrutiny and documentation required for CE marking.
IVDR Classification for Software
Under the IVDR, classification is governed by the software’s intended purpose. Software that drives or influences diagnostic procedures, especially in vitro diagnostic tests, must be assessed under IVDR Annex VIII.
IEC 62304 Software Safety Classification
Beyond MDR and IVDR, MDSW must be classified under IEC 62304:
- Class A: No injury possible.
- Class B: Non-serious injury possible.
- Class C: Risk of serious injury or death.
The IEC classification defines the depth and rigour of the software development lifecycle. Higher risk classes require more comprehensive documentation, testing, and quality control procedures. Although IEC 62304 classification is separate from MDR/IVDR classification, they are often aligned.
How LFH Regulatory Can Help
At LFH Regulatory, our experts help you determine whether your software qualifies as a medical device and guide you through the classification and CE marking process. From regulatory assessments to full compliance planning, we can support your route to market.
Contact us today on +44 1484 662575 or via info@lfhregulatory.co.uk.
References
MDCG 2019-11 – Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (October 2019)
IEC ISO 62304-2015 Medical device software – Software life cycle processes
