Software Category Classification: Focus on User Requirements, Not Labels

The purpose of validation is to verify, based on objective evidence, that the completed software meets the requirements. In other words, software validation reaches its goal when it satisfies the User Requirement Specifications (URS).

GAMP (Good Automated Manufacturing Practice) categorizes software as follows, though it’s important to understand these categories in the context of current regulatory thinking:

Understanding GAMP Software Categories

GAMP 5 (Second Edition, 2022) defines the following categories:

Category 1 represents infrastructure software such as operating systems and database management systems. These provide general functionality and are not configured for specific applications.

Category 3 encompasses non-configured products where standard package functionality directly meets user requirements without any configuration or customization. Examples include analytical instruments with embedded firmware and facility equipment with built-in control systems. These systems are used “as-is” with their standard functionality.

Category 4 covers configured products, where standard package functionality is adapted to meet user requirements through configuration settings without modifying the source code. Document management systems, Manufacturing Execution Systems (MES), and Laboratory Information Management Systems (LIMS) are typical examples. Configuration involves setting parameters, defining workflows, creating forms, and establishing user roles within the system’s designed capabilities.

Category 5 includes custom applications where software is developed or significantly customized through programming to meet specific user requirements. This involves writing new code, developing custom modules, or substantially modifying existing software beyond standard configuration options.

GAMP Category	Type	Approach	Examples	Typical Validation Effort
Category 1	Infrastructure Software	Use as-is	Operating systems, databases	Supplier assessment
Category 3	Non-configured Products	Use standard functionality	Analytical instruments, basic equipment	Limited testing of intended use
Category 4	Configured Products	Configure within system capabilities	DMS, MES, LIMS	Configuration testing and verification
Category 5	Custom Applications	Develop or customize code	Bespoke applications, heavily modified systems	Comprehensive testing including code review

The Critical Point: User Requirements Are the Goal, Not Category Classification

What requires careful attention is that the goal is to build software that meets all user requirements—category classification is merely a tool to help determine the appropriate validation approach, not an end in itself.

I frequently encounter questions such as “What category is this software?” or “Can we somehow make this Category 4?” This approach misses the fundamental point entirely. While Japan’s Ministry of Health, Labour and Welfare (MHLW) “Guideline on Management of Computerized Systems for Marketing Authorization Holders” (revised 2021) emphasizes category classification, Japan is unique in this regard among global regulatory frameworks. Neither the FDA nor PIC/S guidance documents focus on categorical classification in the same manner. Instead, international guidance emphasizes risk-based approaches and the importance of understanding system criticality and complexity.

Practical Example: Microsoft Excel

Consider Microsoft Excel to illustrate how category classification depends on usage, not the software itself.

When you simply install Excel without creating any files, you’re working with Category 1 infrastructure software. If you use Excel as a word processor—creating documents with text and borders but no calculations—this represents Category 3 usage, employing standard functionality as-is. When you incorporate formulas and calculations (for example, creating an invoice that automatically calculates totals), you’re performing configuration activities characteristic of Category 4. Finally, if you write macros or VBA programs to automate complex processes or create custom functionality, you’ve moved into Category 5 territory involving custom programming.

Therefore, asking “What category is Excel?” is a nonsensical question. The correct question is: “What category does this specific use of Excel represent?”

Furthermore, a single Excel workbook can contain multiple sheets serving different purposes. Sheet 1 might serve as a cover page using standard word processing features (Category 3). Sheet 2 might contain formulas for calculations (Category 4). Sheet 3 might include macros for automation (Category 5). This means that within a single IT application, categories can and do coexist. Consequently, rigidly classifying an entire application into a single category becomes meaningless and can actually hinder appropriate validation planning.

Category classification works effectively for structural equipment and analytical instruments with fixed functionality, but becomes problematic when applied to flexible software applications.

Risk-Based Approach: The True Foundation of Software Validation

What truly matters when implementing software validation is not category classification, but rather adopting a comprehensive risk-based approach. Current international guidance, including ICH Q9 (Quality Risk Management) and ICH Q10 (Pharmaceutical Quality System), emphasizes that validation efforts should be proportional to the risk that a system failure could pose to product quality, patient safety, and data integrity.

Consider these scenarios: Even for Category 3 software, if you’re manufacturing high-risk products such as oncology drugs or psychotropic medications, substantial validation activities are necessary. The potential impact of system failure on patient safety demands rigorous validation regardless of the software’s simplicity. Conversely, even for Category 5 custom software, if you’re producing lower-risk products such as vitamin supplements or nutritional products, the validation effort can be appropriately scaled down while still ensuring system reliability.

The risk-based approach considers multiple factors including:

Patient safety impact: What happens if the system fails or produces incorrect results? Could it lead to administration of incorrect doses, wrong medications, or compromised product quality?

Data integrity criticality: Does the system handle data that affects regulatory submissions, batch release decisions, or product quality determinations? The ALCOA+ principles (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available) should guide your assessment.

Regulatory compliance requirements: Which regulations apply to your specific products and operations? Requirements differ for different product types, markets, and manufacturing operations.

Business continuity impact: How critical is the system to ongoing operations? Could system failure halt production or create significant business disruption?

System complexity: More complex systems with multiple integrations, custom code, and numerous configurations generally require more extensive validation than simple, standalone applications.

Current Regulatory Landscape

The pharmaceutical industry operates under an evolving regulatory framework that increasingly emphasizes outcomes over rigid processes. FDA’s guidance on Computer Software Assurance (CSA) for Production and Quality Systems (draft 2022) encourages a more flexible, risk-based approach focused on critical thinking rather than documentation for its own sake. The European Medicines Agency’s Annex 11 (Computerised Systems) continues to provide foundational requirements for GMP computerized systems across the EU. PIC/S PI 011-3 (Good Practices for Computerised Systems in Regulated “GXP” Environments) offers internationally harmonized expectations. Japan’s regulations, while maintaining the category framework, increasingly align with international risk-based approaches.

These regulatory developments support the view that while understanding system characteristics (which GAMP categories help describe) remains valuable, the focus should be on ensuring systems are fit for their intended use through appropriate, risk-proportionate validation efforts.

Conclusion: Breaking Free from Category Classification Obsession

I sincerely hope that readers will liberate themselves from an obsessive focus on category classification. Categories are useful descriptors that can help guide validation planning, but they should never become the primary focus or goal. Instead, concentrate on thoroughly understanding user requirements, carefully assessing risks, and implementing validation activities that are appropriate, sufficient, and proportionate to those risks.

The pharmaceutical industry’s goal is to ensure that computerized systems reliably support the production of safe, effective, high-quality medicines. This goal is achieved through thoughtful application of risk-based validation principles, not through mechanical adherence to category labels.

(To be continued)