Question	Teams Collective Response
Should any upversioning be done when submitting studies that use older versions of SDTM/ADaM IGs?	PHUSE Team: 25 February 2025 The sponsor should discuss any requirements for upversioning the submission datasets with the regulatory agency review team early on. In general, Define-XML may need to be upversioned, but not to the latest SDTM/ADaM IGs since the study start date in the TS domain is before 2017. Known issues/non-compliance resulting from running datasets using older versions of the SDTM/ADaM IG on the current compliance rules should be documented into the appropriate sections of the data reviewer’s guides. Upversioning to a common SDTM/ADaM IG and harmonising controlled terminologies may be required for integrated analyses purposes. Methods of upversioning to a common IG and harmonising controlled terminologies should be documented into the appropriate sections of the data reviewer’s guides for integration datasets or in the Study Data Standardization Plan (SDSP), as indicated in the FDA Study Data Technical Conformance Guide v5.9, section 6.1.2 (dated October 2024, https://www.fda.gov/media/153632/download):
Question	Teams Collective Response
Should eCOA forms be included in the acrf.pdf, in addition to the EDC forms, and submitted as part of eCTD M5? What about central lab and ECG data?	PHUSE Team: 02 February 2025 According to the SDTM Metadata Submission Guidelines v2.0, section 3.1.1 (pg 7, https://www.cdisc.org/standards/foundational/sdtm/sdtm-metadata-submission-guidelines-v2-0): eCOA forms should be annotated and appended to the end of the traditional eCRF pages. However, central lab and ECG collection information does not need to be formatted on a physical page and annotated. The list of such tests performed in the protocol provides sufficient information on what was collected.
Question	Teams Collective Response
I have the following questions related to submitting Define-XML for ADaM datasets to the FDA. Metadata of ADaM datasets is submitted separately from the metadata of SDTM datasets. However, several SDTM variables are copied over to the ADaM datasets for traceability, which initiates following additional questions for these variables: Should we apply the FDA rule for same-named variables per dataset submission package (i.e. separately for ADaM vs SDTM datasets)? The FDA business rule v1.5 is “a variable’s length across a study should be no longer than the maximum length of the actual data (except for SUPPQUAL)”, following the FDA’s Study Data Technical Conformance Guide v4.9 section 3.3.3: “The allotted length for each column containing character (text) data should be set to the maximum length of the variable used across all datasets in the study except for SUPPQUAL datasets.” Should variable length in ADaM datasets be the same as the variable length in SDTM datasets, also in the case of different actual data in ADaM datasets (e.g. because only a subset of records was used)? Should the complete SDTM codelist be copied over to the ADaM metadata, even when some values are no longer applicable in the ADaM dataset (e.g. for a --TEST that is not retained in ADaM)? Should the order of values in the codelist of SDTM variables in the ADaM Define-XML be identical to that in the SDTM Define-XML?	PHUSE Team: 29 January 2025 The following guidelines have been published by CDISC to help answer these questions: SDTM Metadata Submission Guidelines v2.0 (https://www.cdisc.org/standards/foundational/sdtm/sdtm-metadata-submission-guidelines-v2-0) ADaM Metadata Submission Guidelines v1.0 (https://www.cdisc.org/standards/foundational/adam/adam-metadata-submission-guidelines-v1-0) Note that the FDA's Study Data Technical Conformance Guide v5.9, published in October 2024, itemises this guidance in Appendix D to “have been evaluated by CBER and CDER and are not considered to align with their current business needs.” The conformance guide further states: “Consult with your division for more specific instructions.” Define-XML Office Hours Webinar recording: https://www.cdisc.org/events/webinar/define-xml-office-hours PHUSE Define-XML Version 2.0 Completion Guidelines (https://phuse.s3.eu-central-1.amazonaws.com/Deliverables/Optimizing+the+Use+of+Data+Standards/Define-XML+Version+2.0+Completion+Guidelines.pdf) Valid strategies may be adopted for a successful submission package depending on the uniqueness of the submission. The sponsor should directly contact the FDA’s eData team for any specific questions about interpreting the FDA Study Data Technical Conformance Guide (email CBER at mailto:cber-edata@fda.hhs.gov or CDER at cder-edata@fda.hhs.gov). The following are answers to the itemised questions: There have not been any requirements suggested from CDISC ADaM to harmonise the variable lengths for same-named variables in ADaM. At most, ADSL variables carried into other ADaM datasets may need to be the same variable lengths to avoid merging warnings or setting the attribute from the first dataset. When retaining SDTM variables in ADaM datasets for traceability, the sponsor should keep all attributes – except length – the same. The length can be different depending on any sub-setting being done within the ADaM datasets to satisfy the analysis needs. The CDISC ADaM Metadata Guidelines v1.0, section 2, pg. 5, states that: “No definitive guidance exists as to whether codelists in Define-XML should contain all of the possible values for a given study. For example, suppose only mild adverse events have been reported for a study where the data collection instrument collected AE severity as Mild, Moderate or Severe. The sponsor could opt to include all three possible terms in the codelist or limit it to only the single term present in the data. In the sample submission, we have chosen to include all possible values in the codelists.” There is no specific guidance on the order of the codelist terms/values in Define-XML. Some variables may not have an inherent order and may not add any more value to what is being conveyed in the Define-XML document.
I have the following questions on the CDISC Define-XML v2.1.7 guidance, as the examples do not provide full clarity: Can you confirm the dot (.) should not be taken into account when determining the length of datatype=float variables? If so, when including a def:displayFormat, should we apply this as (length+1).significant digits (e.g. length=4, significant digits=2 -> displayFormat=5.2)? Although Define-XML does not limit the number of characters used, is there a recommended maximum length for comments/derivation algorithms beyond which a separate supporting document with ‘additional derivations’ is recommended? Does the stylesheet have limitations on the maximum length for presentation? Per FDA Study Data Technical Conformance Guide v4.9, section 3.1.5 – “Variable values are the most broadly compatible with software and operating systems when they are restricted to ASCII text codes (printable values below 128). Use UTF-8 for extending character sets; however, the use of extended mappings is not recommended” – multi-byte characters are allowed (either in derivation algorithms and/or comments but also in variable values). Do you have more insight into submission of data containing multi-byte characters? Even though we have been trying to eliminate any non-basic ASCII characters from source data, this is not always easy. So, if there are (clearly defined) situations where it is allowed, this would be helpful. Should the length of such variables be determined based on the number of bytes or on the number of characters?	PHUSE Team: 29 January 2025 The following guidelines have been published by CDISC to help answer these questions: SDTM Metadata Submission Guidelines v2.0 (https://www.cdisc.org/standards/foundational/sdtm/sdtm-metadata-submission-guidelines-v2-0) ADaM Metadata Submission Guidelines v1.0 (https://www.cdisc.org/standards/foundational/adam/adam-metadata-submission-guidelines-v1-0) Note that the FDA's Study Data Technical Conformance Guide v5.9, published in October 2024, itemises this guidance in Appendix D to “have been evaluated by CBER and CDER and not considered to align with their current business needs”. The conformance guide further states: “Consult with your division for more specific instructions.” Define-XML Office Hours Webinar recording: https://www.cdisc.org/events/webinar/define-xml-office-hours PHUSE Define-XML Version 2.0 Completion Guidelines (https://phuse.s3.eu-central-1.amazonaws.com/Deliverables/Optimizing+the+Use+of+Data+Standards/Define-XML+Version+2.0+Completion+Guidelines.pdf) Valid strategies may be adopted for a successful submission package depending on the uniqueness of the submission. The sponsor should directly contact the FDA’s eData team for any specific questions about interpreting the FDA Study Data Technical Conformance Guide (email CBER at mailto:cber-edata@fda.hhs.gov or CDER at cder-edata@fda.hhs.gov). The following are answers to the itemised questions: Please refer to the description of the length in the table in the Define-XML v2.1 document, section 4.3.1: “The largest allowable whole number width plus the maximum number of decimal digits.” Sponsors should note that the length pertains to the requirement that the receiving system be able to process and store values, whereas the displayFormat pertains to the presentation. There is no recommended maximum length, as this would be sponsor-defined. The sponsor should consider the user experience of the reviewer to ensure readability of the Define-XML document when setting this length. Most sponsor organisations have a mapping file that will map special characters (e.g. foreign languages other than Japanese or Chinese) to the closest ASCII printable values equivalent or, if not found, leave as blank. a) The sponsor should discuss with the FDA, as it is not recommended to use characters beyond ASCII printable values below 128, per the FDA’s Study Data Technical Conformance Guide v4.9, section 3.1.5. As stated in the PHUSE white paper Transport for the Next Generation, the SAS v5 XPT file “only supports US ASCII Character encoding. No multibyte characters are possible; this requires translation and/or transcription from the source data.” (Pg 4 of reference: https://www.cdisc.org/sites/default/files/2023-05/Transport-for-the-Next-Generation-Version-1.0.pdf) b)The definition of text length in the Define-XML v2.1 document is mentioned in section 4.3.1 to be the maximum allowable length of the characters.
When is it a good idea to submit an eCTD or standardised data sample to the FDA, since ‘they are not reviewed by FDA reviewers at any time’, per FDA TCG section 7.3 [eCTD Sample Submission] (https://www.fda.gov/media/153632/download)? Here are some possible situations: A submission for a new therapeutic area A submission for a new indication A submission for a new product A submission for a product where the data structure has changed	PHUSE Team: 15 August 2024 The purpose of submitting a standardised data sample to the FDA is to determine if the gateway submission is successful. As per Submit an eCTD or Standardized Data Sample to FDA \| FDA – the document that is footnoted in FDA TCG section 7.3 [eCTD Sample Submission] (https://www.fda.gov/media/153632/download) – it is indicated that: ‘The validation of sample submissions does not involve scientific review of the content and is only intended to address conformance to FDA supported electronic submission and data standards.’ It is probably best to interpret the TCG statement of they are not reviewed by FDA reviewers at any time’ as referring to ‘scientific review of content’, and, without confirming with the FDA directly, a good faith understanding that the FDA could possibly review from the perspective of ‘conformance to FDA supported electronic submission and data standards’.
How do I interpret the FDA Study Data Technical Conformance Guide section 3.3.2 (Dataset Size) with respect to documentation of submitted datasets in Define-XML? Should I only consider documenting the non-split datasets/domain in the Define-XML; that is, only documenting the datasets present in the datasets folder in Define-XML, while the split datasets that are submitted under the ‘split’ sub-folder should only be explained in the Data Reviewer’s Guide?	PHUSE Team: 29 August 2023 There are generally two situations for splitting datasets: because of dataset size constraint, or for illustrative purposes. When splitting for dataset size constraint, the split is done after the creation of the whole dataset. Section 7.2 of the Study Data Technical Conformance Guide states: “If you need to split a file that exceeds file size limits (see section 3.3.2), you should submit the smaller split files in the ‘split’ sub-folder in addition to the larger non-split file in the original data folder. There is no need for a second Define-XML file to be submitted within the split subfolder.” There is no need to document the split datasets in Define-XML for submission. These split datasets only need to be documented in the Data Reviewer’s Guide. When splitting for illustrative purposes, such as the FA or QS domain, the FDA’s eData team recommends submitting the split datasets without the inclusion of the whole dataset. Document only the split datasets in the Define-XML. It is recommended to discuss this illustrative split with the regulatory agency prior to submission. Note that the SDTM Metadata Submission Guidance discusses this as well: “The split datasets do not require additional Define-XML documentation.” The ADaM Metadata Submission Guidance does not mention split.
If a sponsor has to submit additional datasets (e.g. ADaM) to the already submitted study to the FDA, should the sponsor submit Define-XML that includes all the datasets (new and old) or a Define-XML with just the new datasets? Will these new datasets be placed in the same folder as the original datasets? Or will they reside in a separate folder? Should the Define file be called the same name (i.e. Define-XML) to avoid conflict with the original Define file with old datasets if only new datasets are submitted later?	PHUSE Team Response: 10 June 2023 The Study Data Technical Conformance Guide (TCG) [https://www.fda.gov/regulatory-information/search-fda-guidance-documents/study-data-technical-conformance-guide-technical-specifications-document], currently v5.2, updated in May 2023, has two relevant sections that assist in addressing this question. Section 4.1.1.2 (SDTM General Considerations) indicates the following: Each submitted SDTM dataset should have its contents described with complete metadata in the Define-XML file (see section 4.1.4.5) and within the cSDRG as appropriate (see section 2.2). When updated datasets (e.g. ‘ae.xpt’, ‘lb.xpt’) are submitted, updated and complete Define-XML and cSDRG covering all datasets should be submitted using the “replace” life cycle operator to update the original file. Section 4.1.2.2 (ADaM General Considerations) indicates the following: Each submitted ADaM dataset should have its contents described with complete metadata in the Define-XML file (see section 4.1.4.5) and within the ADRG as appropriate (see section 2.3). Unlike SDTM, where it is required to always maintain the same SDTM dataset names, ADaM datasets that are resubmitted can have new dataset names that are different from the original submission. Regarding the Define-XML specifically, the TCG wording can be interpreted at least two ways: 1) Each time new information is submitted, a new Define-XML is needed. 2) Only the first Define-XML is considered in the submission, so anything further requested is just supplementing what is already there. Sponsor experience with ADaM dataset resubmission has varied. In some cases, after ADaM datasets were initially accepted by the FDA and then more data was requested, a separate Define-XML, along with the new ADaM datasets, was provided. In the experience of some sponsors, new ADaM datasets have been provided to the FDA with or without the Define-XML dependent on the time frame and the speed of the response. If ADaM datasets have been accepted by the FDA and more data is requested, a Define-XML may be prepared with new data only in a separate directory. The Define-XML may not need to be renamed. Sometimes the same ADaM dataset names can be used. If there are challenges in set-up or other considerations, different ADaM dataset names can be used as long as they are clearly explained in the response letter. Sometimes the FDA accepts additional ADaM datasets without a Define-XML, but this is an exception. When resubmitting subsets of ADaM data, the successful experience of some sponsors is to only include updated datasets in Define-XML to avoid broken links. There is not a one-size-fits-all solution for ADaM dataset resubmission since it depends on the circumstances, so discussion with the FDA review division is essential. The location of resubmissions within m5 of the eCTD is the responsibility of the regulatory publishing team members.
Do sponsors who are considering submissions for oncology studies under RTOR (Real Time Oncology Review) need to adhere to the OOD Safety Data Specifications that are mentioned in this RTOR guidance? It seems that these specifications were still under review by CDISC. What is the current status of the review? Even if it is under review, what is the FDA’s position on adhering to these specifications for upcoming submissions under RTOR?	PHUSE Team Response: 25 April 2023 As per the FDA (email dated 11 April 2023), OCE/OOD safety data specifications are meant to serve as a good practice recommendation and are not considered mandatory at this time. However, the FDA has sought feedback and is planning to release an updated version shortly. Flexibility is included for sponsors on how the ADaM datasets are submitted under RTOR while still following ADaMIG v1.1 CDISC guidance. For formal advice on RTOR data submission for a study under consideration, the sponsor organisation should submit the questions in a meeting package to the corresponding review division.
How should a sponsor handle requests from the FDA related to the creation of a table containing outputs in the pivotal trials of a submission, including hyperlinks to the code used to create the table and the primary ADaMs used? (See the example below.) This request is a) different from the ARM deliverable embedded in the Define-XML that we create as part of a submission and b) not specified in any FDA guidance to date.	PHUSE Team Response: 28 February 2023 While this has not been commonly experienced, the response and method of providing the information may be specific to when it has been requested by the regulatory agency. If the request is made by the regulatory agency ahead of the submission, the sponsor may utilise the Analysis Data Reviewer's Guide (ADRG) section 7.2 and include the additional columns and hyperlinks for Input Data and Program File. For requests by the regulatory agency after the submission, the sponsor may consider providing a document containing the list of program files, the output number and output title produced by the program file, and a description of each where necessary. Refer to the Study Data Technical Conformance Guide for a list of valid file types that can be included in the submission to the FDA. Sponsors should discuss the need to provide executable code with the regulatory agency ahead of providing the program files.
When you submit a custom ADaM dataset like ADAE2 (in addition to ADAE), how do you validate it prior to your submission?	PHUSE Team Response: 25 August 2022 Sponsors can include multiple ADAE datasets in a study as there is no guidance dissuading the use of multiple analysis datasets for adverse events. The use of multiple ADAE datasets will also not result in any Pinnacle 21 finding. However, it is possible for a reviewer from a given regulatory agency to expect a single ADAE dataset, in which case the sponsor may be required to prepare an overall dataset. One method of combining all adverse events into a single dataset may be the use of ACATy or the use of multiple TEAE flags corresponding to each treatment drug in addition to the primary TEAE flag (refer to the ADaM Structure for Occurrence Data (OCCDS) Implementation Guide v1.1). Additionally, AOCCFL can be utilised in combination with TRTEMFL, and TRTEMwFL and AOCCzzFL can be created for the drug w.
What kind of information about a subject with multiple screenings needs to be submitted to the FDA? The FDA Study Data Technical Conformance Guide (v4.8.1, October 2021) includes the following description regarding a subject with multiple screenings: 4.1.1.2: “Subject Identifier (SUBJID) The variable SUBJID uniquely identifies each subject that participates in a study. If a single subject is screened and/or enrolled more than once in a study, then the subject’s SUBJID should be different for each unique screening or enrollment. For a study with multiple screenings and/or multiple enrollments per subject, SUBJID should be included in other related domains besides DM even though it may cause validation errors. It is recommended to include a table linking each SUBJID for a single subject to that subject’s USUBJID with any additional necessary explanation included in the relevant RG.” 4.1.1.3: “DM Domain (Demographics) In the DM domain, each subject should have only one single record per study. Screen failures, when provided, should be included as a record in DM with the ARM, ARMCD, ACTARM, and ACTARMCD field left blank. For subjects who are randomized in treatment group but not treated, the planned arm variables (ARM and ARMCD) should be populated, but actual treatment arm variables (ACTARM and ACTARMCD) should be left blank. For subjects with multiple enrollments within a single study, the primary enrollment should be submitted in DM. Additional enrollments should be included in a custom domain with a similar structure to DM. Clarifying statements in the RG would be helpful. For subjects with multiple screenings and no subsequent enrollment, include the primary screening in DM with additional screenings in a custom domain with a structure similar to DM. For subjects with multiple screenings and subsequent enrollment, include the enrollment in DM with screenings in a custom domain with a structure similar to DM.”	PHUSE Team Response: 11 March 2022 While the FDA's Study Data Technical Conformance Guide (v4.8.1, October 2021) sections 4.1.1.2 and 4.1.1.3 specifically mention how to store data related to subjects with multiple screenings or enrolments in the SDTM domains, sponsors may be varied in their approach to identifying records associated to each screening or enrolment attempt. The Multiple Subject Instances Team at CDISC is currently working on creating the new DC domain that will address this issue. For each USUBJID, this domain will contain multiple entries for each time that the subject screened or enrolled into the study. The SUBJID value will reflect the subject identifier for that time of participation. The Multiple Subject Instances Team at CDISC is also recommending the SUBJID to be included in the parent domain as a permissible variable, following the FDA Study Data Technical Conformance Guide section 4.1.1.2. The new DC domain and this recommendation will be included in the future release of SDTM IG v4.0. The SDTM ADaM Implementation FAQ provided the following examples of how some sponsors are capturing multiple subject instances using the current SDTM domains and variables. Your company may choose to represent this data differently. It is suggested that any concerns about the way the data is captured be discussed with the FDA prior to submission to ensure that it will not cause a denial at the time of submission. Some sponsors may set the value of SUBJID to be consistent within each domain, matching it to some portion of the value of USUBJID, and use the --REFID variables to map each screening or enrolment subject identifier. The use of --REFID for this purpose should be mentioned in the cSDRG. Instead of generating the custom domain to capture additional screening identifiers or enrolment identifiers (mentioned in section 4.1.1.3 of the FDA Study Data Technical Conformance Guide), sponsors may be capturing the additional identifiers in the supplemental qualifier of the DM domain (SUPPDM). The additional data stored in SUPPDM should be described in the cSDRG. Some sponsors have already added the SUBJID into the parent SDTM domains, following the FDA Technical Conformance Guide section 4.1.1.2. Some sponsors have defined the SVSTDTC and SVENDTC variables in the SV domain to be the start and end dates of the first attempts at screening or enrolment and last attempt of screening or enrolment, respectively. Similarly, the SESTDTC variable in the SE domain can been defined as the very first informed consent date.
Does clinical trial data need to be submitted at the time of an IND submission? If it is needed, does a full data package need to be submitted, including all SDTM domains, ADaM datasets, reviewer’s guides, and Define files with the complete validation?	PHUSE Team Response: 11 March 2022 While clinical trial data and the complete data package are not required to be submitted at the time of IND, it would provide the FDA with an early look at the clinical data and the ADaM datasets that the sponsor is considering for the study. The data submitted may include any previous experience with the study drug in humans (often from foreign use). It is always good to discuss the need for submitting data at the time of the IND with the review division at the agency at the Pre-IND meeting. The review division can then decide if they would like to receive and review the data.
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: 13 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. BIMO
These questions are primarily going out to the sub-team that worked on the Best Practices for Submission of Event Adjudication Data White Paper. The White Paper 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 White Paper. 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: 14 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 White Paper is based on previous submission experiences and can be used for submission until a new domain is published by the CDISC. The White Paper 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: 14 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 White Paper 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 White Paper.
Is exposure data from the parent study required to be in the SDTM data of a follow-up study (no treatment 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: 9 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.
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: 22 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 —Standardised Study Data” https://www.fda.gov/downloads/Drugs/Guidances/UCM292334.pdf Study Data Standardised Plan PHUSE template https://phuse.global/Deliverables, direct link to the template
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: 12 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 Technical Requirements for Registration of Pharmaceuticals for Human Use. 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: Electronic Common Technical Document Specification Technical Conformance Guide 2018
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: 7 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 Standardisation 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 NDA's (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: Providing Regulatory Submissions in Electronic Format Section 745A(a) of the Federal Food, Drug, and Cosmetic Act, Guidance for Industry Standardised Study Data, Guidance for Industry FDA Non-binding documents and other resources can also be found in the FDA webpage for Study Data Standard Resources. PMDA Binding Documents: Basic Principles on Electronic Submission of Study Data for New Drug Applications Q&A Guide "Basic Principles on Electronic Submission of Study Data for NDA's" PMDA Non-Binding documents and other resources can also be found on the PMDA website for Advanced Review with Electronic Data Promotion Group.
How do I make a test submission to the FDA?.	PHUSE Team Response: 7 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 Standardised Data Sample to the FDA.
Will JumpStart (DataFit) services be available for Pharma clients before submission? What kind of checks are included in JumpStart?.	PHUSE Team Response: 7 June 2017 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 GitHub code repository. FDA will be sharing more scripts in the near future. Additional References: https://github.com/phuse-org/phuse-scripts
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: 12 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. Beginning after the dates specified above, FDA may refuse to file for NDAs and BLAs or refuse to receive for ANDAs any electronic submission whose study data do not conform to the required standards specified in the FDA Data Standards Catalog. See the Technical Rejection Criteria for Study Data (PDF - 87 KB). 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 Providing Regulatory Submissions in Electronic Format - Standardised 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 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 Technical 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. Advice to European Medicines on Clinical trial data formats. (30APR2013) Source from EMA: EMA Website page on Documents from advisory groups on clinical-trial-data 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)

Browser not supported