A first simple example of end-to-end

Today, we will look at a simple example of CDISC end-to-end.
Suppose we have a question about the height of a subject in our CRF. As the study has been deployed in the US, in Germany, in France and in Korea, there are some translations. Therefore the ODM study design looks like:

Remark that I collapsed some of the XML nodes (the ErrorMessage nodes).
Now have a look at some of the annotations (marked with a star). The first is the attribute "SDSVarName" stating that the captured value will later go into the SDTM variable "VSORRES".
The second states that in some deployments, the units that will be used are inches, and in other deployments, the units that will be used are centimeters. This information will later go into the SDTM variable "VSORRESU".
Also remark that it is not stated under which circumstances which units will be used. This feature will be added to the next version of ODM.
The third annotation is especially important. It is the ODM "Alias" element that can be used to state a synonym for the item in a non-ODM context. In this case it states that in SDTM, the item will be used for the combinates VSORRES with VSTESTCD=HEIGHT.
Brilliant isn't it? All the information for generated the SDTM records is already present! And that at study design time!

The units of measurement are further defined in more detail in the ODM "MeasurementUnit" elements:

Also here, we could add an Alias, e.g. to add the UCUM equivalents of the units. UCUM is a worldwide standard for units of measurement, and is especially used in electronic health records like used in HL7 CDA.

Now, how will all this go into SDTM?
The information is already present at study design, so a define.xml can already be generated at this stage (and not as the last step in the process as still some vendors and processes do). Also, the first (or prototype) SDTM datasets can already be generated once the first data come in. This has the great advantage that one can already start doing quality control when the first datapoints come in. This can save huge amounts of time and money!

Part of the define.xml for this study (which can already be generated at study design time!) can then look like:

It references a codelist for the different test codes, and even more important, references a "ValueList" stating the metadata for each of the tests, such as codelists and ... units of measurement.
The ValueList looks e.g. like:

It states that for VTESTCD "HEIGHT", there is an ItemDef "I_HEIGHT" which defines the metadata for this test.

Now guess how this metadata definition for the test code "HEIGHT" looks like. Here it is:

You may now scroll up to the top of this article and compare this metadata definition for test code "HEIGHT" in define.xml, with the metadata definition for the CRF for the datapoint "Height".

Did you compare? Here is the result:

THEY ARE THE SAME!

This is exactly what we mean with CDISC end-to-end!
The metadata definition for the CRF datapoint "Height" is just copied "as is" into the define.xml, containing the metadata for submission to the FDA.
No transformations necessary!

We can now also copy the "MeasurementUnit" elements from the ODM study design to the define.xml. We do not need to transform them into a codelist. They just remain valid also in the define.xml

In a next article, we will give further examples about CDISC end-to-end, and how we can reuse information from the study design into the metadata that is send to the FDA.