GCC - Module - 1 - SpecificationVersion 1.4

GCC Module 1
Specifications
Version 1.4
Sep 2015
GCC Module 1 Specifications
Version 1.4
Drug Sector
Saudi Food & Drug Authority
Please visit SFDA’s website at

http://www.sfda.gov.sa/En/Drug for the latest update
For Inquiries: [email protected]
For Comments or Suggestions: [email protected]
Sep 2015
Saudi Food & Drug Authority 2
Drug Sector
Vision & Mission
Vision
To be the leading regional Drug Regulatory Authority for pharmaceuticals and cosmetic
products, with professional excellence and services that contribute to the protection and
advancement of public health in the Kingdom of Saudi Arabia.
‫الرؤية‬
‫ ويدد ددساه همنيية سيمةز ستن يف مياية‬،‫أن يكون قطاع ادلواء رائداً اقلمييا يف الرقابة عىل الودوية وست حضارا الحميي‬
.‫وهعزيز الصحة يف امليلكة العربية التعوودية‬
Mission
Protecting public health by ensuring safety, quality, efficacy and accessibility of human,
veterinary drugs and biological products, and safety of cosmetics, through administration of
a national regulatory system which is consistent with international best practice. Through
our mission, we also provide accurate and scientific-based information to the public and
healthcare professionals.
‫الرساةل‬
‫مياية الصحة العاسة سن دالل ضيان أسان وجوود وفعالية وهوفر الودوية البرشية والبيطرية وامليحجا احليوية وسالسة سواود‬
‫ امليارسا ادلولية وهددمي املعلوسا ادلوائية املبنية عىل أسس عليية‬،‫ عرب هطبيق نظا وطين للرقابة ستوافق سع أفض‬،‫الحميي‬
.‫للعاسة واملنييني الصضيني‬
Sep 2015
DOCUMENT CONTROL
Version Date Authors Comments
0.1 07/12/2010 Regulatory Affairs First draft
0.2 08/03/2011 Regulatory Affairs Revised draft
0.3 12/06/2011 Regulatory Affairs External consultation
0.4 03/12/2011 Regulatory Affairs Final revision
1.0 17/12/2011 Regulatory Affairs Published
1.1 08/05/2012 Regulatory Affairs Revised document
1.2 10/11/2012 Regulatory Affairs Minor changes, checksum update
1.3 17/08/2015 Regulatory Affairs Add of submission unit concept, Add

values in submission type, some minor
changes
1.4 17/09/2015 Regulatory Affairs Update
Note: For most recent update please refer to annex 1
Sep 2015
TABLE OF CONTENTS
1 INTRODUCTION ..................................................................................................................................... 6
1.1. BACKGROUND ..................................................................................................................................... 6
1.2. SCOPE .................................................................................................................................................... 6
1.3. TECHNICAL REQUIREMENTS .......................................................................................................... 7
1.4. CHANGE CONTROL ............................................................................................................................ 7
1.5. GLOSSARY ............................................................................................................................................ 8
2 GCC MODULE 1: REGIONAL INFORMATION ...................................................................................... 10
2.1. GENERAL CONSIDERATIONS ......................................................................................................... 10
2.1.1 DOCUMENT GRANULARITY ...................................................................................................... 10
2.1.2 CORRESPONDENCE ..................................................................................................................... 10
2.1.3 SEQUENCE NUMBERS ................................................................................................................. 10
2.1.4 BOOKMARKS AND HYPERTEXT LINKS .................................................................................. 11
2.2. REGIONAL FILE FORMATS............................................................................................................. 11
2.2.1. MODULE 1 .................................................................................................................................. 11
2.2.2. MODULES 2 TO 5....................................................................................................................... 12
2.3. HANDLING OF EMPTY OR MISSING ECTD SECTIONS .............................................................. 12
2.4. TECHNICAL INFORMATION ........................................................................................................... 13
2.4.1. USE OF ELECTRONIC SIGNATURES .................................................................................... 13
2.4.2. SECURITY ISSUES .................................................................................................................... 13
2.4.3. VIRUS PROTECTION................................................................................................................ 13
2.4.4. PASSWORD PROTECTION ...................................................................................................... 13
2.5. GENERAL ARCHITECTURE OF MODULE 1 ................................................................................. 13
2.5.1. CHECKSUM................................................................................................................................ 14
2.5.2. ENVELOPE ................................................................................................................................. 14
2.5.3. XML CATALOGUE .................................................................................................................... 15
2.5.4. DIRECTORY / FILE STRUCTURE........................................................................................... 15
2.5.5. FILE NAMING CONVENTION ................................................................................................. 15
2.6. BUSINESS PROTOCOL ...................................................................................................................... 16
2.7. CHANGE CONTROL .......................................................................................................................... 16
2.8. INSTRUCTIONS FOR EXTENSION SUBMISSIONS ....................................................................... 17
2.9. REFORMATTING ............................................................................................................................... 17
APPENDIX ................................................................................................................................................... 18
APPENDIX 1: ENVELOPE ELEMENT DESCRIPTION ............................................................................ 18
APPENDIX 2: DIRECTORY/FILE STRUCTURE FOR GCC MODULE 1 .................................................... 21
APPENDIX 3: COUNTRY SPECIFIC ELEMENTS .................................................................................. 28
APPENDIX 4: EXAMPLE SCREENSHOT ............................................................................................. 29
APPENDIX 5: LIST OF CODES........................................................................................................... 30
APPENDIX 6: MODULARIZED DTD FOR GCC MODULE 1 ................................................................. 32
GCC Regional DTD .................................................................................................................. 32
GCC Envelope .......................................................................................................................... 36
GCC Leaf ................................................................................................................................. 38
ANNEX 1: ...................................................................................................................................... 40
Sep 2015
1 Introduction
This document specifies Module 1 of the electronic Common Technical Document

(eCTD) for Gulf Cooperation Council (GCC).
This document should be read together with the ICH eCTD Specification to
prepare a valid eCTD submission for GCC. The latest version of the ICH eCTD
Specification can be found at: http://estri.ich.org
The ICH M4 Expert Working Group (EWG) has defined the Common Technical
Document (CTD). The ICH M2 EWG has defined, in the current document, the
specification for the Electronic Common Technical Document (eCTD). The eCTD is
defined as an interface for industry to agency transfer of regulatory information while
at the same time taking into consideration the facilitation of the creation, review, life
cycle management and archiving of the electronic submission.
The eCTD specification lists the criteria that will make an electronic submission
technically valid. The focus of the specification is to provide the ability to transfer the
registration application electronically from industry to a regulatory authority. Industry
to industry and agency to agency transfer is not addressed.
1.1. Background
The specification for the eCTD is based upon content defined within the CTD
issued by the ICH M4 EWG. The CTD describes the organization of modules,
sections and documents. The structure and level of detail specified in the CTD have
been used as the basis for defining the eCTD structure and content but, where
appropriate, additional details have been developed within the eCTD specification.
The philosophy of the eCTD is to use open standards. Open standards, including
proprietary standards which through their widespread use can be considered de facto
standards, are deemed to be appropriate in general.
1.2. Scope
The CTD as defined by the M4 EWG does not cover the full submission that is to
be made in a region. It describes only modules 2 to 5, which are common across all
regions. The regional Administrative Information and Prescribing Information is
Sep 2015
described in Module 1. The CTD does not describe the content of module 1 because it
is regional specific, nor does it describe documents that can be submitted as
amendments or variations to the initial application. The value of producing a
specification for the creation of an electronic submission based only upon the modules
described in the CTD would be limited. Therefore, the M2 EWG has produced a
specification for the eCTD that is applicable to all modules of initial registration
applications and for other submissions of information throughout the life cycle of the
product, such as variations and amendments.
1.3. Technical Requirements

The specification is designed to support high-level functional requirements such
as the following:
 Copying and pasting

 Viewing and printing of documents
 Annotation of documentation
 Facilitating the exporting of information to databases
 Searching within and across applications
 Navigating throughout the eCTD and its subsequent
amendments/variations
1.4. Change Control

The specification for the eCTD is likely to change with time. Factors that could
affect the content of the specification include, but are not limited to:
 Change in the content of the CTD, either through the amendment of

information, at the same level of detail, or by provision of more detailed
definition of content and structure
 Change to the regional requirements for applications that are outside the
scope of the CTD
 Updating standards that are already in use within the eCTD
 Identification of new standards that provide additional value for the
creation and/or usage of the eCTD
 Identification of new functional requirements
 Experience of use of the eCTD by all parties
Sep 2015
1.5. Glossary
A brief glossary of terms (for the purpose of this document only) is indicated below:
Applicant A pharmaceutical company or its agent that is submitting

information in support of an application.
Application A collection of documents compiled by a pharmaceutical company
or its agent in compliance with guidelines in order to seek a
marketing authorization or any amendments thereof.
CTD Common Technical Document
DTD Document Type Definition
eCTD electronic Common Technical Document
An eCTD application may comprise a number of sequences.
EWG Expert Working Group; charged with developing a harmonised
guideline that meets the objectives in the Concept Paper and
Business Plan.
GCC Gulf Cooperation Council
ICH International Conference on Harmonisation of technical
requirements for registration of pharmaceuticals for human use
JPEG Joint Photographic Experts Group
PDF Portable Document Format
PNG Portable Network Graphics
Procedure A registration procedure for the authorization of medicinal
products
Regulatory A collection of sequences covering the start to the end of a specific
activity 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.
RTF Rich Text Format
Submission A single set of information and/or documents supplied by the
applicant as a part of, or the complete, Application. In the context
of eCTD, this is equivalent to ‘sequence’
SVG Scalable Vector Graphics
ToC Table of Contents
XML eXtensible Markup Language
XSL eXtensible StyleSheet Language
Reformat Intended to support the reformatting of an existing submission
application from any format to eCTD
Extension change to a marketing authorization of a medicine such as changes
to the active substance, available strengths, pharmaceutical forms
or the route of administration.
ASMF Active Substance Master File
PMF Plasma Master File
PSUSA PSUR Single Assessment procedure
Sep 2015
USR Urgent Safety Restriction
RMP Risk Management Plan
Submission The submission type describes the regulatory activity to which the
type content will be submitted.
Submission The submission unit element of the envelope metadata set
unit describes the content at a lower level (a “sub-activity”) which is
submitted in relation to a defined regulatory activity such as the
applicant response to validation issues or list of questions or any
other additional information
Sep 2015
2 GCC 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 GCC is specified in the latest version of the Guidance for
Submission that can be found at http://www.sfda.gov.sa
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 kind of documents need be
included in Module 1. In addition, other items such as the rationale for variations and
renewal documentation could also be included in Module 1.
This document describes only the region-specific information that is common to

all eCTD submissions in the Gulf Cooperation countries.
2.1. General Considerations

Typically, an eCTD application will cover all dosage forms and strengths of a
product with any one invented name.
2.1.1 Document granularity

Submissions are a collection of documents and each document should be
provided as a separate file. The detailed structure of the eCTD should conform to the
ICH Granularity Document and GCC M1 specifications.
2.1.2 Correspondence
In addition to the eCTD application information may need to be exchanged to
assist the processing or handling of the application. Not all that correspondence
should be included in the eCTD. This is because the eCTD exchange is currently one
way only, from applicant to Agency, and not all correspondence is directly relevant to
the application dossier.
2.1.3 Sequence Numbers

Sequence numbers are used to differentiate between different submissions of the
same application over the life cycle of the product.
Sep 2015
2.1.4 Bookmarks and hypertext links
Navigation through an electronic submission is greatly enhanced by the
intelligent use of bookmarks and hypertext links. ICH guidance states “It is expected
that any document that has a Table of Contents (TOC) will have bookmarks (see the
eCTD specification for details). Documents without TOCs should have bookmarks
included where it aids in the navigation around the document content. For example, a
4 page document summarizing findings could require bookmarks to aid navigation.
However, a 300 page file containing a single data listing might not require bookmarks
as there is no further internal structure. Please consult national guidance documents
for further details.”
In general terms, bookmarks and hyperlinks should be used to aid navigation. The
overuse of hyperlinks may confuse rather than help assessors and may cause problems
later in life cycle management.
Additional details on creating bookmarks and hypertext links in PDF documents

can be found in the ICH eCTD Specification, Appendix 7.
2.2. Regional File Formats

2.2.1. 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, for other formats see regional guidance for narrative documents to be
included in Module 1.
XML is also an acceptable format for the delivery of structured data in Module 1,
specifically the application form and product information, as long as the XML is
produced to the standard defined in the electronic Application Forms.
Although the use of the file formats defined in Table 1 is strongly recommended,
the GCC and applicants could agree on the use of other formats in Module 1, for
example, the proprietary format MS Word is for Product Information documents in
Module 1.3 (see specific national guidance).
These documents, if requested, should not be referenced in the eCTD backbone,

and should always be provided in addition to the PDF versions.
Sep 2015
Table 1: Acceptable file formats for GCC Module 1
Document File Format Remark

Administrative forms: Documents should be generated
 Application form and XML, PDF, RTF from electronic source documents,
its annexes any signature may be embedded as
 Variation application PDF, RTF graphic file in the PDF text if
form incl. background desired, although this is not
for the variation necessary as the hard paper copy
 Renewal form and its PDF, RTF contains the legally binding
annexes signature.
Product Information: If a higher resolution is necessary
for the mock-ups, use JPEG, GIF,
 Labeling text PNG or SVG on a case-by-case
XML, PDF, RTF
basis.
 Packaging mock-ups XML, PDF, RTF
Labeling texts can be submitted in
 Reference to PDF
XML format according to the PIM
Specimens
Data Exchange Standard. In that
 Readability Testing PDF
context, images can be transmitted
 Information relating to PDF
in JPEG, GIF, PNG, TIF, SVG, or
Orphan Applications MathML.
PDF preferably generated from
Other PDF, RTF
electronic source
These are XML specific file
Document Type formats and must only be the
Definitions and DTD, XSL specified versions of the specific
Stylesheets files required for the submission of
electronic Application Forms
2.2.2. 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. The GCC and pharmaceutical
companies could agree on a case-by-case basis to use formats other than the common
formats (e.g. RTF). However, the use of formats other than those specified by the ICH
eCTD Specification Document is discouraged.
2.3. Handling of Empty or Missing eCTD Sections

For new applications (including generic applications), detailed statements
justifying the absence of data or specific eCTD sections should be provided in the
relevant Quality Overall Summary and/or Non-Clinical/Clinical Overviews (Module
2.3, 2.4, 2.5).
Sep 2015
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.
Note: for a generic application, there is no need to provide a justification for

content that is typically absent.
2.4. Technical information

2.4.1. 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. Currently however, the use of digital signatures for
electronic submissions within GCC is not fully supported and digital signatures
should therefore not be used (Please refer to each national competent authority for
detailed guidance on this matter).
2.4.2. Security issues
The physical security of the submission during transportation is the responsibility

of the applicant. Once received by national competent authority, security and
submission integrity is the sole responsibility of the national competent authority.
2.4.3. Virus protection
The applicant is responsible for checking the submission for viruses. Checking
should be performed with an up-to-date virus checker and be confirmed in the cover
letter.
2.4.4. Password protection
Submission or file level security is not permitted. If one-time security settings or

password protection of electronic submissions are used this could constitute grounds
for the rejection of the submission.
2.5. General Architecture of Module 1

The GCC 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
Sep 2015
valid XML document according to the GCC Regional Document Type Definition
(DTD). The backbone instance (the gc-regional.xml file) contains meta-data for
the leaves, including pointers to the files in the directory structure. In addition, the
GCC Regional DTD defines meta-data at the submission level in the form of an
envelope. The root element is "gc-backbone" and contains two elements: "gc-
envelope" and "m1-gc".
The GCC Regional DTD is modularized i.e. the envelope and leaves are
referenced from the main part of the DTD as external entities called respectively
"gc-envelope.mod" and "gc-leaf.mod". The "gc-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 GCC Regional DTD can be found
in Appendix 4 of this specification.
2.5.1. Checksum
 GCC Module 1 v1.1 checksum for “gc-regional.dtd” is:

0854a8d0c5fcc0a82d2da9cc9105bc41
 GCC Module 1 v1.1 checksum for “gc-envelope.mod” is:

d2fd2c8469705ff4176fdfee27479a6c
 GCC Module 1 v1.1 checksum for “gc-leaf.mod” is:

f131823f73b74c4c8d16291d02643bec
 GCC Module 1 v1.1 checksum for “gc-regional.xsl” is:

4f47ec90c63f45b50639c1d10c5efd00
Note : See “checksum.pdf” for complete hash values
2.5.2. Envelope
The "gc-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.
Sep 2015
2.5.3. XML Catalogue
The “m1-gc” element of the GCC 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-gc” element maps to the directory
structure. (There may at times be what is seen to be a 'redundant' directory structure,
but this is necessary in order to be able to use the same file/directory structure for all
procedures.)
2.5.4. Directory / File Structure
The GCC Module 1 Specification provides the directory and file structure (see
Appendix 2).
2.5.5. File Naming Convention
The eCTD file naming conventions described in the ICH M2 eCTD Specification
and this document are highly recommended. If an applicant wishes to submit multiple
files in one section, where only one highly recommended name is available, this can
be achieved using a suffix to the filename,
File names have fixed and variable components. Components are separated by a
hyphen. No hyphens or spaces should be used within each component.
Fixed components are mandatory. 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 without separation 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 must be the country code as per Appendix 5
except when the document is valid for all countries within the particular procedure.
The second component must be the document type code. The third component if
necessary should be the variable component.
Sep 2015
There are no recommendations for variable components in this specification. The
format of the file is indicated by the file extension. File names must always be in
lowercase, in line with the ICH eCTD specification.
Examples are:
sa-cover.pdf (Saudi Arabia)
ae-cover.pdf (UAE)
bh-cover.pdf (Bahrain)
kw-cover.pdf (Kuwait)
qa-cover.pdf (Qatar)
ye-cover.pdf (Yemen)
sa-form.pdf (Saudi Arabia)
om-form.pdf (Oman)
2.6. Business protocol

The detailed business process between industry and the GCC will form part of the
Industry Guidance for eCTDs. For some period of time the exchange of regulatory
information will take place through exchange of physical media such as CD/DVD-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 (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. The GCC will acknowledge the proper receipt and result of the validation process
(technical [e.g. virus check, XML check, etc.] and content based) to the Sponsor
or Agent that submitted the eCTD.
2.7. Change control

The GCC 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
Sep 2015
 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.
2.8. Instructions for Extension Submissions

Several dosage forms, routes of administration or different strengths can be
managed within a single eCTD application, and this helps avoid submission of data
multiple times (e.g. active substance changes). Submissions for an extension can
either be submitted within an existing eCTD application, as a new sequence
(continuous sequence numbering), or as a new eCTD application (sequence 0000),
depending on the procedure.
For Extension submission, only new data must be submitted as a new sequence in
the already submitted eCTD. The submission type has to be “extension”.
If single eCTDs are used for each strength or form of a product, full data
concerning the extension applied for has to be included in the submitted eCTD and
therefore clear information should be given to the assessor on what is new compared
to earlier submitted data for the product to avoid unnecessary assessment.
2.9. Reformatting
To support the reformatting of an existing submission application from any
format to eCTD, i.e. a baseline eCTD submission containing no content change and
which will not be subject to review, the submission unit type ‘reformat‘ should be
used in the envelope. This type will always be used together with the submission type
‘none’.
Sep 2015
APPENDIX
Appendix 1: Envelope Element Description
The “gc-envelope” element is the root element that defines meta-data of the
submission. This element may contain several envelope entries.
Element Attribute Description/Instructions Example Constraint Occurrence

Root element that provides
meta-data for the submission.
gc-envelope This element may contain Mandatory Unique
several envelopes, which are
country specific.
This element must be country
envelope country sa Mandatory Unique
specific (See appendix 5)
This is the number issued for
the sponsor and the product by
application the GCC and remains for the Mandatory Unique
full lifecycle of the product
from the first data submission
The name of the company
applicant SAFarma Mandatory Unique
submitting the eCTD
Parent element for the
Agency code identification of the receiving SA-SFDA
agency (See appendix 5)
ATC Pick list ATC code Repeatable
Provides administrative
information associated with Mandatory Unique
submission the submission.
type See appendix 5 new-nce Mandatory Unique
Describes actions within the
regulatory activity like initial
submission, update, responses
to questions, any additional Mandatory Unique
submission-unit information or consolidation
submissions respectively when
closing a regulatory activity.
type See appendix 5 reformat Mandatory Unique
procedure See appendix 5 national Mandatory Unique
The name of the medicinal Dawa
invented-name Mandatory Repeatable
product
International Non-proprietary
Name, used to identify
pharmaceutical substances or
active pharmaceutical
ingredients. Each INN is a
inn Allopurinol Optional Repeatable
unique name that is globally
recognized and is public
property. A nonproprietary
name is also known as a
generic name.
Sep 2015
This is the sequence number of 0000
the submission – this should
start at 0000 for the initial
submission, and then increase
sequence incrementally with each Mandatory Unique
subsequent submission
related to the same product
e.g. 0000, 0001, 0002, 0003
etc.
This is the sequence number of
a previous submission to
related-sequence which this submission relates 0001 Optional Repeatable
e.g. the responses to questions
to a particular variation.
submission- This element is used to briefly
Mandatory Unique
description describe the submission
This is any number, used by an
agency or the applicant to
number track the submission, in any Optional Repeatable
procedure, in relation to a
particular product.
Example of the use of the Related Sequence:
The related sequence number describes the relationship of additional information

to the original submission or subsequent submissions.
An illustration of how the related sequence number is used to describe the

relationship of additional information to the original and subsequent submissions
follows.
Sep 2015
Example of how the Related Sequence should be used:
Submission Related
Sequence Comment
Description Sequence
Application for New This is a new regulatory submission and so no related
0000 <none>
Generic application sequence is included
Responses to Section This is continued activity for the regulatory submission
0001 31 for New Generic 0000 initiated in 0000 and so the related sequence points to
application the beginning of that submission
Updated information This is the completion of the regulatory activity for this
0002 for New Generic 0000 submission initiated in 0000 and so the related
application sequence points to the beginning of that submission
Application for
EXTENSION OF
This is the beginning of a new regulatory submission
0003 INDICATION (EOI) <none>
and so no related sequence is included
for the approved
product
Responses Section 31
This is continued activity for the regulatory submission
for the change in
0004 0003 initiated in 0003 and so the related sequence points to
manufacturing site for
the beginning of that submission
the approved product
Responses to CLIN This is continued activity for the regulatory submission
0003
0005 Section 31 EOI for the initiated in 0003 and so the related sequence points to
approved product the beginning of that submission
Sep 2015
Appendix 2: Directory/File Structure for GCC 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

number reference number. These reference numbers can change with
each version of this appendix.
Number CTD section number
Title CTD title
Element Element name in the GCC Backbone
File/Directory File/Directory name from m1-gc should be relative path
from gc-m1 e.g. 12-form/gc/sa-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
The names of the actual files and directories used should be presented in lower
case in accordance with the eCTD specification. The codes “VAR” and “EXT”
represent a variable component of the file name and a representation of a file
extension respectively. The use of upper case for those codes is for illustrative
purposes only to show differentiation between the variable parts and the fixed part of
the name.
Please note that “CC” represents the country code and “LL” the language code. It
is added to a directory if a file is specific to a country. If the file applied to all GCC
countries, “CC” will be “common”.
1 Number
Title GCC Module 1
Element m1-gc
Directory m1/gc
Comment Top level directory for the GCC Module 1 as per ICH eCTD
Specification
2 Number
Title GCC Module 1 – DTD version 1.0
Element
File m1/gc/gc-regional.xml
Comment The GCC Regional XML instance including the envelope
information. Note that the operation attribute for the gc-
regional.xml should always be set to ‘new’
Sep 2015
3 Number 1.0
Title Cover letter
Element m1-0-cover
Directory m1\gc\10-cover
Comment General place holder for cover letter information
If there is a special cover letter from specific agency, please
add the country and language to the directory
m1\gc\10-cover\CC\LL.
4 Number
Title Cover letter for SFDA
Element m1-0-cover
Directory m1\gc\10-cover
File CC-cover-VAR.EXT
Comment Example for the cover letter is specific for (SFDA) in Saudi
Arabia, the placeholder will be m1\gc\10-cover\sa\sa-cover.pdf
5 Number 1.1
Title Module 1 table of contents
Element m1-1-table-of-contents
Directory 0000
Comment The table of contents should include a list of all documents
provided in the data submission by module.
In eCTD, the xml backbone replaces the table of contents
0000\index.xml
6 Number 1.2
Title Application form
Element m1-2-application-form
Directory m1\gc\12-form
File CC-form-VAR.EXT
Comment General place holder for application form information.
7 Number 1.3
Title Product Information
Element m1-3-product-information
Directory m1\gc\13-pi
Comment General placeholder for Product Information
8 Number 1.3.1
Title Summary of Product Characteristics (SPC)
Element m1-3-1-spc
Directory m1\gc\13-pi\131-spc
File CC-spc-VAR.EXT
Comment General placeholder for SPC.
English SPC the directory is m1\gc\13-pi\131-spc\CC\en
Sep 2015
9 Number 1.3.2
Title Labeling
Element m1-3-2-label
Directory m1\gc\13-pi\132-labeling
File CC-label-VAR.EXT
Comment General placeholder for labeling
The directory is m1\gc\13-pi\132-labeling\CC\LL
10 Number 1.3.3
Title Patient information leaflet
Element m1-3-3-pil
Directory m1\gc\13-pi\133-leaflet
Comment General placeholder for Patient information leaflet
11 Number 1.3.3.1
Title Arabic Patient information leaflet
Element m1-3-3-pil
Directory m1\gc\13-pi\133-leaflet\CC\ar
File CC-leaflet-VAR.EXT
Comment Document in Arabic
12 Number 1.3.3.2
Title English Patient information leaflet
Element m1-3-3-pil
Directory m1\gc\13-pi\133-leaflet\CC\en
Comment Document in English
13 Number 1.3.4
Title Artwork (mock-ups)
Element m1-3-4-mockup
Directory m1\gc\13-pi\134-artwork\CC\LL
File CC-artwork-VAR.EXT
Comment Artwork or Mock-ups
14 Number 1.3.5
Title Samples
Element m1-3-5-samples
Directory m1\gc\13-pi\135-samples\CC\LL
File CC-samples-VAR.EXT
Comment Samples
15 Number 1.4
Title Information on the Experts
Element m1-4-expert
Directory m1\gc\14-expert
Comment
Sep 2015
16 Number 1.4.1
Title Quality
Element m1-4-1-quality
Directory m1\gc\14-expert\141-quality
File quality-VAR.EXT
Comment
17 Number 1.4.2
Title Non clinical
Element m1-4-2-non-clinical
Directory m1\gc\14-expert\142-nonclinical
File nonclinical-VAR.EXT
Comment
18 Number 1.4.3
Title Clinical
Element m1-4-3-clinical
Directory m1\gc\14-expert\143-clinical
File clinical-VAR.EXT
Comment
19 Number 1.5
Title Environmental Risk Assessment
Element m1-5-environrisk
Directory m1\gc\15-environrisk
Comment
20 Number 1.5.1
Title Non-GMO
Element m1-5-1-non-gmo
Directory m1\gc\15-environrisk\151-nongmo
File nongmo-VAR.EXT
Comment
21 Number 1.5.2
Title GMO
Element m1-5-2-gmo
Directory m1\gc\15-environrisk\152-gmo
File gmo-VAR.EXT
Comment
22 Number 1.6
Title Pharmacovigilance
Element m1-6-pharmacovigilance
Directory m1\gc\16-pharmacovigilance
Comment
Sep 2015
23 Number 1.6.1
Title Pharmacovigilance System
Element m1-6-pharmacovigilance-system
Directory m1\gc\16-pharmacovigilance\161-phvig-system
File phvigsystem-VAR.EXT
Comment
24 Number 1.6.2
Title Risk Management Plan
Element m1-6-2-risk-management-system
Directory m1\gc\16-pharmacovigilance\162-riskmgt-system
File riskmgtsystem-VAR.EXT
Comment
25 Number 1.7
Title Certificates and Documents
Element m1-7-certificates
Directory m1\gc\17-certificates
Comment
26 Number 1.7.1
Title GMP Certificate
Element m1-7-1-gmp
Directory m1\gc\17-certificates\171-gmp
File CC-gmp-VAR.EXT
Comment
27 Number 1.7.2
Title CPP or Free-sales
Element m1-7-2-cpp
Directory m1\gc\17-certificates\172-cpp
File CC-cpp-VAR.EXT
Comment
28 Number 1.7.3
Title Certificate of analysis – Drug Substance / Finished Product
Element m1-7-3-analysis-substance
Directory m1\gc\17-certificates\173-analysis-substance
File CC-drugsubstance-VAR.EXT
Comment
29 Number 1.7.4
Title Certificate of analysis – Excipients
Element m1-7-4-analysis-excipients
Directory m1\gc\17-certificates\174-analysis-excipients
File CC-excipients-VAR.EXT
Comment
Sep 2015
30 Number 1.7.5
Title Alcohol-content declaration
Element m1-7-5-alcohol-content
Directory m1\gc\17-certificates\175-alcohol-content
File CC-alcoholcontent-VAR.EXT
Comment
31 Number 1.7.6
Title Pork-content declaration
Element m1-7-6-pork-content
File CC-porkcontent-VAR.EXT
Directory m1\gc\17-certificates\176-pork-content
Comment
32 Number 1.7.7
Title Certificate of suitability for TSE
Element m1-7-7-certificate-tse
Directory m1\gc\17-certificates\177-certificate-tse
File CC-tse-VAR.EXT
Comment
33 Number 1.7.8
Title The diluents and coloring agents in the product formula
Element m1-7-8-diluent-coloring-agents
Directory m1\gc\17-certificates\178-diluent-coloring-agents
File CC-diluent-VAR.EXT
Comment
34 Number 1.7.9
Title Patent Information
Element m1-7-9-patent-information
Directory m1\gc\17-certificates\179-patent-information
File CC-patent-VAR.EXT
Comment
35 Number 1.7.10
Title Letter of access or acknowledgements to DMF
Element m1-7-10-letter-access-dmf
Directory m1\gc\17-certificates\1710-letter-access-dmf
File CC-accessdmf-VAR.EXT
Comment
36 Number 1.8
Title Pricing
Element m1-8-pricing
Directory m1\gc\18-pricing
Comment
Sep 2015
37 Number 1.8.1
Title Price list
Element m1-8-1-price-list
Directory m1\gc\18-pricing\181-price-list
File CC-price-VAR.EXT
Comment
38 Number 1.8.2
Title Other documents related
Element m1-8-2-other-document
Directory m1\gc\18-pricing\182-other-doc
File CC-others-VAR.EXT
Comment
39 Number 1.9
Title Responses to questions
Element m1-9-responses
Directory m1\gc\19-responses\CC
File CC-responses-VAR.EXT
Comment
40 Number m1-additional-data
Title Additional data
Element m1-additional-data
Directory m1\gc\additional-data\CC
File CC-additionaldata-VAR.EXT
Comment Any additional data requested should be put on this place such
as documents that don’t really fit in any other sections (transfer
agreement, declaration of conformity of translation, etc.)
Sep 2015
Appendix 3: Country Specific Elements
A number of the elements that represent Module 1 TOC headings possess the
child element “specific”, which allows country specificity of content to be
explicitly indicated.
Module 1 elements that have “specific” child elements can therefore contain
multiple documents, each with content for review by a different country in the Gulf
Cooperation countries. These elements are listed below:

Parent element for identifying
Specific the receiving country for a Mandatory Repeatable
document or documents.
The receiving country for the
country sa Mandatory Unique
document (see appendix 5)
Sep 2015
Appendix 4: Example Screenshot
This appendix is included only to demonstrate how the directory structure may
appear for Module 1 for Gulf Cooperation Council (GCC).
Sep 2015
Appendix 5: List of codes
GCC Agencies (in alphabetic order)
Country Code agency Description

Bahrain BH-MOH Ministry of Health
Kuwait KW-MOH Ministry of Health
Oman OM-MOH Ministry of Health
Qatar QA-NHA National Health Authority
Republic of Yemen YE-MOPH Ministry of Public Health and Population
Saudi Arabia SA-SFDA Saudi Food and Drug Authority
UAE AE-MOH Ministry of Health
Procedure
Type Description
gcc GCC procedure
national National procedure
Submission
Type Description
Asmf Active Substance Master File
extension Extension Submission*
new-bio MAA - Biological
new-gen MAA - Generic (Multisource)
new-nce MAA - New chemical Entity
new-rad MAA - Radiopharmaceuticals
None In the exceptional case of reformatting the application no
regulatory activity is allowed. Therefore, ‘none’ must be
stated. The submission unit will identify the sub-activity
related to the product.
new-her MAA - New Herbal
new-hea MAA - New Health
new-vet MAA - New vet
pmf Plasma Master File
psur Periodic Safety Update Report
psusa PSUR single assessment procedure
renewal Renewal of Marketing Authorization
rmp Risk Management Plan
transfer-ma Transfer of Marketing Authorization
usr Urgent Safety Restriction
var-type1 Variation Type 1
Sep 2015
var-type2 Variation Type 2
withdrawal Withdrawal
*consult your local regulatory authority before submission
Submission unit
Type Description
additional-info Other additional Information (could include, for example,
missing files) and should only be used, if response is not
suitable
closing Submission unit that provides the final documents in the
GCC procedure following the decision of the GCC
committee
correction Correction to the published annexes in the GCC procedure
(usually shortly after approval)
initial Initial submission to start any regulatory activity
reformat Intended to support the reformatting of an existing
submission application from any format to eCTD, i.e. a
baseline eCTD submission containing no content change
and which will not be subject to review. This type will
always be used together with the submission type ‘none’
response Submission unit that contains the response to any kind of
question, validation issues out-standing information
requested by the agency
DESTINATION
In most cases the destination code is an ISO-3166-1 code usually called “country
code”.
Country code Destination

AE State of United Arab Emirates
BH Kingdom of Bahrain
KW State of Kuwait
OM Sultanate of Oman
QA State of Qatar
SA Saudi Arabia
YE Republic of Yemen
Note: Use “common” as country code when the submission applies to all countries.
LANGUAGE
Language Description
ar Arabic (when required)
en English
Sep 2015
Appendix 6: Modularized DTD for GCC Module 1
GCC Regional DTD


<!ENTITY % countries "(ae|common|bh|kw|om|qa|sa|ye)">
<!ENTITY % languages "(en|ar)">
<!ENTITY % leaf-node "(( leaf | node-extension )*)">
<!ENTITY % envelope-module SYSTEM "gc-envelope.mod" >
%envelope-module;
<!ENTITY % leaf-module SYSTEM "gc-leaf.mod" >

%leaf-module;
<!ELEMENT specific (
%leaf-node;
)>
<!ATTLIST specific
country %countries; #REQUIRED
>

<!ELEMENT gc:gc-backbone (
gc-envelope,
m1-gc
)>
<!ATTLIST gc:gc-backbone
xmlns:gc CDATA #FIXED "http://sfda.gov.sa"
Sep 2015
xmlns:xlink CDATA #FIXED
"http://www.w3c.org/1999/xlink"
xml:lang CDATA #IMPLIED
dtd-version CDATA #FIXED "1.1"
>

<!ELEMENT m1-gc (
m1-0-cover,
m1-2-form?,
m1-3-pi?,
m1-4-expert?,
m1-5-environrisk?,
m1-6-pharmacovigilance?,
m1-7-certificates?,
m1-8-pricing?,
m1-9-responses?,
m1-additional-data?
)>

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

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

<!ELEMENT m1-3-pi (
m1-3-1-spc?,
m1-3-2-label?,
m1-3-3-pil?,
m1-3-4-mockup?,
m1-3-5-samples?
)>
<!ELEMENT m1-3-1-spc (
pi-doc+
)>
<!ELEMENT m1-3-2-label (
pi-doc+
)>
<!ELEMENT m1-3-3-pil (
pi-doc+
)>
<!ELEMENT m1-3-4-mockup (
specific+
Sep 2015
)>
<!ELEMENT m1-3-5-samples (
specific+
)>
<!ELEMENT pi-doc (
%leaf-node;
)>
<!ATTLIST pi-doc
xml:lang %languages; #REQUIRED
type (spc|label|pil) #REQUIRED
country %countries; #REQUIRED
>

<!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-environrisk (
(m1-5-1-non-gmo | m1-5-2-gmo)?
)>
<!ELEMENT m1-5-1-non-gmo %leaf-node;>
<!ELEMENT m1-5-2-gmo %leaf-node;>

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

<!ELEMENT m1-7-certificates (
m1-7-1-gmp?,
m1-7-2-cpp?,
m1-7-3-analysis-substance?,
m1-7-4-analysis-excipients?,
m1-7-5-alcohol-content?,
m1-7-6-pork-content?,
Sep 2015
m1-7-7-certificate-tse?,
m1-7-8-diluent-coloring-agents?,
m1-7-9-patent-information?,
m1-7-10-letter-access-dmf?
)>
<!ELEMENT m1-7-1-gmp %leaf-node;>
<!ELEMENT m1-7-2-cpp %leaf-node;>
<!ELEMENT m1-7-3-analysis-substance %leaf-node;>
<!ELEMENT m1-7-4-analysis-excipients %leaf-node;>
<!ELEMENT m1-7-5-alcohol-content %leaf-node;>
<!ELEMENT m1-7-6-pork-content %leaf-node;>
<!ELEMENT m1-7-7-certificate-tse %leaf-node;>
<!ELEMENT m1-7-8-diluent-coloring-agents %leaf-node;>
<!ELEMENT m1-7-9-patent-information %leaf-node;>
<!ELEMENT m1-7-10-letter-access-dmf %leaf-node;>

<!ELEMENT m1-8-pricing (
m1-8-1-price-list?,
m1-8-2-other-document?
)>
<!ELEMENT m1-8-1-price-list %leaf-node;>
<!ELEMENT m1-8-2-other-document %leaf-node;>

<!ELEMENT m1-9-responses (
specific+
)>

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

Sep 2015
GCC Envelope


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

<!ELEMENT application ( number* )>
<!ELEMENT applicant ( #PCDATA )>
<!ELEMENT agency EMPTY>
<!ELEMENT atc ( #PCDATA )>
<!ELEMENT submission EMPTY>
<!ELEMENT submission-unit EMPTY>
<!ELEMENT procedure EMPTY>
<!ELEMENT invented-name ( #PCDATA )>
<!ELEMENT inn ( #PCDATA )>
<!ELEMENT sequence ( #PCDATA )>
<!ELEMENT related-sequence ( #PCDATA )>
<!ELEMENT submission-description ( #PCDATA )>
<!ELEMENT number ( #PCDATA )>

<!ATTLIST agency code (
AE-MOH
| BH-MOH
| KW-MOH
Sep 2015
| OM-MOH
| QA-NHA
| SA-SFDA
| YE-MOPHP
) #REQUIRED>

<!ATTLIST procedure type (
gcc
| national
) #REQUIRED>

<!ATTLIST submission type (
asmf
| extension
| new-gen
| new-nce
| new-bio
| new-rad
| none
| new-her
| new-hea
| new-vet
| pmf
| psur
| psusa
| renewal
| rmp
| transfer-ma
| usr
| var-type1
| var-type2
| withdrawal
) #REQUIRED>

<!ATTLIST submission-unit type (
initial
| response
| additional-info
| closing
| correction
| reformat
) #REQUIRED>

<!ENTITY % env-countries "(ae|common|bh|kw|om|qa|sa|ye)">
Sep 2015

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

GCC Leaf


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

<!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
Sep 2015
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
'>
<!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
>

Sep 2015
Annex 1:
What's New in the GCC Module 1 Specifications (Version 1.4)?
New Capabilities
The concept of “submission unit” is introduced as currently implemented by the

FDA. The existing attribute of the “submission type” will then solely describe a
regulatory activity.
The “submission unit” will describe actions within that regulatory activity like an
initial submission of an application, responses to questions from agencies or any
additional information.
In the same way “reformat” will be used as a submission unit together with
submission type “none” as it is not a regulatory activity, but just a reformatting of the
dossier.
1. Corrected Issues
 Change of some PDF criteria Pass/Fail to Best Practices
 Remove the term ‘EOI’ from Glossary
2. Changes in this new release

Elements Description
Hyperlink and bookmark
http://estri.ich.org Point to the new link of ICH website
ICH eCTD Specification Point to the new link of ICH website
Appendix 2 Modification of the bookmark
Glossary
EOI Remove the term from Glossary
Terms Add new terms
Controlled Vocabularies
Submission type CVs Remove ‘responses’ from the controlled vocabularies
list
Submission unit CVs Add the concept of submission unit type.
Checksum values
checksum Modified the checksum values following the
modification of the Module 1 DTD, envelope, stylesheet
Sections
2.8. Instructions for Extension Corrected the text
Submissions
2.9. Reformatting Add this new section for ‘reformat’
Appendix 1 Add of submission unit type
Add example for the element ‘procedure’
Modified the constraint of Element ‘number’ in optional
Appendix 5: List of codes Add submission type codes
Add submission unit type codes
Envelope, DTD, Stylesheet Minor modifications due to new controlled vocabularies
Validation criteria
submission unit type for Added to Best practices (BP)
"additional-info" and "correction"
All PDF bookmarks are relative Added to BP
All Bookmarks are set in "inherit Added to BP
zoom"
Fast Web View active Added to BP
Sep 2015
Hyperlinks and Bookmarks have a Added to BP
valid target
Submission unit type Added to Pass/Fail
‘reformat‘ should be used with
submission type ‘none’
Sep 2015

GCC - Module - 1 - SpecificationVersion 1.4

Uploaded by

Copyright:

Available Formats

GCC - Module - 1 - SpecificationVersion 1.4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GCC - Module - 1 - SpecificationVersion 1.4

Uploaded by

Copyright:

Available Formats

What is the vision and mission of the Saudi Food & Drug Authority?

What is the vision and mission of the Saudi Food & Drug Authority?

What are the main changes in Version 1.4 of the GCC Module 1 Specifications?

What are the main changes in Version 1.4 of the GCC Module 1 Specifications?

GCC Module 1

Please visit SFDA’s website at

For Inquiries: [email protected]

For Comments or Suggestions: [email protected]

Vision & Mission

0.4 03/12/2011 Regulatory Affairs Final revision

1.0 17/12/2011 Regulatory Affairs Published

1.1 08/05/2012 Regulatory Affairs Revised document

1.2 10/11/2012 Regulatory Affairs Minor changes, checksum update

1.3 17/08/2015 Regulatory Affairs Add of submission unit concept, Add

Note: For most recent update please refer to annex 1

This document specifies Module 1 of the electronic Common Technical Document

1.3. Technical Requirements

 Copying and pasting

1.4. Change Control

 Change in the content of the CTD, either through the amendment of

Applicant A pharmaceutical company or its agent that is submitting

It should be noted that for subsequent submissions in the lifecycle of a medicinal

This document describes only the region-specific information that is common to

2.1. General Considerations

2.1.1 Document granularity

2.1.3 Sequence Numbers

Additional details on creating bookmarks and hypertext links in PDF documents

2.2. Regional File Formats

These documents, if requested, should not be referenced in the eCTD backbone,

Document File Format Remark

2.3. Handling of Empty or Missing eCTD Sections

Note: for a generic application, there is no need to provide a justification for

2.4. Technical information

The use of advanced electronic signatures (digital signatures) will be crucial in

2.4.2. Security issues

The physical security of the submission during transportation is the responsibility

2.4.3. Virus protection

2.4.4. Password protection

Submission or file level security is not permitted. If one-time security settings or

2.5. General Architecture of Module 1

 GCC Module 1 v1.1 checksum for “gc-regional.dtd” is:

 GCC Module 1 v1.1 checksum for “gc-envelope.mod” is:

 GCC Module 1 v1.1 checksum for “gc-leaf.mod” is:

 GCC Module 1 v1.1 checksum for “gc-regional.xsl” is:

Note : See “checksum.pdf” for complete hash values

The "gc-envelope" element is designed to be used for all types of

2.5.4. Directory / File Structure

2.5.5. File Naming Convention

2.6. Business protocol

1. The actual submission of the physical media on which the application is

2.7. Change control

2.8. Instructions for Extension Submissions

Element Attribute Description/Instructions Example Constraint Occurrence

Example of the use of the Related Sequence:

The related sequence number describes the relationship of additional information

An illustration of how the related sequence number is used to describe the

Sequential Each item in the table has a unique sequentially assigned

Element Attribute Description/Instructions Example Constraint Occurrence

GCC Agencies (in alphabetic order)