Worksheet: System Suitability Limit Derivation from Development Data

This is a ready-to-use worksheet for deriving system suitability limits from studied development data, rather than from a compendial default or a copied template. It reproduces the derivation step by step, for each system suitability parameter, so a reviewer can trace the limit directly to the worst-case observation it was set from. Replace every <<FILL: ...>> placeholder. This content is educational reference, not statistical consulting advice; have a qualified statistician confirm the method and any distributional assumptions for your actual data.

Header

Inputs

Derivation steps

1. Identify the worst-case corner. Across every studied condition (not only the nominal center point), find the combination of parameter values that produced the least favorable result for this system suitability parameter. <<FILL: state the corner and the observed value>>
2. Confirm the worst case is genuinely represented, not extrapolated. The worst-case value must come from an actual executed run within the studied range or MODR, not an extrapolation beyond studied conditions. <<FILL: confirm Yes/No; if No, this derivation is not valid until the corner is actually studied>>
3. Apply a margin appropriate to routine variability. A limit set exactly at the single worst observed value leaves no margin for ordinary run-to-run variation; a limit set with excessive margin stops protecting the ATP requirement. State the margin approach used. <<FILL: e.g. limit set at the worst-case observed value rounded to a conservative, ATP-protective round number; or a statistically derived margin from the repeated worst-case-corner runs>>
4. Set the limit. <<FILL: the resulting system suitability acceptance criterion, e.g. "not less than 2.0" or "not more than 1.0%">>
5. Confirm the limit still protects the ATP. Restate, in one sentence, why meeting this limit means the ATP requirement is met. <<FILL>>

Result

Acceptance criteria

• Every system suitability limit on this worksheet traces to an actual studied worst-case observation, not to a compendial default, a competitor’s method, or a prior product’s limit copied across.
• The worst-case corner used is documented with its specific parameter values, not described only as “the edge of the range.”
• The margin approach is stated explicitly, not left implicit in a rounded number with no rationale.
• A limit derived here that later proves too tight or too loose in routine use triggers a documented review of this worksheet, not a silent adjustment of the routine acceptance criterion.

References

ICH Q14, Analytical Procedure Development (system suitability as part of the control strategy, derived from development understanding). ICH Q2(R2), Validation of Analytical Procedures (performance characteristics the system suitability limit ultimately protects).

Confirm the current version of each reference before issue.

Filled specimen

A completed worksheet for the reverse-phase gradient assay used as the running example in the ICH Q14/Q2(R2) article and its accompanying development report. Illustrative only.

1. Worst-case corner: pH 2.8, column temperature 37 C, resolution 2.1, the lowest resolution observed across all 13 studied conditions including the 4 MODR corner-point confirmation runs.
2. Corner genuinely represented: Yes, executed as run 11 of DOE-AD-027, not extrapolated.
3. Margin approach: limit set at the worst-case observed value with no further reduction, since 2.1 already sits at the boundary the MODR was defined to guarantee; a limit set higher (for example 2.2) would fail some of the method’s own claimed operating region and contradict the MODR statement.
4. Limit set: critical-pair resolution not less than 2.0.
5. ATP protection: a run meeting “resolution not less than 2.0” at any point inside the claimed MODR is confirmed, by the development data, to still separate the analyte from D1-D3 at or above the specificity requirement in ATP-2026-011.

Common inspection findings this worksheet prevents

• A system suitability limit that matches no evidence in the development file when a reviewer asks “why this number.”
• A limit set from the nominal, center-point condition rather than the worst case actually studied, so routine batches near the edge of the MODR can fail system suitability unpredictably or, worse, pass when they should not.
• A limit tightened or loosened after routine data comes in, without a documented review connecting the change back to this derivation.
• A claimed MODR whose corner points were never actually run, so the “worst case” used to set the limit is an assumption, not an observation.

How to adapt this worksheet

1. Run one worksheet per system suitability parameter; do not combine multiple parameters into a single derivation.
2. Pull the worst-case condition and its observed value directly from the development report’s raw data, not from a summary table.
3. If a claimed MODR corner was never actually executed, stop: study it before using this worksheet to set a limit from it.
4. Have a second reviewer confirm the worst-case identification and the arithmetic before the limit is written into the analytical procedure development report or the validation protocol.