In December 1998, NASA launched a spacecraft designed to enter a fixed orbit around the planet Mars. The Climate Orbiter reached
Mars in late 1999 and, early in the morning of 23 September, fired its main engine to commence maneuvers into the target orbit.
As the craft passed behind Mars, everything seemed normal.
The spacecraft never re-emerged from behind the planet. NASA instigated an investigation and concluded that two teams involved
in the project had each used different measurement units in navigation calculations; one team had used imperial units while
the other used the metric system. This practice had resulted in data being passed between the teams and used without the necessary
conversions. As a result, a multimillion dollar spacecraft was lost due to a simple data transfer issue.
A similar event happened during the testing of computer systems destined for use as part of a clinical trial. Fortunately,
although it was essentially the same problem, it did not have the same impact as the NASA incident. A blood glucose reading
and other data was going to be collected from a number of subjects, and the data stored on a server located in Europe. That
would then be transferred, in an encrypted ASCII format, to another server in the United States where it was to be used for
analysis.
An issue arose upon the commencement of system testing. The glucose reading for the subjects was being stored on the server
in Europe as mmol/L, while the analysis software was expecting the readings to be measured as mg/dl. The protocol had not
specified which unit was to be used. The fix was simple, luckily, and a few days later the problem was resolved. These two example, albeit at either ends of the scale in terms of their impact, illustrate the potential cost of errors in
data transfers. Within the pharmaceutical industry, one organization is working hard to improve the mechanisms available for
the transfer of clinical data. The Clinical Data Interchange Standards Consortium (CDISC), a nonprofit organization, has been
working over the last four years on the development of standards to support clinical data interchange.
One of the CDISC standards is the Operational Data Model (ODM), and this article is intended as a primer for those who would
like an introduction to the model. The article tries not to delve into great technical detail, either about the ODM itself
or the technical aspects of the model's implementation. Hopefully, it provides just enough information to understand the concepts.
A little history The ODM has its roots in 1999, when work first commenced on what resulted in a first draft of the standard, Draft 0.8, issued
in March 2000. Since then, several versions have been released for review-in October 2000, Version 1.0 was released. November
2001 saw the review release of Version 1.1. The formal release of Version 1.1 occurred in April 2002. The most recent version,
Review Version 1.2, was released for comment in July 2003 and was released for implementation in January 2004.
The ODM has taken some time to evolve into the model we see today. The slow rate of progress in developing the ODM, and the
other three CDISC models, is a criticism often levelled at CDISC as an organization. This seems somewhat unfair. The subject
domain is a complex one, and the wide-ranging interests of the parties involved make achieving consensus difficult and time-consuming.
The role of the ODM The CDISC data models are designed to support the end-to-end data flow within clinical trials, from the operational database
through analysis to regulatory submission. The role of the ODM is to facilitate the movement of clinical data collected from
multiple acquisition sources to an operational database, but it also has application in the subsequent exchange and archiving
of such data.
The model has been designed to be flexible enough to allow data from a variety of sources, such as electronic or paper case
report forms, electronic Patient Diaries, laboratory data, and others, while also allowing for data to be passed to and from
data stores.
Figure 1. ODM file structure.
|
ODM mechanics The ODM specification defines the format of an ODM file as containing the ODM root element with four main subelements (see
Figure 1).
- The Study element, used to detail basic study information such as study name, and to define the MetaData for the study.
- The AdminData element, used to hold user attributes such as locations and signatures for those participating in the trial.
These items are used for audit trail functionality, for example.
- The ReferenceData, used to detail data used in the interpretation of clinical data. An example of such data is laboratory
normal ranges.
- The ClinicalData section, used to hold the data collected as part of the trial.
Facebook
