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

Supplemental Qualifiers Defined | Presentation Title | Presenter Name | Date | Subject | Business Use Only2  “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.”

Supplemental Qualifier Domain Structure | Presentation Title | Presenter Name | Date | Subject | Business Use Only3 Variable NameVariable Label STUDYID Study Identifier RDOMAIN Related Domain Abbreviation USUBJID Unique Subject Identifier IDVAR Identifying Variable IDVARVAL Identifying Variable Value QNAM Qualifier Variable Name QLABEL Qualifier Variable Label QVAL Qualifier Variable Value (must not be null) QORIGOrigin QEVALEvaluator

What We Need to Do | Presentation Title | Presenter Name | Date | Subject | Business Use Only4  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...

A Better Way to Do It | Presentation Title | Presenter Name | Date | Subject | Business Use Only5  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

Why Better for Metadata? | Presentation Title | Presenter Name | Date | Subject | Business Use Only6  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.

Suppquals in Study Data | Presentation Title | Presenter Name | Date | Subject | Business Use Only7  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

%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 Only8 Example Calls to the SUPP macros

Why Better for Study Data? | Presentation Title | Presenter Name | Date | Subject | Business Use Only9  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.

An Even Better Way | Presentation Title | Presenter Name | Date | Subject | Business Use Only10 Do Away with the Problem  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

Row-Level Suppquals? | Presentation Title | Presenter Name | Date | Subject | Business Use Only11  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.