Back to the list

MDCG 2019-11 rev.1: What the New Version Changes for Medical and IVD Software

Medical devices regulation

Since 2019, the MDCG 2019-11 guidance has been a reference for manufacturers of Medical Device Software (MDSW) and in vitro diagnostic software (IVD MDSW). But in practice, the first version left many grey areas: unresolved borderline cases, lack of clarity regarding software modules, and varying interpretations of Rule 11.


The revised version, published on June 17, 2025, goes far beyond cosmetic updates. It brings substantial conceptual and operational clarifications, with a strong focus on the concept of intended purpose, modular software structures, and interactions with other regulations such as the EHDS.


This article breaks down the major changes, outlines concrete implications for manufacturers, and offers practical scenarios to help you adapt your products and technical documentation.




1. Reminder: What Does MDCG 2019-11 Cover?


The guidance focuses on two core concepts:

  • Qualification: determining whether a software product falls under the MDR or IVDR and qualifies as a medical device or an accessory.
  • Classification: assigning the appropriate risk class to the software based on its intended purpose (particularly under Rule 11 of the MDR).

It also addresses special cases:

  • Software that drives or influences a medical device,
  • Differentiating between MDSW and non-medical modules,
  • Software deployed in the cloud, on mobile devices, or embedded in hardware.

Intended purpose is central: it determines qualification, classification, and applicable regulatory requirements.




2. What Changes with Revision 1 (June 2025)

2.1 Clarifications Introduced

  • Extended scope to include software under Annex XVI (products without medical purpose, e.g., aesthetic devices).
  • Intended purpose: The guidance emphasizes the need for a clear, precise, unambiguous statement of purpose—each function with a medical aim must be clinically justified.
  • Modular approach: The document recognizes that software may be broken down into modules. Some modules may be MDSW, others not. The manufacturer must:
  • Clearly define functional boundaries,
  • Document interactions,
  • Prove that non-medical modules do not compromise the safety or performance of medical modules.
  • Interoperability with EHR systems: The guidance incorporates the new requirements of the European Health Data Space (EHDS). Claiming interoperability brings additional obligations.



2.2 New Examples

  • Cases of software intended to treat (notably in mental health, rehabilitation, eating disorders).
  • Therapeutic software using virtual reality or interactive games.
  • Examples where non-medical modules are essential for operation but fall outside MDR/IVDR—as long as boundaries are well documented.
  • A rare example of a Class I software (assistive communication app for patients with autism or cerebral palsy).



2.3 Classification and Rule 11

The document clarifies the three sub-rules:

  • 11a: Software that provides information used for diagnostic or therapeutic decisions.
  • 11b: Software for monitoring physiological processes.
  • 11c: All other software.

It also includes a helpful matrix based on the severity of the clinical situation and the impact of the software on medical decisions, aligning with the IMDRF framework.




3. Practical Scenarios: What This Means for You

Case 1 – Modular Rehabilitation Software

A developer builds a rehabilitation platform including:

  • A virtual reality therapeutic module (MDSW),
  • An administrative tracking module (non-MDSW),
  • A module to track patient engagement.

What Revision 1 says:

  • Each module must be assessed separately.
  • The therapeutic module is classified under Rule 11.
  • Non-medical modules must be documented, and their interaction analyzed in the technical file.



Case 2 – Software Connected to an EHR

A decision support tool is integrated with a certified EHR system.


What Revision 1 says:

  • If the manufacturer claims interoperability, EHDS compliance is also required (interoperability specs, documentation, cybersecurity).
  • MDR qualification alone is no longer sufficient: the regulatory framework becomes dual.



4. Frequently Asked Questions (FAQ)

1. Does my software remain Class IIa if I haven’t changed the algorithm?

Not necessarily. What matters is the impact on medical decisions. Even without technical changes, your regulatory position may evolve under the new guidance.



2. Can I declare non-medical modules as “out of scope”?

Yes, but only if you can justify that they have no impact on the safety or performance of the MDSW.



3. Does cloud hosting affect the classification of my software?

No. The classification depends on the intended purpose, not on technical deployment. That said, additional requirements may apply (cybersecurity, traceability, availability). See also: New MDCG 2025-4 Guidance: Requirements for Medical Device Software Apps on Online Platforms



4. What if I want to connect my software to an EHR?

You will need to comply with both EHDS and MDR/IVDR. A specific interoperability dossier is required.



5. My software was previously considered non-MDSW. Should I requalify it?

Possibly. Borderline cases are now more clearly addressed and may now be considered MDSW.




5. What Manufacturers Should Do Now

  • Reassess your intended purpose with clinical alignment.
  • Map your software architecture: modules, data flows, interfaces.
  • Requalify borderline modules in light of the new examples.
  • Update technical documentation: justification of classification, interface analysis, EHDS compliance if applicable.
  • Re-evaluate clinical/performance evaluation strategies for each module.



6. Conclusion

This is more than just a minor update: it consolidates the interpretive framework. It finally settles some long-standing ambiguities (treatment claims, modular logic, interoperability), while reinforcing the demand for sound justification.


This will require work from manufacturers, but it also provides an opportunity: to build more robust, clear and defensible software architectures and technical files.




Need Strategic Support?


At CSDmed, we help manufacturers:

  • Structure their intended purpose and software architecture,
  • Classify software according to MDR/IVDR logic,
  • Align with MDR, IVDR, AIA and EHDS requirements without overcomplicating development.

Developing a health software product? Start with the right foundation. Let’s talk.

Link to the guide