Medical device verification and validation are two jobs. Verification: the device was built to the specifications (the right bridge, built right). Validation: it is the right device for the user in the real environment. This page is design V&V — V-model, 21 CFR 820.30, the Design History File. It is not IQ / OQ / PQ, and it is not a software-lifecycle manual.
If you meant process validation (IQ / OQ / PQ) → medical device validation process. If you meant software V&V / IEC 62304 how-to → medical device software development and medical device software validation. If you meant QMS → medical device quality management system. If you meant risk → medical device risk management. If you meant FDA approval → FDA medical device approval process.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the regulatory agent / QMS vendor / GTM shop.
Verify vs validate
| Verification — built right | Validation — the right device | |
|---|---|---|
| Looks at | Design outputs vs design inputs | Finished device vs user needs in the intended use |
| Evidence | Inspection, analysis, unit / integration / system tests, code review | Usability / human factors, clinical or simulated-use, real environment |
| When | All the way down the build | On the final or production-equivalent unit |
| Insulin pump | Motor delivers 1.0 U when told; battery meets the 24-hour spec | A person with low dexterity can set a dose during a hypo |
A device can pass every bench spec and still fail validation because a nurse cannot set it up in a noisy ICU. That is the whole point of keeping the two words.
21 CFR 820.30 and the DHF
FDA design controls (21 CFR 820.30) require Class II / III (and some Class I) manufacturers to run a controlled design process: inputs, outputs, review, verification, validation, transfer, changes. The Design History File is the story — not a folder you assemble the week of the audit.
ISO 13485 is the QMS that holds the procedures. ISO 14971 is the risk method that tells V&V what to stress. IEC 62304 is the software lifecycle standard in that family — one of three, not this page’s job. Software planning, software of unknown provenance, software unit/integration tests as a lifecycle live on 700. Here, software is a component you still verify and a user interface you still validate.
The V-model
| Left — specify | Right — test against it |
|---|---|
| User needs | User validation (usability, clinical, simulated use) |
| System requirements / architecture | System verification |
| Detailed design (hardware, software modules) | Integration verification |
| Implementation (code, parts) | Unit verification |
Write the right-side protocol when you write the left-side requirement. That is the only way the DHF traces. Implementation sits at the bottom; you climb out with tests that point at a named requirement, not a vibe.
Usability and clinical validation
Human-factors work (IEC 62366 is the usual citation) watches real users do real tasks and counts use errors. Clinical validation puts the device on the indication: does it do the clinical job in the population you claimed. Simulated-use covers environment — EMI, temperature, the messy room — when a full trial is the wrong tool for that question.
Documents that survive an audit: a V&V plan (or VMP for the design side), requirements with IDs, protocols with acceptance criteria written before the run, raw data, a summary that says pass/fail against those criteria. A slide deck is not a protocol.
FAQ
Do we need IQ / OQ / PQ on this page?
No. Those qualify the manufacturing or equipment process. That is process validation.
Is IEC 62304 enough for V&V?
It is enough for the software lifecycle. The device still needs design verification and user validation under 820.30. Do not treat 62304 as a substitute for this page or for software validation.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the regulatory agent / QMS vendor / GTM shop. Case studies.