The eCTD allows companies to submit clinical and nonclinical study reports in either legacy or granular format. The legacy format requires assembly of all sections of the report into one document, while the granular format allows each section of the report to stand as a separate document. Most companies submit clinical reports (in m5) using the granular format and nonclinical reports (in m4) using the legacy format. The granular format makes it easier to publish clinical study reports, but it requires planning and coordination between Medical Writing and Regulatory Publishing to achieve those efficiencies.
Study Tagging Files
In the eCTD world, both study report formats require study tagging files (STFs) for submission to the FDA. For legacy reports, the STF provides metadata about the report, including the report number, title, and in some sections, route of administration, duration, etc. STFs for granular reports contain the same information they would for a legacy report, but they also act as a table of contents that organizes the files in the report. Every file associated with an STF is identified with a piece of metadata called a file tag. The file tag identifies the type of information contained in that document. Examples of file tags include report body, synopsis, case report forms, datasets, and listings. File tags enable eCTD viewers to organize the report content into virtual folders, making it easier to navigate the hundreds of files that can make up a clinical study report. You can find more details on study tagging files in this ICH guidance document: ICH STF Guidance.
In the eCTD, most nonclinical reports are still submitted in legacy format. There are a couple of reasons for this. The first is that the use of datasets for nonclinical studies is still relatively new, and the standardized formats for that data have not been adopted as widely as the similar formats for clinical reports. Clinical reports generally contain a lot more data, so there was more emphasis on clinical data standards early in the development of the electronic submission standards. The CDISC consortium develops and maintains these standards. You can find more information about CDISC here: CDISC.org, and information about the FDA's implementation of these standards here: FDA Study Data Standards.
The other main reason that nonclinical reports are usually submitted in legacy format has to do with the QA process for those reports. Nonclinical reports are often written by CROs, and they often contain sub-reports that cover a specific discipline or type of analysis. The CRO has to sign off on the quality of the entire report, and then hand it off to the sponsor. The logistics of CRO QA processes and the relatively small size of these reports mean that most CROs prefer to stick with the legacy report format. As sponsors increasingly request granular reports and accompanying datasets, I think this situation will change, but right now there doesn't seem to be a rush to transition.
It is not common to submit clinical reports in legacy format in eCTD submissions. FDA encourages sponsors to submit clinical reports in the granular format with accompanying datasets. Given the size of most of these reports, not having to assemble everything into one document is actually a time saver for sponsors. The term legacy format refers to the way reports used to be assembled. Since some submissions contain study reports that may have been completed years ago, this option is still available for use as needed. I recommend not preparing new clinical reports in the legacy format if your company submits in eCTD format.
The granular report format actually makes it easier to publish a large clinical study report, but, of course, it brings its own challenges. Not having to assemble and paginate a 10,000 page report is a nice bonus, but requires more focus on the document management process. It's important to keep track of all the files that make up the report and make certain that they all end up in the right place in the submission. Every document still needs a leaf title and a file tag for the STF. The file tags allow eCTD viewers to group similar files together under headings. For example, case report forms are grouped by site. This grouping makes it easier for reviewers to navigate the hundreds of files that can make up a large report.
I strongly recommend that Regulatory Publishers work with Medical Writers and Statistical Programmers to help them understand how reports are organized in the eCTD. In particular, pay attention to file tags, leaf titles, and, most importantly, the table of contents of study reports as described in the ICH E3 guidance: ICH E3 Guidance.
In the eCTD world it is highly advantageous for clinical study reports to follow the numbering and heading titles of the E3 guidance. In the legacy format, Medical Writers had more flexibility to adjust the table of contents to their liking. In the eCTD world, that flexibility makes the Regulatory Publisher's job a nightmare. There is some flexibility in the organization of section 14 of the report, since that is part of the report body. There is no flexibility in section 16, since each section requires its own file tags and leaf titles, based on the E3 table of contents. If a particular part of section 16 is not applicable to a given report, leave it out, but don't change the numbering. It is not necessary to assemble all the components under a given file tag, however. Each document can go in separately, as long as the leaf titles differentiate the individual files.
While the legacy report format is still commonly used for nonclinical reports, clinical reports that will be submitted to an eCTD application should be in the granular format. It is important to coordinate between the Medical Writers, Statistical Programmers, and Regulatory Publishers to ensure that granular reports can be easily published in the eCTD submission. Once this coordination is in place, granular report publishing becomes an exercise in document management, where the focus turns to getting each file into it's proper place in the submission, with clear leaf titles and accurate file tags.
This is a complex topic with many nuances not covered in this post. Please post any follow up comments or questions below.