GAMP 5 Category 5: validating custom-built pharmacy software
GAMP 5 is the pharmaceutical industry's working framework for computerized system validation. Its central idea is proportionality: the deeper the system's novelty and risk, the deeper the validation. Custom-built software sits at the deep end, and a buyer should know what that obliges the vendor to produce.
The categories, briefly
| Category | What it is | Validation depth |
|---|---|---|
| 3 · Non-configured | Off-the-shelf product used as installed | Lightest: verify installation and intended use |
| 4 · Configured | A product configured to the process (most commercial pharmacy systems) | Verify the configuration against requirements |
| 5 · Custom | Software written for the operation, including custom extensions to a product | Full lifecycle: the buyer's process is the specification |
What Category 5 obliges
For a custom application there is no installed base to lean on, so the evidence has to be built alongside the software:
- User Requirements Specification. What the operation needs the system to do, in the operation's terms, each requirement identifiable and testable.
- Functional and design specifications. What the system does and how it is built, at a depth a successor engineer could maintain.
- Qualification protocols. Installation Qualification (it is installed as specified), Operational Qualification (each function performs as specified), Performance Qualification (the system performs in the real workflow, with the real people).
- A traceability matrix. Every requirement traces to a design element and to the test that proves it. An inspector reads this document first, because it shows whether the rest is connected or theatrical.
- Supplier assessment. The facility evaluates the vendor's development discipline: version control, code review, testing, release management.
The second edition of GAMP 5 (2022) is explicit that this is compatible with modern engineering: iterative development, automated testing, and critical thinking over checkbox ceremony. The deliverable is defensible evidence, not a particular binder format.
Authored, executed, and the difference
A validation package exists in two states, and honest vendors name the state. Authored means the protocols and specifications are written against the system. Executed means the facility has run them, recorded the results, and resolved the deviations. Execution belongs to each facility and precedes putting the system into regulated use. A vendor who says "validated" without saying which state, and for which facility, is selling the word rather than the work.
What software validation is not
Computerized system validation is not FDA approval, clearance, or inspection, and it does not transfer between facilities. Each facility executes its own qualification for its own scope. What a well-built Category 5 package gives the second facility is a head start measured in months, not an exemption.