Medical Device Development: The 6 Phases From Concept to Market

Not long ago we looked at the medical device companies leading global healthcare innovation, and one thing surfaced in almost every profile. Regulatory readiness was doing as much work as engineering talent. This guide goes a level down, into the process that produces both.
Medical device development is the regulated engineering process that turns a clinical need into a market-authorized product under a quality management system such as ISO 13485. It runs through concept and feasibility, design controls, prototyping, verification and validation, regulatory submission, then post-market surveillance.

What follows walks all six phases, plus the software, hardware, connectivity and compliance with regulatory requirements underneath them. The dates are current too, which matters right now: the FDA’s QMSR took effect in February 2026, and the EU MDR legacy deadlines are close enough to plan around.

Medical device development is the engineering discipline of taking a clinical need to a market-authorized product inside a controlled quality system. The medtech industry also calls it medical device design and development.

What separates a medical device product development process from an ordinary one is traceability. Every design decision has to trace back to a requirement and forward to objective evidence that the requirement was met.

That single constraint reshapes everything. Your architecture, your sprint cadence, your supplier choices, and your test strategy all bend around it.

What the medical device industry counts as a device is wider than most teams expect. A smartphone app that calculates an insulin dose is a device. So is a cloud service that flags an arrhythmia from wearable data. The FDA’s list of AI-enabled medical devices passed 1,400 authorizations at its March 2026 update, with 331 cleared in 2025 alone and the majority in radiology.

What are the medical device classes?

The US Food and Drug Administration sorts devices into three classes by risk, and your class determines almost everything about your timeline and budget.

• Class I (low risk). Bandages, exam gloves, manual instruments. General controls apply, and most are exempt from premarket review.
• Class II (moderate risk). Infusion pumps, patient monitors, most connected devices, the majority of SaMD. Special controls apply on top of general controls, usually via a 510(k). Many monitoring and therapeutic devices are Class II, but classification is device-specific and should be confirmed against the applicable regulation, product code, intended use and technological characteristics.
• Class III (high risk). Devices that support or sustain life, such as implantable defibrillators. These need Premarket Approval (PMA) backed by clinical evidence.

Cross the Atlantic and the scale changes. The EU uses I, IIa, IIb and III under the Medical Device Regulation, and software often lands a class higher than teams predict. Rule 11 of EU MDR Annex VIII pushes much diagnostic and therapeutic software into IIa or above, which pulls a notified body into the project.

SaMD or embedded software: which one are you building?

Software as a Medical Device (SaMD) is software intended for medical purposes that performs its function on its own, without being part of a hardware device. Software in a Medical Device (SiMD), usually called embedded firmware, runs inside the device and controls hardware.

The distinction changes your risk profile. Embedded firmware often has hardware interlocks available as risk controls, so a mechanical pressure relief valve can carry safety weight the software would otherwise carry alone. Standalone software rarely has that luxury, which pushes its safety class upward.

Most modern products are both. A continuous glucose monitor has sensor firmware, a mobile app, a cloud backend and a clinician portal. All of it is in scope, which means medical device app development carries the same design obligations as the hardware.

The medical device product development lifecycle runs through six development phases: concept and feasibility, planning and design controls, prototyping, verification and validation, regulatory submission, then transfer to manufacturing with post-market surveillance. Some teams know it as the medical device new product development process. These activities often overlap and iterate in practice. Organizations may use phase gates, agile increments or other lifecycle models, provided design controls, risk management, traceability, reviews and required evidence are maintained.

Here is the medical device product development lifecycle as a sequence you can plan against:

1. Concept and feasibility. Define the clinical need and intended use. Prove the risky technical assumptions.
2. Planning and design controls. Convert those needs into design inputs. Open the design and development file. Set the regulatory pathway.
3. Prototyping. Build increasingly representative hardware and software. Run formative usability studies.
4. Verification and validation. Prove the design meets its inputs, then prove the device works for real users.
5. Regulatory submission. File a 510(k), De Novo, or PMA in the US. Pursue CE marking through a notified body in the EU.\
6. Transfer to manufacturing and post-market surveillance. Move to pilot then commercial production. Monitor field performance and feed it back.

What happens during concept and feasibility?

Concept and feasibility is where you define the intended use and kill the assumptions that could sink the project later. Medical device concept development is the cheapest stage in which to be wrong, and the one teams compress most often. A phased development approach exists to keep that mistake cheap.

Which is why medical device concept development turns on two questions. What is the intended use statement, and which technical unknowns could make the whole thing infeasible? The second deserves real engineering money. If your device depends on optical sensing through skin, build a bench rig and measure signal quality on real subjects before anyone opens CAD.

The first question deserves even more care, because your intended use statement is the load-bearing sentence of the project. Together with your claims and the device’s technological characteristics, it drives your likely class and regulatory pathway. It also bounds what your labeling can claim. Teams that write it loosely early rewrite their design inputs later.

Planning and design controls: the design and development file

Design controls are the documented design process connecting user needs to design inputs and outputs, then to the evidence that proves them. They are the backbone of the project, and they now live in ISO 13485 clause 7.3 for both US and EU purposes.

It works like this:

• User needs. What the clinician or patient requires, in their language.
• Design inputs. Engineering requirements derived from user needs and regulatory requirements. Testable, unambiguous, complete.
• Design outputs. Drawings, schematics, source code, design specifications, and everything else defining the device.
• Design verification. Evidence that outputs meet inputs.
• Design validation. Evidence that the finished device works for its users in the intended environment.

The design and development file is the compiled record of that chain, and your audit trail for every design decision made. Clause 7.3.10 uses that name, and the QMSR dropped the older design history file (DHF) label, though you will still hear it in practice.

Here is the pattern in projects that go badly. The team treats it as documentation to assemble once the engineering is finished. Then a design change ripples through eighteen months of untracked decisions, and someone spends a quarter reconstructing rationale from Slack threads and old pull requests.

Retrofitting that trail always costs more than building it. Set up a requirements management tool in week one and link every requirement to its test case and its risk control.

How does medical device prototyping work in practice?

Medical device prototyping moves through stages of increasing fidelity, from early design concepts and a proof of concept rig through works-like models to design-frozen pilot units. Each stage answers a narrower question.

• Proof of concept. Does the core mechanism work at all? Breadboards, dev kits, throwaway code.
• Alpha. Integrated function on custom hardware. First PCB spins, first real enclosure, firmware doing the job.
• Beta. Production-intent materials, representative enough for formative usability studies.
• Pilot build. Design frozen and built on the production line: the first market-ready prototype units, used for submission testing.

Design freeze is the milestone that matters most for schedule. After freeze, every change costs you re-verification and possibly a new submission. Before freeze, changes are cheap.

So when do you freeze? Too early and you lock in problems the first prototype never exposed. Too late and design churn keeps invalidating work you have already done. We freeze hardware ahead of software, because the cost curve of hardware iteration climbs faster than software once tooling is committed.

Verification and validation: reading the V-model correctly

Verification asks whether you built the device right against its specifications. Validation asks whether you built the right device for its users. Engineers use both words loosely. Regulators use them precisely.

The V-model visualizes the relationship. Requirements decompose downward on the left arm, from system requirements to subsystem design to unit implementation. Testing climbs back up the right arm, each level answering to the decomposition level opposite it. Design validation answers to user needs at the top.

You will hear the V-model dismissed as waterfall thinking, which misreads it. The V describes the relationships your evidence must contain, saying nothing about build order.

What actually happens in this phase:

• Bench verification. Basic safety and essential performance under IEC 60601, environmental testing, electromagnetic compatibility, and biocompatibility for anything patient-contacting.
• Software verification. Unit, integration, then system testing, traced to software requirements per IEC 62304.
• Summative usability validation. Representative users in a representative environment, per IEC 62366.
• Clinical evaluation. Under EU MDR every device needs one, and whether it extends to a clinical investigation depends on the evidence you already hold. In the US the requirement tracks your submission pathway and the device itself.

Of those four, electrical safety and EMC testing is where schedules break. Accredited lab queues run weeks to months, and a failure means redesign followed by a return to the back of the queue. Book slots earlier than feels necessary.

Regulatory submission: 510(k), De Novo, or PMA?

Your submission pathway follows from your device class and whether a legally marketed predicate exists. Three routes cover almost all US submissions.

510(k) premarket notification applies to most Class II devices. You demonstrate substantial equivalence to a predicate already on the market. Under the MDUFA V commitment letter, FDA’s goal is a decision on 95% of 510(k)s within 90 FDA days. Calendar time runs longer, because FDA days exclude any period the submission sits on hold awaiting your response.

De Novo classification applies when your device is low or moderate risk with no predicate available. If granted, the agency creates a new classification with special controls, making you the predicate for everyone who follows.

Premarket Approval (PMA) applies to Class III. You prove the device is safe and effective on your own clinical evidence instead of leaning on a predicate, which is why it carries by far the heaviest evidence and fee burden.

In the EU, the manufacturer prepares technical documentation and follows the applicable conformity assessment route. Notified body involvement is required for Class IIa, IIb and III devices, and also for certain Class I devices, including sterile, measuring and reusable surgical instruments .Notified body review is commonly reported at 13 to 18 months, and capacity varies by body and device type. It is often the largest fixed block in an EU timeline.

Transfer to manufacturing and post-market surveillance

Design transfer translates design outputs into validated production specifications, which is where medical device manufacturing takes over. Post-market surveillance is the ongoing collection of field data that feeds back into risk management and design.

Design transfer is more engineering work than the name suggests. You are validating medical device manufacturing processes, qualifying contract manufacturing partners, writing inspection criteria, and proving the line can build your device repeatably.

Manufacturability problems you deferred during design surface here, as design specifications the line cannot actually hit. Process validation for anything you cannot fully inspect, such as sterilization or a sealed weld, is its own project.

Then the device ships. Complaint handling, corrective and preventive action (CAPA), adverse event reporting, and periodic safety reporting under EU MDR run continuously from launch.

Take this seriously for a blunt reason. Medical device recalls reached a four-year high in 2024 with 1,059 US events, up 8.6% on 2023, and Class I recalls hit their highest level in fifteen years. Device failure became the leading cause for the first time in over five years. Your feedback loop is what catches the problem before it becomes one of those numbers.

Medical device software development follows IEC 62304, the international standard for software lifecycle processes in this sector. It requires you to classify software by potential harm, then apply proportionate rigor to architecture, detailed design, testing, and maintenance.

The standard does not tell you how to write code. It tells you which processes must exist and what evidence must be retained. The engineering judgment stays yours.

What are the IEC 62304 software safety classes?

It defines three software safety classes by the severity of harm a software failure could cause. Class A means no injury is possible. Class B means non-serious injury is possible. Class C means death or serious injury is possible.

Your class drives your documentation burden. Class A skips detailed design and unit-level requirements. Class C requires architectural design, detailed design to the unit level, plus verification at every level.

Two points teams get wrong. IEC 62304 assigns a software safety class to the software system first. When the architecture is decomposed, software items may be assigned a different class where an appropriate rationale and effective segregation support it. Until a software safety class is assigned, Class C requirements apply.

Software architecture is your biggest lever here. Isolating the safety-critical path into a small Class C item lets the rest of the system sit lower. The documentation savings are substantial and the safety argument is stronger, though segregating embedded medical software under IEC 62304 and ISO 13485 takes architectural discipline from the first sprint.

What is changing in IEC 62304 Edition 2?

Edition 2 will replace the three safety classes with two software process rigor levels and widen the standard’s scope from medical device software to health software. It also adds a normative AI planning clause and moves general QMS clauses out to ISO 13485. Level I roughly replaces Class A. Level II merges Class B and Class C into one high-rigor level.

Be careful with the timeline, because it has slipped repeatedly. Edition 2 is still a draft.

Earlier commentary pointed to publication in 2026. The working group then had roughly 1,500 comments to resolve on the first committee draft and is now circulating a second one. The Johner Institute’s status tracker puts the final draft stage no earlier than 2028, against an IEC forecast publication of late 2028. Other commentators still expect 2027.

What that means for you: EN 62304:2006+A1:2015 remains the harmonized version in the EU, and formal recognition of a new edition typically lags publication by two to three years. Design against Edition 1 today. If your software is currently Class B, model the eventual merge into Level II now, because your rigor requirements go up.

Can you run agile in a regulated software project?

Yes. Agile medical device software development is compatible with IEC 62304, which is process-agnostic, and AAMI TIR45 exists specifically to map agile practices onto the standard’s requirements. What agile does not buy you is an exemption from documentation.

What works in practice:

• Define increments as documentation-complete. A story is done when requirement, code, test, trace link, and risk assessment are all updated. Not when the code merges.
• Keep the design freeze concept. Agile inside a phase, gated between phases.
• Automate the traceability. Requirements tool linked to issue tracker linked to CI results. Manual trace matrices rot within weeks.
• Treat risk analysis as a living artifact. Each increment reviews whether new hazards appeared.

The honest tension: agile optimizes for responding to change while design controls optimize for controlling change. You resolve it by moving fast before design freeze and deliberately after.

Why cybersecurity can now block your clearance

Cybersecurity documentation is a gating criterion for market authorization. Under section 524B of the FD&C Act, cyber devices require a machine-readable software bill of materials (SBOM) and a postmarket vulnerability handling plan in the premarket submission.

The specifics live in the guidance. FDA issued an updated final version on 3 February 2026, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, superseding the June 2025 version. The title shift to Quality Management System tracks the QMSR transition below.

What you owe the agency:

• A secure product development framework woven into your existing design process
• A threat model plus security architecture views
• A machine-readable SBOM covering commercial, open-source, and off-the-shelf components, with version and support-status metadata
• A documented postmarket vulnerability monitoring and patch process
• Security testing evidence, including penetration testing and fuzzing

Miss any of that and the cost lands immediately. An inadequate SBOM alone can trigger a Refuse to Accept decision, a policy FDA has applied to cyber devices since 1 October 2023.

The scrutiny is unsurprising given the installed base. Cynerio’s 2022 analysis of roughly 10 million devices across more than 300 hospitals found 53% of connected medical and IoT devices running a known critical vulnerability. That figure describes hospital fleets rather than devices as shipped, and it has aged, so treat it as an indicator of scale.

AI and machine learning in a regulated device

AI-enabled devices follow the same rules as everything else, with one addition that changes the economics. A predetermined change control plan (PCCP) lets you pre-authorize specific model modifications so you can deploy them without a new submission.

A PCCP names the exact modifications allowed and the protocol governing how each one is implemented and validated, plus an impact assessment showing the device stays safe inside those bounds. FDA finalized its marketing submission recommendations for PCCPs covering AI-enabled device software functions in August 2025. Anything outside the plan still needs a submission.

Write yours with engineering specificity. Improve accuracy is not a modification description. Retrain on additional data drawn from the same population, holding sensitivity at or above 0.90 on a locked holdout set is.

In Europe, AI inside an MDR-regulated device counts as high-risk AI under the AI Act by default, and the assessment folds into your notified body’s existing MDR review.

The deadline moved recently, and it is now settled law. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. It pushed high-risk obligations for AI embedded in Annex I products, medical devices included, to 2 August 2028.

Underneath both regimes sits the same engineering work. Integrating AI and ML into a regulated device means dataset governance, model version control, validation evidence that survives retraining, and a rollback path you can demonstrate.

Medical device IoT development means running four coupled engineering tracks at once: electronics and mechanical hardware, embedded firmware, connectivity, and cloud software. The hard part is the coupling. A change on any track propagates to the others and to your risk file.

This is the part of the lifecycle regulatory consultants and design agencies hand off. It is also where most schedule slip originates.

What does the hardware track involve?

The hardware track covers schematic capture, PCB layout, component sourcing, electromechanical and enclosure design, and the environmental and safety testing that follows. Each has a long lead time, and they are sequentially dependent.

• PCB spins take weeks each. Two to four spins is normal for a first device, and every cycle means fabrication, assembly, bring-up, then debug.
• Component sourcing constrains your design. Second-source everything critical. A single-sourced part with a 40-week lead time can halt a program.
• Enclosure tooling commits you. Injection mold tooling is expensive and slow to change, which is why hardware freeze precedes software freeze.
• Sensor selection is a system decision. Signal quality, power draw, calibration drift, and biocompatibility all interact, so choosing sensors for a medical device is an architecture decision.

Yalantis runs an in-house R&D lab in Warsaw for exactly this reason. Iterating on bench hardware in the same building as the firmware team compresses the debug loop.

Why firmware language choice matters more than it used to

Embedded firmware carries safety-critical responsibility, which makes memory safety an engineering concern instead of a stylistic preference. Buffer overruns, use-after-free, data races, and stack corruption are exactly the failure modes producing the software recalls counted earlier.

Rust eliminates most of them at compile time while keeping the deterministic, no-allocator behavior that constrained embedded targets require. The trade-off is real: toolchain qualification and team familiarity both cost something up front, and library maturity varies by target. Whether Rust earns its place in medical firmware comes down to how much of your safety case rests on memory correctness.

How do you design Bluetooth connectivity for a medical device?

Bluetooth Low Energy (BLE) is the default link for wearable and portable devices because of its power profile. Bluetooth Low Energy medical device development starts from one assumption: the radio link is unreliable, so your data integrity has to survive it dropping.

Where BLE medical device projects go wrong:

• Treating connectivity as always available. It is not. The device must buffer locally and reconcile when the link returns. Data loss during disconnection becomes a patient safety issue.
• Underestimating pairing and bonding UX. Summative usability testing punishes confusing pairing flows hard.
• Skipping link-layer security analysis. Pairing mode, key management, key storage, and man-in-the-middle resistance all belong in your threat model.
• Ignoring coexistence. Hospital environments are crowded at 2.4 GHz. Test in realistic RF conditions.
• Forgetting the OTA update path. Section 524B expects you to be able to patch. A device you cannot safely update carries an unmanaged vulnerability.

The update path is the one most teams underestimate. Safety-critical over-the-air update is its own design problem. You need signed images, atomic apply, verified rollback, and an answer for what happens if power drops mid-write. These are general connected-device architecture problems that acquire a patient safety dimension once a clinician depends on the output.

From device to cloud

The cloud tier inherits regulatory scope whenever it performs a medical function. If your backend runs the algorithm producing the clinical output, your backend is part of the device.

Teams discover the consequences late. Your deployment pipeline falls under change control. Your infrastructure sits inside your risk analysis. Interoperability through HL7 and FHIR becomes a design input instead of an integration afterthought. Where you draw the boundary between device hardware and cloud software determines how much of your backend falls inside the regulated envelope.

ISO 14971 is the international standard for risk management in medical device development. It requires a continuous cycle of identifying the risks associated with medical devices, estimating and evaluating them, implementing controls, and verifying those controls work, maintained across the development lifecycle.

Take the word continuous literally. Risk management is not a document you produce for the auditor. It is the mechanism deciding your architecture, your test priorities, your software safety class, and your human factors protocol.

The ISO 14971 loop:

1. Risk management plan. Scope, responsibilities, reviewers, and acceptability criteria, set before you score anything.
2. Hazard identification. What can go wrong, from hardware failure to user error to cybersecurity compromise.
3. Risk estimation. Severity and probability of occurrence per hazardous situation.
4. Risk control. In strict order of preference: design out the hazard, then add protective measures, then rely on labeling.
5. Residual risk evaluation. What remains after controls, individually and overall.
6. Post-production monitoring. Field data feeds back and can reopen any step above.

That order of preference in step four is a hard requirement. You cannot resolve a hazard with a warning label when a design change could have removed it.

None of that has to be right first time. Nobody gets the first hazard analysis right, and that is expected. What matters is whether it stays a living artifact revisited on every design change, or becomes a spreadsheet nobody has opened since kickoff.

Human factors and usability engineering (IEC 62366)

IEC 62366 is the standard for applying human factors engineering to medical devices. It exists because use errors harm patients at a rate comparable to component failure, and it treats interface design as a risk control.

That risk control splits into two studies. Formative studies run during design and shape the interface. The summative study validates that trained users can complete critical tasks safely, and it happens on the frozen design. Failing it late is brutal, because remediation means redesign, then retesting, then another summative round.

Two frameworks govern quality for most medical device manufacturers. ISO 13485:2016 is the international QMS standard for medical devices, and it now sits inside US regulation following the QMSR transition.

The QMSR changed the US picture in February 2026

The FDA’s Quality Management System Regulation (QMSR) took effect on 2 February 2026, replacing the former Quality System Regulation (QSR) and incorporating ISO 13485:2016 by reference into 21 CFR Part 820.

Practically, this means ISO 13485 compliance is now a US regulatory expectation, with agency-specific supplements retained in Part 820 Subparts A and B. Design controls live in clause 7.3 instead of the old 21 CFR 820.30. The agency also retired the Quality System Inspection Technique (QSIT) in favour of an updated inspection program.

If your QMS documentation still cites 820.30 for design controls, it is out of date. That matters more than a citation cleanup suggests. ECA Academy’s analysis of FY 2025 found 38 of 44 device warning letters cited Part 820, up from 27 the year before.

EU MDR and the transition deadlines still ahead

EU MDR 2017/745 has applied to new devices since May 2021, with extended deadlines for legacy devices carrying older MDD certificates. Those deadlines are now close.

The dates split by class. Class III and implantable Class IIb legacy devices can stay on the market until 31 December 2027. Other Class IIb devices, plus Class IIa and Class Is/Im, have until 31 December 2028. Both depend on conditions that had to be met back in 2024, including an MDR-compliant QMS and a lodged notified body application.

Set that against notified body review running 13 to 18 months and the arithmetic gets uncomfortable for anyone still planning a 2027 transition.

A medical device development timeline runs three to seven years from concept to commercialization, and medical device development costs vary by an order of magnitude across classes.

The benchmark everyone quotes comes from a 2010 Stanford survey of 204 medical technology companies. It put average concept-to-clearance cost for a 510(k) device at roughly $31 million and a Class III PMA device at roughly $94 million.

Treat those numbers with care. The study dates from 2010 and was sponsored by industry associations, and FDA disputed its methodology at the time. It also measures total company capital rather than an engineering quote.

The figures you can verify today are the fees. A standard PMA carries a FY 2026 user fee of $579,272 and a 510(k) costs $26,067, before you have paid for a single test or enrolled patient. Fees reset every 1 October.

What actually drives your medical device development timeline:

• Device class and pathway. A 510(k) with a clean predicate is a different project from a De Novo.
• Clinical evidence. A pivotal trial adds years and is usually the largest single cost.
• Hardware complexity. Every PCB spin and tooling change is calendar time you cannot compress.
• External queues. Notified body and test lab capacity is not yours to control.
• Software safety class. Class C verification effort is materially higher than Class B.
• Rework from late-discovered problems. The one driver you can actually influence.

That last driver is where engineering discipline pays back. A summative failure after design freeze, a broken requirement trail found during submission prep, an EMC failure requiring a board redesign: each costs a quarter or more, and each is preventable with front-loaded rigor.

Front-loading does not mean gold-plating. Spend real money on feasibility, align with the agency through a pre-submission before committing to a test plan, build traceability with tooling from day one, and book external slots early. Run formative studies continuously so the summative one confirms rather than surprises.

The phases stay constant. The evidence burden and the engineering emphasis shift substantially by device type.

How the same process changes by device type

Cardiac devices. Cardiac medical device development spans a wide range. ECG monitors and Holter recorders usually sit in Class II on a 510(k), while implantable therapy is where Class III and a pivotal trial become likely. Implantables add power budget and biocompatibility limits on top. Software class follows each item’s hazard analysis, so segregation can keep most of the system lower, with only the therapy path at Class C.

Wearable monitors. Wearable medical device development is typically Class II. The engineering centre of gravity sits in sensor signal quality and power management, with BLE reliability close behind. Algorithm validation across diverse populations is where clinical evidence concentrates.

Diagnostic software and SaMD. Class II in the US, often IIa or higher in the EU under Rule 11. No hardware risk controls available, so software safety class runs high. Dataset representativeness becomes the core evidence question.

Respiratory devices. IEC 60601 electrical safety plus alarm requirements under IEC 60601-1-8. Alarm design is a human factors problem and a risk problem at once, and it is unforgiving.

Bringing a medical device to market rewards front-loaded discipline more than almost any other kind of engineering. The teams shipping on schedule spent real money on feasibility and opened their design and development file in week one. They also kept their risk file alive from kickoff to launch.

The hardest part is rarely any single phase. It is keeping hardware, firmware, connectivity, cloud software, and regulatory compliance evidence coherent while all five move at once. That coordination problem is why splitting the work across a design agency, a firmware contractor, a regulatory consultant and a cloud team tends to cost more than one end-to-end team.

If you are scoping a device programme and want to pressure-test your pathway, timeline or architecture, our medical device engineers are happy to have that conversation. Bring your hardest open question.