Page Comparison

Questions Received

Teams Collective Response

There are a couple of papers which offer guidance for maintaining 1-1 mapps between AVAL and AVALC. Things like: https://www.lexjansen.com/wuss/2017/79_Final_Paper_PDF.pdf and https://www.pharmasug.org/proceedings/2012/DS/PharmaSUG-2012-DS16.pdf. However, neither of these papers explain how to consistently create derived records, where AVALC is a rounded version of AVAL, which satisfies the 1-1 criteria. For example, suppose (within a single PARAMCD) I need to compute an average and then present that in a list to 1 dp. For example, let's say AVAL=45.333333 so for the listing I want to show 45.3. I've computed an average for another subject where AVAL=45.26 which I also wan to show as 45.3 in a listing. If AVALC=45.3 for both records, then this is not a 1-1 mapping. I obviously can't round AVAL, because that would represent a loss of numerical precision in other calculations. One solution might be 'do not populate AVALC, do the rounding when producing the report'. However, this leaves a lot of work in the reporting program if many parameters are to be listed; the programmer would have to determine the rounding on a per-parameter basis. Ideally the 'heavy lifting' should already have been done at the dataset level

PHUSE Team Response: 8th July 2020

Rounding values of AVAL for listing purpose - where to do the rounding and how/where to store the rounded value

Storing a rounded value in AVAL is not good practice as it typically results in a loss of precision for calculations in the tables. Storing rounded values in AVALC goes against the ADaM rule that there has to be a 1-1 mapping of AVAL to AVALC. Also, it is not the intent to store the character version of a numeric analysis value in AVALC. AVALC should be populated only when the character value is used for analysis. See ADaM IG v1.1, section 3.3.4, 'PARAM, AVAL, AVALC' paragraph 3

There is no ADaM guidance as to variable naming for variables used for listing purpose only

Rounding the analysis result can be done in the listings program, or alternatively, if one wants to store rounded value in the ADaM dataset, a custom variable can be added with an intuitive meaning, eg LISTVAL, to store the rounded value

Study treatment regimen will be A-B-C-D, therefore planned ARMCD can be ABCD. Most of the patients actual ARM ACTARMCD will also be ABCD. But a few patients may skip D or repeat ABC part which is ABC or ABCABCD. Shall we put UNPLANN in actors or put the real ABC or ABCABCD in the ACTARMCD?

PHUSE Team Response; 9th January 2020

The planned treatment should be reflected in ARMCD/ARM, while the actual regimen received should be reflected in ACTARMCD/ACTARM. In general, TA should reflect the protocol-specified treatment regimens to be administered. If the protocol specified the skipping of a treatment regimen by design, then it is acceptable to find inconsistencies between ARMCD and ACTARMCD. However, these should be noted in the cSDRG and explained in further detail

In SV domain, we search all the by-visit source data to get the min and max date of each CRF visit. if due to some reason, there are 1-2 days overlap among 2 consecutive CRF visits in SV domain, we can explain in SDRG or always make visits in SV without overlap which means we assign the overlapped days to 1 CRF visit in SV rather than keep the days in both visits as the source data shown?

PHUSE Team Response: 9th January 2020

Acceptable to have the overlap on the visits in SV domain. There will be no P21 consequences due to this, and as such it is not required to explain further in the DRG. The explain in the DERG would be left to the Sponsor's determination

Questions Received	Teams Collective Response
In SV domain, we search all the by-visit source data to get the min and max date of each CRF visit. if due to some reason, there are 1-2 days overlap among 2 consecutive CRF visits in SV domain, we can explain in SDRG or always make visits in SV without overlap which means we assign the overlapped days to 1 CRF visit in SV rather than keep the days in both visits as the source data shown?	PHUSE Team Response: 9th January 2020 Acceptable to have the overlap on the visits in SV domain. There will be no P21 consequences due to this, and as such it is not required to explain further in the DRG. The explain in the DERG would be left to the Sponsor's determination
For the Table like 'Summary of Common (>=X%) Adverse Events by Overall Frequency', should the flags for common AEs be created in the ADAE dataset?	PHUSE Team Response: 31st July 2019 5pct, 2pct custom flag variables can be added to ADAE Derivation of the flag variable depends on the definition in SAP/table Janssen - If derivation rule is complicated enough, include it in ADAE have an internal macro to derive the variable with parameter being the x of x% internal macro is a reporting macro, not tied to the ADAE Other companies do not include in the ADAE and handle it in the table generating programs can also explain in the ADRG if this table calls into the category of the primary/secondary key safety and efficacy, you will need to submit the program can also be included in the ARM
FDA impressed the wish to keep ETCD/ELEment to facilitate reviewer to review the data in 2011 CDER Common Data Standards Issues Document. However, in all later FDA published Study Data Technical Conformance Guide up to V4.1 published in 2018, only EPOCH is required. EPOCH by it's own should have been informative enough. FDA validator rules V1.2 published in DEC2017 still mentions that variables requested by FDA in Policy documents should be included in the dataset, e.g. EPOCH and ELEMENT. Do you know if FDA still require ELEMENT/ETCD in all domains? If yes, I would suggest to CDISC SDTM team to include those 2 variables in the parent domain and not the SUPP domain	PHUSE Team Response: 4th July 2018 ETCD/ELEMENT Variables: The reference to the 2011 CDER Common Data Standards Issues document is no longer relevant and superseded by the FDA Study Data Technical Conformance Guide. Therefore, any such references must be in alignment with current FDA guidelines. The inclusion of ETCD/ELEMENT within other domains other than those identified within the SDTM/SDTMIG is not recommended. EPOCH Variables: Section 2.2.5 of the SDTM* allows for the timing variable EPOCH within any of the three general observation class domains, except where explicitly stated otherwise in the SDTMIG. Therefore, EPOCH inclusion to facilitate the recommendations identified in section 4.1.4.1 of the FDA Study Data Technical Conformance Guide** is in alignment with CDISC SDTM/SDTMIG* Additional References: CDISC SDTM V1.4/SDTMIG V3.2 FDA Study Data Technical Conformance Guide V4.1
How should OTHER be represented for variables bound by non-extensible codelists?	PHUSE Team Response: 7th June 2017 Existing SDTMIGs (e.g., v3.1.2, v3.1.3, v3.2) do not explicitly define how "OTHER" should be implemented universally for all non-extensible codelists. Additional References: N/A
How should MULTIPLE be used for variables bound by non-extensible codelists?	PHUSE Team Response: 7th June 2017 Existing SDTMIGs (e.g., v3.1.2, v3.1.3, v3.2) do not explicitly define how "MULTIPLE" should be implemented universally for all non-extensible codelists. Additional References: N/A
What are best practices for creating CT for/representing questionnaire responses?	PHUSE Team Response: 7th June 2017 It is recommended to review SDTMIG (v3.1.2, v3.1.3, or v3.2) Section 4.1.3 Coding and Controlled Terminology Assumptions. Furthermore, please also review existing questionnaire CDISC Controlled Terminology (CT) and CDISC Questionnaires, Ratings & Scales (QRS) supplements and related details found on the QRS page – see reference below. Additional References: https://www.cdisc.org/qrs
What is the general recommendation/approach for generating/submitting custom domains (e.g. non-standard CDISC SDTM domains) to regulatory agencies?	PHUSE Team Response: 12th September 2017 As per CDISC SDTM IG version 3.2: A sponsor should submit the domain datasets that were actually collected (or directly derived from the collected data) for a given study. Decisions on what data to collect should be based on the scientific objectives of the study, rather than what is present in SDTM. Note that any data that was collected and will be submitted in an analysis dataset must also appear in tabulation dataset. Both PMDA and FDA allow the creation/submission of custom domains if the study data does not fit into a standard SDTM domain however, custom domain may only be created if the data are different in nature and do not fit into an existing published domain (e.g. standard SDTM, Therapeutic Area Standards). NOTE*: When assessing the need for a custom domain, also storing of data in supplemental qualifier (SUPP--) or findings about (FA--) domains should be considered. Helpful references on when to use findings about or supplemental qualifiers are present in the CDSIC SDTM IG ("When to Use Findings About", "How to Determine where data belong in SDTM Compliant Data Tabulations" and the Supplemental Qualifiers section). Another reference is the PhUSE Paper findings about "Findings About". The overall process for creating a custom domain are clearly explained in the SDTM IG and must always be based on one of the three SDTM general observation classes (interventions, events or findings). Custom domains must be clearly described in the cSDRG/SDRG and specifically PMDA prefers to be consulted beforehand when considering storing data in a custom domain. Source for FDA: Study Data Technical Conformance Guide Source for PMDA: Revision of Technical Conformance Guide on Electronic Study Data Submissions Source for CDISC: CDISC SDTM IG Source for PHUSE: Findings about "Findings About"

Versions Compared

Old Version 9

New Version 10

Key