eCTD Specification Change Requests
|FDA||m5-3-5||Multiple Indications||Resolved by CTD group, no implication for eCTD||Out of scope|
|4-62 (#371)||4-62 (#371) shows that DTDs and style sheets should be put in a dtd or style subfolder but on page 6-2 it shows that dtd files should be placed directly under util folder. Which is correct?||Appendix 4 is the definitive source of information, it should be made sure that it is corrected in the next version||Approved for specification change||Specification changed to Version 3.2|
|Page 4-8, Line 34||Incorrect use of hyphen||Must be changed||Approved for specification change||Specification changed to Version 3.2|
|00040||MHLW||MHLW||Page 2-5||Parta (UPPERCASE is not allowed) – not necessary to restrict to lower case||It is best to leave it as it is (lower case)||Rejected|
|00041||MHLW||MHLW||Page 4-1||Full path of the File/Directory.
…Use the full path to refer to files. The full path is not shown in these examples.
|00042||MHLW||MHLW||Page 6-5||Use the full path to refer to files. The full path is not shown in these examples.||Not relevant||Rejected|
|00050||Liquent||FDA||3.2.A.3||Request 3.2.A.3 to be changed to a repeating element||Understood and will address in Q&A (No. 12) and then next version of DTD||Approved for specification change||Specification changed to Version 3.2|
|00060||FDA||FDA||Appendix 3, footnote 6||States that there will be as many subfolders as there are studies included. There may be some studies in Section 5.3 without patient data listings or CRFs.||Erroneous question, text in footnote is correct; question not relevant||Rejected|
|ich-ectd-3-0.dtd||the element declaration
<!ELEMENT m3-2-p-2-1-components-of-the-drug-product ((leaf |node-extension)?)>
is different to all other element declarations:
<!ELEMENT name ((leaf | node-extension)*)>
|Element is no longer in the 8 October version of the dtd; not relevant any longer||Rejected|
|00080||ECTD IWG||FDA||Header||Updated Version Number||Not relevant, version in header is correct||Rejected|
|00090||EU||FDA||6-9 and 6-13
|Acrobat 5 is specified when it should read “PDF 1.3”||Change the examples (such as PDF 1.2 or PDF 1.3) in the specification to include both the ‘application version’ and the ‘file type’ version.
Also, include some of this in Appendix 7
|Approved for specification change||Specification changed to Version 3.2|
|3.2.p.4||Structure of the DTD to support excipients is less than optimal||DTD will be updated, also addressed in Q&A No. 3||Approved for specification change||inform CTD Q; change
next major release
|Appendix 3, 4||Clarify file names mandatory or optional. Inconsistent wording||Clarification is highly recommended; Q&A (No. 15) recommended before rewriting
agreed that file names are optional
|Approved for specification change||Specification changed to Version 3.2|
|Appendix 4||Recommendation for the use of unique filenames where reviewers are likely to have several files open for comparison.||Unique file names as general principle will be recommended – related to Q&A of 110||Approved for Q&A||No. 15|
|DTD – Appendix 6 Example||Use of the checksum; clarify use of checksum when delete operation is applied||Needs to be addressed in a Q&A (No. 21)
Checksum should be Null
|Approved for Q&A||No. 21|
|Appendix 4, Section 3.2.S.2||Suggest optional use of sub folders to better structure documents||As all file and folder names are optional, this is allowed||Approved for Q&A||No. 17|
|00150||EFPIA||EFPIA||Appendix 4||States that the regional DTD and xml files have one naming convention, but the EU Module 1 has a different naming convention. Which takes precedence.||EU has been changed, not relevant any longer||Out of scope|
|Appendix 4 3.2.P.7||Suggest multiple files allowed for different container closure systems.||Flexibility over number of files to be included in revised M4 Organization document see 00440||Approved||M4 organisation document changed|
|00170||EFPIA||EFPIA||DTD||Use of “Title” attribute within structural elements of the DTD.||No “Title” attribute for the structure||Approved for specification change||consider structure representation and control as part of next major release|
|00180||JPMA||JPMA||Preliminary discussions on how to handle multiple indications||Duplication, see 00010||Out of scope|
|00190||ECTD IWG||Cover Page||Add “International”||Needs to be changed||Approved||Cover page was changed|
|00200||Q&A||DTD||Make the indication attribute required||Change in DTD and specification necessary||Approved for specification change||Specification changed to Version 3.2|
|00210||Q&A||DTD||Need to consider how to update index.xml when there is an error in the backbone||Answer: should be consulted with regulatory agency||Approved for Q&A||No. 3|
|00220||Q&A||EFPIA||The specification be expanded to support two way communication||Out of scope|
|00230||FDA||FDA||2-3 Checksum||Detailed explanation on using checksums when deleting a previously submitted file.||Not relevant as duplication to 00130||Rejected|
|00240||FDA||FDA||Page 6-7||Make leaf ID required in eCTD Specification (at present is optional)||Change specification to make leaf ID required at leaf level||Approved for specification change||Specification changed to Version 3.2|
|00250||EFPIA||EFPIA||Zip files. A realistic mechanism to parcel up a small eCTD submission and attach to an email or simple FTP transmission is required. .zip is one simple option for the bundling together of the files within the directory structure required for an eCTD submission and hence being able to provide a single object to the agency in a highly efficient manner.||Zip is OS dependant, open standard archiving formats may be considered.
Out of scope for IWG
|Out of scope|
|00260||EFPIA||EFPIA||Clarification should be given, with examples as to the intended content of the attribute 'application version'.
The specification defines an attribute termed 'Application Version' but provides no examples of what might be used here. For example, is 'Acrobat v5 okay or should it be PDF v1.3. Other examples might relate to Word version when .rtf files are used reginally etc. It would be useful to understand the purpose of this attribute and hence what to use as valid terms.
|Duplication, see 00090||Approved for specification change||Specification changed to Version 3.2|
|00270||EFPIA||EFPIA||Should bookmarks be presented expanded or collapsed? Should bookmarks for tables and figures be separate structures?
Several options exist regarding the presentation of bookmarks. Firstly the bookmarks can be presented so that they are collapsed to the first level whereby the reviewer can expand those that they wish to explore or they can be presented fully expanded so that the review can see all the bookmarks but this may be a very long list in some documents. Secondly, the bookmarks can be presented sequentially, page by page, or they could be grouped with Tables and Figure appearing separately. Is there a preference form the agencies as to how they wish to see bookmarks presented.
|Not sufficient experience yet for a firm answer across the regions.
Suggestion that it is a company decision for the individual submission
|Approved for Q&A||No. 18|
|00280||EFPIA||EFPIA||The specification should be developed to encompass a definition for acceptable digital signatures
Several companies are wishing to move towards the use of digital signatures but there is no commonly defined acceptable standard and/or statement regarding signatures from ICH. ICH would be a sensible forum for such a standard to emerge. This should be taken on as a change control item but in the meantime some form of guidance through Q&A would be useful eg. what to do if you do have digital signatures – are they acceptable and what constitutes acceptability.
|Appropriate for a short Q&A (No. 14) stating that there is no position on this point||Out of scope|
|00290||EFPIA||EFPIA||The current upper limit of file size should be raised from 50MB.
The original requirement for a maximum file size for pdf files of 50MB came from the initial FDA guidance document dating from 1998. Performance of networks and pcs has increased significantly from then. ICH should consider increasing the maximum file size to something larger. This will facilitate the preparation of documents – particularly legacy documents where scanning has been the only option.
|Test whether file sizes of 100 and 75 MB can be accommodated by all regions
Has been tested and can be accommodated in all regions
|Approved for specification change||Specification changed to Version 3.2|
|00300||EFPIA||EFPIA||Clarification should be given, with examples as to the intended content of the attribute 'font library'.
The specification defines an attribute termed 'font-library' but provides no examples of what might be used here. For example, is 'Arial' appropriate or would it need to be 'Arial, Arial Black, Arial Narrow, Arial Italic' etc. It would be useful to understand the purpose of this attribute and hence what to use as valid terms.
|This it currently not used||Approved for Q&A||No. 19|
|00310||EFPIA||EFPIA||Can clarification be provided about the necessity to provide full text indices (eg. Adobe Catalogue files) and if desired by the agencies, how and where they should be included in the backbone.||There are no current plans to use Full Text Index in any of the regions. The section on providing pdf indexing requirements will be revisited in the next version of the specification; also Q&A No. 16||Approved for specification change||Specification changed to Version 3.2|
|00320||EFPIA||EFPIA||When an update occurs to a file, other documents may have redundant and inaccurate links to it. A mechanism should be established to manage either the redirection of this link and/or the highlighting that the link is pointing to a superceded document and the review tool(s) offers the updated document as an alternative||See change request form||Deferred||until more experience with lifecycle management of eCTDs|
|00330||EFPIA||EFPIA||The DTD should be modularised. For example, the leaf, so it can be used for other purposes such as in the regional module.||Harmonizing the technical approach to Module 1 with the other Modules of the eCTD is planned for the next major release of the eCTD||Approved for specification change||Specification changed to Version 3.2|
||Additional operation attribute to be included in the spec to allow for the ref of a file from multiple places in the backbone but the mgmt of full attribute information only once. It is appropriate to make ref to the same file from many locations. In the eCTD the principle should be that the file is included only once but can be linked to from multiple locations in backbone. This is a good solution except when lifecycle means that this document is, e.g., replaced. Under this circumstance, each entry into backbone must be individually updated. The eCTD should include an option to provide a 'reference' operation attribute. For a new submission, primary location of a file would have the full metadata associated with it but at secondary locations, metadata could refer to the primary location in the backbone. Thus, when updating, it would only be necessary to update the operation attribute at the primary location, thus simplifying lifecycle maintenance and leading to the reduction of potential errors that would occur through updating only some of the links.||When the leaf ID will be mandatory (see 00240) this can be used to provide a reference to the primary entry in the backbone.
Explanatory notes will need to be provided on how to utilize the leaf ID e.g. when multiple instances of a document are required.
|Approved for specification change||Specification changed to Version 3.2|
|00350||EFPIA||EFPIA||Are .tiff files an acceptable format for provision with an eCTD submission or should they be converted to pdf?
tiff is a commonly used format for scanned documents – particularly legacy documents and CRFs.
|No, consult the section of the specification for acceptable formats||Approved for Q&A||No. 20|
|00360||EFPIA||EFPIA||The GxP requirements for signatures needs to be considered in the context of provision of multiple files for a study report – and in particular as it relates to an updated document.
Under GCP and GLP signatures are required and in a paper process these cover the whole report. So in an initial submission the signature provided in a report can be taken to cover the whole report and is contemporaneous. However, once into the lifecycle management process electronically, it is possible to update only certain files eg. a new appendix. Guidance needs to be provided regarding the GxP interpretations of signature applicability – namely when do signatures also need to be updated and how should the process be designed to demonstrate exactly what each version of a signature actually applies to.
|Has been taken to the CTD Coordination group November 2003||Out of scope|
|00370||FDA/PhRMA||FDA||ich-stf-stylesheet-1-0a.xsl internal:vocabulary4leaf-labels-file-tag||Change <item>randomisations-scheme</item> to <item>randomisation-scheme</item> and <item>iec-erb-consent-form-list> to <item>iec-irb-consent-form-list</item>
Use the singular form, randomisation, not the plural form of the word.
Correct a probable error in the iec-irb-constent-form-list value.
|Requestor asked to drop change request||Rejected|
|00380||EFPIA||EFPIA||Appendix 4||Where optional granularity is allowed the specification only defines file names at the lowest level. Advice should be given regarding what file names to use at the higher level.||Reference is made in the Specification to the M4 granularity document||Approved for specification change||Specification changed to Version 3.2|
|00390||FDA/EFPIA||FDA/EFPIA||Page 2-1||Currently states that ICH Web has empty template. No template exists||Empty folder structure will be provided||Approved for Q&A||No. 13|
|00400||EFPIA||EFPIA||Appendix 9||The page numbering in Appendix 9 of the Specification is incorrect. It starts with 9-14 and should be 9-1.||Minor change, can be made at next edit.||Approved for specification change||Specification changed to Version 3.2|
|00410||FDA||FDA||Tracking Table||Close 00180 and delete text in first paragraph of description column||Requestor asked to drop change request||Rejected|
|00420||Boehringer Ingelheim Pharmac. Inc.||FDA||Appendix 4: File Organization for the eCTD||We recommend that all sections of the eCTD Quality Module 3 be allowed the option of containing a single document, or multiple documents in each section and subsection. We agree that once a particular approach has been adopted (single or multiple documents), it should be maintained for the life of the dossier.||Single or multiple documents/files are already allowed in the eCTD. The eCTD Specification (appendix 4) needs to be updated and will be done at the next specification change.||Approved for specification change||Specification changed to Version 3.2|
|00430||Boehringer Ingelheim Pharmaceuticals Inc||FDA||Appendix 4: File Organization for the eCTD||The “2.3 Introduction to the Quality Overall Summary” (Item 11 in the eCTD File Organization) is redundant to the “2.2 CTD Introduction” (Item 10 in the eCTD File Organization).
We recommend that the “2.3 Introduction to the Quality Overall Summary” be deleted from the eCTD specification.
|Not in scope of eCTD, as it is a content issue. Discussion with CTD Q confirmed that there is no need for change, as the placeholder is already there in the CTD Q document. If the numbering is corrected in the CTD Q document, the eCTD will make this change as well.||Rejected|
|00440||FDA||FDA||DTD and Specification||Consider inclusion of Container/Closure system as an attribute||Deferred||until more experience with CTD
|00450||FDA||FDA||Specification v3.0, pages 6-3 through 6-9 and 8-2||Ensure that approved change request #00240 is the currently accepted way all regions are using Leaf ID with the modified file attribute.||Change specification to make leaf ID required at leaf level||Approved for specification change||Specification changed to Version 3.2|
|00460||EFPIA||EFPIA||STF specification & M4 Granularity Annex||Is it feasible for legacy reports to continue to be submitted as a single file/document without the need for splitting up into separate files/documents as per the STF and the Granularity Annex. Is there a specific date from which al reports should be structured in the CTD defined way?||Mixed submissions (legacy as one file and reports written according to STF) are acceptable at the moment. A time frame for the transition will have to be defined||Approved for Q&A||No. 22
|00470||EFPIA||EFPIA||Specification v3.0 & M4 Granularity Appendix||GLP and GCP inspectors expect to see consecutive page numbers across a report. CTD and eCTD allow page numbering by document/file. The two are incompatible.||Has been taken to the CTD Coordination group November 2003||Out of scope|
|00480||JPMA||JPMA||Specification v3.0, Appendix 5||The listing of media types for eCTD submission is not necessary. M2 recommendation on physical media and regional guidance should be referred to instead.||Correct at next specification change, section 5-2||Approved for specification change||Specification changed to Version 3.2|
|00490||JPMA||JPMA||Template Empty Folder Structure||Errors in template of empty folder structures||Update template folder structure||Approved||Empty Folder structure was updated Version 3.03|
|00500||JPMA||JPMA||Specification v3.0, Appendix 3||Errors in Appendix 3, Fig 3-3 and 3-4||Approved for specification change||Specification changed to Version 3.2|
|00510||JPMA||JPMA||Specification v3.0, Appendix 4||Inconsistency between line 23 and line 24 of Appendix 4 in the abbreviation of pharmacology||Correct line 24 to pharmacol||Approved for specification change||Specification changed to Version 3.2|
|00520||JPMA||JPMA||Specification v3.0, Appendix 2||The 256 maximum for length of path does not allow regulators to add to that path, if needed||Change page 2-4 the maximum length to 230 to allow regulators to add server names to the path (page 2-4)||Approved for specification change||Specification changed to Version 3.2|
|00530||ICH M2 IWG||ICH M2 IWG||Specification v3.0, Table 6-3||Clarify the operation attributes REPLACE and APPEND||Correct specification||Approved for specification change||Specification changed to Version 3.2|
|00540||EFPIA||EFPIA||Specification v3.2||For a submission that has been filed utilising v3.0, is it possible to move to v3.2?
Comment from vendors: "Some sponsors have already sent submissions using 3.0 and but may not realize that they have to stick with 3.0 for the rest of that applications life cycle as introduction of ID's and use of ID's in modified file attribute won't allow sponsors to change over to 3.2". Is this true and if so, what is recommended by the agencies? It does not seem practical to stay with an old version forever. Can this situation be rectified and how can it be avoided in future when the specification is updated again?
|The recommendation is that the ID is mandatory, even if using 3.0, to avoid compatibility problems;
For previously submitted files, consult with the Regulatory Agency to ascertain how to resolve the lifecycle issue.
|Approved for Q&A||No. 26|
|550||EFPIA||EFPIA||Specification v3.2||Clarification should be provided regarding any restrictions to character sets in the id value. According to the W3C definition an ID attribute value uses the "name" definition and must start with either a letter, an underscore or a colon and then can be followed by any combination of letters (upper or lower case), digits, period, hyphen underscore or colon. FDA has recently returned a pilot eCTD submission to J&J because the ID attribute value contained an underscore character. They stated that the syntax for the ID attribute must match the syntax of the file name (as specified in the ICH eCTD spec this means lower case letters, digits and hyphens only). They said the ICH spec stated this syntax for the ID attribute quoting page 2-4 and 2-5 of the version 3.2 spec as the basis for this statement. They also said the ID could not contain an underscore as it was being used in hyperlinks, and may be disguised by the formatting of the linking text (if it uses an underline).These two specs are not compatible. Clarification should be provided.||FDA agrees that underscores can appear in the leaf id, as long as it is not the first character||Rejected|
|560||EFPIA||EFPIA||Specification v3.2||Clarification should be provided by all ICH regions as to whether node extensions can be used in Modules 2-5
The ICH spec allows node extensions to be used in Modules 2-5 and their use in Module 1 is a regional matter. FDA states that node extensions are not supported in any part of the submission and this therefore invalidates the ICH spec. Experience on production of submissions for Europe demonstrates that node extensions are required to deliver a navigable structure for Modules 4 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 accept node extensions in Modules 2-5.
|FDA has concerns that node extensions might be over-used. Experience during the testing phase has confirmed the validity of these concerns. In many instances, the requirement for STF in the US eliminates the need for node extensions. There may be some occasions where the use of node extensions could be justified, and that should be discussed with FDA on a case by case basis. For the time being, other regions are able to accept appropriate use of node extensions in compliance with the eCTD specification ( i.e. their use is discouraged unless there is no other feasible means to submit the information). The IWG will review this situation.||Approved for Q&A||No. 28|
|570||EFPIA||EFPIA||Stylesheet||The ICH standard stylesheet does not adequately support the use of node extensions – the display is corrupted.
The ICH spec supports the use of node extensions at the lowest level. When node extensions are used, the stylesheet does not display the title of the file correctly. All files under that node extension are included in the title for each file. The attached screenshots demonstrate the issue.
Slide 1: xml source code
Slide 2: display in style sheet. Text in yellow box should be m5351 (plus node extension detail, ideally)
Slide 3: As displayed in the latest version of The DataFarm viewer(attached PPT slides)
|Approved||Stylesheet was rewritten|
|580||EFPIA||EFPIA||Specification v3.2||There are significant incompatibilities between the output of certain eCTD builder and viewer tools because of differences of interpretation of the spec and differing items being validated. ICH should develop a validation suite.
Recent experience within Europe (and US) has highlighted that the 'valid' output of one vendor product is not necessarily valid as input to another. This is leading to the need to test and correct submissions before filing. The incompatibilities are arising because one product is expecting certain items to be addressed in particular ways (although a specific way is not stated in the eCTD spec). This has led to incompatible interpretations. This could be avoided if a suite were to be developed by ICH which could be used by all tools.
|The issue has been recognised. 1st step is to define the criteria that the various vendors use for validation.||Approved for Q&A||No. 36|
|590||Datafarm Inc.||PhRMA||Specification v3.2||Is the file name for an individual file fixed from beginning to end of life cycle?||Answer in the negative||Approved for Q&A||No. 23|
|600||Datafarm Inc.||PhRMA||Specification v3.2||Regional XML reference in INDEX.XML
According to DTD and spec all documents submitted within the submission should have a reference (leaf) within the XML backbone. When amendments, variations, etc. are sent the appropriate Operation and modified file attributes should be used to maintain the life cycle of that document. Does this rule apply to the leaf that refers to regional XML file? Please note even though the actual document is controlled by the regional authorities the reference and life cycle management of this leaf/document lies within the ICH DTD.
|Approved for Q&A||No. 24|
|610||Datafarm Inc.||PhRMA||Specification v3.2||Application Form and Cover Letter Life Cycle…
According to DTD and spec all documents submitted within the submission should have a reference (leaf) within the XML backbone. When amendments, variations, etc. were sent the appropriate Operation and modified file attributes should be used to maintain the life cycle of that document. Does this rule apply to the leaf that refers to Application Form and Cover Letter that exists in all sequences? Also, this is something that is common across regions.Please note even though the actual document is controlled by the regional authorities it will be nice to have a common set of guidelines as they are common across regions.
|Refers to specific regional documents within Module 1. Consult regional guidance.||Out of scope|
|620||Datafarm Inc.||PhRMA||Specification v3.2||Text file with MD5 Value and cover letter…
The MD5 value for index.xml in a Text file is clearly specified in the spec. Still it led to some confusion with interpretation. Please clarify:
1. There is only one index-md5.txt with index.xml md5 value stored within that file per sequence and it stays along with index.xml.
2. There is no need for index-md5.txt for regional xml file as this MD5 value is already present in the index.xml
3. It is impossible to generate the MD5 value and place that value in the cover letter (page 5-2). This will change the MD5 value of the cover letter, regional xml and index.xml. May be this can be placed on the Media Label.
|In appendix 5, the eCTD Specification requires a paper cover letter that is also to be submitted as a pdf (cover.pdf) not linked to the backbone. This is the cover letter to which the md5 text is to be added as an appendix. These matters are also dealt with in regional guidance.||Approved for specification change||Next minor release|
|630||Datafarm Inc.||PhRMA||Specification v3.2||The ID value requirement is not clear and requires additional specifications.
Per ICH specifications on page 6-8 it states…“Unique identifier for this file in the XML instance. Leaf ID must start with a character.”
It will be nice if this clearly states that ID value should:
-Start with alpha character
-Only alpha and numeric values are allowed and no symbols or special characters
-No spaces are allowed
-Length of the ID value should not exceed "n" characters
Regional review systems have their own limitations in terms of length of the leaf attribute values such as title. It will be nice if ICH controls these just like they are controlling href maximum length and file name maximum length.
|With the exception of the requirement that the id must start with an alpha character, there are no limitations on the contents of these fields, subject to technical limitations.||Rejected|
|640||GSK||EFPIA||Specification v3.2||There is an inconsistency in the description of the maximum file size
Appendix 7: Specification for Submission Formats of the eCTD, page 7-1:
the guidance states: "To ensure that PDF files can be accessed efficiently, PDF files should be no larger than 100 megabytes." However, on page 7-4 of the eCTD Specification, under Page Numbering, the guidance states "Two exceptions to this rule can occur (see details in the guidance for the modules of the CTD. First, where a document is split because of its size (e.g., >50MB), the second or subsequent file should be numbered consecutively to that of the first or preceding file."For consistency, the latter occurrence should be updated to 100MB.
|This is a typographical error in the specification. The maximum file size is 100 MB, not the 50 MB given in the example.||Approved for specification change||Next minor release|
|650||Centocor BV||EFPIA||Specification v3.2, Appendix 4, file organization for Module 3.2.S||File organisation to support manufacturer should be consistent across Modules 2.3.S, 2.3.P, 3.2.S and 3.2.P. At present 3.2.S. is subdivided per substance/manufacturer, 3.2.P has only subdivision by product while 2.3.S and 2.3.P have no subdivisions. Can subdivisions for manufacturer in all sections be defined? See also change request 660
||For Modules 2.3.S and 2.3.P it is already possible to differentiate by manufacturer, by the file name & by attributes.
For Module 3.2.P, refer to CTD Q how they see the organisation of 3.2.P and its subsections.
|Rejected||Refer second part to CTD Q|
|670||Centocor BV||EFPIA||Specification v3.2||To prevent maintenance of identical copies of documents, it should be possible to make a link to the appropriate document elsewhere in the same submission or any of the previous submission in the eCTD life cycle.Examples are given in the original change request.
This could be achieved if an additional operation attribute (e.g. "link") is allowed, next to new, append, replace, delete.
| A file should only be included once within a single sequence.
The requirements for references to one file across sequences are different in each region.
The eCTD EWG will address the "link" concept as it relates to single sequences as part of lifecycle in the next major release.
|Approved for Q&A||No. 38|
|680||Aventis||JPMA||ICH eCTD Style Sheet||ICH eCTD Style sheet cannot work for “Node-Extension” xml-instance||Approved||Stylesheet was rewritten|
|690||GSK||EFPIA||Specification v3.2||Moving to a new version of a specification during the lifecycle of a product.
Do you expect that we would stay with a given DTD version for the duration of an application, so that as long as we are submitting to the same application we would use the same DTD version as used for the original submission, or would we be expected to apply new versions of the DTD within a certain time period, across all submissions regardless of whether they are new or ongoing?
Also, if there is a need to change DTDs, how will the agency viewing tools present the cumulative view if there is a structural change to the submission eg. renaming of old sections, introduction of new sections etc.
|Approved for Q&A||No. 27
|700||Lorenz||EFPIA||Specification v3.2||Can an eCTD be submitted that covers more than one region?
If the content of Modules 2-5 in a submission is to be the same between two or more regions is it allowable to submit more than one Module 1 in the same eCTD?
|Approved for Q&A||No. 29|
|710||Lorenz||EFPIA||Specification v3.2||Are vendor specific style sheet allowed? Style sheets may include function to redirect reference links to other files.||Approved for Q&A||No. 30|
|720||Lorenz||EFPIA||Specification v3.2||Is an MD5 value required for the regional index file
Are regional MD5 checksum files (##-regional-md5.txt) mandatory, optional or not allowed?
|Approved for Q&A||No. 31|