Question | Teams Collective Response |
---|---|
Naming Convention for Split RS Domain In my company, questionnaires are split and have a split dataset name. The Eastern Cooperative Oncology Group (ECOG) performance status, which was initially mapped into QSEG, now needs to be mapped into RSEG, according to SDTM IG v3.3. However, there is also an RS domain for Disease Response forms, resulting in a compliance issue. To solve this issue, I propose a split dataset name for Disease Response in RS (RSRS). Either keep RS as it is because it is not a questionnaire or keep RSEG and provide an explanation of the P21 issue in the cSDRG. What do you think? Do you have any recommendations? | PHUSE Team Response: 26 March 2024 Suggest either keeping everything in RS, including ECOG, or splitting RS into multiple datasets with different names (e.g. RS01, RSDR) and avoiding using a suffix that may be similar to a standard domain name (e.g. RSEG may be confused with having a relationship to the EG domain). The assumption is for the split datasets to add up to become the original domain (FA, RS, QS). It is acceptable to treat the individual response scores as split datasets; however, in that case, the upper-level domain (e.g. RS) cannot be included in the data package. |
Can an SDTM domain that is in the SDTM IG v3.3 be used for a study that is using the SDTM IG v3.2 to map the study data? Will this domain be considered a custom domain and need to be documented in the cSDRG? Similarly, some variables are defined in a TAUG but are not part of the SDTM IG version that is being used for a given study. Can such a variable be added to the parent domain in the tabulation domains? How should this addition be documented in the cSDRG? | PHUSE Team Response: 24 June 2022 There is no harm in borrowing domains from a later SDTM IG version or as documented in a TAUG to add as part of the study tabulation domains. Domains such as AG and CC have been included in the SDTM IG v3.3 and are part of the Alzheimer’s Disease TAUG (for AG) and the Cardiovascular TAUG (for CC). The sponsor may choose to include this information in the cSDRG to add clarification for a regulatory reviewer. It is not required by either CDISC or PHUSE. There is also no harm in adding variables documented in a given TAUG but not yet existing as part of a parent domain in the SDTM IG version. The SDTM IG version 3.3, for example, has included the FOCID variable as part of the OE domain. In order to avoid any Pinnacle 21 findings, however, it is recommended to add such variables in the supplemental qualifier of the domain. Note that the SDTM model differences should also be taken into consideration. The FOCID variable mentioned above, for example, should be added into the supplemental qualifier if the other variables recommended to be included in the FO domain by the SDTM model associated with the SDTM IG v3.3 are not present. Additionally, standardised controlled terminology and standardised external dictionaries linked to the SDTM IG version and model should also be taken into consideration when implementing such variables into the domains. |
Missing severity in the Pinnacle 21 Community Version 3.1. In general, we will execute Pinnacle 21 Community version and justify any outstanding issues present in Pinnacle 21 report under section 4.1 of the Reviewers Guide with severity level. Initially, Pinnacle 21 report used to have various severity levels e.g. Error, Warnings, Notice, Reject. But now the Pinnacle 21 Community version 3.1 (FDA Engine version 1907.2) report will only show severity for rejection rules.
| PHUSE Team Response: 16 March 2021 The PHUSE SDTM/ADaM Implementation FAQ team reached out to the eData team at the FDA. Responses received from the eData team on 1st Feb, 2021 are summarised below:
|
What are FDA Business Rules and Validator Rules?. | PHUSE Team Response: |
20 July 2018 |
20 July 2018 |
20 July 2018 |
20 July 2018 |
|
Section 2 of the 'CDISC ADaM Validation Checks V1.3' document states:
|
| |
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: |
7 June 2017 |
. See reference section below. |
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_
submission.
| |
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: |
7 June 2017 |
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 |
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: 7 June 2017 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. |
The validation software used by the FDA is very buggy. How do we |
recognise 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?. |