eCTD v4.0 AU module 1 and regional information

This document provides the pilot specification and guidance information relevant for preparation of an electronic Common Technical Document (eCTD) sequence to the Therapeutic Goods Administration (TGA). This document will come into effect in late 2025 and should be read in combination with the following supporting technical documentation:

1. International Council for Harmonisation (ICH) electronic Common Technical Document (eCTD) v4.0 Implementation Guide

Purpose and scope

This document serves as the Draft Implementation Guide and Technical Specification for eCTD v4.0 Module-1 and regional information relevant to TGA eCTD v4.0 sequence preparation using the HL7 Version 3 Regulated Product Submission (RPS) Release 2 Normative for human medicinal products. The document will be revised and finalised for general use following the Pilot Phase of implementation testing by the TGA.  This document does not include the specification information for eCTD v4.0 Modules 2-5; readers are directed to ICH eCTD v4.0 Implementation Guide for additional guidance.

Components of eCTD v4.0

Essential components of the eCTD v4.0 specification are provided below.

• eCTD validation criteria v4.0
• Object Identifiers (OIDs) and Universally Unique Identifiers (UUIDs)
• Data Types (section 4.6 of the ICH eCTD Implementation Guide)
• Files and folders (also see sections 4.1 and 11 [Appendix 1] of the ICH eCTD Implementation Guide)
• Controlled vocabulary (also see sections 4.2 and 6 of the ICH eCTD Implementation Guide)
• ICH eCTD v4.0 Schema and XML message (also see sections 4.3 and 7 of the ICH eCTD Implementation Guide)
• AU regional specific requirements mapping v3.2.2 elements to v4.0
• Validation rules (also see Section 12 [Appendix 3] of the ICH eCTD Implementation Guide)
• Forward compatibility (also see sections 10 and 13 [Appendix 3] of the ICH eCTD Implementation Guide)

The principles of creation and use of these components will be defined by:

• ICH eCTD Implementation Guide
• eCTD validation criteria v4.0
• eCTD v4.0 Module 1 draft implementation guide and technical specification (this document)

Creation of an eCTD v4.0 compliant message requires the user to refer to this document in conjunction with requisite documentation published by ICH.

The following table defines some abbreviations and common terms in this document and those specific to eCTD v4.0:

Common abbreviations and terms

The following table defines TGA Specific abbreviations and common terms in this document:

TGA Specific abbreviations and terms

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

This section will provide a brief overview of the essential components of the TGA eCTD v4.0 specification.

TGA Specific information

Sponsor information provided within the AU envelope elements of ICH eCTD v3.2.2 is required within the ICH eCTD v4.0 message. This section describes the purpose of the information and provides sample XML to guide translation between the two ICH eCTD specifications.

* For seq-desc-20, seq-desc-21, and seq-desc 24 only. Please show complete sequence descriptions, including date values or custom text.

e-Identifier

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

<componentOf>
<application>
<id>
<item root="e5cfe5b4-cee1-489e-953b-187a1bbf6b44"  extension="e123456"  />
</id>

eBS Client ID

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

<componentOf>
…
<holder>
<applicant>
<sponsorOrganization>
<name>
<part value="181" />
</name>
</sponsorOrganization>
</applicant>
</holder>

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.

<componentOf2
<categoryEvent>
<code/>
<component>
<categoryEvent>
<code code="aan" codeSystem="1.2.36.1.2001.1005.93.1">
<displayName value="199999 neurovexillin" />
</code>
</categoryEvent>
</component>

Trade name(s)

The name or proposed medicine (trade) name to be used on the Certificate of Registration. For Master Files, insert name of manufacturing site.

<componentOf2>
<categoryEvent>
<code/>
<component>
<categoryEvent>
<code code="product-name" codeSystem="1.2.36.1.2001.1005.93.1">
<displayName value="incrediPill"/>
</code>
</categoryEvent>
</component>

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.

<componentOf2>
<categoryEvent>
<code/>
<component>
<categoryEvent>
<code code="artg-number" codeSystem="1.2.36.1.2001.1005.93.1">
<displayName value="123456"/>
</code>
</categoryEvent>
</component>

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.

<submission>
<id xsi:type="DSET_II">
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="OM-2017-12345-1"/>
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="PV"/>
</id>

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.

TGA object identifiers and controlled vocabulary

Object identifiers (OIDs) are used throughout the eCTD v4.0 sequence to define validation criteria, e-Identifiers (eIDs) or controlled vocabularies (CVs). CVs are an essential component of eCTD v4.0 and are coded lists differentiated by OIDs. TGA specific OIDs and their purpose are provided in the following table.

XML samples for OID use

AU eCTD v4.0 Validation Criteria – 1.2.36.1.2001.1005.88

<id/>
<creationTime/>
<interactionId/>
<processingCode/>
<processingModeCode/>
<acceptAckCode/>
<receiver>
<device classCode="DEV" determinerCode="INSTANCE">
<id>
<item root="2.16.84.1.113883.3.989.2.2.1.11.5" identifierName="ICH eCTD v4.0 IG v1.6"/>
<item root="1.2.36.1.2001.1005.88.1" identiferName="eCTD AU Module1 v4.0"/>
</id>
</device>
</receiver>
<sender>
<device classCode="DEV" determinerCode="INSTANCE">
<id/>
</device>
</sender>

AU Module-1 Context of Use - 1.2.36.1.2001.1005.86

<contextOfUse>
<id root="b36a2ade-33c4-4cb9-95a4-aa09f38b51d3" />
<code code="au_1.0.1" codeSystem="1.2.36.1.2001.1005.86.1" />
<statusCode code="active" />
<!--Cover Letter-->
<derivedFrom>
<documentReference>
<id root="918c021b-6d35-48bc-81a6-6452216feb62" />
</documentReference>
</derivedFrom>
</contextOfUse>

Placement of v3.2 envelope elements within v4.0 message

AU Regulatory Activity Lead – 1.2.36.1.2001.1005.89

<componentOf2>
<categoryEvent>
<code/>
<component>
<categoryEvent>
<code code="reg-act-lead-1" codeSystem="1.2.36.1.2001.1005.89.1" />
</categoryEvent>
</component>

AU Sequence-type (Submission Unit Type) - 1.2.36.1.2001.1005.87

<componentOf1>
<sequenceNumber value ="1" />
<submission>
<id xsi:type="DSET_II">
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="submission number1" />
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="submission number2" />
<code code="seq-type-3" codeSystem="1.2.36.1.2001.1005.87.1" />

AU Sequence-description - 1.2.36.1.2001.1005.91

<controlActProcess classCode="ACTN" moodCode="EVN">
<subject typeCode="SUBJ">
<submissionUnit>
<id root="95198d79-a68b-4588-98c9-156a523d52a2"/>
<code code="seq-desc-20" codeSystem="1.2.36.1.2001.1005.91.1"/>
<title value="PSUR for Period of 2025-01-01 to 2025-12-31"/>
<statusCode code="active"/>

Sequence contents, files and folders

Sequence contents should follow the requirements defined by this document and the eCTD v4.0 document matrix.

When submitting the contents of a Submission Unit, the following structure should be used:

The sequence number folder must be named with the “sequence number” of the submission unit.

File formats and 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 titles to aid reviewers
• ensure the basic construction of the eCTD is maintained.

Follow the IETF rules for Uniform Resource Locators (except for period and asterisk) for file and folder name. All alphanumeric characters are acceptable, and special characters should be limited to those in the table below.

Length

The restrictions on file or folder name lengths should follow the specifications below:

• Maximum document (i.e., file) name length: 64 (including file name extension)
• Maximum folder name length: 64
• Maximum path length including first level folder: 180
• Note: this allows the folder structure to exist under a logical drive with high level folder that is applicable to the sender’s environment. If the path exceeds the 180-character limit or the regionally-defined limit, then folder and file names created by the applicant should be abbreviated.
• File name extension = 3 or 4 characters.

Pathname conventions and best practices

The pathname convention should reference the relative folder path using the forward slash (/) character to separate the folders. For example, the following pathname indicates the location of the file relative to the submissionunit.xml file e.g., "m2/23-qos/introduction.pdf".

The eCTD v4.0 XML message (or payload message) represents the reorganised data sent with your regulatory submission and includes three main schema components: the submissionUnit (sequence-specific details), submission (regulatory activity-level details), and application (dossier-level details), along with the closing element tags.

This draft of the TGA AU Regional specification does not include custom mapping of TGA-specific information within the Document Reference, Document, and Keyword Definition elements. For mapping of TGA-specific information to the components of the conceptual model, refer to TGA Specific Information and the sections below.

Submission unit

Information that is relevant to all modules for a specific eCTD sequence (such as the sequence type, header element, and sequence number) should be included in the submission unit element.

<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<id>
<item root="2.16.840.1.113883.3.989.2.2.1.11.5" identifierName="ICH eCTD v4.0 IG v1.6" />
<item root="1.2.36.1.2001.1005.88.1" identifierName="eCTD AU Module1 v4.0 IG v1.0" />
</id>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<id />
</device>
</sender>
<!--Message Payload begins here-->
<controlActProcess classCode="ACTN" moodCode="EVN">
<subject typeCode="SUBJ">
<submissionUnit>
<id root="95198d79-a68b-4588-98c9-156a523d52a2" />
<code code="seq-desc-20" codeSystem="1.2.36.1.2001.1005.91.1" />
<title value="PSUR for Period of 2025-01-01 to 2025-12-31" />
<statusCode code="active" />
...
<componentOf1>
<sequenceNumber value ="1" />
<submission>
<id xsi:type="DSET_II">
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="submission number1" />
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="submission number2" />
<code code="seq-type-3"
codeSystem="1.2.36.1.2001.1005.87.1" />

Priority number

Priority numbers should be utilised so that documents are displayed logically and consistently, enabling the expedient review of documentation. To allow for the insertion of additional documents in future sequences, it is advisable to assign priority numbers to initial document sets in increments of 1000.

<component>
<priorityNumber value="1000" />
<contextOfUse>
<id root="b36a2ade-33c4-4cb9-95a4-aa09f38b51d3" />
<code code="au_1.0.1" codeSystem="1.2.36.1.2001.1005.86.1" />
<statusCode code="active" />
<derivedFrom>
<documentReference>
<id root="918c021b-6d35-48bc-81a6-6452216feb62" />
</documentReference>
</derivedFrom>
</contextOfUse>
</component>

Sender-defined keyword

Sender-defined keywords should provide useful information about a Context of Use (such as whether it pertains to a specific indication or study). This attribute is further defined by ICH eCTD v4.0.

<component>
<priorityNumber value="1000" />
<contextOfUse>
…
<referencedBy typeCode="REFR">
<keyword>
<code code="p1" codeSystem="product-cv" />
</keyword>
</referencedBy>
<referencedBy typeCode="REFR">
<keyword>
<code code="d1" codeSystem="dosageforms-cv" />
</keyword>
</referencedBy>
</contextOfUse>

Context group

Context groups identify collections of documents that share the same Context of Use and keyword codes (such as a group pertaining to the drug substance data of a specific manufacturer). This function is further defined by ICH eCTD v4.0.

Submission

Essential metadata required for regulatory review that will be referenced in future submissions (such as the submission number and submission mode) should be included within the submission element. Other metadata related to this element may be more precisely defined in future drafts of this specification.

<componentOf1>
<sequenceNumber value="1" />
<submission>
<id xsi:type="DSET_II">
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="PV"/>
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="OM-2017-12345-1"/>
</id>
<code />
<callBackContact>
<contactParty>
<id root="1ab4a989-4bd1-488e-b4a3-3ca2d791ca76" />
<code />
<statusCode code="active" />
<contactPerson>
<name>
<part type="GIV" value="Jay" />
<part type="GIV" value="J" qualifier="IN" />
<part type="FAM" value="Jones" />
</name>
<telecom xsi:type="BAG_TEL">
<item value="mailto:jay.jones@pharmaceuticals.com" />
</telecom>
</contactPerson>
</contactParty>
</callBackContact>
<subject3>
<mode>
<code code="single"/>
</mode>
</subject3>

For submission and contactParty, the code elements are not utilised in AU eCTD v4.0. Those elements should therefore be specified as self-closing elements each.

Application

Information about the application itself (such as the e-identifier and eBS client ID) should be included within the application element. Other metadata related to this element may be more precisely defined in future drafts of this specification.

<componentOf>
<application>
<id>
<item root="e5cfe5b4-cee1-489e-953b-187a1bbf6b44" extension="e123456" />
</id>
<code />
<holder>
<applicant>
<sponsorOrganization>
<name>
<part value="181" />
</name>
</sponsorOrganization>
</applicant>
</holder>

Application type is not utilised in AU eCTD v4.0, therefore this element should be specific as a self-closing element.

Work grouping

Work grouping allows multiple regulatory activities relating to one eCTD application to be submitted as a single sequence. TGA only accept work-grouping sequence types for submissions relating to (bundled) minor variation application pathway.

Work grouped submissions should be submitted by including multiple submission numbers within the submission unit element of the XML message and setting the Submission Mode value to ‘multiple’.

<submission>
<id xsi:type="DSET_II">
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="PM-2024-12345-1"/>
<item root="9cc9196a-f704-444c-b7fd-4ebb616da90a" extension="PM-2024-56789-1"/>
</id>
<code />
...
<subject3>
<mode>
<code code="multiple"/>
</mode>
</subject3>

Use the following sequence requirements based on the type of withdrawal:

Include a cover letter and tracking table with all withdrawal sequences.

Entire product lifecycle: The cancellation of all products from the ARTG. All Context of Use elements relating to the dossier should be suspended.

Submission withdrawal: Removal of all information related to a single submission currently under evaluation. All Context of Use elements relating to the submission being withdrawn should be suspended.

Partial product lifecycle: Removal of a portion of your dossier due to an ARTG cancellation (such as when one of several dosage forms is cancelled). All Context of Use elements relating to the removed products should be suspended.

Partial submission withdrawal: Removal of some (but not all) applications related to a single submission currently under evaluation. All Context of Use elements relating to the withdrawn applications should be suspended.

Partial work-grouped submission withdrawal: Withdrawal of some (but not all) submissions relating to a bundled minor variation submission. Suspend all Context of Use elements related to the withdrawn submissions (except those that also relate to non-withdrawn submissions).

<component>
<priorityNumber value="1000" />
<contextOfUse>
<id root="e91c5e8c-b808-586e-ac1f-73b9efc9cd74" />
<statusCode code="suspended" />
</contextOfUse>
</component>

Transferring sponsorship

Full transfer: if all products under an e-ID are transferred to a new sponsor, the e-ID and related sequences are also transferred. No specific sequence is needed for the transfer, as it is identified by the new eBS Client ID in the payload message. However, the acquiring sponsor should mention the transfer in the next sequence cover letter.

Partial transfer: if only some products within an e-ID are transferred, a new e-ID will be assigned to the new sponsor. The acquiring sponsor must use the next sequence number from the old e-ID for the first sequence of the new dossier, indicating the medicine’s initial review under a different e-ID. Include the previous e-ID in the cover letter of the first sequence. The relinquishing sponsor must remove all documentation related to the transferred products in the next sequence and mention their removal in the cover letter.

File reuse

File reuse is possible through the reference value within the document element. Include two additional parent directory commands when referencing files from another application:

<component>
<document>
<id root="3c2640d5-bc9b-4dc6-bbc7-068fded1ddd0" />
<title value="m2.3.p drug product" />
<text integrityCheckAlgorithm="SHA256">
<reference value="../../e234567/1/m2/23p.pdf" />
<integrityCheck>…
</text>
</document>
</component>

Justification of validation warnings

It is no longer necessary to justify validation warnings within the sequence cover letter. You should instead provide a companion XML document called ‘warnings.xml’ with your sequence to justify these warnings.

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

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

Please contact your eCTD tool vendor for advice on implementation.

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

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

Forward compatibility

Forward compatibility should be used for any dossier that has v3.2.2 content where the application is being converted to a v4.0 message. Once a v4.0 submission unit has been received for an application, all future sequences must be sent in v4.0. Detailed guidance on preparing the required forward compatibility message can be found within the ICH eCTD Implementation Guide (v1.6, Section 8.)

Content from v3.2.2 may come from the index.xml, regional.xml or stf.xml files. When replacing ICH v3.2.2 content or submitting new v4.0 content that should be grouped with v3.2.2 content, the index.xml attribute values (e.g., manufacturer) and stf.xml values (e.g., study id title, file-tag) must match. The following table maps the content to v4.0 elements and attributes and expected usage.

The instructions for submitting references to v3.2.2 content should align with the following conditions:

• Life cycle of submission content is only allowed for active (e.g., new, replace) leaf elements (i.e., content that is in the current view);
• When v3.2.2 content is replaced, it must follow v4.0 context group life cycle rules;
• When submitting the first eCTD v4.0 sequence to an eCTD v3.2.2 dossier the next available sequence number is submitted as a whole number. For example, if the last eCTD v3.2.2 message has a sequence number “0003”, the first eCTD v4.0 submission unit will be sequence number “4”;
• Validation rules apply to the submission unit with v3.2.2. references, and there are validations only relevant when forward compatibility is used in a submission unit; and
• When submitting v4.0 content that should be grouped with v3.2.2 content the keyword codes and values must match.

Download a forward compatibility sample.

Lifecycle operations

The following three lifecycle operations defined under within the ICH eCTD v4.0 Implementation Guide.

• New
• Replace
• Suspend

We encourage you to use replace wherever possible, unless information is being provided for the first time.

Specific lifecycle operations for Australia

Context of Use with specific lifecycle operations mandated for an Australian eCTD are summarised below.

*Except the first time we receive a document in which case it should be a new Context of Use.

For 1.8.2 use RPLC for risk management plans. However, in some instances, replacing 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 a new Context of Use, you will receive a validation warning.

eCTD v4.0 validation rules

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

There are three types of eCTD validation findings:

1. Error—Critical finding:
   • validation findings categorised as errors must be addressed
   • non-compliance will lead to rejection of the sequence
2. 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.
3. Information—Information collected about the data being submitted. This includes:
   • a list of omitted possible documents as defined in document matrix that might be required in a sequence
   • information about unusual lifecycle operations
   • information about study tagging files submitted, etc.

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

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

Sequences with errors or deficiencies

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

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

Checksums

The eCTD v4.0 XML message will contain checksums for all document/text/integrityCheck elements. The SHA-256 integrity check algorithm should be applied to obtain a checksum for all files referenced in a document element within a given submission unit.

The purpose of the checksum is as follows:

• The integrity of each file can be verified by comparing the checksum submitted in the XML message and a computed checksum by the receiving system.

The checksum can be used to verify that the file has not been altered in the historical archive of the Regulatory Authority.