When demonstrating TrialGrid we often have suggestions for new Diagnostics we could add to further help ensure that Rave study builds avoid common mistakes and conform to best practices.
Recently we've added 10 new Diagnostics, bringing the total available up to 64. Here are some highlights from the new batch of Diagnostics:

Edit Check Diagnostics

• Matching Check Steps and Actions: if the Folder, Form and Field specified in a Check Action doesn't have a 'matching' Check Step, then the Edit Check might not behave as expected. This Diagnostic identifies Edit Checks where a Check Action doesn't have a matching Check Step.

• Field Record Positions: a new Diagnostic flags any Edit Checks and Derivations which have a Standard Field without Record Position of 0 or Log Fields which do have Record Position of 0. Both of these conditions might lead to the Edit Check not firing when expected.

• Coded Value not in Data Dictionary: a very common pattern in Edit Checks is to compare the Coded Value of a Field against a value in the Field's Data Dictionary. For example (in CQL):

  

  However Rave Architect doesn't enforce that the static value ('Y') in the example above exists in the Data Dictionary associated with the Field, so its possible to create Edit Checks which can never fire. QC and testing should uncover these, but a quicker and faster way to avoid these errors is to run the TrialGrid Diagnostic:

  

  and then to use the TrialGrid Edit Check editor to select a valid entry from the Data Dictionary:

  

• Dynamic Search Lists on multiple Fields: A Dynamic Search List should not be used on multiple Fields sharing the same Variable. If a DSL is applied to multiple Fields, Rave will refuse to publish the CRF version.

RaveX upgrade compatibility

• IsPresent Check Action: Rave 2016.4 introduced a new Check Action 'IsPresent' which can be used in place of an 'always true' Custom Function. However RaveX requires use of this new Check Action. Our Diagnostic lists Check Actions using an 'always true' style Custom Function and can automatically replace them with the new Check Action.

• Custom Function blacklist: RaveX will blacklist various methods used in C# Custom Function code to prevent security issues in its single-instance multi-tenant environment. This Diagnostic will search through Custom Function code to identify any which might need to be modified.

Study build best practices

• Unused objects: if any Data or Unit Dictionaries or Custom Functions are not used in the study this might higlight an issue with the study build. If they're not needed they can be quickly removed from this Diagnostic.

• Empty objects: similarly, this new Diagnostic flags up any Dictionaries with no Entries, Custom Functions with no code or Forms with no Fields

• Default Value not in Data Dictionary: if a Field has a Default value and a Data Dictionary, then the Default value should exist in the Data Dictionary. This Diagnostic will find any defaults which are not in the associated Data Dictionary.

TrialGrid Diagnostics take a time-consuming activity that requires expert knowledge and transform it into a few clicks to get assurance of conformance to best practice and a full PDF report output to document the results. With more than 60 Diagnostics (and more being added all the time), using TrialGrid could save your Study Builders hundreds of hours of manual effort.

Interested? You can read more about TrialGrid features on our tour page

Using Standard Libraries is an excellent way to achieve study build efficiency but within a study some variation from a Therapeutic Area or Global Standard is expected or even encouraged. So how do you, as a Customer of a study build team, get assurance that what has been delivered to you matches the appropriate standard and that all deviations have been identified, explained and approved?

Some organizations manage this by using difference reports to identify changes between a standards Draft and the Draft as built. These reports will be run on some interval, usually toward the end of the study build process as a hand-off check. But the later you find out that a non-standard Form, Edit Check or Custom Function has been used in the study build the more expensive it will be to correct.

At TrialGrid we want to bring these kinds of checks into the process earlier and make the workflow of standard library compliance and approval an interactive one.

Make a Standard Libary Project

In TrialGrid, any Project can Contain Standard Library Drafts, it's just a checkbox for the Project.

Then any Draft within that Project can be selected as a Standard Library.

This makes it simple to create a Standard Library in TrialGrid, just upload the Architect Loader Spreadsheet of the Draft you want to be a library into a Library Project.

TrialGrid Standard Libraries are Hierarchical

Standard Libraries are generally arranged in a parent-child-grandchild structure. For example, there could be a Core Standard Library which contains Forms and other objects used in all kinds of trials. A descendant of the Core Library could be a Therapeutic Area (TA) Library with new Forms and Dictionaries used only in that TA and with overridden properties of some Core objects (such as additions to an AE or CM Form). Descending from the TA Library could be a Program specific Library.. and so on. This gives you a tree of standards with your Core standard at the root and ever more specific versions branching from it. We call one path through that tree, a "Compliance Chain".

At one end of the chain is your Core Standard Library and at the other end is your particular Study build and there can be any number of Standard Libraries as links in between.

This chain is important when we want to check compliance because if we want to be sure that, say, the AE form is compliant we check the first Standards Parent in the chain. If the AE form is not found there we see if that Standards Draft has a parent and if so we look for the Form in that Draft stopping when we find it or when we reach the end of the chain.

Instant Compliance Checking

Whenever you import or make any change to a Draft object, TrialGrid calculates a "fingerprint" for that object. It then can compare this fingerprint to objects of the same name in the Standards Chain and tell you if they match, are different or are not found at all.

One of the benefits of this approach is that it allows you to run "what if" scenarios and perform impact assessments very quickly. Switch the Standard Library for the Draft and you can immediately see the level of conformance to a different standard. Great for checking impact of new Standard Library versions.

A particular benefit for Study Builders is that the fingerprint of a Form or other object is the same regardless of its source. That means you can copy objects from an existing study, TrialGrid doesn't care where they came from, only that they match or don't match what is in the Standard.

Comparing Objects

Comparing Objects can be done right from the Object Listing. The color-coded line-by-line comparison shows every change.

Being able to compare the objects side by side makes it easier to explain why there has been a deviation from the standard.

Workflow

The workflow permits a Study Builder (or anyone with Standards / Request Approval permission) to request Approval and a Standards Manager to Accept or Deny the request. If an object is changed after an Approval is granted it is reset and will again require Approval.

Every change in the workflow is tracked with comments and a full audit trail so that you can see who Approved, when.

Overview

The Compliance dashboard (with associated PDF detail report) shows a breakdown of which objects are Compliant (a Match found in the Standard), Different or Not Found and of those which have an Approval Request which are Approved and which Denied.

In summary, TrialGrid's Standards Compliance features are easy to use and provide instant feedback on the compliance of your study Build to the Standard Library.

In the previous post we introducted Diagnostics our tools to automate checking of study builds against best practices, making it quick and easy to identify, fix and document issues.

One best practice which should always be followed for Rave study builds is to check that words on forms, query messages and other text strings are spelled correctly. This can't be done, other than by manual inspection, in Rave at all, and isn't easy to do in an exported spreadsheet. eCRFs contain lots of medical terms and can contain HTML tags embedded in the strings, both of which can pose challenges.

Examples of misspellings we've found include:

• narcostic
• recoreded
• procotol
• hepatobilary

Finding and correcting mistakes like these isn't easy without a tool designed to help. The best practice recommendation is to download the Architect Loader Spreadsheet for the Draft, open it in Microsoft Excel and use the spellcheck function to review the appropriate columns.

The TrialGrid Way

The TrialGrid spelling Diagnostic checks all the text strings in a study against a dictionary of English words and a medical dictionary. Possible misspellings are highlighted so it's easy to review:

Fixing the spelling mistake is as easy as clicking the 'Fix' button. Any results flagged by the TrialGrid spell checker which are actually correct can be documented, so that there's an audit trail of when the Diagnostic was run, what issues were found and what action taken.

TrialGrid Diagnostics take a time-consuming activity that requires expert knowledge and transform it into a few clicks to get assurance of conformance to best practice and a full PDF report output to document the results. With more than 50 Diagnostics (and more being added all the time), using TrialGrid could save your Study Builders hundreds of hours of manual effort.

Interested? You can read more about TrialGrid features on our tour page