eCTD AU module 1 and regional information

Specification and guidance for use, V3.1

18 October 2017

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

Introduction

This document applies to all regulatory activities in electronic Common Technical Document (eCTD) format.

The document contains:

  • guidance for compiling an eCTD dossier
  • specifications for compiling and validating your eCTD regulatory activity.

This document replaces AU eCTD specification - Module 1 and regional information Version 3.0 and contains updated information. A summary of the updates are provided with the Summary section.

Version 3.1 of the specifications and validation criteria will come into effect in 2018 following a transition period and should be read in combination with Australian validation criteria version 3.1, eCTD schemas and related files.

Summary of updates in Version 3.1

The following eCTD documents and specifications have been updated as part of the upgrade to version 3.1:

For a comprehensive understanding of the updates introduced in version 3.1 please refer to the to the AU Validation Criteria v3.1 where all updates (both new and changes) been highlighted in yellow. Updates within the validation criteria have been reflected within the XML schemas, related files and checksum values.

For further information on any of the updates please contact esubmissions@health.gov.au.

Purpose of the updates

  • Support the implementation of the Medicine and Medical Device Review (MMDR) recommendations; including the priority, provisions and notification pathways.
  • Allow for the possibility of eCTD dossiers supporting requests for multiple changes (see further references in this document to 'Work sharing' and/or 'work grouping').
  • Provide greater clarity to users.
  • Enhance dossier quality (introduce additional validation criteria to assist with dossier quality).
  • Allow for automation of some process steps within the TGA.

Summary of eCTD updates

Module 1 Section updates
New sections
New sections Rationale
1.3.1.3 Product information - approved The inclusion of an approved folder clearly distinguishes the approved copy from the working copies
1.3.2.3 Consumer medicine information - approved
Updated sections
Updated sections Previous Rationale
1.3.1.4 Package insert 1.3.1.3 Package insert Moved section ID to accommodate Product information – approved

1.3.3.1 Label mock-ups and specimens – clean

1.3.3.2 Label mock-ups and specimens – annotated

1.3.3.3 Label mock-ups and specimens – approved

1.3.3 Label mock-ups and specimens Section has been divided to clearly distinguish the clean, annotated and newly added approved copies.
Sequence Type updates
New Sequence Types
New Rationale
Provisional registration – TGA initiated variation Support MMDR recommendation implementation
Notification
CN
Extension of provisional registration
Duplicate Requirement inclusion for potential work sharing options.

A new sequence description 'Provisional approval – rolling data submission' has also been included to support the implementation of MMDR.

Where known, additional document requirements have been included within the Document Matrix for each of these new sequence types. As more detail on document requirements becomes available, we will update the Document Matrix that appears on the TGA website.

Updated Sequence Types
Updated Sequence Type Previous Rationale
Product Withdrawal Withdrawal Name change to better align with the use of this sequence type. Validation criteria have also been amended.
XML elements

Addition of new XML elements within the AU envelope has been included to build additional capacity into the envelope and allow for future automation of the validation process.

eCTD validation criteria

Updates to the validation criteria for eCTD have been included within version 3.1.

New validation criteria have been included to primarily support the introduction of new XML elements. Updates have also been made to some current criteria to provide further clarity based on experience gained to date.

Please refer the eCTD Validation Criteria within the AU Validation Criteria version 3.1 for further details on updated items.

Terminology

It is acknowledged that the terminology to describe regulatory activities and electronic submissions differs between regions. To assist users interpret this guidance and specification a brief list of terms used is described below:

Term Definition
eCTD electronic Common Technical Document - an electronic standard for the Common Technical Document (CTD) providing the means for transferring information from pharmaceutical companies to agencies.
*eCTD application for the purpose of this document - refers to a collection of electronic documents filed under an e-Identifier and comprises of a number of sequences and regulatory activities.
Envelope Contains the metadata relevant to the eCTD sequence. Metadata are referred to as envelope elements.
e-Identifier is a combination of a letter and six digits, for example e123456. It is the unique identifier for the eCTD application that tracks the products for the entire lifecycle (previously eSubmission Identifier).
leaf 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.
NeeS Non-eCTD Electronic Submission - an alternative electronic standard to eCTD consisting of PDF Files and PDF Table of Contents linking all content for navigational purposes.
regulatory activity a collection of sequences covering a specific request. Referred to in Australia as a submission e.g. Submission for a new chemical entity (NCE).
sequence 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.
Stream An indication of the clinical team that will deal with a request to register a new product. Each stream corresponds to a therapeutic category. These are available on the TGA website.

*Within Australia the words 'submission' and 'application' have very specific meanings within our regulatory framework and legislation. To avoid confusion eCTD application will be used to describe eCTD related terminology rather than application.

Implementation/transition plan

To allow for planning and software updates we have incorporated a transition period for the uptake of the AU eCTD version 3.1 specifications.

Version 3.0 was the first official eCTD version for Australia.

The initial version of this specification was identified as 0.90 to indicate its draft status and versions 1.0 and 2.0 were skipped to avoid confusion with past CTD guidance.

Timelines for implementation of version 3.1

  • The AU eCTD version 3.1 specification will be effective starting 1 January 2018.
  • The AU eCTD version 3.0 specification will be accepted until 30 June 2018.
  • The AU eCTD version 0.90 specification was used for the eCTD pilot and is no longer accepted.

Between 1 January 2018 and 30 June 2018 we will accept both the new version 3.1 and the 'old' version 3.0 of the specification.

Preparing for your eCTD dossier

Specification and guidance for use, V3.1

18 October 2017

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

Obtaining the e-Identifier

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

To obtain an e-Identifier:

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

The e-identifier is:

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

Preparing the eCTD cover letter

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

  • the e-Identifier, the sequence and related sequence in the subject line, consistent with the eCTD envelope
  • a description of the eSubmission:
    • type and number of electronic media
    • approximate submission size, and
    • any characteristics concerning the media that we might need to know
  • a description of the software used to check the files for viruses and a statement as to whether the submission is virus free
  • the regulatory and information technology points of contact for the submission
  • information about the validation including:
    • the validation tool and version used
    • any findings e.g. errors, warnings or possible missing documents as designated by the 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. This is only necessary until we develop an electronic portal.

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

Validating the eCTD sequence

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

There are three types of eCTD validation findings:

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

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

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

Sequences with errors or deficiencies

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

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

Naming the eCTD dossier

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

Example - e123456\0001

Selecting a media format

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

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

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

We do not return the media.

Do not use:

  • passwords
  • double-sided discs.

Sending your eCTD dossier

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

OR

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

OTHERWISE

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

Feedback on validation

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

Within the next 12 months, validation of your submission will be automated. Once that occurs the validation result will be sent to the email address(es) indicated in the Envelope. This will be an automated process and it is the responsibility of the contacts that you nominate to take any required action indicated in the response. It is therefore recommended that an alternative key contact be listed.

AU regional content

Specification and guidance for use, V3.1

18 October 2017

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

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

  • Regulatory requirements and content for module 1 is described within CTD Module 1.
  • The validation criteria to support the content is described within the eCTD Validation Criteria spreadsheet in the AU Validation Criteria 3.1 Excel workbook.
  • Use the eCTD Sequence Matrix to determine what combination of sequence type and sequence description is relevant to your specific sequence.

Module 1 administrative and prescribing information

The ICH Common Technical Document (CTD) specifies that:

  • Module 1 should contain region specific administrative and product information.
  • Module 3.2.R should be used for any additional drug substance and/or drug product information specific to Australia.

AU regional file formats

Specification and guidance for use, V3.1

18 October 2017

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

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

Module 1

In addition to PDF, as defined by the ICH eCTD Specification Document, 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, product information, etc.

Where possible, generate PDFs from an electronic source. Signatures may be embedded as a graphic file in the PDF.

All PDF files, in any module, should be v1.4, v1.5, v1.6 or v1.7 except where a specific requirement for a later version is defined.

Module 2 to 5

In addition to the file formats defined for Modules 2 to 5 in the ICH eCTD Specification and the ICH specifications for study tagging files, 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.

Other AU regional considerations

Specification and guidance for use, V3.1

18 October 2017

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

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

Electronic signatures

Whilst electronic signatures - for example, public key digital signatures - will be crucial, particularly for authentication of electronic submissions and documents, we are currently accepting:

  • Digital signatures as an adjunct to written signatures.
  • Scanned signatures where the documents make up part of the checksum of an eCTD sequence.

Empty or missing eCTD sections

  • Provide detailed statements justifying the absence of data or specific CTD sections in the relevant Quality Overall Summary and/or Nonclinical/Clinical Overviews - for example, Module 2.3, 2.4, or 2.5.
  • Include a statement in the cover letter on the absence of expected Module 1 content.

Do not:

  • Use documents with no substantive content - for example, documents that contain words like 'not applicable' - in the eCTD structure. This creates unnecessary documents that have to be included in the lifecycle and causes delays for evaluators who must open and assess documents with no substantive content.
  • Provide a justification for content that is typically absent for generic medicines.

Updating backbone attributes/metadata

Updating ICH attributes

You can update XML backbone attributes - for example, manufacturer - during the eCTD lifecycle, but these changes can lead to complexity in the cumulative view.

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

We recognise this practice is not allowed in some regions but we do allow the option as it does not negatively impact the evaluation process.

Changes in attributes can only be submitted if lifecycle updates to the content within those sections are submitted.

Updating AU envelope information

The AU envelope information can be updated during the lifecycle as is necessary to reflect changes in the metadata - for example, adding and removing product names.

Bookmarks, Table of Contents and Hyperlinks

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

Bookmarks

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

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

Table of Contents

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

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

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

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

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

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

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

ICH eCTD Specifications - Appendix 7

Reusing files

All sequences will be stored by e-Identifier which can then be used to make referencing possible, to documents in other eCTD applications.

  • Do not submit the same document multiple times. Reusing content that has already been submitted and evaluated makes the evaluation process more efficient.

We accept and encourage you to reuse files when you:

  • Need to submit a file several times within one sequence
  • Are referring to a file that has already been submitted in a previous sequence
  • Are referencing a file submitted in another eCTD application (e-Identifier).

Referencing content submitted in other eCTD applications

If referencing content in another eCTD application create the link in the xml file as shown, highlighted, in the following code:

<m1-4-3-clinical>
  <leaf ID="N3774598bcdd74d5891d954542c552eee" operation="new" xlink:href=
  "../../../../e000111/0000/m1/au/104-expert/1043-clinical/dr-a-jones.pdf" checksum=
  "b6ba67a7740d12bcb938f2850baa584e" checksum-type="MD5">
      <title>Expert Dr. A. Jones</title>
  </leaf>
  <leaf ID="N3ad8bf59e3fd4cb5bbd4f82b31350887" operation="new" xlink:href=
  "104-expert/1043-clinical/dr-b-schmidt.pdf" checksum="bf30251122458c7c5c17dc3ed0002c1e"
  checksum-type="MD5">
      <title>Expert Dr. B. Schmidt</title>
  </leaf>
  <leaf ID="Ne0eeb59ae2f74ba5832965154db4cc13" operation="new" xlink:href=
  "104-expert/1043-clinical/dr-c-smith.pdf" checksum="f1e209870c05f15eef24f4b2e1e74a0f"
  checksum-type="MD5">
      <title>Expert Dr. C. Smith</title>
  </leaf>

This code (highlighted) directs the hyperlink out of the eCTD application and into the referenced eCTD application using the e-Identifier of that eCTD application (referencing itself if directing into another sequence of the same eCTD application).

ICH eCTD Specifications - Appendix 6

Baseline sequences

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

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

Cover letter for baselines

When submitting a baseline sequence, you need to include a statement about each of the following points in the covering letter:

  • the format used for the previous dossier(s)
  • when the previous dossier(s) was submitted
  • verify that the formatting is the only change to the previous dossier(s) and there are no amendments to content
  • all the information in the baseline sequence was in the previous version(s) of the dossier
  • any omissions in the baseline sequence do not cause the content to be misleading.

Changing from paper or NeeS

When changing from paper/NeeS to eCTD we recommend you:

  • use a baseline sequence as a start of an eCTD
  • provide as much content as possible in the eCTD.

You can define the sections provided in a baseline sequence, but make sure that any omissions do not cause the content to be misleading.

We prefer the baseline sequence to consist of high quality electronic source documents, but we will accept good quality scanned images with Optical Character Recognition (OCR) as this will help us search the text during the evaluation process.

We do not evaluate the baseline and you do not need hyperlinks between documents.

Baseline sequence - required identification

Use the sequence type Baseline and sequence description Reformat in the envelope for the baseline sequence.

Initial baselines of paper/NeeS submissions

The baseline should:

  • normally be submitted as sequence 0000 (but if justified, could be submitted at a later date)
  • always be a separate sequence
  • never include new regulatory activities.

The first new regulatory activity - for example, the next variation - in eCTD format should then be submitted as sequence 0001.

Table 1 Demonstration of baseline as an initial eCTD sequence
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 product lifecycle, supplying information as it is needed.

When using a baseline sequence for the first time:

  • Do add documents previously submitted as paper/NeeS in the appropriate part of the eCTD structure with the attribute "NEW".
  • Do not re-submit documents from previous eCTD sequences.

You can use multiple sequences to submit a baseline.

Example - one sequence for the baseline for Modules 4 and 5 followed later by a sequence for the baseline for Module 3 or parts of Module 3.

  • Do use the sequence type Baseline in each case.
  • Do not use the sequence type Supplementary information for baseline sequences.

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

Table 2 demonstrates how to submit multiple baselines later in the eCTD lifecycle.

In this example, the previously submitted content in paper/NeeS format for a variation is submitted as a baseline prior to the initial sequence for the regulatory activity where it is needed.

These sequences can be submitted together on the same electronic media. Each sequence should have a cover letter explaining the purpose of each sequence.

Table 2 How to submit multiple baselines later in the eCTD lifecycle
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 should send an email outlining your proposal to esubmissions@health.gov.au to discuss the best approach.

Work grouping and Work sharing

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

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

Node extensions

Node extensions are additional heading structures beyond those defined by the specifications, generally equated to an additional subfolder in a defined section and are a way of providing additional information in the sequence.

The node extension should be visualised as an extra heading in the CTD structure and should be displayed when viewing the XML backbone.

Consider the impact of changing node extension structures during the lifecycle as this can lead to a higher level of complexity in the cumulative view of the product life cycle history.

Basic rules with using node extensions for AU

You can:

  • Only use node extensions at the lowest level of the eCTD structure.

    Example - you can use a node extension at the level 5.3.5.1 but not at the level 5.3

  • Use node extensions to group documents made up of multiple leaf elements.

    Example - a clinical study made up of separate files for the synopsis, main body and individual appendices could be grouped together under a node extension with the Study Identifier as its Title attribute

  • Nest the node extensions but make sure the first node extension is at the lowest level in the eCTD structure.

    Example - a node extension may be added in Module 5.3.7 to group together files with the Study Identifier as Title attribute. Further node extensions may be added as children of the Study Identifier node, separating Case Report Forms (CRFs), if submitted, from individual patient listings.

Do not use:

  • Node extensions if ICH-specified sub-headings already exist

    Example - do not use the following as node extensions:

    • indication
    • excipient
    • manufacturer
    • drug substance
    • drug product.

Study tagging files

We do not require you to provide study tagging files (STFs) for evaluation. You can reuse content submitted in other regions where STFs have been used. If you do this make sure it conforms to the ICH specifications for study tagging files.

We will collect data about the number and size of ICH E3 16.3 CRFs and non ICH E3 documents for informational purposes.

Transferring sponsorship

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

Acquiring sponsor

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

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

and

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

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

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

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

Relinquishing sponsor

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

  • remove the medicines you transferred from the envelope starting with the next sequence
  • mention their removal in the cover letter.
Table 3 e-Identifiers and transfer of Sponsor activities/tasks
Sponsor
FFF
Sponsor
PPP
Sponsor
YYY
Activity/Task

Product A

Product B

Product C

Product D

e000111

     
0001     eCTD 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 new eCTD application
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

Withdrawals

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

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

AU Module 1 general architecture

Specification and guidance for use, V3.1

18 October 2017

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.

eCTD preparation tools

Specification and guidance for use, V3.1

18 October 2017

Please note: V3.0 of the specification is acceptable until 30 June 2018. This 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 package.

    There is a wide variety of options available, both in terms of multiple vendors and of approaches - for example:

    • installed software
    • software as a service
    • service providers.
  • Find a solution which supports current and ongoing AU eCTD requirements and meets your overall business needs.

  • Validate the prepared regulatory activity using an authenticated commercial eCTD validation tool.

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

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

Change control

Specification and guidance for use, V3.1

18 October 2017

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

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

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

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

Version history

Specification and guidance for use, V3.1

18 October 2017

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

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

Updates to provide greater clarity and align with version 3.1 of the AU eCTD specifications and validation criteria.

Updates to Envelope

Updates to Headers and associated XML elements

Additions to Sequence Types and Sequence Descriptions to cater for MMDR recommendations.

Split of the Regulatory Activity Lead value 'Prescription' into 'Prescription-chemical' and 'Prescription-biological'

Contingent changes to cater for possibility of Work Grouping and Work Sharing

Updates to Bookmark/TOC/Hyperlink guidance

Consideration for Automation processes and planned portal

Updates to Product Information Headings

Updates to specific Lifecycle Operations Guidance

Prescription Medicines Authorisation Branch 01/01/2018