When designing a study, it is very useful to already include information that can later be used for submission of the clinical data to the FDA. The ODM standard does have several features for allowing to do so.

The ItemGroupDef element has an optional attribute 'Domain' allowing to annotate a whole ItemGroup with the SDTM domain information. For example, one can annotate a group of questions (ItemGroup), declaring that the information captured in that ItemGroup will (probably) go into the “Demographics” domain or to the “Vital Signs” domain. Essentially, the contents of the attribute is free text, so one can e.g. add:

  <ItemGroupDef OID="..." Name="..." Domain="VS">...</ItemGroupDef>

or:

  <ItemGroupDef OID="..." Name="..." Domain="Vital Signs">...</ItemGroupDef>

The content of the attribute is not really meant to be machine-interpretable. It is more meant to give a (human) user a hint which domain to use when the (meta)data is mapped to the SDTM, as is done in the SDTM-ETL software.

In case a data point can simply be mapped 1:1 to an SDTM variable, one can use the SDSVarName attribute to annotate the metadata for that datapoint. The text content of the SDSVarName attribute is not free text, but must comply to the rules for a valid SAS Transport 5 variable name: max. 8 characters, and must start with a letter or an underscore. Essentially, it must be a valid SDTM variable name.

For example, for a data point “birth date” it is clear that this will go into the SDTM variable BRTHDTC in the Demographics domain. So the annotation is:

  <ItemDef OID="..." Name="The subjects birth date" SDSVarName="BRTHDTC">...</ItemDef>

As the content of the SDSVarName attribute is supposed to be a valid SDTM variable name, it can be used either for an automated mapping, or at least give a strong hint (“hot candidate”) to the mapping designer that the contents of the corresponding ItemData will go into BRTHDTC.

In ODM 1.3, the ItemDef element is allowed to have one or more “Alias” child elements. The ODM specification says: “An Alias provides an additional name for an ItemDef or an ItemGroupDef. The Context attribute specifies the application domain in which this additional name is relevant”. It can either occur as a child element of ItemDef or of ItemGroupDef. In the upcoming ODM 1.3.1, the use of the Alias element will be allowed on all study design defininition elements, such as StudyEventDef, FormDef, but also on CodeList, ConditionDef, MeasurementUnit, etc..

The Alias element is the ideal instrument to annotate metadata for specific purposes. For example, for an ItemDef for the systolic blood pressure, one can use the following annotation:

  <ItemDef OID="..." Name="Systolic blood pressure" DataType="float" ...>
      <Question>...</Question>
      <Alias Context="SDTM" Value="VSORRES where VSTESTCD=SYSBP"/>
  </ItemDef>

clearly designating that the value of the collected data will go into VSORRES with VSTESTCD being 'SYSBP'.

An example of such an annotated (e)CRF generated from the ODM is:

In ODM 1.3.1, which is expected to be published by the end of 2009, this concept has further been extended. One can also add “Alias” element on “CodeList” and/or “CodeListItem”. This is very useful.

Suppose that we have a repeating group in an EDC system for the SDTM domain “Physical Examination”. The Items in this group are the test name, whether the result is “normal”, “abnormal” or “not done”, and the description of the abnormality in case the result is “abnormal”. The whole group repeats over a list of body parts. So we have a CodeList with:

  <CodeList OID="CL.BODYPARTS" Name="Body parts" DataType="integer">
      <CodeListItem CodedValue="1">
          <Decode><TranslatedText xml:lang="en">Appearance/Skin</TranslatedText></Decode>
          <Alias Context="SDTM" Value="PETESTCD=SKIN PETEST=Appearance/Skin"/>
      </CodeListItem>
      <CodeListItem CodedValue="2">
          <Decode><TranslatedText xml:lang="en">Head, Neck and Thyroid</TranslatedText></Decode>
          <Alias Context="SDTM" Value="PETESTCD=HNT PETEST=Head, Neck and Thyroid"/>
      </CodeListItem>
      <CodeListItem CodedValue="3">
          <Decode><TranslatedText xml:lang="en">Eyes-Ears-Nose-Throat</TranslatedText></Decode>
          <Alias Context="SDTM" Value="PETESTCD=EENT PETEST=Eyes-Ears-Nose-Throat"/>
      </CodeListItem>
      <CodeListItem CodedValue="4">
          <Decode><TranslatedText xml:lang="en">Cardiovascular</TranslatedText></Decode>
          <Alias Context="SDTM" Value="PETESTCD=CARDIO PETEST=Cardiovascular"/>
      </CodeListItem>
      ...
      <Alias Name="SDTM" Value="PETESTCD"/>
  </CodeList>

With the annotations in the Alias elements already fully describing the mapping between the ODM items and the SDTM variables.

Similarly, one can use the Alias element to annotate data elements for other purposes. The 'purpose' is given by the 'Context' attribute. So for example, one can annotate a data element that with its CDASH name.

For example, if we have two data fields, one for the date of the vital signs measurement, and one for the time, one can annotate as follows:

  <ItemDef OID="..." Name="Date of vital signs measurement" DataType="date">
      <Question>...</Question>
      <Alias Context="SDTM" Value="date part of VSDTC"/>
      <Alias Context="CDASH" Value="VSDAT"/>
  </ItemDef>
  <ItemDef OID="..." Name="Time of vital signs measurement" DataType="time">
      <Question>...</Question>
      <Alias Context="SDTM" Value="time part of VSDTC"/>
      <Alias Context="CDASH" Value="VSTIM"/>
  </ItemDef>

The CDASH annotation can be very useful, especially for interfacing with electronic health records and with hospital information systems. For example, we developed a mapping between CDASH forms implemented as ODM, and EHRs using the HL7 CCD (Continuity of Care Document). As each EDC vendor/system may use other OIDs for its data point definitions (some EDC vendors have automated OID assignment), the Alias element is used to designate the CDASH variable. So this leaves the eCRF designer and the EDC vendor the freedom of OID assignment and avoids the problem with naming conventions. We developed a mapping and corresponding XSLT stylesheet that transforms an EHR in the form of a CCD into an ODM “PrepopData” document, which is then read by the CDASH form to prepopulate the form with information from the EHR. This could only be done due to the CDASH annotation in the ODM file.

Extensive information about this system can be found IHE wiki site for Clinical Research Integration and on the Clinical Research Data Capture wiki page.

A presentation I gave on this topic at the CDISC European Interchange 2009 can be found on my website.

One company I am helping with the implementation of CDISC standards, has discovered that the “Alias” concept can be used for a lot of things, and is a simple alternative for vendor extensions to the ODM. They have set up an enumerated list for the value of the “Context” attribute with value such as “Portal”, “Backend”, “Data Cleaning” etc.. This allows them to describe things such as “this item is a subject identifier in the portal”.

Of course, and that is the critic that some people will surely have, is that this is not always portable. Context uses such as “SDTM” or “CDASH” are, and are extremely useful for communication between the different parties in the process. For example, it allows to already start taking care of the mapping between data collection and SDTM submission even before the first data point has been collected. Other “Context” uses may be limited to be useful within one single company, such as annotations for use in a portal.