Overview

he electronic Common Technical Document (eCTD) is 16 years old, approved by the International Council on Harmonisation (ICH) to Step 4 in 2008. It’s old enough to drive a car in the US. It’s had some small changes over the years but is still pretty much the same as it was in the George W. Bush era. It’s had a huge impact on the speed and accuracy of regulatory submissions for pharma … but it could be better. That same year, the US Food and Drug Administration (FDA) started looking at a next-generation submission format, which would become eCTD 4.0. That standard was approved to Step 4 at ICH in 2015, and nine years later, FDA is still not using it. Let’s look at how we got to this point, and what’s holding us back.

The Dark Ages–Before eCTD

FDA has required New Drug Applications for new medications starting in 1938, after a safety issue on sulfanilamide caused over 100 deaths. As requirements for clinical data grew with subsequent FDA regulations based on other safety incidents, these submissions grew in size to a literal truck filled with paper (although it was in triplicate). Similarly, huge amounts of application documents were sent to agencies in Europe, especially after regulations were tightened as a consequence of the thalidomide crisis in the 1960s.

In the US, reviewers would start by reviewing the volume or volumes that contained summary information, which would then reference individual volumes and pages containing such items as toxicology or clinical study reports, protocols, patient case report forms, and quality-control procedures. Such cross-references were originally hand-stamped in the margins of documents, adding to the costs. The reviewer would then request that volume be retrieved from agency storage—which was also growing at an enormous pace—and in the 1990s that action alone could take several days. Things were even worse in Europe, where hard copies of the documentation were delivered to multiple national agencies and reviewers were spread across the countries.

At about the same time, graphical user interfaces (GUIs) on Macintosh and Windows computers were gaining ground in the pharmaceutical industry, making it easier to author, assemble, and cross-reference the application dossiers. Services began to emerge that could make electronic images of printed documents (it might be 10 or more years’ worth of documents that are accumulated into a single application; not everything will have been freshly electronically composed), and agencies began accepting those image formats as review aids—but not replacing the paper. This included DAMOS (Drug Application Methodology with Optical Storage) in 1989 and SEDAMM (Soumission Electronique de Dossiers d’Autorisation de Mise sur le Marché) in 1993.

The appearance of Adobe Acrobat’s Portable Document Format (PDF) in 1993 swiftly became the de facto standard for electronic regulatory documents. Being able to traverse between documents with a single click made cross-referencing simple, and publishing software swiftly adapted to use it.

Along with these emerging standards, reviewers would request other information, such as Word-processable versions of reports, spreadsheets of tables, custom document viewers, and databases. At this time, FDA reviewers did not have an electronic network, and many were lucky to have a personal computer at all. Drug sponsors were asked to provide—on loan—computers, often with a duplicate for reviewers to continue to work at home. This all fell under the heading of CANDA (Computer Aided New Drug Application) in the US; however, the EU and most of the rest of the world never really came up with abbreviations that caught on.

This overwhelmed IT at the health authorities in the US and Europe, as reviewers would have separate computers for each NDA, all within tiny offices. It also overwhelmed the capabilities of a typical office computer at the time. In Europe, and even in the US, some agency staff were opposed to working with electronic versions of documents as they were accustomed to working with paper. That opposition continued even at the start of eCTD.

Two factors eased the situation: a standard electronic submission format utilizing PDF for both the content and tables of contents announced in 1999, and user fees for new drug applications (e.g., in the US in 1992), which enabled, among other things, the upgrading of agency computing capabilities.

The CTD and eCTD

The Common Technical Document

In 1989, ICH began work with the US, EU, and Japan to develop a Common Technical Document (CTD): an outline of a new drug application that would be applicable to all three regions. This would include a regional Module 1 (technically not part of the CTD), summaries in Module 2, quality/manufacturing in Module 3, nonclinical in Module 4, and Clinical in Module 5. The CTD became the mandatory or strongly recommended format for most types of drug applications in the US, Europe, and Japan over the following years and decades. Regrettably, clinical (e.g., Investigational New Drug applications), quality (e.g., IMPD), and applications for relatively novel product application classes (e.g., Advanced Therapy Medicinal Products, ATMP) only mostly fit this model.

It is relatively simple to adapt the CTD into an electronic format using PDF tables of contents, and that is exactly what is called NeeS today (Non-eCTD electronic Submissions). However, this has several shortcomings:

• Life Cycle of Documents: Because all that is sent is a list of documents, it may not be obvious that a document from a previous submission sequence was deleted or changed, other than what is mentioned in a cover letter. This makes it programmatically impossible to present the current state of the dossier.
• Indexing/Tagging: Other than the division by module, and large-scale items such as studies or formulations which group documents into separate folders, it is not simple to locate, for instance, all the procedures for a given excipient, or all the protocol documents across clinical studies for a given indication.

The Electronic CTD

Starting in 1997, ICH also began work on the electronic version of the CTD (eCTD): a means of providing a computer-readable “backbone” for the table of contents, organized hierarchically like the CTD table of contents. This included the following features:

• A complete hierarchical organization for documents in Modules 2-5
• Built on the XML standard, enabling it to be easily transformed into a webpage.
• Folder and File Naming conventions, so that reviewers can easily identify a document.
• An ID is assigned to each document so that it can be referenced in future submissions.
• Life cycle management operation indicating what is new or changed
• Attributes for certain repeating sections to aid in organizing the following sets of documents such as indications, products, and substances

Implementation of eCTD

The eCTD was approved by ICH in 2008, and it rapidly became the primary means of submission to the major markets. It is now accepted—and required for most submissions—in the US, EU and European Economic Area, UK, Japan, Switzerland, Canada, South Korea, China, Taiwan, and the countries of the Gulf Cooperation Council. It is also being implemented in Brazil, Mexico, Egypt, Singapore, and Turkey, and accepted as supplemental in many other countries. FDA reports that as of 2022, 94% of all submissions were in eCTD format, amounting to over 8 million submissions through the electronic gateway.

Each region that has adopted the eCTD needs to create its own Module 1 XML definition (a DTD or XSD file). This also means that they need their own transformation to make it visible as an HTML webpage. While this complicates systems for assembling and reviewing submissions, it does mean that a change for one country does not require going back to ICH to update the standard. Different regions have adopted other conventions too: The US uses “Study Tagging Files” so that each separate PDF associated to a clinical or nonclinical study can be identified with more details (document type such as protocol or CRF, site and patient ID for CRFs, etc.). Other regions use the Node Extension concept to do similar things.

Over the years, the eCTD standard has undergone a few minor changes on an ICH level (impacting mainly Modules 2–5 of the CTD structure) as well as on the national or regional level (concerning the respective Module 1 structure and national peculiarities on the handling of eCTDs). This is reflected in the version numbers of the respective ICH and national eCTD specifications. The current version of the ICH standard is version 3.2.2. As the minor subversion numbers mainly reflect editorial changes, from a technical point of view all versions 3.x have proven to be very stable.

Why eCTD 4.0?

In 2005, even before the eCTD was being adopted, FDA began a new project using Health Level Seven (HL7, a standards group working on healthcare data interchange and accredited with ANSI, the American National Standards Institute) to develop a next-generation submission format. The primary goal was to create a format—and thus a review system—that can manage not only drug applications, but also applications for veterinary drugs, medical devices, cosmetics, food additives, and tobacco products.

This required more flexibility in the XML format; instead of predefined XML elements for each table of contents level, it would need to be parameterized. This meant that a single XML schema could be used to define any kind of submission to agencies (although the “product” metadata section was tied to medicinal products), including Module 1 and any study “tags.” The result is something that looks more like the index at the back of a book than the TOC at the front.

By the time the standard—called RPS for Regulated Product Submissions—was approved by HL7, and by ICH in 2014 as eCTD 4.0, submission structures had been defined for US, EU, and Japanese drug submissions, and by the IMDRF for medical devices.

The RPS standard used for eCTD 4.0 has also been designed to resolve other shortcomings of the eCTD 3.x format:

• The ability to have agencies deliver review questions/comments and submission status in the same format: two-way communication.
• More flexibility in revising documents: replacing one document (such as an updated protocol) with many (a protocol and amendments), or the other way around and to update metadata when a document is reclassified or an error is sent.
• Enhancements to the concept of a “regulatory activity” (one set of submissions to achieve an approval, acceptance, or notification), including grouping or bundling of submissions across products; a change in a raw material supplier can be sent as a single submission unit against several submissions (note that FDA’s latest Module 1 in eCTD 3.x format can do much of the same).

There are some downsides, though, the biggest of which is that new publishing and review software will be needed. Most submissions publishing software supports eCTD 4.0 at this time, although it will likely need updates as each country supplies their own specifics for regional document types. Another is that the RPS format is significantly less human-readable than eCTD 3.x, and its nonhierarchical nature means that constructing a webpage “on the fly” is much more complex. However, the quick web view of eCTD submissions was always a “hack”: it could only display a single submission, not the full life of a dossier. It’s always been better to have the eCTD submission ingested by a review system to account for the changes to a dossier over the months of a review. Additionally, eCTD 4.0 comes with a range of new or changed terminology that users will need to familiarize themselves with.

One other problem with eCTD is that key terms were never clearly defined. The term eCTD can refer to an application, a submission, or a sequence. There is no defined expression for an eCTD dossier, which is the complete set of submissions that have been made for a given product.

Obstacles to Implementation

What has been holding eCTD 4.0 implementation back?

Stopgaps and Other Digitalization Efforts

FDA’s current implementation of the Module 1 administrative information steals a lot of the thunder from eCTD 4.0: It implements the concept of the regulatory activity and parameterizes the TOC for forms and advertising/promotional materials. This reduces the impact of bringing in eCTD 4.0.

Additionally—even though not defined in eCTD 3.x—some eCTD software vendors have implemented the concept of regulatory activities in their tools, allowing applicants to group their submissions as necessary in the user interface.

Meanwhile, FDA has implemented a new format for Medical Device submissions called eSTAR (electronic Submission Template And Resource), which does not use the RPS standard, and more closely resembles the NeeS and 1999 standards. This also lessens the benefits of the single review system concept that spurred the eCTD 4.0 development.

The implementation of IDMP in Europe and elsewhere is also impacting how eCTD 4.0 is implemented, as the eCTD 4.0 administrative information overlaps with the ISO and EU IDMP structures for product and registration information. Decisions will need to be made whether information will be kept separate or overlap.

EU’s Clinical Trial Information System (CTIS) creates yet another format for assembling clinical trial applications (CTAs), not using the eCTD (3.x or 4) backbone. Again, this dilutes the efforts of eCTD 4.0; the RPS standard could certainly have been used for CTIS submissions.

Note that the Eurasian Economic Union (EAEU), consisting of Russia, Belarus, Armenia, Kazakhstan, and Kyrgyzstan, has defined its own submission format which structurally resembles RPS/eCTD 4.0 but is completely independent.

One issue is particularly relevant to the EU. To fully exploit the capabilities of eCTD 4.0 and especially the usability of documents across different applications, it’s important that all receiving agencies are accessing the same common repository. That’s fine for FDA and other agencies and in EU it’s fine for the Centralised Procedure applications, but as discussed in various forums, such a repository is neither available nor planned for the near future for the Mutual Recognition and Decentralised Procedures.

Review Systems

As mentioned above, building the table of contents for an eCTD 4.0 submission is not as simple as it is in version 3.x. FDA went through an extended period of development for a new review system, at least one version of which was abandoned, and a new vendor sought.

COVID-19

The COVID-19 pandemic put many development plans on hold, and eCTD 4.0 appears to be one of its victims.

Worldwide Status of eCTD 4.0

It’s been 10 years since the ICH Step 4 approval of eCTD 4.0. There has been some progress, but no country yet requires submissions in eCTD 4.0 format.

• Japan completed a pilot in 2021 and is accepting voluntary submissions in eCTD 4.0 format, with a mandate to use the format in 2026, but is not implementing two-way communication yet.
• The US completed a pilot in 2023 and is expected to accept eCTD 4.0 submissions only for new applications during 2024 with use of the format mandated no earlier than 2029. At this time, they are testing their review software. Two-way communications are not part of the initial implementation plan.
• The EU is planning a technical pilot for applications using the CP only, without two-way communications, during 2024, with voluntary acceptance starting in 2025, adding MRP/DCP/NP applications in 2026. The first eCTD 4.0 submissions with real content are expected to be submitted during the business pilot starting in 2025.
• Pilots are also planned for 2024 in Brazil and Australia, and in 2025 for Canada and Switzerland.

What to Expect Going Forward

Assuming that agencies keep moving forward with their proposals—not always the case, if you’ve been watching IDMP’s slow progress—drug sponsors will be able to send submissions in eCTD 4.0 format in the next year or two to many of the major markets but won’t be required to do so for a few years after that. Both FDA and EMA typically provide at least two years to adapt to new mandates after final guidance approval.

The use of eCTD 4.0 should have little impact on day-to-day operations: documents will continue to be the same, the submission tables of contents have minimal changes, and the operations of submission publishing software will likely not change, except to enable the new capabilities for lifecycle and metadata changes. The changes for two-way communication will change some process and IT requirements, but those are further down the road.

There are good reasons to adopt eCTD v4.0, especially the added flexibility in lifecycle. However, it will be up to the schedules of each agency’s adoption process for those features before the gains are seen.

For industry, while there may be some hesitation, the fact is that agencies have made their decision. So as the Borg put it, resistance is futile!