Controlled medical-device development is a technical management problem. The team has to keep intended use, risk, requirements, architecture, configuration, verification, validation and transfer connected while the design is changing. A document set produced at the end cannot recreate decisions that were never reviewed or evidence that was never tied to the tested configuration.
ISO 13485:2016 provides the international quality-management framework used across the medical-device sector. In the United States, FDA’s Quality Management System Regulation incorporates ISO 13485:2016 by reference and has been effective since February 2, 2026. The current U.S. rule includes additional provisions and determines which device manufacturers must follow the design-and-development requirements.
Understand the applicable framework
Current 21 CFR 820.10(c) applies ISO 13485 Clause 7.3 design-and-development requirements to manufacturers of Class II and Class III devices and specified Class I devices, including devices automated with computer software. Other requirements depend on the device, activity and market.
The FDA’s QMSR overview explains the U.S. framework. ISO’s ISO 13485 page describes the standard’s medical-device focus and clarifies that certification is not required by the standard itself. A company’s certification status should be verified independently and should never be inferred from its use of design-control terminology.
Plan the development process around risk and evidence
The design and development plan should identify stages, reviews, responsibilities, interfaces, resources and records. It should also explain how the plan changes. For a multidisciplinary system, the plan needs system-level ownership above individual mechanical, electrical, software or quality workstreams.
Useful planning outputs include:
- product and intended-use definition;
- regulatory and standards strategy;
- risk-management plan;
- development stages and technical decision gates;
- design-review scope, participants and independence;
- configuration and change-control approach;
- verification, validation and human-factors strategy;
- supplier and manufacturing-transfer strategy;
- software, cybersecurity and maintenance planning where applicable.
The plan should be proportional to complexity and risk. Proportionality changes the depth and method of evidence, not the need to control applicable activities.
Build inputs that engineering can implement
Design inputs translate user needs, intended use, risk controls, standards and interfaces into requirements. They need measurable acceptance criteria and consistent terminology. Ambiguous adjectives such as intuitive, lightweight, fast or robust should be replaced with the observable conditions that matter to the device.
Inputs should cover the whole system:
- functional and performance behavior;
- safety and risk-control requirements;
- users, use environments and usability;
- mechanical, electrical, software and data interfaces;
- materials, cleaning, biocompatibility or sterility where applicable;
- environmental, transport, storage and service conditions;
- cybersecurity and update behavior for connected products;
- manufacturing, calibration, inspection, packaging and labeling.
Record the source of each input. A regulatory control, product standard, hazard analysis, user need and interface agreement create different review and change consequences.
Make outputs complete enough to build and verify
Design outputs include the documents and data that define the device: drawings, specifications, bills of material, source code, compiled releases, software configuration, schematics, PCB data, algorithms, inspection criteria, assembly instructions, labeling and test methods. They should identify characteristics essential to safety and performance.
A design output is incomplete when successful implementation depends on unrecorded expert knowledge. Prototype notes and a CAD model may be enough to learn, but they are not automatically enough for controlled transfer.
Use reviews to make decisions
Design reviews should evaluate the adequacy of the design and identify problems. A useful review has a defined scope, entry evidence, qualified participants, recorded findings and clear disposition. It does not need to wait for a large phase boundary.
| Review | Decision focus | Typical evidence |
|---|---|---|
| Product-definition review | Is the intended use and regulatory premise coherent? | User needs, classification research, claims, use environment and open questions |
| Architecture review | Can the proposed system meet requirements and control major risks? | Block diagrams, interface definitions, budgets, risk analysis and feasibility data |
| Detailed-design review | Are outputs complete, consistent and ready for formal evidence? | Design files, analyses, software baselines, drawings and development tests |
| Verification-readiness review | Are methods, samples, fixtures and configurations ready? | Approved inputs, protocols, equipment and traceability |
| Transfer review | Can production reproduce and evaluate the approved design? | Manufacturing documents, supplier controls, process evidence and release records |
Separate verification from validation
Verification demonstrates that design outputs meet design inputs. Validation demonstrates that the device meets user needs and intended uses. A bench test can verify a flow-rate requirement; it may not validate that intended users can safely set up and operate the device in the specified use environment.
The verification plan should trace each input to an appropriate method and result. The validation plan should identify representative users, use conditions, production units or justified equivalents, and the clinical or operational evidence needed for intended use. Both plans need controlled configurations and predefined acceptance criteria.
Integrate risk management throughout the design
ISO 14971:2019 describes a medical-device risk-management process across the lifecycle. Risk management should remain active as architecture, use scenarios, components, software and manufacturing processes evolve.
A risk-control trace should answer:
- What hazard and sequence of events are being addressed?
- What control was selected and why?
- Where is the control specified in the design inputs?
- Which output implements it?
- What evidence verifies implementation and effectiveness?
- What residual risk and new risk remain?
Changes in any link should trigger impact review. A new sensor, different enclosure material or software timeout may affect multiple hazards and tests.
Control configuration before formal evidence begins
Formal results need reproducible baselines. Identify hardware revision, software commit or release, programmable-device image, calibration set, accessory, fixture, test method and environmental condition. If a configuration changes during testing, record the impact and disposition before pooling results.
Configuration control also protects investigation quality. A failure that cannot be tied to a build, log and change history is difficult to diagnose and may have to be repeated.
Plan human factors and cybersecurity as design work
FDA’s August 2026 human-factors guidance emphasizes risk from interactions among users, use environments and interfaces. Usability requirements and risk controls should enter the design inputs, with formative evaluation early enough to influence the design.
For connected devices, FDA’s 2026 cybersecurity guidance recommends security design inputs and acceptance criteria. Security architecture, authentication, authorization, data protection, update behavior, logging and vulnerability response need the same configuration and change discipline as other safety-related functions.
Transfer knowledge into the production system
Design transfer verifies that production specifications correctly represent the design. It includes more than sending released files to a contract manufacturer. The team should confirm critical characteristics, supplier controls, assembly methods, calibration, software loading, inspection, test coverage, packaging, labeling and feedback from pilot builds.
Where process output cannot be fully verified by later inspection and test, the process may require validation. Even where final inspection is possible, process capability and measurement uncertainty can determine whether the acceptance strategy is credible.
Control changes using system-level impact
A design-change record should state the reason, affected configurations, impacted requirements, risks, interfaces, verification, validation, regulatory documentation and production records. The narrowest change can have broad effects: an alternate MOSFET changes thermal behavior and EMC; a UI text change alters human-factors evidence; a supplier firmware revision changes cybersecurity and fault recovery.
Change control should enable good engineering by making impact visible. It should not discourage necessary correction.
Manage development as a traceable argument
The final evidence should support a clear argument: the team understood the intended use and risk, translated them into design requirements, produced controlled outputs, demonstrated conformance, validated the device with representative users and conditions, and transferred a reproducible configuration.
Outer Reef provides medical-device engineering program management and multidisciplinary development that keep those decisions connected across disciplines.
