Analysis: New ICH M2 Requirements into eCTD NMV (=RPS)

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.

Article written by

I am GlobalSubmit’s director of professional services. My area of expertise is electronic document management and regulatory submissions, specifically eCTD. I have 12 years of biopharmaceutical industry experience in the US, Europe, Israel and Japan, concentrating on content management for Regulatory Affairs & Submissions, Clinical Development, and Manufacturing, and in submission assembly and publishing. I have worked with over 50 pharmaceutical clients. Previously, I was the practice lead for the Subject Matter Experts/Business Analysts group at First Consulting Group (FCG), now part of CSC. I supervised a group of 12 SMEs/BAs. I was instrumental in the development of the FirstDoc® suite. I developed the project delivery methodology for FirstDoc® R&D, including training materials, project plans, workshop methodology and materials, and requirements and design specifications. I managed the design and development of FirstDoc® GMP and FirstDoc® Legal. Please feel free to contact me at kathleen.clark@globalsubmit.com if you are interested in talking about eCTD products or consulting services, or if you have ideas for the blog.

4 Responses

Page 1 of 1
  1. joelfinkle
    joelfinkle November 18, 2009 at 3:52 AM | |

    The STF — and the Regional Module 1, as well as anything else that needs to be thrown in (ISS, ISE, etc.) — all get folded into the RPS backbone, because it’s just a flexible list of topics, not a stiff hierarchy. One message can have topics (Context of Use codes) from multiple sources, so long as the given Regulatory Activity permits that set. It becomes a validation issue to make sure that an EU labeling code doesn’t go to the US, for instance.

  2. Tweets that mention Analysis: New ICH M2 Requirements into eCTD NMV (=RPS) « The eCTD summit -- Topsy.com

    [...] This post was mentioned on Twitter by Cuberdon, Kathie Clark. Kathie Clark said: Read all about the ICH M2's eCTD NMV requirements to be input into the RPS standard on The eCTD Summit blog: http://bit.ly/4fv8UV [...]

  3. eCTD Study Report Formats | Aerie Canal Consulting

    [...] In the eCTD world, both study report formats require study tagging files (STFs) for submission to the FDA. For legacy reports, the STF provides metadata about the report, including the report number, title, and in some sections, route of administration, duration, etc. STFs for granular reports contain the same information they would for a legacy report, but they also act as a table of contents that organizes the files in the report. Every file associated with an STF is identified with a piece of metadata called a file tag. The file tag identifies the type of information contained in that document. Examples of file tags include report body, synopsis, case report forms, datasets, and listings.  File tags enable eCTD viewers to organize the report content into virtual folders, making it easier to navigate the hundreds of files that can make up a clinical study report. You can find more details on study tagging files in this ICH guidance document: http://estri.ich.org/STF/STFV2-6-1.pdf.  (If you want to see an interesting discussion of the probable future of STFs, check out this post on Kathie Clark’s excellent blog, The eCTD Summit: http://ectdsummit.azurewebsites.net//?p=612.) [...]

  4. FDA Fillable Forms | Aerie Canal Consulting

    [...] In the eCTD world, both study report formats require study tagging files (STFs) for submission to the FDA. For legacy reports, the STF provides metadata about the report, including the report number, title, and in some sections, route of administration, duration, etc. STFs for granular reports contain the same information they would for a legacy report, but they also act as a table of contents that organizes the files in the report. Every file associated with an STF is identified with a piece of metadata called a file tag. The file tag identifies the type of information contained in that document. Examples of file tags include report body, synopsis, case report forms, datasets, and listings. File tags enable eCTD viewers to organize the report content into virtual folders, making it easier to navigate the hundreds of files that can make up a clinical study report. You can find more details on study tagging files in this ICH guidance document: http://estri.ich.org/STF/STFV2-6-1.pdf. (If you want to see an interesting discussion of the probable future of STFs, check out this post on Kathie Clark’s excellent blog, The eCTD Summit: http://ectdsummit.azurewebsites.net//?p=612.) [...]

Please comment with your real name using good manners.

Leave a Reply

You must be logged in to post a comment.