** **Mr. Ziegler, can you explain what exactly is meant by "software as a medical device"?
Josua Ziegler: Certainly. Software as a Medical Device (SaMD) refers to software applications with a medical purpose - for instance, a digital therapy for anxiety that's prescribed by a physician and reimbursed by insurance. The key distinction from general health or wellness apps is that SaMD must deliver clinically validated medical recommendations, often supporting diagnosis, treatment, or monitoring.
** **How long does the typical certification process take?
Josua Ziegler: Expect 12 to 18 months if you start from scratch. That might sound long, but it's necessary to ensure all regulatory requirements are met. Teams with prior experience in ISO 13485 or IEC 62304 may speed this up, but even minor gaps in risk management or documentation can cause significant delays. The process is designed to protect patient safety and ensure product reliability.
** **What are the core requirements for certification?
Josua Ziegler: Certification requires several components. You need a robust Quality Management System (QMS), detailed technical documentation, and a clearly defined software development lifecycle. Documents include a Clinical Evaluation Report, Risk Management File, Software Architecture, and test protocols. You also need to appoint a "Legal Manufacturer" and designate a PRRC (Person Responsible for Regulatory Compliance). Each of these steps is essential for compliance.
** **How does this translate into day-to-day development?
Josua Ziegler: Development must follow a structured and traceable process. Every requirement is given a unique ID so we can link specific pieces of code back to clinical needs. We implement quality checks throughout - using the four-eyes principle, regular code reviews, and static code analysis. This traceability isn’t just bureaucratic - it ensures that any issue in production can be quickly understood and resolved.
** **What are the monetization models for such software?
Josua Ziegler: There are multiple options. For well-defined indications, selective contracts with health insurers work well, especially post-DiGA in Germany. For niche or emerging conditions, partnerships with pharmaceutical companies or co-development models can help fund certification. Direct-to-consumer sales can be an option too, but it requires strong brand trust and patient engagement.
** **What should companies consider before pursuing this path?
Josua Ziegler: A few critical questions: => Do you have team members with regulatory experience (e.g. ISO 13485)? => Is your clinical indication already reimbursed? => Can you fund ongoing compliance for 3-5 years? => Are your internal dev processes ready for audit? Early and proactive contact with regulatory authorities is essential. Also, set realistic timelines with a buffer. Certification is just the beginning - you'll have continuous documentation, reporting, and surveillance obligations.
** **Are there common pitfalls companies should be aware of?
Josua Ziegler: Yes. The biggest one is underestimating the documentation effort. Plan 30–40% of your project budget for regulatory and quality assurance work. Regulatory bodies also have limited capacity, which can slow things down. And remember: even small product updates can trigger re-certification. Think of certification as a continuous process, not a one-time milestone.
** **In conclusion, what are the advantages of being certified?
Josua Ziegler: Certification acts as a trusted quality seal. It tells payers and providers that your product is clinically safe and meets high standards. It opens the door to reimbursement and makes hospital or insurer partnerships possible. Strategically, it forces you to professionalize your development and QA practices, which pays off in scalability and trust.
R2GConnect: Thank you for your insights, Mr. Ziegler. Josua Ziegler: You're very welcome. I hope this gives companies a clearer view of both the challenges and the strategic upside.
Do’s and Don’ts When Certifying Software as a Medical Device ✅ Do’s: => Engage early and proactively with regulatory authorities => Implement a comprehensive Quality Management System (QMS) => Prepare detailed and structured technical documentation (e.g. CER, risk file, software architecture) => Define a clear and traceable software lifecycle with unique requirement IDs => Apply the four-eyes principle in software development => Create realistic, buffer-inclusive timelines for certification => Continuously re-evaluate product changes with compliance in mind => Explore multiple monetization strategies (e.g., insurance contracts, direct-to-consumer, pharma sponsorship)
❌ Don’ts: => Underestimate the scope and effort of regulatory documentation (plan 30–40% of budget) => Ignore ongoing post-market obligations after certification => Rush through the certification process without thorough preparation => Neglect traceability and auditability of software requirements => Skip quality control steps during development => Overlook delays from regulatory body capacity constraints => Undervalue the strategic benefits of certification as a trust-building and monetization tool
Looking to Get Started?
You can benefit from the 1.5-hour MDR Readiness Check offered by Punktum on R2Gconnect. In this hands-on session, the teams help you identify gaps in your SaMD concept and provide a clear, realistic roadmap to certification. Learn more here