Recently, we had the opportunity to share our experiences with MDR Class IIa certification at the “MDR & IVDR Treff BW” hosted by BIOPRO Baden-Württemberg. It was a great moment to reflect on our journey – from strategic preparation to ongoing operations.

For us, this process was far more than a regulatory requirement. It laid the foundation on which we now operate as a certified provider of a modular, medical platform – and taught us several key lessons that we’d like to share.

Early strategic decisions: Intended Purpose as the key driver

One of our most important learnings: the Intended Purpose is the central element of any MDR strategy. Before starting technical implementation, we invested significant effort into researching how different formulations would impact risk classification, certification scope, and future expansion options.

Our approach: we carefully examined whether starting in a lower risk class (e.g., MDR Class I) could accelerate our market entry while ensuring a clear pathway to a higher class such as IIa or IIb. We also worded the Intended Purpose so that future feature expansions and new indications could be integrated without triggering a full recertification.

Risk class trade-off: Fast market entry vs. functional scope

For us, starting as MDR Class I was an important foundation – it allowed us to enter the market quickly, build early partnerships, and collect real-world user feedback. At the same time, it came with a strategic trade-off: the functional scope was limited by regulation, and certain clinical use cases and automated decision support features could only be offered after upgrading to Class IIa. This meant we needed a clear roadmap from day one on how to scale to a higher class without restarting from scratch.

Quality Management System (QMS) as a strategic asset

An ISO 13485-certified QMS is more than a regulatory hurdle – it is the foundation for reproducible quality. We started early with building a digital, audit-proof QMS that integrates development, support, and regulatory processes.

Our lessons learned: treat the QMS as a tool for efficiency and traceability, not just a compliance checkbox. Align development and regulatory teams in the same workflows to avoid information silos. Digital document control and automated traceability of software changes have significantly reduced our audit workload.

Technical documentation: Realistic effort assessment

Technical documentation is the core of the certification process. For us, the key was to document continuously rather than trying to compile everything at the end.

Our concrete learnings: document and risk-assess every function, interface, and data flow. Regularly monitor third-party components such as wearables for changes and update the risk assessment accordingly. Follow a strict internal rule: “No release without updated documentation.”

Complexity in product systems: Mind Article 22

MDR compliance becomes particularly challenging when multiple products are combined into a system or treatment unit. In our modular platform – integrating a variety of measurement devices – this is everyday reality.

Our experiences: consider Article 22 MDR early in your architecture planning. Clearly define contractual responsibilities for each component. Establish processes to respond quickly when partner products change.

Working with the Notified Body: Partnership over formality

Selecting a Notified Body with proven digital health expertise accelerated our process significantly. We learned to communicate proactively and make constructive use of potential interpretation leeway.

Practical tips: secure audit dates well in advance – waiting times can be several months. Maintain an “audit-ready” documentation set at all times. Treat feedback from the Notified Body as an opportunity to improve processes.

Viewing MDR as a USP

MDR Class IIa certification is undoubtedly a challenge – especially in preparation and in ongoing operations. For us, it is also a clear competitive advantage. By certifying our API for connecting third-party systems, we can support completely different use cases at the same time – for example, a pregnancy risk monitoring app in partnership with HiBaby and, in parallel, clinical monitoring for chronic diseases. This enables us to serve multiple market segments with a single certified architecture, turning our product into a platform business rather than a single-purpose solution. A well-researched and strategically worded Intended Purpose becomes a differentiator that builds trust with partners and customers.

Conclusion

MDR certification is not a one-off project – it is a continuous process. For us, the key was to see regulatory requirements not as a brake, but as a framework for shaping quality, safety, and innovation. Our most important takeaways can be summed up in three points: plan early – align Intended Purpose and product strategy from the start; integrate – treat QMS, documentation, and development as a single unit; think long-term – not just meet MDR requirements, but leverage them as a market advantage.