Medical Device Design Controls: Process, Costs and FDA Pathways

How medical device design controls work in practice - user needs, inputs, verification and validation, the DHF - and what a program costs.

August 16, 20186 min read

Written by Konstantin Dolgan, Ph.D., NPDP

Founder & CEO, Product Development Engineer

Published August 16, 2018Updated August 30, 2026

Medical device development is ordinary product development plus evidence. The engineering is familiar - mechanical, electronics, firmware, industrial design - but every decision has to be traceable to a documented user need, and every claim has to be backed by a test. Teams that treat design controls as paperwork bolted on at the end pay for it twice. This guide walks the stages, the FDA pathways, and what a Class II program realistically costs.

Medical device development infographic showing five gated stages from discovery and user needs through design inputs, design and verification, validation and clinical, to transfer and launch, with FDA pathways 510(k), De Novo and PMA and Class I to III risk classes — Five gates, three pathways, three risk classes - the map every device program follows.

The five stages

Discovery and user needs - clinical interviews, workflow observation, competitor and predicate scanning. Output is a user needs list written in the clinician's language, not in specifications.
Design inputs - user needs converted into measurable requirements, plus the first risk analysis (ISO 14971) and the regulatory strategy. This is the gate most programs rush and later re-do.
Design and verification - concept, detailed design, prototypes, then verification testing that proves the device meets its design inputs. Biocompatibility (ISO 10993) and electrical safety (IEC 60601) testing start here.
Validation and clinical - proof that the finished device meets user needs in the hands of real users: human factors validation (IEC 62366), simulated-use studies and, for higher-risk devices, clinical evidence.
Transfer and launch - process validation (IQ/OQ/PQ), supplier qualification, labelling and IFU, submission, and the post-market surveillance and complaint-handling system.

Which FDA pathway applies

Pathway	When it applies	Typical FDA review	Evidence needed
510(k)	Class II device with a legally marketed predicate	3-6 months after submission	Bench comparison to the predicate, safety testing, usability
De Novo	Novel low-to-moderate risk device, no predicate	9-15 months	Full risk-benefit case, sometimes clinical data
PMA	Class III, life-sustaining or implantable	1-3 years	Pivotal clinical trial, manufacturing inspection
Exempt (Class I)	Low-risk general controls devices	No submission	Registration, listing, QMS, labelling

What it costs

Program type	Development cost	Testing and submission	Time to clearance
Class I accessory or simple mechanical	$60k-$180k	$5k-$25k	6-10 months
Class II wearable or diagnostic (510(k))	$250k-$900k	$60k-$180k	14-24 months
Class II with software (IEC 62304)	$450k-$1.5M	$90k-$250k	18-30 months
Class III implantable (PMA)	$2M+	$1M+ clinical	3-7 years

Design controls without the drag

Write user needs before requirements, and keep them short - ten to thirty statements, each testable in principle.
Maintain one traceability matrix from day one: user need to design input to verification test to result. Retrofitting it costs weeks.
Run risk analysis as a live document. Every new failure mode found in test goes back into the FMEA with a mitigation and a verification.
Freeze design inputs before detailed design. Late input changes are the single largest schedule risk in device work.
Choose contract manufacturers that already hold ISO 13485 certification - transferring to a non-certified plant restarts qualification.

Where programs go wrong

Picking a predicate late, then discovering the intended-use statement forces a De Novo.
Treating human factors as a usability nicety instead of a validation requirement with a formative and summative study.
Designing electronics without an IEC 60601 pre-scan, then finding creepage and isolation problems after tooling.
Skipping process validation planning until after design freeze, so the launch slips on IQ/OQ/PQ rather than on design.

Building the design history file as you go

The design history file is not a document you write at the end. It is the accumulated record of every decision, review and test, assembled in the order the work happened. Teams that treat it as a deliverable spend three to six extra months reconstructing evidence they no longer remember creating. Teams that treat it as a byproduct of normal engineering finish the submission in weeks.

DHF artifact	What it records	When it is created	Common failure
Design and development plan	Phases, reviews, responsibilities	Before requirements are frozen	Written once and never updated as scope changes
User needs	Clinical and workflow statements	Discovery	Written as features instead of needs
Design inputs	Testable engineering requirements	Requirements phase	Untestable adjectives such as ergonomic
Design outputs	Drawings, code, specifications, BOM	Development	Released without traceability to inputs
Traceability matrix	Need to input to output to verification	Maintained continuously	Built retroactively before submission
Risk management file	Hazards, controls, residual risk per ISO 14971	From concept onward	Created after the design is frozen
Verification and validation reports	Evidence inputs and needs are met	Late development	Testing on units that do not match production
Design review minutes	Decisions, actions, attendees	Every phase gate	Reviews held without an independent reviewer

Quality engineer reviewing design history file documentation beside a medical device assembly on a clean bench

Testing that drives the schedule

Two testing streams dominate the calendar and neither compresses well. Biocompatibility for any patient-contacting material runs on lab queues measured in months, and electrical safety and EMC testing for an active device fails often enough on the first attempt that a second slot should be assumed in the plan.

Test program	Applicable standard	Typical duration	Typical cost
Cytotoxicity, sensitization, irritation	ISO 10993-5, -10	6-10 weeks	$8,000-$20,000
Extended biocompatibility (implant, systemic)	ISO 10993-6, -11	3-6 months	$40,000-$150,000
Electrical safety	IEC 60601-1	6-10 weeks	$25,000-$60,000
EMC and immunity	IEC 60601-1-2	3-5 weeks	$15,000-$35,000
Usability engineering and human factors validation	IEC 62366-1, FDA HFE guidance	8-14 weeks	$30,000-$90,000
Sterilization validation	ISO 11135 or ISO 11137	8-16 weeks	$20,000-$60,000
Software verification (if applicable)	IEC 62304	Runs with development	Internal effort

Book laboratory slots at the start of the phase, not when the units are ready. Test houses schedule six to twelve weeks out, and a device sitting on a shelf waiting for a chamber is the most common silent delay in device programs.

Pre-submission readiness checklist

Intended use statement written and locked, because it determines the pathway and every claim that follows.
Predicate device identified with a documented substantial-equivalence argument, including where the technology differs.
Traceability matrix complete with no orphan requirements and no verification gaps.
Risk file current, with each residual risk traced to a control and a verification record.
Test units built on production-equivalent tooling, materials and process, with the build documented.
Labeling, instructions for use and packaging drafted and covered by usability validation.
Supplier quality agreements in place for every critical component and process.
A pre-submission meeting requested with the FDA when the pathway or predicate is at all ambiguous - the feedback is free and typically arrives in 60 to 75 days.

Key takeaways

Design controls cost less when they run alongside engineering than when they are reconstructed afterward.
Biocompatibility and 60601 testing set the critical path; reserve lab capacity before the units exist.
A weak intended-use statement is the single most expensive early mistake, because it can convert a 510(k) into a De Novo.
Assume one failed compliance attempt in the budget and the schedule; the programs that finish on time planned for it.

What the design history file actually contains

Design controls under 21 CFR 820.30 and ISO 13485 are often described as paperwork; in practice they are a chain of evidence linking a clinical need to a test result. The design history file is where that chain lives, and an auditor reads it as a story: this is what the user needed, this is how we specified it, this is how we proved it, and this is what we changed when it failed.

DHF element	What it holds	Common audit finding
User needs	Clinician and patient needs in their own language	Needs written as engineering solutions
Design inputs	Testable specifications traced to needs	Untestable inputs such as "easy to clean"
Risk management file	ISO 14971 hazard analysis, controls, residual risk	Risk file frozen at concept, never updated
Design outputs	Drawings, code, specifications, labelling	Outputs not traceable to a specific input
Verification records	Test protocols and reports proving outputs meet inputs	Testing done, protocol written afterwards
Validation records	Evidence the device meets user needs in real use	Bench testing presented as validation
Design reviews and transfer	Minutes, actions, production transfer records	Reviews with no documented independent reviewer

The trace matrix is the spine of that file. Every user need maps to at least one design input, every input to an output, and every output to a verification record. Build it in the first month and maintain it continuously; reconstructing traceability at the end of a program is the single most expensive documentation task in medical device development.

Verification, validation and human factors

Verification and validation get conflated constantly, and regulators notice. Verification asks whether you built the device right against its specifications. Validation asks whether you built the right device against user needs, in the intended environment, with representative users and production-equivalent units.

Verification is bench and lab work: dimensional, electrical safety (IEC 60601-1), EMC (IEC 60601-1-2), software (IEC 62304), biocompatibility (ISO 10993) and sterilization efficacy.
Validation uses production-equivalent devices in simulated or actual use, including a summative human factors study under IEC 62366-1 and the FDA's human factors guidance.
Formative usability studies belong at concept and mid-design; discovering a use-related hazard during the summative study means redesign at the worst possible moment.
Software validation follows a documented plan proportional to the level of concern, with unit, integration and system testing recorded.
Process validation (IQ/OQ/PQ) proves manufacturing can reproduce the validated device, and is required before commercial distribution.

Budget verification and validation at 25 to 40 percent of total development cost on a Class II device, and schedule the summative human factors study before design freeze rather than after. Related reading: medical equipment manufacturing challenges.

Frequently asked questions

How long does medical device development take?

A Class II device with a clear predicate typically takes 14-24 months from user needs to FDA clearance, of which 3-6 months is FDA review. Class I exempt devices can reach market in under a year; PMA devices take several years because of clinical trials.

What are design controls?

Design controls are the FDA 21 CFR 820.30 requirements that a device be developed against documented user needs and design inputs, verified against those inputs, validated with users, and traceable throughout. They apply to Class II and Class III devices and some Class I devices.

What is the difference between verification and validation?

Verification proves the device meets its design inputs - did we build the thing right. Validation proves the finished device meets user needs in real use - did we build the right thing. Both are required, and validation must use production-equivalent units.

Do I need ISO 13485 to develop a medical device?

You need a quality management system that satisfies FDA 21 CFR 820; ISO 13485 certification is the practical route and is required for CE marking. Development partners and contract manufacturers should already be certified so their records support your submission. Work with LA NPDT: if you are moving from here to execution, start with our medical device development or talk to us about medical device prototyping .

Filed under:Education Inspiration

All articles

Medical Device Verification and Validation: Stages, Costs and Design Controls
Medical device verification and validation explained: design inputs, V&V protocols, human factors, biocompatibility and design-control documentation.
Prototyping Medical Devices: Stages, Design Controls and Costs
Prototyping a medical device is not just building a working model. Each stage has to produce evidence a regulator will accept. Here is how the stages, documentation and costs fit together.
Medical Device Design: Process, Documentation and Cost
A practical guide to medical device design under design controls: what each phase produces, how verification differs from validation, and what the work costs.