eCTD AU module 1 and regional information v3.2

Obtaining the e-Identifier

You will need an e-Identifier before you submit your first regulatory activity in eCTD format.

To obtain an e-Identifier:

• send an email to esubmissions@health.gov.au
• include the following information in your email:
  • the applicant’s name as listed in the eBS client database
  • name of the active ingredient (the AAN or proposed AANs) or subject of an eCTD sequence regarding a Master File
  • a description of the submission (application type, dosage form), if referring to a medicine
  • name and address of manufacturing site, if referring to a Master File.

The e-identifier is:

• a combination of the letter ‘e’ and six digits. Example: e123456
• valid throughout the entire lifecycle of a product unless split from a package as explained in Transferring sponsorship.

Preparing the eCTD cover letter

Include the following information in the cover letter in addition to the CTD requirements for the Cover Letter:

• the e-Identifier, the sequence and related sequence in the subject line, consistent with the eCTD envelope
• a description of the eSubmission:
  • type and number of electronic media
  • approximate submission size, and
  • any characteristics concerning the media that we might need to know
• a description of the software used to check the files for viruses and a statement as to whether the submission is virus free
• the regulatory and information technology points of contact for the submission
• information about the validation including:
  • the validation tool and version used
• a paper copy of the Cover Letter should be included with the physical media containing the eCTD. This is only necessary until we develop an electronic portal.

You do not need to include a copy of the validation report; however, an electronic copy needs to be provided if requested.

Validating the eCTD sequence

You must validate your sequence prior to submitting to us. The validation software that you use should be able to validate the AU Module 1 criteria. We also validate each eCTD sequence using the AU Validation Criteria.

There are three types of eCTD validation findings:

• Error - Critical finding:
  • validation findings categorised as errors must be addressed
  • non-compliance will lead to rejection of the sequence
  • Refer to Sequences with errors or deficiencies for further information.
• Warning - Best practice recommendations:
  • validation findings categorised as warnings should be addressed
  • we recommend warnings be eliminated whenever possible
  • repeated or excessive issues may result in a request from us for you to fix the sequence and resubmit it.
• Information - Information collected about the data being submitted. This includes:
  • a list of omitted possible documents as defined in the Document Matrix that might be required in a sequence
  • information about unusual lifecycle operations
  • information about study tagging files submitted, etc.

Please minimise sequences with warnings and address any warnings in the warnings.xml file. See web guidance for detailed instructions.

You must validate your applications prior to submitting to the TGA. See the section in this document headed eCTD preparation tools for further comment on suitable publishing and validation tools.

Sequences with errors or deficiencies

We will not process sequences with validation errors. You will need to re-submit the sequence without validation errors. Evaluation will not proceed until a sequence free of validation errors and been provided. For further information or to discuss specific validation errors please contact esubmissions@health.gov.au.

If your sequence has content deficiencies, you will need to submit changes in a follow-up sequence as part of the application lifecycle.

Naming the eCTD dossier

Name the eCTD dossier after the e-Identifier and include the sequence number.

Example: e123456\0001

Selecting a media format

The size of a sequence is only limited by the size of your media format.

You may use the following media formats for an eCTD sequence to enable the eSubmission to be submitted as one unit:

• Compact Disc-Recordable (CD-R) conforming to the Joliet specification
• Digital Versatile Disc-Random Access Memory (DVD-RAM) Universal Disc Format (UDF) standard
• Digital Versatile Disc-Recordable (DVD+R/-R) recorded in the Universal Disc Format (UDF) standard
• Universal Serial Bus media (2.0 or higher)
• Portable External Hard Drive (USB 2.0 or higher).

We do not return the media.

Do not use:

• passwords
• double-sided discs.

Sending your eCTD dossier

If your sequence is less than 100Mb and you have it ready by the time you complete the online pre-submission application form, you can upload it as a zip file directly into the form.

If the file size is small enough to attach to an email, do so and email it to esubmissions@health.gov.au.

For large file transfers please contact esubmissions@health.gov.au to discuss options.

OTHERWISE

Follow the guidance in Part B of general Dossier requirements located at General dossier requirements: Part B: Electronic dossiers.

Feedback on validation

We will contact you if we have any issues during the validation and/or uploading an eCTD sequence.

Validation of your submission is an automated process. Therefore, the validation result will be sent to the email address(es) indicated in the Envelope. It is the responsibility of the contacts that you nominate to take any required action indicated in the response, as such we recommend that an alternative key contact be listed.

Regional content refers to the Australian specific information to be included within your eCTD application.

• Regulatory requirements and content for module 1 is described within CTD Module 1 and the Document Matrix.

• The validation criteria to support the content is described within the eCTD Validation Criteria spreadsheet: 

  Australian eCTD validation criteria v3.2 [Excel, 25.21 KB]
• Use the eCTD Sequence Matrix to determine what combination of sequence type and sequence description is relevant to your specific sequence.

Module 1 administrative and prescribing information

The ICH Common Technical Document (CTD) specifies that:

• Module 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.
• The AU Module 1 contains folders specific for Medical Device or Apparatus information related to a prescription medicine application. Do not provide this information to Module-3.

File formats refers to the accepted file type for documents within a sequence.

Module 1

In addition to PDF, as defined by the ICH eCTD Specification Document - external site, we will also accept XML, and MS Word Forms.

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, Product Information, 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.

Module 2 to 5

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

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 justification in the Warnings.xml file on the absence of expected Module 1 content, when required.

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 - external site - 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 - external site - 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.

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.

Table 1: Demonstration of baseline as an initial eCTD sequence

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.

Table 2: How to submit multiple baselines later in the eCTD lifecycle

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-sharing

Work sharing allows for a single sequence to be applied across multiple eCTD applications. The information provided within a work sharing transmission must relate to all eCTD applications and is utilised by other regulators to allow common documents to be applied across many eCTD applications. The TGA has considered the use of work-sharing in consultation with Industry stakeholders arriving at the conclusion that the practice has very limited utility due to our eCTD application assignment process. As a result, we do not accept work-sharing sequences.

Work-grouping

Work grouping allows multiple regulatory submissions relating to one eCTD application to be submitted as a single sequence. This format can be used when providing information for bundled minor variation submissions. We do not accept work-grouping sequence types for submissions outside the minor variation application pathway.

To prepare a work grouping sequence, the submission mode must be set to work-grouping within the XML envelope. To support good lifecycle management, we have introduced the sequence description ‘Partial Withdrawal’ {seq-desc-27} to support scenarios where part of a bundled minor variation sequence needs to be withdrawn.

Partial withdrawal of work-grouped minor variation submissions

Partial withdrawal of a bundled eCTD sequence consisting of multiple minor variation submissions is possible with Partial Withdrawal {seq-desc-27}.

Example

ABC Pharmaceuticals has submitted a bundled minor variation sequence consisting of a minor editorial change submission and a general extension of indications submission. After submitting the sequence, the sponsor decided not to progress with the generic extension of indications submission. They submit a partial withdrawal sequence to remove the information relating to it.

Example of an eCTD Application containing of a bundled minor variation partial withdrawal sequence

When providing the sequence, ensure:

• The sequence type is Supplementary Information {seq-type-45} and the sequence description is Partial Withdrawal {seq-desc-27}.
• Relate the sequence to the initial bundled submission sequence.
• Input the number for the submission that will be removed from evaluation as the submission number.
• Remove only the documents associated with the withdrawn minor variation by using the ‘delete’ operator and reference the leaf ID of the document.
• Remove all reference to the withdrawn variation by replacing the documents that reference the submission, excluding the cover letter.
• All removed documents are listed in the cover letter, and an assurance that no changes beyond removing references to the withdrawn variation have been made.
• All validation warnings are justified.

Example of using the delete operator to remove a document

<m1-3-1-1-pi-clean> <leaf ID="a655da252b9d34fcf22ed1fcf39b1c241" operation="delete" checksum=" b6ba67a7740d12bcb938f2850baa584e " checksum-type="md5" modified-file="../../../0044/m1/au/auregional.xml#af3c456d247f0a36e63d" xlink:type="simple"> <title>Expert Dr. C. Smith</title> </leaf>

Example of using the replace operator to replace a document

<m1-3-1-2-pi-annotated> <leaf ID="aa4375bfbf4cc59173b26231705405568" operation="replace" checksum="0d68efc0fee4eb602bc03b485b17263f" checksum-type="md5" modified-file="../../../0044/m1/au/auregional.xml#ad3c456d22424a366646" xlink:href="103-med-info/1031-pi/10311-pi-clean/PI-Doc.pdf" xlink:type="simple"> <title>Expert Dr. D. Smith</title>

Do not:

• Submit partial withdrawals as full withdrawals.
• Remove and re-add documents that are identical as this will affect the lifecycle.
• Provide any additional submissions or data for evaluation within this sequence (this will have to be submitted as a new sequence.)

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 - external site.

We will collect data about the number and size of ICH E3 - external site 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.

Table 3: e-Identifiers and transfer of Sponsor activities/tasks

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.

Justification of validation warnings

When justifying validation warnings, it is no longer necessary to do so within the sequence cover letter. Instead, you should now provide a companion XML document called ‘warnings.xml’ with your sequence to justify these warnings.

Use the following code as an example of how to structure the warnings.xml file:

<warnings-explained>

     <rule number="4.1.24">
          <rule-description> Risk management plan operation</rule-description>
          <comment>Justification of warning text.</comment>
     </rule>
     <rule number="6.22">
          <rule-description>PDF initial view must be correct</rule-description>
          <comment> Justification of warning text.</comment>
     </rule>
</warnings-explained>

Please contact your eCTD tool vendor for advice on implementation.

Failure to provide warnings.xml when your sequence attracts priority warnings (and failure to justify all priority warnings within warnings.xml) will result in a validation error (see criteria 2.10 and 2.11).

Non-priority validation warnings are no longer required to be justified.

List of priority warnings

Backbone file for AU Module 1

The Australian Module 1 eCTD backbone file is comprised of:

• a fixed eXtensible Markup Language (XML) root element
• the envelope elements
• the eCTD heading elements describing the files provided.

Creating the Module 1 eCTD backbone file

To create the Australian Module 1 backbone file for a given sequence:

1. Create an XML file containing the standard XML root element with the appropriate XML declaration using authenticated eCTD preparation software.
2. Create an envelope with elements containing the appropriate metadata values describing this sequence.
3. Create elements as needed for this sequence:
   1. Heading elements, organizing the Module 1 content to meet our review requirements
   2. Leaf elements, providing a file system reference to each file being submitted along with other information such as eCTD check-sum and life-cycle information.
4. Name the Australian Module 1 eCTD backbone file au-regional.xml and place it in the au subfolder within Module 1, i.e. within the m1 subfolder of the sequence.
5. Validate the resulting backbone using a suitable eCTD validation tool.

Style-sheets

The AU Module 1 is provided with a standard style-sheet that:

• can be used to view content
• displays the complete Module 1 table of contents, i.e. all sections, irrespective of whether files are present in those sections
• enables you to use a browser to open the content in Module 1
• is not part of the specification package.

You can submit eCTD applications with or without the style-sheet.

We will not use the style sheet to review content.

The style-sheet is not checked during the validation process.

XML root element

All Australian Module 1 backbone files will contain the standard XML root element.

The required text includes an XML declaration and the root element tga_ectd with its attributes linking this XML file to the XML definition.

The line breaks inside of the tga_ectd element as shown in the following two excerpts are not mandatory.

Excerpt 1: XML root element without style-sheet

The following code shows the root section of the backbone file without a style sheet reference and is the standard for the root section:

<?xml version="1.0" encoding="UTF-8"?>
<tga_ectd schema-version="3.2"
xmlns="tga_ectd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="tga_ectd ../../util/dtd/au-regional.xsd"
xmlns:xlink="http://www.w3.org/1999/xlink" >

Excerpt 2: XML root element with style-sheet

If you use the au-regional.xsl style sheet it must be referenced as follows:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../../util/style/au-regional.xsl" type="text/xsl"?>
<tga_ectd schema-version="3.2"
xmlns="tga_ectd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="tga_ectd ../../util/dtd/au-regional.xsd"
xmlns:xlink="http://www.w3.org/1999/xlink" >

Envelope

The XML envelope is a key part of the eCTD specification. It is reproduced in Table 4 below.

Table 4: XML envelope

^{* The sequence type should only be multiple if the sequence mode is set to work grouping. In all other cases, it should be single.}

^{** The list of values is defined in the schema file and these are: single, work-grouping, work-sharing.}

Submitting multiple values

You need to provide a separate element for each entry when submitting multiple values for envelope elements such as AAN, Product Name and ARTG Number.

Use the following code as an example for the multiple values in the envelope:

<au-envelope>
	<esub-id>e061061</esub-id>
	<client-id>Pharma Inc.</ client-id>
	<aan>Approved Name 1</aan>
	<aan>Approved Name 2</aan>
	<product-name>Product A</product-name>
	<product-name>Product B</product-name>
	<product-name>Product C</product-name>
	<product-name>Product D</product-name>
	<artg-number>123456</artg-number>
	<artg-number>654321</artg-number>
	<submission-number>PM-2017-12345-1-5</submission-number>
	<submission-number>PV</submission-number>
	<sequence-number>0000</sequence-number>
	<related-sequence-number>0000</related-sequence-number>
	<reg-activity-lead code-version="5.0" code="reg-act-lead-6" />
	<sequence-type code-version="5.0" code="seq-type-6" />
	<sequence-description code-version="5.0" code="seq-desc-2" />
	<sequence-type>
	<submission-mode>single</submission-mode>
	<email>contact1@pharma-inc.com</email>
	<email>contact2@pharma-inc.com</email>
</au-envelope>

The defined lists

The defined lists are separate XML files maintained by the TGA containing a standard set of codes for the corresponding envelope element.

These code definition files contain:

• a version number
• a version date
• coded values
• plain texts for each value. Only this value is shown to our evaluators in the review system.

Each coded value:

• has its own assigned version valid-from-version, which defines the first version of the file where this code is valid.
• may also have version information assigned, valid-to-version, which defines an expiration for this code in terms of version number.

<item code=”seq-desc-6” valid-from-version=”0.8” valid-to-version=”0.9”>Response to Request</item>

The XML file specifies:

• a number for each version
• a valid-from for each version
• an expired date (if applicable).

<versions>
	<version number="0.8" valid-from="2014-01-01" expired="2014-04-30" />
	<version number="0.9" valid-from="2014-05-01" expired="2015-12-31" />
	<version number="3.0" valid-from="2015-06-01" expired="2018-06-30" />
	<version number="4.0" valid-from="2018-01-01" expired="2025-07-30" />
	<version number="5.0" valid-from="2024-02-01" />
</versions>

Provide the code attribute value from the appropriate element in the code definition file. Provide the version of the XML file as the code-version attribute value in the appropriate element in the au-regional.xml file. See the example XML code under Submitting multiple values.

We will validate sequences to ensure that codes are valid according to the version information.

e-Identifier

Enter this identifier as assigned in the envelope and use it as the name for the eCTD application folder which contains sequence folders.

Example: e123456

eBS Client ID

The applicant’s eBS client ID as used in the eBS client database.

Example: 181

Approved name(s)

The approved name(s) of the ingredient(s) - AAN, ABN, etc. as applicable - as they appear in the Australian Approved Names list.

Example: 100604 amoxicillin.

Trade name(s)

The name or proposed medicine (trade) name to be used on the Certificate of Registration.

Example: incrediPill.

For Master Files, insert name of manufacturing site.

ARTG number

ARTG numbers should be supplied when known, typically for variations to an already registered good. This can be a four-, five- or six-digit number.

Example: 123456

Submission number(s)

The submission number(s) or application number(s) applicable to the sequence being submitted. These should be provided as follows:

• PM-2017-12345-1-5 Prescription medicines submission numbers: Prefix PM followed by the submission number and stream. If the submission number is not yet known it is appropriate to only include the prefix and the stream i.e., PM-1. NOTE that this will apply whether the activity refers to a biological medicine or other molecular type (‘chemical’ medicine).
• BA-2017-12345-1 Biologicals submission numbers: Prefix BA followed by the submission number. If the submission number is not yet known it is appropriate to only include the prefix e.g. BA.
• OM-2017-12345-1 OTC medicines submission numbers: Prefix OM followed by the submission number. If the submission number is not yet known it is appropriate to only include the prefix e.g. OM.
• Complementary Medicines: For registered complementary medicines the same protocol applies as for OTC medicines as detailed above. For listed complementary medicines no validation is planned at this time.
• PV Pharmacovigilance: No submission number is assigned; PV should be entered for all sequences where pharmacovigilance information is submitted.
• MF Master Files: No submission number is assigned; MF should be entered for all sequences where master file information is submitted.
• MD Medical Devices: Depending on whether the eCTD application is a device application or a conformity assessment, the prefix should be DA or DC e.g. DA-2017-12345-1.

Allowable combinations of the above are:

• PM with PV or MF;
• BA with PV or MF;
• OM with PV;
• PV with PM, BA, or OM;
• MF with PM or BA.

Sequence number

Four-digit sequence number matching the sequence folder being submitted.

Example: 0002

Note that we would not expect the sequence number 0000 to be used unless submitting a baseline sequence. The initial sequence of a regulatory activity should always be 0001.

Related sequence number

The related sequence number is used to group sequences.

This enables us to easily evaluate sequences associated with a particular regulatory activity.

All sequences that belong to a specific regulatory activity should contain the same four-digit number in the related sequence number field as demonstrated in the table:

Table 5: All sequences must contain the same four-digit number in the related sequence number field

Each Initial sequence of a regulatory activity will reference itself.

Each Supplementary Information thereafter will reference the initial sequence of the regulatory activity.

The related sequence number should be approached similar to the Submission ID described in the US regional specification - external site.

Regulatory activity lead

The regulatory activity lead identifies the group within the TGA which is expected to take the lead in the review process.

Example: OTC

This example shows how to specify the regulatory activity lead for an OTC medicine. The code for “OTC” is reg-act-lead-4 as specified in the defined list which is identified in ‘related information and guidance’ below.

<reg-activity-lead code-version=”5.0” code=”reg-act-lead-4” />

The code version must be specified as an attribute code-version of the regulatory activity lead element.

The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).

Related information and guidance

Reg-activity-lead - Official defined list for Regulatory Activity Lead

Sequence type

The sequence type identifies the type of activity that is being submitted, either:

• the regulatory activity type (for the first sequence of the regulatory activity)
• the supplementary information for the follow-up sequences of a regulatory activity that has already commenced.

Example: Sequence type

This example shows how to specify the regulatory activity lead for a new chemical entity. The code for “New chemical entities” is seq-type-1 as specified in the defined list (see URL given above):

<sequence-type code-version=”5.0” code=”seq-type-1” />

The code version must be specified as an attribute code-version of the sequence-type element. The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).

Related information and guidance

• sequence-type - external site - Official defined list for Sequence Type
• sequence matrix - A summary of which sequence descriptions can be used in combination with which sequence types.

Sequence description

Content description for the submitted sequence should be one of the values from sequence-description.

Refer to the sequence description  for the current list of values.

The examples listed below are a subset of the overall list and show how to handle the different approaches.

1. You can use some values without further information - for example, Initial.
2. You enter both the start and end dates for some values - for example, PSUR for Period of 2015-01-01 to 2015-06-30.
3. You add a brief description (fewer than 40 characters) for other values - for example, Uncategorised, DESCRIPTION.

Example 1: Initial sequence

This example below shows how to specify the sequence description element for an initial sequence. The code for “Initial” is seq-desc-2 as specified in sequence-description.

<sequence-description code-version=”5.0” code=”seq-desc-2” />

Example 2: PSUR with start and end dates

This example shows how to specify the sequence description element for a PSUR sequence with a PSUR start date of 2015-01-01 and a PSUR end date of 2015-06-30.

The code for “PSUR” is seq-desc-20 as specified in the defined list sequence-description, where the complete text is defined as follows:

PSUR for Period of {from-date:d} to {to-date:d}

In this text, two placeholders have been specified:

• the from-date
• the to-date.

Both placeholders require an actual value in date format (because of the letter 'd' following the colon).

These values have to be specified through data child elements of the sequence-description element as shown:

<sequence-description code-version=”5.0” code=”seq-desc-20”>
	<data use=”from-date”>2024-06-01</data>
	<data use=”to-date”>2024-12-01</data>
</sequence-description>

The code version must be specified as an attribute code-version of the sequence-description element. The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).

Example 3: Uncategorised sequence

This example shows how to specify the sequence description element for an uncategorized sequence.

The code for “uncategorized” is seq-desc-24 as specified in sequence-description, where the complete text is defined as follows:

Uncategorised, {description:s}

In this case, according to the defined list, a brief description text is required as additional data. The name of the placeholder is description.

It requires a value in plain text (sometimes referred to as a “string” in computer speak) which is indicated by the letter “s” following the colon.

The value has to be specified through a data child element of the sequence-description element as shown:

<sequence-description code-version=”5.0” code=”seq-desc-24”>
	<data use=”description”>This is a brief description</data>
</sequence-description>

The code version must be specified as an attribute code-version of the sequence-description element.

The code version refers to the version of the defined list being referenced (the version attribute of the codes element therein).

Related information and guidance

• sequence-description - external site - Official defined lists for Sequence Description
• Sequence Matrix - external site - A summary of which sequence descriptions can be used in combination with which sequence types.

Submission mode

The submission mode must be single or work sharing. If the sequences type is ‘Supplementary information’, the submission mode must be the same as in the related sequence.

Contact email

Sequences received will ultimately be validated through an automated process. Results of the validation will be sent to the email addresses provided. This email address will be contacted regarding any issues with validation of the sequence.

See the example XML code under Submitting multiple values.

It is the responsibility of the applicant to ensure that the email addresses provided in the envelope can receive emails with attachments, e.g. zip files, and that these emails do not get lost in SPAM.

Heading elements

The next 12 tables list the heading elements of the Australian CTD Module 1 v3.2.

Content under the following headings should be provided when required as defined in the Document Matrix, relative to sequence-type.

Table 6: Heading element 1.0 - Correspondence

Table 7: Heading element 1.2 - Administrative information

Table 8: Heading element 1.3 - Medicine information and labelling

^{*The section ID for Package insert has been updated but the element has been maintained to be consistent with previous specification versions.}

Provide the Product Information and Consumer Medicine Information in PDF format within the eCTD. Do not include working documents previously associated with NeeS submissions as they are not needed - for example, Microsoft Word source documents.

Table 9: Heading element 1.4 - Information about the experts

Table 10: Heading element 1.5 - Specific requirements for different types of applications

^{*The business terminology for Designation applications – supporting documents has been updated but the element has been maintained to be consistent with previous specification versions.}

The 'document-matrix' XML file on the electronic submissions web page of the TGA website provides more information as to when documents are expected under these headings. In particular:

• 1.5.5 -Co-marketed medicines declarations should include the ‘Letters of authorisation’.
• 1.5.6 - Combination medicine consent is relevant to prescription medicine applications.
• 1.5.7 - OTC product assurances are relevant to OTC applications.
• 1.5.8 - Umbrella brand assessment is relevant to OTC applications.

Table 11: Heading element 1.6 - Master files and certificates of suitability

Table 12: Heading element 1.7 - Compliance with meetings and pre-submission processes

Table 13: Heading element 1.8 - Information relating to pharmacovigilance

Table 14: Heading element 1.9 - Summary of biopharmaceutic studies

Table 15: Heading element 1.10 - Information relating to paediatrics

Table 16: Heading element 1.11 - Foreign regulatory information

Table 17: Heading element 1.12 - Antibiotic resistance data

Table 18: Heading element 6.1 - Medical Device

We have added M6.1 to the AU Module-1 folder structure to accommodate information relating to any medical device, apparatus or diagnostic aid associated with a combination application. The term “Medical Device” is not intended to be limiting in scope.

Node extensions and leaf elements

Make title elements short, precise and informative. Do not repeat information already categorized by heading elements.

Place the most important identifying/distinguishing information at the beginning so we do not have to scroll to the end of the title.

You can repeat the optional node extension and leaf elements as required. The schema will ensure the checksum-type attribute contains either ‘MD5’ or ‘md5’.

Node extensions

You can use node-extension elements:

• to define structures beyond the heading elements.
• wherever a leaf element is allowed in the schema.
• to organise multiple files which are needed under a normal eCTD heading.

The node-extension structure complies with general ICH eCTD specifications - external site, but it is not a blanket permission to use the structures anywhere or without consideration. You may email esubmissions@health.gov.au for advice if the usage is novel.

The optional node-extension element contains a single mandatory title element, followed by at least one leaf element, and can be followed by another optional node-extension element.

Leaf elements

The leaf elements provide the content for each heading element.

This optional element contains, the title element along with a number of attributes, all based upon the ICH eCTD definition provided in the Electronic Common Technical Document Specification (Version 3.2.2) - external site.

Lifecycle operations

The following four lifecycle operations defined under the ICH eCTD specification - external site:

• New
• Replace
• Delete
• Append.

We encourage you to:

• Use New, Replace, and Delete.
• Only use Append as part of the study tagging files (STF) as defined by the ICH eCTD Backbone File Specification for Study Tagging Files - external site. If you use Append for any other purpose, you will:
  • receive a validation warning
  • need to include an explanation in the warnings.xml file.

Specific lifecycle operations for Australia

The nodes with specific lifecycle operations mandated for an Australian eCTD are summarised in Table 19.

Table 19: Nodes with specific lifecycle operations

^{*Except the first time we receive a document in which case the attribute should be ‘New’.}

For 1.8.2 use the lifecycle operator replace for Risk management plans. However in some instances, replace may not be appropriate - for example, when a new draft Risk management plan is submitted for consideration. When a final document is submitted, it will replace the draft. Thus it should be clear which Risk management plan is the current approved plan. If you use the lifecycle operator new, you:

• will receive a validation warning

Files and folders

File and folder naming conventions

Naming conventions for the content files are not part of the validation criteria for eCTD.

You may use files submitted in other regions without re-naming, but:

• ensure all content is referenced by the appropriate XML files for efficient navigation
• provide precise but informative leaf titles to aid reviewers
• ensure the basic construction of the eCTD is maintained
• adhere to the naming conventions as described in Table 20

Naming conventions matrix

Table 20: Naming conventions matrix

Folder and file name - path length

Ensure the overall length of the folder and file name path, starting from the sequence number, does not exceed 180 characters, for any file in any module.

We acknowledge it is less than the ICH agreed overall path length.

We do not mandate or recommend any particular software to prepare an eCTD submission.

We recommend you, as the applicant:

• Prepare the eCTD using an authenticated commercial eCTD preparation software package.
  There is a wide variety of options available, both in terms of multiple vendors and of approaches - for example:
  • installed software
  • software as a service
  • service providers.
• Find a solution which supports current and ongoing AU eCTD requirements and meets your overall business needs.
• Validate the prepared regulatory activity using an authenticated commercial eCTD validation tool.

These validation tools are not just XML checkers or parsers, but evaluate the technical content of each sequence. We recommend, you use a validation tool that:

• supports checking current and ongoing AU eCTD requirements
• minimises the possibility of technical validation errors which can cause delays in the overall regulatory process.

We have used the World Wide Web Consortium (W3C) Schema approach to define the updated Module 1.

The following documents were referenced during the creation of this specification:

• EU Module 1 eCTD Specification - external site
• Guidance Document: Creation of the Canadian Module 1 Backbone - external site
• The eCTD Backbone Files Specification for US Module 1 - external site

Factors that could affect the content of the specification include, but are not limited to:

• change in the content of the Module 1 for the CTD
• update of standards that are already in use within the eCTD
• new standards for the creating and/or using eCTD
• new functional requirements
• experience with using eCTD, in particular Module 1.

We will:

• provide a practical timeframe for future changes to minimize impact on industry.
• introduce changes at scheduled intervals to allow stability.

Please send any feedback, comments or questions to esubmissions@health.gov.au.