Articles tagged with 'Standards Compliance'

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

Sidebar

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.

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!

Standards Compliance for Study Builders

In my last post I explained some of the standards compliance and comparison features in TrialGrid. Being able to determine compliance in a report is very useful but what about the Study Builder? How does a Study Builder know, during the setup of a Form, what the Standard allows to be changed and what must be preserved exactly the same as the Standard Object in order to maintain compliance?

In TrialGrid we present this information to the Study Builder in several ways so that they can build Forms compliant from the start.

First, the Form displays a Standards Compliance summary area which shows whether Fields can be added to the Form or Fields can be deleted.

Compliance Summary

This summary is updated as the Form is saved so that the Study Builder can always see whether the Form they are working on is currently in a state of Matched (exactly the same as the standard), Modified (allowed changes have been made) or Not Explained (non-allowed changes made).

Secondly, changes which are allowed to individual properties of the Form or of any Field are marked with a pencil icon as shown here on the Name property:

Name Field

The pencil icon signals that this property may be changed without breaking standards compliance.

Finally, although the Standard Form may allow some Fields to be deleted there may be other Fields which are Required and so cannot be deleted. These are marked in the Fields list with a "STD. Required" label:

Required Field

Deleting a Required Field will mark the Form as non-compliant to the standard.

Our goal with TrialGrid is to bring activities like standards compliance checking into the study build workflow so that non-conformances can be explained and addressed as early in the process as possible. Just one of the ways that TrialGrid makes life better for Study Builders.

Standards Compliance

Standard Libraries. The concept is straightforward; A Standard Library is a set of Forms, Data Dictionaries, Edit Checks and other study design elements which can be used as building-blocks to assemble an EDC study design. Using a Standard Library should increase efficiency, eliminate variation, reduce study build times and therefore reduce cost. The reality is not always so straightforward. Standard Libraries require maintenance and they require enforcement to ensure that they are being used correctly and these activities are not free. For CRO's providing EDC study build services where every client Sponsor has one or more Standard Libraries, managing compliance can be a major challenge.

Medidata Rave Architect provides Global Libraries to organize standard design objects and a Copy Wizard to quickly pull those objects into a study design. These are useful tools for the Study Builder but really only cover the initial phase of study build. Lets look at an example of Standards in action to see how TrialGrid extends the capabilities of Rave Architect to support the use of standards through the entire study build.

A Standard Form

We'll start with an example standard Form, loosely based on the CDISC Demography Form. Here is the design of the form in Architect.

Form Design

This is the Form definition which is copied into a new study.

Changes to the Standard Form

In many cases a "Standard Form" will have some allowed changes. Some Fields may be optional, some Properties of Fields such as their Labels or Help text, may be allowed to be changed. Making these changes may not be considered a deviation from the Standard.

The following changes are made to the Standard Form by our Study Builder:

  • The Time of Birth field is made inactive (invisible, not collected)
  • The Sex field is moved down the field order so that it appears after Race
  • Planned Arm Code and Arm are removed altogether from the form
  • The field label for Date Of Birth is changed to "Birth Date"
  • A new field, RELSTAT : Self-reported relationship status, is added to the Form

It now looks like this (changes highlighted):

Form Design

Challenges

The challenge for the Standards Manager and for the Study Builder is to determine if the changes that have been made to this Form make it non-compliant. The Rave Architect Global Library stores the original Form and Architect provides a difference report which can help to determine the differences between the Form as pulled from the library and as-modified in the study:

Difference report

The color coding shows that changes have been made to the Fields of the DM Form but it is difficult to read in the spreadsheet format and Architect doesn't have any concept of what changes are allowed to a Form or to Field properties so cannot be any help in determining if these changes are OK (compliant with Standard) or not (non-compliant).

If your process requires these kinds of changes to be reviewed by a Standards Manager or otherwise compared against a set of written rules for the use of the Standard this can become a very time-consuming activity, stretching timelines and increasing costs.

The TrialGrid way

TrialGrid is a system that brings together Standards Compliance, Study Design and Quality checking into a single integrated environment. So how does it manage the Standards Compliance workflow?

First we'd import both the Global Library Draft and the Study Draft into TrialGrid. It takes about 30 seconds to download an Architect Loader Spreadsheet from Rave Architect and about 30 seconds to load one into TrialGrid. In two minutes we can have the library and study draft uploaded into the system.

Next we mark the Global Library Draft as a Library and we link the Study Draft to it, actions that take about 5 seconds to perform.

Immediately the Form list shows that the DM form has been modified from the standard and that the changes are unexplained:

TG Form List

So what are those differences? Click the Compare button to find out:

TG Compare

In the top left we see a summary of the changes which tells us which changes, if any, are deviations from the Standard. Below is a graphical representation of the Fields of the Form with the Standard on the left and the current Form on the right. Changes are colored in Red and lines between the Fields show how they match up. We can quickly see which Fields have changed and which have no equivalent between the Standard and the New. Fields which have been moved in the order are also clear to see, we can see that SEX has been moved down below RACEOTH in the new Form.

Clicking on any of the Field boxes takes the user to the Properties with any changes highlighted.

TG Property Change

Allowed Changes

So far we have demonstrated that TrialGrid makes comparisons between objects easier but what about Allowed changes?

In order to set that up we need to navigate to the Standard Form. Here we can select the Standards Control tab and set some global options for the Form. In this case we're saying that the Form Help Property can be changed and that Fields may be Removed and that Fields may be added.

TG Form Standards

But there are some Fields we do not want to be removed such as Date of Birth. We can override this option for the Date of Birth Field. If our standard allows it we can also select properties which are allowed to be changed. Here we select "Pre Text" (the question label) as an allowed change and mark the field as Required by the Standard.

TG Form Standards

Finally, for Time of Birth we can allow the Active property to be changed (not shown in screenshot).

Now when we return to the Comparison view we see that all our changes are now shown in green.

TG Compare Again

If you recall from the start our changes were:

  • The Time of Birth field is made inactive (invisible, not collected) - Made an allowed change to the Active Property to this field.
  • The Sex field is moved down the field order so that it appears after Race - Shown in the comparison (allowed by default)
  • Planned Arm Code and Arm are removed altogether from the form - Form allows fields to be removed (unless they are marked required)
  • The field label for Date Of Birth is changed to "Birth Date" - Field allows changes to the Pre-Text property so this is now OK
  • A new field, RELSTAT : Self-reported relationship status, is added to the Form - Form allows additional Fields to be added so this is now OK.

Summary

The goal of this post was to demonstrate how the Standards Compliance features of TrialGrid assist study teams in tracking compliance without having to use the Architect Difference Report. The Allowed Changes feature reduces the workload on the Standards Manager or Global Librarian so that they do not have to manually review and approve every tiny change to any element of a Standard Form.

There was no space in this post to go through the workflow for Standards Compliance approval requests and the reporting aspects of this feature, I'll save that for a future post. If you are interested in seeing more of this feature, please contact us.