...
Note: In the ODM model, all internal keys are assumed to be unchangeable. This was done to make the audit trail issues work: If the SubjectKey in the model were the actual external subject identifier (or randomization ID) of a patient, and that value is sent incorrectly in one ODM file, there would be no way to correct the mistake in a follow-up file. In doing this, we intend that the external subject keys (and other externally visible key variables) should be defined as Items in the metadata. Thus they can be modified through normal modify/audit mechanism. Although this solves the problem of supporting modification of study keys, it leaves the user without a way to identify which ItemDefs have special meaning or what the meaning is. The most obvious place where this is a problem is in matching up patients when loading data from an external source. If you cannot find the patient ID, how do you do the matching? The answer is to create an Alias child element of ItemDef to provide an alternative name by, for example, setting with Context="SDSVarName" and Name="USUBJID". Setting Context to SDSVarName is a convention that can be used to tag the Item with a business meaning. Rather than try to enumerate all possible meanings in the ODM model, the Data Exchange Standards Team thought it best to rely on the set of variable names defined in the CDISC SDTM; this list covers the core variables used in managing clinical data. Software that is processing an ODM-compliant XML instance can therefore use specific Names when Context="SDSVarName" to identify standard, frequently used variables. The use of this Context value is restricted to variables defined in the SDTM model. In tagging a variable, you are identifying it as matching the SDTM definition for that variable. A partial list of commonly used values includes:
See the SDTM and SDTMIG for more information about SDTM variables. |
| Example | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
...