With more than 100 Diagnostic checks (and more planned) TrialGrid is able to identify many quality, standards and best practice issues in Rave Study Builds. But if the Diagnostics identify 100 issues, which should you work on first? What should get priority?

As with so many things, it depends. Not all TrialGrid Diagnostics are appropriate for every study. For example, there are a number of Diagnostics which relate to Rave EDC (formerly RaveX). If you are using Rave EDC for your study then findings from these Diagnostics are high priority. If you are using Rave Classic then findings from these Diagnostics are either of low priority or the Diagnostic should not be used at all.

This week we released a new feature for Diagnostics which allow an Importance of High, Medium or Low to be assigned to Diagnostics used in your Project. So for Project 1 a Diagnostic might be High importance while in Project 2 the same Diagnostic is of Medium or Low importance.

Any Diagnostic which is Active for a Project can now have its importance set:

This importance level is also exported in Diagnostic results. Very useful in the Excel exports to allow filtering of results:

And in the Diagnostic results themselves you can also filter by Importance level:

All Diagnostics have a default of "Medium" importance. Adjust this as required for your individual Project.

We hope these features help our customers who are communicating Diagnostic results back to study build teams for action.

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!