The revised MDCG 2019-11 guidance on qualification and classification of software (the Revised Guidance) introduces a series of clarifications and expansions that impact how software is qualified and classified as a medical device under the EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR). While the core principles remain unchanged, the Revised Guidance provides more detailed examples, specifically includes software using artificial intelligence (AI), and addresses modular software and interoperability with electronic health records (EHRs) under the European Health Data Space (EHDS).
This blog post outlines these key updates and considers their potential impact on compliance obligations for software manufacturers.
General scope
The Revised Guidance tightens its focus by explicitly naming “Medical Device Software (MDSW)” as well as includes the term “Medical Device Artificial Intelligence (MDAI)” within the scope, clarifying that AI‑enabled software will be assessed under the same qualification and classification criteria. The Revised Guidance also adds a clarifying note that the legacy term “stand‑alone software” has been dropped because software is now judged only by its intended purpose, whether it is embedded, mobile, or cloud‑based.
The Revised Guidance also clarifies that these principles also apply to MDR Annex XVI products that do not have a medical purpose.
Modules
The Revised Guidance introduces several clarifications and expansions relating to products that have a number of modules. In general, manufacturers must ensure that the intended purpose of each module is clearly defined and that any dependencies are transparently communicated and justified.
The Revised Guidance puts greater emphasis on the need to assess not only medical device modules but also non-medical modules that impact the overall safety and performance of the software, requiring these to be included in the conformity assessment. The Revised Guidance also requires manufacturers to provide clearer documentation on module boundaries, interfaces, and regulatory status, to enhance transparency for users and regulators. This broadens the scope of technical and clinical evaluation, increasing manufacturer’s workload and the need for interdisciplinary expertise across functions.
In addition, the integration and interoperability requirements highlight risks related to software ecosystems, meaning that manufacturers must not only control their own modules but also consider the safety implications of third-party components or host platforms they interact with. This can have as a result the complication of risk management and potential liability considerations.
Interplay with the EHDS
The Revised Guidance covers the interoperability between MDSW and EHR systems under the EHDS Regulation. It emphasizes that manufacturers must navigate overlapping compliance obligations under MDR/IVDR and EHDS when claiming interoperability. For manufacturers, this update is important because it highlights the need to carefully evaluate not only the software modules but also how these modules interact with EHR systems within a broader regulatory framework. This includes understanding when MDSW or modules qualify as medical devices or high-risk AI systems and ensuring compliance with the overlapping regulations.
The Revised Guidance leaves open questions around how to practically implement compliance in multi-module, overlapping regulation contexts, especially for manufacturers integrating AI features or connecting with diverse EHR platforms.
The Revised Guidance also sets out a specific example of connected software that would be considered as a medical device:
- MDSW integrated into an electronic health record (EHR) platform, designed to analyse patient-specific clinical data, such as diagnostic results, medical history, and current symptoms, to provide therapy recommendations and/or alerts for potential adverse drug interactions. This software assists healthcare professionals in making therapeutic decisions and managing clinical patient care, such as adjusting treatment plans or flagging high-risk scenarios for prompt intervention.
New examples of qualification and classification of MDSW
The Revised Guidance introduces a number of examples of software that qualify as medical devices and examples of how to classify some MDSW. In particular, a new example of a Class I MDSW has been included:
- MDSW app intended to assist persons with a communication disorder (e.g. cerebral palsy, autism (ASD), selective mutism, MS, MND, Down’s syndrome, aphasia, etc.) talk by converting a set of selected symbols into spoken language. Depending on the patient’s medical status, the selection can be done through various means such as a touch screen, head tracking or eye gaze.
However, there are minimal examples relating to AI software, or, for example, ChatGPT systems, which given the prevalence of such products, seems like an obvious omission. There are however examples relating to video game simulations (for example to alleviate certain eating disorder behaviours such as bulimia and anorexia) and virtual reality headset (for example, as an aid in the rehabilitation of persons with amputations by alleviating phantom limb-related phenomena, or to provide therapy for patients with Post Traumatic Stress Disorder).
Next Steps for MDSW manufacturers
- Clearly define and document intended purpose of each MDSW or module, including non-medical ones.
- Reassess Annex XVI products using the updated MDSW criteria.
- Evaluate the impact of non-medical modules on device safety and performance.
- Align with EHDS requirements and check compliance with AI Act.
- Review the new examples to verify proper software qualification or classification.