FDA Module 1

Electronic Common Technical Document (eCTD) v4.0

Implementation Guide v1.4

U.S. Department of Health and Human Services

Food and Drug Administration
Center for Drug Evaluation and Research
Center for Biologics Evaluation and Research
June 2021
DOCUMENT CHANGE HISTORY
Date Version Summary of Changes
2016-02-23 1.0 Initial Step 4 Regional Implementation Guide.
2017-03-20 1.1 Revised Step 4 Regional Implementation Guide based on
review comments and consistency changes with the ICH
eCTD v4.0 Implementation Guide v1.2.
2019-12-03 1.2 Revised Step 4 Regional Implementation Guide based on
review comments and consistency changes with the ICH
eCTD v4.0 Implementation Guide v1.3.
2021-01 1.3 Revised based on public comments from the “Electronic
Common Technical Document v4.0 Technical
Conformance Guide; Food and Drug Administration
Electronic Common Technical Document v4.0 Module 1
Implementation Package; Request for Comments”
Federal Register Notice. Changes include removal the
following: 1) Two-way communications and associated
data elements; 2) Regulatory Review Time; 3) Applicant
DUNS Number; 4) Document media type; and 5)
Category Event. In addition, changes have been made to
the folder structure and additional instructions for
placement of files for grouped submissions.
2021-06 1.4 Revised based on consistency review of eCTD v4.0
references (e.g., updated excluded elements for
applicant) and notation of elements and attributes. No
substantive changes have been made in this version.

i
 TABLE OF CONTENTS Page
Notice to Readers .............................................................................................................................. v
Instructions to Reader...................................................................................................................... vi
Document Content .................................................................................................................................... vi
XML Snippets .......................................................................................................................................... vii
Location in XML .................................................................................................................................... viii
XML Elements Tables .............................................................................................................................. ix
1. Purpose ...................................................................................................................................... 1
2. Scope .......................................................................................................................................... 1
3. Components of the eCTD v4.0 .................................................................................................. 1
3.1 Referenced Documents ................................................................................................................. 2
3.2 Files and Folders ........................................................................................................................... 2
3.3 Controlled Vocabularies .............................................................................................................. 2
3.4 ICH eCTD v4.0 XML Schema ..................................................................................................... 2
3.5 The eCTD v4.0 XML Message..................................................................................................... 3
3.6 OIDs and UUIDs ........................................................................................................................... 3
Object Identifiers ...................................................................................................................................... 3
Universally Unique Identifiers .................................................................................................................. 3
3.7 Data Types ..................................................................................................................................... 4
3.8 ICH eCTD v4.0 Implementation Guide for Modules 2-5 .......................................................... 4
3.9 ICH Harmonized Elements.......................................................................................................... 4
ICH Included Elements ............................................................................................................................. 4
ICH Excluded Elements............................................................................................................................ 4
3.10 FDA-Specific Elements................................................................................................................. 4
FDA Included Elements ....................................................................................................................... 4
FDA Excluded Elements ...................................................................................................................... 5
4. Submission Contents, Folder and File Structure .................................................................... 5
4.1 Folder Structure and Submission Unit Contents ....................................................................... 5
4.2 Naming Conventions .................................................................................................................... 6
4.3 Allowable Characters ................................................................................................................... 6
4.4 Length ............................................................................................................................................ 6
4.5 Pathname Conventions and Best Practices ................................................................................ 6
4.6 Folder Hierarchy .......................................................................................................................... 6
4.7 File Formats .................................................................................................................................. 7

ii
 4.8 Checksums..................................................................................................................................... 7
4.9 Compressed Archive..................................................................................................................... 7
5. Controlled Vocabularies ........................................................................................................... 7
5.1 Controlled Vocabularies Specified Regionally ........................................................................... 7
5.2 Excluded Regional Vocabularies ................................................................................................. 8
5.3 Controlled Vocabularies specified by ICH ................................................................................. 8
5.4 Controlled Vocabulary specified by HL7 ................................................................................... 8
5.5 Sender-defined Vocabulary ......................................................................................................... 8
6. ICH eCTD v4.0 XML Schema .................................................................................................. 8
7. eCTD v4.0 XML Message ......................................................................................................... 8
7.1 Message Header ............................................................................................................................ 8
XML Elements.......................................................................................................................................... 9
Required Elements .................................................................................................................................... 9
Message Header XML Sample ................................................................................................................. 9
7.2 Payload Message ......................................................................................................................... 10
Submission Unit...................................................................................................................................... 15
Priority Number for Context of Use ....................................................................................................... 17
Context of Use ........................................................................................................................................ 17
Related Context of Use (Context of Use Life Cycle) ............................................................................. 17
Document Reference............................................................................................................................... 17
Keyword ................................................................................................................................................. 17
Sequence Number ................................................................................................................................... 19
Submission.............................................................................................................................................. 19
Contact Party .......................................................................................................................................... 23
Application......................................................................................................................................... 33
Applicant ............................................................................................................................................ 37
Application Reference........................................................................................................................ 39
Document ........................................................................................................................................... 41
Keyword Definitions .......................................................................................................................... 41
7.3 Grouped Submissions ................................................................................................................. 42
Submission Reference............................................................................................................................. 43
Grouped Submission Sample .................................................................................................................. 44
7.4 Withdrawing Submission Contents .......................................................................................... 45
7.5 Promotional Materials ............................................................................................................... 45
8. TRANSITION MAPPING MESSAGE FROM ECTD V3.2.2 .............................................. 46
8.1 Message Header .......................................................................................................................... 46
XML Elements........................................................................................................................................ 46
Required Elements .................................................................................................................................. 46
Message Header XML Sample ............................................................................................................... 47

iii
 8.2 Payload Message ......................................................................................................................... 47
Keywords in TMM ................................................................................................................................. 53
Post Transition ........................................................................................................................................ 53
9. Appendix: File Reuse .............................................................................................................. 54
10. Appendix: Application Prefix ............................................................................................. 55

List of Figures 53T

Figure 1: Submission Unit Folder ................................................................................................. 6

40TU U40T

List of Tables 53T

Table 1: Legend of Symbols used in Document .......................................................................... vi

40TU U40T

Table 2: Legend for XML Snippets ............................................................................................ vii

40TU U40T

Table 3: Location in XML Notation ..........................................................................................viii

40TU U40T

Table 4: Sample XML Element Table ......................................................................................... ix

40TU U40T

Table 5: Message Header XML Structure ................................................................................... 9

40TU U40T

Table 6: eCTD v4.0 XML Message Structure ........................................................................... 10

40TU U40T

Table 7: Message Header XML Structure ................................................................................. 46

40TU U40T

Table 8: Transition Mapping Message Payload XML Structure ............................................ 47

40TU U40T

Table 9: Application Prefix ......................................................................................................... 55

40TU U40T

iv
NOTICE TO READERS
Sections of this document referencing the HL7 (Version 3) Standard, Regulatory Product
Submission Release 2 Normative is copyrighted by Health Level Seven International ® ALL
RIGHTS RESERVED.

v
INSTRUCTIONS TO READER
This is a technical document that provides instructions on how to implement the eCTD v4.0
specification for the FDA Module 1 submission content. The information in this document is
provided in a consistent manner with the ICH eCTD v4.0 Implementation Guide. In addition, the
reader may be prompted by visual cues about the context or referenced information being
presented in the document.
Document Content
In the document there are several notations that are used to provide clarity to the subject matter.
The first is the use of XML components (i.e., elements and attributes) versus the concept that it
represents. The document text follows the notations described below:
• XML components
o The document’s narrative text is in bold, italicized text in camel case, e.g.,
contextOfUse
o The XML samples are as notated below in the XML Snippets section.
• Concepts without attribution to the standard and/or message
o A defined concept, e.g., Context of Use is noted in plain text with first letter
capitalized.

The following table provides visual cues that are used in the document.
Table 1: Legend of Symbols used in Document
Icon Description
Technical descriptions

Items to be careful to follow

Additional Instructions

References to other documents

vi
XML Snippets
The following figure indicates the color coding used in the XML snippets and any meaning that
should be inferred in the samples.
Table 2: Legend for XML Snippets
Text Description
Color Sample
Teal Schema components
<?xml version “1.0” encoding=“UTF-
8”?>
Blue XML notations
< ….= “”>
Brown XML element
id
code
Red XML attribute
root
extension
Black Value of the attribute or element
2.16.840.1.113883

The following rules were used in the development of the XML samples:
• The notation of <!--....notes….-- > was used to describe conditions that should be met for
an element.
• The notation … [Description] … was used to indicate when there were additional elements
not represented in the XML, but may be present in the actual XML message.
Note: XML editors may display these XML components differently, please use the legend
above for XML presented in this document.

vii
Location in XML
Each of the elements in this document includes a section named, “Location in XML”. The
notation included uses the following convention:

Table 3: Location in XML Notation

Notation Description Instruction for use
> Single arrow The element follows the previous without
indentation in the XML.
>> Double arrow The element follows the previous with an
indentation in the XML.

For example, the following location shows both notations and is followed by the XML sample.

• controlActProcess>>subject>>submissionUnit>>component>>priorityNumber>
contextOfUse
Element’s location in XML

<controlActProcess classCode="ACTN" moodCode="EVN">

<subject typeCode="SUBJ">
<submissionUnit>
<id root="e6f34476-8288-43f2-a2ea-5860d19fcf32"/>
<code code="us_submission_unit_type_1"
codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.13.1"/>
<title value="Original Application- Indication: pain"/>
<statusCode code="active"/>
<component>
<priorityNumber value="1000"/>
<contextOfUse>

The priority number is represented in the path as it is a required element. In some cases optional
elements will not appear in this notation. The schema is used to enforce any element sequencing
requirements, but not optional elements.

Refer to the ICH eCTD v4.0 Implementation Guide for the ICH specific
required elements.

Note: For FDA specific required elements, refer to Section 7.2 of this document.

viii
XML Elements Tables
A table has been provided for each element in the XML message. When elements have multiple
element parts or attributes, they are provided in one table. When there are no attributes or values
for an element, the cell is grayed out to indicate that an attribute value is not required in the XML
message.
Table 4: Sample XML Element Table
Table Name: <element>.<element 2>
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples

Conformance
Business Rules
Excluded Elements
and/or Attributes

Table Name: Each table is named for the elements it is representing in the XML – i.e.,
<element>.<element 2>. For example, the Application element has an element for the identifier, it
would be represented as: application.id.

Element: Identifies the XML element.

Attribute: Identifies the XML attribute.
Cardinality: Provides information on how many times the element/attribute can be repeated in the
XML message. The values in this table define the cardinality to be applied in eCTD v4.0
implementation, which sometimes restrict the cardinality defined in the schema.
Value(s) Allowed/Examples: Identifies the values allowed using simple data types and any
associated examples. References to controlled vocabulary are also provided.
Description/Instructions: Provides a description of the element or attribute.
Conformance: Identifies the validation requirements (e.g., XML Elements or attributes) and/or
conditions that need to be met by the element.
Business Rules: Identifies any business rules that are harmonized for ICH and references to
Regional/Module 1 Implementation Guides when the business rules are not harmonized.
Excluded Elements and/or Attributes: Identifies datatype elements and/or attributes that are part
of the HL7 Regulated Product Submission standard and not included in the Module 1 portion of
the eCTD v4.0 Implementation.

ix
1. PURPOSE
This document serves as the implementation guide and a technical specification for the Food and Drug
Administration (FDA) Electronic Common Technical Document (eCTD) v4.0 Module 1 using the
Regulated Product Submission (RPS) Release 2, Normative standard. The audience for this document
is mainly the individuals or organizations creating or implementing eCTD v4.0 publishing and/or review
systems and its use should enable eCTD tool vendors to build a tool that publishes or displays eCTD
compliant messages (i.e., utilizing the RPS standard) to the intended recipients of the information.

Note to Implementers: This implementation guide should be used in

conjunction with the ICH eCTD v4.0 Implementation Guide, as the eCTD
v4.0 message may be incomplete without following instructions in both
implementation guides.

2. SCOPE
The RPS standard defines the message for exchanging information electronically between Regulators
and Regulated Industry. The message provides the ability to describe the contents of the regulatory
exchange and all information needed to process the exchange between parties. The RPS message is
designed to be flexible enough to be used to support regulatory exchanges for any regulated product.

This document only includes eCTD v4.0 Module 1 instructions for the FDA regional content of the
eCTD. The instructions for eCTD v4.0 Modules 2 – 5, which are shared across all ICH regions, are not
included in this implementation guide. Refer to the ICH eCTD v4.0 Implementation Guide for
additional instructions necessary to create a complete eCTD v4.0 message. In addition, sections in this
document may also be included in the ICH eCTD v4.0 Implementation Guide and may include a
reference back to that document.
3. COMPONENTS OF THE ECTD V4.0
This section provides a brief overview of the essential components of the eCTD v4.0 specification. The
essential components include:
• OIDs and UUIDs (summarized in Section 3.6)
• Data Types (summarized in Section 3.7)
• ICH Implementation Guide (summarized in Section 3.8)
• Files and Folders (detailed information provided in Section 4)
• Controlled Vocabulary (detailed information provided in Section 5)
• ICH eCTD v4.0 XML Schema (detailed information provided in Section 6)
• eCTD v4.0 XML message (detailed information provided in Section 7)
• Transition Mapping Message from v3.2.2 (detailed information in Section 8)

Each of these components is detailed in the subsequent sections to include specific information about the
component’s role in the implementation of this specification. In order to compose a complete eCTD
v4.0 compliant message, the contents of this implementation guide are complemented by several other
documents. The focus of this document is to outline the essential components of the eCTD v4.0 and
specifically the information required to compose Module 1 of the CTD.

1
Note: Reference the ESTRI Website (https://www.ich.org/page/electronic-standards-estri) for complete
list of documents in the ICH eCTD v4.0 Implementation Package and the FDA eCTD website for a
complete list of documents for the FDA Module 1 components of the eCTD v4.0 message.
3.1 Referenced Documents
For additional regional references, the following documents should be referenced for complete
regulatory and technical content:
• FDA Guidance for Industry, Providing Regulatory Submissions in Electronic Format — Human
Pharmaceutical Product Applications and Related Submissions Using the eCTD Specifications
• FDA Technical Specification Document, eCTD v4.0 Technical Conformance Guide
• ICH eCTD v4.0 Implementation Package
• ICH Specification for Submission Format for eCTD
• FDA Specifications for File Format Types Using eCTD Specifications
• FDA Study Data Technical Conformance Guide
• ICH eCTD v4.0 and FDA Module 1 Controlled Vocabulary Spreadsheet and Genericode files

Note to Implementers: The FDA Module 1 Controlled Vocabulary provided in

the Spreadsheet format is intended as the human readable version of the
content, and the Genericode format is intended for implementers to use as a
computable version of the content. The information provided in both files is
exactly the same.

3.2 Files and Folders

For additional details regarding files and folders in Module 1, refer to Section 4 in this document.
Refer to the ICH eCTD v4.0 Implementation Guide for general information on
the files and folders.

3.3 Controlled Vocabularies

The controlled vocabularies are detailed in Section 5 and examples are given for the applicable XML
components in Section 7 (i.e., elements with controlled vocabulary).
Refer to the ICH eCTD v4.0 Implementation Guide for additional
information about the controlled vocabulary maintained by ICH and
external organizations.
3.4 ICH eCTD v4.0 XML Schema
This section outlines the required schema files for the ICH eCTD v4.0 Message.
Refer to the ICH eCTD v4.0 Implementation Guide for the schema file
inventory.

2
3.5 The eCTD v4.0 XML Message
The eCTD v4.0 message is based on the ICH eCTD v4.0 schema and has only been constrained where
noted in this Implementation Guide or the ICH eCTD v4.0 Implementation Guide. One XML message
should be created for each exchange as a Submission Unit.
Refer to the ICH eCTD v4.0 Implementation Guide for additional
information about the composition of the XML message.

3.6 OIDs and UUIDs

There are two types of unique identifiers, Object Identifiers (OIDs) and Universally Unique Identifiers
(UUIDs). The subsections below provide additional information on how they are used by the FDA
regional implementation.
Object Identifiers
Refer to the ICH eCTD v4.0 Implementation Guide for additional details.

The current OID for the FDA code lists is:

• FDA-ectd4-code-lists - 2.16.840.1.113883.3.989.5.1.2.2.1

The FDA OIDs are typically used as the code system value. Refer to the Module 1 Controlled
Vocabulary OID list for the assigned code systems.

In addition for this implementation, an OID may also be designated as the identifier application.id@root
attribute (Refer to Section ) and submission.id@root attribute (Refer to Section 7.2.8.2.1), the OID is the
namespace OID (provided by the FDA) and the identifier extension is a value assigned by that
namespace (i.e., the application or submission number).

Universally Unique Identifiers

Refer to the ICH eCTD v4.0 Implementation Guide for additional details.

When providing the application number assigned by the FDA for the application.id@root,
applicationReference.id@root or the specific case outlined in Section 7.2.8.6 for the submission
number, submission.id@root, the following OID namespaces should be used instead of a universally
unique identifier:
• CBER Application Id OID - 2.16.840.1.113883.3.989.5.1.2.2.1.15.1
• CDER Application Id OID - 2.16.840.1.113883.3.989.5.1.2.2.1.16.1

The following OID should only be used for applicationReference.id@root to identify related medical
device applications:

• CDRH Application Id OID - 2.16.840.1.113883.3.989.5.1.2.2.1.17.1

Refer to Section 7.2.10 and 7.2.12 for additional information about the use of these OIDs.

3
3.7 Data Types
Refer to the ICH eCTD v4.0 Implementation Guide for details as there are no
regional variations.

3.8 ICH eCTD v4.0 Implementation Guide for Modules 2-5

The ICH eCTD v4.0 Implementation Guide for Module 2-5 provides the instructions for organizing the
documentation in the submission (i.e., the documents and placement in the CTD). The regulatory
submission content for investigational or marketing information is mainly found in Module 2-5 of the
CTD except for the content that is administrative and region specific.

Note to Implementers: The information in this Implementation Guide is necessary,

but not sufficient for creating the complete XML message for transmission. Please
reference the ICH eCTDv4.0 Implementation Guide to send a complete XML
message. The ICH eCTD v4.0 Implementation Guide is available through the ICH
ESTRI website. (https://www.ich.org/page/electronic-standards-estri).

3.9 ICH Harmonized Elements

This section outlines the XML elements that are included in the ICH eCTD v4.0 Implementation Guide
and harmonized across the Regions unless otherwise noted in this document.
ICH Included Elements
Refer to the ICH eCTD v4.0 Implementation Guide for the ICH Included
Elements.

ICH Excluded Elements

Refer to the ICH eCTD v4.0 Implementation Guide for the ICH Excluded
Elements.

3.10 FDA-Specific Elements

The elements and business rules that are specific to the FDA are covered in this document.
FDA Included Elements
The following elements are included in this document with additional regional guidance:
• submissionUnit
• keyword
• submission
• contactParty
• application
o reference.applicationReference
o holder.applicant
• contextOfUse
o subjectOf.submissionReference

4
 FDA Excluded Elements
In addition to the excluded elements in the ICH eCTD v4.0 Implementation Guide for Module 2-5, there
were region-specific elements identified that may also be excluded from the FDA implementation. The
following elements are excluded from the FDA implementation of eCTD v4.0 and should not be
included in the XML Message:
• application
o subject.ReviewProcedure
o informationRecipient.territorialAuthority
• submission
o subject1.regulatoryStatus
o subject3.mode
o subject4.regulatoryReviewTime
o subject5.submissionGroup

• review
o subject1.manufacturedProduct
o subject2.productCategory
o subject3.regulatoryStatus
o holder.applicant
o author.territorialAuthority

• categoryEvent

4. SUBMISSION CONTENTS, FOLDER AND FILE STRUCTURE

The folder and file structure specified for the document contents being transmitted along with the XML
message should follow various specifications and rules as presented below in this section.
4.1 Folder Structure and Submission Unit Contents
When submitting the contents of a Submission Unit, the following structure should be used:
The Regionally-specified Folder is not included in the FDA Module 1 implementation. This
folder should not be included in the submission unit package.
The Sequence Number Folder must be submitted and named with the “sequence number” of the
Submission Unit i.e., the actual value of the sequence number (e.g., 1).
The applicant will be sending submission contents as one Submission Unit within each message
transmission. All documents in the submission must be placed in a main submission folder using
sequence number (which you must specify) that is unique within the application. Figure 1: Submission
Unit depicts the folder structure for a Submission Unit sent by the applicant.

5
 Figure 1: Submission Unit Folder
Sequence Number Folder

Refer to the ICH eCTD v4.0 Implementation Guide for additional

information about the submission unit contents.
When there is more than one Submission in the Submission Unit (i.e., a grouped submission), all
submitted documents must be referenced by only one application element, this is considered the primary
application. The sequence number of the primary application must be designated as the sequence
number folder as depicted in Figure 1. See Section 7.3 Grouped Submissions for additional information.

4.2 Naming Conventions

Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

4.3 Allowable Characters

Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

4.4 Length
Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

4.5 Pathname Conventions and Best Practices

Refer to the ICH eCTD v4.0 Implementation Guide for details. For
instruction on file reuse, see the File Reuse Appendix in Section 9.

4.6 Folder Hierarchy

Refer to the ICH eCTD v4.0 Implementation Guide for additional
information.

Note: Module 1 typically has one folder. In all modules, only use subfolders if the files warrant an
additional level of organization or to comply with other FDA technical specification or guidance.

6
4.7 File Formats
In the eCTD v4.0 message, file formats are not specified by the ICH eCTD v4.0 Implementation Guide
and are not maintained in this document. Refer to Section 3.1 Referenced Documents for additional
information on file formats.
4.8 Checksums
Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

4.9 Compressed Archive

Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

5. CONTROLLED VOCABULARIES
As described in Section 3.3, there is extensive use of controlled vocabularies in the execution of an
eCTD v4.0 message. The information in the following sub-sections outline the controlled vocabulary
used in developing an eCTD v4.0 message. There are several different authoritative sources for the
controlled vocabulary, and as such they are categorized below by the organization that controls the
content.
Note to Implementers: The controlled vocabulary is provided both in
genericode and spreadsheet file formats.

5.1 Controlled Vocabularies Specified Regionally

The controlled vocabularies specified by the FDA for the eCTD v4.0 implementation are provided in the
Module 1 Controlled Vocabulary files (e.g., genericode or spreadsheet). The codeSystem OIDs and
code values for each of the code sets are defined by FDA and are available in the associated documents.
The following vocabularies have additional values defined by the FDA:
• US Application Type
• US Context of Use
• US CoU Keyword Definition Type
• US Form Type
• US Promotional Document Type
• US Promotional Material Audience Type
• US Promotional Material Type
• US Submission Contact Status
• US Submission Contact Type
• US Submission Type
• US Submission Unit Status
• US Submission Unit Type
• US Telecom Capabilities
• US Telecom Use

7
5.2 Excluded Regional Vocabularies
The FDA controlled vocabulary is only provided for code elements that are allowed. There are elements
and their code attributes which are excluded from the FDA controlled vocabulary. The excluded code
lists include:
• applicationReference.reasonCode@code (Application Reference Reason)
• ingredientSubstance.code@code (Ingredient)
• manufacturedProduct.code@code (Product)
• mode.code@code (Mode)
• territory.code@code (Territorial Authority Place or Territory Named Entity)
• regulatoryReviewTime.code@code (Regulatory Review Time)
• reviewProcedure.code@code (Review Procedure)
• productCategory.code@code (Product Category)
• categoryEvent.code@code (Category Event)

Refer to Section 3.9.2 for ICH Excluded elements and 3.10.2 for FDA Excluded elements.
5.3 Controlled Vocabularies specified by ICH
Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

5.4 Controlled Vocabulary specified by HL7

The controlled vocabularies are constrained in the FDA regulatory submissions as follows:
• submissionUnit.statusCode
• submissionContact.statusCode

5.5 Sender-defined Vocabulary

Refer to the ICH eCTD v4.0 Implementation Guide for details.

6. ICH ECTD V4.0 XML SCHEMA

Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

7. ECTD V4.0 XML MESSAGE

Refer to the ICH eCTD v4.0 Implementation Guide for details as there are
no regional variations.

7.1 Message Header

The message header information provides a set of elements that are needed to specify the sender and
receiver as well as the version of the ICH and Regional/Module 1 Implementation Guides used to
generate the message.

8
 XML Elements
The following XML shows the required elements/attributes to validate the message against the schema.
Table 5: Message Header XML Structure
XML Structure
<PORP_IN000001UV ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-
org:v3 PORP_IN000001UV.xsd">
<id/>
<creationTime/>
<interactionId/> These elements should be represented with
<processingCode/> self-closing tags as shown here.
<processingModeCode/>
<acceptAckCode/> Refer to the ICH
<receiver> eCTD v4.0
<device classCode="DEV" determinerCode="INSTANCE"> Implementation
<id> Guide
<item root="" identifierName=""/>
</id>
</device>
Refer to the ICH
</receiver>
eCTD v4.0
<sender>
<device classCode="DEV" determinerCode="INSTANCE"> Implementation
<id/> Guide
</device>
</sender>
Required Elements
There are no additional instructions for the Regional/Module 1 Implementation. Refer to the ICH eCTD
v4.0 Implementation Guide for specific information.

Message Header XML Sample

The following XML sample shows the content of the message header id element. The receiver.device.id
element contains the IG versioning information required for the eCTD v4.0 Message XML header:
<id/>
<creationTime/>
<interactionId/>
<processingCode/>
<processingModeCode/>
<acceptAckCode/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<id>
<item root="2.16.840.1.113883.3.989.2.2.1.11.3" identifierName="ICH eCTD v4.0 IG
v1.4/>
<item root="2.16.840.1.113883.3.989.5.1.2.2.1.18.5" identifierName="FDA eCTD v4.0 IG
v1.4"/>

9
 </id>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<id/>
</device>
</sender>
7.2 Payload Message
The following table provides a breakdown of the eCTD v4.0 XML structure noting the placement of
each element in the XML Schema. The table is organized with the following three elements in the
structure: submissionUnit, submission and application. The elements are annotated with balloon text
boxes that provide references to either this document (outlined in blue and referenced by Section
number) or the ICH eCTD v4.0 Implementation Guide to identify the authoritative source of information
for the element.
Table 6: eCTD v4.0 XML Message Structure
XML Structure
The eCTD v4.0 begins at the controlActProcess of the payload XML message related to Module 1
content.
<controlActProcess classCode="ACTN" moodCode="EVN">
<subject typeCode="SUBJ">
The submissionUnit element contains the following Context of Use elements and their attributes:
• component.contextOfUse
o primaryInformationRecipient.TerritorialAuthority
o replacementOf.relatedContextOfUse
o derivedFrom.documentReference
o subjectOf.submissionReference
o referencedBy.keyword
Note: All of these elements are not included in this implementation guide. Refer to the ICH eCTD
v4.0 Implementation Guide for additional information.
<submissionUnit>
<id/>
submissionUnit (Section 7.2.1) – Refer to the ICH
<code/>
eCTD v4.0 Implementation Guide
<title/>
<statusCode/>
<component> priorityNumber (Section 7.2.2) – Refer to the ICH
<priorityNumber value=""/> eCTD v4.0 Implementation Guide
<contextOfUse>
<id/>
contextOfUse (Section7.2.3) – Refer to the ICH eCTD
<code/>
v4.0 Implementation Guide
<statusCode/>
<primaryInformationRecipient>
<territorialAuthority> primaryInformationRecipient.territorialAut
<governingAuthority> hority – Excluded from FDA eCTD v4.0
<id/> implementation

10
 <name/>
</governingAuthority>
</territorialAuthority>
</primaryInformationRecipient>
<replacementOf typeCode="RPLC"> replacementOf.relatedContextOfUse
<relatedContextOfUse> (Section 7.2.4) – Refer to the ICH
<id/> eCTD v4.0 Implementation Guide
</relatedContextOfUse>
</replacementOf>
<derivedFrom>
<documentReference> derivedFrom.documentReference (Section
<id/> 7.2.5) – Refer to the ICH eCTD v4.0
</documentReference> Implementation Guide
</derivedFrom>
<subjectOf negationInd=""> submissionReference (Section 7.3.1)
<submissionReference>
<id><item/></id>
</submissionReference>
</subjectOf>

<referencedBy typeCode="REFR">
<keyword>
keyword (Section 7.2.6) – Refer to the
<code/>
ICH eCTD v4.0 Implementation Guide
</keyword>
</referencedBy>
</contextOfUse>
</component>
This section of the XML relates to specifying the submission element. The following elements
may follow the componentOf1.submisision element:
• sequenceNumber (included as an element of the relationship between submissionUnit and
submission)
• callBackContact.contactParty
• subject1.regulatoryStatus
• subject2.review
o subject1.manufacturedProduct
o holder.applicant
o author.territorialAuthority
o subject2.productCategory
o subject3.regulatoryStatus
• subject3.mode
• subject4.regulatoryReviewTime
• subject5.submissionGroup
Note: All of these elements are not included in this implementation guide. Refer to the ICH eCTD
v4.0 Implementation Guide for additional information.

11
<componentOf1>
sequenceNumber.submission (Section 7.2.7) – Refer to the
<sequenceNumber/>
ICH eCTD v4.0 Implementation Guide
<submission>
<id/>
submission (Section 7.2.8) – Refer to the ICH eCTD v4.0
<code/> Implementation Guide for Transition Mapping only
<callBackContact>
<contactParty>
<id/>
<code/>
<statusCode/>
<contactPerson> callBackContact (Section
<name/>
7.2.9) – Refer to the ICH
<asAgent>
eCTD v4.0 Implementation
<representedOrganization>
Guide for Transition
<id/>
Mapping only
<name/>
</representedOrganization>
</asAgent>
</contactPerson>
</contactParty>
</callBackContact>
<subject1>
<regulatoryStatus> regulatoryStatus – Excluded from
<code/> ICH eCTD v4.0 Implementation.
</regulatoryStatus>
</subject1>
<subject2>
<review> review – Excluded from FDA eCTD v4.0
<id/> Implementation
<statusCode/>
<effectiveTime/>
<subject1>
<manufacturedProduct> manufacturedProduct.manufactured
<manufacturedProduct> Product – Excluded from FDA eCTD
<name/> v4.0 Implementation
</manufacturedProduct>
</manufacturedProduct>
</subject1> review.holder – Excluded from FDA
<holder> eCTD v4.0 Implementation
<applicant/>
</holder>
<author> review.territorialAuthority – Excluded from
<territorialAuthority/> FDA eCTD v4.0 Implementation
</author>
<subject2>
<productCategory> productCategory – Excluded from FDA
<code/> eCTD v4.0 Implementation
</productCategory>

12
 </subject2>
<subject3>
<regulatoryStatus> regulatoryStatus – Excluded from FDA
<code/> eCTD v4.0 Implementation
</regulatoryStatus>
</subject3>
</review>
</subject2>
<subject3> mode – Excluded from FDA eCTD v4.0
<mode> Implementation
<code/>
</mode>
</subject3>
<subject4>
<regulatoryReviewTime> regulatoryReviewTime – Excluded from
<code/> FDA eCTD v4.0 Implementation
</regulatoryReviewTime>
</subject4>
<subject5>
<submissionGroup> submissionGroup – Excluded from FDA
<id/> eCTD v4.0 Implementation
</submissionGroup>
</subject5>
XML Structure
This section of the XML relates to the application element. The application section contains the
following elements and their attributes:
holder.applicant
informationRecipient.territorialAuthority
subject.reviewProcedure
reference.applicationReference
component.document
referencedBy.keyword
referencedBy.keywordDefinition
<componentOf>
<application> application (Section 7.2.10) – Refer to
<id> the ICH eCTD 4.0 Implementation
<item/> Guide.
</id>
<code/>
<holder>
<applicant>
<sponsorOrganization>
<id></id> holder.applicant (Section 7.2.11)
<name></name>
</sponsorOrganization>
</applicant>
</holder>

13
 <informationRecipient>
<territorialAuthority>
<governingAuthority> informationRecipient.territorialAuth
<id/> ority – Excluded from FDA eCTD
<name/> v4.0 Implementation
</governingAuthority>
</territorialAuthority>
</informationRecipient>
<subject>
reviewProcedure – Excluded from
<reviewProcedure>
FDA eCTD v4.0 Implementation
<code/>
</reviewProcedure>
</subject>
<reference>
<applicationReference> applicationReference (Section 7.2.12)
<id/>
</applicationReference>
</reference>
<component>
document <document>
(Section 7.2.13) – <id/>
Refer to the ICH <title/>
eCTD v4.0 <text integrityCheckAlgorithm="" mediaType="" language="">
Implementation <reference/>
Guide <integrityCheck/>
</text>
<referencedBy typeCode="REFR">
keyword – <keyword>
Excluded from <code/>
the ICH eCTD </keyword>
v4.0 </referencedBy>
Implementation </document>
</component>
<referencedBy>
<keywordDefinition>
<code/>
<statusCode/>
keywordDefinitio
<value>
n (Section7.2.14)
<item code="" codeSystem="">
– Refer to the
<displayName/>
ICH eCTD v4.0
</item>
Implementation
</value>
Guide
</keywordDefinition>
</referencedBy>
</application>
</componentOf>
</submission>
</componentOf1>

14
 <componentOf2>
<categoryEvent>
<code/>
<component>
<categoryEvent> subject.categoryEvent – Excluded from
<code/> FDA eCTD v4.0 Implementation
</categoryEvent>
</component>
</categoryEvent>
</componentOf2>
</submissionUnit>
</subject>
</controlActProcess>
</PORP_IN000001UV>

All information in this section is organized in order that the eCTD v4.0 XML components appear within
the schema with the exception of special types of submissions (e.g., grouped submissions).
Submission Unit
The submissionUnit element was outlined in the ICH eCTD v4.0 Implementation Guide and only FDA
specific information is provided in this document.
7.2.1.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.1.2 XML Elements
The following tables provide a subset of XML elements and attributes required for the submissionUnit
element, and any special instructions.
The classCode and moodCode are not required in the eCTD v4.0 XML message. The
classCode is fixed to "ACT" and moodCode is fixed to "EVN". If the XML message
contains any other values for these attributes it will be invalid against the schema.

Conditions that apply to the submissionUnit element:

• Only one submissionUnit element can exist for a message.

submissionUnit.title
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
title [0..1] This is the container element that
provides a sender-defined
description of the Submission
Unit.

15
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
value [1..1] Text The value attribute of the title
element indicates the reason for
sending the Submission Unit.

Conformance If the title element is provided, the value attribute is required.

Business The submissionUnit.title element is an optional value that allows up to 128
Rules characters. Only the first 128 characters of the submissionUnit.title@value
attribute will be displayed.

This additional information allows for a brief description of the purpose of the
Submission Unit, but should not contain any reviewable information. The value
should not:
• contain a response to FDA inquiries
• replace the cover letter
• pose questions to the FDA
• contain information that is in support of an application or is needed in the
approvability or acceptability of an application, or
• contain information that is critical or needs to be reviewed.

submissionUnit.statusCode
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
statusCode [0..1] This is the container element that
indicates the status of the
Submission Unit.
code [1..1] Alpha The code attribute of the
statusCode element indicates the
active status of the Submission Unit.

Conformance If the statusCode element is provided, the code attribute is required.

Business The statusCode@code must always be active.
Rules
See instruction on how to withdraw Submission Unit and its contents in Section
7.4.
7.2.1.3 Terminology
All FDA controlled vocabularies are provided in the genericode and spreadsheet files. 1

1
Final Implementation Terminology is provided on the FDA website.

16
7.2.1.4 Excluded Elements
Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

Priority Number for Context of Use

The priorityNumber element was outlined in the ICH eCTD v4.0 Implementation Guide and only FDA
specific information is provided in this document.
7.2.2.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information as there
are no regional variations.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
Context of Use
The contextOfUse element was outlined in the ICH eCTD v4.0 Implementation Guide and only FDA
specific information is provided in this document.
7.2.3.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information as there
are no regional variations.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
Related Context of Use (Context of Use Life Cycle)
The relatedContextOfUse element was outlined in the ICH eCTD v4.0 Implementation Guide and only
FDA specific information is provided in this document.
7.2.4.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information as there
are no regional variations.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
Document Reference
The documentReference element was outlined in the ICH eCTD v4.0 Implementation Guide and only
FDA specific information is provided in this document.
7.2.5.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information as there
are no regional variations.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
Keyword
The Keyword element was outlined in the ICH eCTD v4.0 Implementation Guide and only FDA specific
information is provided in this document.

17
7.2.6.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.6.2 XML Elements
The following table provides a subset of XML elements and attributes required for the keyword
element, and any special instructions.

The classCode and moodCode are not required in the eCTD v4.0 XML
message. The classCode is fixed to "OBS" and moodCode is fixed to "EVN".
If the XML message contains any other values for these attributes it will be
invalid against the schema.

keyword.code
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
code [1..1] This is the container element that
identifies the keyword.
code [1..1] Text The code attribute identifies the
code value for the keyword.
e.g.,
ich_route_1,
MANU001 or
MFR_001
for
Manufacture
Site
codeSystem [1..1] Valid OID The codeSystem attribute is a
unique identifier that indicates the
controlled vocabulary system.

This should be the OID registered

for the code system.
Conformance The code and codeSystem attribute values are required.
A keyword can only have one code.
Business For Module 1 keywords, the code should be a valid value from the controlled list
Rules of FDA Module 1 keywords or provided as a keyword definition for the
application.
7.2.6.3 Terminology
All terminology is provided in genericode and spreadsheet file formats.

18
7.2.6.4 Excluded Elements
Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

Sequence Number
The sequenceNumber element was outlined in the ICH eCTD v4.0 Implementation Guide and only
FDA specific information is provided in this document.
See Section 7.3 Grouped Submissions for specific instructions for that type of Submission Unit – i.e.,
this is the only variation for sequence numbers.
7.2.7.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
Submission
The submission element describes the regulatory activity within an application.
7.2.8.1 Location in XML
The submission element in the XML message is in the following location for the regulatory activity:
• submissionUnit>> componentOf1>> submission
Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.8.2 XML Elements
The following tables provide a complete set of XML elements and attributes required for the
submission element, and any special instructions.

The classCode and moodCode are not required in the eCTD v4.0 XML
message. The classCode is fixed to "ACT" and moodCode is fixed to "EVN".
If the XML message contains any other values for these attributes it will be
invalid against the schema.

The id@xsi:type is not required in the eCTD v4.0 XML message. The xsi:type
is fixed to "DSET_II". If the XML message contains any other values for this
attribute it will be invalid against the schema.

19
 submission.id
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
id [1..1] This is the container element of
the following elements and
attributes by which it uniquely
identifies the Submission.
id.item root [1..1] Valid UUID or The root attribute of the id.item
OID element provides a unique
identifier (UUID) or the
namespace for existing
submissions (OID).
extension [0..1] Text The extension attribute of the
id.item element provides the
sequence number for the first
sequence in the regulatory activity.
Conformance The id.item@root attribute is required for the submission element.
Business Only one item element should be provided for a new v4.0 submission and must be
Rules a unique identifier (UUID).

For open regulatory activities initiated before the transition to eCTD v4.0, two
item elements should be provided when sending the first v4.0 Submission Unit for
the Submission.
• The first item should be a unique identifier (UUID).
• The second item value should indicate an OID for the namespace
(associated with the FDA Center) for the root attribute and the first
sequence number submitted for the regulatory activity for the extension
attribute. This value will be used to ensure the submission contents is
linked to the correct submission.

Note: If the Submission Unit type indicates it is an amendment to an open

regulatory activity and the submission UUID is not on file, it will not be accepted.
Therefore, the instructions above for open regulatory activities should be applied
to prevent any submission rejections.

Multiple submission elements in a Submission Unit are only accepted if a grouped

submission is submitted. Refer to Section 7.3 on Grouped Submissions.

20
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
Excluded The following datatype attributes may not be required by eCTD v4.0:
Elements • id.item @controlInformationExtension
and/or • id.item @controlInformationRoot
Attributes • id.item@displayable
• id.item @flavorId
• id.item@identifierName
• id.item @nullFlavor
• id.item@reliability
• id.item@scope
• id.item @validTimeLow
• id.item @validTimeHigh
• id.item @updateMode
• id.item@xsiType
• id@controlInformationRoot
• id@controlInformationExtension
• id@flavorId
• id@nullFlavor
• id@updateMode
• id@validTimeLow
• id@validTimeHigh

submission.code
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
code [1..1] This is the container element that
organizes the coded value for the
Submission.
code [1..1] Text The code attribute indicates a
coded value for the type of
Submission being sent.
codeSystem [1..1] Valid OID The codeSystem attribute is a
unique identifier that indicates the
controlled vocabulary system.

This should be the OID registered

for the code system.
Conformance There must be one and only one code@code and its associated code@codeSystem
attribute specified for a Submission.

21
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
Business Valid code and codeSystem attributes should be provided based on the FDA’s
Rules controlled vocabulary. Refer to the eCTD v4.0 Technical Conformance Guide and
the Controlled Vocabulary files for specific rules for the allowable submission
types for each application.
Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
and/or • code.displayName
Attributes • code.originalText
• code.source
• code.translation
• code@codeSystemName
• code@codeSystemVersion
• code@codingRationale
• code@controlInformationExtension
• code@controlInformationRoot
• code@flavorId
• code@id
• code@nullFlavor
• code@updateMode
• code@validTimeHigh
• code@validTimeLow
• code@valueSet
• code@valueSetVersion
• code@xsiType
7.2.8.3 Terminology
All FDA controlled vocabularies are provided in the genericode and spreadsheet files. 2

7.2.8.4 Excluded Elements

The following elements are not valid in messages sent to the FDA. If any of the elements are submitted,
they will not be incorporated in the systems available to the reviewers.
• submissionGroup – this element is not required and will be ignored if submitted.
• mode - this element is not required and will be ignored if submitted.
• review - this element is not required and will be ignored if submitted.
• regulatoryStatus - this element is excluded from the eCTD implementation.

7.2.8.5 XML Samples

The following is an example of the XML for the submission element.

2
Final Implementation Terminology is provided on the FDA website.

22
 New Regulatory Activities – Submitted as v4.0 Messages
The following sample depicts the required elements for sending a new regulatory activity as a v4.0
message. This should be used for the initial and any subsequent submission units to a regulatory
activity.

<componentOf1>
<sequenceNumber value="1"/>
<submission>
<id>
<item root="20b45e49-a226-4bd4-a716-bb54eba3b0ed"/>
</id>
<code code="us_submission_type_1"
codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.12.3"/>

7.2.8.6 Open Regulatory Activities Initiated before Transitioning to eCTD v4.0 -

Initial v4.0 Message
The following sample depicts the required elements for sending the initial v4.0 message to an open
regulatory activity. This should be used only for the first submission unit after the transmission mapping
message. All subsequent submission units should reference the UUID established for the regulatory
activity.
<componentOf1>
<sequenceNumber value="11"/>
<submission>
<id>
<item root="20b45e49-a226-4bd4-a716-bb54eba3b0ed"/>
<item root="2.16.840.1.113883.3.989.5.1.2.2.1.16.1" extension="0010"/>
</id>
<code code="us_submission_type_3"
codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.12.3"/>

Note the Submission number (e.g., 0010) is noted in the v3.2.2 format of four digits. All
submission numbers in v4.0 will be assigned a whole number (e.g., 10).

Contact Party
7.2.9.1 Location in XML
The contactParty element in the XML message is in the following location for contacts:
submissionUnit>>componentOf1>>submission>>callBackContact>>contactParty>contactPerson
Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.9.2 XML Elements
The following tables provide a complete set of XML elements and attributes required for the contactParty
element, and any special instructions.

23
 The callBackContact@typeCode is not required in the eCTD v4.0 XML message. The
typeCode is fixed to "CALLBCK". If the XML message contains any other values for this
attribute it will be invalid against the schema.
The contactParty@classCode is not required in the eCTD v4.0 XML message. The
classCode is fixed to "CON". If the XML message contains any other values for this
attribute it will be invalid against the schema.
The contactPerson@classCode is not required in the eCTD v4.0 XML message. The
classCode is fixed to "PSN". If the XML message contains any other values for this
attribute it will be invalid against the schema.
The asAgent@classCode is not required in the eCTD v4.0 XML message. The classCode is
fixed to "AGNT". If the XML message contains any other values for this attribute it will be
invalid against the schema.
The representedOrganization@classCode is not required in the eCTD v4.0 XML message.
The classCode is fixed to "ORG". If the XML message contains any other values for this
attribute it will be invalid against the schema.

A submission should have one or more contacts provided. Contact(s) should be provided for each new
regulatory activity and should include the appropriate regulatory and technical contacts. Only changes
to the contact parties (additions, suspensions or modifications) should be provided in future submission
units of the regulatory activity. See Section 7.2.9.6 for additional information about life cycling contact
party information within a regulatory activity.

Contact Party
7.2.9.2.1.1 callBackContact.contactParty.id
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
id [1..1] This is a container element that
organizes the contact party’s
identifier.
root [1..1] Valid The root attribute is for a global
UUID unique identifier for the contact party.
Conformance The contact party id@root attribute is required if the element is provided.
Business If contacts need to be updated the id@root value should remain the same to ensure
Rules only one contact record is on file for an individual per contact type.
Excluded The following datatype attributes may not be required by eCTD v4.0:
Elements • id@extension
and/or • id@identifierName
Attributes • id@scope
• id@reliability
• id@displayable
• id@validTimeLow
• id@validTimeHigh
• id@controlInformationRoot

24
 • id@controlInformationExtension
• id@nullFlavor
• id@flavorId
• id@updateMode

7.2.9.2.1.2 callBackContact.contactParty.code
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
code [1..1] This is a container element that
organizes the coded value for the
Contact Party.
code [1..1] Text The code attribute is a unique value
that indicates the type of Contact
e.g., Party based on Regional controlled
us_submis vocabulary.
sion_conta
ct_type_1

codeSystem [1..1] Valid OID The codeSystem attribute is a unique

identifier that indicates the controlled
vocabulary system.

This should be the OID registered for

the code system.
Conformance The code@code and code@codeSystem values are required if the contact party
element is provided.
Business Rules Valid code and codeSystem attributes should be provided based on the FDA’s
controlled vocabulary. Refer to the Controlled Vocabulary files for the contact
party type.

25
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
Excluded The following datatype attributes may not be required by eCTD v4.0:
Elements • code@codeSystemName
and/or • code@codeSystemVersion
Attributes • code@codingRationale
• code@controlInformationExtension
• code@controlInformationRoot
• code.displayName
• code@flavorId
• code@id
• code@nullFlavor
• code.originalText
• code.source
• code.translation
• code@updateMode
• code@validTimeHigh
• code@validTimeLow
• code@valueSet
• code@valueSetVersion
• code@xsiType
7.2.9.2.1.3 callBackContact.contactParty.statusCode
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
statusCode [1..1] This is a container element that
organizes the status code value for the
Contact Party.
code [1..1] Alpha The code attribute is a unique value
that indicates the status of the Contact
e.g., active Party and is based on HL7 controlled
or vocabulary constrained by the region.
suspended
updateMo [0..1] Alpha The updateMode attribute provides
de the coded value to indicate if the
e.g., R for statusCode element has been changed
Replace for the Contact Party.
Conformance A statusCode@code value should be provided if the contactParty element is
provided.
Business Rules The status code should either be active or suspended.
Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
• statusCode.part

26
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
and/or • statusCode@controlInformationRoot
Attributes • statusCode@controlInformationExtension
• statusCode@flavorId
• statusCode@nullFlavor
• statusCode@updateMode
• statusCode@validTimeLow
• statusCode@validTimeHigh

Contact Person
7.2.9.2.2.1 callBackContact.contactParty.contactPerson.name
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
name.part [1..1] This is a container element that
organizes the value of contact
person’s name.
value [1..1] String The value attribute is for the value of
e.g., Jane the name part of the Contact Party.
type [1..1] Alpha The type attribute is for the type of
e.g., GIV the name part – e.g., family name,
given name (including first name and
middle name or initial).
* note this
is a
controlled
list from
HL7 and
included in
the schema
qualifier [0..1] Alpha The qualifier attribute is a subtype of
e.g., MID, the name part – e.g., middle name or
IN initial.
* note this
is a
controlled
list from
HL7 and
included in
the schema
Conformance If a name is provided, both the part@value and part@type attributes should be
provided for each name part.

27
 Business Rules Each part of a person’s name will have its own item element and should include
the appropriate HL7 name parts.
• name.part@type as “GIV” for a first name
• name.part@type as “FAM” for a last name
• name.part@qualifier as “IN” for middle initial
• name.part@qualifier as “MID” for middle name

Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
and/or • name.part@code
Attributes • name.part@codeSystem
• name.part@codeSystemVersion
• name.part@language
• name.part@nullFlavor
• name.part@xsi:type

7.2.9.2.2.2 callBackContact.contactParty.contactPerson.telecom
The xsi:type for the telecom attribute should be listed as an unordered list or
“BAG_TEL”.

Element Attribute Cardinalit Value(s) Description

y Allowed Instructions
Examples
item [1..1] This is a container element that
organizes the Contact Party’s contact
information (e.g., telephone and
email).
value [1..1] String The value attribute provides the
e.g., Contact Party’s contact information
tel:+1(111 (e.g., telephone and email).
)999-9999
use [1..1] String The use attribute indicates the
telecom connection (e.g., workplace
e.g., WP, or mobile contact).
MC
capabilities [1..1] String The capabilities attribute indicates the
telecom service (e.g., voice or fax).
e.g., voice,
fax
Conformance An item element should have a value attribute.

28
 Business Rules The phone number value should follow the following format:
• domestic phone number has no more than 15 digits, tel:“+”, formatted as
follows: “country code”, “(area code)”, “3-digit prefix”, ‘-“ “4-digit
number”; “postd:”up to 10-digit extension”.
o For example tel:+1(111)999-9999;postd:12345
• international phone number has no more than 20 digits, formatted
as follows: tel:“+”, “phone country”, “(phone city)”, “phone local”;
“postd:”up to 10-digit extension”.
o For example “tel:+011(123)1234567890” or if no phone city,
tel:+011()1234567890

The phone number – i.e., the item element requires both the use and capabilities
attribute values. Refer to the Controlled Vocabulary for the telecom use valid
values.

The email value should follow the following format:

• value should be formatted as: “mailto:[email protected]”

Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
and/or • telecom.item@controlInformationRoot
Attributes • telecom.item@controlInformationExtension
• telecom.item@flavorId
• telecom.item@nullFlavor
• telecom.item@updateMode
• telecom.item@validTimeLow
• telecom.item@validTimeHigh
• telecom.item@xsi:type

7.2.9.2.2.3 callBackContact.contactParty.asAgent.representedOrganization.name
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
name.part [1..1] This is a container element that
organizes the value for the
represented Organization’s name.
value [1..1] String The value attribute provides the
e.g., Acme organization’s name.
Pharmace
uticals
Conformance If a contact party is provided, the organization represented should also be
provided, and the part@value attribute is required.
Business Rules The name of the organization should be provided only when the contact party is
initialized or changed.

29
 Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
and/or • name.part@code
Attributes • name.part@codeSystem
• name.part@codeSystemVersion
• name.part@language
• name.part@nullFlavor
• name.part@qualifier
• name.part@xsi:type
7.2.9.3 Terminology
All terminology is provided in genericode and spreadsheet file formats.

7.2.9.4 Excluded Elements

The following class attributes are excluded from the FDA implementation:
• contactPerson.id – note this is an additional identifier for the named individual instead of their
contactParty.id. Only the contactParty.id element is used.
7.2.9.5 XML Sample
The following XML snippet is an example of a new contact party:
<callBackContact>
<contactParty>
<id root="417e5c25-2001-40d1-af34-f1f285614187"/>
<code code="us_submission_contact_type_1"
codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.11.1"/>
<statusCode code="active"/>
<contactPerson>
<name>
<part type="GIV" value="Jane"/>
<part type="GIV" value="Mary" qualifier="MID"/>
<part type="FAM" value="Smith"/>
</name>
<telecom xsi:type="BAG_TEL">
<item value="tel:+1(212)555-1234" use="WP" capabilities="voice"/>
<item value="tel:+1(212)555-5678" use="MC" capabilities="voice"/>
<item value="tel:+1(111)999-9999" use="WP" capabilities="fax"/>
<item value="mailto:[email protected]"/>
</telecom>
<asAgent>
<representedOrganization>
<name>
<part value="Good Drugs"/>
</name>
</representedOrganization>
</asAgent>

30
 </contactPerson>
</contactParty>
</callBackContact>

7.2.9.6 Contact Party Life cycle

The Contact Party for a Submission should be provided in the initial Submission Unit and any time the
Contact Party is added, removed or contact information needs to be updated. To change the contact’s
type, suspend the previous contact and send a new contact party element with the new type. To assign
more than one contact type for an individual, send multiple contact party elements. For Grouped
Submissions, only one set of contacts should be provided under the primary application.

The following sections describe how to life cycle a contact’s information for a Submission – i.e.,
suspending and updating one or more parts of the contact party’s information.

Suspending a Contact
The contacts for a regulatory activity may change during the course of the submission review. If that
happens and a contact is no longer active, the contact should be suspended.
When suspending a contact, the contactParty element should use the same id@root attribute value to
identify the contact party and change to the status code from active to suspended using the updateMode
attribute. The sample below shows the required elements and attributes:
<callBackContact>
<contactParty>
<id root="417e5c25-2001-40d1-af34-f1f285614187"/>
<code code="us_submission_contact_type_1"
codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.11.1"/>
<statusCode code="suspended" updateMode="R" />
</contactParty>
<callBackContact>

Note: Only the required elements for the contact party are sent when suspending a contact.

Updating Contact Information

When updating contact information, use the same id@root attribute value to identify the contact party
and indicate the changed element by providing the updateMode attribute for that element. The
following subsections outline the instructions for updating each element of the Contact’s information.
There is also a complete XML sample to show the use of the updateMode attribute.
7.2.9.6.2.1 Contact Person’s Name
To make updates to a contact party’s information, the entire callBackContact element should be sent.
The values for the updateMode are indicated below depending on whether or not there is a change to the
contactPerson.name element.
• For a change – indicate by using an “R” as the name@updateMode attribute value.
• For no change – indicate by using an “N” as the name@updateMode attribute value.

31
7.2.9.6.2.2 Contact Person’s Telecom
To make updates to a contact party’s information, the entire callBackContact element should be sent.
The values for the updateMode attribute are indicated below depending on whether or not there is a
change to the contactPerson.telecom element.
• For a change – indicate by using an “R” as the telecom@updateMode attribute value.
• For no change – indicate by using an “N” as the telecom@updateMode attribute value.
7.2.9.6.2.3 Contact Person’s Address
To make updates to a contact party’s information, the entire callBackContact element should be sent.
The values for the updateMode attribute are indicated below depending on whether or not there is a
change to the contactPerson.addr element.
• For a change – indicate by using an “R” as the addr@updateMode attribute value.
• For no change – indicate by using an “N” as the addr@updateMode attribute value.
7.2.9.6.2.4 Represented Organization’s Name
To make updates to a contact party’s information, the entire callBackContact element should be sent.
The values for the updateMode attribute are indicated below depending on whether or not there is a
change to the representedOrganization.name element.
• For a change – indicate by using an “R” as the name@updateMode attribute value.
• For no change – indicate by using an “N” as the name@updateMode attribute value.

XML Sample – Updating Contact Party

The following XML snippet depicts how to send a change to the contact record. The contact’s
information should be complete each time it is submitted – i.e., each element of the contact’s
information is replaced by the update. Note that the id and code elements cannot be updated. If the id
or code element is changed, the contact will not exist and therefore cannot be changed.

<callBackContact>
<contactParty>
<id root="417e5c25-2001-40d1-af34-f1f285614187"/>
<code code="us_submission_contact_type_1"
codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.11.1"/>
<statusCode code="active" updateMode="N"/>
<contactPerson>
<name updateMode="N">
<part type="GIV" value="Jane"/>
<part type="GIV" value="Mary" qualifier="MID"/>
<part type="FAM" value="Smith"/>
</name>
<telecom xsi:type="BAG_TEL" updateMode="R">
<item value="tel:+1(212)555-9997" use="WP" capabilities="voice"/>
<item value="tel:+1(212)555-9998" use="MC" capabilities="voice"/>
<item value="tel:+1(111)999-9999" use="WP" capabilities="fax"/>
<item value="mailto:[email protected]"/>
</telecom>

32
 <addr updateMode="N">
<part xsi:type="ADXP" value="123 Main Street" type="STR"/>
<part xsi:type="ADXP" value="Anytown" type="CTY"/>
<part xsi:type="ADXP" value="NY" type="STA"/>
<part xsi:type="ADXP" value="10159" type="ZIP"/>
</addr>
<asAgent>
<representedOrganization>
<name updateMode="N">
<part value="Good Drugs"/>
</name>
</representedOrganization>
</asAgent>
</contactPerson>
</contactParty>
</callBackContact>

Application
The application element is presented in this section of the Implementation Guide as it is the connection
point for the document and keywordDefinition elements in the XML message. The concept of
Application differs across regions.
Note: Application is also a Module 2-5 concept that will also be provided in the ICH
eCTD v4.0 Implementation Guide. Additional Regional information is provided in this
document.

7.2.10.1 Location in XML

Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.10.2 XML Elements
The following tables provide a complete set of XML elements and attributes required for the application
element, and any special instructions.
The classCode and moodCode are not required in the eCTD v4.0 XML message. The
classCode is fixed to "ACT" and moodCode is fixed to "EVN". If the XML message contains
any other values for these attributes it will be invalid against the schema.

The id@xsi:type is not required in the eCTD v4.0 XML message. The xsi:type is fixed
to "DSET_II". If the XML message contains any other values for this attribute it will
be invalid against the schema.

33
Conditions that apply to the application element:
• Only one application element can be provided for each submission element.
• An application element is required to have one and only one id.item@root attribute.

application.id
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
id [1..1] This is the container element of
the following elements and
attributes by which it uniquely
identifies the application.
id.item [1..1] This is the container element of
the following attributes by which it
uniquely identifies the application.
Note: This is an FDA constraint.
root [1..1] Valid OID The root attribute of the id.item
e.g., element provides a namespace
2.16.840.1.1138 unique identifier for the FDA
83.3.989.5.1.2.2. Center.
1.16.1
extension [1..1] Text The extension attribute of the
id.item element provides a location
e.g., 123456 to specify the FDA application
tracking number.
Conformance The id.item@root attribute is required for the application element.
Business Only one id.item element should be submitted for FDA applications. If more than
Rules one application number is submitted for a Submission, the message will not be
accepted.

Multiple application elements in a Submission Unit are only accepted if a grouped

submission is submitted (i.e., multiple submission elements will also exist with
one application element per submission). Refer to Section 7.3 on Grouped
Submissions.

The id.item@root attribute is an OID namespace for the FDA Center assigned
application number provided in the id.item@extension attribute. This information
will be static through the entire life cycle of the application.

The extension value is the 6-digit value for the application number.

34
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
Excluded The following datatype attributes may not be required by eCTD v4.0:
Elements • id.item @controlInformationExtension
and/or • id.item @controlInformationRoot
Attributes • id.item@displayable
• id.item @flavorId
• id.item@identifierName
• id.item @nullFlavor
• id.item@reliability
• id.item@scope
• id.item @validTimeLow
• id.item @validTimeHigh
• id.item @updateMode
• id.item@xsiType
• id@controlInformationRoot
• id@controlInformationExtension
• id@flavorId
• id@nullFlavor
• id@updateMode
• id@validTimeLow
• id@validTimeHigh

application.code
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
code [1..1] This is the container element that
organizes the coded value for the
application.
code [1..1] Text The code attribute is a unique
value that indicates the type of
e.g., application based on the FDA
us_applicatio controlled vocabulary (e.g., NDA,
n_type_1 ANDA, BLA, etc.).
codeSystem [1..1] Valid OID The codeSystem attribute is a
unique identifier that indicates the
2.16.840.1.11 controlled vocabulary system.
3883.3.989.5.
1.2.2.1.1.2 This should be the OID registered
for the code system.
Conformance There must be one and only one code@code attribute specified for an application.

35
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
Business Valid code and codeSystem attributes should be provided based on the
Rules FDA’s controlled vocabulary. Refer to the Controlled Vocabulary files for
the application code rules and usage.
Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
and/or • code@controlInformationExtension
Attributes • code@controlInformationRoot
• code@codeSystemName
• code@codeSystemVersion
• code@codingRationale
• code.displayName
• code@flavorId
• code@id
• code@nullFlavor
• code.originalText
• code.translation
• code.source
• code@updateMode
• code@validTimeHigh
• code@validTimeLow
• code@valueSet
• code@valueSetVersion
• code@xsiType
7.2.10.3 Terminology
All FDA controlled vocabularies are provided in the genericode and spreadsheet files. 3

7.2.10.4 Excluded Elements

The following elements are not valid in messages sent to the FDA. If any of the elements are
submitted, they will not be incorporated in the systems available to the reviewers.
• informationRecipient.TerritorialAuthority – this information is not required and will be
ignored if submitted.
• subject.ReviewProcedure – this element is not required and will be ignored if submitted.
7.2.10.5 XML Samples
The following is an example of the XML for the application information. The application enters as a
componentOf element between submission and application elements.

3
Final Implementation Terminology is provided on the FDA website.

36
…
[This XML section will repeat for each application element. A submission element is a componentOf
an application element]
…

<componentOf>
<application>
<id>
<item root="2.16.840.1.113883.3.989.5.1.2.2.1.16.1" extension="456789"/>
</id>
<code code="us_application_type_1" codeSystem="2.16.840.1.113883.3.989.5.1.2.2.1.1.2"/>
…
[Additional information may appear after the addition of the application.code, for
example any of the following elements related to application – component,
referencedBy, reference, or holder]
…
</application>
</componentOf>

See XML Color Legend for color usage

Applicant
The applicant included in the message should be the same applicant on any forms submitted for the
submission unit. The applicant should be identified by the Company Name.
7.2.11.1 Location in XML
The applicant element in the XML message is in the following location for documents:
• controlActProcess>> subject>> submissionUnit>>componentOf>>submission>>
componentOf>>application>>applicant
Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.11.2 XML Elements
The following tables provide a complete set of XML elements and attributes required for the applicant
element, and any special instructions.
The classCode is not required in the eCTD v4.0 XML message. The classCode is fixed to
"SPNSR". If the XML message contains any other values for this attribute it will be invalid
against the schema.

37
 applicant.name
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
name.part [1..1] This is a container element that
organizes the value of applicant’s
name.
value [1..1] String The value attribute provides the
e.g., Acme name part of the Applicant.
Conformance The name.part@value attribute is required.
Business Rules The applicant’s name should represent the applicant/sponsor of the application.
Excluded The following datatype elements and attributes may not be required by eCTD
Elements v4.0:
and/or • name.part@code
Attributes • name.part@codeSystem
• name.part@codeSystemVersion
• name.part@language
• name.part@nullFlavor
• name.part@qualifier
• name.part@xsi:type
7.2.11.3 Terminology
There is no controlled terminology for this element.

7.2.11.4 Excluded Elements

The following class attributes are not valid in messages sent to the FDA. If any of the values are
submitted, they will be ignored.
• applicant.sponsoringOrganization.id
• applicant.sponsoringOrganization.addr
• applicant.sponsoringOrganization.telecom

To provide contact information, see Section 7.2.9 for contact party instructions.
7.2.11.5 XML Samples
The following is an example of the XML for the applicant information. The applicant element follows
the application.code element.
<holder>
<applicant>
<sponsorOrganization>
<name >
<part value="Acme Pharmaceuticals"/>
</name>
</sponsorOrganization>
</applicant>

38
</holder>

Application Reference
An application may reference another application that was previously sent to the FDA, the
applicationReference element should be used to indicate the related application. The sender may
reference applications in other FDA Centers, however content 4 (i.e., documents or files) may not be
reused by reference.
7.2.12.1 Location in XML
The application element in the XML message is in the following location for documents:
• controlActProcess>> subject>> submissionUnit>>componentOf>>submission>>
componentOf>>application>>reference>>applicationReference
Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.12.2 XML Elements
The following tables provide a complete set of XML elements and attributes required for the
applicationReference element, and any special instructions.
The classCode and moodCode are not required in the eCTD v4.0 XML message. The
classCode is fixed to "ACT" and moodCode is fixed to "EVN". If the XML message
contains any other values for these attributes it will be invalid against the schema.

The application may have zero to many application references. For each application reference, an
applicationReference element should be provided.

applicationReference.id
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
id [1..1] This is the container element of
the following elements and
attributes by which it uniquely
identifies the referenced
application.
root [1..1] Valid OID The root attribute of the id element
provides a namespace unique
2.16.840.1.1138 identifier for the FDA Center.
83.3.989.5.1.2.2.
1.16.1
extension [1..1] Text The extension attribute of the id
element provides a location to
e.g.,MF012345 specify the FDA application
tracking number being referenced.

4
Each FDA Center has its own document repository and content cannot be referenced across Centers.

39
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
Conformance The id@root attribute is required for the applicationReference element.
Business Only one id@root and id@extension attributes should be submitted for each FDA
Rules application reference. Multiple applicationReference elements may be provided
for the regulatory activity/submission.

The id@root attribute is an OID namespace for the FDA Center assigned
application number provided in the id@extension attribute.

The extension value should be composed of the case-sensitive (specifically

uppercase) application type prefix (e.g., IND, MF, etc.) and the assigned value
(e.g., 6 digits) for the application number. The application type prefix will be used
to determine the reason for reference (e.g., MF for the Drug Master File). Refer to
Section 10 Appendix: Application Prefix for a list of valid prefixes.

An Application Reference only needs to be sent once for that application.

Excluded The following datatype attributes may not be required by eCTD v4.0:
Elements • id@controlInformationRoot
and/or • id@controlInformationExtension
Attributes • id@displayable
• id@flavorId
• id@identifierName
• id@nullFlavor
• id@reliability
• id@scope
• id@validTimeLow
• id@validTimeHigh
• id@updateMode
• id@xsi:type
7.2.12.3 Terminology
All FDA controlled vocabularies are provided in the genericode and spreadsheet files. 5

7.2.12.4 Excluded Elements

The following class attributes are excluded for the applicationReference element:
• applicationReference.reasonCode
7.2.12.5 XML Samples
The following is an example of the XML for the application reference information. The
applicationReference follows the holder element.

5
Final Implementation Terminology is provided on the FDA website.

40
<reference>
<applicationReference>
id root="2.16.840.1.113883.3.989.5.1.2.2.1.16.1" extension="MF012345"/>
</applicationReference>
</reference>

Document
The document element was outlined in the ICH eCTD v4.0 Implementation Guide and only FDA
specific information is provided in this document.
7.2.13.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information as there
are no regional variations.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.

Keyword Definitions
The keywordDefinition element was outlined in the ICH eCTD v4.0 Implementation Guide and only
FDA specific information is provided in this document.
7.2.14.1 Location in XML
Refer to the ICH eCTD v4.0 Implementation Guide for additional information as there
are no regional variations.

Refer to Table 6: eCTD v4.0 XML Message Structure for the XML representation.
7.2.14.1 Terminology
There are additional regional keyword definition types for the Module 1 content.
All FDA controlled vocabularies are provided in the genericode and spreadsheet files. 6

6
Final Implementation Terminology is provided on the FDA website.

41
7.3 Grouped Submissions
A grouped submission is a single Submission Unit applied to more than one Submission. A grouped
submission is also known as a global supplement, global submission, bundled supplement, bundled
submission, multiple product submission or trans-BLA. This type of submission eliminates the need to
submit multiple, identical submission units to different applications. The grouped submission concept
does not replace non-eCTD cross referencing functionality (e.g., use of m1.4.4).

Grouped submissions are the only business case for sending a Submission Unit with more than one
componentOf.submission element (e.g., manufacturing changes that affect more than one
application). If a Submission Unit does not meet the following criteria, it should not be sent to the
FDA:
• All contents in the Submission Unit relate to all Submissions in the Submission Unit.
o The exception is the FDA Forms that should accompany each Submission.
• Each Submission in the group has a unique sequence number for that application.
• When sending any Context of Use life cycle – the operation will apply to all submissions in the
group.
• The keyword definitions code and value pair should have the same codes across all applications.
o The keyword definitions must exist for all applications in the group.
o The keyword code and its value should be specified once per Context of Use.
• All submission contents must be placed in the primary application’s sequence folder.
• All submissions in the group must have the same application code.
• All submissions in the group must have the same submission code.
• All documents must be specified under ONE application element in the submissionunit.xml file.
• If documents are included in more than one application element, the group submission will be
rejected.
Grouped submissions have additional requirements in the submission unit message, which are outlined
below and presented in this section:

• Sequence Numbers – should follow the same instructions in the ICH eCTD v4.0 Implementation
Guide unless the following scenario exists:
o There is more than one submission/regulatory activity in an application that is part of the
grouped submission. In this case all regulatory activities within that application should have
the same sequence number. E.g., Grouped Submission Unit includes the following:
 Submission #10 - (Sequence Number #20) – Application #1
 Submission #15 - (Sequence Number #20) – Application #1
Note – the sequence number is “20” for both submissions in the application, this is because the
sequence is received together and contains the same submission contents.
• Submission Reference (See Section 7.3.1) – this element is used to associate specific content to one
or more applications in the submission on the context of use elements.
Refer to the implementation package for grouped submission examples and the Module 1 contents of its
submission unit. Specific instructions are provided for the following elements when included in a
grouped submission (e.g., contacts, submission references, etc.).

42
 Refer to the FDA eCTD v4.0 Implementation Package for XML Samples.

Submission Reference
The submissionReference element is used to indicate when a contextOfUse element is not relevant to a
specific Submission within a submissionUnit element.
7.3.1.1 Location in XML
The submissionReference element in the XML message is in the following location:
submissionUnit>> component>>contextOfUse> replacementOf > derivedFrom > subjectOf
7.3.1.2 XML Elements
The following is an example of a submissionReference element:
<subjectOf negationInd="true">
<submissionReference>
<id>
<item root="5cfec3c5-2fd2-45fb-b92f-3a70d261467b"/>
<item root="ae57b6fe-6a18-4bac-a3aa-f7540078b25a"/>
</id>
</submissionReference>
</subjectOf>
See instructions for when to provide one or more submission reference items. These should be used
only for grouped submissions.
Only one submissionReference element should be used for each contextOfUse element, but it may have
multiple items.
The subjectOf@negationInd attribute value shall be “true” for any submissionReference
element.

submissionReference.id
Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
id [1..1] This is the container element of the
following elements and attributes
by which it uniquely identifies the
referenced submission.
id.item [1..*] This is the container element for the
attributes by which it uniquely
identifies the referenced
submission.

43
 Element Attribute Cardinality Value(s) Description
Allowed Instructions
Examples
root [1..1] Valid UUID The root attribute of the id.item
element provides a global unique
identifier for the referenced
submission in the group.
Conformance The id.item@root attribute is required.
Business More than one item element may be provided. This should only be used for
Rules grouped submissions to designate the FDA forms (e.g., 356h) that are not
associated with a Submission.
The UUID must exist as one of the submission identifiers in the grouped
submission.
Excluded The following datatype attributes may not be required by eCTD v4.0:
Elements • id.item @controlInformationExtension
and/or • id.item @controlInformationRoot
Attributes • id.item@displayable
• id.item @flavorId
• id.item@identifierName
• id.item @nullFlavor
• id.item@reliability
• id.item@scope
• id.item @validTimeLow
• id.item @validTimeHigh
• id.item @updateMode
• id.item@xsiType
• id@controlInformationRoot
• id@controlInformationExtension
• id@flavorId
• id@nullFlavor
• id@updateMode
• id@validTimeLow
• id@validTimeHigh
7.3.1.1 Terminology
There is no controlled terminology for this element.

7.3.1.2 Excluded Elements

No class elements are excluded for the submissionReference element.
Grouped Submission Sample
Refer to the FDA eCTD v4.0 Implementation Package for XML Samples.

44
7.4 Withdrawing Submission Contents
If a Submission Unit is sent in error, a new Submission Unit should be submitted and all of the Context
of Use elements need to either be suspended – i.e., they will be shown as inactive or a replace function
needs to be provided to reinstate the previous document as the current submission contents.
Refer to the ICH eCTD v4.0 Implementation Guide for more details for suspend and
replace operations.

7.5 Promotional Materials

For Submission Units that include promotional materials, additional information (e.g., keywords) is
required.
Refer to the FDA eCTD v4.0 Implementation Package for Module 1 Controlled
Vocabulary files with the valid keyword for promotional materials.
Refer to the eCTD v4.0 Technical Conformance Guide for additional information.

45
8. TRANSITION MAPPING MESSAGE FROM ECTD V3.2.2
In addition to the instructions presented in the ICH eCTD v4.0 Implementation Guide, the FDA allows
transition of eCTD v3.2.2 based on both Module 1 versions of the DTD – i.e., v2.01 and v3.3. The FDA
Controlled Vocabulary provides the valid values for both versions of the DTD. The information
provided below supplements instructions in the ICH eCTD v4.0 Implementation Guide for the
Transition Mapping Message.
8.1 Message Header
The message header information provides a set of elements that are needed to specify the sender and
receiver as well as the version of the ICH and Regional/Module 1 Implementation Guides used to
generate the message.
XML Elements
The following XML shows the required elements/attributes to validate the message against the schema.
Table 7: Message Header XML Structure
XML Structure
<PORP_IN000001UV ITSVersion="XML_1.0"xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-
org:v3 PORP_IN000001UV.xsd">
<id/>
<creationTime/>
<interactionId/> These elements should be represented with self-
<processingCode/> closing tags as shown here.
<processingModeCode/>
<acceptAckCode/>
<receiver>
<device classCode="DEV" determinerCode="INSTANCE"> Refer to the ICH
<id> eCTD v4.0
<item root="" identifierName=""/> Implementation
</id> Guide
</device>
</receiver>
<sender> Refer to the ICH
<device classCode="DEV" determinerCode="INSTANCE"> eCTD v4.0
<id/> Implementation
</device> Guide
</sender>

Required Elements
No additional instructions provide for the Regional/Module 1 Implementation. Refer to the ICH eCTD
v4.0 Implementation Guide for specific information.

46
 Message Header XML Sample
The following XML sample shows the content of the message header id element. The receiver.device.id
element contains the IG versioning information required for the Transition Mapping Message XML
header:
<id/>
<creationTime/>
<interactionId/>
<processingCode/>
<processingModeCode/>
<acceptAckCode/>
<receiver typeCode="RCV">
<device classCode="DEV" determinerCode="INSTANCE">
<id>
<item root="2.16.840.1.113883.3.989.2.2.1.11.3" identifierName="ICH eCTD v4.0 IG
v1.4"/>
<item root="2.16.840.1.113883.3.989.5.1.2.2.1.18.5" identifierName="USFDA eCTD v4.0
IG v1.4"/>
</id>
</device>
</receiver>
<sender typeCode="SND">
<device classCode="DEV" determinerCode="INSTANCE">
<id/>
</device>
</sender>

8.2 Payload Message

The following table shows the relevant elements and attributes in the v3.2.2 Transition Mapping Message.
Table 8: Transition Mapping Message Payload XML Structure
XML Structure
The eCTD v4.0 begins at the controlActProcess of the payload XML message related to Module 1
content.
<controlActProcess classCode="ACTN" moodCode="EVN">
<subject typeCode="SUBJ">
The submissionUnit element contains the following Context of Use elements and their attributes:
• component.contextOfUse
o primaryInformationRecipient.TerritorialAuthority
o replacementOf.relatedContextOfUse
o derivedFrom.documentReference
o subjectOf.submissionReference
o referencedBy.keyword
Note: These elements are not included in this implementation guide. Refer to the ICH eCTD v4.0
Implementation Guide for additional information.

47
<submissionUnit>
<id/>
submissionUnit – Refer to the ICH eCTD v4.0
<code/>
Implementation Guide
<title/>
<statusCode/>
<component>
<priorityNumber value=""/> priorityNumber – Refer to the ICH eCTD v4.0
<contextOfUse>
Implementation Guide
<id/>
<code/>
<statusCode/> contextOfUse – Refer to the ICH eCTD v4.0
<primaryInformationRecipient> Implementation Guide
<territorialAuthority>
<governingAuthority> primaryInformationRecipient.territorialAuth
<id/> ority – Excluded from FDA eCTD v4.0
<name/> Implementation
</governingAuthority>
</territorialAuthority>
</primaryInformationRecipient>
<replacementOf typeCode="RPLC">
<relatedContextOfUse> replacementOf.relatedContextOfUse
<id/> – Excluded from FDA eCTD v4.0
</relatedContextOfUse> Transition Mapping Message
</replacementOf>
<derivedFrom>
<documentReference> derivedFrom.documentReference – Refer
<id/> to the ICH eCTD v4.0 Implementation
</documentReference> Guide
</derivedFrom>
<subjectOf negationInd="">
submissionReference – Excluded from FDA
<submissionReference>
eCTD v4.0 Transition Mapping Message
<id><item/></id>
Implementation
</submissionReference>
</subjectOf>

<referencedBy typeCode="REFR">
<keyword>
keyword – Refer to the ICH eCTD v4.0
<code/>
</keyword> Implementation Guide
</referencedBy>
</contextOfUse>
</component>

48
This section of the XML relates to specifying the Submission element. The following elements
may follow the componentOf1.submisision element:
• sequenceNumber (included as an element of the relationship between submissionUnit and
submission)
• callBackContact.contactParty
• subject1.regulatoryStatus
• subject2.review
o subject1.manufacturedProduct
o holder.applicant
o author.territorialAuthority
o subject2.productCategory
o subject3.regulatoryStatus
• subject3.mode
• subject4.regulatoryReviewTime
• subject5.submissionGroup
Note: All of these elements are not included in this implementation guide. Refer to the ICH eCTD
v4.0 Implementation Guide for additional information.
<componentOf1>
sequenceNumber.submission – Refer to the ICH eCTD v4.0
<sequenceNumber/> Implementation Guide
<submission>
<id/> submission – Refer to the ICH eCTD v4.0 Implementation
<code/> Guide for Transition Mapping
<callBackContact>
<contactParty>
<id/>
<code/>
<statusCode/>
<contactPerson>
<name/> callBackContact (Section 7.2.9)
<asAgent> – Refer to the ICH eCTD v4.0
<representedOrganization> Implementation Guide for
<id/> Transition Mapping
<name/>
</representedOrganization>
</asAgent>
</contactPerson>
</contactParty>
</callBackContact>
<subject1> regulatoryStatus – Excluded
<regulatoryStatus> from FDA eCTD v4.0 Transition
<code/> Mapping Message Implementation
</regulatoryStatus>
</subject1>
<subject2>
<review>
review – Excluded from FDA eCTD v4.0
<id/>
Transition Mapping Message Implementation
<statusCode/>

49
 <effectiveTime/>
<subject1> manufacturedProduct.manufacturedP
<manufacturedProduct> roduct – Excluded from FDA eCTD
<manufacturedProduct> v4.0 Transition Mapping Message
<name/> Implementation
</manufacturedProduct>
</manufacturedProduct>
</subject1> review.holder – Excluded from FDA eCTD
<holder> v4.0 Transition Mapping Message
<applicant/>
</holder>
<author> review.territorialAuthority – Excluded from
<territorialAuthority/> FDA eCTD v4.0 Transition Mapping Message
</author> Implementation
<subject2>
<productCategory> productCategory – Excluded from FDA
<code/> eCTD v4.0 Transition Mapping Message
</productCategory> Implementation
</subject2>
<subject3>
<regulatoryStatus> regulatoryStatus – Excluded from FDA
<code/> eCTD v4.0 Transition Mapping Message
</regulatoryStatus> Implementation
</subject3>
</review>
</subject2> mode – Excluded from FDA eCTD v4.0
<subject3> Transition Mapping Message
<mode> Implementation
<code/>
</mode>
</subject3>
<subject4> regulatoryReviewTime – Excluded from
<regulatoryReviewTime> FDA eCTD v4.0 Transition Mapping
<code/> Message Implementation
</regulatoryReviewTime>
</subject4>
<subject5> submissionGroup – Excluded from FDA
<submissionGroup> eCTD v4.0 Transition Mapping Message
<id/> Implementation
</submissionGroup>
</subject5>
XML Structure
This section of the XML relates to the application element. The application section contains the
following elements and their attributes:
holder.applicant
informationRecipient.territorialAuthority
subject.reviewProcedure
reference.applicationReference

50
component.document
referencedBy.keyword
referencedBy.keywordDefinition

<componentOf>
<application> application
<id> Refer to the ICH eCTD 4.0
<item/> Implementation Guide.
</id>
<code/>
<holder>
<applicant>
<sponsorOrganization>
<id></id> holder.applicant (Section 7.2.11)
<name></name>
</sponsorOrganization>
</applicant>
</holder>
<informationRecipient>
<territorialAuthority>
<governingAuthority> informationRecipient.territorialAuth
<id/> ority – Excluded from FDA eCTD
<name/> v4.0 Transition Mapping Message
</governingAuthority> Implementation
</territorialAuthority>
</informationRecipient>
<subject> reviewProcedure – Excluded from
<reviewProcedure>
FDA eCTD v4.0 Transition Mapping
<code/>
Message Implementation
</reviewProcedure>
</subject>
<reference>
<applicationReference> applicationReference – Excluded from
<id/> FDA eCTD v4.0 Transition Mapping
</applicationReference> Message Implementation
</reference>

51
 <component>
document – Refer <document>
to the ICH eCTD <id/>
v4.0 <title/>
Implementation <text integrityCheckAlgorithm="" mediaType="" language="">
Guide <reference/>
<integrityCheck/>
</text>
<referencedBy typeCode="REFR">
keyword – <keyword>
Excluded from <code/>
FDA eCTD v4.0 </keyword>
Transition </referencedBy>
Mapping </document>
Message </component>
Implementation <referencedBy>
<keywordDefinition>
<code/>
<statusCode/>
keywordDefinition <value>
– Refer to the ICH <item code="" codeSystem="">
eCTD v4.0 <displayName/>
Implementation </item>
Guide </value>
</keywordDefinition>
</referencedBy>
</application>
</componentOf>
</submission>
</componentOf1>
<componentOf2>
<categoryEvent>
<code/>
<component>
<categoryEvent> componentOf2.categoryEvent – Excluded from FDA
<code/> eCTD v4.0 Transition Mapping Message
</categoryEvent> Implementation
</component>
</categoryEvent>
</componentOf2>
</submissionUnit>
</subject>
</controlActProcess>
</PORP_IN000001UV>

The ICH eCTD v4.0 Implementation Guide contains the specific information on transitioning the current
view of the application prior to submitting eCTD v4.0 messages, known as the transition mapping
message. This section contains the region-specific .

52
 Keywords in TMM
It is important to note that all keywords may not have existed as attributes in the ICH or FDA eCTD
backbone (i.e., DTD files). Keywords therefore may need to be transitioned from multiple locations
from eCTD v3.2.2 messages.
• Keywords may be transitioned from the following sources:
o ICH or FDA DTD Attributes
o DTD v2.01 CTD Headings include the form-type keywords
o The STF file also includes the following eCTD v4.0 keywords
 Document Types (previously specified as the file-tag element)
 Study-title (previously specified as the title element)
 Study-id
 Duration, Species, Route of Administration, and Type of Control (previously
specified as the Category element)
 Site-id (previously specified as the property element)
• Consolidation of Keywords from the following attributes:
o Study Id and Study Title – follow the instructions in the ICH eCTD v4.0 Implementation
Guide to merge the values of these two attributes when transitioning from v3.2.2 to v4.0.
Post Transition
The following special instructions should be followed for submissions received after the Transition
Mapping message is submitted.
Sequence number – follows the same instructions in the ICH eCTD v4.0 Implementation Guide
unless the following scenario exists:
o After receipt of the Transition Mapping message, the sequence number should continue to be
assigned sequentially and issued as whole numbers instead of following the v3.2.2
instructions for 4-digit values with leading zeros.
Submission Number – follows the same instructions in the ICH eCTD v4.0 Implementation
Guide unless the following scenario exists:
o If continuing a regulatory activity, the submission number should reference the initial
sequence for the regulatory activity using the id@root attribute for the appropriate namespace
OID (e.g., CDER or CBER OID) and id@extension attribute for the sequence number
submitted for the initial submission unit for the regulatory activity. Please reference the
eCTD v4.0 Technical Conformance Guide for additional information when submitting eCTD
v4.0 messages to regulatory activities initiated before the transition to eCTD v4.0.
Document and File Reuse – only documents (and reference to associated files) that need to be
life cycled in v4.0 or used in other applications should be transitioned. If documents are not
transitioned, they will need to be resubmitted in eCTD v4.0 in order to be referenced (i.e., for
document or file reuse).

Grouped Submission – all applications in the group must be transitioned prior to submitting an
eCTD v4.0 message for that group. In addition, all keywords should be standardized across
applications during and after the transition to enable Grouped Submissions.

53
9. APPENDIX: FILE REUSE
The document element should follow the ICH eCTD v4.0 Implementation Guide, including the section
“Considerations for the Document Element”.
In most cases document reuse should be used when referencing previously submitted content. For any
file previously submitted that requires a new title (i.e., the content does not change) a new document
element may be submitted to FDA according to the following file reuse requirements.
The text.reference@value attribute must include the relative path of the file previously submitted. The
file may have been referenced by a previously submitted document element in the same or different
application (see examples below). To reference the file, the location of the previous file must be placed
in the text reference value attribute with the following components, as applicable:
• Application Number – includes the application type prefix and the 6 digits of the application
number that is represented by the application number (i.e. application.id.item@extension)
transmitted with the original contents. Prefix values are presented in Table 9: Application Prefix
in Section 10. Note that the application number is only provided when the referenced file is in a
different application.
• Sequence Number for the Submission Unit in which the file was originally submitted.
• The remainder of the path must be included as it existed when the Submission Unit was
submitted to the FDA Center 7 (i.e., “m1/promotional_website.pdf”)
File path example for a file in a different application:
<reference value="../../NDA123456/99/m1/promotional_website.pdf"/>

File path example for a file in the same application:

<reference value="../99/m1/promotional_website.pdf"/>

For other text elements and attributes should be the same as the previously submitted document element:
• text@IntegrityCheckAlgorithm
• text.integrityCheck

The following snippet provides an example of how to send a new document element for an existing file.
<component>
<document>
<id root="51a1c7d0-5275-48e3-9ebe-5a7e597612bf"/>
<title value="New Document Title for File Reused from APP#123456"/>
<text integrityCheckAlgorithm="SHA256">
<reference value="../../NDA123456/99/m1/promotional_website.pdf"/>
<integrityCheck>576be0c1495daf8dfec41355654570d50f286d1266613335b7690a670746a6
d3</integrityCheck>
</text>
</document>
</component>

Note: the document identifier and title must be unique to the new document element.

7
Each FDA Center has its own document repository and content cannot be referenced across Centers.

54
10. APPENDIX: APPLICATION PREFIX

The application prefix may be applied to the following two element values:

• applicationReference.id@extension – the value is a reference to an application previously

submitted to the FDA 8 that relates to the current submission
• document.text.reference@value – the value indicates the relative path for the document
previously submitted to the FDA Center

The prefix must be in uppercase when including as a value – i.e., the application type prefix is case-
sensitive.
Table 9: Application Prefix
Application Type Prefix Comments
New Drug Application NDA
Abbreviated New Drug Application ANDA
Biologic License Application BLA
Investigational New Drug IND
Drug Master File MF
Emergency Use Authorization EUA
Investigational Device Exemption IDE The IDE, PMA, and 510K
application types should
Premarket Approval Application PMA only be used in the
Premarket Notification 510k 510K applicationReference
element along with the
CDRH Application Id OID.

8
The value provided may reference applications in another FDA Center

55