CDISC Journal. The Major Impacts of CDISC on Clinical Data Lifecycle. By Chengxin Li, Nancy Bauer, Boehringer Ingelheim Pharmaceuticals, Inc.

Transcription

1 CDISC Journal Clinical Data Interchange Standards Consortium oc tober 2012 The Major Impacts of CDISC on Clinical Data Lifecycle By Chengxin Li, Nancy Bauer, Boehringer Ingelheim Pharmaceuticals, Inc. Abstract CDISC has defined a series of standards covering the entire clinical data lifecycle, from data collection to submission. This paper describes the major impacts of CDISC on the clinical data lifecycle within data management and programming such as interoperability, metadata repository, controlled terminology, formats, traceability, programming model, macrotized programming, and object oriented clinical programming. This paper reflects authors current understandings of CDISC and visions of clinical data processing. 1. Introduction The Clinical Data Interchange Standards Consortium (CDISC) 1 has defined a series of standards to support the collection, exchange, submission and archive of clinical research data and metadata. The CDISC data models include Clinical Data Acquisition Standards Harmonization (CDASH) [1] for data collection, Study Data Tabulation Model (SDTM) [2] for tabulation data submission, Analysis Data Model (ADaM) [3] for analysis dataset, Case Report Tabulation Data Definition Specification (DEFINE. XML) [4] for metadata of submission data. CDISC has also specifically established analysis data model for adverse event with the ADaM Data Structure for Adverse Event Analysis (ADAE) [5], analysis data model for time to event with the ADaM Basic Data Structure for Time-to-Event Analyses (ADTTE) [6]. To assist in the implementation, CDISC has been developing implementation guides such as Data Tabulation Model Implementation Guide (SDTM IG) [7], Analysis Data Model (ADaM) Implementation Guide (ADaM IG) [8], and Clinical Data Acquisition Standards Harmonization (CDASH) User Guide (CDASH UG) [9]. The LAB Model is defined separately for the transfer of clinical laboratory data, consisting of the LAB Base Model, the XML Schema Implementation of the Base Model, the Microbiology Extension, and Reference Range Model [10]. To achieve standardization and interoperability, CDISC, actively with National Cancer Institute (NCI) Enterprise Vocabulary Services (EVS), defines Controlled Terminologies (CT) standard 2 for CDISC data standards. CDISC also provides standard format for interchange and archive of the metadata and data for clinical study with the Operational Data Model (ODM) [11], research protocol planning and design with the Protocol Representation Model (PRM) [12], and the bridge protocol among the homogeneous and heterogeneous systems with the Biomedical Research Integrated Domain Group (BRIDG) Model [13], 1

2 e.g., for the case of exchange information between Health Level Seven (HL7) Electronic Health Record (EHR) system and CDISC system. With the ODM, BRIDG and the PRM (the subset of BRIDG), CDISC inherits with interoperability, especially with semantic interoperability. The BRIDG model, a protocol-driven domain analysis model (DAM), can be used for both application development and message specification. The shared views in BRIDG are expressed with visual diagrams of the industry standard Unified Modeling Language (UML) 3 widely used in the object-oriented software engineering field. In the current BRIDG Project the primary focuses are specifying data structures, business processes, and relationships, which correspond to three categories of diagrams in UML: static diagrams (e.g., class diagram for defining data structures), dynamic diagrams (e.g., activity diagram for describing workflows), and interaction diagrams (e.g. communication diagram for messaging). Trial design is the starting point in a clinical trial and has been specified in several CDISC standards, including the CDISC Study Design Model in XML (SDM-XML) standard [14] (an extension to core ODM), SDTM, and PRM. However, since the data lifecycle is initiated from data collection, the trial design is out of scope of this paper. The FDA clinical data review is also beyond scope of this paper as it s outside of the sponsor s coverage. This paper discusses the data lifecycle, interoperability, metadata repository, controlled terminology, formats, traceability, and submission. This paper also depicts the CDISC impacts on programming in clinical data processing. 2. Data Lifecycle CDISC covers the whole data lifecycle of clinical research, publishing and supporting a series of clinical data standards that make the clinical data processes as metadata-driven from collection to submission. The clinical data lifecycle is illustrated in Figure 1. Collection Storage Transformation Analysis Submission Lifecycle CRF Clinical Database/Data Warehouse SDTM Domain ADaM Dataset Clinical Trial Report/TFL ectd Standard and Document CDASH Standard SDTM Standard ADaM Standard Study SAP, including TOC and Display Shells DEFINE Standard Fig. 1: The Clinical Data Lifecycle 2 CDISC.org

3 The clinical data is initiated from data collection with CDASH compliant Case Report Forms (CRF) through data collection instruments such as Remote Data Capture (RDC) or Electronic Data Capture (EDC). The collected raw patient data is stored in Clinical database or clinical data warehouse. The outputs (e.g., Oracle Clinical (O*C) data) are the inputs to transformation program to generate SDTM compliant domains. Based on SDTM domains, following the analysis plan and table of contents defined in a Statistical Analysis Plan (SAP), the analysis datasets can be defined and created. The ADaM model including the newly defined ADAE and ADTTE support the definition and structure of the analysis datasets. Based on analysis datasets, further following display templates defined in the technical SAP, the tables, figures, and listings (TFLs) are produced. In the clinical data lifecycle, it is a very important step to prepare and submit qualified data and metadata to regulatory authorities (e.g., FDA). The electronic Common Technical Document (ectd) contains the content and structure of clinical data within a submission. The Define.XML document specifies the standard for providing Case Report Tabulations Data Definitions and analysis in an XML format for submission. For the submitted data and metadata, compliance checks are required. 3. Data Management 3.1 Interoperability The interoperability is the ability of exchanging and processing data successfully among systems. HL7 has categorized interoperability as technical interoperability, semantic interoperability, and process interoperability [15]. Table 1 summarizes this HL7 hierarchical interoperability concept used in CDISC and adopted by FDA. Table 1. CDISC Interoperability Type Requirement Standard 4 Technical Interoperability Integrity of Data Transportation SAS XPORT Transport Format, ODM Semantic Interoperability Process Interoperability Technical Interoperability + Integrity of Understanding Semantic Interoperability + Integrity of Processes Controlled Terminology, BRIDG Not Available (dynamic diagrams need to be defined in BRIDG) For submission, the current goal is to achieve semantic interoperability. The metadata repository (MDR) solution and submitted data standard compliance are currently the best approaches to achieve this goal. 3.2 Metadata Repository (MDR) Traditionally, metadata are maintained internally by the individual sponsor using Excel as the tool. This has been resulting in, High cost to develop, implement, and maintain; Low efficiency in use; and Shortage of interoperability. 3 CDISC.org

4 To resolve the above problems, esp. to support computable semantic interoperability, the CDISC initialized CDISC SHARE (CDISC Shared Health And Research Electronic Library) project [16]. Based on BRIDG and ISO abstract data types [17], the CDISC SHARE project intended to build up a global, industry-wide shared semantic library (SHARE MDR) with unambiguous data element definitions for safety and efficacy and other areas related to protocol-driven research. CDISC SHARE crosses the entire clinical data lifecycle from data collection to submission. To achieve the CDISC SHARE goals of improving biomedical research and its link with healthcare, it is a very important step to develop an open source software for CDISC world to effectively use the SHARE MDR. According to the CDISC SHARE Requirements Summary document [18], the CDISC SHARE system should support metadata model, user management, work items and managed objects, printing and exporting, searching and browsing, etc. The metadata model is the core of the CDISC SHARE system supporting BRIDG and ISO datatypes, SDTM and CDASH standards, and CDISC controlled terminologies. It is expected that the availability of CDISC SHARE MDR system should be another milestone to achieve semantic interoperability. 3.3 Controlled Terminology The CDISC Terminology Team has been developing controlled terminologies working with representatives of governments, organizations, and companies. The production terminology is published by the National Cancer Institute s Enterprise Vocabulary Services (NCIEVS) and available at The table 2 summarizes the controlled terminologies (CT) of CDASH, SDTM, and ADaM. Table 2. The Requirements for Controlled Terminology CDISC Data Model CDASH SDTM Control Terminology Requirements Under development; Acceptable to use a subset of SDTM CT; Common CT subsets available for CM, DA, EG, EX, VS in CDASH v1.1 Extensible or non-extensible, e.g., non-extensible CT: SEX(M/F/U/UN); CT should be submitted in upper case text except: (a) the CT from external reference and conforming to the external reference (e.g., MedDRA); (b) units (e.g., mg/dl); (c) test names (e.g., LBTEST= Glucose ). ADaM ADaM CT available for PARAMTYP, DATEFL, TIMEFL, DTYPE; May carry over SDTM CT if the variable name from SDTM, e.g., SEX, RACE, AGEU. 4 CDISC.org

5 The CT standard defines the CT structure as codes, names, values, synonyms, definitions, and preferred terms. The NCI preferred terms can be used for displays in CTR. Figure 2 shows one SDTM CT example. Fig. 2: The Structure of SDTM Controlled Terminology The CT adoption is the critical step to achieve standardization and semantic interoperability, and also useful for pooled analyses. According to the FDA submission draft guidance [19], although some CTs are extensible, the extensible codelist from sponsor for a submission are discouraged. The sponsor should contact CT maintenance organization earlier so that the sponsor terms can be included in the standard CT. 3.4 Formats Traditionally the sponsor character formats and numeric formats were defined and attached to the corresponding variables during the trial setup or to the analysis datasets. However, in the CDISC world, it was required that no sponsor formats should be associated in SDTM and ADaM datasets. And further, as stated in table 2, all the controlled terminologies in SDTM and ADaM should be submitted in upper case with some exceptions, in which case is against human reading habits. Therefore, the NCI preferred terms (PT) instead of CT terms in CTR would be preferred, e.g., Dose Increased instead of DOSE INCREASED in the reported tables. From another perspective, in the CTR some reported items with sorting order are also required. The SDTM variable list, which may need sort order in CTR, are DM.RACE, DM.SEX, DM.ETHNIC, AE.AEACN, AE.AESEV, AE.AEOUT, AETOXGR, CE.CESEV, EGPOS, VSPOS, and optionally all the variables with (NY) codelist. 5 CDISC.org

6 Below is a format proposal for CDISC compliant trials using O*C: i. Define char formats with CT as short values (data values), PT as long values (display values), e.g. display format for RACE in figure 3, Fig. 3: The Display Format for RACE Variable ii. Derive sort order format based on term sequences whenever practical, e.g. display format for RACE in figure 4. Please note that not all variables need display sort order format. Fig. 4: The sort Order Formate for RACE iii. During trial O*C discrete value group (DVG) setup, pick up the above defined char format, thus the char format attached to the corresponding variable in O*C. iv. During transformation from O*C data to SDTM domain, the format is detached and CT are put as values. v. For the easy usage, the study DVG lookup table is generated. The application interface of DVG lookup table is standardized, containing STUDYID, DOMAIN, SAS variable name (SASVARNM), format name (FMTNM), format category (FMTCAT), sequence number (SEQNUM), short value and long value, etc. See figure 5 for one such example. 6 CDISC.org

7 Fig. 5: The Standard API of DVG Lookup With the study based DVG lookup table, the programmer when programming the TFLs can programmatically or manually locate which format should be applied by domain name (DOMAIN), variable name (SASVARNM), purpose of use (FMTCAT), and further referring to the format contents (SHORTVAL and LONGVAL). To keep traceability from CTR to ADaM, the sort order variables and decode variables should be added to ADaM dataset. This applies especially to those SDTM variables carrying over to ADaM with harmonization principle, e.g., in ADSL, DM.RACE with RACEN and DM.SEX with SEXN/SEXDECOD. 3.5 Traceability CDISC takes a strong position regarding traceability when building AdaM files from SDTM. Traceability is built by clearly establishing the path between an element and its immediate predecessor. The full path is traced by going from one element to its predecessors, then on to their predecessors, and so on, back to the SDTM domains, and ultimately to the data collection instrument. (p7, CDISC Analysis Data Model Version 2.1) The main purpose of traceability is to facilitate reviews. From submitted metadata, the reviewers can fully and easily understand how the sponsor handled the data, end-to-end tracing from P value in CTR back to SDTM, and further back to the CRF. With respect to traceability designed in CDISC, SDTM presents as the foundation. ADaM standard facilitates the traceability to SDTM. CDASH design is harmonized with SDTM, therefore assures the end-to-end traceability from SDTM to CDASH. Table 3 clarifies the requirements of CDASH, SDTM, and ADaM to guarantee the traceability from ADaM to SDTM, and then to CDASH, especially summarize how to implement traceability when producing ADaM datasets. 7 CDISC.org

8 Table 3. The Requirements for Traceability CDISC Data Model CDASH SDTM ADaM Requirements CDASH is harmonized with SDTM. If collected exactly as needed for SDTM, use SDTM variable name on CRF. In each CDASH domain, CDASH lists the SDTM-based variable names defined in the SDTM IG. In this way, CDASH assures end-to-end traceability from SDTM to CDASH. CDASH also has some CDASH specific variables, e.g, *DAT and *TIM variables, which are the base for SDTM *DTC variables. Foundation (over 30 domains defined in SDTM IG v3.1.2) Metadata traceability and data point traceability clarify how the analysis datasets were created to assist review. If using SDTM variables, follow harmonization principle: same name, same meaning, and same values. Include as much supportive SDTM variables from SDTM as needed to facilitate transparency and clarity of derivations and analysis for statistical reviewers. Include all observed and derived rows for a given analysis parameter to provide the most flexibility for the reviewers in testing the robustness of an analysis. Include SRCDOM, SRCVAR, SRCSEQ, and ASEQ to support data point traceability whenever practical. 3.6 Submission There are more challenges and thus requiring more efforts on submissions with CDISC than ever before. To prepare qualified submission data, it needs to check the conformities not only to business processes, but also to the data standards. Along with several submission documents from FDA, e.g., Study Data Specifications, 6 Guidance for Industry-Providing Regulatory Submissions in Electronic Format Standardized Study Data, 7 CDER Common Data Standards Issues Document, 8 CDISC has defined metadata standard of submitted data- Define.xml. It is most desirable to achieve semantic interoperability in standardized study data submissions. It is possible and feasible to achieve this semantic interoperability by complying with CDISC standards, e.g., by use of controlled terminologies and consistently defined metadata. The consistently defined metadata across studies is helpful not only to pooled analyses but also for submitted data to be loaded into FDA JANUS data warehouse. There are several tools used for compliance checks with the submitted data. One typical such software package is so-called OpenCDISC Validator, 9 which is an open source tool sponsored by FDA. The metadata is as important as data itself. The sponsor should spend as much time to produce highly qualified metadata to facilitate reviews, thus improving the efficiency of the regulatory review process to consequently achieve the goal of speeding up drug approval. 8 CDISC.org

9 4. Programming Methodology 4.1 Programming Model By introducing SDTM and ADaM, the programming model is significantly changed. The analysis datasets are required to be derived from SDTM domains rather than from company proprietary data structures. The scenario is illustrated in figure 6. ecrf ecrf Raw Data including external LAB data, ECG data, etc. Analysis Datasets Evolving Raw Data including external LAB data, ECG data, etc. SDTM Domains ADaM Datasets CTR CTR Fig. 6: The CDISC Programming Model Figure 6 indicates that in CDISC programming model the ADaM datasets should be only based on SDTM domains and SDTM be fully reflected collected data in CRF. In this way the end-to-end traceability is ensured from ADaM to SDTM and further to collected raw data. In SDTM domains, not only required and expected variables but also all the permissible variables collected or possibly derivable should be mapped to SDTM. Therefore, it would be preferable if the CRF design should be CDASH compliant as the CDASH is designed to be harmonized with SDTM. The key difference between traditional CRF and CDASH compliant CRF lies in the traditional CRF as time sequences (visits) oriented, however, CDASH CRF as domains (topics) oriented. As stated in ADaM, for a study, the ADaM subject-level analysis dataset (ADSL) describing the attributes of subject is required at minimum. The optimum number of ADaM basic data structure (BDS) datasets should be created to perform various analyses. It should be noted that not every analyses need to have a corresponding ADaM dataset, but the key endpoint analyses, inferential analyses, and complicated 9 CDISC.org

10 analyses which are not easy for reviewer to follow the logic should be designed with ADaM datasets. Some simple displays can be directly coded from SDTM domains such as data summary displays which do not need derivation for timing widow, nor imputation for missing data, nor derivation with complicated algorithms. Along with meeting analysis requirements and ADaM compliance, cost-effectiveness should be another factor when specifying ADaM datasets. It is very important to define what datasets and how many datasets are needed for an optimal solution. As addressed in ADaM, some discrepancies are allowed in population and baseline variables between SDTM and ADaM owning to different requirements from different parties. In our experiences, it shall be a better choice not to implement population flags in SDTM but only in ADaM. In SDTM submission, the Center for Drug Evaluation and Research (CDER) expects baseline flags to be populated in some finding domains: LB, VS, EG, PC, MB and MS. One option is to derive those baseline flags by default with the last non-missing value before or on reference start date. If ADaM differs with SDTM in baseline, differentiate them with variables of ABLFL, BASE, BASETYPE, and population flags in ADaM datasets. Besides the traceability (metadata traceability and data point traceability), ADaM also requires analysis-ready wherever possible, which makes the least efforts on the CTR/TFL programming. To produce an analysis result, ideally one should just subset the data from a single ADaM dataset and then invokes a SAS procedure. When designing ADaM datasets, besides complying with ADaM general rules, the designer shall keep in mind of facilitating reviews as a principle. The ADaM dataset should include variables which are of interests to reviewer although not used in analyses, in which case may result in variables redundancy, e.g. inclusion of core variables such as SITE, COUNTRY, SEX, AGE, RACE, BASELINE, and population flags not only in ADSL but in BDS datasets as well. 4.2 Macrotized Programming In CDISC data processing, if the input and output are both standardized, the conversion from input to output can be macrotized with SAS. As indicated in figure1, in the clinical data lifecycle there are three programming sections: SDTM domain transformation, ADaM dataset generation, and TFL creation. For the SDTM transformation, the input is SDTM harmonized collected raw data, and the output is SDTM domains. Under this scenario, one macro has been successfully implemented to generate SDTM domains [20]. The macros for safety analyses are traditionally widely implemented with defined display templates, e.g., the company level LAB macro, AE macro, etc. In CDISC, correspondingly, SDTM defines AE, LB, EG, VS, EX, DS domains related to safety evaluations, and ADaM WG defines ADAE dataset used for AE incidence data analyses. To transition to CDISC standard compliance, the macros for safety analyses need to be adjusted to SDTM domains as inputs, ADAE or ADaM BDS compliant datasets as outputs. Based on the output analysis datasets, the macros for safty analyses can be further updated to produce CTR with standard TFL templates. 10 CDISC.org

11 It s much more complicated to generate efficacy analysis datasets since the study SAP is also one important input. The SAP is quite different across the therapeutic areas. CDISC has been defining therapeutic area standards, but mainly focus on data collection fields at present. Although the multiplicity exists in efficacy analysis, it can still be standardized with primary endpoints, imputations, and derivations within a specific therapeutic area. According to our experiences, a macro can still be implemented for generating a specific ADaM dataset within a specific therapeutic area, and a further macro can be implemented for a standard TFL shell. This is especially true to the trials within the same project. Standard data structures lead to standard programs. For a process, if input and output can be standardized, it should be implemented with a macro as a general rule. 4.3 Object Oriented Programming The current SAS programming methods adopted in clinical trials conceptually belong to structured programming category, represented by macros for repeated blocks, and DATA STEP, IF-THEN-ELSE, CASE -WHEN, DO-LOOP structures for sequence and condition processes. However, in other areas, e.g., in computer science or information technology, the object oriented programming has become dominated for decades. SAS itself has equipped with SAS/SCL (SAS Component Language), 10 allowing programmers to create and compile object-oriented programs under the SAS Component Object Model (SCOM) framework. Under this framework, the Base/SAS and SAS/Macro statements can be submitted and executed. And further with SAS/AF (SAS Applications facility), 11 the customized desktop GUI applications can be created by a library of fully objected oriented drag-and-drop widgets. With SAS/AF, customer SCL programs can be attached as needed. CDISC defines SDTM based on domain concept. CDASH designed as topic oriented other than traditionally time sequence oriented is another significant step conceptually towards object oriented. Together with BRIDG model represented with UML, SDTM has been facilitated with object-oriented schema. CDISC is aiming at all CDISC data models should be BRIDG harmonized although currently only on CDASH and SDTM, and on the data structures (static semantics). The BRIDG model needs to be extended to ADaM standard such that the ADaM metadata can be expressed with UML diagram architecture. This requires BRIDG should be extended to various processes (dynamic semantics). From there programmers with SAS/SCL can create ADaM datasets from SDTM domains and further generate CTR with objected-oriented methods. Hence, the adopting next generation programming-- object oriented programming with SAS in clinical trial programming becomes technically feasible. Figure 7 illustrates the layers of object oriented architecture in CDISC. 11 CDISC.org

12 TFL ADaM Dataset SDTM Domain BRIDG Model UML Fig. 7: The Layers of Object Oriented Architecture 5. Discussion As shown in figure 1, the data collection is standardized with CDASH on CRF and the output standardized with SDTM, so the transformation from collected raw data to SDTM domain datasets can be handled by a SAS macro. On the other hand, SAS has rich dataset manipulation functions like subsetting, merging, sorting with data step or SAS SQL, thus SAS based data warehouse can be set up. It would become redundant with, for instance, O*C data manipulation, especially with RDC and EDC instruments. As also indicated in figure 1, CDISC chain is broken at the CTR section. The common display shells should be included in the CDISC roadmap, at least display shells for safety analyses and subject set analyses should be doing so. Collaborating with other stakeholders, 12 CDISC should speed up BRIDG model development, harmonizing not only for static content but also for dynamic content of the CDISC standards. Starting from BRIDG model, a working group should be set up, e.g., by FDA/PhUSE, to investigate the objectoriented programming applications in clinical data processing. Meanwhile, SAS should incorporate BRIDG into SAS libraries or procedures as well. Acknowledgement Great thank Jingwei Gao for all the supports to this paper. Endnotes CDISC defined or used. 5. ASEQ will be added in the next version of ADaM IG used for the traceability between consecutive ADaM datasets (ADTTE standard v.1.0, p6). 12 CDISC.org

13 6. UCM pdf UCM pdf The BRIDG project stakeholders include the Clinical Data Interchange Standards Consortium (CDISC), the HL7 Regulated Clinical Research Information Management Technical Committee (RCRIM TC), the National Cancer Institute (NCI) and its Cancer Biomedical Informatics Grid (cabig ), and the US Food and Drug Administration (FDA). References 1. CDISC CDASH Team, the Clinical Data Acquisition Standards Harmonization (CDASH) v1.1, 18 January CDISC Submission Data Standards Team, the Study Data Tabulation Model v1.1, April 28, CDISC Analysis Data Model Team, the Analysis Data Model (ADaM) Version 2.1, December 17, CDISC define.xml Team, the Case Report Tabulation Data Definition Specification Version 1.0.0, Feburary 9, CDISC Analysis Data Model (ADaM) Team, the Analysis Data Model (ADaM) Data Structure for Adverse Event Analysis Version 1.0, May 10, CDISC Analysis Data Model (ADaM) Team, the ADaM Basic Data Structure for Time-to-Event Analyses Version 1.0, May 8, CDISC Submission Data Standards Team, the Study Data Tabulation Model Implementation Guide: Human Clinical Trials V3.1.2, November 12, CDISC Analysis Data Model (ADaM) Team, the Analysis Data Model (ADaM) Implementation Guide Version 1.0, December 17, CDISC CDASH Project Team, Clinical Data Acquisiton Standards Harmonization (CDASH) User Guide, V1-1.1, 12 April CDISC Laboratory Data Team (LAB), Laboratory Data Model for Base Model Version 1.0.1, Schema Version Microbiology Extension Review Version, Reference Range Model Review Version, April CDISC, Operational Data Model (ODM) Version 1.3.1, Feb The CDISC Protocol Representation Group (PRG), The Protocol Representation Model Version 1.0, Jan The Biomedical Research Integrated Domain Group (BRIDG) Model Version 3.1, Feb The CDISC Study Design Model in XML (SDM-XML) standard Version Health Level Seven EHR Interoperability Work Group, Coming to Terms: Scoping Interoperability for Health Care, Feb. 2007, The CDISC SHARE Team, SHARE Project Overview Version 1.0, 5 September 2012, /0/70e1df7a3cd8a66f331770b0bc0f149b/misc/share_project_overview_v_1_0_.pdf 17. Health informatics Harmonized data types for information interchange, ISO 21090: The CDISC SHARE Leadership Team, Summary of CDISC SHARE Requirements, November 2011, contentmgr/files/0/70e1df7a3cd8a66f331770b0bc0f149b/misc/cdisc_share_requirements_summary.pdf 19. U.S. Department of Health and Human Service, Food and Drug Administration, Center for Drug Evaluation and Research (CDER), Center for Biologics Evaluation and Research (CBER), Center for Devices and Radiological Health (CDRH), Guidance for Industry-Providing Regulatory Submissions in Electronic Format--Standardized Study Data (Draft Guidance), Feb C. Li, J. Gao, N. Bauer, SDTM Domain Mapping with Structured Programming Methodology, PharmaSUG 2012-Paper DS06, May 2012 Copyright CDISC October 2012 cdisc.org 13 CDISC.org