final industry book of knowledge v1.2

V1.2 26-May-2009 1

Industry Book of Knowledge Practical Considerations for eCTD Submissions:

A CMC Perspective

A compilation of points to consider based on collective experiences from: Abbott, Amgen, Astellas, Astra Zeneca, B.Braun Medical, Biogen Idec, Boehringer Ingelheim, Bristol Myers Squibb, Cephalon, Eli Lilly, Glaxo-Smith Kline, Johnson & Johnson, Merck, Novartis, Pfizer,

sanofi aventis, Takeda, Wyeth

Industry Book of Knowledge 2009

V1.2 26-May-2009 2

Authors: Abbott, Amgen,Astra-Zeneca, Boehringer Ingelheim, Cephalon, Eli Lilly, Glaxo-Smith Kline, Johnson & Johnson, Merck, sanofi-aventis, Takeda


V1.2 26-May-2009 3

Contents Considerations for eCTD: A CMC Perspective......................................................................... 6

Background ............................................................................................................................... 6 Introduction ................................................................................................................................ 6 Industry Thoughts and Experiences .......................................................................................... 6

Submission Ready Documents .............................................................................................. 6 eCTD Implementation Strategy ............................................................................................. 6 Dossier Conversions and Baselines: The Initial CMC Sequence .......................................... 7

Differences Between U.S. and E.U. .......................................................................................... 7 Authoring ..................................................................................................................................... 8

Background ............................................................................................................................... 8 Introduction ................................................................................................................................ 8 Industry Thoughts and Experiences .......................................................................................... 8

eCTD Organization and Content Strategies .......................................................................... 8 Navigation within Documents .............................................................................................. 10

Granularity ................................................................................................................................. 12 Background ............................................................................................................................. 12 Introduction .............................................................................................................................. 12 Industry Thoughts and Experiences ........................................................................................ 13 Practical Granularity Considerations ....................................................................................... 17

Leaf Titles .................................................................................................................................. 21 Background ............................................................................................................................. 21 Industry Thoughts and Experiences ........................................................................................ 21

Filenames .................................................................................................................................. 23 Background ............................................................................................................................. 23 Industry Thoughts and Experiences ........................................................................................ 23

Lifecycle Management of CTD-Formatted Quality Documentation ...................................... 28 Introduction .............................................................................................................................. 28 Questions and Answers .......................................................................................................... 30

1. What are the "pros" and "cons" associated with lifecycle management? ........................ 30 2. When does lifecycle management begin? ....................................................................... 30 3. When do we use new, replace, append, delete? ............................................................. 31 4. What documents are living? ............................................................................................ 31 5. What CMC application types affect lifecycle management? ............................................ 32 6. Is it necessary or beneficial to build a baseline eCTD-formatted dossier? ...................... 33 7. What markets require lifecycle management? ................................................................. 33 8. How do you minimize the impact of lifecycle management when you have shared drug substances, shared facilities, etc.? ...................................................................................... 33 9. Considerations for lifecycle management of single documents that are linked or cross-referenced in the backbone ................................................................................................. 34

Relevant Guidance .................................................................................................................... 28 Version History ......................................................................................................................... 28


V1.2 26-May-2009 4

Foreword The ICH M2 eCTD specification is open to many interpretations and there are certainly numerous equally valid approaches to the organization of the eCTD Quality Modules (Modules 2.3 and 3). The ICH eCTD guidance and specification intentionally serves to allow sponsors the ability to author, review and maintain regulatory dossiers in a manner which suits both internal business processes and requirements of various ICH regional health authorities. For the Quality Modules, the ease or difficulty of regulatory review and proper lifecycle management is largely affected by how the sponsor chooses to implement the eCTD and build the initial dossier. Done well, regulatory dossiers in the eCTD format add value to an organization by facilitating the review of a product profile, providing easy access to current Quality commitments, showing a complete history of manufacturing changes and providing a single user interface for regulatory correspondence and a complete index of regulatory filings for an application. However, short sighted implementation plans for CMC sections of eCTD dossiers have long lasting effects and can be difficult to manage, but not impossible to recover from. It is critical to foster an open dialogue across disciplines within an organization such that the benefits of an eCTD format can be leveraged without unintentionally burdening the regulatory process or creating unnecessary redundancies in the name of eCTD dossier maintenance or “compliance”. Finally, interpretation of what the ICH eCTD specification allows should not be confused with limitations which may be introduced by the functionality of available software or other in-house procedures used to build and manage eCTD dossiers. It is important to understand, from a holistic perspective, where flexibility can be applied and the risks and benefits inherent in each approach. Editor Deanna Murden President ePharmaCMC, LLC


V1.2 26-May-2009 5

Purpose The intent of this Book of Knowledge is to share current practical experiences from across the industry. Dossiers created and managed in the eCTD format offer many benefits to the profession of Regulatory Chemistry, Manufacturing and Controls, and many consider the eCTD to be a step forward in minimizing the regulatory burden of product maintenance. It is believed that the creation and publication of a set of industry wide generally recognized interpretations to the assembly and maintenance of CMC dossiers in the current eCTD format will benefit sponsors & other interested parties in the successful and early adoption of the eCTD. The presentation of this Book of Knowledge serves to aid sponsor organizations in maximizing the benefits of an eCTD format submission from the start, realizing an early return investment. The information presented herein was created by industry volunteers responsible for authoring, managing and otherwise working with CMC dossier content in an eCTD format from a dossier sponsors point of view. This compilation highlights key lessons learned, and attempts to bring perspective to those involved in authoring submissions for pre- and post-approval dossiers, CMC managers, dossier publishers and submission managers such that knowledgeable decisions can be made that leverage the benefits of an eCTD submission for industry. The intent is not to standardize implementation practices across industry, but to acknowledge and support many equally valid and diverse approaches to the CMC dossier in an eCTD format. The information is presented in a neutral, balanced fashion as Points to Consider. Pro‟s and con‟s of many different options and variations of interpretation within the current boundaries of ICH M2 v3.2.2 are presented. Questions or comments may be addressed to [email protected]

mailto:[email protected]

Industry Topic Paper: Considerations for eCTD 2009

V1.2 26-May-2009 6

Considerations for eCTD: A CMC Perspective

Background All electronic submissions made to FDA must be in eCTD format. EMEA has also mandated that starting in January 2010; any centralized procedures submitted electronically must be in eCTD format. Several European countries are also requiring electronic submissions for national and mutual recognition procedure applications. There are several different approaches for when to implement eCTD. eCTD implementation plans may consider implementation for new submissions only versus conversion of existing applications, implementation by region (e.g., U.S. only, followed by others), implementation by procedure type (e.g., centralized procedure vs. national), conversion of existing applications at the time of post-approval change or annual report, and implementation of marketing applications vs. applications for investigational products.

Introduction Significant preparation is necessary before eCTD implementation can take place. Processes for preparing an electronic submission are different and more complex than those used for preparing a paper submission. Ideally, all submission documents will be consistently formatted, of the appropriate granularity for lifecycle management of the eCTD, and available in an electronic document repository with version control. Conversion strategies and use of legacy (old format) documents create special issues for integration with an eCTD dossier, especially when the documents have not been created by the sponsor company.

Industry Thoughts and Experiences

Submission Ready Documents

Submission Ready is defined as a document that is ready to incorporate into an eCTD format dossier without further modification. The development and use of internal standards or templates should be considered to facilitate this process. These standards should address fonts, margins, granularity, headers, footers, bookmarking, cross-referencing and hypertext linking, document naming conventions, pdf version, and lack of password protection. The use of optical character recognition (OCR) technology is recommended for all scanned documents that are included in an eCTD submission to facilitate the review process by global health authorities.

eCTD Implementation Strategy

An eCTD implementation strategy begins with a sponsor‟s assessment of current publishing and document management systems and potential integration with available eCTD tools and software. While not specific to the discipline of CMC, a practical approach to dossier creation, review processes, availability of eCTD viewing tools, and implementation of lifecycle management using eCTD must be considered. In addition to filing new applications in eCTD format, each company will need a strategy for converting existing applications from eNDA, NeeS (non-eCTD electronic submissions), or paper format to eCTD format. Decisions must address the priority for eCTD conversion, for example, convert to eCTD for one region at a time (e.g., all U.S. submissions followed by E.U.

Industry Topic Paper: Considerations for eCTD 2009

V1.2 26-May-2009 7

submissions), convert all marketing applications before converting investigational applications; convert in E.U. by procedure type (e.g., convert all CP applications, followed by MRP applications). The current level of regulatory activity against a product can also be considered in the conversion strategy since eCTD may be most beneficial to both the sponsor and the agency when there is a high level of regulatory activity to monitor.

Dossier Conversions and Baselines: The Initial CMC Sequence

Regardless of the number of documents and sections that will be included in the initial CMC sequence of an eCTD, advanced planning must occur to address the overall structure of the CMC parts of the application, including eCTD meta-data/attribute values, leaf titles and granularity of content. For example, if the first eCTD sequence for CMC contains the typically limited data for an annual report, choices for eCTD Module 3 attributes should not be short sighted to exclude future content or the whole of the future CMC section. An eCTD submission is most valuable when all sections of the application are included in the XML backbone for easy reference. When existing applications are converted to eCTD format, previously submitted documents that are unchanged may be resubmitted as part of the eCTD "baseline." A baseline may be especially helpful for applications that are subject to a high level of regulatory activity; however, a baseline cannot include previously submitted information that is still pending approval. Creation of the eCTD baseline can be a significant undertaking, especially if the original documents are not available electronically or are not in CTD format. A partial baseline of only key CMC documents is another consideration. Even if available electronically, legacy documents may not meet current standards for "submission readiness" and a decision will need to be made as to whether they add value in their current state, will be reformatted for submission, or will be left out of the eCTD until they are revised and brought up to current standards. If legacy documents are not of the proper granularity, they can be split into smaller documents for inclusion in the baseline as long as the document content remains unchanged. If legacy documents are not available electronically, a decision will need to be made regarding the value of including them in the baseline as scanned documents.

Differences Between U.S. and E.U. In the U.S. conversions can be made at the time of a post-approval supplement or an annual report. If this is done, the sponsor must clearly identify those sections that have been revised for the current post-approval change or annual report to distinguish them from sections that are being resubmitted with no content changes. In the E.U., an application can be converted to eCTD in a "Reformat" sequence that includes only unchanged documents that have been previously submitted and approved. This baseline sequence can be submitted at the same time as a variation sequence. If there are unapproved CMC changes pending at the time of submission of the original Reformat sequence, a second Reformat sequence can be submitted to the eCTD to include those changes after they are approved. Regional Health Authorities encourage early communication by sponsors, as eCTD is new for everyone and not all situations can be anticipated via guidance or procedure.

Industry Topic Paper: Authoring Considerations 2009

V1.2 26-May-2009 8

Authoring

Background Dossier components for an eCTD format submission can be, and often are, dependent on previously submitted versions of that same content. New strategies for authoring an eCTD format submission include paying attention to eCTD dossier attributes which may identify content by manufacturing site or by strength, dosage form or even synthetic route. Document granularity (number of documents) per eCTD sub-heading is generally established at the time of submission of the first eCTD sequence. For lifecycle operations of Replace to be most useful over time, granularity in future sequences must match that previously provided or regulatory history may be lost. Authoring must also take into consideration whether changes for a particular section should be incorporated into the lifecycle of the dossier by replacing existing documents or by creating new documents, including the possibility that prior content may need to be deleted before adding new content within Module 3. Documents for large regulatory submissions may be written by many contributors across multiple functional areas. The development of common authoring standards that apply to all groups will lead to a consistent presentation of information and facilitate review of the regulatory submission.

Introduction Approaches for insuring consistency of regulatory submission documents may include the use of document templates to facilitate the creation of consistently formatted documents, regardless of the author or functional group responsible for document content. Templates can provide an outline for content and formatting that reflects agreed fonts, margins, and document headers and footers. Style guides can be written to document consistent formatting requirements, terminology, navigation, cross-referencing standards, etc. Document templates may also include standard boilerplate or commonly used introductory text reflecting current practice and sponsor defined interpretations of regulatory guidances. Within these basic templating concepts, there are considerations for creating content and pdf output that are more suitable for electronic viewing in the eCTD format.

Industry Thoughts and Experiences

eCTD Organization and Content Strategies

Dossier content in an eCTD format dossier is provided in a very granular fashion (meaning, many small documents). These individual granular documents are subsequently organized and categorized electronically through the use of eCTD attributes (such as manufacturer, substance, dosage form) which provide context and relevancy. The attributes chosen for the initial Module 3 sequence in eCTD format have implications for document granularity that will apply throughout the lifecycle of the dossier. Example: If the drug product specification is provided in an eCTD as two separate documents under section 3.2.P.5.1, one for 50mg and one for 100mg, a subsequent post approval change


V1.2 26-May-2009 9

cannot provide a single document covering both the 50mg and the 100mg without also performing a delete operation on the initial two files. Example: If a drug substance is manufactured at two sites, A and B, and a single document that covers both sites is submitted in the initial eCTD sequence, submission of a new document for a post-approval change that is only applicable to site A may lead to outdated or conflicting site A information in the original document that covered both sites. To remedy this, the Delete operator could be applied to the original document that covered both sites and a second new document, containing only site B information, could be created. This could, however, lead to re-review of unchanged but re-submitted site B information.

Use of document templates

The use of document templates including instructions and example text improve the ability to implement standards for document content and level of detail, especially when writing is distributed to functional areas or diverse global sites. Caution should be exercised with this approach since instructional text and example text may accidentally be left in the document when published. An additional strategy is to use “shell” templates that include high level headings and minimum formatting standards for regulatory compliance.

Headers and Footers can be standardized for the eCTD viewing environment

Bookmarks and CTD numbering can be automatically embedded via the templates to facilitate publishing

Templates can encourage the use of proper granularity for an eCTD submission and encourage consistent approaches.

This approach may sacrifice document consistency from submission to submission, unless there is another way to communicate best practices to the authoring groups. This is especially relevant for CMC where multiple regional guidances for content exist, and interpretations may vary.

Document Identifiers

Documents included in an eCTD submission should have a unique identifier somewhere in the document to help agency reviewers who may have more than one document open at a time. This is particularly useful when the eCTD contains multiple sections 3.2.S or 3.2.P. CTD numbering, document title and/or eCTD attributes (e.g., site, route, strength) may be used to identify a document. A unique control number may also be assigned to each document for this purpose. The best method of identifying a document may be dependent upon whether that document was written specifically for a regulatory application for a given product or if it could potentially be included in multiple applications for various products. For example, application/product-specific information such as product name, CTD subsection, and eCTD attributes can be used as the identifier in documents written for a specific application or product and a document control number can be used as the identifier in documents that may be included in multiple applications or multiple sections of an application. The use of CTD numbering here may limit the ability to repurpose content for dossiers outside of ICH regions that may use a different dossier structure (ASEAN CTD for instance).


V1.2 26-May-2009 10

Location of Identifying Information

Identifying information may be included in a document header or footer that appears on each page of the document, in a heading that is bookmarked within the content of a document, or both.

For example “Specification(s)” vs. “3.2.P.4.1 Specification(s) (Magnesium Stearate, Big Factory)” Inclusion of attribute information (e.g., substance, manufacturer, dosage strength, excipient) in document headings may not be necessary if the attribute information is included in the header or footer of the document.

Numbering of Sections

Options for section numbering include use of CTD numbering or outline numbering (e.g., I, II, III, etc.) If CTD numbering is used, caution should be exercised in extending the standard CTD numbering to cover subsections within a document (e.g., 3.2.P.8.1.1.3.1) as this can get unwieldy.

Numbering of Tables and Figures

An eCTD for Module 3 is comprised of many small documents. Using standard table and figure numbering will lead to many instances of "Table 1" since numbering will restart with each document rather than continuing from the previous section. This is generally not a problem since cross-references to specific tables and figures in other sections of the CTD are uncommon. If it is necessary to cross-reference specific tables and figures across different documents, Inclusion of the CTD section number in table and figure numbering (i.e. 3.2.P.1.Table 1) may help to distinguish tables in one section from those in another section. This approach will increase the number of characters consumed in the bookmark pane and may have a negative impact on navigation within a document. Use of excessive sub-numbering approaches for tables and figures can lead to confusion in following the lead section number to the table level when multiple tables and figures exist in the same document (i.e. 3.2.P.3.3.1.2 Table 1, 3.2.P.3.3.1 Table 1).

Document Version Control

Automated application of document information such as version number or approval date can aid in version control between the sponsor‟s document management system where authoring occurs and the actual published eCTD submission.

Navigation within Documents

Table of Contents

The inclusion of document level table of contents is helpful for navigation within a longer report style document such as P.2 or P.3.5. However, most documents within Module 3 are of sufficient granularity (1-2 pgs) such that a TOC is not helpful and should not be viewed as a requirement. Since an eCTD format submission is not read front to back and has no through pagination – a TOC is commonly considered as redundant to pdf bookmarking.


V1.2 26-May-2009 11

Bookmarks

Bookmarks facilitate navigation within a document and are especially useful for documents with multiple subsections or tables and figures. Templates may be used to automate the creation of bookmarks from styles used for headings and table or figure captions in the Microsoft Word documents. Caution should be used to limit the number of levels of nested bookmarks since excessive nesting may be cumbersome for the reviewer. Although guidance allows up to 5 levels of bookmarks within a document, generally one, two, or three levels are sufficient, depending on the length and complexity of the document. The addition of bookmarked headings within a document to identify the CTD section in which the document is located (e.g., insertion of a bookmarked heading of P.8 Stability before the document identifying bookmarked heading of P.8.1 Stability Summary and Conclusions) will increase the nesting and should be avoided.

Hyperlinking

Hypertext linking within a document should follow standard publishing guidelines. However, this is not to be confused with inter-document hyperlinking (linking of one document to another). Inter-document linking should be approached with caution in the eCTD format. Hyperlinks will become outdated when destination documents are replaced, causing a link to actually take a viewer to an outdated version of the file with no indication they are not viewing the most current version. In general, inter-document hyperlinks are only recommended when scientific topics within the dossier span multiple sections (i.e., polymorphs, impurities/degradation products, justification of specifications). In most cases, consider providing a textual reference to a section or document within the eCTD, without actually providing an electronic inter-document link.

Industry Topic Paper: Granularity 2009

V1.2 26-May-2009 12

Granularity

Background Granularity is a new concept in dossier management for CMC. The eCTD specification describes a fixed number of heading elements that mirror the ICH M4Q CTD guidance, but does not state how many discrete documents may be contained within each heading. In simple terms, Granularity is the extent to which a larger entity or section is subdivided, defined as one document = one pdf For example, 3.2.P.3.3 Description of Manufacturing Process and Controls may be presented in an eCTD dossier as a single pdf document, OR, the same information could be provided as three separate pdf files, breaking down the same content into one pdf for the flow diagram, another pdf for the process description, and a third pdf file containing the process controls. All three pdf files would sit under the eCTD heading element of 3.2.P.3.3. Description of Manufacturing Process and Controls.

Introduction Granularity assists companies in developing a global strategy for submissions (electronic & paper) and has an effect on subsequent submissions and eCTD lifecycle. Document granularity may simplify the authoring of otherwise complex technical sections and facilitates electronic lifecycle management. The expectation for lifecycle management should affect decisions regarding granularity. If documents are large and contain many facts that may change, it would be burdensome to repeatedly update and submit a large document. Likewise, it might be difficult for the regulatory authority to know what specific piece of information has been revised within the large document. Therefore, it is beneficial to divide these documents into multiple smaller documents ("granules") to ease the lifecycle management of the document.


V1.2 26-May-2009 13

Industry Thoughts and Experiences In general, the approach many companies take with respect to granularity is driven by internal company processes for the authorship of CMC documentation. Unique approaches to authoring CMC documents, the complexity of document numbering systems, and the frequent outsourcing of CMC-related activities may affect the granularity of CMC documentation prepared for submission. Some additional key considerations for influencing the approach to granularity are outlined in the following table:

Fewer, Larger Documents Multiple Smaller Documents

Considerations Pro Con Pro Con

1) Document management

The storyline and content may be presented in a single document.

A single document for a given section may be quite large and would not facilitate lifecycle updates.

Lifecycle management is facilitated; smaller documents - possibly easier for reviewer to locate a change; can minimize updates

If multiple dosage strengths are manufactured at the same site, then a site change would require the update to be made to several documents for the same information

Registers the process to the application rather than on a site basis; manage only one document

management of a complex technical document that requires authoring from different individuals

May help in managing completion of the dossier by multiple authors depending on the document management system (e.g., one granular document per author as opposed to many authors in one document)

Perception that if there are multiple granular documents for a reviewer to open, instead of one common document, this may present challenges in efficiently reviewing the application

Advantageous if specific strengths are manufactured at specific sites (i.e. document granularity matches the drug supply chain)

2) Authoring Allows authors to generate technical content in story format

Disjointed if following CTD specification or outline (jumps around)

Allows flexibility for multiple authors. Authors can process documents independent of the other authors

Re-education of authors to think in discrete sections vs. story format

Allows for carryover of irrelevant sections / material (non-CTD section material or data repetition)

Focuses discussion to relevant CTD section header

Use of hyperlinks or cross-references are not easily applied in non-electronic submissions (international)


V1.2 26-May-2009 14


3) Lifecycle management

Fewer documents on backbone of dossier

Complicated to introduce discrete sections into a larger section for post approval changes (challenges presented in removing old data)

Lifecycle management is facilitated when multiple, smaller documents are provided.

Additional granularity puts a large number of files on the backbone;

Change management of submission documentation may be more challenging. As discrete sections or pages of large, single documents are updated, careful management of registration documentation (and conditions of approval) is needed to assure currently registered information is accessible

Consider using descriptive leaf titles for each file to help differentiate among multiple documents.

4) Reviewer ease

Can easily scroll to review content/sections

Increased number of bookmarks to follow

The multiple document approach to document preparation may facilitate the regulatory review of the submission, in particular with post-approval changes.

Increasing granularity can break the thought process for a reviewer. Not easy to review when there is no continuous flow/thread across different documents and different styles of writing by author. Multiple authors need to aligned and harmonized where possible.

Easier navigation Use of attachments causes difficulties (placement relevant to sections – not supported by CTD specification), e.g., signed COA‟s, unique Regional documents, literature references that are not journal references

Consider redundancies in information provided multiple times. It may be disruptive to review so many documents to obtain the full storyline which could have been described in one single document.

Need to scroll top down


V1.2 26-May-2009 15


5) Strictly adhering to M4Q for granularity

Consistent format for Health Authority reviewers and offers a consistent format

Does not allow flexibility as each submission is unique. Sometimes may need to write documents at the less granular level than the prescribed M4Q guidance or sometimes even more granular

Simple to implement; just separating breaks into separate technical documents (maintaining CTD headers and removing “industry” applied section numbers)

Does not consider the potential for lifecycle management updates.

6) CMC content of the submission

Multiple dosage strengths may best be presented in multiple documents if it is determined that there are manufacturing or control differences between the different strengths or if it is known that post-approval changes will need to be applied to one or more of the strengths.


V1.2 26-May-2009 16

Figure 1 - Example of Choices in Document Granularity

3.2.P.8.3 Stability Data

Potency 1 Potency 2

Stability Condition A Stability Condition B

3.2.P.8.3.1 Stability Data-Stability Condition

A

Potency 1 Potency 2

3.2.P.8.3.2 Stability Data – Stability Condition B

Potency 1 Potency 2

3.2.P.8.3.1.1 Stability Data- Stability Condition A-

Potency 1

3.2.P.8.3.1.2 Stability Data- Stability Condition A-

Potency 2

3.2.P.8.3.2.1 Stability Data- Stability Condition B-

Potency 1

3.2.P.8.3.2.2 Stability Data-Stability Condition B-

Potency 2

More Granular Less Granular


V1.2 26-May-2009 17

Practical Granularity Considerations CTD Numbering Scheme

CTD Section Title Granularity

3.2.S Drug Substance

3.2.S.1 General Information <no document>

3.2.S.1.1 Nomenclature single

3.2.S.1.2 Structure single

3.2.S 1.3 General Properties single

3.2.S.2 Manufacture <no document>

3.2.S.2.1 Manufacturer(s) single

3.2.S.2.2 Description of Manufacturing Process and Process Controls

single document

-or-

Separate documents each for flow diagram, detailed description and IPC.

3.2.S.2.3 Control of Materials Multiple documents for each specification, each method for each raw material, solvent and reagent, each method for each starting material

-or-

Single document for each material (reagent, solvent, starting material). Each single document has the spec, methods.

3.2.S.2.4 Controls of Critical Steps and Intermediates Single or Multiple - dependent upon the process (a separate document would be prepared for each intermediate product).

3.2.S.2.5 Process Validation and/or Evaluation single document

3.2.S.2.6 Manufacturing Process Development single document

3.2.S.3 Characterization <no document>

3.2.S.3.1

Elucidation of Structure and Other Characteristics

single

-or-

multiple documents. Solid state, physical chemical properties, elucidation of structure

3.2.S.3.2 Impurities single

-or-

multiple - one for product related, one for process related

3.2.S.4 Control of Drug Substance <no document>

3.2.S.4.1 Specification single document

3.2.S.4.2

Analytical Procedures

Multiple documents. One for each test procedure


V1.2 26-May-2009 18

CTD Numbering Scheme


-or-

single document

3.2.S.4.3

Validation of Analytical Procedures

Multiple documents. One report for each procedure.

-or-

single document

3.2.S.4.4

Batch Analyses

Single (overall table of batch results)

-or-

Multiple. CoAs for each batch

-or-

Multiple. Separate documents by type. (i.e. Registration, clinical, non-clinical)

3.2.S.4.5 Justification of Specification Single document

3.2.S.5 Reference Standards or Materials Single document or multiples with w/CoAs included

3.2.S.6 Container Closure System Single

-or-

-or-

Multiple. Separate document for each packaging material, test method, drawing, etc.

3.2.S.7 Stability <no document>

3.2.S.7.1 Stability Summary and Conclusions Single document Or Multiple, with storage statement/retest period as a separate document

3.2.S.7.2 Post-approval Stability Protocol and Stability Commitment

Single document

3.2.S.7.3 Stability Data Single document or multiple documents grouped by a logical variable for the substance (site, batch size, pilot, validation etc)

3.2.P Drug Product

3.2.P.1

Description and Composition of the Drug Product

Single

-or-

Multiple - a separate document is prepared for each dosage strength.


V1.2 26-May-2009 19



3.2.P.2 Pharmaceutical Development Single or Multiple document approach. One document may be prepared which contains all P.2 sections for the PharmDevelopment Report. Or consider that each subsection within P.2 may be its own document. Consider providing a separate document for Clinical Trial Formulations/Batch information.

3.2.P.3 Manufacture <no document>

3.2.P.3.1 Manufacturer(s) Single or Multiple

3.2.P.3.2 Batch Formula Single

-or-

Multiple. Considerations - a separate document for each dosage strength, site location or batch size (consider which variable works for your product).

3.2.P.3.3 Description of Manufacturing Process and Process Controls

Single

-or-

Multiple .

3.2.P.3.4 Controls of Critical Steps and Intermediates Single or Multiple - dependent upon the process.

3.2.P.3.5 Process Validation and/or Evaluation Single or Multiple, dependent upon the process and number of sites.

3.2.P.4 Control of Excipients A single document for all compendial excipients may be provided at this level in the XML backbone.

3.2.P.4.1 Specifications Single

3.2.P.4.2 Analytical Procedures Multiple - each analytical procedures is prepared as a separate document.

3.2.P.4.3 Validation of Analytical Procedures Multiple

3.2.P.4.4 Justification of Specifications Single

3.2.P.4.5 Excipients of Human or Animal Origin Single, (if applicable).

3.2.P.4.6 Novel Excipient Single

3.2.P.5 Control of Drug Product <no document>


V1.2 26-May-2009 20



3.2.P.5.1 Specification(s) Single or Multiple Consider a separate document for each dosage strength.

3.2.P.5.2 Analytical Procedures Multiple - each analytical procedures is prepared as a separate document.

3.2.P.5.3 Validation of Analytical Procedures Multiple, one document per analytical procedure

3.2.P.5.4 Batch Analyses Single or Multiple. Considerations – group by a logical variable (batch use, site, batch size etc.)

3.2.P 5.5 Characterization of Impurities Single

3.2.P.5.6 Justification of Specification(s) Single

3.2.P.6 Reference Standards or Materials Single or Multiple if CoAs provided

3.2.P.7 Container Closure System Multiple. Consider – grouping by some logical variable i.e. Pkg configuration

3.2.P.8 Stability <no document>

3.2.P.8.1 Stability Summary and Conclusion Single or multiple. Consider providing a separate document for storage statement

3.2.P.8.2 Post-approval Stability Protocol and Stability Commitment

Single

-or-

Multiple - a separate document is prepared for each dosage strength, potentially each manufacturing site. (Note - the protocol and commitments are combined in one document for each dosage strength, site, etc.)

3.2.P.8.3 Stability Data Multiple, grouped by some logical variable (primary stability, stress stability, supportive stability, etc.)

3.2.A Appendices

3.2.A.1 Facilities and Equipment Multiple documents, primarily to accommodate large file sizes and multiple sources of documents that are required

3.2.A.2 Adventitious Agents Safety Evaluation Single or multiple.

3.2.A.3 Novel Excipient Multiple – per ICH M4Q

3.2.R Regional Information Multiple

Industry Topic Paper: Leaf Titles 2009

V1.2 26-May-2009 21

Leaf Titles

Background The Leaf Title is the phrase that appears in the index.xml to describe a file‟s content. The XML backbone allows more than one leaf to point to the same physical file in the folder directory; however each leaf has its own identity value and may have its own unique title. Note: The Leaf Title and Filename are different properties (their entries are usually different).

For Example: Leaf Title=”Description and Composition of the Drug Product” Filename = “desc-comp.pdf”

Industry Thoughts and Experiences Titles: Consider… Pro Con

Length Limited character width is available on the screen In many tools, short titles makes more apparent any information that appears at the end of the title (e.g., operation attribute, sequence number)

If hypertext linking is not provided for all external cross-references and the leaf title does not match the (longer) text used in cross-references, the correct leaf to locate in the XML may not be apparent

Clarity Content of leaf is apparent without having to open/view it

Avoid adding clarity where not justified, e.g., avoid including strength to leaf titles of strength-independent topics (otherwise, adding a new strength later in the application would warrant a Replace of a leaf if its content did not change and would subject the old leaf content to a re-review)

Excluding the same information as in XML attributes or heading elements (e.g., ICH code) Exception: for applying logic to multiple leafs (e.g., 3.2.P.2.x and 3.2.R.x) where x = 1,2,3 etc. for successive leaves

Above as for Length Some tools produce a tab at the top of a viewed PDF. If multiple leaves can be viewed at the same time and the tab shows only the first [x] characters of the leaf title, then tabs could appear with the “same” (shortened) content. Contrary to ICH eCTD specification Appendix 4

Consistency of spelling across regions (use ICH eCTD specification where possible)

Consistent use of e.g., American vs. British English gives professional image

May introduce an additional publishing step (and introduce error)

Consistency of font, format and presentation of titles across sequences and across modules

Consistency (e.g., all Title Case format) gives a professional and pleasing image and makes the Cumulative View easier to review

Ensuring consistency may introduce an additional (manual) step and hence delay or error

Industry Topic Paper: Leaf Titles 2009

V1.2 26-May-2009 22

Titles: Consider… Pro Con

For example: Flow Diagram Description of Manufacturing Process Process Controls

Consistency of title content in the same element across sequences

Standardization makes content easier to grasp History (traceability) is obvious For example: Recommended – CoA BN-87087 CoA BN-13244 Not recommended – Certificate of Analysis BN -243 CoA BN34524 BN431245 Certificate of Analysis

May have to review prior submission(s) in eCTD viewer to assess the appropriate title for the new or replaced leaf

How to apply uniqueness (when multiple leaves are in same folder or New leaves appear in later sequences)

Placing uniqueness first makes differences in leaf content more apparent (e.g., „50 mg - Batch Analysis‟ vs. „Batch Analysis – 50 mg‟) in the XML and in leaf tabs

If multiple leaves can be viewed at the same time and the PDF has a tab that shows only the first [x] characters of the leaf title, then the CTD topic won‟t appear first when viewing leaves across elements Health authority may prefer the CTD topic to be first

Starting with a grouping phrase for those CTD topics with high granularity (e.g., S.2.3 Control of Materials, P.7 Container Closure System), e.g.,: Drawing – Bottle 75 ml Drawing – Bottle 150 ml Drawing - Blister

Leaf title can organize topics in a logical manner & ease of review

Addition of grouping phrase will lengthen the leaf title

Conventions used in other Modules (e.g., for 3.3 Literature References)

Consistency gives image of global review and coordinated application

Agreeing a single company standard may be difficult to achieve

Different titles for leaves that point to the same physical file in the folder directory

Uniqueness can focus reviewer on relevant content, e.g., a method that covers assay, content uniformity and identification might only be needed for identification from one XML section

Reviewer could be confused (e.g., Global Submit can note if linked files have been reviewed) – other vendor tools may not

Amending the content with clarification for subsequent submissions

Content of file is clear Inconsistency in the cumulative view may confuse viewers

Industry Topic Paper: Filenames 2009

V1.2 26-May-2009 23

Filenames

Background The Filename is a unique name given to a file and that appears as the final portion of the Directory. It includes the filename extension (e.g., …/myfilename.pdf). Note: The Leaf Title and Filename are different properties (their entries are usually different). Filenames are read by the XML language and have strict rules about structure, characters and total length. Filenames are subject to validation criteria in certain markets. Generally, eCTD filenames must be short and descriptive, use lower case letters, avoid special characters, and not contain any spaces. By contrast, a Leaf Title is a free text entry with no XML or eCTD validation rules.

For Example: Leaf Title=”Description and Composition of the Drug Product” Filename = “desc-comp.pdf”

Industry Thoughts and Experiences Filename: Consider… Pro Con

Compliance to XML restrictions provided in Appendix 2 of the ICH eCTD specification: Letters „a‟ to „z‟ Digits „0‟ to „9‟ Hyphen

No validation concerns Specification does not allow for: Japanese characters Regional characters, e.g., ö Spaces Colons Underscore (low lines) Uppercase Full stops (other than just prior to the extension)

Length filename restriction of 64 characters (including the extension) and total path restriction of 230 characters

1

Note: start counting at the sequence number (000x/…)

No validation concerns Portion added by the applicant is to be abbreviated however it can then be challenging as to what the abbreviation means

Regional expectations (e.g., Belgium checker)

No validation concerns Loss of flexibility Imposition of worst case restrictions for global submissions Regional rules vary across modules (e.g., M1 to M3)

Transformations, e.g.,: Decimal point to „pt‟ Plus sign to „and‟ Slash to „-„

No validation concerns Standardization offers consistency

Abbreviations can confuse understanding of the file‟s content

1 Sponsor’s eCTD building tool software may impose further restrictions on the total path length.

Industry Topic Paper: Filenames 2009

V1.2 26-May-2009 24

Filename: Consider… Pro Con

μg to „microg‟ Percentage to „pc‟ Ranges to „-„

Avoidance of: Consecutive hyphens In EU Module 1, hyphen in the variable portion Hyphen just prior to .extension (e.g., -.pdf)

No validation concerns

Industry Topic Paper: Lifecycle Management 2009

V1.2 26-May-2009 28

Lifecycle Management of CTD-Formatted Quality Documentation

Introduction Lifecycle Management is the ICH-CTD expectation that relevant documentation at the regulatory authorities describes current information about the product. While some markets, prior to CTD format, required "replacement pages" when changes in the product's lifecycle caused existing documentation to become outdated or incorrect, only with the introduction of CTD did it become a written expectation to clearly provide the updated content in a consistent and systematic way. Lifecycle management applies to new drug applications, new biologics applications, master file applications, and investigational new drug applications that are formatted and submitted in CTD or eCTD format. The expectation for lifecycle management appears in the ICH-CTD guideline "M4 Organization of the Common Technical Document for the Registration of Pharmaceuticals for Human Use"; it reads "In choosing the level of granularity for this Module, the applicant should consider that, when relevant information is changed at any point in the product's lifecycle, replacements of complete documents/files should be provided in the CTD and eCTD". While lifecycle management is not an ICH-CTD expectation for Modules 1 or 2, it may be beneficial to apply lifecycle management to some documents in these Modules. For example, a company might choose to keep the Index of Approved Commitments or the Log of Outstanding Regulatory Business living by replacing the document each year. Additionally, there may be some markets that require certain documents in Modules 1 and 2 to be kept living. For example, Health Canada requires that the Certified Product Information Document (CPID) be kept living. Also for Europe, it may be necessary to update the Quality Overall Summary when responding to questions during the review of an application. Additionally, it might be beneficial to keep the QOS updated if the QOS could potentially be provided to another market in a later wave of submissions (e.g., a market that requires a full dossier that aligns with the EU registration). The eCTD Specification provides for lifecycle management. The eCTD Specification requires that metadata, entitled the "Operation Attribute", be assigned to each document to inform the regulatory authority how the applicant intends the files in the submission to be used. The four operation attributes that can be used are: "New", "Replace", "Append", and "Delete". In the eCTD, each document must have one of these four operation attribute values associated with the document to aid regulatory agencies in managing the lifecycle of the submission. It is at the discretion of the applicant to choose which of the four Operation Attributes to assign to each file. Case examples are provided in the ICH-CTD specification "M2 EWG Electronic Common Technical Document Specification" to aid in understanding when it is appropriate to use each of the four operation attributes. Additional examples are provided below. When a file is submitted with an operation attribute of "replace" or "delete", the original file is not discarded or removed from the XML backbone. The eCTD DTD provides facilities for the regulatory authority to accurately locate the original file that was appended, replaced or deleted. Whenever "append", "replace", or "delete" are assigned to a document, additional metadata (entitled the "Modified-Leaf Attribute") must identify the original file. Authorities are expected to use eCTD viewing systems (or "viewers") that have the capability to view the entire dossier in a "current" view, where replaced and deleted files are not shown, and also to view the entire


V1.2 26-May-2009 29

dossier in a "cumulative" view where all documents are shown with designations to indicate when a document is current or not current. The expectation for lifecycle management should affect decisions regarding granularity. If documents are large and contain many facts that may change, it would be burdensome to repeatedly update and submit a large document. Likewise, it might be difficult for the regulatory authority to know what specific piece of information has been revised within the large document. Therefore, it is beneficial to divide these documents into multiple smaller documents ("granules") to ease the lifecycle management of the document. The expectation for lifecycle management should also affect decisions regarding eCTD leaf (document) titles. The applicant should consider if the product is likely to add new strengths, new dosage forms, new manufacturers, new container closure systems, etc. For example, while there may only be one container closure system in the original application, a second container closure system may be added later in the product's lifecycle. In this scenario, it would be wise to name the original file with an identifier (e.g., vial) for the container closure system. Then, if a document describing a new container closure system is added later, the new file can likewise include an identifier for the added container closure system (e.g., syringe). While the expectation for lifecycle management has been included in the ICH-CTD guidelines and while the operation attributes have been provided for managing lifecycle in the eCTD, little implementation guidance exists. For example, guidance does not currently exist to explain what documents should be kept in a current state or to specify what application types affect lifecycle. Additionally, guidance regarding the need to reformat previously-submitted non-CTD-formatted documentation into a baseline CTD application has not been provided by all agencies. Therefore, the following questions and answers are provided to aid in decision-making and implementing lifecycle management.


V1.2 26-May-2009 30

Questions and Answers

1. What are the "pros" and "cons" associated with lifecycle management?

Lifecycle management (use of the 4 operation attributes) is a characteristic principle and an expectation of the CTD and eCTD format. It is not appropriate to always assign "new" whenever a document is submitted. Listed below is a summary of what can be expected with the implementation of lifecycle management. Benefits of lifecycle management Difficulties caused by lifecycle management

Meets ICH-CTD expectations

Viewing applications is easier because documents can be seen in a current view.

Serves as an aid in complying with change control requirements, since it is simpler to find what information is currently registered. See comment

(a) under

difficulties.

Lifecycle management is achievable since you have the freedom to choose new, replace, append, or delete as you see fit.

If you keep documents current, you will be able to cross reference to them in the future, rather than sending them anew.

Additional resources may be needed when authoring submissions due to the need to locate and updated previously-submitted documents

Need to develop business processes for lifecycle management.

(a)

Need to fully understand that “current” documents do not necessarily correspond to “approved” documents. Need to take this into consideration when reviewing change controls.

Need to clarify for reviewers when documents are submitted for lifecycle management purposes only.

Increases submission workload to the extent that administrative changes need to be reported in an effort to support proper lifecycle management. Before lifecycle management came into existence, sponsors were not consumed with having to make "corrective" submissions as a means to update their product's lifecycle management.

Possibility for re-review of previously approved information, since historical documents are updated and submitted due to outdated information.

†

† Significant experience exists within industry to suggest that reviewers are not frequently re-reviewing previously-approved information that is provided solely because it is within the same document as information that is being updated during a product's lifecycle.

2. When does lifecycle management begin?

Lifecycle management considerations begin prior to the first eCTD submission. Decisions related to granularity, folder structures, and eCTD leaf (document) title should be made with the product's lifecycle in mind. Consider what documents are likely to become outdated, what information should be included in the eCTD leaf title to differentiate between similar files, and if line extensions are expected. Once relevant information is provided in Module 3 at any point in the product's lifecycle, replacements of complete documents/files should be provided.


V1.2 26-May-2009 31

3. When do we use new, replace, append, delete?

It is very important for authors to look at previous submission operations when planning future submissions.

Terms Definition

New A new document indicates the data is NEW and is NOT related to any previously submitted data. (eg.,0. New formulations, validation studies, new analytical methods)

Replace Use this operation for documents that replace a previously submitted document. The data in the previously submitted document is either partly or completely invalid but the section is still required in the submission. (e.g., change in a specific analytical procedure, updating stability data, change in a manufacturing procedure)

Delete Use this operation for documents that do not contain any valid information and no data is required in these sections. (e.g.: delete an old formulation, delete a discontinued assay).

Append Use this Operation to add information to current documents, where you want the reviewer to consider the original document and the appended document during review. The new data does NOT invalidate the existing “current” data, just adds to it. Append is not widely used for CMC applications (ex: append could be used to add stability data to a very large stability document. However, replace is more frequently used).

It is at the discretion of the applicant to choose which of the four operation attributes to assign to document. The most-commonly used operation attributes for CMC documents are included in Appendix 1.

4. What documents are living?

When preparing a post-approval change application, companies provide data and information to support the change. Additionally, for lifecycle management purposes, the company must also determine which previously-submitted CTD-formatted documents must be updated to reflect the changed information. In order to determine if each affected document must be updated to reflect a change, it is necessary to determine if the document is a "living" document. A living document is defined as any Module 3 document that contains information that provides factual information about the product, product components, and manufacturing facility or that provides information about how the product is currently manufactured, controlled, and tested. In contrast, a Module 3 document is not considered to be living if it contains information that describes a developmental study, validation study, or analyses of a specific lot. In general, documents that are not living do not need to be updated to reflect changes. It would not be appropriate to replace details of a study performed in the past. Also, it is not necessary to delete the document altogether, because the study continues to provide useful information about the product. For example, to change a product release specification for pH from 7.0 to 7.1, the company will provide data to support why the specification change is appropriate. Guidance documents usually outline the data needed to support a change. The company must then search through previously-submitted living CTD documents to locate instances where the specification is listed at 7.0. Living documents such as 3.2.P.5.1 Specifications will be updated to incorporate the new information. In contrast, a batch analyses table in 3.2.P.5.4 that provides the results of a lot manufactured and released prior to the pH specification change should not be updated to change the specification. The table should reflect the specification that was in place at the time. Detailed advice regarding the best operation attributes to assign to each CTD document is provided in Appendix 1.


V1.2 26-May-2009 32

5. What CMC application types affect lifecycle management?

Generally speaking, the documentation in Module 3 is expected to be "current", regardless of the application type in which a change is submitted. Therefore, all post-approval change application types should include updated module 3 documents if the documentation becomes outdated. Guidance does not exist on the mechanism for keeping module 3 current when very minor details become outdated. If a country does not have a minor change reporting system, there may not be a mechanism for updating the module 3 documentation. In a strict interpretation, it would be necessary to revise this information and call attention to the very minor changes in order to submit information that is current. It would not be appropriate to modify information in Module 3 without informing the agency that information has changed. The following table summarizes the pros and cons of updating module 3 with non-reportable changes.

Pros Cons

Meets the strict interpretation of the ICH-CTD expectation for lifecycle management

Very minor changes are not likely to generate questions or delay approvals

No mechanism exists for reporting minor changes for many regulatory agencies.

For agencies that have no minor change reporting system, it will be necessary to keep track of minor changes and report them in the next regulatory filing. Tracking could continue for many years.

If changes are tracked and filed with a later regulatory submission, regulatory agencies will not see changes until several years after they are implemented and they may not agree with the decision to consider a change to be very minor.

Additional resources may be needed when authoring submissions due to the need to keep track of minor changes


V1.2 26-May-2009 33

6. Is it necessary or beneficial to build a baseline eCTD-formatted dossier?

While it is not a requirement, reformatted legacy documentation for Quality modules may be reformatted into eCTD format and submitted to the agency (thereby creating an eCTD “baseline submission”). Generally speaking, reformatting is most often done gradually over time as variations of certain documents are submitted in eCTD format. However, the sponsor must weigh the benefits of having a complete dossier in eCTD format and seeing the "big picture" when setting granularity and filenames. This can also be achieved by creating a "roadmap" or an eCTD baseline application but not submitting it to the regulatory agencies. The following table summarizes the pros and cons of creating and submitting a CTD baseline application.

Pros Cons

The EU CTD/eCTD guidelines encourage manufacturers to voluntarily reformat quality information into eCTD format. The EU provides guidance on how to conduct reformatting from their previous format.

Once reformatted, it may be easier to refer to documents using current documentation management system

Considering all of the CTD components at one time may help manufacturers to establish granularity and file names with the "big picture" in mind.

Once Module 3 documentation is in CTD format, it must be kept current per lifecycle management requirements.

Significant resources may be required to reformat information.

In the US, Canada, and Australia, there is no guidance for reformatting into eCTD format.

7. What markets require lifecycle management?

The CTD and eCTD format (including lifecycle management) are expected in the US, EU, Canada, and Australia.

8. How do you minimize the impact of lifecycle management when you have shared drug substances, shared facilities, etc.?

In the United States, for pharmaceutical products, one of the NDAs in the product family can be considered the „parent‟ or primary NDA. Other NDAs sharing the same drug substance may include a cross reference to the „parent‟ or primary NDA. This cross reference may be placed in Module 1.4.4 Cross Reference to Other Applications or Module 3.2.S at the highest level (based on the tool being used). Once the cross reference is registered, changes to the drug substance would only be filed to the „parent‟ or primary NDA. This strategy avoids filing identical detail to multiple NDAs. When submitting a multi-product submission, the cover letter can list all of the -NDAs affected by the submission. Applicable form(s) for each NDA should be populated. A copy of the cover letter and the appropriate form(s) should be placed on the individual, corresponding NDA backbone. Only the „parent‟ or primary NDA will contain the Module 3 detail. When submitting to the Agency, a filing will be made for each NDA, even though all but one submission will only contain the cover letter and form(s).


V1.2 26-May-2009 34

In the United States, for biological products, post-approval changes can be filed using the trans-BLA process. When a change that is common to multiple products must be submitted, then the applicant can submit the documentation for the change to only one product. The application prepares one cover letter listing all affected products and a separate 356h form for each affected product. The cover letter, all of the 356h forms, and the module 3 documentation are submitted to only one product. CBER will review and approve the supplement for all affected products. Note that this trans-BLA system does not provide a mechanism for keeping the documentation current in the remaining product licenses. Ideally, manufacturers should choose the same product to which to send changes, so that one backbone is kept current. In the EU for biological products, the Vaccine Antigen Master File system can be used to consolidate drug substance documentation into one XML backbone. However, this system does not address shared facility documentation.

9. Considerations for lifecycle management of single documents that are linked or cross-referenced in the backbone

There are instances in Module 3 where information contained in a single file needs to be re-used or referenced throughout various modules on the backbone. In consideration of lifecycle, a reference (i.e., a hyperlink or a written cross reference to a single file) can be utilized. If a hyperlink is used, considerations should be made for lifecycle management of the modules. If a change is made to the referenced document in a future submission, the previous hyperlink will be lost. However, a written cross reference to the leaf title of the referenced document would remain intact and accurate throughout the lifecycle.


V1.2 26-May-2009 35

Appendix 1: Commonly Used Operation Attributes

CTD

Numbering Scheme

CTD Section Title Life Cycle for marketing

authorizations and/or clinical applications

Comments

Module 1 United States

1.1.1 Application Form: FDA Form 1571 new

1.1.2 Application Form: FDA Form 356h new

1.2 Cover Letters new

1.3.2 Field Copy Certification new

1.4.1 Letter of Authorization DMF letters - "replace" for updates, "new" for new letters

1.6.1 Meeting Request new

1.6.2 Meeting Background Materials new, append

1.6.3 Correspondence Regarding Meetings new

1.11.1 Quality Information Amendment

1.12.14 Environmental Analysis new, replace

1.12.16 Field Alert Reports new

1.13.5 Summary of Manufacturing Changes new, replace "Summary of manufacturing changes" = "new". "Index of Approved CMC Changes" = "replace"

1.13.6 Summary of Microbiological Changes new

1.13.7 Summary of Other Significant New Information

new

1.13.13 Status of Other Postmarketing Studies new, replace

1.13.14 Log of Outstanding Regulatory Business new, replace

Europe

1.0 Cover Letter new

1.2 Application Form new

1.4.1 Information about the Experts - Quality new

1.6.1 Non-GMO Environmental Risk Assessment new, replace

1.6.2 GMO Environmental Risk Assessment new, replace

N/A Responses to Questions new

Canada

1.4.1 Certified Product Information Document (CPID)

replace

Module 2

2.3 Quality Overall Summary - Introduction

new, replace

Pros for "new" = not required to update. Pros for "replace" = only one current document


V1.2 26-May-2009 36

CTD Numbering

Scheme CTD Section Title

Life Cycle for marketing authorizations and/or clinical

applications Comments

2.3.S Drug Substance New1

2.3.S.1 General Information replace, new, append2

2.3.S.2 Manufacture replace, new, append2

2.3.S.3 Characterisation replace, new, append2

2.3.S.4 Control of Drug Substance replace, new, append2

2.3.S.5 Reference Standards or Materials replace, new, append2

2.3.S.6 Container Closure System replace, new, append2

2.3.S.7 Stability replace, new, append2

2.3.P Drug Product new1

2.3.P.1 Description and Composition of the Drug Product

replace, new, append2

2.3.P.2 Pharmaceutical Development replace, new, append2

2.3.P.3 Manufacture replace, new, append2

2.3.P.4 Controls of Excipients replace, new, append2

2.3.P.5 Control of Drug Product replace, new, append2

2.3.P.6 Reference Standards or Materials replace, new, append2

2.3.P.7 Container Closure System replace, new, append2

2.3.P.8 Stability replace, new, append2

2.3.A.1 Facilities and Equipment replace, new, append2

2.3.A.2 Adventitious Agents Safety Evaluation replace, new, append2

2.3.A.3 Excipients replace, new, append2

2.3.R Regional Information replace, new, append2

Module 3

3.2.S Drug Substance new1

3.2.S.1.1 Nomenclature replace

3.2.S.1.2 Structure replace

3.2.S.1.3 General Properties replace

3.2.S.2.1 Manufacturer(s) replace

3.2.S.2.2 Desc. of Manuf. Process and Process Controls

replace could also use "new" for a new operation or a new site

3.2.S.2.3 Control of Materials replace could also use "new" for a new material

3.2.S.2.4 Controls of Critical Steps and Intermediates


3.2.S.2.5 Process Validation and/or Evaluation new

3.2.S.2.6 Manufacturing Process Development new

3.2.S 3.1 Elucidation of Structure and other Characteristics

replace, new


V1.2 26-May-2009 37

CTD Numbering




3.2.S.3.2 Impurities new, replace

3.2.S.4.1 Specification replace

3.2.S.4.2 Analytical Procedures replace could also use "new" or "delete" for adding or deleting an assay, respectively

3.2.S.4.3 Validation of Analytical Procedures new could also use "replace" if documents are divided into "granules" by parameter rather than by method

3.2.S.4.4 Batch Analyses new

3.2.S.4.5 Justification of Specification new could use "replace" if a table of specifications and justifications is provided

3.2.S.5 Reference Standards or Materials replace

3.2.S.6 Container Closure System replace

3.2.S.7.1 Stability Summary and Conclusions replace, new "new" can be used for new studies

3.2.S.7.2 Post-approval Stab. Protocol and Stab. Commitment

replace, new new can be used for new studies

3.2.S.7.3 Stability Data replace, new new can be used for new studies

3.2.P Drug Product new1

3.2.P.1 Description and Composition of the Drug Product

replace

3.2.P.2 Pharmaceutical Development new3

3.2.P.2.1 Components of the Drug Product new

3.2.P.2.2 Drug Product new

3.2.P.2.3 Manufacturing Process Development new

3.2.P.2.4 Container Closure System new

3.2.P.2.5 Microbiological Attributes new

3.2.P.2.6 Compatibility new

3.2.P.3.1 Manufacturer(s) replace

3.2.P.3.2 Batch Formula replace

3.2.P.3.3 Description of Manufacturing Process and Process Controls


3.2.P.3.4 Controls of Critical Steps and Intermediates


3.2.P.3.5 Process Validation and/or Evaluation new

3.2.P.4.1 Specifications replace

3.2.P.4.2 Analytical Procedures replace could also use "new" or "delete" for adding or


V1.2 26-May-2009 38

CTD Numbering




deleting an assay, respectively

3.2.P.4.3 Validation of Analytical Procedures new could also use "replace" if documents are divided into "granules" by parameter rather than by method

3.2.P.4.4 Justification of Specifications new could use "replace" if a table of specifications and justifications is provided

3.2.P.4.5 Excipients of Human or Animal Origin new, replace, delete

3.2.P.4.6 Novel Excipient

3.2.P.5.1 Specification(s) replace

3.2.P.5.2 Analytical Procedures replace could also use "new" or "delete" for adding or deleting an assay, respectively

3.2.P.5.3 Validation of Analytical Procedures new could also use "replace" if documents are divided into "granules" by parameter rather than by method

3.2.P.5.4 Batch Analyses new

3.2.P.5.5 Characterisation of Impurities new, replace

3.2.P.5.6 Justification of Specification(s) new could use "replace" if a table of specifications and justifications is provided

3.2.P.6 Reference Standards or Materials replace

3.2.P.7 Container Closure System replace, new

3.2.P.8.1 Stability Summary and Conclusion replace, new "new" can be used for new studies

3.2.P.8.2 Post-approval Stability Protocol and Stability Commitment

replace, new "new" can be used for new studies

3.2.P.8.3 Stability Data replace, new "new" can be used for new studies

3.2.A.1 Facilities and Equipment replace, new

3.2.A.2 Adventitious Agents Safety Evaluation new

3.2.A.3 Excipient new, replace, delete

3.2.R Regional Information replace, new

3.3 Literature References new, replace

1 The ICH-CTD Guideline M4 states that no documents should reside at this level. However, experience with inserting a document at this location (usually to provide a document containing a cross-reference to another location) exists within the industry. The ability to have a document at this level may be dependent upon the eCTD building tool that is used.


V1.2 26-May-2009 39

CTD Numbering




2 The ICH-CTD Guideline M4 states that only one document should reside at this level. However, experience with using the operation attribute "new" in order to have multiple documents at this level exists within the industry. The ability to have multiple documents at this level may be dependent upon the eCTD building tool that is used. In order to keep only one document at this level, then "replace" or "append" can be used to update the QOS, as required.

3 The ICH-CTD Guideline M4 states that documents may be placed at 4-level (3.2.P.2) or 5-level (3.2.P.2.x) granularity at this location.

Industry Book of Knowledge: Relevant Guidance 2009

V1.2 26-May-2009 28

Relevant Guidance Health Authority guidelines are available that give Industry a good idea of where content should be presented ICH: M2 WG: http://estri.ich.org/eCTD/eCTD_Specification_v3_2.pdf M4: http://www.ich.org/LOB/media/MEDIA554.pdf EMEA: The EU-CTD Notice to Applicants http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol2_en.htm The CTD question and answer document published by the Notice to Applicants http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd_qa_05_2006.pdf The ICH CTD Q & A: http://www.ich.org/LOB/media/MEDIA1189.pdf The ICH CTD Q & A: EU: Updated ICH M2 Questions & Answers on Common Technical Document for the Registration of

Pharmaceuticals for Human Use; EMEA website, 19-Dec-2008 The EMEA pre-submission guidance: http://www.emea.europa.eu/htms/human/postguidance/index.htm The EMEA post-authorization guidance: http://www.emea.europa.eu/htms/human/postguidance/index.htm EMEA guidance on file-naming: http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol2_en.htm EMEA guidance on pdf file-naming: http://www.emea.europa.eu/htms/human/qrd/docs/43183607en.pdf December 2008 EMEA Statement of intent: http://www.emea.europa.eu/pdfs/human/regaffair/57245908en.pdf Jan 2008 EMEA Statement of Intent: http://www.emea.europa.eu/pdfs/human/regaffair/56336607en.pdf FDA: M4 Guidance for Industry http://www.fda.gov/cber/gdlns/m4ctd.pdf; M4Q - Quality Guidance for Industry http://www.fda.gov/cder/guidance/4539q.pdf

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

http://www.ich.org/LOB/media/MEDIA554.pdf

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol2_en.htm

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd_qa_05_2006.pdf

http://www.ich.org/LOB/media/MEDIA1189.pdf

/traction/read?proj=Themes&sort=3&type=single&rec=771&side=1

/traction/read?proj=Themes&sort=3&type=single&rec=771&side=1

http://www.emea.europa.eu/htms/human/postguidance/index.htm

http://www.emea.europa.eu/htms/human/postguidance/index.htm

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol2_en.htm

http://www.emea.europa.eu/htms/human/qrd/docs/43183607en.pdf

http://www.emea.europa.eu/pdfs/human/regaffair/57245908en.pdf

http://www.emea.europa.eu/pdfs/human/regaffair/56336607en.pdf

http://www.fda.gov/cber/gdlns/m4ctd.pdf

http://www.fda.gov/cder/guidance/4539q.pdf

Industry Book of Knowledge: Relevant Guidance 2009

V1.2 26-May-2009 29

Guidance for Industry M2: eCTD Specification, Questions & Answers and Change Requests http://www.fda.gov/cder/guidance/6339fnl.pdf Guidance for Industry M2: eCTD Specification, Questions & Answers and Change Requests http://www.fda.gov/cber/gdlns/ichm2ectdqa1.pdf Health Canada: Draft Guidance for Industry: Preparation of New Drug Submissions in the CTD Format: http://www.hc-sc.gc.ca/dhp-mps/alt_formats/hpfb-dgpsa/pdf/prodpharma/notice_avis_ctd-eng.pdf Canadian M1 guidance: http://www.hc-sc.gc.ca/dhp-mps/prodpharma/applic-demande/guide-ld/ctd/ectd/ectd_mod1_guide-ld-eng.php Japan: http://www.mhlw.go.jp/english/index.html Australia: Draft eCTD guidance: http://www.tga.gov.au/pmeds/ectdguidedr.pdf Australian Module 1 guidance: http://www.tga.gov.au/pmeds/ectdaumod1.pdf

http://www.fda.gov/cder/guidance/6339fnl.pdf

http://www.fda.gov/cber/gdlns/ichm2ectdqa1.pdf

http://www.hc-sc.gc.ca/dhp-mps/alt_formats/hpfb-dgpsa/pdf/prodpharma/notice_avis_ctd-eng.pdf

http://www.hc-sc.gc.ca/dhp-mps/prodpharma/applic-demande/guide-ld/ctd/ectd/ectd_mod1_guide-ld-eng.php

http://www.hc-sc.gc.ca/dhp-mps/prodpharma/applic-demande/guide-ld/ctd/ectd/ectd_mod1_guide-ld-eng.php

http://www.mhlw.go.jp/english/index.html

http://www.tga.gov.au/pmeds/ectdguidedr.pdf

http://www.tga.gov.au/pmeds/ectdaumod1.pdf

Industry Book of Knowledge: Version History 2009

V1.2 26-May-2009 28

Version History V1.0 Initial Compiled Draft for Review April 1, 2009

V1.1 Industry Comments incorporated. Version history added

May 11, 2009

V1.2 Foreword added, spell check and TOC modified for consistency across sections. Other formatting.

May 22, 2009