ISO 13485 7.3.7 design validation: intended use, plans, records and reports

Design verification establishes whether design outputs meet design inputs.
Design validation establishes whether the product meets requirements for its specified application or intended use.
Linking the two requires more than a passed input test: the evidence must also address who will use the product, in which environment and for which purpose.

This article discusses ISO 13485:2016 clauses 7.3.6 and 7.3.7 through a fictional thermometer example.
Document titles and identifiers below are MedQraft implementation examples, not prescribed forms.

1. Different reference points for the conclusion

The distinction is not simply machine testing versus testing with people.
Usability-related inputs can be verified, and validation can involve several forms of technical and clinical evidence.
Identify the requirement and the conclusion each activity supports, rather than classifying it solely by its location or method.

2. A cleared reading does not establish completion of measurement

Consider a fictional home-use thermometer with an input requiring the previous reading to disappear in a specified error state.
A test confirms that behavior.
The result supports that display requirement, rather than every requirement for the product.

During a simulated home-use evaluation, a participant sees the blank screen and puts the thermometer away.
In an interview after the task, the participant explains that the blank screen appeared to mean the power was off.
This observation provides evidence about interpretation and continuation of measurement.
One observation does not establish a population failure rate or a conclusion about the entire device.

The next step is to investigate how the display state, error message, repeat-measurement interaction and instructions work together.
Adding text is a design option to evaluate, not proof of resolution.
After a change, determine the appropriate scope of verification and validation from its impact.

This is a development discovery and improvement example, not a claim of completed final validation.
It addresses one use-related aspect.
Measurement performance and other aspects of the intended use require their own consideration.

3. Define the scope before writing the protocol

Validation needs a planned approach and a defensible relationship between the evaluated product and the conclusion.
Evidence supporting intended use and completion before release are important audit considerations.
See the official MDSAP Audit Approach, Chapter 5 Task 10.

4. Connect the plan, execution record and report

Producing three documents is less important than maintaining a common evaluation identity across them.
Product versions, activity identifiers and the source of acceptance criteria make the conclusion traceable to evidence.

A plan and protocol may be combined, and a report may contain the traceability matrix.
Choose a structure appropriate to the organization's procedures and product complexity.
Consolidating documents should preserve the information needed to reconstruct decisions.

5. Follow one evaluation item through the evidence chain

The following example illustrates traceability.
It is neither a product acceptance standard nor an actual study result.

Avoid recording only an interpretation such as “the user was confused.”
Record the action, its timing and the participant's response to a stated question separately.
If assistance was provided, preserve that fact and evaluate its effect on the result.
Distinguishing post-task interviews from intervention during the task helps protect the meaning of the observation.

Acceptance criteria should be established before results are known.
Do not introduce a convenient threshold retrospectively.
Select participant or sample numbers and repetitions using the evaluation purpose, risk, method and applicable guidance.
Address applicable statistical methods and the rationale for sample size in planning; a single universal number is inappropriate.

6. Assign preparation, review and approval roles

A standard clause should not be treated as a fixed department signature box.
Establish authority and responsibility through organizational procedures and the development plan, with relevant competence involved in review.
One possible allocation is:

• Preparation: Development and evaluation personnel translate the intended use and configuration into the plan and protocol.
  Personnel performing the activity record observations and deviations.
• Technical review: Appropriate reviewers assess whether the methods address the purpose, risk-related items, representativeness and scope of conclusions.
  Usability, clinical or statistical expertise may be needed.
• Quality and regulatory review: Reviewers check applicable requirements, revision control, traceability, unresolved issues and approval conditions.
  Department names may differ across organizations.
• Approval: Authorized personnel approve use of the plan or acceptance of the report under the applicable procedure.
  A signature does not supply missing evidence.

The report should distinguish completion of an activity from sufficient evidence for the intended purpose.
Identify unperformed work, unresolved issues and the responsibility for follow-up.

7. Standards and document-control connections

ISO 13485 is not a product test method that assigns a universal number of users.
Identify product-specific performance and safety standards and market requirements separately.
Record the edition and applicability of each reference used to justify the evaluation.

The FDA guidance Applying Human Factors and Usability Engineering to Medical Devices gives recommendations concerning intended users, uses, environments and use-related risk reduction.
On the review date, the official page identifies an August 2026 version.
Its recommendations should not be presented as mandatory document templates for every jurisdiction.
FDA guidance page

Where clinical evaluation is applicable, it does not automatically mean that a new clinical trial is always required.
Determine the evidence needed for the device and regulatory context.
Completion of a usability evaluation must not be generalized into proof of clinical effectiveness.

8. Revise documents while preserving the history of records

When revising a plan, identify the reason, effective timing, affected activities and approval status.
Do not make an earlier activity appear to have been conducted under a later protocol.
Preserve the connection between the previous plan and its execution records, and identify the revision used for additional work.

Record corrections should follow the organization's procedure and preserve traceability of the original information and correction.
Reissuing a report should retain links to raw data, the earlier conclusion, the reason for revision and the revised conclusion.
Where participant information is involved, define access restrictions and privacy arrangements.

Do not assign an arbitrary period such as five years to every record.
Determine retention requirements using device lifetime, applicable regulation and contractual conditions within the organization's record-control process.
For electronic evidence, consider retrieval, permissions, backup, recovery and change history as well as storage location.

9. Review the links before approving the conclusion

A reviewer should be able to identify the product configuration and intended use from the report, then move from its conclusion to predetermined criteria, actual records and raw data.
Explain how deviations and unresolved items affect the conclusion.

For the fictional thermometer, “the error display was changed” is only an action status.
The evidence should show which use problem was addressed and how the revised configuration was assessed against the relevant requirements and intended purpose.
Include or reference that chain in the design and development file so it remains useful in subsequent changes.

Related insights

• 7.3.3: Design input requirements
• 7.3.5: Design review and necessary actions
• 7.3.6: Verification plans, test records and reports
• QMS insights

Sources and review scope

Reviewed 2026-11-02 using official standards metadata and scope information, the MDSAP audit approach and FDA guidance information.
This article does not reproduce standard text or forms.
For implementation, consult the organization's controlled editions and applicable regulatory texts.

1. ISO 13485:2016, medical device quality management systems.
2. MDSAP Audit Approach AU P0002.011, 2026-08-03, document and record controls and design/development audit considerations.
3. ISO 14971:2019, medical device risk management.
4. IEC 62366-1:2015 AMD1:2020, safety-related usability engineering.
5. FDA human factors and usability engineering guidance, official page labeled August 2026.