Why Your Class IIa Software Can’t Use Class I Evidence
A manufacturer submits a clinical evaluation for their diagnostic support software classified as Class IIa. The Notified Body stops at page twelve. The issue isn’t the quality of the literature review. It’s that every study cited evaluated a Class I device. The classification gap makes the entire evidence base irrelevant.
In This Article
This happens more often than it should. Manufacturers treating classification as a checkbox exercise discover too late that it controls everything downstream. The clinical evaluation requirements, the depth of investigation, the acceptability of equivalence claims, the PMCF obligations—all of these scale directly with device class.
For software medical devices, this relationship becomes particularly acute. The same algorithm can shift between Class I and Class IIa based solely on its intended purpose. That shift changes not just regulatory submission requirements but the entire framework for demonstrating safety and performance.
Classification Determines Clinical Evidence Depth
MDR Article 61 sets different clinical evidence standards by class. But the practical impact goes beyond what the regulation explicitly states. Notified Bodies apply these requirements through a lens shaped by risk classification.
For Class I devices, a well-structured literature review combined with usability testing often suffices. The focus remains on demonstrating that the device performs as intended and that users can operate it safely within the specified environment.
Class IIa devices trigger a different evaluation standard. The clinical evidence must now address not just performance but clinical benefit. It must demonstrate that the device achieves its intended clinical outcome in the target population. This isn’t a subtle difference. It’s a fundamental change in what evidence needs to prove.
Class IIb and III devices require even deeper investigation. Equivalence claims face severe scrutiny. The preference shifts strongly toward device-specific clinical data. PMCF transitions from surveillance to active evidence generation.
Classification doesn’t just change submission requirements. It changes what counts as sufficient evidence. A literature review acceptable for Class I becomes insufficient for Class IIa, even if the studies themselves are high quality.
The Software Classification Challenge
Software medical devices present unique classification complexity. MDR Annex VIII Rule 11 creates classification scenarios that depend entirely on the information the software provides and how clinicians use that information.
Rule 11 establishes three tiers. Software for diagnostic or therapeutic purposes that drives clinical decisions without physician oversight reaches Class IIa minimum. Software providing information used to make decisions about diagnosis or treatment also reaches Class IIa. Only software meant to support decision-making without direct influence on clinical choices remains Class I.
The boundary between these categories isn’t always clear in practice. Manufacturers sometimes interpret their software’s role generously, classifying it as Class I when its actual use pattern pushes it into Class IIa territory.
During clinical evaluation, this misclassification becomes visible. If the intended purpose describes the software as decision support but the clinical evidence shows physicians relying on its output without independent verification, the classification conflicts with the use reality.
Manufacturers classify diagnostic software as Class I based on labeling that emphasizes
Frequently Asked Questions
What is a Clinical Evaluation Report (CER)?
A CER is a mandatory document under MDR 2017/745 that demonstrates the safety and performance of a medical device through systematic analysis of clinical data. It must be updated throughout the device lifecycle based on PMCF findings.
How often should the CER be updated?
The CER should be updated whenever significant new clinical data becomes available, after PMCF activities, when there are changes to the device or intended purpose, and at minimum during annual reviews as part of post-market surveillance.
What causes CER rejection by Notified Bodies?
Common reasons include inadequate equivalence demonstration, insufficient clinical data for claims, poorly structured SOTA analysis, missing gap analysis, and lack of clear benefit-risk determination. Structure and logical flow are as important as the data itself.
Which MDCG guidance documents are most relevant for clinical evaluation?
Key documents include MDCG 2020-5 (Equivalence), MDCG 2020-6 (Sufficient Clinical Evidence), MDCG 2020-13 (CEAR Template), MDCG 2020-7 (PMCF Plan), and MDCG 2020-8 (PMCF Evaluation Report).
Need Expert Help with Your Clinical Evaluation?
Get personalized guidance on MDR compliance, CER writing, and Notified Body preparation.
✌
Peace, Hatem
Your Clinical Evaluation Partner
Follow me for more insights and practical advice.
