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

Anyone who participates in endurance sports such as cycling or running will have heard of The Wall. It is the point at which the athlete exhausts their glycogen stores, resulting in a feeling of fatigue, the inability to go on.

As a Data Manager in a Study Builder role the chances are that you have experienced something similar, the point at which the logic for an edit check becomes too complex and you have to fall back on a Custom Function. This is the Edit Check complexity "Wall."

Three levels of Edit Check logic

Essentially Rave has three levels of edit check logic:

• Field Checks (Range, IsRequired, QueryFutureDate etc)
• Configured Checks (Rave Edit Checks)
• Custom Functions

Field Checks can be set up with a few clicks and some data entry for expected high and low ranges. They are extremely fast and easy to set up and require little or no testing since they are features of the validated Rave system.

Configured Checks are written using Rave's Edit Check editor which uses a postfix notation (1 1 + 2 isequalto). Rave Edit Checks are flexible and very functional but every Edit Check that is written has to be specified, written and tested making it an order of magnitude more expensive to create than a Field Check. The learning curve for Configured Checks is quite steep since most of us were taught infix notation in school (1 + 1 == 2).

Lastly we have Custom Functions. These are written in C#, VB.NET or SQL and require some level of true programming expertise. Custom Functions are the fallback, the special tool in the toolbox for the truly complex situations. Besides the difficulty of hiring (and keeping) good programmers in the current technical market, Custom Functions have to be specified, reviewed for coding standards and performance impact as well as tested. Because of the level of skill required we want to write as few Custom Functions as possible.

Costs and learning curves

A graph of the learning curves for the different Edit Check logic types might look like this:

As we can see from the image, Field Checks have a very fast learning curve but they don't get you to a very high level of complexity. Learning Configured checks can be done quite quickly for the basics but mastery takes longer and eventually you reach the Wall where the complexity of a specified check means that you will need to use a Custom Function. We are all familiar with the most simple Custom Function:

1

return true;

But doing anything more complicated takes technical training.

Mitigation

The Wall represents the transition from Configured Checks to those requiring Custom Functions. We know that writing Custom Functions is expensive so we want to reduce reliance on them and so move the Wall further away. Some strategies which can be used to do this are:

• Have standard/parameterized Custom Functions. For instance, instead of writing a custom function to compare specific date and time values, create a parameterized function which can be used for any date and time comparisons. These types of standard functions don't need the same level of validation as a bespoke Custom Function.

• Analyse the Edit Checks you have written in the past and the queries that they generated. Research on Edit Check complexity in Medidata Rave studies found that the most complex edit checks were the ones least likely to fire. If an Edit Check requires logic so complex that it requires a bespoke Custom Function you may be better off using a manual listing or running the Edit Check as part of other back-end checks.

What we are doing

At TrialGrid we're attacking this challenge with CQL, our Clinical Query Language. CQL is an infix format for Rave Configured Edit Checks.

An Edit Check with CQL (infix) logic like:

1

A > B AND (C == D OR C == E)

would be translated into a Rave Edit Check (postfix) logic like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

 A
 B
 ISGREATERTHAN
 C
 D
 ISEQUALTO
 C
 E
 ISEQUALTO
 OR
 AND

In fact the translation works both ways, Rave Edit Checks can be instantly translated into CQL and CQL can be translated instantly back into Rave Edit Checks. There is no lock-in here, CQL translates into pure-Rave Edit Checks. Since infix notation is what we all learned in school, CQL is much easier to learn.

But we can do more. CQL includes a set of built-in functions that look like Rave Edit Check functions (IsEqualTo, IsPresent etc) but which automatically generate Custom Functions for you.

For example, We have been asked for an Edit Check that determines if a text field contains non-ASCII characters. Providing a standard Custom Function to do that is easy enough but we go one further and integrate it into CQL.

1

AETERM.IsNotAscii

to the user this looks no more complex than the standard Rave IsNotEmpty test:

1

AETERM.IsNotEmpty

The TrialGrid application takes care of generating the Custom Function. You'll still need some bespoke Custom Functions but fewer and fewer as time goes on and we build more into CQL.

Why wait?

But why wait? TrialGrid allows you to create these function templates yourself, extending CQL and your Rave Edit Checks with your own private functions that become part of the CQL language. Want to know if AETERM.IsSigned? or AETERM.HasOpenQuery? Add them to CQL and give your Custom Function programmers more interesting work to do.

Configuration, not Programming

By using TrialGrid, Edit Checks that would previously have required Custom Functions can now be done by configuration. Our graph looks more like:

The Wall is moved further away and the learning curve is made much flatter. This is more than just a nice to have, it means more productive Study Build staff and reduced costs. Another step on our journey to reduce the time and effort of Study Build by 50%.

Interested in improving your Rave study build efficiency? Contact us to find out how TrialGrid can help.

Brick wall image by FWStudio