On this page: Regional content | Regional file formats | Electronic signatures | Empty or missing eCTD sections | Updating backbone attributes/metadata | Bookmarks, TOCs and hyperlinks | Reusing files | Baseline submissions

Regional content

Module 1 administrative and prescribing information

The ICH Common Technical Document (CTD) specifies that:

• Modules 1 should contain region specific administrative and product information
• Module 3.2.R should be used for any additional drug substance and/or drug product information specific to Australia.

Use the eCTD Sequence Matrix spreadsheet in the AU Regional Specification and Validation Criteria 3.0 Excel workbook eSubmission Validation Criteria to determine the content that is relevant to your specific regulatory activity.

Related information and guidance

CTD Module 1 Administrative information and prescribing information for Australia is being updated for the new content and numbering of Modules 1 and 3.2R.

Node extensions

Node extensions^[10] are a way of providing additional information in the sequence.

The node extension should be visualised as an extra heading in the CTD structure and should be displayed when viewing the XML backbone.

Consider the impact of changing node extension structures during the lifecycle as this can lead to a higher level of complexity in the cumulative view of a submission^[11].

Basic rules with using node extensions for AU

You can:

• Only use node extensions at the lowest level of the eCTD structure.

  Example - you can use a node extension at the level 5.3.5.1 but not at the level 5.3

• Use node extensions to group documents made up of multiple leaf elements.

  Example - a clinical study made up of separate files for the synopsis, main body and individual appendices could be grouped together under a node extension with the Study Identifier as its Title attribute

• Nest the node extensions but make sure the first node extension is at the lowest level in the eCTD structure.

  Example - a node extension may be added in Module 5.3.7 to group together files with the Study Identifier as Title attribute. Further node extensions may be added as children of the Study Identifier node, separating Case Report Forms (CRFs), if submitted, from individual patient listings.

Do not use:

• Node extensions if ICH specified sub headings already exist

  Example - do not use the following as node extensions:

  • indication
  • excipient
  • manufacturer
  • drug substance
  • drug product.

Study tagging files

We do not require you to provide study tagging files (STFs) for evaluation. You can reuse content submitted in other regions where STFs have been used. If you do this make sure it conforms to the ICH specifications for study tagging files.

We will collect data about the number and size of ICH E3 16.3 CRFs and non ICH E3 documents for informational purposes.

Regional file formats

Module 1

* XML format could replace PDF format whenever a structured exchange standard exists for the content

In addition to PDF, as defined by the ICH eCTD Specification Document, we will also accept XML.

Currently, there are no structured exchange standards for content, but these may be introduced in the future for content such as the lifecycle management tracking table, application forms, etc.

Where possible, generate PDFs from an electronic source. Signatures may be embedded as a graphic file in the PDF.

All PDF files, in any module, should be v1.4, v1.5, v1.6 or v1.7 except where a specific requirement for a later version is defined.

Modules 2 to 5

In addition to the file formats defined for Modules 2 to 5 in the ICH eCTD Specification, we will allow comma separated value (CSV) and plain text (TXT) files in Modules 4 and 5 to allow for specialist analysis - for example, population pharmacokinetics analysis.

Electronic signatures

Whilst electronic signatures - for example, public key digital signatures - will be crucial, particularly for authentication of electronic submissions and documents, we are currently accepting:

• Digital signatures as an adjunct to written signatures.
• Scanned signatures where the documents make up part of the checksum of an eCTD submission.

Empty or missing eCTD sections

In applications for new medicines:

• Provide detailed statements justifying the absence of data or specific CTD sections in the relevant Quality Overall Summary and/or Nonclinical/Clinical Overviews—for example, Module 2.3, 2.4, or 2.5.
• Include a statement in the cover letter on the absence of expected Module 1 content (based on information in the eSubmission Validation Criteria).

Do not:

• Use documents with no substantive content - for example, documents that contain words like 'not applicable' - in the eCTD structure. This creates unnecessary documents that have to be lifecycled and causes delays for evaluators who must open and assess documents with no substantive content.
• Provide a justification for content that is typically absent for applications for generic medicines.

Updating backbone attributes/metadata

Updating ICH attributes

You can update XML backbone attributes - for example, manufacturer - during the eCTD lifecycle, but these changes can lead to complexity in the cumulative view of a submission.

Whilst our evaluation system and processes can manage these changes, they are not required. We also recognise this practice is not allowed in some regions but we do allow the option as it does not negatively impact the evaluation process.

Changes in attributes can only be submitted if lifecycle updates to the content within those sections are submitted.

Updating AU envelope information

The AU envelope information can be updated during the lifecycle as is necessary to reflect changes in the application metadata—for example, adding and removing product names.

Bookmarks, TOCs and hyperlinks

We can increase the efficiency in evaluating your application if you prepare the documents so we can quickly locate content.

We recommend you:

• Use bookmarks and/or Tables of Content to assist us with navigating through PDF documents to quickly find information.
• Include Table of Contents, and/or if appropriate, a Table of Tables, Table of Figures, etc. on the first page for documents with more than five pages and with multiple sections.
• Use hyperlinks when they would aid the evaluation in ways not already possible through the use of the eCTD index.xml and the Tables of Contents. However, be aware that hyperlinks can cause confusion later in lifecycle.

Related information and guidance

ICH eCTD Specifications - Appendix 7

Reusing files

All eCTD format applications will be stored by eSubmission Identifier which can then be used to make referencing possible, to documents in other applications.

• Do not submit the same document multiple times. Reusing content that has already been submitted and evaluated makes the evaluation process more efficient.

We accept and encourage you to reuse files when you:

• Need to submit a file several times within one sequence^[12]
• Are referring to a file that has already been submitted in a previous sequence
• Are referencing a file submitted in another application.

Referencing content submitted in other applications

If referencing content in another application, create the link in the xml file as shown, highlighted, in the following code:

<m1-4-3-clinical>
  <leaf ID="N3774598bcdd74d5891d954542c552eee" operation="new" xlink:href=
  "../../../../e000111/0000/m1/au/104-expert/1043-clinical/dr-a-jones.pdf" checksum=
  "b6ba67a7740d12bcb938f2850baa584e" checksum-type="MD5">
      <title>Expert Dr. A. Jones</title>
  </leaf>
  <leaf ID="N3ad8bf59e3fd4cb5bbd4f82b31350887" operation="new" xlink:href=
  "104-expert/1043-clinical/dr-b-schmidt.pdf" checksum="bf30251122458c7c5c17dc3ed0002c1e"
  checksum-type="MD5">
      <title>Expert Dr. B. Schmidt</title>
  </leaf>
  <leaf ID="Ne0eeb59ae2f74ba5832965154db4cc13" operation="new" xlink:href=
  "104-expert/1043-clinical/dr-c-smith.pdf" checksum="f1e209870c05f15eef24f4b2e1e74a0f"
  checksum-type="MD5">
      <title>Expert Dr. C. Smith</title>
  </leaf>

This code (highlighted) directs the hyperlink out of the application and into the referenced application using the eSubmission ID of that application (referencing itself if directing into another sequence of the same application).

Related information and guidance

ICH eCTD Specifications - Appendix 6

Baseline submissions

A baseline submission^[13] is a resubmission of currently valid documents that you have already provided to us in another format.

Cover letter for baseline submissions

When making a baseline submission, you need to include a statement about each of the following points in the covering letter:

• the format used for the previous dossier(s)
• when the previous dossier(s) was submitted
• verify that the formatting is the only change to the previous dossier(s) and there are no amendments to content
• all the information in the baseline submission was in the previous version(s) of the dossier
• any omissions in the baseline submission do not cause the content to be misleading.

Changing from paper or NeeS

When changing from paper/NeeS to eCTD we recommend you:

• use a baseline sequence as a start of an eCTD
• provide as much content as possible in the eCTD.

You can define the sections provided in a baseline sequence, but make sure that any omissions do not cause the content to be misleading.

We prefer the baseline submission to consist of high quality electronic source documents, but we will accept good quality scanned images with Optical Character Recognition (OCR) as this will help us search the text during the evaluation process.

We do not evaluate the baseline submissions and you do not need hyperlinks between documents.

Baseline sequence

Use the sequence type Baseline and sequence description Reformat in the envelope for the baseline sequence.

Initial baselines of paper/NeeS submissions

The baseline should:

• normally be submitted as sequence 0000 (but if justified, could be submitted at a later date)
• always be a separate sequence
• never include new regulatory activities.

The first new regulatory activity - for example, the next variation - in eCTD format should then be submitted as sequence 0001.

Baselines submitted as multiple sequences

A baseline can be submitted later in the application lifecycle supplying information as it is needed.

When using a baseline sequence for the first time:

• Do add documents previously submitted as paper/NeeS in the appropriate part of the eCTD structure with the attribute 'NEW'.
• Do not re-submit documents from previous eCTD sequences.

You can use multiple sequences to submit a baseline.

Example - one sequence for the baseline for Modules 4 and 5 followed later by a sequence for the baseline for Module 3 or parts of Module 3.

• Do use the sequence type Baseline in each case.
• Do not use the sequence type Supplementary information for baseline submissions.

Make sure the related sequence for a baseline references itself in the envelope metadata.

Table 4 demonstrates how to submit multiple baselines later in the eCTD lifecycle.

In this example, the previously submitted content in paper/NeeS format for a variation application is submitted as a baseline prior to the initial sequence for the regulatory activity where it is needed.

These sequences can be submitted together on the same electronic media. Each sequence should have a cover letter explaining the purpose of each sequence.

Mid-lifecycle baselines of eCTD applications

There may be rare circumstances where you may wish to submit a baseline of content previously submitted in the eCTD format. In such cases, you can send an email outlining your proposal to esubmissions@tga.gov.au to discuss the best approach.

Related information and guidance

Australian Schema - structure, content and semantics of the Australian eCTD Module 1.