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 Name Variable 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)

QORIG Origin

QEVAL Evaluator

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

| Presentation Title | Presenter Name | Date | Subject | Business Use Only8

%suppqual_make(

inlib=work,mdlib=md,mdprefix=sdtm_,outlib=sdtm)

%suppqual_get(

inlib=sdtm,mdlib=md,mdprefix=sdtm,outlib=work)

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.