ISO 13485 7.3.5 design reviews: assess requirements, identify issues and track actions
Use a fictional thermometer display to understand design review objectives, participants, evidence, decisions and follow-up actions under ISO 13485 7.3.5.
Design reviews evaluate the design and determine necessary actions
A design and development review evaluates whether design results can meet requirements and identifies problems and the actions they need.
The people involved should work from the same design information and available evidence.
Issues raised in the review need to remain connected to the resulting actions and their resolution.
Under ISO 13485:2016, design inputs in 7.3.3 define what the product must satisfy.
Design outputs in 7.3.4 describe the design that implements those requirements.
Clause 7.3.5 addresses the systematic evaluation of those results: whether the design is suitable, what problems remain and what action is needed.
This article focuses on those decisions rather than repeating the preparation of input lists or drawings.
The official MDSAP Audit Approach checks that reviews occur at suitable stages under the design plan, that relevant functions and necessary specialists participate, and that outstanding actions are being resolved or have been resolved.[1] The thermometer and role assignments below are fictional examples developed by MedQraft, not reports of a real device defect or user study.
Requirements, the identified design and available evidence support the review.
The outcome is an assessment and any necessary actions; a review meeting alone does not establish that all verification is complete.
A fictional thermometer: can the user distinguish a failed measurement?
Assume the development team has established an input requirement for users to recognize a failed measurement.
Review materials include the error-handling requirement, display design, state transitions, relevant risk analysis and the evaluation evidence currently available.
The requirement is abbreviated here for explanation.
An actual input specification needs defined conditions and criteria that allow it to be assessed.
In the proposed display, an error indicator appears while the previous temperature remains visible.
A reviewer raises the possibility that a user could mistake the old value for a new measurement.
The existence of an error message is therefore not sufficient, on its own, to conclude that the requirement has been adequately implemented.
The issue should be more specific than “improve error display.”
Identify the error state, the value that remains visible, the related requirement and the question still to be resolved.
A reviewer's concern is not evidence that actual users have made this error, nor does it establish a frequency of misuse.
| Review connection | What to examine in this fictional case |
|---|---|
| Reference | The input and relevant risk-control requirements for recognizing failed measurements |
| Design under review | Error-state display, treatment of previous values, state transitions and instructions |
| Identified concern | A previous value might be interpreted as a current valid result |
| Evidence gap | How to evaluate that distinction and whether the evidence available is sufficient |
| Necessary action | Decide display changes, assess affected information and behavior, and plan subsequent checks |
Possible options include suppressing the previous value in the error state or clearly separating historical results from the current measurement.
Neither option is a universal instruction for thermometers.
The decision depends on intended use, users, risk analysis and the product's display system, followed by appropriate evaluation.
The left-hand display illustrates a concern to review.
The right-hand display is a possible direction for revision, not a proven safe or usable solution.
It remains subject to appropriate evaluation.
Choose participants for the design stage and the questions being evaluated
The official guidance calls for representatives of functions concerned with the stage under review and any necessary specialists.[1] In practice, identify the knowledge and responsibility needed for the actual decisions rather than inviting the same job titles to every review.
In this example, the display designer can explain error states and treatment of stored values.
A person responsible for usability can assess relevant user conditions and evaluation methods.
Where software behavior or risk controls are affected, include people able to evaluate those aspects.
These are example responsibilities, not mandatory department names specified by ISO 13485.
Before the review, align the identity and revision of the materials.
Reviewing a new display against an obsolete state-transition specification can lead to conflicting conclusions.
Connect the applicable requirements, outputs, risk-management information, available test or analysis results and open issues within a clear review scope.
Turn findings into actions that can be carried out and assessed
“Revision planned” does not explain what will change or how completion will be judged.
The following is a practical tracking structure proposed by MedQraft.
It is not a prescribed ISO form.
| Record element | Example approach |
|---|---|
| Issue and basis | Further assessment of the previous-value display is needed against the identified input and display revision |
| Agreed action | Determine changes to old-value treatment and error guidance; assess affected transitions and instructions |
| Responsibility and timing | Identify who makes the change, who assesses it, and the target in relation to the design plan |
| Method and criteria | Plan checks of behavior in the relevant error conditions and any necessary usability evaluation |
| Completion evidence | Link the revised design, evaluation results and conclusion; keep unresolved items open |
After the change, assess whether evidence addresses the issue raised in the review.
The presence of a revised file is not sufficient.
If evaluation is incomplete, distinguish implementation status from confirmation status.
Decisions on progression depend on the importance of remaining issues and the design plan; avoid treating every open item as equivalent.
Connecting the issue, action and evidence makes resolution traceable.
An item remains open when evidence is insufficient or the problem persists.
Connect reviews with verification and validation while preserving their purposes
Reviews evaluate the ability of design results to meet requirements at suitable stages and identify problems and actions.
Verification establishes whether outputs meet input requirements.
Validation addresses whether the resulting product meets requirements for its specified application or intended use.
A review may evaluate existing verification or validation evidence and call for more work, but agreement among participants does not replace the necessary testing or evaluation.
For the thermometer, checking how a previous value is handled in an error state and evaluating whether intended users understand the failure are different questions.
Select methods appropriate to the product, risk and evaluation purpose.
The detailed roles of verification and validation are addressed by clauses 7.3.6 and 7.3.7.
Keep records of review results and necessary actions, including the identity of the design, participants and date.
Carry out reviews at suitable stages in accordance with documented plans and maintain connections between changing requirements, design information, evidence and open actions.
MDSAP also explains that not every review requires a fully convened meeting.[1] What matters is that its scope, decisions and actions can be followed.
Questions for preparing the next review
- Are the requirements and the identity and revision of the design clear?
- Do the participants cover the functions and specialist knowledge needed for these decisions?
- Are review opinions, established facts and missing evidence distinguished?
- Does each necessary action have responsibility and evidence for judging completion?
- Can the team explain the resolution or continuing management of earlier open items?
These questions are practical suggestions.
Their purpose is to help a reader of the record understand why a decision was made and what remains to be done.
Related articles and clause guide
- 7.3.3 Design inputs: define requirements before design
- 7.3.4 Design outputs: implement requirements in design information
- Responsibilities and checks at design stages
- Quality-system insights and ISO 13485 clause guide
Sources
[1] MDSAP AU P0002.011, MDSAP Audit Approach, revision 2026-08-03, Chapter 5 Task 14, p.93.
Official PDF.
Checked 2026-10-31.
The section maps to ISO 13485:2016 7.3.2 and 7.3.5 and addresses review stages, participation, feedback and outstanding actions.
[2] ISO 13485:2016, clauses 7.3.5, 7.3.6 and 7.3.7. Official ISO standard information.
Read the applicable requirements together with the organization's procedures.
The fictional case and suggested format do not replace the standard.
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 ↗