ISO 13485 7.3.3 design inputs: define use, performance and safety requirements
Turn a vague goal such as a fast, accurate thermometer into assessable design inputs.
A fictional example connects use conditions, performance, safety, evidence and review under clause 7.3.3.
Define the conditions the design must satisfy
Before developing the detailed design, turn the intended use and the necessary function, performance, usability and safety into requirements that can be assessed.
“Fast and accurate” expresses an ambition.
It does not tell a designer or evaluator what result is acceptable, under which conditions, or why that result is appropriate.
This article addresses ISO 13485:2016 clause 7.3.3, design and development inputs.
Our preceding article on clause 7.3.2 connected development activities with responsibilities.
Here the focus is the required properties and behavior of the product.
Information from product realization planning under 7.1 and customer-related processes under 7.2 can contribute to those inputs.
The official MDSAP audit approach links clause 7.3.3 with establishing, reviewing and approving inputs, including intended use, functional, performance and safety requirements, applicable regulatory requirements and risk management results.
It also examines completeness, clarity, consistency and verifiability.[1] The thermometer example and document arrangements below are MedQraft's practical illustrations.
Translate an aspiration into conditions and requirements.
“Fast” alone does not define the timing conditions or an acceptance criterion.
Fictional example: a fast, accurate home thermometer
Imagine a team considering an electronic thermometer for a caregiver to measure a child's temperature at home.
Its first draft says only “measure quickly and accurately.”
One developer may focus on measurement time while another reader thinks about the number of displayed digits.
They are giving different meanings to the same instruction.
The team first defines the intended user and patient population, measurement site and method, and use environment.
Calling the device an electronic thermometer does not determine whether it is contact or non-contact, or which site it measures.
Filling in a convenient accuracy or time value before establishing that context can fix an inappropriate target.
No actual measurement range, permissible error or time limit is prescribed here.
The table identifies decisions and evidence needed to complete requirements.
An unresolved numerical field is not an approved, complete design input.
| Starting phrase | Context to establish | Content to specify | Illustrative assessment approach |
|---|---|---|---|
| Suitable for home use | User, patient population, measurement site and method, environment | Measurement and reading tasks to be supported under those conditions | Use-scenario analysis and appropriate user evaluation |
| Accurate | Measurement range, reference comparison conditions, environmental range | Performance criteria and permissible error under defined conditions | Performance evaluation using suitable reference methods |
| Fast | Definitions of measurement start, completion and readiness | Permitted time to completion under the stated conditions | Timing with consistent start and end conditions |
| Avoid misleading the user | Foreseeable invalid measurements and associated harm | Risk controls to prevent an invalid measurement being mistaken for a normal result | Evaluation of specified error conditions and user recognition and response |
The final row is a possible risk-control requirement for this fictional product.
It is not a universal requirement for every thermometer to use the same error detection or display.
The relevant technology and risk analysis determine which conditions can be detected and which response is appropriate.
Collect evidence beyond a customer request
A customer request alone is unlikely to cover every relevant input.
The following original guide organizes information to consider when applying clause 7.3.3; it is not a reproduction of an ISO table or a prescribed form.
| Information to examine | Question for the fictional thermometer team |
|---|---|
| Function, performance, usability and safety for the intended use | Who measures whose temperature, at which site, under which conditions, and with what required result? |
| Applicable regulations and standards | Which requirements apply to the target markets and device method, and which editions and conditions were reviewed? |
| Risk management outputs | Which product requirements implement the controls identified through risk analysis? |
| Relevant information from previous similar designs | Which earlier use problems or complaints also matter for this product? |
| Other essential conditions | Are compatibility, maintenance, storage or other product-specific needs missing? |
An earlier model's specification is evidence to assess, not an automatic answer for the new device.
A different user, measurement method or environment can change whether earlier test conditions and controls remain appropriate.
Similarly, a list of standard titles is more useful when it identifies the particular requirements and conditions that influence the design inputs.
Connect each requirement to conditions and a basis
MedQraft suggests linking a requirement identifier, requirement statement, applicable conditions, source or rationale, assessment approach and review status.
Those field names are a practical suggestion, not mandatory ISO column headings.
Their purpose is to make the origin of a requirement and the basis for judging it traceable.
For example, “measurement time must be short” has no start or end point.
Timing from power-on and timing from the start of measurement can produce different results.
Review the relevant requirements and intended use, establish the criterion, and make its conditions available in the requirement or a linked document.
An assessable requirement does not always need a number.
Required behavior in a defined state, information to be provided, and completion of a user task can also be specified clearly and evaluated appropriately.
Words such as “convenient,” “sufficient” or “if possible,” without further definition, invite evaluators to apply different criteria.
Connect the statement with its conditions, basis and assessment approach.
The record arrangement is illustrative; actual methods and acceptance criteria need product-specific evidence.
Considering how a requirement can be assessed at the input stage does not replace subsequent detailed verification and validation planning.
Clause 7.3.6 addresses whether design outputs meet input requirements; clause 7.3.7 addresses suitability for the specified application or intended use.
A single performance test should not be assumed to answer every usability and safety question.
Distinguish a required outcome from an implementation idea
“The caregiver can recognize that measurement is complete” and “place a particular colored LED on the front panel” describe different levels of information.
Clarifying the required function and use conditions first allows the team to evaluate possible implementations, such as visual or audible feedback, against that need.
This does not prohibit technical constraints in the inputs.
A contract, interface compatibility requirement or regulatory condition may constrain structure or components.
Record that constraint and its basis where applicable.
The point is to avoid turning an unsupported early idea into a mandatory requirement by accident.
Resolve ambiguity and conflict before approval
Suppose the fictional team records both “completion must be audible” and “the device must make no sound during use.”
Without conditions, those statements conflict.
Determine which users and environments need which feedback, distinguish the conditions or adjust the requirement, and retain the rationale.
Approving both statements unchanged leaves the implementation team to choose between them.
Review whether the inputs are sufficiently complete, have a clear meaning, are consistent with one another and can be assessed.
Track unresolved conditions, the evidence or action needed to resolve them, and their implications for related design work.
A “to be decided” field should not be treated as a completed input.
Review establishes whether the inputs are a usable design basis.
This original diagram includes resolution of open items in the review before approval.
Inputs are not necessarily written once and then frozen forever.
When use conditions or risk analysis change, assess the effects on related requirements, design and assessment activities, and apply the organization's change procedures.
The central point of clause 7.3.3 here is to establish, review and approve clear product requirements with the conditions and evidence needed to support them.
Sources and scope
- MDSAP Audit Approach, MDSAP AU P0002.011, revised 3 August 2026.
Chapter 5, Tasks 5 and 6 on inputs and their review, and Tasks 7 and 10 on outputs, verification and validation.
Official document page. - ISO 13485:2016 official publication information.
Third edition, 2016, shown as current after confirmation in 2025.
Checked 28 October 2026.
This is a public-source explanation, not a reproduction or official translation of the standard.
The thermometer, record arrangements and review questions are fictional examples and practical suggestions.
Determine numerical criteria and applicable regulations and standards for the actual target markets, intended use and device characteristics.
Related reading
- Clause 7.3.2: stage responsibilities and decision criteria
- Clause 7.1: planning product realization
- Clause 7.2: requirements review before order acceptance
- QMS topics and the ISO 13485 clause guide
Continue through ISO 13485 clauses
Let's talk
Apply what you have read
to your product.
Tell us your product's current stage and the questions you need to review.
Discuss your questions ↗