«INTERNATIONAL CONFERENCE ON HARMONISATION OF TECHNICAL REQUIREMENTS FOR REGISTRATION OF PHARMACEUTICALS FOR HUMAN USE ICH M2 EWG Electronic Common ...»
ICH eCTD Specification V 3.2.2 16-July-2008
INTERNATIONAL CONFERENCE ON HARMONISATION OF
TECHNICAL REQUIREMENTS FOR REGISTRATION OF
PHARMACEUTICALS FOR HUMAN USE
ICH M2 EWG
Electronic Common Technical Document Specification
This specification has been developed by the ICH M2 Expert Working
Group and maintained by the eCTD Implementation Working Group in accordance with the ICH Process as pertains to the M2 EWG and eCTD change control as it pertains to the eCTD IWG.
ICH eCTD Specification V 3.2.2 16-July-2008 Document Change History Version Date Description Number Version 3.0 October 2003 Initial Step 4 Document Version 3.1 November 2003 Incorporated approved change requests 00020, 00030, 00090, 00110, 00190, 00200, 00240, 00260, 00290, 00310, 00380, 00400, 00420, 00450, 00480, 00500, 00510, 00520, 00530 Version 3.2 February 2004 Editorial Corrections and Changes to Align with the M4 Organisation Document : Granularity Annex Version 3.2.1 June 2008 Incorporated approved change requests 0120, 0130, 0140, 0210, 0270, 0300, 0390, 0560, 0590, 0600, 0620, 0640, 0670, 0700, 0710, 0720, 0730, 0750, 0760, 0770, 0780, 0810, 0820, 0940, 0960, 1030, 1080, 01170, 1250, 1280, 1310, 1320, 1360, 1370, 1400, 1450, 1580, 1660, 1680.
Incorporated eCTD Q&As 1-3, 5-7, 9and 41-47. Provided clarity on Operation Attribute use. Converted all instances of ‘leafs’ to ‘leaf elements’.
Removed numbering not defined by
ICH eCTD Specification
Appendix 1: Overall Architecture
Guiding Design Principles
Modular Structure of the eCTD
XML Based eCTD
Multiple Region Support
Life Cycle Management
Appendix 2: The eCTD Submission
The eCTD Submission
XML eCTD Instance
Regional Use of Other Formats
Element to File Directory Mapping
Appendix 3: General Considerations for the CTD Modules
Folder and File Naming Conventions
Screenshots and Folder Hierarchy
Module 1 Administrative Information and Prescribing Information
Module 2 Summaries
Module 3 Quality
Module 4 Nonclinical Study Reports
Module 5 Clinical Study Reports
Appendix 4: File Organization for the eCTD
Appendix 5: Region Specific Information Including Transmission and Receipt
Region Specific Information: Module 1
ICH eCTD Specification V 3.2.1 16-July-2008 Transport
Appendix 6: The eCTD XML Submission
File Names and Directory Structure
Life Cycle Management
DTD Content Model
eCTD Element/Attribute Instructions
Example 6-1: Instructions for a Simple New Submission
Example 6-2: Instructions for an Amendment, Supplement, or Variation
Example 6-3: Instructions for Multiple Indications
Example 6-4: Instructions for Multiple Drug Substances, Manufacturers, and Products...... 6-13 Example 6-5: Instructions for Extending XML eCTD DTD Elements
Example 6-6: Instructions for Submitting Sections as Paper
Appendix 7: Specification for Submission Formats
Definition of Subset
Notes on Embedding Japanese Fonts:
Use of Color Fonts
Page Size and Margins
Headers and Footers
Source of Electronic Document
Methods for Creating PDF Documents and Images
Hypertext Linking and Bookmarks
Document Information Fields
Open Dialog Box
Indexing PDF Documents
Use of Acrobat Plug-Ins
Appendix 8: XML eCTD DTD
ICH eCTD Specification V 3.2.2 16-July-2008 ICH eCTD Specification Introduction The ICH M4 Expert Working Group (EWG) has defined the Common Technical Document (CTD). The ICH M2 EWG has defined, in the current document, the specification for the Electronic Common Technical Document (eCTD). The eCTD is defined as an interface for industry to agency transfer of regulatory information while at the same time taking into consideration the facilitation of the creation, review, life cycle management and archiving of the electronic submission. The eCTD specification lists the criteria that will make an electronic submission technically valid. The focus of the specification is to provide the ability to transfer the registration application electronically from industry to a regulatory authority. Industry to industry and agency to agency transfer is not addressed.
Background The specification for the eCTD is based upon content defined within the CTD issued by the ICH M4 EWG.
The CTD describes the organization of modules, sections and documents. The structure and level of detail specified in the CTD have been used as the basis for defining the eCTD structure and content but, where appropriate, additional details have been developed within the eCTD specification.
The philosophy of the eCTD is to use open standards. Open standards, including proprietary standards which through their widespread use can be considered de facto standards, are deemed to be appropriate in general.
Scope The CTD as defined by the M4 EWG does not cover the full submission that is to be made in a region. It describes only modules 2 to 5, which are common across all regions. The CTD does not describe the content of module 1, the Regional Administrative Information and Prescribing Information, nor does it describe documents that can be submitted as amendments or variations to the initial application.
The value of producing a specification for the creation of an electronic submission based only upon the modules described in the CTD would be limited. Therefore, the M2 EWG has produced a specification for the eCTD that is applicable to all modules of initial registration applications and for other submissions of information throughout the life cycle of the product, such as variations and amendments.
This document describes the parts of the registration application that are common to all regions and some of the life cycle requirements for products. The parts of the registration application that are specific to a region will be covered by regional guidance. However, this backbone has been developed to handle both the regional and common parts of submissions.
The specification is designed to support high-level functional requirements such as the following:
• Copy and paste
• Viewing and printing of documents
• Annotation of documentation
• Facilitate the exporting of information to databases
• Searching within and across applications
• Navigation throughout the eCTD and its subsequent amendments/variations Change Control The specification for the eCTD is likely to change with time. Factors that could affect the content of the
specification include, but are not limited to:
• Change in the content of the CTD, either through the amendment of information, at the same level of detail, or by provision of more detailed definition of content and structure
• Change to the regional requirements for applications that are outside the scope of the CTD
• Updating standards that are already in use within the eCTD
• Identification of new standards that provide additional value for the creation and/or usage of the eCTD
• Identification of new functional requirements
• Experience of use of the eCTD by all parties Details of the change control management are described in an external ICH document.
Page 2 Appendix 1: Overall Architecture Guiding Design Principles This appendix defines the basic principles that drove the design and architecture of the eCTD. Detailed specifications are defined in appendices 2 and 6.
The business process to be supported can be described as follow:
The business process defines specific requirements for the message. The eCTD Specification currently provides only a transport mechanism for one-way traffic from applicant to agency.
The primary focus of the eCTD is to provide a data interchange message between industry and agencies.
Industry initiates the process by creating the initial submission in terms of an electronic CTD. Throughout the life cycle of this process, additional information will be submitted to update or modify the information contained in the initial submission (e.g., supplement, amendment, variation.) The agency can submit acknowledgements, queries and requests to industry. These are considered simple messages using electronic mail or other transport formats. The overall architecture of the eCTD is designed to provide a commonly agreed upon submission and submission structure that imposes minimal restriction to the industry and agencies.
Modular Structure of the eCTD The structure of the electronic submission in terms of organization and navigation should be consistent with the modular structure of the Common Technical Document. The goal of this design principle is to standardize the electronic format of the common parts of the eCTD.
XML Based eCTD The XML eCTD DTD (Document Type Definition) defines the overall structure of the submission. The purpose of the XML backbone is two-fold: (1) to manage meta-data for the entire submission and each document within the submission and (2) to constitute a comprehensive table of contents and provide corresponding navigation aids. Meta-data on submission level include information about submitting and receiving organization, manufacturer, publisher, ID and kind of the submission, and related data items.
Examples for meta-data on document level are versioning information, language, descriptive information such as document names and checksums. Details are defined in appendix 6.
The XML instance of any submission should be created and validated according to the XML eCTD DTD as defined in appendix 8.
The XML eCTD DTD describes the hierarchical structure according to the CTD as defined by the ICH M4 Expert Working Group. It includes multiple hierarchical levels depending on the specific module as defined in the CTD. The actual submission can include more hierarchical levels below those defined in the CTD. The XML eCTD instance covers the entire submission including all hierarchical levels and includes references to each individual file.
The submission should include a Stylesheet that supports presentation of the XML instance, navigation according to the table of contents, and provides access to all documents within the submission. A standard Stylesheet for viewing the eCTD submission is defined and provided by the ICH M2 EWG. Presentation and navigation via other Stylesheets on the receiving side should be possible. Consult regional authorities on the acceptability of submitting non-ICH stylesheets.
Page 1-1 Multiple Region Support The scope of each submission is global according to the Common Technical Document, meaning that modules 2 through 5 of a submission are intended for all regions with the exception of selected documents (e.g., in the quality module), which have a regional scope. Module 1 of a submission is regional in nature.
The DTD as defined by the ICH M2 expert working group specifies the structure of the common parts of the eCTD primarily focusing on module 2 through 5. It enables linking to regional XML index files for module 1 which will be defined by the authorities in each region. Due to the significant differences in documentation requirements across regions it is not expected that a single, global eCTD submission could be constructed and transmitted to multiple regions with each regional authority ignoring or deleting other regions' submission material.
Life Cycle Management The applicant creates a submission that is stored in a local repository. The applicant submits the initial submission to the agency, which imports the submission into another local repository. The nature and kind of the local repositories is not within the scope of the eCTD. The initial submission should be selfcontained, meaning that it includes all documents and no references to other submissions. Regional guidance should be consulted if references to other submissions are needed.
Following the initial submission, the applicant can submit incremental updates such as amendments and variations. Updates can refer to documents in the previous submissions. Updates should be designed in a way that they can be loaded into the repository by fully preserving the initial or previous submission via version control. The XML backbone should include meta-data identifying the update and providing navigation aids to filter for different submission types.
It is preferred that when a Common Technical Document is submitted electronically, the entire submission be in electronic form with the exception of certain regional forms that currently require written signatures.
See appendix 5 for regional requirements. See appendix 6 for a description of how to submit a CTD containing both paper and electronic components.
Page 1-2Appendix 2: The eCTD Submission
Introduction This appendix specifies the Information Technology aspect of the eCTD submission. Informally, the eCTD submission is a directory structure with files including the XML eCTD instance, reports, data and other submission information. The eCTD submission supports multilingual and multi-region aspects.
The eCTD Submission