CDISC UK Network Breakout session Notes 07/06/16 Afternoon Session 1: Dealing with changing versions of SDTM and Controlled Terminology (CT) How do people manage this? Is this managed via a sponsor Standards Team, or does each project/asset manage their own standards? How should people be trained to handle changing versions of SDTM and CT standards? Writing the study data standardization plan as early as possible helps to make the issues clear. FDA data standards catalogue is clear about which standards are currently supported, and when standards will no longer be supported. Some organizations continually update the CT used across all studies (some every quarterly release, some every few releases, e.g. once a year). Some organizations use different CT versions for different studies the CT version to be used in a study is decided early on in the study, and fixed. It would be useful if more explanation were given when changes are made to CT. Sometimes the reason for the change is not clear. Mapping study data to SDTM domains One big time consumer is trying to place source data and identify the optimal target SDTM domain and/or variable to use when it s not obvious. Common examples are: - FA versus SUPP are there rules to help decide is something a qualifier to parent domain content, or is it a new test (and so goes to FA if Events or Interventions class). - When to use IG MO domain vs. something more TA specific (Ocular, RE, CV, etc.). No clear resolution emerged. Some have found FDA advice about this helpful (i.e. through direct communication with CDER). During this discussion it was mentioned that feedback and advice given by one FDA team might not necessarily agree with feedback given by another team e.g. the group of people giving feedback on a test submission might not necessarily be the same group of people who do the clinical review. The Mapping of the Treatment Emergent Flag in SDTM in light of the latest FDA technical conformance guide: CDER Common Data Standards Issues Document (version 1.1/December 2011) says that a treatment emergent flag should be included in AE. See page 8 of: http://www.fda.gov/downloads/drugs/developmentapprovalprocess/formssubmissionrequir ements/electronicsubmissions/ucm254113.pdf FDA Technical Conformance Guide (March 2016) says that there is no variable in the AE domain that indicates if an AE was treatment-emergent, and that all AEs should be included in the AE
domain regardless of whether they are treatment emergent. No mention is made of including a treatment-emergent flag. See page 17 of: http://www.fda.gov/downloads/forindustry/datastandards/studydatastandards/ucm384744. pdf FDA need to be asked to reconsider not incorporating this variable. Does anybody have experience of incorporating this variable into the SDTM AE domain? Or in an ADaM dataset? (and dealing with possible differences in definition between treatmentemergent variable in SDTM versus ADaM). ADaM AVAL/AVALC issues To get around one-to-one mapping issues with AVAL and AVALC, we have sometimes only populated AVALC for strings of text results (e.g. for ECG data where we have interpretation results), and left AVAL blank for these cases, and left AVALC blank for the non-text results (e.g. ECG parameters). Obviously this isn t technically a one-to-one map, as we have many AVAL results mapping to the same blank result in AVALC do blank values count with this one-to-one map? When we validate the ADaMs we don t get any errors, but I want to check whether this is an acceptable process. This was clarified in ADaM IG v1.1: see section 3.3.4. The notes on AVAL and AVALC address this issue: Within a given parameter, if there exists a row on which both AVALC and AVAL are populated, then there must be a one-to-one mapping between AVALC and AVAL on all rows on which both variables are populated. (In other words, there is no requirement that a null value in either AVAL or AVALC be included in the one-to-one mapping.) Similarly, we have in the past dropped AVALC from the ADaM and included the SDTM xxstresc variable containing the result as a character. Is this approach frowned upon in any way, or is it generally acceptable? An example of why we might do this is in PK concentration data, where we need AVAL to be 0 for all BLQ results for summaries, but because there are multiple analytes/metabolites we have different levels of quantitation, therefore we have AVALC results that differ for 1 value of AVAL. Need to check with CDISC: Mapping from SDTM character variable to AVAL is almost but not quite one-to-one. SDTM character variable needs to be in ADaM dataset. Is it permissible to copy the character variable from SDTM? TRTxxP/TRTP/TRTSEQP If the client require the treatments to be given as abbreviations, or letters (e.g. Drug A 250 mg = A) as per the SAP, is it acceptable to use these abbreviations in the treatment variables in the ADSL and subsequent ADaMs, or is it preferred to have the actual drug name and dose information in these treatment variables and create the abbreviations in the TFL codes? Need to check with CDISC and/or FDA. Does anybody have experience of doing this for a submission? Visist/timepoint variables Is it acceptable to include timepoint information (e.g. 1 hour, 5 hour, 10 minutes) in the AVISIT variable, so that it takes the form of e.g. Day 1, 2 hour? Or is it more preferable to have an AVISIT and an ATPT so that AVISIT can just contain the day information, Day 1 in my example, and ATPT can just contain the timepoint information, 2 hour?
ADaM IG is not very proscriptive about this it gives suggestions that the latter may be done. This is probably an issue that should be clarified with the regulator before submission. Is it acceptable to include variables in the ADaM datasets that are solely used for ease in the TFLs, e.g. a variable combining subject number, sex and age? I personally prefer not to include variables such as this, as the ADaM contains all of these things separately anyway and I feel a variable combining them is just repeating data, but I also don t know 100% that it s not allowed to have variables such as this. If the question means a variable containing strings of the form 12345 F 24, when the dataset already has USUBJID, SEX, AGE then this seems quite unusual. How does the need for this arise? Removing data that is not required for analysis: When programming ADaMs, (for example ADLB), I usually include all data from the SDTM that are related to the ADaM I am aiming to produce (in this case, all LB data, unless there are some LB data that can go in another ADaM domain). Is this necessary, or can we remove parameters/categories which are not required for analysis? For example, in labs data, we usually summarise chemistry, haematology and urinalysis data. We usually list pretty much everything else, e.g. serology data. Would we therefore be able to only include chemistry, haematology and urinalysis data in the ADLB, or should we still include the other labs data that will not be summarised? Another example could be ADVS, but not including parameters found in VS, e.g. height, weight and BMI. Only data used for the analyses being performed needs to be included. We are currently using Pinnacle 21 v2.1.0 validator, and in there there s an application for define.xml creation. We haven t really utilised this so I was wondering if other people have used it and whether they have encountered any issues with it. I believe this was mentioned in this presentation: http://portal.cdisc.org/cdisc%20user%20networks/europe/english%20language/presentation s/2016%2006%2007%20- %20UK%20Network%20Face%20to%20Face/Formedix%20Practical%20Implementation%20of% 20Define%20CDISC%20UK%20Network%207Jun16.pptx ). This was thought to be a quick and simple way of making define.xml that might be useful if you have a short deadline, or as a starting point for further development. The problem with this approach is that if you create define.xml from XPT files and standard CDISC-provided metadata, then you have to add in your study-specific metadata somehow. I was wondering whether there was anything specific that we re meant to do with regards to clinical significance variables. I have seen this done 2 ways: first by just bringing in the xxclsig variable from the SDTM and adding it to the ADaM, or by holding the clinical significance in an AVALCATx variable. The problem with the 2nd method is that if for some reason, we have 2 high results where 1 is clinically significant and the other is not, we have seen validator errors because there is not a 1-1 map between AVAL and AVALCATx. ADaM IG 1.1 hints that AVALCATx should be a function of AVAL/AVALC and PARAMCD (either one-to-one or many-to-one), i.e. the value of AVALCATx should be determined by the values of PARAMCD and AVAL/AVALC, but nothing else. This needs clarficiation.
Afternoon - Session 2: Question: Splitting Domains from Magdalena Litwin-Wojciechowska (Roche) Two reasons for splitting domains: 1. Sponsor may choose to split SDTM domains, for example to represent findings about medical history in FAMH and findings about adverse events in FAAE. 2. FDA requirements: Datasets greater than 5 GB should be split into smaller datasets. SDTMIG v.3.2 Chapter 4.1.1.7 Splitting Domains Sponsors may choose to split a domain of topically related information into physically separate datasets. There is a set of rules that must be adhered to when splitting domains. One of these rules states: 5. Permissible variables included in one split dataset need not be included in all split datasets. Should the datasets be appended in SAS, permissible variables not used in some split datasets will have null values in the appended datasets. Care is advised, however, when considering variable order. Should a permissible variable used in one (or more) split datasets not be included in the first dataset used in a SAS Set statement, the order of variables could be compromised. FDA Validation Rule FDAC159 Split datasets should have matching variable lengths for future merges. Datasets should be resized to the maximum length used prior to splitting. FDA Validation Rule FDAC036 Variable length should be assigned based on actual stored data to minimize file size. Datasets should be re-sized to the maximum length of actual data used prior to splitting. Discussion Summary 1. Companies agreed that splitting domains of topically related information into physically separate datasets and splitting domains due to their size (as per FDA requirements) are two different concepts. 2. If sponsor chooses to split domains, e.g. FA into FAAE and FAMH then these domains should be treated as separate datasets and they may not have the same permissible variables nor they need to keep the same variable lengths. In define.xml they will be submitted as separate entities. 3. Domains split by sponsor (not due to size) are not meant to be merged; however SDTMIG v3.2 suggests they may be appended which may be misleading: Permissible variables included in one split dataset need not be included in all split datasets. Should the datasets be appended in SAS, permissible variables not used in
some split datasets will have null values in the appended datasets. Care is advised, however, when considering variable order. Should a permissible variable used in one (or more) split datasets not be included in the first dataset used in a SAS Set statement, the order of variables could be compromised. Question: Experience of uploading xml results to EUDRAC T CT Mark from Formedix had experience of uploading xml files to EUDRACT. This did not work due to there being an issue with the versions being used by EUDRACT; the schema may be using a different version from the validator. The validator has been offline since January whilst they fix this problem. Recommendation to enter the data manually. Question: Feedback from Test Submissions to the FDA One company had feedback from the FDA on the output of running the Pinnacle 21 checks, where the FDA had run a newer version over the data, so finding more issues. In the same way, FDA are accepting define version 1.0, however would prefer to receive version 2.0. Question to the FDA: Please could they document which version of the CDISC validation checks they are using, i.e. Pinnacle 21 checks Gavin Winpenny (Roche) will provide further information about Pinnacle 21 Enterprise system. General topic: Versioning of Controlled Terminology General feedback is that it would be useful to know which version of SDTM controlled terminology the FDA is using and how they are managing them. All submissions should state up front which controlled terminology the study or package of studies used. Afternoon - Session 3: Question about define version 2.0; Company implementation is to split up terminology codelists by domain e.g. units, however in define they are requesting the units in one large codelist. <Did anyone have a solution to this or is this just a pain point when using define?> What common issues can hold up a submission? Group decided to refer the requestor to the FDA website where they have posted a presentation and there was also a good presentation from the FDA at the European CDISC Interchange. FDA Guidance on Providing Regulatory Submissions in Electronic Format Standardized Study Data: Who DRUG Dictionary update from Warwick Benger (GSK)
This guidance which has been mandated from 17th December 2016, states that standard Terminology Standard should be used, state Who DRUG dictionary. Many companies use their own company specific drug dictionaries, like GDK. One of the reasons GSK uses an in house drug dictionary is that they receive a greater hit rate; 90% in-house; 60-70% using Who DD. The PMDA is following FDA s guidance and requesting Who DD to be used from 2017 for regulatory submissions. GSK have been in negotiations with them and have agreed to the following: - At the moment, GSK to code all data as normal using Who DD (coding occur in ADaM datasets) - GSK to code data into the SDTM CM dataset - GSK to create a second SDTM CM dataset to display the Who DD terms, which will involve mapping the in house dictionary terms to Who DD levels. - PMDA agreed they only require Drug level ingredients and ATC codes FDA is not pushing for Who DD to be used at the moment but is recommended. Thank you to Warwick for sharing this important information.