Articles tagged with 'Edit Checks'

Faster Rave Edit Check Building and Diagnostic Fixes

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:

Folder Wildcard

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

Form Choice

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

Field Choice

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:

Dictionary Value

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:


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?

CQL Point And Click QuickEdit*
Style Infix Postfix Postfix
Speed Fast Slow Fast
Select OIDs Yes Yes No
Field Search Yes No No
Dictionary Search Yes No No
Field Context Yes No No
Auto set RecordPosition for standard Fields Yes No No

*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


Edit Check Webinar

Following the success of our first two webinars on Study Build Diagnostics and Standards Compliance (contact us if you'd like to view the recordings), we're adding a new webinar on Edit Checks.

Using TrialGrid you can write Edit Checks without having to think in 'postfix'. If you've ever had to think hard to work out some postfix logic like this:

1 1 + 2 = 4 3 - 1 = OR

then we think you'll like our alternative:

1 + 1 = 2 OR 4 - 3 = 1

We'll also be looking at how you can create re-usable Custom Function Templates, so that Edit Check programmers can make use of advanced custom function behaviour without having to write (or even see) and C# code.

And we'll explore how you can quickly test your Edit Check logic and build up a library of test cases to ensure that your Edit Checks are functioning as expected.

Someone said to us recently:

It's like you've been reading my mind!

We don't actually read minds but we have been in the eClinical industry for more than 20 years and around Medidata Rave for more than a decade so we know the process challenges of building Medidata Rave studies and we are building TrialGrid to address those challenges head on.

Join us to see how.

We will hold 2 sessions of the Edit Check webinar to accommodate different time zones:

#3a Edit Checks : Wednesday 24th May

8:00 AM - 8:30 AM BST 9:00 AM - 9:30 AM CET 12:30 PM - 1:00 PM IST 3:00 PM - 3:30 PM CST

Register for this free webinar:

or by clicking the link below:

Register for the TrialGrid Edit Check Webinar

#3b Edit Checks : Wednesday 24th May

5:00 PM - 5:30 PM BST 6:00 PM - 6:30 PM CET 12:00 PM - 12:30 PM EDT 9:00 AM - 9:30 AM PDT

Register for this free webinar:

or by clicking the link below:

Register for the TrialGrid Edit Check Webinar

We look forward to hosting you in these webinars. If you have any questions please contact us.

Save 20-30% on Edit Check Builds

Andrew and I are on a mission to reduce the cost and effort of building Rave studies by 50%. It's an ambitious goal but nothing really worth doing is easy.

One of the most costly areas of study build is the writing and testing of Edit Checks. So lets take a look at Edit Checks and where the costs are.

Three levels of Edit Check logic

In the previous post we looked at the 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. Field edit checks are so easy we're giving these a value of $1 for all the checks set on a field (Is Required, Simple Numeric Ranges, Cannot be a Future date etc). That doesn't mean they literally cost $1 to include in your study. Depending on how you build, staffing costs, how luxurious your offices are etc your price will vary. $1 is just a good baseline figure to compare other costs against.

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 more expensive to create than a simple Field Check. You also need a more skilled study builder to write a Configured check. So let's say, $10, on average, to create a configured edit check. Again, $10 is not a literal cost, it's just a comparison.

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. We'll say, conservatively, $50 for the development of a Custom Function. Once again $50 is just a relative cost to the $1 field check since the average Custom Function is at least 50x more complex than a field check.

Study Averages

There is no such thing as an average study the size and complexity of a study depends on it's Phase, Therapeutic Area and many other variables. But we have seen a lot of trials over the years so we'll illustrate costs with what we think is fairly typical: A study with around 1,000 data entry fields, 1,000 Configured Edit Checks and 100 Custom Functions.

Given those numbers we can draw a graph that shows how the Edit Checks in our study stack up.


A graph of the costs is also enlightening:


The bulk of the costs is in the Configured Edit Checks but those 100 Custom Functions account for 30% of the cost.

How to reduce the cost?

Field Edits are so easy there is little that could be done to make creating them more efficient but there is scope for improvement in Configured Edits and Custom Functions. How could we reduce the costs of those?

At TrialGrid we're attacking this challenge with CQL, the Clinical Query Language. CQL is an infix format for Rave Configured Edit Checks which is easy and fast to write and which has built-in testing facilities.

An Edit Check with CQL (infix) logic like:

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

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


CQL also includes a set of built-in functions that 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. Using it in a CQL expression is easy:


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.

We (conservatively) estimate that CQL can save a Clinical Programmer or Data Manager 50% of the effort of writing Configured Edit Checks and that the generation of Custom Functions will reduce the number of Custom Functions that have to be hand-written by at least 10%. When we plug these numbers into our costings for our example study the price drops to $10,500 from $16,000 a saving of 34%


Who wouldn't want that?