Other AU regional considerations

This section includes additional points to consider when compiling your eCTD sequence to ensure a high quality dossier.

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 sequence.

Empty or missing eCTD sections

• 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.

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 included in the lifecycle 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 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.

Whilst our evaluation system and processes can manage these changes, they are not required.

We 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 metadata - for example, adding and removing product names.

Bookmarks, Table of Contents and Hyperlinks

Bookmarks and hyperlinks can be used to assist with navigation of the dossier.

Bookmarks

Use bookmarks to assist us with navigating through PDF documents. We recommend that documents which have multiple headings, sections, tables, figures, references or appendices AND more than ten pages contain bookmarks. Bookmarks are not expected in Literature References; however individual references should be provided as separate files and uniquely identified.

The validation criteria mandate a check of any documents other than Literature References, which have more than ten pages but do not contain bookmarks. A list of these will be created at validation. Excessive deficiencies may lead to complications with the evaluation of your dossier and should be avoided.

Table of Contents

Include a Table of Contents, and/or if appropriate, a Table of Tables, Table of Figures, etc. on the first page for documents with more than ten pages AND with multiple sections. If a Table of content is provided in addition to bookmarks, it should be hyperlinked. Document title pages are not necessary in an eCTD application.

Hyperlinks

Use hyperlinks to aid navigation. A proper use of bookmarks, TOCs and leaf titles with section numbers can reduce the need for hyperlinks by encouraging the use of the eCTD index.xml and internal document navigation options. References in documents should use the same titles of documents as they will be referenced in the eCTD index.xml. If this is not done and the reference is not obvious, hyperlinks should be created.

Hyperlinks can cause confusion later in lifecycle so the use of obvious hyperlinks should be avoided e.g. a reference in 2.3.S.1 to 3.2.S.1.1 Nomenclature is not necessary.

Module 3 uses a low level of granularity and is quite detailed in the definition of its content. Changes to the content are more frequent during later lifecycle sequences. It is therefore advised that the amount of hyperlinks applied to Module 3 be limited.

The structure for Module 4 and Module 5 however, is less defined and the content provided can vary greatly. Change to the content is also less frequent during later lifecycle sequences. It is therefore encouraged that particular attention be applied to hyperlinks from the summaries in Module 2 to the referenced studies in Modules 4 and 5.

If a reference is cited multiple times on a page, only the first instance need be hyperlinked.

References should not contain external links e.g. website or email.

Related information and guidance

ICH eCTD Specifications - Appendix 7

Reusing files

All sequences will be stored by e-Identifier which can then be used to make referencing possible, to documents in other eCTD 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
• Are referring to a file that has already been submitted in a previous sequence
• Are referencing a file submitted in another eCTD application (e-Identifier).

Referencing content submitted in other eCTD applications

If referencing content in another eCTD 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 eCTD application and into the referenced eCTD application using the e-Identifier of that eCTD application (referencing itself if directing into another sequence of the same eCTD application).

Related information and guidance

ICH eCTD Specifications - Appendix 6

Baseline sequences

It is highly recommended but not mandatory to use a baseline when converting to eCTD from another format. It provides the essential information in just one sequence to create an eCTD format product life cycle.

In essence the baseline is a resubmission of currently valid documents that you have already provided to us in another format such as NeeS or paper.

In this section: Cover letter for baselines | Changing from paper or NeeS | Baseline sequence - required identification | Initial baselines of paper/NeeS submissions | Baselines submitted as multiple sequences | Mid-lifecycle baselines of eCTD applications

Cover letter for baselines

When submitting a baseline sequence, 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 sequence was in the previous version(s) of the dossier
• any omissions in the baseline sequence 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 sequence 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 and you do not need hyperlinks between documents.

Baseline sequence - required identification

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 product 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 sequences.

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

Table 2 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 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 should send an email outlining your proposal to esubmissions@health.gov.au to discuss the best approach.

Work grouping and Work sharing

At times an applicant may wish to undertake more than one regulatory activity to a single product, or to apply a single variation to more than one product. In an eCTD dossier this could occur through work grouping (the former case) or work sharing (the latter case).

Each of these features is being given initial consideration by the TGA. The necessary structural changes to the XML envelope have therefore been incorporated in this eCTD specification update. However until the full detail is confirmed, they will lie dormant.

Node extensions

Node extensions are additional heading structures beyond those defined by the specifications, generally equated to an additional subfolder in a defined section and 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 the product life cycle history.

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.

Transferring sponsorship

If all products included under an e-Identifier are transferred to a new sponsor, the e-Identifier and the related sequences are transferred to the new sponsor.

Acquiring sponsor

The e-Identifier will transfer with the medicine, unless:

• there were multiple medicines submitted under the same e-Identifier

and

• you only acquired a portion of those in the transfer.

In the case of partial transfers, we will assign new e-Identifiers to the new sponsors.

Begin the first sequence of the new application with the next sequence number that would have been submitted under the old e-Identifier (see Table 1). This will indicate to evaluators that the medicine was initially reviewed under a different identifier.

Make sure you include the e-Identifier of the previous eCTD application in the cover letter of the new eCTD application.

Relinquishing sponsor

The future sequences of the medicines that remain under the initial identifier will continue as usual, however you should:

• remove the medicines you transferred from the envelope starting with the next sequence
• mention their removal in the cover letter.

Withdrawals

When withdrawing an entire product lifecycle history, the sequence type Product Withdrawal and sequence description Withdrawal should be used and only a Cover letter should be included as a 'New' document.

When withdrawing a regulatory activity, the sequence description Withdrawal should be used in combination with the initial sequence type used for the regulatory activity, and a Cover letter should be included.