Building Edit Checks is one of the most time-consuming activities during study builds.
In this post I'll show how much TrialGrid can speed up Edit Check programming, using three example Edit Checks of increasing length and complexity.

Here's a comparison of the time taken to build these Edit Checks in TrialGrid and in Medidata Rave (shorter is better!):

As you can see it is consistently faster in TrialGrid. To measure the time and effort I used a stopwatch app and an app which records how many mouse clicks and key presses you've made. As we'll see, building Edit Checks in Rave can involve a LOT of mouse clicks.

1. Simple Edit Check

Many Edit Checks are relatively straightforward, looking for inconsistencies in data entry between two Fields, and then raising a query, as in this example:

1
2
3
4

On form AE, if AEONGO is checked and AEENDAT has a value, then:
    open a query with message "End Date is provided, but Ongoing is also checked"
    on field AEONGO
    to Marking group "Site from System"

TrialGrid

Here's the TrialGrid Edit Check editor with the apps collecting timings and metrics on the right:

Note: when building these Edit Checks in both TrialGrid and Rave I copy-pasted the query text from the specification document, as would probably happen in practice, so the key presses don't include typing the query message.

We can see a readable description of the Edit Check at the top, then 2 versions of the check logic; on the left-hand side we see the TrialGrid Clinical Query Language version and on the right-hand side we see the Rave 'quickedit' format. When creating an Edit Check in TrialGrid we type in the CQL expression and the quickedit version is automatically created. We provide lots of autocomplete support to help choose Fields, Forms and other objects, and highlight any errors:

If a Field is unique to one Form then its not necessary to specify the Form - the system knows that Field 'AEONGO' is on the AE Form, and only on that Form, so we don't need to enter it. If we need to specify Forms, Folders, etc we can do so, as in the next example Edit Check.

Medidata Rave

In Medidata Rave we have to think about Edit Checks in postfix logic - this Edit Check has 6 check steps in postfix:

So we can see that creating this Edit Check in TrialGrid takes 29 seconds compared with 76 seconds in Rave - more than twice as fast. Rave needs almost 4 times as many mouse clicks. TrialGrid requires more key presses, but typing is faster than the repetitive mouse activity for Rave.

2. Medium Edit Check

Next I took Edit Checks with more complex specifications, like this one, which is checking that vitals signs have been measured within a 4 hour time window after drug administration:

1
2
3
4

In CYCLE2, check that the 2nd vitals signs measurements where taken 4 hours after drug administration (+/- 30 minutes).  If not:
    open a query with message "Vital signs were not recorded within 4 hours (+/- 30 minutes) of drug administration"
    on field VSDTC in form VS1
    to Marking group "Site from System", requires response and requires manual close

TrialGrid

Above we can see how Clinical Query Language lets you specify Folders, Forms and record positions as well as the Fields.

Rave

For this Edit Check Rave needs 21 postfix steps:

TrialGrid makes more use of the keyboard, but the Rave editor takes more than 2 minutes longer because most mouse clicks trigger a request back to the Rave web server to refresh the page.

3. Long Edit Check

Some Edit Checks are considerably longer and involve many Fields, for example checking that inclusion and exclusion criteria have been met. Sometimes this is done with a simple yes/no question asking if all criteria have been met, but sometimes each inclusion and exclusion criterion is a separate question. In the following example there are 10 inclusion questions and 28 exclusions.

The specification for this check can be quite simple:

1
2
3
4

If the patient is eligible and any inclusion or exclusion criteria is not met
    open a query with message "If at least one Inclusion/Exclusion criteria is not met, "Is the patient eligible for inclusion on this study?" should be No. Please reconcile"
    on field ELIGIBLE in form ELIGCRIT
    to Marking group "Site from System", requires response and requires manual close

TrialGrid

In TrialGrid Clinical Query Language we can use the 'any' function and list the Fields:

Rave

In Rave we have to create 159 postfix checksteps. Unsurprisingly this takes a long time and its difficult to maintain concentration during the repetitive point-and-click for each step; I'd spent 45 minutes and more than 800 mouse clicks when I lost concentration for a second and accidentally clicked on the reset button on the stopwatch app:

At this point I'd completed about 130 out of 159 check steps and I didn't have the mental strength to redo the exercise since it had already taken almost 10 times longer than in TrialGrid.

For those of you familiar with Rave Edit Checks, you might also have been thinking that using the 'quickedit' format would be quicker. In Rave 'quickedit' the checksteps are presented in a raw format, delimited by a pipe '|' character. You can edit this:

Editing using 'quickedit' is faster than the point-and-click Rave editor, but still almost 2 times slower than in TrialGrid.

Summary

Here's the comparison again of the time taken to build these example Edit Checks in Rave and TrialGrid:

Clearly its more efficient to create an Edit Check in TrialGrid, but the difference for each Edit Check ranges from just under a minute for simple checks to four minutes for longer ones. What does this add up to, how much time can be saved for a whole study? I'll answer that question in my next blog post...