No.

Question

Answer

Approval Date

A paper CTD may contain more than one copy of the same document. In the eCTD, do you have to include more than one copy of a file?

Separate entries in the XML backbone for each reference of the file can accommodate this need. The file should be included once in an appropriate place in the folder structure. Avoid duplicating the file.

February 2003

How should cross-references be presented in the eCTD?

CTD cross-references can be supported in the eCTD through the use of hyperlinks.

February 2003

Is it possible to change the values previously assigned to XML node attributes (e.g., the case where no value or the wrong value is placed in indication and later it is decided that a value/different value is necessary)?

Currently no.

This question generated change requests 00200 and 00210.

February 2003

It is very difficult to work out how to construct a valid index.xml file for the Control of Excipients section of Module 3 (3.2.P.4) without having to duplicate entries in the backbone and without deviating from the intended CTD structure. CTD expects that for each excipient a separate section 3.2.P.4.1 through 3.2.P.4.4 can be provided and that 3.2.P.4.5 and 3.2.P.4.6 are separate files. The eCTD cannot deliver a structure in which entries for 3.2.P.4.5 and 3.2.P.4.6 are not repeated either in the folder structure or as entries in the backbone.

This question was generated by change request 00100.

One way to construct a backbone is as follows:
Repeat the element m3-2-p-4-control-of-excipients for each excipient and assign the excipient attribute (e.g., magnesium stearate, and purified water) for each repeat. Under each of these include the leaf elements covering documents for 3.2.P.4.1, 3.2.P.4.2, 3.2.P.4.3 & 3.2.P.4.4. It is not necessary to include the leaf elements for 3.2.P.4.5 & 3.2.P.4.6 here. Then create another repeat of the element m3-2-p-4-control-of-excipients and assign the excipient attribute value 'animal-human-novel'. Include the leaf elements for 3.2.P.4.5 & 3.2.P.4.6 here.

The directory/file structure may look something like this :

whilst the structure of the index.xml file would be like the image on the next page:

February 2003

Certain TOC tags are not required by the DTD. It is unclear if these need to be completed 1) always if possible 2) only if this element is repeated or 3) only if a regional authority requests it. Please clarify.

To be consistent with CTD general Q&A, always include these attributes as appropriate:
- substance
- manufacturer
- product-name
- excipient
- indication
- dosage form

February 2003

Appendix 4 provides specific folder names for some sections and states other sections can typically be submitted, as individual files. What is the definition of 'typically' and what should be done when they are not typical?

There are now clear definitions of what is recommended for the granularity of documents provided in the ICH guidance on 'Organisation of the Common Technical Document for the Registration of Pharmaceuticals for Human Use'. This describes what is considered to be the appropriate granularity for each section of the CTD and hence eCTD. Where there is no definition provided in the organisation document, applicants are free to construct the dossier as they see fit so long as it adheres to the conventions for folder and file naming described in the eCTD specification.

February 2003

Is there any control in the eCTD Specification over terminology to be used for indications?

February 2003

How will the reviewer view and use the “append” operation attribute? It would also be useful to have clarifications on how review tools within agencies will handle these attributes.

The eCTD Specification is concerned with the transport of electronic CTDs from applicant to regulator. Consult regulatory authorities in each region on the electronic review tools each use to view this format.

February 2003

Will questions from Health Authorities be provided electronically using the specification?

The eCTD Specification provides a transport mechanism for one-way traffic from applicant to agency.

This question generated change request 00220.

February 2003

It is recommended to have the name of the root folder to be the application number or registration number of the drug. Unfortunately, in some European countries companies don’t get the application number prior to the submission. In the case of an MRP each country will give a different number creating an issue for naming the root folder. In some countries, the application number is given per pack size and/or strength, and the unique application number will be difficult to identify. A unique identifier such as for the FDA submission is therefore quite difficult to achieve in Europe.

Contact the regulatory authority for guidance.

February 2003

For the ID attribute, is it allowable to utilize an internal applicant identifier or would it need to be more understandable in order to support reasonable human identification (e.g. in reviewer to applicant correspondence about an issue).

The ID attribute is intended to be a unique reference within the submission that can be used to reference the item from another item within the XML document. XML requires the ID to begin with an alphabetic character. If an internal ID generator uses only numbers, appending a number to a leading alphabetic character that then could be used as the ID can create the ID.

February 2003

The eCTD Specification allows for one novel excipient in 3.2.A.3. What happens if there is more than one?

This question is identified in change request 00050.

The regulatory authority should be consulted for a solution until the change request is resolved.

February 2003

The specification currently states that there is an eCTD empty folder template on the ICH website. One is not located there. Where is it?

This question was generated by change request 00390

A file which can be downloaded and run to create an empty eCTD folder template is now available on the ICH website.

July 2003

What is the position on the use of digital signatures within the eCTD?

This question was generated by change request 00280

Currently there are no plans for the M2 Expert Working Group to address this issue. Regional guidance should be consulted for the current use of digital signatures.

July 2003

Are the filenames for documents referred to in Appendix 4 of the specification mandatory or optional?

This question was generated by change request 00110 and 00120

Filenames in the eCTD are optional. The ones provided are highly recommended. To assist the reviewer when several similar files are open at the same time, it can be appropriate to consider alternative naming conventions that could provide unique, understandable filenames. The general provisions for naming of files are in Appendix 6 of the Specification.

July 2003

Can clarification be provided about the necessity to provide full text indices (eg. Adobe Catalogue files) and if desired by the agencies, how and where they should be included in the backbone?

This question was generated by change request 00310

Full text indices are not required by any of the ICH regional agencies and therefore the provision of guidance is not necessary.

July 2003

Would it be acceptable to introduce a level of sub-folders not described in the eCTD specification to assist the submission construction process?

This question was generated by change request 00140

Yes

July 2003

Should bookmarks be presented expanded or collapsed? Should bookmarks for tables and figures be separate structures?

This question was generated by change request 00270

Insufficient experience is available across agencies to provide any formal guidance on this. It might not be considered appropriate to have all the bookmarks open since, in some instances, these can be so numerous that they are not useful to the review and it can affect ‘refresh’ time in a web-browser. Equally, it is probably not useful to have the bookmarks fully closed, since the reviewer would always have to open them. It is recommended, therefore, that the applicant considers the usefulness to the reviewers of how to present bookmarks and has some level of consistency across similar document types within the submission.

July 2003

Can clarification be provided for what should be included as values for the ‘font library’ attribute?

This question was generated by change request 00300

At present, no agency intends to make use of this attribute and therefore provision of guidance is not necessary.

July 2003

Are .tiff files an acceptable format for provision within an eCTD submission or should they be converted to .pdf?

This question was generated by change request 00350

The .tiff file type is not supported within the eCTD specification. The section in the specification should be consulted (Appendix 7) relating to acceptable formats.

July 2003

When using the ‘delete’ operation attribute a checksum is required. Since no file is being provided to assign a checksum to, how should this checksum attribute be used?

This question was generated by change request 00130

It is recommended that a null entry be made in the checksum attribute, i.e., double quotation marks with no entry between (“”).

July 2003

Is it feasible for legacy reports to continue to be submitted as a single file/document without being split into separate files/documents as per the M4 Organisation Granularity Annex.

Is there a specific date from which all reports should be structured in the M4 Organisation Granularity Annex described way?

This question was generated by change request 00460

For study reports that have already been produced or are currently in the process of production, it is considered acceptable to submit these as a single file if this is the way that they have been created.

It is recommended that new reports be created utilising the granularity described in the M4 Organisation Granularity Annex.

November 2003

Is the file name for an individual file fixed from beginning to end of life cycle?

This question was generated by change request 00590

No, except for names predefined in the eCTD specification or regional guidance, e.g. index.xml.

June 2004

Is the operation attribute for the regional (module 1) backbone xml file always new?

This question was generated by change request 00600

Refer to regional guidance.

June 2004

According to ICH E3 Structure and Content of Clinical Study Reports, the case report forms should be located in Appendix 16.3, the individual patient data listings in Appendix 16.4 and the publications and literature references in Appendices 16.1.11 and 16.1.12 respectively. The CTD organization provides locations for case report forms and individual patient data listings in Module 5.3.7 and for literature references in Module 5.4. Where should these items actually be placed in the CTD and the eCTD?

This question was submitted to the CTD Implementation Coordination Group.

The treatment in the CTD and the eCTD is different. For the eCTD:
PDF files for case report forms and individual patient data listings should be organised by study in the folder for Module 5.3.7. However, in the ~~index.xml~~ file the leaf elements for the case report forms and individual patient data listings should be included under the same heading as other study report files with additional information included with any accompanying study tagging file. In addition, a repeat of the leaf element ~~can~~ ~~be placed under the heading 5.3.7 Case Report Forms and Individual Patient Data Listings. Datasets, if required by the region, should be organised according to regional guidance.~~

~~Files for publications and literature references should be located in the folder for Module 5.4. However, in the~~ ~~index.xml~~ ~~file the leaf elements for the publications and literature references~~ ~~should~~ be included under the same heading as other study report files with additional information included with any accompanying study tagging file. In addition, a repeat of the leaf element should be placed under the heading for 5.4 Literature References.

THIS ANSWER IS WITHDRAWN. SEE Q&A #42

June 2004

October 2006

If an applicant submits an eCTD using Specification v3.0, how is forward compatibility with version 3.2 assured?

This question was generated by change request 00540

The recommendation is that applicants use the ID, even if using 3.0, to avoid future compatibility problems;
For previously submitted files, consult with the Regulatory Agency to ascertain how to resolve the lifecycle issue.

June 2004

Is it expected that one would stay with a given DTD version for the duration of an application, so that as long as submissions are made to the same application, one would use the same DTD version as for the original submission?

Would - on the other hand - the expectation be that new versions of the DTD are applied within a certain time period, across all submissions regardless of whether they are new or ongoing?
Also, if there is a need to change DTDs, how will the agency viewing tools present the cumulative view if there is a structural change to the submission eg. renaming of old sections, introduction of new sections etc.

The question was generated by change request 00690

Applicants are expected to use the current DTD as accepted in the individual regions. The M2 Expert Working Group and the agencies of the three regions will provide guidance on when to use new releases. The timing of the implementations of new releases will be determined as required. Regulatory changes (e.g. changes in the CTD) might have to be implemented immediately, while technical changes might be delayed to major new releases.

November 2004

Clarification should be provided by all ICH regions as to whether node extensions can be used in Modules 2-5
The ICH spec allows node extensions to be used in Modules 2-5 and their use in Module 1 is a regional matter. FDA states that node extensions are not supported in any part of the submission and this therefore invalidates the ICH spec. Experience on production of submissions for Europe demonstrates that node extensions are required to deliver a navigable structure for Modules 4 and 5. At present this means that eCTDs are not re-usable across regions and thus will create significant amounts of rework for industry. FDA should accept node extensions in Modules 2-5.

The question was generated by change request 00560

The use of node extensions should be discussed with FDA on a case by case basis. Other regions are able to accept appropriate use of node extensions in compliance with the eCTD specification (i.e. their use is discouraged unless there is no other feasible means to submit the information).
Refer to EU and MHLW regional guidance for specific instances where it can be used.

November 2004

May 2005

Can a single, global eCTD submission be constructed and transmitted to multiple regions, with each regional authority ignoring or deleting other regions' submission material?

The question was generated by change request 00700

This is not advised.

May 2005

Are applicant provided style sheets allowed?

The question was generated by change request 00710

Consult regional guidance

May 2005

Is a regional MD5 checksum file (xx-regional-md5.txt) needed?

The question was generated by change request 00720

Not needed, index.xml includes the checksum for this file.

May 2005

Japanese characters are 2 bytes. Can 64 characters still be used for file/folder names in Japanese?

The question was generated by change request 00730

The Specification 3.2 does not allow for Japanese characters in folder and file names.

May 2005

Do submission sequence numbers have to be consecutive, i.e., 0005 must be submitted after 0004?

The question was generated by change request 00760

For Japanese submissions, sequential numbering is required. For all other regions, it is preferred, but not required. For all regions, sequence numbers should be unique within the overall application.

May 2005

Can the operation attribute ‘new’ be used in subsequent submissions where there is already a file in the same node?

The question was generated by change request 00820

Yes, but there might not be many opportunities in Modules 2-5, where this could apply. This might be more applicable in Module 1 with items such as cover letters and application forms. Refer to table 6-3 of the Specification 3.2 for the appropriate use of the operation attribute.

May 2005

Can further clarification be provided on the related sequence element?

The question was generated by change request 00890

Related sequence is used differently across the regions. Consult regional guidance for details.

May 2005

From the eCTD experience of the IWG, what parts of the Specification are commonly misinterpreted that would prevent my eCTD message from being viewed by another applicant/regulator?

This question was generated by change request 00580

Based on experience, there have been different interpretations of the eCTD Specification that have prevented timely exchange of eCTD submissions. Those creating and viewing eCTD messages should adhere to the eCTD Specifications (ICH and regional) and consult with regional authorities to avoid these problems. The items in the following list already exist in the Specification 3.2, but have been summarized here to alleviate these problems. Adherence to these items is technically necessary to exchange eCTD messages. Extra controls might hinder the exchange of eCTD messages. The IWG will continue to monitor eCTD implementation to provide additional clarity.
Items 12 and 20 were updated on May 11,2007

May 2005

May 2007

The eCTD specification supports the ability to refer to a previously submitted file, for example, by including in sequence 0005 a leaf with Operation Attribute of 'new' that refers to a file submitted in 0000. Is it possible to indicate to the reviewer that they have already received and reviewed the file before? Could an additional Operation Attribute be considered for this type of cross-referenceing or re-use?

The question was generated by change request 01080

At this stage of the implementation of the eCTD, the four Operation Attributes (new, append, replace and delete) will remain and not be added to. With the existing specification it is technically possible to determine that a file is not in the current sequence, but is from a previous sequence.

Suppliers of eCTD viewing tools are encouraged to develop a visual way of displaying the difference between a leaf referring to a file in the current sequence and a leaf referring to a file in a previous sequence.

In this circumstance note that the list of items to be checked under Q&A No. 36 should allow for the xlink:href to refer to files in another sequence and not prevent viewing of the eCTD by another applicant/regulator.

Refer to regional guidance with respect to the allowance of reference to previously submitted files.

November 2005

The eCTD specification recommends not including a file more than once within a sequence. If multiple leaf references are intended to display a file in multiple locations within the eCTD, is it possible to indicate to the reviewer that this file is referred to more than once in the sequence, which might alert the reviewer that the file is displayed multiple times?

Could an additional Operation Attribute be considered for this type of cross-referencing or re-use?

The question was generated by change request 01080

November 2005

In Modules 2-5, instead of submitting pdf documents is it possible to submit XML documents?

The question was generated by change request 01250

It is recognized that there is a general trend towards describing the contents of documents with XML. However, the current specification supports only the use of XML for structured information. It can be interpreted from this that the submission of summaries, reports and other narrative documents in XML format is not currently supported by the specification. The specification also states that regulatory authorities and applicants could agree to use other formats regionally (including uses of the common formats in a different way from the above). Thus, if an applicant wishes to use XML for narrative documents, they should liaise with their regional regulatory authority, understanding that other regulatory authorities may not accept these XML files.

In the longer term, M2 may adopt a standard for describing narrative documents with XML.

November 2005

Can PDF version 1.4 be used across all regions?

~~The eCTD specification will be changed at the next release to indicate that PDF version 1.4 is the only version acceptable in all regions. Applicants should transition as soon as possible.~~
This answer has been withdrawn. See Q&A No. 46.

Nov-2005

May-2007

The M4 Granularity document requires that all pages of a document should include a unique header or footer that briefly identifies its subject matter.

With the eCTD there is a significant amount of metadata available to the reviewer to allow easy identification of the document concerned without the necessity to place an identifier in the header or footer. Is it necessary to include a unique identifier in an electronic only submission?

The question was generated by change request 1310.

When an electronic submission is made, there are still circumstances where it is appropriate to have a unique identifier on each page (header or footer) of the document, e.g. when the document is printed or multiple documents are viewed on screen at the same time. The unique identifier does not necessarily have to contain the CTD section identifier or other metadata. It should be sufficient to identify the general subject matter of the document, e.g. study identifier, batch number.

June 2006

Case report forms, data sets and individual patient data listings should be organized according to regional guidance.

Files for publications and literature references should be located in the folder for Module 5.4. However, in the index.xml file the leaf elements for the publications and literature references should be included under the same heading as other study report files with additional information included with any accompanying study tagging file. In addition, a repeat of the leaf element should be placed under the heading for 5.4 Literature References.

Oct-06

Please, confirm that a single file can replace multiple files from various previous sequences.

No, a single leaf operation can only target a single leaf element. It is important to distinguish between leaf elements and files. eCTD specifications describe the management of leaf elements, not files.

May-07

Please, confirm that a single file in an eCTD lifecycle can be replaced multiple times

No, once a leaf element has been replaced in an application it is no longer considered current. Only the current leaf should be replaced in a subsequent sequence.

May-07

How to update the eCTD metadata if the name of an excipient changes, as indicated in e.g. the USP/NF or European Pharmacopoeia? The names of excipients have to be incorporated in the metadata of an eCTD. It is even reflected in the folder names under 3.2.P.4. During the lifecycle of a medicinal product the name of a particular excipient used may change over time without alterations being made to the formulation.

How to deal on the level of the eCTD with alterations in the name of a particular compendial excipient?

How to deal on the level of the eCTD with alterations in the name of a particular noncompendial excipient?

The eCTD specification does not have an explicit mechanism for changes to attributes during life cycle. As a work around, applicants would delete all leafs within the element with the incorrect excipient attribute and re-submit them within an element with the corrected excipient attribute. This work around would apply to both compendial and non-compendial excipients. Please consult your agency before performing this operation.

May-07

ICH eCTD Question Number 40 asks whether it is acceptable to submit PDF V1.4 files across all regions. Although the answer given is in the affirmative, it actually goes much further than mere ‘acceptability’ by appearing to make V1.4 mandatory for eCTDs. Shouldn’t V1.4 be ‘acceptable’ or perhaps ‘preferred’ (if justified) rather than ‘mandatory’?

Q&A 40 is being retired and a new Q&A is created to read: all regions have agreed to accept PDF 1.4. Please consult regional guidance to submit other versions of PDF.

May-07

Is PDF/A-1 an acceptable PDF file format for documents submitted in an eCTD?

PDF/A-1 is an archive format and does not meet the ICH review needs for use with an eCTD.

May-07