Case Study
Pharmacovigilance Safety Database Validation

About Us & Our Approach

At Biomapas, we specialize in the validation of Pharmacovigilance systems. Our skilled validation team brings practical knowledge and experience in routine pharmacovigilance activities, software development, and project management. Their expertise enables us to pinpoint and manage nuanced risks associated with pharmacovigilance and software development processes, create compliance-friendly validation strategies, and meet our clients’ budget and time requirements.

As a real-world example, let’s look at a case study of a Pharmacovigilance system validation we recently tackled.

The Challenge?

We were approached by a mid-sized pharma company in the European Union to validate a cloud-based safety database.

They needed the next system release validated and implemented within two months, with four additional releases lined up over the following two and a half months.

Our mission was clear – ensure a smooth, compliant validation of the five impending releases. For clarity, we’ll refer to them as Release 1, Release 2, etc. Complications arose due to the sheer number of release notes and overlapping releases, making our task all the more challenging.

To accomplish our client’s goal, we drafted the following plan:

Document business process requirements.
Perform risk assessment of the supplier.
Develop a validation strategy.
Execute validation activities for each release

1. Documenting Business Process Requirements

Understanding what our client aims to achieve with the system is key to streamlining our efforts and executing validation activities efficiently and cost-effectively. Our client already had a User Requirements Specification (URS) from the system’s previous release. We worked together to confirm the relevance of these requirements, made necessary adjustments, and simplified any redundant language.

2. Performing Vendor Risk Assessment

Although vendor risk assessment typically follows the development of a validation strategy, in this case, the supplier was predefined, and we needed to figure out how to validate all forthcoming releases effectively. Thus, we started by evaluating:

The supplier’s approach to internal validation activities.
The quality of their validation documentation and release notes.
Our past experiences with the supplier.

After our initial review of validation documents, release notes, and internal workshops discussing our experience with the supplier, we identified several risks:

GAMP Categorization

The supplier classified the system as GAMP 5 category 4. Still, we believe the internally developed system should be placed in GAMP 5 category 5, requiring more comprehensive validation activities.

System Bugs

The supplier did not validate bug fixes in the system, which could lead to errors in the case processing workflow and disrupt the interaction among different database functions.

Lack of Validation

No validation was performed for new functionalities with a medium impact assessment. Given that the system’s overall impact was assessed as high (for processing and reporting adverse event information), we saw this as a significant risk to system compliance.

Release Notes

The level of detail in release notes was low. From previous interactions, we knew that responses from the supplier could be delayed, and we had to factor in the risk and extent of follow-up requests to meet the system implementation timeline.

3. Developing The Validation Strategy

With the results from our risk assessment and considering the system’s previous validation history (last validated around two years ago), we agreed on the following validation strategy with the client:

Validate Release 1 as a new application.
For Releases 2 to 5, review release notes and supplier validation documents, perform risk and impact assessments of changes and develop a unique validation plan for each release.

4. Validation Activities

We then started our work on each release, including an initial system assessment for Release 1, reviewing release notes and supplier validation packages for Release 2, and extensive work for Release 3 to Release 5, involving a review of a large number of release notes and extensive communication with the supplier to clarify uncertainties.

We started with the initial system assessment. This safety database was assessed as GxP regulated and GAMP 5 category 3 as our client uses it in the supplier’s default configuration. Still, we have decided to prepare and run a thorough user acceptance test (UAT), considering risk assessment results. The complete list of prepared documents includes:

User requirements specification.
Validation plan.
Change review checklist.
UAT scripts.
Validation report.

The system description was not prepared due to the peculiarities of the client’s approach to database documentation. Our team performed the UAT, the results were documented in the validation report, and the system release was successfully launched according to set timelines.

For this release, we have reviewed the release notes and validation package of the supplier and communicated the review results to the client. It was mutually agreed that the extent and scope of changes are not significant enough to run UAT. So we have prepared the corresponding validation package:

User requirements specification (no changes from Release 1)
Validation plan
Change review checklist
Validation report

Again, the system release could be used in daily operations according to supplier schedules.

We have to admit that the work with these releases was quite extensive. Mainly because of a large number of release notes (1500+). The review also required extensive communication with the supplier to clarify all the uncertainties. So we started the review as early as possible and communicated a question once it arose. When the review was completed and all uncertainties clarified, a summary of the activity was provided to the client. The summary included:

Number of release notes regarding new features stratified by impact (low, medium, high).
Number of release notes regarding bug fixes stratified in the same way.

The validation packages of suppliers were also reviewed for all releases.

Our approach was to save time for our client and show that the number of release notes with medium and high impact is large enough to consider a complete validation cycle for them. So, we have agreed to run UAT for Release 5 as it contains all the new features and bug fixes from Release 3 – Release 5. A similar validation package was prepared for this validation cycle:

User requirements specification (aligned with new features).
Validation plan.
Change review checklist.
UAT scripts.
Validation report.

There were additional difficulties with this validation cycle as the supplier’s access to the sandbox and validation environment was overdue. Still, we have managed to complete validation activities on time.

Start a conversation

While guidelines review might suggest that validation for GAMP 5 category 3 systems is straightforward, practical experience teaches us that it can be challenging. As illustrated in this case, factors like multiple releases, extensive documentation, and supplier peculiarities can complicate the process significantly.

If implementing Pharmacovigilance computerized systems seems daunting, we’re here to help. We provide customized support based on your needs and budget.

Don’t hesitate to get in touch with our business development department for more details or to request a proposal (RFP).

Let's Talk