AU Module 1 general architecture

On this page: Backbone file for AU Module 1 | XML root element | Envelope | Heading elements | Node extensions and leaf elements | Lifecycle operations | Files and folders

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.

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

In this section: Submitting multiple values | The defined lists | e-Identifier | eBS Client ID | Approved name(s) | Trade name(s) | ARTG number | Submission number(s) | Sequence number | Related sequence number | Regulatory activity lead | Sequence type | Sequence description | Submission mode | Contact email

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.

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:

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

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

Related information and guidance

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

Related information and guidance

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

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

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

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:

• 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. If you use Append for any other purpose, you will:
  • receive a validation warning
  • need to include an explanation in the cover letter.

Specific lifecycle operations for Australia

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

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

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.