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, or 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.
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)
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
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)
- 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:
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.
Once study testing and validation is complete, training users is handled the same way, 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.
TrialKit System-Level Certification
Crucial Data Solutions (CDS) performs certification testing on all functions in a standardized environment. The underlying functions tested 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 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
- Action Items
- Site Documents
- Study Documents
- Form Field Rendering
- Monitor Report
- Lab Normals
- Importing Data
- Study Progress Report
- 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
- TrialKit Drive Automated Exports
- Visit Summary Report
- Signature By Role Management