You are here

eCTD AU module 1 and regional information

Specification and guidance for use, V3.1

18 October 2017

Book pagination

AU Module 1 general architecture

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

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:
    • Heading elements, organizing the Module 1 content to meet our review requirements
    • 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.
    • 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.
    • 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.1"
    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.1"
    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
XML Element Description Constraint Occurrence Defined List
esub-id e-Identifier Mandatory Single  
client-id eBS Client ID Mandatory Single  
aan Approved Name(s) Mandatory Multiple  
product-name Trade Name(s) Mandatory Multiple  
artg-number ARTG Number(s) Optional Multiple  
submission-number Submission or Application Number(s) Mandatory Multiple  
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 Multiple* Yes
sequence-type/sequence-description Sequence Description Mandatory Single Yes
submission-mode Submissions mode Mandatory Single Yes**
work-sharing   Optional Multiple  
work-sharing/esub-id Work sharing e-Identifier Mandatory Single  
work-sharing/submission-number Work sharing submission number Mandatory Multiple  
work-sharing/sequence-number Work sharing sequence number Mandatory Single  
email Contact Email Mandatory Multiple  

* 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="4.0" code="reg-act-lead-6" />
  <sequence-type code-version="4.0" code="seq-type-6" />
  <sequence-description code-version="4.0" code="seq-desc-2" />
  <sequence-type>
  <submission-mode code-version="4.0" code="seq-desc-1" />
  <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="4.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 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.

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

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="4.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).

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="4.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).

  • sequence-type - 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 will be required to combine some values with a date - for example, Response to Request for Information - 2014-03-30.
  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.
  4. 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="4.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 (as indicated by 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="4.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="4.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).

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

Submission mode

Until the work grouping and work sharing functions are sufficiently developed, the only valid mode is 'single' which denotes a single regulatory activity.

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

Content under the following headings should be provided when required as defined in the Sequence Matrix.

Table 6 Heading element 1.0 - Correspondence
Section ID Business Terminology XML-Element
1 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 7 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 8 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 Product information - approved m1-3-1-3-pi-approved
1.3.1.4 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.2.3 Consumer medicines information - approved m1-3-2-3-cmi-approved
1.3.3 Label mock-ups and specimens m1-3-3-mockup
1.3.3.1 Label mock-ups and specimens - clean m1-3-3-1-mockup-clean
1.3.3.2 Label mock-ups and specimens - annotated m1-3-3-2-mockup-annotated
1.3.3.3 Label mock-ups and specimens - approved m1-3-3-3-mockup-approved

*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 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 9 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 10 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 Designation applications - supporting documents 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 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
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 12 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 13 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 14 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 15 Heading element 1.10 - Information relating to paediatrics
Section ID Business Terminology XML-Element
1.10 Information relating to paediatrics m1-10-paediatrics
Table 16 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 17 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/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, 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).

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 summarised in Table 18.

Table 18 Nodes with specific lifecycle operations
Section ID Business Terminology Lifecycle Operation
1.0 Correspondence  
1.0.1 Cover letter New
1.0.2 Lifecycle management tracking table Replace*
1.3 Medicine information and labelling  
1.3.1.1 Product information - clean Replace*
1.3.1.2 Product information - annotated Replace*
1.3.1.3 Product information - approved Replace*
1.3.2.1 Consumer medicines information - clean Replace*
1.3.2.2 Consumer medicines information - annotated Replace*
1.3.2.3 Consumer medicines information - approved Replace*
1.3.3.1 Label mock-ups and specimens - clean Replace*
1.3.3.2 Label mock-ups and specimens - annotated Replace*
1.3.3.3 Label mock-ups and specimens - approved Replace*
1.8 Information relating to Pharmacovigilance  
1.8.2 Risk management plan Replace*
1.11 Foreign regulatory information
1.11.1 Foreign regulatory status Replace*
Any use of Append outside the defined usage in Study Tagging Files

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

Naming conventions matrix

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

Book pagination