User Acceptance/Validating Studies
      Back to home
      1. Help Center
      2. Study Administrators and Managers
      3. User Acceptance/Validating Studies

      Study Validation and Training

      Testing a database, validation, and user training

      Contents:

      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

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

      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