EU Region Question and Answer and Specification Change Request Document Version 1.14 November 2008 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 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. # 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 product With respect to product information (PI) documents, the currently acceptable file Mar-2007 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 or This question was generated by EU Change Request A004 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 added be used respectively? 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 Follow- required as CTD/e-CTD submissions in the EU. 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 documents Questions, what to include in Module 1 and what to include in Modules 2-5. The should be attached to the Cover Letter (1.0). However, no EU Module 1 specification Version 1.2.1 now includes the section for Responses recommendation is given with regard to the organisation of the table to Questions. The CTD guidance and eCTD specification together should give of contents, nor to the names and organisation of the files etc. Do adequate direction for applicants to construct a Responses to Questions dossier these recommendations exist? 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 ICH the structure if it has multiple substances? 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 official The question was generated by ICH change request 00710 and the 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 Related A 'regulatory activity' is a logical unit of submission activity (eg, a Type II Feb-2008 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 eCTD This question was generated from EU Change Request QA- sequence should be provided (a lifecycle sequence) correcting these errors, with 20061120-01 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 needed Mar-2008 component of filenames should be a “meaningful concatenation of it is suggested that the word 'point' is used in the filename eg. 1point5mg words without separation and should be kept as brief and 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-20070627- structure, as these would create a document lifecycle for non-existent 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 nor Mar-2008 backbone during the life an application, for example, if the is it necessary to attempt workarounds such as deleting existing documents and manufacturers name changes, the proposed name of the dosage resubmitting with new attributes. The recommendation is to retain the obsolete form is not accepted or an excipient is granted a pharmacoepial 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-20071002- Decentralised Procedures and is therefore not applicable for the Centralised 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 to This question was generated by EU Change Requests CR- the content located in module 3 e.g. Flow Chart of the Manufacturing Sites, and 20070906-01 & CR-20070927-01 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 The application number element description on page 9 of the guidance states that this is the “number assigned to the application by the receiving agency”. Given the explanation provided on page 14 of the EMEA‟s recently released Q&A on eCTD Implementation (7th February 2008) we presume that for Centralised Submissions, the EMEA procedure number is meant here (see accompanying change request). In DCP, MRP and especially National Procedures already several numbers are used to identify a submission. To avoid misunderstanding clear definitions and guidance of what number to use where is needed. For instance in The Netherlands for a MRP submission the MRP procedure number and a case number has to be used (and of course the MA number). Could the TIGes provide feedback/guidance on the definition of the Application Number element for MRP, DCP and National Procedures. 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. 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 EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component A001 eCTD EU Module 1 What is the EU's position on the use of XML for the content of the submission Change request added retrospectively to allow Implemented in EU M1 Implement in v1.3: Specification instead of PDF and/or RTF? tracking of the Q&A process 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 M1 Implement in v1.3: Specification tracking of the Q&A process 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 a Change request added retrospectively to allow Answered in Q&A Answered as Question #9 separate subfolder. How should a product be added to the structure if it has tracking of the Q&A process multiple substances? EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component 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 M1 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 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 not appropriate use of node extensions in section with agreed text supported in any part of the submission and this therefore invalidates the ICH compliance with the eCTD specification (i.e. spec. Experience on production of submissions for Europe demonstrates that their use is discouraged unless there is no node extensions are required to deliver a navigable structure for Modules 4 other feasible means to submit the information). and 5. At present this means that eCTDs are not re-usable across regions and thus will create significant amounts of rework for industry. FDA should May 2005: Referred to EU and MHLW regional accept node extensions in Modules 2-5. 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 M1 Implement in v1.3: generated by ICH Specification regional guidance v1.3 Answered as Question 11. change request Put a comment in appendix 00710 June 2005: Applicant stylesheets are accepted 2,row 72. 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 different Answered in Q&A Answered as Question #13 Specification commonly misinterpreted that would prevent my eCTD message from being interpretations of the eCTD Specification that and covered by EU viewed by another applicant/regulator? have prevented timely exchange of eCTD Validation criteria. 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 Component 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 been It may be possible to have an additional Implemented in EU M1 Opened 19-09-2004 (EFPIA) Specification v1.0 created it is not possible to know what each sequence is about with physically attribute assigned to the submission type v1.1 Agreed 24-09-04 opening the sequence documents and reading the Cover Letter. Industry is „submission description‟. This could be either already considering requesting the vendors to provide some additional optional or mandatory dependent upon Dec 05: Implemented in description to assist in creation of the applications and we understand that at submission type. eCTD Spec v1.1 - new least the EMEA is adding a description to this Docubridge records. It would element 'submission- be logical to standardise on an additional attribute that the applicant can description' added to complete for there own records and that the agencies can make use of in their envelope. 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 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 agencies. R. de Boer to split the CR This change request is made to enable the AF to be used during MRP into those points that are submissions. Some of the requests made below are suitable for none MRP nice to have and those subm as well. which are essential Generic apps - It should be possible to include reference medicinal products requirements 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 that and in CTD Q&A. 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 Component 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 to procedure - Mutual recognition procedure- Independent National procedures- Referred to Notice to Applicants Group 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 in Implemented in EU M1 Dec 05: Implemented in Specification submitted using XML, so the PIM DES does the same for product information. accordance with the PIM DES' should be v1.2.1 eCTD Spec v1.1 - accepted The current EU Module 1 specification permits PDF and RTF as formats for detailed, as this standard includes more than file formats amended. product information, but not XML. For administrative information, however, XML (additional documents that can be Oct 06: Updated in eCTD XML is permitted. Suggestion : Include XML as an accepted format for the attached with the XML) Spec v1.2.1 - accepted file “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 folder Retain separate util folder for components that Implemented in EU M1 Oct 06: Kumar) Specification that includes STYLE and DTD folders. The screen shots are good and can be submitted outside eCTD e.g. e-AF and v1.2.1 Implemented in eCTD Spec 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 we util folder to obviate need for regional util folder. have a DTD folder.This structure is clear and consistent across all regions as More testing required of PIM container 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 of eCTD EU Module 1 EU Module 1 Specification: Implemented in EU M1 Dec 05: Implemented in Medicines (José Specification Element : m1-6-1-non-gmo v1.1 eCTD Spec v1.1, cell 43 Manuel Vidal Directory : m1/eu/16-environrisk/161-nongmo p.21 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 Component 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 M1 Dec 05: Implemented in Marr) Specification v1.0, EAF approval in Europe, that of the Decentralised Procedure. In the current eCTD v1.1 eCTD Spec v1.1 new v1.0 envelope a picklist provides for the option of Centralised, Mutual Recognition attribute in envelope. 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 M1 Dec 05: Implemented in Specification per the road map (DES 2.1), for December 2005. will need to be created in EU M1 for 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 will Deferred Referred to ICH for next v3.2 system interoperability (EURS/PIM RS) for regulators for them to make PIM consider for the scope of the next major release major version of the eCTD. submissions to applicants either with or without eCTD. (ICH Change Request #1110) 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 the Implemented in EU M1 Dec 05: Implemented in Specification and „national‟ as folders between the root folder and the sequence number. „procedure‟ folders deleted. This should 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 Component 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 implementation Answered in Q&A Answered as Question #14 Specification sequences indicates that we should refer to regional guidance with respect to of the eCTD, the four Operation Attributes allowance of cross-referral. This guidance needs to be established. (new, append, replace and delete) will remain Referred to ICH for next ICH Question: The eCTD specification supports the ability to refer to a and not be added to. With the existing major version of the eCTD. previously submitted file, for example, by including in sequence 0005 a leaf specification it is technically possible to with Operation Attribute of 'new' that refers to a file submitted in 0000. Is it determine that a file is not in the current possible to indicate to the reviewer that they have already received and 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 1. Recommended solution Implemented in EU M1 Oct 06: Implemented in Specification This CR requested the following actions: - Add TGZ as allowed file format (this format is 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 the - Add name specification “131-pim-xxxx- image formats (JPEG, GIF, PNG, TIF, SVG, MathML) ar.zip/tgz ” for the PIM file Today, PIM systems are under elaboration and practical experience provided - Keep Element “m1-3-1-pim” some feedback about the way PIM has been integrated into the EU Module 1. - Remove description the use of EU M1 “util” Following the feedback received, we believe that there is a simpler way to folder for PIM include PIM in EU Module1. - Remove definition of folder “131-pim-xxxx-ar ” It is more appropriate to include PIM into the EU Module 1 as a single archive file than directly refer to the XML file. Therefore, it is proposed to: Refer to PIM DES specifications for - Add ZIP format and TGZ format as valid file formats compression protocols - 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 Component 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 as Implemented in EU M1 Oct 06: Implemented in Specification defined by ICH in the context of eCTD. The leaf entity is defined by: 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 M1 Implemented in EU Module Liquent, Thomson Specification Module 1 eCTD version 1.1 specification indicates that the corresponding Check guidance is clear 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 Module Addressed by EU M1 v1.3 specification and Closed None Kendle Specification and type 1 specifications issued in January 2006 become mandatory for use in all transition plan definition 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 the Implemented in EU M1 Implement in v1.3: eu-regional.xml in the index.xml? 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 be documents obsolete. It is also not new, because the eu-regional.xml has been 'new'. Investigate other 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 for EU M1 is 1st priority – Lang/country codes for Implemented in EU M1 Implemented in EU Module Roche Specification, v1.2 the planned accession of Romania and Bulgaria. Version 1.2 of the DTD RO BU in DTD, specifications and style- v1.2.1 1 eCTD v1.2.1 included several changes, including the removal of these country and sheet. Assessment of required changes to language codes. Given the planned accession date of 1st Jan 2007, we align 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 Component 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 included Closed None Liquent Specification, v1.2 managed by an eCTD how should the operations attributes be used? 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 Specification, v1.2 eCTD documents should be handled in the same way eCTD Interlinking detailing the guidance to that the SPC is currently handled in eCTD - Group submit only the final agreed Currently with a paper submission there is the possibility of submitting a only the final agreed versions of the documents version of the M3 response to a question which may contain a proposal (e.g. a change to the should be submitted at (or just before) the end documents in the eCTD. specification) and when that is found to be acceptable by the regulators the of the procedure. The interim versions should (This will set a precedent for revised Module 3 content can be submitted. With an eCTD is it always not be exchanged in the eCTD - they should be an eCTD Q&A and any expected that the Module 3 section is updated at the time of submitting the exchanged as communications outside the appropriate guidance response or can this also be delayed until it is known that the response is eCTD. change). acceptable? 20060703-01 Geoff Williams, EU Module 1 DTD and Implemented in EU M1 Implemented in EU Module Roche Specification, v1.2 The European Commission website URL is incorrect 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 M1 Implemented in EU Module Roche Specification, v1.2 The example filenames given for two documents in the specification are v1.2.1 1 eCTD v1.2.1 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 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 Bruggen, 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 Deferred Discussed at ICH M2, see eCTDConsultancy Appendix 6 submitted. 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. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component 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 group, rapporteur and co-rapporteur have at this stage already received an initial they responded "It is required to submit the copy of the eCTD. application to Rap / Co-Rap at the same time (i) How is the applicant advised to handle validation changes in the eCTD? as to the EMEA. It is therefore not possible to Should another eCTD sequence be created, incorporating the suggested submit to Rap / Co-Rap only after validation of changes, or should the original sequence be corrected? NB If an additional 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 the Duplicated None Datafarm specification v1.2.1 inconsistent with the accompanying statement that „common‟ is the directory 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 M1 Implement in v1.3: J&JPRD specification v1.2.1, variable component of filenames should be a “meaningful concatenation of 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 these specification 'file naming variable components. The change request applied for is to allow the use of convention' 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 M1 Implement in v1.3: America specification v1.2.1, regarding the Specifications. 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 M1 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 reflect v1.3 Change the 3 examples in examples examples, this folder contains the EU Module 1 DTD files. This is incorrect 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 to instatement of max. 50 character field length. 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 Component 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, it ICH tracking sheet for 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 M1 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. 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 a Write a Q&A to clarify until new version is text which illustrates this on 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 Rejected Discussed at ICH M2, see 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? A. The regulatory authority should be consulted for a solution until the 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, item 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 Deferred Discussed at ICH M2, see Roche 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 xlink:href discussion and position taken at an EU level. should exist. At the time this was written, we probably meant “exist 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 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 Component 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 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. The change request says that the element for Module 3.2.A.3 (Novel 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 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. CR-20070426-01 Joe Cipollina, BMS ich-stf-stylesheet-2- The ICH STF Stylesheet currently posted gives inconsistent display results in This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see 2.xsl Internet Explorer. It seems to work in some cases but not in others. STF files group for consideration. It has been added ICH tracking sheet for which were viewable with the older version of the stylesheet are no longer here for completeness and to record any details of outcome. 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 the This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see 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 is Nov-07 Q&A wording proposed Implemented in EU M1 Implement in v1.3: GSK not provided, and there is no need for the applicant to provide „not applicable‟ v1.3 Answered asQ&A #18. pages. However, we have experienced occasions where we receive Change text on p.6 to questions after EMEA content validation with respect to sections that are include text from Q&A 18. 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 M1 Implement in v1.3: GSK specification v1.2.1 response to questions specification 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>? The use of related-sequence attribute 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 to Implemented in EU M1 Implement in v1.3 if values Ethypharm specification v1.2.1 standardised the value of this element. define list 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 / dextroproxifen), Sep-07 Requested to be withdrawn and Withdrawn None Ethypharm what is the best practice : duplicate <atc> and <inn> element ? resubmitted as a CR (subsequently submitted as CR-20070718-01) EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component QA-20070628-04 Thierry Le Ridant, eCTD EU Module 1 DCP or MRP are followed by a national phase (PIL etc.). What should be the Response provided in Best Practice guide for Closed None Ethypharm specification v1.2.1 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 stylesheet Data from the envelope is displayed in blue but they are not hyperlinks. The Sep-07 Analysis undertaken of all EU Implemented in EU M1 Implement in v1.3: Ethypharm use of blue text should be limited to hyperlinks stylesheets shows inconsistency. Change 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 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-New Deferred Refer to eAF project - eCTDConsultancy filepaths for the xlink:href attribute value 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 is Nov-07 Was referred to eCTD Interlinking Accepted - refer to Propose to eCTD Ethypharm specification v1.2.1 no link between the <inn> element and the <atc> element. We suggest to Group "No changes required – Because there eCTD Interlinking Interlinking/TIGes that atc is regroup them into an <active> element which will permit to identify the link is no one to one relationship between Group removed altogether from the between atc and inn. substance and atc codes. The codes relate to envelope. the indication of the product." Request information from Subsequent research shows this may not be EMEA and MS on use of atc correct. code. Needs further June 2008: eCTD Interlinking: ATC code left in clarification. EU M1 v1.3 Await development of the Dec 08: Interlinking Group - there is definitely eAF where the ATC will be no link between the substance and the processed. 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). 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 period Further detail included in original question. 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 - 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 EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component QA-20070906-01 Hans van Bruggen, eCTD EU Module 1 Could the TIGes clarify what <Submission> “type” attribute value should be Nov-07 Review required across other Implemented in EU M1 Implement in v1.3: eCTDConsultancy specification v1.2.1 selected for the following types of submission: specifications. See also CR-20070926-01 v1.3 Propose revised list. See B.V. 1. Annual Reassessment CR-20070926-0 - ensure 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 M1 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. 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 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 M1 Implement in v1.3: Montes, EMEA specification v1.2.1 specifications. See also QA-20070906-01 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 M1 Implement in v1.3: AstraZeneca specification v1.2.1 and specification to be submitted. The basis for eCTD is to submit documents defines how to reference content from more v1.3 Include a short additional Guidance on Type 1A only once, but to be able to fulfil the European variation guidelines all required than one leaf location. Some clarity might be section on p.6 under and 1B variations documents would need to be submitted. This change request gives a added to specification. 'General Architecture'. 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 Winkel, Notice to Applicants vol The ASMF guidelines state that the manufacturer and the applicant should Nov-07 This issue is referrd to the NtA Q&A on Deferred Refer to NTA Q&A N.V. Organon 2B both submit an identical Applicant‟s Part (AP) of the EDMF. handling of ASMF Guidelines for eCTD files indicate that the AP should be included in Section 3.2.S of the eCTD. 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 discussion Deferred Referred to Harmonisation i3Logic lifecycle of an application? and position Tasforce 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 section Implemented in EU M1 Answered as Question 20 Montes, EMEA specification v1.2.1 centralised procedures? can be used for CP in a transition period for v1.3 Refer to CTD Guidance #4 submitting documents as part of a new M1 on use of the additional data structure before the latest DTD version is section (i.e. it should not be implemented (e.g. paediatrics data). used for CP) - amend therefore line 68 of the table in appendix 2 EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component 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 M1 Accepted for next minor 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 in v1.3 update of EU Module 1 annex to the form (p14). It is proposed that all supporting data is provided in Variations. Accepted to update EU M1 eCTD eCTD the same location, as an annex to the form. In addition, it is proposed that a specification in line with CTD Q&A response. Amend Appendix 2 row 67, table of suggested names is added to the specification, such that these p.27. Text should be documents are provided in a consistent manner. consistent with CTD Q&A Further information included in the original change request #4C CR-20071009-01 Hans van Bruggen, 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 discussion Deferred Referred to Harmonisation eCTDConsultancy specification v1.2.1 Environmental risk Assessments, using the operations new, append replace and position Tasforce B.V. and/or delete. 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 in Nov-07 Best Practice guide written for review Accepted - refer to Feb-08 Present guidance Andrew to distribute GSK parallel and affect the same document? and approval eCTD Interlinking for consideration by eCTD current documents. Get Group Interlinking Group comments and consider inclusion of general principles/guidance in harmonised eCTD guidance. Include details of particular scenarios/use cases. CR-20080129-01 Geoff Williams, EU M1 stylesheet The current stylesheet displays the full structure of the Module 1, whether the Rejected None Roche 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. 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. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component 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 M1 To be implemented in v1.3 Roche v1.2.1 Please consult regional guidance to submit other versions of PDF.”. come from EFPIA, clarifying further the use of 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 that application form. 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 requirement To be included in eCTD v1.3 2008 Implemented in EU M1 Include acceptance of XML to provide a table as a file under 1.0 Cover Letter that keeps track of the v1.3 as a file format for the Cover sequences, when and when they have been submitted. This will allow each Format and layout of the table to be defined by Letter section (1.0) also. NCA to know that any „missing‟ sequences are not relevant to them and eCTD Interlinking Group. For implementation in v1.3 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 M1 To be implemented in v1.3: EMEA v1.2.1 1.10 Information relating to Paediatrics. The eCTD specification should be v1.3 Amend specification and updated in line with the new CTD structure. stylesheet accordingly 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 PMF 2nd step is currently a Schwarz specification, Appendix Plasma Master File (PMF). Following the centralised authorisation of the PMF interim guidance on which submission type to eCTD Interlinking type II variation. In the new CSL Behring AG 1 "Envelope Element the PMF 2nd Step Procedure must be performed. In this 2nd Step Procedure, use. Group regulation this will be a type Description", therein the PMF certificate must be submitted for each product in order to make the IB variation (possibly IA). A element = submission link between PMF and the product's marketing authorisation. According to the dedicated submission type and attribute = type (p. "Guideline on Plasma Master File (PMF) And Vaccine Antigen Master File for PMF 2nd step is 10) (VAMF) “Second Step”" this is NOT a variation submission. considered not to be needed If this is done for an existing eCTD, there is no adequate submission type at this time, certainly not defined in the Module 1 Specification to describe this submission. until the new variation Recommendation: Define an additional valid submission type for a PMF 2nd regulation is in force and it is Step Submission, such as "pmf-2nd-step". clear what submission type a PMF 2nd step is. In the meantime, produce guidance for applicants detailing how to use the eCTD format both for the PMF itself and for the 2nd step in the MAA. This guidance should be produced by EMEA by end 2008. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component CR-20080514 Kevin Wing, EU Module 1 The example provided for the application number element description on page Refer to eCTD Interlinking Group for discussion Open Complete the survey for MS eCTDConsultancy Specification v1.2.1 9 of the guidance is in the format of an EMEA Marketing Authorisation and drafting of Q&A on what is expected in that on requirements for Number i.e. EU/1/00/150/001 and not an EMEA Procedure Number such as field. Draft survey for MS on requirements for application/procedure EMEA/H/C/XXX/X/XX. 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 would appropriate requesting a only be assigned upon approval and would also be strength-specific). This is change to the way supported by the explanation provided on page 14 of the EMEA‟s recently application numbers are 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, produce EMEA/H/C/XXX/X/XX. associated business And add a clarification to the description that the number required for this guidance on how each value is the procedure number. 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-01 Anne Mieke EU Module 1 Since this information is mandatory in the cover letter, variation and renewal Refer to eCTD Interlinking Group for discussion Open Complete the survey for MS Reijnders, Specification v1.2.1 application form and is useful for retrieving information from the eCTD and drafting of Q&A on what is expected in that on requirements for eCTDConsultancy lifecycle it would be beneficial to add the Marketing Authorization Numbers to field. Draft survey for MS on requirements for application/procedure the EU M1 envelope information 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. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component CR-20080514-02 Kevin Wing, EU Module 1 The EU Module 1.2.1 specification only includes instructions relating to 1.3.1 CR originator to draft a proposal for the Open CR originator to draft a eCTDConsultancy Specification v1.2.1 SPC, Labelling and Package Leaflet identifiers and Language/Country Codes information, to be included in the next version proposal for the information, in the context of document filenames/folder paths. This information is also of the specification. to be included in the next required as XML metadata and this change request is to update the version of the specification. specification to clarify this requirement. CR-20080514-03 Anne Mieke EU Module 1 Since sequence numbers do not have to be used in sequential order it would The Cover Letter and tracking table if Rejected None Reijnders, Specification v1.2.1 be beneficial to add the submission date back into the EU M1 envelope appropriate should be used to track the date - it eCTDConsultancy information. 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 a Implemented in EU Delete criterion Criteria dpi of more than 300. The ETICS testing demonstrated that it does not 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 Change reference Criteria incorrect as it is ICH Q&A 36 - change reference. 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 Change EU criterion #18 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 and include comment and leaf or node extension 'title' attribute is not empty‟. #18 states „If the value of included a statement to indicate that this is not reference to ICH criterion the operation attribute is delete,……title is not required…..Consistency should consistent with the ICH criterion #20. #20 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. 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 eCTDConsultancy Specification v1.2.1 ago and has been presented/discussed at conferences, implemented by which has been improved and is robust with EU Q&A some vendors and is included as a term in the EMEA‟s Q&A Relating to 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 the sequence, but to indicate that application EU M1 eCTD guidance describes use of the related sequence element to number is used in addition. Dependency on CR- groups eCTD sequences into 3 Regulatory Activities (an MAA, a technical 20080514 and the drafting of guidance for use variation and a labelling change variation). of and requirements for application numbers by all agencies. In the afore-mentioned EMEA Q&A document, it is the Application Number (procedure number) that is described as the “envelope element which is used to group together submissions relating to a particular regulatory 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? EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component CR-20080514-05 Anne Mieke EU Module 1 The application number element description on page 9 of the guidance states See CR-20080514-04 -guidance to be Open Complete the survey for MS Reijnders, Specification v1.2.1 that this is the “number assigned to the application by the receiving agency”. produced. on requirements for eCTDConsultancy Given the explanation provided on page 14 of the EMEA‟s recently released application/procedure Q&A on eCTD Implementation (7th February 2008) we presume that for number, and use of this Centralised Submissions, the EMEA procedure number is meant here (see element. Once results have 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 definitions change to the way 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, produce Could the TIGes provide feedback/guidance on the definition of the associated business Application Number element for MRP, DCP and National Procedures. 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 which Article 61(3) exists as a submission type in the Rejected Schwarz, CSL v1.3 are registered under the Central Procedure and the Mutual Recognition EU M1 specification v1.3 Behring AG 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. CR-20080703 Andrew Marr EU M1 Specification The list of submission types included in the eCTD Module 1specification v1.3 As part of the creation of EU Module 1, v1.3 Accepted - refer to Discuss again in eCTD (EFPIA) v1.3 does not include Repeat Use Procedure. What submission type should be and in conjunction with the development of the Q&A Interlinking to confirm that used for this submission? eCTD in MRP/DCP Best Practice document it was agreed that this consideration was given to the creation of should not be includd as a „Repeat Use Procedure‟ as a specific submission type. After deliberation, this was submission type in the next not accepted. However, the Best Practice version of EU M1 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‟. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component CR-20080703-01 Andrew Marr EU M1 Specification The list of submission types included in the eCTD Module 1specification v1.3 As part the development of the eCTD in Accepted - refer to Discuss again in eCTD (EFPIA) v1.3 does not include a specific submission type for a change of the Reference MRP/DCP Best Practice document it was Q&A Interlinking to confirm that Member State in MRP. What submission type should be used for this agreed that „Change of RMS‟ would utilise an it was agreed that this submission? existing submission type and that a Q&A should should not be included as a be prepared to this effect. The submission type that should be used is submission type in the next „supplemental-information‟ and the submission version of EU M1 description should be „Change of Reference Member State‟ 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 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 table MRP and DCP on page 45. XML on p.45 is not included in the folder m1/eu/10-cover/common. 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 IB Accepted Refer to EMEA post- GSK v1.3 dossiers – all CHMP members should get an electronic copy of everything, variations are split by NeeS and eCTD. For approval copy requirements including Type IA/IB variations – otherwise future lifecycle operators will be NeeS, they stay as they are. For eCTD, the for change to text. invalid. requirements for Type IA and IB variations The current copy requirements do not differentiate between eCTD and NeeS. mirror those for Type II – i.e. “Other CHMP For Type IA and IB variations, only the Rapporteur requires 2 electronic members: 1 electronic copy”. 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 Component 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 Accepted - refer to Discuss and agree in eCTD Identified as a hurdle for GSK Practice Guidance preferring to centralise electronic dossier production, or following the form, a single „common‟ English language cover eCTD Interlinking Interlinking group eCTD implementation. preferred „Comprehensive model‟ for eCTD in MRP/DCP must get a cover letter is acceptable in all MS. Group Cover letter is not letter translated into all European languages before building the dossier. For covered by legislation, submissions requiring an application form, this is unavoidable, since the form contains details of the MAH, and local contacts etc. However, for follow up but nevertheless some measures, or simple administrative submissions, the requirement to get a MS have requirements cover letter translated up to 23 times is onerous and does not add value to for local laguage the dossier (NB the rest of the content is likely to be in English). Could a versions. HMA to try to „common‟ English language cover letter be used for such submissions? persuade individual agencies to relax requirements for a cover letter in the local 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 CR-20080909 Leigh Sandwell, eCTD Guidance Current guidance requires that statements justifying absence of data in the Recommend that empty Module 1 Sections do Accepted - refer to Discuss further in eCTD Approach to M1 is Pfizer eCTD should be provided in the QOS, non-clinical and clinical overviews, as not require a justification statement to be eCTD Interlinking Interlinking Group. If different than for other applicable, and that no placeholder documents are required in the eCTD included in each section and the Q&A Group acceptability of no modules, as M1 should structure. The guidance should be updated to clarify how to deal with empty document is updated to reflect Module 1. placeholder documents in always be populated sections of Module 1 and any potential justification that may be required. M1 is confirmed, update (even with 'not Q&A, specification and applicable' statements) as existing guidance as a legal requirement. applicable to confirm that Another proposal is that any M1 justifications only justifications should required should be be required - simple submitted as an attachment statements of not to 10 Cover Letter. applicable should be included in the cover letter. Revisit this discussion as currently no agreement. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component CR-20080909-01 Dietmar Boecker, eCTD Guidance Guidelines on the submission of the EU-RMP require a stand-alone format of Accepted Refer to EMEA eCTD Bayer Schering the document including all annexes to be located in eCTD Module 1.8.2. This Business Team for is in contradiction to the ICH eCTD requirements, that mandates a different discussion and confirmation, location for most of the annexes. and amend all guidance In section 4.4 of the EU-RMP guideline EMEA/CHMP/96268/2005 it is outlined that the EU-RMP "should be provided (...) in a stand-alone format documents as 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 Draft an eCTD Q&A to 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 detail a proposal for all renewals is available. assigned to specific CTD-defined locations then additional documents for they should be included in 1.2 Application variations and renewals in Form. These might include declarations, certificates, justifications etc. Where possible, the eCTD, consistent with they should be organised according to the the CTD Q&A 4c (must Annexes for the Application Form for new include information on products (Annexes 1 to 22). Where documents renewals also) cannot be assigned to one of the annexes then Propose to amend EU M1 it is appropriate to place them after the specification in next version annexes. The „Additional Data‟ section of to also reflect the CTD Module 1 should not be used except for country- Q&A. specific information. The eCTD Q&A, detailing The EU M1 specification should therefore be amended in the next version to reflect this, and the approach, should be a Q&A is required to confirm this, and also to referred to in the meantime. confirm that the same approach should be taken for renewals. EU eCTD Specification Change Requests # Requestor Specification Description Comments Status Action Component CR-20081008 Andrew Marr, GSK eCTD specification The guidance just issued by QRD regarding production by the applicant of the Dec 08: EMEA meeting held to discuss issue - Accepted EMEA to revise eCTD (EFPIA) v3.2 PDF for final labelling is incompatible with the eCTD and will lead to conclusion that requirements for EMEA PDFs guidance to reflect the duplication of effort. arise from the EMEA EPAR publication inconsistency, and advise In the longer term EMEA must align their requirements and if there is process, and eCTD filenaming requirements that, until further notice, the business logic for the filename as per the EPAR proposed name then an EU have a different purpose and support a different specification change may be justified with the inclusion an appropriate proess (review) and therefore requirements eCTD filenaming filename that meets ICH general filename requirements. cannot be aligned until Q3 2009 when the convention should be used EMEA publication process is re-designed. This for the product documents In the short-term there is an urgent need for clarification as to how an conclusion was not redily accepted by industry - in the eCTD, and at the time applicant can submit product information inside and outside the eCTD, for all either alignment must be sought, or at least of publication of the EPAR, submission types without duplication of effort or risk of failure to validate or clear guidance should be provided as to how to a separate folder outside the accept manage in the meantime, adn a clear plan for eCTD should be submitted, resolution should be presented by EMEA containing a zip file with all of the translated product information PDFs (exact copies of the final files inside the eCTD), observing the EMEA filenaming convention. These files are used for publication only, and the files in the eCTD are used for archiving and lifecycle. (In non-eCTD electronic submissions, the EMEA filenaming convention should be observed). Plan further meetings to address the alignment. 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 Open Neurauter, Etedo checksum in the provided index-md5.txt. Guidance is given by the EMEA to additional issue: “The checksum of the provide this checksum in the cover letter, however, the possibility to verify the index.xml should be calculated by a validation MD5 with the EURSvalidator is not given. tool and compared with the checksum provided Authorities not using the EURSvalidator perform checks with tools verifying in the index-md5.txt.” In case of invalidity the the overall checksum. We received responses from clients that submissions recommended severity should be A. are rejected due to invalid values in the index-md5.txt. However this issue is not part of the EU Validation Crieria. In case of MRP/DCP we encounter troubles that submissions are accepted only in regions the EURSvalidator is used.