Two words that sound interchangeable answer completely different questions. Verification asks whether you built the device right — does it meet the specifications you wrote? Validation asks whether you built the right device — does it meet the actual needs of the user and patient in real conditions of use? A device can pass every verification test and still fail validation, and that failure is the expensive one, because it means the specifications themselves were wrong.

This article is general engineering education, not regulatory or legal advice. Projects House is an engineering firm; confirm your specific regulatory path with qualified regulatory counsel.

A concrete example

Suppose your specification says an infusion pump shall deliver flow accurate to within a stated percentage.

  • Verification: set the pump to a range of rates on the bench, measure delivered volume against a calibrated reference, confirm the error stays inside the specified limit across the operating range, at temperature extremes, and at end of battery life. Objective evidence against a written requirement.
  • Validation: put the pump in front of actual nurses on an actual ward, with real patients or a high-fidelity simulation, and confirm it delivers the therapy safely under the pressures of real work. Perhaps the accuracy is perfect but the rate is entered in units that invite a decimal-point error at three in the morning. Verification passes. Validation fails.

That is the whole distinction, and it is why validation cannot be done on the bench by the engineers who designed the device.

Verification in practice

Verification is testing against design outputs. It is planned, protocol-driven, and traceable:

  • Every requirement in the design input document needs at least one verification activity linked to it.
  • Methods include bench measurement, inspection, analysis, and standards-based testing — electrical safety per IEC 60601, biocompatibility testing of patient-contacting materials, sterilization efficacy, package integrity, software unit and integration testing.
  • Tests must run on devices representative of production — same materials, same process, same supplier. A hand-built prototype does not verify a molded production part.
  • Sample sizes need a documented statistical rationale, not a convenient number.
  • Results are recorded as pass or fail against pre-defined acceptance criteria written before the test ran.

The output is a traceability matrix showing every requirement is covered and every test passed — the backbone of the file described in the design history file.

Validation in practice

Validation tests against user needs, which are broader and softer than specifications. It typically includes:

  • Simulated or actual use testing with representative users — clinicians, patients, or caregivers, not the development team — in a representative environment.
  • Human factors and usability validation, which for many devices is a formal study focused on use-related hazards rather than user satisfaction. This is a discipline in itself; see medical device usability engineering.
  • Clinical evidence where the intended use requires it, ranging from a literature-based justification to a full clinical study. Scope is discussed in medical device clinical trials.
  • Software validation in the intended environment, on the intended platforms, with real data.

Validation is performed on initial production units or their equivalent, under actual or simulated use conditions — a device built on a different process is not the device you are validating.

A third term people mix in: process validation

Design verification and design validation both concern the device. Process validation concerns manufacturing: proving that a process whose output cannot be fully verified by inspection — sterilization, injection molding of a critical dimension, adhesive bonding, welding, cleaning — consistently produces conforming product. It is usually structured as installation, operational, and performance qualification. If a process output can be fully inspected on every unit, you verify it; if it cannot, you validate the process. This sits alongside the quality system requirements in ISO 13485.

Where the regulation puts them

Both activities are explicit elements of the FDA's design control requirements, which structure development as user needs feeding design inputs, inputs feeding outputs, outputs verified against inputs, and the finished device validated against the original user needs. Design reviews gate each transition, and risk management runs alongside throughout. The framework is walked through in FDA design controls, and the risk process that interlocks with it in ISO 14971 risk management. Every risk control measure you identify has to be both implemented and shown effective — which is verification and validation again, applied to the controls themselves.

When each happens in a project

Verification is iterative and starts early. You verify subsystems as they mature, then verify the integrated device formally once the design is frozen. Validation comes later by necessity, because it needs production-representative units. In practice the sequence is: freeze the design, build a pilot lot on production tooling and processes, run formal verification on those units, then run validation with real users.

The scheduling trap is treating both as a single block of work at the end. Formal verification on a device with unstable requirements is wasted money, because every design change invalidates completed tests.

Mistakes we see repeatedly

  • Requirements that cannot be tested. "Easy to use" and "durable" are not requirements. If you cannot write an acceptance criterion, you cannot verify it.
  • Verifying prototypes. Testing hand-built units and calling it design verification. The molded, sterilized, production-process device is what must pass.
  • Validating with the development team. Engineers who designed the interface cannot discover that it confuses users.
  • Writing acceptance criteria after seeing results. An auditor will notice, and it undermines the whole file.
  • Skipping process validation on a process whose output is invisible — a bond line or a seal that looks fine and is not.
  • Leaving traceability until the end, then reverse-engineering it from memory.

How Projects House approaches it

We write requirements in testable form from the first design input review, because a requirement that cannot be measured becomes an argument later. More on this area is collected on our medical device development page.

Plan your V&V before you freeze the design

If you are approaching design freeze and want the verification and validation plan built around your device rather than bolted on, send us the details through the contact form.