Egypt’s Draft EG Module 1 eCTD Specification: What Regulatory Teams Need to Know

REGULATORY INTELLIGENCE • EGYPT • eCTD

A practical overview of Version 1.0/2026 and what the proposed Egypt-specific eCTD structure means for Regulatory Affairs teams.

Key message: EG Module 1 defines how Egypt-specific administrative and regulatory information should be structured, identified and maintained within the eCTD lifecycle.

Introduction

As part of Egypt’s move toward eCTD, the Egyptian Drug Authority (EDA) has developed a dedicated EG Module 1 eCTD Specification – Version 1.0/2026.

Unlike Modules 2–5, which follow the common ICH CTD structure, Module 1 contains Egypt-specific administrative and regulatory information.

The specification explains how this information should be technically structured inside an Egyptian eCTD submission, including the XML backbone, metadata, folder structure, file naming, submission identifiers and the exact location of Module 1 documents.

So, what does this specification actually mean for Regulatory Affairs teams?

What Is EG Module 1?

The simplest way to understand it is:

ICH tells us how the global eCTD is structured. EG Module 1 tells us how the Egyptian part of that eCTD should be structured.

EDA states that the EG Module 1 Specification should be read together with the ICH eCTD Specification when preparing a valid eCTD submission for Egypt.

It therefore goes beyond identifying which documents belong in Module 1. It defines how those documents should be:

Structured → Named → Identified → Linked → Tracked → Maintained

1. Egypt Will Have Its Own Module 1 Structure

EG Module 1 will have its own regional architecture.

The structure includes:

eg-regional.xml → eg-envelope → m1-eg → documents

The eg-regional.xml file acts as the Egyptian XML backbone. It contains metadata and links to the documents included in Module 1.

In simple terms, documents are no longer only stored in folders. The eCTD structure also needs to understand what each document is, where it belongs and what regulatory activity it relates to.

2. The Envelope Becomes a Key Part of Every Submission

The EG Envelope contains the high-level metadata that describes the submission.

This includes information such as:

• Submission type

• Submission mode

• Procedure tracking number

• Submission unit

• Applicant

• Agency

• Product information

• Sequence

• Related sequence

The agency code defined for the Egyptian Drug Authority is:

EG-EDA

The procedure tracking number is also used to connect the submission with the relevant regulatory procedure and is issued through the EDA portal.

3. Sequence and Related Sequence Must Be Managed Correctly

Every submission becomes part of the product’s eCTD lifecycle.

Sequence numbers progress as:

0000 → 0001 → 0002 → 0003...

But the sequence number alone is not enough.

The Related Sequence identifies the regulatory activity to which a subsequent submission belongs.

For example:

0000 — Original MAA

0001 — Response to questions related to 0000

0002 — Further response related to 0000

Although the sequence number continues to increase, the Related Sequence keeps the different submissions connected to the regulatory activity that originally started them.

This is one of the most important lifecycle concepts Regulatory Affairs teams will need to understand.

4. Baseline Submissions Have a Defined Technical Structure

For products transitioning from an existing format into eCTD, the specification provides a defined approach for the baseline.

The baseline covering Modules 1–5 is submitted using:

Submission Type: none

Submission Unit Type: reformat

For example:

Sequence 0000 → Baseline → Reformat

The next new regulatory activity would then begin in the following sequence.

This creates a technical starting point for managing the existing dossier within the new eCTD lifecycle.

5. File Naming Will Follow Defined Rules

File naming will no longer be arbitrary.

The general proposed structure is:

FIXED-VAR.EXT

The fixed component identifies the type of document, while the optional variable component can provide additional useful information.

• Be lowercase

• Contain no spaces

• Use hyphens where needed

• Remain short and descriptive

Examples provided in the specification include:

cover.pdf • form-eaf.pdf • outer-tablet10mg.pdf

The overall file path starting from the sequence number must also not exceed 180 characters.

This means file naming and document placement become part of technical submission compliance.

6. Empty Sections Should Stay Empty

The specification also addresses what happens when an eCTD section has no applicable content.

Placeholder documents such as “Not Applicable” or “No Relevant Content” should generally not be added just to fill an empty section.

Instead, the section should remain empty, with justification provided where required.

Why? Because adding unnecessary placeholder documents creates a document lifecycle that then has to be maintained in future sequences.

7. Previously Submitted Documents Should Not Simply Be Submitted Again

During lifecycle management, documents already submitted in a previous sequence should generally not be submitted again just because they remain valid.

Instead, the eCTD lifecycle should be used to reference information that already exists in earlier sequences.

This is one of the fundamental differences between ordinary electronic folders and a true eCTD lifecycle.

8. Every eCTD Lifecycle Will Have a Unique UUID

The specification introduces another important technical identifier: UUID – Universal Unique Identifier.

Each eCTD lifecycle must have its own unique UUID.

The UUID should be machine-generated and remain the same throughout all sequences belonging to that particular lifecycle.

EDA uses the UUID to help associate incoming sequences with the correct eCTD application.

Sequence number = identifies the individual submission

UUID = identifies the eCTD lifecycle it belongs to

9. Module 1 Document Placement Is Precisely Defined

A major part of the specification is Appendix 2, which maps the complete Egyptian Module 1 directory and file structure.

Dedicated locations are defined for many regulatory documents, including:

• Application Forms and Legal Documents: manufacturing licences, GMP certificates, toll manufacturing licences, agreements and other legal documents.

• EDA Approvals: Registration Request Approval, Inquiry Approval, Name Approval, Registration Licence, Pricing Certificate, Inspection Report, Importation Approval, CADC Report, Stability Approval, Module 3 Approval, Variation Approvals and others.

• Declarations, Reference Documents, Composition, Certificates of Analysis, Post-Approval Changes, Pharmacovigilance, Inspection, Product Information and Specific Application Requirements.

The important point is:

These regulatory documents are not necessarily new. What is new is that each document now has a defined technical position within the Egyptian eCTD structure.

10. Product Information Has Its Own Language Structure

Product information will also follow a defined language structure.

The specification currently identifies:

ar → Arabic

en → English

For Module 1.3.1, documents should be placed in the appropriate language directory throughout the lifecycle.

Specific identifiers are also defined, such as:

spc → Summary of Product Characteristics

pl → Package Leaflet

Practical Checklist: What Exactly Is Included in Egypt’s Module 1?

Use this as a practical mapping checklist against the EDA EG Module 1 structure. Not every item applies to every product or submission; non-applicable sections should remain empty unless EDA requires a justification. The tracking table, however, is specified as accompanying the cover letter for submissions across all procedures.

Technical Entry Point

• EG regional XML: eg-regional.xml — includes the Egyptian envelope metadata and links to Module 1 documents.

• 1.0 Cover Letter.

• Tracking Table — included with the cover letter for all procedures.

1.2 Application Forms

• 1.2.1 Application Form.

1.2.2 Legal Documents

• 1.2.2.1 Letter of Attorney for Company Representative.

• 1.2.2.2 Manufacturing License and IDA License.

• 1.2.2.3 GMP Certificate(s) / Alternative Documents.

• 1.2.2.4 The Register of Trade.

• 1.2.2.5 Toll Manufacturer License.

• 1.2.2.6 Scientific Office License.

• 1.2.2.7 Importers Register License.

• 1.2.2.8 Store License.

• 1.2.2.9 Authorisation Letter / Agency Agreement.

• 1.2.2.10 Manufacturing Agreement.

• 1.2.2.11 Packaging Agreement.

• 1.2.2.12 Storage Agreement.

• 1.2.2.13 Other Agreements.

• 1.2.2.14 Termination / Waiver.

• 1.2.2.15 Tax Card.

• 1.2.2.16 List of Distributors.

• 1.2.2.17 IP Protection Law No. 82 of 2002 Commitment.

• 1.2.2.18 NEW local MA legal Agreement.

• 1.2.2.19 Letter of Authorisation for a new Applicant in Egypt.

• 1.2.2.20 PV Agreement between the MAH & the Service Provider.

• 1.2.2.21 GMP Certificate.

1.2.3 EDA Approvals

• 1.2.3.1 Registration Request Approval.

• 1.2.3.2 Inquiry Approval.

• 1.2.3.3 Name Approval.

• 1.2.3.4 Registration License.

• 1.2.3.5 Preliminary Approval.

• 1.2.3.6 Non-Reference Approval.

• 1.2.3.7 Exemption Approval.

• 1.2.3.8 Pricing Certificate.

• 1.2.3.9 Pharmacovigilance Approval.

• 1.2.3.10 Inspection Report.

• 1.2.3.11 Importation Approval for each API.

• 1.2.3.12 CADC Report.

• 1.2.3.13 Stability Study Approval.

• 1.2.3.14 Stability Protocol Approval.

• 1.2.3.15 Module 3 Approval.

• 1.2.3.16 Module 5 Approval.

• 1.2.3.17 Pre-approved letters from EDA concerning the product.

• 1.2.3.18 Variation Approvals.

• 1.2.3.19 Innovative Products Scientific Committee Approval.

• 1.2.3.20 Registration License for the Solvent.

1.2.4 Declarations

• 1.2.4.1 Declaration Letter stating the list of Registered & Under-Registration Products owned by the Toll Company.

• 1.2.4.2 Declaration Letter from the License Holder specifying the API Manufacturers.

• 1.2.4.3 Declaration Letter from the License Holder specifying the approved pack in Egypt.

• 1.2.4.4 Declaration Letter from the License Holder stating the Form of Bulk (Strips, Capsules, etc.).

• 1.2.4.5 Declaration Letter from the Manufacturer of the Active Substance to inform the Applicant in case of modification of the manufacturing process or specifications.

• 1.2.4.6 Declaration Letter from API Supplier.

• 1.2.4.7 Declaration Letter for Site Addition.

• 1.2.4.8 Declaration Letter from LH stating all Variations & Justification for the Change.

• 1.2.4.9 Other declarations requested by Egyptian Drug Authority.

• 1.2.4.10 List of the Countries where the Product is registered & marketed.

• 1.2.4.11 Ph. Eur. Certificate(s) of Suitability for TSE.

• 1.2.4.12 TSE/BSE Supplier Safety Declaration (if CEP not available).

• 1.2.4.13 Raw Materials Storage Responsibility Declaration (for local products).

• 1.2.4.14 Excipient/s Supplier Name & Origin.

• 1.2.4.15 Trade Name of the Albumin used as Stabilizer.

• 1.2.4.16 Albumin as Stabilizer Batch Release Certificate.

• 1.2.4.17 Plasma Derivative Supplier Safety and Efficacy Commitment.

• 1.2.4.18 No Change in physical Address and Product-related Processes Declaration.

• 1.2.4.19 Pack Type Declaration.

• 1.2.4.20 Insert Declaration Letter.

• 1.2.4.21 Site Master File Declaration.

• 1.2.4.22 Storage Temperature at 25 °C Declaration.

1.2.5 Reference Product Document / Compendial

• 1.2.5.1 The Reference Product Documents.

• 1.2.5.2 Scientific Reference (Trials & Literature).

• 1.2.5.3 Reference for the trade name change.

• 1.2.5.4 The latest recent Pharmacopeia.

1.2.6 Imported Products Documents

• 1.2.6.1 Certificate of Pharmaceutical Product (CPP).

• 1.2.6.2 List of Affiliates / Subsidiaries.

1.2.7 Reliance Documents

• 1.2.7.1 Sameness Letter.

• 1.2.7.2 Unredacted Assessment Report.

• 1.2.7.3 RRA Variation Application with Annexes.

• 1.2.7.4 Correspondences between the Applicant and the Reference Agency.

• 1.2.7.5 List of Changes after first MA issued from EMA or FDA.

• 1.2.7.6 Rejection or Amendment Reporting Commitment.

1.2.8 Composition Documents

• 1.2.8.1 Composition Certificate.

• 1.2.8.2 Specifications.

• 1.2.8.3 Any Composition Calculations.

• 1.2.8.4 Pellets / Premix Composition and Certificates.

• 1.2.8.5 Opadry / Coating Premix Composition.

• 1.2.8.6 Capsule Shell Composition.

• 1.2.8.7 Synonyms Evidence.

• 1.2.9 Certificate of Analysis.

1.2.10 Post Approval Changes Requirements

• 1.2.10.1 PAC Approval from the COO (Imported Products).

• 1.2.10.2 Summary of Change for Variation.

• 1.2.10.3 Justification of the proposed Post Approval Change.

• 1.2.10.4 Any additional Documents relevant to Variations.

• 1.2.11 Proof of Payment.

1.2.12 Analysis Requirements Documentation — Biological Products Only

• 1.2.12.1 Detailed Standard Operating Procedures (SOP).

• 1.2.12.2 Summary Protocol for Vaccines and Plasma-derived Medicinal Products.

1.2.13 Plasma-Derived Medicinal Products

• 1.2.13.1 Plasma Master File.

• 1.2.13.2 Certificate of Plasma Batch Release from Health Authority.

• 1.2.13.3 PMF Approval from Country of Origin.

• 1.2.14 Scientific Advice Report.

1.2.15 Documents Related to Pharmacovigilance

• 1.2.15.1 Latest valid PSMF Assessment Report / Confirmation E-mail of PSMF Document(s) Receival.

• 1.2.15.2 Updated Version of Summary of PSMF(s) / PSSF.

• 1.2.15.3 The latest PSUR(s) (or the ACO in Case of Renewal).

• 1.2.15.4 The most updated EU/Global/Core Risk Management Plan (RMP).

• 1.2.15.5 The Egyptian Display of EU-RMP / Global-RMP.

1.2.16 Documents Related to Inspection

• 1.2.16.1 Site Master File for all Manufacturers.

• 1.2.16.2 Latest Full Inspection Report(s) by SRA (past 3 years).

• 1.2.16.3 One completed Batch Manufacturing and Packaging Record.

• 1.2.16.4 List of any Recalls with Quality Defects (past 3 years), if found.

• 1.2.16.5 Any Warning Letter or equivalent regulatory action (production-line specific), if found.

• 1.2.16.6 Last Annual Product Quality Review.

• 1.2.16.7 Cold Chain Storage & Transportation Procedures including excursion allowed.

1.3 Product Information

• 1.3.1 SmPC, Labelling and Package Leaflet — use the appropriate language directory (Arabic or English).

• 1.3.2 Mock-up.

• 1.3.3 Specimen.

• 1.3.4 Consultation with Target Patient Groups.

• 1.3.5 Product Information already approved in the Member States.

• 1.3.6 Braille.

1.4 Information about the Experts

• 1.4.1 Quality.

• 1.4.2 Non-Clinical.

• 1.4.3 Clinical.

1.5 Specific Requirements for Different Types of Applications

• 1.5.1 Information for Bibliographical Applications.

• 1.5.2 Information for Generic, Hybrid or Bio-similar Applications.

• 1.5.3 (Extended) Data / Market Exclusivity.

• 1.5.4 Exceptional Circumstances.

• 1.5.5 Conditional Marketing Authorisation.

1.6 Environmental Risk Assessment

• 1.6.1 Non-GMO.

• 1.6.2 GMO.

Only one of sections 1.6.1 or 1.6.2 should contain content in a given sequence.

1.7 Information Relating to Orphan Market Exclusivity

• 1.7.1 Similarity.

• 1.7.2 Market Exclusivity.

1.8 Information Relating to Pharmacovigilance

• 1.8.1 Pharmacovigilance System.

• 1.8.2 Risk-management System.

• 1.9 Information Relating to Clinical Trials.

• 1.10 Information Relating to Paediatrics.

Additional EG Module 1 Sections

• Responses to Questions — m1/eg/responses.

• Additional Data — for required information not otherwise included in EG Module 1; do not use it to resubmit documents already submitted in earlier sequences.

• Utility files — DTD and style-sheet folders used by the eCTD technical structure.

Source: Egyptian Drug Authority, EG Module 1 eCTD Specification, Version 1.0/2026, Appendix 2 (Directory / File Structure for Module 1), pp. 29–78.

Why Does This Matter for Pharmaceutical Companies?

The EG Module 1 specification makes one point very clear:

Successful eCTD implementation requires much more than generating an XML file.

Companies will need reliable control over:

Document → Module 1 location → File name → Metadata → Regulatory activity → Sequence → Related sequence → Lifecycle

Regulatory Affairs, document management and eCTD publishing processes therefore need to work together much more closely.

A company may have the correct scientific and regulatory documents, but technical readiness also depends on how those documents are structured, named, identified and maintained throughout the product lifecycle.

How Can Companies Start Preparing?

Regulatory Affairs teams can begin reviewing their readiness in several important areas:

Module 1 document mapping: Identify where existing regulatory documents would fit within the proposed Egyptian Module 1 structure.

Document naming: Review whether current file-management practices can support the proposed naming conventions.

Metadata readiness: Assess how submission types, tracking numbers, submission units, sequences and Related Sequences will be controlled.

Lifecycle management: Ensure teams can identify current documents, historical documents, replaced documents and the regulatory activity associated with each submission.

Publishing capability: Assess whether systems and resources can generate the required XML backbone, envelope metadata, UUID and lifecycle operations.

Team readiness: Ensure Regulatory Affairs and supporting functions understand that eCTD is a lifecycle-management process, not simply dossier compilation.

Looking Ahead

EDA’s Technical Guidance for eCTD Submissions in Egypt explains how the proposed regulatory lifecycle should work.

The EG Module 1 eCTD Specification goes one level deeper and defines how the Egypt-specific part of that lifecycle should be technically constructed.

Together, these documents show that Egypt’s eCTD transition is not simply a move:

from paper to electronic documents.

It is a move:

from documents and folders → to structured, validated and lifecycle-managed regulatory information.

And that is the shift Regulatory Affairs teams should start preparing for now.

Official EDA Sources

• Egyptian Drug Authority (EDA), Draft EG Module 1 eCTD Specification, Version 1.0/2026.

• Egyptian Drug Authority (EDA), Draft Technical Guidance for eCTD Submissions in Egypt, Version 1/2026.

• ICH — Electronic Standards for the Transfer of Regulatory Information (ESTRI)

Status note: The EG Module 1 specification is Version 1.0/2026 and is currently provided in draft form; its cover does not specify an issue date or effective date.