Study Validation and Training

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

  1. Study roles and permissions

  2. Data Dictionaries (be sure to export the applicable version if the study has is more than one)

    1. Form Properties

    2. Conditional Actions

    3. Field Properties

  3. A Complete PDF Casebook

  4. 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:
ce69d2c1-df71-4adc-961c-18dea28718e5


  • 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.

 

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:

Navigating TrialKit

The Basics

 


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.

  1. User-specific sign in security
  2. User management and access history
  3. Site management
  4. Study user membership
  5. Form Building
  6. Conditional actions
  7. Data Entry
  8. External variables
  9. Subject Form Data Audit
  10. Version Management
  11. Subject Record Management
  12. Visit Schedules and Cohorts
  13. Study Configuration 
  14. Record Review Workflow
  15. Data Exports
  16. Study Management
  17. Report Builder
  18. Query Management
  19. Role Security
  20. Randomization
  21. Action Items
  22. Notifications
  23. Site Documents
  24. Study Documents
  25. Form Field Rendering
  26. Monitor Report
  27. Lab Normals
  28. Importing Data
  29. Study Progress Report
  30. Adjudication
  31. User Preferences
  32. Record Status Report
  33. Field Level Review (SDV)
  34. PDF Exports
  35. Payment Management
  36. Medical Coding
  37. File Uploads and Storage
  38. Wearables Data
  39. Inventory Management
  40. ePRO and eDiaries
  41. Informed Consent
  42. Trial Master File
  43. Dashboard Report
  44. Video Conferencing
  45. Scheduling
  46. TrialKit Drive Automated Exports
  47. Visit Summary Report
  48. CTMS
  49. Signature By Role Management