Today we released Diagnostic #101. Reaching the 100 Diagnostic milestone seems a good time to think back on what we have achieved so far.

Two years ago when we started building our first Diagnostic we knew that every quality check we automated was one less check that had to be performed manually. Today organizations are putting our Diagnostics at the heart of their quality practices, freeing their Rave study build experts to do more valuable work than manual review.

Originally we called our Diagnostics "Linters". As you know, in everyday life lint is the fluff that you find in your pockets and air filters. In software development it means the bugs, stylistic errors and "things that just don't look right" in code. Software Linters identify and help you remove this type of lint and improve your product.

The term "Linter" didn't mean much to our target users of Study Builders and Data Managers and honestly nobody is much worried that their study contains a bit too much fluff so we went with the term "Diagnostic" instead. Just as in real life, Diagnostic findings don't all have equal weight. A spelling error in your question text is embarrassing but an error that requires a Migration to fix is going to be expensive - but they can be equally difficult to spot.

Here's an example Rave Edit Check as shown in Rave Architect. See the logical error?

If you spotted it immediately, good for you but you were primed that there was a problem there. Would you have spotted it in manual review of 1,000 Edit Checks? If you didn't see it, don't feel too bad. Here's another example highlighting a similar problem:

One of these is logically correct, the other doesn't make a lot of sense but Rave is quite permissive in what it allows for Constant values and their formats. For the record "Y" is not a valid Data Format for the value "$1" and "Deferred" is not a valid Data Format for the value "$20", these should be Y ($1) and Deferred ($20).

Diagnostic 101 finds these kinds of errors in Edit Checks and Derivations - avoiding a costly Migration. Yes, these kinds of problems should be found in testing but we've seen all kinds of acceptable (but invalid) combinations and we suspect some of these have made it into production.

As with all new Diagnostics, there is no incremental cost to our customers for these new features and Diagnostic 101 won't be our last. Watch this space!

Next week we're attending the Medidata Next conference in New York and we're looking forward to meeting up with friends old and new, customers and past colleagues. In the run up to the conference we're working on major new features but that doesn't mean we're neglecting existing functionality.

This week we've been spending more quality time with Diagnostics.

New Diagnostics

Our policy has always been that if a Diagnostic is suggested to us by a customer and we think it makes sense for the community we'll add it to our catalog at no cost. A customer contacted us to suggest a diagnostic for Static Values in Edit Check steps. As it stands, Rave believes you know what you are doing and will allow you to do this:

Here I'm defining a Static Value as "NONE" with a format of $3. That's 3 characters which means Rave will interpret this value as "NON". Something is wrong here. Either the value should be "NON" or the format should be $4 so that Rave will see "NONE". Diagnostic 86 identifies this situation and it happens more often than you would expect.

Meanwhile another customer was also in touch to suggest a new diagnostic for Form level Signature Is Required. The issue is that if a form is set as Signature Required = No (unchecked) but there are Fields which Participate in Signature on the Form then Fields may not be able to be locked because they have not been signed. Diagnostic 85 identifies this situation. Conversely, you can have a Form which is Signature Required = Yes (checked) but there are no Fields on the Form which actually participate in Signature. Probably you don't need to sign a page where there are no Fields which can be signed so Diagnostic 87 identifies this state of affairs.

Previously, this customer had suggested diagnostics for Data Entry and Non-Data Entry Fields. For example, a Field which cannot be data entered by a user should not have an OpenQuery action on it because the user would not be able to make changes to the Field to action that query. Similarly, a field where you expect data entry by Investigator users should be visible. You might also want to make sure these Fields are verified and require data entry. In all, these Data-Entry and Non-Data Entry diagnostics bring us to 94 diagnostics in total.

Updates to existing Diagnostics

Diagnostic 71 is designed to find Required Fields which are view/entry restricted from Site Users "Site Users" means Investigators, Study Coordinators and other roles who are expected to provide the values for these required fields. To assist with this diagnostic TrialGrid has a flag in its URL configuration for EDC roles which determines if an EDC role represents a "Site User". This is useful but not flexible enough for some users so this week we added a new feature and updated Diagnostic 71 with a selector for role names and exclusions.

Entering or selecting Role names in this setting will override the "Site User" flag in the configuration for this diagnostic. Note the color coding of Role names. If a name appears in the configuration it appears in Blue, in Orange if it is not in the configuration. This can be important when you are copying diagnostics settings between Projects in different URLs.

New Diagnostic Features

We recently heard from a group evaluating TrialGrid that a table of contents and bookmarking in the PDF diagnostic report would be a useful feature, especially where there are a lot of findings. We agreed and from now on all PDF diagnostic reports will include a Table of Contents page with hyperlinks to the results of each diagnostic from the PDF outline view and from the page numbers in the Table.

But sometimes reviewing diagnostic results would be easier if you had them in an easily sortable and filterable format like a spreadsheet. To support that we added a new report to the diagnostic process - an Excel spreadsheet of the results:

Summary

Last week we added the Search Feature to quickly find objects across all your study designs. This week it has been new and updated diagnostics and new diagnostic features. The TrialGrid product continues to improve, in large part driven by customer feedback so a big thank you to everyone who has contributed ideas.

Next week we'll be in New York for the Medidata Next conference and we look forward to seeing you there!

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