EU Module 1 Specification

Version 1.4.1

November 2011
Document Control

Change Record
Version Date Author(s) Comments
0.1 July, 2001 Stan van Belkum Draft
0.2 September, 2001 Stan van Belkum Draft
0.3 October, 2001 Stan van Belkum Draft
0.4 November, 2001 Stan van Belkum Draft
0.5 February, 2002 Stan van Belkum Draft
0.6 February, 2002 Stan van Belkum Draft
0.7 March, 2002 Stan van Belkum Draft
0.8 October, 2002 Stan van Belkum Draft
0.9 November, 2002 Stan van Belkum Draft
0.91 February, 2003 Stan van Belkum Draft
0.92 July, 2003 Stan van Belkum Draft
0.93 February 2004 M. Bley Draft
0.95.1 May 2004 EMEA Draft
0.95.2 28 May 2004 EMEA Draft
0.95.3 23 June 2004 EMEA Draft
1.0 July 2004 EMEA Final
1.1 December 2005 EMEA Integration of PIM
1.2 May 2006 EMEA Structural changes from CTD
1.2.1 October 2006 EMEA Alignment to CTD and Change Requests
1.3 May 2008 EMEA Incorporation of paediatric requirements and Change
Requests
1.4 August 2009 EMEA Alignment to the New Variation Regulation and
Change Requests
1.4.1 November 2011 EMA Incorporation of Additional Change Requests and
Q&A

Reviewers
Version Name Organisation
0.1-0.3 EU Regulators EU Regulatory Authorities, EMEA
0.4 Interested parties
0.5-0.6 EU Regulators EU Regulatory Authorities, EMEA
0.7-0.8 Interested parties
0.9 EU regulators EU Regulatory Authorities, EMEA
0.91 EU Regulators ICH, EMEA EU Regulatory Authorities, EMEA
0.92 EU regulators EU Regulatory Authorities (members TIGes and NtA)
0.95.1 EU Regulators, interested parties EU Regulatory Authorities (members TIGes and NtA), EFPIA,
Pharma, other interested parties

0.95.2 EU Regulators, interested parties EU Regulatory Authorities (members TIGes and NtA), EFPIA,
Pharma, other interested parties
0.95.3 EU Regulators, interested parties EU Regulatory Authorities (members TIGes and NtA), EFPIA,
Pharma, other interested parties
1.1
1.2
1.2.1
1.3 EU Regulators, interested parties EU Regulatory Authorities (members TIGes and NtA), EFPIA,
Pharma, other interested parties
1.4 EU Regulators, interested parties EU Regulatory Authorities (members TIGes and NtA), EFPIA,
EGA, other interested parties
1.4.1 EU Regulators, interested parties EU Regulatory Authorities (members TIGes and NtA), EFPIA,
EGA, other interested parties

2
Distribution
Version Name Organisation
0.4 http://esubmission.eudra.org
0.7 http://esubmission.eudra.org
0.8 http://esubmission.eudra.org
0.91
0.92 http://esubmission.eudra.org
0.95.1 http://esubmission.eudra.org
0.95.2 http://esubmission.eudra.org
0.95.3 http://esubmission.eudra.org
1.0 http://pharmacos.eudra.org/F2/eudralex/vol-2/home.htm
1.1
1.2
1.2.1 http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm
1.3 http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm
1.4 http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm
1.4.1 http://ec.europa.eu/health/documents/eudralex/vol-2/index_en.htm

3
 TABLE OF CONTENT

DOCUMENT CONTROL......................................................................................................................... 2
CHANGE RECORD ................................................................................................................................................ 2
REVIEWERS ......................................................................................................................................................... 2
DISTRIBUTION ..................................................................................................................................................... 3
GLOSSARY OF TERMS ........................................................................................................................ 5

INTRODUCTION..................................................................................................................................... 6

EU MODULE 1: REGIONAL INFORMATION........................................................................................ 6

REGIONAL FILE FORMATS.................................................................................................................. 6

MODULE 1 ........................................................................................................................................................... 6
MODULES 2 TO 5 ................................................................................................................................................. 7
USE OF ELECTRONIC SIGNATURES.................................................................................................. 7

HANDLING OF EMPTY OR MISSING ECTD SECTIONS..................................................................... 8

UPDATING BACKBONE ATTRIBUTES/METADATA .......................................................................... 8

GENERAL ARCHITECTURE OF MODULE 1 ....................................................................................... 8

ENVELOPE ........................................................................................................................................................... 9
M-1-EU ................................................................................................................................................................ 9
DIRECTORY / FILE STRUCTURE.......................................................................................................................... 10
NODE EXTENSIONS ............................................................................................................................................ 10
FILE NAMING CONVENTION .............................................................................................................................. 11
FOLDER AND FILE NAME PATH LENGTH ........................................................................................................... 11
BUSINESS PROTOCOL ...................................................................................................................... 11

CHANGE CONTROL............................................................................................................................ 12

APPENDIX 1: THE EU MODULE 1 XML SUBMISSION ..................................................................... 13

APPENDIX 1.1: ENVELOPE ELEMENT DESCRIPTION....................................................................................... 13
APPENDIX 1.2: COUNTRY-SPECIFIC ELEMENTS ............................................................................................. 22
APPENDIX 1.3: PRODUCT INFORMATION ELEMENT DESCRIPTION ................................................................ 22
APPENDIX 2: DIRECTORY / FILE STRUCTURE FOR MODULE 1................................................... 23
APPENDIX 2.1: DESTINATION CODES .............................................................................................................. 41
APPENDIX 2.2: LANGUAGE CODES .................................................................................................................. 42
APPENDIX 2.3: SMPC, LABELLING AND PACKAGE LEAFLET FILE NAME IDENTIFIERS ............................... 42
APPENDIX 2.4: AGENCY CODES AND NAMES .................................................................................................. 43
APPENDIX 3: MODULARISED DTD FOR EU MODULE 1................................................................. 45
EU-REGIONAL.DTD ............................................................................................................................................. 45
EU-ENVELOPE.MOD ............................................................................................................................................ 49
EU-LEAF.MOD .................................................................................................................................................... 50

4
Glossary of Terms

Term Definition
Applicant A pharmaceutical company or its agent that is submitting information in
support of an application.
Applicant’s Information Regulatory information submitted by an applicant for, or to maintain, a
marketing authorisation that falls within the scope of this guidance
document.
eCTD Application A collection of electronic documents compiled by a pharmaceutical
company or its agent in compliance with European legislation and
guidelines in order to seek a marketing authorisation or any
amendments thereof. An eCTD application may comprise a number of
sequences. In the EU an eCTD application may comprise several
dosage forms and strengths, all under one invented product name.
This is understood to be equivalent to a Global Marketing Authorisation
according to Art. 6 para 2 Dir. 2001/83/EC as amended. Some review
tools describe such a collection as a dossier.
Procedure A Community registration procedure for the authorisation of medicinal
products in the European Community. There a 4 types of procedure
that operate within the EC – Centralised, Decentralised, Mutual
Recognition and National.
Regulatory Activity A collection of sequences covering the start to the end of a specific
business process, e.g. an initial MA application or Type II variation. It is
a concept used in some review tools to group together several business
related sequences.
Submission or Sequence A single set of information and / or electronic documents supplied at
one particular time by the applicant as a part of, or the complete, eCTD
Application. In the context of eCTD, this is equivalent to a sequence.

5
Introduction
This document specifies Module 1 of the electronic Common Technical Document (eCTD) for the
European Union (“EU”).

This document should be read together with the ICH eCTD Specification to prepare a valid eCTD
submission in the EU. The latest version of the ICH eCTD Specification can be found at:
http://estri.ich.org/eCTD.

EU Module 1: Regional Information

The ICH Common Technical Document (“CTD”) specifies that Module 1 should contain region-specific
administrative and product information. The content and numbering of Module 1 for the EU is
specified in the latest version of the Notice to Applicants that can be found at:
http://ec.europa.eu/health/documents/eudralex/vol-2/index_en.htm

The following items listed in the Notice to Applicants should be included for an initial submission:
– a cover letter,
– a comprehensive table of contents 1 ,
– an application form,
– product information documents,
– information on the experts,
– specific requirements for different types of applications (if required),
– an environmental risk assessment,
– information relating to orphan market exclusivity (if required),
– information relating to pharmacovigilance,
– information relating to clinical trials (if required),
– information relating to paediatrics.

In addition, other items such as answers to regulatory questions, rationale for variations and renewal
documentation could also be included in Module 1.

It should be noted, that for subsequent submissions in the lifecycle of a medicinal product, e.g. for a
variation, not all of the above mentioned types of document need be included in Module 1. Consult
the various legal documents for guidance on the exact documents to be submitted in such a case,
e.g. Regulation (EC) No 1084/2003 and Regulation (EC) No 1085/2003 for Type IA, Type IB and
Type II variations.

This document describes only the region-specific information that is common to all submissions in the
different Member States. However, at the same time the EU Module 1 Specification allows for
country-specific information to be included in Module 1, if required. Country-specific information could
relate to the details of the business process applied (e.g. specifying the number and names of those
parts for which a paper copy is still requested) and local preferences for file formats.

Note that the acronym ‘EMEA’ will continue to be used when referring to the European Medicines
Agency in various technical text herein, e.g. envelope, until such time there is a major revision to this
specification.

Regional File Formats

Module 1
The file formats that can be included in Module 1 are given in Table 1. In addition to the common
format PDF, as defined by the ICH eCTD Specification Document, XML and image formats are also
accepted on an ad hoc basis. Note that all PDF files included in an eCTD (irrespective of the module)
1
TOC not required for eCTD as the XML backbone acts as a table of contents

6
should be v1.4 or v1.7 (see ICH Q&A for further detail re pdf version acceptability), except where
there is an agency-specific requirement for a later version (e.g. for an application form).
Although the use of the file formats defined in Table 1 is strongly recommended, regulatory authorities
and applicants could agree on the use of other formats in Module 1. For example, proprietary format
MS Word is requested by some agencies for Product Information documents in Section 1.3. These
documents, if requested, should not be referenced in the eCTD backbone, and should normally be
provided in addition to the PDF versions (Note: Tracked change Product Information provided in Word
format is not required to be provided in PDF format within the eCTD). Guidance should be referred to
regarding the provision of MS Word and other requested documents (e.g. the TIGes harmonised
eCTD guidance).

Table 1 Acceptable file formats for Module 1

Document File Format Remark
Cover letter XML*, PDF PDF preferably generated from electronic source.
Administrative forms: Documents should be generated from electronic source
 Application form and its documents, any signature may be embedded as a
annexes XML*, PDF graphic file in the PDF text if desired, although this is not
always necessary as the hard paper copy, if required by
 Variation application form the receiving agency, contains the legally binding
incl. background for the XML*, PDF signature.
variation
 Renewal form and its
annexes XML*, PDF

Product Information: If a higher resolution is necessary for the mock-ups, use

JPEG, GIF, PNG or SVG on a case-by-case basis.
 Product information text** PDF

 Packaging mock-ups PDF

 Reference to specimens PDF

Other PDF PDF preferably generated from electronic source.

* = In line with the general principles of the ICH eCTD Specification, it is intended that XML will
eventually become the sole submission format for administrative forms and product information
documents (as they contain structured data and a long-term goal of this development is the
normalisation of data in Module 1). Note that as XML documents become available for practical
implementation (including documents other than the above), they will be introduced into Module 1 and
the current file formats may ultimately be replaced (after an appropriate transition period).

** = SmPC, Package Leaflet and labelling

Modules 2 to 5
No additional file formats are defined for Modules 2 to 5 other than those mentioned in the ICH eCTD
Specification Document. In line with the statement on regional use of other formats in the ICH eCTD
Specification Document, individual Member States and pharmaceutical companies could agree on a
case-by-case basis to use formats other than the common formats. However, the use of formats other
than those specified by the ICH eCTD Specification Document is discouraged.

Use of Electronic Signatures

The use of advanced electronic signatures (digital signatures) will be crucial in achieving pure
electronic communication between the pharmaceutical industry and regulatory agencies, particularly
for authentication of electronic submissions and documents contained therein. The EU is therefore
developing a long-term strategy to implement digital signatures. Currently however, the use of digital
signatures for electronic submissions within the EU is not fully supported and digital signatures should
therefore not be used. Please refer to the TIGes Harmonised eCTD Guidance for information on the
use of electronic signatures.

7
Handling of Empty or Missing eCTD Sections
For new applications (including generic applications), detailed statements justifying the absence of
data or specific CTD sections should be provided in the relevant Quality Overall Summary and/or
Non-Clinical/Clinical Overviews (Module 2.3, 2.4, 2.5). Note that placeholder documents highlighting
'no relevant content' should not be placed in the eCTD structure, as these would create a document
lifecycle for non-existent documents, and unnecessary complication and maintenance of the eCTD.

For a generic application, there is no need to provide a justification for content that is typically absent.

The EU Module 1 is provided with a standard style-sheet that can be used to view the content. Note
that the style-sheet has been designed to display the complete Module 1 table of contents (i.e. all the
sections), irrespective of whether files are actually present in those sections or not.

Updating backbone attributes/metadata

It is not possible to update XML backbone attributes such as ‘manufacturer’ during the eCTD lifecycle,
nor is it necessary to attempt workarounds such as deleting existing documents and resubmitting
them with new attributes. The recommendation is to retain the obsolete entry and to rely on the
document content to explain the current details. The sole exception to this rule is the EU envelope
“submission type” attribute, which can be updated to support a mid-lifecycle change in submission
type from one variation type to another (under the variation regulation). As the submission type is
likely to change in any case with each submission (e.g. from ‘initial-maa’ to ‘supplemental information’
etc), this particular significant change in submission type should be further signalled using the free-
text “submission description” envelope element.

Whilst the need for a change to the set of EU Module 1 XML attributes/metadata (this covers country,
language and product information type) in the middle of the procedure is deemed to be very rare, it is
recommended to contact the agency whether such change could be done during the procedure, along
with other changes, or as part of an eCTD “reformat” submission.

General Architecture of Module 1

The EU Module 1 architecture is similar to that of Modules 2 to 5 of the eCTD, comprising a directory
structure and a backbone with leaves. The backbone must be a valid XML document according to the
EU Regional Document Type Definition (DTD). The backbone instance (the “eu-regional.xml” file)
contains meta-data for the leaves, including pointers to the files in the directory structure. In addition,
the EU Regional DTD defines meta-data at the submission level in the form of an envelope. The root
element is “eu-backbone” and contains two elements: “eu-envelope” and “m1-eu”.

The EU Regional DTD is modularised, i.e. the envelope and leaves are referenced from the main part
of the DTD as external entities called respectively "eu-envelope.mod" and "eu-leaf.mod ". The EU
”leaf” is identical to the leaf element described in the ICH eCTD DTD; reference is made to Table 6-8
of the ICH eCTD Specification. A full description of the EU Regional DTD can be found in Appendix 3
of this specification.

Examples of XML coding for a simple new application, supplemental information and a submission for
a National or Mutual Recognition Procedure are provided as an annex to this specification. Examples
of XML coding that support the new variation regulation are provided as well.

Files can be referred to across modules (e.g. from Module 1 to Module 2) or across sequences within
the same eCTD application; note however that it is not possible to refer to files in sequences in other
eCTD applications. When referring to files across modules or across sequences, the reference must
always be relative, starting from the location of the XML file. For instance, a reference from within
Module 1 of Sequence 0003 (e.g. 0003/m1/eu/eu-regional.xml) to a file located in Module 2 of
Sequence 0000 (e.g. file “introduction.pdf” in folder 0000/m2/22-intro), would be encoded in the EU
Module 1 as “../../../0000/m2/22-intro/introduction.pdf”. (This example is not business-specific – it
merely serves to demonstrate the principle).

8
Envelope
The “eu-envelope” element is designed to be used for all types of submissions (initial, variations,
renewals, etc.) for a given medicinal product and will mainly be used for the first simple processing at
the agency level. The envelope provides meta-data at the submission level. A description of each
"envelope" element is provided in Appendix 1 of this specification.

For Centralised Procedure submissions, the “eu-envelope” element should contain a single
“envelope “element with the country attribute value set to ‘emea’. For all other procedures, the
“eu-envelope” element should contain a separate “envelope” element for each Member State
involved in the procedure that is going to receive that particular sequence, and each envelope country
attribute should be set to the country value of the receiving Member State. Note that the value
'common' cannot be used in the envelope.

The envelope element submission ‘mode’ should only be used in variation or line extension regulatory
activities, and the value can be set to: ‘single’, ‘grouping’ or ‘worksharing’. An additional high-level
submission number should also be provided in the envelope under the following circumstances:

 For worksharing submissions

Here, the submission ‘mode’ value will be ‘worksharing’ and the high-level number is a
worksharing number;

 For submissions of grouped Type 1A variations that affect multiple marketing authorisations
Here, the submission ‘mode’ will be ‘grouping’ and the high-level number is group
number/‘periodic report’ number. Please refer to the annex and associated guidance for
further details of this high-level number.

Such a high-level number, if appropriate, should be provided in addition to the usual product-specific
tracking numbers. If the high-level number is required but is not known (e.g. for the first submission of
the procedure), this element should be populated with the value ‘to be advised’. The relevant number
will usually be provided by or obtained from the appropriate tracking system or regulatory agency.

Examples of ‘single’, ‘grouping’ and ‘worksharing’ submissions are provided in the annex to this
specification.

m-1-eu
The “m1-eu” element of the EU regional DTD is based on the same conceptual approach as the
common part of the ICH eCTD DTD. It provides an XML catalogue with meta-data at the leaf level
including pointers to the location of files in a directory structure. As for the ICH eCTD DTD,
the “m1-eu” element maps to the directory structure. (There may at times be what is seen to be an
apparently 'redundant' directory structure, but this is necessary in order to be able to use the same file
/ directory structure for all procedures.) Furthermore, as the same structure will be used during the
lifecycle of the submission, the use of country directories even to place a single file in one submission
is justified because it could be used to house several files in a subsequent submission, and in doing
so the structure would not change. A tabular overview of the directory structure explaining where to
place country and language-specific files is provided in Appendix 2 of this specification.

9
Directory / File Structure
The EU Module 1 Specification provides a directory and file structure that is strongly recommended:
 The same high-level directory structure is used for all 4 procedures (MR, National,
Decentralised and Centralised Procedures). This is possible, despite the fact that files for the
MR, Decentralised and National Procedures are usually country-specific, whereas files for the
Centralised Procedure are usually language-specific.
 Country directories are named according to Appendix 2.1.
 Language directories are named according to Appendix 2.2.
 The recommended directory structure for the use of country and language identifiers is
described in Appendix 2. In general, Modules 1.0, 1.2, 1.3.2, 1.3.3, 1.3.4, 1.3.5, ‘Additional
Data’ and ‘Responses’ have country subdirectories. Module 1.3.1 (Product Information) has
both country and language subdirectories.
o For the Centralised Procedure, the country subdirectory is always named "emea",
irrespective of whether it contains “common” or country folders; language
subdirectories in Module 1.3.1 have the appropriate language identifier.
o For MR, Decentralised and National Procedures:
 Documents for each country are placed in an appropriately named
subdirectory. The folder name "common" should only be used for documents
potentially applicable to all EU countries, irrespective of whether they are
currently involved in the procedure or not.
 In Module 1.3.1, every document should be placed in an appropriately named
language subdirectory, even if the country only has one official language.
Where a country has more than one official language (e.g. Belgium) separate
language subdirectories should be used for each set of documents in a
different language.
 Should a country have documents in more than one language in a Module
other than 1.3.1, then it is recommended to use the VAR (variable) part of the
filename to identify the language of the document.

Node Extensions
Node extensions are a way of providing extra organisational information to the eCTD. The node
extension should be visualised as an extra heading in the CTD structure and should be displayed as
such when the XML backbone is viewed.

However, the use of node extensions should be limited to those areas where it is critical.
Consideration should be given regarding the impact of the view for the reviewer since the inconsistent
use of node extensions can lead to unanticipated effects in the cumulative view of a submission.

The following rules govern the use of node extensions in the EU:
 Node extensions must not be used where ICH-specified sub-headings already exist (e.g.
indication, manufacturer, drug substance, drug product are all-ICH specified node
extensions).
 Node extensions must only be used at the lowest level of the eCTD structure (e.g. a node
extension can be used at the level 5.3.5.1 but must not be used at the level 5.3).
 Node extensions are mainly to be used to group together documents made up of multiple leaf
elements (e.g. a clinical study made up of separate files for the synopsis, main body and
individual appendices could be grouped together under a node extension with the Study
Identifier as its Title attribute).
 Node extensions must be maintained over the entire life of the eCTD lifecycle (e.g. if a node
extension is used in Sequence 0000 to group files for a study report in Module 5.3.5.1, then
any files submitted in a later sequence must also be placed under a node extension, even if
only one file is submitted).
 Node extensions may be nested as this is allowed by the eCTD DTD. However, as noted in
Bullet 2, the first node extension must be at the lowest level in the eCTD structure (e.g. in
Module 5.3.7 a node extension may be added to group together files with the Study Identifier
as Title attribute). Further node extensions may be added as children of the Study Identifier
node, separating CRFs from individual patient listings.

10
  The content associated with a node extension can be placed in a separate sub folder in the
submission; this is recommended for studies in Module 5 where study reports are provided as
multiple files. However, there is no specific requirement for an additional subfolder. For
example, if node extensions are used to further define ‘m1-responses’, additional folders
under ‘m1/eu/responses/cc’ are not recommended as these would then break EU file and
folder naming convention rules (see next section).

File Naming Convention

File names in Module 1 follow one of two conventions.

Country-specific items in sections 1.0; 1.2; 1.3; m1-responses and m1-additional-data have the
general structure CC-FIXED-VAR.EXT, where CC is a country code used in some CTD modules,
FIXED is a defined component of the filename based on the CTD section and VAR is an additional
optional variable component. EXT represents the file extension. Components are separated by a
hyphen (except the dot for the file extension). No spaces should be used within each component but
hyphens can be used in the variable part to separate several words.

Fixed components are highly recommended. The variable component is optional and should be used
as appropriate to further define these files. The variable component, if used, should be a meaningful
concatenation of words with the option of hyphens for separators and should be kept as brief and
descriptive as possible. File extensions in line with this specification should be applied as applicable.

The first component in a file name should be the country code, as per Appendix 2.1, except when the
document is valid for all countries in all procedures, as per Appendix 2. The second component
should be the document type code, as per Appendix 2 and 2.3. The third component if necessary
should be the variable component. In cases where differentiation is needed (e.g. between 1.5mg and
15mg). the word 'point' written in full (i.e. ‘1point5mg’) or a hyphen can be used (i.e.’1-5mg’).

There are no recommendations for variable components in this specification. The format of the file is
indicated by the file extension. File names should always be in lowercase, in line with the ICH eCTD
specification.

Examples:
fr-cover.pdf
be-form.xml
it-form-annex1.pdf
pt-form-proofpayment.pdf
uk-outer-tablet10mg.pdf
emea-combined-tablet1-5mg.pdf
emea-combined-tablet10mgannotated.pdf
nongmo.pdf

Non-country specific items in Sections 1.4; 1.5; 1.6; 1.7; 1.8; 1.9 and 1.10 have fixed file names, as
defined in Appendix 2.

Folder and File Name Path Length

The overall folder and file name path length starting from the sequence number should not exceed
180 characters, for any file in any module. This is an EU regional requirement, and it is acknowledged
that this is less than the ICH agreed overall path length.

Business Protocol
It is clear that the detailed business process between industry and a regulatory agency in the EU
cannot be completely harmonised due to the differences in organisation and processes. The exact
description has to be provided by the individual Member States. However, a few common steps can
be identified, taking into consideration that for some period of time the exchange of regulatory
information will take place through exchange of physical media like CD-Rs:
1. The actual submission of the physical media on which the application is contained should be
accompanied by at least a signed paper copy of the cover letter (where required by the local

11
 agency). The content of this cover letter is defined in the ICH eCTD Specification Document
Appendix 5, as is the packaging of the media units.
2. Most agencies and the EMA are unable to provide positive feedback of technically valid
submissions. However, if there is any problem experienced during the upload of the sequence
agencies will promptly inform the applicants.

A unique identifier of the submission is necessary and there could be different procedures for
agencies to assign such a number. Either the applicant could request it of the relevant agency before
submission, or, after receipt of the first submission, the agency could send it to the applicant (e.g.
through an email connection for all related subsequent submissions). Relevant national guidelines
should be consulted.

Change Control
The EU Module 1 specification 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 Module 1 for 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
 Update of 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, in particular Module 1.

Details of the change control process are described in an external EU document to be found at
http://ec.europa.eu/health/documents/eudralex/vol-2/index_en.htm

For the EU Change Control Process and Electronic Submission Change Request/Q&A Form, use the
following address: http://esubmission.emea.europa.eu/doc/index.html.

12
 Appendix 1: The EU Module 1 XML Submission

The EU Module 1 XML Submission contains an element for each Table of Contents entry of the Notice to Applicants Module 1. The following sections
describe information that is captured within the Module 1 XML submission in an eCTD, but which is not captured within the Notice to Applicants Table of
Contents for Module 1.

Appendix 1.1: Envelope Element Description

The “eu-envelope” element is the root element that defines meta-data of the submission. This element may contain several envelope entries, each related to
a specific country.

Element Attribute Description/Instructions Example Constraint Occurrence

eu-envelope Root element that provides meta-data for the submission. This element may contain N/A Mandatory Unique
several envelopes, which are country specific.
envelope Parent element for the submission meta-data. This element must be country-specific N/A Mandatory Repeatable
or in the case of the Centralised Procedure, ‘emea’.
country The country to which the envelope applies (or ‘emea’). be Mandatory Unique
submission Provides administrative information associated with the submission. N/A Mandatory Unique

13
Element Attribute Description/Instructions Example Constraint Occurrence
type The type of submission material sent to the regulatory agency. The following are the var-type2 Mandatory Unique
valid values:
 initial-maa = Initial Marketing Authorisation Application
 var-type1a = Variation Type IA
 var-type1b = Variation Type IB
 var-type2 = Variation Type II
 var-nat = National variation (e.g. national variation to apply for a pack size
that is already registered within an existing MRP/DCP authorisation)
 extension = Extension
 psur = Periodic Safety Update Report (PSUR)
 renewal = Renewal (yearly or 5-yearly)
 supplemental-info = Supplemental Information (could include, for example,
response to validation issues, response to questions or letter of undertaking)
 fum = Follow-Up Measure (includes post-approval commitments for national
MAs)
 specific-obligation = Specific Obligation
 asmf = Active Substance Master File
 pmf = Plasma Master File
 referral = Referral under Article 29, 30, 31, 35 or 36
 annual-reassessment = Annual Reassessment
 usr = Urgent Safety Restriction
 paed-article-29 = Paediatric submission, Article 29
 paed-article-46 = Paediatric submission, Article 46
 article-58 = Article 58 (to be used for an initial application)
 notification-61-3 = Notification 61(3)
 transfer-ma = Transfer of a marketing authorisation
 corrigendum = Correction to the published annexes (usually shortly after
approval)
 lifting-suspension = Lifting of a suspension
 withdrawal = Withdrawal of a marketing authorisation (during any
assessment use “supplemental-info”)
 reformat = Intended to support the reformatting of an existing submission
dossier from any format to eCTD, i.e. a baseline eCTD submission containing
no content change and which will not be subject to review (see example
below)
N.B. Officially, Roman numerals are used for variations, e.g. Type IA, Type
II – the elements must remain Arabic, however.

14
Element Attribute Description/Instructions Example Constraint Occurrence
mode The high-level handling of the information submitted as part of variation(s) and single Optional Unique
extension applications. The mode should only be used in variation or line extension (note that
regulatory activities and must be included in every sequence of that activity. The this element
following are the valid values: must be
 single = a single regulatory activity (e.g. a Type II variation) populated for
 grouping = a grouped activity (e.g. several variations grouped into a single sequences in
submission, or a periodic report of type IA variations applicable to one or variation and
more marketing authorisations) line
 worksharing = an activity subject to a worksharing agreement (e.g. a Type II extension
variation applicable to more than one marketing authorisation) activities)
This information should be identical with the information provided/ticked in the
application form.
number This is the high-level submission number, either a ‘worksharing’ number, or the high- For worksharing: Optional Unique
level submission number to be used when grouping Type IA variations for multiple EMEA/H/xxxx/WS/001
marketing authorisations
(Note that for submissions affecting multiple MAs, the ‘xxxx’ used in the submission
number is a permanent placeholder, as a single product number cannot be For grouped IAs:
provided). EMEA/H/C/xxxx/IG/xxxx
If the Applicant did not obtain the sequential number from the relevant Authorities in
advance of their application this field should be populated as "xxxx" as well.
tracking Provides administrative information associated with the application. N/A Mandatory Unique

15
 Element Attribute Description/Instructions Example Constraint Occurrence
number This is any number, used by an agency or the applicant to track the submission, in See column left Mandatory Repeatable
any procedure, in relation to a particular product. This could be one or more of the
following:
 an MRP/DCP number (e.g. DE/H/0126/001/MR),
 a national procedure number (e.g. 2131577),
 the EMEA application number (e.g. EMEA/H/C/000123 or
EMEA/H/C/000123/II/14),
 an authorisation or licence number, (e.g. EU/1/00/44/0003 – 0004)
 any other number used by an agency to track a submission, (e.g.
PL01234/0003-0004)
 a number used by the applicant to manage the submission within their
company (e.g. Pharmacompany123)
There must be at least one tracking number identified from the regulators and, in
addition, the applicant can choose to include an internal tracking number.
It is suggested that if the procedure number has not yet been allocated by the
agency then the term ‘to be advised’ should be used. Applicants should consult
national guidance for further information.

In case of worksharing, or grouped type IA variations applying to more than one MA,
a separate eCTD submission must be built for each MA covered by the variation. In
the envelope of each of the eCTD submissions, the high-level submission number
will be the same, but the individual tracking numbers listed here should be specific to
the MA in question, e.g.:
For worksharing:
 EMEA/H/C/000123/WS005/

For grouped type 1A variations across multiple MAs:

 EMEA/H/C/000123/IG003/
Please ensure that these WS/IG numbers are always mentioned in the case of
supplemental information or corrigendum otherwise the Agency might not be able to
process your submission correctly.
applicant The name of the company submitting the eCTD. PharmaCompany Ltd. Mandatory Unique

16
 Element Attribute Description/Instructions Example Constraint Occurrence
agency Parent element for the identification of the receiving agency. N/A Mandatory Unique
code The identification of the receiving agency (see Appendix 2.4). EU-EMEA Mandatory Unique
procedure Defines the procedure in use with the submission N/A Mandatory Unique
type The type of procedure for the submission. The following are the valid values: centralised Mandatory Unique
 centralised = Centralised Procedure
 national = National Procedure
 mutual-recognition = Mutual Recognition Procedure
 decentralised = Decentralised Procedure
invented-name The name of the medicinal product. WonderPill Mandatory Repeatable
inn International Non-proprietary Name, used to identify pharmaceutical substances or Pioglitazone hydrochloride Optional Repeatable
active pharmaceutical ingredients. Each INN is a unique name that is globally
recognized and is public property. A non-proprietary name is also known as a
generic name.
sequence This is the sequence number of the submission – this should start at 0000 for the 0000 Mandatory Unique
initial submission, and then increase incrementally with each subsequent submission
related to the same product e.g. 0000, 0001, 0002, 0003 etc.
related-sequence This is the sequence number of previous submission(s) to which this submission 0001 Optional Repeatable
relates e.g. the responses to questions to a particular variation. see guidance below on use
and the annex
submission- This element is used to provide a free text description of the submission. The list Response to D120 LOQ Mandatory Unique
description below provides additional examples for such a field:
 For an MAA: Original MAA Application for <Product X> / Response to D120
LOQ
 For a Type II variation: Please quote the scope of variation from the Application
Form
 For a Type IB variation: Please quote the scope of variation from the Application
Form
 For an Annual Reassessment submission: 4th AR submission for <Product X>
 Response to validation questions
 Providing supplementary information
 Dxxx translations

17
Example of the use of the Related Sequence

The Related Sequence number is used to identify sequences belonging to the same ‘regulatory activity’. A 'regulatory activity' is a logical unit of submission
activity (e.g., a Type II Variation) with a defined start and end point (e.g. initial submission to final approval). In the eCTD world, this will consist of all the
sequences that together make up the lifecycle of that particular 'regulatory activity’.

The related sequence attribute should always be left blank for new applications or new regulatory activities (e.g. variations, PSURs). When submitting
lifecycle sequences within an existing activity, the related sequence attribute should be populated with the sequence number of the first sequence in the
activity, regardless of how many sequences make up the activity. The related sequence attribute should be considered independent of any modified file
attributes in a submission. For example, if a sequence 0010 modifies files (leaves) in sequence 0008 and 0009, the entry for related sequence in sequence
0010 should be the sequence number that started the regulatory activity that 0010 falls within, which will not necessarily be sequence 0008 or 0009. See
below for some illustrative examples.

It is generally expected that there is usually just one Related Sequence, but there are occasions where more than one Related Sequence should be provided:
e.g. there are two FUMs (sequence 0050 and sequence 0060) and a single response (sequence 0070) is produced that relates to both FUMs. If more than
one different category of activities are referred to (as related sequence), then the “highest category” should be used in the envelope attributes, and if any of
the related variations were grouped, then ‘grouping’ should be used.

Special attention should be paid to the correct use of the Related Sequence element when the regulatory activity is a variation that covers more than one
Marketing Authorisation. An example is given in the Annex.

Sequence Submission description Related sequence Comment

0000 Original MAA application <none>
This is a continuation of the regulatory activity initiated in 0000 and so
0001 Day 121 Responses to questions on the original application 0000
the related sequence points to the beginning of that activity
Day 181 Responses to further questions on the original This is a continuation of the regulatory activity initiated in 0000 and so
0002 0000
application the related sequence points to the beginning of that activity
Letter of Undertaking (submission type: supplemental This is a continuation of the regulatory activity initiated in 0000 and so
0003 0000
information) the related sequence points to the beginning of that activity
This is the beginning of a new regulatory activity and so no related
0004 Type II variation for ‘Treatment of Pain’ indication <none>
sequence is included
Type II variation for a change in manufacturing site This is the beginning of a new regulatory activity and so no related
0005 <none>
(Westferry) sequence is included
Responses to questions on Type II variation for ‘Treatment This is a continuation of the regulatory activity initiated in 0004 and so
0006 0004
of Pain’ indication the related sequence points to the beginning of that activity
0007 Responses to questions on Type II variation for change in 0005 This is a continuation of the regulatory activity initiated in 0005 and so

18
Sequence Submission description Related sequence Comment
manufacturing site (Westferry) the related sequence points to the beginning of that activity
Extension to introduce a new dosage form (iv solution) that
This is the beginning of a new regulatory activity and so no related
0008 amends information provided in the original application and <none>
sequence is included
the manufacturing change variation
Updated, agreed, product information taking into account This is the completion of the new indication (‘Treatment of Pain’)
0009 0004
new indication (‘Treatment of Pain’) activity
00010 Updated, agreed product information for the iv formulation 0008 This is the completion of the new dosage form (iv solution) activity

For a new Regulatory Activity, the appropriate submission type should be used. Applicants should refer to the submission type descriptions in the EU Module
1 specification. For the sequence that initiates a Regulatory Activity ‘supplemental-info’ and ‘corrigendum’ should not be used. These should only be used for
subsequent sequences within that Regulatory Activity.

The submission type ‘supplemental-info’ should be routinely used for all subsequent sequences until the conclusion of the Regulatory Activity. The
submission type ‘corrigendum’ should only be used in exceptional circumstances to correct information, typically for product information, after the Regulatory
Activity has concluded.

Tables 1, 2 and 3 provide examples of this convention.

Table 1: Example of an initial MAA in the Centralised Procedure

Sequence Submission Description Submission Type Related Sequence
number
0000 Initial MAA initial-maa none
0001 Validation update supplemental-info 0000
0002 Day 121 responses supplemental-info 0000
0003 Day 181 responses supplemental-info 0000
0004 Day 210 Agreed English product supplemental-info 0000
information
0005 Day 215 – translated product supplemental-info 0000
information
0006 Final translations of product supplemental-info 0000
information for Decision
0007 Correction of errors in Danish product corrigendum 0000
information after Decision

19
Table 2: Example of an initial MAA in the Decentralised Procedure
Sequence Submission Description Submission Type Related Sequence
number
0000 Initial MAA initial-maa none
0001 Validation update supplemental-info 0000
0002 Day 106 responses supplemental-info 0000
0003 Day 180 responses supplemental-info 0000
0004 Day 210 Agreed English product supplemental-info 0000
information

Table 3: Example of a Variation

Sequence Submission Description Submission Type Related Sequence
number
0008 Variation for new indication of COPD var-type2 none
0009 Validation update supplemental-info 0008
0010 Responses to questions supplemental-info 0008

Table 4 provides details of which submission types should never have a related sequence and which should always have a related sequence

Table 4: List of Submission Types and the Use of Related Sequence

Submission Type Should Never Have A Should Always Have A
Related Sequence Related Sequence
initial-maa Yes
var-type1a Yes
var-type1b Yes
var-type2 Yes
var-nat Yes
extension Yes
psur Yes
renewal Yes
supplemental-info Yes
fum Yes
specific-obligation Yes
asmf Yes

20
 Submission Type Should Never Have A Should Always Have A
Related Sequence Related Sequence
pmf Yes
referral Yes
annual-reassessment Yes
usr Yes
paed-article-29 Yes
paed-article-46 Yes
article-58 Yes
notification-61-3 Yes
transfer-ma Yes
corrigendum Yes
lifting-suspension Yes
withdrawal Yes
reformat Yes

Example of the use of the submission type ‘reformat’

The submission type ‘reformat’ should be used in each case. (Note: the submission type ‘supplemental-info’ should not be used for the second reformat
submission.) Related sequence should not be used.
An example is given below.
Sequence Submission Description Submission Type Related Sequence
number
0000 Baseline of Modules 4 & 5 reformat None
0001 Variation for new indication of COPD var-type2 None
0002 Baseline of Module 3 reformat None
0003 Extension for 8mg tablet extension None

21
Appendix 1.2: Country-Specific Elements
A number of the elements that represent NtA Module 1 TOC headings possess the child element “specific”, which allows country-specificity of content to be
explicitly indicated.

Element Attribute Description/Instructions Example Constraint Occurrence

specific Parent element for identifying the receiving country for a document or N/A Mandatory Repeatable
documents.
country The receiving country for the document(s) (or “common”) (see Appendix 2.1 uk Mandatory Unique
for full list of allowable values)

Module 1 elements that have “specific” child elements can therefore contain multiple documents, each with content for review by a different country. These
elements are listed below:
 m1-0-cover (1.0 Cover Letter)
 m1-2-form (1.2 Application Form)
 m1-3-2-mockup (1.3.2 Mock-Up)
 m1-3-3-specimen (1.3.3 Specimen)
 m1-3-4-consultation (1.3.4 Consultation with Target Patient Groups)
 m1-3-5-approved (1.3.5 Product Information Already Approved in the Member States)
 m1-responses (Responses to Questions)
 m1-additional-data (Additional Data)

Appendix 1.3: Product Information Element Description

The “m1-3-1-spc-label-pl” corresponds to the Notice to Applicants heading 1.3.1 SmPC, Labelling and Package Leaflet. This element can have multiple
child “pi-doc” elements that allow identification of product information language, document type and applicable country as described below.

Element Attribute Description/Instructions Example Constraint Occurrence

pi-doc Parent element for identification of the type, language and country of one or N/A Mandatory Repeatable
more product information documents.
xml:lang The language that the product information is written in (see Appendix 2.2 for fr Mandatory Unique
allowable values).
type The type of product information document (see Appendix 2.3 for allowable combined Mandatory Unique
values).

22
 country The receiving country for the product information (or “common”) (see be Mandatory Unique
Appendix 2.1 for full list of allowable values)

Appendix 2: Directory / File Structure for Module 1

The directory / file structure is defined in this appendix as a table containing the following information:

Sequential Each item in the table has a unique sequentially assigned reference number. These reference numbers can
number change with each version of this appendix.
Number CTD section number
Title CTD title
Element Element name in the EU Backbone
File/Directory File/Directory name from m1/eu – should be relative path from eu/m1 e.g. 12-form/fr-form.pdf. This is consistent
with ICH standards. The file extension corresponds to the file type; i.e. the “pdf” extension is only illustrative.
Comment Comments

Where the following conventions are used:

Codes* Definition
CC Country Code, also referred to as the destination code as per Appendix 2.1
LL Local Language code as per Appendix 2.2
EXT File extension.
PIDOC Product Information Document identifier as per Appendix 2.3
VAR Variable component of the filename.
DDDD A sequence number made of 4 digits (e.g. 0000)

* = The names of the actual files and directories used should be presented in lower case in accordance with the eCTD specification. The use of upper case
for codes is for illustrative purposes only to show differentiation between the variable parts and the fixed part of the name.

23
1 Number
Title Module 1 EU
Element m1-eu
Directory m1/eu
Comment Top level directory for the EU Module 1as per ICH eCTD Specification
2 Number
Title
Element
File m1/eu/eu-regional.xml
Comment The EU Regional XML instance including the envelope information. Note that the operation attribute for the eu.regional.xml should
always be set to ‘new’.
3 Number 1.0
Title Cover Letter
Element m1-0-cover
Directory m1/eu/10-cover
Comment
4 Number
Title
Element
Directory m1/eu/10-cover/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.

24
5 Number
Title
Element
File m1/eu/10-cover/CC/CC-cover-VAR.EXT
Comment Filename for the Cover Letter composed of a fixed component “CC”, a fixed component “cover” and an optional variable component if
required (e.g. fr-cover-variationrationale.pdf). When only the cover letter is submitted in this directory the file name should be CC-
cover.pdf.
Note that the tracking table required with MPR/DCP submissions should be located within a 'common' directory, with the filename
'common-cover-tracking.pdf' or 'common-cover-tracking.xml’.
Single document correspondences e.g. Letter of Undertakings should be placed here.
6 Number 1.2
Title Application Form
Element m1-2-form
Directory m1/eu/12-form
Comment The Application Form refers to any form (new applications, applications for variations or renewals).
7 Number
Title
Element
Directory m1/eu/12-form/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.
8 Number
Title
Element
File m1/eu/12-form/CC/CC-form-VAR.EXT

25
 Comment Filename for the Application Form composed of a fixed component “CC”, a fixed component “form” and an optional variable component
to be used if required (e.g. fr-form-annex01.pdf, fr-form-proofpayment.pdf). When only the application form is submitted in this directory
the file name should be CC -form.pdf. Annexes that potentially apply to all EU countries should be placed in the ‘common’ sub-directory
(e.g. common-form-annex12.pdf, common-form-pheurcertificate.pdf). The variable component, if used, should be a logical name and
should be added without spaces
Supportive documents, which are not part of any M2-5 section or Response to Questions, should be placed here.
Any updates to documents originating from M2-5 should replace the outdated version in its original location in M2-5. Supportive
documents submitted as answers to questions should be placed in Module 1 Responses to Questions (see line 66-68).
9 Number 1.3
Title Product Information
Element m1-3-pi
Directory m1/eu/13-pi
Comment General placeholder for Product Information
10 Number 1.3.1
Title SmPC, Labelling and Package Leaflet
Element m1-3-1-spc-label-pl
Directory m1/eu/13-pi/131-spclabelpl
Comment General placeholder for SmPC, Labelling, Package Leaflet or Combined PI when submitting paper-based PI documents (PDF).
11 Number
Title
Element
Directory m1/eu/13-pi/131-spclabelpl/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.
12 Number
Title
Element
Directory m1/eu/13-pi/131-spclabelpl/CC/LL
Comment Always use a language directory at this level during the lifecycle of the submission. See Row 13 for an example.

26
13 Number
Title
Element
File m1/eu/13-pi/131-spclabelpl/CC/LL/CC-PIDOC-VAR.EXT
Comment Filename for the spc-label-pl document composed by a fixed component “CC”, a fixed component “PIDOC” as per table of Appendix 2.3
and an optional variable component to be used if needed (e.g. m1/eu/13-pi/131-spclabelpl/emea/de/emea-combined-tablet10mgde.pdf).

27
14 Number 1.3.1
Title SmPC, Labelling and Package Leaflet
Element m1-3-1-pim
File m1/eu/13-pi/131-pim-DDDD-AR.zip or m1/eu/13-pi/131-pim-DDDD-AR.tgz
Comment This element should not be used anymore as the PIM project was closed on 28/03/2011 and will be removed from this annex 2 and the
DTD. With the next major revision of the EU M1 Specification the required technical changes will be introduced.
15 Number 1.3.2
Title Mock-up
Element m1-3-2-mockup
Directory m1/eu/13-pi/132-mockup
Comment
16 Number
Title
Element
Directory m1/eu/13-pi/132-mockup/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.
17 Number
Title
Element
File m1/eu/13-pi/132-mockup/CC/CC-mockup-VAR.EXT
Comment Filename for the mock-up document composed by a fixed component “CC”, a fixed component “mockup” and an optional variable
component to be used if needed. (e.g. fr-mockup-tablet10mgouter.pdf).

28
18 Number 1.3.3
Title Specimen
Element m1-3-3-specimen
Directory m1/eu/13-pi/133-specimen
Comment
19 Number
Title
Element
Directory m1/eu/13-pi/133-specimen/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.
20 Number
Title
Element
File m1/eu/13-pi/133-specimen/CC/CC-specimen-VAR.EXT
Comment Filename for the list of physical specimens provided with the submission composed by a fixed component “CC”, a fixed component
“specimen” and an optional variable component to be used if needed. (e.g. fr-specimen.pdf).
21 Number 1.3.4
Title Consultation with Target Patient Groups
Element m1-3-4-consultation
Directory m1/eu/13-pi/134-consultation
Comment
22 Number
Title
Element
Directory m1/eu/13-pi/134-consultation/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.

29
23 Number
Title
Element
File m1/eu/13-pi/134-consultation/CC/CC-consultation-VAR.EXT
Comment Filename for the results of assessments carried out in cooperation with target patient groups on the package leaflet, composed by a fixed
component “CC”, a fixed component “consultation” and an optional variable component to be used if needed. (e.g. consultation-
tablet10mgpl.pdf).
24 Number 1.3.5
Title Product Information already approved in the Member States
Element m1-3-5-approved
Directory m1/eu/13-pi/135-approved
Comment
25 Number
Title
Element
Directory m1/eu/13-pi/135-approved/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted.
26 Number
Title
Element
File m1/eu/13-pi/135-approved/CC/CC-approved-VAR.EXT
Comment Filename for the approved Product Information document composed by a fixed component “CC”, a fixed component “approved” and an
optional variable component to be used if needed. The “CC” prefix should be used for the country receiving the submission, not the
country where the product information is already approved (e.g. when submitting a dossier in France, where Product Information has
been approved in Poland, the file name would be (e.g. fr-approved-poland.pdf or fr-approved-polandmanumber.pdf).
27 Number 1.3.6
Title Braille
Element m1-3-6-braille
Directory m1/eu/13-pi/136-braille
Comment

30
28 Number
Title
Element
File m1/eu/13-pi/136-braille/braille-VAR.EXT
Comment Filename for the Braille information is composed by a fixed component “braille” and an optional variable component to be used if needed.
(e.g. braille.pdf).
29 Number 1.4
Title Information about the Experts
Element m1-4-expert
Directory m1/eu/14-expert
Comment General placeholder for Expert Information.
30 Number 1.4.1
Title Quality
Element m1-4-1-quality
Directory m1/eu/14-expert/141-quality
Comment General placeholder for quality information.
31 Number
Title
Element
File m1/eu/14-expert/141-quality/quality-VAR.EXT
Comment Filename for the quality expert document composed by a fixed component “quality” and an optional variable component to be used if
needed. (e.g. quality.pdf).
32 Number 1.4.2
Title Non-Clinical
Element m1-4-2-non-clinical
Directory m1/eu/14-expert/142-nonclinical
Comment General placeholder for non-clinical information.

31
33 Number
Title
Element
File m1/eu/14-expert/142-nonclinical/nonclinical-VAR.EXT
Comment Filename for the non-clinical expert document composed by a fixed component “nonclinical” and an optional variable component to be
used if needed. (e.g. nonclinical.pdf).
34 Number 1.4.3
Title Clinical
Element m1-4-3-clinical
Directory m1/eu/14-expert/143-clinical
Comment General placeholder for clinical information.
35 Number
Title
Element
File m1/eu/14-expert/143-clinical/clinical-VAR.EXT
Comment Filename for the clinical expert document composed by a fixed component “clinical” and an optional variable component to be used if
needed. (e.g. clinical.pdf).
36 Number 1.5
Title Specific Requirements for Different Types of Applications
Element m1-5-specific
Directory m1/eu/15-specific
Comment General placeholder for Specific Information.
37 Number 1.5.1
Title Information for Bibliographical Applications
Element m1-5-1-bibliographic
Directory m1/eu/15-specific/151-bibliographic
Comment General placeholder for bibliographical applications.

32
38 Number
Title
Element
File m1/eu/15-specific/151-bibliographic/bibliographic-VAR.EXT
Comment Filename for the specific bibliographic submission information composed by a fixed component “bibliographic” and an optional variable
component to be used if needed. (e.g. bibliographic.pdf).
39 Number 1.5.2
Title Information for Generic, ‘Hybrid’ or Bio-similar Applications
Element m1-5-2-generic-hybrid-biosimilar
Directory m1/eu/15-specific/152-generic-hybrid-bio-similar
Comment General placeholder for generic, ‘hybrid’ or bio-similar applications.
40 Number
Title
Element
File m1/eu/15-specific/152-generic-hybrid-bio-similar/generic-VAR.EXT or m1/eu/15-specific/152-generic-hybrid-bio-similar/hybrid-VAR.EXT
or m1/eu/15-specific/152-generic-hybrid-bio-similar/biosimilar-VAR.EXT
Comment Filename for the specific generic, hybrid or bio-similar submission information composed by a fixed component “generic” or “hybrid” or
“biosimilar”, and an optional variable component to be used if needed (e.g. generic.pdf).
41 Number 1.5.3
Title (Extended) Data/Market Exclusivity
Element m1-5-3-data-market-exclusivity
Directory m1/eu/15-specific/153-data-market-exclusivity
Comment General placeholder for (extended) data/market exclusivity.
42 Number
Title
Element
File m1/eu/15-specific/153-data-market-exclusivity/datamarketexclusivity-VAR.EXT
Comment Filename for the data / market exclusivity composed of a fixed component “datamarketexclusivity” and an optional variable component to
be used if needed (e.g. datamarketexclusivity.pdf).

33
43 Number 1.5.4
Title Exceptional Circumstances
Element m1-5-4-exceptional-circumstances
Directory m1/eu/15-specific/154-exceptional
Comment General placeholder for marketing authorisation granted under exceptional circumstances.
44 Number
Title
Element
File m1/eu/15-specific/154-exceptional/exceptional-VAR.EXT
Comment Filename for marketing authorisation granted under exceptional circumstances, composed of a fixed component “exceptional” and an
optional variable component to be used if needed (e.g. exceptional.pdf).
45 Number 1.5.5
Title Conditional Marketing Authorisation
Element m1-5-5-conditional-ma
Directory m1/eu/15-specific/155-conditional-ma
Comment General placeholder for conditional marketing authorisation.
46 Number
Title
Element
File m1/eu/15-specific/155-conditional-ma/conditionalma-VAR.EXT
Comment Filename for conditional marketing authorisation, composed of a fixed component “conditionalma” and an optional variable component to
be used if needed (e.g. conditionalma.pdf).
47 Number 1.6
Title Environmental Risk Assessment
Element m1-6-environrisk
Directory m1/eu/16-environrisk
Comment General placeholder for Environmental Risk Assessment.

34
48 Number 1.6.1
Title Non-GMO
Element m1-6-1-non-gmo
Directory m1/eu/16-environrisk/161-nongmo
Comment General placeholder for non-GMO.
49 Number
Title
Element
File m1/eu/16-environrisk/161-nongmo/nongmo-VAR.EXT
Comment Filename for the environmental risk assessment non-GMO composed by a fixed component “nongmo” and an optional variable
component to be used if needed. (e.g. nongmo.pdf).
50 Number 1.6.2
Title GMO
Element m1-6-2-gmo
Directory m1/eu/16-environrisk/162-gmo
Comment General placeholder for GMO.
51 Number
Title
Element
File m1/eu/16-environrisk/162-gmo/gmo-VAR.EXT
Comment Filename for the environmental risk assessment GMO-composed by a fixed component “gmo” and an optional variable component to be
used if needed (e.g. gmo.pdf).
52 Number 1.7
Title Information relating to Orphan Market Exclusivity
Element m1-7-orphan
Directory m1/eu/17-orphan
Comment General placeholder for Orphan Market Exclusivity information.

35
53 Number 1.7.1
Title Similarity
Element m1-7-1-similarity
Directory m1/eu/17-orphan/171-similarity
Comment General placeholder for information on similarity with authorised orphan product.
54 Number
Title
Element
File m1/eu/17-orphan/171-similarity/similarity-VAR.EXT
Comment Filename for the information on similarity composed by a fixed component “similarity” and an optional variable component to be used if
needed.
55 Number 1.7.2
Title Market Exclusivity
Element m1-7-2-market-exclusivity
Directory m1/eu/17-orphan/172-market-exclusivity
Comment General placeholder for information on market exclusivity.
56 Number
Title
Element
File m1/eu/17-orphan/172-market-exclusivity/marketexclusivity-VAR.EXT
Comment Filename for information on market exclusivity composed by a fixed component “marketexclusivity” and an optional variable component
to be used if needed.
57 Number 1.8
Title Information relating to Pharmacovigilance
Element m1-8-pharmacovigilance
Directory m1/eu/18-pharmacovigilance
Comment General placeholder for information on pharmacovigilance.

36
58 Number 1.8.1
Title Pharmacovigilance System
Element m1-8-1-pharmacovigilance-system
Directory m1/eu/18-pharmacovigilance/181-phvig-system
Comment General placeholder for information on pharmacovigilance system.
59 Number
Title
Element
File m1/eu/18-pharmacovigilance/181-phvig-system/phvigsystem-VAR.EXT
Comment Filename for information on pharmacovigilance system composed by a fixed component “phvigsystem” and an optional variable
component to be used if needed.
60 Number 1.8.2
Title Risk-management System
Element m1-8-2-risk-management-system
Directory m1/eu/18-pharmacovigilance/182-riskmgt-system
Comment General placeholder for information on risk management system.
61 Number
Title
Element
File m1/eu/18-pharmacovigilance/182-riskmgt-system/riskmgtsystem-VAR.EXT
Comment Filename for information on pharmacovigilance system composed by a fixed component “riskmgtsystem” and an optional variable
component to be used if needed.
62 Number 1.9
Title Information relating to Clinical Trials
Element m1-9-clinical-trials
Directory m1/eu/19-clinical-trials
Comment General placeholder for information on clinical trials.

37
63 Number
Title
Element
File m1/eu/19-clinical-trials/clinicaltrials-VAR.EXT
Comment Filename for information on clinical trials composed by a fixed component “clinicaltrials” and an optional variable component to be used if
needed.
64 Number 1.10
Title Information relating to Paediatrics
Element m1-10-paediatrics
Directory m1/eu/110-paediatrics
Comment General placeholder for information on paediatrics.
65 Number
Title
Element
Directory m1/eu/110-paediatrics/paediatrics-VAR.EXT
Comment Filename for information on paediatrics composed by a fixed component “paediatrics” and an optional variable component to be used if
needed.
66 Number
Title Responses to Questions
Element m1-responses
Directory m1/eu/responses
Comment
67 Number
Title
Element
Directory m1/eu/responses/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.

38
68 Number
Title
Element
File m1/eu/responses/CC/CC-responses-VAR.EXT
Comment Filename for responses to questions composed by a fixed component “CC”, a fixed component “responses” and an optional variable
component to be used if needed (e.g. be-responses.pdf).
69 Number
Title Additional Data
Element m1-additional-data
Directory m1/eu/additional-data
Comment The 'Additional Data’ section should only be used for information required for National, MR and Decentralised Procedures; it is therefore
not generally applicable for the Centralised Procedure.
70 Number
Title
Element
Directory m1/eu/additional-data/CC
Comment Always use the country directory at this level for all procedures even when only one file is submitted to only one country during the
lifecycle of the submission.
71 Number
Title
Element
File m1/eu/additional-data/CC/CC-additionaldata-VAR.EXT
Comment Filename for additional information requested composed by a fixed component “CC”, a fixed component “additionaldata” and an optional
variable component to be used if needed (e.g. be-additionaldata-yellowpink.pdf).
Supporting data for variations should be not be placed in this section; wherever possible they should be placed in the relevant CTD
section, primarily within Module 3 ‘Quality’ and Module 1 (1.3.1) ‘Summary of Product Characteristics, Labelling and Package Leaflet’.
Where documents cannot be assigned to specific CTD-defined locations, then they should be attached to the 1.2 Application Form. The
same approach should be used for renewals. Additionally see comments in row no 8.
The 'Additional Data’ section should only be used for information required for country specific information/documentation for National, MR
and Decentralised Procedures; it is not applicable for the Centralised Procedure.

39
72 Number
Title
Element
Directory m1/eu/util
Comment Additional folder to hold utility files used in EU Region only.
73 Number
Title
Element
Directory m1/eu/util/dtd
Comment Additional folder to hold DTD files used in EU Region only.
74 Number
Title
Element
Directory util/dtd
Comment ICH specified location for eCTD DTD files.
75 Number
Title
Element
Directory util/style
Comment ICH specified location for eCTD style-sheet files. The style-sheet to be used should be the most recent version, which is always
published as part of the specification package for download.
Note that the XML instance can only point to one style-sheet and that referencing a customised style-sheet will effectively prevent the
agency using the official one. It is therefore recommended not to submit customised style-sheets.

40
Appendix 2.1: Destination Codes
In most cases the destination code is an ISO-3166-1-alpha-2 code usually called “country code” or
“CC” in this specification.

Code Destination Comment

at Austria ISO-3166-1-alpha-2 code
be Belgium ISO-3166-1-alpha-2 code
bg Bulgaria ISO-3166-1-alpha-2 code
This is not an ISO code, but should be used to identify documents
that are potentially applicable to all EU countries, irrespective of
common All countries whether they are participating in the procedure or not
This code should be used in the Decentralised Procedure and
Mutual Recognition Procedures only.
cy Cyprus ISO-3166-1-alpha-2 code
cz Czech Republic ISO-3166-1-alpha-2 code
de Germany ISO-3166-1-alpha-2 code
dk Denmark ISO-3166-1-alpha-2 code
ee Estonia ISO-3166-1-alpha-2 code
This is not an ISO code, but should be used as per guidance for
el Greece
application forms in the Notice to Applicants
This is not an ISO code, but should be used for files that apply to
emea EMEA
all countries in the Centralised Procedure
es Spain ISO-3166-1-alpha-2 code
fi Finland ISO-3166-1-alpha-2 code
fr France ISO-3166-1-alpha-2 code
hu Hungary ISO-3166-1-alpha-2 code
ie Ireland ISO-3166-1-alpha-2 code
is Iceland ISO-3166-1-alpha-2 code
it Italy ISO-3166-1-alpha-2 code
li Liechtenstein ISO-3166-1-alpha-2 code
lt Lithuania ISO-3166-1-alpha-2 code
lu Luxembourg ISO-3166-1-alpha-2 code
lv Latvia ISO-3166-1-alpha-2 code
mt Malta ISO-3166-1-alpha-2 code
nl Netherlands ISO-3166-1-alpha-2 code
no Norway ISO-3166-1-alpha-2 code
pl Poland ISO-3166-1-alpha-2 code
pt Portugal ISO-3166-1-alpha-2 code
ro Romania ISO-3166-1-alpha-2 code
se Sweden ISO-3166-1-alpha-2 code
si Slovenia ISO-3166-1-alpha-2 code
sk Slovakia ISO-3166-1-alpha-2 code
This is not an ISO country code, but should be used as per
uk United Kingdom
guidance for application forms in the Notice to Applicants

41
Appendix 2.2: Language Codes
Codes are ISO-639-1 codes defining the European languages used in the context of eCTD
submissions for marketing authorisation applications in the EEA.

Code Language
bg Bulgarian
cs Czech
da Danish
de German
el Greek
en English
es Spanish
et Estonian
fi Finnish
fr French
hu Hungarian
is Icelandic
it Italian
lt Lithuanian
lv Latvian
mt Maltese
nl Dutch
no Norwegian
pl Polish
pt Portuguese
ro Romanian
sk Slovakian
sl Slovenian
sv Swedish

Appendix 2.3: SmPC, Labelling and Package Leaflet File Name Identifiers

PI DOC Description
spc Summary of Product Characteristics
annex2 Annex II
outer Outer Packaging
interpack Intermediate Packaging*
impack Immediate Packaging
other Other product information
pl Package Leaflet
Single text file incorporating the following documents:
spc + annex2 + outer + interpack + impack + other + pl, in this sequence as
combined
applicable for the Centralised Procedure. Only one file per language is required.
‘Combined’ means presented as one document.
* = When labelling documents are submitted as a single file, the type ‘interpack’ should be used

42
Appendix 2.4: Agency Codes and Names

The table below provides the list of Agencies as identified on the Heads of Medicines Agency website,
i.e. http://www.hma.eu. The Agency Code is the value to use from within the EU Module 1 XML file.

Country Agency Human/Vet Agency Name

Code (H/V)
Austria - BASG-Federal Office for Safety in Health Care
Austria AT-AGES H/V
(AGES-PharmMed LCM)
Belgium - Agence Fédérale des Médicaments et des
Belgium BE-FAMHP H/V
Produits de Santé
BG-BDA H Bulgaria - Bulgarian Drug Agency
Bulgaria
BG-NVS V Bulgaria - Institute for Control of Veterinary Product
Cyprus CY-VS H/V Cyprus - Ministry of Health Pharmaceutical Services
CZ-SUKL H Czech Rep - State Institute for Drug Control
Czech Rep. Czech Rep - Institute for State Control of Veterinary
CZ-USKVBL V
Biologicals and Medicaments
Denmark DK-DKMA H/V Denmark - Danish Medicines Agency
Estonia EE-SAM H/V Estonia - State Agency of Medicines
EU EU-EMEA H/V EMEA - European Medicines Agency
Finland FI-NAM H/V Finland - National Agency for Medicines
FR- France - AFSSAPS - Agence Française de Sécurité
H
AFSSAPS Sanitaire des Produits de Santé
France France - ANMV - Agence Nationale du Médicament
FR-ANMV V Vétérinaire, Agence Française de Sécurité Sanitaire
des Aliments
Germany - BfArM - Bundesinstitut für Arzneimittel und
DE-BFARM H
Medizinprodukte
Germany – BVL - Bundesamt für Verbraucherschutz
Germany DE-BVL V
und Lebensmittelsicherheit, Ref. 301
Germany – PEI - Paul-Ehrlich Institut, Bundesinstitut für
DE-PEI H/V
Impfstoffe und biomedizinische Arzneimittel
Greece EL-EOF H/V Greece - EOF - National Drug Organisation
HU-IVMP V Hungary - Institute for Veterinary Medicinal Products
Hungary
HU-OGYI H Hungary - National Institute of Pharmacy
Iceland IS-IMCA H/V Iceland - Icelandic Medicines Control Agency
IE-IMB H/V Ireland - Irish Medicines Board
Ireland
IE-DAFF V Ireland - Dept of Agriculture & Food
IT-AIFA H Italy - Agenzia Italiana del Farmaco
Italy - Laboratorio di Medicina Veterinaria, Istituto
IT-LMV V
Italy Superiore di Sanità
Italy - Ministero della Salute, Direzione Generale della
IT-SPV H/V
Sanità Pubblica Veterinaria
Latvia LV-ZVA H/V Latvia - State Agency of Medicines
Liechtenstein - Kontrollstelle für Arzneimittel beim Amt
Liechtenstein LI-LLV H/V
für Lebensmittelkontrolle und Veterinärwesen
Lithuania LT-SMCA H Lithuania - State Medicines Control Agency

43
 Country Agency Human/Vet Agency Name
Code (H/V)
Lithuania - Lithuanian State Inspection on Veterinary
LT-VVPI V
Preparations
LT-VMVT V Lithuania - State Food and Veterinary Service
LU- Luxembourg - Direction de la Santé Villa Louvigny
Luxembourg H/V
MINSANT Division de la Pharmacie et des Medicaments
MT-MRU V Malta - Medicines Regulatory Unit
Malta MT- Malta - Medicines Authority Divizjoni Tas-Sahha
H
MEDAUTH Bezzjoni Ghar-Regolazzjoni Tal-Medicini
Netherlands - College ter Beoordeling van
Netherlands NL-MEB H/V
Geneesmiddelen Medicines Evaluation Board
Norway NO-NOMA H/V Norway - The Norwegian Medicines Agency
Poland - Office for Registration of Medicinal Products,
Poland PL-URPL H/V
Medical Devices and Biocidal Products
Portugal - DGV - Direcção Geral de Veterinária,
PT-DGV H/V
Divisão de Meios de Defesa da Saúde Animal
Portugal
PT- Portugal - INFARMED - Instituto Nacional da Farmácia
H/V
INFARMED e do Medicamento Parque da Saúde de Lisboa
Romania RO-ANM H/V Romania - National Medicines Agency
SK-SIDC H Slovak Rep - State Institute for Drug Control
Slovak Rep. Slovak Rep - Institute for State Control of Veterinary
SK-USKVBL V
Biologicals and Medicaments Biovetská 34
Slovenia - Agency for Medicinal Products and Medical
Slovenia SI-JAZMP H/V
Devices of the Republic of Slovenia
Spain - Agencia Española de Medicamentos y
Spain ES-AGEMED H/V
Productos Sanitarios
Sweden SE-MPA H/V Sweden - Medical Products Agency
United UK-MHRA H Medicines and Healthcare products Regulatory Agency
Kingdom UK-VMD V VMD - Veterinary Medicines Directorate

Note that only ‘human’ agency codes/names should be used in the context of an eCTD submission.

44
Appendix 3: Modularised DTD for EU Module 1

eu-regional.dtd

<!--
PUBLIC "-//EU//DTD eCTD EU Backbone 1.4//EN"
In the eCTD File Organisation: "util/dtd/eu-regional.dtd"

August 2009

Contributors:
AFSSAPS (Aziz Diop)
EMEA (Laurent Desqueper)
MEB (C.A. van Belkum)

Meaning or value of the suffixes:

? : element must appear 0 or 1 time
* : element must appear 0 or more time
+ : element must appear 1 or more times
<none>: element must appear once and only once
-->

<!-- General declarations, external modules references................... -->

<!ENTITY % countries
"(at|be|bg|common|cy|cz|de|dk|ee|el|es|emea|fi|fr|hu|ie|is|it|li|lt|lu|lv|mt|nl|no|pl|pt|ro|se|si|sk|uk)">
<!ENTITY % languages "(bg|cs|da|de|el|en|es|et|fi|fr|hu|is|it|lt|lv|mt|nl|no|pl|pt|ro|sk|sl|sv)">

<!ENTITY % leaf-node "(( leaf | node-extension )*)">

<!ENTITY % envelope-module SYSTEM "eu-envelope.mod" >

%envelope-module;

<!ENTITY % leaf-module SYSTEM "eu-leaf.mod" >

%leaf-module;

<!ELEMENT specific (
%leaf-node;
)>
<!ATTLIST specific
country %countries; #REQUIRED
>
<!ELEMENT pi-doc (
%leaf-node;
)>
<!ATTLIST pi-doc
xml:lang %languages; #REQUIRED
type (spc|annex2|outer|interpack|impack|other|pl|combined) #REQUIRED
country %countries; #REQUIRED
>

<!-- Root element ..................................................... -->

<!ELEMENT eu:eu-backbone (
eu-envelope,
m1-eu
)>

45
<!ATTLIST eu:eu-backbone
xmlns:eu CDATA #FIXED "http://europa.eu.int"
xmlns:xlink CDATA #FIXED "http://www.w3c.org/1999/xlink"
xml:lang CDATA #IMPLIED
dtd-version CDATA #FIXED "1.4"
>

<!-- ................................................................... -->

<!ELEMENT m1-eu (
m1-0-cover,
m1-2-form?,
m1-3-pi?,
m1-4-expert?,
m1-5-specific?,
m1-6-environrisk?,
m1-7-orphan?,
m1-8-pharmacovigilance?,
m1-9-clinical-trials?,
m1-10-paediatrics?,
m1-responses?,
m1-additional-data?
)>

<!-- ................................................................... -->

<!ELEMENT m1-0-cover (
specific+
)>

<!-- ................................................................... -->

<!ELEMENT m1-2-form (
specific+
)>

<!-- ................................................................... -->

<!ELEMENT m1-3-pi (
m1-3-1-spc-label-pl?,
m1-3-1-pim?,
m1-3-2-mockup?,
m1-3-3-specimen?,
m1-3-4-consultation?,
m1-3-5-approved?,
m1-3-6-braille?
)>

<!ELEMENT m1-3-1-spc-label-pl (
pi-doc+
)>
<!ELEMENT m1-3-1-pim (
leaf
)>
<!ELEMENT m1-3-2-mockup (
specific+
)>
<!ELEMENT m1-3-3-specimen (
specific+
)>
<!ELEMENT m1-3-4-consultation (
specific+
)>

46
<!ELEMENT m1-3-5-approved (
specific+
)>
<!ELEMENT m1-3-6-braille (
%leaf-node;
)>

<!-- ................................................................... -->

<!ELEMENT m1-4-expert (
m1-4-1-quality?,
m1-4-2-non-clinical?,
m1-4-3-clinical?
)>

<!ELEMENT m1-4-1-quality %leaf-node;>

<!ELEMENT m1-4-2-non-clinical %leaf-node;>
<!ELEMENT m1-4-3-clinical %leaf-node;>

<!-- ................................................................... -->

<!ELEMENT m1-5-specific (
m1-5-1-bibliographic?,
m1-5-2-generic-hybrid-bio-similar?,
m1-5-3-data-market-exclusivity?,
m1-5-4-exceptional-circumstances?,
m1-5-5-conditional-ma?
)>

<!ELEMENT m1-5-1-bibliographic %leaf-node;>

<!ELEMENT m1-5-2-generic-hybrid-bio-similar %leaf-node;>
<!ELEMENT m1-5-3-data-market-exclusivity %leaf-node;>
<!ELEMENT m1-5-4-exceptional-circumstances %leaf-node;>
<!ELEMENT m1-5-5-conditional-ma %leaf-node;>

<!-- ................................................................... -->

<!ELEMENT m1-6-environrisk (
(m1-6-1-non-gmo | m1-6-2-gmo)?
)>
<!ELEMENT m1-6-1-non-gmo %leaf-node;>
<!ELEMENT m1-6-2-gmo %leaf-node;>

<!-- ................................................................... -->

<!ELEMENT m1-7-orphan (
m1-7-1-similarity?,
m1-7-2-market-exclusivity?
)>
<!ELEMENT m1-7-1-similarity %leaf-node;>
<!ELEMENT m1-7-2-market-exclusivity %leaf-node;>

<!-- ................................................................... -->

<!ELEMENT m1-8-pharmacovigilance (
m1-8-1-pharmacovigilance-system?,
m1-8-2-risk-management-system?
)>
<!ELEMENT m1-8-1-pharmacovigilance-system %leaf-node;>
<!ELEMENT m1-8-2-risk-management-system %leaf-node;>

<!-- ................................................................... -->

<!ELEMENT m1-9-clinical-trials %leaf-node;>

47
<!-- ................................................................... -->
<!ELEMENT m1-10-paediatrics %leaf-node;>

<!-- ................................................................... -->

<!ELEMENT m1-responses (
specific+
)>

<!-- ................................................................... -->

<!ELEMENT m1-additional-data (
specific+
)>

48
eu-envelope.mod

<!--
In the eCTD File Organisation: "util/dtd/eu-envelope.mod"

Version 1.4
August 2009

Contributors:
AFSSAPS (Aziz Diop)
EMEA (Laurent Desqueper)
MEB (C.A. van Belkum)

-->

<!-- ................................................................... -->

<!ELEMENT eu-envelope (
envelope+
)>

<!ELEMENT envelope (
submission,
applicant,
agency,
procedure,
invented-name+,
inn*,
sequence,
related-sequence*,
submission-description
)>

<!-- ................................................................... -->

<!ELEMENT submission ( number?, tracking ) >
<!ELEMENT tracking ( number+ )>
<!ELEMENT number ( #PCDATA )>
<!ELEMENT applicant ( #PCDATA )>
<!ELEMENT agency EMPTY>
<!ELEMENT procedure EMPTY >
<!ELEMENT invented-name ( #PCDATA )>
<!ELEMENT inn ( #PCDATA )>
<!ELEMENT sequence ( #PCDATA )>
<!ELEMENT related-sequence ( #PCDATA )>
<!ELEMENT submission-description ( #PCDATA )>

<!-- ................................................................... -->

<!ATTLIST submission
type ( initial-maa | var-type1a | var-type1b | var-type2 | var-nat | extension | psur | renewal |
supplemental-info | fum | specific-obligation | asmf | pmf | referral | annual-reassessment | usr | paed-
article-29 | paed-article-46 | article-58 | notification-61-3 | transfer-ma | corrigendum | lifting-
suspension | withdrawal | reformat) #REQUIRED
mode ( single | grouping | worksharing ) #IMPLIED
>

49
<!-- ................................................................... -->
<!ATTLIST agency
code ( AT-AGES | BE-FAMHP | BG-BDA | BG-NVS | CY-VS | CZ-SUKL | CZ-USKVBL | DE-BFARM |
DE-BVL | DE-PEI | DK-DKMA | EE-SAM | EL-EOF | ES-AGEMED | FI-NAM | FR-AFSSAPS | FR-
ANMV | HU-IVMP | HU-OGYI | IE-IMB | IE-DAFF | IS-IMCA | IT-AIFA | IT-LMV | IT-SPV | LI-LLV | LT-
SMCA | LT-VVPI | LT-VMVT | LU-MINSANT | LV-ZVA | MT-MRU | MT-MEDAUTH | NL-MEB | NO-
NOMA | PL-URPL | PT-DGV | PT-INFARMED | RO-ANM | SE-MPA | SI-JAZMP | SK-SIDC | SK-
USKVBL | UK-MHRA | UK-VMD | EU-EMEA ) #REQUIRED>

<!-- ................................................................... -->

<!ATTLIST procedure
type (
centralised
| national
| mutual-recognition
| decentralised
) #REQUIRED
>

<!-- ................................................................... -->

<!ENTITY % env-countries
"(at|be|bg|cy|cz|de|dk|ee|el|emea|es|fi|fr|hu|ie|is|it|li|lt|lu|lv|mt|nl|no|pl|pt|ro|se|si|sk|uk)">

<!-- ................................................................... -->

<!ATTLIST envelope country %env-countries; #REQUIRED >
<!ATTLIST related-sequence country %env-countries; #IMPLIED >

<!-- +++ -->

eu-leaf.mod

<!--
In the eCTD File Organisation: "util/dtd/eu-leaf.mod"

Version 1.4
August 2009

Contributors:
AFSSAPS (Aziz Diop)
EMEA (Laurent Desqueper)
MEB (C.A. van Belkum)

This is based on ich-ectd-3-2.dtd;

If the ich-ectd.dtd is modularized, this one could be replaced.

Hence, one is certain that the common and EU leaf are the same.
-->

<!-- ============================================================= -->

<!ELEMENT node-extension (title, (leaf | node-extension)+)>
<!ATTLIST node-extension
ID ID #IMPLIED
xml:lang CDATA #IMPLIED
>

50
<!-- ============================================================= -->
<!ENTITY % show-list " (new | replace | embed | other | none) ">
<!ENTITY % actuate-list " (onLoad | onRequest | other | none) ">
<!ENTITY % operation-list " (new | append | replace | delete) ">
<!ENTITY % leaf-element " (title, link-text?) ">
<!ENTITY % leaf-att '
ID ID #REQUIRED
application-version CDATA #IMPLIED
version CDATA #IMPLIED
font-library CDATA #IMPLIED
operation %operation-list; #REQUIRED
modified-file CDATA #IMPLIED
checksum CDATA #REQUIRED
checksum-type CDATA #REQUIRED
keywords CDATA #IMPLIED
xmlns:xlink CDATA #FIXED "http://www.w3c.org/1999/xlink"
xlink:type CDATA #FIXED "simple"
xlink:role CDATA #IMPLIED
xlink:href CDATA #IMPLIED
xlink:show %show-list; #IMPLIED
xlink:actuate %actuate-list; #IMPLIED
xml:lang CDATA #IMPLIED
'>

<!ELEMENT leaf %leaf-element;>

<!ATTLIST leaf
%leaf-att;
>
<!ELEMENT title (#PCDATA)>
<!ELEMENT link-text (#PCDATA | xref)*>

<!ELEMENT xref EMPTY>

<!ATTLIST xref
ID ID #REQUIRED
xmlns:xlink CDATA #FIXED "http://www.w3c.org/1999/xlink"
xlink:type CDATA #FIXED "simple"
xlink:role CDATA #IMPLIED
xlink:title CDATA #REQUIRED
xlink:href CDATA #REQUIRED
xlink:show %show-list; #IMPLIED
xlink:actuate %actuate-list; #IMPLIED
>

<!-- +++ -->

51