IVDR and IVD Software: How to Properly Qualify and Classify Your Software

Since the EU Regulation (EU) 2017/746 (IVDR) came into force in May 2022, the world of in vitro diagnostics (IVD) has faced a radical shift. One of the major changes? The now-crucial role of Notified Bodies: it is estimated that nearly 80% of IVD devices must now be assessed by a Notified Body to obtain CE marking.

In this context, software used in IVD raises many questions:

• Is all software affected?
• When should software be considered an IVD medical device?
• What mistakes should be avoided to prevent a roadblock during the assessment?

This article sums it up, based on the Position Paper published by Team-NB, the European Association of Notified Bodies, on June 17th 2025.

1. Key regulatory reminders

A quick look back: before IVDR, Directive 98/79/EC provided for relatively limited Notified Body involvement. The new regulation, however, bases device classification on the risks related to the intended purpose — and software is firmly under the spotlight.

In 2019, the MDCG (Medical Device Coordination Group) issued guidance (MDCG 2019-11) clarifying software qualification and classification under both MDR and IVDR. Yet many manufacturers still struggle to apply these texts to their own cases. That’s why the Team-NB Position Paper is so helpful: it clarifies what Notified Bodies expect.

2. What is IVD software under IVDR?

MDSW, or Medical Device Software, refers to any software intended for a medical purpose as defined in the IVDR:

• On its own (e.g., a stand-alone NGS analysis app)
• Integrated in a system (e.g., analyser firmware)
• Or as a module or accessory.

Key point: Some software combines modules with a medical purpose and others without (e.g., stock management, pure archiving). Each module must be clearly delineated and documented.

3. 3 scenarios to qualify your software

The Position Paper provides a clear decision flow-chart to make the right call. Here’s a simplified version:

➊ Software driving or influencing a device

E.g., firmware, motor control module. In this case, the software is evaluated as an integral part of the IVD system. No separate classification.

➋ Stand-alone IVD software

E.g., NGS application, image analysis software for cancer screening. In this case, the software is an IVD in its own right. It must be classified based on its intended use and have its own technical documentation.

➌ Accessory software

E.g., middleware, image format converter for AI analysis. Here, the software has no direct medical purpose but supports an IVD device. It’s classified as an accessory, and still subject to IVDR requirements.

Watchword: your intended use is the golden thread.

4. Practical examples: what does it look like in real life?

Example 1

NGS sequence analysis software for detecting hereditary genetic anomalies. It provides a diagnostic result directly → stand-alone IVD MDSW.

Example 2

A mobile app that processes blood glucose data to generate alerts and adjust insulin doses. Diagnostic or therapeutic purpose → IVD MDSW.

Example 3

A middleware module converting biopsy slide images for AI processing. It has no medical purpose on its own but enables the process → accessory.

5. Mistakes to avoid

• Assuming that a cloud software or visualisation module is always out of scope: it depends entirely on the intended purpose.
• Blending medical and non-medical modules without clear boundaries: document the separation.
• Forgetting that the classification of the whole system prevails: an integrated module must follow the system’s classification.

6. FAQ — Your frequent questions

What is non-IVD software?

E.g., LIMS, ERP, stock management: no data processing for diagnostic purposes → out of scope of IVDR.

Is a LIMS covered by the IVDR?

No, unless a part of it generates diagnostic interpretation. Then that module must be qualified as IVD MDSW.

How about cloud-based software?

Location doesn’t matter (cloud, PC, mobile): only the intended use counts.

My software is sold separately — what do I do?

Check if it’s meant for stand-alone IVD use or as part of a system. That determines the assessment procedure.

Can I qualify a module as ‘non-medical’?

Yes, but you must show it has zero direct interaction with diagnostic data. Boundaries and interfaces must be clear.

7. Conclusion: the key is the intended purpose

To avoid any roadblocks during Notified Body review, always ask yourself: “What is the real intended purpose?” Draft it clearly, justify your choices, and document your modules. And if in doubt: don’t take unnecessary risks.

Not sure how to qualify or classify your software? CSDmed is here to help you secure your IVDR journey and prevent last-minute surprises during CE assessment.

Contact us to discuss your projects.

You might also be interested in this article: New MDCG 2025-4 Guidance: Requirements for Medical Device Software Apps on Online Platforms