The eCTD summit

The ICH M2 ESTRI Main Page has been updated with the following announcement:

“ICH M2 has initiated the development of the Next Major Version of the eCTD (eCTD NMV) to improve robustness, flexibility and long term stability of the message. In accordance with the decision by the ICH Steering Committee that technical specifications should no longer be developed solely within ICH, but should be created in collaboration with Standards Development Organisations (SDOs), the eCTD NMV will be developed jointly with the HL7 RPS project. M2 has developed this list of requirements as input into the HL7 RPS Project.”

I took a look at the requirements (which have been posted before in various drafts).  They stretch to nine pages, and range from some that are uncontroversial and obvious to some that signal a significant change in direction.  In this posting, I point out some of the more interesting requirements.

Regulatory Activities

The new spec really supports the concept of organizing sequences into regulatory activities.  A regulatory activity is a collection of sequences that lead to a decision by the regulatory agency (such as an MAA, Variation, NDS, SNDS, Original NDA, Supplement, etc.) which can be mapped to individual ICH-regional regulatory processes.  This concept does not exist in ICH eCTD, although the regional authorities have added it using the concept of “related sequence.”  The NMV spec includes a number of formal requirements to support the Regulatory Activity concept.

Cross Application References

Current eCTD does not support cross application references, but neither does it prohibit their use.  The only authority to my knowledge who actively supports them is the FDA (who will send you a document providing directions if you email them at esub@fda.hhs.gov ).  EMEA expressly forbids them.

The new spec explicitly supports them as shown in the following requirements:

• Files should only need to be submitted once to a Health Authority and can be included by reference in multiple regulatory submissions to support multiple regulatory actions even across applications
• The message should support the reuse of electronic files from a previously submitted instance across applications.

Future of Study Tagging Files (STFs)

When I first read the requirement

When the same documentation is provided, it should be submitted in the same way across HAs. For example, when a study report is submitted in US it is submitted using the STF which is not acceptable in other HAs. This minimizes reuse capabilities and adds to Industry costs to prepare globally harmonized dossiers.

I wasn’t sure if ICH was suggesting that the STF concept should go away altogether.  I asked my colleague Jason Rock, who represents the FDA at ICH M2.  Jason explained that the goal was to do away with the STF as a separate XML file.  STF information would be contained in the main backbone, and could be ignored by authorities who don’t want it.   This was also confirmed in a later requirement reading “STF construct should be integrated into the message standard.”

Maintenance of Metadata:

Many sponsors have experienced problems with their eCTD due to the inability of the standard to accommodate corrections or changes in metadata (such as manufacturer).  eCTD NMV requirements include the requirement for the message to support the addition, updating and deletion of metadata to a previously submitted instances, e.g., related sequences, submission type, operation attribute, manufacturer name, etc.

Lifecycle

New NMV requirements regarding lifecycle are likely to be applauded by sponsors:

• Replacement of multiple leafs with single leaf and vice versa should be supported in eCTD.
• The operation attribute value “append” be removed from the list of allowed values (leaving only new, replace and delete)
• Allow a replace or delete leaf to modify more than one leaf in a previous sequence or sequences
• Allow a single leaf to be “modified” by more than one leaf in later sequences (supports changes in granularity)

Physical File Rules

The days of relying on a standard folder structure for XML-based eSubmissions are coming to an end as all parties move to acknowledge that they should be using the backbone/TOC and not the file system.  The NMV spec includes a requirement that “The physical file structure. (file/folder structure) should be minimal”.

File names would also be able to include underscores, which will come as a relief to anyone who has struggled with if or how to eliminate underscores from SAS file names.

Logical Groupings

New mechanisms for grouping files at levels below sections are called for:

• Provide ability to group a collection (or set) of files that together represent a document or reviewable grouping (e.g, all files related to a study report, all files related to a labeling document, all files related to a manufacturer or manufacturing component (e.g., container closure))
• Provide ability to treat a grouping of files as a single entity and to be treated as if it were a single file (complete with all descriptive attributes e.g., title) for all life cycle operations and relationship management and reuse needs

Scope

An important architectural concept for eCTD NMV/RPS is the separation of the messaging mechanism from the TOC.  The TOC is no longer built into the specification, but supplied by the regional authorities.  This is encapsulated in the requirement “Allow the capacity to modify the ICH CTD organizational structure (ToC) without modifying or changing the eCTD message structure.”

Compatibility

For those worried about the impact of the switch on their current eCTDs, some compatibility requirements should provide some reassurance:

• It should be possible for an applicant to build on an eCTD lifecycle started using the eCTD 3.2.x specification and continued using the eCTD NMV specification.
• No applicant should be required to resubmit data in the eCTD NMV specification if it has previously been submitted using the eCTD 3.2.x specification.