FDA Final Guidance Webinar Q&A
- What’s the best practice when there is no mention in the guidance while it is in the SDTM rule checks? For example, AE treatment emergent flag is expected in the SDTM check rules but is not mentioned in the guidance anymore.
Make sure to review all supporting documents including the Technical Conformance Guide, Data Standards Catalog, and published validation rules. For example, the “Validation Rules for Study Data Tabulation Model (SDTM) Formatted Studies” document that was published in November, 2014 has a special business rule FDAC022 (SD1097) with reference to SDTM IG example as recommended implementation approach. FDAC0022 Description: “According to FDA expectations, a treatment-emergent flag should be included in SUPPAE according to SDTM IG v3.1.2 #8.4.3″. For an overview of FDA validation rules see our FDA Validation Rules webinar recap.
- Is the Dec 17 version of guidance the final guidance? Why FDA still refers it as a draft guidance?
The FDA is aware of the need to remove “draft” from their Study Data Standards Resources page regarding the “For CDER and CBER: Draft Guidance for Industry – Providing Regulatory Submissions in Electronic Format — Standardized Study Data.” document link. To be clear, this guidance document is final.
- How are Community 2.0 updates implemented? I had submitted an issue regarding TS controlled terminology, which you all said would be fixed. But how will I receive those updates?
OpenCDISC Community v2.0 has an Auto-Update feature that will notify and update the software to the latest available release. The next update is expected in end of January.
- Can you speak of Pinnacle’s qualifications of interpreting the FDA guidance vs. other vendors in the market?
Pinnacle 21 develops OpenCDISC and FDA DataFit. Our consultants support multiple FDA teams including JumpStart, eDATA, and Standards Testing. Booz Allen Hamilton supports FDA in multiple facets, including data standards support across Centers (e.g. eData team support in CDER).
- It seems that DSC does not include QS-FT termimology whereas OpenCDISC has checks for the codelist. Should we follow QS-FT terminology for QS domain?
Yes, our recommendation is to follow CDISC QS Control Terminology.
- The timetable specifies that, for studies with a start date of 24 months after the notice, standard data is required. What about the studies that started prior to the requirement date? Can those “older” studies be submitted with legacy data standards?
Formally you may submit ‘older’ studies in legacy format. However, we highly recommend you to start implementing standardized data as soon as possible to avoid potential problems in the future. FDA provides some “grace period” to ensure that the industry has enough time for implementation. Before “final enforcement” date you need to propose your submission plan to the reviewer team and get agreement on it. In some cases FDA reviewers may want standardized data for older studies because it can facilitate the review process. If you have issues with converting legacy data, include in your Legacy Data Conversion Plan Report per the TCG for FDA review.
- which roles are typically involved in the communication with FDA on the data standard?
We recommend you include all relevant disciplines from Sponsor side (e.g. Biostats, clinical) to ensure any questions from FDA can be addressed. From the FDA perspective, include your division’s review team, and also the relevant technical SMEs (e.g., CDER eData, CBER CDISC) so that technical review can be done during any communication/meeting to expedite the process.
- Does it mean that ALL Phase I studies will have to be reworked afterwards in order to comply with current standards at time of the submission, sometimes years after they have been completed & analyzed?
No, you do not have to re-map your legacy studies. Formally, new FDA requirements are for new studies only with start dates after the indicated requirement dates. However, each particular case should be agreed to by the review team dedicated to your particular application.
- It is clear from the guidance all ADaM programs creating ADaM datasets supporting either CSR or ISS/ISE should be submitted. What it is not clear are requirements for submitting analysis output programs. In my experience I saw different approach/position, different interpretation depending on sponsors and/or reviewer preferences. e.g. asking only programs supporting key efficacy analysis. Could you please clarify if there is any specific FDA requirements / position for that?
New FDA guidance does not specify if all or only efficacy related programs should be submitted. You need to discuss this with the review team dedicated to your submission.
- Should the Data Standardization Plan include non-clinical studies?
Yes; The SDTCG explicitly asks for “clinical and nonclinical studies” to be included in the SDSP. See SDTCG, Section 2.1 for further details.
- I was wondering if there is any requirement with regards to analyisis output programs. I saw so far different approaches / positions both on FDA single reviewer and sponsor side. e.g. submitting any programs vs supporting key efficacy analysis output programs.
New FDA guidance does not specify if all or only efficacy related programs should be submitted. You need to discuss this with the review team dedicated to your submission.
- Is it the start of the study (maybe 3 month before first patient first visit) or the submission time that decide which version is required. I.e. If starting the study in something close to the latest version available at that time could there then still be a need to remap/upgrade later to a newer version ? Do all studies in a submission have to follow the same version (e.g. SDTM version, e.g. MedDRA version).
Yes; The SDTCG explicitly asks for “clinical and nonclinical studies” to be included in the SDSP. See SDTCG, Section 2.1 for further details.
- If we submit both split and none-split datasets, which datasets are documented in the define.xml document?
SDTCG #7.1: “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.” This means that you only need to document the non-split datesets.
- The technical guidance says re-screened patient should have a new SUBJID. Shouldn’t OCV allow multiple records per USUBJID, but single record per SUBJID?
There are no finalized detailed specifications on how to handle re-screened subjects in SDTM data. OpenCDISC Validator is expected to report all potential data issues. Sponsor should explain false-positive messages.
- Is there any requirements for special characters use in variable contents? e.g. not only in variable metadata but also actual contents
There are no formal requirements in the Guidance documents. In general FDA reviewers want to see ACSII characters and English text only. You need to clarify expectations with the review division.
- How does it work for the DM domain if a re-screened patient has a unique USUBJID with multiple SUBJIDs associated?
There are no finalized detailed specifications on how to handle re-screened subjects in SDTM data. There are two basic implementations options:
1. Two separate records in DM with the same USUBJID value, but different SUBJID, INVID, SITEID, DMDTC, etc.
2. One record in DM. Re-screened SUBJID and other info is provided in SUPPDM.
- We had a subject enroll in a study twice, screen and become randomized at 2 sites. With unique SUBJID, how will data show this relationship so reviewer knows it’s the same person?
USUBJID value must be the same across the whole application.
- My understanding was that the requirement of the Treatment Emergent flag with SDTM.AE was being downplayed, as it can be a complex analysis variable that, in my opinion, should be done in ADaM. The derivation can depend on date imputations, for example. But you are saying that it is required. What is correct?
Please refer to “Validation Rules for Study Data Tabulation Model (SDTM) Formatted Studies” document that was published in November, 2014. It has a special business rule FDAC022 (SD1097) with reference to SDTM IG example as recommended implementation approach. FDAC0022 Description: “According to FDA expectations, a treatment-emergent flag should be included in SUPPAE according to SDTM IG v3.1.2 #8.4.3″. For an overview of FDA validation rules see our FDA Validation Rules webinar recap.
- My understanding is that *.sas as sas program file names is acceptable in the technical conformance guide. Is that correct?
A formal eCTD requirement is to have “.txt” extension for ASCII text files. SDTCG provides an example for a sas program file as “adae.sas.txt”
- For all expected variables, domains, etc. are these included in the FDA validation rules available at OpenCDISC?
Yes, OpenCDISC Validator has checks for presence of SDTM Required and Expected Variables (SD0056/FDAC0017 and SD0056/FDAC0020) as well as additional “FDA Expected” variables (SD1077/FDAC0021)
- About : “SDTM doesn’t contain imputed data”. so in relation to the previous topic “Treatment emergent Flag expected for Adverse Event”, how to manage this in the SDTM, as imputation date have to be done, if missing, before calculate the Treatment emergent flag.
1. Populate only Derived info in SDTM data. Keep Imputations for ADaM. If for some AE records you cannot derive a Treatment Emergent Flag, then keep this info missing in SDTM, but impute it in ADaM. However your AE data are expected to have TRTEM Flag for most records.
2. Ensure that your data collection process is well designed (e.g., a separate form or a check box for TRTEM AEs) and well managed (cleaning of AESTDTC).
- Concerning imputations, so if a date is partial it should not contribute for example to form SE, correct?
Yes, no imputations in SDTM. If you have partially missing dates in SE form, you are in big trouble. Please ensure that your team follows GCDMP.
- At the CDISC Interchange, agreement was reached between SDS and ADaM teams to remove baseline flags from SDTM (replace with flag for last obs before exposure), and derive them solely in ADaM. Did that happen too late to be included in the December guidance?
During the last CDISC Interchange, standards’ development teams proposed a new approach to handle Baseline info for future versions of SDTM. It’s not finalized and not a part of any current SDTM version. Also, keep in mind that FDA is not CDISC. While submission data are based on SDTM standard, some review specific data elements are expected by FDA team. A Baseline Flag is an example.
- Will the FDA further clarify if patient profiles will be needed in the future after SDTM becomes mandatory?
If Tabulation data is submitted in SDTM standard, then patient profiles are not required. Using standard tools and data in standized format allows FDA reviewers to easily generate patient profiles. If FDA does require profiles, they will likely ask for that information.
- Since sponsors are not currently accustomed to discussing their data plan via a formal SDSP at their FDA meetings, will FDA provide guidance to sponsors so those who can discuss the data plan (Standards or Statistical Programmers) will be invited to attend the Pre-IND or end of Phase II meetings, or is it up to the sponsor to know this should occur?
The FDA is engaged with PhUSE Working Groups who have tasked themselves with generating templates for industry to utilize. We suggest engaging in these groups for further information, or attend the PhUSE CSS in March 2015.
- Should the “treatment emergent” flaf left blank when not fully completed AESTDTC and/or AEENDTC? (the imputation can be obvious only with the partial dates)
It depends on particular data. A general rule is that SDTM data should keep only derived data, while imputations are expected in ADaM.
Treatment Emergent Flag is usually derived based on Start Date. However if AESTDTC is (partially) missing and AEENDTC is before RFSTDTC, then you know that AE is not TRTEM.
If partially missing AESTDTC is enough to make conclusion about TRTEM status, then it’s still derived, not imputed info.
Examples:
1. AESTDTC=2015-01, RFSTDTC=2014-12-31: AE is Treatment Emergent.
2. AESTDTC=2014, RFSTDTC=2015-01-07: AE is Not Treatment Emergent.
3. AESTDTC=2015, RFSTDTC=2015-01-07: You cannot derive Treatment Emegrent Flag. Imputations are required.
Please ensure that you provide full and detailed documentation on you computational algorithms in study metadata.
- Is the use of WHO DD dictionary mandatory for CM or other dictionaries can be used?
WHO Drug Dictionary is commonly used for coding of Concomitant Medication. Please consult with FDA review devision if you have a plan to use other dictionary. This should also be reflected in your SDSP.
- With the advent of a new “misc folder” instead of listings do you think that FDA is getting away from generating listings for each study? It seems that the datasets (SEND, SDTM, and ADaM) would stand alone to support any listings.
Once the standards requirements are in effect, the idea would be that listings would be replaced by the SDTM tabulations data, so yes.
- Does FDA expect that OpenCDISC warnings be documented in the SDRG?
FDA expects that all reported messages be documented in SDRG. It includes Errors, Warnings and Notices.
E.g., if during ADaM validation you received a “DM is missing or lacks necessary variables and cannot be used for this cross-dataset validation” notice, it means that you did not include DM dataset needed for some ADaM cross-reference checks. You are expected to re-run ADaM validation with DM and EX datasets added or find some reasonable explanations why you did not run DM-ADaM cross-reference checks.
- Based on the 2 year implementation plan from 2014-12-17 does the agency have the authority to “request” sponsors to comply with the standard earlier?
Review team dedicated to your particular application may make any additional requests. Communication with review division is key for succesful submission.
- If we need to file NDA in 2016 do we still need to convert legacy data to SDTM
Please communicate with the FDA reviewer team dedicated to your particular application. Formally in 2016, data in legacy format may be accepted so long as study start date is before the FDA required dates.
- Since submitted data should now be relevant for review and analysis, how would a Sponsor determine what data may not be relevant? For instance, if a protocol calls for 4 hourly vital assessments, yet a monitored patient has 24 hours of data, can only the protocol defined data be provided? If so, how would one represent this decision in the data?
FDA guidance encourage sponsors to communicate with the review division on study specific questions.
- For NDA submission in 2016 do we need to follow Clinical Data Validation Rules release by FDA
For NDA submission in 2016 you need to follow the most recent version of Validation Rules available at that time. Current version of Business Rules for SDTM data is a good starting point.
- Hi, would you please describe typical traceability problems FDA may have between collected (CDASH or company standard) and submitted data (SDTM, ADaM).
The most common traceability problem is poor documentation for study data. For example, no descriptions, annotations or other metadata on sponsor-specific variables like –SPID, –GRPID, even in cases when those variables are Key Variables in datasets. Another example is a confusing or unclear mapping of legacy data to SDTM format. Usage of appropriate CRF design by utilizing existing standards (e.g., CDASH, CT) may simplify SDTM conversion process and provide expected traceability between collected and submitted data.
- When we submit a different SUBJID (and different USUBJID) for the same subject twice, how does the FDA identify that these two records in the SDTM domains belong to the same subject?
You must to populate the same USUBJID for the same person. FDA does not disclose their fraud-detection algorithms.
- How do you view relationship between CDISC, Pinnacle 21 (OpenCDISC), and FDA?
Pinnacle 21 is a company that develops OpenCDISC and was founded by the original creators of OpenCDISC. Pinnacle 21 is also a Platinum member of CDISC and participates on several CDISC development teams. However, there is no affiliation between Pinnacle 21, OpenCDISC, and CDISC. FDA is a customer of Pinnacle 21 and is using our OpenCDISC Enterprise platform (aka DataFit) for validation of submission data. Pinnacle 21 consultants also support multiple FDA teams including JumpStart, eDATA, and Standards Testing.
- In the first timeframe example, can the SDTM v4.1 be added to the list of supported standards sooner?
FDA has a special procedure for testing new standards before their acceptance and inclusion in the Data Standards Catalog. The standard must first be finilized by SDO before it can be reviewed and accepted as an update to the DSC.
- For the ADRG are you saying that the agency wants specific data duplicated in the ADRG even though it is in other documents so the ADaM reviewer has one source or are you saying that they do not want data duplicated in ADRG and ADaM reviewers will always reference multiple documents so data is in only one source?
The FDA has stated in the TCG that they are aware of potentially duplicate information in the ADRG as in other documents, but that is still the Agency preference.
- Does the Study Data Standardization Plan (SDSP) need to be included in the eCTD file folder structure for a NDA submission? OR, is this Standardization Plan not going to be part of the eCTD files but simply provided to the FDA in the FDA-Sponsor meetings?
The SDSP should be located in the General Investigational Plan section of eCTD (1.13.9) and also provided to the Agency during your meeting.
- As the Technical Conformance Guide supersedes the CDER Study Data Common Issues Documents, does this mean that guidance specified on the CDER Study Data Common Issues Documents but NOT on the Technical Conformance Guide is no longer applicable? To be specific, the CDER Study Data Common Issues Documents on page 11 specifies that RFSTDTC should be the start of treatment with only 2 exceptions (I enclose the guidance below in double quotes). Could you please shed some light on this? “Study Day variables (–DY, –STDY, andENDY) are calculated based on RFSTDTC. For most study designs, RFSTDTC should be the start of treatment. RFSTDTC may be some other event only when 1) a substantial proportion of subjects will not receive study treatment (e.g., when the study includes a non-treatment control arm), or 2) the planned treatment administration is dependent on the subject experiencing a disease episode, and not on any fixed study day.”
Since the TCG supercedes previous documents, you should use the most recent version of the FDA’s “current view”. That being said, if a study in a submission has been formatted based on a previous FDA opinion, then this information should be shared in the SDRG as rationale for any deviations from current expectations.
- Will studies complete prior to 2015 in non CDISC structures that are part of electronic submission after the 2017 deadline be require to be converted to CDISC format.
Formally studies completed prior to 2015 are not required to be submitted in SDTM format. However we advise you to confirm expectations with your review team.
- Is EPOCH required for any other domain besides DS?
Yes, EPOCH is expected to be populated in all datasets where this variable can facilitate review process by selecting records for particular treatment period. E.g., EPOCH is expected in AE, LB, VS, PC, etc. EPOCH may be not useful and can be dropped out in MH, SC or IE domains.
- Please can you clarify the common issue around arm etc. Was the the issue that the ARM was missing or was not?
FDA guidance asks to populate a missing value in ARM variable for Screen Failures and in ACTARM variable for Not Treated subjects. This requirement is inconsistent with SDTM specifications. Additional clarifications from FDA is expected.
- When you show “Trial Design domains should be included” is that actually the FDA definition where “should” = “must” or is it really just “should”?
“Trial Summary (TS) domain must be included because there are several applications which require it. All expected Trail Summary Parameters must be populated.
Other Trial Design domains are rearly used by tools today. Discuss with your FDA reviewer team if you may not include them into submission data for particular studies? We recommend to always populate Trial Design domain for application pivotal studies.”
- What about file size restrictions when using the DATA-XML format? Seems to me that the 1 GB restriction might actually present an issue if the filesize restriction applies to non-compressed file
Currently the Dataset-XML format is not an FDA accepted format for submission data, though it is currently being assessed by the Agency.
- What do you mean by “just include key variables” in SUPPQUAL? What is your definition of “key variable”? My understanding is that we have to submit ALL collected medical items. Can we withdraw a collected medical item from submission for the reason that it does not fit into CDISC nomenclature and?
“Key data” means any review and analysis related information. Here are some examples of “non-key data”:
1. Data management info like Samples Tracking, data querries, confirmation on form completions, etc.
2. EDC system related info like internal subject id or record number on CRF
3. Other operational info
4. Metadata like MedDRA versions should be stored in define.xml, not SUPPQUAL domains
- Do baseline flags in SDTM need to match those in ADaM which has definition defined in the statistical analysis plans that may differ from the definition of a baseline visit on the CRF or in the Protocol?
ADaM has a set of special Baseline variables. If you use SDTM –BLFL variable in ADaM data then its value must match values in SDTM data. Analysis Baseline variables are independent from SDTM –BLFL. See ADaM IG for details.
- While SDTM and ADaM data are considered GCP files, are define files considered GCP document?
Since the goal of GCP is to assure quality, reliability, and integrity of data collected, we would consider the associated define files as GCP documents.
- if many of the date based SDTM (endtc etc.) vars aren’t used for any analysis outputs are they still required to be included in the ADaM dataset? I’ve heard mix thoughts about over cluttering the ADaM if variables aren’t needed at all for the analysis.
No only Analysis related SDTM variable should be included in ADaM datasets. Well-designed ADaM datasets have traceability info which can provide a reference to SDTM records for additional details if needed.
- What is the purpose of submitting the unsplit dataset files in addition to the split files?
FDA cannot modify your data. Submission of both split and un-split datasets provides flexibility in their usage through a variety of analytical tools.
- In the PhUSE White Paper Best Practices – Assigning VISITNUM to Unscheduled Visits and Assigning EPOCH to Observations states For partial observation dates, the EPOCH should be assigned based on chronology of known date parts (e.g., 2013-06 is chronologically after 2013-05-17). The Technical Conformance Guide states If the data needed to derive these variables are missing, then these variables cannot be derived and the values should be null. Are these contradictory statements or not?
Calculation of EPOCH is quite tricky in case of partially missing dates. No imputations are permitted in SDTM data. If data allows to derive EPOCH, then EPOCH value should be populated. If different interpetations may exist and some impuatations are required then EPOCH variable value should be missing in SDTM data.
- As per the FDA Guideline ACTARM should be NULL or BLANK for NOT TREATED subjects. Issue. Suppose a subject has passed all the Inclusion/exclusion criteria and has been enrolled in the study and further randomized to a particular arm (eg: ARM A) , but during the course of study, this subject never received the study drug then the arm and actarm will be as below: ARM = ARM A ACTARM = NOT TREATED
Acording to FDA SDTCG ARM=A, ACTARM has missing value. SDTM IG expects to have value “NOT TREATED” in ACTARM. This inconsistency needs clarification from FDA.
- Please clarify: aCRF should contain variable names AND coding. And an example.
The aCRF maps data collection fields to corresponding variables or variable values within a dataset. For example, “Outcome” would have the variable name “AEOUT”, though coding may need to be provided for specific values of a variable.
- Which Domains do we need to include Screen failure data within?
DM, IE, DS and anything related to the protocol specific I/E criteria. E.g., MH, LB, etc.
- For some NDAs , you may have studies that have already implemented Company standards prior to the 2017 requirement and then a few new study starts post 2017 that are required to use CDISC. For the submission (NDA), it will have a “hybrid” of standards – do you need to convert entire NDA to CDISC? All the examples in the guidance only speak to new study starts, no the submission (NDA) type examples. We have lots of NDAs planned in 2017 and it is not clear what the expectation is for the NDA that is a hybrid.
The standards used for each study should be listed explicitly in a Study Data Standardization Plan (SDSP), as discussed in the SDTCG, as early as the pre-IND meeting. Data format is study specific. You may use SDTM for one study and legacy for another one. Usage of different SDTM versions are also permissible across (but not within) studies. Please discuss your Standardization Plan with your FDA review team. The FDA is aware that data conversion may not be feasible for all cases, so your rationale should be provided in the SDRG.
- In the case of the double-blind trial and an extention study– the subject can have two different subject number. I thought in the processing of the USUBJID, the subject would carry the same USUBJID from the double-blind trial to the extention study as well as the ISS pooling. Is this not correct?
There are many different types of Subject Ids. For example,
1. Subject may have several randomizations during the study and some associated Randomization Numbers
2. Subject may be re-screened on the same or different sites with different Screening Numbers
3. Subject may be moved across different sites or geografical locations with diffrent Site ID
4. Etc.
In some cases it could be a real challenge to handle all those different IDs. Nevertheless one rule must be followed in all implementations. USUBJID valud must be the same for the same person.
