presentation: esubmissions in australia - part 2

eSubmissions in Australia Part 2

Dr John Donohoe Director, Knowledge Management Section Office of Medicines Authorisation

16 December 2014

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.

eSubmissions in Australia 1

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

eSubmissions in Australia

2

http://estri.ich.org/eCTD/eCTD_Specification_v3_2_2.pdf

http://estri.ich.org/eCTD/eCTD_Specification_v3_2_2.pdf

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.


3

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


4

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!


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.


6

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.


7

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.


8

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.


9

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.eSubmissions in Australia

10

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.


11

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


12

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:


13

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


14

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


15

http://www.tga.gov.au/downloads/sequence-description.xml

http://www.tga.gov.au/downloads/reg-activity-lead.xml

http://www.tga.gov.au/downloads/sequence-type.xml

Envelope Elements: Sequence Description • The sequence description defined list of codes and values is available from

http://tga.gov.au/downloads/sequence-description.xml. 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)


16

http://tga.gov.au/downloads/sequence-description.xml

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.


17


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


18


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


19


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.


20

Envelope Elements Regulatory Activity Lead

The regulatory activity lead defined list of codes and values is managed at http://tga.gov.au/downloads/reg-activity-lead.xml. 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.


21

http://tga.gov.au/downloads/reg-activity-lead.xml

Envelope Elements Sequence Type

The sequence type defined list of codes and values is available from http://tga.gov.au/downloads/sequence-type.xml. 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. eSubmissions in Australia

22

http://tga.gov.au/downloads/sequence-type.xml

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.


23

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 1.3.1.1 Product information - clean m1-3-1-1-pi-clean 1.3.1.2 Product information - annotated m1-3-1-2-pi-annotated 1.3.1.3 Package insert m1-3-1-3-pack-ins

1.3.2 Consumer medicines information m1-3-2-cmi 1.3.2.1 Consumer medicines information - clean m1-3-2-1-cmi-clean 1.3.2.2 Consumer medicines information - annotated m1-3-2-2-cmi-annotated

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


24

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


25

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.

Folder File Description e123456 Application folder with eSubmission identifier e.g. e123456 0000 Sequence folder with four digit sequence number e.g. 0000 index.xml Index file in accordance with ICH index-md5.txt MD5 checksum in accordance with ICH m1 Content folder for Module 1 documents in accordance with ICH au Australia country specific folder au-regional.xml Australia regional index file for Module 1 m2 Content folder for Module 2 documents in accordance with ICH m3 Content folder for Module 3 documents in accordance with ICH m4 Content folder for Module 4 documents in accordance with ICH m5 Content folder for Module 5 documents in accordance with ICH util Util folder in accordance with ICH dtd DTD and schema folder in accordance with ICH au-regional.xsd Australia regional backbone schema for Module 1 xlink.xsd W3C schema for XLink 1.1 (referenced from au-regional.xsd) xml.xsd W3C schema for XML namespace (referenced from au-regional.xsd)

ich-ectd-3-2.dtd ICH DTD for Modules 2 to 5 style Style sheet folder in accordance with ICH (optional) ectd-2-0.xsl ICH style sheet for Modules 2 to 5 (optional) au-regional.xsl Style sheet for Australian regional backbone (optional) 0000-validation-report Comprehensive output from an eCTD validation tool


26

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!


presentation: esubmissions in australia - part 2

Presentations & Public Speaking