TrialGrid includes features that allow you to compare objects between Drafts and between an object and its library definition. This functionality is similar to the Rave Architect Difference Report but collects all the changes to an object into a single page.

This is a useful feature but we recently made it more convenient by making the comparison appear in a pop-up window rather than on its own page.

When working on a Form, Data Dictionary or other Draft object the ability to compare against a library without leaving the editor saves a lot of time.

If you'd like to learn more about the TrialGrid compare features then this video might also be useful. We are currently experimenting with short videos to explain features and to provide users with training alongside our online help.

Writing Custom Functions in Medidata Rave Architect can be a frustrating experience. The editor provides the basics for entering and validating Custom Function code in C# but little more. So what are the alternatives?

Visual Studio

Many Custom Function programmers do not develop Custom Functions in Architect. Instead they rely on Visual Studio which provides line numbering, syntax highlighting and all the benefits of a modern source code editor. Properly configured with the Medidata Core Object DLL's Visual Studio can also provide syntax highlighting and intellisense for the Rave Core Object Model classes.

In the most basic usage a programmer would write their Custom Function code in Visual Studio and then cut and paste it into the Architect Custom Function edit window to validate and save the code.

Custom Function Debugger

Programmers with Visual Studio and access to the Custom Function Debugger and ROAD (Rave On A Disk) have the best possible experience since they can connect directly to a running Rave instance to debug and test Custom Functions. This setup is highly recommended for Custom Function programmers but it can be difficult to arrange access to ROAD.

What if you don't have Visual Studio?

The majority of Rave study builders do not have access to the Custom Function Debugger and cannot install Visual Studio on their computers and so are stuck with the basic Custom Function editor in Architect. If you want to develop Custom Functions of any complexity you will need a guide to the available classes and methods of the Rave Object Model such as DataPoint, Record and Subject. Happily, Medidata has published a list of allowed methods as part of the Custom Function documentation on learn.mdsol.com. This is recommended reading and can help you look up method signatures without having to rely on guesswork and scanning other Custom Functions for examples.

The TrialGrid Custom Function Editor

Organizations with access to TrialGrid may use our advanced version of the Custom Function editor. This includes many of the features of a programmers editor like Visual Studio:

• Syntax highlighting
• Line numbering
• Search/Replace
• Auto-formatting
• Undo/redo for editing
• Code folding
• Validation
• Autocomplete

In the example above you can see Autocomplete showing the list of available methods for the DataPoint object type.

This isn't the same as the Intellisense you get with Visual Studio which is context-aware (i.e. it knows the types of variables and can provide autocomplete specific to that variable) but it reduces the need to consult the documentation to look up method signatures which is a big time saver.

Overall the TrialGrid Custom Function editor is a major step-up from the basic editor included with Rave Architect but for users that can install Visual Studio this is still the recommended approach.

Feature comparison

If you are interested in knowing more about how the TrialGrid Custom Function Editor can accelerate your Medidata Rave study build process please contact us!

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!