1) What do you know about CDISC and its standards?
CDISC stands for Clinical Data Interchange Standards Consortium and it is developed keeping in mind to bring great deal of efficiency in the entire drug development process. CDISC brings efficiency to the entire drug development process by improving the data quality and speed-up the whole drug development process and to do that CDISC developed a series of standards, which include Operation data Model (ODM), Study data Tabulation Model (SDTM) and the Analysis Data Model ADaM).
2) Why people these days are more talking about CDSIC and what advantages it brings to the Pharmaceutical Industry?
A) Generally speaking, Only about 30% of programming time is used to generate statistical results with SAS®, and the rest of programming time is used to familiarize data structure, check data accuracy, and tabulate/list raw data and statistical results into certain formats. This non-statistical programming time will be significantly reduced after implementing the CDISC standards.
3) What are the challenges as SAS programmer you think you will face when you first implement CDISC standards in you company?
A) With the new requirements of electronic submission, CRT datasets need to conform to a set of standards for facilitating reviewing process. They no longer are created solely for programmers convenient. SDS will be treated as specifications of datasets to be submitted, potentially as reference of CRF design. Therefore, statistical programming may need to start from this common ground. All existing programs/macros may also need to be remapped based on CDISC so one can take advantage to validate submission information by using tools which reviewer may use for reviewing and to accelerate reviewing process without providing unnecessary data, tables and listings. With the new requirements from updating electronic submission and CDISC implementation, understanding only SAS® may not be good enough to fulfill for final deliverables. It is a time to expand and enhance the job skills from various aspects under new change so that SAS® programmers can take a competitive advantage, and continue to play a main role in both statistical analysis and reporting for drug development.
References:
Pharmasug/2007/fc/fc05
pharmasug/2003/fda compliance/fda055
1) What do you understand about SDTM and its importance?
SDTM stands for Standard data Tabulation Model, which defines a standard structure for study data tabulations that are to be submitted as part of a product application to a regulatory authority such as the United States Food and Drug Administration (FDA) 2.
In July 2004 the Clinical Data Interchange Standards Consortium (CDISC) published standards on the design and content of clinical trial tabulation data sets, known as the Study Data Tabulation Model (SDTM). According to the CDISC standard, there are four ways to represent a subject in a clinical study: tabulations, data listings, analysis datasets, and subject profiles6.
Before SDTM:
There are different names for each domain and domains don’t have a standard structure. There is no standard variables list for each and every domain.
Because of this FDA reviewers always had to take so much pain in understanding themselves with different data, domain names and name of the variable in each analysis dataset. Reviewers will have spent most of the valuable time in cleaning up the data into a standard format rather than reviewing the data for the accuracy. This process will delay the drug development process as such.
After SDTM:
There will be standard domain names and standard structure for each domain. There will be a list of standard variables and names for each and every dataset. Because of this, it will become easy to find and understand the data and reviewers will need less time to review the data than the data without SDTM standards. This process will improve the consistency in reviewing the data and it can be time efficient.
The purpose of creating SDTM domain data sets is to provide Case Report Tabulation (CRT) data FDA, in a standardized format. If we follow these standards it can greatly reduce the effort necessary for data mapping. Improper use of CDISC standards, such as using a valid domain or variable name incorrectly, can slow the metadata mapping process and should be avoided4.
2) PROC CDISC for SDTM 3.1 Format 2?
Syntax The PROC CDISC syntax for CDISC SDTM is presented below. The DATA= parameter specifies the location of your SDTM conforming data source.PROC CDISC MODEL=SDTM;SDTM SDTMVersion = "3.1";DOMAINDATA DATA = results. AE DOMAIN = AE CATEGORY = EVENT;RUN;
3) What are the capabilities of PROC CDISC 2?
PROC CDISC performs the following checks on domain content of the source:
Verifies that all required variables are present in the data set
Reports as an error any variables in the data set that are not defined in the domain
Reports a warning for any expected domain variables that are not in the data set
Notes any permitted domain variables that are not in the data set
Verifies that all domain variables are of the expected data type and proper length
Detects any domain variables that are assigned a controlled terminology specification by the domain and do not have a format assigned to them.
The procedure also performs the following checks on domain data content of the source on a per observation basis:
Verifies that all required variable fields do not contain missing values
Detects occurrences of expected variable fields that contain missing values
Detects the conformance of all ISO-8601 specification assigned values; including date, time, date time, duration, and interval types
Notes correctness of yes/no and yes/no/null responses,
4) What are the different approaches for creating the SDTM 3?
There are 3 general approaches to create the SDTM datasets:
a) Build the SDTM entirely in the CDMS,
b) Build the SDTM entirely on the “back-end” in SAS,
c) or take a hybrid approach and build the SDTM partially in the CDMS and partially in SAS.
BUILD THE SDTM ENTIRELY IN THE CDMS
It is possible to build the SDTM entirely within the CDMS. If the CDMS allows for broad structural control of the underlying database, then you could build your eCRF or CRF based clinical database to SDTM standards.
Advantages:
• Your “raw” database is equivalent to your SDTM which provides the most elegant solution.
• Your clinical data management staff will be able to converse with end-users/sponsors about the data easily since your clinical data manager and the und-user/sponsor will both be looking at SDTM datasets.
• As soon as the CDMS database is built, the SDTM datasets are available.
Disadvantages:
• This approach may be cost prohibitive. Forcing the CDMS to create the SDTM structures may simply be too cumbersome to do efficiently.
• Forcing the CDMS to adapt to the SDTM may cause problems with the operation of the CDMS which could reduce data quality.
BUILD THE SDTM ENTIRELY ON THE “BACK-END” IN SAS
Assuming that SAS is not your CDMS solution, another approach is to take the clinical data from your CDMS and manipulate it into the SDTM with SAS programming.
Advantages:
• The great flexibility of SAS will let you transform any proprietary CDMS structure into the SDTM. You do not have to work around the rigid constraints of the CDMS.
• Changes could be made to the SDTM conversion without disturbing clinical data management processes.
• The CDMS is allowed to do what it does best which is to enter, manage, and clean data.
Disadvantages: • There would be additional cost to transform the data from your typical CDMS structure into the SDTM.
Specifications, programming, and validation of the SAS programming transformation would be required.
• Once the CDMS database is up, there would then be a subsequent delay while the SDTM is created in SAS.
This delay would slow down the production of analysis datasets and reporting. This assumes that you follow the linear progression of CDMS -> SDTM -> analysis datasets (ADaM).
• Since the SDTM is a derivation of the “raw” data, there could be errors in translation from the “raw” CDMS data to the SDTM.
• Your clinical data management staff may be at a disadvantage when speaking with end-users/sponsors about the data since the data manager will likely be looking at the CDMS data and the sponsor will see SDTM data.
BUILD THE SDTM USING A HYBRID APPROACH
Again, assuming that SAS is not your CDMS solution, you could build some of the SDTM within the confines of the CDMS and do the rest of the work in SAS. There are things that could be done easily in the CDMS such as naming data tables the same as SDTM domains, using SDTM variable names in the CTMS, and performing simple derivations (such as age) in the CDMS. More complex SDTM derivations and manipulations can then be performed in SAS.
Advantages:
• The changes to the CDMS are easy to implement.
• The SDTM conversions to be done in SAS are manageable and much can be automated.
Disadvantages:
• There would still be some additional cost needed to transform the data from the SDTM-like CDMS structure into the SDTM. Specifications, programming, and validation of the transformation would be required.
• There would be some delay while the SDTM-like CDMS data is converted to the SDTM.
• Your clinical data management staff may still have a slight disadvantage when speaking with endusers/ sponsors about the data since the clinical data manager will be looking at the SDTM-like data and the sponsor will see the true SDTM data.
5) What do you know about SDTM domains?
A basic understanding of the SDTM domains, their structure and their interrelations is vital to determining which domains you need to create and in assessing the level to which your existing data is compliant. The SDTM consists of a set of clinical data file specifications and underlying guidelines. These different file structures are referred to as domains. Each domain is designed to contain a particular type of data associated with clinical trials, such as demographics, vital signs or adverse events.
The CDISC SDTM Implementation Guide provides specifications for 30 domains. The SDTM domains are divided into six classes.
The 21 clinical data domains are contained in three of these classes:
Interventions,
Events and
Findings.
The trial design class contains seven domains and the special-purpose class contains two domains (Demographics and Comments).
The trial design domains provide the reviewer with information on the criteria, structure and scheduled events of a clinical trail. The only required domain is demographics.
There are two other special purpose relationship data sets, the Supplemental Qualifiers (SUPPQUAL) data set and the Relate Records (RELREC) data set. SUPPQUAL is a highly normalized data set that allows you to store virtually any type of information related to one of the domain data sets. SUPPQUAL domain also accommodates variables longer than 200, the Ist 200 characters should be stored in the domain variable and the remaining should be stored in it5.
6) What are the general guidelines to SDTM variables?
Each of the SDTM domains has a collection of variables associated with it.
There are five roles that a variable can have:
Identifier,
Topic,
Timing,
Qualifier,
and for trial design domains,
Rule. Using lab data as an example, the subject ID, domain ID and sequence (e.g. visit) are identifiers.
The name of the lab parameter is the topic,
the date and time of sample collection are timing variables,
the result is a result qualifier and the variable containing the units is a variable qualifier.
Variables that are common across domains include the basic identifiers study ID (STUDYID), a two-character domain ID (DOMAIN) and unique subject ID (USUBJID).
In studies with multiple sites that are allowed to assign their own subject identifiers, the site ID and the subject ID must be combined to form USUBJID.
Prefixing a standard variable name fragment with the two-character domain ID generally forms all other variable names.
The SDTM specifications do not require all of the variables associated with a domain to be included in a submission. In regard to complying with the SDTM standards, the implementation guide specifies each variable as being included in one of three categories:
Required, Expected, and Permitted4.
REQUIRED – These variables are necessary for the proper functioning of standard software tools used by reviewers. They must be included in the data set structure and should not have a missing value for any observation.
EXPECTED – These variables must be included in the data set structure; however it is permissible to have missing values.
PERMISSIBLE – These variables are not a required part of the domain and they should not be included in the data set structure if the information they were designed to contain was not collected.
7) Can you tell me more About SDTM Domains5?
SDTM Domains are grouped by classes, which is useful for producing more meaningful relational schemas. Consider the following domain classes and their respective domains.
• Special Purpose Class – Pertains to unique domains concerning detailed information about the subjects in a study.
Demography (DM), Comments (CO)
• Findings Class – Collected information resulting from a planned evaluation to address specific questions about the subject, such as whether a subject is suitable to participate or continue in a study.
Electrocardiogram (EG)
Inclusion / Exclusion (IE)
Lab Results (LB)
Physical Examination (PE)
Questionnaire (QS)
Subject Characteristics (SC)
Vital Signs (VS)
• Events Class – Incidents independent of the study that happen to the subject during the lifetime of the study.
Adverse Events (AE)
Patient Disposition (DS)
Medical History (MH)
• Interventions Class – Treatments and procedures that are intentionally administered to the subject, such as treatment coincident with the study period, per protocol, or self-administered (e.g., alcohol and tobacco use).
Concomitant Medications (CM)
Exposure to Treatment Drug (EX)
Substance Usage (SU)
• Trial Design Class – Information about the design of the clinical trial (e.g., crossover trial, treatment arms) including information about the subjects with respect to treatment and visits.
Subject Elements (SE)
Subject Visits (SV)
Trial Arms (TA)
Trial Elements (TE)
Trial Inclusion / Exclusion Criteria (TI)
Trial Visits (TV)
7) Can you tell me how to do the Mapping for existing Domains?
First step is the comparison of metadata with the SDTM domain metadata. If the data getting from the data management is in somewhat compliance to SDTM metadata, use automated mapping as the Ist step.
If the data management metadata is not in compliance with SDTM then avoid auto mapping. So do manual mapping the datasets to SDTM datasets and the mapping each variable to appropriate domain.
The whole process of mapping include: *Read in the corporate data standards into a database table.
• Assign a CDISC domain prefix to each database module.
• Attach a combo box containing the SDTM variable for the selected domain to a new mapping variable field.
• Search each module, and within each module select the most appropriate CDISC variable.
•Then search for variables mapped to the wrong type Character not equal to Character; Numeric not equal to Numeric.
• Review the mapping to see if any conflicts are resolvable by mapping to a more appropriate variable.
• We need to verify that the mapped variable is appropriate for each role.
• Then finally we have to ensure all ‘required’ variables are present in the domain6.
8) What do you know about SDTM Implementation Guide, Have you used it, if you have can you tell me which version you have used so far?
SDTM Implementation guide provides documentation on metadata (data of data) for the domain datasets that includes filename, variable names, type of variables and its labels etc. I have used SDTM implementation guide versions 3.1.1/3.1.2
9) Can you identify which variables should we have to include in each domain?
A) SDTM implementation guide V 3.1.1/V 3.1.2 specifies each variable is being included in one of the 3 types.
REQUIRED –They must be included in the data set structure and should not have a missing value for any observation.
EXPECTED – These variables must be included in the data set; however it is permissible to have missing values.
PERMISSIBLE – These variables are not a required part of the domain and they should not be included in the data set structure if the information they were designed to contain was not collected.
10) Can you give some examples for MAPPING *6?
Here are some examples for SDTM mapping:
• Character variables defined as Numeric
• Numeric Variables defined as Character
• Variables collected without an obvious corresponding domain in the CDISC SDTM mapping. So must go into SUPPQUAL
• Several corporate modules that map to one corresponding domain in CDISC SDTM.
• Core SDTM is a subset of the existing corporate standards
• Vertical versus Horizontal structure, (e.g. Vitals)
• Dates – combining date and times; partial dates.
• Data collapsing issues e.g. Adverse Events and Concomitant Medications.
• Adverse Events maximum intensity
• Metadata needed to laboratory data standardization.
10) Explain the Process of SDTM Mapping?
A list of basic variable mappings is given below *4.
DIRECT: a CDM variable is copied directly to a domain variable without any changes other than assigning the CDISC standard label.
RENAME: only the variable name and label may change but the contents remain the same.
STANDARDIZE: mapping reported values to standard units or standard terminology
REFORMAT: the actual value being represented does not change, only the format in which is stored changes, such as converting a SAS date to an ISO8601 format character string.
COMBINING: directly combining two or more CDM variables to form a single SDTM variable.
SPLITTING: a CDM variable is divided into two or more SDTM variables.
DERIVATION: creating a domain variable based on a computation, algorithm, series of logic rules or decoding using one or more CDM variables.
11) What are the Common Issues in Mapping Dummy corporate standards to CDISC (SDTM) Standards?
• Character variables defined as Numeric
• Numeric Variables defined as Character
• Variables collected without an obvious corresponding domain in the CDISC SDTM mapping. So must go into SUPPQUAL
• Several corporate modules that map to one corresponding domain in CDISC SDTM.
• Dictionary codes not in SDTM parent module, so if needed must be collected in SUPPQUAL.
• Core SDTM is a subset of the existing corporate standards
• Different structure of Lab CDISC Domain e.g. baseline flag.
• Vertical versus Horizontal structure, (e.g. Vitals)
• Additional Metadata needed to describe the source in SUPPQUAL
• Dates – combining date and times; partial dates.
• Data collapsing issues e.g. Adverse Events and Concomitant Medications.
• Adverse Events maximum intensity
• Metadata needed to laboratory data standardization.
Ref: Mapping Corporate Data Standards to the CDISC Model (SAS Paper) by David Parker, AstraZeneca, Manchester, United Kingdom
The Analysis Data Model describes the general structure, metadata, and content typically found in Analysis Datasets and accompanying documentation. The three types of metadata associated with analysis datasets (analysis dataset metadata, analysis variable metadata, and analysis results metadata) are described and examples provided. (source:CDISC Analysis Data Model: Version 2.0)
Analysis datasets (AD) are typically developed from the collected clinical trial data and used to create statistical summaries of efficacy and safety data. These AD’s are characterized by the creation of derived analysis variables and/or records. These derived data may represent a statistical calculation of an important outcome measure, such as change from baseline, or may represent the last observation for a subject while under therapy. As such, these datasets are one of the types of data sent to the regulatory agency such as FDA.
The CDISC Analysis Data Model (ADaM) defines a standard for Analysis Dataset’s to be submitted to the regulatory agency. This provides a clear content, source, and quality of the datasets submitted in support of the statistical analysis performed by the sponsor.
In ADaM, the descriptions of the AD’s build on the nomenclature of the SDTM with the addition of attributes, variables and data structures needed for statistical analyses. To achieve the principle of clear and unambiguous communication relies on clear AD documentation. This documentation provides the link between the general description of the analysis found in the protocol or statistical analysis plan and the source data.
12) Can you explain AdaM or AdaM datasets *7?
3) pharmasug/2005/fdacompliance/fc01.pdf
4) http://www2.sas.com/proceedings/forum2008/207-2008.pdf
5) http://analytics.ncsu.edu/sesug/2006/PO08_06.PDF
6) http://www.lexjansen.com/phuse/2005/cd/cd11.pdf
7) http://www.pharmasug.org/2005/FC03.pdf
Apart from those .. you may also need to prepare for these questions too...
Robert Stemplinger:
1) How many years experience you have working with CDISC standards?
2) What have you been done as per CDISC standards.
(Tell me the usuall process flow or the procedure you have followed regarding implementation of CDISC standards)
3) For how many studies so far you have done SDTM mapping.
4) Have you ever been asked to create specifications for SDTM mapping.
If yes, how do you create specification document for mapping.
5) Do you have experience doing the mapping as per the sponsor standards.
6) a) Tell me few details about the databases you have worked with so far?
b) Which database do you think you had most trouble with? (Inform, Rave, Clintrial or Oracle clinical)
7) How do you validate
a) annotated CRF
b) Specification Document
c) SDTM datasets
d) Case Report Tabulations (CRT-DDS)
8) a) How do you verify all the standards has been maintained as per the SDTM implementation guide?
b) How do you perform validation checks on SDTM v 3.1.1 or 3.1.2 datasets? ( WEBSDM/Open CDISC or PROC CDISC)?
9) What you will do when you find a problem as part of the validation process?
10) What kind of macros you have developed which can be useful in creating SDTM standard datasets?
11) Do you like to create a single program for each domain and then include in a batch program or
just one big program for all the domains.
12) Do you have any experience talking to the client on regular basis? If, yes... share with me your experience?
13) Do you have experience working with people in different time zone?
14) Do you have experience or knowledge about WEBSDM checks or Open CDISC?
15) Do you know PROC CDISC?
16) How do you create Define file (XML or PDF), if you already had experience creating one?
17) If you are working as a validator, how do you communicate with the main programmer?
18) How many weeks time you think you need to finish creating the SDTM datasets? (Just for programming)?
How many weeks, if you also been asked to develop specifications?
19) Is there any sample program you can write or show ... which will give us an idea about you SAS programming skills?
20) What's the challenging part regarding the whole SDTM mapping process?
21) For which domain do you think you always need to be very careful? and why?
22) If I ask you to create SDTM mapping specification document? what documents or files you need and why?
23) Do you know anything about splitting domains. (or Can you split the domains rather than creating one big domain)?
24) What is value level meta data?
25) What do you know about controlled terminology and for which domains you need controlled terminology?
26) What are RELREC and SUPPQUAL domains.
27) Can you share with me any differences you know between implementation guide v3.1.1 and v3.1.2?
28) How do you determine the time line, If the client asked you to provide one for the SDTM mapping conversion process?
29) Is there any way to apply attributes to the SDTM variables other than just manually typing all the details about (length/label/format/informat etc) in an attrib statement?
30) You have been asked to create a domain (not included in implmentation guide) for CRF, what you will do or how do you create one?
Here are few more questions .....exclusive to SDTM Mapping....
CDISC SDTM Questions You might be asked
in an interview
1)
Have you used - -STAT variable anytime. If yes,
why and in what kind of domain you used that variable.
2)
I see in your CV that you have experience in
developing SDTM domains based on IG 3.1.1, V3.1.2 and V3.1.3. Can you share
some of the differences between each version of Implementation Guide?
(Difference between SDTM IG 3.1.1 vs. V3.1.2 and V3.1.2 vs. V3.1.3)
3)
Can you
give me an example of a variable which can be used to group some of the records?
4)
Tell me your experience using - -SPEC variable.
5)
What’s the significance of - -PRESP variable and
tell me what do you know about - -OCCUR variable.
6)
Can you give me an example of a Topic Variable
in:
a)
Intervention Domains
b)
Event Domains
c)
Finding Domains
7)
What’s your experience creating the Related
Records domain (RELREC)? Can you give me few examples of the domains you’ve used
to create a RELREC SDTM domain?
8)
What’s your experience creating the Findings About
(FA) and Clinical Events (CE) domains.
What’s the difference between the FA and CE
domains?
9)
Can you give me few examples of the kind of data
you are going to map it to FA and CE domains.
10)
Why can’t we include Clinical Event data in AE
domain?
11)
What’s your experience creating the custom
domains? How do you create a custom domain?
12)
What you do, if you have a CRF page and all of
the information collected on it aren’t related to any specific SDTM domain.
13)
When do you create a SUPPQUAL or Custom domain?
14)
If you have any experience creating a custom
domain, can you share, what kind of the data that was and what’s the PREFIX you
have used for the domain name.
15)
Tell me about the difficult thing you have to do
or manage when you work as a SDTM standards implementer.
16)
Have you use - -OBJ variable. If you are, in
which domain? And what’s the significance.
17)
Tell me about Required/Expected or Permissible variables
in SDTM domains.
18)
Have you created any Tumor Domains? Can you give use few examples of the tumor
domains you have created.
