
Home	Services	CDISC	News	About us

New Features and Enhancement in version 1.3 of the CDISC ODM Standard

Recently (end of December 2006), CDISC has published version 1.3 of the ODM Standard (final).
The standards documents, XML-Schemas and example files can be downloaded from the CDISC website.

XML4Pharma has contributed a lot to this new version of the standard, especially in the areas of EDC and internationalization.

New features and enhancements

The ODM 1.3 has a lot of new features and enhancements, especially for EDC, for improved data transmissions, and for electronic submissions.
The new features and enhancements in a nutshell:

New opportunities for EDC

The ODM 1.3 enables fully automated creation of eCRFs in different languages, due to:

the new Description element (fully internationalized) allows to add descriptions in different languages at the level of StudyEventDef, FormDef, ItemGroupDef and ItemDef. These can be used to automatically generate the appropriate labels (in the target language) for the eCRF
the new ConditionDef element allows conditional navigation within eCRFs generated from the ODM metadata. This means that e.g. one can define that the questions about pregnancy need not to be answered in case the subject is male. In an automatically generated eCRF, the pregnancy questions are automatically blanked out when the investigator ticks that the subject is male.
The conditions themselves can be expressed in any language understandable by software (e.g. XPath, scripting languages, ...). For paper CRFs, the condition needs to be described within a Description element (fully internationalized).
An set of examples of such automatically created eCRFs using conditions for navigation can be found here.

Improved data transmission

Until now, in order to check whether transmitted clinical data were of the correct type and format, it was necessary to write software (such as the CDISC ODM Checker) which goes beyond simple validation against the XML-Schema.
In order to simplify this process, and to allow for more efficient, higher quality clinical data interchange, a set of 12 datatypes has been added to the standard. As these datatypes are extension of native XML-Schema datatypes, type-correctness of transferred clinical data can now be performed by simple validation against the XML-Schema.
These new datatypes are:

string	boolean
hexBinary	base64Binary
hexFloat	base64Float
partialDate	partialTime
partialDateTime	intervalDateTime
durationDateTime	incompleteDateTime
URI

Many people will also welcome the partialXXX and incompleteDateTime datatypes, allowing to transfer partial or incomplete date/time information in a controllable way.
Furthermore, durationDateTime and intervalDateTime datatypes have been introduced to enable ODM files to carry SDTM datasets information, thus allowing to replace SAS Transport files by ODM files for FDA submissions (which is the next step that will be made possible by the combined ODM / define.xml / SDTM teams).
The URI datatype is meant for referencing an external data file or URL.

The new binary datatypes (hexBinary, base64Binary, hexFloat, base64Float) not only make it possible to transfer binary data from SAS Transport files, but also allow e.g. to transfer images or any other binary information within ODM files (for example: XRay images, ECGs, ...).

Although the old datatypes are (and will in future be) fully supported, implementors are encouraged to use the new datatypes, and to use "typed ItemData" elements for transmissions.
The latter are:

ItemDataString	ItemDataInteger	ItemDataFloat	ItemDataDate	ItemDataTime
ItemDataDatetime	ItemDataText	ItemDataHexBinary	ItemDataBase64Binary	ItemDataHexFloat
ItemDataHexBase64Float	ItemDataPartialDate	ItemDataPartialTime	ItemDataPartialDatetime	ItemDataDurationDatetime
ItemDataIntervalDatetime	ItemDataIncompleteDatetime	ItemDataURI

Incorporation of some of the define.xml extensions

Grouping of AuditRecords, Signatures and Annotations

With the old ODM standard, audit records, signatures and annotations needed to be included directly into their SubjectData, StudyEventData, FormData, ItemGroupData or ItemData element.
With the new standard, it becomes possible to group all of these into a single, or set of AuditRecords, Signatures and Annotations elements. The latter than come under the ClinicalData element. This is however only possible with the new "typed ItemData" elements: these can contain a AuditRecordID, SignatureID, and/or AnnotationID to point to the corresponding entry in the AuditRecords, Signatures and/or Annotations elements.

This new feature will make it more easier for EDC and CDMS vendors to write software to export ODM, as in many cases, auditrecords, signatures and annotations are stored in separate database tables. The old mechanism only remains in place for non-typed ItemData elements

Enumerations in CodeLists

The ODM team found that it is not always necessary to have decodes in code lists. For example, in an oncology study, a question can occur about the number of cigarette packages a smoker consumes per day. Let's say the possible answers are "1", "2", ">2", then there is no necessity to have decodes.
In the old ODM, a Decode was always mandatory. So, in order to maintain backwards compatibility, the team chose to have a new element "EnumeratedItem", which has the same properties as the "CodeListItem" element, but without the obligation of having a decoding statement.

Vendor extensions

Just like in the ODM 1.2.1, a vendor extensions mechanism has been put in place, so that extensions can be described in an XML-Schema, thus allowing much simpler validation of transferred data.

Furthermore, it is not unimportant to note, that with the ODM 1.3, no DTD (Document Type Definition) is published anymore (why drive a Trabant if you can drive a Rolls ?).