The eCTD was a once in a lifetime achievement: an international agreement – originally between the US, the EU, and Japan, but now incorporating numerous countries from South Korea to South Africa, Brazil to Saudi Arabia[1]. Building on ICH’s work on the Common Technical Document (CTD), the eCTD created a content and electronic format for submissions that experience shows has radically improved review times for new drugs.
However, it had some shortcomings, the biggest being flexibility and changeability: To incorporate new document types in the global portions of the eCTD would require significant approvals by agencies and could create incompatibilities with earlier submissions[2]. This is because each section in the CTD table of contents is a separate XML element. This meant that any new document types ended up in Module 1 – the region-specific part, defined by each region as a separate XML specification, requiring software updates for each change[3]. If you look at the history of changes for the Module 1 XML for each country, you’ll see that’s where the action is, for instance, Swissmedic has had several changes that are nothing more than correcting typos[4].
Around the same time that the eCTD version 3.2 was being approved, in 2008, FDA began a project with Health Level Seven (HL7) to build a successor, called RPS (Regulated Product Submissions)[5]. It has since been approved by the International Conference on Harmonisation (ICH) as eCTD version 4.0. The goals for this project were to:
- Provide a single electronic format, and corresponding review system, for all divisions at FDA (Medical Devices, for instance, have a very different set of document requirements from drugs).
- Include a means of communicating agency responses in the same format, rather than relying on emailed documents without any associated metadata.
- Specify a controlled list for document content types that could be updated more simply than changing the XML definition (a Document Type Definition [DTD] or Schema).
- Increase submission flexibility by permitting changes to metadata, whether correcting a misspelling, changing a manufacturer or brand name, or dividing test specifications among different vendors.
- Devise a means of identifying content files separately from the submission, so that they can be referenced by other submissions without knowing the agency file structure.
- Create a means of replacing one document with many, or many with one.
- Define a Regulatory Activity as a group of submissions to get a single approval or acceptance (although frustratingly, the standard uses the term Submission for the grouping, and Submission Unit for the individual submissions).
With Step 4 Approval by ICH in 2015, it was expected that implementation would come swiftly after that[6]. However, nine years later, only Japan optionally accepts eCTD 4.0, and other regions have delayed their pilots (or created their own format, as the EAEU did)[7].
The reasons for this include issues with developing review systems (US FDA)[8], implementation of other data initiatives (CTIS, IDMP, etc., at the European Medicines Agency), and the COVID-19 pandemic (everyone had priorities shifted, workers unavailable, and remote-work drawing a large share of IT resources).
There are still challenges, especially to create a common repository for EU MRP and DCP submissions, versus separate ones for each member country. Also, no country has yet specified how they will implement the two-way communications capabilities of the standard7,[9]. This has the potential for improving agency/sponsor queries and responses but will require some major process changes for both the agencies and the drug sponsors/authorization holders.
Implementing eCTD 4.0 will involve new software and new processes, which will require companies to invest time, money and resources. While major software providers do support the format, there will almost certainly be tweaks when the final specifications arrive from each agency. Likely changes will include new tools or software features to manage changes to metadata, instructions for how to replace one file with many or many with one, and a few terminology changes for the Regulatory Activity concept. When the two-way communications scheme is implemented, this will also require some infrastructure changes for notification and delivery of content from the agency gateways – most companies only send through the gateway, although various data filings (safety, drug registration) do have status responses and notifications of acceptance.
One big change from the current eCTD is that the current format has an XML style sheet that can reformat the eCTD XML into a viewable web page by just double-clicking the “index.xml” file[10]. While this could theoretically be done for eCTD 4.0, it would be much slower, because there is no hierarchical organization to the documents in the submission, only identification of each document’s type and order. Much more processing would be needed to do so. However, the HTML view of an eCTD has always been limited in functionality because of the inability to incorporate multiple submissions to show the current state of the submission dossier – all the major software providers first load that XML into their databases for quick access to the history of the application. Viewing software also integrates all the parts of the submissions, eliminating the need for a separate style sheet for the Module 1 (regional) data.[11]
There are many good reasons to be excited about eCTD 4.0 – and of course as with any change, a number of bumps along the way.
What are your concerns about eCTD 4.0? And what preparation, if any, have you put in place to transition your submissions? We would be interested in hearing your thoughts on the changes.
About the author:
Karl-Heinz Loebel is Director and Principal Consultant, Regulatory Operations, at Cencora PharmaLex. With more than 18 years of experience in regulatory operations, he has built his expertise in data management and the electronic exchange of information with regulators and has been a constant contributor to shared industry/agency forums on digital data exchange for the past decade.
[1] Electronic Common Technical Document Specification. [Online] 2008. [Cited: 04 10, 2024.] https://admin.ich.org/sites/default/files/inline-files/eCTD_Specification_v3_2_2_0.pdf
[2] Global ICH eCTD Adoption, EFPIA, Dec 2021. https://www.efpia.eu/media/636610/ectd-white-paper_final-20-dec-21.pdf
[3] EU Module 1 eCTD Specification, EMA. 2017. https://esubmission.ema.europa.eu/eumodule1/docs/EU%20M1%20eCTD%20Spec%20v3.0.2-HHMG-20170308.pdf
[4] Swissmedic. Swissmedic. [Online].; 2020 [cited 2024 05 09. Available from: https://www.swissmedic.ch/dam/swissmedic/en/dokumente/infrastruktur/os/swiss_m1_specificationforectdv.pdf.download.pdf/swiss_m1_specificationforectdv15.pdf.
[5] FDA Data Exchange Standards Initiatives, Regulated Product Submission (RPS) Standard Status. https://www.fda.gov/media/77168/download
[6] International Conference on Harmonisation. Multidisciplinary Guidelines. https://ich.org/page/multidisciplinary-guidelines
[7] ICH M8. ICH electronic Common Technical Document – eCTD v4.0 . [Online] 2024 https://ich.org/page/ich-electronic-common-technical-document-ectd-v40
[8] Food and Drug Administration. Electronic Common Technical Document (eCTD) v4.0. [Online] 2024 https://www.fda.gov/drugs/electronic-regulatory-submission-and-review/electronic-common-technical-document-ectd-v40
[9] Esubmission news, eCTD 4.0. https://esubmission.ema.europa.eu/eCTD%20NMV/eCTD.html
[10] International Conference on Harmonisation. ICH electronic Common Technical Document – eCTD v3.2.2 Specification and Related Files, Style Sheet. [Online] 2004 https://admin.ich.org/sites/default/files/inline-files/ectd-2-0_0.xsl
[11] European Medicines Agency. eCTD Guidance Document. [Online] 2009 https://esubmission.ema.europa.eu/doc/eCTD%20Guidance%20Document%201.0%20FINAL%20FOR%20PUBLICATION.pdf
