Skip to content
PQMS
  • Homepage
  • Products
  • About Us
  • Blog
  • Contact us
Login
Book demo

  • 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.

    Sindu K

    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.

    Sindu K

    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.

    Sindu K

    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

    • Can AI help in Validation? Cutting Through the Hype

      Can AI help in Validation? Cutting Through the Hype

      As interest in AI continues to grow, some vendors are promoting AI as tools capable of generating qualification deliverables such as User Requirement Specifications (URS), Functional Specifications (FS), and traceability matrices, with minimal human input. This article provides a grounded, practical look at what AI can and cannot do in the context of URS and FS creation and automating traceability matrix. It explains how LLM models work; what URS and FS documents are, and how they fit in the qualification process; it also looks at tests we ran with custom LLMs to automate reconciliation as in automating generation of a traceability matrix, and the results obtained; and suggests where AI may offer limited support – while highlighting why human ownership and input is still required for critical tasks like URS and FS development.

      Introduction: Opportunity vs. Overpromise

      The rise of AI tools like ChatGPT has sparked broad interest across regulated industries. In pharmaceutical, biotech, medical device, and cosmetics sectors, companies are exploring how these tools might reduce documentation workload, increase consistency, and support compliance efforts.

      However, alongside this enthusiasm, some vendors have begun promoting the idea that large language models (LLMs) can generate qualification documents – such as User Requirements Specifications (URS), Functional Specifications (FS), or even test scripts – with a simple prompt.

      While these claims are designed to attract attention, they risk oversimplifying what these qualification documents really are, how they are developed – and where, if at all, AI actually fits into the process.

      This article explains the role and requirements of key qualification documents, explores how LLMs like ChatGPT work, and examines where AI tools can – and cannot – be appropriately applied to support the qualification process.

      What a URS Actually Does – and Why It Matters

      A URS (User Requirements Specification) is a critical foundation for any qualified entity. It defines what the user needs the system, equipment, utility, or software to do – in terms that are clear, measurable, and auditable.

      A robust URS is not a generic checklist. It must be developed by knowledgeable stakeholders who understand:

      • The intended use of the system,
      • Key process and operational parameters (e.g., throughput, control logic, data handling),
      • The regulatory framework and internal quality expectations,
      • Integration points with other systems (e.g., MES, SCADA, LIMS),
      • Environmental, safety, and compliance constraints.

      A well-defined URS supports:

      • Effective vendor selection and procurement,
      • A clear basis for design and testing,
      • Alignment with qualification protocols and traceability,
      • Compliance with GxP expectations for “fitness for intended use.”

      When a URS is vague or incomplete, the consequences can be significant: unsuitable equipment, misaligned vendor deliverables, inefficient qualification efforts, or gaps that lead to inspection findings and remediation. Poor input at the URS stage can therefore compromise the entire lifecycle of the system – including its qualification.

      How LLMs Like ChatGPT Actually Work

      How LLMs function is often misunderstood. Tools like ChatGPT do not think, reason, or understand. In fact, they generate text by predicting the most statistically likely next word in a sentence, based on patterns learned from massive volumes of publicly available internet text.

      In practice, this means:

      • They do not understand context in the way a human expert does,
      • They do not verify accuracy,
      • And they do not apply regulatory logic or domain-specific judgment.

      Critically, high-quality URSs, FSs, and qualification scripts are typically internal and proprietary – not available in the public domain. As a result, these documents are not well represented in the training data used to build general-purpose language models.

      This creates a risk of ‘hallucination’: that is, AI can sometimes confidently generate text that sounds correct but is factually inaccurate or entirely fabricated. In regulated environments, this presents an obvious risk – especially when such content is used to support compliance activities.

      Can LLMs Write a URS? What’s the Real Limitation?

      When asked to generate a URS, an LLM can produce something that looks well-formatted – but that document is likely to be too generic or vague to be useful in practice.

      For example, asking ChatGPT to generate a URS for a “sifter” will not trigger the LLM to ask clarifying questions on aspects such as:

      • Process requirements: What is the role of the sifter in the process? For example, it could be particle size separation, de-lumping, or scalping. Or which screening motion – centrifugal, vibratory, or gyratory – is best suited for your materials? What are the in-process material characteristics (e.g., moisture content, particle size distribution)? How will the sifter integrate with upstream or downstream equipment, like granulators or during presses – by using gravity-fed or vacuum transfer systems? Is the sifter intended for batch processing or continuous operation?
      • Performance requirements: What throughput is needed? Are there maximum allowable noise or vibration levels to comply with workplace safety standards? What is the acceptable level of material loss or retention during the process?
      • Design and construction requirements: What are the material of construction (MOC) requirements? What specific surface finish (e.g., Ra < 0.8 µm), required? What are the requirements for welding and polish?  What utilities are available, like compressed air pressure, electrical supply, or vacuum systems, to support its operation? Does it need tool-less disassembly for cleaning? What are the cleaning needs (e.g., CIP, SIP, manual)?
      • Controls and automation: Will the sifter be integrated with a Supervisory Control and Data Acquisition (SCADA) system or Programmable Logic Controller (PLC)? Are alarms, interlocks, or data logging required? Should it support electronic batch records or interface with Manufacturing Execution System (MES)? Is Process Analytical Technology (PAT)-driven monitoring required?
      • Environmental or containment needs: Is operator protection (e.g., for potent APIs) required? What classification zone applies?  For example, if OEB 5 containment is required, pneumatic clamping mechanisms have to be put in place.

      These are essential details – and they define far more than the basic equipment type. They shape how the system will be designed, selected, installed, qualified, and operated. Without them, the URS cannot serve its purpose as a regulatory and procurement document.

      Even if LLMs are fine-tuned on customer data, key questions remain:

      • Who validates the quality and compliance of the source material?
      • Is the model version-controlled?
      • Is the data private – or potentially exposed across users or systems?
      • Will the AI output reflect your company’s unique process – or generalize from unrelated inputs?

      And if subject matter experts must still correct or rebuild the draft, it’s worth asking: is the AI truly reducing effort, or simply introducing another layer of review?

      Functional Specifications: A Vendor’s Responsibility

      Once the URS is approved, the FS (Functional Specification) is typically authored by the vendor, service provider, or internal engineering team. The FS outlines how the solution will meet the defined user requirements – through system design, control logic, automation behavior, configuration, and integration.

      Authoring an FS requires:

      • Proprietary system knowledge,
      • Awareness of design constraints,
      • Understanding of operational and regulatory requirements,
      • Collaboration across quality, engineering, IT, and qualification functions.

      The FS is the vendor’s responsibility – it represents their response to the URS. And this raises an important point: why would a vendor delegate that responsibility to an AI tool that doesn’t understand their product? Even with access to a URS, an LLM cannot independently determine how a system meets those requirements without being explicitly told.

      The same applies to qualification test scripts. These are step-by-step instructions used to verify whether the system meets its documented requirements. They must be traceable, reproducible, and inspection-ready – and they require domain knowledge to be meaningful. LLMs cannot reliably generate test descriptions because they don’t understand how the system functions, what needs to be tested, or how to design a test that produces meaningful, validated results.

      If generating test scripts were as simple as prompting an AI, most qualification tools would be fully automated by now. But they are not – because test design remains a technical, judgment-based process.

      Can LLMs Automate the Process of Filling a Traceability Matrix?

      Some vendors have been marketing their ability to automate traceability, namely by using LLMs to identify which test script aligns with a given URS requirement. But is it really possible to perform this task truly reliably using AI?

      One approach would be to use a type of LLM known as a sentence transformer model, a class of AI designed to compare entire sentences rather than individual words. These models can capture semantic relationships between phrases – for example, comparing the intent of a URS requirement with the description in a test script (be it an IQ, OQ, or PQ) – and then rank the closest matches accordingly, to select which script number matches each URS requirement.

      Transformer models are trained on billions of data points and can encode the meaning of phrases or entire sentences, not just individual words. However, their reported accuracy leaves some questions.

      Here are the published accuracy figures for some commonly used transformer models:

      ModelReported Accuracy
      all-distilroberta-v1~85%
      all-MiniLM-L12-v2~80%
      paraphrase-MiniLM-L6-v2~70%

      To assess performance in a qualification context, we tested two of these models – all-distilroberta-v1 and all-MiniLM-L12-v2 – by asking them to match 50 URS statements against 50 corresponding functional requirements.

      Despite both documents being clearly written, the LLMs mismatched 11 of the 50 statements to the wrong requirements – more than 20%. Even when combining different transformer models to improve accuracy, we never obtained an accuracy of 90%. Of note, this occurred even when both input sets were well structured. In real-world scenarios, where URSs and scripts often vary in phrasing, specificity, or formatting, this represents a serious challenge to the idea that LLMs can automate traceability.

      For matching URS requirements to test scripts the accuracy shortfall would become even more pronounced, as scripts are written in less descriptive and more procedural language than FSs – simply describing steps to be executed, and not their intent. Sentence transformer models are not yet capable of reliably inferring test intent from such procedural language. The point then is that if human experts still need to manually verify each AI-suggested match, what, if any, are the efficiency gains?

      It’s also worth noting that these models are more specialized than general-purpose LLMs like ChatGPT or Mistral. Therefore if transformer-based models – trained specifically for sentence matching – struggle with this task, non-specialised models will likely perform worse.

      Where LLMs Might Help

      Despite these limitations, LLMs can still support certain tasks – particularly when used under SME supervision in low-risk contexts. Potential use cases include:

      • Drafting boilerplate content (e.g., introductory or regulatory reference sections),
      • Improving clarity, grammar, or formatting,
      • Suggesting document structures or outlines,

      These kinds of low-risk, repeatable, and time-consuming activities are suitable areas for automation, with AI acting as a support tool. However, even in these cases, outputs need to be reviewed and approved by qualified personnel to ensure regulatory accuracy and contextual appropriateness.

      Final Thoughts

      The importance of accuracy in qualification, and the limitations of LLMs mean human input is still essential. While LLMs can support low-risk, repetitive tasks like drafting boilerplate content or improving formatting, their role in generating qualification documents remains limited.

      By definition, a URS must reflect what human users need from that asset/service to be purchased – something no AI can independently determine. These documents require expert judgment, deep process understanding, and context-specific decisions that LLMs simply cannot replicate, at this level of maturity.

      Similarly, the use of AI for automating traceability – such as matching URS statements to test steps – still falls short. Even advanced sentence transformer models show accuracy rates that are too low for compliance-critical tasks. In regulated environments, a 20% error rate isn’t just inefficient – it’s dangerous.

      Errors in qualification can have serious consequences: from costly equipment failures to regulatory violations or, worse, risks to patient safety. That’s why experienced professionals must remain in control of the process.

      In short, LLMs may enhance productivity in certain areas, but when it comes to URS, FS, and traceability matrix, human expertise, oversight, and responsibility are irreplaceable.

      ravi

      June 18, 2025
      Uncategorized
      AI, pharmaceutical, validation

    • The ROI of eLog Pro: Not Just Financial Benefits for Pharmaceutical Manufacturers

      The ROI of eLog Pro: Not Just Financial Benefits for Pharmaceutical Manufacturers

      Synopsis

      This article explores how eLog Pro, Quascenta’s electronic GMP logbook software, helps pharmaceutical manufacturers to achieve GMP compliance and boost operational efficiency. It details the limitations of paper-based logbooks and shows how digital documentation improves data accuracy, reduces human errors, and streamlines regulatory processes. Featuring mobile data capture, offline access, and seamless equipment integration, eLog Pro supports real-time collaboration and audit readiness. The platform delivers significant ROI through reduced costs, increased productivity, and improved data integrity—making it a vital tool for pharma digital transformation in GMP environments.

      Why eLog Pro?

      Pharmaceutical manufacturers operate in a highly regulated environment where comprehensive documentation of routine operations, including equipment usage, cleaning, calibration, and environmental conditions, is necessary for complying with Good Manufacturing Practices (GMP). Traditionally, this has meant maintaining thousands of paper-based logbooks – an approach that is unfortunately inefficient, error-prone, and costly.

      Electronic GMP logs however, such as Quascenta’s eLog Pro, can offer a user-friendly software solution that transforms how pharmaceutical facilities manage GMP activities. By replacing traditional paper-format logs with a streamlined digital platform, Quascenta’s eLog Pro can capture data efficiently, enabling real-time collaboration, automated compliance, and significant cost savings. Beyond improving operational efficiency, it also delivers a strong return on investment (ROI) for adopters by reducing material costs, minimizing errors, and freeing up valuable personnel time.

      Streamlined Data Capture

      One of the main inefficiencies of paper-based logbooks is the time and effort required for manual data entry. With eLog Pro, operators can enter data directly into the system, eliminating the risk of transcription errors to ensure greater accuracy in record-keeping. The platform also supports mobile devices, allowing personnel to record events and observations in real time, rather than relying on handwritten notes that must be transcribed later. Multi-user access enables multiple team members to contribute to log records simultaneously too, adding to the efficiency gains for your team.

      In manufacturing or R&D environments, data often needs to be collected near equipment or instruments where Wi-Fi may be unavailable— however eLog Pro allows data entry even while offline. The system then synchronizes securely with the cloud once connectivity is restored – e.g. at the end of the day or after shifts – through a process secured by robust cybersecurity safeguards.

      By reducing manual errors and automating data entry, companies not only save time but also minimize costly deviations and investigations. Investigating and resolving data discrepancies in a GMP environment is a resource-intensive process, often requiring hours of additional work from quality assurance teams. With eLog Pro, data integrity is ensured from the outset, reducing the likelihood of such costly errors.

      Improved Visibility and Collaboration

      Access to accurate, up-to-date log records is critical for smooth operations and regulatory compliance. eLog Pro provides real-time access to log data from any location, eliminating delays associated with searching for paper records. A centralized digital repository ensures that all teams work with the same accurate data, preventing duplication and miscommunication.

      Improved coordination between departments leads to better decision-making. When maintenance teams, quality personnel, and operations staff have instant access to log records, they can collaborate more effectively, reducing downtime while ensuring continued compliance with GMP standards. The ability to quickly retrieve historical data also helps make audits and inspections go more smoothly, saving time and reducing the associated stress of compliance reviews.

      Data-Driven Decision-Making

      Traditional logbooks provide limited opportunities for analysis. Paper records make it difficult to identify trends, investigate recurring issues, or make data-driven decisions. eLog Pro changes this by offering powerful data analysis tools that enable companies to identify patterns, conduct root cause analysis, and take proactive measures to prevent issues before they escalate.

      For example, a facility using paper-based logbooks may not immediately recognize recurring equipment failures, leading to repeated production stoppages. With eLog Pro, trend analysis can highlight patterns of equipment malfunctions, allowing maintenance teams to address underlying issues before they result in costly downtime. Similarly, deviations and compliance issues can be tracked and analyzed in real time, improving overall process reliability.

      Regulatory Compliance Simplified

      Ensuring compliance with regulatory requirements is one of the most time-consuming aspects of pharmaceutical manufacturing. Paper-based logbooks require extensive manual effort to maintain, verify, and retrieve during audits. eLog Pro simplifies this process by automatically generating complete and accurate audit trails, ensuring that all log entries and modifications are recorded transparently.

      Electronic signatures further enhance compliance by helping to ensure data authenticity and integrity, to meet FDA 21 CFR Part 11 and other regulatory requirements. Secure cloud-based storage eliminates the risk of lost or damaged records, a common issue with paper logbooks. By streamlining audit preparation and reducing the risk of non-compliance, eLog Pro helps companies avoid costly penalties and regulatory delays.

      Financial Benefits: A Breakdown of Cost Savings

      Implementing eLog Pro leads to substantial cost savings by eliminating expenses associated with paper-based logbooks. The savings begin with the direct costs of paper, printing, and storage but extend beyond that to include labor efficiencies and error reduction.

      For example, a typical pharmaceutical site may maintain logbooks for equipment usage, cleanroom monitoring, warehouse environmental conditions, and calibration records. For a site managing 500 pieces of equipment, maintaining paper logbooks can be a significant expense.

      • The cost of printing and binding a 100-page logbook is approximately $15 per logbook.
      • Maintaining 500 logbooks per site results in an estimated monthly printing cost of $7,500, translating to $90,000 annually.
      • Additional logbooks for environmental monitoring and calibration can add another $15,000 to $60,000 in yearly costs.

      These figures do not account for the indirect costs of managing paper records. For example, paper logbooks require climate-controlled storage to prevent deterioration over time, adding facility and maintenance expenses. Digital logbooks eliminate these storage costs while also reducing the risk of lost or misplaced records.

      Labor savings also contribute significantly to ROI. Employees spend considerable time manually entering data, reviewing logbooks for completeness, and correcting errors. Transitioning to eLog Pro reduces administrative burden, freeing up personnel for more value-added tasks. Additionally, automated workflows and instant data retrieval speed up routine operations, improving overall productivity.

      Conclusion: A Clear Return on Investment

      Quascenta’s eLog Pro is more than just an electronic logbook—it is a strategic investment in efficiency, compliance, and cost reduction. By transitioning from paper-based logbooks to a digital solution, pharmaceutical companies can achieve significant savings on materials, labor, and storage while improving data accuracy and regulatory readiness.

      With a rapid implementation timeline and an intuitive interface, eLog Pro allows companies to start realizing benefits within weeks. As the industry moves toward increased digitalization, adopting a solution like eLog Pro is a crucial step in optimizing manufacturing processes, ensuring compliance, and maximizing profitability.

      For companies looking to improve GMP log management, eLog Pro offers a proven solution that delivers measurable financial and operational benefits. Request a demo today to see how it can transform your facility.

      Quascenta Team

      May 26, 2025
      Electronic Log, Uncategorized
      electronic log book, 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.