Edit Checks (improved QuickEdit)

Our first release of TrialGrid introduced the Clinical Query Language (CQL). CQL allows you to write edit checks in an infix format (2 + 2 = 4) instead of the postfix format Medidata Rave uses ( 2 2 + 4 =). In our tests using CQL to build edit checks is much more efficient than the point-and-click alternative in Rave Architect and is easier to learn.

But what about Clinical Programmers with years of Rave study build experience? These users almost exclusively use the Rave QuickEdit format for edit checks and after years of practice think in postfix. What could we do for them?

Rave Architect has a very simple editor for QuickEdit, just a plain text area with check attributes, steps and actions all presented as pipe-separated lines. Despite its simplicity it provides a lot of power - allowing users to cut and paste check steps and actions and create new checks.

The TrialGrid equivalent editor has the same functionality and adds auto-complete features to allow the selection of action types, step types and folders / forms / field and custom function names:

The QuickEdit text can be cut and pasted between Rave and TrialGrid, making it very easy to take advantage of the advanced features of TrialGrid when in the edit/publish/test/edit cycle of working with edit checks.

The CQL format is still there and users can switch between the QuickEdit, CQL and Description tabs to see the check displayed in the format of their choice. Edits made to a check in the CQL tab are reflected in the QuickEdit tab and vice-versa.

Overall we think experienced QuickEdit users are going to feel right at home in the TrialGrid check editor.

QuickEdit for Derivations

Useful as QuickEdit is, Rave Architect doesn't offer a QuickEdit format for Derivations. TrialGrid now provides this with all the same auto-complete benefits.

This format can't be cut and pasted into Rave but it can still be a convenient format to edit Derivations if you are familiar with QuickEdit for Edit Checks.

Spreadsheet editing for Fields in Forms

The TrialGrid Form editor offers a lot of features:

• Drag and drop re-ordering of fields
• Form preview for Rave Classic and Rave EDC (formerly RaveX)
• Form preview by EDC Role (e.g. see a Form as a user with that Role would)
• Cloning Fields within the Form
• Copy and paste for View and Entry restrictions

These are all useful but nothing beats the convenience of editing an Architect Loader Spreadsheet (ALS) when you want to do bulk-changes to the Fields in a Form.

The downsides of spreadsheet editing are the need to import/export the ALS and taking care to make sure the changes are valid.

TrialGrid now allows customized grid-views of Form Fields to be defined per TrialGrid role. This means that you can define an editing grid for your Standards Management staff separate to your Study Builders or Data Managers. These views can include read-only columns, default values for new Fields and are especially useful when combined with Custom Field Properties (Field Metadata).

In the screenshot we see the Form editor with several custom sheets defined (Review Summary, Standards Review, Core Items) with the Standards Review tab selected. The selected column, "Standard Field Number" is a custom property added to Fields in the TrialGrid system. Note that this custom attribute has the same look and feel as the "normal" attributes of the Fields such as VariableOID, Field Name, Is Log etc.

Multiple editing grids can be defined for a TrialGrid role and each can have a different set of columns shown.

We think this grid editor provides the convenience of a spreadsheet with the validation and control of the normal Form editor.

Uppercasing Data Dictionary Values

The Data Dictionary editor in TrialGrid also uses a spreadsheet-like grid which allows cut and paste, sorting by column and drag-to-reorder but we recently the ability to uppercase text in selected cells:

This is a small feature, but very convenient when you need it.

Wrapping up

This is just a sample of the features added in the last few months. Look out for some future posts about enhancements to our document generation and automated test features!

Summer is usually a quiet time in our industry with people taking vacations but at TrialGrid we're busier than ever working with our clients to get the most from Medidata Rave and the TrialGrid application.

Medidata Webinar / Fix-All Diagnostics

The good news is we are continuing to make improvements and release new features. This month, in a joint Webinar with Medidata, we presented our Diagnostic "Fix All" functionality. This is particularly important to Medidata Rave customers as they adopt Rave 2018.1.0 or above. In these new versions of Rave, Medidata has taken a best practice (always set RecordPosition=0 for Standard Fields) and made it a requirement with the result that many ongoing Rave studies will need to be updated.

Long-term this change will be a great benefit to Rave users because not adhering to this best practice can cause edit checks to not work as expected - but in the short term it will be extra work. We know of one group that spent two
days of effort updating a single study. In the webinar we showcased our Diagnostic for RecordPosition and its automatic "Fix All" capability. Using this Diagnostic could have resolved this issue in 10 minutes - a saving of 15 hours and 50 minutes or 96% less effort.

Updates to CQL

Two years ago we introduced CQL, the Clinical Query Language, an alternative way of specifying Edit Checks. Rave Architect provides two ways of authoring Edit Checks: a point-and-click Edit Check builder and the powerful (but cryptic) QuickEdit text format. Both are based on postfix notation which can be difficult to learn. Here's a simple mathematical expression in postfix format:

2 2 + 4 =

CQL provides a more familiar infix notation:

2 + 2 = 4

Last week we upgraded our Edit Check editor with a new version of CQL and even better auto-complete helpers. This makes writing Edit Checks even faster.

Here's me starting an edit check. Notice how the editor offers me a listing of Folders or the Folder wildcard:

I choose the wildcard option (any folder) and now I'm choosing a Form:

I choose the AE form and now I'm choosing the Field:

Notice that TrialGrid is giving you much more here than just the Field OID that Rave requires for an Edit Check. We're also seeing the Field Label, whether it is a log Field, it's data type and any associated Data Dictionary. This extra context makes it much easier to select the correct Field without having to look up an annotate or have the Form editor open.

If I select a Field which has an associated dictionary and I ask for the CodedValue then typing a # gives me a listing of all the possible values from that Dictionary:

In each of these helper listings, typing a few more characters will filter the list of choices further. And this brings me to possibly my favorite feature of this upgraded editor, the Field search.

Field Search

Let's say you have the specification for a simple Edit Check:

AE Start Date cannot be later than AE End Date

You have to translate that into something you can create as an Edit Check:

AE Folder, AE Form, AESTDAT > AE Folder, AE Form, AEENDAT

Which means that you have to know the OID of the AE Folder and the AE Form and the Field OIDs for these Fields. In the new CQL editor you can simply type:

..End

To see a listing of all the Fields which contain (in their Question text or OID) the word "End":

Writing Edit Checks with CQL is fast, really fast but how does it compare to the Rave Edit Check point-and-click builder and to QuickEdit?

*Note that TrialGrid shows QuickEdit and CQL side-by-side and editing in one automatically updates the other so if you're productive with QuickEdit those skills are directly transferable to TrialGrid.

Medidata Rave is the market leading EDC system. The TrialGrid application is designed to help Study Builders make the most of Medidata Rave by speeding study development, managing library compliance and automating quality checks. If you want to see what TrialGrid can do for your team, Contact us

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