eCTD 4.0 Implementation: Eligibility and Migration Readiness

For a regulatory operations team, “migration” can mean adopting a new publisher, starting an eligible application in v4.0, or continuing an existing application through forward compatibility. Those are different projects. A software import may change where you work without changing the submission format the authority accepts.

This guide helps you choose the right project, identify its dependencies, and produce an evidence record that publishing, regulatory affairs and quality can review together. The detailed eligibility paths focus on FDA and EU centralised applications. Other jurisdictions require their own decision, even when the same documents serve several markets.

A dated decision tree for your next application

Use the application record, rather than the next document's title, to answer the first question. “New annual report” does not mean “new application.” If the application's format history is unknown, retrieve it before selecting a production format.

Next, check whether the evidence describes production use, a technical pilot, or a future plan. Record that status explicitly. A vendor demonstration and an authority's pilot invitation answer different questions from a production acceptance notice.

Finally, ask whether your proposed software and operating process support that exact path. Eligibility is necessary, but it does not establish that a particular product edition, regional configuration or external publishing service can deliver it.

Read regional dates with their scope attached

EMA opened optional use for new CAP MAAs on December 22, 2025. Its July 8, 2026 update identifies Q1 2027 as strongly recommended and Q1 2028 as mandatory for those new applications. Existing-application forward compatibility and non-CAP implementation have separate pilot work; those dates are not a blanket conversion deadline for every EU dossier. EMA also asks applicants to contact its eCTD team before submitting v4.0. EMA implementation updates.

For other markets, use the following sources to open a separate eligibility record:

• Japan: PMDA's domestic package index was updated June 3, 2026, with package 1.6.0.3. Confirm the application category and domestic operating instructions alongside the package; a package number alone does not resolve transition eligibility. PMDA domestic implementation package.
• Switzerland: Swissmedic describes live implementation during 2027 following its pilot, with continued v3.2.2 support during a multiyear transition. Treat that as a plan when scheduling today's production work. Swissmedic v4.0 implementation.
• Canada: Start with Health Canada's current electronic-filing index. Its link to an earlier draft v4 consultation does not itself establish an operational v4 route for your submission. Health Canada filing instructions.
• Australia: TGA's published v4 AU Module 1 document is labelled a draft pilot specification. Confirm the operational instructions separately before using it to schedule production. TGA v4 AU Module 1 draft.

These entries identify the source and its limits. They are not an interchangeable global rollout calendar. Assign someone to recheck the relevant authority before the format decision and again before the production release.

What actually changes in eCTD v4.0

eCTD v4.0 uses HL7 Version 3 Regulated Product Submission, Release 2 Normative. It is not a migration to FHIR Bundles. XML remains part of the submission: ICH's supporting documentation describes submissionunit.xml, a checksum file and submission content. It also describes submission units as sequences with sequence numbers. Removing sequence control or historical records from your SOP would therefore be the wrong preparation. ICH support documentation v1.6, revised May 2024, slides 6–7 and 19–21.

The practical change is how the message represents and organises content. FDA's Technical Conformance Guide describes a single submission-unit message for ICH and regional content, with controlled terminology and metadata. Context of use connects a document to its role in the dossier; keywords help organise that context. Lifecycle relationships and document reuse still require deliberate handling. FDA Technical Conformance Guide v1.5, June 2026, sections 1.5.1–1.5.5.

For operators, this shifts some attention from finding the right folder to checking the meaning of the metadata. A document may open correctly while its assigned context is wrong. Reviewers therefore need to inspect both the document and how the submission presents it.

Files and regional packaging conventions also remain relevant. The EU Practical Guidance explicitly describes folders, submissionunit.xml, sha256.txt and a numbered sequence folder. Its lifecycle section preserves distinctions between documents and contexts of use. Do not treat a standalone submission-unit file as proof that all necessary application history has been supplied. EU Practical Guidance v1.0, December 2025, sections 1 and 5.

Training should connect these concepts to real decisions: who assigns metadata, who approves it, how a correction is documented, and how a reviewer distinguishes current content from an earlier state. Learning vocabulary without practising those decisions leaves the operational change unfinished.

Select an applicable document set, not just the newest download

Record the implementation guide, controlled vocabulary, validation criteria and transmission instructions separately. Their version numbers and support dates need not move together.

FDA's standards table illustrates the problem. The following is a September 14, 2026 snapshot, not a permanent configuration prescription. FDA v4.0 standards and support dates.

“Available to download” is not the same field as “support begins.” Where a field says TBD, keep it unresolved until applicable instructions establish the production choice. Ask the publisher to show the selected configuration and its basis.

Likewise, ICH's August 2026 page lists implementation-guide package 1.7 and controlled-vocabulary package 1.0.3 following June endorsement. A newer international package does not by itself establish regional adoption. ICH's current v4.0 package index.

Create a small document register for each planned release. Include the title, revision, publication date, applicable support date, authority, application scope, URL and date checked. Keep a copy of the governing document with the record so a later reviewer can reconstruct the decision after the web page changes.

If two sources appear inconsistent, retain both and describe the exact conflict. For example, a technical guide may explain a future capability while an operational notice limits present use. The unresolved question is availability for the intended filing, not whether the technical concept exists. Resolve that question before treating the configuration as approved for production.

Prepare the portfolio before selecting a pilot

Inventory applications and their next obligations

Start with each application's receiving authority, identifier, procedure, current specification, next planned activity, due date and publishing owner. Include outsourced applications. A team can underestimate its transition work when the service provider holds the history and the sponsor's tracker only lists the next deadline.

For an existing application, identify where the complete submitted history, acknowledgements and working records live. For a new application, document how its identity and scope were established. Record cross-market document reuse separately from application lifecycle: the same report can support different applications without making their regulatory histories interchangeable.

Use this inventory to choose a bounded first implementation. The candidate needs confirmed eligibility, available source material, accountable reviewers and time to resolve findings. Low document volume is useful only after those conditions are met. A small filing attached to an ineligible legacy path remains a poor choice.

Establish source and metadata ownership

List the approved source documents and identify the controlled copy of each. Check document titles, intended dossier locations, links, bookmarks and any supporting files relevant to the selected submission. Preserve the existing document-quality review; a different electronic format does not remove that work.

Then assign responsibility for application metadata, submission metadata and document context. The publisher may enter those values, while regulatory affairs owns their meaning. Make the handoff explicit so an incorrect term does not circulate through several reviews simply because nobody considers it their decision.

Use one representative document to practise the handoff. Have its owner state the intended role, the publisher show the resulting metadata, and a reviewer explain how it appears in the output. Record disagreements before repeating the approach across the dossier. This is a proposed preparation exercise, not a claim that a vendor's metadata workflow has been tested.

Define outputs across publishing, review and delivery

A successful implementation should leave inspectable outputs at each boundary. Request the published package, the configuration record, the technical validation report, the review disposition and the delivery evidence relevant to the selected route. Agree where each output will be retained and who can retrieve it.

Separate the responsibilities. A publisher produces the submission package; a viewer helps people inspect it; a validator evaluates the implemented technical checks; a transport mechanism delivers it. One product may combine several functions, but the evidence for each function remains distinct. A local validation result is not an authority acknowledgement or scientific approval.

For an outsourced route, agree whether the sponsor receives the actual package and reports or only a completion email. Ask who corrects a metadata error, who authorises a rerun, and who handles an acknowledgement requiring follow-up. An attractive service description is insufficient if these responsibilities remain unassigned near the deadline.

Practise the changed operating process

Update SOPs and work instructions around decisions operators actually make. Cover selecting the correct application path, confirming the document set, approving metadata, reviewing findings, releasing the output and retaining delivery records. Include a stop condition for an unknown authority scope or unresolved configuration.

FDA offers an optional sample-submission process for new v4.0 applications. Its implementation page separates that process from future forward compatibility. Use an eligible sample opportunity to learn about your selected route; do not interpret it as permission to convert an existing application. FDA v4.0 implementation and sample submissions.

Plan the first production handoff around dependencies rather than a universal number of weeks. Source readiness, access setup, vendor configuration, reviewer availability and agency coordination can determine the schedule. Keep staff and tooling available for applications that continue under another specification.

Worked exercise: three programmes, three decisions

The following portfolio is fictional. It demonstrates documentary planning as of September 14, 2026. No package was generated, validator run or authority submission performed for this example.

Programme Alder: a new FDA IND. The regulatory owner confirms that this is a new application rather than an amendment to an existing IND. The team records the eligibility source, proposed filing date and current document set. It can proceed to an evaluation of the v4.0 workflow, subject to the remaining readiness checks.

The publishing supplier then proposes its “latest FDA profile.” The evidence record remains incomplete until the supplier identifies the actual guide, vocabulary and validation versions. If it selects a revision whose support date is TBD, the team asks for the applicable basis before approving the setup. The outcome is “eligible path; configuration unresolved,” not a blanket pass.

Programme Birch: an annual report for an existing FDA v3.2.2 IND. Its small file count initially makes it look like an easy first project. The application-history check changes that decision. Under FDA's current implementation status, it is not a candidate for a routine production switch based on available forward compatibility. The team retains its existing publishing route and records the condition that would reopen the decision: applicable FDA transition instructions.

The useful work does not stop. Birch's owner can still reconcile the archive, locate missing acknowledgements and document metadata ownership. Those improvements prepare the team without pretending an unavailable format transition has occurred.

Programme Cedar: a new EU CAP MAA. Its regulatory owner confirms the centralised procedure, reviews EMA's optional route and coordinates the proposed v4.0 submission. The team creates an EU document register and evaluates the EU output separately from Alder's FDA configuration.

Now change one input: Cedar becomes a decentralised procedure. The earlier CAP decision no longer covers it. The owner must check the relevant procedure's operational status; the presence of EU technical documentation is insufficient. This is why the procedure belongs in the first row of the planning record rather than in a note added after publishing.

Change another input: all three programmes use an external publisher. Their authority eligibility stays the same. The handoff changes: the sponsor must obtain the provider's configuration evidence, review reports, packages and delivery records instead of assuming they are available in an internal system.

To reproduce the exercise, replace the three programme descriptions with your applications. Complete the checklist below using real source records. A second reviewer should be able to reach the same path decision without relying on the project owner's memory. Disagreement reveals a missing fact or an interpretation requiring resolution.

Migration evidence checklist

Use one record per application and planned release. Mark each item pass, blocked or revisit, with a reason and review date. “Pass” means the specified evidence supports that item; it does not mean the authority has approved the application. This is a suggested operating checklist, not a new regulatory requirement.

Add evidence locations to the record, not just ticks. If the package changes after review, identify what changed and which checks need repeating. If an authority updates a support date before release, reopen the affected configuration decision rather than discarding the entire assessment.

For a first implementation, review blocked and revisit items in the same meeting as the planned submission date. A schedule that ignores unresolved eligibility or configuration is not ready merely because document preparation is on track.

A publishing-vendor switch needs its own inventory and cutover evidence even when the submission format stays unchanged.

Questions that make a vendor discussion useful

Bring the completed application record to the conversation. Ask the supplier to name the product, edition, deployment and regional configuration proposed for this workflow. “Supports eCTD 4.0” is too broad to establish fit for your application.

For a broader shortlist, use the eCTD 4.0 software vendor guide alongside this application record. A portfolio-wide selection should account for the publishing routes you need to retain as well as the new route you want to introduce.

Ask how the supplier exposes document context and review findings, what history must be available, and what package and records you can export. Have it distinguish released capability from a demonstration, pilot or roadmap item. If you need both v3.2.2 and v4.0, identify the supported product or service for each and the person responsible for the boundary between them.

For technical validation, request the implemented criteria version and the handling of checks outside the product's scope. For delivery, request the actual transport responsibility and the evidence returned to the sponsor. These questions turn a feature presentation into an assessment of the work your team needs to complete.

Assyro publishes this guide and supports FDA eCTD v4.0 workflows. It can be considered for an eligible project. Assyro does not currently support eCTD v3.2.2, so it should not replace a required legacy publishing route. Confirm the specific application scope and current configuration during an Assyro demonstration.

Your next action is to select one application, attach the authority eligibility source, and assign owners to the unresolved checklist items. That produces a reviewable implementation decision while keeping the rest of the portfolio supported.

Use the eCTD proof-of-concept planning guide to structure the vendor evidence record. Its downloadable fixture is v3.2.2-only; create and qualify separate v4.0 cases for an eligible v4.0 application. For a supported new-application v4.0 workflow, evaluate Assyro eCTD validation; existing v3.2.2 continuation requires separately supported tooling.