EU eCTD Module 1: what to check before submission

Module 1 is regional and procedure-specific

EU eCTD Module 1 contains regional administrative information rather than the scientific content in Modules 2 to 5. The expected documents depend on the submission type, authorisation route, countries involved and whether product information changes.

A completeness check therefore needs submission context as well as a file list. It should not assume that every possible Module 1 section is required for every sequence.

Check the current technical baseline

The EU eSubmission programme publishes the current Module 1 specification, validation criteria, accepted file formats, implementation timeline and harmonised technical guidance. At this guide's review date, the programme identifies EU Module 1 specification v3.1.1 as mandatory from 1 December 2025.

Validate against the current published package rather than a locally saved checklist. Technical requirements and validation criteria can change independently of the substantive regulatory procedure.

• Confirm sequence type, procedure, countries and submission description.
• Check envelope and metadata values against the current specification.
• Confirm cover letter, application form and procedure-specific administrative documents.
• Map changed SmPC, labelling and package-leaflet documents to the correct regional sections.
• Run the current EU validation criteria and resolve errors before dispatch.

What Module 1 actually contains

The EU regional module is administrative, but "administrative" understates how much of a validation failure originates here. Section 1.0 carries the cover letter, 1.1 the comprehensive table of contents, and 1.2 the application form — the three documents an assessor opens first and the three most likely to contradict each other.

Section 1.3 holds the product information: the summary of product characteristics, labelling, package leaflet, and mock-ups or specimens where required. For multi-country procedures this is also where the volume lives, because national translations and country-specific annexes multiply the file count quickly.

The remaining sections are conditional, and that conditionality is the point. Information about the experts sits in 1.4; specific requirements for particular application types in 1.5; the environmental risk assessment in 1.6; orphan market exclusivity in 1.7; pharmacovigilance, including the summary of the pharmacovigilance system and the risk management plan, in 1.8; clinical trial information in 1.9; and paediatric information in 1.10.

Whether each applies depends on the procedure, the legal basis of the application, the product type and the countries involved. A checklist that marks every section as required produces false findings; one that marks them all optional produces silence where a real gap exists. The applicability decision is the work.

Where the contradictions usually are

Technical validation is largely mechanical, and so are most of the failures it catches. The recurring pattern is not a missing document — it is the same fact stated differently in three places.

The application form, the cover letter and the eCTD envelope all carry procedure and product metadata, and they are typically prepared by different people at different times. An invented name that changed late, a strength added during preparation, a Reference Member State corrected after the form was first drafted: each of these has to propagate to all three, and nothing in the authoring tools enforces it.

The second pattern is the table of contents that no longer describes the submission. Section 1.1 is generated early, files move, and the document that is meant to orient the assessor becomes the first thing that misleads them.

The third is product information that is internally inconsistent across languages or between the SmPC and the leaflet — a change applied to the English source and to some, but not all, of the translations.

None of these require regulatory judgement to detect. They require someone to compare fields that live in different files, which is exactly the work that gets compressed when a submission date is close.

• Reconcile procedure, product name, strengths and MA numbers across cover letter, application form and envelope.
• Regenerate the table of contents after the final file move, not before.
• Check that every product-information change reached every language version.
• Confirm the declared submission type matches what the sequence actually contains.

Sequence metadata and the lifecycle it implies

An eCTD sequence is not a folder of documents; it is a statement about the lifecycle of a dossier. The envelope declares the submission type, the related sequence, and the operation applied to each document — new, replace, append or delete.

The operation attributes are where lifecycle errors accumulate. A document submitted as new when it replaces an earlier version leaves two live copies in the assessor's view. A replace pointing at the wrong predecessor silently rewrites the wrong part of the history. Neither necessarily fails validation, and both are painful to unpick several sequences later.

Related-sequence numbering matters for the same reason. A response to validation questions, a supplementary submission and a new application look similar in a directory listing and behave very differently in the lifecycle view.

Check the cumulative view rather than the sequence in isolation whenever the tooling allows it. The question is not "is this sequence valid" but "does the dossier read correctly after this sequence is applied".

Run validation early, and read what it does not say

The EU validation criteria are published, versioned and mechanical. Running them at the end, on the day of dispatch, converts every finding into schedule risk. Running them on a partial sequence during compilation converts most of them into an afternoon's work.

Understand what the criteria do and do not cover. They test structure, metadata, file formats and references — not whether the cover letter describes the right change, whether the application form matches the intended procedure, or whether a conditional Module 1 section should have been included. A sequence can pass every technical criterion and still be rejected at validation for a missing document nobody flagged as applicable.

This is why a completeness check and a validation run are different activities. The validator answers "is this well-formed". The completeness check answers "is this the right set of documents for this submission", and only the second one needs to know your procedure, product type and target countries.

• Run the current validation criteria during compilation, not only before dispatch.
• Re-run after the final file moves and metadata edits.
• Treat a clean validation as necessary, not sufficient.
• Keep the criteria version used with the submission record.

Keep the check evidence-based

For each expected item, record whether it is present, not applicable, missing or still to be confirmed. Link the conclusion to the declared submission context and the source requirement used.

Distinguish clearly between the four states. "Not applicable" is a decision with a reason behind it and should carry that reason; "still to be confirmed" is an open action with an owner. Collapsing the two — marking something not applicable because nobody has checked yet — is how a genuine gap survives every review it passes through.

Patient identifiers are not needed for a Module 1 completeness check. Remove personal data and confidential material that is not necessary for the review before sharing documents with any tool or external reviewer.

A completeness check narrows what a qualified reviewer has to look at. It does not replace them: applicability decisions, the adequacy of the product information and the regulatory strategy behind the submission all need professional judgement on the full dossier.