Medical Device Product Development: An EU MDR-First Guide

Around three in four medical-device start-ups never reach the market they were built for. According to the Focused Ultrasound Foundation, the failure rate sits near 75 percent. Most of those failures happen at the regulatory file, the design history, or in the gap between an idea that worked in the lab and one that holds up to a notified body audit.

This raises a practical question:
But how do you actually build a medical device, from idea to CE mark, MDR-ready, audit-ready, without the multi-year, multi-million-Euro detours that sink most projects?

This guide walks through medical device product development the way it actually plays out for EU and DACH start-ups: five phases, with the EU MDR sitting at the centre of the framework and not the end. We cover how the build-on-top capability stack (embedded firmware, AI and ML, sensors, companion app, cloud, clinical data) changes the sequence; where teams burn most of their budget and the regulatory deliverables you cannot leave for the last six weeks. By the end you will have a workable mental model for what every phase produces and what every phase costs when it slips.

Table of Content

Why Most Product-development Frameworks Miss the EU Reality

The phrase “5 phases” usually maps to the FDA’s Design Control flow, with 510(k) submissions and predicate devices framing every decision. That works when the market is the United States. For a Berlin, Germany or EU start-up planning to CE-mark their device for the market, the same framework leaves out the regulatory questions that decide the project.

The EU Medical Device Regulation, Regulation 2017/745, reshapes the path in three concrete ways.

First, classification is more demanding. Annex VIII and especially Rule 11, covering software intended to provide information used for diagnosis or treatment, push a meaningful share of digital health products up to Class IIa or IIb. A US-style assumption that “software is a low-risk add-on” breaks at the first notified body engagement.

Second, the notified body becomes a primary partner rather than an afterthought. For any device above Class I, a notified body audits both your quality management system and your technical documentation. Lead times are typically 12 to 18 months from engagement to certification. Picking and shortlisting a notified body belongs in Phase 2, before 4.

Third, clinical evidence under MDR is heavier than the old MDD or FDA equivalents. Article 61 and the corresponding MDCG guidance, including MDCG 2020-13 on Clinical Evaluation Assessment Reports and MDCG 2021-24 on classification, define a clinical evaluation pathway with real bite. Equivalence claims are harder to defend and literature reviews alone are rarely enough above Class IIa.

-> In short: a generic 5-phase framework can get you a working prototype. It will not get you a CE-marked product, because it does not account for the regulatory steps that have to start in Phase 1.

What To Do:

Write your intended use statement in week one and freeze it before any architecture decisions.
Run a notified body shortlist at Phase 2: names, capacity, scope codes, current backlog.
Read MDCG 2019-11 and MDCG 2020-3 once and use them. They shape more decisions than regulatory texts.

Phase 1: Discovery and Feasibility

Phase 1 is where most projects either set themselves up well or sentence themselves to a hard slog later in medical device product development. The work splits into two parallel threads: clinical and commercial validation on one side, classification and regulatory thinking on the other.

On the clinical and commercial side, the standard procedures apply. This means defining the user, finding the actual clinical problem, mapping the existing solutions, talking to clinicians rather than just other founders, validating willingness to pay and deciding on your launch market. If you are in the EU, narrow it down to one or two member states for the first CE-marking cycle. None of this is specific to medical devices. What is medical device specific is the document discipline and every interview, assumption and decision must be recorded.

The piece most early-stage teams underweight is classification. Under MDR, your intended use statement determines your class. Your class determines your conformity assessment route, the depth of your technical documentation, the level of clinical evidence and the kind of notified body you engage. A single sentence in your intended use, for example whether the device “monitors” a parameter or “diagnoses” a condition, moves you from Class I to Class IIa or higher.

Annex VIII has 22 classification rules. For software, Rule 11 is the one that matters most. For wearables and sensors, Rules 9, 10 and 12 are the usual deciders. Run the classification exercise in Phase 1 as a working hypothesis you defend through every later phase.

-> In short: Phase 1 produces an intended use statement, a working classification and a notified body shortlist. Skip any of these and Phase 4 turns into a year of expensive corrections.

What To Do:

Draft the intended use statement before any technical specs.
Run a provisional MDR classification under Annex VIII and document the reasoning.
Build a notified body shortlist with at least three names, ranked by relevant scope codes and current backlog.

Phase 2: Concept and Prototype

Phase 2 turns the validated need from Phase 1 into something you can hold, demo and break. The deliverable is a proof of concept for medical device product development. Enough working hardware and software to test the riskiest assumptions and run user studies with clinicians, well short of a final design or a sterile production unit.

Two parallel workstreams matter here.

The first is technical feasibility. For digital-health products that involve sensing, this is the moment to evaluate sensor candidates, signal quality, power budgets and the data path from device to backend. For pure software products, it is the moment to validate the algorithm with the actual data sources you will use in production. Either way, the goal is to retire the technical risks that would make Phase 3 infeasible, before you commit to a full design.

The second is regulatory scaffolding. Phase 2 is where the QMS work starts, anchored on ISO 13485:2016 and the risk file opens here too. ISO 14971:2019 is the governing standard and your first hazard analysis should be in place before any code is checked in or any board is fabricated. Late risk analysis is one of the single biggest budget burns in this industry.

This is also where the notified body shortlist becomes a real conversation. Most notified bodies will not formally engage until you have a QMS draft and a credible product story, but you should be writing to them in Phase 2 to understand their capacity and timeline. Booking a slot 12 months out is normal under current MDR conditions.

We have seen this play out cleanly with a stealth-stage founder building a 3 mm wearable sensor that sits under a smartwatch. A Technical Feasibility Assessment in Phase 2 locked the intended use, the MDR classification and the sensor evaluation in six weeks rather than the six months an open-ended discovery would have taken. It also gave the founder a defensible product story to take into Phase 3.

-> In short: Phase 2 retires technical risk and opens the regulatory documentation tree. If your QMS scaffold and risk file do not exist at the end of Phase 2, your Phase 3 will not be MDR-aligned.

What To Do:

Define which assumptions the prototype must validate and build the smallest version that does that.
Open the QMS (procedures and templates) and the risk file in parallel with the prototype build.
Make first contact with two or three notified bodies on the Phase 1 shortlist.

Phase 3: Design and Development (the Capability Stack)

This is the biggest phase, the longest phase and the one where the build-on-top capability stack actually shows up. Generical medical device product development treats Phase 3 as one block, “Design and Development.” That framing misses what makes modern medical devices hard.

Today a medical device usually arrives at the patient as a coordinated set of layers. From the bottom up, that set typically includes:

Layer 1: Hardware. Sensors, microcontroller, power, enclosure, biocompatible materials. Governed by IEC 60601 (electrical safety) and ISO 10993 (biocompatibility).

Layer 2: Embedded firmware. RTOS, drivers, communication stacks (BLE, GSM, Wi-Fi), power management. Governed by IEC 62304 (medical device software lifecycle) and increasingly by cybersecurity expectations under MDR Annex I.

Layer 3: Sensor signal processing. Filtering, calibration, feature extraction. Often a separable software module that, depending on classification, falls under IEC 62304 software safety class B or C.

Layer 4: AI and ML inference. Classification, prediction, drift monitoring. Adds Predetermined Change Control Plans, validation against held-out data, and ongoing performance monitoring obligations.

Layer 5: Companion app. Mobile or desktop interface for patient or clinician. This is the layer that most often triggers MDR Rule 11, pushing the whole product up to Class IIa or higher even when the hardware on its own would have been lower.

Layer 6: Cloud and clinical data. Patient data backend, clinician portal, registry feeds. Adds GDPR obligations and in practice, ISO 27001 alignment for credibility.

Layer 7: Regulatory wrap. Design History File, technical documentation (Annex II and III), clinical evaluation report, post-market surveillance plan. Sits above everything else and references every layer below.

The point of laying out the stack this way is to make a strategic argument. Every layer you add compounds regulatory mass. A wearable with no app sits in one regulatory shape, add the app and the same product moves into a different one and add an ML inference layer and it moves again. There are multiple projects where the founders price the build correctly for layers 1 and 2 and are stunned by what layers 4 to 7 cost.

The correct Phase 3 sequence takes this into account. First, architect the full stack on paper. Decide which layers are truly necessary for the initial CE-marked release and which can be deferred until v2. Build the layers in order, validating each one against the design inputs that drive it.

Case study: Everon

The Everon medical device product development is now a voice-controlled GSM communicator combined with a BLE wristband for home nursing. It is a prime example of stack thinking done right. The hardware (the wristband and communicator), the embedded firmware (the BLE and GSM stacks), the sensor signal processing (fall detection), the companion app (for caregivers) and the cloud (the home nursing dashboard) all integrate into a single CE-marked product. Each layer was specified and tested against MDR-aligned design controls and the technical documentation cleanly maps to the layered architecture. Each layer of the architecture is also documented in the technical file, risk analysis and verification plan.

-> In short: Phase 3 should be designed around the capability stack. Treating it as a single block of “engineering” is what underprices most projects.

What To Do:

Diagram your capability stack before any sprint planning and mark which layers are in scope for the first CE release.
Map each layer to its standards (IEC 62304 software class, IEC 60601, ISO 10993, GDPR, ISO 27001).
Tie design inputs to specific layers in your DHF, so traceability later in Phase 4 actually holds.

Phase 4: Verification, Validation and the EU Regulatory Path

Phase 4 is where the engineering you produced in Phase 3 meets the audit. Verification and validation generate the evidence and the conformity assessment route turns that evidence into a CE mark.

Verification answers “did we build the device right?” It tests against design specifications. Validation answers “did we build the right device?” It tests against user needs and intended use. The IEC 62304 software lifecycle, ISO 14971 risk management, IEC 60601 electrical safety, ISO 10993 biocompatibility and your QMS procedures all converge here. Each layer of the stack you built in Phase 3 needs its own verification and validation evidence.

The piece most teams underestimate is clinical evaluation. Under MDR Article 61 and MDCG 2020-13, the clinical evaluation report goes well beyond a literature review. The work it does is to build a structured argument that your specific device, with its specific intended use, is safe and performs as intended. For Class IIa devices, equivalence claims can sometimes carry it. For Class IIb and III, you almost always need clinical investigation data. Plan this as a Phase 3 activity at the latest, with patient recruitment running in parallel to engineering.

The conformity assessment route follows classification in medical device product development. Class I devices are self-certified and registered. Class I sterile and measuring devices, as well as Class IIa and above, go through a notified body. For software in classes IIa and above, a full QMS audit against ISO 13485 is expected, as well as a technical documentation review. Under current MDR conditions, the full cycle from initial engagement to CE certificate typically takes 12 to 18 months, and joining the queue late can delay your launch by up to a year.

-> In short: calling Phase 4 “testing the device” undersells it considerably. The work here is to generate the documented, traceable evidence that lets a notified body sign off. Without the clinical evaluation, the technical documentation and the QMS audit closed, there is no CE mark.

What To Do:

Build your verification and validation plan from the layered architecture, not from a generic checklist.
Start the clinical evaluation in Phase 3.
Engage your notified body 12 to 18 months ahead of your target CE date.

Phase 5: Launch and Post-market Surveillance Under MDR

Phase 5 is often where guidance stops. However, under MDR, things become much more challenging than people expect in their medical device product development.

Post-market surveillance under MDR is structurally different from FDA post-market obligations. Articles 83 to 86 of the regulation, plus MDCG 2022-21, lay out a PMS system, a PMS plan and for Class IIa and above, a Periodic Safety Update Report that has to be evaluated by your notified body. Post-Market Clinical Follow-up is mandatory for most devices above Class I, the PMCF plan is part of the clinical evaluation file submitted at certification and updates run on a defined cadence.

EUDAMED, the European database, is the backbone of registration and reporting. All your UDI, device, certificate, incident and PMS results information flows through it. The vigilance reporting timelines are tight: serious incidents must be reported within 15 days, while deaths and serious public health threats must be reported within two days.

For software devices, the post-market layer also covers cybersecurity vigilance and AI or ML performance monitoring where applicable. A predetermined change control plan gives you the ability to update your model without re-certifying, provided it was filed and approved at original certification. Plan the PCCP at Phase 3.

-> In short: Phase 5 under MDR runs as ongoing operational work, with PMS, PSUR, PMCF and EUDAMED reporting on defined cadences for the life of the product.

What To Do:

Resource a PMS function from day one of launch with clear ownership and defined cadence.
Connect your complaint handling, vigilance reporting and CAPA system to one source of truth.
Schedule the first PSUR review at month 12 (Class IIa) or month 6 (Class IIb and III).

Where Medical-device Product Development Teams Burn Budget

Five failure modes recur across the projects we have worked on. None of them are unusual and they can all be avoided by adopting a few specific habits.

1. Misclassified intended use

The intended use statement quietly drifts during Phase 2 or Phase 3 as features are added. A Class IIa product creeps toward Class IIb. The team only finds out at notified body audit, when six to twelve months of work has to be re-documented and sometimes redesigned.

Fix: freeze the intended use statement in Phase 1 and treat any change to it as a formal change request reviewed by your regulatory function.

2. Risk file built backwards

The ISO 14971 hazard analysis begins in month 18 because 'we will do it before the audit'. The risk file is reconstructed from memory and the traceability between hazards, controls and design outputs is not actually maintained. The notified body identifies the gaps. Three to six months of remediation are required.

Fix: open the risk file in Phase 2, before the first sprint and maintain it as a living document.

3. DHF as documentation theatre

Although the Design History File appears complete and every section heading is filled in, the traceability from design inputs to outputs to verification does not survive careful scrutiny. During an audit, the technical documentation reviewer pulls one thread and the rest unravels.

Fix: maintain DHF traceability continuously, not in a sprint before the audit. Use a tool (any tool) rather than a folder of Word documents.

4. MDD legacy under MDR: the Rule 11 surprise

in medical device product development a device certified under the old MDD enters the MDR transition window. Previously classified as Class I, the software component now falls under Rule 11 and is reclassified as Class IIa or IIb. A notified body must be engaged, the technical documentation revised to the structure of MDR Annexes II and III and the clinical evaluation updated. This process takes twelve to eighteen months, often while the legacy device is on a deprecation timeline.

Fix: re-classify every MDD-era product under MDR rules now, before the certificate expires.

5. Clinical evidence underestimated

The team plans to conduct a literature review and make an equivalence claim, but the notified body has asked for actual clinical investigation data. This adds eighteen to thirty-six months to the launch timeline.

Fix: validate the clinical evidence strategy with the notified body in Phase 2, at the latest by submission.

-> In short: the five failure modes are well-documented and individually avoidable. They become fatal when a team accumulates two or three of them in parallel.

FAQs: Questions Teams Keep Asking us in Medical Device Product Development

Q1: How long does CE marking for a medical device actually take?

A1: For a Class IIa device starting from a working prototype, it takes twelve to twenty-four months from engagement with the notified body to receiving the certificate, assuming that the technical documentation and clinical evaluation are in order. The process for Class IIb and III devices takes longer, often two to three years. Most of the variance is in clinical evaluation and the time it takes to get through the notified body queue, rather than in the engineering itself.

Q2: When do I need to engage a notified body?

A2: In medical device product development any device above Class I and for Class I sterile and Class I measuring devices, the initial engagement should happen in Phase 2 at the latest, both because the queue is long and because the notified body’s scope codes and capacity will shape your shortlist. By Phase 3, your selected notified body should be aware of your project and timeline.

Q3: Is my software a medical device?

A3: If it is intended to provide information used for diagnosis, prediction, prognosis, treatment monitoring, or treatment recommendation, then under MDR Rule 11 it is almost certainly a medical device and most software falls into Class IIa or higher. MDCG 2019-11 is the operative guidance. Mobile apps, web portals and AI or ML inference layers all qualify under the same rule.

Q4: What is the biggest difference between MDR and the old MDD?

A4: There are three things to consider, in order of practical impact. First, software classification: Rule 11 pushes most digital health products up by one or two classes. Second, clinical evidence: equivalence claims are harder to defend and clinical investigation is required for most Class IIb and all Class III devices. Third, post-market obligations: PMS plan, PSUR, PMCF and EUDAMED reporting are heavier and more structured. Together, these change the cost shape of a CE-mark cycle compared with the MDD era.

Closing Thoughts

Medical device product development is one of the few engineering fields where the regulatory and the technical have to be designed together. Separating them is what makes projects run for an extra year or two. The teams that ship into the EU market consistently treat the EU MDR as a Phase 1 design constraint that shapes every later decision.

If you are at any of these phases and want a second pair of eyes on classification, your medical device, on the capability stack, or on the regulatory path, that is exactly the work our MedTech Product Development Service exists for.