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.

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.

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.

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.

Future

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!