You are here

TGA Internet site archive

The content on this page and other TGA archive pages is provided to assist research and may contain references to activities or policies that have no current application. See the full archive disclaimer.

TGA presentations given at ARCS eCTD workshop, December 2014

Presentations: eSubmissions in Australia

17 December 2014


These presentation papers are provided on the TGA's website solely for the purpose of indicating or suggesting what TGA representatives spoke about to the various conferences and seminars to which it relates. The papers are not legislative in nature and should not be taken to be statements of any law or policy in any way.

The Australian Government Department of Health (of which the TGA is a part) advises that (a) the presentation papers should not be relied upon in any way as representing a comprehensive description of regulatory requirements, and (b) cannot guarantee, and assumes no legal liability or responsibility for, the accuracy, currency or completeness of the information contained in the presentation paper.

Presentation: eSubmissions in Australia - Part 1

  • Presented by: Dr John Donohoe, Director, Knowledge Management, Office of Medicines Authorisation, Market Authorisation Group, Therapeutic Goods Administration
  • Presented at: ARCS eCTD workshop, December 2014
  • Presentation summary: This presentation provided an updated on the pilot phase for eCTD for prescriptions medicines in Australia.


Presentation: eSubmissions in Australia - Part 1

Dr John Donohoe
Director, Knowledge Management
Office of Medicines Authorisation
Market Authorisation Group

eCTD Workshop - Melbourne, December 2014

Slide 1 - The road to eCTD

  • Transition to CTD - 2004
  • Implementation of NeeS - 2011
  • Implementation of eCTD capability - 2014
    • Revised AU Module 1
  • Past Activities

Slide 2 - eCTD at TGA

  • Integration of business processes
    • Records management, application management, evaluators
    • Total Lifecycle Management of products
  • Capacity and capability building
    • Support, training for internal and external staff
    • Updating guidance, processes, services
  • Update on progress with the Pilot phase

Slide 3 - The road to eCTD

Past Activities - revised AU Module 1

  • Alignment with EU - revised structure
  • Separate lifecycle tracking table
  • Moved to application form
    • human embryos/embryonic stem cells
    • GMP information
    • individual patient data
  • Used global terminology where possible e.g. changed "Overseas" to "Foreign"
  • Flexibility for non-prescription medicines

Slide 4 - The road to eCTD

  • Expanded internal training programme
  • Lessons from pilot submissions
  • Alignment of existing business process
  • Review of consultation process
  • Updates to specifications and system configuration
  • February 2015 - Assessment of experience with, and readiness for, eCTD
  • Current Activities and Next Steps

Slide 5 - The road to eCTD

Some numbers...

  • 1231 NeeS Submissions as of June 2014
  • 1856 Approvals in 2013 for Prescription Category 1 and Category 3 Applications*
  • 2808 Approvals in 2013 for Over the Counter Applications*
  • Developing capacity to evaluate electronically
  • 7 eCTD submissions received in eCTD pilot

* Numbers taken from the TGA Half-yearly performance reports, July to December 2013, Published May 2014

Slide 6 - The road to eCTD

The eCTD Pilot Phase
  • Working with applicants to identify suitable eCTD submissions for the pilot phase
  • Developing various aspects of system
  • Looking for a range of application types:
    • new chemical entity
    • major variations to a prescription medicine (both with and without baseline)
    • generic medicine
    • submissions prepared with different publishing tools
    • prescription / non-prescription medicines
    • master files

Please contact if you wish to discuss being involved with the pilot phase

Slide 7 - The eCTD pilot

Current business protocol for submitting an eCTD
  • Participation in pilot phase
  • Obtaining the eSubmission Identifier - submit written request to
  • The Cover Letter - Paper copy should be submitted until Portal is implemented
  • Validation Reports - Electronic copy should be submitted in e.g. "0000-validation-report" folder
  • Expected Structure of Submitted Media
    • Submit in folder named after eSubmission Identifier.
    • Preference is that entire application should not span multiple devices
  • Media Formats - flexible
  • Feedback on Validation of Application
    • TGA will inform applicants if problems are experienced during the upload of an eCTD sequence.
    • Confirmation of delivery is through the courier company

Slide 8 - eCTD document matrix

screenshot showing eCTD document matrix

Slide 9 - Building regulatory activities and submission numbering

Regulatory activity
  • The entire group of sequences supporting a specific regulatory activity Identified/established by the submission type e.g., an original application and all its amendments leading to approval
  • Must be unique within the application
  • Incremented for each new submission to an application

Slide 10 - eCTD: General information & advice

  • Once an eCTD always an eCTD means don't send non-eCTD or paper to an eCTD application
  • Don't send files outside the eCTD sequence folder
  • Don't send files that are not referenced in the correct, appropriate eCTD backbone (index.xml, au-regional.xml)
  • Develop checklists to ensure the submission is complete

Slide 11 - Always check your submission

  • Quality check (QC) your submission prior to submitting it
  • Use checklists and establish a good, efficient QC process
  • Ensure the media contains the submission
  • Ensure no files are truncated
  • Check submission using a validation tool

Slide 12 - eCTD validation

  • Use an eCTD Validator to identify technical problems with your submission before sending it to TGA
  • Do not ignore errors
  • High error content will result in the rejection of your submission
    • lost time and $
  • Current eCTD Validation Specifications are available on the TGA eCTD webpages

Slide 13 - Rejections

Submissions that are technically deficient or otherwise cannot be processed:

  • Cannot determine the correct application number/type
  • High level of validation errors
  • Duplicate eCTD sequence numbers
  • Non-allowed file types e.g. .exe

Slide 14 - Font embedding

  • The intent is to ensure evaluator can access all the information in your submission
  • Use the "standard fonts" and there is no need to embed, these fonts are always available on the evaluator's PCs
  • If you use "non-standard fonts" you should fully embed the font.

Slide 15 - PDF errors

  • Create text-based PDFs from source documents
  • Avoid scanning documents or embedding scanned documents
  • Use validated OCR if you must scan a document
    • Use only standard fonts
    • Fully embed all non-standard fonts if used
  • Initial View Settings
    • Set the Navigation Tab to open to "Bookmarks Panel and Page." If there are no bookmarks, set the Navigation Tab to "Page Only." Page Layout and Magnification should be set to "Default."

Slide 16 - PDF errors

  • Navigation
    • Provide bookmarks and a hyperlinked TOC
    • Use hypertext links throughout the body of the document to link to:
      • supporting annotations
      • related sections
      • references
      • appendices
      • tables, or
      • figures that are not located on the same page as the narrative text.

Slide 17 - Improving PDF documents

  • Include page numbers
  • Include document date
  • Avoid use of scanned documents:
    • Limits ability to text search
    • Can copy only as a 'graphic'
  • Hypertext links: Within a document and between documents in an application
    • May be challenge to create, QC and maintain, but
    • Very useful to the evaluator e.g., Links to Pharm/Tox studies for qualification of impurities in Module 4

Slide 18 - Bookmarks, TOCs, and hyperlinks

  • Bookmarks and/or TOCs make the review more efficient.
  • TGA recommends that documents with more than five pages and with multiple sections should provide a Table of Contents, and/or if appropriate, a Table of Tables, Table of Figures, etc. on the first page of the document.
  • Hyperlinks are recommended when they would aid the evaluation in ways not already possible through the use of the eCTD index.xml and document navigation aids.
  • Applicants should consider when creating cross document hyperlinks that they can cause confusion later in lifecycle and therefore be distracting for an efficient review.

Slide 19 - Hypertext link issues

  • Insufficient hyperlinks (none or not enough)
  • Hypertext links go to incorrect destination or don't work (destination set to same page)
  • References aren't descriptive enough for an evaluator to find the information if the link doesn't work or doesn't exist
  • The Table of Contents (TOC) isn't linked
  • For inter-document links, it's preferred that the link opens the target document in a new window

Evaluators appreciate links instead of searching for a reference (table, figure, document, section, etc.)

Slide 20 - Hypertext link recommendations

Provide linked references in documents (tables, figures, images, sections, inter- document links, etc.)

  • Provide clear, concise references.
  • Use blue text links (preferred) or blue box links
  • Providing linked references from the cover letter is helpful
  • Provide linked TOCs in documents
  • Set links to Inherit Zoom
  • Check your links before submitting

Slide 21 - Document settings

  • Initial View Settings for PDFs:
  • Navigation tab set to open to bookmarks, panel and page
  • Page Layout set to default
  • Magnification should be set default

Slide 22 - Operator attribute issues

  • Issue:
    • Incorrect use of eCTD operator attributes (i.e., fail to use/apply the replace operator resulting in multiple version of the same document when there should only be one current version)?
    • Is there only one current version?
    • Will the evaluator expect to see and know why there are multiple current versions?
    • Will evaluators know the difference between each current version from the leaf title?
  • Solution:
    • If the answer is "no", you may not be using eCTD operator attributes correctly or you need to use leaf titles or another method to indicate the difference for the multiple current versions of a document.

Slide 23 - Document granularity issues

  • Issue:
    • You are providing many one page bioequivalence summary table documents when it would probably be more efficient for an evaluator to have one document with a TOC, bookmarks and links
  • Solution:
    • If it makes sense to combine one and two page documents into a single document in an eCTD section, then do it and provide a linked TOC with bookmarks.

Slide 24 - eCTD at TGA

Highlights of the AU validation criteria
  • There are no naming conventions being validated
  • File Reuse - Information is collected about references outside the application and sequence as well as multiple references to a file within a sequence
  • Cover Letter must be New
  • Lifecycle Tracking Table must be Replace
  • Application Form should be New
  • Risk Management Plan should be Replace
  • STF accepted but if provided, will be validated and must be valid

Slide 25 - eCTD at TGA

  • Continuity planning
    • Commitment to existing registration timelines
    • Assistance for applicants and sponsors
  • Assessment of progress
    • First assessment point - Feb 2015
    • Continue accepting target application types to the pilot phase and beyond on a case-by-case basis
  • Review of technical documentation
    • Review of stakeholder comment
    • On-going development of supporting documentation
  • Ongoing communication with stakeholders

Slide 26 - Future direction for eSubmissions

  • Readiness assessment in February 2015 will determine next steps
  • Revised technical documents
  • eSubmissions Portal and Automated Processes
  • Regulated Product Submissions Standard

Slide 27 - Stay informed about eCTD

Print version

How to access a pdf document

Presentation: eSubmissions in Australia - Part 2

  • Presented by: Dr John Donohoe, Director, Knowledge Management, Office of Medicines Authorisation, Market Authorisation Group, Therapeutic Goods Administration
  • Presented at: ARCS eCTD workshop, December 2014
  • Presentation summary: This presentation provided an updated on the pilot phase for eCTD for prescriptions medicines in Australia.


Presentation: eSubmissions in Australia - Part 2

Dr John Donohoe
Director, Knowledge Management
Office of Medicines Authorisation

16 December 2014

Slide 1 - Regional content

  • Module 1 administrative and prescribing information
  • Module 2.3.R and 3.2.R regional information
    • 2.3.R should provide a brief description of the information provided under 3.2.R
    • Applicants should include the following information in Module 3.2.R, where appropriate:
      • Process validation scheme for the drug product
      • Certificates of suitability
      • Risk of transmitting animal spongiform encephalopathy agents
      • Certified Product Details
      • Supplier's declarations regarding compliance with packaging standards and colouring standards.

Slide 2 - Node extensions

  • A way of providing extra organisational information to the eCTD.
  • Visualised as an extra heading in the CTD structure.
  • Displayed as extra headings when the XML backbone is viewed.
  • Node-extension structure is in compliance with general ICH eCTD specifications
  • Example: Grouping multiple files belonging to a single study
    • 5312 (eCTD Section)
      • Study ABC123
        • Synopsis.pdf
        • Report Body.pdf
        • Discontinued Patient Listing.pdf
      • Study XYZ321
        • Synopsis.pdf
        • Report Body.pdf
        • Discontinued Patient Listing.pdf
    • 537 CRFs
      • Study ABC123
        • Site 123
          • CRF-123-0001.pdf
          • CRF-123-0002.pdf
        • Site 234
          • CRF-234-0001.pdf
          • CRF-234-0002.pdf

Slide 3 - Node extensions and leaf elements

  • Structures beyond the heading elements can be defined through node extension elements.
  • Content for each heading element is provided through leaf elements.
  • Wherever a leaf element is allowed in the schema, a node-extension element is also allowed.
  • The optional node-extension element contains a single mandatory title element, followed by at least one leaf element.
  • The node extension title element and leaf title element should be short, precise and informative
    • Information already categorized by heading elements need not be repeated.
    • The most important identifying information should be placed at the beginning to prevent reviewers from having to scroll to the end of the title.

Slide 4 - Node extensions

  • Node Extension structures should be considered and used where needed to assist reviewers
  • Consider the impact of changing node extension structures during the lifecycle
  • Don't use where ICH specified sub headings already exist
  • Only use at the lowest level of the eCTD structure
  • Use to group together multiple like documents
  • Node extensions may be nested
  • Node extensions content can be placed in separate sub folders

Slide 5 - Leaf titles

  • The display name given to a document and will be shown to the evaluator
  • An evaluator never sees the file/folder names in the file structure
  • Leaf titles should not include:
    • file extensions, e.g. appendix1.pdf
    • hyphens or underscores, e.g. copy-certification.pdf
    • eCTD section number.

The eCTD application has "life cycle" and contains the history of all your submissions!

Slide 6 - Study tagging files

  • A structured solution to organizing studies in eCTD applications providing a consistent structure for review and categorisation of clinical and nonclinical studies.
  • Comprised of an XML Backbone file with category information and links to study content.
  • Content tags based on ICH E3 Guidance on the Structure of Clinical Studies.
  • Predefined values for Species, Route of Administration, Duration and Type of Control.
  • TGA does not currently have any plans to mandate study tagging files (STFs) for evaluation purposes.
  • Applicants wishing to reuse content submitted in other regions where STFs have been used can do so.
  • If provided, STFs will be validated and must be conform to standards and specifications.

Slide 7 - Regional file formats

  • Module 1 - Both PDF and XML have been designated as acceptable file formats for the AU Module 1.
    • No structured exchange (XML) standards for content are currently defined
    • These may be introduced in the future for content such as the lifecycle management tracking table, application forms, etc.
    • All PDF files included in an eCTD irrespective of the module should be v1.4, v1.5, v1.6 or v1.7 except where a specific requirement for a later version is defined
    • It is preferred that PDFs be generated from an electronic source. Signatures may be embedded as a graphic file in the PDF text if desired.
  • Modules 2 to 5 - No additional file formats are defined for Modules 2 to 5 other than those mentioned in the ICH eCTD Specification Document.

Slide 8 - Use of electronic signatures

  • Currently the use of digital signatures for electronic submissions is not fully supported within the TGA.
  • Scanned signatures would ordinarily be used where the documents make up part of the checksum of an eCTD submission.

Slide 9 - Handling of empty or missing eCTD sections

  • For new applications, including generic applications, detailed statements justifying the absence of data or specific CTD sections should be provided in the relevant Quality Overall Summary and/or Nonclinical/Clinical Overviews e.g. Module 2.3, 2.4, or 2.5.
  • For a generic application, there is no need to provide a justification for content that is typically absent.
  • Note that placeholder documents highlighting no relevant content should not be placed in the eCTD structure.

Slide 10 - Updating backbone attributes

  • Updating ICH attributes
    • Updating XML backbone attributes such as manufacturer during the eCTD lifecycle is possible.
    • Consideration should be given regarding the impact of changing backbone attributes during the lifecycle.
    • Changes can lead to a higher level of complexity in the cumulative view of a submission.
  • Updating AU envelope information
    • The AU envelope information can be updated during the lifecycle as is necessary to reflect changes in the application metadata.

Slide 11 - File reuse

  • TGA accepts and encourages applicants to make active use of file reuse.
  • Applicants should not submit the same document multiple times.
  • File reuse should be used when
    • a file is submitted multiple times within one sequence,
    • a file already submitted in an earlier sequence is being referenced again,
    • or if a file submitted in another application is being referenced in a new application.
  • TGA is implementing a flat repository structure to make cross application referencing possible.
    • Links to content provided in other applications simply need to be directed out of the current application structure and into the structure of the corresponding application.
    • All application will be stored using the eSubmission Identifier to make cross referencing easily predictable and possible.

Slide 12 - Module 1 architecture

The AU module 1 backbone file and style-sheet

  • The Australian Module 1 is schema based instead of using a dtd.
  • The Australian Module 1 eCTD backbone file comprises three main components:
    • A fixed eXtensible Markup Language (XML) root element;
    • The envelope elements; and
    • The eCTD heading elements describing the actual files provided.
  • Style-Sheet
    • A standard style-sheet is provided that can be used to view content
    • The style-sheet has been designed to display the complete Module 1
    • The style-sheet is not part of the specification package
    • eCTD applications can be submitted with or without the style-sheet
    • The TGA will not be reviewing content using the style-sheet
    • Its existence is not part of the validation criteria

Slide 13 - Module 1 architecture

XML root element

  • All Australian Module 1 backbone files prepared for the TGA will contain the standard XML root element
  • The required text includes an XML declaration and the root element tga_ectd with its attributes linking the XML file to the XML definition prepared by the TGA
  • Without style-sheet
  • With style-sheet

Slide 14 - Envelope elements

  • What are Envelope Elements?
    • Administrative information imbedded into a sequence which helps to identify and categorise the content, also for automated processes.
XML Element Description Constraint Occurrence Defined List
esub-id eSubmission Identifier Mandatory Single  
applicant Applicant Mandatory Single  
aan Australian Approved Name(s) Mandatory Multiple  
product-name Product Name Mandatory Multiple  
artg-number ARTG Number Optional Multiple  
sequence-description Sequence Description Mandatory Single X
sequence-number Sequence Number Mandatory Single  
related-sequence-number Related Sequence Number Optional Single  
reg-activity-lead Regulatory Activity Lead Mandatory Single X
sequence-type Sequence Type Mandatory Single X

Slide 15 - Envelope elements: Defined lists

  • The defined lists are provided and maintained as separate XML files
  • Each file contains a standard set of codes for the corresponding envelope element.
  • Codes have been implemented to reduce validation issues
  • The code definition files contain a version number, version date and coded values as well as plain texts for each value.
  • Only the plain text value is shown to the reviewers in the review system.
  • Defined lists have been created for
    • Sequence description
    • Regulatory activity lead
    • Sequence type

Slide 16 - Envelope elements: Sequence description

  • The sequence description defined list of codes and values is available from <>. Applicants should refer to this list for current list values.
  • There are 4 types of sequence description approaches
    • Some values can be used without further information
    • Others will require the description to be combined with a date
    • In the example with the PSUR, both the start date and the end date have to be entered
    • Finally, some descriptions will need additional information added in the form of a brief description (brief - under 40 characters)

Slide 17 - Envelope elements

Sequence description example 1

Some values can be used without further information e.g. Initial.

  • The code for "Initial" is seq-desc-2 as specified in the defined list
  • Note that the code version must be specified as an attribute code-version of the sequence-description element.

Slide 18 - Envelope elements

Sequence description example 2

Others will require the description to be combined with a date e.g. Response to Screening Clarification Request - 2014-03-30.

  • The code for a response to a screening clarification request is seq-desc-5 as specified in the defined list
  • Response to Screening Clarification Request - {date:d}
  • A date is required as additional data. The name of the placeholder is date. It requires an actual value in date format (because of the letter d following the colon).

Slide 19 - Envelope elements

Sequence description example 3
  • In the example with the PSUR, both the start date and the end date will have to be entered e.g. PSUR for Period of 2015-01-01 to 2015-06-30.
    • The code for "PSUR" is seq-desc-20 as specified in the defined list
    • PSUR for Period of {from-date:d} to {to-date:d}
    • Two placeholders have been specified. The first one is named from-date and the second one is named to-date

Slide 20 -Envelope elements

Sequence description example 4

Finally, some descriptions will need additional information added in the form of a brief description (brief - under 40 characters) e.g. Uncategorised, DESCRIPTION.

  • The code for "uncategorized" is seq-desc-24 as specified in the defined list
  • Uncategorised, {description:s}
  • The name of the placeholder is description. It requires an actual value in plain text format which is indicated by the letter "s" following the colon.

Slide 21 - Envelope elements

Regulatory activity lead

The regulatory activity lead defined list of codes and values is managed at <>. Applicants should refer to this list for current list values.

The code for "Prescription" is reg-act-lead-6 as specified in the defined list.

Note that the code version must be specified as an attribute code-version of the reg-activity-lead element.

Slide 22 - Envelope elements

Sequence type

The sequence type defined list of codes and values is available from <>. Applicants should refer to this list for current list values.

The code for "New chemical entities" is seq-type-1 as specified in the defined list.

Note that the code version must be specified as an attribute code-version of the sequence-type element.

Slide 23 - Heading elements

What are Heading Elements?

  • Each specified section of the eCTD is associated with a heading element which is used to identify and organise the content associated with that section.

Slide 24 - Heading elements

Section ID Business Terminology XML-Element
1.0 Correspondence m1-0-correspondence
1.0.1 Cover letter m1-0-1-cover
1.0.2 Lifecycle management tracking table m1-0-2-tracking-table
1.0.3 Response to request for information m1-0-3-response
1.2 Administrative Information m1-2-admin-info
1.2.1 Application forms m1-2-1-app-form
1.2.2 Pre-submission details m1-2-2-pre-sub-details
1.2.3 Patent certification m1-2-3-pat-cert
1.2.4 Change in sponsor m1-2-4-change-sponsor
1.3 Medicine information and labelling m1-3-med-info
1.3.1 Product information and package insert m1-3-1-pi Product information - clean m1-3-1-1-pi-clean Product information - annotated m1-3-1-2-pi-annotated Package insert m1-3-1-3-pack-ins
1.3.2 Consumer medicines information m1-3-2-cmi Consumer medicines information - clean m1-3-2-1-cmi-clean Consumer medicines information - annotated m1-3-2-2-cmi-annotated
1.3.3 Label mock-ups and specimens m1-3-3-mockup

Section ID Business Terminology XML-Element
1.4 Information about the experts m1-4-experts
1.4.1 Quality m1-4-1-quality
1.4.2 Nonclinical m1-4-2-nonclinical
1.4.3 Clinical m1-4-3-clinical
1.5 Specific requirements for different types of applications m1-5-specific
1.5.1 Literature-based submission documents m1-5-1-lit-based
1.5.2 Orphan drug designation m1-5-2-orphan
1.5.3 Genetically modified organisms consents m1-5-3-gmo
1.5.4 Additional trade name declarations m1-5-4-trade-name
1.5.5 Co-marketed medicines declarations m1-5-5-co-marketed
1.5.6 Combination medicine consent m1-5-6-comb-med
1.5.7 OTC product assurances m1-5-7-prod-assurance
1.5.8 Analytical validation summary m1-5-8-analyt-val-sum
1.6 Master files and certificates of suitability m1-6-master-files
1.6.1 Relevant external sources m1-6-1-ext-sources
1.6.2 Applicant's declaration m1-6-2-app-decl
1.6.3 Letters of access m1-6-3-loa

Slide 25 - Heading elements

Section ID Business Terminology XML-Element
1.7 Compliance with meetings and pre- submission processes m1-7-compliance
1.7.1 Details of compliance with pre-submission meeting outcomes m1-7-1-pre-sub
1.7.2 Details of any additional data to be submitted m1-7-2-add-data
1.7.3 Declaration of compliance with pre-submission planning form and planning letter m1-7-3-planning
1.8 Information relating to pharmacovigilance m1-8-pv
1.8.1 Pharmacovigilance systems m1-8-1-pv-systems
1.8.2 Risk management plan m1-8-2-risk
1.9 Summary of biopharmaceutic studies m1-9-biopharm
1.9.1 Summary of bioavailability or bioequivalence study m1-9-1-ba-be
1.9.2 Justification for not providing biopharmaceutic studies m1-9-2-justification
1.10 Information relating to paediatrics m1-10-paediatrics
1.11 Foreign regulatory information m1-11-foreign
1.11.1 Foreign regulatory status m1-11-1-status
1.11.2 Foreign product information m1-11-2-pi
1.11.3 Data similarities and differences m1-11-3-similarities
1.11.4 Foreign evaluation reports m1-11-4-eval-reports
1.12 Antibiotic resistance data m1-12-antibiotic

Slide 26 - Module 1 architecture

Files and folders
  • Naming conventions for the content files are irrelevant for electronic review.
  • All content must be referenced by the appropriate XML files for efficient navigation.
  • Applicants should concentrate on providing precise but informative leaf titles to aid reviewers.

Slide 27 - The final take away

Consider your audience:

  • If you were the evaluator and you are not familiar with the submission, could you easily navigate the submission and do an efficient review?
  • Perform an overall QC after compiling the submission.
  • Navigate the submission using eCTD TOC tree, leaf titles, links, and bookmarks keeping the evaluator in mind.
  • Use a QC process or checklist to help ensure submissions don't contain formatting issues.
  • Good planning and being proactive can help you avoid the need to respond to queries, send resubmissions, and send additional corrective submissions to fix formatting issues!

Print version

How to access a pdf document