Supplemental Qualifiers

1. Supplemental Qualifiers Gregory Steffens Novartis Associate Director, Programming NJ CDISC Users’ Group 17 April 2014

2. Supplemental Qualifiers Defined | Presentation Title | Presenter Name | Date | Subject | Business Use Only “The SDTM does not allow the addition of new variables. Therefore, the Supplemental Qualifiers special purpose dataset model is used to capture non-standard variables and their association to parent records in general-observation-class datasets” “SUPP-- datasets are also used to capture attributions. An attribution is typically an interpretation or subjective classification of one or more observations by a specific evaluator, such as a population flag that classifies a subject or their data according to their evaluability for efficacy analysis, or whether an observation is considered to be clinically significant.”

3. Supplemental Qualifier Domain Structure | Presentation Title | Presenter Name | Date | Subject | Business Use Only

4. What We Need to Do | Presentation Title | Presenter Name | Date | Subject | Business Use Only Describe the supplemental qualifier elements in metadata and submit the define file Describe the supplemental qualifier domains in metadata and submit the define file Create parent and supplemental qualifier study data sets Some people create and maintain these manually, defining each individual SUPP– domain But ...

5. A Better Way to Do It | Presentation Title | Presenter Name | Date | Subject | Business Use Only • Metadata • Define the suppqual element in its parent domain • Include a suppqual flag variable in your element-level metadata • Create a software module that generates metadata which describes the suppqual domain and suppqual elements from that simple suppqual flag • Study Data • Create two software modules that move suppqual elements between the study parent domain and the study SUPP– domain

6. Why Better for Metadata? | Presentation Title | Presenter Name | Date | Subject | Business Use Only SUPP– is a combination of study data and metadata. It’s better to put metadata information in metadata and study information in study data. Also SUPP-- metadata is very limited to QLABEL and QORIGIN. Defining a suppqual flag in your element-level metadata enables full definition of suppqual elements, with all the metadata attributes. The simple flag enables generation of VLM metadata to define v2 to describe SUPP--. Higher quality definition of SUPP– domains because they are programmatically generated, no more need to remember the many details of the SUPP– domain when you have a new one to define. Maintenance is much easier to add and delete suppqual elements.

7. Suppquals in Study Data | Presentation Title | Presenter Name | Date | Subject | Business Use Only A suppqual_make software module can move elements from a parent domain to its SUPP– domain A suppqual_get software module can move elements from a SUPP– domain to its parent domain The suppqual elements can be created in the parent domain, just like any other element. The suppqual_make module will then move them to the SUPP– domain automatically. When generating TLFs that require suppqual elements, the suppqual_get module can be called to move the suppqual elements from the SUPP– to the parent domain

8. Example Calls to the SUPP macros %suppqual_make( inlib=work,mdlib=md,mdprefix=sdtm_,outlib=sdtm) %suppqual_get( inlib=sdtm,mdlib=md,mdprefix=sdtm,outlib=work) | Presentation Title | Presenter Name | Date | Subject | Business Use Only

9. Why Better for Study Data? | Presentation Title | Presenter Name | Date | Subject | Business Use Only Reusable code is usually better, but especially in this kind of case that is both mechanical and complex TLFs can be generated from pure SDTM, no need for SDTM plus, minus, etc. Just call suppqual_get and start your TLF program code No need to submit a different database to the FDA (SDTM) than you actually used in the TLF programming (SDTM+). Much more transparent and less room for error.

10. An Even Better Way Do Away with the Problem | Presentation Title | Presenter Name | Date | Subject | Business Use Only Remove the SUPP– domains from all the CDISC data standards Replace these with a suppqual flag attribute in the ItemRef element of the define.xml file Add suppqual elements “to the right” in the parent study data domain Systems which cannot handle suppqual elements can ignore them based on the flags in the metadata No more need to move data between parent and SUPP– domains No more need to generate SUPP– domain descriptions in metadata No more need to submit different data structures to the FDA than you actually generated TLFs from

11. Row-Level Suppquals? | Presentation Title | Presenter Name | Date | Subject | Business Use Only Do suppqual elements exist in tall-thin, vertical study data sets? The tall-thin study data sets contain “virtual elements” whose names are in TESTCD and values are in ORRES. If there are suppquals in short-wide, horizontal study data sets, why can’t there be suppquals in tall-thin, vertical study data sets? TESTCD values that fall outside the controlled terminology. These require additional metadata, than exists in the define.xml file now.