Articles tagged with 'Edit Checks'

Image

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

Times
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:

https://attendee.gotowebinar.com/register/8506460051787951873

or by clicking the link below:

Register for the TrialGrid Edit Check Webinar

#3b Edit Checks : Wednesday 24th May

Times
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:

https://attendee.gotowebinar.com/register/2622995321791138817

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.

TypicalEditChecksByType

A graph of the costs is also enlightening:

OverallCost1

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:

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

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:

1
AETERM.IsNotAscii

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%

OverallCost2

Who wouldn't want that?

Image

Have you hit the Edit Check Wall?

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:

TheWall1

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:

TheWall2

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