Not all Equipment is Category 3 in GAMP5

I think folks tend to fall into a trap when it comes to equipment and GAMP5, automatically assuming that because it is equipment it must be Category 3. Oh, how that can lead to problems.

When thinking about equipment it is best to think in terms of “No Configuration” and ” Low Configuration” software. This terminology is used to describe software that requires little to no configuration or customization to meet the user’s needs.

No Configuration(NoCo) aligns with GAMP 5 Category 3 software, which is described as “Non-Configured Products”. These are commercial off-the-shelf software applications that are used as-is, without any customization or with only minimal parameter settings. My microwave is NoCo.

Low Configuration(LoCo) typically falls between Category 3 and Category 4 software. It refers to software that requires some configuration, but not to the extent of fully configurable systems. My PlayStation is LoCo.

The distinction between these categories is important for determining the appropriate validation approach:

Category 3 (NoCo) software generally requires less extensive validation efforts, as it is used without significant modifications. Truly it can be implicit testing.
Software with low configuration may require a bit more scrutiny in validation, but still less than fully configurable or custom-developed systems.

Remember that GAMP 5 emphasizes a continuum approach rather than strict categorization. The level of validation effort should be based on the system’s impact on patient safety, product quality, and data integrity, as well as the extent of configuration or customization.

When is Something Low Configuration?

Low Configuration refers to software that requires minimal setup or customization to meet user needs, falling between Category 3 (Non-Configured Products) and Category 4 (Configured Products) software. Here’s a breakdown of what counts as low configuration:

Parameter settings: Software that allows basic parameter adjustments without altering core functionality.
Limited customization: Applications that permit some tailoring to specific workflows, but not extensive modifications.
Standard modules: Software that uses pre-built, configurable modules to adapt to business processes.
Default configurations: Systems that can be used with supplier-provided default settings or with minor adjustments.
Simple data input: Applications that allow input of specific data or ranges, such as electronic chart recorders with input ranges and alarm setpoints.
Basic user interface customization: Software that allows minor changes to the user interface without altering underlying functionality.
Report customization: Systems that permit basic report formatting or selection of data fields to display.
Simple workflow adjustments: Applications that allow minor changes to predefined workflows without complex programming.

It’s important to note that the distinction between low configuration and more extensive configuration (Category 4) can sometimes be subjective. The key is to assess the extent of configuration required and its impact on the system’s core functionality and GxP compliance. Organizations should document their rationale for categorization in system risk assessments or validation plans.

Attribute	Category 3 (No Configuration)	Low Configuration	Category 4
Configuration Level	No configuration	Minimal configuration	Extensive configuration
Parameter Settings	Fixed or minimal	Basic adjustments	Complex adjustments
Customization	None	Limited	Extensive
Modules	Pre-built, non-configurable	Standard, slightly configurable	Highly configurable
Default Settings	Used as-is	Minor adjustments	Significant modifications
Data Input	Fixed format	Simple data/range input	Complex data structures
User Interface	Fixed	Basic customization	Extensive customization
Workflow Adjustments	None	Minor changes	Significant alterations
User Account Management	Basic, often single-user	Limited user roles and permissions	Advanced user management with multiple roles and access levels
Report Customization	Pre-defined reports	Basic formatting/field selection	Advanced report design
Example Equipment	pH meter	Electronic chart recorder	Chromatography data system
Validation Effort	Minimal	Moderate	Extensive
Risk Level	Low	Low to Medium	Medium to High
Supplier Documentation	Heavily relied upon	Partially relied upon	Supplemented with in-house testing

Here’s the thing to be aware of, a lot of equipment these days is more category 4 than 3, as the manufacturers include all sorts of features, such as user account management and trending and configurable reports. And to be frank, I’ve seen too many situations where Programmable Logic Controllers (PLCs) didn’t take into account all that configuration from standard function libraries to control specific manufacturing processes.

Your methodology needs to keep up with the technological growth curve.

Tom Gauld on Kafka’s book for toddlers

I do enjoy some Kafka-adjacent humor on a Sunday morning.

Risk Assessments as part of Design and Verification

Facility design and manufacturing processes are complex, multi-stage operations, fraught with difficulty. Ensuring the facility meets Good Manufacturing Practice (GMP) standards and other regulatory requirements is a major challenge. The complex regulations around biomanufacturing facilities require careful planning and documentation from the earliest design stages.

Which is why consensus standards like ASTM E2500 exist.

Central to these approaches are risk assessment, to which there are three primary components:

An understanding of the uncertainties in the design (which includes materials, processing, equipment, personnel, environment, detection systems, feedback control)
An identification of the hazards and failure mechanisms
An estimation of the risks associated with each hazard and failure

Folks often get tied up on what tool to use. Frankly, this is a phase approach. We start with a PHA for design, an FMEA for verification and a HACCP/Layers of Control Analysis for Acceptance. Throughout we use a bow-tie for communication.

Aspect	Bow-Tie	PHA (Preliminary Hazard Analysis)	FMEA (Failure Mode and Effects Analysis)	HACCP (Hazard Analysis and Critical Control Points)
Primary Focus	Visualizing risk pathways	Early hazard identification	Potential failure modes	Systematically identify, evaluate, and control hazards that could compromise product safety
Timing in Process	Any stage	Early development	Any stage, often design	Throughout production
Approach	Combines causes and consequences	Top-down	Bottom-up	Systematic prevention
Complexity	Moderate	Low to moderate	High	Moderate
Visual Representation	Central event with causes and consequences	Tabular format	Tabular format	Flow diagram with CCPs
Risk Quantification	Can include, not required	Basic risk estimation	Risk Priority Number (RPN)	Not typically quantified
Regulatory Alignment	Less common in pharma	Aligns with ISO 14971	Widely accepted in pharma	Less common in pharma
Critical Points	Identifies barriers	Does not specify	Identifies critical failure modes	Identifies Critical Control Points (CCPs)
Scope	Specific hazardous event	System-level hazards	Component or process-level failures	Process-specific hazards
Team Requirements	Cross-functional	Less detailed knowledge needed	Detailed system knowledge	Food safety expertise
Ongoing Management	Can be used for monitoring	Often updated periodically	Regularly updated	Continuous monitoring of CCPs
Output	Visual risk scenario	List of hazards and initial risk levels	Prioritized list of failure modes	HACCP plan with CCPs
Typical Use in Pharma	Risk communication	Early risk identification	Detailed risk analysis	Product Safety/Contamination Control

At BOSCON this year I’ll be talking about this fascinating detail, perhaps too much detail.

NIIMBL Experience

Not sure how many students read this, but here is an exciting opportunity.

The NIIMBL eXperience is an exclusive in-person, all expenses paid immersion program that offers students real-world insight into biopharmaceutical industry careers through hands-on activities and direct interactions with industry professionals.

Key program goals:

Increase access to the biopharmaceutical manufacturing industry among traditionally underrepresented populations, including Black, Latinx, and Native American students
Broaden the talent pipelines by connecting industry to talented STEM students
Offer exposure to the biopharma manufacturing ecosystem

Student applications for all seven NIIMBL eXperience 2025 locations are now open. Explore your career possibilities in the biopharma industry. Apply now. The application deadline is February 7, 2025.

Apply for the NIIMBL eXperience

Handling Standard and Normal Changes from GAMP5

The folks behind GAMP5 are perhaps the worst in naming things. And one of the worse is the whole standard versus normal changes. Maybe when naming two types of changes do not use strong synonyms. Seems like good advice in general, when naming categories don’t draw from a list of synonyms.

Computer system changes and the GAMP5 framework

Based on the search results, here are the key differences between a standard change and a normal change in GAMP 5:

Standard Change

Pre-approved changes that are considered relatively low risk and performed frequently.
Follows a documented process that has been reviewed and approved by Change Management.
Does not require approval each time it is implemented.
Often tracked as part of the IT Service Request process rather than the GxP Change Control process.
Can be automated to increase efficiency.
Has well-defined, repeatable steps.

So a standard change is one that is always done the same way, can be proceduralized, and is of low risk. In exchange for doing all that work, you get to do them by a standard process without the evaluation of a GxP change control, because you have already done all the evaluation and the implementation is the same every single time. If you need to perform evaluation or create an action plan, it is not a standard change.

Normal Change

Any change that is not a Standard change or Emergency change.
Requires full Change Management review for each occurrence.
Raised as a GxP Change Control.
Approved or rejected by the Change Manager, which usually means Quality review.
Often involves non-trivial changes to services, processes, or infrastructure.
May require somewhat unique or novel approaches.
Undergoes assessment and action planning.

The key distinction is that Standard changes have pre-approved processes and do not require individual approval, while Normal changes go through the full change management process each time. Standard changes are meant for routine, low-risk activities, while Normal changes are for more significant modifications that require careful review and approval.

What About Emergency Changes

An emergency change is a change that must be implemented immediately to address an unexpected situation that requires urgent action to:

Ensure continued operations
Address a critical issue or crisis

Key characteristics of emergency changes in GAMP 5:

They need to be expedited quickly to obtain authorization and approval before implementation.
They follow a fast-track process compared to normal changes.
A full change control should be filed for evaluation within a few business days after execution.
Impacted items are typically withheld from further use pending evaluation of the emergency change.
They represent a situation where there is an acceptable level of risk expected due to the urgent nature.
Specific approvals and authorizations are still required, but through an accelerated process.
Emergency changes may not be as thoroughly tested as normal changes due to time constraints.
A remediation or back-out process should be included in case issues arise from the rapid implementation.
The goal is to address the critical situation while minimizing impact to live services.

The key difference from standard or normal changes is that emergency changes follow an expedited process to deal with urgent, unforeseen issues that require immediate action, while still maintaining some level of control and documentation. However, they should still be evaluated and fully documented after implementation.