eCTD 4.0 has a variety of different new terminology. To make sure you can tell the difference between your CoUs and UUIDs, this blog post will walk through the key concepts in eCTD 4.0.
In our introduction to eCTD 4.0 post, we talked about the drivers behind the Next Major Version of eCTD, version 4.0, and its benefits for organizations. eCTD 4.0 has a variety of different new terminology. Some of these terms are just new words for old concepts, while others introduce completely new concepts to the eCTD world. To make sure you can tell the difference between your CoUs and UUIDs, we will walk through the key concepts in eCTD 4.0.
The technical details of the eCTD specifications are located in Implementation Guides, published by the ICH and Regional Health Authorities. These contain the nuts and bolts of how to make the backbone for an eCTD 4.0 submission. They are also notoriously dense:
8.2.14.1 Location in XML
The document element in the XML message is in the following location for documents:
controlActProcess>>subject>>submissionUnit>>componentOf1>>submission>>componentOf>>application>>component>>document
Then turn right at the first hyperlink, and keep going past the Synopsis... (from ICH IG, page 60)
For the most part, the implementation guides will have their components integrated into your eCTD compilation software. eCTD 4.0 is very much intended to be created by a machine instead of by hand, and the implementation guides are written to match. While your tool vendor will be spending lots of time with the implementation guide, you are probably fine working through some of the numerous summaries.
Sponsors who have been submitting to the EU have already been introduced to the Universal Unique Identifier (UUID). At its most basic, a UUID is a hexadecimal text in the form of 8-4-4-4-12 characters.
Sample: 8154a4cc-50b5-4c0f-9f85-ff3720783ca4
In eCTD 4.0, UUIDs are used almost everywhere to reference parts of the backbone. You will have separate UUIDs for each submission unit, the context of use, application, and document, among others. The use of UUIDs is intended to make it very easy to reference any component part of your eCTD in another submission or section.
Sponsors who have started working with the latest version of the FDA eCTD specifications have already received a taste of working with agency-created controlled vocabularies. In eCTD 4.0, controlled vocabularies will become ubiquitous. Vocabularies maintained by the ICH, HL7, regional authorities, and sponsor organizations themselves will all be a part of an eCTD 4.0 submission.
To manage all of these different lists, eCTD 4.0 uses Object Identifiers (OID). Each separate controlled vocabulary list (e.g., species, the context of use) has its own unique OID. In your eCTD 4.0 backbone, whenever you use a value from a controlled vocabulary, your tool will also need to specify the OID to show which list that value is taken from.
While OIDs mostly refer to controlled vocabularies, they can also refer to other items, such as organizations and specific centers within a health authority.
In eCTD 4.0, metadata that was in subsections of eCTD 3.2 (i.e., Substance and Manufacturer in section 2.3.S) are referred to as Keywords. Just as today, the section (Context of Use) in a particular document is located in determines which keywords are appropriate.
As part of your eCTD 4.0 backbone, you will also include Keyword Definitions. These are the sponsor-defined values for keywords and include both a code and a display name.
|
Section 3.2.S |
Attribute (eCTD 3.2) Keyword (eCTD 4.0) |
Value (eCTD 3.2) Keyword Definition (eCTD 4.0) |
|
Manufacturer |
EXTEDO |
|
|
Substance |
Wonderpill |
Submission Unit is the term used in eCTD 4.0 for what we previously called submissions or sequences. The submission unit is the overall unit of work contained in a single backbone (now the submissionunit.xml). In certain circumstances, such as grouped submissions, you can have multiple submissions and sequences included as part of a single submission unit. For the most part, however, the submission unit is synonymous with what we think of as submissions today.
Context of Use is one of the major new terms that is introduced in eCTD 4.0. While it certainly is important, from an end-user perspective, Context of Use is simply a new term for a section. Like eCTD 3.2, eCTD 4.0 has five modules, with a single regional module and four common modules. Within each of these modules are multiple sections that we have all grown to know over the last 15 years of eCTD. With some minor changes, those sections match exactly the context of use in eCTD 4.0.
One new function in eCTD 4.0 is the ability to control the order in which documents within a section/context of use are displayed. In eCTD 3.2, you were often at the mercy of a health authority's viewer or your own eCTD compilation tool to determine the order of documents in a section. In eCTD 4.0, a priority number is introduced, allowing users to manage the display order directly in the backbone. This maintains consistency across viewing platforms and tools, as well as allows sponsors to integrate documents submitted across multiple submission units to be integrated into an overall section in whichever order the sponsor wants.
For submissions to the FDA, sponsors are used to using STFs to organize their studies. In the EU and other regions, Node Extensions are used instead. In eCTD 4.0, these approaches are finally harmonized into a single concept: document groups. Document groups allow users to further group documents under a single context of use, like studies in modules 4 and 5.
As with every component of an eCTD 4.0 backbone, documents also have their own UUID. This allows for an expansion of the possible options for lifecycle management and re-use from that which was possible in eCTD 3.2. You will still have the option to replace documents with updated documents in later submission units, but you will also now be able to replace multiple documents with a single document and vice versa. With this ability, the former lifecycle operation for append has been removed.
Similarly, the UUID allows for the very easy reuse of documents across different applications. In eCTD 3.2, you can use cross-application referencing to point to a document in a different application using the xlink:href. This can cause plenty of issues with lifecycle management and tracking of that document. In eCTD 4.0, you would instead point to a document using its UUID. As long as documents are maintained in the same repository, health authorities can use the UUID to view documents in any application.
With the UUIDs present on Context of Use and Keyword Definitions maintained in the backbone, sponsors can now update the metadata on sections without changing or lifecycle managing the documents within those sections. In eCTD 4.0, you will no longer need to remove and re-send an entire section just to fix an incorrect piece of metadata.
Unlike the transition from FDA DTD 2.01 to 3.3 or EU 2.0 to 3.0.1, moving an application from eCTD 3.2 to eCTD 4.0 requires a dedicated transition submission. These submissions are known as Transitional Mapping Messages (TMM). As part of the TMM, you will convert all of your documents, sections, and metadata to the eCTD 4.0 framework. Much like previous changes in specification, this transition is a one-way street – once your eCTD 4.0 TMM has been accepted, you cannot go back to submitting in eCTD 3.2 for an application. Look for a future blog on TMMs for more details!
eCTD 4.0 also introduces the concept of two-way communication. With two-way communication, health authorities can include their communications to sponsor companies as submission units within an overall application. While not all regions are currently focused on implementing two-way communication as part of their eCTD 4.0 rollout, the ability to centralize health authority communication within a submission remains a major driver for eCTD 4.0 adoption. Two-way communication is a major topic in eCTD 4.0, as well as a major business driver. We will take a deeper look at it in an upcoming blog post.
The switch to eCTD 4.0 will be a significant technical challenge that will need to be dealt with largely by vendors of eCTD publishing systems. A major upgrade to current eCTD publishing and management systems will be required, and most eCTD vendors, including EXTEDO, plan a major release specifically to cover eCTD 4.0.
The planning for eCTD 4.0 will focus on regulatory departments. As health authorities begin to accept eCTD 4.0 submissions, regulatory departments will need to plan their transition to the new standards. Ensuring that software upgrades and transitional mapping messages do not cause conflicts with ongoing timelines will be major planning challenges. Additionally, regulatory departments will need to ensure that their tracking sheets and SOPs are both updated and in alignment with the new terminology used in eCTD 4.0. As two-way communication is introduced, new processes will need to be developed to ensure that agency communication is still routed and distributed appropriately.
To learn more about eCTD 4.0 objectives, benefits, impact on organizations, and roadmaps to implementation, download EXTEDO's whitepaper: eCTD v4.0: Objectives, benefits & impact on life science organizations.