When you are working with Standard Libraries of Forms, Data Dictionaries, Edit Checks and other types of Medidata Rave study design objects it is normal to have deviations from the standard defined by the matching object in the library.

For example, you might add or remove an entry from a Data Dictionary or you might change the question text of a Field on a Form.

Some of these deviations from the library object are expected: A neonatal study may collect age in days or weeks rather than in years for example, but some of these deviations may require review by a Standards Librarian or Standards Manager.

Old Standards Compliance Workflow

Since 2016 the TrialGrid system has had a review workflow for differences from the Standard Library. We call this the Standards Compliance Workflow. Up until now, an object which deviated from the standard would be flagged as an unexplained deviation. The study builder or programmer could request approval for the object and this would notify a Standards Librarian to review the object and approve or deny the deviation. If the object was changed again, any approval would be removed, rather like an investigator signature in Rave EDC, and the workflow would return to Unexplained and require re-approval.

New Standards Compliance Workflow

This week we released an update to our standard compliance which uses this workflow on a per-change basis. Previously approvals were requested and granted on a per-object basis e.g.

1. "This Form has deviated from standard please approve".

Now approvals are per-change this single request might now be two individual requests:

1. "The Field AGE in Form DM now has a FixedUnit of 'weeks'. Please approve."
2. "The AGE_UNITS Field in Form DM has been removed. Please approve"

With the new system the Standard Librarian can review each change individually and approve/deny it. The overall Form status would be the worst status (Denied or Unexplained) with the Form getting approved status only if all the deviations had been approved.

In this screenshot we see the comparison between a Form and its equivalent in the standard library filtered to just show the differences. We can see the differences have different explanation states as denoted by their colors:

The counts of differences and their workflow states are also show in listings as shown in this Form list:

These listings can be filtered to show only items where explanation is required or where approval has been requested to make it easy for Study Builders or Standard Librarians to find objects requiring their attention.

Advantages of new approach

This new approach improves dialog between Study Builder and Standards Librarian because each change can be individually discussed. The explanations, requests for approval and approvals are all stored at the Project level so if a change in a Field definition is approved in Draft1 then this exact change does not have to be re-approved in Draft 2 and Draft 3 which significantly reduces the workload for both Study Builders and Standards Librarians.

With these fine-grained approvals it is easier to spot trends and gather metrics on deviations from the standard library so that the usage instructions for library objects can be improved. The TrialGrid system also has a number of features which allow expected deviations to be encoded in the library. These expected deviations do not have to be explained, they are automatically approved, again improving the efficiency of the team.

Batch Approval

One consequence of having per-difference approvals is that the number of changes to be reviewed is increased. Previously there might be a request to review five Forms, under the new system this might be a request to review thirty changes across those same five Forms. New features of the standards approval listings allow Standard Librarians to search and filter these requests and approve/deny them in batch.

Similar functionality is available for study builders requesting approval for changes to an object. If they make changes to a Form they can request approval for those changes individually or make a request for all the changes in a batch.

Conditional Approval

Our old workflow process had four states:

1. Unexplained - A change has been made but the Study Builder has not yet requested approval for it (they may still be working on it with further changes expected)

2. Approval Requested - The Study Builder has finalized their work (for now) and is requesting approval for the deviation from the standard.

3. Approved - A Standards Librarian has reviewed the deviation and approved it.

4. Denied - A Standards Librarian has reviewed the deviation and has rejected it, signalling that the Study Builder should change the object design before requesting approval again or revert it to the standard.

The new process adds a new state Conditionally Approved which is a signal that the Standards Librarian is accepting this deviation for now but will want to review this decision later. This is useful where the deviation is the addition of a new object such as a Form or an Edit Check which does not exist in the library. There can be no detailed comparison between this new object and the library because it does not exist in the library. The Standards Librarian may want to give a go-ahead to allow the new Form or Edit Check to exist but re-review it at a later stage to ensure that it is compliant with the principles of the library when it is finalized.

Summary

The use of Standard Libraries is highly recommended to improve the speed and efficiency of study build but deviations from the standard are inevitable. The ability to review and approve deviations and to capture detailed information about the types of deviations and reasons for them is important for continuous improvement of the Libraries and team efficiency.

The TrialGrid system can be used for Medidata Rave study build activities where this standards-compliance feedback is available in real-time or it can be used after study build is complete to perform comparisons between the library and the as-built study in a postmortem or lessons-learned exercise.

Either way, an organization will gain insight into how and why their study builds deviate from their library standards.

Edit Checks (improved QuickEdit)

Our first release of TrialGrid introduced the Clinical Query Language (CQL). CQL allows you to write edit checks in an infix format (2 + 2 = 4) instead of the postfix format Medidata Rave uses ( 2 2 + 4 =). In our tests using CQL to build edit checks is much more efficient than the point-and-click alternative in Rave Architect and is easier to learn.

But what about Clinical Programmers with years of Rave study build experience? These users almost exclusively use the Rave QuickEdit format for edit checks and after years of practice think in postfix. What could we do for them?

Rave Architect has a very simple editor for QuickEdit, just a plain text area with check attributes, steps and actions all presented as pipe-separated lines. Despite its simplicity it provides a lot of power - allowing users to cut and paste check steps and actions and create new checks.

The TrialGrid equivalent editor has the same functionality and adds auto-complete features to allow the selection of action types, step types and folders / forms / field and custom function names:

The QuickEdit text can be cut and pasted between Rave and TrialGrid, making it very easy to take advantage of the advanced features of TrialGrid when in the edit/publish/test/edit cycle of working with edit checks.

The CQL format is still there and users can switch between the QuickEdit, CQL and Description tabs to see the check displayed in the format of their choice. Edits made to a check in the CQL tab are reflected in the QuickEdit tab and vice-versa.

Overall we think experienced QuickEdit users are going to feel right at home in the TrialGrid check editor.

QuickEdit for Derivations

Useful as QuickEdit is, Rave Architect doesn't offer a QuickEdit format for Derivations. TrialGrid now provides this with all the same auto-complete benefits.

This format can't be cut and pasted into Rave but it can still be a convenient format to edit Derivations if you are familiar with QuickEdit for Edit Checks.

Spreadsheet editing for Fields in Forms

The TrialGrid Form editor offers a lot of features:

• Drag and drop re-ordering of fields
• Form preview for Rave Classic and Rave EDC (formerly RaveX)
• Form preview by EDC Role (e.g. see a Form as a user with that Role would)
• Cloning Fields within the Form
• Copy and paste for View and Entry restrictions

These are all useful but nothing beats the convenience of editing an Architect Loader Spreadsheet (ALS) when you want to do bulk-changes to the Fields in a Form.

The downsides of spreadsheet editing are the need to import/export the ALS and taking care to make sure the changes are valid.

TrialGrid now allows customized grid-views of Form Fields to be defined per TrialGrid role. This means that you can define an editing grid for your Standards Management staff separate to your Study Builders or Data Managers. These views can include read-only columns, default values for new Fields and are especially useful when combined with Custom Field Properties (Field Metadata).

In the screenshot we see the Form editor with several custom sheets defined (Review Summary, Standards Review, Core Items) with the Standards Review tab selected. The selected column, "Standard Field Number" is a custom property added to Fields in the TrialGrid system. Note that this custom attribute has the same look and feel as the "normal" attributes of the Fields such as VariableOID, Field Name, Is Log etc.

Multiple editing grids can be defined for a TrialGrid role and each can have a different set of columns shown.

We think this grid editor provides the convenience of a spreadsheet with the validation and control of the normal Form editor.

Uppercasing Data Dictionary Values

The Data Dictionary editor in TrialGrid also uses a spreadsheet-like grid which allows cut and paste, sorting by column and drag-to-reorder but we recently the ability to uppercase text in selected cells:

This is a small feature, but very convenient when you need it.

Wrapping up

This is just a sample of the features added in the last few months. Look out for some future posts about enhancements to our document generation and automated test features!

Deleting Folders

One of the features of Rave Architect which can be frustrating for study builders is its enforcement of referential integrity. Simply stated, Architect wants to make sure that your study is always valid and that if, say, a Folder called "SCREENING" is referenced in an Edit Check, that a Folder called "SCREENING" does actually exist. This means it won't allow you to delete that Folder until that reference is removed.

Normally this is what you want but it can also feel constraining when you really want to delete that Folder but can't...

...and as you can see, Architect doesn't tell you HOW the Folder is in use.

To be fair to Architect, it's trying to stop you doing something you will regret. If the Folder is referenced in 20 Edit Checks, removing that Folder will make those Edit Checks invalid and Architect won't let you save an invalid check so should it delete the related Edit Checks?

At times like these many Rave study builders will simply download the Architect Loader Spreadsheet to Excel - an environment that doesn't enforce referential integrity - and start doing search and replace and deletions. The danger of that is that you can waste a lot of time trying to re-load the study back into Architect when you don't get all the references matched up right again and you get caught in the edit -> try to load -> edit -> try to load cycle.

It would be nice if Architect warned you of the consequences of deleting the Folder and then allowed you to go ahead anyway. Kind of like TrialGrid does....

In this case TrialGrid is telling you what the consequences of deleting this Folder will be. You can then decide if that is really what you want to do.

Deleting checks and Derivations from the Form Editor

Following on from Folders it can be frustrating to find that you can't delete a Field from a Form because it has some related Edit Check. You could always see the Edit Checks related to a Field in the TrialGrid Form editor (just as you can in Rave Architect) but now the TrialGrid version allows you to delete those Edit Checks too:

Draft Compare Report

Comparisons between Drafts are really easy in TrialGrid and we continue to make improvements in this area. In October 2020 we added popup compares but our users wanted a report they could export and share.

So now you can perform a compare and then export it to Excel:

Every object difference is listed along with original and new values and a colored difference report of the changes between them:

This compare report makes it easier than ever to work out what changed between two Drafts and to share a report of those differences.

These are just a few of the convenience features in TrialGrid that help to make Study Builders more productive. Contact us if you'd like a demonstration of this or the many other features of TrialGrid!