Validation package

The validation documents of the platform and of a study: how each is made, versions, who signs, the ZIP and the TMF.

The validation package gathers every document of a computerised system validation by GAMP 5: from the validation plan and the user requirements to the IQ and OQ protocols, the traceability matrix, the summary reports and the certificate. The portal writes most of them from its own data, keeps their versions and signatures, and gives the whole package as one ZIP. There are two packages: the platform's, made once per installation, and each study's.

Who sees it

The platform's package is under “Validation package” in the portal menu, for people the Portal Owner allowed personally or through a group (see “Access management”). A study's package is in the study menu for members with the right to the study's documents; reading it is enough to download, making and signing needs the right to edit documents, and approving needs the right to approve them. A study's package is kept in its QA environment: that is where the study build is validated. The eCRF and all its versions are built there, each candidate is tested there by its UAT, and the package is made and approved there. Then “Release in production” carries the validated candidate into production, where it works at once: nothing is validated in production. The menu item in production and in the training environment leads to the package in QA. In production the package is neither made nor signed, also in an older study made before the QA environments: its package page explains that validation happens in QA and leads to “eCRF versions”, where the QA environment is made. Documents that earlier releases kept in production by mistake move to the study's QA environment once (at the install of the release, or when an older study gets its QA environment), with a line in the audit trail; after that production holds no package.

The checklist

The page shows the documents by stage: plan, specification, installation, reviews, testing, release, operation and maintenance. Each row says whose document it is (Supplier, Client, Supplier writes and client approves), how it is made (written by the portal, a template to fill in, a protocol executed here, screenshots), its version and its signatures. The colour of the circle is the state: green approved, amber waiting for signatures, red made on another release, grey not made yet. On top, the numbers and the bar show how much of the package is approved.

“Make” writes a document from the current data. If nothing changed, no new version appears. “Make all” writes every document in the chosen language; for the platform it runs in the background. “ZIP” downloads the current version of every document with a manifest and SHA-256 checksums; a study's ZIP also carries the platform's package. The file 00_contents.txt in the ZIP lists the documents with their other names and names those not made yet: for a full package, press “Make all” and download the ZIP again.

Under a document's name you see the other names it goes by in other companies' SOPs: the FRS is the SRS (software requirements specification), the OQS the TSR (Test Summary Report), the IQ-VM and IQ-APP protocols the IQs, the VSR-S and VSR-C summary reports the VSR, the TM the RTM. The search in the top bar finds the package by these names too.

Versions and signatures

A new document is version 0.1, the next draft 0.2, and the first approved one 1.0. Each version is kept as PDF and Word, with the data it was printed from. You can also upload your own version (for example, a plan your company wrote in its own template).

A version is signed with your e-mail and password, in order: prepared by, reviewed by, approved by. The author cannot review or approve the same version. Supplier documents are signed only by the people the Portal Owner listed under “Who signs for the supplier”; client documents only by everyone else. So the supplier can never approve a client document for the client: a client document counts as approved only after the client's own signature.

Protocols and screenshots

IQ protocols and the OQ test execution protocol are executed on the document's page: for each step mark pass, fail or not applicable and write what you saw (a failed or not applicable step needs a comment). Steps the application can check itself (build, migrations, audit trail chain, e-mail, Portal Owners, time) are filled in automatically; a result you record takes their place. Screenshots for the evidence document are uploaded on its page, with a caption and the step they show.

Where the data comes from

The platform's documents are written from the requirements with their risks, the hand-written validation documents of the supplier, and the results of the build's automated tests and code checks, which the release archive carries. If the server has no test run attached, the page says so and the test reports say the run is missing. The certificate in the supplier's summary report is issued only when every criterion is met: all tests passed, IQ and OQ executed with nothing failed, all other supplier documents approved.

A study's documents are written from the eCRF candidate being validated in the QA environment, the newest one (the specification, the edit checks, the traceability), its UAT runs with their steps and signatures, and the release record of each version released into production. The candidate's specification shows which production version it became, with the SHA-256 of both. While the package is not approved, the Release in production form of the QA environment says so (how many documents of how many are approved), and a release with the package not approved goes to the audit trail.

Maintenance plan

The System Maintenance Plan (SMP) says how the system stays in its validated state from its release for use until its retirement, following GAMP 5 (Second Edition) and Annex 11: backup and the restore test, business continuity and disaster recovery, updates and change control, security patches, monitoring, incidents and CAPA, periodic review, user access review, archiving, decommissioning, roles and the schedule. The portal writes it from the installation's data: the backup's schedule and retention from the installation scripts, whether a recent copy exists, the periodic jobs, the audit trail chain check, the releases and the change control procedure, the people who sign for the supplier. If there is no recent copy, the plan says so in red. What the system cannot know (response times, who keeps the key, how often the restore is tested) is left in square brackets; the table of restore tests is filled in at each test.

In a study it is the client's plan for the study build in operation: eCRF changes through the QA environment and UAT, the team's access review, data integrity, the periodic review, the close, the archive and the retention. The client prepares and approves it; the demo study shows it approved.

Send to the TMF

In a study with the eTMF switched on, “Send to the TMF” files every made document of the study's package and of the platform's package in the study's eTMF. Each document goes to its TMF artifact (for example, the eCRF specification to “CRF specification”, the platform's documents to “Computerised system validation”) and follows the eTMF's quality control rules. Sending again adds a new version only for the documents that changed; the result is in the audit trail.

What stays with you

A generated document is a draft until people review and sign it: the portal does not validate the system for you. The validation plan, the client's URS approval, the user acceptance testing and the client's summary report are your company's decisions, made under your SOPs.