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.
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 email@example.com ). EMEA expressly forbids them.
The new spec explicitly supports them as shown in the following requirements:
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.
New NMV requirements regarding lifecycle are likely to be applauded by sponsors:
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.
New mechanisms for grouping files at levels below sections are called for:
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.”
For those worried about the impact of the switch on their current eCTDs, some compatibility requirements should provide some reassurance:
You must be logged in to post a comment.