13/May/2016 As one of the activities of CDISC Japan User Group (CJUG), a small group, "Extension study team" was organized in 2015. The team discussed what kind of approach works better for SDTM creation of extended studies. Disclaimer: The views and opinions expressed in this document are those of the authors and do not necessarily represent the opinions of CJUG, members' respective companies or organizations, or regulatory authorities. The content in this document should not be interpreted as a data standard and/or information required by regulatory authorities. Summary Team implemented tiny SDTM datasets to find better practice of SDTM creation for extended studies. Several approaches support the SDTM implementation of extended studies. One of them is to include all data from all relevant studies into the single set of SDTM (we call this approach "consolidated"). Team focused on this method and created/validated SDTM datasets. As conclusion, tem found that data should pretend as if it is independent single study for the validation process. Background of extended studies Extended studies are designed in many ways. This is not simple at all. For example, protocol originator may define "first phase" for efficacy confirmation and "second phase" for long-term safety confirmation. Two phases are connected substantially. As other example, "single dose test", "dose escalation test" and "tolerance test" may be bundled into single protocol. Fig.1: Examples of extended study design Efficacy (Double Blinded) Safety (Open Labelled) Single Dose Dose Escalation Tolerance Study ID may be the same or different among these phases/tests. CRF design is also diverse. Independent CRFs can be created or single CRF may collect all data. Each sponsor takes its own 1/12
approach. Submission and interim analysis can be taken into account. SDTM datasets will be created at appropriate milestones. Though any different cases are expected, team decided not to assume specific scenario. Team realized that better practices are required outside of SDTM creation. For example, data cut off protocol design CRF design minimize issues on statistical analysis However, these issues are out of scope of the team and not discussed. Segmentation vs. Consolidation Next topic for team was to consider pros/cons of 2 major approaches of SDTM creation for extended studies. No recommendation is described in SDTM/SDTM IG. Consolidation approach: include all relevant data into single set of SDTM datasets Segmentation approach: split data into appropriate different SDTM datasets Fig. 2: Examples of segmentation and consolidation Study design: Subjects who completed study A are enrolled into study B. Study A Study B Segmentation: 2 SDTM datasets are created SDTM for Study A SDTM for Study B Consolidation: One SDTM dataset is created SDTM for Study A + Study B 2/12
What if you are reviewer in regulatory... Regulatory expectations and requirements are important to implement appropriate SDTM datasets. At the time of team activity (Aug 2015 to Apr 2016), it looks that PMDA has internal communication over the data structure of extended study. However, no official announcement has been released yet. It's convenient for reviewers if all data in interest is stored in SDTM. This is especially true when cross study data is required for analysis for review. In this case, consolidation approach works well. Fig. 3: Diagram of data distribution Consolidation approach enables to put all data into single SDTM datasets. In segmentation approach, reviewer may have to look into other SDTM datasets to find source data. Study A Study B 0 8 16 24 32 40 48 56 64 Consolidation SDTM(A+B) Segmentation SDTM(A) SDTM(B) On the other hand, PMDA plans to establish data repository. Sponsor may submit SDTM to PMDA during the study and re-submit SDTM after the study is closed. In this case, if the sponsor adopts consolidation approach, some parts of the re-submitted data are the duplication of the first submission data. Furthermore, data collections on previously submitted data can be made at re-submission. Hence, PMDA needs to update the data in its data repository. Fig. 4: Data Duplication in consolidation approach SDTM for first submission SDTM for second submission Duplicated data New data Sponsor perspective Any type of study design is adopted at many sponsors. As a result, best approach is different among sponsors. As an example, let's think the following scenario. A sponsor designs the extended study. 3/12
This study consists from 2 parts and study ID is different (study A and study B). Demographic data is collected at the beginning of study A. If sponsor implement SDTM on segmentation approach, SDTM datasets for study B doesn't include DM domain. Such SDTM datasets cannot pass the gateway system provided by PMDA *1. Statistician may prefer the consolidated SDTM as they need to look into single SDTM to find data required for analysis. It enables clear traceability also. Thus, consolidation approach is the best way for these cases. On the other hand, segmentation approach is also suitable for other cases, for example, independent CRFs are created and/or clinical database is established separately. 4/12
Test implementation Team created sample SDTM datasets to verify the validity of approach and to clarify underlying issues. SDTM datasets are validated by Pinnacle 21 community version. Assumption Team decided to implement SDTM dataset based on consolidation approach. Single set of SDTM is created in this methodology. Team assumed a protocol that defines extended study consists from 2 phases. The purpose of first phase is to verify the efficacy and the purpose of second part is to confirm the safety of study drug. Study ID is different. SDTM is created for each study and merged into single SDTM datasets. Validation results (Pinnacle 21 Community 2.0.1, SDTM 3.2) Issues are found as follows. DM Well known golden rule of DM domain is "1 record per 1 subject" *2. However, consolidated SDTM datasets never invoked any issues. This is due to algorithm of Pinnacle 21. Validator refers STUDYID variable and tries to find out duplication of subject for each study. For example, following DM is regarded as valid dataset. STUDYID DOMAIN USUBJID SEX... AA DM XXX-001 M BB DM XXX-001 M Team modified the value of STUDYID variable as follows. Validator reports the error. STUDYID DOMAIN USUBJID SEX... AA_BB DM XXX-001 M AA_BB DM XXX-001 M --DY variable SDTM datasets can have --DY variable. The value of --DY stores the elapsed days based on the content of RFSTDTC in DM domain. Validator refers RFSTDTC in DM domain, and calculates the expected value internally. Derived value is compared against the value in target datasets. In this process, validator searches DM domain to catch the value of RFSTDTC variable. If multiple records are found in DM domain for a given USUBJID, last record is selected. Let's see what happens in the following example. Target subject ID is XXX-001. Validator searches the DM domain and finds 2 records. But, the last record (STUDYID=BB, USUBJID=XXX-001) is 5/12
selected. 2015-02-01 is the base of day calculation. Expected day is "-31" for pulse at 2015-01-01 and 1 for pulse measured at 2015-02-01. STUDYID DOMAIN USUBJID RFSTDTC......... AA DM XXX-001 2015-01-01 BB DM XXX-001 2015-02-01 STUDYID DOMAIN USUBJID VSTESTCD VSDTC VSDY... AA VS XXX-001 PULSE 2015-01-01-31 BB VS XXX-001 PULSE 2015-02-01 1 However, this is not always what users want. Some users want to keep the elapsed days based on the start date (RFSTDTC) for each study. Other users want to calculate the --DY value based on the RFSTDTC value of first record of DM domain. Neither of them is supported by Pinnacle 21. The same goes for --STDY and --ENDY variable. STUDYID variable The values of STUDYID variable in each record is verified by validator. Validator regards content of STUDYID in DM domain as valid value. If multiple records are found in DM domain, validator selects the first record. Again, we see it in an example. Please see the following table. VS domain is the target of validation. Validator searches DM domain and finds data for subject XXX-001. As a result, "AA" is expected content of STUDYID variable. Hence, 2nd line of VS domain is reported as "invalid value in STUDYID variable". STUDYID DOMAIN USUBJID RFSTDTC......... AA DM XXX-001 2015-01-01 BB DM XXX-001 2015-02-01 STUDYID DOMAIN USUBJID VSTESTCD VSDTC VSDY... AA VS XXX-001 PULSE 2015-01-01-31 BB VS XXX-001 PULSE 2015-02-01 1 6/12
Validation results (Pinnacle 21, Community Version 2.1.1, SDTM3.2 (PMDA)) New version of Pinnacle 21 was released during team activity. Team validated sample SDTM by the new release of Pinnacle 21.All findings reported in the previous section are confirmed (but the severity is different). In addition to these, following issues are found. RFXSTDTC vs EXSTDTC Validator compares the content of RFXSTDTC against EXSTDTC in EX domain. If multiple records are found for a subject in DM domain, last records are selected as reference. In the following example, 1 st line of EX domain (STUDYID=AA, EXSTDTC=2015-01-01) indicates that dose is initiated before the reference date. Validator reports the contradiction between RFXSTDTC and EXSTDTC. STUDYID DOMAIN USUBJID RFXSTDTC RFXENDTC... AA DM XXX-001 2015-01-01 2015-01-31 BB DM XXX-001 2015-02-01 2015-02-28 STUDYID DOMAIN USUBJID EXTRT EXSTDTC EXENDTC AA EX XXX-001 DRUG AA 2015-01-01 2015-01-31 BB EX XXX-001 DRUG BB 2015-02-01 2015-02-28 RFXENDTC vs. EXENDTC Validator also sees the consistency between RFXENDTC and EXENDTC in EX domain. Again, last record in DM domain is selected as reference when multiple records are found for a subject. In the following example, sponsor changed the order of data in DM domain, as sponsor took action for previous error (RFXSTDTC vs. EXSTDTC). Validator selects RFXENDTC in the last record in DM as reference value. The content (2015-01-31) is compared against EXENDTC. 2 nd line of EX domain indicates that last dose is 2015-02-28. This is contradiction against RFXENDTC. Validator fires error. STUDYID DOMAIN USUBJID RFXSTDTC RFXENDTC... BB DM XXX-001 2015-02-01 2015-02-28 AA DM XXX-001 2015-01-01 2015-01-31 STUDYID DOMAIN USUBJID EXTRT EXSTDTC EXENDTC AA EX XXX-001 DRUG AA 2015-01-01 2015-01-31 BB EX XXX-001 DRUG BB 2015-02-01 2015-02-28 7/12
Consideration Sample SDTM datasets are created by simple merge of SDTM for each study. As a result, DM domain stores 2 records for each subject. This is not problematic at all when DM domain is validated. However, this structure of DM domain causes common errors in other domains. Team was unable to find any solutions of STUDYID error. As far as content of STUDYID is inconsistent in DM domain, this error always happens. Validator has built-in algorithm for --DY derivation. If sponsors want to derive the content of --DY variable based on the start date of first phase of study, tricky DM implementation is required. Fig. 5: Sponsor wants to calculate --DY based on the RFSTDTC of first study. But this structure cases error in validation... STUDYID DOMAIN USUBJID RFSTDTC......... AA DM XXX-001 2015-01-01 BB DM XXX-001 2015-02-01 STUDYID DOMAIN USUBJID VSTESTCD VSDTC VSDY... AA VS XXX-001 PULSE 2015-01-01 1 BB VS XXX-001 PULSE 2015-02-01 32 The possible solution is to sort records of DM domain in descending order for RFSTDTC value. That is, 1st line in Fig 5 will be the 2 nd record in the modified DM dataset. But, as a result, DM domain stores the data in chronologically descending though other domains hold all data chronologically. This solution depends on the actual record position and this is fragile for sorting of data. Consistency between RFXSTDTC/RFXENDTC and EXSTDTC/EXENDTC is checked by Pinnacle 21, Community Version 2.1.1. These checks are complementary and one of them would fire the error even though sponsor changed the order of records. Sponsor may accept the all errors as they are rather than trying to resolve errors. Instead, all errors will be fully explained / supported in Study Data Reviewers' Guide. Followings must be considered in this case. Validator (Pinnacle 21) cannot ensure the validity of --DY calculation. Hence, sponsor must ensure that all --DY variables are derived as it's defined in the SDTM IG. Regulatory (PMDA) checks the submitted SDTM by Pinnacle 21. Regulatory would find 8/12
many errors in their environment. Root cause of these errors is the approach of SDTM implementation. This is sponsor's decision. Regulatory may ask sponsor to re-build the SDTM following less-erroneous methodology. Team concludes as follows. SDTM dataset for extended study must be structured in a way to maximize the functionality of validator. In details, 1. Unique content of STUDYID variable. All records should have the same value. 2. DM domain should have only 1 record per 1 subject. PMDA guideline requires ensuring the quality of SDTM datasets based on the public validation rules. If sponsor creates SDTM following principles above, validation software works very well. Sponsor can show the validity of submitted SDTM to PMDA and no sponsor-specific tool will be required. Recommendations Team recommends implementing SDTM for extended study as if they are single study when consolidation approach is taken. That is, value of STUDYID is static for all records in SDTM. Even though difference study ID is given to each study, STUDY ID should be fixed. DM domain should have only 1 record per 1 subject. Points to consider Validation is not the only hot topic when sponsor creates SDTM datasets with consolidation approach. Hereafter, we list the expected problems and possible solutions to them. Please note that this list is not exhaustive. Demographic data Subject demographics data can be collected multiple times. In this case, followings are possible handling. Store the baseline data in DM domain. Non-baseline demographic data is not implemented in SDTM. acrf indicates this as appropriate. Store the baseline data in DM domain. Non-baseline demographic data is stored in SUPPDM. --DY variable Derived content of --DY variable based on the RFSTDTC in DM domain. If sponsor wants to calculate 9/12
the elapsed days based on the other date, do it in ADaM. Multiple informed consent Sponsor should consider the way to store the date of additional informed consent. Such date will be mapped to SUPPDM and DS. Content of DSSCAT and/or DSTERM will be decided carefully to facilitate the usefulness of clinical data. Population Flag SDTM IG, Appendix C2 lists the supplemental qualifiers name codes for population flag. Thus, sponsor can store the population flag in SUPPDM domain. However, SDTM IG provides no guidance how to have multiple flag for 1 subject. In extended study, each subject may have independent population flag for each study phase. Flag may be different (ex. Y to 1 st phase and N to 2 nd phase). Store the all population flags in SUPPDM domain. Sponsor cannot follow naming convention fully in this case. Do not store population flag in SDTM. Handle them in ADaM. (Appendix C2 will be deprecated in the next version of SDTM IG *3 ) Duplicated data A part of clinical data is duplicated at collection phase. For example, adverse events are collected multiple times. Team recommends documenting the data handling procedure in advance. One of duplicated records should be deleted. Latest information (ex. outcome) should be reflected in SDTM Include all records in SDTM datasets. Duplicated records are bundled by --GRPID variable. This decision should be communicated to statistician. acrf Sponsor may create CRFs for each study. Define.XML supports the multiple acrf. But the default style sheet doesn't support multiple a CRF. Followings are solutions. Modify style sheet at sponsor (sponsor should take all responsibility for the change) Merge acrf s into single file (page link should be cared) Study Data Reviewer's Guide (SDRG) There is dedicated section to explain the status of submitted SDTM datasets in SDRG. Sponsor would make the most of this document. *5 Trial Design Model 10/12
If there are multiple protocols for extended study, it can be hard to describe the study design as single study. ARM Team found least difficulty on description of arms. If the study consists from "Double Blind" phase and "Open" phase, following may work well. Placebo arm:placebo + Drug A Active arm:drug A + Drug A Other approaches would fit for more complex study design. TS domain Some TS parameters can be used multiple times and others can be used just one time *4. If the parameter has no cardinality limitation, create records as needed. TSGRPID variable helps to bond the related parameters. If the cardinality of the parameter is "1", sponsor should make a decision. Sponsor may compromise on limited information or include complete information with violation of SDTM rule. Invalid TS domain may bring unexpected influence to regulatory. Consultation with reviewer is also important. USUBJID Content of USUBJID is derived generally. If extended study has multiple protocols, several approaches can be applied. Concatenate all study IDs and SUBJID (ex. Study A_Study B_SUBJID) Concatenate first phase study ID and SUBJID VISIT Duplication of VISIT definition is not allowed by SDTM IG architect. However, same visit name can be seen in extended studies (For example, VISIT 1 for first study, VISIT 1 for second study). In such case, we recommend concatenating study ID and Visit (ex. VISIT 1-STUDY A, VISIT 1-STUDY B). This may facilitate the usefulness of clinical data. --BLFL This is not problematic at all, if baseline is found just one time throughout the extended study. If multiple baselines are defined in the protocol (ex. baseline of first study and baseline for following study), sponsor wishes to reflect this in SDMT datasets. No errors will be reported when validator finds multiple BLFL=Y. However, team is not sure such SDTM can be easily reviewed by regulatory software. This will be described in the SDRG in addition to consultation with review division. 11/12
Team Members (in alphabetical order) Daisuke Hisada (Taiho Pharmaceutical, Data Science) Hajime Shimizu (Takeda Pharmaceutical, Clinical Data Management & Technology) Keiichiro Sakuraba (Kissei Pharmaceutical, Clinical Data Science) Mirai Kirihara (A2 Healthcare, Data Management Group 2, Data Science) Contact Information Your comments and questions are valued and encouraged. Please contact at: Hajime Shimizu Takeda Pharmaceutical Japan Email: hajime.shimizu@takeda.com OR CJUG-SDTM-OFFICE (CJUG-SDTM-OFFICE@umin.ac.jp) Notes *1:Pinnacle 21 Community:SDTM 3.2 PMDA Rule:SD1020 *2:SDTM IG 3.2: "One record per subject". Study Data Technical Conformance Guide 3.0: "In the DM domain, each subject should have only one single record per study" *3:Inputs from CJUG SDTM Meeting (Mar. 2016) *4:Cardinality of ADDON is one (SD1214) *5:SDRG Template provides the section to describe the details of extended study. 12/12