Articles tagged with 'TrialGrid'

Standards Compliance Improvements

This week we rolled out improvements to our Standards Compliance functionality with the goal of making it easier to see where Draft objects have been copied from and what library and object they are being compared against.

Sidebar Compliance information for all objects

The editors for Draft Objects in TrialGrid have a sidebar that shows important information:

  • Change history
  • Comments/Discussion about this object
  • Labels associated with this object
  • Tickets (tasks) associated with this object


Previously this sidebar also included information about where an object was copied from and its standards compliance state - but this was not consistent for all object types. The editors were updated to ensure that all now contain:

  • Copied from information (if the object was copied from another Draft in TrialGrid)
  • Standards Compliance information

Standards Compliance for Test Cases

We added Standards Compliance for Test Cases. These can now be copied from a library and compared against it just like Forms, Edit Checks etc. This means you can store Tests for your Edit Checks, Forms and other objects in a Library and track changes to them.

Where did this Object come from?

As a Study Builder you sometimes you want to copy an object from a Library but it is also very common to copy an object from a previous study. Previously, TrialGrid would remember which Draft an object was copied from and always compare back to that object if the source was a Draft in a Standard library. This could be confusing so we now make it clear where the object came from and whether it came from a Library or just an ordinary Draft.

In this image you can see that our object was copied from an object called "CM" in the LIBRARY 1 project and the CDASH LIBRARY Draft. The library icon () tells us that this Project / Draft combination is a library.

Copied From

What am I comparing against?

It is now very clear where an object was copied from but what library is it being compared to? The next section of our sidebar provides that information.

Compliance Information

It tells us:

  1. What library draft this object is being compared against and whether this is the same as the default Library for this Draft. You can change this comparison library. This allows you to have a default Library for the draft which all objects are compared against and then override for a particular object. AE, CM and VS Forms could all be compared against a default "Core Library" with TA-specific Forms being compared back to their specific TA Library.

  2. The Identifier that is being used to match to an object in the library. Usually this will be the same as the object name or OID but it doesn't have to be. Imagine that the library contains a standard Form called "VITALS". You might copy that object from the library and rename it to "VITALS_VISIT1". There is no object in the Library called "VITALS_VISIT1" so for the purposes of comparison you would enter the identifier "VITALS" so that it was being compared to the correct source object.

  3. The current compliance state and what object it is being compared against. It may seem obvious that if I am looking for a Form called "CM" in a Library then I will either find it (Match) or not (Not Found) in that Library but because Libraries can be linked together in TrialGrid the system may not find it in the first linked Library. For example, your TA-specific library may not contain the "CM" Form but it may be linked to a Core Standards library where the CM Form is to be found. TrialGrid searches through all your linked libraries (what we call the chain of compliance libraries) until it finds the object it's looking for or it reaches the end of the chain.

Note that these changes mean you are free to copy an object from any other Draft (e.g. a sister study) and it is clear what the object is being compared against.

If you copy from a Library it will continue to compare against that library until you change it. If you don't copy from a Library it will compare against the default Library for the Draft.

Faster Calculation

Calculating the object to match to and its compliance state (Matched, Different, Different with allowed changes etc) doesn't take very long for each object but if you have thousands of them it can take a few seconds. Previously the system calculated compliance every time it showed an object listing but some clients have thousands of objects and this caused poor performance. Object status is now calculated in the background and stored with every object. This improves the performance of listings but means that switching the default library for a Draft will cause recalculation of object status. Normally this will happen within 30 seconds even for a large study.


We plan on further improvements to Standards Compliance in 2020. If this is an area of functionality that you are interested in please get in touch!

Custom Property Types

It seems you can never have enough Metadata. Last month I wrote about Custom Metadata for Projects and Drafts in the TrialGrid system and this week we expanded this capability further. You can now define Custom Properties for Forms, Fields, Projects and Drafts in the TrialGrid system and for each of those Properties define its display order, data type (text, boolean or choice) and list of allowed values.

Custom Properties

Our industry is increasingly turning to Metadata Repositories (MDRs) to manage study design elements. Part of the promise of these systems is to capture not just the "What" of Forms, Fields, Data Dictionaries and other design elements but also the "Why" and the "How" : Why should this Field appear in this Form in this type of study? and How should the Form be modified if this is a Phase II rather than a Phase III study?

For all it's strengths, Medidata Rave Architect does not have any capability to import custom metadata. An MDR can output an Architect Loader Spreadsheet which defines the structure of the study but there's no way to include any of the data that led to that particular configuration. Examples include:

  • Is this a follow-on study?
  • What is the age group of the study participants?
  • Is the study blinded, unblinded?
  • What is the therapeutic area for this study?
  • Will the study run in the USA / Europe / China / Japan?
  • What Medical Coding system will be used for the study?
  • Does the study use Rave Safety Gateway?
  • Is there an ePRO component to the study?

Having this information associated as data to the study build is very useful to study builders in the short term but we have ambitions to use this metadata to automatically configure and validate study build. Watch this space!

Form Editor Improvements

When we started in 2016, Andrew and I had two main ideas for Medidata Rave: 1) Diagnostic Quality Checks and 2) Infix Edit Check editing. We didn't set out to create a better Architect but we needed a way for users to view and correct issues in study design objects identified by Diagnostics.

We introduced our Form Editor in early 2017 with some nice innovations for cloning Fields and moving them around, copying View and Entry restrictions and various other improvements over Architect:

Original Form Editor

Recently Andrew worked on further improvements and a few weeks ago these were made available on our Beta site.

Form Preview

We tried to make our Editor look a lot like the Form as it is displayed in Rave but our users were asking for improved preview and for Rave EDC (RaveX) preview. This is now available for Rave Classic:

Preview Classic

And for Rave EDC (this one shown in full-width mode):

Preview RaveEDC

We're particularly excited about the RaveEDC preview since, at least at the time of writing, this is a capability that Rave Architect doesn't provide.

View and Entry Restrictions

Keeping track of View and Entry restrictions for Fields can be fiddly. In Architect and in our original Form editor these were separate lists but Andrew has now put them side-by-side which makes it a lot easier to see whether a user is View or Entry restricted to a Field. Really you only want one of these checked, if a user is View restricted (they can't see the Field) then they are implicitly Entry restricted!

Editing Restrictions

In this screenshot you can also see an indication of the Form-level restrictions. Where a Field is restricted at the Form level there's no point in also restricting it at the Field level.

These changes to the editor also preserved the copy and paste functionality so if you have a block of Fields which should have the same restriction settings you can copy them from one Field to another. This can save you a lot of time and reduce errors.

Previewing Restrictions

The new Form Editor also offers the ability to preview as a particular role which makes it easy to check restrictions settings. Here I'm previewing a Form as the Batch Upload user and I can see that the first Field is View Restricted to me (it appears greyed out)

Previewing Restrictions


These are just the highlights of our new Form Editor. Andrew has also done a lot of work to improve the look and feel and the use of visual space to make designing and editing Forms in TrialGrid a really friction-free experience. We hope you'll like it and as always we want to hear new ideas for improvement of the TrialGrid system!