Page History

The SDTM expert volunteers (Barrie Nelson, Joyce Hernandez, Janet Siani, Gary Cunningham, Abhishek Dabral), Julie Chason, and I have been busy lately, finalizing the metadata in SHARE for SDTM v1.3/SDTMIG v3.1.3. Before I go on with details, reckon relationships as the lines between assets in this SHARE Metamodel.

ISO 11179 defines relationship as "connection among model elements". It is a simple definition, yet with profound usages applications in the SHARE MDR. We use relationships to impose constraints between asset types. For instance, a variable metadata element (MDE) may only be represented by 1 value domain (VD). We use relationships to represent collections and their members. Examples: A domain-level metadata element set (MDES), which is a collection entity, may contain multiple variable MDE asset members; or, a class-level MDES may contain multiple domain MDES. We also use relationships to express hierarchies. The SHARE Stack diagram does a great job illustrating the hierarchy among various asset types for SDTM. As you can tell by now, we don't take relationships lightly.

We used imported the SDTM metadata spreadsheet posted on the CDISC website to formulate the baseline content. During our recent quality sweep, we realized some relationships didn't look right and sometimes some were missing. Take Findings About, for example. Findings About was shown as a class at the same level of the 3 general observations classes. Further, domain FA was a member of the Findings class (see Before relationship graph on the right). Information about these relationships was not included in the original SDTM metadata spreadsheet, nor were they explicit in the standard. We approached the SDS Leadership Team and obtained the authoritative information about their relationships (see After relationship graph). The revised metadata now reflects the true intention of the model, which the 2-dimensional metadata spreadsheet didn't address.

The DOMAIN variable in each SDTMIG domain demonstrates another good use of relationships. In SDTM, DOMAIN gets a constant value, which depends on the domain it belongs. For example, the value of AE.DOMAIN is "AE". This is quite different from AE.DOMAIN being represented by a character VD (see Before relationship graph on the right). We decided we ought to be expressive, and most importantly, take advantage of the CDISC Controlled Terminology assets that already exist in the MDR. After the revision, AE.DOMAIN has a much richer set of metadata (see After relationship graph) -- The variable now has a VD representation that contains only 1 domain value (DV) of "AE", of which implements the NCI EVS concept code of C49562, of which subsets from the CDISC SDTM Submission Domain Abbreviation Terminology codelist. That's clarity.

Some relationships for SDTM can be less than easy to discern from the PDF documents (normative documents). The team has done a fabulous job making them explicit and correct in SHARE so that the standard will become less esoteric, expressing making expert knowledge as metadata.