A medical device can solve the right clinical problem and still fail in development. User needs may be too vague to test, engineering teams may interpret the same requirement differently, prototypes may not represent production units, or essential knowledge may be lost when the design is transferred to a manufacturer.
Medical device design controls are intended to prevent these failures. They create a structured, documented process for transforming a clinical or user need into a device that can be manufactured consistently and shown to meet its intended purpose.
Design controls do not replace creativity. They make development decisions traceable. A team should be able to explain:
- Who needs the device and why
- What the device must do
- What technical solution was developed
- How the solution was reviewed
- How requirements were verified
- How user needs and intended use were validated
- How risks were controlled
- How the approved design was transferred into production
This guide explains the complete design control process, from user needs to design transfer, with practical examples for product owners, startups, engineers and medical device development teams.
Regulatory note: This article provides general product-development information, not legal or regulatory advice. Applicable requirements depend on device classification, intended use, technology and target markets.
What Are Medical Device Design Controls?
Medical device design controls are the procedures, activities and records used to plan, manage, review and document device design and development. Their purpose is to ensure that the final device meets user needs, intended uses, specified requirements and applicable regulatory obligations.
The process is usually presented as a sequence:
- Design and development planning
- User needs and intended use
- Design and development inputs
- Design and development outputs
- Design reviews
- Design verification
- Design validation
- Design transfer
- Design changes
- Design and development records
In practice, the process is iterative. Verification may reveal an incomplete requirement. Formative usability testing may identify a new use-related risk. Supplier feedback may require a tolerance change. Design controls provide a disciplined way to evaluate and document these loops rather than pretending that development is linear.
The 2026 FDA QMSR Update
The regulatory language used in the United States changed in 2026. The FDA’s Quality Management System Regulation, or QMSR, became effective on February 2, 2026. The QMSR amended 21 CFR Part 820 and incorporates ISO 13485:2016 as the foundation of the medical device quality management system framework.
The FDA states that this change aligns U.S. current good manufacturing practice requirements more closely with international quality management requirements and specifically integrates risk management. See the FDA Quality Management System Regulation overview.
Historically, U.S. teams referred to the design control requirements in 21 CFR 820.30. Under the current QMSR, 21 CFR 820.10(c) requires applicable manufacturers to comply with the design and development requirements incorporated from ISO 13485:2016, Clause 7.3 and its subclauses.
The phrase medical device design controls remains widely used in industry and search, but current procedures and regulatory strategies should be mapped to the present QMSR and applicable ISO 13485 requirements rather than relying only on the former regulation.
According to current FDA educational material, the QMSR design and development requirements apply to manufacturers of all Class II and Class III devices and specified Class I devices, including devices automated with computer software. Teams should confirm applicability for their specific product. See the FDA’s QMSR Design and Development presentation.
How the Design Control Elements Connect
The following simplified example shows how one need is progressively translated into objective evidence.
| Design control element | Example for a portable home monitor |
|---|---|
| User need | The patient needs to carry the monitor during normal daily activity. |
| Design input | The complete device shall weigh no more than 1.2 kg and fit within a defined carrying volume. |
| Design output | Approved enclosure drawings, component specifications, bill of materials and assembly instructions. |
| Verification | Measurements confirm that production-equivalent units meet the weight and dimensional limits. |
| Validation | Representative patients can carry, set up and use the device safely during simulated or actual daily activities. |
| Design transfer | Released specifications, inspection methods, assembly processes and acceptance criteria are implemented by production. |
Each stage answers a different question:
- User needs: Are we solving the right problem?
- Design inputs: Have we converted the problem into complete requirements?
- Design outputs: Have we defined a buildable solution?
- Verification: Did we build the product according to the requirements?
- Validation: Did we build the right product for the intended users and use?
- Design transfer: Can production repeatedly make the approved product?
Confusing these questions is one of the most common causes of incomplete design control documentation.
1. Start With Design and Development Planning
A design and development plan defines how the project will be controlled. It should be created early and updated as the project changes.
The plan commonly identifies:
- Development stages and major deliverables
- Roles, responsibilities and decision authority
- Required design reviews
- Verification and validation activities
- Risk management interfaces
- Human factors and usability activities
- Software, hardware and mechanical development processes
- Supplier and contract manufacturer involvement
- Regulatory submission milestones
- Configuration and document controls
- Design transfer activities
- Records to be maintained
The plan should also define how different teams exchange information. For example, an enclosure change may affect antenna performance, cleaning validation, biocompatibility, ingress protection, assembly tooling and packaging. If mechanical, electronic, software, quality and manufacturing teams work in separate systems without controlled interfaces, changes can easily become inconsistent.
Planning does not mean predicting every test at the beginning. It means defining how the project will determine, approve and update the activities required to demonstrate that the design is safe, effective and manufacturable.
2. Define Intended Use and User Needs
User needs establish what the device must enable people to accomplish. They are derived from the clinical problem, intended purpose, users, use environments, workflows and foreseeable limitations.
User research may involve:
- Interviews with patients, caregivers and healthcare professionals
- Contextual observation in clinics or homes
- Workflow and task analysis
- Review of complaints and limitations of existing products
- Competitive and literature research
- Early ergonomic and interaction studies
- Consultation with service, cleaning and reprocessing personnel
Good user needs are solution-neutral where possible. They describe the outcome before locking the team into a particular mechanism.
| Weak or premature statement | Better user need |
| The device needs a 5-inch touchscreen. | The operator needs to read status and complete critical settings while wearing clinical gloves. |
| The device should use a rechargeable lithium battery. | The user needs the device to operate throughout a normal treatment period without interruption. |
| The enclosure should have a blue LED. | The user needs to determine clearly when therapy is active. |
The solution may eventually include a touchscreen, battery or LED, but those decisions should emerge from design inputs and architecture rather than being mistaken for the underlying need.
Include All Intended Users
The patient is not always the only user. Depending on the product, relevant users may include:
- Physicians and nurses
- Family caregivers
- Home health workers
- Sterile processing staff
- Installation and service technicians
- Administrators who configure connected systems
Their needs may conflict. A service technician may need diagnostic access, while cybersecurity controls must prevent unauthorized access. A clinician may need advanced settings, while a home user needs a simplified workflow. These tensions should be recognized during development rather than discovered during validation.
Define the Use Environment
User needs should consider where and under what conditions the device will be used. Lighting, noise, temperature, humidity, space, connectivity, cleaning resources, electromagnetic interference, protective equipment and time pressure may all affect safety and performance.
The intended use, indications, contraindications, user profiles and use environments become essential foundations for design inputs, risk management and human factors engineering.
3. Convert User Needs Into Design Inputs
Design inputs translate user needs and intended use into specific product requirements. They define the functional, performance, usability, safety and regulatory characteristics the design must satisfy.
Under the current QMSR framework, FDA training materials describe inputs as including functional, performance, usability and safety requirements according to intended use, applicable regulatory and standards requirements, and pertinent risk management outputs. Inputs should be complete, unambiguous, verifiable or validatable, and not conflict with one another.
Common categories include:
- Functional requirements
- Performance and accuracy requirements
- Physical dimensions and weight
- User interface and alarm requirements
- Software and data requirements
- Electrical and battery requirements
- Mechanical strength and reliability
- Biocompatibility
- Sterility or reprocessing
- Packaging and shelf life
- Environmental operating and storage limits
- Cybersecurity and privacy
- Labeling and instructions for use
- Manufacturing and servicing constraints
- Regulatory and consensus standard requirements
- Risk control requirements
Make Inputs Measurable
Terms such as “lightweight,” “durable,” “easy to use,” “fast,” “secure” and “portable” are useful research language but weak design inputs unless they are converted into measurable criteria.
Compare:
- Weak: The alarm shall be loud enough.
- Better: The alarm shall achieve the specified sound pressure level across the defined frequency range and measurement conditions.
- Weak: The device shall be easy to clean.
- Better: The enclosure shall withstand the validated cleaning method for the specified number of cycles without loss of legibility, sealing, safety or performance.
- Weak: The measurement shall be accurate.
- Better: The measurement error shall remain within the defined tolerance across the stated operating range and environmental conditions.
Acceptance criteria should be determined before testing. Writing the requirement after seeing what a prototype can achieve turns verification into justification rather than objective evaluation.
Resolve Conflicts and Assumptions
Requirements often conflict. A smaller device may have less battery capacity. A quieter motor may generate less flow. A soft-touch coating may be difficult to disinfect. Stronger authentication may increase setup burden.
Each conflict should be evaluated with clinical, engineering, risk, usability and commercial context. Assumptions should be documented and tested, especially when they affect safety or intended performance.
4. Integrate Risk Management With Design Controls
Risk management should not be a separate file created shortly before submission. It should influence the design from concept through post-market changes.
A productive relationship works in both directions:
- User research and task analysis identify hazards and foreseeable use errors.
- Risk analysis creates or modifies design inputs.
- Design outputs implement risk controls.
- Verification confirms that risk controls meet their specifications.
- Validation evaluates whether risk controls work for intended users under representative conditions.
- Production and post-market information may reveal new hazards or change risk estimates.
For example, a risk analysis may identify that an incorrectly seated cartridge could cause under-delivery. This could lead to:
- A design input requiring detection of incomplete insertion
- Mechanical and sensor outputs that prevent operation
- Verification tests across tolerance extremes
- Usability validation involving representative users
- Production inspection criteria for the relevant components
This trace makes the risk control more credible than a warning added to the instructions alone.
5. Create Controlled Design Outputs
Design outputs are the results of design and development that define the device. They describe what will be built, purchased, inspected, tested, packaged, labeled, installed and serviced.
Examples include:
- Engineering drawings and tolerances
- CAD models
- Bills of materials
- Material and component specifications
- Circuit schematics and PCB files
- Software architecture, code and configuration
- Algorithms and software design specifications
- User interface specifications
- Manufacturing and assembly instructions
- Inspection methods and acceptance criteria
- Test methods
- Packaging and labeling specifications
- Instructions for use
- Installation and service procedures
- Supplier requirements
Outputs must be detailed enough to support purchasing, manufacturing and servicing, and they should contain or reference acceptance criteria. They should also identify characteristics essential for safe and proper use.
Outputs Must Be Approved and Configuration-Controlled
A prototype assembled by the engineering team may contain undocumented hand adjustments, substitute parts or unofficial firmware. It is not a controlled output until the relevant configuration is identified, reviewed, approved and reproducible.
This is particularly important when multiple prototype generations exist. Verification performed on hardware revision B and validation performed on revision C cannot support the final design unless the differences and their effects are understood.
6. Conduct Design Reviews at Meaningful Stages
Design reviews are planned, systematic evaluations of development results. They are decision points, not presentation meetings.
A review should evaluate whether the current work:
- Meets the defined requirements for that stage
- Has unresolved technical or clinical risks
- Contains conflicting or incomplete information
- Is ready to proceed to the next stage
- Requires corrective actions or additional evidence
Typical reviews may include:
- User needs and intended use review
- System requirements review
- Architecture review
- Preliminary design review
- Critical design review
- Verification readiness review
- Validation readiness review
- Design transfer or release review
The review team should include functions appropriate to the decision. Independence does not require an outsider unfamiliar with the product, but the review should include objective perspectives rather than only the people who created the work.
Review records should document attendees, materials reviewed, decisions, identified issues, assigned actions, due dates and closure evidence. An open issue does not disappear because the meeting ended.
7. Verify That Outputs Meet Inputs
Design verification provides objective evidence that design outputs meet design input requirements. In simple terms: did the team build the product according to specification?
Verification methods may include:
- Inspection and measurement
- Bench testing
- Electrical safety and EMC testing
- Biocompatibility testing
- Software unit, integration and system testing
- Code review and static analysis
- Reliability and environmental testing
- Packaging integrity and transportation testing
- Sterilization or cleaning process studies
- Engineering analysis
- Traceability analysis
Every verification activity should define:
- The requirement being tested
- The test method and equipment
- The test article and configuration
- Sample size and rationale
- Environmental and preconditioning requirements
- Acceptance criteria
- Raw data and results
- Deviations and anomalies
- Reviewer and approval records
Verification Is Not the Same as Validation
A team may verify that a button requires the specified force, the screen displays the correct message and the alarm reaches the required sound level. Those tests do not prove that intended users can operate the device safely in context. That question belongs to validation.
Verification typically focuses on specifications. Validation focuses on user needs and intended use.
8. Validate the Device for Intended Use
Design validation provides objective evidence that the device meets user needs and intended use. It should be performed under defined operating conditions using production units or equivalent devices representative of the final design.
Validation may include:
- Simulated-use testing
- Human factors validation
- Clinical evaluation or investigation, where required
- Performance evaluation in representative environments
- Packaging and distribution validation
- Cleaning, reprocessing or sterilization validation
- Software system validation
- Installation and service validation
The FDA explains that design validation evaluates whether the device conforms to defined user needs and intended uses and may include testing under actual or simulated use conditions. See the FDA’s IDE-related explanation of verification and validation.
Use Representative Users and Conditions
Validation results are only persuasive if participants, tasks, environments, training and device configurations represent intended use.
Consider:
- Age and health conditions
- Vision, hearing, dexterity and cognition
- Professional experience
- Language and literacy
- Personal protective equipment
- Home versus clinical setting
- Stress, distraction and time pressure
- Accessories and connected systems
- Cleaning, maintenance and storage
A product intended for older home users should not be validated only by healthy employees from the engineering team. Familiarity with the design can hide problems that first-time users will encounter.
Validate the Complete User Experience
The device is more than its enclosure and electronics. Validation may need to cover packaging, setup, accessories, labeling, instructions, training, software, connectivity, alarms, cleaning, charging and disposal.
For an integrated medical product development example, OPD’s wearable brain-computer interface design case shows how ergonomic testing, wearing stability, electronic integration and production considerations interact within one system.
9. Maintain Bidirectional Traceability
A traceability matrix connects user needs, design inputs, risks, outputs, verification and validation evidence.
Traceability should answer both directions:
- Does every approved requirement have an implemented output and appropriate evidence?
- Does every output exist for a justified requirement or risk control?
A simplified matrix might include:
| User need | Design input | Risk control | Design output | Verification | Validation |
| Patient can identify active therapy | UI-014: active state displayed within defined time | Prevent unnoticed interruption | UI specification and LED drawing | UI response-time test | Representative-use study |
| Device remains available during treatment | PWR-006: minimum runtime under defined load | Reduce therapy interruption | Battery and power-management specification | Runtime and low-battery tests | Full treatment simulation |
Traceability makes gaps visible before an audit or submission. It also supports impact analysis when a requirement, component or test changes.
Traceability is not merely a spreadsheet created at the end. It is a development tool that should evolve with the product baseline.
10. Transfer the Approved Design Into Production
Design transfer converts the approved design into production specifications, processes and controls that can consistently produce the intended device.
This stage is frequently underestimated. A device that works when assembled by its designers may fail when production volume increases, operators change, suppliers use normal tolerance ranges or inspection methods are applied differently.
Design transfer commonly includes:
- Final released drawings and bills of materials
- Approved suppliers and component specifications
- Manufacturing work instructions
- Tooling, fixtures and test equipment
- In-process and final inspection methods
- Acceptance criteria
- Process validation where results cannot be fully verified later
- Software programming and configuration controls
- Labeling and packaging controls
- Training for production and quality personnel
- Pilot builds and first-article inspection
- Yield, capability and defect analysis
- Service and repair documentation
Transfer Is a Controlled Handover, Not a File Upload
Sending CAD files to a contract manufacturer does not complete design transfer. The receiving team must be able to interpret the requirements, control the configuration and demonstrate that the manufacturing process produces conforming devices.
Important questions include:
- Are tolerances realistic for the selected process?
- Are critical-to-quality characteristics identified?
- Can incoming inspection detect supplier variation?
- Are assembly steps clear and repeatable?
- Are test fixtures qualified and measurement methods suitable?
- Can firmware and calibration data be controlled by device version?
- Have packaging and labeling variants been correctly linked to markets?
- Are nonconforming materials prevented from entering finished devices?
Early design for manufacturing and assembly reduces transfer risk. Waiting until design freeze to involve suppliers may reveal costly problems in tooling, component availability, inspection access or process capability.
OPD’s medical device design and healthcare product development services connect research, industrial design, engineering, prototyping, testing coordination and production support so manufacturing considerations can be addressed before release.
11. Control Design and Development Changes
Medical device design controls continue after the first production release. Components become obsolete, suppliers change processes, software is updated, complaints reveal usability issues and new regulatory requirements emerge.
Before implementation, a design change should be:
- Identified and described
- Reviewed for significance
- Assessed for impact on requirements and risk
- Evaluated for impact on existing parts and products
- Verified or validated as appropriate
- Reviewed for regulatory consequences
- Approved and configuration-controlled
- Communicated to affected functions and suppliers
A “small” change may have system effects. Replacing an adhesive can affect biocompatibility, sealing, aging and manufacturing. Changing a wireless module can affect EMC, cybersecurity, power consumption, labeling and regulatory submissions. Modifying an alarm message can affect translations, human factors evidence and software testing.
Change control should therefore use traceability and risk management to determine the necessary depth of evaluation.
12. Maintain a Design and Development File
The current QMSR framework requires manufacturers to maintain a design and development file for each medical device type or family. The file should include or reference records that demonstrate conformity with applicable design and development requirements, including changes.
In U.S. industry, teams may still use the historical term Design History File, or DHF. Under ISO 13485 and the QMSR, design and development file is the current terminology used in FDA educational material.
The file may include or reference:
- Design and development plans
- User needs and intended use documentation
- Design inputs and outputs
- Risk management records
- Design review records
- Verification and validation protocols and reports
- Traceability records
- Design change records
- Transfer and release evidence
- Relevant approvals and decisions
The file does not need to be one physical binder. It may reference controlled records in validated electronic systems. What matters is that the records are complete, retrievable, linked to the correct product version and able to show how the design process was controlled.
Build Evidence Into the Product From the Beginning
Effective medical device design controls create a continuous chain from the clinical problem to the production line. User needs define the outcome. Design inputs make that outcome measurable. Outputs describe the solution. Verification and validation provide evidence. Design transfer makes the result repeatable.
When these activities are integrated with risk management, human factors and manufacturing, documentation becomes a record of sound development rather than an administrative exercise performed after the product is designed.
OPD supports companies through integrated medical device design and healthcare product development, including product strategy, user research, industrial design, mechanical and electronic engineering, software development, medical device prototyping, testing coordination and production support. If you are developing a medical product and need to connect user needs with a practical, manufacturable design, contact OPD to discuss your project.
