I started working with Medidata Rave in 2008 and I remember being impressed by the scope of the Rave product. Compared to other EDC systems it seemed to have everything: EDC, data migrations and versioning, double-key data entry, PDF generation, customizable workflow, non-programming edit checking, data export generation and reporting, library management, APIs for data import and export.. the list went on.

One thing that has always been missing however, is the ability to manage custom metadata alongside the metadata that Rave needs to function.

For example, Rave Forms have a number of attributes but in Architect there is no facility to add the SDTM domain or copyright information regarding the Form if it represents a validated instrument. Similarly, for the Fields in a Form there is no way to add additional metadata regarding the mapping of that Field to IxRS transfer specifications, SDTM generation or anything else, except by the use of naming conventions.

This omission has become more acutely felt as companies embrace the CDISC SDTM standard and work to make their study build processes repeatable. In order to plan a study from protocol design through to analysis many organizations have started to explore Metadata Repositories (MDR). These systems are designed to be highly configurable to different kinds of metadata and the mappings between them and to provide sophisticated tools for impact analysis and governance of that metadata.

MDRs promise much, but honestly I am yet to hear of an MDR project that was considered simple by anyone involved in it. They take time and a great deal of planning in order to deliver on their promise.

So what if you are an organization using Medidata Rave and you want to capture additional metadata on Rave Forms and Fields so that you can streamline your SDTM generation process? Chances are you are using a spreadsheet to capture that information and you have a process that looks like this:

This works but the mapping document and the study design can easily get out of sync, versioning is problematic and the Statistican has two Excel spreadsheets to merge and manage.

This is exactly the challenge our friends at BioForum faced when working with Medidata Rave. They have built a framework for the generation of SDTM from the Rave standard outputs which is driven by a mapping between Rave fields and Forms and the SDTM. Managing the mapping in the same tool where the Standard Libaries are maintained and where studies are built and quality checked would be so much more convenient:

To facililate this we built a simple mechanism into TrialGrid which allows users to define custom properties for their studies. These can be associated either with Form or with Field objects and users can decide whether to include these properties in object listings (e.g. to show the custom property alongside the Form OID in the list of Forms).

These properties then appear in the Form editor just like other attributes of the Form and Fields where changes to them are audit trailed.

These additional properties are exported from TrialGrid into the output ALS spreadsheet in their own custom sheets. You can load this file direct into Rave Architect since Architect ignores sheets it does not recognize. TrialGrid will load this metadata if it is present so if you do have an MDR and want to include additional metadata in the ALS file then TrialGrid can upload it.

Combined with our Library Management features, TrialGrid offers a simple way to manage compliance to library standards and an environment that unifies Rave study design and essential metadata management in a single solution which can be licensed on a per-study or per-user basis at a fraction of the cost of a full-blown MDR.

Please contact us for more information about the Standards and Metadata Management features of TrialGrid.