SDTM FAQ Team Responses

From PHUSE Wiki
Jump to: navigation, search

Topic: Validation/Conformance Rules (VCR Sub-Team)



1) What are FDA Business Rules and Validator Rules?

PHUSE Team Response: 20th July 2018

a) FDA Business Rules

The FDA Business Rules document V1.3, published December 2017, states 'The FDA Business Rules describe the business requirement for regulatory review to help ensure that the study data is compliant, useful, and will support meaningful review and analysis.' For more information see Section 8 of the Technical Conformance Guide

b) Validator Rules

The FDA Validator Rules document V1.2 published December 2017, states 'The rules used by the FDA study data validator to ensure data are standards compliant and support meaningful review and analysis. In addition, the document links the study data business rules to the study data validator rules.'

Please refer to the most recent version of these documents that are available in the Business Rules section at the following Web Page


2) What are CDISC SDTM Conformance Rules?

PHUSE Team Response: 20th July 2018

a) CDISC Study Data Tabulation Model: Conformance Rules User Guide, V1.0 published in December 2016, states 'The purpose of this guide is to document a standard, concise structure for identifying and classifying SDTM and SDTMIG text that may constitute a conformance rule definition. The structure for the rules, the Rules Metadata Model, and the conventions for its content are described in detail.' Additionally, a companion Microsoft Excel workbook, SDTMIGV3.2 Conformance Rules V1.0, was released simultaneously. For each rule, the workbook describes the RuleID, Class, Domain, Variable, Rule, and Condition along with the SDTMIG reference details, Programmable Flag and FDA Rule ID (V1.0).

Please refer to the most recent version of the SDTM Conformance Rules document here

CDISC ADaM Validation Checks V1.3, published in March 2015, states 'This document contains a list of requirements which may be used to validate datasets against a subset of these rules which are objective and unambiguously evaluable. The validation checks within this document are defined to be machine readable (i.e. programmable within computer software) and capable of being implemented by ADaM users. The validation checks within this document can be implemented with software to test rules defined within the ADaM Implementation Guide 1.0, Data Structure for Adverse Events (ADAE), and the ADaM Basic Data Structure for Time-to-Event Analyses.' Additionally, a companion Microsoft Excel workbook, ADaM-validation_checks_V1.3_final, was released simultaneously. For each rule, the ADaM workbook describes the following: Check Number, ADaM IG Section Number, Text from ADaM IG, ADaM Structure Group, Functional Group, ADaM Variable Group and Machine-Testable Failure Criteria.

Please refer to the most recent version of the ADaM Validation Checks document here

3) How do the FDA Business Rules and Validator Rules differ from the CDISC SDTM Conformance rules and ADaM checks?

PHUSE Team Response: 20th July 2018

a) The CDISC conformance rules check for conformance to the CDISC standards; whereas the FDA business rules help to confirm that the study data are compliant, useful and support a meaningful review.

The FDA Validator Rules check whether the FDA business rules are met. Not every FDA Business Rule can be automated; checking some of them would need human involvement.

4) If I get no error messages from my CDISC conformance checks, are the SDTM and ADaM submission datasets CDISC-conformant?

PHUSE Team Response: 20th July 2018

a) It is important to understand that absence of validation tool error message doesn't ensure CDISC conformance. There are some aspects of SDTM and ADaM conformance that are not testable by computer.

Secion 1 of the 'CDISC Study Data Tabulation Model: Conformance Rules User Guide V1.0' document states, 'Rules governed by this guidance are not assumed to be universally programmable, that is, capable of being implemented as automated checks.' Section 3 defines a rules metadata attribute 'Programmable' as 'Indicator that a rule may be able to be implemented as an automated check.' The 'Programmable Flag Comment' is defined as 'Supplemental explanatory text for rules where there is a condition or factor as to whether they are able to be programmed as an automated check. In most cases this text would indicate a specific dependency on data or metadata that cannot be assumed to be always present and available.' Of the 410 conformance rules defined in the document, 85 are dependent on addition data or metadata, including in some cases non-standard sponsor data and metadata. Some of these rules are not tested by common validation tools; yet they still must be followed for SDTM conformance.

Similarly, Secion 2 of the 'CDISC ADaM Validation Checks V1.3' document states:

'The validation checks within this document can be implemented with software... The checks are meant to test the structure and certain standardised content of the ADaM data sets. These checks are not meant to define the whole spectrum of ADaM compliance including content and well defined metadata.

The following are examples of aspects of ADaM compliance that cannot be tested by software program:

Within section 4.3.1 of the Implementation Guide the text says, 'Include all observed and derived rows for a given analysis parameter.'
Within section 4.6.1 of the Implementation Guide the text says, 'To identify population-specific analysed rows, use population-specific indicator variables.'
Many ADaM variables are conditionally required (required if a condition is true), but some conditions are not testable by a software program.
One of the key components of the ADaM is the inclusion of thorough and well defined metadata. The thoroughness and clarity of metadata cannot be tested by a machine-readable algorithm but is necessary to enable the traceability that ADaM requires.

While the examples above are rules that must be followed while implementing ADaM , they cannot be tested by a machine-readable algorithm. Instead, a complete assessment of compliance must be based on an understanding of the scope of the study data and the analyses which the datasets should support coupled with the published validation checks within this document and the general rules and principles published in the ADaM Implementation Guide.'

_____________________________________________________________________________________________________________________

1) When the Errors and Warnings are still in the validation report after running validation tool before submitting to regulatory agencies, how do companies document this?

2) Should each error and warning documented or every unique error and warning has to be documented? How can the different errors and warnings produced in the report be handled?

3) How should messages with Reject severity be addressed?


PHUSE Team Response: 7th June 2017

1) In general, the outstanding errors and warnings should be documented in Study Data Reviewers Guide (SDRG as csdrg.pdf) for SDTM and Analysis Data Reviewers Guide (ADRG as adrg.pdf) for ADaM. The PhUSE templates are available on the PhUSE Wiki. See reference section below.

2) It is the decision of the sponsor to document the errors/warnings. It is highly recommended to document the rationale for the failure. The level of the documentation depends on the reviewer and the regulatory agency. It is recommended to document each and every unique SDTM error/warnings within each domain in the Study Data Reviewers Guide with as much detail as possible. Similarly, it is recommended to document each and every unique ADaM error/warnings within each dataset in the Analysis Data Reviewers Guide with as much detail as possible.

3) The intent of Reject severity is that the data must be FIXED in the submission. Please be proactive and speak to the regulatory agencies prior to a submission.

Additional References:
http://www.phusewiki.org/wiki/index.php?title=Study_Data_Reviewer%27s_Guide

http://www.phusewiki.org/wiki/index.php?title=Analysis_Data_Reviewer%27s_Guide

__________________________________________________________________________________________________________

1) What are the best ways to document errors/warnings caused due to Controlled Terminology? For e.g. when a non-extensible Codelist has been extended or if extensible codelist has been extended?

PHUSE Team Response: 7th June 2017

1) Please reference the FDA Technical Conformance Guide section 6 on the maintenance of the controlled terminology for US submissions. Please refer to Validation rules spreadsheet in the PMDA website for more information on the non-extensible codelists. It is recommended to document errors/warnings in the SDRG or ADRG.

Additional References:

N/A


__________________________________________________________________________________________________________

1) How do we document the errors/warnings from the FDA or PMDA Validation rules that are not part of the CDISC Validation rules?

PHUSE Team Response: 7th June 2017

1) Please refer to Validation rules spreadsheet in the FDA and PMDA website for more information. It is recommended to document errors/warnings specific to the regulatory authorities’ validation rules in the SDRG and ADRG. Please be proactive and speak to the reviewer and the regulatory agencies prior to a submission.

Additional References:

N/A


1) The validation software used by the FDA is very buggy. How do we recognize false positive errors/warnings from real ones? Is there a numbered list of them, so that we can reference these false positives in the SDRG?

Topic: SDTM/ADaM IG Nuances (IGN Sub-Team)



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 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 listing 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 want 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 listing program, or alternatively, if one wants to store the rounded value in the ADaM dataset, a custom variable can be added with an intuitive meaning, e.g. 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.

___________________________________________________________________________________________________________________________

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



_____________________________________________________________________________________________________________________________________

1) 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

1) 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


___________________________________________________________________________________________________________________________

1) How should OTHER be represented for variables bound by non-extensible codelists?

PHUSE Team Response: 7th June 2017

1) 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


__________________________________________________________________________________________________________

1) How should MULTIPLE be used for variables bound by non-extensible codelists?

PHUSE Team Response: 7th June 2017

1) 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


__________________________________________________________________________________________________________

1) What are best practices for creating CT for/representing questionnaire responses?

PHUSE Team Response: 7th June 2017

1) 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


__________________________________________________________________________________________________________

1) 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"

Topic: Data Submissions (DSUB Sub-Team)



At one point there was a joint CDISC/FDA team working on defining locations in SDTM/ADaM for BIMO components so that the CLINSITE information could be pulled from the submitted data instead of a separate dataset. This joint effort has currently been put on hold. However, at this point, the team recommends to continue to reference the current BIORESEARCH MONITORING TECHNICAL CONFORMANCE GUIDE (https://www.fda.gov/regulatory-information/search-fda-guidance-documents/bioresearch-monitoring-technical-conformance-guide https://www.fda.gov/regulatory-information/search-fda-guidance-documents/bioresearch-monitoring-technical-conformance-guide) and Standardized Format for Electronic Submission of NDA and BLA Content for the Planning of Bioresearch Monitoring (BIMO) Inspections for CDER Submissions. (https://www.fda.gov/regulatory-information/search-fda-guidance-documents/standardized-format-electronic-submission-nda-and-bla-content-planning-bioresearch-monitoring-bimo) for details.

PHUSE Team Response: 13th August 2020

The team has provided their response to the question on "Requirements for Clinical Site Data and Subject Level Data Listings for FDA CDER's Inspection Process (also called BIMO submission or OSI Pre-NDA request)." in the past. https://www.phusewiki.org/wiki/index.php?title=Requirements_for_Clinical_Site_Data_and_Subject_Level_Data_Listings_for_FDA_CDER%27s_Inspection_Process_(BIMO)

_____________________________________________________________________________________________________________________
These questions are primarily going out to the sub-team that worked on the Best Practices for Submission of Event Adjudication Data Whitepaper. The whitepaper provided very useful tips on how to map adjudicated data to the new custom SDTM domain of EA. The following are the follow-up questions to this whitepaper.

Are there any plans of including the EA domain in future CDISC SDTM IG releases? If so, which IG is this being targeted for? Is it ok to assume that sponsors can submit this as a custom domain to regulatory agencies until then?

PHUSE Team Response: 14th July 2020

CDISC SDS informed that the adjudication project is under consideration and may be in the future SDTMIG (beyond SDTMIG v3.4). Submitting EA as a custom domain is allowed by the current SDTMIG. The proposed domain in the whitepaper is based on previous submission experiences and can be used for submission until a new domain is published by the CDISC.

The whitepaper did not get into any suggestions on how to map this into ADaM. This may be intentional, as it may depend on the nature of the analysis surrounding adjudicated data or even the type of adjudicated data itself. Is there any general recommendation you can make?

PHUSE Team Response: 14th July 2020

For ADaM, a statistical/reporting analysis plan determines which data should go into the analysis datasets and how the data are used for reporting and associated analyses. An example is not included in the whitepaper because, in general, only the final adjudication assessment is included in the ADaM dataset. However, an example of how to capture final assessments in EA domain is provided in the whitepaper.

_________________________________________________________________________________________________________________

Is exposure data from the parent study required to be in the SDTM data of a follow-up study (no treament given in follow-up study)? Is it required for FDA and PMDA? Can the exposure data be carried over from the parent study SDTM into the follow-up study SDTM data, or does it need to be re-collected on the CRF of the follow-up study?

PHUSE Team Response: 9th January 2020

In general, if the data is not collected on the CRF for the follow up study, then it is not recommended to report that into SDTM datasets. In this example, we recommend not to carry it over to SDTM for the follow up study. Instead, this information can be presented in the analysis dataset.

___________________________________________________________________________________________________________________________

1) Is there a Standard in the Industry of how they determine the study start date for clinical studies? Is it the protocol finalised date, first subject in date or first initiation date?

PHUSE Team Response: 22nd November 2018

As per the guidance from the FDA - Providing Regulatory Submission in Electronic Format - Standardised Study Data, 'the study start date for clinical studies is the earliest date of informed consent among any subject that enrolled in the study'. For example, see Study Start Date in the SDTM Trial Summary Domain (TSPARMCD = SSTDTC). For nonclinical studies, the study start date is the date on which the study protocol or plan is approved (signed) by the Study Director, also known as the study initiation date. For example, see Study Start Date in the SEND Trial Summary Domain (TSPARMCD = STSTDTC). This definition is consistent with the Study Data Standardised Plan (SDSP) PHUSE template, which is reviewed and authorised for usage.

References

FDA Guidance, "Providing Regulatory Submissions In Electronic Format —Standardized Study Data” https://www.fda.gov/downloads/Drugs/Guidances/UCM292334.pdf

Study Data Standardized Plan PhUSE template https://www.phuse.eu/css-deliverables, direct link to the template: https://www.phuse.eu/documents//sop/wp/phuse-tp001-study-data-standardization-plan-v1-8409.docx

_______________________________________________________________________________________________________________________________

PHUSE Team Response: 26th April 2018 - Requirements for Clinical Site Data and Subject Level Data Listings for FDA CDER's Inspection Process (also called BIMO submission or OSI Pre-NDA request). Please note, as there is a lot of detailed information here, a new page has been created. Click this link to review the teams response

__________________________________________________________________________________________________________________

1) What goes in the 'misc' folder with an m5 eCTD folder structure? For example, a lookup file containing SMQ assignment. The file is used during the creation of pooled ADaM to support an ISS. We want to provide this dataset to the reviewer. This does not contain subject’s data and it is not SDTM or ADaM. Should this go to the 'misc' folder? or to the analysis folder and described in the define.xml and classified as non-ADaM? or is it enough to describe its structure in the ADRG?

PHUSE Team Response: 12th April 2018

According to the FDA Study Data Technical Conformance Guide (version 4.0), Section 7, which describes the Electronic Submission Format, the misc folder should “contain datasets that do not qualify as analysis, profile, or tabulation datasets in this subfolder.” These datasets should be in SAS Transport Format (.xpt). Since these datasets do not qualify as analysis, profile, or tabulation they do not need to be included in the define.xml however information about use of these datasets should be included in the reviewer’s guide.

If you have other documents/files that support the creation of your datasets, be they analysis or tabulation, or your TLGs, such as a spreadsheet for CTC Toxicity Grade or SMQ assignment, you can convert it to an acceptable format (e.g. PDF, TXT, or XPT) and place these in the “misc” folder. The file name must be in all lowercase letters or numbers with no spaces or special characters, only a hyphen is allowed in the name. Conventions on the files names can be found in the FDA document International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use, Appendix 2, Name, page 11-12. Information about these additional files and their use in creating the datasets should be included in the reviewer’s guides.

Additional References:

https://www.fda.gov/downloads/ForIndustry/DataStandards/StudyDataStandards/UCM384744.pdf https://www.fda.gov/downloads/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/UCM163556.pdf
__________________________________________________________________________________________________________

1) Does the legacy data in non-CDISC format need to be converted to SDTM for all studies that are part of the FDA or PMDA submissions? If a sponsor has one pivotal study in non-CDISC and the other pivotal study in CDISC, do I need to convert both to CDISC format before submission?

PHUSE Team Response: 7th June 2017

FDA:

The study submitted electronically must be in CDISC format if the study start date is after Dec 17th, 2016.

If ALL studies included in the NDA started after the mandate date and data are collected in legacy format, then yes, the conversion from legacy to SDTM is required.

If ALL studies included in the NDA started prior and do not meet the CDISC mandate date of Dec 17th 2016, then it is still acceptable to submit the data in legacy (non-CDISC) format.

In addition to the CDISC mandate above, if there is no consistent data format across ALL studies, e.g. the pivotal studies are in SDTM format, but the rest supporting studies in legacy format. The data contents and formats are proposed in the briefing package (BP) before the meeting with FDA, the reviewers either agree with your proposal or request different contents and formats.

The Study Data Standardization Plan, which can be shared as early as the pre-IND and is recommended prior to the EOP2, is a way to communicate with FDA proposed study standards for nonclinical and clinical studies within an IND/indication. This is the opportunity to agree upon study standards early in the development of a compound.

The SDSP:

Is used to establish and document a plan for describing the data standardization approach for planned studies within a specific submission in the development program.

Contains information about the intended and/or current state of data standards that are being used for studies within a compound.

Is used as a communication tool with the FDA or other Health Authorities to ensure that the reviewers understand the data standards that the sponsor is using for each study.

Is recommended to be included as part of a regulatory submission to Health Authorities.

PMDA:

Since October 2016, PMDA accepts submissions in CDISC format. Until March 2020, there is a transition period during which PMDA accepts the legacy submission and partial data submission (hybrid submissions). Sponsors need to have the special consultation meeting (consultation on data format of submission of electronic study data) with PMDA when decided to submit the electronic datasets (approximately one year before the submission - it will be the timing of the decision of the submission package) in order to agree about the electronic datasets format for NDA submission.

From April 2020, all required study data need to be submitted in CDISC format, whatever when the study started. Studies in legacy format will need to be converted; No waivers are allowed on this point. Closed or completed studies will require data conversion if study meets eStudy data submission criteria as described in the Basic Principles on Electronic Submission of Study Data for New Drug Applications (binding document):

  • Target studies (phase I and CP studies, phase 2-3 studies) will be those classified as evaluation study in submission package
  • If phase I or CP study used as evaluation study and is one of the following types, then electronic data always required
  • Phase I studies of oncology drugs
  • Phase I studies conducted on both Japanese and non-Japanese subjects (e.g.; global clinical trials and bridging studies)
  • QT/QTc studies based on ICH E14 guideline


For other phase I and CP studies that don’t meet above criteria, electronic data required when PMDA needs them for their review. The study types will be those where standard PK analysis conducted, Population PK, and PBPK.

Additional References:

FDA Binding Documents:

FDA Non-binding documents and other resources can also be found in the FDA webpage for Study Data Standard Resources.

PMDA Binding Documents:

PMDA Non-Binding documents and other resources can also be found on the PMDA website for Advanced Review with Electronic Data Promotion Group


__________________________________________________________________________________________________________

1) How do I make a test submission to the FDA?

PHUSE Team Response: 7th June 2017

FDA provides a dedicated website page on how to Submit an eCTD or Standardized Data Sample to the FDA – see reference below.
The pages provides recommendations and steps to submit a sample submission.

Additional References:

Submit an eCTD or Standardized Data Sample to the FDA.: https://www.fda.gov/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/ucm174459.htm


__________________________________________________________________________________________________________

1) Will JumpStart (DataFit) services be available for pharma clients before submission? What kind of checks are included in JumpStart?

PHUSE Team Response: 7th June 2017

1) JumpStart as a Service is specific to FDA. There are multiple versions of open source validator tools available for use that are similar to the version of DataFit that FDA use. Use of a validator to check for compliance issues and inclusion of a Study Data Reviewer’s Guide will get a sponsor close to all the information FDA looks at during the data fitness portion of a JumpStart service. The standard demographics analysis panels are available via the google code repository held by the PhUSE Standard Scripts working group. FDA will be sharing more scripts in the near future.

Additional References:

https://github.com/phuse-org/phuse-scripts


__________________________________________________________________________________________________________

1) When will CDISC (SDTM/ADaM) data standards be mandatory for data submission and how does this differ from for each regulatory agency?

PHUSE Team Response: 12th September 2017

The data standards requirements may differ from country to country and each regulatory body will have their set of requirements. Below you will find basic available information from the US (FDA), Japan (PMDA), and other countries that may or may not require dataset submission at this point.

US (FDA): CDER and CBER strongly encourage IND sponsors and NDA applicants to consider the implementation and use of study data standards as early as possible in the product development life cycle so that data standards are accounted for in the design, conduct, and analysis of studies.

  • Sponsors whose studies start after Dec. 17, 2016, must submit data in the data formats supported by FDA and listed in the FDA Data Standards Catalog. This applies to NDAs, BLAs, ANDAs, and subsequent submissions to the types of applications.


  • For INDs, the requirement applies for studies that start after Dec. 17, 2017.



FDA Submission Type Timing
NDA, ANDA, and certain BLA submissions Studies which start after 2016-12-17 (December 17th, 2016)
Commercial INDs and amendments, except for submissions described in section 561 of the Federal Food, Drug, and Cosmetic Act Studies which start after 2017-12-17 (December 17th, 2017

For the definition of "study start date," see the Guidance for Industry, Providing Regulatory Submissions in Electronic Format - Standardized Study Data (PDF - 131 KB)

Source for FDA:
-US FDA Website on Study Data for Submission to CDER and CBER
-US FDA Website on Study Data Standards Resource

Additional reference documents/webinar for FDA:

Study Data Standards in eCTD: What You Need to Know About the New Technical Rejection Criteria, October 12, 2016: eCTD Study Data Standards Webinar.

Japan (PMDA): Electronic data submission starts from 01-Oct-2016 with the transition period as noted in the table below.

PMDA Submission Type Timing
NDAs (eStudy Data submission criteria*) - Transition Period Submission on or after 2016-10-01 (October 1st 2016) until 2020-03-31 (March 31st, 2020)
All NDAs (eStudy Data submission criteria*) Submission on or after 2020-04-01 (April 1st, 2020)

During the transition period, PMDA accepts the legacy submission and partial data submission (hybrid submissions)

  • Sponsor need to have the special consultation meeting (consultation on data format of submission of electronic study data) with PMDA one year before the submission (it will be the timing of the decision of the submission package).



  • During that meeting, Sponsor needs to have an agreement with PMDA about the electronic datasets for NDA submission.



All required study data need to be submitted in CDISC format after April 1st, 2020

  • No waivers are allowed after this date. All the clinical studies data meeting eStudy submission criteria* must be compliant to CDISC standard format for submissions on or after April 1st, 2020. Therefore closed or completed studies in legacy format need to be converted.



*eStudy Data submission criteria: electronic data in CDISC format needed for studies meeting the following criteria.

  • Target studies (Phase I and Clinical Pharmacology studies, Phase 2-3 studies) will be those classified as evaluation study in submission package
  • If Phase I or Clinical Pharmacology study used as evaluation study and is one of the following types, then electronic data always required
  • Phase I studies of oncology drugs
  • Phase I studies conducted on both Japanese and non-Japanese subjects (e.g: global clinical trials and bridging studies)
  • QT/QTc studies based on ICH E14 guideline
  • For other phase I and Clinical Pharmacology studies that don't meet above criteria, electronic data required when PMDA needs them for their review. The study types will be those where standard PK analysis conducted, Population PK, and PBPK



Supported standard and versions (data standard catalog) and validation rules including rejection criteria are available together with applicable guidance on the PMDA Advance Review with Electronic Data promotion group website.

Source for PMDA:
-PMDA Techical Notification for Electronic Data Submissions
-PMDA Website for Advanced Review with Electronic Data promotion group

The below response for other regulatory agencies was put together on 28-Jun-2017, the regulation may have updated since then. We strongly suggest checking each regulatory website for most current information.

-Other countries like Europe, China recommend the use of CDISC data standards and define.xml following the FDA requirements but they do not mandate it yet.

As far as the European Medicines Agency (EMA) goes, the Clinical Trial Advisory Group on clinical trial data formats (CTAG2) is working on advising the EMA on clinical data formats, where it is leaning toward CDISC standards (although if it accepts, it would likely follow a similar progression as the FDA, with a 2-3 years pilot. CTAG2 provided the EMA with recommendations to use CDISC (SDTM/ADaM) and define.xml similarly to FDA requirements. Final advice to the European Medicines Agenda from the clinical trial advisory group on Clinical trial data formats. (30APR2013).

Source from EMA:


China Food and Drug Administration (CDFA) has endorsed CDISC standards in their Clinical Trial Data Management Technology Guide* (July 2016): they mention "CDISC standards have seen more and more recognised and widely used in the industry, has become an international clinical trial data "common language"

Although, not yet mandatory in every country, CDISC data standards has operational use, such as transfer between organisations, sponsor warehousing, etc., such that it is a good idea to produced CDSIC complaint datasets, even if not technically required for submission. This also allow to create one unique package with ver few or minor updates for submission in different countries.

*English translation of the Clinical Trial Data Management Technology Guide is not available on the CFDA website. CDISC website has its own translation of the Document in English.

Source for CFDA:
CFDA Website (Chinese)
CFDA Website (English)

Topic: Trial Design Domain (TDD Sub-Team)



Do you create TA and TE domain for Observation Studies. There is no intervention/medication given to subject in this type of study. There are two type of observational study:
1) Retrospective trial. For example, a study to observe subjects who had taken medication in past.
2) Prospective study. For example, a study to observe the biomarkers in subjects who have certain traits as oppose to subjects who don't have those traits.

PHUSE Team Response: 12th May 2020

TA and TE as described in the SDTM were conceived of in the context of a prospective trial, usually an interventional trial. The concepts may be of interest in observational studies, but it will take some thought to apply them. There may be time periods of interest in a retrospective trial, and data collection may be keyed to those time periods. For example, a study of subjects who took a particular medication might collect data about the subject before, during, and after they took the medication. For prospective study, there might be only one arm and one epoch (observation), but there would be a plan for data collection. Trial Sets may be useful for representing groups of subjects with different preexisting characteristics. Trial Sets are described in the SENDIG, but can be adapted for use in human clinical trials. There is a webinar in the CDISC archive on this topic.

________________________________________________________________________________________________________

According to SDTM-IG 3.3, Example 2, Row 2: https://www.cdisc.org/standards/foundational/sdtmig/sdtmig-v3-3#Trial+Summary, when TSPARMCD=TPHASE and the value is not applicable, 'NA' should be mapped to TSVALNF.

If this is the case, then why is there CDISC SDTM Terminology of 'NOT APPLICABLE' in the TPHASE CodeList? These are the cases I found in CDISC SDTM Terminology where a TSPARMCD CodeList value matches a value in ISO 21090 Version: SDTM Terminology 2019-06-28 CodeList: CL.C66737.TPHASE CodeList Value: NOT APPLICABLE CodeList Value ID: C48660 CodeList: CL.C99078.INTTYPE CodeList Value: OTHER CodeList Value ID: C17649
''

PHUSE Team Response: 9th January 2020

The team have decided that it is the simplest for implementers to use the value from CT rather than mapping to TSVALNF. This will also be noted as a known issue with SDTMIG v3.3. CDISC are working towards publishing these known issues on their website.

___________________________________________________________________________________________________________________________

In SDTM-IG 3.3, there is inconsistency with TSVAL when TSPARMCD=FCNTRY. In the IG example dataset at 7.4.2 Trial Summary, TS-examples, TSVAL is assigned the full country name and TSVALCD is assigned the alpha-3 code: https://www.cdisc.org/standards/foundational/sdtmig/sdtmig-v3-3#Trial+Summary

IG Appendix C1, it says TSVAL should bee assigned the alpha-3 code: https://www.cdisc.org/standards/foundational/sdtmig/sdtmig-v3-3#Trial+Summary+Codes

For reference, in SDTM-IG 3.2, in the example dataset, both TSVAL and TSVALCD are assigned the alpha-3 code. Appendix C! is consistent for FCNTRY across 3.2 and 3.3. It seems like they deliberately changed this in the 3.3 examples, but forgot to change this in the Appendix. For FCNTRY, should full country name or alpha-3 code be mapped to TSVAL?


PHUSE Team Response: 7th January 2020

CDISC has verified that TSVAL was changed to the full country name in error. It should have been the alpha-3 code. CDISC has noted this as a known issue for SDTMIG v3.3 and will correct in a subsequent version.


_________________________________________________________________________________________________________________________________

Storing dictionary versions in Trial Summary dataset (TS). As per SDTM Terminology_29Mar2019 we have the below code list (C66788). We are required to store MedDRA and WHODrug dictionary versions in SDTM and ultimately reflect in analysis TLF's. DICTNAM Dictionary Name C43820 MedDRA Medical Dictionary for Regulatory Activities C49475 WHODD World Health Organisation Drug Dictionary. The current solution is to store in supplemental datasets, however, this means repeating the same data for every record. As an alternate solution, will below be in violation of CDISC guidelines?

  • TSPARMCD TSPARM TSVAL TSVALCD TSVCDREF
  • DICTNAM Dictionary Name MedDRA 22.0 Medical Dictionary for Regulatory Activities
  • DICTNAM Dictionary Name WHOIDD WHODrug Global B3 March 2019 World Health Organisation Drug Dictionary


PHUSE Team Response: 31st July 2019

Not a violation if recorded in SUPP or in TS, as they are not required in either, as per CDISC SDTM IG. They should be included in the SDSP and in Define.XML. It's also optional to add into DRGs. DICTNAM is not valid CT for TSPARMCD as per most recent NCI SDTM CT

_____________________________________________________________________________________________________________________________________

1) Why are Screen Failures and Not Assigned not represented in TA?

PHUSE Team Response: 7th June 2017

1) TA represents only paths where things happen as desired. There are many circumstances where things don't happen as desired, including screen failures, drop-outs before study completion, and the study being terminated before completion. Although a protocol may deal with handling some of such circumstances, including all these in TA could overwhelm the desired paths with all the undesired paths. This scope (desired paths, rather than all paths) was part of the original proposal from Norman Stockbridge at FDA.

Additional References:

N/A


__________________________________________________________________________________________________________

1) How should a subject that is incorrectly dosed be represented in SE (i.e. a subject is randomized to Drug A, but receives Drug B)? Unplanned element?

PHUSE Team Response: 7th June 2017

An element which does not occur in the Trial Elements (TE) dataset should be represented as unplanned.

An element which is not part of the arm to which a subject was assigned but does appear in the TE dataset should be represented using the appropriate ETCD value.

If Drug B was an element in TE, then for a subject who received the treatment described in the Drug B element their SE records would include a record for the Drug B element, regardless of whether they were assigned to an arm that included that element, as defined in the Trial Arms (TA) dataset.

Improvements to the examples for DM and SE were included in the Public Review of SDTMIG v3.3 Batch 3, and are expected to be included in the final standard. The revised examples include values for ACTARM and ACTARMCD, which help to represent the situation when subjects are not treated as planned.


Additional References:

N/A


__________________________________________________________________________________________________________

1) How to define an unplanned Element in SE? Example: unexpected washout

PHUSE Team Response: 7th June 2017

If an element was unplanned for the subject but still a planned element for the trial, then in the SE dataset for that subject the actual element name should be used rather than ETCD = UNPLAN. ETCD = UNPLAN would be used when the element does not exist in TA/TE.

Additional References:

N/A