Computer System Validation: What CSA Changed

Computer system validation (CSV) is documented evidence that a computerised system does what you rely on it to do, consistently, throughout its life.

It applies to any system whose failure could affect product quality, patient safety or record integrity: LIMS, MES, ERP where it holds batch data, chromatography data systems, electronic batch records, and the spreadsheet somebody built to calculate a release limit.

Scope

Is the system GxP relevant? Does it create, modify, store or transmit a record you rely on for a regulatory decision?

What is the intended use? Validation covers what you use the software for. A system with fifty features and three you rely on is validated against those three.

Getting scope wrong in either direction is expensive. Too wide and you validate functions nobody uses. Too narrow and an unvalidated function turns out to sit under a batch release.

The traditional lifecycle

• User requirements (URS): what you need it to do.
• Functional and design specifications: how it will do that.
• IQ, OQ, PQ: installed correctly, operating as specified, performing in your process with your people.
• Traceability matrix: every requirement mapped to the test that proves it.
• Change control and periodic review thereafter.

A system patched, upgraded and reconfigured for four years without change control is no longer in a validated state.

Computer Software Assurance

FDA's Computer Software Assurance (CSA) guidance responds to validation packages that were heavy on screenshots and signatures and light on analysis of what could fail.

CSA asks for a risk-based approach:

• Establish intended use and whether the feature affects patient safety or product quality directly.
• For high-risk features, scripted testing with recorded evidence.
• For lower-risk features, unscripted or exploratory testing, ad hoc testing, and reliance on the vendor's own testing where justified.
• Record what happened, not a screenshot of every click.

CSA does not reduce the requirement. It moves effort toward risk: for most systems, less documentation on routine functions and more analysis of the few that matter.

Data integrity

Validation should demonstrate that the system enforces ALCOA: that audit trails are enabled and cannot be turned off by the people generating data, that access rights match role, that the clock cannot be altered without a record, and that records can be retrieved for their retention period. 21 CFR Part 11 sets those requirements; validation is how you show they hold.