The medical device validation process on this page is process validation: Installation, Operational, and Performance Qualification, plus the statistics that make a sample mean something. It is not “are we building the right device” (that is design V&V) and it is not software validation.
If you meant verification vs validation / V-model / DHF → medical device verification and validation. If you meant software validation → medical device software validation. If you meant QMS → medical device quality management system.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the regulatory agent / QMS vendor / GTM shop.
Why the line exists
Verification (design outputs = design inputs) and design validation (the finished device meets user needs) are the V&V page. Process validation is the manufacturing and equipment question: can this line, this clean, this steriliser, this imaging-chain config, produce the same conforming device again.
You need it when end-of-line test would destroy the unit, when 100% inspection is a fantasy, or when the process itself is the quality argument (sterilisation, seal, clean). FDA’s process-validation guidance is three stages: design the process, qualify it, then keep watching it. IQ / OQ / PQ are the qualification stage.
IQ, OQ, PQ
| Phase | Question | Typical evidence | Usual miss |
|---|---|---|---|
| IQ | Is it installed as specified | Install records, utilities, calibration certs, manuals | Missing cert; wrong firmware; undocumented utility |
| OQ | Does it run inside the stated range | Challenge at the edges, alarms, interlocks, software screens | Only the happy path; no worst-case load |
| PQ | Does it hold under real production | Consecutive lots or runs, real materials, operators, shifts | Engineering samples that are not the line |
A CT or ultrasound chain: IQ is power, network, and the manufacturer’s install checklist. OQ is image quality, timing, and transfer at the specified settings. PQ is representative studies, real techs, the same PACS path the hospital will use — not a phantom-only afternoon. Software that is the device still has its own validation on 700; this page is the process around it.
Manufacturing stages (FDA guidance)
| Stage | Job | What you freeze |
|---|---|---|
| Process design | Name critical process parameters and their windows | Materials, equipment, CPPs (time, temperature, pressure, dose) |
| Process qualification | IQ → OQ → PQ on that design | A qualified line and a protocol pack |
| Continued process verification | The line stays in control after the party | Monitoring, change control, re-qualification when the change is big enough |
A change to a CPP, a new supplier lot that is not equivalent, a moved steriliser — those reopen qualification. “We validated it in 2022” is not a state. It is a date.
Statistics that earn the sample
You do not test every unit. You take a sample that can support the claim. AQL (ISO 2859-style) sets an acceptable quality level for lot inspection. LTPD / success-run sampling answers “how many consecutive passes do I need to claim reliability R at confidence C.” The common zero-defect formula is n = ln(1 − C) / ln(R). For 99% reliability at 95% confidence that is 299. That number is a method, not a lucky sample size for every process. High-risk cleans and sterilisers often sit in that neighbourhood; a low-risk cosmetic step does not.
DOE (design of experiments) is how you find which CPPs actually move the output before you freeze the window. Confidence intervals say how tight the estimate is. Hypothesis tests say whether two set-ups differ for a reason. Pick the tool from the risk, not from the software you already own.
The QMS that files the protocols and the deviations is ISO 13485 / 820. Risk that sets the sample is ISO 14971.
FAQ
Is this the same as design validation?
No. Design validation asks whether the device meets user needs. Process validation asks whether the process can make that device again. The first is 502.
Do we need 299 units every time?
No. 299 is one success-run answer for 95/99. Justify n from the risk and the claim. A destructive test on a high-risk process needs a written rationale, not a copied blog number.
If the device is imaging software, PYCAD is the imaging stack (viewer / model), not the validation shop. Case studies.