Medical Device Software Under MDR and IEC 62304: Getting to CE-Marking Without Delays

MDR classification: what your software actually is

The Medical Device Regulation classifies products by the risk they carry. For software, specific rules apply — primarily Rule 11 of Annex VIII MDR:

• Class I: software without direct influence on medical decisions — administrative tools without clinical relevance.
• Class IIa: software providing information for diagnostic or therapeutic decisions without direct threat to life or limb on faulty decisions.
• Class IIb: software where a fault can cause serious harm, but not immediate death.
• Class III: software whose faults can be directly life-threatening.

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: the quality management system

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:

• Defined responsibilities (CEO, Quality Officer, Regulatory Affairs).
• Documented processes for development, validation, release, post-market surveillance.
• Risk management to ISO 14971.
• Management of change — every product change passes through a defined release process.
• Improvement processes — CAPAs (corrective and preventive actions).

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.

IEC 62304: the software lifecycle

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:

• Safety classification of the software (A, B, C) by potential harm scope.
• Requirements analysis with traceability to the risk assessment.
• Software architecture documentation at component level.
• Unit and integration testing with traceable coverage.
• Configuration management for code and documentation.
• Problem-resolution process for defects post-release.

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.

Clinical evaluation

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.

Notified Body: selection and process

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:

1. Selection and contract setup (two to four months; waitlists can extend this).
2. Technical documentation submission for review.
3. On-site QMS audit at the manufacturer.
4. Review report with queries and conditions.
5. Remediation and final release.

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.

The three common mistakes of HealthTech startups

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.

How D'Cloud approaches HealthTech projects

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.

Next step

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.

Frequently asked questions

Can a standalone app be a medical device?

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.

How do we handle post-market surveillance?

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.

What does the MDR transition period mean for us?

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.

Can the QMS be operated by external consultants?

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.

How high is documentation effort in ongoing operation?

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.