BASIC USAGE OF CDISC SDTM GUIDANCE RULES TO STANDARDIZED DATASETSWITH SDTM DOMAINS VARIABLES AND VALUESAS PER FDA Vasanth Kumar Kunitala 1,Varun Kumar Sharma 2, Ikanshu Karla 3, Pradeep Moondra 4, Himansu kansara 5, Sandeep Bhat 6 Wincere Solutions Pvt Ltd, B 11, 2 nd Floor Sector 65,Nodia - 201301 Uttar Pradesh. ABSTRACT This article mainly describes the basic usage of CDISC SDTM guidance rules to standardized datasets with SDTM domains variables and values for save the time and controlled processes to submit the regulatory agency. Apply standards from a library of standard domain modules to a blank study specific SDTM CRF.Mainly focus on identify the client standard module and annotation variables to study specific SDTM CRF domain pages. Ensure study CRFs and completed SDTM annotations are stored appropriately in an official repository or client documentation archives as required.maintain a strong working knowledge of Global SDTM standards and its use to ensure compliance and consistency with provided client standard modules.mainly describes the SDTM domains mapping process and SDTM data conversions programs and SDTM domain validation to the consolidating the data for regulatory submissions from different sources within the time. Keywords CDISC, SDTM domains mapping process,sdtm data conversions,sdtm domain validation ABBREVIATIONS FDA ecrf CDISC PRM CDASH LAB SEND ODM SDTM ADaM CRTM BRIDG SUPPQUAL = Food & Drug Administration = Electronic case repot forms = Clinical Data Interchange Standard Consortium = Protocol represent model, Protocol representation group =Clinical data acquisition standards harmonization =Laboratory Data Model =Standard for Exchange of Nonclinical Data = Operational Data Model =Study data tabulation model = Analysis Dataset Model =Case report tabulation model =Biomedical research Integrated Domain group =Supplemental Qualifiers 187
SDS SDTMIG CDMS CT NCI =Submission Data Standards =Study Data Tabulation Model Implementation guide =Clinical data management system =Controlled terminologies =National cancer institute Introduction Clinical Data Interchange Standard Consortium (CDISC) is a global, open, multidisciplinary, non-profit organization that has established standards to support the acquisition, exchange, submission and archive of clinical research data and metadata. Itleadsto the development of standards that improve efficiency while supporting the scientific nature of clinical research 1. In CDISC mainly nine models are involved PRM, CDASH, LAB, SEND, ODM, SDTM, ADaM, CRTM and BRIDG. It recognizes the ultimate goal of creating regulatory submissions that allow for flexibility in scientific content and easily access.study Data Tabulation Model (SDTM) defines a standard structure for study data tabulations (datasets) that are to be submitted to a regulatory authority such as the Food & Drug Administration (FDA) 2. Benefits of SDTM is it s mainly allows reviewers at the FDA to develop a repository of all submitted studies and create standalone tools to access, manipulate and view the study data. Today clinical trial process in pharmacy industryis represented in figure1. SDTM Implementation Guide and Its Versions for Clinical trials are prepared by Submission Data Standards (SDS) Team 3. Study Data Tabulation Model Implementation guide (SDTMIG) has two different versions: i) SDTMIG V3.1.1 ii) SDTMIG V3.1.2. SDTM MAPPING LEVELS SDTM mapping is performed on 3-levels which are described in bellow. I) Domain level SDTM Mapping 1) Special Purpose Domain: -Include subject level data. Examples are: Demographics (DM), Comments (CO), Subject Visits (SV), Subject Elements (SE). 2) General observations:- It was are classified into three classesi) 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 4. Examples: Electrocardiogram (EG), Inclusion / Exclusion (IE),Lab Results (LB),Physical Examination (PE),Questionnaire (QS),Subject Characteristics (SC),Vital Signs (VS). ii)events Class: - Incidents independent of the study that happens to the subject during the lifetime of the study. Examples: Adverse Events (AE), Patient Disposition (DS), Medical History (MH). iii)interventions Class:-Treatments and procedures that are intentionally administered to the subject, such as treatment coincident with the study period, per protocol, or selfadministered (e.g., alcohol and tobacco use). Examples: Concomitant Medications (CM),Exposure to Treatment Drug (EX),Substance Usage (SU). 3) Trial Design Model: - The design of a clinical trial is a plan for what assessments will be done to subjects and what data will be collected during the trial to address the trial's objectives. These datasets fall under this model: Trial Arms (TA) Trial Elements (TE) Trial Visits (TV) Trial Inclusion/Exclusion Criteria (TI) Trial Summary Information (TS) 188
4) Findings about: - Findingsabout Events is a specialization of the Findings General Observation Class 5. As such, it shares all qualities and conventions of Findings observations but is specialized by the addition of the --OBJ variable.it is intended, as its name implies, to be used when collected data represent findings about an Event or Intervention that cannot be represented within an Event or Intervention record or as a Supplemental Qualifier to such a record we can store in finding about 5) Relationship Datasets: - i) SUPPQUAL:-This datasets are used to capture nonstandard variables and their association to parent records. Supplemental Qualifiers are always created in the following situation. Availability of non SDTM standard data which has study data cannot be used in the parent domain. For ex: PE abnormal findings are in SUPPPE. Any dataset in which SDTM variable has text value exceeding the length of 200 character limit. Text value is split such that characters 1-200 are in the parent domain and characters >200 go into the SUPPQUAL domain 6. Only exception in this case: Trial Inclusion/Exclusion (TI) domain. If variable IETEST >200, then the remaining part of text will go into metadata and will linked to the Define.xml.Example for using SUPPQUAL in demography domain is shown in figure2. ii) Relate Records: RELREC is used to describe the relationship between records in two or more dataset. For ex: Adverse Event record related to the Concomitant medication. RELREC is created only per sponsor s request for the following cases. A) Information collected about relationship between concomitant medication and Adverse Event for an observation. B) Any information which has link between multiple datasets and has a scientific rationale behind the link.sponsor Defined or Custom Domain These are the domains usually created in any of the study trial, when we encounter data which is of non SDTM standard and cannot be included in any of the SDTM domain 7. To include this non SDTM standard data into the study domains, sponsor defined or custom domains are created. Criticaldomains core variable is described in table 1. II) Variable level SDTM Mapping SDTM Implementation guide describes the general conceptual model for preparing clinical study data that is submitted to regulatory authorities. The SDTMIG V3.1.2 provides specific domain models, assumptions, business rules, and examples for preparing standard tabulation datasets.sdtm Fundamentals SDTM Variable Classification: 1) Identifier: These are the variable which identifies the study, subject involved, domain and sequence number. 2) Topic: This specifies the focus of the observations 3) Timing: Describes the timing of an observations 4) Qualifier: Contains additional text, values, or results which helps describes the observations5) Rule: This explains the algorithm or calculation involved to derived date- times or visits. This is mainly used in Trial Design Domain. Classification of Qualifier Variables: Qualifier is further categorized into five classes: 1) Grouping Qualifier: These are used to group together a collection of observation. Example: LBCAT. 2) Result Qualifier: This describes the specific result associated with Topic variables for a finding.3) Synonym Qualifier: This variable contains alternate value name for a particular observation. Ex: AETERM, AEMODIFY and AEDECOD. 4) Record Qualifier: This defines additional attributes of an observationina record. Ex: AEREL. 5) Variable Qualifier: This variable further describes the value of an observation in a record. Ex: Lab Units (LBORRESU). Metadata Contents and Attributes Core Variables a) Required: - These variable must be present in the dataset and cannot be null for any record. b) Expected: - These variable must be present in the dataset but can have a null value. c) Permissible: -these variables should be included in variable appropriately and when data is collected. If all records have a null value, then this variable should be dropped. Important domains core variable is described in table 2. III) Value level SDTM Mapping 189
Controlled Terminology is defined as the terminology that controls the value of any variable. (See Appendix C, Page 271 SDTMIG 3.1.2). In almost all of SDTM domains, there are some variables which always have controlled terminology associated with them. If any variable is defined in the SDTMIG with the Controlled Terms or Formats as ACN, NY, STERF, NCOMPLT etc., and then all the values of this variable must be populated using the Controlled terminology.sdtm CT.xls file consist of all value of controlled terminology for SDTM variables and its synonym values 8. Allthe controlledterminologies (CT) in CDISC, SDTM and ADaM should be submittedin upper case with some exceptions, in which case is against human reading habits. Therefore the NCI preferred terms instead of CT terms in CTR would be preferred, e.g., Dose Decreased instead of DOSE DECREASED in the reported tables. While creating SDTM domain programmer must check the value for controlled variable in the file and then provide responses. Date and Time variable --DTC and STDTC All timing variable DTC and STDTC variable fall into either permissible or expected category depending on dataset. As per definition these variable are allowed to have null records. All SAS user defined formats which we want to use in the SDTM mapping process. We should generate them before SDTM mapping and these custom formats are stored in FORMAT table. User defined formats mainly applied for DVGs present in CRF and maintained the CT of SDTM. Format table is show in table 3. As per CDISC guidelines all timing variable must be presented in ISO 8601 format in the entire SDTM domain.iso 8601 Format ISO 8601 Format As per the FDA guidelines all the dates available in SDTM dataset must follow the following format for the date and time presentation in variables such as --DTC and --STDTC. YYYY-MM-DDTHH: MM:SS. CT(**) shown published externally (ex: MedDRA or follow CDISC specific terminology) CT (*) shown that value from a sponsor defined code list. ISO 8601 data and time conversion rule as per SDTM standard example in demography domain is shown in table4. Also as per the format value of this variable must be a character value.iso 8601 Duration Values In any case possible, where instead of dates and time, we encountered the value in the following way for example as shown in the column label Duration recorded then values must be recorded as shown in the column on right labeled as DUR value. Duration recorded --DUR value 2 Years P2Y 10 Weeks P10W 3 Months 10 days P3M10D 2 hours before RFSTDTC -PT2H* SDTM MAPPING PROCESS SDTM mapping is performed by using the following technical process which is mainly described in bellow.1) Direct:-A CDM variable is copied directly to a domain variable without any changes other than assigning the CDISC standard label. 2) Rename: - Only the variable name and label may change but the contents remain the same 9.3)Standardize: - Mapping reported values to standard units or standard terminology. 4) 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. 5) Combining: - directly combining two or more CDM variables to form a single SDTM variable. 6) Splitting: - a CDM variable is divided into two or more SDTM variables. 7) Derivation: - creating a domain variable based on a computation, algorithm, series of logic rules or decoding using one or more CDM variables. In SDTM mapping mainly take care about following thinks. 1) Character variables defined as Numeric 2) Numeric Variables defined as Character 3) Variables collected without an obvious corresponding domain in the CDISC SDTM mapping 4) So must gointo SUPPQUAL 5) several corporate modules that map to one corresponding domain in CDISC SDTM 5) Core SDTM is a subset of the existing corporate standards 6) Vertical versus Horizontal structure, (e.g. Vitals) 7) Dates combining date and times; partial dates 8) Data collapsing issues e.g. Adverse Events and Concomitant Medications 9) Adverse 190
Events maximum intensity 10) Metadata needed to laboratory data standardization.example program for Demography domain SDTM data conversions is show in table5. If we want to mapping for existing domainsfirst 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. Annotated demography CRF with SDTM variables is shown in table6.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 10 ADVANTAGES SDTM is Improve consistency, efficiency and Enhance critical timings. Concentrate on scientific nature of data rather than structure of data. SDTM mainly benefits to theleverage synergies Sponsor to sponsor, vendor-to-sponsor, Sponsor-to-Regulatory Agencyetc.SDTM approved by FDA and SDTM FDA preferred way of submitting clinical study data and Speed up registration process. It streamlining data flow and data interchange between partners and providers. Maintained the Standardization saves time due to controlled processes at Data Management. Main advantages of SDTM 1) the changes to the CDMS are easy to implement. 2) The SDTM conversions to be done in SAS are manageable and much can be automated. Your raw database is equivalent to your SDTM which provides the most elegant solution.3) 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 datasets4) As soon as the CDMS database is built, the SDTM datasets are available.5) 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 11. 6) Changes could be made to the SDTM conversion without disturbing clinical data management processes for make our work to more efficient to before submit the FDA. DISADVANTAGES 1) 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. 2) There would be some delay while the SDTM-like CDMS data is converted to the SDTM. 3) Your clinical data management staff may still have a slight disadvantage when speaking with endusers or 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. 4) This approach may be cost prohibitive. Forcing the CDMS to create the SDTM structures may simply be too cumbersome to do efficiently. 5) Forcing the CDMS to adapt to the SDTM may cause problems with the operation of the CDMS which could reduce data quality. 6) There would be additional cost to transform the data from your typical CDMS structure into the SDTM. And Specifications, programming, and validation of the SAS programming transformation would be required. RESULTS&DISCUSSIONS Using specialized vendor specific software for converting the data from one format to another has pushed the operational costs. Maintenance of specialized vendor specific software with proprietary standards is difficultand Legacy system integration is difficult and time consuming. Consolidating the data for regulatory submissions from different sources takes a lot of time and money. Based upon these many reasons the CDISC was implemented. In that SDTM mainlydevelop for standard data models that 191
support the scientific nature of clinical research and Flexible, easily interpreted regulatory submissions. SDTM increased the model quality and integrity, independent of implementation strategy and platform and Global, multidisciplinary, cross-functional teams. SDTM Maximum sharing of information with other groups and notpromotes any individual vendor or organization 12. Build the SDTM entirely in 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. Build the SDTM entirely on the backend 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.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.Entire clinical data repository frame work is described in figure3. Conclusion The mission of SDTM is to lead the development of global, vendor-neutral, platform-independent standards to improve data quality and accelerate product development in our industry. Before SDTMtheDomains are not in Standard Domain Names and Standard Variables are not presentthen selfready to submit the FDA. We had to familiarize themselves with unique domain names,variables and variable names used in an application it really take very time consuming process. And Pooling, joining datasets awkward, is very difficult. Good portion of review time spent for cleaning up the data but it still Inefficient and error-prone. After SDTM the Domains are with Standard Domain Names and Standard Variables, Standard Variable Names are in standards. Standard Domain Names are Easy to Find Data and Standard Variable Names are Immediate Familiarity with the Data and maintained the Consistency. Minimize the learning curve and reduce the time efficient. SDTM is used to maintain the clinical data standard that helps to manage clinical data in a proper standardized and uniform way with errors. Now a dayit was strongly recommended by FDA; therefore, complying with these guidelines significantly improves the stands and quality of FDA submission to accelerates the FDA review, resulting in a reduced time to process the very huge clinical data. In CDISC under the SDTM data mapping and SDTM conversion is very important to submit the anyclinical documentto FDA. Contact Information Authors contributions this work was carried out in collaboration between all authors in Wincere solutions Pvt Ltd. All authors in Wincere solutions SAS team was read and approved the final manuscript. References 1. CDISC analysis Data model team, the analysis Data model Version 2.1, December 17, 2009. 2. CDISC define.xml team, the Case report tabulation Data Definition Specification Version 1.0.0, February 9, 2005. 3. CDISC analysis Data model team, the Adam basic Data Structure for time-to-event analyses Version 1.0, May 8, 2012. 4. CDISC Submission Data Standards team, the Study Data tabulation model Implementation guide: human Clinical trials V3.1.2, November 12, 2008. 192
5. CDISC analysis Data model team, the analysis Data model Implementation guide Version 1.0, December 17, 2009. 6. CDISC CDASH Project team, Clinical Data acquisition Standards harmonization (CDASH) user guide, V1-1.1, 12 April 2012. 7. CDISC, operational Data model (ODM) Version 1.3.1, Feb. 2010. 8. The CDISC Protocol representation group (PRG), the Protocol representation model Version 1.0, Jan. 2010. 9. The biomedical research Integrated Domain group (BRIDG) model Version 3.1, Feb. 2012 10. The CDISC Study Design model in Xml (SDM-Xml) standard Version 1.0 11. The CDISC Share team, Share Project overview Version 1.0, 5 September 2012, http://www.cdisc.org/stuff/contentmgr/files 12. Health informatics harmonized data types for information interchange, ISO 21090:2011 13. The CDISC Share leadership team, Summary of CDISC Share requirements, November 2011, http://www.cdisc.org/stuff/ Table1:- Criticaldomains core variable S.No Domains Required(present, non-missing) Permissible(present or non- present and non-missing or missing ) Expected (present nonmissing or missing ) 1 CM (One record per recorded medication occurrence or constant-dosing interval per subject.) 2 TA(One record per planned Element per Arm) 3 TE (One record per planned Element) CMSEQ CMTRT (Reported Name of Drug, Med, or Therapy) STUDYID DOMAIN ARMCD (Planned Arm Code) ARM (Description of Planned Arm) TAETORD (Order of Element within Arm) ETCD (Element Code) EPOCH (Epoch) STUDYID (Study Identifier) DOMAIN (Domain Abbreviation) ETCD (Element Code) ELEMENT (Description of Element) TESTRL (Rule for Start of Element) CMGRPID CMCAT CMSCAT CMPRESP CMOCCUR CMSTAT CMREASND - TEENRL (Rule for End of Element) TEDUR (Planned Duration of Element) - ELEMENT (Description Element) TABRANCH (Branch) - of 4 TV(One record per STUDYID VISIT ARMCD (Planned 193
planned Visit per Arm) 5 SUPP (One record per IDVAR, IDVARVAL, and QNAM value per subject ) 6 RELREC (One record per related record, group of records or datasets ) DOMAIN VISITNUM TVSTRL STUDYID (Study Identifier) RDOMAIN (Related Domain Abbreviation) USUBJID (Unique Subject Identifier) QNAM (Qualifier Variable Name) QLABEL (Qualifier Variable Label) QVAL (Data Value) QORIG (Origin ) STUDYID RDOMAIN IDVAR (Identifying Variable) RELID (Relationship Identifier) VISITDY ARM TVENRL - - Arm Code) QEVAL (Evaluator) IDVAR (Identifying Variable) IDVARVAL (Identifying Variable Value) USUBJID (Unique Subject Identifier) IDVARVAL (Identifying Variable Value ) RELTYPE (Relationship Type) Table2:- Important domains core variable Domains Required(present, nonmissing) Permissible(present or nonpresent and non-missing or missing ) Expected (present missing ) non-missing or CT DM(One record per subject ) AE(One record per adverse event per subject ) DOMAIN STUDYID SUBJID SITEID USUBJID SEX ARM COUNTRY DOMAIN STUDYID SITEID USUBJID AESEQ AETERM AEDECOD INVID INVNAM BRTNDTC ETHNIC DMDTC DMDY AECAT(category for adverse event) AESCAT(subcategory for adverse event) AELOC(location of event) AEOUT(outcome of adverse event) AESCAN(involves cancer) AESDTH(result in death) AGE AGEU RACE RFSTDTC RFENDTC 194 AEBODSYS(body system ) AESER(serious event) AESEV(severity) AEACN(action taken with study treatment) AEREL(causality) AESTDTC(start date/time of ae) AEENDTC(end date/time * NY *
AESHOSP(prolongs hospitalization) of ae) VS (One record per vital sign measurement per time point per visit per subject) VSSEQ VSTESTCD VSTEST VSLOC(location of VS measurement) VISIT(visit name) VISITDY(planned study day of visit) VSTPTNUM(planned time point number) VSSTAT(completion status) VSREASND(reason not performed) VISITNUM(visit number) VSDTC(date/time of measurements) VSBLFL(baseline flag) VSORRESU(original units) VSSTRESC (character result) VSSTRSN (numeric result) VSSTRESU (standard units) MH(One record per medical history event per subject ) LB(One record per analyze per planned time point number per time point reference per visit per subject ) MHSEQ MHTERM LBTESTCD LBSEQ LBTEST MHPRESP (MH event prespecified) MHOCCUR (MH occurrence) MHSTAT ( completion status) LBFAST (Fasting Status ) LBSTAT (Completion Status) LBREASND(Reason Test Not Done ) LBDRUFL (Derived Flag ) LBBLFL(Baseline Flag) LBCAT(Category for Lab Test ) LBORRES(Result or Finding in Original Units ) LBORRESU( Original Units ) - NY NY ND EG(One record per ECG observation per time point per visit per subject ) FA(One record per finding per object per time point per time point reference per visit per EGSEQ EGTESTCD EGTEST FAOBJ (Object of the Observation) FATEST (Findings About Test Name) EGGRPID (Group ID) EGCAT (Category for ECG) EGPOS (ECG Position of Subject) EGORRESU(Original Units) EGMETHOD(Method of ECG Test) FAORRESU FASTRESN FASTRESU FASTAT FAREASND 195 EGORRES(Result or Finding in Original Units) EGSTRESC(Character Result) EGBLFL(Baseline Flag) VISITNUM(Visit Number) EGDTC(Date/Time of ECG) FAORRES FASTRESC VISITNUM ISO 8601
subject ) FATESTCD Table3:- Format table for SDTM variable values with CT S,NO Format name 1 $race row1 row2 row3 row4 2 $AE 1 2 3 4 5 7 3 $RESULT YES no UNKN ASIAN ASIAN BLACK ASIAN WHITE OTHER MILD MODERATE SEVERE LIFE THREATENING DEATH- RELATED Y N U Table4. ISO 8601 data and time conversion rule as per SDTM standard example in demography domain INPUT Date of Collection Time of Collection 19870601 900 198706 900 1987 900 OUTPUT DMDTC (Date/time of demographic data collection) 1987-06-01T9:00 1987-06--T9:00 1987T9:00 Table5:- Example program for Demography domain SDTM data conversions Data DM(keep=STUDYID DOMAIN USUBJID ARM SUBJID RFSTDTC RFENDTC DMDTC BRTHDTC SITEID INVID INVNAM AGE DMDY AGEU SEX RACE ETHNIC ARMCD COUNTRY DMDTC BRTHDTC DMDY); length STUDYID $20. DOMAIN $2. USUBJID ARM $14. SUBJID $3. RFSTDTC RFENDTC DMDTC BRTHDTC $20. SITEID INVID $6. INVNAM $30. AGE 3. DMDY 4. AGEU $10. SEX ARMCD $1. COUNTRY 196
$3. ; Set XXX.demo; STUDYID=STUDY; domain=dcmname; USUBJID=TRIM(STUDY) '.' PT; ARM='Drug 10 mg'; SUBJID=PT; RFSTDTC='2003-04-29'; RFENDTC='2003-10-12'; SITEID=INVSITE; INVID=' '; INVNAM=' '; AGE=. ; AGEU=SUBSTR(AGERG,9,5); SEX=GENDER; if sex = null thendelete; race=race; ethnicity=ethnic; ARMCD='DRUG10'; COUNTRY='USA'; DMDTC=' '; BRTHDTC=' '; DMDY=.; run; proccdisc model=sdtm; SDTM SDTMVersion = "3.1"; DOMAINDATA DATA = dmv DOMAIN = DM CATEGORY = SPECIAL; run; procprint;run; ods csvall file='dm.csv'; procprint; run; ods csvall close; Table6:- Annotated demography CRF with SDTM variables DCM BROWN VIEWS DARK PINK QUESTION BLUE DVG DARK GREEN VISIT 1 SCREENING VISIT DCM: (INFORMED_CONSENT) INFORMED CONSENT VIEW: (IC) Date Consent form for Screening was signed: / / 2 0 0 7 ICDT DD MM YYYY 197
DCM: (DEMOGRAPHY) DEMOGRAPHY VIEW: (DM) Date of birth: / / 1 9 BRTHDT DD MM YYYY OR If date of birth is unknown, enter estimated age: AGE AGEU yrs Race: RACE (Please tick only one box. If mixed race, please tick Other and specify)? Caucasian <RACE> #1? African? Asian? Other, please specify: SCORRES SCTEST HEIGHT HEIGHTU Height (cm): Table7:- DS_ Domain SDTM mapping in excel 198
Figure1:- Flow chart of today clinical trial process in pharmacy industry Figure2:- Example for using SUPPQUAL in demography domain 199
Figure3:- Flow chart diagram for entire clinical data repository frame work 200