By Clare Harney, Principal Advisor, Santegic
If you're building Software as a Medical Device and you've started looking seriously at ISO 13485 certification, you've probably already discovered something uncomfortable: the standard wasn't written with software in mind.
ISO 13485 is a rigorous, well-established framework for quality management in medical device manufacturing. But when you apply it to a SaMD product; a clinical decision support tool, a diagnostic application, an AI powered patient monitoring system; you're not implementing only one standard. You're navigating the intersection of several simultaneously, while also trying to provide a product and, in many cases, secure your next round of funding.
That combination of pressures is where most digital health companies run into difficulty. Not because the regulatory framework is unreasonable, but because the path through it is genuinely complex and the cost of getting it wrong is high.
ISO 13485 doesn't exist in isolation for SaMD companies. It sits alongside IEC 62304, which governs the software development lifecycle; ISO 14971, which covers risk management; IEC 62366, which addresses usability engineering; and, for the European market, EU MDR 2017/745 and its associated MDCG guidance documents.
Understanding how these standards interrelate, where they overlap, where they create additional obligations, and how to build a Quality Management System is key. A QMS and Technical File that satisfies all of them coherently requires expertise that most product teams don't have in house. The most common consequence is gaps. Not deliberate non-compliance, but honest omissions that tend to surface at the worst possible moment: during a notified body audit, or when a prospective client's procurement team requests your technical documentation.
Before any documentation work begins, there's a more fundamental question that SaMD companies frequently underestimate: does your software qualify as a medical device, and if so, at what classification? Can you sufficiently justify that classification with an intended use statement that informs all future claims you can make about your software benefits.
Under EU MDR Rule 11, the classification logic for software is not straightforward. The same type of product can fall into Class IIa, IIb, or Class III depending on factors including the severity of the conditions it addresses and the directness of its impact on patient outcomes when it works as intended, but also in the case that things don’t go as intended. Getting this wrong determines your conformity assessment route, your notified body obligations, and your timeline to market.
For AI and machine learning-based SaMD, there's an additional layer. Continuously learning systems introduce ongoing post-market validation requirements and the expectation of Predetermined Change Control Plans. The regulatory landscape here is still evolving, but the direction of travel is clear: regulators expect manufacturers to demonstrate control over adaptive systems across their full lifecycle, not just at the point of initial approval.
A compliant QMS and Technical File for a SaMD product involves not just the Quality Manual and core procedures, but a complete Technical File, a risk management file, software lifecycle documentation, clinical evaluation plans and records, and an operational post-market surveillance and post market clinical follow-up framework. These aren't one off deliverables. Post market clinical follow up, Periodic Safety Update Reports, and CAPA management need to run continuously after certification, post market surveillance is a living thing! Many organisations achieve certification and then find themselves underprepared for the ongoing operational cadence it demands.
This is why the design of the QMS matters as much as its content. A system built around templates that don't reflect how your organisation actually works will create compliance theatre rather than genuine quality management, and experienced auditors can tell the difference.
Certification is a means to market access. For a digital health startup or scaleup, compliance timelines don't exist independently of funding rounds, product launches, and commercial milestones. A pathway to ISO 13485 and MDR compliance that takes 18-24 months without specialist support, may be commercially untenable for a company that needs to demonstrate regulatory progress to investors within the next six months.
Regulatory advice that ignores the realities of funding, launch pressures and resource constraints isn't useful regardless of how technically correct it is. Accelerating the timeline requires a structured approach, pre-built frameworks calibrated to SaMD requirements, and embedded support that allows a small team to focus on building their product while the compliance infrastructure develops alongside them.
If you're at the beginning of this process, the most valuable first step is an honest gap assessment: mapping your current state and plans against the applicable standards, clarifying your classification, and producing a prioritised roadmap with realistic effort estimates.
That clarity is what allows a digital health company to approach certification as a managed programme. The standards are demanding but achievable, and for companies that approach it well, ISO 13485 and MDR certification becomes a genuine competitive differentiator, providing evidence of a quality culture that investors, healthcare system clients, and clinical partners can rely on.
If you'd like to talk through where your organisation stands, Santegic would be happy to help. Book a call with Clare and we can start mapping your path to certification.
Santegic Advisory works with digital health companies to accelerate their path to ISO 13485 certification and EU MDR compliance. To learn more or book a discovery call, visit santegic.com.
One conversation. The right expertise.
