Skip to content
PQMS
  • Homepage
  • Products
  • About Us
  • Blog
  • Contact us
Login
Book demo
  • From Qualification to PPQ: The Bigger Picture of Paperless Validation

    From Qualification to PPQ: The Bigger Picture of Paperless Validation

    When organisations discuss paperless validation, Computer System Validation (CSV) is almost always the first topic on the table. This comes as no surprise — electronic hardware and software have become deeply embedded in every facet of modern manufacturing. Yet, while digital systems serve an important supporting function, they are not what ultimately produces a product. The most critical component in any manufacturing operation is the equipment itself. Without equipment, nothing gets made. That is why paperless validation should focus strongly on the equipment level.

    Whether introducing new equipment or modifying an existing asset, the end goal seems to be always the same: to qualify the equipment or update its qualification records. In the case of an existing piece of equipment, this might involve changes to the PLC logic or the replacement and upgrade of key components.  But is that enough?

    What matters most when teams make these changes is not simply whether they have updated the qualification records correctly. Far more important is the effect these changes have had on process parameters. Regulators and auditors are primarily concerned with whether manufacturing and cleaning processes continue to perform consistently — whether there is variation within a batch and from one batch to the next.  That is the question of interest.

    This article addresses an often-missed link in this chain: the data that the process validation team needs after the equipment qualification team completes its work. This handover of critical information is, in reality, the most important activity in the entire process.  Because it determines whether the process remains compliant. One cannot operate equipment in a range that was not qualified. 

    Process Paramters

    Process parameters are not merely operational settings — they are the critical link between equipment performance and product quality. They have a direct and measurable effect on the Critical Quality Attributes (CQAs) that define whether a drug product meets its specification. A shift in even 1 process parameter, however small, can alter the quality profile of the final product. This is precisely why teams must carefully assess every equipment modification and consider its downstream impact on process parameters and, ultimately, patient safety.

    The same principle applies when purchasing new equipment. Does the new equipment truly match the existing one? Teams must analyse and document this comparison before moving forward with procurement.

    Consider a real example. A site plans to replace an old granulation mixer with a new model featuring an updated, more efficient bowl design and a PLC-controlled mixing cycle.

    The new mixer requires equipment qualification before the site can put it into production. But qualification should not be the starting point. Before defining the additional equipment and software qualification steps, the team should ask at least two questions to determine what it needs to demonstrate through PPQ and CV runs to ensure the product meets its specifications, both in-process and in the finished product.

    1. Is the new equipment identical to the equipment it will replace? If differences exist, what are they? How could those differences affect product quality? For example, has the bowl geometry changed in a way that alters the product-contact surface area or mixing dynamics?
    2. Will the site purchase the equipment “off the shelf,” or will the supplier customise it?

    The new bowl design may alter the fundamental fluid dynamics and mass movement within the mixer. As a result, the existing ranges for critical process parameters such as mixing speed, shear profile, mixing time to endpoint, and torque curves may no longer remain valid. The team would therefore need to repeat PPQ runs on the new equipment to demonstrate that the process still meets the required product specifications.

    A change in PLC logic could also fundamentally alter how the equipment controls and sequences the process. The original PPQ runs used a specific set of automated controls, including defined ramp rates, hold times, interlocks, alarm thresholds, and parameter sequencing. These controls consistently delivered product that met its CQAs.

    If the new PLC logic manages these same parameters differently — perhaps through different control algorithms, tighter or wider deadbands, altered timing sequences, or different response characteristics to process deviations — the previously validated process no longer represents the new operating conditions. The team must therefore conduct new PPQ runs to demonstrate that the new control logic, while governing the same critical process parameters, still produces a product that consistently meets its drug product specifications, batch after batch. Parameters, still produces a product that consistently meets its drug product specifications, batch after batch.

    3 Runs Completed Successfully – Tell us more about the process

    Three successful PPQ runs may satisfy the immediate qualification requirement, but they do not provide the full picture. They represent a limited snapshot — a demonstration that the process can produce compliant product under controlled conditions on three occasions. What they cannot tell us is how tightly the product specification remains within tolerance over time. This is precisely why Continued Process Verification (CPV) exists — to confirm that the results demonstrated during the three PPQ runs remain consistent at batch fifty, batch one hundred, and beyond. Without sustained monitoring during the CPV stage, those three successful runs can create false assurance while leaving the risk of slow, undetected drift from the drug product specification unaddressed.

    The team must not only monitor the process after PPQ runs; it must also monitor the equipment and the PLC logic that controls it. PLC logic does not remain static. Software updates, firmware patches, sensor recalibration, and even subtle electrical degradation can change how the control system behaves over time. A timing sequence can drift by milliseconds, maintenance can inadvertently overwrite an alarm threshold, or a control loop can respond differently to input signals — and any of these changes can shift process parameters without triggering a single deviation.

    Equally, the physical equipment is subject to wear and tear that no PLC can detect — bowl surfaces that degrade over time, impeller blades that erode and alter shear profiles, seals that harden and introduce dead spots, or contact surfaces that pit and roughen, changing both product interaction and cleanability. If the organisation monitors only the product and the process but neglects the equipment’s control logic and its physical condition, it creates a blind spot where the root cause of a future quality failure — whether digital or mechanical — will remain invisible until it manifests as out-of-specification product in the hands of the patient.

    Paperless Validation Must Evolve Too

    If validation is a lifecycle, then paperless validation must evolve with it. The objective is not simply to replace paper with electronic records. It is to make validation easier to manage throughout its entire lifecycle — from initial qualification through process validation, change control, monitoring and ongoing verification.

    This means paperless validation must look beyond electronic components, software, and PLC logic alone. The equipment in its entirety must be qualified — its mechanical systems, its control logic, its physical condition and its interaction with other equipment. This is not a novel concept. ISPE Baseline Guide Volume 5 on Commissioning and Qualification makes this point clearly: qualification should encompass the complete equipment system, not just its individual automated elements. A paperless approach that captures only the digital layer while ignoring the physical asset beneath it is not simplifying the lifecycle — it is leaving critical gaps in it.

    Positioning PQMS Suite

    This is where an integrated platform such as Quascenta’s PQMS Suite can support the broader validation lifecycle.

    ValDoc Pro supports all qualification & computer system validation activities; eProcess Pro manages PPQ runs and CPV runs; eResidue Pro supports cleaning process management; eLog Pro enables electronic logging and recording of routine operational activities to support ongoing monitoring and control; and QMS Pro manages the change control, CAPAs, and non-conformances that changes like this can trigger.

    Together, these capabilities allow organisations to move beyond simply converting paper-based validation tasks into electronic format. Instead, they create a connected digital environment that brings qualification, process validation, cleaning validation, change control, and ongoing monitoring together within one coherent, living system.

    ravi

    September 1, 2026
    Uncategorized
    csv, digital transformation, digitilization, Equipment Qualification, paperless validation, Pharmaceutical Validation, Quality Assurance
  • GAMP 5 Software Categories

    GAMP 5 Software Categories

    GAMP 5 is one of the most effective frameworks that help validation teams ask the right questions first.

    Modern pharmaceutical validation is no longer built around documenting everything equally. Whether following traditional Computer System Validation (CSV) or the more recent Computer Software Assurance (CSA) approach, the focus has shifted toward applying validation effort based on system impact, function, and complexity.

    That principle sits at the heart of GAMP 5 software classification. The framework helps teams determine whether software is being used as delivered, configured to fit a process, or custom-built, because each scenario carries a different level of validation expectation.

    Why is classification important?

    Picture this: Two pharmaceutical companies both use Microsoft Excel. One runs it straight off the shelf—using pivot tables and basic formulas with nothing fancy. The other uses a sprawling, macros-powered workbook that calculates batch yields and auto-generates reports. While they have the same software name on the label, they exist in completely different validation worlds.

    This is exactly why GAMP 5 classification matters. It aligns validation activities, documentation depth, testing expectations, and risk controls with the way the software is used.

    First Things First: What is GAMP 5?

    GAMP 5 stands for Good Automated Manufacturing Practice. A globally trusted guideline published by ISPE that tells pharma and biotech companies how to validate the computerised systems they use in their work. While GAMP 5 is not a law, it shows companies exactly how to comply with the laws.

    Every validation starts the same way.

    Before any category conversation begins, three documents are non-negotiable regardless of the software.

    • User Requirement Specification (URS): Defines what you need.
    • Functional Specification (FS): Confirms that the software can deliver it.
    • Traceability Matrix (TM): Connects every requirement to a tested result—the paperwork equivalent of connecting all the dots.

    Think of URS + FS + TM as the backbone of every validation package. Everything else? That depends on which category your software falls into.

    Breaking it down

    GAMP 5 sorts software into categories based on one thing: how much your team modified it.

    GAMP 5 software is broadly divided into three categories: Category 3, Category 4, and Category 5. Each category represents a different level of customisation, complexity, and validation requirements.

     Now, let us understand the GAMP 5 software categories with a simple example

    Category 3: (Non-Configured Products)

    Software You Use Exactly as It Came

    Category 3 is like buying a car straight from the showroom. You drive it exactly as the manufacturer designed it—no modifications, no tuning, no custom parts.

    This category includes software your team installs and uses as-is. Since nothing inside the system has changed, validation mainly focuses on confirming that the software installs correctly, works properly, and performs reliably in your environment through: User Requirements Specification (URS), Functional Specification (FS), Traceability Matrix (TM), Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ).

    You didn’t rebuild the car. You simply made sure it runs

    Category 4: (Configured Products)

    Software Customized Without Coding

    Category 4 is like customizing a car after purchase. The engine stays the same, but you adjust the seats, dashboard, lighting, or navigation to suit your needs.

    Similarly, Category 4 software is configured—not coded. But tailored through workflows, forms, permissions, and settings without changing the source code, because those configurations affect how the system behaves.

    The validation requires Category 3 documents plus a Configuration Specification (CS) for configured workflows and settings.

    You didn’t change the engine — but you tuned the ride.

    Category 5: (Bespoke)

    Software That Was Built, Scripted, or Coded

    Category 5 is like building your own car from the ground up. You design the engine, wiring, controls, and performance yourself — which means every detail must be tested carefully.

    This includes internally developed tools. Since your team created the logic, validation is much deeper, including unit, integration, and system testing.

    Category 5 also requires Category 4 documents plus Design Specifications (DS) and detailed testing records for custom-coded logic.

    When you build the engine yourself, you also own the responsibility of proving it works.

    Every category is additive. Category 4 does not replace Category 3 requirements—it builds on them. Category 5 does not start from scratch—it adds one more document on top of Category 4. You climb the staircase; you never restart it.

    The bottom line:

    GAMP 5 categorization is not about placing software into boxes. It is about understanding risk well enough to apply the right level of validation effort, control, and assurance throughout the system life cycle.

    When used properly, categorization becomes a practical decision-making tool—guiding everything from testing strategy and documentation depth to supplier involvement and project planning. Under both CSV and CSA practices, the focus is shifting away from excessive documentation and toward critical thinking, because strong validation is not measured by the amount of paperwork produced. It is measured by how intelligently risk is understood and controlled.

    And that’s the kind of clarity that makes a Monday morning validation meeting feel a lot more manageable.

    Reference :

    ISPE. GAMP® 5: A Risk-Based Approach to Compliant GxP Computerised Systems. International Society for Pharmaceutical Engineering (ISPE), 2008.

    ravi

    August 14, 2026
    Uncategorized
    CATEGORY 3, CATEGORY 4, CATEGORY 5, digital transformation, GAMP 5, pharmaceutical, Pharmaceutical Validation, Quality Assurance, User Requirement Specification
  • Instrument Classification: Why One Qualification Strategy Doesn’t Fit Every Instrument

    Instrument Classification: Why One Qualification Strategy Doesn’t Fit Every Instrument

    Every pharmaceutical QC lab relies on a diverse range of analytical instruments, from simple glassware to sophisticated analytical systems that incorporate sophisticated electronics and even a configurable software. As new instruments are procured, a fundamental question arises: Does this instrument require qualification? And if qualification is needed, what level of rigour is appropriate? Clearly, a pipette and an HPLC system demand very different approaches. Making this determination consistently each time an instrument is acquired requires a structured framework.  USP General Chapter <1058> “Analytical Instrument and System Qualification” addresses this need through a risk-based framework for Analytical Instrument Qualification (AIQ), ensuring qualification effort is proportionate to the instrument’s intended use, functionality, and analytical system complexity.

    From Function to Classification

    A typical laboratory contains a diverse mix of equipment: simple apparatus without measurement capability, instruments incorporating firmware and sophisticated electronics, and computerised systems connected to software or wider software platforms. This diversity leads naturally to the next question: How should they be classified?

    USP <1058> groups analytical instruments into three broad categories based on measurement capability and how complex the instrument is.  This tiered structure forms the foundation of a risk-based approach that avoids both over-qualifying simple equipment and under-qualifying complex systems — a balance that has become increasingly important as regulatory scrutiny around data integrity and analytical lifecycle management intensifies.

    A Closer Look at the Categories

    Each of the three groups, listed below, reflect a different level of effort required to demonstrate that an instrument is fit for its intended purpose.

    • Group A — standard laboratory apparatus without measurement capability and therefore the need to calibrate them. Basic functionality can be verified through visual inspection.

    Examples:  Glass beakers, volumetric flasks, magnetic stirrers, and vortex mixers.

    • Group B — Instruments that generate measurements or equipment that control experimental conditions thereby having an influence on analytical results.

    Examples:  Analytical balance, pH meter, laboratory oven, and thermometer.

    • Group C — computerised analytical systems where hardware and software together generate, process, calculate, store, or report analytical data. These systems require the highest level of qualification due to their functionality and complexity.

    Examples:  HPLC system with chromatography data system (CDS),

    The three groups represent the top level of the USP <1058> classification framework. USP <1058> further subdivides them into eight subcategories, enabling qualification activities to be matched more precisely to an instrument’s functionality and intended use. 

    The verification workload does not scale in a single leap from Group A to Group B to Group C – it escalates gradually across the subcategories.   Recognising these nuances allows laboratories to right-size their approach: minimal for A1/A2, structured and calibration-driven for B1, enhanced with calculation checks for B2, and further reinforced with method and configuration controls for B3.  For Group C, qualification effort expands further because these systems incorporate software, and their qualification fundamentals should align with GAMP 5 principles for computerised system validation — applying full 4Qs qualification for C1 with fixed vendor software, extending to configuration management for C2, and expanding again for C3 to include full software lifecycle documentation, custom code assessment, and interface testing. This graded approach ensures that verification effort remains proportionate to the risk each instrument poses to data quality.  The sections below explain the verification workload for each subcategory in turn.

      Sub-category Keyword Example Activity List
    A1No Metrological functionMagnetic stirrer (without temperature control) and vortex mixerVerification only.  Verification activity is limited to: A short, risk-based justification stating why no qualification is required.Confirming the equipment is present, correctly installed, and identified (asset tag, location).Visual observation that it operates as intended (e.g., the stirrer spins, the vortex mixes).Retaining the supplier documentation or operating manual.   No calibration, no performance testing, and no periodic requalification typically required.
    A2No user calibrationSieves and volumetric glasswareVerification only.  These items may have defined specifications (e.g., certified mesh size, Class A tolerance) but they are not calibrated by the user. Verification typically includes: A short, risk-based justification stating why no qualification is required.Installation/receipt check and asset identification.Visual confirmation of fitness for use and absence of damage.Retention of manufacturer certificates confirming compliance with compendial specifications.   Differs from A1 in that the specification is verified against supplier provided conformance document(s).
    B1Firmware-controlledAnalytical balance and pH meterVendor-supplied qualification package, typically covering FS,  IQ and OQ.Verification of the User Requirement Specification (URS) through executed IQ, OQ, and PQ.Routine calibration against traceable standards, with documented procedures and records.Periodic performance verification (e.g., daily balance checks, buffer verification for pH meters).Change control and requalification for firmware updates.
    B2In-built calculationsTOC Analyser and density meterAll B1 activities plus: Verification of built-in calculations against known reference materials or manually calculated values. OQ to challenge computational logic. Documented evidence that calculation algorithms are appropriate for intended use.
    B3User-defined routinesFTIR with custom methods and Gas Chromatography All B1 and B2 activities plus: Verification of user-defined methods through method-specific challenge testing. Documented control of method creation, review, approval, and version management.
    C1Non configurable  softwareStand-alone chromatography data system (CDS) with standard templatesVendor-supplied qualification package, typically covering IQ and OQ, aligned with GAMP 5 Category 3.Routine calibration and maintenance of hardware components against traceable standards, with documented procedures and records.Verification of the URS through executed IQ, OQ, and PQChange control and requalification for software patches and version upgrades.
    C2Configurable softwareELN with configurable templatesVendor-supplied qualification package, typically covering IQ and OQ, aligned with GAMP 5 Category 4.  Activities apart from that noted for C1 include:Documented Configuration Specification (CS) covering all user-configured elements (templates, workflows, user roles, calculations).  
    C3Custom softwareLIMS integrated with SAP and custom calculationsVendor-supplied qualification package, typically covering IQ and OQ, aligned with GAMP 5 Category 5.  Activities include:Software development lifecycle definition Documented Design Qualification (DQ)Source code review, structural testing, or thorough supplier assessment for custom-developed code.Comprehensive testing of custom calculations, workflows, and interfaces (e.g., SAP, LIMS, ERP integrations).

    As instrument functionality and analytical system complexity increase, so does the level of  documented activities needed to demonstrate fitness for intended use.

    Conclusion

    Instrument classification is the starting point for determining qualification effort. Rather than applying a uniform qualification strategy across all laboratory instruments, USP <1058> encourages a proportionate approach based on instrument characteristics, intended use, and system complexity. By matching the qualification package to the instrument’s role, laboratories can focus effort where it adds value while maintaining confidence that analytical systems are fit for their intended use.

    Reference:

    1. USP–NF General Chapter <1058> Analytical Instrument and System Qualification. USP–NF, official 1 June 2026.

    ravi

    August 1, 2026
    Uncategorized
    digital transformation, GAMP 5, group a, group b, group c, GxP Compliance, instrument classification, instrumnet qualification, pharmaceutical, Pharmaceutical Validation, User Requirement Specification
  • Equipment Classification: The Decision That Drives Qualification

    Equipment Classification: The Decision That Drives Qualification

    Before an equipment qualification protocol is drafted, here’s a question worth asking: Does every piece of equipment have to go through a qualification lifecycle requiring the same resources, time, and effort, or would commissioning suffice for some?

    Some never pause to question whether full commissioning and qualification are truly necessary. Instead, the default option of qualifying every asset is exercised because it appears comprehensive on paper. But is this approach the most efficient use of time and resources, or could a more targeted strategy deliver faster, equally reliable outcomes?

    Equipment classification provides a structured way to answer that question. As outlined in the ISPE Baseline Guide Volume 5, the System Classification framework classifies equipment as Direct Impact or Not Direct Impact, providing the basis for determining the qualification strategy.

    System Classification According to ISPE

    Classification comes down to answering eight questions — a YES to any one of them makes the equipment Direct Impact. All eight have to come back NO before it can be Not Direct Impact. (ISPE Baseline® Guide Volume 5, Section 3.3)

    1. Does it control a CPP, or otherwise serve a defined CQA?
    2. Does it have direct contact with the product or process stream?
    3. Does it produce an excipient, ingredient, or solvent—Water for Injection being the obvious one?
    4. Is it used for cleaning, sanitising, or sterilising?
    5. Does it maintain an environment—temperature, humidity, an aseptic zone — that’s a CPP for the process?
    6. Does it generate or hold data used to accept or reject the batch, or fall under 21 CFR Part 11 or EU GMP Annex 11?
    7. Does it provide the container closure or product protection?
    8. Does it apply or check product identification with no independent verification elsewhere?

    Classification Outcomes

    Every piece of equipment gets sorted into one of two categories based on how it answers those eight questions — Direct Impact or Not Direct Impact.

    Direct Impact (DI)Not Direct Impact (NDI)
    Qualified and commissioned Commissioned only
    Scope set by CQA/CPP risk to the productScope set by SME judgment and HSE criticality
    System Risk Assessment identifies the CDEsSME review sets the commissioning scope
    Full C&Q documentation packageCommissioning documentation only

    Consider the following examples:

    • A vial filling machine answers YES at Q2 alone—it’s in direct contact with the product during filling, and a failure there is a direct line to product quality. One YES is enough. It’s Direct Impact and goes through the commissioning and qualification workflow.
    • A shrink-wrapping machine sits downstream; it bundles product that’s already capped, stoppered, or sealed. It doesn’t touch product, so Q2 is a clean NO. The question worth pausing on is Q7—product protection. Shrink film does protect the product in transit, so a quick read might call this a YES. But Q7 asks whether this equipment provides the seal on which product quality depends, and the upstream capping or stoppering step already provides that seal. The shrink wrap is a secondary bundle, not the barrier the product relies on. Q7 comes back NO, and so does the rest. The shrink-wrapper is Not Direct Impact. It still goes through commissioning—it just doesn’t go through qualification.

    Where classification gets genuinely tricky

    Most equipment can be classified with relative ease. Utilities, however, often require a closer evaluation because their classification depends on how they support the process.

    1. Utilities controlling critical process parameters: Product contact alone does not determine classification. Utilities that control Critical Process Parameters (CPPs) may still be classified as Direct Impact.

    Example: A chilled water system cooling a jacketed reactor may never contact the product, but if it controls the reaction temperature (a CPP), it is classified as Direct Impact.

    • Utilities with multiple points of use: The same utility can serve both Direct Impact and Not Direct Impact applications. Classification should be based on the specific point of use rather than the utility itself.

    Example: Compressed air used to dry product-contact equipment after cleaning may be classified as Direct Impact. The same compressed air used only to operate non-product-contact equipment is Not Direct Impact.

    • Function over equipment type: Classify systems such as nitrogen, vacuum, or compressed air according to their function in the process, not their names.

    Example: Nitrogen used for product blanketing is Direct Impact, whereas nitrogen used only for line pressurisation may not be.

    The Bottom Line

    The most effective qualification programmes do not qualify every equipment. They are selective. Equipment classification provides the framework for making that decision consistently, ensuring that the qualification effort, project resources, and regulatory focus remain aligned with actual product and process risk.

    Reference

    1. ISPE Baseline® Guide: Commissioning and Qualification, Volume 5, Second Edition. International Society for Pharmaceutical Engineering (ISPE), 2019. ISBN 978-1-946964-23-6.

    ravi

    July 27, 2026
    Uncategorized
    digital transformation, direct impact, Equipment Qualification, GxP Compliance, ispe, not direct impact, pharmaceutical, Pharmaceutical Validation, Quality Assurance
  • FMEA Beyond the Form: Are You There Yet?

    FMEA Beyond the Form: Are You There Yet?

    “What if one could travel briefly into the future, identify a forthcoming error, return to the present before it occurs, and intervene to prevent it?”

    That idea sits at the heart of risk analysis. To identify risks at the start and build on them as new ones emerge.  In any manufacturing setup, small, unnoticed issues can quietly grow into serious consequences.  In an industry like pharmaceutical manufacturing, that would mean patient safety. Risk analysis is therefore a fundamental part of every exercise in pharma, be it buying equipment, developing a new product or setting up its manufacturing process. 

    ICH Q9 lists many risk management tools.  FMEA is one of them.  Yet teams prefer it over others like HAZOP or HACCP, to name some. Its value lies in its simplicity and adaptability across design, manufacturing, maintenance, software, and quality systems, like a Swiss army knife. 

    What is FMEA?

    Failure Mode and Effects Analysis (FMEA) is a systematic method for identifying potential failure modes, their causes, and their effects on a system, product, or process. It focuses on “what could go wrong” at the level of assets/components, process steps, or activities and evaluates how those failures impact safety, quality, and reliability. 

    Regulatory and standards frameworks (for example, ISO 14971 for medical devices or ICH Q9 principles in pharma) expect a structured, documented approach to risk management, and FMEA is a commonly accepted method to support these expectations.

    Core Elements of FMEA

    A typical FMEA analysis involves using a template, typically made using a spreadsheet.  Key column headings in the spreadsheet are:

    1. Component/Step: Break the item you’re analysing into components, process steps, or functions
    2. Potential Failure mode: Define the risk and how the failure will happen.
    3. Effect of failure: The consequence of that failure on the next step, the system, the product, or the patient/user.
    4. Severity (S): How serious the effect of the failure is on the patient, product, process, or business (e.g., from minor inconvenience to critical safety impact)? Teams set up a scale in the spreadsheet, for example, 1–5, with each level defined to avoid confusion.
    5. Cause of failure: Underlying reasons, such as human error, equipment malfunction, design weakness, or inadequate procedure.
    6. Occurrence (O): The estimated frequency or likelihood that a particular cause will lead to the failure mode.  Like the severity scale, teams set up a separate scale in the spreadsheet for occurrence
    7. Current controls: Preventive or detective measures already in place (alarms, SOPs, in‑process tests, automation, training, etc.).
    8. Detection (D): The likelihood that existing controls will detect the failure mode before it causes the effect.  As with the severity and occurrence scales, teams set up one for detection, too.
    9. RPN Score: Teams either multiply the severity, occurrence, and detectability scores to give a single composite score (RPN=S×O×D), or use a traffic light matrix to identify the final risk score.

    a. The first method involves setting up 3-level bands and converting the RPN composite score to a risk level,

    RPN Score RangeRisk levelWhat the team should do
    1-15LowNo immediate action needed
    16-60MediumPlan corrective action
    60-125HighRisk is unacceptable.  Assign owner.  Escalate to design controls.

    b. The second method is where, for a certain severity score and occurrence score, you find the risk class (Low being green, yellow being medium and red being High). You then determine the risk level by comparing the detectability score against the risk class. Various versions of this method exist. 

    Teams can also carry out the same analysis qualitatively, as shown in the figure below.

    Best Practices for Effective FMEA Usage

    FMEA is not without flaws, but knowing its limitations and compensating for them is vital.  In addition, the same simplicity that makes FMEA popular also creates weaknesses when organisations apply it mechanically, score it inconsistently, or treat it as a documentation exercise rather than a decision-making tool. 

    • Risk Template Setup

    It is better to avoid the consolidated RPN Score approach as it masks fundamentally different risk profiles. For example, a failure mode with Severity 5, Occurrence 1, Detectability 5 has the same RPN as one with Severity 5, Occurrence 5, Detectability 1.  Yet the first clearly represents a much higher potential impact.

    In a traffic‑light matrix, the same issue may also happen.  A Severity of 5 with Occurrence 1 can have the same risk class as Severity 1 and Occurrence 5.  Knowing this piece of information allows the user to change the colour of the former to red and the latter to green. 

    • Subjective Scoring

    A quantitative approach is difficult to work with.  Different team members often interpret the same failure differently, leading to scores driven more by opinion than by harmonised criteria or historical evidence. As a result, the same process can receive very different risk ratings across departments, sites, or even separate meetings.  A qualitative scale is easier to work with. 

    • Static Vs Live

    People perform FMEA analysis, and people are fallible; the team will inevitably miss some risks. Teams must therefore link the FMEA to the QMS, feed every newly identified root cause back, and continuously update the analysis.

    In addition, processes change, equipment ages, and new knowledge emerges over time. An outdated FMEA gives the appearance of control without reflecting the current reality. 

    • Scope of Analysis

    Any risk analysis works best when the team defines its scope clearly. Carrying out, for example, risk analysis for an entire facility or a project does not provide focus on each component of the systems/functions that the project covers.

    • Poor linkage to Actions

    Risk analysis loses its purpose if teams don’t link it to design controls or procedural controls when the risk score is high. ISPE C&Q and PDA TR54 provide great examples of risk analysis. 

    conclusion

    Ultimately, FMEA only adds value when it moves beyond numbers and colour codes to actual action taken due to high-risk scores. When teams use FMEA the right way—tightly linked to the QMS, kept current, and revisited as knowledge grows—it becomes far more than a form to complete; it becomes a practical way to ‘visit the future’ long enough to prevent today’s risks from becoming tomorrow’s deviations, recalls, or patient harm.

    ravi

    July 1, 2026
    Uncategorized
    FMEA, GMP, ICH Q9, Pharma Manufacturing, Quality Risk Management, RPN score
  • User Requirements Specification — Getting the Sequence Right.

    User Requirements Specification — Getting the Sequence Right.

    Most of us have written a URS with a system already in mind. The vendor had been shortlisted, sometimes already selected, and the document was drafted to formalise what had already been decided. The result is a URS that describes a product rather than defines a need. It cannot be used to challenge whether the selected system is fit for purpose, because that question was never genuinely open.

    This is the most common URS failure in the industry. Not vague language. Not missing signatures. The sequence. A URS written after vendor selection is not a requirements document. It is a justification; those of us who have reviewed enough of them know the difference.

    What the Regulators and ISPE Expect

    The ISPE definition is precise: the URS states what the system must do, not how it should do it. Every major GxP framework shares one expectation underneath the differing language: document what you need before you build it, and prove you did.

    The Annex 11 makes this more explicit than before. URS traceability to testing is no longer implied — it is mandatory. Risk management must be embedded from URS through to system retirement. The one-time IQ/OQ/PQ followed by silence is no longer a defensible position.

    What the URS Must Cover

    Every requirement in it must be verifiable — specific enough that someone can design a test, run it, and return a clear pass or fail. If it cannot be tested, it does not belong.

    The URS must cover, at a minimum:

    • Functional capabilities — calculations, safety functions, access controls, audit trails, and output formats
    • Data handling — data definitions, valid ranges, integrity controls, backup, and archiving
    • Technical performance — capacity, failover behaviour, and disaster recovery
    • Interfaces — with users, other systems, and equipment
    • Environmental and power conditions — the physical operating environment in which the system must function
    • Alarm requirements — including explicit identification of critical alarms
    • System automation — with clearly defined boundaries between systems
    • Data integrity requires its own attention. The URS must define what the system needs to do to satisfy ALCOA+ principles — data that is Attributable, Legible, Contemporaneous, Original, and Accurate, and beyond that, Complete, Consistent, Enduring, and Available. These are not abstract ideals. Each one translates directly into a testable requirement — audit trails, user access controls, timestamps, backup provisions, and data storage conditions.
    • Every requirement should state its category — Quality, Business, or HSE — and its source, whether a CQA, a CPP, a regulatory requirement, a risk assessment output, or an engineering standard. We must explicitly identify quality-critical requirements and write them with precision.

    Finally, not every requirement carries the same weight. Separating mandatory from beneficial and nice-to-haves keeps the qualification effort focused where it actually matters.

    What a GMP-Grade Requirement Looks Like

    The gap between a weak requirement and a defensible one is not technical knowledge. It is discipline, specificity, and process ownership.

    Weak Requirement GMP-Grade Requirement
    The system shall monitor temperature.The system shall continuously monitor storage temperature within 2°C–8°C(CPP), trigger a GMP-critical alarm within 60 seconds of exceedance, and maintain a tamper-proof audit trail per 21 CFR Part 11.
    The system should print labels correctly.The system shall restrict label reprints to QA-authorised personnel with an electronic signature, reason code, and a full audit trail of all print events and template changes.

    A requirement that cannot be tested has no place in a qualification programme.

    Five Failure Modes That Destroy URS Credibility

    These are not theoretical. They are the patterns behind real audit observations, 483s, and warning letters.

    1. Vague, untestable language. Robust, appropriate, user-friendly — these are not requirements. If a test cannot be written for it, it does not belong in the document.
    2. Vendor Brochure Transcription. A URS sourced from supplier documentation belongs to their sales cycle, not your process. Auditors notice immediately.
    3. No CQAs or CPPs identification. You cannot build a credible risk assessment on a document that fails to identify what is critical.
    4. URS Written Post-Selection. A URS written after vendor selection is not a requirements document. It is a justification.
    5. Never Updated After Go-Live. If your team has not updated the document to reflect the current validated state, it is a liability.

    Each of these patterns is recoverable before qualification begins. After a deviation occurs, they become the gap that an investigation cannot close.

    Conclusion

    A URS is only as useful as the process understanding behind it. Written early, classified correctly, and maintained through every system change — it is the document that gives every qualification activity its purpose. Written late, vaguely, or not at all — it is the gap an investigation will eventually fall into.

    ravi

    June 15, 2026
    Uncategorized
    ALCOA+, GMP validation, GxP Compliance, Pharmaceutical Validation, QMS, Quality Assurance, Regulatory compliance, User Requirement Specification
  • The Illusion of Root Cause:  5 Whys in QMS

    The Illusion of Root Cause:  5 Whys in QMS

    Most of us have used the 5 Whys during deviation investigations, but have we been using it correctly? It appears on every deviation investigation form, every deviation report, every post-incident review. Five questions. Five answers. Signed and filed as a CAPA starting point. But is this the right approach? 

    The Linear Trap

    Consider the example shown below with a problem statement and associated 5Why analysis :

    Problem Statement: An older version of an SOP was found on the shopfloor that triggered a deviation. 

    LevelQuestionAnswer
    Why 1Why was the older version of SOP-xxxx found on the shopfloor?Operator used a printed copy not updated after the revision.
     Why 2Why was the printed copy not replaced after the new version was approved?No one informed the shopfloor supervisor that SOP-XXXX had been revised.
     Why 3Why was the shopfloor supervisor not notified of the revision?System notifies only the document owner, not active-use areas.
     Why 4Why does the notification process exclude active-use areas?The distribution matrix was not updated when the shopfloor was added as a user area.
     Why 5Why was the distribution matrix not updated?No requirement in change control to review the distribution matrix when adding a user area.

    The above 5 Whys analysis runs as a single straight line — one problem, one Why, one answer, repeated five times. That works when a failure has a single, clear cause.  But real deviations rarely behave in this manner. 

    When you look at the problem statement — older version of SOP-XXXX found on the shopfloor — can we attribute it to just one reason? There may be three distinct causes, each having its own branches. Not all will reach Why 5, and that is fine. The goal is to find the branches that lead to a true systemic cause.

    The Branching Model

    The same analysis done differently reveals three independent causal branches:

    Problem Statement: An older version of an SOP was found on the shopfloor that triggered a deviation. 

    Branch B is important for a different reason: it closes early and clears Document Control of a failure. This is equally valuable — the 5 Whys is not only a tool to find blame, but to eliminate false leads and confirm where controls did hold

    Why This Matters in Pharma QMS

    When the 5 Whys analysis is forced into a single linear chain, investigations routinely stop at the first plausible answer rather than the true systemic cause.  This leads to CAPAs that address symptoms rather than eliminating the underlying system gaps. Examples include retraining the operator, reminding Document Control, etc. The branching model exposes multiple independent failure pathways. In this example, even if Branch A’s CAPA (an HR–Document Control notification procedure) is fully implemented, the deviation could recur via Branch C if the configuration baseline register gap remains unaddressed.

    The branching model depends heavily on the knowledge of the team conducting the analysis.  A fishbone (Ishikawa) diagram can help identify potential causes before drilling down. For high-risk deviations with patient safety implications, FMEA or fault tree analysis provides a more defensible, data-driven structure.

    5Why – The Right Way – Step by Step

    Using 5 Whys correctly in a pharmaceutical QMS context means:

    • Start with a well-defined problem statement — observable, specific, and bounded. Vague statements generate vague chains.
    • Identify all Why 1 possibilities before drilling — brainstorm independently, then build separate branches for each distinct causal pathway.
    • Allow branches to close early when appropriate — a branch that leads to “this control worked correctly” is a valid and useful finding.
    • Do not force five levels — the goal is the systemic root cause, not a count of five. Three Whys that reach a procedural gap are better than five Whys that circle back to a symptom.
    • Validate each root cause with the reverse test — ask: “If this root cause were eliminated, would the deviation have been prevented?” If the answer is no, keep drilling.
    • Link each confirmed root cause to a discrete CAPA action — one root cause, one CAPA. Multiple root causes from multiple branches each require their own corrective action plan.

    The Real Goal

    The 5 Whys was never intended to be a form-filler. Sakichi Toyoda introduced it into Toyota’s production system as a discipline of genuine inquiry, not documentation compliance. In a QMS environment where the pressure is to close deviations quickly and move on, it is easy to treat it as a checkbox. The result is a CAPA system full of retraining records and SOP updates that address the same recurring deviations, investigation after investigation.

    The branching 5 Whys is time-consuming, there is no doubt about that, but it is the version that actually protects product quality and patient safety. The illusion of root cause is easy to create. The root cause itself takes work to find.

    ravi

    June 5, 2026
    Uncategorized
    pharmaceutical, quality management system, root cause analysis
  • Factory Acceptance and Site Acceptance Testing: Accelerating Equipment Qualification with ValDoc Pro

    Factory Acceptance and Site Acceptance Testing: Accelerating Equipment Qualification with ValDoc Pro

    https://www.pqms.com/wp-content/uploads/2025/12/FAT-SAT-Article-1.mp4

    Synopsis:

    “Suitable for the intended purpose/activities” is a core regulatory expectation for all pharmaceutical manufacturing equipment, and qualification is the documented proof that this is achieved. The qualification lifecycle starts with a User Requirement Specification (URS) document followed by a Functional Specification (FS).  Test Scripts are executed in IQ, OQ and PQ documents to demonstrate that the requirements noted in the URS are met. Because running IQ/OQ/PQ scripts at the manufacturing site is time-consuming and the responsibility falls only on the drug manufacturer, some of the effort can be shared with the vendor via Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT).  ValDoc Pro can streamline this process and build better compliance.  

    Regulatory Guidelines:

    121 CFR 211.63 states that “Equipment must be of appropriate design, adequate size, and suitably located to facilitate operations for its intended use”[2].  While the FDA recognises the advantages of FAT and SAT (mentioned in presentations by the FDA), there is no guideline that discusses this.   EU GMP Annex 15 & PIC/S explicitly state, in sections 3.4-3.7, that:

    • Equipment, especially if incorporating novel or complex technology, may be evaluated, if applicable, at the vendor prior to delivery.
    • Prior to installation, equipment should be confirmed to comply with the URS/ functional specification at the vendor site, if applicable.
    • Where appropriate and justified, documentation review and some tests could be performed at the FAT or other stages without the need to repeat on-site at IQ/OQ if it can be shown that the functionality is not affected by the transport and installation.
    • FAT may be supplemented by the execution of a SAT following the receipt of equipment at the manufacturing site.

    Leveraging Vendor Testing:

    The Factory Acceptance Test (FAT) is carried out at the vendor’s site and provides documented evidence that the equipment meets the user requirements and the vendor has fulfilled contractual responsibilities. A well‑planned FAT helps save time during qualification by identifying design issues, functional gaps, and integration problems before the equipment leaves the factory.   Sending the equipment back to the vendor to fix issues, especially when they are located across continents, is avoided through FAT.  Fat also provides the ability to check internal components of the equipment that one would not be able to reach at the site unless it is disassembled. 

    It is not necessary that a FAT test be performed for all equipment/systems.  That decision is left to the manufacturing site and its policy.  For a greenfield facility, a commissioning and qualification (C&Q) plan will direct this strategy.  A survey by ECA Academy in 2018 found that FAT is used by 37% of the companies surveyed, while 55% stated “it depends on the complexity of the project”. SAT was found to be used by 49% of those surveyed [5]. 

    Planning and preparation for the Factory Acceptance Test (FAT) are critical because the activity is conducted at the vendor’s site and involves budgeting for extra expenses on both sides. The decision to perform FAT is typically taken very early in the procurement lifecycle, during the development of the User Requirement Specification (URS) for the equipment.  The contract signed between the drug manufacturer and the vendor for an equipment includes scope of the FAT, responsibilities and the commercials.  The details of what is to be covered in FAT are put down in a protocol and frozen before approval of the design stage.  The site and the vendor have to agree on the features/functions to be demonstrated, parameter specification to be met, tests to be carried out, and identify the URS points covered by FAT.  The FAT protocol is sent to the drug manufacturer for review.  Once approved, then only the protocol can be executed.  During execution, the drug manufacturer representative(s) ideally should be present to at least to verify the minimum test requirements and resolve any deviations.  During and after the pandemic, many FATs have been conducted remotely, reducing travel and related expenses and making this an attractive option, particularly when organisations can leverage a wide range of digital tools and platforms to their advantage.

    The FAT protocol, once executed, is compiled along with attachments and sent to the site by the vendor for review.  In most cases, the equipment would have to be disassembled before shipping.  The documentation put together details equipment component labels and the process to follow to reassemble these components. 

    Similar to the FAT, the Site Acceptance Test (SAT) is not a mandatory test to perform.  The advantage of SAT is time savings.   A successful execution of the SAT protocol provides assurance that the equipment works as per specification post-transportation to the site.  While infrastructure, utilities, interfaces, etc, are defined in advance and agreed upon, surprises may crop up.  The SAT protocol also rechecks issues found during FAT.  These should be addressed before IQ begins.  In addition, the presence of the vendor’s team at the site speeds up testing, as that machine is very well known to them. 

    The SAT process follows the same overall approach as the FAT, but is performed at the manufacturing site rather than at the vendor’s facility. Whether a SAT will be performed should be defined in the C&Q plan and, preferably, specified in the URS and subsequently reflected in the contract.  SAT is led by the site, along with the vendor’s project/commissioning/service staff.  The SAT protocol is normally drafted by the vendor or the project engineering/validation team. 

    A decision that the site needs to take is whether they would like to leverage what was tested in FAT and SAT.  Most sites leverage the data from these tests.  The SAT protocol has many tests that overlap with what one would carry out under IQ and OQ protocols. 

    Accelerating FAT and SAT Efficiency with ValDoc Pro:

    ValDoc Pro is an easy to use Qualification management application that assists companies in digitizing their qualification workflow, from URS onwards through the entire lifecycle.  Its role-based access and real-time collaboration features enable vendors and manufacturers to coordinate FAT and SAT seamlessly.  Following are some of the advantages:

    • Vendor Access: Vendor can create, obtain site approval and execute FAT protocols within ValDoc Pro, with controlled access to designated folders/files. 
    • Site Review and Approval: The FAT protocol and FAT report can be submitted for review and approval online.
    • Seamless Flow: Generating the protocol by the vendor, review, execution and compilation all can be carried out seamlessly in ValDoc Pro. 
    • Sequential: ValDoc Pro ensures that the SAT protocol cannot be executed until the executed FAT report has been approved.  This ensures that the SAT protocol captures all relevant tests. 
    • Traceability Matrix: ValDoc Pro maintains a continuous link from URS through FAT/SAT to IQ/OQ/PQ, demonstrating to regulators that all user requirements were tested and all deviations addressed.

    Conclusion:

    Compared with relying solely on traditional IQ, OQ, and PQ, integrating FAT and SAT into the equipment qualification strategy allows issues to be identified earlier at the vendor and manufacturing site, limits risk, and reduces the amount of testing and troubleshooting that must be compressed into already busy commissioning windows. This upstream focus not only improves the quality of delivered assets but also frees site resources to concentrate on value-added verification and routine operation rather than firefighting late-stage gaps. ValDoc Pro-enabled FAT and SAT give pharmaceutical manufacturers a more efficient and compliant path to equipment qualification by moving protocols into a digitized, collaborative environment and enabling options such as Remote FAT, so teams can shorten timelines, reduce on-site disruption, and strengthen data integrity while maintaining full traceability from URS through lifecycle maintenance. In a landscape where each site-based role carries a greater workload, embedding FAT and SAT within a robust application like ValDoc Pro is not just an efficiency gain, but a strategic necessity for sustaining reliable, inspection-ready manufacturing.

    [1] FDA. Process Validation: General Principles and Practices. U.S. Food and Drug Administration.

    [2] “U.S. Food and Drug Administration. 21 CFR Part 211 – Current Good Manufacturing Practice for Finished Pharmaceuticals, §211.63 Equipment design, size, and location.”

    [3] European Commission. EU Guidelines for Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use, EudraLex, Volume 4, Annex 15: Qualification and Validation. In operation since 1 October 2015

    [4] PIC/S. Guide to Good Manufacturing Practice for Medicinal Products, PE 009 (current version), Annex 15: Qualification and Validation

    [5] ECA Academy. FAT & SAT not frequently used as Part of Qualification – ECA Modern Qualification Survey Results. GMP News, gmp-compliance.org (2018)

    ravi

    December 12, 2025
    Uncategorized
    Equipment Qualification, Equipment Testing, GMP Compliance, Pharmaceutical Validation, Process Validation, Quality Assurance
  • Who is actually Responsible for the URS?

    Who is actually Responsible for the URS?

    Synopsis:

    Before purchasing an equipment, software or instrument, regulatory requirement mandates that one documents what is expected of the proposed acquisition. While it may be tempting to rely on vendors for this, as they understand their product, they do not understand the business requirements. That is why the User Requirement Specification (URS) must be authored by the team responsible for this new acquisition. This article explains why a user-driven URS ensures the acquired entity genuinely matches user needs, moving it from basic functionality to real-world fit

    It All Starts with a Need

    Picture this. You have been asked to put together a URS for a new equipment/software/instrument.  If this requirement was identical or similar to one that you have purchased in the past, that makes your task easier.  But what if this is a brand-new requirement.  Where do you start? 

    Appendix D5 from the ISPE GAMP 5 guidance document says it the best when it states that each user requirement should be specific, measurable, achievable, realistic, and testable.   It is also a good practice to prioritize the requirements, typically in two or three levels: (mandatory (high), beneficial (medium), and nice-to-have (low)) Or (mandatory (high) and nice-to-have (low)).

    The Easy Way

    As a vendor, we very often get asked to provide a draft URS that the regulated company then uses as a basis to draft the requirement.  Is this the right approach?  It sounds logical, right? After all, vendors are experts in the products they sell. But here’s the catch — they are experts in their product, not your business process.

    Sometimes we receive a URS that lists a specific brand or model, even including specifications unique to that brand. This is not the intended purpose of a user requirement, which should describe what is the needed functionally, not prescribe a particular vendor or solution.  When this happens, it limits the scope of solutions, undermines competitive assessment, and can introduce bias or compliance risks. Such requirements do not reflect true user needs but rather pre-select a solution, making it harder to compare alternatives and potentially exclude options that better meet functional requirements. GAMP 5 guidelines recommend describing functional needs in clear, objective terms, avoiding references to specific suppliers unless it is absolutely necessary to do so for business reasons

      Understanding the Roles the RACI way

      How do we decide the roles of various stakeholders.  A RACI Matrix, a simple chart that outlines who does what, breaks down the roles:

      Responsible:  Team/end users responsible for the business process.  The end users or process owners are usually responsible for drafting the URS since they know the operational needs best.

      Accountable: Manager(s) responsible for the business process.  Oversees URS creation and ensures it meets desired goals

      Consulted:

      • Other departments to provide their input/expertise as the acquired product may influence their workflows
      • IT team for software/IT hardware requirements to provide input on technical feasibility and rollout implications
      • CSV team for software to include regulatory requirements
      • Vendor – provide input and give technical advice. 
      • Informed-Vendors so as to put together a function requirement specification. 

      What do the Regulators Say?

      The FDA, the EMA and others, have made their stance clear: every system must be “fit for its intended use.”  That phrase — fit for intended use — is powerful. It means the system should perform exactly as needed for your specific products and processes.

      And who defines that intended use? Not the vendor — you do.

      According to the FDA’s General Principles of Software Validation and EMA’s Annex 11 on Computerised Systems, the responsibility for defining and confirming suitability lies with the regulated user organisation for computerised systems.  But that principle doesn’t stop there. Under broader GMP guidance, such as Annex 15 on Qualification and Validation, the manufacturers are responsible for ensuring equipment is suitable for its intended purpose and for defining its requirements in a User Requirements Specification (URS) or functional specification.

      In short, the user determines what’s needed; the vendor shows how their product meets those needs.

      Why Ownership Matters?

      When the customer owns the URS, everything aligns. The equipment fits its real operational needs, and the system passes regulatory scrutiny because it was built for its true purpose. And most importantly, it saves time, money, and frustration down the road.

      When vendors take over the URS, it might seem faster, but it’s like letting someone else write your recipe — you’ll never get the exact flavour you wanted.

      ravi

      November 9, 2025
      Uncategorized
      Equipment Qualification, GMP Compliance, Pharmaceutical Validation, Quality Assurance, URS, User Requirement Specification
    • Demystifying GAMP 5 Software Classification: Understanding Categories 3, 4 and 5

      Demystifying GAMP 5 Software Classification: Understanding Categories 3, 4 and 5
      Demystifying GAMP 5 Software Classifications

      Summary:

      In a GxP environment, the software to be acquired should be fit for use. In order to meet the user requirements, one buys software that can be used as-is, with configuration, or custom-developed. To ensure the appropriate documents are included in the qualification package, it is essential to identify the relevant qualification documents for each scenario. This article explores how the software classifications, defined in GAMP 5, aid in determining the necessary qualification documentation for software in Categories 3, 4, and 5.

      Defining Software Qualification Requirements:

      When a pharmaceutical company, be it a manufacturer or a CRO, purchases software for use in a GxP environment, they must create a clear and detailed User Requirement Specification (URS) that outlines their needs. In response to the URS, the software vendor(s) submit a Functional Specification (FS) that describes how their software will address the user requirements. All URS requirements must be tested and proven through qualification. A Traceability Matrix (TM) is a document that maps each specific requirement within the URS to corresponding testing scripts.

      Every software qualification workflow requires a URS, FS, and TM to ensure that each requirement is properly addressed, tested, and fulfilled. The other documents in the qualification package depend on the category the software falls under per GAMP 5.   

      Category 3 consists of Commercial Off-the-Shelf Software (COTS) that is used as-is; for instance, Microsoft Excel (without macros), or statistical tools like JMP and Minitab. The qualification objective for such software is to ensure proper installation and expected performance. For software installed on a computer or server, Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) must be completed. For Software as a Solution (SaaS) applications, since the software is pre-installed on the cloud, a simplified IQ may be conducted together with a full OQ to comprise an IOQ, and a PQ test is performed.

      Category 4 encompasses software that is configured without changing the code. Examples include Laboratory Information Management Systems (LIMS) or Manufacturing Execution Systems (MES), where modifications can be made to templates, forms, or workflows without changing the main software. Another example is an Excel sheet that has been configured for a specific use without macros or Visual Basic code. In addition to the qualification documents specified for Category 3 software, configured systems require a Configuration Specification (CS) to document the changes or settings that have been made.

      Category 5 includes software developed from scratch or that has undergone code modifications. One example is an Excel sheet that has macros, scripts, or Visual Basic code added. These systems are unique to a company and may be developed in-house or by an external vendor. Testing for Category 5 is more detailed, involving unit, integration, and full system testing to ensure that all components function as intended. This is critical, as even minor code changes can impact performance. The same documents that are required for Category 4 are also required for Category 5. Additionally, a Design Specification (DS) is needed to explain the software construction, since the logic has been modified or custom-developed.

      Conclusion:

      Identifying a software’s category under GAMP 5 is not always clear.  One does not decide on the basis of the software name; rather, it depends on its usage. The same software can potentially belong to any of the three categories—category 3 if used as-is, category 4 if configuration is required, or category 5 if custom coding is required. Higher the category classification, more extensive is the documentation and testing requirements.

      ravi

      November 5, 2025
      Uncategorized
      Computer System Validation, GAMP 5, GxP Compliance, Pharmaceutical Validation, Software Categories, Software Classification
    1 2
    Next Page

    Powering Quality from Lab to Label © 2025, Quascenta Pte. Ltd.