Validation, Qualification & Assurance

The framework that decides what needs validating and how much: policy, validation master planning, inventories of what is in scope, categorisation, intended use, risk and who is accountable for each lifecycle state.

Without a governing strategy, validation effort distributes by habit — everything gets the same depth, capacity runs out, and the depth applied to a high-risk system is indistinguishable from a low-risk one.

The evidence chain: user need, intended use, critical aspects, risk, design, verification, acceptance — and the traceability that lets any one of them be followed to the evidence that satisfied it.

Traceability is what converts a stack of test results into an argument. Without it, an organisation can show that testing happened but not that the testing covered what mattered, which is the question an inspector actually asks.

Qualifying the physical: design, installation, operational and performance qualification, risk-based verification, leverage of commissioning, release for use and periodic requalification.

Qualification is the evidence that equipment does what the process needs, under the conditions it will meet. Where it duplicates commissioning rather than leveraging it, cost rises and nothing is learned that was not already known.

The three-stage lifecycle: process design, process qualification including PPQ, and continued verification — with the state of control maintained through change rather than proven once.

The lifecycle model exists because three successful batches never demonstrated ongoing capability. Stage 3 is the part most often under-resourced and the only part that shows the process is still doing what it was validated to do.

Validating removal and protection: chemical residue, microbial control, sterilisation cycles and transport — each with limits, worst cases, verification and evidence that control continues.

These validations protect against harm that leaves no signal in the product. Health-based exposure limits made this quantitative rather than conventional, and an organisation still using arbitrary limits is defending a number it cannot derive.

Demonstrating a method is fit for its purpose: performance characteristics, protocol and acceptance criteria, robustness, transfer to receiving laboratories, verification and ongoing monitoring.

Method validation defines the uncertainty attached to every number the method will produce. Where it is done to a template rather than to the decision the result supports, the reported precision does not describe the real one.

Assurance for computerised systems: intended use and process risk, supplier evidence, an appropriate testing method, data-integrity controls, release and periodic review.

Computer software assurance moved the question from "how much documentation" to "what could this system do to the patient or the record". Effort follows risk — but only where intended use has actually been analysed rather than assumed from a category.

Assurance for control systems specifically: control narratives, configuration and parameter sets, alarms and interlocks, recipes, interfaces, testing and keeping the controlled state after go-live.

Control systems are where a small configuration change has a direct physical consequence, and where the change can be made by someone whose role is not framed as making regulated changes. The validated state here erodes through routine engineering work rather than through projects.

Assurance for models and AI: context of use, data provenance and representativeness, performance and its limits, human oversight, evaluation, change and drift management, and a defined fallback.

A model behaves acceptably on the data it saw and unpredictably beyond it, and the boundary is invisible in normal operation. Assurance therefore has to bound the context of use explicitly, because nothing about the system announces when it has left it.

Keeping the validated state after everyone has moved on: periodic review, monitoring, deviations, changes, patches, calibration, maintenance and whether the evidence still supports the claim.

Validation is a claim about the present, maintained by work that is never as visible as the original project. Most loss of validated state is cumulative and undramatic — a patch here, a parameter there — and is discovered during an inspection rather than during operation.