Verification and Validation

Verification and validation answer different questions

The familiar shorthand is useful: verification asks, “Did we design the device correctly?” Validation asks, “Did we design the correct device?” The two activities overlap, but one cannot replace the other.

A verified display may show every value with the specified accuracy, colour and update rate. Validation may still reveal that an intended nurse cannot interpret the display reliably during a critical task in the real use environment.

MTL-103 — User Needs and Design Inputs explains the source of the questions. MTL-104 — Design Controls and Technical Documentation explains how the resulting evidence forms part of the controlled design record.

Start with an evidence strategy—not a list of tests

An evidence strategy identifies what must be demonstrated, why it matters, the most suitable method, the level at which the evidence belongs and when it is needed. It prevents teams from discovering late that a requirement cannot be tested, a sample is unrepresentative or a critical use scenario was never addressed.

• Identify every applicable user need, design input, risk control, claim, standard and regulatory obligation.
• Decide which conclusions require analysis, inspection, test, demonstration, review, clinical evidence, usability evidence or process evidence.
• Allocate evidence to component, software item, subsystem, system and representative-product levels.
• Define required environments, interfaces, accessories, data, users, fault conditions and lifecycle states.
• Plan sample sizes and statistical reasoning in proportion to variability, risk and the conclusion being made.
• Sequence activities so early evidence reduces uncertainty before expensive formal execution.
• Define entry, suspension, resumption and completion criteria for each evidence phase.

Development testing remains valuable. It explores the design and helps engineers learn. Formal verification or validation has a different purpose: it produces controlled evidence against approved criteria using an identified configuration.

Choose the method that best supports the conclusion

More testing is not automatically stronger evidence. A justified worst-case analysis may be more informative than repeating a nominal test. Conversely, analysis based on uncertain models or uncontrolled inputs may require confirmation through physical testing.

When evidence is reused—from a platform, supplier, previous version or recognised standard—the team must establish its relevance to the current device, configuration, requirements, risks and intended use.

Traceability connects the question, method and conclusion

Traceability should allow a reviewer to move in both directions: from each requirement or risk control to its evidence, and from every verification or validation result back to the approved reason it was performed.

Traceability is not merely a completed matrix. It exposes missing requirements, untested interfaces, duplicate tests, obsolete results and conclusions that depend on unresolved anomalies.

A credible protocol makes the decision reproducible

A protocol should be approved before formal execution and provide enough information for a competent person to repeat the activity and understand the result without relying on undocumented knowledge.

• Purpose, scope and the exact requirements, risks or user needs addressed.
• Responsibilities, required competence and any independence expectations.
• Device, software, accessories, test equipment, tools and data configurations.
• Preconditions, environment, installation, calibration and sample preparation.
• Step-by-step method, including nominal, boundary, fault and recovery conditions.
• Predefined acceptance criteria linked to the intended conclusion.
• Sample size, repetitions and statistical method where relevant.
• Rules for recording raw data, objective observations, deviations and anomalies.
• Conditions for stopping, repeating or invalidating an activity.
• Required review, approval and traceability of the final report.

Acceptance criteria should not be written after the result is known. If the team learns that a criterion was inappropriate, it should control the change, explain the rationale and assess the implications for prior work.

Know exactly what was evaluated

Evidence is only meaningful when the tested configuration is known. The record should identify the device variant, hardware revision, software and firmware versions, calibration state, accessories, consumables, external systems, test data, tools and relevant environmental conditions.

“Same as the last build” is not configuration evidence. Unrecorded substitutions, patches, fixture changes or parameter adjustments can invalidate an otherwise successful result.

Control formal execution without hiding reality

Formal execution should follow the approved method, but control does not mean pretending the unexpected did not occur. Record actual observations, raw data, deviations, interruptions and environmental conditions as they happen.

• Confirm entry criteria and configuration before execution begins.
• Use contemporaneous, attributable and legible records.
• Preserve raw data and identify any processing or transformation applied.
• Do not silently alter steps, parameters, samples or acceptance criteria.
• Record deviations and assess whether they affect result validity.
• Protect electronic records, scripts and test software under appropriate configuration control.
• Ensure reviewers can distinguish observed facts from interpretation.

Automated test systems need their own assurance. The extent depends on what the tool does, the possibility of detecting an error and the significance of an incorrect result.

Anomalies are part of the evidence

A failed test is not erased by a successful retest. The original result, investigation, root cause, correction, risk assessment and regression decision remain part of the development history.

Open anomalies at a gate require explicit assessment. Severity labels alone are insufficient; the decision should consider the affected claim, requirement, risk, user scenario and uncertainty.

Validation must represent intended use

Design validation evaluates the resulting device against its intended use and user needs. It therefore depends on representative product, intended users, relevant patient or specimen characteristics, expected environments, accessories, interfaces and realistic workflows.

MTL-102 — Intended Purpose, Users and Use Environments establishes the boundary conditions. If validation excludes an important user group, home environment, workflow interruption or connected system, the resulting claim must be correspondingly limited or additional evidence provided.

• Use production-equivalent product or document why an alternative is representative.
• Cover intended users and relevant differences in knowledge, capability and training.
• Reproduce meaningful environmental, workflow and interface conditions.
• Evaluate complete tasks and outcomes—not only isolated functions.
• Include applicable clinical, performance and usability evidence.
• Confirm packaging, labelling, instructions, accessories and training as part of the delivered solution.
• Complete validation before release and revisit it when changes affect intended use or user needs.

Several activities use the word “validation”

These activities interact but should not be collapsed into one ambiguous “validation test”. Each has its own question, evidence basis and applicable requirements.

Risk controls and interfaces need explicit evidence

MTL-105 — Medical-device Risk Management explains how risk controls become requirements and verification activities. Verification should confirm both that each control is implemented and that it is effective in the relevant sequence of events.

Interfaces deserve special attention because responsibility is frequently divided. Evidence may need to cover device-to-device connections, software APIs, accessories, alarms, consumables, user hand-offs, service tools, manufacturing data and external infrastructure.

A component-level pass does not prove system-level effectiveness. If a safety function depends on a sensor, algorithm, actuator, power supply and user response, the strategy must demonstrate the complete control path and relevant failure conditions.

Separate ownership, execution and approval deliberately

The organisation should define who plans evidence, who creates the design, who executes the activity, who reviews the result and who accepts the resulting product or risk decision. The required degree of independence depends on applicable standards, risk and organisational capability.

Independence is not achieved merely by moving a signature to another department. Reviewers need suitable competence, access to the evidence and authority to challenge the conclusion.

Use evidence maturity at development gates

MTL-101 — The Medical-device Development Lifecycle places these gates within the wider flow from intended purpose to post-market learning.

Worked example: a connected injection device

A user need states that an intended patient must be able to complete a prescribed injection at home and understand whether the dose was delivered. Design inputs define delivered-volume accuracy, injection time, audible and visual feedback, fault responses, operating temperature, connectivity behaviour and the information presented by the companion application.

If all quantitative requirements pass but intended users cannot distinguish a completed injection from a recoverable interruption, verification may be successful while validation is not. The finding must feed back into user needs, risk, interface design and regression evidence.

Common failure patterns

Practical verification and validation checklist

• Intended purpose, users, environments, user needs and claims are approved.
• Design inputs are measurable, unambiguous and traceable.
• Risk controls have implementation and effectiveness evidence.
• The evidence strategy covers component, subsystem, system and representative-product levels.
• Methods, acceptance criteria and statistical rationale are approved before execution.
• Samples, configurations, tools, data and environments are controlled and recorded.
• Interfaces, boundary conditions, faults and recovery paths are included.
• Raw data, deviations, anomalies and failed results are preserved.
• Regression scope is justified after every relevant change or failure.
• Validation represents intended users, workflows, environments and delivered product.
• Traceability supports both requirement-to-result and result-to-requirement review.
• Release conclusions match the exact configuration supported by the evidence.