I have my opinions about the CDISC Operational Data Model (ODM) and the lack of support for it in EDC systems on the market.
Complaining about it has been very therapeutic for me but probably hasn't done much for anyone else. Jozef Aerts and others have put a lot of work into the specification and while joining them in their volunteer activities isn't practical at the moment I would like to provide some help.
So I started looking around for documentation on the ODM beyond the specification itself with the idea of providing some how-to-get-started links. There are a few articles [1, 2] which talk about the ODM in a general sense and a number of example ODM formatted files but I didn't find much HOW-TO material.
If you are a systems implementer or integrator then the ODM 1.3 specification is a great document and it gives you all the information you need. But if you are someone who wants to design their study using the CDISC ODM Metadata and needs an introductory text, there isn't much for you.
I hope that this tutorial will help fill that gap by providing an introduction and step-by-step examples of how to use the CDISC ODM to build a study design.
Maybe it will even help to raise interest in this important standard.
Why define your study using the ODM?
This series of articles is going to go through the process of setting up a simple study design in the ODM 1.3 Metadata Snapshot format. As you can see from CDISC's own list of vendors, very few of the EDC vendors from our own EDC Survey are certified capable of importing a study design in that format. So is it worth it?
I think so. Many vendors have the capability of working with the ODM format but have not taken up CDISC certification. As an example, in their marketing material, EDC vendor Clinipace describe how their technicians encode your study requirements into the ODM format for loading into their system.
Even if your vendor doesn't (yet) have tools to import your ODM file directly, by using this format you are specifying your study design in a standard format. Every Sponsor and every Vendor seem to have their own specification documents for form and validation check design. The ODM can act as a shared vocabulary between Sponsor and Vendor, helping to eliminate confusion in the specification process.
Understanding the ODM Format
The ODM is an XML-based specification language. If you are unfamiliar with XML there are many good tutorials available online [1,2]. This tutorial assumes that you know your elements from your attributes and how to write an XML file in a text editor but don’t worry, XML and the ODM are not hard to understand and we’re going to go slow.
Data vs MetaData
The ODM specification has two major parts. First is the Metadata part which defines what events, forms, questions and dictionaries (among other things) a study is made up of. This section will be our focus.
The second part is the patient data which provides a data transport and storage mechanism for the actual clinical data as entered into the eCRFs. We're not going to worry about that part since we're only focused on study specification in this tutorial.
Snapshot vs Transactional
As well as being in two parts, ODM files can be one of two types: Snapshot or Transactional. A Snapshot is like a photograph, a complete view of how things were at some particular moment but lacking in depth (audit trail).
A transactional file may contain a Snapshot but it also contains a set of updates (transactions) that should be applied to a snapshot state to bring this picture up to date.
Transactional files are most often concerned with patient data since patient data changes a lot more than Metadata. Snapshot files are fine for our study metadata definition and give vendors less problems so we'll stick with a snapshot file.