AU eCTD specification: Module 1 and regional information

Version 3.0

14 April 2015

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

This guidance:

  • applies to all regulatory activities[1] provided to us in eCTD[2] format
  • needs to be used with the ICH eCTD Specification to prepare a valid eCTD submission[3].

In this guidance


Footnotes

  1. A subgroup of an Application which can be a group of related sequences for one approval or notification process. Usually defined for the lifecycle of the specific approval process.
  2. electronic Common Technical Document
  3. generic term that refers to an application, a regulatory activity type and/or a sequence. Often used when not referring specifically to a particular hierarchical level of the application

Business protocol for preparing for your eCTD transaction

Version 3.0

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

Obtaining the eSubmission identifier

eCTD submissions rely on the eSubmission Identifier to create the top level folder. This then forms the anchor for subsequent sequences and relative file referencing so that hyperlinks can refer to previously submitted documents. Applicants who have chosen the eCTD format must continue in the eCTD format for all future regulatory activities.

You will need an eSubmission identifier before you submit your first regulatory activity[4] for an application[5] in eCTD format.

To obtain an eSubmission identifier:

  • send an email to esubmissions@tga.gov.au
  • include the following information in your email:
    • the applicant's name as listed in the eBS client database
    • Name of medicine (the AAN[6] or proposed AANs) or subject of Master File
    • a description of the Application (application type, dosage form), if referring to a medicine
    • Name and address of manufacturing site, if referring to a Master File.

The identifier is:

  • made up of a letter and six digits. Example: e123456
  • valid throughout the entire lifecycle of a product unless split from a package as explained elsewhere.

eSubmission identifiers when transferring sponsorship

If all products included under an eSubmission Identifier are transferred to a new sponsor, the eSubmission Identifier and the related sequences[7] are transferred to the new sponsor.

Acquiring sponsor

The eSubmission Identifier will transfer with the medicine, unless:

  • there were multiple medicines submitted under the same eSubmission Identifier

and

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

In the case the partial transfers, we will assign new eSubmission 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 eSubmission Identifier (see Table 1). This will indicate to evaluators that the medicine was initially reviewed under a different identifier.

Make sure you include the eSubmission Identifier of the previous application in the cover letter of the new application.

Relinquishing sponsor

The further 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 1 eSubmission Identifiers and transfer of Sponsor activities/tasks
Sponsor
FFF
Sponsor
PPP
Sponsor
YYY
Activity/Task

Product A

Product B

Product C

Product D

e000111Text

0001 Application for Products A, B, C and D from Sponsor FFF
0002 A regulatory activity or notification

Product A

Product B

e000111

Product C

Product D

e000222

0003 PPP submits first sequence as 0003 referencing the transfer from e000111 and submitting a regulatory activity.
0003 0004 Companies FFF and PPP undertake business as usual

Product A

Product B

e000111

Product C

e000222

Product D

e000333

0005 YYY submits first sequence as 0005 referencing e000222
0004 0005 0006 Companies FFF, PPP and YYY undertake business as usual

Preparing the eCTD cover letter

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

  • the eSubmission 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
    • any findings e.g. errors, warnings or possible missing documents as designated by the eSubmission Document Matrix that would be expected for your specific sequence type
  • a paper copy of the Cover Letter should be included with the physical media containing the eCTD[8]. 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

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.
  • 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 eSubmission Document Matrix that might be required in a sequence
    • information about unusual lifecycle operations
    • information about study tagging files submitted, etc.

Please minimise sequences[9] with warnings and address any warnings in the Cover Letter.

We recommend you use one of the validation tools on our website to validate your applications prior to submitting to us.

Sequences with errors or deficiencies

We will reject sequences with validation errors and you will need to re-submit unless you gain our agreement.

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

Related information and guidance

File: Australian eCTD Regional Specification and Validation Criteria.xls located at Electronic submissons - Validation.

Structuring the application folder

Use an application[5] folder named after the eSubmission identifier and include the sequence folder(s) as sub-folder(s) with their contents.

Example - D:\e123456\0001.

Selecting a media format

The size of an eSubmission is only limited by the size of your media format.

You may use the following media formats for an eCTD sequence regulatory activity 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 application

Pack the cover letter and media securely prior to sending.

For Australia Post

Send to our postal address:

Electronic Submissions
Therapeutic Goods Administration
PO Box 100
Woden ACT 2606 Australia

You can request proof of delivery from Australia Post for packages sent by Express Post.

For courier services

Send to our site address:

Electronic Submissions
Therapeutic Goods Administration
136 Narrabundah Lane
Symonston ACT 2609 Australia

Your submission package is traceable by the courier company throughout transport and delivery, and you can request proof of delivery from your courier.

Feedback on validation of application

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


Footnotes

  1. The term Regulatory Activity is a subgroup of an Application which can be a group of related sequences for one approval or notification process - for example, one variation. One Regulatory Activity is usually defined for the lifecycle of the specific approval process.
  2. The term Application in relation to TGA's medicine registration process and is the top group of a series of sequences for the same product - for example, active ingredient. One Application is usually defined for the complete life cycle of the specific product.
  3. Australian Approved Name
  4. A package of information bundled together in an electronic structure providing information to the agency
  5. electronic Common Technical Document
  6. A package of information bundled together in an electronic structure providing information to the agency

AU regional content

Version 3.0

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

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

Table 2 File formats that can be included in Module 1.
Section ID Business Terminology File Format
1.0 Correspondence
1.0.1 Cover letter XML*, PDF
1.0.2 Lifecycle management tracking table XML*, PDF
1.2 Administrative Information
1.2.1 Application forms XML*, PDF
Other XML*, PDF

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

Table 3 Demonstration of baseline as an initial eCTD sequence
Sequence Sequence Type Sequence Description Related Sequence
0000 Baseline Reformat 0000
0001 C-Extension of Indication of COPD Initial 0001
0002 Supplementary information Response to Request for Information 0001
0003 H-Minor Variation, Not Resulting in a New Register Entry Initial 0003
0004 F-Major Variation - New Strength Initial 0004

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.

Table 4 How to submit multiple baselines later in the eCTD lifecycle
Sequence Sequence Type Sequence Description Related Sequence
0001 J-PI Change with Data Initial 0001
0002 C-Extension of Indication Initial 0002
0003 Supplementary information Response to Request for Information 0001
0004 Baseline Reformat 0004
0005 F-Major Variation - New Strength Initial 0005
0006 Baseline Reformat 0006
0007 G-Minor Variation, New Register Entry - Change of Formulation Initial 0007
0008 Supplementary information Response to Request for Information 0005

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.


Footnotes

  1. Additional heading structures beyond those defined by the specifications - generally equated to an additional subfolder in a defined section
  2. In this and related documents, this is a generic term that can refer to an application, a regulatory activity type and/or a sequence. Often used when not referring specifically to a particular hierarchical level of the application.
  3. A package of information bundled together in an electronic structure providing information to the agency
  4. In this and related documents, this is a generic term that can refer to an application, a regulatory activity type and/or a sequence. Often used when not referring specifically to a particular hierarchical level of the application.

AU Module 1 general architecture

Version 3.0

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

Backbone file for Australian 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[14]:

  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:
    • Heading elements, organizing the Module 1 content to meet our review requirements
    • Leaf[15] 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.0"
    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.0"
    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 elements

Table 5 XML envelope elements
XML Element Description Constraint Occurrence Defined List
esub-id eSubmission Identifier Mandatory Single
applicant Applicant Mandatory Single
aan Australian Approved Name(s) Mandatory Multiple
product-name[16] Product Name Mandatory Multiple
artg-number ARTG Number Optional[17] Multiple
sequence-description Sequence Description Mandatory Single Yes
sequence-number Sequence Number Mandatory Single
related-sequence-number Related Sequence Number Mandatory Single
reg-activity-lead Regulatory Activity Lead Mandatory Single Yes
sequence-type Sequence Type Mandatory Single Yes

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>
  <applicant>Pharma Inc.</applicant>
  <aan>AAN 1</aan>
  <aan>AAN 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>
  <sequence-type code-version="3.0" code="seq-type-6" />
  <reg-activity-lead code-version="3.0" code="reg-act-lead-6" />
  <sequence-number>0000</sequence-number>
  <sequence-description code-version="3.0" code="seq-desc-2" />
  <related-sequence-number>0000</related-sequence-number>
</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"/>
</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 submissions to ensure that codes are valid according to the version information in a submission.

eSubmission Identifier

Make sure you have obtained your eSubmission Identifier prior to submitting the first sequence of an eCTD.

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

Applicant

The applicant name as listed in the eBS client database.

Example: Pharma Inc.

Australian approved name(s)

The name of the active ingredients that are accepted for inclusion in the Australian Approved Name list.

Example: amoxicillin.

Product name

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

Example: incrediPill.

ARTG number

All applicable ARTG numbers (if available). This can be a four-, five- or six-digit number.

Example: 123456

Sequence description

Content description for the submitted sequence[19] 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.

Example 1 You can use some values without further information - for example, Initial.
Example 2 You will be required to combine some values with a date - for example, Response to Request for Information - 2014 03 30.
Example 3 You enter both the start and end dates for some values - for example, PSUR for Period of 2015-01-01 to 2015-06-30.
Example 4 You add a brief description (under 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="3.0" code="seq-desc-2" />
Example 2 - Response to a request for information

This example shows how to specify the sequence description element for responding to a request for information.

The code is seq-desc-5 as specified in sequence-description, where the complete text is defined as follows:

Response to Request for Information - {date:d}

In this case, a date is required as additional data. The name of the placeholder is date.

It requires an actual value in date format (because of the letter d 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="3.0" code="seq-desc-5">
  <data use="date">2015-06-01</data>
</sequence-description>

Use the format YYYY-MM-DD for the actual date value wherever a date type placeholder is defined in the code lists.

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

Example 3 - 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="3.0" code="seq-desc-20">
  <data use="from-date">2015-06-01</data>
  <data use="to-date">2015-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 4 - 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="3.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).

Sequence number

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

Example: 0000

Related sequence number

The related sequence number is used to group sequences[20] within an eSubmission.

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 Table 6.

Table 6 All sequences must contain the same four-digit number in the related sequence number field
Sequence Related Sequence Sequence Type Sequence Description
0001 0001 New Chemical Entity Initial
0002 0001 Supplementary Information Response to Request for Information
0003 0001 Supplementary Information Response to Request for Information
0004 0004 F - Major Variation - New Dosage Form Initial
0005 0005 Self-Assessment Review (SAR) Initial
0006 0006 G - Minor Variation, New Register Entry - New Container Type Initial
0007 0004 Supplementary Information Response to Request for Information
0008 0004 Supplementary Information Response to Request for Information
0009 0004 Supplementary Information Product Information
0010 0006 Supplementary Information Product Information

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

Regulatory activity lead

The regulatory activity lead identifies the group within the TGA which is expected to take the lead in the review process. Refer to this list for current list values.

Example: Prescription

This example shows how to specify the regulatory activity lead for a prescription medicine. The code for 'Prescription' is reg-act-lead-6 as specified in the defined list (see URL given above):

<reg-activity-lead code-version="3.0" code="reg-act-lead-6" />

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

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 regulatory activity.
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="3.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

Heading elements

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

Table 7 Heading element 1.0 - Correspondence
Section ID Business Terminology XML-Element
1.0 Correspondence m1-0-correspondence
1.0.1 Cover letter m1-0-1-cover
1.0.2 Lifecycle management tracking table m1-0-2-tracking-table
1.0.3 Response to Request for Information m1-0-3-response
Table 8 Heading element 1.2 - Administrative information
Section ID Business Terminology XML-Element
1.2 Administrative Information m1-2-admin-info
1.2.1 Application forms m1-2-1-app-form
1.2.2 Pre-submission details m1-2-2-pre-sub-details
1.2.3 Patent certification m1-2-3-pat-cert
1.2.4 Change in sponsor m1-2-4-change-sponsor
Table 9 Heading element 1.3 - Medicine information and labelling
Section ID Business Terminology XML-Element
1.3 Medicine information and labelling m1-3-med-info
1.3.1 Product information and package insert m1-3-1-pi
1.3.1.1 Product information - clean m1-3-1-1-pi-clean
1.3.1.2 Product information - annotated m1-3-1-2-pi-annotated
1.3.1.3 Package insert m1-3-1-3-pack-ins
1.3.2 Consumer medicines information m1-3-2-cmi
1.3.2.1 Consumer medicines information - clean m1-3-2-1-cmi-clean
1.3.2.2 Consumer medicines information - annotated m1-3-2-2-cmi-annotated
1.3.3 Label mock-ups and specimens m1-3-3-mockup

Provide the Product information and Consumer medicines 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 10 Heading element 1.4 - Information about the experts
Section ID Business Terminology XML-Element
1.4 Information about the experts m1-4-experts
1.4.1 Quality m1-4-1-quality
1.4.2 Nonclinical m1-4-2-nonclinical
1.4.3 Clinical m1-4-3-clinical
Table 11 Heading element 1.5 - Specific requirements for different types of applications
Section ID Business Terminology XML-Element
1.5 Specific requirements for different types of applications m1-5-specific
1.5.1 Literature-based submission documents m1-5-1-lit-based
1.5.2 Orphan drug designation m1-5-2-orphan
1.5.3 Genetically modified organisms consents m1-5-3-gmo
1.5.4 Additional trade name declarations m1-5-4-trade-name
1.5.5 Co-marketed medicines declarations m1-5-5-co-marketed
1.5.6 Combination medicine consent m1-5-6-comb-med
1.5.7 OTC product assurances m1-5-7-prod-assurance
1.5.8 Umbrella brand assessment m1-5-8-umbrella

The Australian eCTD regional specification and validation criteria 3.0 provides more information as to when documents are expected under these headings, see the tab 'eSubmission Document Matrix'. 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 12 Heading element 1.6 - Master files and certificates of suitability
Section ID Business Terminology XML-Element
1.6 Master files and certificates of suitability m1-6-master-files
1.6.1 Relevant external sources m1-6-1-ext-sources
1.6.2 Applicant's declaration m1-6-2-app-decl
1.6.3 Letters of access m1-6-3-loa
Table 13 Heading element 1.7 - Compliance with meetings and pre-submission processes
Section ID Business Terminology XML-Element
1.7 Compliance with meetings and pre-submission processes m1-7-compliance
1.7.1 Details of compliance with pre-submission meeting outcomes m1-7-1-pre-sub
1.7.2 Details of any additional data to be submitted m1-7-2-add-data
1.7.3 Declaration of compliance with pre-submission planning form and planning letter m1-7-3-planning
Table 14 Heading element 1.8 - Information relating to pharmacovigilance
Section ID Business Terminology XML-Element
1.8 Information relating to pharmacovigilance m1-8-pv
1.8.1 Pharmacovigilance systems m1-8-1-pv-systems
1.8.2 Risk management plan m1-8-2-risk
Table 15 Heading element 1.9 - Summary of biopharmaceutic studies
Section ID Business Terminology XML-Element
1.9 Summary of biopharmaceutic studies m1-9-biopharm
1.9.1 Summary of bioavailability or bioequivalence study m1-9-1-ba-be
1.9.2 Justification for not providing biopharmaceutic studies m1-9-2-justification
Table 16 Heading element 1.10 - Information relating to paediatrics
Section ID Business Terminology XML-Element
1.10 Information relating to paediatrics m1-10-paediatrics
Table 17 Heading element 1.11 - Foreign regulatory information
Section ID Business Terminology XML-Element
1.11 Foreign regulatory information m1-11-foreign
1.11.1 Foreign regulatory status m1-11-1-status
1.11.2 Foreign product information m1-11-2-pi
1.11.3 Data similarities and differences m1-11-3-similarities
1.11.4 Foreign evaluation reports m1-11-4-eval-reports
Table 18 Heading element 1.12 - Antibiotic resistance data
Section ID Business Terminology XML-Element
1.12 Antibiotic resistance data m1-12-antibiotic

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 information at the beginning so we do not have to scroll to the end of the title.

You can repeat the optional node extension[21] and leaf[22] 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, but it is not a blanket permission to use the structures anywhere or without consideration. You may email esubmissions@tga.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.

The 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).

Lifecycle operations

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

  • New
  • Replace
  • Delete
  • Append.

We encourage you to:

Specific lifecycle operations for Australia

The nodes with specific lifecycle operations mandated for an Australian eCTD are summarized in the following table.

Table 19 Nodes with specific lifecycle operations mandated for an Australian eCTD
Section ID Business Terminology Lifecycle Operation Validation
1.0 Correspondence
1.0.1 Cover letter New Error*
1.0.2 Lifecycle management tracking table Replace** Error*
1.8 Information relating to pharmacovigilance
1.8.2 Risk management plan Replace** Warning*
1.11 Foreign regulatory information
1.11.1 Foreign regulatory status Replace** Error*
Any use of Append outside the defined usage in Study Tagging Files Warning*

*That is, if the condition is not satisfied then validation generates an Error or Warning as indicated.

**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
  • need to include a justification in the cover letter.

Files and folders

File and folder naming conventions

Naming conventions for the content files are not part of the validation criteria for eCTDs submitted to us.

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[23] titles to aid reviewers
  • ensure the basic construction of the eCTD is maintained
  • adhere to the naming conventions as described in the next table.
Table 20 Naming conventions matrix
Folder File Description
e123456   Application folder with eSubmission Identifier e.g. e123456
  0000       Sequence folder with four-digit sequence number e.g. 0000
        index.xml Index file in accordance with ICH
        index-md5.txt MD5 checksum in accordance with ICH
    m1     Content folder for Module 1 documents in accordance with ICH
      au   Australia country specific folder
        au-regional.xml Australia regional index file for Module 1
    m2     Content folder for Module 2 documents in accordance with ICH
    m3     Content folder for Module 3 documents in accordance with ICH
    m4     Content folder for Module 4 documents in accordance with ICH
    m5     Content folder for Module 5 documents in accordance with ICH
    util     Util folder in accordance with ICH
      dtd   DTD and schema folder in accordance with ICH
        au-regional.xsd Australia regional backbone schema for Module 1
        xlink.xsd W3C schema for XLink 1.1 (referenced from au-regional.xsd)
        xml.xsd W3C schema for XML namespace (referenced from au-regional.xsd)
        ich-ectd-3-2.dtd ICH DTD for Modules 2 to 5
      style   Style sheet folder in accordance with ICH (optional)
        ectd-2-0.xsl ICH style sheet for Modules 2 to 5 (optional)
        au-regional.xsl Style sheet for Australian regional backbone (optional)

Folder and file name path length

Ensure the overall folder and file name path length 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.


Footnotes

  1. A sequence is a package of information bundled together in an electronic structure providing information to the agency. The contents of a sequence will depend on the regulatory activity type and whether it is the initial sequence of the regulatory activity or a follow-up providing additional data or changes.
  2. Structural element of an eCTD submission delivering a document. It provides the link information to the document along with the title associated with the linked content
  3. For Master Files, insert name of manufacturing site.
  4. ARTG numbers should be supplied when known, typically for sequences submitted after regulatory approval.
  5. The term Application in relation to TGA's medicine registration process and is the top group of a series of sequences for the same product - for example, active ingredient. One Application is usually defined for the complete life cycle of the specific product.
  6. A sequence is a package of information bundled together in an electronic structure providing information to the agency. The contents of a sequence will depend on the regulatory activity type and whether it is the initial sequence of the regulatory activity or a follow-up providing additional data or changes.
  7. A package of information bundled together in an electronic structure providing information to the agency
  8. Additional heading structures beyond those defined by the specifications - generally equated to an additional subfolder in a defined section
  9. Structural element of an eCTD submission delivering a document. It provides the link information to the document along with the title associated with the linked content
  10. Structural element of an eCTD submission delivering a document. It provides the link information to the document along with the title associated with the linked content

eCTD preparation tools

Version 3.0

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

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.

    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 the regulatory activity. 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.

Vendors of validation tools that demonstrate their tools are in-line with validation criteria will be added to the list on our website.

Change control

Version 3.0

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

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

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

How to access a pdf document

*Large file warning: Attempting to open large files over the Internet within the browser window may cause problems. It is strongly recommended you download this document to your own computer and open from there.

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@tga.gov.au.

Version history

Version 3.0

Please note: This version (V3.0) of the specification is acceptable until 30 June 2018. Version V3.1 becomes effective on 1 January 2018.

When new versions are released, there will be an implementation of at least six months in which we will accept both the new and old versions of the specifications to allow planning and software updates.

The AU eCTD version 3.0 specification will be effective starting 1 June 2015.

The AU eCTD version 0.90 specification will be accepted until 31 December 2015.

Version 3.0 is the first official eCTD version for Australia.

  • The initial version of this specification was identified as 0.90 to indicate its draft status.
  • Versions 1.0 and 2.0 have been skipped to avoid confusion with past CTD guidance.
Table: Version history
Version Description of change Author Effective date
V0.90 Original draft publication for pilot implementation and industry review Group Support Unit
Market Authorisation Group
01/07/2014
V3.0

AU eCTD specification for official use.

Version 3.0 aligns the numbering for CTD specifications (previously 2.2) and NeeS specifications (previously 1.0) to bring all formats under one version number

Regulatory Operations Unit
Market Authorisation Division
01/04/2015