When the Project Specification and the Project System don’t match…

Case Studies

Sometimes it’s a simple thing that gives quality management theory a challenge. For example:

Conventional practice for testing a clinical trial project system asserts the following: When tracing from a test result to the official Project Specification (PS), any discrepancy between the PS and the system requires failing the test step and then re-testing it again in a new test cycle after a correction interval. If we translate this assertion into other terms, the problem with this reasoning becomes obvious: The approach mandates that errors that occur only in the project specification document must result in failing the system – even though the system is perfectly correct. Impact on timelines and project costs are the unfortunate results of this convention.

A typical example: The PS for System XYZ, which outlines the setup configurations for the new project system, has an error in the table that describes the permitted treatment windows for each clinical visit. The PS says X plus or minus three days is permitted at Visit 2; the system is configured to allow four days. From client meetings and correspondence, it’s certain that four days is correct– that is, the system is entirely accurate. The only error that has occurred is that the team has forgotten to make the update to the project specification document prior to the start of testing.

Veracity Logic takes the following view in such cases: When there is certainty and collateral confirmation that only the PS document needs to be corrected, Testers are instructed to mark the test step as a Pass and open a new case in our Issue Tracking System for the required PS Update. A unique tracking number is generated for the case and a discrepancy note including this number is added by the Tester to the test case/step. The Validation Summary Report for the entire testing process captures both the number of Passed and Failed test steps and the number and location of PS Updates required to be corrected (and the PS re-approved) prior to releasing the system for Client User Acceptance Testing.

Need to shorten startup time without sacrificing project quality?

Case Studies

Problem:

Your study has a hard startup timeline but there have been an array of delays and modifications on the science side of things. You not only need to make up time, you need to make some changes to the specifications for your vendors, including your IRT system which is already in validation…and you need to do it all without killing your timeline or sacrificing quality. What to do?
Solution:

We know clinical trials…change is a common phenomenon! That’s why Veracity Logic’s IRT was designed to provide maximum flexibility for just such situations. The VLIRT® system was built with an emphasis on two key strategies:

Validated CORE technology
Configurable project system modifications

Our validated CORE informs risk assessment strategies to enable focused, efficient testing and a high quality product in a timeline-friendly fashion.

Our base of easily modified, quickly accessed, protocol-specific setup configurations keeps the need for custom coding to a minimum in the development and change management of all project systems.

Want more to know more about how VLIRT can make your life easier?