You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

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 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 imported the SDTM metadata spreadsheet on the CDISC website to formulate the baseline content. During our recent quality sweep, we realized some relationships didn't look right and 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.

Findings About: Before Changes

Findings About: After Changes to Correct Relationships

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.

AE.DOMAIN: Before Changes

AE.DOMAIN: After Changes to Add Richness in Metadata

 

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, making expert knowledge as metadata.

 

  • No labels