International Conference On Harmonisation Of Technical Requirements For Registration Of Pharmaceuticals For Human Use

TL;DR: The official goal of the ICH is to harmonize inconsistent technical regulatory standards across different regions and countries in order to avoid costly, wasteful, and duplicative testing in pharmaceutical development.

Abstract: The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) is a combined industry and government organization. It is centrally involved in constructing and setting international technical standards for the testing, development, and monitoring of pharmaceuticals, especially in the fields of drug quality, safety, and efficacy. There are two types of memberships: full membership with voting rights; and membership that permits only 'observer' status without voting rights. The ICH Steering Committee (SC) was established in 1990 and determines the policies and procedures for ICH, selects the topics for harmonization and monitors the progress of harmonization initiatives. The core financial support for ICH is, and has been, provided by the international pharmaceutical industry trade associations. The official goal of the ICH is to harmonize inconsistent technical regulatory standards across different regions and countries in order to avoid costly, wasteful, and duplicative testing in pharmaceutical development. Keywords: drug regulatory authorities; ICH; ICH Steering Committee (SC); international pharmaceutical industry

Summary

Introduction

• The file formats included in this section are those formats that are commonly used in electronic submissions.
• Other formats can be used according to guidance published in each region.

Background

• There are many factors that have influenced the design of the eCTD.
• The submissions should be able to accommodate regional requirements that are represented in regional guidance documents, regulations, and statutes.
• The technology should be extensible so that as technology changes, the new electronic solutions can be accommodated.
• The backbone is based on an XML Document Type Definition (DTD).
• This should be done with caution since it can be more difficult for the regulatory authority to manage the life cycle of that file if there is more than one pointer to the file.

Scope

• It 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 production of 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 lifecycle 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 lifecycle requirements for products.
• The backbone has been developed to handle both the regional and common parts of submissions.

Process

• The eCTD Specification Change Control Board (CCB) is authorized by the ICH Steering Committee to make changes to the eCTD Specification to keep pace with advancing technology.
• The agreed changes to the specification will be published for public comment in each region.
• Comments are collected and considered by the CCB and will be adopted in modified or unmodified form or rejected.
• Regulatory authorities will support submissions described by at least two consecutive versions of the eCTD Specification.
• The CCB will establish its meeting schedule at the first meeting of the CCB.

Procedure

• Change requests received at least 30 days before a scheduled CCB meeting will be placed on the agenda for that ICH eCTD Specification V 2.0 February 12, 2002 Page 8 meeting.
• A detailed description of any testing or research that was done to support the solution(s) being proposed.
• Advice on backward compatibility issues, if any.
• The CCB will maintain a public list of requests and the status of each request.
• New change requests will be posted to the list within 30 days of their receipt.

Approach to Documentation and Use of the eCTD Specification

• The approach to the management of the specification for the eCTD is to divide the documentation into a series of independent but related appendices.
• This will facilitate the maintenance of the specification, as it will not require that all documentation be updated even for a small change to one part of the specification.
• Thus being able to more readily support the currency of the specification as a whole.

Business Model

• The business process defines specific requirements for the message.
• Throughout the lifecycle of this process, additional information will be submitted to update or modify the information contained in the initial submission e.g. supplement, amendment, variation etc.
• The agency can submit acknowledgements, queries and requests to the industry.
• These are considered simple messages utilizing 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.
• Meta-data on submission level includes information about submitting and receiving organization, manufacturer, publisher, ID and kind of the submission, and related data items.
• It includes multiple hierarchical levels depending on the specific module as 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 style sheet that supports presentation of the XML instance, navigation according to the table of contents and provides access to all documents within the submission.

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.
• The DTD as defined by the ICH M2 expert working group specifies the structure of the common parts of the eCTD primarily focusing in module 2 through 5.

Lifecycle Management

• The eCTD is capable of containing initial submissions, supplements, amendments and variations.
• There are no uniform definitions for these terms in the three regions, but amendments and supplements are terms used in the United States.
• The variations, supplements and amendments are used to provide additional information to an original regulatory dossier.
• Each regional DTD should be referenced in the eCTD DTD by the submitter.
• When revisions are sent to a regulatory authority, the new file should be submitted as a leaf element associated with the same tag name as the file being amended or deleted.

The eCTD Submission

• An eCTD Submission is a collection of data objects that follows the eCTD Specification.
• The main function of the eCTD Submission is data exchange.
• The biggest benefits are expected when the eCTD Submission is loaded into an information system that supports the review process.
• In the web environment, the eCTD Submission should be usable without processing in at least in the following ways: Standalone: Viewable with a web browser.
• The eCTD Submission is composed of the following: Directory Structure XML eCTD instance Content files.

Directory Structure

• There should be a reasonable maximum number of entries (directories and files) per directory.
• The directory structure should follow the rules below.
• The name of the files and directories are identifiers.
• The file names are not intended to convey meta-data, though some meaning in the names helps; i.e., no random names.
• Any directory names and file names that are added to the eCTD submission by the applicant should be descriptive and logical.

XML eCTD Instance

• The instance is in the submission sequence number directory .
• The submission sequence number directory should contain at least two files and one or more directories.
• The intention is to have links from the instance to leaf files in the eCTD submission as opposed to creating a single XML document that contains the entire eCTD submission.
• The instance also contains meta-data at the leaf level.
• The ICH web site includes an eCTD Template that is an empty directory structure with a recommended style sheet.

Logical Documents and Files

• In general, the XML eCTD DTD maps explicitly to the CTD table of contents, but there are exceptions where the XML eCTD DTD maps to the level of use designated by the appropriate ICH CTD Implementation Working Group (IWG) instead.
• In the event the physical file exceeds the recommended maximum file size due to graphics, data content, scanned images, or other large format content, additional files may make up the logical document.
• Furthermore, if the logical document consists of multiple file formats, then more than one physical file would be needed.
• An example of such a case would be PDF and XML data that together represent the logical document.

Formats

• This process could be very long; e.g. 50 years.
• This points to neutral formats: formal standard, industrial standard, vendor independent, text-like.
• The list of agreed formats will be updated as technology evolves and new requirements arise.
• XML will be the preferred format for all types of data.

Common Formats

• The common formats that can be included in an eCTD Submission are: Narrative: Portable Document Format (PDF) Structured: Extensible Markup Language (XML) Graphic:.
• When appropriate or when PDF is not possible, use Joint Photographic Experts Group (JPEG), Portable Network Graphics (PNG), Scalable Vector Graphics (SVG) and Graphics Interchange Format (GIF).
• Special formats for very high resolutions may be appropriate on a case-by-case basis.

Regional Use of Other Formats

• Regulatory authorities and applicants could agree to use other formats regionally; i.e., Page 2-3 non-common formats or uses of the common formats in a different way from above.
• The intention of the use of other formats is for transition.
• There are two classes of transitions: Legacy Transition: from the past to the present; i.e., old formats to present formats.
• From the present to the future; i.e., from present formats to new formats, also known as Future Transition.
• The new formats would normally be candidates for common formats.

Links

• Links among objects in the eCTD Submission should be relative.
• The intention is to make the eCTD submission self-contained.
• All literature references introduced by the applicant should be included in the submission, for secondary references (references to a reference), absolute links to external objects can be used.
• Different formats allow for the use of different linking technology.

Presentation

• The linking between style sheet (that could be in a separate file) and a data file should be relative.
• One file could have several style sheets; the one used depends on the media.
• There could be one presentation for the screen and another for paper.

Checksums

• The eCTD Submission should contain checksums for each individual file including a checksum file for the eCTD XML instance.
• Initially, the MD5 Message-Digest Algorithm (MD5) should be used for this purpose.
• Including a checksum for each individual file provides a number of benefits including: Element to file directory mapping Follow these rules: Add the corresponding extension to the file.

File extension

• All files should have one and only one file extension.
• The file extension should be used to indicate the format of the file.
• The mapping between formats and extensions are: IANA nomenclature text/css css text/html html or htm text/xml xml application/pdf pdf application/rtf rtf application/vnd.ms-excel xls image/jpeg jpg image/png png image/gif gif Non IANA nomenclature DTD dtd XPT (SAS) xpt XSL xsl The eCTD Submission could use formats not registered with the Internet Assigned Numbers Authority (IANA).
• For formats absent from this list, widely used mapping between the formats and the extensions should be used.
• If a mechanism (e.g., standard) becomes available that associate the formats with file extension, it should be considered for this specification, also known as Future direction.

Name

• The notation "U+" refers to the Unicode [UNICODE] notation.
• Incorrect file names (with the extension):: a part.pdf (' ' ; SPACE is not allowed) hello (missing extension) hello:xml (':' ; COLON is not allowed).
• Only lower case letters should be used in all file and directory names.
• “data/module_1/introduction.html” is the path; “introduction.html” is a File Name.
• Document Name is the first Name in the File Name.

Folder and File Naming Conventions

• This could be used in most cases, however applicants may modify this specification where appropriate.
• To include an additional folder for information where an appropriate folder name is not available in the eCTD specification.
• The file extension should be used to indicate the format of the file.
• The following table gives an example how files could be named.
• Reference should be made to regional guidances.

Submission Addresses

• Submissions should be sent directly to the appropriate regulatory authority.
• Information needed to send physical media to each regulatory authority is found at the reference location in Table 5-2.
• Media Regulatory authorities are prepared to accept electronic submissions provided on the media listed in Table 5-3.
• To optimize processing efficiency, the authors recommend choosing media with a capacity most appropriate to the size of the submission.
• Whenever possible, applicants should choose media capable of holding the submission on the fewest number of units.

Cover letter

• Applicants should provide a cover letter as a PDF file (cover.pdf).
• A paper cover letter should also be included with non-electronic portions of the submission (such as forms with signatures or seals, and certifications).
• A description of the electronic submission including type and number of electronic media, approximate size of the submission, and, if appropriate, format used for DLT tapes.
• A statement that the submission is virus free with a description of the software used to check the files for viruses.
• The regulatory and information technology points of contact for the submission.

Preparing the media

• CD-ROMs should be packaged carefully to ensure that they arrive in a usable condition.
• Particularly vulnerable are diskettes and CD-ROM jewel cases shipped in envelopes without bubble-type protective material or stiff backing.
• The use of a jiffy-type bag by itself to ship media will not provide adequate protection for shipping electronic media.

Transport

• Secure data exchange over the Internet is the recommended means for transporting submissions.
• Until the regulatory authorities can develop secure electronic gateways, submissions should continue to be physically transported by courier or registered mail.

Security

• No security settings or password protection for PDF files should be included.
• Security fields should be set to allow printing, changes to the document, selecting text and graphics, and adding or changing notes and form fields.

Receipt

• Upon arrival at the regulatory authority, the submission is archived according to local regulations.
• A read-only copy of the submission is then made available to the review community in the regulatory authority.

File Names and Directory Structure

• Recipients of the eCTD should be able to directly navigate through the submission at the folder and file level, i.e. without benefit of a customized end user application.
• The structure of the eCTD and instructions for how to create folder names facilitate this type of navigation.
• The original submission and subsequent amendments and variations should use the same top-level folder name.
• The DTD for the regional xml backbone file should be in the util folder for each submission.

Operation Attribute

• The applicant uses the operation attribute to tell the regulatory authority how the applicant intends the files in the submission to be used.
• Table 6- 2 describes the meaning of each allowed value of the operation attribute.
• These examples are not a complete list of all possible situations.
• - Submission 0001, which is submitted at a later time, is the submission of the file structure.pdf, which is now current and replaces the file structure.pdf in submission 0000.

DTD Content Model

• The content model of the eCTD is derived from the organization of the Common Technical Document.
• Page 6-8 Page 6-9 eCTD Element/Attribute Instructions.
• One or more child leaf elements can be submitted for a parent table of contents tag.
• ID Unique identifier for this location in the XML instance.
• The file submitter’s internal version number or version identification for the report.

Instructions for a Simple New Submission

• The following XML fragment demonstrates the submission of a clinical overview of efficacy as a single PDF document.
• This submission includes the file “efficacy-overview.pdf” in the relative directory “module-2/clinical-summary” (i.e. the one starting below the Dossier number and submission sequence directories).
• The regional review application should treat this as a new submission to be associated with the submission identified in CTD module 1, which is region specific.

Instructions for Multiple Indications7

• Multiple therapeutic indications use an additional attribute associated with the <m2-7-3summary-of-clinical-efficacy> and the <m5-3-5-reports-of-efficacy-and-safety-studies> elements to allow multiple indications to be submitted.
• The following table shows the use of these attributes.
• DOCTYPE ectd:ectd SYSTEM "util/dtd/ich-ectd-1-0.dtd"> <ectd:ectd xmlns:ectd = "http://www.ich.org/ectd" <title>nausea efficacy summary</title> </leaf> </m2-7-3-summary-of-clinical-efficacy>.
• </m2-7-clinical-summary> </m2-common-technical-document-summaries> <m5-clinical-study-reports> <m5-3-clinical-study-reports> <m5-3-5-reports-of-efficacy-and-safety-studies indication = "pain"> <leaf operation = "new" xlink:type = "simple" xlink:href = "module-5/clinical-study-reports/efficacy-safety-pain/pain-sr1.pdf">.

Instructions for Multiple Drug Substances, Manufacturers and Products

• Multiple drug substances use additional attributes associated with the <m3-2-s-drugsubstance> element to allow unique combinations of the drug substance name and manufacturer to be submitted.
• The following table shows the use of these attributes.
• This is an example of the a section of the instance showing the submission of information about two drug substances, one of which is supplied by two manufacturers: <m3-2-body-of-data> <m3-2-s-drug-substance substance = "acetaminophen" manufacturer = "my supplier"> <leaf operation = "new" xlink:type = "simple" xlink:href = "module-3/body-of-data/drug-substance/acetaminophen-my-supplier/acetaminophen.pdf">.
• You should follow the following principles when using <node-extension>: 1. You should only extend the lowest level of defined elements.
• This makes it possible for the regulatory authority to locate the original file and update its status.

Instructions for Submitting Sections as Paper

• During the transition to fully electronic submissions of the CTD, some sections can be submitted as paper only.
• These sections should be identified in the XML eCTD instance by including a PDF file in the instance that describes the content and location of the paper section.
• The PDF file might consist of only one page with the name of the CTD document and the physical volume number and tab identifier.

Version

• Agencies should be able to read all PDF files with version 4.0 or higher of the Acrobat Reader.
• Agencies should not need any additional software to read and navigate the PDF files.
• Review can be facilitated through use of Adobe Acrobat since significantly more functionality is available in this product than with Acrobat Reader.

Fonts

• PDF viewing software automatically substitutes a font to display text if the font used to create the text is unavailable on the reviewer’s computer.
• Therefore, all additional fonts used in the PDF files should be embedded to ensure that those fonts would always be available to the reviewer.
• One problem associated with embedding fonts is that embedding requires additional computer storage space.
• Times New Roman, 12-point font, the font used for this document is adequate in size for reading narrative text and should be used whenever possible.
• When choosing a point size for tables, a balance should be made between providing sufficient information on a single page that may facilitate data comparisons for the reviewer while still achieving a point size that remains legible.

Use of Color fonts

• Blue font can be used for hypertext links.
• If a font color other than black is used, light colors that do not print well on grayscale printers should be avoided.
• Color reproduction can be tested prior to submission by printing sample pages from the document using a gray scale printer.
• The use of background shadowing should be avoided.

Page Orientation

• Pages should be properly oriented so that all portrait pages are presented in portrait and all landscape pages are presented in landscape.
• To achieve this, the page orientation of landscape pages should be set to landscape prior to saving the PDF document in final form.

Page Size and Margins

• A sufficient margin (at least 2.5cm) on the left side of each page should be provided in order to avoid obscuring information if the reviewer subsequently prints and binds the pages for temporary use.
• For pages in landscape orientation (typically tables and publications) smaller margins are allowable (at least 2.0cm at the top and 0.8cm left and right) so as to allow more information, displayed legibly, on the page (see Section 3, Fonts).
• It is acceptable that header and footer information appears within these margins but not so close to the page edge that it may risk being lost upon printing.

Source of Electronic Document

• PDF documents produced by scanning paper documents are usually inferior to those produced from an electronic source document.
• Scanned documents are more difficult to read and do not allow reviewers to search or copy and paste text for editing.

Methods for Creating PDF Documents and Images

• The method used for creating PDF documents should produce the best replication of a paper document.
• When creating PDF files containing images, the images should not be downsampled.
• Paper documents containing hand-written notes should be scanned at 300 dpi.
• If black and white photos are submitted, 8-bit grayscale images should be considered.

Hypertext Linking and Bookmarks

• Hypertext links and bookmarks are techniques used to improve navigation through PDF documents.
• Hypertext links can be designated by rectangles using thin lines or by blue text.
• These bookmarks are essential for the efficient navigation through documents.
• Relative paths should be used when creating hypertext links to minimize the loss of hyperlink functionality when folders are moved between disk drives.
• When creating bookmarks and hyperlinks, the magnification setting Inherit Zoom should be used so that the destination page displays at the same magnification level that the reviewer is using for the rest of the document.

Page Numbering

• Only page numbers for individual documents are needed.
• It is easier to navigate through an electronic document if the page numbers for the document and the PDF file are the same.
• Two exceptions to this rule can occur, details of which can be found in the guidance for the modules of the CTD.
• Firstly, where a document is split because of its size (e.g. >50MB), under which circumstances the second or subsequent file should be numbered consecutively to that of the first or preceding file.
• Document Information Fields Document information fields should not be used for the common portions of the eCTD, but they may be appropriate for some of the regional documents.

Open Dialog Box

• The open dialog box sets the document view when the file is opened.
• The initial view of the PDF files should be set as Bookmarks and Page.
• If there are no bookmarks, the initial view as Page only should be set.
• The Magnification and Page Layout should be set as default.

Indexing PDF Documents

• Full text indices can be used to help find specific documents and/or search for text within documents.
• When a document or group of documents is indexed, all words and numbers in the file and all information stored in the Document Information fields are stored in special index files that are functionally accessible using the search tools available in Acrobat.
• Portions of a document that are imaged are not indexed.
• These full text indices should not be confused with a table of contents.
• Indices should not require extensions or additions to off-the-shelf Acrobat programs.

XML Files

• A working group at the World Wide Web Consortium (W3C) developed XML.
• The element type identifies the piece of information.
• By using a hierarchical structure, XML allows you to relate two or more elements.
• This could be represented in the XML file as <applicant XML:LANG=“EN”> Worldwide Pharmaceuticals Inc.</applicant>.
• The specific names of the element types and attributes as well as the valid syntax, structure and format for defining the XML elements are included in a file called document type declaration (DTD).

SVG Files

• SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text.
• Text can be in any XML namespace suitable to the appplication, which enhances searchability and accessibility of the SVG graphics.

Internet

• The world-wide network of computers for accessing, sending, sharing, and transferring information between sites at different locations.
• It is uncontrolled and unadministered, and when you connect to the Internet, you actually become a part of it.

Leaf

• The eCTD DTD XML element that describes the content to be provided.
• The leaf consists of a file and the meta-data associated with that file.

Network

• A communication system which connects different computers and enables them to share peripherals such as printers, disk drives and databases.
• Users can access applications and databases connected by the network.

Figures

Table 3-1

Table 3-3

Table 6-4

Table 6-1

Figure 6-1

Figure 3-3 Screenshot of the folder structure of module 4

Table 6-11

Table 5-3

Table 5-2

Figure 3-4 Screenshot of the folder structure of module 5

Figure 3-2 Screenshot of the folder structure of module 3

Table 6-7

Table 6-9

Figure 7-1

Table 6-5

Table 6-6

Table 3-2

Figure 3-1 Screenshot of the folder structure of module 2

Table 6-10

Table 6-3 Understanding the Operation Attribute

Full text

ICH eCTD Specification V 2.0 February 12, 2002
Page 1
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 in accordance with the ICH Process as pertains to the M2 EWG.

ICH eCTD Specification V 2.0 February 12, 2002
Page 2
ICH eCTD Specification..................................................................................................... 5
Introduction ..................................................................................................................... 5
Background......................................................................................................................5
Scope ............................................................................................................................... 5
Requirements................................................................................................................... 6
Change Control................................................................................................................ 6
Introduction .................................................................................................................. 6
Process.......................................................................................................................... 7
Procedure...................................................................................................................... 7
Approach to Documentation and Use of the eCTD Specification................................... 8
Appendix 1 Overall Architecture..................................................................................... 1-1
Guiding Design Principles............................................................................................ 1-1
Business Model............................................................................................................. 1-1
Modular Structure of the eCTD.................................................................................... 1-1
XML Based eCTD........................................................................................................ 1-1
Multiple Region Support .............................................................................................. 1-2
Lifecycle Management ................................................................................................. 1-2
Appendix 2 The eCTD Submission ................................................................................. 2-1
Introduction .................................................................................................................. 2-1
The eCTD Submission.................................................................................................. 2-1
Directory Structure....................................................................................................2-1
XML eCTD Instance.................................................................................................2-1
eCTD Template ............................................................................................................2-2
Logical Documents and Files ....................................................................................... 2-2
Formats .........................................................................................................................2-2
Common Formats ......................................................................................................... 2-2
Regional Use of Other Formats.................................................................................... 2-2
Links ............................................................................................................................. 2-3
Presentation .................................................................................................................. 2-3
Checksums.................................................................................................................... 2-3
Element to file directory mapping................................................................................ 2-3
File extension................................................................................................................ 2-4
Name............................................................................................................................. 2-4
References .................................................................................................................... 2-5
Appendix 3 General Considerations for the CTD Modules............................................. 3-1
Introduction .................................................................................................................. 3-1
Folder and File Naming Conventions........................................................................... 3-1
Screenshots and folder hierarchy.................................................................................. 3-2
Module 1 Administrative Information and Prescribing Information............................ 3-3
Module 2 Summaries....................................................................................................3-3
Module 3 Quality.......................................................................................................... 3-3
Module 4 Nonclinical Study Reports ........................................................................... 3-5
Module 5 Clinical Study Reports .................................................................................3-9
Appendix 4 File Organization for the eCTD ................................................................... 4-1
Appendix 5 Region Specific Information Including Transmission and Receipt ............. 5-1

ICH eCTD Specification V 2.0 February 12, 2002
Page 3
Introduction .................................................................................................................. 5-1
Region specific information: Module 1........................................................................ 5-1
Region .......................................................................................................................5-1
Submission Addresses .................................................................................................. 5-2
Media............................................................................................................................ 5-2
Media and format ...................................................................................................... 5-2
Cover letter ................................................................................................................... 5-2
Preparing the media...................................................................................................... 5-3
Transport.......................................................................................................................5-3
Security......................................................................................................................... 5-3
Receipt.......................................................................................................................... 5-4
Acknowledgment.......................................................................................................... 5-4
Appendix 6 The eCTD XML Submission ....................................................................... 6-1
Background................................................................................................................... 6-1
File Names and Directory Structure ............................................................................. 6-1
Lifecycle Management ................................................................................................. 6-3
Operation Attribute....................................................................................................... 6-3
DTD Content Model.....................................................................................................6-6
eCTD Element/Attribute Instructions........................................................................... 6-9
Instructions for a Simple New Submission ................................................................ 6-11
Instructions for an Amendment, Supplement or Variation......................................... 6-12
Instructions for Multiple Indications .......................................................................... 6-12
Instructions for Multiple Drug Substances, Manufacturers and Products.................. 6-13
Instructions for extending XML eCTD DTD elements.............................................. 6-14
Instructions for Submitting Sections as Paper............................................................ 6-15
Appendix 7 Specification for Submission Formats ......................................................... 7-1
Introduction .................................................................................................................. 7-1
PDF............................................................................................................................... 7-1
Version ...................................................................................................................... 7-1
Fonts.......................................................................................................................... 7-1
Use of Color fonts ..................................................................................................... 7-2
Page Orientation........................................................................................................ 7-2
Page Size and Margins .............................................................................................. 7-2
Source of Electronic Document ................................................................................ 7-3
Methods for Creating PDF Documents and Images..................................................7-3
Hypertext Linking and Bookmarks........................................................................... 7-4
Page Numbering........................................................................................................ 7-4
Document Information Fields ................................................................................... 7-5
Open Dialog Box....................................................................................................... 7-5
Security...................................................................................................................... 7-5
Indexing PDF Documents ......................................................................................... 7-5
Use of Acrobat Plug-Ins............................................................................................7-5
XML Files..................................................................................................................... 7-6
SVG Files ..................................................................................................................... 7-6
Appendix 8 XML eCTD DTD.........................................................................................8-1
Appendix 9 Glossary...................................................................................................... 9-16

ICH eCTD Specification V 2.0 February 12, 2002
Page 4
Logical Document................................................................................................... 9-17

ICH eCTD Specification V 2.0 February 12, 2002
Page 5
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, lifecycle
management and archival 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.
The specification is divided into a series of main sections followed by a number of
appendices in which detailed technical specifications are given. It will provide a
mechanism whereby parts of the specification will be updated or adjusted to agreed new
technologies or standards on an independent basis without the necessity of updating it all.
This aspect will be covered in the chapter Change Control.
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 has 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 utilize open standards. Open standards, including
proprietary standards, which through their widespread usage 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.
It 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 production of 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
lifecycle 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 lifecycle requirements for products. The parts of the registration

Frequently asked questions

Q1. What contributions have the authors mentioned in the paper "International conference on harmonisation of technical requirements for registration of pharmaceuticals for human use" ?

The ICH M4 Expert Working Group ( EWG ) has defined the Common Technical Document ( CTD ) this paper, which is an interface for industry to Agency transfer of regulatory information while at the same time taking into consideration the facilitation of the creation, review, lifecycle management and archival of the electronic submission. 

Q2. Why is SVG a language for describing two-dimensional graphics in XML?

Because of its compatibility and leveraging of other Web standards, features like scripting can be done on SVG elements and other XML elements from different namespaces simultaneously within the same Web page. 

Q3. What is the way to compress PDF images?

For PDF images, one of the following lossless compression techniques should be used: • For lossless compression of color and grayscale images, use Zip/Flate (one techniquewith two names). 

Q4. What should be set to allow printing, changes to the document, and adding or changing notes and?

Security fields should be set to allow printing, changes to the document, selecting text and graphics, and adding or changing notes and form fields. 

Q5. What is the magnification setting for hypertext links?

When creating bookmarks and hyperlinks, the magnification setting Inherit Zoom should be used so that the destination page displays at the same magnification level that the reviewer is using for the rest of the document. 

Q6. How long before a CCB meeting will the change request be placed on the agenda?

Change requests received at least 30 days before a scheduled CCB meeting will be placed on the agenda for thatICH eCTD Specification V 2.0 February 12, 2002Page 8meeting. 

Q7. What is the way to protect a CD-ROM?

Particularly vulnerable are diskettes and CD-ROM jewel cases shipped in envelopes without bubble-type protective material or stiff backing. 

Q8. How should the page orientation be set to landscape?

Pages should be properly oriented so that all portrait pages are presented in portrait and all landscape pages are presented in landscape.