forked from elong0527/r4csr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
submission-overview.Rmd
41 lines (34 loc) · 1.82 KB
/
submission-overview.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# (PART) eCTD submission {-}
# Overview {#submission-overview}
The electronic Common Technical Document (eCTD) is a standard format for
the electronic submission of applications, amendments, supplements,
and reports from the applicant to the regulator.
The eCTD offers a solution to submit documents stored in a
standard directory structure, with file integrity validation
mechanisms in place.
To submit TLFs created by R to regulatory agencies, we should follow
the spirit of the existing eCTD submission guidelines to prepare
the deliverables, and provide the essential details in the relevant
documents for review.
The goal of the following two chapters is to provide guidance to follow
Section 4.1.2.10 of the
[FDA Study Data Technical Conformance Guide](https://www.fda.gov/media/88173/download):
::: {.rmdnote}
"Sponsors should provide the software programs used to create all ADaM
datasets and **generate tables and figures associated with primary and
secondary efficacy analyses**. Furthermore, sponsors should submit software
programs used to generate additional information included in Section 14
CLINICAL STUDIES of the Prescribing Information (PI)26 if applicable.
**The specific software utilized should be specified in the ADRG**.
The main purpose of requesting the submission of these programs
**is to understand the process by which the variables for the respective
analyses were created and to confirm the analysis algorithms**.
Sponsors should submit software programs in **ASCII text format**;
however, executable file extensions should not be used."
:::
Chapter \@ref(submission-package) will focus on preparing
proprietary R packages and analysis code into proper
formats for submission.
Chapter \@ref(running-environment) will discuss
the recommendations to make the R code running environment
reproducible for dry run tests and reviews.