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
  • One-Size-Fits-All Paperless Validation – Is It Really Fit for Use?

    One-Size-Fits-All Paperless Validation – Is It Really Fit for Use?

    Synopsis:

    Popular  validation tools have a basic flaw – these applications were designed to only carry out qualification activities.  This article emphasises the differences between qualification and validation, and why for process and cleaning validation/monitoring, such “paperless validation” applications offer little more value than a document management system. An efficient digital validation platform has to be a suite of applications each performing what it has to be designed for, qualification, manufacturing process management, cleaning process management separately,  but still integrated so as to provide a smooth flow of data. 

    Introduction

    No manufacturing sector can survive without a relentless focus on quality—because the very essence of manufacturing is to produce consistent and standardized product.  Any lapse in quality in pharmaceutical industry leads to regulatory scrutiny, fines, damaged reputations, and ultimately business failure. 

    In pharmaceutical manufacturing, the regulatory expectation is that the process be in “a state of control”.  And historically we “validate” processes, e.g., manufacturing, packaging, cleaning or QC method.  The core objective of validation is to demonstrate document consistent, controlled performance over time.  Validation is more than a regulatory requirement—it is the foundation of operational consistency, product quality and most importantly.

    As digital “validation” solutions flood the market, the expectation is that these digital tools do more than merely replicating paper processes in electronic form – that they will enable smarter, more integrated validation approaches that align with regulatory requirements and operational needs. But do they deliver on this promise?

    This article explores the differences between validation and qualification, and why the “one-size-fits-all” approach towards  “validation” is an idea that falls well short of customer expectations. 

    Let’s Clarify the Basics

    Before delving deeper, it is crucial to differentiate between the two terms that are often confused: qualification and validation.

    • The expectation from Qualification is that the equipment, utilities, instruments, software used in a GMP environment have been installed correctly and function as intended.
    • Expectation from Validation is to show that the processes are “in a state of control”. 

    In simple terms, Qualification answers, “Does that entity work as per our requirement?” while Validation dives deeper to explore, “Can we get a reliable and consistent product?”

    Understanding Qualification

    The User Requirements Specification (URS) is usually the first document created when a new entity/asset is being planned, detailing the requirements, including business, compliance, and operational requirements.  This activity is done by stakeholders who are either responsible or accountable for that asset/entity.

    The selected vendor(s), or the internal resource where applicable, respond with a Functional Specification (FS) detailing how the requirements in the User requirement will be met.

    The specific test script document requirements vary depending on what is being qualified. However, the intent remains the same: to demonstrate, through test scripts, that the User Requirement Specification (URS) requirements have been met. These test scripts may be documented in Factory Acceptance Tests (FAT), Installation Qualification (IQ), Operational Qualification (OQ), Site Acceptance Tests (SAT), or Performance Qualification (PQ). The selection of which of these to include depends on the particular asset or system being qualified.

    A Traceability Matrix document is then put together mapping each requirement to the corresponding tests, detailing the user requirement ID and the test script ID. This matrix provides clear visibility of how every user requirement specified in the URS is verified through specific test cases. 

    In this sense, qualification is more likely to be a documentation-driven, structured and checklist-based approach, focusing on verifying that vendor-supplied asset/entity meet predefined specifications. 

    Understanding Validation

    Validation, by contrast, focuses on ensuring that processes consistently produce outcomes that meet predetermined specifications.

    According to the FDA, validation is: “Establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes.”

    Where qualification proves that an asset/entity is installed and functions correctly, validation demonstrates that the processes using that asset/entity are robust, repeatable, and compliant.  Furthermore, it is even more critical that “effective monitoring and control systems” are put in place for “process performance and product quality, thereby providing assurance of continued suitability and capability of processes”. This is a requirement as per ICHQ10 and continues to be for the last decade one of the most cited observations. The goal in validation and monitoring is not just compliance but smarter, data-driven decisions, continuous improvement being an important pillar. 

    Validation, therefore, is data-driven  and is focussed on data analysis providing the assurance that the process will consistently produce product whose quality meets predetermined specifications.

    Given that qualification and validation have very different approaches and end goals, is it possible to use one software tool to manage both requirements?

    Many software vendors market “all-in-one” applications as a one-stop solution. These apps promise to provide a unified platform for validation.  At first glance, the appeal of a unified system is undeniable. After all, a single tool that manages documentation, qualification, and validation activities across an entire organization sounds like a great solution.

    However, when the design requirement for a qualification activity has absolutely no relationship with what is to be done in validation and ongoing monitoring, how is it possible to combine the use cases?  

    The data type that a qualification management system main data type is textual information. User requirements are primarily captured as detailed text entries within structured tables, and supporting test scripts are also documented largely in text form. While most data centers around descriptive narratives—such as specifications, acceptance criteria, and rationales—numeric data appears mainly when recording process parameters during process qualification (PQ) for equipment. This emphasis on text ensures that every requirement and its verification are clearly documented for traceability, auditability, and regulatory compliance.

    Validation and ongoing monitoring activities are fundamentally centered around the defined product specifications, attribute specifications, equipment process parameter ranges and how these are met. The primary data type handled in this context is numeric, as these processes often involve the collection and analysis of quantifiable results—such as, equipment process parameter range for a noted batch, attribute measured results—to demonstrate compliance with set limits or acceptance criteria. This numerical data provides objective evidence to verify that equipment operate within their approved specifications, and enables continuous, data-driven monitoring to promptly detect deviations or trends. While supporting documentation like SOP may include textual explanations or rationales, it is the structured numeric data that forms the backbone of validation and monitoring efficacy.

    Pharmaceutical regulators expect manufacturers to proactively show processes are in control, detect deviations, implement timely corrections, and continually improve processes to guarantee product safety and efficacy.  While qualification is an integral part of the process validation program and expects all entities/assets used in the product manufacture to be shown to be “fit for use”, the expectation is also timely access to real-time or trending data, making it easy to promptly identify deviations, detect process drifts, or generate automated alerts.

    So an  “all-in-one” application designed to aid in qualification and CSV, can only act as storage repository for files associated with process validation.  Such applications consider validation or ongoing process verification runs as static activities with no ability to let the data speak for itself.   These teams rely on time-consuming, error-prone manual reviews to collate and interpret data, increasing the risk of missed trends and delayed responses to quality issues. Furthermore, static documentation impedes data integration, reduces the potential for cross-functional collaboration, and hinders the effectiveness of continuous improvement initiatives—ultimately compromising regulatory compliance and the robust oversight expected in modern pharmaceutical manufacturing.

    Conclusions

    Ultimately, companies must weigh the true cost of investment, both in terms of efficiency and compliance risk, when selecting validation tools. It may be time for the industry to reconsider whether costly all-in-one solutions are necessary, or if more focused, built for purpose software solutions targeted toward manufacturing process would better serve their needs.

    ravi

    July 27, 2025
    paperless validation
    digital transformation, digitilization, paperless validation, pharmaceutical
  • Digitalization in Pharma: How to make the switch

    Digitalization in Pharma: How to make the switch

    Synopsis

    A robust digital ecosystem streamlines processes and improves data management in the pharmaceutical industry, but conflicting priorities can create disconnected software silos. Because digitization needs continuous investment, steady incremental progress is better than sporadic efforts. Success depends on strong leadership, a committed and skilled implementation team, and solid management and stakeholder support.

    Introduction

    The COVID-19 pandemic signalled a shift in mindset for the pharmaceutical industry. Almost overnight, many companies were forced to move from traditional paper documents and desktop-based applications to a digital, remote-working ecosystem. 

    Yet, when the SARS-CoV-2 virus went into an endemic state and employees returned to work, many of the processes that had been converted to the digital domain remained that way.  They were more efficient, drove better compliance and saved the company resources and money, it transpired. And so, willingly or not, pharmaceutical companies started embracing digitalization.

    The industry had, of course, been using software applications before the pandemic, such as Enterprise Resource Planning (ERP), Quality Management Systems (QMS), and Laboratory Information Management Systems (LIMS). But the pandemic instigated a drive to move all processes to digital platforms. Now, as companies increasingly invest in software applications and gravitate toward connected factories and sites, it has become clear that there are significant challenges involved in integrating both hardware and software systems.

    Challenges

    One of the challenges pharmaceutical companies have faced relates to the migration away from paper-based records. A batch manufacturing record (BMR), for example, must be maintained for every product batch, and is typically recorded on paper. The same is true of the logs that track everything from daily equipment use to weighing balance verifications. The shift to digital during the pandemic, however, meant that these records had to be captured on tablet devices instead. For staff to move freely around a facility, from equipment to equipment, these tablets require wireless connectivity to a central server or the cloud. And therein lies the problem – existing cleanroom infrastructures were not designed for wireless connectivity.  Cleanrooms need to be retrofitted with wireless routers.  And this also brings up a whole host of cybersecurity concerns, such as setting up an effective ransomware mitigation plan.

    Another challenge is choosing the right software. No application can manage an entire site, so companies must select and integrate a series of software tools for certain tasks, activities, and processes without duplicating them, which is where things can get confusing. Process parameter data, for example, is captured in both a BMR and a Process Performance Qualification (PPQ) run record or report, while the data in an Annual Quality Review (AQR) Report comes from disparate sources, with some requiring analyses by statistical tools.

    Defining digital requirements

    The first step to a successful digital transformation program is identifying  the activities being carried out at a manufacturing site.  A plan must then be put together to discern which of them can and should be digitized.

    Not every activity needs to be digitized immediately, however. Just like a solo house buyer might consider a multi-bedroom property, leaving space for future expansion when it comes to digital applications is a sensible move.

    Who decides which activities should go digital? Many companies have created a new team or point person, responsible for getting departments to share their digitization requirements. Approving the overall requirement, meanwhile, is a job for the site head. It’s a critical activity, one that’s similar to putting up a pharmaceutical facility.

    The site head has the power to allocate money across multiple budgets, even when the purse strings are tight, and he is the right person to form a team that that has collective knowledge of the activities taking place at the site.

    Setting goals

    Once the activities being moved to the digital domain have been identified, specific goals need to be decided on. Many companies prioritize the ability to see and analyze data on demand while others want to streamline their practices before the workflow is digitized, doing away with non-value-adding activities. The latter is a critical issue, one that can lead to heated discussions. In company meetings, it’s common to hear the expression: “If it ain’t broke, don’t fix it”. This is where the site head can offer a (gentle) guiding hand to make sure that digitalization and all the efficiency it brings isn’t sacrificed through fear of disrupting the status quo.

    A connected digital platform will generate a large amount of data. That’s why it’s important to decide which part of the collected data is to be analyzed and how.  Companies may also find that some of the data has no purpose.  In which case, they need to decide whether it’s worth storing.  In the same vein, it’s important to examine the relevant procedures and forms to identify those that will become obsolete once transferred to the digital domain. For example, equipment usage log data can be obtained from the Manufacturing Execution System (MES), so why capture it in a logbook?It’s critical to ‘spring clean’ what data is to be collected and from where before moving it to the digital realm. 

    Another question to ask is whether the technology currently available can be leveraged to improve efficiency. For instance, digitalization has already impacted training with classroom training being replaced in some cases by virtual reality training, while videos have replaced many stepwise procedures.

    Creating a requirements document

    Once the workflows and associated activities have been sanitized and streamlined, a site requirement document needs to be created. The priority should be on marking mandatory requirements – all others can  be thought of as ‘nice-to-haves’.

    A company with multiple manufacturing sites might even consider a global document covering all locations.

    Ultimately,  the goal is to define a system with seamless data flows. This is where an (internal or external) IT source with software architecture knowledge can be included in the team. This resource can assist the team with developing the digital platform’s architecture.

    Revising the requirements document

    Next, the team needs to start looking for applications that are available on the market. The goal at this stage is to find applications that meet all the mandatory requirements. Some of these requirements may already be covered by existing company applications such as ERP, LIMS, and QMS, and it’s possible that new requirements arise when reviewing applications. On the other hand, there may be requirements – specially mandatory – that aren’t met by existing applications (more on how to handle these later in the article).

    Once the team has defined its requirements and compared them with what’s available on the market, it may need to then include new requirements or redefine existing ones in its documentation. Applications of interest should be categorized into groups covering the same activities. If some  overlap, the application  can  be incorporated into multiple groups. Then, the documentation should  be restructured to define the requirements for each application group. With the help of the IT resource, details about how these application groups will ‘talk to’ each other should also be noted in the document.

    One way forward involves identifying applications that can form the nucleus of the digital platform, with other applications interfacing through the nucleus via an Application Programming Interface (API).  An API allows two software applications to ‘speak’ to each other. This streamlines data flows between applications.

    Data could be transferred from one application to the other but that would be inefficient.  For example, if all the receiving application wants to know is  when production on a piece of equipment started and ended, why provide extraneous information? The right design then is to identify the fields of interest and only query them when needed. 

    The other option is to consider a data hub. Here, data from disparate sources is assimilated and stored in a database that can be used by any application. The advantage of this kind of architecture is that it moves away from data duplication, avoiding  data inconsistencies and enhancing data integrity. Care should be taken though to ensure that a clear audit trail identifies the changes any application makes to the data and that data changes are broadcast to all applications. This immediately reveals the impact of any changes made.

    It’s also important to specify the location where an application will be hosted and who it will be hosted by. This is where the team’s input becomes crucial.

    Storage

    Something else to consider is where the applications and the data will reside. The software industry is increasingly moving to the cloud. The main driver behind this is the ability to provide instant support, and, more importantly, to put all infrastructure under the software vendor’s control.

    A problem with site-based servers is that they require localized on-site support, and this has become very expensive. It’s also well documented that multi-tenant Software as a Subscription (SaaS) applications can be rolled out faster than site-based installations. This is due to the time saved in avoiding application installations and leveraging vendor-executed qualification documentation. The reason why the vendor executed documents can be leveraged is because the application has already been installed and qualified.  Repeating the same test for each site does not add any value, except when executing performance qualification. 

    Some vendors only provide applications on a multi-tenant SaaS basis. If some of the applications are running on a local server or on the company’s cloud account, the type of data architecture to use when integrating these applications is the next thing to address. 

    Once the requirement document has been revised, the team may prefer splitting the document for vendor evaluation. Care should, however, be taken to ensure that the relevant interface requirements are properly spelled out in the “child requirement documents”.

    Finding a vendor

    Selecting a vendor is critical to successfully setting up a complete digital platform. Some make the mistake of sharing the requirement document with the vendor and then asking it to self-certify whether all requirements are being met. This can lead to either:

    (a) the company only discovering missing features after the software has been purchased, or

    (b) the vendor hastily developing the missing features and then releasing them without proper testing.

    Neither of these options leads to productive outcomes. They usually result in delays caused by incomplete platform setups and sometimes even the selection of a new vendor. The digitalization team must, therefore, verify whether the requirements are being met and make notes on those that aren’t, along with a reason why. This can still lead to the vendor being asked to develop missing features, but it will, at least, be an informed decision.

    Another common pitfall is making decisions based on presentations that rely on scripted videos. In the era of Theranos-type scams, it’s not always clear if a product  demo represents a prototype or a working application.  This is why it’s important for the team to verify the product’s minimal functionalities. Company data might need to be anonymized when checking requirements against the features being presented.  This anonymized data can then be fed into the application and the process verified. This should be a mandatory requirement.

    Some applications require specialist knowledge (e.g., process validation and cleaning validation). So naturally, an application designed by a subject matter expert will be of a higher quality and better suit users’ needs. This becomes very apparent during the demo as the workflow tends to be much smoother. 

    It may also be a good idea to consider a vendor who can provide software for multiple applications, thereby ensuring interconnectivity between them all. But care should be taken to ensure that the vendor has expertise in the other applications of interest. For example, it could be that the vendor is known for their Manufacturing Execution System (MES) application but not for their process validation application.  In this case, it’s better to consider applications from separate vendors. 

    Once a vendor has been decided on, the team then faces the challenging task of matching their requirements to the application. Only once these applications are identified can they begin to appraise vendors, discuss goals, and share requirements. Vendors should also be encouraged to look out for and highlight any potential implementation roadblocks so that they can clear them early on.

    What should the digitalization team do when requirements are not supported by any existing applications? Should it develop solutions on its own? In this case, reflection is key. As a company in the drug manufacturing business – not software development – it’s best to stay in the right lane. There are very few pharmaceutical manufacturers that have successfully developed and managed applications by themselves.

    The problem does not lie in the software’s development phase but rather in its maintenance, where both the underlying framework and the application itself need to be kept up-to-date. It’s at this point, especially in the manufacturing sector, that a third party vendor is usually called in to update the code. But what happens when the technology stock used to build these applications becomes obsolete – will another application be developed? Who will test the application? The self-development of applications often leads down a rabbit hole of issues such as these. In some companies, there’s something of a ‘software graveyard’ where many tombstones point to abandoned in-house software developments. The best strategy is, then, to identify a suitable vendor who knows what they’re doing.

    Qualifying and rolling out applications

    Many applications fail early on because some members of the team tasked with implementing the roll-out, i.e., qualification of the system followed by training all the associated users and implementing changes to affected procedures, do not believe that the application they’ve purchased will meet the relevant requirements.

    Procedural delays and red tape caused by objections can stretch out application implementation times. It’s therefore important that the team leader lay out a clear timeline. Site management should also provide support for addressing delays (be it actual or based on perceptions).

    Sometimes it’s just not possible to roll out all the features of an application at once. This might be due to network or extra hardware requirements. In such cases, the application roll-out can be divided into phases that each have a clearly defined execution timeline. Site management should ensure that an adequate budget is available for rolling out the later phases.

    Qualifying the application can also drain a significant amount of time. The team must, therefore, draw up a clear map of what needs to be qualified. If dealing with a SaaS application, then it will need to discern whether the vendor qualification document can be leveraged rather than repeating the qualification process.

    A clear demarcation must also be made when it comes to establishing what the requirements will be if the application is hosted on a local server instead of a SaaS application. If this is not done, then the computer systems validation team will often create its own installation qualification document in an ad hoc fashion. This can result in an auditor questioning how the team performed an installation on a server that was not its own. 

    A long-term commitment

    Unlocking the full potential of a digital ecosystem demands ongoing evolution and adaptation. Regular assessments and strategic adjustments are essential for its continued success. Changes in technology, regulations, vendor status, and the like can dictate various requirement changes, while activities that could not previously be brought onto the digital platform can be successfully integrated. It’s therefore crucial that pharmaceutical companies look to maintain ongoing digital transformations into the future.

    From defining digital requirements and documenting them, to finding the right vendor and finally rolling out applications, leadership is key on the journey to digitalization. It plays a central role in both budgeting to keep the platform fully functional and ensuring that the right team members are retained.  This team will be responsible for carrying out an annual review of the digital platform and recommending course corrections as required. In all this, there must be active and constructive leadership support.

    In today’s interconnected world, we can harness and leverage data to our advantage. It’s crucial that we understand how to effectively use data and then translate that understanding into action that enhances existing processes. The members of an agile and efficient digital transformation team serve as skilled navigators capable of interpreting ever-changing circumstances and adapting to a shifting landscape.

    Quascenta Team

    April 28, 2025
    Uncategorized
    digital transformation, digitilization, pharmaceutical

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