Testing a database, validation, and user training
TrialKit System Validation
System validation is a requirement of a few common industry regulations whereby supplier systems (like TrialKit) should be validated at a high level before being approved and put to use. While this is not a definite dependency for building a study or deploying one, it is a concept to consider covering if your organization has not yet done so.
Crucial Data Solutions (CDS) verifies and certifies the TrialKit platform for customer use in medical research (OQ and PQ), but cannot perform validation on behalf of its customers. Please reach out to your CDS Sales Representative for more information on how CDS can best assist your organization with that part of the process.
Study Validation and Testing
Once the study building process has wrapped up, it's time to perform testing and study validation. This process is not only applicable at the beginning of a study, but also when changes to the design are made mid-study.
Formal study validation is an important step for verifying how well the database will support a study protocol and compliance with applicable regulatory guidelines in the regions where the study data is collected or submitted.
Here's a sample validation plan outline.
TrialKit’s functions are all verified at a system level under a common use case (configuration) and can be guaranteed by CDS to function appropriately. The idea behind study validation, as it's covered here, is to verify that a given function works the way it is intended for a given study in a manner that aligns with applicable requirements (both regulatory and protocol). The validation process also helps catch settings that may have been unintentionally missed or misunderstood during the study build.
It is important to follow your organization's Standard Operating Procedures (SOPs). The goal of this article is to suggest methods for efficiently building acceptance and validation documentation.
Export the study design and key configurations
Study roles and permissions
Data Dictionaries (be sure to export the applicable version if the study has is more than one)
Form Properties
Conditional Actions
Field Properties
A Complete PDF Casebook
Export the visit schedule
Topics that will get validated from the exported files above:
Form-level conditional actions
Field-level conditional actions
Form rules (properties)
Study role access
Form view/edit rights
Field Blinding
Visit Schedule date windows
Document the Validation
Using the exported role permissions file from #1 above , verify the user roles have access to the functions they need. An exhaustive check is not necessary here since user permissions are already validated by CDS. The idea is to understand the key permissions that users need to perform their duties.
Using the exported Excel files from #2 above, add columns that are needed to address each of the elements being tested:
Pass or Fail
Results - Common answers are “As expected”, “Failure”, or “Test Script Failure” Always want to answer as expected if it passes not just pass. You have to refer to the requirement of the row.
Notes Failure documentation
By Whom (Testers initials)
Date of the test(s)
Notes
Example of columns added to a validation script:
.png "image(606).png")
Go down the file and verify the conditional action or property being tested behaves as it is intended. Edit checks can be skipped (these will be tested next). Form properties will cover important factors including view/edit rights for roles and field blinding. To make this easier, grant the Administrator role access to switch roles.
Run Auto-validation on the form’s edit checks. The results will be logged and maintained within TrialKit, which can also be exported for filing purposes.
On a test subject, verify the visit schedule and date windows are displaying as intended based on a sample Registration date.
Any other items to validate will depend on the functions being used in the study. For example:
Randomization
eConsenting
ePRO diaries and deployment timelines
Product Distribution and Assignments
Entering Test Data
TrialKit is designed in a way that allows for a single database to be used for development, testing, and later moving to a live status. Even after a study has gone live, additional versions will be added as changes are needed and the test data will be added in the actual study. An additional/separate environment is not necessary because all the testing/training data will be entered into an Administrative site. When data is later exported or reports are produced, that Administrative data will not be included. This concept greatly helps streamline control and quality of a study design.
To enter test data in a development version of the study, an Administrative site will need to be used. With that, data can freely be entered without any consequences or impact on the study design or any preexisting live data that is getting collected on the previous published version.
Simply head to the subject manager and walk through the flow of the study. Be sure that the test subject is on the correct version where the new changes have been applied.
.png "image(604).png")
User Training
Once study testing and validation is complete, training users is handled the same way as UAT, where a separate Administrative site can be used to give access to users that need to be trained. This way they can enter "sandbox" data into the actual environment that they will eventually be enrolling and adding study data.
This Knowledge base is a great resource to use for linking to applicable help articles for training study end Users. It's also possible to create custom web pages and link to those from your study home page or from any form. The benefit with that is the ability to prevent specific content for your study and form completion guidelines.
Here are a couple suggested articles that end Users will find helpful:
TrialKit System-Level Certification
Crucial Data Solutions (CDS) performs certification testing on all functions in a standardized environment. That is documented with each major version that is released and summarized on a version certificate (available upon request).
The underlying functions tested as part of this process are in the list below. This can be a helpful reference to use in supplier-level validation for your organization, depending on the functions utilized for a given study/project.
User-specific sign in security
User management and access history
Site management
Study user membership
Form Building
Conditional actions
Data Entry
External variables
Subject Form Data Audit
Version Management
Subject Record Management
Visit Schedules and Cohorts
Study Configuration
Record Review Workflow
Data Exports
Study Management
Report Builder
Query Management
Role Security
Randomization
Action Items
Notifications
Site Documents
Study Documents
Form Field Rendering
Monitor Report
Lab Normals
Importing Data
Study Progress Report
Adjudication
User Preferences
Record Status Report
Field Level Review (SDV)
PDF Exports
Payment Management
Medical Coding
File Uploads and Storage
Wearables Data
Inventory Management
ePRO and eDiaries
Informed Consent
Trial Master File
Dashboard Report
Video Conferencing
Scheduling
TrialKit Drive Automated Exports
Visit Summary Report
CTMS
Signature By Role Management