3. Regulatory and quality frameworks

Model requalification after a design change or solver upgrade does not exist in a regulatory vacuum. Every regulated model — a pharmacokinetic exposure model, a computational fluid dynamics (CFD) simulation supporting a device submission, a process model used in continuous manufacturing, or a machine-learning classifier embedded in a clinical decision support tool — sits inside a layered framework of external standards and internal procedures. Understanding that framework is what separates a defensible requalification package from a pile of regression plots. The goal of this section is to map the applicable standards to concrete requalification obligations, and to show how internal SOPs translate those obligations into executable work.

The layered structure: regulation, standard, guidance, SOP

Regulatory expectations arrive in four distinct layers, and each layer carries a different kind of authority. Statutes and regulations (for example, 21 CFR Part 820 in the US or EU MDR 2017/745) are legally binding. Consensus standards such as ISO 13485, IEC 62304, or ISO/IEC 17025 become binding when invoked by regulation, contract, or internal policy. Guidance documents — FDA's Assessing the Credibility of Computational Modeling and Simulation in Medical Device Submissions, EMA's modelling-and-simulation reflection papers, ICH Q8–Q10 for pharmaceutical quality systems — describe expected practice without being law, yet deviation requires justification. Finally, internal SOPs are where the organization commits to a specific, auditable method. An inspector will typically read the SOP first, then test whether the model file, change record, and requalification report actually follow it.

A practical consequence: the same solver upgrade can be a minor documentation event under one framework and a full revalidation under another. If a model supports a regulatory decision, the strictest applicable layer governs. Requalification planning therefore begins with a regulatory applicability assessment, not with running the new solver.

Mapping standards to requalification obligations

The table below summarizes how the most commonly encountered frameworks constrain requalification work. The "requalification trigger" column is the operative content — it tells you what event forces action and what evidence the framework expects.

Two patterns are worth extracting. First, nearly every framework ties the depth of requalification to risk and impact on intended use, not to the size of the code change. A one-line solver patch that alters numerical dissipation in a turbulence model can be far more consequential than a large refactor of input parsing. Second, the frameworks consistently demand traceability: the change record must connect to the requirement it affects, the verification activity that re-establishes confidence, and the validation evidence that confirms fitness for the context of use.

From standard to SOP: the internal control chain

Internal SOPs operationalize the external layers. A typical requalification SOP defines the change classification scheme, the impact assessment method, the required verification and validation activities per class, the approval authorities, and the record retention rules. The figure below shows how a change event flows through this control chain and where each external framework exerts its influence.

The dashed feedback path in the figure is not decorative. In practice, the most common audit finding is a requalification plan that was executed as written but whose scope was never revisited after early verification results showed the change was more consequential than classified. The SOP should therefore require a documented re-scope decision point after code verification and before validation comparison.

Writing a defensible change classification

Most requalification SOPs use a three-tier classification. A workable scheme, consistent with the risk-based expectations of the frameworks above, is:

• Class 1 — Cosmetic or non-functional. Documentation, comments, logging format, or UI text with no effect on numerical results. Requalification: regression test on a fixed benchmark case to confirm bitwise or tolerance-level identical output, plus a change record. No revalidation.
• Class 2 — Functional but bounded. Solver option changes, library upgrades, or input-handling fixes that can alter results within a known envelope. Requalification: code verification (method of manufactured solutions or equivalent), solution verification (grid/mesh and time-step convergence), and re-execution of the validation suite against the original acceptance criteria.
• Class 3 — Context-of-use affecting. Changes to the governing equations, turbulence or material models, numerical schemes, or the intended use itself. Requalification: full credibility reassessment — re-establish the question of interest, re-run verification and validation, re-evaluate uncertainty, and obtain regulatory-affairs sign-off before the model returns to service.

The classification must be justified in writing, not merely selected. A useful discipline is to record the worst credible outcome of the change: if the solver upgrade could shift a predicted peak wall shear stress by more than the validation acceptance tolerance, the change is Class 3 regardless of how small the code diff appears.

What the evidence package must contain

Across FDA, EMA, and ISO expectations, a complete requalification package contains five linked artifacts: (1) the change request and classification rationale; (2) the impact assessment tracing the change to affected requirements and validation cases; (3) the requalification plan with pre-defined acceptance criteria; (4) execution evidence — verification results, validation comparisons, and any updated uncertainty analysis; and (5) the approval record with named authorities and dates. The traceability matrix connecting these five is what an auditor will sample. If a validation case was retired because the change made it obsolete, the retirement must itself be justified and the replacement case identified.

Practical example: classifying a turbulence-model upgrade

Consider a CFD model used to support a catheter tip-location submission, validated against particle image velocimetry (PIV) data with an acceptance criterion of ±12% on peak velocity magnitude at three axial stations. The vendor releases a new solver version that changes the wall treatment in the k-ω SST model. The change request is raised, and the impact assessment records: governing equations unchanged, near-wall treatment changed, validation cases sensitive to near-wall shear. The classification is set to Class 3 with the rationale that the change directly affects a quantity the validation cases measure.

The plan pre-specifies: code verification via a manufactured solution for the wall function; solution verification with three mesh levels and a grid convergence index; re-execution of all three PIV validation cases against the original ±12% criterion; and a sensitivity run at the finest mesh to bound the change in peak velocity. Execution shows the new solver shifts peak velocity by +4.1% at station 2, within the ±12% criterion but outside the original solver's ±1.5% run-to-run band. The validation passes, but the uncertainty analysis is updated to reflect the larger solver-attributable uncertainty, and the credibility assessment is re-issued. The package closes with QA approval and the model returns to service under the new solver version, with the old version archived and marked superseded.

This example illustrates the central lesson of the regulatory framework: compliance is not a single document but a chain of justified decisions, each traceable to a standard, executed under an SOP, and closed with evidence that a reviewer can follow without asking the modeler what happened.