If you are building studies in Medidata Rave, sooner or later you'll want to generate an Annotated Case Report Form so that you can communicate the study design with other team members who may not have access to Rave and to document the study data structures.

Some time ago we were asked whether we could create annotated CRFs in Microsoft Word format since this format is easily modified and can easily be converted into PDF (and many other formats) from Word.

Experiments with Template solutions

For a proof of concept we began by looking at templating solutions for Word. The idea was to have a Word document and then "decorate" it with template control tags which would allow us to loop over collections such as the list of Forms in a study and its Fields and insert text.

This seemed like it would work well for simple content:

But for complex content like generating the Annotate of a Form it soon became a tangled mess of template tags that mixed up the content and the formatting.

The idea had promise, "It's just a word processing document!" but the reality didn't deliver for complex documents like annotates.

Requirements

Back at the drawing board we thought about next steps and refined our requirements:

1. Word Based. We love free software but our corporate users have Microsoft Word installed already. Often their computers are locked down so that they can't install new software even if it is free.

2. Flexible. Should be able to use Word features such as tables, borders, font-sizes and colors etc.

3. Easy to author for a technical data manager but not code-inside-Word.

"Easy" is a relative term and difficult to reconcile with "Flexible" but if we could deliver a solution with roughly the complexity of authoring HTML web pages that seemed a reasonable compromise.

Word Documents from Markup

Inserting HTML into Word documents is possible. We tried it, but it didn't give us the fine level of control we wanted for generating our documents. Could we instead create a markup language for Word? Something like HTML?

Here is a simple example of the markup language we created:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<?xml version="1.0" encoding="utf-8" ?>
<document>
    <heading level="0" align="center">~ Invoice ~</heading>
    <para>
        Dear Sir/Madam,<br/><br/>
        <run font-bold="true">Thank you</run> for your order:
    </para>
    <table style="Light Shading Accent 1">
        <row>
            <cell>Qty</cell>
            <cell>Desc</cell>
        </row>
        <row>
            <cell>15</cell>
            <cell>User Licenses</cell>
        </row>
    </table>
    <para space-before="0.5cm">
        Yours Sincerely,<br/>
        <br/>
        The TrialGrid Team
    </para>
</document>

to generate:

This markup language gives us the ability to create headers, footers, tables of contents, insert pictures, change page sizing, manage fonts and styling etc.

Generating Annotates

With this markup language we were able to finally start on building our Annotate generator. Here's a sneak peek of an annotate that just shows the layout of the Form:

Summary

We didn't set out to create a system for generating any kind of Word document but it gives us a lot of flexibility in generating all kinds of annotate variants. In the example above we don't show Field OIDs or names but we can easily add that in any font, color or position you might want.

The markup to generate this result is not too complex and we plan to make it available to our users so that they can modify it and make their own variants.

In the meantime, if you have ever wanted something more or different from your Medidata Rave annotates please do get in contact, we'd be happy to discuss your requirements and maybe incorporate them.

Despite the holiday season it has been a busy month at TrialGrid. We hosted two audits in July and our Quality Management System and approach to validation continues to be well received by Auditors. At the same time, we managed to make more than 60 changes to the system including improvements to the UAT functionality and the addition of 11 new Diagnostics, bringing our total to 119.

All of these new Diagnostics were suggested by customers and our policy on these is really simple - if a suggested Diagnostic would be useful to all our clients, we implement it for free. As a result, we have a backlog of 30-40 new Diagnostics to add over the coming months. Big thanks to all our contributors!

As well as adding the following Diagnostics we also added new options to many existing Diagnostics (e.g. to ignore inactive Fields, Forms and Edit Checks). In all, our 119 Diagnostics have more than 300 settings which all you to customize the operation of the Diagnostics to your own standards.

0109 : Fields should NOT have a SAS Format Specified

As you know, if you don't set a specific SAS Format for a Field then Rave will assign one. Depending on your work practices you might choose to always use Rave defaults (this Diagnostic) or specify your own formats.

If you choose to specify your own formats then you will likely want to use Diagnostic 0051 : Fields should have a SAS Format Specified which is the exact opposite of 0109.

This highlights the importance of selecting Diagnostics which match your own best practices. The easiest way to manage this is to set up standard sets of Diagnostics (and their associated settings) in a TrialGrid Project. These standard settings can then be imported into any other Project.

We can suggest a set of core Diagnostics and help you set up a standard library of Diagnostics you want to run.

0110 : ePRO Forms should not require signature

This should be self-evident but its easy to make a mistake here.

0111 : Ensure a set of Custom Functions exist in a Draft

When you have Custom Functions that call other custom functions via PerformCustomFunction it's easy to forget to include those additional CFs in your study draft. Rave won't recognize there's a problem until you start testing your Edit Checks and it discovers that the dynamically called Custom Function doesn't exist. This Diagnostic ensures that one or more required Custom Functions appear in the Draft.

0112 : Targets of Set Dynamic Search List Check Actions should have a Control Type of DynamicSearchList

In Rave you set a Field to be a Dynamic Search List via a Check Action but the Field itself has to be set to have a DynamicSearchList control or you won't be able to publish the Draft. This Diagnostic tells you sooner.

0113 : Primary Form may not have Dynamic Search Lists

Speaking of Dynamic Search Lists, did you know that they cannot appear on the Primary Form or the Draft cannot be published? This Diagnostic will catch that for you.

0114 : Forms should have Confirm Save set

Rave has four settings for Save Confirmation - No Confirmation (Save Confirm Checkbox unchecked), No Link, Link Next and Link Custom. You can use this Diagnostic to ensure Forms are not set to "No Confirmation".

If you want to enforce a particular Confirmation Style you can use Diagnostic 0074. Note that RaveEDC (formerly RaveX) only supports some of the Confirmation options and Diagnostic 0074 was updated to provide even more control over the types of confirmation links you allow in your studies.

0115 : Ensure specific Forms/Folder/Matrix combinations exist

This Diagnostic checks that specific Form/Folder combinations exist in either specific Matrices or in Any Matrix. If a combination exists but the Form is inactive then a warning is given. You would use this Diagnostic to ensure that standard Forms appear where you would expect them to in your studies e.g. an IVRS integration Form or a study withdrawal Form.

0116 : Ensure specific Forms/Fields have Set Folder Observation Date checked

When you are using Rave's subject calendar features you'll need to ensure that the Folder Observation Date is checked. This Diagnostics ensures that key Fields have the necessary options set.

0117 : Check name of Primary Form

If you have a standard for the name of your enrolment form this Diagnostic will help you enforce it. The Diagnostic checks that the Primary Form for the Draft has a specific name or matches a specific pattern (e.g. contains the word "Subject").

0118 : Check Draft Confirmation Message and Signature Prompts match expected text

This Diagnostic checks that the Save Confirmation Message and Signature Prompt text for the Draft exactly match the values provided. This allows organizations to ensure that their legal wording is being reproduced precisely in study designs.

0119 : Fields of ControlType CheckBox should not be used except on a specific set of Forms or Fields

Some organizations do not use CheckBox controls except in specific circumstances. Checkboxes have a value of Checked (1) or Unchecked (0) which makes it difficult to know if a user deliberately chose not to check a box or overlooked the question.

New releases

If you are already a TrialGrid user, check the online help for the latest Release Notes on Beta. We will soon be pushing a new version (Version 14) to the pre-production environment and contacting customers to announce the Production release date.

We've blogged before about Matrix features in TrialGrid; creating All-Forms and Merged Matrices, features to help with viewing large Matrices and highlighting inactive Forms.

Recently we were asked by some of our users if we could help identify 'overlapping Matrices', i.e. a Folder/Form combination which exists in two or more Matrices (excluding the All-Forms and Merged Matrices). It is useful to check for this because Medidata Rave EDC will remove Forms when reversing a Merge Matrix Check Action and if a Form is included in more than one Matrix then Forms can disappear from subjects unexpectedly.

However it is very difficult to spot this problem in advance, especially on a large study. The largest we've seen has more than 500 Folders, 50 Forms, 30 Matrices and over 14,000 Folder/Form combinations in those Matrices. Checking those for overlaps in Rave or a spreadsheet is virtually impossible.

With that in mind we set to work to add features to TrialGrid Matrices to make it easy to see when Folder/Forms are used in more than one Matrix.

Searching and selecting multiple Matrices

When we first open the Matrices editor in TrialGrid the Default Matrix is displayed. Here we're using a small demo study as an example:

We can zoom in:

and can search for all of the 'VISIT' Matrices and select them by clicking 'Select All':

Overlaps highlighted

Now we can see two Folder/Form combinations which are highlighted orange (used in two Matrices) and red (used in three or more Matrices). Hovering over the cells shows us which Matrices are used:

This highlighting means it is easy to see where there are overlaps and find the Matrices which need to be edited.

Editing is as simple as clicking on the cells:

Merged and All-Forms Matrices

Once we're done with correcting the Matrices we can quickly generate Merged or All-Form Matrices:

Printing Matrices

You can print out one, or a combination of Matrices:

Large Matrices

The examples above are from a small study we use to demo TrialGrid. A real study might be much larger. Here's an extract from a real study Draft which has more than 200 Matrices:

In this image we are displaying 214 Matrices simultaneously and we can immediately see the overlaps.

Imagine searching through Rave Architect or an Architect Loader Spreadsheet to find them!

One more thing...

While working on these additions to Matrix features we added an easter egg for some entertainment.

'GAME ON' as our Medidata friends would say (no Matrices were harmed in the making of this clip).

Contact us if you'd like to learn more about TrialGrid and see these features in action.