Medical Device Cpk Requirements

How does capability evidence fit into IQ/OQ/PQ validation and risk-based acceptance without inventing a universal FDA or ISO 13485 Cpk threshold?

• Predefine the index, sigma estimator, sample plan, and acceptance criterion.
• Demonstrate stability and measurement adequacy before interpreting capability.
• Use risk-based criteria and alternative methods for non-normal or attribute outputs.

Neither ISO 13485 nor 21 CFR Part 820 specifies a numeric Cpk. Capability is one input to process validation (IQ / OQ / PQ) and to risk-based acceptance under ISO 14971. Acceptance criteria are set in the validation protocol, justified by risk and by measurement uncertainty, and approved before execution. Any "medical device requires Cpk 1.33" claim is a customer or internal convention, not a regulation.

1. Reference the risk file — capability target must trace to a hazard and harm severity, not to a copy-paste 1.33.
2. Author the validation protocol with pre-approved acceptance criteria and sampling rationale.
3. Qualify the measurement system with traceable calibration and documented uncertainty.
4. Execute OQ at process window edges to demonstrate capability across worst-case operating conditions.
5. Execute PQ under representative production, with statistically justified sample size.
6. Log every deviation; a failed criterion is a CAPA input, not a study to re-run.
7. Re-validate on defined triggers: design change, process change, supplier change, drift observed in monitoring.

• Cpk target set by copy-paste from another product, not from risk analysis.
• Sampling plan without documented rationale.
• Measurement uncertainty not quantified; Cpk reported to two decimals inside gauge noise.
• OQ executed inside a narrow, comfortable window rather than the validated worst case.
• Traceability gap between measured lot, calibration record and DHR.
• Re-validation triggers not defined; drift in monitoring never escalates.

• Capability numbers without measurement uncertainty are unauditable — Cpk within measurement noise is not capability.
• Sampling "n = 30" without a risk-based rationale is the most common validation audit finding.
• OQ that only tests nominal conditions is not OQ; it is PQ mislabeled.
• A "successful" PQ that hides an OQ excursion will surface as a field complaint months later.

• Do not use capability alone as validation evidence — IQ, OQ and PQ together form validation.
• Do not report Cpk without stating measurement uncertainty.
• Do not rely on a single PQ result for the life of the product; define re-validation triggers.

• Cpk vs measurement uncertainty: Cpk is only meaningful when the ratio of uncertainty to tolerance is documented and acceptable.
• Capability vs sampling: Sample size traces to risk, not to statistical convenience.
• PQ Cpk vs monitoring: Ongoing monitoring must be able to detect drift within the validated window.

Use the free Process Capability Calculator to compute Cp, Cpk, Pp, Ppk, sigma level, and predicted PPM from your measurement data — no sign-up required.

• Never claim regulatory compliance from a numeric Cpk alone — validation is a documented process, not a number.
• Never approve a protocol without pre-defined acceptance criteria.
• Never close a deviation without a CAPA linkage.

• ✓Acceptance criterion traced to risk analysis
• ✓Validation protocol approved before execution
• ✓Measurement uncertainty quantified and documented
• ✓Sampling rationale documented, not defaulted
• ✓OQ executed at worst-case within specification
• ✓PQ executed under representative production conditions
• ✓Re-validation triggers defined and monitored

• Process condition: statistical stability is required.
• Distribution assumption: use a distribution model justified for the data.
• Confirm process stability and measurement-system adequacy before interpreting a capability index.
• Use a justified distribution model or non-normal method when the normal model is unsuitable.
• Numerical targets shown on industry pages are common examples, not universal requirements. The contract, drawing, customer-specific requirement, Control Plan, and validation protocol take precedence.