The Medical Device Regulation classifies products by the risk they carry. For software, specific rules apply — primarily Rule 11 of Annex VIII MDR:
For most HealthTech startups, products land in Class IIa. A digital symptom-assessment tool issuing a recommendation is IIa. A diabetes-management system with insulin-dose suggestion is more likely IIb or III — depending on the specific logic.
The class determines whether a Notified Body must be engaged (mandatory from Class IIa) and what scope the technical documentation covers.
ISO 13485 is the international standard for quality management systems specific to medical devices. It defines how an organization structures processes, roles, documentation, risk management, and continuous improvement to demonstrably develop medical devices of reliable quality.
For a startup, this means a quality management manual containing at minimum:
Standing up an ISO 13485 QMS typically takes six to nine months. A specialized consultant accelerates the work by two to three months relative to a full internal build.
Where ISO 13485 governs the organization-wide QMS, IEC 62304 is the specific standard for software development in medical devices and standalone medical device software.
Core requirements:
In practice, IEC 62304 drives substantially more documentation obligation than a comparable B2B web application. That is not ritual — the documentation is the foundation of certification by the Notified Body.
From Class IIa onward, MDR requires a clinical evaluation: evidence that the product fulfills its purpose safely and effectively. For software without direct patient contact, the evidence may come from literature review. For software with diagnostic or therapeutic function, prospective clinical investigations are often required.
Clinical evaluation is often the time-critical element of certification — study design, ethical approval, and recruitment take time. A realistic window: six to twelve months in addition to technical development.
For Class IIa and above, a Notified Body must audit both technical documentation and the QMS. In Europe, common examiners include TÜV SÜD, TÜV Rheinland, DEKRA, and several smaller bodies.
Typical flow:
Total duration from engagement start to CE certification: typically six to twelve months. Added to the prior development phase, the overall first-certification window lands at twelve to eighteen months.
First mistake: QMS build deferred to project end. The consequence: when the MVP is ready, the complete development documentation must be reconstructed — under time pressure, often with gaps, expensively. Recommendation: stand up ISO 13485 base structures on day one, parallel to product development.
Second mistake: classification not reliably established early. Many startups assume Class I for speed-to-market and are reclassified to IIa by the regulator or the Notified Body. The rollback typically costs six to twelve months. Recommendation: a qualified Regulatory Affairs advisor assesses class in the first month.
Third mistake: development partner without MedTech experience. Most software suppliers have experience with standard B2B products, not with IEC 62304. The engagement works, but requires strong internal regulatory expertise. Recommendation: when selecting a partner, specifically ask about experience with medical device software.
Our approach on medical device software: work contract with clearly bounded sprint packages. IEC 62304 documentation from the first sprint — requirements, architecture, tests, traceability matrix. Close coordination with the customer's Regulatory Affairs team or an external QMS consultant.
Production data in EU regions, preferably with HDS certification or ISO-27001-certified European providers. Development with synthetic or pseudonymized data. No personal health information in test or development environments.
Standard fifteen days of free post-delivery bug-fixing, followed by a maintenance contract that explicitly includes patch management post Notified Body release. Regulated engagements sit within our software development services, flanked by cybersecurity and consulting and training services — a QMS-conformant development process functions only as a combined package, not as an isolated measure.
If you have a HealthTech product in planning or early development, the most important early step is classification and QMS base-structure setup. Book a complimentary online scoping session — we bring experience with medical device software and frame realistic time and resource planning. The related pieces on GDPR-aligned product development and NIS2 and ISO 27001 in software supply chains add the legal and technical flanking building blocks that medical device software requires from the outset.
Yes, if it carries a medical intended use. A step counter without clinical interpretation typically is not a medical device. An app identifying atrial fibrillation in an ECG and issuing a recommendation is, with high probability, Class IIa.
An under-planned component. MDR Articles 83 to 86 require active post-market monitoring — reporting of serious incidents, periodic safety reports, trend analysis of customer feedback. Operationally, a team or process running continuously — not a one-off effort.
Transition periods for existing MDD-certified products have been extended several times. For new developments, MDR applies directly. Early engagement with a Notified Body and a regulatory advisor avoids surprises.
Operationally yes, responsibility no. QMS responsibility sits with the manufacturer (typically with the CEO). External support for setup and operation is common and sensible — full outsourcing does not work because certain roles (Quality Officer) must be filled internally.
In a well-established structure, roughly fifteen to twenty percent of total development effort. Substantial, but not dominant. In a poorly set-up structure, the share grows considerably higher as rework and retrospective documentation accumulate.
© 2026 D'Cloud Software & Digital Agency. All rights reserved.