This is the second part of our two-part blog series on CRF validation. If you haven’t read the first part yet, you can access it here for a comprehensive glimpse on the topic.
We talked about all the potential pitfalls of CRF validation—there are many. However, one system was designed from the very beginning with CRF validation in mind.
CRF validation is a multi-step process. Those steps include:
- Test script generation
- CRF data entry
- Edit check execution
- CRF insert
- CRF update
- Data validity
- Validation reporting
- CRF validated tag
Each of these steps needs to document each event that occurs. TrialKit does all this:
Test Script Generation
Prior to validating a CRF, test data must be created. In TrialKit, we query the database of each CRF and look for a variety of things, including fields, edit checks, numeric ranges and coded fields. TrialKit offers the user the ability to create as many test records as they choose. When the test data is generated, the process is automatic and happens in seconds. The actual data cycles through all the various possible combinations of data. This assures a thorough test. The more test records that are run through the system the more complete the test. In addition, TrialKit allows the user to edit any test record and change any data, this further increases the effectiveness of the test.
CRF Data Entry
This is the key. TrialKit loads the actual case report form. It then reads through the test script and pulls each piece of data. It then populates the actual CRF control on the form with the piece of test data. This exactly emulates the behavior of the actual user. This is the only way to truly test the CRF environment.
Edit Check Execution
After entering the entire test record, TrialKit then submits the form exactly the same way the user would. This mimics the exact process of data cleansing through edit checks. Each time an edit check is fired, TrialKit logs the event.
CRF Insert
After cleansing the data, TrialKit then submits the form. The form is submitted as a new record and the data is moved to the database. Each time a user submits a form in TrialKit, that form’s data is always saved. We do not permit annoying messages that force a user to take action prior to the data moving to the database. This first save is done as an insert, exactly the same way a user would enter a new form.
CRF Update
After inserting the record, TrialKit then resubmits the form. This time the form is being updated. This again emulates the exact action a user would take when updating an existing CRF.
Data Validity
After both the insert and update processes, the data is then checked. TrialKit goes through each field and checks to be sure that the data in the database matches the data in the test script. If it does, the field is tagged as validated. If not the field is tagged as in error.
Validation Reporting
At the end of the process, a comprehensive report is available to the user. This report can be filtered by any criteria. For example, to test that a given edit check fired correctly, search by the edit check error message. The report will display all records that fired the edit check and reported an error. The report also allows for comprehensive searching and filtering on any other event. A 100-record CRF validation usually produces a 3,000 line report. With searching and filtering, the user can easily check every component of a CRF. In addition, the report allows the user to drill directly into the saved record which is displayed with data and error messages. This report can then be exported to Excel. However, it always exists in the database awaiting a potential audit.
CRF Validated Tag
When the user has completed reviewing the results of the validation, they can tag the form as validated. That tag follows the form wherever it goes, including being exported to the form library and imported into subsequent studies for reuse. Each tool that displays and accesses a CRF for design, shows the current validation status of the form. If a validated form is changed, the validated tag is cleared.
Summary
Are you sure that if an auditor shows up at your site and checks your CRFs for validation, that they will pass? The above process virtually guarantees it. Large CRFs can be validated in as little as an hour. Trying to perform this process manually would take multiple FTEs weeks if not months. In our last post, we asked the question: has a CRF ever been truly validated? The answer using TrialKit is an emphatic YES! To learn more about CRF validation in TrialKit, get in touch with us today.
