How we achieved MDR IIb certification: The Infermedica story
)
How does a healthcare AI solution earn one of the most rigorous certifications in Europe?
Looking back at our MDR process, the single biggest challenge was aligning the evolving AI-based components with the regulatory expectations for safety, performance, and transparency. This difficulty was not only technical but also organizational, because it required us to balance innovation with compliance in a fast-changing environment.
In this article, we share the key challenges we faced, the lessons we learned, and the advice we’d give to anyone walking the same path.
Read on to discover the highs and lows in our story of succeeding to get MDR Class IIb certification (with zero non-conformities).
)
At a glance:
What makes getting MDR Class IIb so challenging?
Navigating the gray zone of AI regulation
AI technologies still operate in a kind of regulatory "gray zone." When it came to applying MDR requirements to machine learning systems, there was often a lack of clarity: How do you demonstrate transparency in AI outputs? How do you validate performance in a way regulators will accept? With very few precedents to rely on, we had to carefully interpret emerging guidance and adapt it to our own use cases—often breaking new ground along the way.
It is important to note that the Medical Device Regulation (MDR) only partially addressed the specifics of software. Its core provisions were still designed primarily with “traditional” medical devices in mind, not adaptive, data-driven systems like AI. In practice, most MDR requirements focus on design, safety, clinical evaluation, and post-market surveillance for mechanical or electronic devices, rather than for algorithms. Moreover, there are still no dedicated guidelines specifically for AI, and one of the few documents comparing MDR requirements with the AI Act — Interplay between the Medical Devices Regulation (MDR) & In Vitro Diagnostic Medical Devices Regulation (IVDR) and the Artificial Intelligence Act (MDCG 2025-6 / AIB 2025-1) — does not fully resolve the challenges of implementing AI in healthcare. Remember, interpretation is your responsibility. Everything not explicitly covered by MDCG must be your justified interpretation. As the manufacturer, you carry the responsibility—use methods that support the clinical purpose and patient safety (risk-based approach, adequate clinical validation, robust post-market surveillance).
💡 Advice
Gather as many best practices as possible: review literature, industry reports, and case studies of similar AI implementations. Document your sources and key learnings. Systematically map requirements from ISO/IEC standards (e.g., safety, risk management, quality management, software engineering), IMDRF documents (SaMD definitions, clinical evaluation), and MDCG guidance. Build a traceability matrix linking requirements to evidence. If MDCG does not address a particular question, refer to guidelines from FDA, NHS/MHRA, or other recognized authorities. Having a solid reference from the FDA is better than having no reference at all.
Evidence generation and documentation
Proving clinical safety and effectiveness wasn’t straightforward. We needed to show, in a structured and reproducible way, that our platform consistently delivers accurate results. This required us to design comprehensive verification and validation strategies and to build test plans that would satisfy not only our engineers but also the expectations of regulatory auditors. Balancing these two perspectives was demanding, but it was essential to build trust in our solution.
In line with Article 61 of the MDR, our approach to clinical evaluation combined several complementary evidence sources:
We systematically reviewed relevant, up-to-date publications concerning the device’s safety profile, performance characteristics, design features, and intended purpose.
Critical review of all available pre-clinical data, including results of internal testing, performance evaluations, and analytical validation. We also conducted two retrospective studies, analyzing real-world datasets to assess diagnostic and triage accuracy.
We performed a structured assessment of similar devices available on the market, comparing their safety and performance profiles with our own results to support the argument for clinical equivalence where appropriate.
By triangulating these data sources, we were able to present a robust, well-documented clinical evaluation that demonstrated our platform’s safety and effectiveness without requiring new prospective clinical investigations.
💡 Advice
Collect all available clinical and non-clinical data early and organize it systematically. Classify each dataset by its potential use case: some evidence will be more relevant for demonstrating clinical benefits, while other data will be better suited for proving safety or risk mitigation. Your goal is to build a diverse, complementary evidence package rather than rely on a single study type. Use retrospective studies, literature reviews, bench testing, and market comparisons together to form a robust argument. A well-structured, multi-source evidence base not only satisfies regulatory expectations but also strengthens the credibility of your product in front of clinicians and business stakeholders.
)
Not all AI is created equal. We’ve got MDR Class IIb certification.
Building trust in healthcare AI: our Medical Guidance Platform is now MDR Class IIb certified, the highest level for software of its kind.
Read the article →
Cross-functional coordination
Achieving MDR compliance required close collaboration between medical experts, software engineers, and regulatory quality managers. This collaboration was highly time-intensive, and misalignments in priorities or interpretations could easily create bottlenecks.
For this reason, it is worth formally establishing a dedicated cross-functional team early in the process. As a regulatory manager, you cannot afford to communicate with dozens of stakeholders for every question or deliverable—efficiency is crucial. Equally important is to define the scope of competencies, responsibilities, and decision-making authority from the start.
💡 Advice
Build cross-functional squads early, with shared goals and regular alignment between medical, technical, and regulatory teams. Assign one point of contact (POC) per function (e.g., clinical, engineering, product, customer success) who will be responsible for gathering input within their team and providing consolidated feedback. Work with leadership to clarify who owns which decisions—there will be many, from risk classification to clinical evidence strategy to software verification scope. Having this governance framework in place prevents decision paralysis, minimizes rework, and ensures accountability.
Strategic uncertainty
We also faced uncertainty around timing and regulatory strategy. Deciding which functionalities should remain in scope for certification versus which should be excluded to avoid higher regulatory burdens was a recurring challenge. These decisions directly affected both product development and market positioning.
In reality, it is rarely possible to include every feature you would like in the initial certification cycle. A pragmatic approach starts with a clear specification, a structured requirements analysis, and a realistic assessment of the costs and resources the organization can commit. Product strategy must go hand in hand with regulatory strategy, and sometimes the two need to be adjusted to each other to create a feasible roadmap.
In our case, with the Medical Guidance Platform, we succeeded in building a modular solution. This architecture allowed us to offer multiple modules and functionalities under one regulatory “umbrella,” providing flexibility to expand capabilities over time without triggering a full recertification effort for every single feature. This modular approach proved essential for managing both compliance obligations and time-to-market.
💡 Advice
Don’t treat regulatory scoping as a one-off decision. Engage product, clinical, and regulatory teams early to prioritize features that are core to your value—and be prepared to postpone or redesign others.
Finding the right Notified Body
Another major hurdle was identifying a Notified Body that truly understood what we were building and was able to offer a process that was both efficient and reasonably priced. Many potential partners either lacked the expertise to assess AI-based medical devices effectively or proposed timelines and costs that were prohibitive. This search consumed significant time and effort and highlighted the immaturity of the ecosystem for certifying advanced AI technologies.
💡 Advice
Choose a notified body that not only understands MDR but also has hands-on experience with AI and digital health products. A good partner will ask the right questions, provide clear feedback, and guide you through gray areas instead of just checking boxes.
)
Defining validation thresholds
Setting validation thresholds was also complex. We needed to ensure the highest levels of patient safety while at the same time avoiding excessive over-triage, which could reduce the product’s utility and unnecessarily burden healthcare systems. Finding this balance between safety and usability was one of the most delicate aspects of our work.
At Infermedica, we have a significant advantage: over the past 13 years, our medical team has built a comprehensive medical knowledge base and an extensive library of more than 10,000 curated test cases. This allowed us to define thresholds based not only on theoretical risk but also on robust, empirical evidence. We were able to validate these thresholds against a very large and diverse set of scenarios, which strengthened our confidence that they reflect real-world performance.
This extensive test coverage gave us the ability to demonstrate to auditors and stakeholders that our thresholds were both clinically justified and statistically sound, striking the right balance between patient safety, accuracy, and usability.
💡 Advice
Involve diverse stakeholders when setting thresholds. Regulators, clinicians, and product teams should all agree on the acceptable balance between safety and practicality.
A pleasant surprise in usability testing
Despite the many challenges, one of the most rewarding and pleasant surprises came during our usability testing. Users—including senior citizens, often assumed to struggle with digital tools—handled the product with remarkable ease and confidence. Their positive engagement and intuitive use of the system exceeded expectations and validated the product’s design in a very human and encouraging way.
💡 Advice
Don’t overlook real-world testing with diverse user groups. Insights from patients and clinicians can validate your design in ways that technical checks can’t.
Concluding our MDR Class IIb journey
Ultimately, the greatest challenge was not a single obstacle but the convergence of new AI-specific expectations with traditional medical device rigor, coupled with external and internal complexities around benchmarking, validation thresholds, and partner selection.
At the same time, the enthusiasm and adaptability of real users reminded us of the value and impact of what we are building. It was this balancing act—between pushing forward and proving compliance—that defined the hardest part of our MDR journey.
BL/EN/2025/09/29/1
)
)
)