Articles tagged with 'Metadata'

Custom Property Types

It seems you can never have enough Metadata. Last month I wrote about Custom Metadata for Projects and Drafts in the TrialGrid system and this week we expanded this capability further. You can now define Custom Properties for Forms, Fields, Projects and Drafts in the TrialGrid system and for each of those Properties define its display order, data type (text, boolean or choice) and list of allowed values.

Custom Properties

Our industry is increasingly turning to Metadata Repositories (MDRs) to manage study design elements. Part of the promise of these systems is to capture not just the "What" of Forms, Fields, Data Dictionaries and other design elements but also the "Why" and the "How" : Why should this Field appear in this Form in this type of study? and How should the Form be modified if this is a Phase II rather than a Phase III study?

For all it's strengths, Medidata Rave Architect does not have any capability to import custom metadata. An MDR can output an Architect Loader Spreadsheet which defines the structure of the study but there's no way to include any of the data that led to that particular configuration. Examples include:

  • Is this a follow-on study?
  • What is the age group of the study participants?
  • Is the study blinded, unblinded?
  • What is the therapeutic area for this study?
  • Will the study run in the USA / Europe / China / Japan?
  • What Medical Coding system will be used for the study?
  • Does the study use Rave Safety Gateway?
  • Is there an ePRO component to the study?

Having this information associated as data to the study build is very useful to study builders in the short term but we have ambitions to use this metadata to automatically configure and validate study build. Watch this space!

Draft and Project Metadata

Medidata recently celebrated its 20 year anniversary, an amazing milestone, congratulations to all our friends and colleagues at Medidata!

Rave Architect, the Form and Edit Check design part of Rave, isn't quite 20 years old and in fact it still looks remarkably fresh, but nearly 20 years after it was first created, the needs of its users have grown. Some Rave installs have been running for more than a decade, accumulating hundreds of studies and reaching a scale that, I'm sure, would surprise the original designers of Architect.

That scale brings with it organizational challenges. Teams of 2 or 3 study builders in a single location have become departments of fifty or more study builders spread across different continents and timezones. Which projects are active? Which projects belong to which therapeutic areas? Which are the Phase III or Phase IV projects? Rave Architect doesn't have the ability to capture that Metadata. The Project listing in Architect gives you two useful attributes: The name of the Project and whether or not the Project is Active.

Architect Projects

This isn't a criticism of Architect; It's a tool designed to help you with the work of building and publishing EDC studies. It isn't a project planning tool, a team coordination platform or a Metadata repository. As an organization that uses Architect you need to provide those things.

As a result Organizations have tools for Project planning, technical document management, specifications management, UAT findings tracking, programming review and many more - some of them use commercial software but many of them are home-grown using spreadsheets and shared drives.

Our goal at TrialGrid is to provide a single, integrated environment for the nuts-and-bolts work of the study build but also the tracking activities that go on around it. As every Clinical Programmer knows, the job isn't done when you create a Form or an Edit Check. You also need to update a system or a spreadsheet to indicate that you've done that work and that it's ready to be reviewed by a technical reviewer, a standards manager, a tester or a manager. Life would be so much easier if there was a function in the study build tool that would perform that step.

That's why in TrialGrid we provide Labels that can be applied to any study design object to signal a workflow state (e.g. Ready for Review) or to provide informational tags (e.g. IxRS Integration) and Custom Metadata that can be applied to Forms and Fields in the study design to capture additional information (e.g. Form Standards Version, SDTM Annotation, E2B field relation, SDV tier).

And this week we added the ability to apply labels and custom Metadata to Projects and to Drafts. Allowing you to get a better overview of your Projects and to filter or search the list:

TrialGrid Projects

Just like Labels and Metadata on other object types, you get to choose the names and colors of Labels and the additional Metadata you want to capture. If it's Metadata related to study design objects such as Forms, Fields or the Draft itself then it is automatically exported to and imported from ALS files. This is useful if your source of ALS files is not Rave Architect but some kind of Metadata Repository - now some of that useful Metadata can be transferred along with the study design where it's helpful for Clinical Programmers.

We have further plans for this kind of metadata. Stay tuned!

If you would like to get future updates about this and other new features in TrialGrid, please use the subscribe button above to subscribe to our newsletter.

Do you really need an MDR?

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:

Excel Management

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:

TrialGrid Management

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).

Managing Properties

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

Editing Properties

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.