What you will learn
By the end of this topic, you should be able to describe the main stages of medical-device development, explain why they overlap, identify the evidence created at each stage, and recognise the processes that continue throughout the complete device lifecycle.
The big picture
A medical device is not developed by completing engineering first and adding quality or regulatory documentation afterwards. The product and its evidence develop together. Intended purpose shapes regulatory strategy and user needs; risks shape requirements and architecture; verification and validation produce evidence; real-world experience then feeds back into every controlled lifecycle process.
The lifecycle is iterative, but it is not uncontrolled. Teams may revisit earlier decisions as knowledge grows, provided changes, rationale, risks and resulting evidence remain controlled and traceable.
Nine lifecycle stages
The names of stages and gates vary between organisations. The underlying logic is more important than the labels.
Need and opportunity
Is there a real clinical or user problem worth solving?Understand the problem, the people affected, the current care pathway, the use environment and the benefit the device is expected to provide.
Typical evidence: Problem statement, stakeholder map, early use scenarios and feasibility evidence.Intended purpose and strategy
What exactly will the device do, for whom and where?Define the medical purpose, target population, intended users, indications, contraindications and operating environment. Establish likely device qualification, classification and market pathways early.
Typical evidence: Intended-purpose statement, claims, regulatory strategy and development plan.User needs and design inputs
What must be true for the device to be safe, effective and usable?Translate clinical, user, regulatory, safety, performance, interface and business needs into clear, testable design inputs. Resolve ambiguity before it becomes expensive design rework.
Typical evidence: Approved user needs, system requirements, acceptance criteria and traceability.Architecture and risk controls
How will the system meet its requirements and control risk?Define the product architecture, boundaries, interfaces and allocation of requirements. Identify hazards and foreseeable sequences of events, then select risk controls in the design wherever practicable.
Typical evidence: Architecture, interface specifications, risk analyses and allocated risk-control requirements.Detailed design and implementation
Can the design be built consistently and reviewed objectively?Develop hardware, software, mechanics, packaging, labelling and production methods under configuration control. Review outputs against their inputs and manage suppliers as part of the design system.
Typical evidence: Schematics, drawings, code, specifications, bills of material, review records and prototypes.Verification
Did we build the device right?Use inspection, analysis, test and other objective methods to show that every applicable design input has been met. Investigate failures and anomalies rather than treating a test report as a box-ticking exercise.
Typical evidence: Approved protocols, calibrated equipment records, results, reports, deviations and requirements traceability.Validation and clinical evidence
Did we build the right device?Show that the finished device meets user needs and intended use under actual or simulated conditions of use. Bring together usability, clinical or performance evidence, packaging, labelling and representative production units.
Typical evidence: Validation plans and reports, usability validation, clinical or performance evaluation and benefit–risk conclusions.Transfer, release and market access
Can the approved device be made and supplied reliably?Transfer the controlled design into routine production and service. Qualify processes, confirm supplier and inspection controls, complete technical documentation and obtain the required approvals before release.
Typical evidence: Device master information, process validation, training, release records, declarations and regulatory approvals.Post-market, change and retirement
Does the device remain safe and effective in real use?Collect and evaluate complaints, vigilance, service, production, cybersecurity and performance information. Feed learning back into risk management, clinical evaluation, corrective action and controlled change through the whole supported life of the device.
Typical evidence: Post-market reports, trend reviews, CAPA, updated risk files, change assessments and retirement plans.Activities that run across the lifecycle
These are not isolated work packages. Each changes as the design, evidence and knowledge of the device mature.
Quality management
Defines the controlled processes, responsibilities, records and review mechanisms used throughout development and supply.
Risk management
Begins with planning and intended use, influences requirements and design, and continues through production and post-market monitoring.
Traceability
Connects needs, requirements, risks, design outputs, verification, validation and changes so that conclusions are supported by evidence.
Human factors
Brings users, use environments, use-related risk and interface design into the lifecycle—not just into a final usability test.
Clinical and performance evidence
Starts with the claims and evidence strategy, then develops as the design and knowledge of the device mature.
Configuration and change control
Ensures teams know which design was reviewed, tested, manufactured, released and subsequently changed.
Cybersecurity
Addresses assets, threats, security requirements, verification, secure updates and vulnerability handling across the supported lifetime.
Supplier and manufacturing control
Makes purchased items and production processes part of the controlled product, not activities that begin after design.
What makes a decision gate effective?
A gate is a controlled decision about readiness to proceed—not a meeting held because the schedule says so. A useful gate asks:
- Are the required inputs complete enough for the next stage?
- Are safety, performance, usability, security and regulatory questions visible?
- Are decisions supported by reviewed evidence rather than optimism?
- Are open issues understood, owned and acceptable for this point in development?
- Are interfaces, configuration and traceability under control?
- Does the plan still reflect the device, its risks and intended markets?
A gate can legitimately approve progress with open actions. What matters is that the residual uncertainty is explicit, assessed and controlled.
A simple example: a connected injection device
An early concept may be “help patients take injections correctly.” That is not yet a usable design input. The team must define the intended therapy context, users and environment; decide what the device measures or controls; identify risks such as incorrect dose, missed completion, misleading feedback or loss of connectivity; and turn those risks and needs into testable requirements.
Architecture allocates functions between the injector, electronics, mobile application and cloud service. Verification shows that each allocated requirement is met. Validation determines whether intended users can achieve the intended result safely in representative conditions. Transfer then proves that the tested design can be manufactured and configured consistently. Complaints, field data, software vulnerabilities and production trends continue to test the original assumptions after release.
Common misconceptions
“The lifecycle is a waterfall.”
No. Iteration is expected. The discipline lies in controlling decisions and ensuring affected risks, requirements and evidence are revisited.
“Risk management belongs to the risk manager.”
No. The process may have an owner, but identifying hazards and implementing effective controls requires clinical, engineering, usability, manufacturing and post-market knowledge.
“Verification and validation are the test phase.”
No. Their strategy, methods, configurations and acceptance criteria should be planned while requirements and architecture are being developed.
“Release ends development.”
No. Production and post-market information can require corrective action, risk-file updates, new evidence, design changes or eventual product retirement.
Seven things to remember
- Begin with the medical purpose, users and use environment.
- Develop the product and its objective evidence together.
- Make requirements testable and traceable.
- Use risk management to shape design decisions—not merely to describe them.
- Plan verification and validation before the design is finished.
- Treat transfer, suppliers and production as part of product development.
- Use post-market learning to keep the device safe, effective and current.
Starting points and authoritative references
Exact requirements depend on the device, markets and applicable regulatory framework. Useful starting points include: