Cover Letter Example - Excel
Cover Letter Example document sample
Shared by: jgz20642
EU Region Question and Answer and Specification Change Request Document Version 1.17 March 2009 Document Change History Version Number Date Description Version 1.0 Jul-04 Initial baseline after reviewing existing questions Version 1.1 Sep-04 Change Request added (EFPIA) Version 1.2 Jun-05 New Change Requests and Q&A added, plus ICH Q&A referred for regional advice Version 1.3 Sep-05 New Change Requests 09, 10, 11, 12, 13 added Version 1.4 Nov-05 New Change Request 14 added Version 1.5 Dec-05 Q&A 14 added Version 1.6 Dec-05 Updated after release of eCTD v1.1 Version 1.7 Mar-06 CRs 15-16-17-18 Added for TIGes-J-24 Version 1.8 Jun-06 Review of document carried out for TIGes Version 1.9 Nov-07 Comprehensive addition of accrued change requests and review of summaries Version 1.10 Jan-08 Further updates for publishing on EMEA e-subs website Version 1.11 Jan-08 More updates for publishing on EMEA e-subs website (whilst review of CRs/Q&A is ongoing) Version 1.12 Mar-08 Q&As 9, 12, 15-21 added confirmed after TIGes-J-32 Version 1.13 Jun-08 CRs and QA 22 added for TIGes 33, general update after publication of EU M1 specification v1.3 Version 1.14 Dec-08 Comments from Interlinking Group on all CRs assigned to this group, and comments from Dec. TIGes. Addition of CR-2008-12-10 Version 1.15 Mar-09 CRs added for TIGes 35. Full review of outstanding change requests and assignments. Introduction of colour coding for open/closed CRs Version 1.16 Mar-09 Updated after Interlinking meeting review of all assigned CRs Version 1.17 May-09 Updated after Interlinking meeting of April 2009 and publication of updated validation criteria May 2009, update of CP dossier requirements April 2009, publication of Harmonisaed Guidance May 2009 Introduction This document is a summary of questions and change control requests reviewed by the Telematics Implementation Group electronic submissions (TIGes) on the eCTD Specification, PIM and electronic Application Forms (eAF). Questions are listed with with an approved answer. Change control requests are listed with details of the person, company or organisation who submitted the request, along with details of the actions taken and status of the request. The change control requests and Q&As here relate to EU specific aspects of the eCTD and EU regional electronic submission formats. Reference should be made to the ICH Q&A and Change Requests tracking document for matters that affect all regions (http://estri.ich.org/ectd/). This document will be updated as the specification undergoes change control or as new questions are submitted to the TIGes. Key to Q&A Worksheet Each question is numbered. The question is written out in full and a reference to the change control procedure item that caused the question to be asked is listed. An official answer is given. The approval date for the answer is listed. Key to Change Requests Worksheet Each change request or question received is numbered. A subset of the change request or question information is copied from the "European eCTD Standards Q&A and Change Request Form", including the name and organisation of the person raising the request and the description of the change or the question in full. Any comments arising during the analysis of the issue by TIGes are recorded as well as the Status and Action(s) resulting. CR closed : Either action progressed to completion in EU, Referred to ICH M2 and completed, Rejected and not progressed CR open : On-going within EU or Referred to ICH M2 still on-going # Question Answer Approval Date 1 What is the EU's position on the use of XML for the content of the In line with the general principles of the ICH eCTD Specification Document, it is Mar-2007 submission instead of PDF and/or RTF? intended that XML will become the submission format for administrative forms and product information documents as they contain structured data. The long This question was generated by EU Change Request A001 term goal of this development is the normalisation of data in Module 1. As the XML documents become available for practical implementation, they will be introduced into Module 1 and the current file formats may be replaced after a transition period. 2 Can further guidance be given on the acceptable formats for With respect to product information (PI) documents, the currently acceptable file Mar-2007 product information in the eCTD? formats are indicated in the EU Module 1 specification. When generating product information files for the Centralised, Mutual recognition and This question was generated by EU Change Request A002 Decentralised Procedures, QRD templates as issued by the EMEA should be used. For National Procedures, refer to national guidance. The EU will be moving into the direction of an XML approach for the exchange of product information as part of the Product Information Management (PIM) project which is currently being implemntated in the Centralised Procedure. For additional details on the PIM project, see: http://pim.emea.europa.eu 3 Is the submission of application forms as XML documents It is the intention of the EU to provide XML standards for application forms. The Mar-2007 acceptable? specifications for new and variations forms have been issued and can be accessed at This question was generated by EU Change Request A003 http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm. An electronic version of the renewals form is currently under development. Refer to national guidance regarding the applicability of the XML Application Forms. 4 What is EU's position on the use of e-signatures in the eCTD? A crucial part of pure electronic communications between the pharmaceutical Mar-2007 industry and regulatory agencies and authentication of electronic submissions This question was generated by EU Change Request A004 or documents contained in electronic submissions will be the use of digital signatures. Currently the EU is developing a (long-term) strategy to implement digital signatures. As yet, digital signatures cannot be used or supported in electronic submissions in the EU. # Question Answer Approval Date 5 How should an applicant handle a Type I variation within an eCTD? The Notice to Applicants group has issued a CTD Q&A regarding the placement Mar-2007 of documents within the CTD structure for Type I variations. The eCTD should This question was generated by EU Change Request 0003 also be constructed using these principles. The Q&A (4c) can be accessed at http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol- 2/b/ctd_qa_05_2006.pdf 6 The EU Module 1 Specification allows 3 procedures (National, The EU Module 1 specification defines the submission types that are part of the Mar-2007 Centralised and Mutual recognition procedure). How should eCTD (V1.2.1, p10). The submission type to be used in this instance is “Community referrals” be handled, which type of procedure should 'arbitration'. [Note, since this question was originally received, the EU has be used respectively? added the Decentralised Procedure as an acceptable submission procedure type.] This question was generated by EU Change Request 0004 7 I am trying to understand the complete scope of what submissions The EU Module 1 specification defines the submission types that are part of the Mar-2007 are to be eCTD (V1.2.1, p10). All of these submission types are covered, including required as CTD/e-CTD submissions in the EU. Follow-up Measures and PSUR submissions. From reading some background on the topic, I think the scope may include: - all new applications - all variations - all response documents (MRP and CP response documents) - all renewals but does not include - submissions of data as part of a FUM but which is not a variation - PSUR submissions Can you please confirm/correct this understanding. This question was generated by EU Change Request A007 # Question Answer Approval Date 8 I am seeking information on the structure of the eCTD response to The May 2006 version of the Notice to Applicants Mar-2007 list of questions dossier. In the eCTD EU module 1 specifications (http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd_05- v1.0, it is stated that responses to questions can be included in 2006.pdf) now defines a specific section in Module 1 for Responses to Module 1. At the Annex 2 level, it is stated that response Questions, what to include in Module 1 and what to include in Modules 2-5. The documents should be attached to the Cover Letter (1.0). However, EU Module 1 specification Version 1.2.1 now includes the section for no recommendation is given with regard to the organisation of the Responses to Questions. The CTD guidance and eCTD specification together table of contents, nor to the names and organisation of the files etc. should give adequate direction for applicants to construct a Responses to Do these recommendations exist? Questions dossier in eCTD format. The filenaming recommendation is also included in the EU specification v1.2.1. This question was generated by EU Change Request A008 9 M3 requires each substance-manufacturer and drug product to be The ICH CTD guidance recommends that the applicant repeat the complete Feb-2008 added in a separate subfolder. How should a product be added to Module 3.2.S for each drug substance that makes up the drug product. The the structure if it has multiple substances? ICH eCTD specification allows the repeat of the Module 3.2.S within the XML backbone. Therefore, the applicant should create the eCTD in this way. This question was generated by EU Change Request A009 10 Where can node extensions be used in a EU eCTD submission? Node extensions may be used where additional navigation in the XML backbone Mar-2007 is required. The primary place where they may be used is in Module 5 where a The question was generated by ICH change request 00560 and the node extension for each study may be useful so as to allow multiple files for a response to ICH eCTD Question 28. This is recorded as EU single study to be grouped together and separated distinctly from other studies. Change Request A010. For Module 4 where there are multi-file reports this can also be useful. Other places where they can be useful is in Module 1 to differentiate between PI documents provided in PDF and those provided in RTF/Word and in Module 5 to differentiate reports associated with a different dosing regimen for the same indication. However, the use of node extensions should be limited to those areas where it is critical and consideration should be given regarding the impact of the view for the reviewer since the inconsistent use of node extensions can lead to unanticipated effects in the cumulative view of a submission. See separate Q&A #10 worksheet for more details # Question Answer Approval Date 11 In the eCTD for the EU, are applicant provided style sheets Little advantage is to be gained by the use of custom stylesheets. The XML Mar-2007 allowed? instance can only point to one stylesheet and the inclusion of a reference to a stylesheet that is not the regional one would prevent the agency using the The question was generated by ICH change request 00710 and the official EU stylesheet. It is therefore recommended not to submit customised response to ICH eCTD Question 30. This is recorded as EU stylesheets. Change Request A011. 12 Can clearer guidance be provided regarding how to use the A 'regulatory activity' is a logical unit of submission activity (eg, a Type II Feb-2008 Related Sequence attribute during the lifecycle of the eCTD? Variation) with a defined start and end point (eg initial submission to final approval). In the eCTD world, this will consist of all the sequences that together This question was generated by EU Change Requests A012 and make up the lifecycle of that particular 'regulatory activity‟. QA-20070628-01 The related sequence attribute should always be left blank for new applications or new regulatory activities (eg variations, PSURs). When submitting lifecycle sequences within an existing activity, the related sequence attribute should be populated with the sequence number of the first sequence in the activity, regardless of how many sequences make up the activity. The related sequence attribute should be considered independent of any modified file attributes in a submission. For example, if a sequence 0010 modifies files (leaves) in sequence 0008 and 0009, the entry for related sequence in sequence 0010 should be the sequence number that started the regulatory activity that 0010 falls within, which will not necessarily be sequence 0008 or 0009. For examples, see the table in Worksheet QA 19. 13 ICH has issued a list of items to be checked by the applicant before A list of validation criteria specific to the EU has been prepared by the EURS Jan-2008 a submission is sent to the agency (Q&A 36). Could a list also be Implementation Group and is to be published separately on the esubmission produced for EU regionally specific items that should also be website http://www.esubmission.europa.eu checked? This question was generated by EU Change Request A013 14 What is the EU regional guidance relating to the ability to cross- In the EU it is possible to refer to a file located in the same sequence or any Mar-2007 reference from one sequence to files in another sequence? previous sequence of the same eCTD. It is not possible to refer to other eCTDs. The question was generated by ICH change request 01080 and the response to ICH eCTD Question 37. This is recorded as EU Change Request A014. # Question Answer Approval Date 15 How is the applicant advised to handle technical (eCTD If an eCTD fails technical validation, then a replacement sequence must be Feb-2008 specification) and business (content) validation changes in the provided, since an invalid sequence cannot be loaded into an agency‟s review eCTD tool. If, once technical validation has been completed, content validation identifies missing sections or administrative errors, then an additional new This question was generated from EU Change Request QA- eCTD sequence should be provided (a lifecycle sequence) correcting these 20061120-01 errors, with replacement or additional new documents as required. The applicant should not send a replacement of the original sequence. 16 The EU eCTD Specification v1.2.1 states that the variable No it is not acceptable to use a hyphen. In cases where differentiation is Mar-2008 component of filenames should be a “meaningful concatenation of needed it is suggested that the word 'point' is used in the filename eg. words without separation and should be kept as brief and 1point5mg descriptive as possible” but also specifies that hyphens (“-“) should not be used within these variable components. There are occassions where there needs to be differentiation between documents, for example, strength (1.5mg or 15mg). Is it acceptable that under such circumstances to use a hyphen to differentiate between documents. This question was generated by EU Change Request CR- 20061221-01 17 The EU eCTD Specification v1.2.1 states that the envelope element The envelope should be repeated for each member state and 'common' should Feb-2008 of MRP or DCP submissions could be assigned a country attribute not be used. The specification will be updated at the next version to correct this. value "common" when the same sequence is being submitted to multiple countries. Isn't it more appropriate to utilise a separate envelope for each Member State? This question was generated by EU Change Request CR- 20070309-01 # Question Answer Approval Date 18 Is it necessary to include statements in the CTD/eCTD justifying the For new applications, detailed statements justifying absence of data or specific Mar-2008 absence of data? If so, where should these statements be placed in CTD sections should be provided in the relevant Quality overall summary and/or the CTD structure? non-clinical/clinical overviews (Module 2.3, 2.4, 2.5). Note that placeholder documents highlighting 'no relevant content' should not be placed in the eCTD This question was generated by EU Change Request QA- structure, as these would create a document lifecycle for non-existent 20070627-01 documents and unnecessary complication and maintenance of the eCTD. 19 In Europe does the applicant need to update attributes in the eCTD Reference is made to ICH Q&A #3. It is not possible to update the attributes Mar-2008 backbone during the life an application, for example, if the nor is it necessary to attempt workarounds such as deleting existing documents manufacturers name changes, the proposed name of the dosage and resubmitting with new attributes. The recommendation is to retain the form is not accepted or an excipient is granted a pharmacoepial obsolete entry and to rely on the document content to explain the current details. name. This question was generated by EU Change Request QA- 20070816-01 20 Should eCTD Module 1 section "additional data" be empty for Yes. The Notice to Applicants CTD Q&A #4C states that the 'Additional Data" Mar-2008 EMEA centralised procedures? should only be used for information required for National, MRP and This question was generated by EU Change Request CR- Decentralised Procedures and is therefore not applicable for the Centralised 20071002-01 Procedure except during a transition period when an old version of a DTD is being used to support inclusion of a newly defined section of Notice to Applicants ie. paediatric data which will be included in EU specification Module 1 v1.3 as a new section 1.10 Information relating to Paediatrics. # Question Answer Approval Date 21 Can content files that are included in the index.xml (ICH Modules 2- Yes. For appendices to the application form which may also be located in Mar-2008 5) also be referred to in the eu-regional.xml? module 3, it is recommended to create a leaf in the eu-regional.xml that points This question was generated by EU Change Requests CR- to the content located in module 3 e.g. Flow Chart of the Manufacturing Sites, 20070906-01 & CR-20070927-01 and Ph.Eur Certificate. Other scenarios where this approach should be used include type Ia and Ib variations, where content is requested in module 1 which is available in pre-existing locations in module 3, e.g. copy of the approved specification. 22 In the NtA Section 2.7.6 Synopses of Individual Studies requires It is acceptable either to include copies of the synopses for each study in Apr-2009 that the synopses are included in this section but the ICH eCTD Section 2.7.6 or to provide hyperlinks to synopses located in Module 5 without Specification suggests that it would be satisfactory to provide providing copies in section 2.7.6. In either case a Listing of Clinical Studies hyperlinks to the synopses located in Module 5. Could clarification should be provided and this should include hyperlinks to the first page of each be provided regarding what is acceptable for the eCTD in the EU? synopsis. This question was generated by EU Change Request CR-20090126 Node Extensions As noted in the ICH Q&A 28, the use of node extensions is to be clarified in regional guidance. This short document proposes how node extensions may be used in EU eCTDs. Assumption: The applicant is not planning to create a single eCTD for Modules 2-5 that can be used in all regions. As noted, the FDA expressly forbids the use of node extensions, therefore, if the these are inserted anywhere in Modules 2-5 the eCTD will be invalid in the US. Node extensions are a way of providing extra organisational information to the eCTD. The node extension should be visualised as an extra heading in the CTD structure and should be displayed as such when the XML backbone is viewed. The following are the proposed rule for the use of node extension in the EU: 1. Node extensions must not be used where there is an ICH specified node extension e.g. indication, manufacturer, drug substance, drug product are all ICH specified node extensions 2. Node extensions must only be used at the lowest level of the eCTD structure e.g. a node extension can be used at the level 184.108.40.206 but must not be used at the level 5.3 It was noted that the eCTD DTD currently allows node extensions to be placed at any level, eventually, this may need to be amended in the ICH specification. 3. Node extensions are mainly to be used to group together documents made up of multiple leaf elements e.g. a clinical study made up of separate files for the synopsis, main body and individual appendices could be grouped together under a node extension with the Study Identifier as its Title attribute 4. Once added, node extensions must be maintained over the entire life of the eCTD lifecycle e.g. if a node extension is used in sequence 0000 to group files for a study report in Module 220.127.116.11, then any files submitted in a later sequence must also be placed under a node extension, even if only one file is submitted 5. Node extensions may be nested as this is allowed by the eCTD DTD. However, as noted in point 2, the first node extension must be at the lowest level in the eCTD structure. e.g. in Module 5.3.7 a node extension may be added to group together files with the Study Identifier as Title attribute. Further node extensions may be added as children of the Study Identifier node, separating CRFs from individual patient listings. Note : This description has been included in EU Specification v1.3 Example of how the Related Sequence should be used Sequence Submission Description Related Comment Sequence 0000 Original MAA application <none> 0001 Day 121 Responses to questions on the original application 0000 This is a continuation of the regulatory activity initiated in 0000 and so the related sequence points to the beginning of that activity 0002 Day 181 Responses to further questions on the original 0000 This is a continuation of the regulatory activity initiated in application 0000 and so the related sequence points to the beginning of that activity 0003 Type II variation for treatment of pain indication <none> This is the beginning of a new regulatory activity and so no related sequence is included 0004 Type II variation for a change in manufacturing site (Westferry) <none> This is the beginning of a new regulatory activity and so no related sequence is included 0005 Responses to questions on Type II variation for the pain 0003 This is a continuation of the regulatory activity initiated in indication 0003 and so the related sequence points to the beginning of that activity 0006 Responses to questions on Type II variation for change in 0004 This is a continuation of the regulatory activity initiated in manufacturing site (Westferry) 0004 and so the related sequence points to the beginning of that activity 0007 Line extension to introduce a new dosage form (iv solution) <none> This is the beginning of a new regulatory activity and so no that amends information provided in the original application related sequence is included and the manufacturing change variation 0008 Updated, agreed, product information taking into account new 0003 This is the completion of the new indication (pain) activity indication (pain) 0009 Updated, agreed product information for the iv formulation 0007 This is the completion of the new dosage form (iv solution) activity Note : This description has been included in EU Specification v1.3 EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting A001 eCTD EU Module 1 What is the EU's position on the use of XML for the content of the Change request added retrospectively to allow Implemented in EU Implement in v1.3: Specification submission instead of PDF and/or RTF? tracking of the Q&A process M1 v1.3 Answered as Question #1. Clarify in Appendix 2 row 6 (comments section) A002 eCTD EU Module 1 Can further guidance be given on the acceptable formats for product Change request added retrospectively to allow Answered in Q&A Answered as Question #2 Specification information in the eCTD? tracking of the Q&A process A003 eCTD EU Module 1 Is the submission of application forms as XML documents acceptable? Change request added retrospectively to allow Answered in Q&A Answered as Question #3 Specification tracking of the Q&A process A004 eCTD EU Module 1 What is EU's position on the use of e-signatures in the eCTD? Change request added retrospectively to allow Implemented in EU Implement in v1.3: Specification tracking of the Q&A process M1 v1.3 Answered as QAA #4. Include a new section alongside 'acceptable formats' p.6 stating that reference should be made to national guidance on the use of e-signatures. A007 eCTD EU Module 1 I am trying to understand the complete scope of what submissions are to be Change request added retrospectively to allow Answered in Q&A Answered as Question #7 Specification required as CTD/e-CTD submissions in the EU. tracking of the Q&A process From reading some background on the topic, I think the scope may include: - all new applications - all variations - all response documents (MRP and CP response documents) - all renewals but does not include - submissions of data as part of a FUM but which is not a variation - PSUR submissions Can you please confirm/correct this understanding. A008 eCTD EU Module 1 I am seeking information on the structure of the eCTD response to list of Change request added retrospectively to allow Answered in Q&A Answered as Question #8 Specification questions dossier. In the eCTD EU module 1 specifications v1.0, it is stated tracking of the Q&A process that responses to questions can be included in Module 1. At the Annex 2 level, it is stated that response documents should be attached to the Cover Letter (1.0). However, no recommendation is given with regard to the organisation of the table of contents, nor to the names and organisation of the files etc. Do these recommendations exist? A009 M3 requires each substance-manufacturer and drug product to be added in Change request added retrospectively to allow Answered in Q&A Answered as Question #9 a separate subfolder. How should a product be added to the structure if it tracking of the Q&A process has multiple substances? EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting A010 The question was eCTD EU Module 1 Clarification should be provided by all ICH regions as to whether node November 2004: The use of node extensions Implemented in EU Implement in v1.3: generated by ICH Specification extensions can be used in Modules 2-5 should be discussed with FDA on a case by M1 v1.3 Answered as Q&A #10. change request The ICH spec allows node extensions to be used in Modules 2-5 and their case basis. Other regions are able to accept Include on p.7 an additional 00560 use in Module 1 is a regional matter. FDA states that node extensions are appropriate use of node extensions in section with agreed text not supported in any part of the submission and this therefore invalidates compliance with the eCTD specification (i.e. the ICH spec. Experience on production of submissions for Europe their use is discouraged unless there is no demonstrates that node extensions are required to deliver a navigable other feasible means to submit the structure for Modules 4 and 5. At present this means that eCTDs are not re- information). usable across regions and thus will create significant amounts of rework for industry. FDA should accept node extensions in Modules 2-5. May 2005: Referred to EU and MHLW regional guidance for specific instances where it can be used. June 2005: Proposal to come from EFPIA as to how node extensions may be accepted in the EU. Clarification: FDA strongly discourages node extensions. ACTION: EFPIA to circulate the proposal to TIGes-J. A011 The question was eCTD EU Module 1 Are applicant provided style sheets allowed? May 2005 - referred to EU and MHLW for Implemented in EU Implement in v1.3: generated by ICH Specification regional guidance M1 v1.3 Answered as Question 11. change request Put a comment in appendix 00710 June 2005: Applicant stylesheets are 2,row 72. accepted in the EU. However, there are improvements to be documented and made to the EU stylesheet to ensure that its features meet requirements. If necessary changes are made, the use of company stylesheets should be strongly discouraged. A012 The question was eCTD EU Module 1 Can further clarification be provided on the related sequence element? May 2005 - referred to EU and MHLW for Answered in Q&A Answered as Question #12 generated by Specification regional guidance change request 00890 June 2005: To be covered by the EFPIA White Paper on eCTD LCM. Feb 2008 : Answered as Question #12 A013 eCTD EU Module 1 From the eCTD experience of the IWG, what parts of the Specification are Based on experience, there have been Answered in Q&A Answered as Question #13 Specification commonly misinterpreted that would prevent my eCTD message from being different interpretations of the eCTD and covered by EU viewed by another applicant/regulator? Specification that have prevented timely Validation criteria. exchange of eCTD submissions. Those creating and viewing eCTD messages should adhere to the eCTD Specifications (ICH and regional) and consult with regional authorities to avoid these problems. The items in the following list already exist in the Specification 3.2, but have been summarized here to alleviate these problems. Adherence to these items is technically necessary to exchange eCTD messages. Extra controls might hinder the exchange of eCTD messages. The IWG will continue to monitor eCTD implementation to provide additional clarity. May 2005 - referred to EU and MHLW for regional guidance June 2005: Need EU validation criteria. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting A014 Generated by ICH What is the EU regional guidance relating to the ability to cross-reference Answered in Q&A Answered as Question #14. Q&A # 37. from one sequence to files in another sequence? 0001 Andrew Marr EU DTD v1.0, Experience is showing that when a number of lifecycle documents have It may be possible to have an additional Implemented in EU Opened 19-09-2004 (EFPIA) Specification v1.0 been created it is not possible to know what each sequence is about with attribute assigned to the submission type M1 v1.1 Agreed 24-09-04 physically opening the sequence documents and reading the Cover Letter. „submission description‟. This could be either Industry is already considering requesting the vendors to provide some optional or mandatory dependent upon Dec 05: Implemented in additional description to assist in creation of the applications and we submission type. eCTD Spec v1.1 - new understand that at least the EMEA is adding a description to this Docubridge element 'submission- records. It would be logical to standardise on an additional attribute that the description' added to applicant can complete for there own records and that the agencies can envelope. make use of in their reviews.For example an applicant could use a simple description of „Excipient change‟ – against a Type II variation submission type. It this way a set of simple descriptions will be built up over time that will assist differentiation between sequence content without the necessity of opening a cover letter. 0002 Sandoz (Ron de Application Form The EAF does not allow for the form to be combined for all member states Deferred Referred to NtA with MRFG eAF Boer) during MRP subm. For a paper based subm this combined AF has been representatives. requested by some and has been accepted by all EU member state R. de Boer to split the CR agencies. This change request is made to enable the AF to be used during into those points that are MRP submissions. Some of the requests made below are suitable for none nice to have and those MRP subm as well. which are essential Generic apps - It should be possible to include reference medicinal requirements products for multiple MSs. In case of an MRP this needs to be filled in for each MS, because the reference product marketed in each MS is different. This change is relevant for MRP only. It should be possible to include multiple medicinal products used in the BE study. All submission types. Proposed dispensing/classification - It should be possible to select both “subject to medical prescription” and “not subject to medical prescription”. It should be possible to include multiple marketing authorisation holders. CP&MRP It should be possible to include multiple persons authorised for communication after authorisation. It should be possible to include multiple qualified persons for pharmacovigilance . It should be possible to include multiple persons responsible for scientific services. 0003 EFPIA (A. P. Marr) How should an applicant handle a Type I variation within and eCTD? Referred as Q&A to Notice to Applicants Group Answered in Q&A Answered as Question #5 Guidance provided in the Notice to Applicants for Type II variations states and in CTD Q&A. that they should be organised according to CTD but for Type IA/IB variations it simply states that they should be organised according to CTD, where applicable. This suggests that there will be occasions when it is not applicable to utilise a CTD structure and under those circumstances it will not be possible to use the eCTD. Clarification should be provided on how to minimise incompatibilities with the eCTD since it is impossible to construct an eCTD that is not CTD compliant EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting 0004 Fujisawa GmbH EU Module 1 envelope Notice to applicants “Volume 2A/ Procedures for marketing More understanding of eCTD LCM required for Answered in Q&A Answered as Question #6. (M. Hamzakadi) authorisationChapter 1/ Marketing Authorisation/February 2004” describes 4 resolution Refers to list of submission types of Marketing authorisation procedures (p.3-6) as follows: - Centralised types (already responded procedure - Mutual recognition procedure- Independent National procedures- Referred to Notice to Applicants Group to in CR-20070926-01). Community referrals. In comparison with this, the appendix 1: Envelope Element Description” of the EU Module 1 Specification v1.0 document do not include the “Community referrals” for the element “procedure” as valid value. The list of valid values for the “type” of procedure for the submission should be adapted i.e. a new value “community referrals” should be added if possible? 0005 EMEA (T. Buxton) eCTD EU Module 1 In the same way as the electronic application form permits information to be In fact, the acceptance of 'Other file formats Implemented in EU Dec 05: Implemented in Specification submitted using XML, so the PIM DES does the same for product in accordance with the PIM DES' should be M1 v1.2.1 eCTD Spec v1.1 - accepted information. The current EU Module 1 specification permits PDF and RTF as detailed, as this standard includes more than file formats amended. formats for product information, but not XML. For administrative information, XML (additional documents that can be Oct 06: Updated in eCTD however, XML is permitted. Suggestion : Include XML as an accepted format attached with the XML) Spec v1.2.1 - accepted file for the “labelling text” item Furthermore the specification has been formats amended updated to recognise that PIM files are submitted in archive format as ZIP or TGZ files that contain XML and other file formats. 0006 Datafarm (S. eCTD EU Module 1 The specifications do not provide folder structure requirements for UTIL Retain separate util folder for components that Implemented in EU Oct 06: Kumar) Specification folder that includes STYLE and DTD folders. The screen shots are good can be submitted outside eCTD e.g. e-AF and M1 v1.2.1 Implemented in eCTD Spec and include a STYLE folder under UTIL folder under m1/eu. See page 25 to PIM. For those regional components that are v1.2.1, cell 72, p.28 29.Please note that the STYLE folder is already present under submission always submitted as part of eCTD, use global folder under UTIL folder e.g. eu12345/0000/util/style. In the same location util folder to obviate need for regional util we have a DTD folder.This structure is clear and consistent across all folder. More testing required of PIM container regions as well as ICH folder structure specifications.EMEA should consider removing the additional util folder from eu folder under m1. All necessary files (DTD and style sheet) should be placed in their respective folders under one UTIL folder.Also, note that the relative path in the XML file should be updated for both DTD and style sheet. See Page 30 onwards.Correct path is:../../util/dtd/eu-regional.dtd../../util/style/eu-regional.xsl. Suggestion: Keep one global (for both ICH and Regional) Util folder under submission (sequence) folder. Util dtd - dtd files for ICH and regional style – stylesheet for ICH and Regional 0007 IABG (T. eCTD EU Module 1 eCTD should take into consideration the ISO standard ISO/PRF 19005-1 ( This was referred to ICH where it was Rejected None Bergsteiner) Specification PDF/A) for long-term readibility of PDF documents. concluded that PDF/A does not support the review process for eCTDs. Response issued as ICH eCTD Q&A 47. 0008 Spanish Agency eCTD EU Module 1 EU Module 1 Specification: Implemented in EU Dec 05: Implemented in of Medicines Specification Element : m1-6-1-non-gmo M1 v1.1 eCTD Spec v1.1, cell 43 (José Manuel Directory : m1/eu/16-environrisk/161-nongmo p.21 Vidal Morales) eCTD EU Backbone DTD - 1.0: Element : m1-6-1-non-gmo Directory : m1/eu/16-environrisk/161-non-gmo (without last hyphen) In the file eCTD EU Backbone DTD - 1.0 the directory must be named: m1/eu/16-environrisk/161-nongmo EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting 0009 GSK (Andrew EU DTD v1.0, The New Medicines Legislation defines a new procedure for regulatory Update the attribute values in the DTDs. Implemented in EU Dec 05: Implemented in Marr) Specification v1.0, approval in Europe, that of the Decentralised Procedure. In the current M1 v1.1 eCTD Spec v1.1 new EAF v1.0 eCTD envelope a picklist provides for the option of Centralised, Mutual attribute in envelope. Recognition or National. Decentralised needs to be added as an option. Likewise for the Electronic Application Form. These need to be in place for adoption of the new procedure in November 2005. 0010 EMEA (J. Rueda) eCTD EU Module 1 The inclusion of the PIM DES into EU Module 1 of the eCTD is planned, as An additional element “m1-3-1-pim-xxxx-y” Implemented in EU Dec 05: Implemented in Specification per the road map (DES 2.1), for December 2005. will need to be created in EU M1 for M1 v1.1 eCTD Spec v1.1 - new This means that the current DES container will need to be re-design in order accommodating the new PIM container when element in 1.3.1 to have a unique container for submitting PIM in/outside eCTD and to submitted within the eCTD minimise as much as possible changes in the current eCTD EU Module 1 specifications. To achieve this, the DES group has proposal for implementation.Currently, when PIM is submitted inside eCTD, EU M1 has two util folders, one in EU M1 level and another one at the root level. The PIM DES container has an util folder as well. The new PIM container, scheduled for DES 2.1 DEC 05 will align with EU m1 structure (in/outside eCTD). With this new container there will be a unique "util" folder in EU M1, the one already in there. Note that the eCTD specifications define the location for DTDs and style- sheets. EU M1 specifications only contain screenshots with “util\dtd” and “util\style”. Full proposal in Change Request proposal 0011 EMEA (J. Rueda) eCTD Specification eCTD requires a two way communication mechanism to allow flexibility and Referred to ICH - Out of Scope for EU. ICH Deferred Referred to ICH for next ICH M2 v3.2 system interoperability (EURS/PIM RS) for regulators for them to make PIM will consider for the scope of the next major major version of the eCTD. submissions to applicants either with or without eCTD. release (ICH Change Request #1110) To be carried forward into eCTD Next Major Version 0012 EMEA (J. Rueda) eCTD EU Module 1 The list of submission types accepted in eCTD format listed in the eCTD EMEA to prepare a list to be confirmed at the Duplicated None Specification specification should be in line with the list of submission types listed as eCTD interlinking. accepted in NtA Volume 2. Currently, the 2 lists are not consistent with one Nov 2007 - still under consideration and now another. linked to additional CRs - QA-20070906-01 & CR-20070926-01 0013 EFPIA (A. P. Marr) eCTD EU Module 1 The structure of folders given in the EU Module 1 have „Centralised‟, „Mutual‟ The folder structures should be clarified and Implemented in EU Dec 05: Implemented in Specification and „national‟ as folders between the root folder and the sequence number. the „procedure‟ folders deleted. This should M1 v1.1 eCTD Spec v1.1 This was not intended as part of the structure submitted in the eCTD. improve the clarity of the specification and Three representative folder structures are provided in the specification to hence valid submissions. represent how folders and files should be placed for each of the centralised, mutual and national procedures. The folder structure includes „centralised‟, „mutual‟ or „national‟. I do not believe that it was the intent that this folder, placed between the root directory and the sequence number was intended to be used in the submission itself. Recently, Belgium has issued guidance for e-submission and refers to the EU specification but they have been receiving examples where the applicants have interpreted that the folder should be included. This will cause problems later when eCTD are received (rather than just e-subs in folder structures‟ EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting 0014 EFPIA (A. P. Marr) eCTD EU Module 1 The newly agreed ICH Q&A #38 on referring to files submitted in previous ICH Answer :At this stage of the Answered in Q&A Answered as Question #14 Specification sequences indicates that we should refer to regional guidance with respect implementation of the eCTD, the four to allowance of cross-referral. This guidance needs to be established. Operation Attributes (new, append, replace Referred to ICH for next ICH Question: The eCTD specification supports the ability to refer to a and delete) will remain and not be added to. major version of the eCTD. previously submitted file, for example, by including in sequence 0005 a leaf With the existing specification it is technically with Operation Attribute of 'new' that refers to a file submitted in 0000. Is it possible to determine that a file is not in the possible to indicate to the reviewer that they have already received and current sequence, but is from a previous reviewed the file before? Could an additional Operation Attribute be sequence.Suppliers of eCTD viewing tools are considered for this type of cross-referenceing or re-use? encouraged to develop a visual way of displaying the difference between a leaf referring to a file in the current sequence and a leaf referring to a file in a previous sequence.In this circumstance note that the list of items to be checked under Q&A No. 36 should allow for the xlink:href to refer to files in another sequence and not prevent viewing of the eCTD by another applicant/regulator.Refer to regional guidance with respect to the allowance of reference to previously submitted files. NB. For Europe, this Guidance has been agreed and issued as Q&A #14. Recommendation to update the attribute values in the DTD at a future point 0015 PIM Core Team eCTD EU Module 1 In December 2005, a CR was requested to include PIM into the EU Module Recommended solution Implemented in EU Oct 06: Implemented in Specification 1. This CR requested the following actions: - Add TGZ as allowed file format (this format is M1 v1.2.1 eCTD Spec v1.2.1 - Creation of element “m1-3-1-pim” to link to the PIM XML file- Identify the preferred as it is more open than the ZIP “util” folder of the EU Module 1 as the appropriate location for PIM utilities format) (DTD and style-sheets) - Add ZIP as allowed file format - Amend file formats supported by the EU Module 1 to add XML as well as - Add name specification “131-pim-xxxx- the image formats (JPEG, GIF, PNG, TIF, SVG, MathML) ar.zip/tgz ” for the PIM file Today, PIM systems are under elaboration and practical experience - Keep Element “m1-3-1-pim” provided some feedback about the way PIM has been integrated into the EU - Remove description the use of EU M1 “util” Module 1. folder for PIM Following the feedback received, we believe that there is a simpler way to - Remove definition of folder “131-pim-xxxx-ar ” include PIM in EU Module1. It is more appropriate to include PIM into the EU Module 1 as a single Refer to PIM DES specifications for archive file than directly refer to the XML file. Therefore, it is proposed to: compression protocols - Add ZIP format and TGZ format as valid file formats - Remove the need to merge “util” folders for PIM and EU Module 1, as the PIM util folder will be stored within the ZIP / TGZ file - Folder “131-pim-xxxx-ar” is no longer needed because PIM will be reduced to a single file. The name of that file will be “131-pim-xxxx-ar.zip ” or “131-pim-xxxx-ar.tgz ” depending on the format used Further information included in the original change request. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting 0016 PIM Core Team eCTD EU Module 1 The link from EU Module 1 to PIM is defined in v1.1 by using the leaf entity Implemented in EU Oct 06: Implemented in Specification as defined by ICH in the context of eCTD. The leaf entity is defined by: M1 v1.2.1 eCTD Spec v1.2.1 - Leaf elements - Node extension elements (which may contain other leaf and/or node extension elements) In the context of a PIM submission, only one PIM file needs to be attached to the EU Module 1. Also, no concept of node extension is needed. Therefore, the EU M1 Specification and DTD need to be updated to define element “m1-3-1-pim ” so that it can contain only 1 leaf element Recommended Solution: Update Specifications and DTD to define element “m1-3-1-pim” containing a single leaf element 0017 Bernadette Billet eCTD EU Module 1 When providing PIM and/or the XML Electronic application form, the EU They do not have to referece. Implemented in EU Implemented in EU Module Liquent, Thomson Specification Module 1 eCTD version 1.1 specification indicates that the corresponding Check guidance is clear M1 v1.2.1 1 eCTD v1.2.1 Scientific DTDs and stylesheets should be located in the m1\eu\util directory. Should the DTDs and stylesheets also be referenced by <leaf> elements within the eu-regional.xml file, or is this unnecessary as simply serve to support the XML content of PIM and/or the application form? 0018 Alex Yates eCTD EU Module 1 Please can you inform us as to the date when the updated European Addressed by EU M1 v1.3 specification and Closed None Kendle Specification and type Module 1 specifications issued in January 2006 become mandatory for use transition plan definition in all eCTD submissions in the EU. It takes some time to update the system for generating the EU Module 1 XML and so this information would be useful. In the future, consideration should be given to adding a date for coming in to operation to the European Module 1 specifications guideline. 20060524-01 Ron de Boer If I submit sequence number 0001. What will be the operation attribute for Implemented in EU Implement in v1.3: the eu-regional.xml in the index.xml? M1 v1.3 Include a clarification in the This can not be replace, because the eu-regional.xml only contains the spec in Appendix row 2 - updated parts and a replace operation will make all previously submitted operation attribute should documents obsolete. It is also not new, because the eu-regional.xml has be 'new'. Investigate other been submitted before. Should it perhaps be append? locations where an update could be provided. 20060627-01 Geoff Williams, EU Module 1 DTD and Version 1.1 of the EU Module 1 DTD included country and language codes EU M1 is 1st priority – Lang/country codes for Implemented in EU Implemented in EU Module Roche Specification, v1.2 for the planned accession of Romania and Bulgaria. Version 1.2 of the DTD RO BU in DTD, specifications and style-sheet. M1 v1.2.1 1 eCTD v1.2.1 included several changes, including the removal of these country and Assessment of required changes to align language codes. Given the planned accession date of 1st Jan 2007, we same requirement in eAF-New eAF-Var. believe that these codes should be in place now to allow use of the eCTD EMEA Regulatory Affairs to agree to this CR. specification for submissions beginning on January 1st 2007. Reinstate the country codes into the DTD. Issue an updated specification document (or alternate form of guidance) stating that these codes are not to be used in any submission before the formal accession date of these two countries to the EU. On the accession date, issue a revision to the specification (or other guidance note) allowing the use of the country and language codes. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting 20060627-02 Bernadette Billet, EU Module 1 DTD and When migrating the product information from Word to PIM for a product Updated in guidance - Word not to be Closed None Liquent Specification, v1.2 managed by an eCTD how should the operations attributes be used? included in the eCTD in any case. Version 1.2 DTD allows either a PIM submission or the Word documents in 1.3.1, not both. For a product that has previously submitted Word PI documents these will be located under 131-spc-label-pl but with PIM it will go under 131-pim. As such it is not appropriate to use „replace‟ since replace should only be used on documents at the same location in the backbone. If „new‟ is used for PIM this will still leave the previous Word documents as being current. It is not possible to use delete either since the specification does not support entry of leafs in both 131-pim and 131-spc-label-pl in the same submission. Could guidance please be given for how to manage this transition so that the PIM information is seen as new and the old Word information is seen simultaneously as „not current‟ when a current or cumulative view is used? 20060627-03 Andrew Marr, GSK EU Module 1 DTD and When to submit Module 3 updates as part of responses to questions with an 16-12-2008 eCTD Interlinking: The module 3 Accepted - refer to Produce an NTA CTD Q&A Interlinking Specification, v1.2 eCTD documents should be handled in the same Interlinking Group detailing the guidance to way that the SPC is currently handled in eCTD submit only the final agreed Currently with a paper submission there is the possibility of submitting a - only the final agreed versions of the version of the M3 response to a question which may contain a proposal (e.g. a change to the documents should be submitted at (or just documents in the eCTD. specification) and when that is found to be acceptable by the regulators the before) the end of the procedure. The interim (This will set a precedent revised Module 3 content can be submitted. With an eCTD is it always versions should not be exchanged in the for an eCTD Q&A and any expected that the Module 3 section is updated at the time of submitting the eCTD - they should be exchanged as appropriate guidance response or can this also be delayed until it is known that the response is communications outside the eCTD. change). acceptable? March-09 : Options for Q&A have been drafted and are to be reviewed by the Interlinking Group. 20060703-01 Geoff Williams, EU Module 1 DTD and Implemented in EU Implemented in EU Module Roche Specification, v1.2 The European Commission website URL is incorrect M1 v1.2.1 1 eCTD v1.2.1 The Commission website is referenced on pages 2, 4 and 7 of Version 1.2 of the specification. The website URL is incorrect. It should be http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm 20060703-02 Geoff Williams, EU Module 1 DTD and Implemented in EU Implemented in EU Module Roche Specification, v1.2 M1 v1.2.1 1 eCTD v1.2.1 The example filenames given for two documents in the specification are incorrect as they include invalid characters (full stops). On page 26 of the specification, in the list of the Directory/File Structure for Module 1, the entries for items 67 and 69 on the list are invalid. In row 67, the file path and filename is proposed as m1/eu/18- pharmacovigilance/ 181-phvig-system/phvigsystem.VAR.EXT but it should include a hyphen rather than a full stop before the VAR variable, e.g. m1/eu/18-pharmacovigilance/ 181-phvig-system/phvigsystem-VAR.EXT Likewise, on row 69 the proposed file path and filename is m1/eu/18- pharmacovigilance/ 182-riskmgt-system/riskmgtsystem.VAR.EXT but it should include a hyphen rather than a full stop before the VAR variable, e.g. m1/eu/18-pharmacovigilance/ 182-riskmgt-system/riskmgtsystem-VAR.EXT 20060914-01 Aziz Diop, eAF DTD and style It is mandatory in the DTD to choose an option in the centralised procedure Deferred Refer to eAF project eAF AFSSAPS sheet between (mandatory scope, optional scope and Generic of a Centrally Authorised Medicinal Product). Example of a product “Aluvia film-coated tablets” 200mg of lopinavir/50mg of rotonavir A CHMP scientific opinion : Article 58 Regulation (EC) N° 726/2004 Date acceptance by WHO : 24-05-2006 QA-20061017-01 Hans van ICH eCTD specs v3.2 Nine Questions on the use of the eCTD in Module 3 of the CTD were This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see Bruggen, Appendix 6 submitted. group for consideration. It has been added ICH tracking sheet for eCTDConsultancy here for completeness and to record any details of outcome. discussion and position taken at an EU level. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting QA-20061120-01 Alastair Nixon, When submitting via the centralised procedure, changes are frequently Nov-07 Part i) Accepted for Q&A Answered in Q&A Answered as Question #15 GSK required to the dossier following validation by the EMEA. At present, the Part ii) was referred to eCTD Interlinking rapporteur and co-rapporteur have at this stage already received an initial group, they responded "It is required to submit copy of the eCTD. the application to Rap / Co-Rap at the same (i) How is the applicant advised to handle validation changes in the eCTD? time as to the EMEA. It is therefore not Should another eCTD sequence be created, incorporating the suggested possible to submit to Rap / Co-Rap only after changes, or should the original sequence be corrected? NB If an additional validation of the application." sequence were to be provided, the assessor would need to view both sequences in „current‟ view in an eCTD viewer. Further, if the original submission was not 0000, in some eCTD viewing tools, it is currently not possible to view the „current‟ content of selected sequences only – the tool will only allow the user to view the current view of all submitted sequences. (ii) What is the EMEA‟s view on provision of copies of the electronic dossier for the rapporteur and co-rapporteur? Could this be delayed until after validation, to prevent industry having to submit either updated original sequence or 2 sequences? CR-20061120-02 Shy Kumar, eCTD EU Module 1 The example submission directory structure for MRP (Appendix 3) may be Mar-07 After discussion, it was agreed that Duplicated None Datafarm specification v1.2.1 inconsistent with the accompanying statement that „common‟ is the directory the examples are correct and do not require to hold all files applicable to more than one country changing. CR-20061221-01 Kevin Wing, eCTD EU Module 1 EU Module 1 Specification v1.2.1 (and predecessors) requests that the Sep-07 Proposed for Q&A Implemented in EU Implement in v1.3: J&JPRD specification v1.2.1, variable component of filenames should be a “meaningful concatenation of M1 v1.3 Answered as Q&A #16. page 7 words without separation and should be kept as brief and descriptive as Change p.7 of the possible” but also specifies that hyphens (“-“) should not be used within specification 'file naming these variable components. The change request applied for is to allow the convention' use of hyphens within the variable component of filenames in the EU Module 1. CR-20070118-01 Harv Martens, ING eCTD EU Module 1 Examples 2 and 3 of the EU Module 1, in the context of v1.2.1, are incorrect Mar-07 Accepted to update example files Implemented in EU Implement in v1.3: America specification v1.2.1, regarding the Specifications. M1 v1.3 Change as specified examples EU M1 Specifications require PI documents (section 1.3.1) to be named as follows: CC/LL/CC-SPCDOC-VAR.EXT For instance, a French SPC in Belgium should be named, e.g.: be/fr/be-spc.doc Examples 2 and 3 name such file with the prefix set to the language instead of the country: be/fr/fr-spc.doc Examples need to be updated so that the name of the PI documents is inline with the EU M1 Specifications. CR-20070122-01 Harv Martens, ING eCTD EU Module 1 Examples 2 to 4 contain a util folder within the m1/eu folder. This folder can Mar-07 Examples to be corrected, and to Implemented in EU Implement in v1.3: America specification v1.2.1, exist to hold EU-specific files (DTDs and/or style-sheets) but in the provided include index.xml and MD5 checksum to M1 v1.3 Change the 3 examples in examples examples, this folder contains the EU Module 1 DTD files. This is incorrect reflect valid eCTD submissions. all the locations as detailed and can be misleading in the change request itself CR-20070130-01 Shy Kumar, eCTD EU Module 1 The EU Module 1 Specifications, version 1.1, provided a description of the Mar-07 No change to specification. No re- Rejected None Datafarm specification v1.2.1 field "submission-description" in the envelope, including a size limitation set instatement of max. 50 character field length. to 50 characters. Gain practical experience with no limitation. The EU Module 1 Specifications, version 1.2.1, has removed the information on the field size limitation. There is no indication whether the limitation still applies or not. Note: A similar question has been asked in the context of the eCTD on the length of the "title" element(Change Request 750). The initial answer was to limit the 1024 bytes. However during one of the last meetings (June 2006), it has been decided to remove the size limitation, and to request concise titles. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20070215-01 Ashley Birch, ICH eCTD Q&A 40 ICH eCTD Question Number 40 asks whether it is acceptable to submit PDF Rejected Discussed at ICH M2, see AstraZeneca V1.4 files across all regions. Although the answer given is in the affirmative, ICH tracking sheet for it actually goes much further than mere „acceptability‟ by appearing to make details of outcome. V1.4 mandatory for eCTDs. Shouldn‟t V1.4 be „acceptable‟ or perhaps „preferred‟ (if justified) rather than „mandatory‟? CR-20070309-01 Kevin Wing, eCTD EU Module 1 Page 39 of EU Module 1 Specification v1.2.1 suggests that the envelope Sep-07 “Common” should not be an allowable Implemented in EU Implement in v1.3: J&JPRD specification v1.2.1 element of MRP or DCP submissions could be assigned a country attribute value for the envelope. M1 v1.3 p.6 section 'Envelope' - value "common" when the same sequence is being submitted to multiple Change wording to specify the use of multiple propose text for inclusion countries. The change request applied for is to change the example to country-specific elements. here. Also change example illustrate the use of multiple repeated country-specific envelopes, instead of Write a Q&A to clarify until new version is text which illustrates this on a single envelope labeled “common”. produced p.39 See Q&A #17 20080220: See CR- 20080129-02 CR-20070316-01 N. Chandar, Take ICH Specification v3.2 Deferred Discussed at ICH M2, see ICH M2 Solutions ICH tracking sheet for The query relates to details of the Q&A document (MS Excel spreadsheet) details of outcome. under Question 12. This currently states : Q. The eCTD Specification allows for one novel excipient in 3.2.A.3. What happens if there is more than one? To be carried forward into A. The regulatory authority should be consulted for a solution until the eCTD Next Major Version change request is resolved. Change Request 00050 stated : Description :Request 3.2.A.3 to be changed to a repeating element. Comment : Understood and will address in Q&A (No. 12) and then next version of DTD. Status : Approved for specification change. Action : Specification changed to Version 3.2 Specification v3.2 just repeats the same text in dtd ( does not give an attribute list to be captured similar to m3-2-a-2). Could an attribute for „excipient‟ be introduced and/or a naming convention for file naming convention be defined. CR-20070405-01 Geoff Williams, ICH Q&A, Q&A36, ICH Q&A36, item 12 says “Ensure all the files identified by an xlink:href This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see Roche item 12 reference exist”. This should be clarified to state where the files can exist. group for consideration. It has been added ICH tracking sheet for here for completeness and to record any details of outcome. The check for item 12 is ambiguous as to where the file identified in discussion and position taken at an EU level. Addressed in EU Q&A 14 xlink:href should exist. At the time this was written, we probably meant “exist as regional guidance within the same sequence”. However, current thinking on the use and reuse of content means that content can exist in another sequence within the same application or (for the US at least) within a separate application Some testing of this was carried out in the ETICS study and the results showed that tools were not necessarily sticking to the strictest interpretation (within the same sequence). This item description should be amended to describe the current use and understanding of the xlink:href. CR-20070405-02 Geoff Williams, ICH Q&A36, Item 20 ICH Q&A36, item 20 states “Ensure that leaf or node extension Title attribute This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see ICH M2 Roche is not empty (except when the operation attribute is delete)”. It is not clear group for consideration. It has been added ICH tracking sheet for why the parenthetical condition for delete is in place. here for completeness and to record any details of outcome. discussion and position taken at an EU level. It is not clear why the ICH response should be so proscriptive about the content of the title attribute when the leaf is to be deleted. There is value in having a title attribute even for leaf elements that will be deleted, so that the view of a single sequence has information to aid the user. I propose that the condition is removed so that this reads “Ensure that leaf or node extension Title attribute is not empty” EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20070405-03 Geoff Williams, ICH DTD, v3.2 This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see ICH M2 Roche The approved Change Request 00050 says that the element for Module group for consideration. It has been added ICH tracking sheet for 3.2.A.3 will be made a repeating attribute in Version 3.2 of the specification. here for completeness and to record any details of outcome. This does not appear to have been done. discussion and position taken at an EU level. To be carried forward into The change request says that the element for Module 3.2.A.3 (Novel eCTD Next Major Version Excipient) will be made a repeating element. This means to me that it should be able to appear 0, 1 or more times in the structure. The cardinality should be denoted with a * in the element description. However, version 3.2 is as follows: <!ELEMENT m3-2-a-appendices (leaf* , m3-2-a-1-facilities-and-equipment* , m3-2-a-2-adventitiousagents-safety-evaluation* , m3-2-a-3-excipients?)> As you can see, the cardinality is indicated by a ? and this means that the element can appear 0 or 1 times only. This change needs to be implemented in v3.3.1 to allow further change requests about this element to be considered. CR-20070408-01 Dirk Beth, Mission ICH DTD, v3.2 Mission3 submits this change request with the suggestion of migrating the This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see ICH M2 3 narrative content of submissions from PDF to XML. An XML model that fits group for consideration. It has been added ICH tracking sheet for the needs of this industry will yield significant benefits to both sponsors and here for completeness and to record any details of outcome. regulatory reviewers. discussion and position taken at an EU level. Part of Workplan for ICH M2 SENTRI group to consider CR-20070426-01 Joe Cipollina, BMS ich-stf-stylesheet-2- The ICH STF Stylesheet currently posted gives inconsistent display results This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see 2.xsl in Internet Explorer. It seems to work in some cases but not in others. STF group for consideration. It has been added ICH tracking sheet for files which were viewable with the older version of the stylesheet are no here for completeness and to record any details of outcome. longer always viewable. discussion and position taken at an EU level. CR-20070426-02 Joe Cipollina, BMS Valid-values.xml There are differences in the values listed in the valid-values file posted on This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see the ESTRI website and the valid-values file posted on the FDA website. group for consideration. It has been added ICH tracking sheet for here for completeness and to record any details of outcome. discussion and position taken at an EU level. QA-20070627-01 Alastair Nixon, One principle of the eCTD is that content that is not required for the dossier Nov-07 Q&A wording proposed Implemented in EU Implement in v1.3: GSK is not provided, and there is no need for the applicant to provide „not M1 v1.3 Answered asQ&A #18. applicable‟ pages. However, we have experienced occasions where we Change text on p.6 to receive questions after EMEA content validation with respect to sections that include text from Q&A 18. are missing in the eCTD, but where no justification has been provided. Add a statement to indicate Is it necessary to include statements in the CTD/eCTD justifying the absence that further information of data? If so, where should these statements be placed in the CTD national guidance should structure? be referred to. Further information included in the original change request CR-20070627-01 Alastair Nixon, eCTD EU Module 1 Error in Appendix 2, suggesting that applicant uses the 10-cover section for Sep-07 Accepted for next release of Implemented in EU Implement in v1.3: GSK specification v1.2.1 response to questions specification M1 v1.3 Remove reference in row 5, appendix 2, p.13 QA-20070628-01 Thierry Le Ridant, eCTD EU Module 1 During a sequence 0026, we must modified SPC of the 0020 sequence and Nov-07 Both proposals are considered Answered in Q&A Answered as Q&A #12 Ethypharm specification v1.2.1 leaflet of the 0022 sequence. incorrect. A Q&A has been drafted to clarify What should be the value of the <related-sequence> in the <envelope>? use of related-sequence attribute The last sequence modified (0022) or it should be blank? See also CR A012 See Question 12 QA-20070628-02 Thierry Le Ridant, eCTD EU Module 1 Is it possible to have a list of value for the <agency-name> in order to Nov-07 EMEA has referred to EUTCT group Implemented in EU Implement in v1.3 if values Ethypharm specification v1.2.1 standardised the value of this element. to define list M1 v1.3 list exists: 20080220: List to be implemented in EUTCT - to come from ECD QA-20070628-03 Thierry Le Ridant, For an association of two active substance (eg Paracetamol / Sep-07 Requested to be withdrawn and Withdrawn None Ethypharm dextroproxifen), what is the best practice : duplicate <atc> and <inn> resubmitted as a CR (subsequently submitted element ? as CR-20070718-01) EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting QA-20070628-04 Thierry Le Ridant, eCTD EU Module 1 DCP or MRP are followed by a national phase (PIL etc.). What should be Response provided in Best Practice guide for Closed None Ethypharm specification v1.2.1 the value of the "procedure type" field "national" or "MRP" ? use of eCTD in MRP/DCP published by CMD(h). CR-20070628-01 Thierry Le Ridant, EU Module 1 Data from the envelope is displayed in blue but they are not hyperlinks. The Sep-07 Analysis undertaken of all EU Implemented in EU Implement in v1.3: Ethypharm stylesheet use of blue text should be limited to hyperlinks stylesheets shows inconsistency. Change M1 v1.3 Stylesheet to be updated to request accepted and will be implemented in include all black text. next updates of each stylesheet CR-20070711-01 Alban Dhanani, eAF-New v2.1 The current Application Form for New applications is not well designed in Deferred Refer to eAF project eAF AFSSAPS terms of reporting of CMS involved in subsequent waves in the case of a repeat use in the decentralised procedure. The impact on the current eAF- New is even bigger since it is not possible to identify CMS for different waves (wave number element missing) and a change to the dtd is needed to make it possible. CR-20070714-01 Kevin Wing, eAF New specification The specification for the eAF-new does not specify the use of relative Sep-07 Accepted for next release of eAF- Deferred Refer to eAF project - eAF eCTDConsultancy filepaths for the xlink:href attribute value New specification Accepted for next minor update of eAF CR-20070718-01 Thierry Le Ridant, eCTD EU Module 1 In the Envelope, in the case of an association of 2 active substances, there Nov-07 Was referred to eCTD Interlinking Rejected None Ethypharm specification v1.2.1 is no link between the <inn> element and the <atc> element. We suggest to Group "No changes required – Because there regroup them into an <active> element which will permit to identify the link is no one to one relationship between between atc and inn. substance and atc codes. The codes relate to the indication of the product." Subsequent research shows this may not be correct. June 2008: eCTD Interlinking: ATC code left in EU M1 v1.3 Dec 08: Interlinking Group - there is definitely no link between the substance and the atc.Consideration of whether to remove the atc from the eCTD envelope, in anticipation of the eAF which will enable use of structured meta-data on the submission (including the atc if necessary). March-09 : Close this change request. Open new change request for deletion of ATC code from EU Module 1 specification. Ensure that requirements for ATC code use are defined and progressed within eAF project. QA-20070813-01 Phyllis Thomas, In Europe (and with the current ICH M2 eCTD specification), does the Aug-07 Requested to be withdrawn due to an Withdrawn None AstraZeneca applicant need to update attributes in the eCTD backbone during the life an error. To be resubmitted after correction of application? error. (Resubmitted as Q&A-20070816-01) Further detail included in original question. CR-20070814-01 Ann Verhoye, ICH CR 1550 Request to re-open change request 1550: this change request is closed Sep-07 Examples in two provided annexes Rejected None FAMHP, Belgium mentioning that all filenames in module 2.3 and 3 will be mentioned in italics: were reviewed. No consensus on proposal this means that no filename check is possible, and no standard for filenames Rejected could be introduced. FAMHP, has made a proposal in order to foresee the possibility for multiple documents to be submitted within module 3, so to allow granularity, and to keep filename standards as well, therefore, the FAMHP requests to reopen this CR and to have a look at the FAMHP granularity proposal in order to foresee variable parts in the filenames and to maintain fixed components as a standard. First reactions form the national IT workgroup in Belgium were very positive. QA-20070816-01 Phyllis Thomas, In Europe (and with the current ICH M2 eCTD specification), does the Sep-07 Question to be referred to ICH M2 Answered in Q&A Answered as Question #19 AstraZeneca applicant need to update attributes in the eCTD backbone during the life an Q&A. Refer to ICH Q&A application? An EU Q&A to be prepared in the interim Further detail included in original question. period EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20070816-01 Kevin Wing, eAF-New v2.1 The specification for the eAF-new does not enable multiple meeting dates to Sep-07 Accepted for next update to the Deferred Refer to eAF project - eAF eCTDConsultancy be included for provision of CHMP scientific advice (section 3.1) or for specification Accepted for next minor Member State scientific recommendations (section 3.2) update of eAF QA-20070906-01 Hans van eCTD EU Module 1 Could the TIGes clarify what <Submission> “type” attribute value should be Nov-07 Review required across other Implemented in EU Implement in v1.3: Bruggen, specification v1.2.1 selected for the following types of submission: specifications. See also CR-20070926-01 M1 v1.3 Propose revised list. See eCTDConsultancy 1. Annual Reassessment CR-20070926-0 - ensure B.V. 2. Duplex registration these values are in the 3. Line Extension revised list. Also include community referrals. CR-20070906-01 Reinko Abels, eCTD EU Module 1 The current EU Module 1 specification does not specify that content files in Nov-07 Accepted with proposed change to Implemented in EU Implement in v1.3: Qdossier B.V. specification v1.2.1 the ICH section can be pointed to by eCTD leaf elements in the eu- wording to page 6 of the specification. M1 v1.3 Include a short additional regional.xml file See also CR-20070927-01 section on p.6 under 'General Architecture'. Wording to clarify that content filesin the ICH section can be pointed to from regional leaf elements (see CR-20070927-01) See Q&A #21 CR-20070912-01 Jose Manuel eAF-New v2.1 Orphan medicinal product information (section 1.2) applies to all types of Deferred Referred to eAF project for eAF Simarro, AEMPS, procedures not only for centralised ones. resolution Spain CR-20070926-01 Juan Rueda eCTD EU Module 1 Update Specifications re list of procedure types Nov-07 Review required across other Implemented in EU Implement in v1.3: Montes, EMEA specification v1.2.1 specifications. See also QA-20070906-01 M1 v1.3 List should be finalised: Propose final list for agreement by NtA Interlinking/TIGes CR-20070927-01 Ulrika Lantz, eCTD EU Module 1 Many post-approval submission types require a copy of an already approved Nov-07 The eCTD specification already Implemented in EU Implement in v1.3: AstraZeneca specification v1.2.1 specification to be submitted. The basis for eCTD is to submit documents defines how to reference content from more M1 v1.3 Include a short additional and Guidance on Type only once, but to be able to fulfil the European variation guidelines all than one leaf location. Some clarity might be section on p.6 under 1A and 1B variations required documents would need to be submitted. This change request gives added to specification. 'General Architecture'. a suggestion on how this could be handled in eCTD. See also CR 20070906-01 Wording to clarify that Further information included in the original change request. content filesin the ICH section can be pointed to from regional leaf elements (see CR-20070906-01) See Q&A #21 CR-20070928-01 Leo van de Notice to Applicants The ASMF guidelines state that the manufacturer and the applicant should Nov-07 This issue is referrd to the NtA Q&A Deferred Subgroup of Interlinking Interlinking Winkel, N.V. vol 2B both submit an identical Applicant‟s Part (AP) of the EDMF. on handling of ASMF group to be established to Organon Guidelines for eCTD files indicate that the AP should be included in Section March-09 : Subgroup of Interlinking group to produce guidance for ASMF 3.2.S of the eCTD. be established to produce guidance for ASMF Section 3.2.S does not allow the AP to be included as one document; the AP should be separated in parts reflecting the CTD structure and the general parts of the AP can not be included in 3.2.S. Conclusion: if the AP of the EDMF is included in part 3.2.S than it is not identical anymore to the AP submitted by the ASMF. Further information included in the original change request CR-20071001-01 Deanna Murden, How should sponsors manage summary documents in Module 2 over the Nov-07 Referred to ad hoc group for Deferred Referred to Harmonisation Harmonisation i3Logic lifecycle of an application? discussion and position Tasforce EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20071002-01 Juan Rueda eCTD EU Module 1 Should eCTD Module 1 section "additional data" be empty for EMEA Feb 08: Specify in EU M1 v1.3 that this Implemented in EU Answered as Question 20 Montes, EMEA specification v1.2.1 centralised procedures? section can be used for CP in a transition M1 v1.3 Refer to CTD Guidance #4 period for submitting documents as part of a on use of the additional new M1 structure before the latest DTD data section (i.e. it should version is implemented (e.g. paediatrics data). not be used for CP) - amend therefore line 68 of the table in appendix 2 CR-20071003-01 Alastair Nixon, eCTD EU Module 1 Supporting data for variations that is not provided in m3 is currently either Nov-07 An EU CTD Q&A (4c) already exists Implemented in EU Implemented Appendix 2 GSK specification v1.2.1 provided with the cover letter (p13 of EU M1 Specification v121), or as an about the placement of additional documents M1 v1.3 row 72. annex to the form (p14). It is proposed that all supporting data is provided in in Variations. Accepted to update EU M1 the same location, as an annex to the form. In addition, it is proposed that a eCTD specification in line with CTD Q&A table of suggested names is added to the specification, such that these response. documents are provided in a consistent manner. Further information included in the original change request CR-20071009-01 Hans van eCTD EU Module 1 Guidance is needed on how to maintain the lifecycle of Section 1.6 Nov-07 Referred to ad hoc group for Deferred Referred to Harmonisation Harmonisation Bruggen, specification v1.2.1 Environmental risk Assessments, using the operations new, append replace discussion and position Tasforce eCTDConsultancy and/or delete. B.V. Further information included in the original change request QA-20071022-01 Alastair Nixon, In the eCTD, how should an applicant handle multiple variations that occur Nov-07 Best Practice guide written for review Accepted - refer to Present guidance for Interlinking GSK in parallel and affect the same document? and approval Interlinking Group consideration by Interlinking March-09 : Subgroup to be established to address all issues of variation, in the context of the new Variations Regulations. This CR will be addressed within this group. CR-20080129-01 Geoff Williams, EU M1 stylesheet The current stylesheet displays the full structure of the Module 1, whether Rejected None Roche the displayed sections have content or not. This is a little confusing as it gives the impression of much more information than is really present. In addition, some sections are mutually exclusive and others only apply for particular procedure types. The display of the complete structure is not consistent with the behaviour of the ICH stylesheet, which only displays sections that have content. Proposal: Change the stylesheet so that it only displays sections that have content. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080129-02 Geoff Williams, EU Module 1 DTD, eu- A previously submitted CR (20070309-01) proposed the prohibition against Feb 08: New change request to be submitted Withdrawn None Roche envelope.mod and the use of “common” as an acceptable country identifier in the EU Module 1 by EFPIA proposing a 'softened' approach Specification, v1.2.1 envelope. This CR seeks to clarify the use, or otherwise, of the country where the country identifier 'common' can be identifier “ common” for content files in the EU Module 1. used in certain circumstances. Currently, no clear guidance exists about the correct use of the country identifier “common” when creating an EU Module 1 eCTD, particularly in relation to the application of this country identifier to content files. This has led to an inconsistency in usage of the value for the country attribute. A country identifier is used for content included in sections of Module 1 that can contain country specific content. The original intent of the “common” country value was to provide some means of identifying content that was used submitted in a section that can contain country specific information but, in this particular submission, is reused by several countries. Propsal:The submitter of this CR proposes completely removing the country identifier “common” from the list of acceptable country identifier values. Specific guidance should be included about to how to manage content that is used in more than one country. CR-20080129-03 Geoff Williams, eCTD Specification ICH eCTD Q&A 46 states “all regions have agreed to accept PDF 1.4. Feb 08: New proposal with simpler wording to Implemented in EU Implemented on Page 5 Roche v1.2.1 Please consult regional guidance to submit other versions of PDF.”. come from EFPIA, clarifying further the use of M1 v1.3 Clarification is required about the acceptability of versions of PDF other than PDF versions. PDF 1.4 in the EU region. N.B. EU Validation Criteria specify v1.4 (but warning only). It is noted that the planned EU eCTD Validation Criteria will include a statement that all files should be PDF 1.4. All PDF files included in the eCTD should be v1.4 except where there is an agency specific However, it is also noted that some specific EU NCAs require the use of requirement for a later version eg. for an Acrobat Forms and other documents created in later versions of PDF and application form. that do not function as needed if created in a lower version of PDF. Specific attention is drawn to the MHRA Application Forms that require Acrobat 7.1 (PDF 1.6) and the EMEA Paediatric Implementation Plan Application Forms that require Acrobat 8 (PDF 1.7). Proposal: Adoption of the following statement in the EU Module 1 Specification document. PDF files submitted as part of an eCTD must be at least version PDF 1.4. Earlier versions of PDF must be converted to at least PDF 1.4. Files created with later versions of PDF may be submitted as part of a European eCTD. CR-20080218 Andrew Marr, GSK The Best Practice for eCTD in MRP/DCP (draft v0.4) includes as To be included in eCTD v1.3 2008 Implemented in EU Implemented in Appendix 2 requirement to provide a table as a file under 1.0 Cover Letter that keeps M1 v1.3 Line 4 track of the sequences, when and when they have been submitted. This will Format and layout of the table to be defined allow each NCA to know that any „missing‟ sequences are not relevant to by eCTD Interlinking Group. them and hence have not been submitted. The example tables in the guidance have been developed in Word and would be expected to be submitted as a PDF. However, when an earlier version of the guidance was provided to vendors for comment, several made a request that this table is able to be supplied as an xml file as this would allow it to be generated automatically by the building tools. Production of a word-processed file would be inefficient. CR-20080303 Claire Holmes, EU M1 Specification The proposed new EU M1 CTD Guidance from NtA includes a new section Implemented in EU Included in DTD and EMEA v1.2.1 1.10 Information relating to Paediatrics. The eCTD specification should be M1 v1.3 througout the document updated in line with the new CTD structure. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080415 Ms Nadine EU Module 1 As a manufacturer for plasma products, CSL have a centrally authorised Refer to eCTD Interlinking Group to write Accepted - refer to EMEA to draft guidance Interlinking Schwarz specification, Plasma Master File (PMF). Following the centralised authorisation of the interim guidance on which submission type to eCTD Interlinking CSL Behring AG Appendix 1 "Envelope PMF the PMF 2nd Step Procedure must be performed. In this 2nd Step use. Group Element Description", Procedure, the PMF certificate must be submitted for each product in order March-09 : Draft guidance is under therein element = to make the link between PMF and the product's marketing authorisation. development by EMEA, taking into account submission and According to the "Guideline on Plasma Master File (PMF) And Vaccine the new regulations, and will be circulated to attribute = type (p. 10) Antigen Master File (VAMF) “Second Step”" this is NOT a variation the Interlinking group for endorsement submission. If this is done for an existing eCTD, there is no adequate submission type defined in the Module 1 Specification to describe this submission. Recommendation: Define an additional valid submission type for a PMF 2nd Step Submission, such as "pmf-2nd-step". CR-20080514 Kevin Wing, EU Module 1 The example provided for the application number element description on Refer to eCTD Interlinking Group for Open Complete the survey for TIGes eCTDConsultancy Specification v1.2.1 page 9 of the guidance is in the format of an EMEA Marketing Authorisation discussion and drafting of Q&A on what is MS on requirements for Number i.e. EU/1/00/150/001 and not an EMEA Procedure Number such as expected in that field. Draft survey for MS on application/procedure EMEA/H/C/XXX/X/XX. requirements for application/procedure number, and use of this number, and use of this element. element. Once results have The accompanying description that this is the “number assigned to the been gathered, produce a application by the receiving agency” suggests that what is meant here is the new change request as procedure number, and not the marketing authorization number (which appropriate requesting a would only be assigned upon approval and would also be strength-specific). change to the way This is supported by the explanation provided on page 14 of the EMEA‟s application numbers are recently released Q&A on eCTD Implementation (7th February 2008). captured in the envelope. Change the example for the application number element from: Based on the technical EU/1/00/150/001 guidance given in the new to eCTD specification, EMEA/H/C/XXX/X/XX. produce associated And add a clarification to the description that the number required for this business guidance on how value is the procedure number. each application number element is to be used. (KM to complete survey and submit CR as appropriate in collaboration with industry) Produce interim guidance relating to current EU M1 specification and the use of application numbers, before such time as a new EU M! version is available. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080514-01 Anne Mieke EU Module 1 Since this information is mandatory in the cover letter, variation and renewal Refer to eCTD Interlinking Group for Open Complete the survey for TIGes Reijnders, Specification v1.2.1 application form and is useful for retrieving information from the eCTD discussion and drafting of Q&A on what is MS on requirements for eCTDConsultancy lifecycle it would be beneficial to add the Marketing Authorization Numbers expected in that field. Draft survey for MS on application/procedure to the EU M1 envelope information requirements for application/procedure number, and use of this number, and use of this element. element. Once results have been gathered, produce a new change request as appropriate requesting a change to the way application numbers are captured in the envelope. Based on the technical guidance given in the new eCTD specification, produce associated business guidance on how each application number element is to be used. (KM to complete survey and submit CR as appropriate in collaboration with industry) Produce interim guidance relating to current EU M1 specification and the use of application numbers, before such time as a new EU M! version is available. CR-20080514-02 Kevin Wing, EU Module 1 The EU Module 1.2.1 specification only includes instructions relating to 1.3.1 TIGes 6 March 09 : Progress revised Q&A that Open CR originator to draft a TIGes eCTDConsultancy Specification v1.2.1 SPC, Labelling and Package Leaflet identifiers and Language/Country incorporates 'refer to regional guidance' for proposal for the Codes in the context of document filenames/folder paths. This information is ICH Q&A 57 relating to the use of xml:lang information, to be included also required as XML metadata and this change request is to update the in the next version of the specification to clarify this requirement. specification. CR-20080514-03 Anne Mieke EU Module 1 Since sequence numbers do not have to be used in sequential order it The Cover Letter and tracking table if Rejected None Reijnders, Specification v1.2.1 would be beneficial to add the submission date back into the EU M1 appropriate should be used to track the date - eCTDConsultancy envelope information. it is not useful ot have it in the envelope. CR-20080610 Andrew Marr, GSK EU eCTD Validation EU validation criterion #37 defines that no file should have been scanned at Implemented in EU Implemented in EU Criteria a dpi of more than 300. The ETICS testing demonstrated that it does not validation criteria v2.0 validation criteria v2.0 appear possible to assess a pdf file and determine what the scan resolution used to produce the file actually was. It is proposed that this criterion is deleted. CR-20080610-01 Andrew Marr, GSK EU eCTD Validation EU validation criterion #45 refers to EU Q&A as its reference. This is Check all references Implemented in EU Implemented in EU Criteria incorrect as it is ICH Q&A 36 - change reference. validation criteria v2.0 validation criteria v2.0 CR-20080610-02 Andrew Marr, GSK EU eCTD Validation There is an inconsistency between EU validation Criterion #11 and #18 Change criterion #18 to indicate that the title Implemented in EU Implemented in EU Criteria relating to the title field when the delete operation is used. #11 states „Every should be included when delete is used, but validation criteria v2.0 validation criteria v2.0 leaf or node extension 'title' attribute is not empty‟. #18 states „If the value of included a statement to indicate that this is not the operation attribute is delete,……title is not required…..Consistency consistent with the ICH criterion #20. should be introduced. Create an ICH CR to indicate that ICH criterion Additionally the wording of #11 could be improved to state “No leaf or node #20 should refer to regional guidance. extension 'title' attribute is empty” Even if this is changed then there is still inconsistency. Either – agree that the title should be included when delete is used – change #18 but this would require a change to ICH Q&A36 #20 Or – agree that title remains optional and therefore modify #11 to provide an exception when the delete is used. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080514-04 Kevin Wing, EU Module 1 The concept of the Regulatory Activity was introduced within the EU 3 years Refer to guidance on use of related sequence, Accepted - refer to Refer to Q&A Interlinking eCTDConsultancy Specification v1.2.1 ago and has been presented/discussed at conferences, implemented by which has been improved and is robust with Q&A some vendors and is included as a term in the EMEA‟s Q&A Relating to EU M1 v1.3. Practical and Technical Aspects eCTD Submission (7th February 2008). EMEA Q&A guidance should be amended to refer to EU guidance on use ofrelated The “Example of the use of the Related Sequence” section on page 11 of sequence, but to indicate that application the EU M1 eCTD guidance describes use of the related sequence element number is used in addition. Dependency on to groups eCTD sequences into 3 Regulatory Activities (an MAA, a technical CR-20080514 and the drafting of guidance for variation and a labelling change variation). use of and requirements for application numbers by all agencies. In the afore-mentioned EMEA Q&A document, it is the Application Number March-09 : Confirmed as pending, awaiting (procedure number) that is described as the “envelope element which is TIGes action on use of Application/Procedure used to group together submissions relating to a particular regulatory Numbers activity”. Could the TIGes provide feedback/guidance on whether the Application Number or Related Sequence is the element used to group sequences together within a Regulatory Activity. If the Related Sequence is not used for grouping together Regulatory Activities, could the TIGes comment on what value this element is adding to the EU specification? CR-20080514-05 Anne Mieke EU Module 1 The application number element description on page 9 of the guidance See CR-20080514-04 -guidance to be Open Complete the survey for TIGes Reijnders, Specification v1.2.1 states that this is the “number assigned to the application by the receiving produced. MS on requirements for eCTDConsultancy agency”. Given the explanation provided on page 14 of the EMEA‟s recently application/procedure released Q&A on eCTD Implementation (7th February 2008) we presume number, and use of this that for Centralised Submissions, the EMEA procedure number is meant element. Once results have here (see accompanying change request). been gathered, produce a new change request as In DCP, MRP and especially National Procedures already several numbers appropriate requesting a are used to identify a submission. To avoid misunderstanding clear change to the way definitions and guidance of what number to use where is needed. application numbers are captured in the envelope. For instance in The Netherlands for a MRP submission the MRP procedure Based on the technical number and a case number has to be used (and of course the MA number). guidance given in the new eCTD specification, Could the TIGes provide feedback/guidance on the definition of the produce associated Application Number element for MRP, DCP and National Procedures. business guidance on how each application number element is to be used. (KM to complete survey and submit CR as appropriate in collaboration with industry) Produce interim guidance relating to current EU M1 specification and the use of application numbers, before such time as a new EU M! version is available. CR-20080627 NMs Nadine EU M1 Specification As a manufacturer for plasma products, CSL have eCTDs for products Article 61(3) exists as a submission type in the Rejected Schwarz, CSL v1.3 which are registered under the Central Procedure and the Mutual EU M1 specification v1.3 Behring AG Recognition Procedure. For either procedure, the CMD(h) STANDARD OPERATING PROCEDURE PROCEDURE FOR ARTICLE 61(3) CHANGES TO PATIENT INFORMATION (Rev. 1, July 2007) is applicable. By this procedure, administrative changes to the product information, such as corrections of typographical errors, may be notified to EMEA or RMS instead of submitting a variation. If this is done for an existing eCTD, there is no adequate submission type defined in the Module 1 Specification to describe this submission. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080703 Andrew Marr EU M1 Specification The list of submission types included in the eCTD Module 1specification As part of the creation of EU Module 1, v1.3 Accepted - refer to Produce Q&A and update Interlinking (EFPIA) v1.3 v1.3 does not include Repeat Use Procedure. What submission type should and in conjunction with the development of the Q&A and include in Best Practice Guidance be used for this submission? eCTD in MRP/DCP Best Practice document updated Best consideration was given to the creation of Practice Guidance „Repeat Use Procedure‟ as a specific submission type. After deliberation, this was not accepted. However, the Best Practice Guide did not include any recommendation for which submission type should be used. In discussion at the eCTD Interlinking Group it was proposed that „Initial MAA‟ should be used and that a Q&A should be prepared to this effect. The submission type that should be used is „initial-maa‟ since this is the initiation for the new Concerned Member States. The submission description should be „Repeat Use Procedure‟. March-09 : Interlinking agreed that as an interim, a Q&A would be produced and in the CR-20080703-01 Andrew Marr EU M1 Specification The list of submission types included in the eCTD Module 1specification As part the development of the eCTD in Accepted - refer to Produce Q&A Interlinking (EFPIA) v1.3 v1.3 does not include a specific submission type for a change of the MRP/DCP Best Practice document it was Q&A Reference Member State in MRP. What submission type should be used for agreed that „Change of RMS‟ would utilise an this submission? existing submission type and that a Q&A should be prepared to this effect. The submission type that should be used is „supplemental-information‟ and the submission description should be „Change of Reference Member State‟ March-09 : CMD(h) reviewing guidance on change of RMS. Q&A to be produced to explain how change should relate to eCTD. CR-20080806 Remco Munnick, EU M1 Specification In the text of page 16, under nr 4 it mentions: 'Note that the tracking table Include the common folder in the examples for Accepted Implement in next version Interlinking Sandoz v1.3 required with MPR/DCP submissions should be located within a 'common' MRP on page 37 of EU M1 specification. directory, with the filename 'tracking.pdf' or 'tracking.xml‟. Include the tracking table in the example for Also update the example However when you look to the examples for MRP and DCP, the tracking MRP and DCP on page 45. XML on p.45 table is not included in the folder m1/eu/10-cover/common. March-09 : Confirmed by Interlinking Also in the screenshot on page 37, there should be a common folder under m1/eu/10-cover, which is missing. CR-20080903 Alastair Nixon, EU M1 Specification Copy requirements for eCTDs should be different from other electronic Electronic copy requirements for Type IA and Implemented in new Dossier requirements GSK v1.3 dossiers – all CHMP members should get an electronic copy of everything, IB variations are split by NeeS and eCTD. For dossier requirements updated April 2009 including Type IA/IB variations – otherwise future lifecycle operators will be NeeS, they stay as they are. For eCTD, the invalid. requirements for Type IA and IB variations The current copy requirements do not differentiate between eCTD and mirror those for Type II – i.e. “Other CHMP NeeS. For Type IA and IB variations, only the Rapporteur requires 2 members: 1 electronic copy”. electronic copies, other CHMP members get nothing. However, a Type IA variation can amend a significant piece of content in the dossier. For example, a Category 12a variation to tighten a specification will modify S4.1. A future Type II variation could result in a replacement active specification being submitted, but the if the original change had not been uploaded by an agency, the modified file in the second change will be invalid. In addition, any countries not uploading all sequences will get an incorrect „current view‟ for the application. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080903-01 Alastair Nixon, MRP/DCP Best The requirement for a cover letter in local language means that applicants For submissions not requiring an application Implemented March 2009 CMD(h) press GSK Practice Guidance preferring to centralise electronic dossier production, or following the form, a single „common‟ English language release included statement preferred „Comprehensive model‟ for eCTD in MRP/DCP must get a cover cover letter is acceptable in all MS. letter translated into all European languages before building the dossier. Identified as a hurdle for eCTD For submissions requiring an application form, this is unavoidable, since the implementation. Cover letter is not covered by form contains details of the MAH, and local contacts etc. However, for follow legislation, but nevertheless some MS have up measures, or simple administrative submissions, the requirement to get a requirements for local laguage versions. HMA cover letter translated up to 23 times is onerous and does not add value to to try to persuade individual agencies to relax the dossier (NB the rest of the content is likely to be in English). Could a requirements for a cover letter in the local „common‟ English language cover letter be used for such submissions? language. This should not be a requirement - one cover letter in EN should be accepted by all MS. ACTION: Applicants to inform Interlinknig group of any MS asking for local language cover letters, and the group will try to dissuade these MS. Also indicate if these MS have local letter templates or are asking for the general cover letter to be translated. Also include information as to whether the MS ask for this cover letter to be in the eCTD. March-09 : Updated national requirements table should address but press release will indicate that there should be no additional national requirements. Consideration to be given to identification of point of contact is NCAs request/require additional national specifics. CR-20080909 Leigh Sandwell, eCTD Guidance Current guidance requires that statements justifying absence of data in the Recommend that empty Module 1 Sections do Implemented in Agreed wording include in Pfizer eCTD should be provided in the QOS, non-clinical and clinical overviews, as not require a justification statement to be Harmonised Guidance Harmonised eCTD applicable, and that no placeholder documents are required in the eCTD included in each section and the Q&A Guidance v1.0 structure. The guidance should be updated to clarify how to deal with empty document is updated to reflect Module 1. sections of Module 1 and any potential justification that may be required. Approach to M1 is different than for other modules, as M1 should always be populated (even with 'not applicable' statements) as a legal requirement. Another proposal is that only justifications should be required - simple statements of not applicable should be included in the cover letter. Revisit this discussion as currently no agreement. March-09 : Principle that empty sections where no justification for absence is required should be listed in the Cover Letter. Proposal to provide statement in Harmonised eCTD Guidance. Wording to be confirmed by Interlinking Group. April -09 : decision modified and agreed statement included in Harmonised guidance - Section 3.2.1 EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20080909-01 Dietmar Boecker, eCTD Guidance Guidelines on the submission of the EU-RMP require a stand-alone format Accepted Refer to EMEA eCTD EMEA Bayer Schering of the document including all annexes to be located in eCTD Module 1.8.2. Business Team for This is in contradiction to the ICH eCTD requirements, that mandates a discussion and different location for most of the annexes. confirmation, and amend In section 4.4 of the EU-RMP guideline EMEA/CHMP/96268/2005 it is all guidance documents as outlined that the EU-RMP "should be provided (...) in a stand-alone format appropriate. allowing circulation to, and evaluation by pharmacovigilance and risk management experts". The same requirement is defined by the Pre- Submission guide in response to question 36. The template for the EU-RMP (EMEA/192632/2006) lists 8 Annexes, which should be provided in eCTD Module 1.8.2 together with the main body of the RMP. However, some of the annexes like the current SPC have already well defined locations in other Modules of the eCTD. For the location of the EU-RMP annexes it is proposed to update the guidelines mentioned above, so that applicants should cross refer from the EU-RMP to other locations of the eCTD where appropriate. With the exception of the annex 1, all annexes would be affected: CR-20081023 Remco Munnik, EU Module 1 Discrepancy in guidance on where to store additional documentation for The CTD Q&A 4c is correct and should be Accepted - refer to Review content of Renewal Interlinking Sandoz (EGA) Specification v1.3 variations that do not have a place in CTD structure. No guidance for observed - Where documents cannot be Q&A Guidance renewals is available. assigned to specific CTD-defined locations then they should be included in 1.2 Application Form. These might include declarations, certificates, justifications etc. Where possible, they should be organised according to the Annexes for the Application Form for new products (Annexes 1 to 22). Where documents cannot be assigned to one of the annexes then it is appropriate to place them after the annexes. The „Additional Data‟ section of Module 1 should not be used except for country-specific information. The EU M1 specification should therefore be amended in the next version to reflect this, and a Q&A is required to confirm this, and also to confirm that the same approach should be taken for renewals. March-09 : Interlinking to confirm that referral to Renewal Guidance is sufficient CR-20081008 Andrew Marr, eCTD specification The guidance just issued by QRD regarding production by the applicant of Dec 08: EMEA meeting held to discuss issue - Accepted File naming convention EMEA GSK (EFPIA) v3.2 the PDF for final labelling is incompatible with the eCTD and will lead to conclusion that requirements for EMEA PDFs agreed. Publication in User duplication of effort. arise from the EMEA EPAR publication guide on how to generate In the longer term EMEA must align their requirements and if there is process, and eCTD filenaming requirements PDF versions of Product business logic for the filename as per the EPAR proposed name then an EU have a different purpose and support a Information' and 'Questions specification change may be justified with the inclusion an appropriate different proess (review) and therefore and answers relating to filename that meets ICH general filename requirements. requirements cannot be aligned until Q3 2009 practical and technical when the EMEA publication process is re- aspects of the In the short-term there is an urgent need for clarification as to how an designed. This conclusion was not redily implementation' to be applicant can submit product information inside and outside the eCTD, for all accepted by industry - either alignment must updated submission types without duplication of effort or risk of failure to validate or be sought, or at least clear guidance should accept be provided as to how to manage in the meantime, and a clear plan for resolution should be presented by EMEA March 2009 : EMEA updated PDF naming convention within 'User guide on how to generate PDF versions of Product Information' to be consistent with eCTD. Practical Q&A needs to be updated to also reflect this change. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Group Where Action Component is Sitting CR-20081210 Gerhardt EU Validation Criteria So far, the EU Validation Criteria do not verify the correctness of the overall Introduce to the EU Validation Criteria an Implemented in v2.1 Validation criteria v2.1 Neurauter, Extedo checksum in the provided index-md5.txt. Guidance is given by the EMEA to additional issue: “The checksum of the of validation criteria published provide this checksum in the cover letter, however, the possibility to verify index.xml should be calculated by a validation the MD5 with the EURSvalidator is not given. tool and compared with the checksum Authorities not using the EURSvalidator perform checks with tools verifying provided in the index-md5.txt.” In case of the overall checksum. We received responses from clients that submissions invalidity the recommended severity should be are rejected due to invalid values in the index-md5.txt. However this issue is A. not part of the EU Validation Crieria. TIGes 6 March 09 : Agreed to progress as an In case of MRP/DCP we encounter troubles that submissions are accepted urgent change and actioned to the EURS only in regions the EURSvalidator is used. group CR-20090126 NtA Volume 2B The ICH M2 eCTD specification and Notice to Applicants Volume 2B provide TIGes 6 March 09 : Principle supported. Action Answered in Q&A Answered as Question #22 Section 2.7.6 different information concerning how to deal with the Synopses of Individual to Interlinking Group to progress. Suggested Studies in Section 2.7.6. The guidance should be harmonised to provide a that option of either hyperlinking to or inclusion similar message in both the CTD and eCTD and avoid confusion. of synopses. The NtA guidance states: Recommend that the NtA guidance is updated 2.7.6 Synopses of Individual Studies to reflect the Section 2.7.6 guidance in the The ICH E3 guideline (Structure and Content of Clinical Study Reports) ICH M2 eCTD or clearly reference this suggests inclusion of a study synopsis with each clinical study report, and difference between the paper and electronic provides one example of a format for such synopses. outputs. This section should include the table entitled Listing of Clinical Studies, March-09 : Interlinking agreed that described in guidance for Module 5, followed by all individual study hyperlinking should be an option for synopses organised in the same sequence as the study reports in Module 5. applicants. Q&A to be produced. It is expected that one synopsis will be prepared per study for use in all April-09 : Interlinking group endorsed a Q&A regions, and that the same synopsis will be included in this section and as for publication part of the clinical study report in Module 5. The length of a synopsis will usually be up to 3 pages, but a synopsis for a more complex and important study may be longer, e.g. 10 pages. Within the individual synopsis, tables and figures should be used as appropriate to aid clarity. But the ICH M2 eCTD guidance states: These synopses should already be located in the Clinical Study Reports in Module 5 and should not, therefore, be repeated in Module 2. It is considered sufficient to provide hyperlinks from the listing of the studies, located here, to the locations of the synopses in Module 5.