Medical device software validation is the evidence that the software does its intended use in the real clinical environment — that you built the right system, not only the system you specified. Verification is “built to spec.” Validation is “the spec was the right job.” This page is software validation. It is not IQ / OQ / PQ, and it is not device design V&V.
If you meant device verification vs validation / V-model / DHF → medical device verification and validation. If you meant process validation (IQ / OQ / PQ) → medical device validation process. If you meant software testing (unit / integration / system) → medical device software testing. If you meant IEC 62304 / how the software is built → medical device software development.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the 62304 / validation / vendor house.
Verify vs validate, for software
| Verification — built right | Validation — the right software | |
|---|---|---|
| Question | Does it match the software requirements | Does it meet intended use for the people who will run it |
| Looks at | Spec, design, code, interfaces | Clinical environment, users, other devices, outcomes |
| Typical work | Reviews, unit / integration / system tests | User acceptance, simulated use, clinical or real-world performance |
| Insulin pump | 1.0 U commanded → 1.0 U delivered, on the bench | A person in a hypo can set a dose on the interface that shipped |
A pump can pass every bench spec and still fail validation because the interface is unusable with low dexterity. Keep the two words. The test layers that feed verification are 496. The device-level pair and the V-model are 699 502 — do not copy that job here.
GPSV and the standards around it
In the U.S., FDA’s General Principles of Software Validation is the software-validation guidance: documented evidence, throughout the lifecycle, that the software will consistently fulfil its intended use. EU MDR wants the same idea inside the technical file. IEC 62304 is the software lifecycle standard in that family — one standard, not this page’s how-to. The 62304 process, Class A/B/C, and the DHF trail live on 494. ISO 13485 is the QMS that stores the records — 699 QMS.
Risk class still scales the pack. Class III software is not a Class I checklist with extra headers. Proportion the evidence to the harm, then write it so an auditor can follow the intended-use claim to a result.
Validation lifecycle
| Artefact | Job |
|---|---|
| Validation plan | Scope, roles, methods, acceptance criteria — a working document, not a cover sheet |
| Software requirements | Intended use turned into testable statements (specific, measurable) |
| Test protocols | Steps, expected results, pass/fail written before the run; include the ugly clinical cases |
| Traceability | Every requirement → a protocol → a result. No orphan claims |
| Summary | What ran, what failed, what was fixed, whether intended use holds |
Agile does not pause validation until the last sprint. Bake the protocol into the increment that claims a piece of intended use. Software updates are risk-based re-validation: a copy change is not a new dosage algorithm. Declare the impact, then test that impact — not the entire history every time, and not nothing.
Risk-based, in the clinic
A list of software hazards is not a validation. Tie each hazard to a clinical situation. For a pump: exercise, sleep, a missed calibration, a dead battery, a user who taps twice. Controls have to work in those situations (a hard max dose in software is a control; a warning buried in a PDF is not). Monitor whether the control still holds after release.
Boundary and load tests belong here when they challenge intended use — the glucose meter at the edge of its stated temperature, the imaging tool on a full PACS, not only on a phantom in a lab. Recreating the clinical setting (hardware, data, users) is the difference between a demo and a validation. Anonymised real data beats only-synthetic when the claim is clinical.
Automation helps the repetitive checks. It does not replace a person trying the task the labelling says they will do. Mix them; do not pick a brand of test runner and call it a strategy.
What this page is not
IQ / OQ / PQ qualify a manufacturing or equipment process. That is 699 501. The V-model and the device Design History File as the job are 699 502. This page stops at software intended use.
FAQ
Is IEC 62304 enough?
It is enough for the software lifecycle. You still need validation against intended use (this page) and, for the device, design V&V on 502.
Do we re-validate every patch?
To the risk of the change. A critical-function change reopens the protocols that cover it. A low-impact fix needs a written rationale that says why the intended-use claim still holds.