We have collected Cunesoft’s preferred list of eCTD related articles
- Values and disadvantages of outsourcing the regulatory affairs tasks in the pharmaceutical industry in eu countries
- Comparative study for generic drug approval process
- New requirements for electronic submissions of DMFs
- Harmonised technical guidance for eCTD submissions in the EU
- Checklist: DMF Road to Readiness
- Checklist: eCTD Road to Readiness beyond 2017
- eCTD Submission Process Diagram
The ICH Common Technical Document (CTD) provides a common format for marketing authorization submissions in all ICH markets, and use of this format is now mandatory. The Electronic Common Technical Document (eCTD) is a regulatory electronic submission standard developed by ICH that is being adopted by HAs not only in the US, EU, Japan, but also in many other countries.
Table of Contents
- Mandatory Use of the Electronic Common Technical Document format
- Why eCTD?
- What to know or do to create a technically-compliant eCTD
- eCTD requirements
- Understanding Lifecycle Management
- Module 1 Backbone
- Technical Validation
- Electronic Submissions Gateways and Portals
Health Authorities (HAs) currently require Sponsors to provide regulatory dossiers in various formats. The International Conference of Harmonization (ICH) brings together the Regulatory Authorities of the European Union (EU), Japan and the United States (US) and experts from the pharmaceutical industry in the three regions to discuss scientific and technical aspects of product registration. The purpose is to make recommendations on ways to achieve greater harmonization in the interpretation and application of technical guidelines and requirements for product registration in order to reduce or obviate the need to duplicate the testing carried out during the research and development of new medicines.
The ICH Common Technical Document (CTD) provides a common format for marketing authorization submissions in all ICH markets, and use of this format is now mandatory. The Electronic Common Technical Document (eCTD) is a regulatory electronic submission standard developed by ICH that is being adopted by HAs not only in the US, EU, Japan, but also in many other countries. The eCTD builds on the ICH CTD harmonization and standardizes the structure, format and content of ICH CTD submissions electronically. Benefits to HAs and Sponsors include reduction in document storage, ease of navigation, document re-use without resubmission of data, and clarity around document status.
HAs in the ICH regions have invested significant time and effort, and indicated their commitment to implementation of eCTD. In addition, HAs in the ICH regions, as well as other markets, are moving toward a fully electronic submission environment, and many are initiating other electronic submission initiatives to support this move (eg, HA Electronic Submission Gateways, HA Electronic Application Forms, and mutually recognized technical validations).
Mandatory Use of the Electronic Common Technical Document format
Agencies are mandating eCTD for more and more submission types. Soon, only the eCTD format will be accepted throughout the marketing authorisation of drugs. Each region and local authority has determined the rate in which they will implement eCTD, and each has chosen the timing associated with accepting specific regulatory activities in the eCTD format. Please refer to the ICH website or local authority websites for additional information relative to submission types and timing.
In addition to the fact that eCTD is becoming mandatory for most regulatory submission types, there are many benefits associated with implementing the format for both sponsors and the HAs. Providing submissions in eCTD format facilitates a global submission strategy that both reduces the timelines associated with the production and distribution of regulatory submissions, and potentially time to market for sponsors across markets.
Providing a submission in eCTD format facilitates processing and review for the Agencies. Most Agencies are implementing gateways and portals as a means of receiving eCTD submissions. This secure electronic transfer of the dossier means that a submission can be received by the reviewer within minutes of completion, drastically reducing processing and review times. It also reduces the time and costs associated with managing and storing paper, printing or scanning documents. The XML backbone allows agencies to automatically upload the sequence into their systems and validate the sequences for technical completeness. Changes and updates to dossiers are easier for the reviewer to identify. Bookmarks and hyperlinks facilitate quick referencing of information. Since all files are submitted electronically there is no need for agencies to scan documents or industry to print, transport and store masses of paper.
What to know or do to create a technically-compliant eCTD
When submitting in eCTD format, it is important to prepare yourself for the differences between creating a submission in paper or electronic format and producing a technically compliant eCTD submission. Our advice would be that users:
- Understand the relationship between authoring/creating “Submission Ready” documents that meet ICH eCTD Specifications and a “technically compliant” eCTD submission. For example:
- Use of MS Word templates
- Use standard fonts (eg, Times New Roman)
- Use MS Word heading styles to enable automatic creation of Bookmarks on Rendering or to create document Tables of Contents (TOCs)
- Document TOCs required for documents 8 pages or more
- PDF Version of documents must be 1.5
- Bookmarking and Hyperlinking requirements
- Read and understand the ICH eCTD Specifications and how they relate to your documents and submissions
- What is a submission vs. sequence?
- What is lifecycle management (ie, each Letter of Authorization is NOT a new submission, but rather a new sequence)
- Why can’t I just delete a sequence or a document?
- What is metadata?
- What metadata is associated with the product?
- What metadata is associated with the document?
- What is a study tagging file or node and why do I need them?
- What metadata is needed to create specific folders in M2-M5?
- Is what I create a product or a substance?
- ICH granularity and file name requirements ([Comprehensive Table of Contents (Headings & Hierarchy)]
- Documents that were previously a single large document may now become several smaller documents.
- Where each document maps into the eCTD structure.
Understanding what is required up front will save you time and unnecessary delays during the publishing or validation process and can help you avoid rejections of the submission by the Agency.
Please refer to the current eCTD Specifications for additional detail.
The CTD content requirements do not change when transitioning to eCTD. However, there are additional requirements when submitting in eCTD format.
- Module 1 is unique for each Region. Please refer to the ICH website and/or local authority websites for Module 1 specific information.
- The following figure illustrates the Canadian eCTD file/folder structure.
- The root directory, or Top Level Folder as called in this example, will contain all the sequences for a specific application. The name of the Top Level Folder must reflect the unique Dossier Identifier number (eg, e123456) obtained from the Agency for a specific product or Master File (eg, DMF number, IND/NDA/MAA number), and this number stays consistent throughout the dossier lifecycle.
- The sequence number folder will include the regional M1 folder, as well as the globally consistent M2 through M5 folders. In addition, it will contain the required eCTD technical files/folders: the util folder, the eCTD backbone file (index.xml), and the eCTD calculated checksum file (index-md5.txt).
- The M1 folder contains all regionally specific files (refer to regional guidance).
- The structure of Modules 2 through 5 (M2-M5) are defined in the ICH eCTD Specification document.
- The util folder contains the technical auxiliary files for an eCTD, the so-called DTD & Stylesheets. The DTD folder deposits the structure for Module 1 and Module 2-5 (as required from the different regions and the ICH).
- The Stylesheets are technically used to display xml files and make them readable within a browser.
- The xml backbone is used as a navigation file which actually represents a Table of Content of the submission. As an eCTD is somehow divided between M1, the regional section, and M2-M5, the ICH section, there are two xml backbones provided: the regional backbone (in the above example, ca-regional.xml) located in Module 1 to navigate through the regional specific content, and a separate xml backbone file (index.xml) for easy navigation through M2-M5.
- The first regulatory activity for an eCTD dossier will start with either Sequence 0000 (EU and Canada) or Sequence 0001 (US). Sequences are numbered using 4 digits, and subsequent sequences are numbered using the next consecutive number (0002, 0003, etc.).
- Each new regulatory activity (an amendment, Annual Report, Letter of Authorization submission, etc.) for that dossier will be a new sequence, using the next consecutive 4-digit sequence number.
- Usually, if a sequence has been technically rejected by an Authority, the sequence number would remain the same as the rejected sequence and resubmitted; rejections for content are almost always resolved by the submission of a new sequence using the next sequential number.
Understanding Lifecycle Management
Each file in an eCTD sequence is given an attribute. There are four attributes: New, Append (which most Agencies prefer is NOT used), Replace, or Delete, and they define how the document in the sequence relates to all previous sequences in the eCTD.
For example, a cover letter, which is almost always “New,” describes the content of the submission to the Agency. If a change to a document previously submitted to the Agency was being made in the current sequence, the attribute would be “Replace.” If the change was intended to remove an obsolete document, the attribute would be “Delete.”
Module 1 Backbone
Each region has very specific envelope information requirements. Please refer to local guidance for additional information.
The following is a basic description of some envelope information:
The envelope information can be extracted out of the XX-regional.xml. The regional backbone as already mentioned, is not only used for easy navigation but is used also for extracting the submissions key data information as well as defined metadata at a glance.
An overview of some envelope information is provided below:
The <applicant> Element
This mandatory element contains the sponsor’s name, i.e. the company which is submitting this regulatory transaction. Great care should be taken to ensure accuracy and consistency with this content. For example, the values “My Company” or “My Company, Inc.” or “My Company, Inc” are all different which may cause difficulties or delays in the processing of the regulatory transaction.
The <product-name> Element
This mandatory element contains the drug name, i.e. the product which is being addressed in this application. Great care should be taken to ensure accuracy and consistency with this content. For example, the values “My Product” or “My product” or “My Product” (note the double space!) are all different which may cause difficulties or delays in the processing of the regulatory transaction.
The <dossier-identifier> Element
This mandatory element contains the unique identifier assigned by the Agency. It is expected that the sponsor will acquire a valid dossier identifier from the Agency in which the eCTD will be provided before submitting the initial regulatory transaction.
The <dossier-type> Element
This mandatory element contains the type of dossier, i.e. from a simplistic perspective, whether it is a pharmaceutical or biologic regulatory activity. The content of this element is taken from a list of values defined by the local Agency.
The <regulatory-activity-type> Element
This mandatory element contains the type of the regulatory activity, i.e. from a simplistic perspective, what regulatory purpose this filing is addressing. The content of this element is taken from a list of values defined by the local Authority.
The <sequence-description> Element
This mandatory element describes the sequence (regulatory transaction) based upon a series of possibilities.
The <related-sequence-number> Element
This optional element contains the four-digit sequence number of the first sequence in this regulatory activity. The schema ensures that the content is in the format “9999”, i.e. four digits.
The xml structure of Module 1
The xml file of Module 1 contains two categories of elements:
- Heading elements which act as an electronic Table of Contents to organize the documents submitted in Module 1. However, there are additional heading elements called node-extensions which can be created at pre-defined sections within an eCTD structure in order to group documents.
- Leaf elements which describe one document along with additional information such as the defined metadata or the document related lifecycle information (new, replaced, delete, append). Each document is linked and can be retrieved easily.
Documents should be placed at the lowest level of the eCTD tree. In most cases, documents are not permitted directly under a heading element if the heading element contains sub-headings.
It should be mentioned that there will be a difference between the physical folder structure within an eCTD and the xml structure/headings shown in the xml backbone. The software usually provides the respective headings shown as folders within the application. After the sequence has been published, the heading structure will be shown in the xml backbone, whereas the physical folder structure will not represent the same folder hierarchy and might only contain files. This output complies to ICH and Regional specifications.
Once an eCTD has been published, it should be “validated” using a software that will check an eCTD submission for technical compliance to ICH and Agency specifications. This step should not be skipped, as any technical invalidity would lead to a rejection. Make sure your eCTD submission complies to the technical requirements specified by the respective regional authority.
It is recommended that High/Medium or Pass/Fail errors be corrected before submission. Also, re-validate the sequence after correcting any errors. A valid test result must be present before sending the sequence to the Agency.
Electronic Submissions Gateways and Portals
Agencies have begun implementing Electronic Submission Gateways and Portals in an effort to streamline the electronic submission process and facilitate a secure and easy transfer of information (eCTD sequences) from a Sponsor to an Agency. Future standards will also encompass 2-way communications between the Agencies and Sponsors using their electronic submission gateways.
EMA utilizes the EMA eSubmission Gateway for CP submissions; US FDA utilizes the US FDA ESG for all eCTD submissions; Health Canada utilizes the FDA ESG as their Common Electronic Submission Gateway (CESG), and EU utilizes the Common European Submission Platform (CESP) to name a few.