website header-4

Validating your eQMS

📗 Read time: 347 minutes (just kidding-- it's ~15 minutes)

Your team needs a thorough understanding of how your selected software will be validated, and this topic should be a critical part of your eQMS evaluation. In particular, it's important to understand what your vendor/ partner will bring to the table. Below is a primer on managing the initial qualification/validation process for your new eQMS. 

Table of contents: Key sections for eQMS validation

Some documents that should be on your radar

These items will be raised directly/ indirectly as you are inspected, especially if you are in or near a commercial stage. So make sure to get these in place with your chosen vendor.

eqms SOP icon

Standard Operating Procedures

Regardless of your scale, you will at least want to have an SOP on vendor management on the books that governs how you onboard critical-to-quality vendors/ contractors. As you mature, it also makes sense to consider a specific and updated Computer Systems Validation procedure or instruction. For the latter, note how many SaaS vendors you are working with and consider a thoughtful approach to re-qualifications.
eqms confidentiality

Confidentiality Agreement

This agreement is between you and the vendor, and is required to protect your data, intellectual property, and commitments regarding privacy (for patient or employee private information). This is especially relevant for SaaS vendors who will also be hosting/ processing your data. And if you have information in your quality records from EU citizens, you may also request a Data Privacy Addendum as well that fulfills GDPR requirements.
eqms QTA agreement

Quality Technical Agreement

This should be required in a GxP environment. A QTA is simply a quality-to-quality agreement that outlines responsibilities and sets expectations. It should be signed by quality leaders from your company and the vendor.
eqms privacy dpa icon

Data Privacy Agreement

Emerging privacy legislation in EU, Canada and some US states means this topic needs to be addressed head-on, especially with patients/ users in EU. Your partners should at least offer a DPA including GDPR-compliant Standard Contractual Clauses.

Validation Overview: What is the GAMP 5 Framework?

An Introduction to GAMP 5

GAMP 5 drives the life sciences space and is consistent with ISO and other key standards.  This should be the methodology underlying your validation efforts. You can find a good reference here or review the webinar by Melita Ball @ MBCA Consulting regarding validation. Other standards/regulations that you are subject to, such as 21 CFR p.11/ Annex 11, CLIA/CAP, etc. are also relevant and can/should be incorporated into your qualification as appropriate.Validation establishes "documented evidence which provides a high degree of assurance that a specific computerized process or operation will consistently produce a quality result meeting its predetermined specifications." Source: GAMP 5

GAMP 5  provides a risk-based approach to validation, and two core areas of focus will be:

  1.  The level of customization in the software (e.g. commercial off the shelf vs. custom software)
  2. Possible impact based on company stage, area of use, etc.

Let’s just say this out loud together-- your eQMS will hold critical documents accompanied by electronic signatures and  should be deemed critical/ higher risk for companies from preclinical to commercial stages. It's just not an option to ignore validation altogether. But the framework does allow your  stage and type of software to dictate how difficult this will be.

A GxP auditor's perspective starts with a basic, but critical premise.

Is the eQMS package you implemented fit for purpose and did you follow your SOPs in qualifying it?” Source: FDA Auditor re CSV

The quote above is from an FDA auditor with +20 years field experience and who also advised on the agency’s cloud computing activities. And it sounds simple, doesn't it? Let’s unpack this.

The “fit for purpose” bit is an essential term of art-- it presupposes that you have:

  1. A documented set of requirements for your needs; and
  2. That you documented how your selected solution meets those core requirements; and how you validated all of this.

Whether this stuff takes the form of a simple memo or a full URS, Quality Audit, UAT, etc. is really a secondary point driven by your quality SOPs, stage, risk assessment, etc. But showing the inspectors nothing is more likely to cause you a problems than showing them something them something they can review.

The second part is a little easier to follow. If you have critical vendors/contractors, you should have a documented SOP governing how you qualify, audit and manage them. You may also have an additional SOP governing computer systems validation. You should expect to be asked: 

Did you follow your own SOPs?
Where’s the audit and risk assessment?
Is your qualification based on your risk assessment?
Can you explain/ defend it easily?

How to validate a heavily-customized eQMS

Whether you are creating your own software tools from scratch or heavily customizing from an existing core, your software validation will be a bit heavier by default. You are basically in the regulated software business, and auditors will hold your efforts to the same high standards they would a stand-alone software developer deployment. Your vendor partner or consultants can/ should make sure to deliver some or all of these documents as part of a release, but remember this process also governs any changes you want to make in the future-- meaning you will have to update your validation with any changes. Let’s be honest here-- this is onerous, and a core reason why so many custom deployments languish without updates for years at a time.

Delivering the software will require the following:

  1. Your development team (either a vendor, consultant, or internal group) needs a defined quality manual defining how the group meets general GMP/GAMP/ISO requirements for:
    1. Document Control
    2. Change Control
    3. Deviations/Issues
    4. Staff training
    5. Vendor management/ Audit
    6. Infrastructure/ environments
    7. Business Continuity/ Disaster Recovery
    8. Software Development Lifecycle (SDLC) process
  2. Validation documents for your release must be comprised of documents from design to deployment that follow your SDLC and GAMP 5. That means each release should be managed by a defined validation plan and change control and should reference some/ all of these items:
    1. Design Specifications: these dictate exactly what the software does, and are usually referenced as User Requirements Specifications (URS) and more detailed Functional Requirements Specifications (FRS)
    2. Operational Qualification (OQ): a pre-approved set of tests to be executed in a controlled environment that demonstrates delivery of User/ Functional requirements. Remember to include objective evidence of execution.
    3. Traceability Matrix: connects all requirements to executed Tests in the OQ
    4. System Release: QA approval to deploy
    5. Installation Qualification (IQ) documents the steps to deploy the software to an environment.
    6. Performance Qualification (PQ) is a set of tests to prove the deployed software is working properly.
    7. Validation Summary
  3. 21 CFR p.11 / Annex 11 assessment: Given how critical this is to data integrity, it’s important to assess this separately. Remember not all of these requirements are technical (e.g. some rely on SOPs). A detailed checklist approach works well here. If you use your vendor's make sure to add a review that assesses your components.

How to validate a cloud-based eQMS

SaaS platforms should already have in place the core validation ready for review. That means the software/ infrastructure has been developed in accordance with all relevant standards within a defined quality manual, including detailed Software Development Life Cycle, and is attended by a full suite of validation documentation made available to your team on demand (User Requirements, Functional Requirements, Traceability Matrices, OQ/PQ/IQ, etc.).

Coupling this with the quote from the FDA auditor above means you need a memo or qualification document that:

  • Documents the need for an eQMS with a basic list of your requirements (don't have one? See the link to download a draft template below).
  • Describes your vendor selection decision, including mitigation for any critical missing requirements.
  • References your audit/ risk assessment of the selected vendor and vendor documentation.
  • Justifies your qualification on a risk-based approach. Here you are linking back to your audit/risk assessment and documenting your expected approach to acceptance testing and an re-qualifications for updates.
  • Executes an appropriate User Acceptance Testing (or Mini-PQ) to document that the account configuration is "fit for your purpose".  It's important to note that you aren't verifying the system functionality (the vendor did that!) you are verifying the categories, workflows, user groups etc. are set based on your specifications.

 

How to validate ZenQMS [URS download]

While many of our clients are experienced, we want our process and approach to be simple for anyone to follow. We start by sharing a checklist to guide your supplier qualification audit as well as your review of all quality and validation documents.

We provide a templated URS you can customize for your own purpose.  We also provide a UAT that covers all the main journeys through the application-- this is not meant to be exhaustive, but is an ideal way showing the technology is fit for intended use in your organization.

ZenQMS also provides a downloadable p.11/Annex 11 checklist, that can also be included in your internal documentation.

The kicker here-- we don't charge for these items or our guidance support in the process. It is all part of our single fixed implementation fee. 

Let's Do This
  • Guided audit/ qualification checklist
  • URS Template
  • UAT Template
  • p.11/ Annex 11 Checklist
  • No charges.