{"text_format":"2","workbook":"xls","n_sheets":6,"sheets":["Cover","Intro","Q&A","Q&A No. 36","Change Requests","Retired Q&A"],"not_rendered":{"charts":0,"images":5,"macros":0,"external_links":1,"defined_names":31,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"run_cost":"one","rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900","formulas":"cached_only"}

{"sheet":"Cover","index":0,"n_rows":37,"n_cols":4,"rows_kept":37,"cut":false,"hidden":false,"merged":[[1,0,1,4],[2,1,2,3]],"flags":["formulas_cached_only"]}
[]
["国际人用药品注册技术协调会\n\n\neCTD IWG问题解答和规范变更要求文件\n\n版本1.31\n2018年6月5日"]
[null,"文件变更记录"]
[null,"版本号","日期","说明"]
[null,"版本1.0","2003-01-01","审查提交给ICH的问题后的初始基线"]
[null,"版本1.1","2003-02-01","ICH筹划指导委员会会议（东京）"]
[null,"版本1.2","2003-07-01","ICH筹划指导委员会会议（布鲁塞尔）"]
[null,"版本 1.3","2003-07-01","ICH筹划指导委员会会议（布鲁塞尔）FDA律师评论"]
[null,"版本 1.4","2003-07-01","ICH筹划指导委员会会议（布鲁塞尔）会后"]
[null,"版本 1.5","2003年11月","ICH筹划指导委员会会议（大阪）"]
[null,"版本 1.6","2004-01-01","IFPMA格式化问题通知后"]
[null,"版本 1.7","2004-06-01","ICH筹划指导委员会会议（华盛顿）"]
[null,"版本 1.8","2004年11月","ICH筹划指导委员会会议（横滨）"]
[null,"版本 1.9","2005年5月","ICH筹划指导委员会会议（布鲁塞尔）"]
[null,"版本 1.10","2005年11月","ICH筹划指导委员会会议（芝加哥）"]
[null,"版本 1.11","2006年6月","ICH筹划指导委员会会议（横滨）"]
[null,"版本 1.12","2006-10-01","ICH筹划指导委员会会议（芝加哥）"]
[null,"版本 1.13","2007-05-01","ICH筹划指导委员会会议（布鲁塞尔）"]
[null,"版本 1.14","2007-11-01","ICH筹划指导委员会会议（横滨）"]
[null,"版本 1.15","2008年6月","ICH筹划指导委员会会议（波特兰）"]
[null,"版本 1.16","2008年11月","ICH筹划指导委员会会议（布鲁塞尔）"]
[null,"版本 1.17","2009年6月","ICH筹划指导委员会会议（横滨）"]
[null,"版本 1.17.1","2009年8月","纠正Q&A 49和5个已取消Q&A的排版问题（6、11、15、25和28）——内容不变"]
[null,"版本 1.18","2009年10月","ICH筹划指导委员会会议（圣路易斯）"]
[null,"版本 1.19","2010年6月","ICH筹划指导委员会会议（塔林）"]
[null,"版本 1.20","2011年6月","ICH筹划指导委员会会议（辛辛那提）"]
[null,"版本 1.21","2011年11月","ICH筹划指导委员会会议（塞维利亚）"]
[null,"版本 1.22","2012年6月","ICH筹划指导委员会会议（福冈）"]
[null,"版本 1.23","2012年11月","ICH筹划指导委员会会议（圣地亚哥）"]
[null,"版本 1.24","2013年6月","ICH筹划指导委员会会议（布鲁塞尔）"]
[null,"版本 1.25","2013年11月","ICH筹划指导委员会会议（大阪）"]
[null,"版本 1.26","2014年6月","ICH筹划指导委员会会议（明尼阿波利斯）"]
[null,"版本 1.27","2015年6月","ICH筹划指导委员会会议（福冈）"]
[null,"版本 1.28","2016年6月","ICH大会会议（里斯本）"]
[null,"版本 1.29","2016年11月","ICH大会会议（大阪）"]
[null,"版本 1.30","2017年8月","ICH大会电子签名"]
[null,"版本 1.31","2018年6月","ICH大会会议（神户）"]

{"sheet":"Intro","index":1,"n_rows":1,"n_cols":1,"rows_kept":1,"cut":false,"hidden":false,"merged":[[0,0,0,12]],"flags":["formulas_cached_only"]}
["前言\n\n本问答文件是eCTD实施工作组（IWG）审查eCTD规范问题的摘要。在此解答的问题与所有三个ICH区域内eCTD相关常见问题有关。在步骤2规范中收到的许多问题已在步骤4中得到解决，但未在此列表中列出。有关区域特定申请类型的实施时间框架、模块1实施、生命周期管理的问题，以及那些与规范中引导读者至每个区域的项目相关的问题，将在每个区域发布的指南文件中一一解答。\n\n有关《通用技术文件》（CTD）目录的问题，请访问ICH网站的CTD问答部分。\n\n到目前为止提出的一些问题涉及对eCTD规范的变更请求。本文件的变更请求部分将对eCTD IWG收到的所有项目进行处理，并标明这些项目的状态。\n\n本文件将根据施行的规范的变更控制或向eCTD IWG提交的新问题更新。"]

{"sheet":"Q&A","index":2,"n_rows":49,"n_cols":5,"rows_kept":49,"cut":false,"hidden":false,"merged":[[13,0,14,0],[13,1,14,1],[13,3,14,3],[13,4,14,4]],"flags":["formulas_cached_only"]}
["编号","问题","回答","获批日期","状态"]
[8,"评审人员如何查看和使用“append（补充）”操作属性？澄清各机构内的审查工具如何处理这些属性也将帮助到我们。","eCTD规范涉及从申请人到监管机构的电子CTD传输。有关各区域用于查看此格式的电子审查工具，请咨询各区域的监管当局。","2003年2月"]
[12,"eCTD规范允许在3.2.A.3中使用一种新型赋形剂。如果有不止一种新型赋形剂应该怎么处理？\n\n该问题出现在变更请求00050中。","在解决变更请求之前，应咨询监管机构，寻求解决方案。","2003年2月"]
[14,"eCTD中对使用数字签名持何立场？\n\n该问题由变更请求00280生成","目前，M2专家工作组还没有解决这个问题的计划。有关目前数字签名的使用，请参阅区域指南。","2003年7月"]
[16,"可否对提供全文索引（例如Adobe目录文件）的必要性进行澄清？如果各机构需要，应如何在主干文件中的何处列出全文索引？\n\n该问题由变更请求00310生成","任何ICH区域机构都不要求提供全文索引，因此无需提供指导。","2003年7月"]
[20,".tiff文件是否是eCTD提交中可接受的提供格式，还是应该转换为.pdf？\n\n该问题由变更请求00350生成","eCTD规范中不支持.tiff文件类型。请参阅规范中有关可接受格式的章节（附录7）。","2003年7月"]
[22,"遗留报告是否可以继续作为单个文件/文档提交，而不需要按照M4组织粒度结构附件将其拆分为单独的文件/文档？\n\n是否有一个特定的日期，自该日期起，所有报告均应按照M4组织粒度结构附件所述方式进行结构化？\n\n该问题由变更请求00460生成","对于已经生成或目前正在生成的研究报告，如果这是其创建方式，则认为可以将其作为单一文件提交。\n\n建议使用M4组织粒度结构附件所述粒度结构创建新的报告。","2003年11月"]
[24,"区域（模块1）主干xml文件的操作属性是否始终为new（新建）？\n\n该问题由变更请求00600生成","请参阅区域指南。","2004年6月","已纳入eCTD规范v3.2.1第6-2页\n根据变更请求1870于2008年11月进行更新；未纳入eCTD规范v3.2.2，但将在下一个次要版本的发布中增加此内容，且此回复仍然有效。"]
[26,"如果申请人使用规范v3.0提交eCTD，如何确保与版本3.2的正向兼容性？\n\n该问题由变更请求00540生成","建议申请人使用ID，即使使用3.0，也可避免将来的兼容性问题；\n对于以前提交的文件，请咨询监管机构，以确定如何解决生命周期问题。","2004年6月"]
[27,"是否应在整个申请过程中保留给定的DTD版本，以便只要是为同一申请提交资料，都可以使用与初始提交资料相同的DTD版本？\n\n或者，在某个时间段内，提交的所有资料均应采用DTD的新版本，无论是新提交还是持续提交的资料？\n此外，如果需要更改DTD，而提交资料的结构发生变化，那么该机构的阅读工具将如何呈现累积视图，例如，旧章节的重命名、新章节的引进等。\n\n该问题由变更请求00690生成","申请人应该使用各个区域接受的当前DTD。M2专家工作组和这三个地区的机构将就何时使用新版本提供指导。新版本的实施时间将根据需要确定。法规变更(例如CTD中的变更)可能必须立即实施，而技术变更可延迟到在主要的新版本中进行。","2004年11月"]
[35,"能否对相关序列元素做进一步澄清？\n\n该问题由变更请求00890生成","相关序列在不同区域中的使用方式不同。详细信息请参阅区域指南。","2005年5月"]
[36,"根据IWG的eCTD经验，用户通常会对规范的哪些部分产生误解，而其他申请人/监管机构可能因此无法查看我的eCTD信息？\n\n\n该问题由变更请求00580生成","根据经验，对eCTD规范的不同解释，将导致无法及时交换eCTD申报资料。创建和查看eCTD消息者应遵守eCTD规范（ICH和区域性），并与区域当局协商以避免这些问题。下面列表中的项目(本文件的Q&A第36号工作表)已经存在于规范3.2中，但为了缓解这些问题，在此进行了总结。在交换eCTD消息时，必须严格遵守这些项目。额外的限制可能会妨碍eCTD消息的交换。IWG将继续监测eCTD的实施情况，以提供更高的透明度。\n\n项目12和20于2007年5月11日更新\n项目11和20于2009年6月10日更新","2005年5月\n\n\n\n\n\n2007年5月\n2009年6月"]
[48,"可否提供关于“index-md5.txt”文件格式的额外指导？\n\n该问题由变更请求01730生成","“index-md5.txt”文件应仅包含相应“index.xml”文件的MD5 checksum的32个字符。在此值之前或之后不应有其他字符(包括回车和其他非打印字符)。","2008年6月"]
[49,"可否提供关于如何处理缺失属性值的额外指导？\n\n该问题由变更请求01740生成","eCTD DTD定义了两种类型的“attributes（属性）”：\n包含leaf元素的属性（例如，id、checksum、operation等）和用于定义重复单元上下文的属性（例如，3.2.S的“substance（物质）”属性、5.3.5的“indication（适应症）”属性等）。eCTD DTD将这些属性定义为必需的(即技术上必需的)或隐含的(即可选的)。\n\n对于所有“implied（隐含的）”属性，如果没有为该属性赋值，则应该忽略该属性。例如，2.3.P隐含了“product-name（产品名称）”、“dosageform（剂型）”和“manufacturer（制造商）”属性。如果申办方选择为这些属性赋值（例如，分别赋值为X药物、片剂、X公司），则index.xml可以包含以下语句：\n<m2-3-p-drug-product dosage-form=\"Tablets\" manufacturer=\"Company X\" product-name=\"Drug X\"> \n[注：这些属性可以按任何顺序提供]\n\n如果申办方选择只为“product-name（产品名称）”和“dosageform（剂型）”属性赋值，则index.xml将包含以下语句：\n<m2-3-p-drug-product dosage-form=\"Tablets\" product-name=\"Drug X”> \n无需提供“manufacturer（制造商）”语句，因为没有为该属性赋值。\n\n","2008年6月"]
[null,null,"所有技术上“必需”的属性均应赋值，否则文件将无效。每个leaf元素在技术上有四个必需的属性：ID、operation、checksum和checksum-type。具有删除操作的leaf元素不会调用xlink:href属性值。因此，“checksum（校验和）”和“checksum-type（校验和类型）”属性通常没有适当的赋值。在日本，“checksum（校验和）”属性值将为空[即，双引号之间无条目（checksum=“”）]，“checksum-type（校验和类型）”属性值应为“md5”。在所有其他区域中，“checksum（校验和）”和“checksum-type（校验和类型）”属性值将为空。"]
[50,"ICH eCTD Q&A的问题30表示，申请人应就在提供其自身样式表的可接受性方面寻求区域指导。ICH M2/ESTRI网站已经发布ICH样式表的校验和（checksum），我们知道如果提供的样式表的校验和与发布的值不匹配，某些eCTD验证工具将报错。\nICH可否对申请人创建的样式表的可接受性给出任何进一步的指导？\n\n该问题由变更请求01750生成","每个eCTD都应该包含已批准的ICH和区域样式表，用于eCTD将发送到的相关区域或国家。\n\nICH现在建议申请人不要向监管机构提交其自身的样式表，而应该提交经ICH和区域核准、唯一可接受的样式表。\n\n请参阅区域指南，确定在特定区域内应该使用的样式表版本。","2008年6月"]
[51,"util/dtd和util/style文件夹的内容是否有任何限制？\n\n该问题由变更请求01760生成","这些文件夹的内容存在一些限制。通常，文件夹内容仅限于支持eCTD的结构、验证和查看的ICH和区域文件。该说明适用于ICH和区域DTD、区域支持文件（例如eu.mod文件）、验证所需的文件（例如valid-values.xml文件）以及ICH和区域样式表文件。其他杂项文件不得使用这些文件夹。\n\n应提供相关的ICH和区域文件，以支持特定的eCTD申报资料和拟提交eCTD的区域要求。这些文件夹可以包含ICH和其他区域允许的区域文件，而且不会导致任何验证问题。","2008年6月"]
[52,"Leaf ID在eCTD序列中或XML实例中是唯一的吗？\n\n该问题由变更请求01770生成","eCTD主干XML实例中的leaf ID应该是唯一的，否则文件将无效，因为重复值将导致解析错误。Leaf ID在序列中的唯一性并不是技术要求。对leaf ID的引用总是包含XML实例的路径和文件名，因此需要为leaf提供唯一标识符。","2008年6月"]
[53,"eCTD中的所有PDF文件都必须有书签吗？\n\n该问题由变更请求01820生成","任何有目录（TOC）的文档都应该有书签（有关详细信息，请参阅eCTD规范）。没有TOC的文档也应该包含书签，这样可为导航文档内容提供辅助。例如，一个4页的研究结果总结文档可能需要书签来辅助导航。而一个300页包含单一数据列表的文件可能不需要书签，因为文档中没有其他内部结构。有关详细信息，请参阅区域指南。","2008年6月"]
[54,"eCTD文件夹结构是否可以包含空文件夹（即不包含其他文件夹或文件的文件夹）？\n\n该问题由变更请求01830生成","不得提交空文件夹。","2008年6月"]
[55,"eCTD规范建议将PDF 1.4作为所有地区唯一可接受的版本。ICH对其他PDF文档属性是否有任何建议？\n\n该问题由变更请求01840生成","使用其他PDF视图工具时，设置可能会有所不同。但是，在Acrobat 7中，可以通过单击“文件>文档属性”找到文档属性，然后可以找到以下选项卡。\n说明选项卡——申请人应确保该文件使用Q&A #71中指定的PDF版本PDF 1.4，或符合区域指南的其他版本。应对文件进行优化，以便进行快速的网络浏览。ICH未针对此选项卡上的任何其他字段提出建议。\n安全选项卡——如eCTD规范所述，单个文件不应该具有任何安全设置。\n字体选项卡——eCTD规范中纳入了使用字体和嵌入的提议。\n初始视图——ICH建议使用以下设置：显示 = 书签面板和页面；页面布局 = 默认；放大倍数 = 默认；打开第1页\n对于以上未明确提及的任何单个设置，ICH未提出建议。","2008年6月\n\n2013年6月"]
[56,"如何使用leaf说明中的申请版本属性？\n\n该问题由变更请求01850生成","申请版本属性仅应在以下情况下使用：\n对于PDF中具有相关内容的leaf元素，应使用申请版本指明PDF版本（例如，PDF 1.4）。要识别PDF版本，请在Acrobat中打开PDF文件，然后单击“文件>文档属性”，可以在“说明”选项卡上找到该PDF版本。","2008年6月"]
[57,"可否澄清xml:lang属性的正确用法？\n\n该问题由变更请求01860生成","目前未在ICH eCTD主干中使用xml:lang属性。请参阅区域模块中有关此属性用法的区域指南。","2008年6月"]
[58,"是否要求模块3结构性元数据的值（在模块3.2.S中，这些值为原料药名称和制造商；在模块3.2.P中，这些值为制剂名称、剂型和制造商）也必须用作模块文件夹的名称？\n\n该问题由变更请求01880生成","否。技术上未要求元数据值必须与目录结构中的文件夹名称完全相同。此外，工具供应商应该使用户能够为元数据和文件夹分别设置不同的值，因为这将使用户能够管理文件夹/文件路径的总体长度，而不会影响结构性元数据的描述性值。","2008年11月"]
[59,"是否需要跨序列维护相同的文件夹名称？例如，物质名称 \n\n该问题由变更请求01890生成","否。在适当的情况下，可以跨序列更改文件夹名称，例如由于文件夹名称过长。此外，eCTD构建工具不得强制要求跨序列维护文件夹名称。","2008年11月"]
[60,"是否允许从同一主干实例或另一个序列中的多个leaf引用单个STF文件？\n\n该问题由变更请求01780生成","由于管理每个使用实例的生命周期需求的潜在问题，不建议这样做。不得提交具有同一研究ID的多个STF。","2008年11月"]
[61,"是否允许在STF文件中引用同一主干实例或另一个序列中的另一个eCTD元素中的leaf元素？\n\n该问题由变更请求01790生成","由于存在管理每个使用实例的生命周期需求的潜在问题，不建议这样做。不得提交具有同一研究ID的多个STF。","2008年11月"]
[62,"为了符合STF规范中题为“在CTD的不同子章节中呈报一项研究的信息”的章节的规定，是否允许在主干的两个不同位置提供具有同一研究ID的多个STD文件？\n\n该问题由变更请求01800生成","在提交属于多个eCTD子章节的单项研究的结果时，应创建单个STF，并将其与单个子章节相关联。对于该研究涉及的额外的每个子章节，申办方应提交单份文件，记录可以找到STF的子章节。\n\n如果希望能够保留在单个子章节下控制研究报告生命周期的能力，而不是提交单个文件，将需要提交额外的STF文件和附带的leaf。多个STF的研究id应由独特的研究标识符组成，并附有明确的后缀，例如，ADME123-absorption、ADME123-distribution。不得提交具有同一研究ID的多个STF。","2008年11月"]
[63,"为了遵守STF规范中题为“区分CTD同一子章节中的时间特异性分析”的章节的规定，是否允许在同一位置提供具有同一研究ID的两个STF文件，并使用研究标题对两组进行区分？是否允许或建议为研究ID添加后缀对两组进行区分？\n\n该问题由变更请求01810生成","具有同一研究ID的两个STF文件将被视为同一研究。不可能通过研究标题进行区分。为研究id添加后缀将支持区分，例如，abc123-6month、abc123-12month。","2008年11月"]
[64,"eCTD申报资料中可否引用网站或包含URL？\n\n该问题由变更请求01960生成","一般而言，申请人引入的参考文献应包括在申报资料中（参见模块5.4的M4E (R1)指南和eCTD规范v3.2.2附录2，链接，第2-2页)。由于无法保证网站链接在文档的生命周期内始终保持有效，因此不得使用URL链接。有关模块1中URL的使用，请参阅区域指南。","2009年6月"]
[65,"模块3中使用的XML结构是否必须与模块2中使用的XML结构匹配？例如，如果模块3为两个原料药制造商分别设立了单独的章节，并且分别具有各自的XML属性，那么模块2可否用一个单独的质量综述（QOS）章节涵盖这两个制造商？\n\n该问题由变更请求650、660、1420、1430和1540生成","模块3中使用的XML结构不需要与模块2.3中使用的XML结构匹配。\n\nICH M4粒度结构附件在技术上允许的最小粒度结构选项是一个涵盖所有模块2.3主题的文件，在这种情况下，技术上不需要XML属性。如果申请人使用更精细的粒度结构结构，例如2.3.S，则可以使用“substance（物质）”和“manufacturer（制造商）”单独的XML属性值提供一个文件（或多个文件，具有唯一的leaf标题）。在这种情况下，2.3.S和3.2.S属性值可以不同；例如，2.3“制造商”的“all（全部）”，与多个3.2.S“制造商”章节各自的特定属性值（另请参见Q&A #67）。如果申请人使用最细化的选项，例如2.3.S.1，则应提供附带“substance（物质）”和“manufacturer（制造商）”XML属性值的文件。有关任何粒度结构结构限制，请参阅区域指南。\n\n请注意，对于所有粒度结构结构选项，文件可以位于一个名为23-qos的目录文件夹中，如果是这样，则所有文件名在技术上必须是唯一的，无论使用何种XML属性值。","2009年10月"]
[66,"是否需要模块2和模块3的XML属性来标识原料药“substance（物质）”和“manufacturer（制造商）”，或者仅当每种都不止一个时才需要？\n\n该问题由变更请求650、660、1420、1430和1540生成","在技术上，需要模块2（“2.3.S原料药”）和模块3（“3.2.S原料药”）中的XML原料药元素。当前的文档类型定义（DTD）在技术上要求呈现这些属性（即，在DTD中指定为“#REQUIRED”）。\n\n“substance（物质）”属性主要用于区分固定剂量复方制剂中的不同原料药或共同包装的不同制剂。通常建议此属性使用INN名称。\n\n“manufacturer（制造商）”属性旨在促进生命周期管理，在这种情况下，同一原料药可能存在不同的制造商，每个制造商可能使用不同的合成途径（化学实体）或制造过程（生物制剂）。如果申请人确定不需要为每个原料药制造商编制单独的3.2.S章节，例如，如果很少的3.2.Sx主题有制造商/研究中心特异性文件（现在或可能是将来），那么可以使用一般的伞状术语，例如“所有”或“申请人”或“未指定”。（使用伞状术语并不会妨碍今后出现新的制造商可能拥有其自身XML属性的情况。）但是，对每个属性进行简短的信息描述就足够了，因为目前使用这些描述符是为了帮助申请查看者(例如，以便区分不同的原料药章节)，而不是为了计算机化数据管理。","2009年10月"]
[67,"对于所需的原料药XML属性“substance（物质）”和“manufacturer（制造商）”，可否澄清应包括哪些描述性文本？\n\n该问题由变更请求650、660、1420、1430和1540生成","这些属性旨在为申请查看者提供潜在leaf元素的简短信息描述，并在适用时区分S.1至S.7的不同章节（即，只有经判断认为拥有单独的章节可提供一些益处时）。因此，无需对应任何受控词汇表。\n\n由于INN名称通常较短，因此建议将其用于“substance（物质）”属性。更长的INN名称应予以缩短。如果没有INN，则使用公司代码即可。“manufacturer（制造商）”同样应简短且具有描述性。例如，“manufacturer（制造商）”可以是公司名称或长公司名称的第一个单词或缩写，和/或可以包括研究中心，如果与区分多个研究中心相关。如果不需要为每个原料药制造商编制单独的3.2.S（和2.3.S）章节，例如，如果很少的3.2.Sx主题有多个文件（现在或可能是将来），那么可以使用一般的伞状术语，例如“所有”或“申请人”或“未指定”。","2009年10月"]
[68,"是否需要模块2和模块3的XML属性来标识制剂“product-name（产品名称）”、“manufacturer（制造商）”和“dosageform（剂型）”，或者仅当每种都不止一个时才需要？\n\n该问题由变更请求650、660、1420、1430和1540生成","根据当前的XML文档类型定义（DTD），这些属性是可选的（即在DTD中指定为“#IMPLIED”），从技术上来说，这两个模块都不需要这些属性。\n\n在实践中，如果批准多个3.2.P章节，则包含这些属性可能会有帮助（例如，如果每个属性中有多个主题）。此外，部分属性可能适合用于第一次提交的申报资料，以便能够区分后来的CMC修订，例如，用于生产线扩展。由于目前使用该描述符是为了帮助申请查看者，而不是为了计算机化数据管理，因此提供每个属性的简短描述即可。","2009年10月"]
[69,"如果要提供制剂“manufacturer（制造商）”，是否可以确认，制剂制造商与原料药制造商不同是可接受的，因为一些eCTD工具似乎强制要求相同？\n\n该问题由变更请求650、660、1420、1430和1540生成","制剂制造商可不同于原料药制造商，在这种情况下，他们的描述符可能也会不同。","2009年10月"]
[70,"对于可选的制剂XML属性“product-name（产品名称）”、“manufacturer（制造商）”和“dosageform（剂型）”，是否可以澄清应包括哪些描述性文本？\n\n该问题由变更请求650、660、1420、1430、1540和1570生成","首先回想一下，包含其中任何一个属性都是可选的。这些属性旨在提供对潜在leaf元素的简短信息描述，并在适用时区分P.1至P.8章节组（即，只有经判断认为拥有单独的章节可提供一些益处时）。因此，XML属性无需对应任何受控词汇表。\n申请人决定如何使用这些属性。“product-name（产品名称）”可以包括，例如，INN（或缩写INN）。其可以用于区分“active（活性）”和“diluent（稀释剂）”制剂章节，如适用。此外，“product-name（产品名称）”描述符还可以用于区分，例如，“A-type（A型）”与“B-type（B型）”药品制剂，和/或包括规格信息（例如，如果可以证明为另一规格划分单独章节是合理的）。或者，这种区分（以及其他，如同一剂型多种规格的区分）可包涵在一个章节的内容中（例如，比较表中），而不是在元素属性中进行描述，特别是在大多数信息在该章节中通用的情况下。\n虽然商品名称也可以用作属性值，但不建议这样做，因为当局并不一定会接受拟议商标。在提交eCTD申请后，才能知道商标的可接受性。根据当前的ICH eCTD规范，随后将无法修改已提交章节的属性条目。\n如果需要条目，则“manufacturer（制造商）”可以是公司名称，或者是一般的伞状术语，例如“所有”或“申请人”或“未指定”。或者，例如，其可以是公司名称或长公司名称的第一个单词或缩写，也可以包括研究中心，如果与区分多个研究中心相关。\n“dosageform（剂型）”可以由简短的描述性文本组成，例如“混悬剂粉末”或“稀释剂”。","2009年10月\n\n\n\n\n\n2012年6月"]
[71,"PDF 1.7（ISO 32000）的ESTRI建议得到有限制的支持。ICH应该澄清现在可以接受哪些版本的PDF。\n\n该问题由变更请求2010生成","PDF 1.4和1.7(根据ESTRI建议所确定的限制条件)现在可以在所有ICH区域使用。\n有关提交其他版本的信息，请咨询地区当局。\n所有ICH监管机构现在都接受PDF 1.4、1.5、1.6和1.7，限制条件如M2建议中所述。","2011年6月\n2011年11月"]
[72,"是否必须使用3.2.P.4（赋形剂控制）中的“excipient（赋形剂）”属性？\n\n该问题由变更请求100、1380、1410和2030生成","否。不必使用该属性（即，即使制剂中含有多种赋形剂，也只能有一个赋形剂章节）。“excipient（赋形剂）”属性是可选的，即，在技术上来看，模块3中的XML元素不是必需的。但是，如果使用重复的3.2.P.4章节，则应使用“excipient（赋形剂）”属性，识别和区分章节内容。\n如果使用，则属性条目由申请人决定。一般术语（例如，“all（所有）”、“compendial（药典）”、“coating agent（涂层剂）”、“non-compendial（非药典）”）和/或特别命名的赋形剂条目是可接受的。","2011年11月"]
[73,"赋形剂文件的内容往往很少。是否可以澄清赋形剂的粒度结构？\n\n该问题由变更请求100、1380、1410和2030生成","可以提交涵盖一个或多个每种赋形剂、所有赋形剂、每种赋形剂主题（即，3.2.P.4.1至3.2.P.4.6）或所有赋形剂主题的文件。\n\n选项1（使用单个3.2.P.4章节，没有任何更低级别的粒度结构）：如果总体信息量很小，例如仅使用药典赋形剂时，这个选项很有吸引力。在这种情况下，通常仅在3.2.P.4级别*提交一个文件，有或没有“excipient（赋形剂）”属性，该文件将覆盖所有使用的赋形剂和赋形剂主题（即，3.2.P.4.x）。\n选项2 （使用多个3.2.P.4章节，3.2.P.4.x没有更低级别的粒度结构）：每种赋形剂或赋形剂组可以在3.2.P.4级别*（而不是在3.2.P.4.x级别）提交一个或多个涵盖相关赋形剂主题的文件，。“excipient（赋形剂）”属性可用于识别赋形剂名称或组名称（例如，“药典”）。可以使用单个文件涵盖所有主题（3.2.P.4.x）或分别涵盖每个主题。\n选项3 （使用具有3.2.P.4.x粒度结构的多个3.2.P.4章节）：每种赋形剂（CTD主题）可以在相应的3.2.P.4.x级别提交一个或多个文件。可以使用信息性eCTD标题区分同一3.2.P.4.x级别的多个文件（例如，每种赋形剂或赋形剂组的单独文件，分别涵盖一个3.2.P.4.x主题）。\n\n选项2和3在申报资料中可以合并。例如，可以在一个章节（选项2）中在3.2.P.4级别提供单个涵盖所有药典赋形剂（即，一组（例如）赋形剂属性为“compendial（药典）”的赋形剂）的文件，而在相关的3.2.P.4.x级别（选项3）提供命名或分组（例如，“coating agent（涂层剂）”）为非药典赋形剂章节的多个更精细的文件。\n\n对于所有选项，如果未使用人源、动物源和/或新型赋形剂，在粒度结构问题上就无法达成ICH共识。参考区域指南，该指南承认“excipient（赋形剂）”属性（如“Human（人源性）、Animal（动物源性）、Novel（新型）”）可能划分为单独的章节。\n关于赋形剂粒度结构的考虑因素包括：例如，提供的信息量和未来生命周期潜力、全球文档生成的业务流程和来源以及全球市场信息的可重复利用性。\n由于目前使用赋形剂描述符是为了帮助申请查看者，而不是为了计算机化数据管理，因此如果内容仅仅是对药典专论的引用，应避免每种药典赋形剂使用多个文件的情况。\n\n*虽然这种将文件放在标题P.4下的方法似乎不符合2005年10月最初发布的“M4粒度结构附件”的规定，但是对于eCTD申报资料仍然是可接受的，并且符合eCTD规范V3.2.2。如果使用，建议单个文件的文件名为“excipients.pdf”，多个文件的文件名为“excipients-var.pdf”，其中var = 区分文件的变量部分。\n\n\n\n\n\n","2011年11月"]
[74,"赋形剂列表应放在eCTD结构中的什么位置？\n\n该问题由变更请求100、1380、1410和2030生成","根据ICH M4Q，剂型的所有组分均应在3.2.P.1中列出（制剂的描述和组成），每个组分都有其功能和质量标准参考（例如，药典专论、制造商规范）。在章节3.2.P.4（赋形剂控制）中，ICH希望在3.2.P.4.1（规范）中提供赋形剂规范。在某些情况下，选择在3.2.P.4中重新列出赋形剂或链接回3.2.P.1中的列表可能会有帮助，但ICH不希望在3.2.P.4中重复赋形剂列表。","2011年11月"]
[75,"申请人应如何管理变成药典赋形剂的非药典赋形剂、重命名的赋形剂或不再被视为新型赋形剂的新型赋形剂的生命周期？\n\n该问题由变更请求100、1380、1410和2030生成","绝不得仅仅为了修订元数据或重新定位有效文件提交eCTD申报资料。此类变更应与该申请的另一修正案同时进行。在可能应用属性调整或重新定位文件之前，请咨询地区当局或查阅区域指南，和/或通知监管机构因技术障碍和预期的eCTD版本更新而导致的任何变更延迟。\n不得使用以下两个选项修改元数据：1)不得跨CTD章节分割leaf的生命周期，即，在新的CTD标题中呈现leaf（“替换”原来的CTD标题中已提交的leaf）不是良好的eCTD操作规范。2)在新的CTD标题中添加操作属性为NEW（新建）的leaf而不改变原来的CTD标题中初始提交的内容，将使申请在eCTD视图工具中的生命周期无效。\n如果非药典赋形剂变成药典赋形剂：\n 如果申请只有一个3.2.P.4章节，其中未使用任何赋形剂属性，或使用的赋形剂属性名称中不含“compendial（药典）”或“non-compendial（非药典）”，则可以Replaced（替换）或Delete（删除）受影响的leaf。\n如果申请包含多个3.2.P.4章节：\ni)如果使用赋形剂的名称作为属性，且没有其他关于分组药典赋形剂的章节，例如，“compendial（药典）”作为其属性，则需要更新受影响的内容并替换leaf；\nii)如果使用赋形剂分组，属性名称为（例如）“compendial（药典）”或“non-compendial（非药典）”，那么在药典章节中，用更新的内容Replaced（替换）受影响的leaf。在非药典章节中，现在对应于药典内容的leaf，具有可应用的DELETE（删除）操作属性。\n在任何情况下，如果在3.2.A.3中提供了关于最初非药典赋形剂的大量信息，则请保留3.2.A.3章节。如果希望不再维护该信息或不再对其进行生命周期管理，则可应用于3.2.A.3 leaf的DELETE（删除）操作属性可能不可用于赋形剂控制。\n如果重新命名赋形剂：  \n根据eCTD规范V3.2.2，无法修改“excipient（赋形剂）”元数据。如果在属性中指定了赋形剂名称，根据ICH eCTD规范，申请人可以删除具有现在过时属性值的所有leaf元素，并为具有修改后的属性值的文件提供新的leaf元素。但是，生命周期历史会脱节，且同一文件的旧leaf和新leaf之间将没有技术关系。或者，申请应在eCTD的下一个主要版本可用之前保持原样。\n对于不再被视为新型赋形剂的新型赋形剂：更新3.2.P.4的内容，以确认赋形剂不再被视为新型赋形剂，并保留3.2.A.3章节。如果希望不再维护该信息或不再对其进行生命周期管理，则DELETE（删除）操作属性可用于受影响的3.2.A.3 leaf，但不可用于赋形剂控制。","2011年11月"]
[76,"可否就申请人如何更好地组织与容器密封系统有关的leaf元素提供额外指导？\n\n该问题由变更请求440生成","申请人可以选择最适合其业务需求的粒度结构。所有容器密封信息都可以放在一个3.2.P.7文件中，或者根据情况放在该申请的多个文件中。\n\n对于eCTD规范3.2.2，除了通过使用某些区域不允许的节点扩展之外，无法在“container closure system（容器密封系统）”（CCS）元素下创建从属的XML元素（标题）（例如，m3-2-p-7-container-closure-system）。当前的规范也不允许CCS章节重复。如果有多个leaf元素，则可以通过使用常用标识符命名leaf元素的<title>来实现某些组织，以允许对相关leaf元素进行排序和分组，然后在同一leaf标题中使用唯一标识符来区分内容。例如，leaf元素可以命名为：“Description – Aclar Blister”、“Description – HDPE Bottle – 50 mL”，或者：“HDPE Bottle – 50 mL – Description”、“HDPE Bottle – 50 mL – Manufacturers”、“HDPE Bottle – 50 mL – Specification”。可以在<title>中提供额外信息或其他信息，例如，包装组件信息（铝盖、PVC层压板）。\n或者，可以提供每个CCS的单个leaf元素（例如，瓶子或吸塑）。\n\n选择初始提交方法后，为了eCTD当前视图，建议在申请的生命周期中保留该方法。","2012年6月"]
[77,"可否就申请人如何更好地组织与稳定性数据有关的leaf元素文件提供额外指导？\n\n该问题由变更请求1560生成","申请人可以选择最适合其业务需求的粒度结构。根据申请的需要，所有稳定性数据都可以出现在一个或多个3.2.P.8.3 leaf元素中。\n\n对于eCTD规范V3.2.2，原料药稳定性（S.7）或制剂稳定性（P.8）的XML元素（标题）都不可重复。如果有数个leaf元素文件，则可以同一格式命名leaf元素文件的<title>来实现某些组织性。例如，对于P.8.3 leaf元素，可以是： \n“Aclar blister –10 mg – long term storage”、\n“Aclar blister –10 mg – accelerated”或\n“Accelerated – bottles – 10 mg, 25 mg”、\n“Accelerated – blisters – 10 mg, 25 mg”或\n“36 months – bottles – 10 mg, 25 mg”\n\n可以在<title>中提供额外信息或其他信息，例如，储存条件、容器方向、和/或“primary（初级）”与“supportive（支持性）”等信息。不建议在这些leaf元素文件的<title>中使用“all strengths（所有规格）”，因为今后的序列可能会引入新的规格。\n选择初始提交方法后，为了eCTD当前视图，建议在申请的生命周期中保留该方法。\n","2012年6月"]
[78,"可否就在模块3.2.S和模块3.2.P以及3.2.A.1和3.2.A.2中使用的元数据值之间是否存在任何链接提供进一步的指导？\n\n该问题由变更请求1290、1640生成","模块3.2.S和3.2.P中使用的元数据与3.2.A.1或3.2.A.2中使用点元数据之间不需要任何链接。此外，3.2.A.1中使用的属性值与3.2.A.2中使用的属性值之间不需要任何链接。\n3.2.A.1和3.2.A.2分别均可适用于原料药和制剂。\n申请人可以选择任何属性或不选择任何属性，以根据需要创建尽可能多的3.2.A.1和3.2.A.2章节。DTD未定义这些属性可以选择的值（例如，它们可以是3.2.S或3.2.P中使用的制造商，或者是唯一的）。\n\n当前的XML eCTD DTD（即，ICH eCTD规范附录8）允许使用以下index.xml概念（当使用适当的XML语法实现时）：\nm3-2-s-drug-substance [manufacturer: all] [substance: insulin]\nm3-2-p-drug-product [manufacturer: all] [product name: active] [dosage form: injection]\nm3-2-a-appendices \nm3-2-a-1-facilities-and-equipment [manufacturer: East Park Building 2] \nm3-2-a-1-facilities-and-equipment [manufacturer: East Park Building 4]\n","2012年6月"]
[79,"可否就模块3.2.A.1中制造商属性的使用提供额外指导？\n\n该问题由变更请求1640生成","如果使用，“manufacturer（制造商）”属性的条目将由申请人决定。属性/元数据值应使用唯一的描述符，以明确识别和区分重复章节中的信息。\n\n该属性可以是城镇或研究中心所在位置（例如，“East Park”），或者也可以更加具体（例如，“East Park Building 2”或“East Park Building 4”）。命名3.2.A.1下出现的leaf元素文件还可以使用其他详细信息，以进一步补充属性中提供的信息。\n\n如果制造商属性有多个值（从而产生多个3.2.A.1章节），并且文件是通用的（例如，洁净室分类），则可以创建多个leaf元素，以便跨章节共享这些文件；且每个文件都只需要提交一次。\n\n评审人员优选尽可能减少跨章节共享的leaf元素文件数量；这意味着使用特异性较低的属性条目（产生较少的章节），而不是详细的条目（产生许多章节）。如果足够数量的文件可跨设施通用，则只可以提供一个3.2.A.1章节（例如，无描述符，或描述符为“all（全部）”）；在这种情况下，需要在文件中使用独特的leaf标题或比较表。\n","2012年6月"]
[80,"PDF/A支持文档中的外部超链接。ICH是否可以取消PDF/A的使用限制？","进一步的研究表明PDF/A-1和A-2支持外部超链接。此外，PDF/A-1和A-2还支持ICH建议中所述的限制。因此，ICH将允许提交符合PDF/A-1或A-2的PDF格式的申报资料。关于PDF/A-1和A-2的可接受性，请参阅区域指南。","2013年11月"]
[81,"ICH Q11和Q8称：“质量标准制定依据”章节（即分别为S.4.5和P.5.6）是“总结原料药（和制剂）总体控制策略的理想章节”。可否选择将控制策略摘要放在模块3的其他部分？","可以。将控制策略总结放在S.4.5和P.5.6以外的章节是可接受的，例如，3.2.S.2.6和3.2.P.2或者3.2.S.4*和3.2.P.5*。具体位置由申请人决定。但是，因为控制策略总结在模块3中无特定位置，申请人应在模块2.3（例如，2.3引言）中说明总结的位置。\n\n*虽然这种将文件放在标题3.2.S.4和3.2.P.5下的方法似乎不符合ICH M4(R3)组织（粒度结构附件）的规定，但是对于eCTD申报资料仍然是可接受的，并且符合eCTD规范v3.2.2。如果使用该方法，则建议文件名称为“ctrlstrat.pdf”。\n","2015年6月"]
[82,"有2个文件描述了eCTD的提交格式：1) eCTD v3.2.2规范（附录7）；2) eCTD提交格式规范。应该参考哪个文件？","用eCTD提交格式规范取代eCTD v3.2.2规范（附录7）。有关该区域实施的生效日期，请参阅区域指南。","2016年4月"]
[83,"使用最新的STF样式表（版本2.3），无法在外部/独立的eCTD阅读器（例如Rosetta）中查看STF。此外，无法在IE v11中启动和查看STF。\n\n该问题是否是整个行业的问题？可否就我们如何处理这个问题提出建议？","M8建议发送方应在STF index.xml leaf参考中包含序列号（即，相对路径）。leaf参考中的序列号示例如下： xlink:href=\"../../../../../../../0004/index.xml#a8d1f43a7435d1f5d8364e0825c369a3d\" xlink:type=\"simple\"，其中0004是序列号。\n","2018年6月"]

{"sheet":"Q&A No. 36","index":3,"n_rows":30,"n_cols":3,"rows_kept":30,"cut":false,"hidden":false,"merged":[[0,0,0,1]],"flags":["formulas_cached_only"]}
["Q&A第36问  更新日期：2009年6月",null,"最后更新日期"]
[1,"确保序列文件夹中有一个名为index.xml的ICH主干文件"]
[2,"确保ICH发布的eCTD DTD校验和与“util/dtd”文件夹中的eCTD DTD校验和相同"]
[3,"确保根据“util/dtd”文件夹中相应的eCTD DTD版本验证index.xml"]
[4,"确保根据ICH eCTD规范中定义的、符合逻辑的正确属性内容验证eCTD index.xml，如下所示："]
[null,"- 如果operation（操作）属性值为new（新建），则modified-file（已修改文件）属性值为空或未提供"]
[null,"- 如果operation（操作）属性值为append（补充）、replace（替换）或delete（删除），则modified-file（已修改文件）属性将具有有效值"]
[null,"- 如果operation（操作）属性值为new（新建）、append（补充）或replace（替换），则xlink:href属性将具有有效值"]
[null,"- 确认ID属性值以字母或下划线字符开始"]
[5,"确保相应文件夹中有xx-regional.xml[1]"]
[6,"确保区域发布的DTD、Schema和相关文件的校验和与“util/dtd”文件夹中相应文件的校验和相同。"]
[7,"确保根据“util/dtd”文件夹中相应的区域DTD、Schema和相关文件（例如，模块文件）验证区域索引文件。"]
[8,"如果使用区域性要求的实例文件（例如，STF），请确保DTD、Schema和相关文件的区域发布校验和与“util/dtd”文件夹中相应文件的校验和相同。"]
[9,"如果使用区域性要求的实例文件（例如，STF），请确保根据“util/dtd”文件夹中相应的区域性DTD、Schema和相关文件验证实例文件。"]
[10,"确保验证区域xml文件具有正确的XML语法和正确的属性内容（请参阅区域指南）"]
[11,"确保每个文件的校验和等于相关主干文件（即，index.xml、xx-regional.xml）或index-md5.txt中所述的相关校验和。","2009-06-01"]
[12,"确保通过xlink：href引用标识的所有文件都存在。\n必须咨询区域当局，以确定xlink:href的目标是否可在引用leaf所在序列之外存在。"]
[13,"确保文件夹m1到m5中没有未引用的文件（包括“util”子文件夹以外的子文件夹）"]
[14,"确保与所引用的DTD相关的modified file（已修改文件）属性使用了适当的格式。（规范3.0与规范3.2）"]
[15,"确保所有文件和文件夹命名约定（长度限制和允许的字符）符合eCTD规范附录6的规定（注意：强烈建议使用eCTD规范中的文件夹和文件名，但不强制使用（参见Q&A第15问））"]
[16,"确保申报资料中包含的所有最低级别的标题元素至少包含一个leaf"]
[17,"确保PDF文件均不超过100兆字节"]
[18,"确保序列号有4位数（即，0000至9999之间的数字）"]
[19,"确保序列文件夹名称与xx-regional.xml中的序列号匹配（在日本不适用）"]
[20,"确保leaf或节点扩展名Title（标题）属性不为空。唯一的例外是operation（操作）属性值为“delete（删除）”的leaf元素，其中Title（标题）可以为空（请参阅区域指南）。","2009-06-01"]
[21,"确保所有文件均未启用文件级保密或密码保护"]
[22,"确保PDF链接和书签的对应关系"]
[23,"确保已优化PDF文件，以实现快速网络交付"]
[]
[null,"[1] 其中xx代表ICH区域标识符：eu代表欧盟；jp代表日本；us代表美国地区"]

{"sheet":"Change Requests","index":4,"n_rows":222,"n_cols":8,"rows_kept":222,"cut":false,"hidden":false,"merged":[[0,0,1,7]],"flags":["formulas_cached_only"]}
["eCTD规范变更请求 （在步骤4发布后收到的）"]
[]
["编号","请求者","M2申办方","规范要素","说明","意见","状态","措施"]
["00010","CTD-E\nFDA","FDA","m5-3-5","多种适应症","由CTD小组解决，对eCTD没有任何影响","超出范围","无"]
["00020","Liquent","EFPIA\nFDA","4-62 (#371)","4-62（＃371）显示DTD和样式表应该放在dtd或样式子文件夹中，但是在第6-2页，显示dtd文件应该直接放在util文件夹下。哪个是对的？","附录4是信息的最终来源，应确保在下一个版本中对其进行更正","批准规范变更","规范更改为版本3.2"]
["00030","EFPIA","EFPIA\nFDA","第4-8页，第34行","连字符的使用不正确","必须更改","批准规范变更","规范更改为版本3.2"]
["00040","MHLW","MHLW","第2-5页","Parta（不允许使用大写）——没有必要限制为小写","最好保持原样（小写）","拒绝","无"]
["00041","MHLW ","MHLW","第4-1页","文件/目录的完整路径。\n第6-5页                                        ……使用完整路径引用文件。这些示例中未显示完整路径。","不相关","拒绝","无"]
["00042","MHLW ","MHLW","第6-5页","使用完整路径引用文件。这些示例中未显示完整路径。","不相关","拒绝","无"]
["00050","Liquent","FDA","3.2.A.3","要求3.2.A.3更改为重复元素","理解，并将在Q&A（第12问）和下一个版本DTD中解决","批准规范变更","规范更改为版本3.2"]
["00060","FDA","FDA","附录3，脚注6","规定包括多少项研究就有多少个子文件夹。第5.3节中可能有一些研究没有患者数据列表或CRF。","错误的问题，脚注中的文本是正确的；问题不相关","拒绝","无"]
["00070","EFPIA","EFPIA\nFDA","ich-ectd-3-0.dtd","元素声明\n\n<!ELEMENT m3-2-p-2-1-components-of-the-drug-product ((leaf |node-extension)?)>\n\n与所有其他元素声明不同：\n\n<!ELEMENT name ((leaf | node-extension)*)>","元素不在dtd的10月8日版本中；不再相关","拒绝","无"]
["00080","ECTD IWG","FDA","标题","更新版本号","不相关，标题中的版本是正确的","拒绝","无"]
["00090","EU","FDA","6-9与6-13\n\n表6-8","在应读取“PDF 1.3”时指定Acrobat 5","更改规范中的示例（例如PDF 1.2或PDF 1.3）以包括“申请版本”和“文件类型”版本。\n另外，在附录7中包括其中的一部分","批准规范变更","规范更改为版本3.2"]
["00100","EFPIA\nEU","EFPIA\nEU","3.2.p.4","支持赋形剂的DTD结构不是最佳的","将更新DTD，也将在Q&A第3问中解决","批准规范变更","Q&A 72-75告知CTDQ；更改下一个主要版本"]
["00110","EFPIA\nEU","EFPIA\nEU","附录3、4","澄清文件名是强制性的还是可选的。措辞不一致","强烈建议澄清；重写之前建议参考Q&A（第15问）\n\n同意文件名是可选的","批准规范变更","规范更改为版本3.2"]
["00120","EFPIA\nEU","EFPIA\nEU","附录4","在评审人员可能会打开几个文件进行比较的情况下，关于使用唯一文件名的建议。","建议使用唯一的文件名作为一般原则——与Q&A第110问相关","批准Q&A","纳入eCTD规范v3.2.1，第3-1和4-1页（在Q&A第15问中解决）"]
["00130","EFPIA\nEU","EFPIA\nEU","DTD——附录6     示例","使用校验和；澄清在应用delete（删除）操作时使用校验和","需要在Q&A（第21问）中解决\n校验和应为空","批准Q&A","纳入eCTD规范v3.2.1，表6-3（在Q&A第21问中解决）"]
["00140","EFPIA\nEU","EFPIA\nEU","附录4，第3.2.S.2节","建议可选择使用子文件夹来更好地构建文档","由于所有文件和文件夹名称都是可选的，因此允许这样做","批准Q&A","纳入eCTD规范v3.2.1，第3-1页（在Q&A第17问中解决）"]
["00150","EFPIA","EFPIA","附录4","规定区域DTD和xml文件具有一个命名约定，但欧盟模块1具有不同的命名约定。哪个优先？","欧盟已经更改，不再相关","超出范围","无"]
["00160","EFPIA\nEU","EFPIA\nEU","附录4，3.2.P.7","建议允许不同的容器密封系统使用多个文件。","有关修订后的M4组织文件中包含的文件数量的灵活性，参见00440","批准 ","M4组织文件变更"]
["00170","EFPIA","EFPIA","DTD","在DTD结构元素中使用“Title（标题）”属性","结构无“Title（标题）”属性","批准规范变更","考虑将结构呈现和控制作为下一个主要版本的一部分\nNMV Req  #ICH126"]
["00180","JPMA","JPMA",null,"关于如何处理多种适应症的初步讨论","重复，参见00010","超出范围","无"]
["00190","ECTD IWG",null,"封面","添加“国际”","需要变更","批准 ","封面已更改"]
["00200","Q&A",null,"DTD","创建所需的indication（适应症）属性","需要更改DTD和规范","批准规范变更","规范更改为版本3.2"]
["00210","Q&A",null,"DTD","当主干出现错误时，需要考虑如何更新index.xml","答：应咨询监管机构","批准Q&A","纳入eCTD规范v3.2.1，附录4和6（在Q&A第3问中解决）"]
["00220","Q&A","EFPIA",null,"扩展规范以支持双向沟通",null,"超出范围","纳入eCTD规范v3.2.1，第1-1页（在Q&A第9问中解决）"]
["00230","FDA","FDA","2-3校验和","关于删除先前提交的文件时使用校验和的详细说明。","不相关，与00130重复","拒绝","无"]
["00240","FDA","FDA","第6-7页","创建eCTD规范所需的leaf ID（目前是可选的）","更改规范，在leaf水平创建所需的leaf ID","批准规范变更","规范更改为版本3.2"]
["00250","EFPIA","EFPIA",null,"Zip文件。需要一种现实的机制来打包小型eCTD申报资料并附在电子邮件中或进行简单的FTP传输。.zip是将eCTD申报资料所需的目录结构中的文件捆绑在一起的一个简单选项，因此能够以高效的方式向监管机构提供单个对象。","Zip依赖于操作系统，可以考虑开放标准存档格式。\n\n超出IWG的范围","超出范围","无"]
["00260","EFPIA","EFPIA",null,"应予澄清，并举例说明属性“application version（申请版本）”的预期内容。\n\n规范定义了一个名为“application version（申请版本）”的属性，但未提供此处可以使用的示例。例如，为“Acrobat v5”还是应为PDF v1.3。当区域使用.rtf文件时，其他示例可能与Word版本有关。理解这个属性的用途以及使用什么作为有效的术语是很有用的。","重复，参见00090","批准规范变更","规范更改为版本3.2"]
["00270","EFPIA","EFPIA",null,"书签应该展开还是折叠？表格和图形的书签应该采用独立结构吗？\n\n关于书签的呈现存在若干选项。首先，可以将书签折叠到第一级，这样评审人员可以展开他们想要查看的书签，或者可以完全展开以便评审人员可以看到所有书签，但在一些文件中这可能是一个很长的列表。其次，书签可以按顺序逐页呈现，也可以按表格和图形分组显示。各机构关于他们希望看到的书签呈现方式是否存在偏好？","各地区没有足够的经验给出肯定的答案。\n\n建议由提交单项申报资料的公司决定","批准Q&A","纳入eCTD规范v3.2.1，第7-4页（在Q&A第18问中解决）"]
["00280","EFPIA","EFPIA",null,"应制定规范以包含可接受的数字签名的定义\n\n一些公司希望转为使用数字签名，但没有关于ICH签名的通常定义的可接受标准和/或声明。ICH将是出现这种标准的明智论坛。这应该作为一项变更控制项目，但同时，通过Q&A进行某种形式的指导将是有用的，例如，如果你确实有数字签名，该怎么做？——这些数字签名是可接受的吗？构成可接受性的元素有哪些？","适用于简短的Q&A（第14问），说明在这一点上没有立场","超出范围","无"]
["00290","EFPIA","EFPIA",null,"应该提高当前文件大小上限50 MB。\n原来关于pdf文件最大为50 MB的要求来自1998年发布的最初的FDA指南文件。从那时起，网络和个人电脑的性能都显著提高。ICH应考虑将最大文件大小增加到更大的值。这将有助于文件的准备，特别是只能选择扫描的遗留文档。","测试是否所有地区都可以接受100和75 MB的文件大小\n\n已经过测试，所有地区均可接受","批准规范变更","规范更改为版本3.2"]
["00300","EFPIA","EFPIA",null,"应予澄清，并举例说明属性“font library（字体库）”的预期内容。\n\n规范定义了一个名为“font library（字体库）”的属性，但未提供此处可以使用的示例。例如，“Arial”是否合适，还是需要“Arial, Arial Black, Arial Narrow, Arial Italic”等？理解这个属性的用途以及使用什么作为有效的术语是很有用的。","目前没有使用","批准Q&A","纳入eCTD规范v3.2.1，表6-8（在Q&A第19问中解决）"]
["00310","EFPIA","EFPIA",null,"可否澄清提供全文索引（例如Adobe目录文件）的必要性？如果各机构需要，应如何以及在何处将其纳入主干？","目前没有在任何地区使用全文索引的计划。有关提供pdf索引要求的章节将在下一版规范中重新讨论；另请参见Q&A第16问","批准规范变更","规范更改为版本3.2，第7-4页"]
["00320","EFPIA","EFPIA",null,"当文件发生更新时，其他文档可能存在冗余且不准确的链接。应建立一种机制来管理此链接的重定向和/或突出显示链接指向已被取代的文档，并且审阅工具提供更新的文档作为替代","请参阅变更申请表\n\n\n\n\n\n2009年10月更新：变更请求需要更改PDF，且ICH不会追究。请参阅区域指南。","推迟\n\n\n\n\n\n拒绝","直到获得更多有关eCTD生命周期管理的经验\n\n建议作为区域实施指南主题"]
["00330","EFPIA","EFPIA",null,"DTD应该模块化。例如，leaf，这样才可将其用于其他目的，例如在区域模块中。","计划在eCTD的下一个主要版本中对模块1的技术方法与eCTD的其他模块进行协调","批准规范变更","规范更改为版本3.2"]
["00340","EFPIA","EFPIA\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n",null,"要包含在规范中的其他操作属性允许从主干中的多个位置引用同一文件，但只进行一次完整属性信息的管理。从多个位置引用同一个文件是合适的。在eCTD中，原则应该是文件只能纳入一次，但是可以从主干中的多个位置进行链接。这是一个很好的解决方案，除非这个文档的生命周期是（例如）被替换。在这种情况下，必须单独更新每个放入主干的条目。eCTD应包括一个提供“reference（引用）”操作属性的选项。对于新的提交，文件的主要位置将具有与其关联的完整元数据，但在次要位置，元数据可以引用主干中的主要位置。因此，在更新时，只需要更新主要位置处的操作属性，从而简化生命周期维护，并通过只更新某些链接来减少可能发生的错误。","当leaf ID具有强制性时（参见00240），这可以用于引用主干中的主要条目。\n\n需要提供关于如何利用leaf ID的解释性说明，例如，什么时候一个文档的多个实例是必须的。\n\n","批准规范变更","规范更改为版本3.2"]
["00350","EFPIA","EFPIA",null,".tiff文件是否是随eCTD申报资料提供的可接受格式，还是应该转换为.pdf？\n\nTiff是扫描文件的常用格式，特别是遗留文档和CRF。","否，有关可接受的格式，请参阅规范的相应章节。","批准Q&A","第20问"]
["00360","EFPIA","EFPIA",null,"在为研究报告提供多个文件的背景下需要考虑签名的GxP要求，特别是在其与更新文档相关时。\n\n根据GCP和GLP，签名是必需的，并且在纸质流程中，这些签名涵盖了整个报告。因此，在初次提交时，报告中提供的签名可以同时用于涵盖整个报告。但是，以电子方式进入生命周期管理过程后，可能仅可更新特定的文件，例如，一个新的附录。需要就签名适用性的GxP解释提供指导——即还有什么时候也需要更新签名，以及应该如何设计流程来准确地演示签名的每个版本实际适用于什么情况。","已于2003年11月提交至CTD协调小组","超出范围","无"]
["00370","FDA/PhRMA","FDA","ich-stf-stylesheet-1-0a.xsl internal:vocabulary4leaf-labels-file-tag","将<item>randomisations-scheme</item>更改为<item>randomisation-scheme</item>，并将<item>iec-erb-consent-form-list>更改为<item>iec-irb-consent-form-list</item>\n\n使用单数形式，随机化，而不是单词的复数形式。\n\n更正iec-irb-constent-form-list值中可能发生的错误。","请求者请求删除更改请求","拒绝","无"]
["00380","EFPIA","EFPIA","附录4","在允许可选粒度的情况下，规范仅定义最低级别的文件名。应该提出关于在更高级别使用什么文件名的建议。","在规范中关于M4粒度文档的文献已引用","批准规范变更","规范更改为版本3.2"]
["00390","FDA/EFPIA","FDA/EFPIA","第2-1页","目前声明ICH 网站有空模板。模板不存在","将提供空文件夹结构","批准Q&A","纳入eCTD规范v3.2.1，第2-1页（在Q&A第13问中解决）"]
["00400","EFPIA","EFPIA","附录9","规范附录9中的页码编号不正确。从9-14开始，应为9-1。","可以在下次编辑时做小改动。","批准规范变更","规范更改为版本3.2"]
["00410","FDA","FDA","跟踪表","关闭00180并删除描述列第一段中的文本","请求者请求删除更改请求","拒绝","无"]
["00420","Boehringer Ingelheim Pharmac. Inc.","FDA","附录4：eCTD的文件组织","我们建议允许eCTD质量模块3的所有章节中，在每个章节和子章节中可以选择包含单个文档，或者多个文档。我们同意，一旦采用某种特定方法（单个或多个文档），就应该在申报资料的生命周期内保持这种方法。","eCTD中已允许使用单个或多个文档/文件。eCTD规范（附录4）需要更新，并将在下一次规范变更时完成。","批准规范变更","规范更改为版本3.2"]
["00430","Boehringer Ingelheim Pharmaceuticals Inc","FDA","附录4：eCTD的文件组织","“2.3 质量综述简介”（eCTD文件组织中的第11项）对于“2.2 CTD简介”（eCTD文件组织中的第10项）是多余的。\n\n我们建议从eCTD规范中删除“2.3 质量综述简介”。","不在eCTD的范围内，因为这是一个内容问题。与CTD Q讨论后确认无需更改，因为占位符已存在于CTD Q文档中。如果更正CTD Q文档中编号，则eCTD也将进行此更改。","拒绝","无"]
["00440","FDA","FDA","DTD和规范","考虑纳入Container/Closure system（容器密封系统）作为一个属性",null,"推迟\n批准Q&A（2012年6月）","第76问\n\n"]
["00450","FDA","FDA","规范v3.0，第6-3页至第6-9页和第8-2页","确保批准的变更请求＃00240是当前接受的方式，所有区域都使用具有modified file（已修改文件）属性的Leaf ID。","更改规范，在leaf水平创建所需的leaf ID","批准规范变更","规范更改为版本3.2"]
["00460","EFPIA","EFPIA","STF规范和M4粒度附件","遗留报告是否可以继续作为单个文件/文档提交，而不需要根据STF和粒度附件将其拆分为单独的文件/文档？是否有一个特定的日期，自该日期起，所有报告均应以CTD定义的方式进行构建？","目前可以接受混合提交（遗留文件作为单个文件和根据STF编写的报告）。必须定义过渡的时间框架","批准Q&A","第22问\n"]
["00470","EFPIA","EFPIA","规范v3.0和M4粒度附录","GLP和GCP检查员希望在报告中看到连续的页码。CTD和eCTD允许按文档/文件进行页码编号。这两者是不相容的。","已于2003年11月提交至CTD协调小组","超出范围","无"]
["00480","JPMA","JPMA","规范v3.0，附录5","没有必要列出提交eCTD的媒体类型。而应该参考M2关于物理媒体和区域指南的建议。","在下一次规范变更时更正，第5-2节","批准规范变更","规范更改为版本3.2"]
["00490","JPMA","JPMA","模板空文件夹结构","空文件夹结构模板中的错误","更新模板文件夹结构 ","批准 ","空文件夹结构已更新为版本3.03"]
["00500","JPMA","JPMA","规范v3.0，附录3","附录3、图3-3和3-4中的错误",null,"批准规范变更","规范更改为版本3.2"]
["00510","JPMA","JPMA","规范v3.0，附录4","附录4第23行和第24行的药理学缩写不一致","将第24行更正为pharmacol","批准规范变更","规范更改为版本3.2"]
["00520","JPMA","JPMA","规范v3.0，附录2","最大路径长度256不允许监管机构添加到该路径，如果需要的话","将第2-4页的最大长度更改为230，以允许监管机构将服务器名称添加到该路径（第2-4页）","批准规范变更","规范更改为版本3.2"]
["00530","ICH M2 IWG","ICH M2 IWG","规范v3.0，表6-3","澄清操作属性REPLACE（替换）和APPEND（补充）","更正规范","批准规范变更","规范更改为版本3.2"]
["00540","EFPIA","EFPIA","规范v3.2","对于使用v3.0提交的申报资料，是否可以转为v3.2？\n\n供应商的意见：“一些申办方已经使用3.0版本发送了申报资料，但可能没有意识到他们必须在该申请剩余的生命周期内坚持使用3.0版本，因为在modified file（已修改文件）属性中引入ID和使用ID将不允许申办方改为3.2版本。”真是这样吗？如果是这样，监管机构有什么建议？永远留用旧版本似乎不切实际。是否可以纠正这种情况，今后再次更新规范时如何避免这种情况？","建议是为了避免兼容性问题，即使使用3.0，也必须使用该ID；\n对于之前提交的文件，请咨询监管机构，以确定如何解决生命周期问题。","批准Q&A","第26问"]
["550","EFPIA","EFPIA","规范v3.2","应澄清有关id值中字符集的任何限制。根据W3C定义，ID属性值使用“name（名称）”定义，必须以字母、下划线或冒号开头，然后可以跟随任何字母（大写或小写）、数字、句点、连字符或冒号的任意组合。FDA最近将一份初步eCTD申报资料退回给J&J，因为ID属性值包含一个下划线字符。他们表示，ID属性的语法必须与文件名的语法相匹配（根据ICH eCTD规范的规定，这意味着只能使用小写字母、数字和连字符）。他们表示，ICH规范规定了ID属性的这种语法，并通过引用3.2版规范的第2-4和2-5页内容，为这种说法提供了依据。他们还表示，ID不能包含下划线，因为在超链接中使用时，下划线可能会被链接文本的格式（如果它使用下划线）掩盖。这两个规范不相容。应予以澄清。","FDA一致认可下划线可以出现在leaf id中，但不能是第一个字符\n2008年3月更新：ID属性旨在成为申报资料中的唯一编号，可用于从XML文档中的另一个项引用该项。XML ID值必须以字母字符或下划线开头。如果申请人使用仅采用数字的内部ID生成器，则将生成的数字附在到前导字母字符或下划线后面将创建一个有效的ID值。有关此属性值组成的信息，请参阅W3C网站上的XML-ID建议（http://www.w3.org/TR/xml-id/#processing）","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["560","EFPIA","EFPIA","规范v3.2","所有ICH区域均应澄清是否可以在模块2-5中使用节点扩展\nICH规范允许在模块2-5中使用节点扩展，而在模块1中使用节点扩展则是区域性问题。FDA规定，申报资料的任何部分都不支持节点扩展，这会导致ICH规范无效。生成欧洲申报资料的经验表明，需要使用节点扩展来为模块4和5提供可导航的结构。目前，这意味着eCTD不能跨区域重用，并将给该行业造成大量的重复工作。FDA应接受模块2-5中的节点扩展。","FDA担心节点扩展可能被过度使用。测试阶段的经验证实了这些担忧的正确性。在许多情况下，美国对STF的要求消除了对节点扩展的需要。但在某些情况下，节点扩展的使用可能是合理的，应该根据具体情况与FDA进行讨论。目前，其他区域能够接受符合eCTD规范的节点扩展的适当使用（即，除非没有其他可行的方式来提交资料，否则不鼓励使用节点扩展）。IWG将审查这种情况。","批准Q&A","纳入eCTD规范v3.2.1，表6-8和示例6-15（在Q&A第28问中解决）"]
["570","EFPIA","EFPIA","样式表","ICH标准样式表不足以支持节点扩展的使用——显示已损坏。\nICH规范支持在最低级别使用节点扩展。使用节点扩展时，样式表不会正确显示文件的标题。该节点扩展下的所有文件都包含在每个文件的标题中。所附屏幕截图展示了这个问题。\n幻灯片1：xml源代码                             幻灯片2：在样式表中显示。黄色框中的文本应为m5351（理想情况下，加上节点扩展细节）                幻灯片3：在最新版本的DataFarm阅读器中（所附PPT幻灯片）显示",null,"批准","重写样式表"]
["580","EFPIA","EFPIA","规范v3.2","某些eCTD构建器和阅读器工具的输出之间存在显著的不兼容性，原因是对规范的解释和验证的项目不同。ICH应该开发验证套件。\n欧洲（和美国）最近的经验强调，一个供应商产品的“有效”输出不一定是另一个供应商的有效输入。这导致需要在提交之前测试并更正申报资料。之所以会产生不兼容性，是因为一个产品期望以特定的方式处理某些项目（尽管eCTD规范中没有说明具体的方式）。这导致了不相容的解释。如果所有工具都可以使用ICH开发的套件，就可以避免这种情况。","这个问题已得到承认。第一步需要确定各个供应商用于验证的标准。","批准Q&A","第36问"]
["590","Datafarm Inc.","PhRMA","规范v3.2","单个文件的文件名是否从生命周期的开始到结束都是固定的？","回答是否定的","批准Q&A","纳入eCTD规范v3.2.1，表6-4至6-6（在Q&A第23问中解决）"]
["600","Datafarm Inc.","PhRMA","规范v3.2","INDEX.XML中的区域XML引用\n根据DTD和规范，申报资料中提交的所有文档都应该在XML主干中有一个参考文件（leaf）。当发送修正案、变更等，应使用适当的Operation（操作）属性和modified file（已修改文件）属性来维护该文档的生命周期。此规则是否适用于引用区域XML文件的leaf？请注意，即使实际文档由区域当局控制，该leaf/文档的引用和生命周期管理也属于ICH DTD范畴。\n ",null,"批准Q&A","纳入eCTD规范v3.2.1，第6-2页（在Q&A第24问中解决）"]
["610","Datafarm Inc.","PhRMA","规范v3.2","申请表和封面函生命周期管理……\n根据DTD和规范，申报资料中提交的所有文档都应该在XML主干中有一个参考文件（leaf）。当发送修正案、变更等，应使用适当的Operation（操作）属性和modified file（已修改文件）属性来维护该文档的生命周期。此规则是否适用于引用所有序列中存在的申请表和封面函的leaf？此外，这在各个区域通用。请注意，即使实际文档由区域当局控制，但最好有一套可在各个区域通用的指导原则。","请参阅模块1中的特定区域文档。请参阅区域指南。","超出范围","无"]
["620","Datafarm Inc.","PhRMA","规范v3.2","包含MD5值和封面函的Text文件…… \n\n规范中明确规定了Text文件中index.xml的MD5值。但它仍然导致了一些解释上的混乱。                    请澄清：\n1.每个序列只有一个index-md5.txt，其index.xml md5值存储在该文件中，并且它与index.xml一起保存。\n2.对于区域xml文件，不需要index-md5.txt，因为此MD5值已存在于index.xml中\n3.无法生成MD5值并将该值放在封面函中（第5-2页）。这将更改封面函、区域xml和index.xml中的MD5值。也许这可以放在媒体标签上。","在附录5中，eCTD规范要求提供一份纸质封面函，该封面函也应作为pdf（cover.pdf）提交，不与主干相关联。这是将md5文本作为附录添加到其中的封面函。这些问题也在区域指南中得到处理。","批准规范变更","纳入eCTD规范v3.2.1，第5-2和6-2页（在Q&A第31问中解决）"]
["630","Datafarm Inc.","PhRMA","规范v3.2","ID值要求不明确，需要额外的规范。\n根据ICH规范第6-8页的规定……“XML实例中此文件的唯一标识符。Leaf ID必须以字符开头。”\n最好明确表示该ID值应：\n-以字母字符开头\n-只允许使用字母和数值，不允许使用符号或特殊字符\n-不允许使用空格\n-ID值的长度不得超过“n”个字符\n\n区域评审系统在leaf属性值（例如标题）的长度方面有自己的限制。如果ICH能像控制href最大长度和文件名最大长度那样控制它们就好了。","除了id必须以字母字符开头的要求之外，这些字段的内容没有限制，但受技术限制。\n\n2008年3月更新：ID属性旨在成为申报资料中的唯一编号，可用于从XML文档中的另一个项引用该项。XML ID值必须以字母字符或下划线开头。如果申请人使用仅采用数字的内部ID生成器，则将生成的数字附在到前导字母字符或下划线后面将创建一个有效的ID值。有关此属性值组成的信息，请参阅W3C网站上的XML-ID建议（http://www.w3.org/TR/xml-id/#processing）","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["640","GSK","EFPIA","规范v3.2","最大文件大小的描述不一致\n\n附录7：eCTD的提交格式规范，第7-1页：            指南指出：“为确保可以有效地访问PDF文件，PDF文件不得超过100 MB。”但是，在eCTD规范的第7-4页，在页面编号下，指南指出:“此规则可能出现两个例外情况（请参阅CTD模块指南中的详细信息）。首先，因为文件大小（例如，>50 MB）而拆分文档的情况，第二个文件或后续文件应接着第一个文件或前一个文件连续编号。”为了保持一致，后者应更新为100 MB。","这是规范中的印刷错误。最大文件大小为100 MB，而不是示例中给出的50 MB。","批准规范变更","纳入eCTD规范v3.2.1，附录7"]
["650","Centocor BV","EFPIA","规范v3.2，附录4， 模块3.2.S的文件组织","模块2.3.S、2.3.P、3.2.S和3.2.P中支持制造商的文件组织应保持一致。目前，3.2.S按物质/制造商细分，3.2.P仅按产品细分，而2.3.S和2.3.P没有细分。可否定义所有章节中的制造商细分？另请参见变更请求660\n","对于模块2.3.S和2.3.P，已经可以按制造商、文件名和属性进行区分。\n\n对于模块3.2.P，请参阅CTD Q了解他们如何看待3.2.P及其子章节的组织。","拒绝\n\n批准Q&A（2009年10月）","Q&A #65-70"]
["660","Centocor BV","EFPIA","规范v3.2","3.2.P的文件组织在区分制造商方面应遵循与3.2.S相同的原则。3.2.S具有按物质/制造商细分的文件夹组织，3.2.P在产品下没有这样的组织。应为每个制造商引入文件夹结构。\n","请参阅CTD Q以确定他们希望如何组织3.2.P及其子章节。","超出范围\n批准Q&A（2009年10月）","Q&A #65-70"]
["670","Centocor BV","EFPIA","规范v3.2 ","为了防止维护相同的文档副本，应该可以在同一申报资料或eCTD生命周期中任何先前提交的申报资料中的其他地方链接到相应文档。原始更改请求中给出了示例。\n\n如果允许使用除new（新建）、replace（替换）、delete（删除）以外的其他操作属性（例如“link（链接）”），则可以实现这一点。","一个文件在一个序列中只应包含一次。\n\n每个区域跨序列多次引用一个文件的要求不同。\n\neCTD EWG将解决“link（链接）”概念，因为它与单个序列相关，作为下一个主要版本生命周期的一部分。","批准Q&A","纳入eCTD规范v3.2.1，第6-5页（在Q&A第38问中解决）"]
["680","Aventis","JPMA","ICH eCTD样式表","ICH eCTD样式表不适用于“节点扩展”xml示例",null,"批准","重写样式表"]
["690","GSK","EFPIA","规范v3.2","在产品的生命周期中转为新版规范。\n\n是否希望我们在申请期间保留给定的DTD版本，这样只要我们提交至同一申请，我们将使用与初始申报资料使用的相同的DTD版本，或者，是否希望我们在某个时间段内对所有申报资料使用新版DTD，无论它们是新建的还是进行中的申请？\n此外，如果需要更改DTD，对申报资料的结构发生变化，则监管机构的阅读工具将如何呈现累积视图，例如，旧章节的重命名、新章节的引进等。",null,"批准Q&A","第27问\n"]
["700","Lorenz","EFPIA","规范v3.2","是否可以提交涵盖多个区域的eCTD？\n如果申报资料中模块2-5的内容在两个或多个区域之间是相同的，是否可以在同一eCTD中提交多个模块1？",null,"批准Q&A","纳入eCTD规范v3.2.1，第1-2页（在Q&A第29问中解决）"]
["710","Lorenz","EFPIA","规范v3.2","是否支持供应商特定样式表？样式表可以包括将引用链接重定向到其他文件的功能。",null,"批准Q&A","纳入eCTD规范v3.2.1，第1-1页（在Q&A第30问中解决）"]
["720","Lorenz","EFPIA","规范v3.2","区域index文件是否需要MD5值？\n区域MD5校验和文件（##-regional-md5.txt）是强制性的、可选的还是不允许的？","重复CR#620","批准Q&A","纳入eCTD规范v3.2.1，第5-2和6-2页（在Q&A第31问中解决）"]
["730","Lorenz","EFPIA","规范v3.2","日文字符是两个字节。日语文件/文件夹名称是否仍可使用64个字符？",null,"批准Q&A","纳入eCTD规范v3.2.1，第2-3页（在Q&A第32问中解决）"]
["740","Lorenz","EFPIA","规范v3.2","澄清“id”属性允许使用的前导字符。\n规范的表6.8规定，id值应以字符开头。这可能不精确，因为字符可以是字母、数字或其他。根据W3C定义，不允许使用数字。可否提供更准确的定义，以确定哪些是实际允许使用的字符？","参见Q&A第11问","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["750","Lorenz","EFPIA","规范v3.2","允许/推荐的“title（标题）”属性的长度是多少？\n\nTitle（标题）字段似乎对字符数没有限制。由于研究报告等文件的标题通常可以是几百个字符，因此可否指导实际上是否存在任何限制，以及完整标题对于评审人员来说是否具有任何价值，或者是否应使用缩写形式？","建议最多使用1024个字节，并建议保持标题简洁。\n\n关于使用简明标题长度的建议（在2006年6月会议期间改变了之前的意见（见上文））\n\n","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["760","Lorenz","EFPIA","规范v3.2","申报资料序列号是否必须连续，例如，0005必须在0004之后提交，或者是否存在0005可以在0004之前提交的情况？",null,"批准Q&A","纳入eCTD规范v3.2.1，第6-1页（在Q&A第33问中解决）"]
["770","AstraZeneca","PhRMA","规范v3.2，参见第6-11页，“纸质文件提交部分的说明” 。 ","可否澄清Application-Version（申请版本）字段的内容引用PDF版本或Acrobat版本（例如，PDF版本1.4或Acrobat 5）。","我们已经将其处理为一个变更请求（#00090），我们的回复是它应该是PDF版本。看起来仍然给出了一些Acrobat版本号。我们需要在下一个版本中更正该问题。","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["780","AstraZeneca","PhRMA","规范v3.2，参见“创建PDF文档和图像的方法”。","扫描标准——是否可以600 dpi扫描，而不是ICH推荐的300 dpi？当以300 dpi扫描时，日语汉字文档看起来不清楚。","规范应改为“至少300 dpi”。","批准规范变更","纳入eCTD规范v3.2.1，附录7"]
["790","AstraZeneca","PhRMA","规范v3.2，参见“修改、补充或变更的说明”。  ","PDF Global Acrobat Specifications的标准化——有什么计划使eCTD的PDF Global Acrobat Specifications标准化（例如，Distiller设置）？提取PDF时的PDF设置是什么？什么版本（1.3？）PDF需要经过优化？PDF是否有缩略图？","eCTD规范的PDF章节涉及所有区域的标准化；下一个版规范将评估PDF或XML的使用。","拒绝","无"]
["800","AstraZeneca","PhRMA","规范v3.2，参见第6-11页","安慰剂和参照药物——在临床试验申请中，有关安慰剂和参照药物的CMC信息应放置于何处？例如，将每个安慰剂和每个参照药物视为申请中单独的3.2制剂，或者，将同时将安慰剂和参照药物纳入3.2区域？","这是一个CTD Q问题，将被移交给CTD Q组。\n\n请参阅区域指南。","拒绝","无"]
["810","EFPIA","EFPIA","Q&A 28","eCTD IWG可否根据欧洲的经验来审查该Q&A？\n作为Q&A的一部分，提出了以下声明：“目前，其他区域能够接受符合eCTD规范的节点扩展的适当使用（即，除非没有其他可行的方式来提交资料，否则不鼓励使用节点扩展）。IWG将审查这种情况。”欧洲的经验是，通常在最低级别常规使用节点扩展来区分不同的研究，从而组织用于每项研究的文件。其他的例子在主干的更高级别的使用，则需要一些用于区分的地方（属性不支持）。目前看起来没有出现任何问题，有必要审查该指南，因为实际上在欧洲“预期”会使用节点扩展。","已经补充了Q&A第28问。","批准","纳入eCTD规范v3.2.1，表6-8和示例6-15（在Q&A第28问中解决）"]
["820","GSK Canada","FDA","规范v3.2和区域规范","在随后的提交中，操作属性“new（新建）”是否可以用于主干中特定位置的文档，在之前的提交中该位置已经有文档的背景下？eCTD构建的产品供应商解释说，在eCTD的生命周期中，任何时候都不能提交包含相同名称/标题的文档，其中操作属性在后续提交中被指定为new（新建）。举个例子：变更/修正案包含一个“封面函”。这始终与特定申请有关。“New（新建）”是应该使用的属性。“Replace（替换）”或“delete（删除）”不相关，“append（补充）”不适用，因为没有必要引用前一个文件，因为可能没有预期的关系。还有其他一些例子，模块2-5中可能会出现这些问题，例如，在模块2中，其中QOS可能是全新的，不依赖于“append（补充）”，也不需要“delete（删除）”或“replace（替换）”。可否澄清在随后的提交中使用“new（新建）”的可接受性？",null,"批准Q&A","纳入eCTD规范v3.2.1，表6-3（在Q&A第34问中解决）"]
["830","Liquent","PhRMA","每个区域的实施指南","区域仅接受eCTD的意愿\n哪些国家/地区仅接受eCTD作为正式的申报资料用于存档？在什么情况下？您是否知道愿意接受eCTD的非ICH国家？","区域当局就这些问题进行了沟通，请参阅相关内容。","拒绝","无"]
["840","Liquent","PhRMA","规范v3.2","PDF文件的版本\n是否有关于接受不同版本的Acrobat文档和/或向后兼容性期望的授权？不得不承认可以购买到的只能是最新版本。FDA网站上的最新指导文件显示PDF1.4，虽然\nAcrobat Distiller可以设置为创建较低版本的PDF，但在较高版本的Acrobat中处理后（通常需要添加链接、书签等），文件将保留该较高版本，且无法“保存为较低版本”。","参见变更请求00790的答案","拒绝","无"]
["850","Liquent","PhRMA","规范v3.2","在DIA EDM大会上，有人询问了超链接和申报资料的生命周期。对于申办方知道将在日后更新的文件（例如，作为120天安全更新的一部分），FDA表示，在最初的申请中最好不要提供超链接；而应该提供物理引用，以便评审员能够通过主干访问。该方法是否在所有区域都可以接受？","这是一个与业务相关的问题，eCTD IWG无法回答。根据具体情况咨询区域当局。","拒绝","无"]
["860","Liquent","PhRMA","规范v3.2","可否提供关于使用append（补充）操作的任何最佳实践建议；是否期望补充的内容将包括关于其所应用的原始文档部分的上下文线索？","这是一个与业务相关的问题，eCTD IWG无法回答。根据具体情况咨询区域当局。","拒绝","无"]
["870","Liquent","PhRMA","欧盟区域规范","随着XML格式的欧盟申请表v1.0的发布，是否有接受和/或强制执行的时间框架？可否提供有关如何在eCTD中纳入该时间框架和支持文件的详细信息（附带申请表XML文件的支持文件，或主要util目录中的支持文件等）？","欧盟区域问题","拒绝","无"]
["880","Liquent","PhRMA","欧盟给申请人的通知","是否进一步讨论了在相互认可程序中eCTD生命周期的处理？有人建议，可以“扩展”eCTD生命周期，以帮助支持向不同的相关成员国提交多份申报资料。进一步的指导会很快澄清这一点吗？","欧盟区域问题","拒绝","无"]
["890","Liquent","PhRMA","规范v3.2","可否进一步澄清相关的序列元素？是否只应包含对modified-file（已修改文件）路径中包含的序列或新提交的资料可能涉及的任何序列的引用？",null,"批准Q&A","第35问"]
["900","Liquent","PhRMA",null,"欧洲的监管机构有什么培训和教育计划来帮助他们理解eCTD的生命周期机遇和挑战的含义？",null,"拒绝","无"]
["910","Liquent","PhRMA","规范v3.2","是否有关于文件长度的建议以及是否需要有自己的内部目录？代表文档结构的书签是否可以替代目录？","请参阅规范3.2的第7-3页。","拒绝","无"]
["920","Liquent","PhRMA","美国与欧盟地区规范","通过SPL和PIM计划，是否计划发布关于如何在eCTD中包含这些文档及其支持文件以及解决生命周期问题的具体指导？","请参阅模块1中的区域指南","拒绝","无"]
["930","Liquent","PhRMA","eCTD DTD ","是否预期将使用non-leaf元素的ID属性，以及使用该属性是否具有生命周期含义？","一个示例有助于理解这个问题。","拒绝","无"]
["940","Liquent","PhRMA","规范v3.2","对于leaf ID使用的字符数量是否有（技术上的或实际的）限制？GUID是否适合该值？","参考W3C文档Qname ","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["950","Liquent","PhRMA","规范v3.2","如果文件经多次补充——序列0001、0002和0003，都包含一个leaf，其操作 = “append（补充）”，并修改0000中提交的leaf，那么从评审的角度来看，是否到了某个时候，这个操作就变得难以处理了呢？是否期望在某个时候，将在0000中提交的文件替换为将当前文档作为单个leaf组成的sum-total并删除补充的leaf元素会更有意义？","这是一个与业务相关的问题，eCTD IWG无法回答。","拒绝","无"]
["960","Liquent","PhRMA","eCTD DTD和编写规范","如何在eCTD中使用link-text和xref元素？到目前为止，我们还没有找到它们的应用，并想知道它们的适用范围。","保留供将来使用——在规范中说明","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["970","Liquent","PhRMA","规范v3.2和区域规范","2004年11月的Q&A包括关于使用节点扩展的问题（#28，变更请求00560），我们从客户那里了解到，节点扩展在欧盟是必要的，但是在v3.2规范中特别不鼓励使用节点扩展。对于它们的继续使用是否有进一步的考虑？","重复的变更请求，参见00810","拒绝","无"]
["980","Liquent","PhRMA","规范v3.2","是否有计划更新ICH和/或区域纸质CTD规范，以进一步促进eCTD和纸质资料的并行提交，而某些地区仍需要提交纸质eCTD（如EMEA v0.3指导文件所述：自2004年6月以来使用电子通用技术文件（“eCTD”）作为源文提交时支持上市许可申请的注册资料纸质提交的实用指南）？","请参阅区域指南。","超出范围","无"]
["990","Liquent","PhRMA","规范v3.2","模块2-5或任何区域的模块1中是否有eCTD的其他章节正被考虑用于XML/与PDF相对的结构化内容？","对于结构化XML文件，请参阅区域指南。对于使用XML代替PDF，请参阅变更请求00709","超出范围","无"]
["1000","Liquent","PhRMA","规范v3.2","是否进一步讨论了在不需要重新提交内容的情况下防止链接过期的链接生命周期问题？","参见变更请求00320","推迟","无"]
["1010","Liquent","PhRMA","研究标记文件的eCTD 主干文件规范v2.6，2004年11月","v2.6 STF规范没有提到content-block，但DTD中仍存在；这些使用是预期中的吗，如果是，是否可以提供示例？","即使它们仍在DTD中，也不得使用content-block。这将在今后的DTD版本中得到纠正。","推迟","下一个主要版本\nNMV Req #ICH114和ICH128"]
["1020","Liquent","PhRMA",null,"在ICH网站上有一个STF v2.6的zip文件，但FDA网站仍然是v1.1。假设2.6版本是要使用的正确版本，如果使用累积方法，并给出xlink：href的格式如何从文件夹/文件路径更改为主干的间接引用，以及对属性元素使用意图的更改，如果我之前根据1.1规范提交了STF，新的STF是否应从旧的doc-content元素中删除属性元素并更新xlink:href属性的格式？如果采用累积方法，是否需要更换先前提交的STF以反映当前的使用情况？","请参阅美国区域指南","超出范围","无"]
["1030","Liquent","PhRMA","eCTD DTD","是否有计划使用，驱动和/或显示leaf属性，或者在不打算使用它们的情况下将它们从规范中删除？","保留供将来使用——在规范中说明","批准规范变更","纳入eCTD规范v3.2.1，表6-8"]
["1040","Liquent","PhRMA","行业指南——根据ICH-CTD格式提交上市申请","是否预期公司将在特定时间范围内继续提交混合资料（eNDA/eBLA与CTD内容）？是否预期最终将在eCTD中纳入所有混合要求？FDA可否告诉我们今年和去年他们分别收到多少份混合资料与eCTD？",null,"超出范围","无"]
["1050","Liquent","PhRMA","美国模块1 v1.1，2004年3月","可否进一步澄清相关的序列元素？是否只应包含对modified-file（已修改文件）路径中包含的序列或新提交的资料可能涉及的任何序列的引用？","重复的变更请求，参见00890","拒绝","无"]
["1060","PhRMA","PhRMA","eCTD DTD、STF DTD 和CTD粒度","与M 3类似，M 4+5中的信息粒度应明确定义并被所有区域接受。基于粒度的可接受性应该没有区域差异；当跨区域提供相同的信息时，粒度（以及任何定义的attributing（属性）或file-tagging（文件标签）或keywording（关键词））必须相同。文件标签、关键词和属性应被视为ICH的受控词汇表，以确保不同区域以相同的方式赋予相同的内容文件属性。需要解释定义每个术语的申请+使用，以支持一致的解释、理解和使用。\n表现\n目前有一个名为“nonclinical-study-report（非临床研究报告）”的ICH文件标签。最近FDA对STF文件的实施表明不使用该ICH批准的术语而是使用“美国”术语“nonclinical-data（非临床数据）”。ICH文件标签的区域更改应由ICH批准并反映在ICH文档中。不应该需要“info-type（信息类型）”标签，因为所有标签都应该是ICH批准的。","FDA将起草一份对其当前STF规范的修改草案，并与M2 EWG共享以征求意见。所有意见都得到处理后，FDA将发布新的STF规范。","超出范围","区域问题\n在STF规范v2.6.1中进行了更正"]
["1070","FDA","FDA","eCTD消息","当前的eCTD实施没有强制要求一致性、促进自动化或促进数据的重复使用（例如，赋形剂——不能在申报资料之间进行检索，因为它是自由文本字段）。建模技术可以使我们更容易地识别用于协作或数据共享的领域。为此，我们认为采用架构方法是明确识别数据和联系所必需的。\n此外，更灵活的规范（例如，主干之外的受控词汇表；对不同产品类型重复使用相同传输机制的能力）将允许我们将规范扩展到其他产品线（即，重复使用规范）。",null,"批准规范变更","下一个主要版本\nNMV Req #ICH69、ICH81和ICH114"]
["1080","PhRMA","PhRMA","规范3.2","需要更新规范以显示如何使用消息在所有3个区域（与CR 320相关）中一致地支持以下方案：重复使用相同的物理文件                                          1）在无重复文件的同一申报资料实例中（多次引用单个主干）；                                      2）无重复文件的单项申请的不同申报资料之间的内容（在单项上市许可申请中引用不同的主干实例）；                     3）多项申请的不同申报资料之间的内容（引用不同上市许可申请的不同实例）；\n解决方案必须解决以下情况：                           a）表明文件已在另一个上下文中提交（并可能已审查）所需的适当操作属性值；                                 b）已发生后续文件生命周期更改（例如，删除、补充、替换）并适用于所有重复使用的上下文；                        c）发生了后续文件生命周期更改，并且不适用于所有上下文。","不清楚这是否可以通过文档处理（规范中更细致的语言或并行的“实施指南”），或者是否需要对DTD进行技术更改。\n\n方案：\n仔细分析需求后：\n1）澄清（用示例）如何在规范内实现上述目标。\n2）创建实施指南，指定推荐的机制并纳入示例。\n3）修改现有技术DTD，然后执行步骤1或2。\n\n与CR＃670相关","批准Q&A","纳入eCTD规范v3.2.1，第6-5页（在Q&A第37和38问中解决）\n"]
["1090","PhRMA","PhRMA","eCTD DTD、STF DTD 和CTD粒度","逻辑文件的概念\n- 为由多个文件组成的文档提供组织结构（例如，在任何eCTD元素中，没有一致的机制来识别哪些文件是相关的并且对整个“文档”做出贡献；尤其重要的是当该元素中存在多个文档时）\n- 提供组织结构来创建\\维护组成文档的多个文件之间随着时间推移的关系（文档的生命周期管理）\n- 当需要重复使用逻辑文档时，可以引用逻辑文档，而不是组成逻辑文档的文件集合",null,"批准规范变更","下一个主要版本\nNMV Req #ICH59和ICH60"]
["1100","PhRMA","PhRMA","eCTD DTD和STF DTD","当前的实施策略允许各个区域决定是否接受规范的各个方面，这可能会在规范实施中造成分歧。这可能导致一个区域拒绝一项申请而另一个区域接受该申请。\n虽然区域在接收信息时可能具有“偏好”，但这些“偏好”不得超越规范。\n示例\n1.使用STF或使用节点扩展名编译或组织的文件的完全相同的集合不会被所有区域接受，即使这两种方法都得到了ICH的批准。\n2.不是所有区域都能接受采用累积或累加方法进行STF管理。\n可能的解决方案\n方案#1：删除不同的方法并就单一方法达成一致。\n方案#2：要求所有区域都接受任何使用书面规范的有效提交。","一个子团队将测试涉及将所有研究标签移动到eCTD DTD以将STF功能合并到eCD主干的更改。此测试还将确保eCTD主干将继续支持其他地区提交研究内容的方法。\n\nM2成员可以将此问题传达给供应商。\n\n1）将在下一个主要版本中重新评估2）现在有一种STF管理方法","1）拒绝     2）批准纳入下一个次要版本中","纳入STF规范v2.6.1"]
["1110","EU/EFPIA","EU/EFPIA","规范v3.2 ","欧盟代表团希望重新开放关于双向通信的变更请求＃220。在eCTD中，生命周期中的大量数据监管机构创建并发送给申请人。这包括问题清单、决策文件、批准后承诺清单等。欧盟代表团还认为这个问题与批准状态的跟踪有关（请参见单独的变更请求），其中批准或拒绝的通知来自监管机构。应修改eCTD规范以包含这种信息交换。\n这一要求具有一定的紧迫性，因为欧盟目前正在实施用于标签信息交换的PIM标准。该标准包括双向数据交换，计划将其纳入EU M 1规范。根据目前的规范，这需要为该机构寻找行业沟通的解决方案。","目前这是一项区域要求。\n\n模块1内的欧盟解决方案作为临时解决方案可能是可行的。","推迟","考虑下一个主要版本的范围\nNMV Req #ICH87、ICH111、ICH112和ICH113"]
["1120","EU/EFPIA","EU/EFPIA","规范v3.2 ","欧盟代表团建议增加一种方法来跟踪与改变授权的活动相关的序列组的“批准状态”。此信息的一个用途是允许eCTD的消费者查看生命周期的“已批准”视图，该视图明确排除正在审核、拒绝或撤回审议的数据。\n提案与单独的变更请求中提出的双向沟通概念有关。批准状态是从监管机构发送给申请人的信息的另一个示例。\n解决方案可以在区域层面进行，但欧盟代表团认为其他地区可以从这些信息中受益，在ICH层面提出解决办法将是有利的。","目前这是一项区域要求。\n\n模块1内的欧盟解决方案作为临时解决方案可能是可行的","推迟","考虑下一个主要版本的范围作为区域实施主题解决\n"]
["1130","EU","EU","规范v3.2 ","经验表明，一个供应商产品的“有效”输出不一定能成为另一个供应商的有效输入。这要求在提交之前测试和纠正递交资料，并导致与各机构中安装的工具不兼容。这是因为一个产品期望以特定的方式处理某些项目（尽管eCTD规范中没有说明具体的方式）。这是导致了不相容的解释。应改进eCTD规范，以便纳入特定的技术验证标准，从而允许不同工具和区域的一致实施。预计将使用Schema来优化eCTD的自动验证。\n此更改请求涉及与eCTD规范相关的技术验证标准，而不涉及文件/文档的科学和法规内容。我们还注意到，使用XML Schema可能无法解决所有可能的技术验证标准（例如，leaf文件的文件大小），并且可能需要其他解决方案。","早先提供的基于变更请求580（2004年5月8日提交）Q&A第36问的信息被认为是不充分的。\n\nM2将在DIA年会上采取行动并安排特别会议，或者FDA可以围绕DIA年会召开会议    \n\n亦考虑于2007年召开ICH 7/DIA会议","批准规范变更；通过eCTD NMV的实施指南继续监控和解决问题","下一个主要版本  作为实施指南制定的一部分解决 "]
["1140","Health Canada","Health Canada","规范3.2","规范和DTD需要支持产品生命周期内的提交管理。规范和DTD需要支持产品生命周期内的提交管理。这包括：\n1. 首次提交\n2. 随后提交，作为对该机构的请求的回应\n3. 申请人发起的后续提交\n需要能够支持/跟踪后续提交的并行审查。当前规范旨在用于提交序列中的线性增量。一些当前的操作属性仍然导致工具供应商和机构指南中的混淆，例如，\nsequ 0000   myfile.pdf   new\nsequ 0001   myfile.pdf  append  sequ 0000\nsequ 0002   myfile.pdf  replace  sequ 0001\n当前视图应该是什么？如何解决这个问题？还有几个类似的操作属性组合示例，可能会在阅读工具中导致错误消息或使审阅人员感到困惑。","更明确地说明append（补充）的用法                           IWG成员可能会与其他机构分享更改\n","分配给子组进行测试\n","PhRMA率先对eCTD规范做小改动，并将结果带到下次会议\nNMV Req #ICH123"]
["1150","Health Canada","Health Canada","规范v3.2 ","当前规范定义了从企业发送给监管机构的消息。该规范的初衷是支持双向通信。这一节从未被记录在案。需要定义从监管机构发送给企业的消息。可以链接到生命周期管理。","重复，参见1110","推迟","考虑下一个主要版本的范围\nNMV Req #ICH87、ICH111、ICH112和ICH113"]
["1160","JPMA","JPMA","Leaf文件","不鼓励在文件之间建立链接，因为如果文件被修改将无法维护链接。","2009年10月更新：变更请求需要更改PDF，ICH不会追究。请参阅区域指南。","超出范围 ","有关下一个主要版本，请参阅EWG\n建议作为区域实施指南主题"]
["1170","JPMA","JPMA","PDF文件","Acrobat版本已更新。规范声明使用Acrobat Reader 4.0。应明确声明支持的PDF版本。应该仔细考虑这一点，包括考虑日语Acrobat，因为在某些阅读器版本中存在影响查看某些PDF版本的bug。","在规范文档中使用特定的pdf版本而不是Acrobat版本号。\n\n在下一个次要版本之前，已发布Q&A第40问\n\nM2 SENTRI小组还将探讨PDF A的可能性                     ","批准规范变更","纳入eCTD规范v3.2.1，第7-1页（在Q&A第40和46问中解决）"]
["1180","JPMA","JPMA","STF","请重新考虑STF中的研究报告信息的处理。创建STF文件是额外的工作。","子团队正在努力解决此问题以及变更请求1100中的问题","推迟","有关下一个主要版本，请参阅EWGNMV Req＃ICH42、ICH114和ICH128"]
[1190,"JPMA","JPMA","规范3.2","任何未来的eCTD规范都应该与当前的eCTD规范相互兼容。\n如果ICH M2计划修改eCTD规范，我们希望继续使用当前的eCTD数据，尤其是eCTD主干XML实例。\n此外，许多公司和监管机构可能已经投资于基于当前eCTD规范的系统。如果将发布下一个主要的eCTD规范，则必须修改这些系统。\n应尽量减少修改。我们需要当前和新的eCTD系统之间具有兼容性，或者至少我们需要一种方法来轻松地将eCTD从当前标准转换为新标准。","该问题在eCTD的变更控制流程中有所涉及","拒绝","无"]
[1200,"JPMA","JPMA","规范3.2和样式表","当前的DTD具有固定的TOC。浏览器的TOC基于样式表信息显示。\n在日本，我们希望有一个日文的TOC来加速审查并促进监管机构与申请人之间的沟通。\n此外，固定的eCTD TOC名称与实际的CTD TOC名称不同。",null,"超出范围","请参阅EWGNMV Req＃ICH52和ICH126"]
[1210,"JPMA","JPMA","规范3.2","将来，CTD结构（TOC）可能会被修改。这将需要相应的eCTD规范更改。很难对eCTD规范进行频繁更改，也会对企业、监管机构和供应商造成负担。如果M2计划修改eCTD规范，则应考虑在修订CTD TOC时易于维护eCTD规范。",null,"超出范围","请参阅EWGNMV Req＃ICH67"]
[1220,"JPMA","JPMA","规范3.2","没人能预测CTD结构将来会发生什么样的变化。因此，应设计eCTD规范以适应CTD变化。\neCTD规范应该使用XML命名空间来允许包含其他XML消息（例如，在eCTD中包含ICSR消息）。",null,"超出范围","请参阅EWGNMV Req＃ICH67"]
[1230,"JPMA","JPMA","规范3.2","目前的eCTD样式表具有固定的标签。那么就不可能适应一些CTD TOC要求（例如，不可能在2.3 TOC中显示制造和成分，这是CTD要求）。\neCTD规范应具有一定的灵活性，以显示要求和CTD规范意图。",null,"超出范围","请参阅EWG\nNMV Req  #ICH52、ICH127，并作为实施指南的一部分解决"]
[1240,"MHLW","MHLW","实例","根据对当前评估过程的拟合，不仅需要完整的XML实例，还需要累积的XML实例。","需要解决日本的业务需求\n","超出范围 ","请参阅EWG由MHLW撤回（2009年6月）"]
[1250,"MHLW","MHLW","Leaf文件","对于重复使用文档，应该允许使用XML文档作为leaf文件。",null,"批准Q&A","纳入eCTD规范v3.2.1，第7-5页（在Q&A第39问中解决）"]
["1260","DOCUMENTUM","PhRMA","STF样式表(ich-stf-stylesheet-2-2.xsl)，版本2.6，2004年11月17日","原始样式表将无法正确处理xlink:href的值。它假定href值包含序列号。[FDA的样本文件并非如此。]\n以下将使用原始样式表找到该文件（但在正确显示STF页面时仍然存在问题，因为它无法正确处理相对路径）：\n<doc-content xlink:href=\"../../../../../../../0000/index.xml#e5155\">\nRewriting the above in an equivalent way：\n<doc-content xlink:href=\"../../../../../../index.xml#e5155\">\n产生以下信息：\n文档标题 = 无法显示XML页面\n我们修复了上述问题和其他问题，以便正确显示STF。此外，为了允许不存在序列号的情况，我们还允许申报资料的名称具有任何长度，而不仅仅是4个字符（例如“0000”）。","eCTD IWG将尽快发布新的样式表","批准","重写样式表"]
["1270","PhRMA","PhRMA","STF规范版本2.6，2004年11月17日","引用STF文件的leaf的每个示例都错误地使用属性“version（版本）”字段。“version（版本）”属性用于申办方的内部版本号或leaf引用的文件的版本标识。STF规范文本中“version（版本）”下引用的信息是否实际上应在“application-version（申请版本）”下引用？或者，“application-version（申请版本）”是否仅用于内容文件（例如，PDF、MS Word）？","ICH正在调查此错误。这将在下一个次要版本中更新。\n\n使用version（版本）字段的规范示例是错误的，但ETICS显示所有供应商都按照STF规范编写。为了尽量减少对现有工具的重新设计，在发布下一个主要版本之前，使用将保留原样。","推迟","无"]
["1280","PhRMA","PhRMA","规范v3.2 ","在许多情况下，申办方需要在单个申报资料中的leaf之间建立“append（补充）”关系，而当前规范建议不要这样做。\n商业案例：\n1）可能需要拆分大文件。监管机构和申办方更喜欢这些文件在消息中相关（通过“append（补充）”），而不是每个文件都被提交为“new（新建）”而没有任何关系。\n2）提交以前未提交的粒度文档。在该集合的leafs中存在明显的“append（补充）”关系（例如，对协议的修订）。在提供此集合时，申办方希望建立leaf关系以在此类信息的呈现中保持一致（与此类型的其他文档相比），并在将来支持更有效的生命周期管理。显示这些关系要比将它们全部作为“new（新建）”文件更为清晰。\n","1）补充不得用于关联分割文件，如规范v3.2，第6-3页中所述     2）批准纳入下一个次要版本中","1）拒绝      2）批准纳入下一个次要版本中","纳入eCTD规范v3.2.1，表6-3"]
["1290","Acusphere","FDA","规范v3.2第4-25页，以及eCTD IWG Q&A和规范变更请求文件，版本1.9，变更请求00050和Q&A第12问。","我们要求澄清章节3.2.A.3中编号部分的文件夹和文件命名约定。                                            eCTD定义了对于每种新型赋形剂，应在章节3.2.A.3中创建一个单独的文件夹，每个文件夹使用赋形剂的名称作为唯一标识（例如，32a3-excip-name1和32a3-excip-name2）。目录/文件结构应遵循模块3中的原料药章节。\n考虑到新型赋形剂的附录遵循原料药结构，但这些赋形剂不是原料药，可否就附录3.2.A.3中子文件夹和文件的编号部分的命名约定提供指引？（例如，对于标题为“3.2.S.2 制造”的章节，我们的方法是省略新型赋形剂文件夹名称中的“s”，并使用以下约定之一：32a32-manuf-Name1或32a3-2-manuf-Name1）。这种方法是否可接受？","问题将在eCTD规范下一个主要版本的要求收集期间得到解决","批准规范变更\n（2007年10月更新）\n推迟\n批准Q&A（2012年6月）\n","请参阅CTD-Q（2007年10月更新）\nQ&A第78-79问"]
["1300","Acusphere","FDA","规范v3.2，第4-19和4-20页，以及eCTD IWG问题解答和规范变更请求文件，版本1.9，Q&A第3问。","当信息包含在章节3.2.A.3中时，我们要求澄清有关药物新型赋形剂的信息量，这些信息必须包含在章节3.2.P.4中。\nCTD规定每种非药典赋形剂都可以提供一个单独的章节（从3.2.P.4.1至3.2.P.4.4），3.2.P.4.5和3.2.P.4.6是单独的文件。在eCTD中构建这些元素的方法在eCTD IWG问答和规范变更请求文件版本1.9的Q&A第3问中得到了解决。\n对于新型非药典赋形剂，是否应该重复包含3.2.P.4.1到3.2.P.4.4文件的文件夹，即使CTD已经规定新型赋形剂应该在章节3.2.P.4.6和3.2.A.3中讨论？\n另外，如果章节3.2.A.3中提供了更详细的信息，可否澄清3.2.P.4.6中需要多少关于新型赋形剂的信息？仅仅将评审人员引导至3.2.A.3获取更多信息是否足够？","这主要是一个CTD问题，应该提交给ICH秘书处。","超出范围\n批准Q&A（2011年11月）","无\n请参阅CTDQ\nQ&A第72-75问"]
[1310,"GE Healthcare","EFPIA","M4粒度附录","粒度文档规定：“此外，文档的所有页面都应该包含一个唯一的页眉或页脚，用于简要地识别其主题。在纸质药物申报资料中，应在文档之前的选项卡上使用类似的标识符，以便于在申报资料中查找该文档。可以使用完整章节编号和标题的缩写。”\n\n使用eCTD，评审人员可以获得大量元数据来方便地识别相关文档，而无需在页眉或页脚中放置标识符。",null,"批准Q&A","纳入eCTD规范v3.2.1，第7-2页（在Q&A第41问中解决）"]
[1320,"ING America Inc.","JPMA","eCTD版本3.2规范及最新发布的eCTD Q&A ——版本1.11，2006年6月8日","关于CRF的位置的指导令人困惑，似乎与欧盟和美国的区域指南（ETICS中的问题区域）相冲突。当前的混乱需要消除。CTD和eCTD中的处理不同。\n对于eCTD：\n在M5.3.7文件夹中，CRF和个体患者数据列表的PDF文件均应按研究进行组织。但是，在index.xml文件中，CRF和个体患者数据列表的leaf元素应包含在与其他研究报告文件相同的标题下，并且任何随附的研究标签文件中都包含其他信息。此外，重复使用的leaf元素可以放在标题5.3.7 CRF和个体患者数据列表下。如果该区域要求，则数据集应根据区域指南进行组织。\n出版物和参考文献的文件应位于M5.4文件夹中。但是，在index.xml文件中，出版物和参考文献的leaf元素应包含在与其他研究报告文件相同的标题下，并且任何随附的STF中都包含其他信息。此外，重复使用的leaf元素应放在标题5.4参考文献下。","Q&A＃25已被Q&A＃42取代以解决此问题","批准Q&A","纳入eCTD规范v3.2.1，第3-13页（在Q&A第42问中解决）"]
[1330,"ING America Inc.","JPMA","eCTD版本3.2规范、STF的各种相关规范与区域模块。","ICH M2 eCTD Q＆A第36项编号2和6表明，eCTD申报资料使用正确和准确的DTD和架构，并且每个DTD或架构的MD5校验和必须与“已发布的”MD5校验和匹配。但是，众多DTD（和架构）中只有一个（即eCTD V3.2 DTD）与其校验和一起在固定的Web位置发布。这引起了工具供应商、申办方和监管机构的困惑。在ETICS研究期间，供应商正在使用几种不同版本的EU V1.1 DTD。还发现了其他修改的DTD。\n建议：与eCTD相关的所有DTD和架构（ICH或区域）都要发布在ESTRI网站上，以及它们各自的MD5校验和以及任何所需的样式表或相关文件（例如，valid-values.xml）。每个地区都应承诺通过商定的流程维护ESTRI网站上的最新信息（可能在每次M2会议上审查和确认这些项目）。","每个区域负责发布在其自己的区域中创建和使用的DTD和架构的校验和。ICH DTD的校验和将在ESTRI网站上提供。","已获批准","更新ESTRI网站以添加STF DTD校验和"]
[1340,"ING America Inc.","JPMA","STF规范版本2.6与STF V2.2 DTD， 2004年11月17日","“content-block（内容块）”元素及其子元素保留在DTD中，但是内容块的使用已从规范中删除，并且不打算使用它。应该从DTD中删除，以保持一致性和准确性。","重复CR#1010。\n\n即使它们仍在DTD中，也不得使用content-block。这将在今后的DTD版本中得到纠正。\n\n同意，应在下一版STF规范和DTD中更新","批准规范变更","下一个主要版本\nNMV Req #ICH114和ICH128"]
[1350,"WSMI","EFPIA","DTD","标题中的链接“http://www.ich.org/ectd”会导致错误的消息。建议替换为“http://estri.ich.org/ectd”。XLINK的引用不是实际的“http://www.w3c.org/1999/xlink”。建议替换为“http://www.w3.org/TR/xlink”","同意，应在下一版ICH eCTD规范和DTD中更新\n\n2009年10月更新：正确的引用应为“http://www.w3.org/1999/xlink”\n\n另请参阅CR＃1970","批准规范变更","下一个主要版本\n重新评估与eCTD NMV的相关性"]
[1360,"eCTDconsultancy BV","EFPIA","无变更，仅澄清——eCTD规范v3.2附录6","请确认单个文件是否可以替换来自以前各个序列的多个文件。","否，单个leaf操作只能针对单个leaf元素。区分leaf元素和文件很重要。eCTD规范规定了leaf元素的管理，而不是文件的管理。","批准Q&A","纳入eCTD规范v3.2.1，第6-4页（在Q&A第43问中解决）"]
[1370,"eCTDconsultancy BV","EFPIA","无变更，仅澄清——eCTD规范v3.2附录6","请确认eCTD生命周期中的单个文件是否可以进行多次替换","否，申请中的一个leaf元素被替换后，其不再是当前leaf。只可替换后续序列中的当前leaf。","批准Q&A","纳入eCTD规范v3.2.1，第6-4页（在Q&A第44问中解决）"]
[1380,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4 第90行","请修改指南，为每种赋形剂提供一个3.2.P.4.1文件，无论其是否涉及药典或非药典赋形剂。","请参阅ICH M4粒度附件，该附件表明3.2.P.4.1可能包含一个或多个文档。eCTD指南提供了将每种赋形剂（药典或非药典）放在单独文件中的灵活性。","超出范围\n批准Q&A（2011年11月）","请参阅CTD-Q\nQ&A第72-75问"]
[1390,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4 第90行","请允许在同一份文件中引用多个区域药典。药典赋形剂是在一个或多个药典中描述的赋形剂。如果在多个药典中描述了赋形剂，是否允许列出所有相关药典，而不限于与单个国家相关的药典？\n这样可以最大限度地重复使用文件3.2.P.4.1。\n在3.2.4.1和3.2.P.5.1等文件中对药典的引用也适用同样的原则。\n","这超出了M2 IWG的范围","超出范围\n","请参阅CTD-Q\n"]
[1400,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4 第90行","如果（例如，USP/NF或欧洲药典显示）赋形剂的名称发生变化，应如何更新eCTD？赋形剂的名称必须包含在eCTD的元数据中。甚至反映在3.2.P.4下的文件夹名称中。在药品生命周期中，使用的特定赋形剂的名称可能随时间而改变，但不会改变制剂。\n\n如何在eCTD层面上处理特定药典赋形剂名称的改变？\n\n如何在eCTD层面上处理特定非药典赋形剂名称的改变？\n","eCTD规范没有在生命周期中对属性进行更改的明确机制。为了解决这个问题，申请人会删除存在错误excipient（赋形剂）属性的元素中的所有leafs，并在具有正确excipient（赋形剂）属性的元素中重新提交这些leafs。这种解决方案将适用于药典和非药典赋形剂。在执行此操作之前，请咨询监管机构。","批准Q&A","纳入eCTD规范v3.2.1，附录4和6（在Q&A第45问中解决）"]
[1410,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4","在eCTD层面上如何处理在初次提交时为非药典赋形剂后来成为药典赋形剂的赋形剂？药典赋形剂不得集中在一份文件3.2.P.4.1中。当药典中描述了最初的非药典赋形剂时，申请人可以通过replace（替换）操作提供替换文件3.2.P.4.1，并具有已修改文件3.2.P.4.1、3.2.P.4.2、3.2.P.4.3和3.2.P.4.4该问题/建议涉及关于药典赋形剂文件粒度的问题3和关于使用一个替换文件替换多个文件的问题1。","这超出了M2 IWG的范围","超出范围\n批准Q&A（2011年11月）","请参阅CTD-Q\nQ&A第72-75问"]
[1420,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4","请提供指导，说明原料药和制剂的“Manufacturer（制造商）”属性是生产中心。制造商的名称必须包含在eCTD的元数据中。甚至反映在3.2.S和3.2.P下的文件夹名称中。在药品生命周期中，制造商的名称可以改变而不改变生产工艺。\n如果提交纸质文件，则此类更改被视为行政更改。但是，当使用制造名称时，它会对eCTD生命周期的结构产生巨大影响，从而导致eCTD生命周期的当前和累积视图片段化。如果使用制造地点（城市），名称更改不会影响eCTD的当前和累积视图                                    当在一个城市使用元数据，而制造商将其工厂迁移到另一个位置时，将产生新的3.2.S或3.2.P，并且更改将如预期可见。\n","eCTD规范没有在生命周期中对属性进行更改的明确机制。制造商属性的细节需要参考CTD-Q。将在4.0版中分析更改制造商的机制。\n\n另见CR＃1400（Q&A第45问）","推迟\n\n批准Q&A（2009年10月）","Q&A #65-70"]
[1430,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4","请提供指导，制造研究中心“common（通用）”可用于独立于原料药和制剂生产工艺中涉及的制造研究中心的文件。模块3中的以下章节独立于制造工厂：\n• 3.2.S.1 一般信息\n• 3.2.S.3 表征\n• 3.2.P.1 一般说明和组成\n• 3.2.P.2 产品开发\n• 3.2.P.3.1 制造商\n\n如果必须在每个制造商下列出这些文档，则文档可能会被纳入文件夹结构中一次，但在eCTD中，它必须进行多次链接。因此，leaf级别的生命周期必须重复多次。使用“common（通用）”作为属性“manufacturer（制造商）”的值将消除这种冗余。\n","目前尚未由规范定义。","推迟\n\n批准Q&A（2009年10月）","Q&A #65-70"]
[1440,"eCTDconsultancy BV","EFPIA","eCTD规范v3.2附录4","请提供指导，“product-name（产品名称）”属性与商标无关，但对于注射用粉末和溶剂，涉及活性成分和稀释剂成分之间的区别。此外，对于IND，可用于描述参照药物或安慰剂制剂。","目前尚未由规范定义。","推迟\n批准Q&A（2012年6月）","请参阅CTD-Q\nQ&A第70问修订版"]
[1450,"AstraZeneca","EFPIA","ICH eCTD Q&A 40","ICH eCTD第40问询问是否所有区域均可提交PDF V1.4文件。虽然给出的答案是肯定的，但实际上远远不止“可接受性”这么简单，似乎强制要求eCTD使用V1.4版本。V1.4不应该是“可接受的”或者可能是“首选的”（如果合理的话）而不是“强制性的”吗？","Q&A第40问将被取消，创建了Q&A第46问，即：所有区域都同意接受PDF 1.4。请参阅区域指南以提交其他版本的PDF。","批准Q&A","纳入eCTD规范v3.2.1，第7-1页（在Q&A第46问中解决）"]
[1460,"Mission3","PhARMA","eCTD V3.2规范，第        2-2页","Mission3提交此变更请求，建议将提交的叙述内容从PDF迁移到XML。符合该行业需求的XML模型将为申办方和监管机构评审人员带来明显的好处。","M2 EWG继续监控文档格式标准。M2 EWG目前不建议将XML用于叙述性内容。","推迟","推迟到SENTRI工作组"]
[1470,"Roche Products Ltd","EFPIA","ICH Q&A，Q&A36，第12项","ICH Q&A36第12项表明：“确保通过xlink：href引用标识的所有文件都存在。”  应该澄清这一点，以说明文件可以存在的位置。","必须咨询区域当局，以确定xlink:href的目标是否可以存在于引用leaf出现的序列之外。此文本将添加到Q&A ＃36第12项","已获批准","Q&A #36修订版"]
[1480,"Roche Products Ltd","EFPIA","ICH Q&A36，第20项","ICH Q&A36第20项表明：“确保leaf或节点扩展名Title（标题）属性不为空（除非操作属性为delete（删除））。”  目前尚不清楚为什么要列出括号中的条件。","第20项的声明修改为：确保leaf或节点扩展名Title（标题）属性不为空。唯一的例外是operation（操作）属性值为“delete（删除）”的leaf元素，其中Title（标题）可以为空。","已获批准","Q&A #36修订版"]
[1490,"Roche Products Ltd","EFPIA","DTD","批准的变更请求00050表示，模块3.2.A.3的元素将成为规范3.2版中的重复属性。这一点似乎尚未实现。","同意，基数会从?改为*","批准规范变更","下一个主要版本\nNMV Req #ICH129"]
[1500,"Take Solutions Ltd","EFPIA","规范v3.2和/或Q&A 文件","区分模块3.2.A.3中多个新型赋形剂","同意，在DTD中增加excipient（赋形剂）属性","批准规范变更","下一个主要版本\nNMV Req #ICH129"]
[1510,"PhRMA","PhRMA","ich-stf-stylesheet-2-2.xsl","当前发布的ICH STF样式表在Internet Explorer中显示的结果不一致。它似乎在某些情况下有效但在其他情况下则无效。使用较旧版本的样式表可查看的STF文件不一定总是可见。","正在分析STF样式表2.2版。","已获批准","重写样式表"]
[1520,"PhRMA","PhRMA","Valid-values.xml","ESTRI网站上发布的有效值文件中列出的值与FDA网站上发布的有效值文件存在差异。","建议申请人遵循区域指南。将分析ICH清单，并在将来采取纠正措施","已获批准","区域问题"]
[1530,"EXTEDO – IABG Life Sciences Solutions","EU","仅DTD","选择性地解决了生成断开链接的概念缺陷，或者只为了更新超链接信息而重新提交文档的需求。","ICH M2确认已收到该提案，并将根据eCTD下一个主要版本的业务要求进行考虑。\n2009年10月更新：变更请求需要更改PDF，ICH不会追究。请参阅区域指南。","推迟\n超出范围","下一个主要版本\n建议作为区域实施指南主题"]
[1540,"PhRMA","PhRMA","DTD和编写规范，附录4（包括意见文本）、 6和8","制造商的eCTD属性应从DTD和2.3.S、2.3.P、3.2.S、3.2.P的书面规范中删除。","超出范围 ","推迟\n\n批准Q&A（2009年10月）","Q&A #65-70"]
[1550,"PhRMA","PhRMA","编写规范附录4，模块3文件名的所有行项","附录4中模块2.3和模块3的所有文件名应以斜体显示——表示它们是可选的，而不是强制性的","进一步分析要完成的规范\n\n另见CR # 110","已获批准","纳入eCTD规范v3.2.1"]
[1560,"PhRMA","PhRMA","DTD，编写规范","章节3.2.P.8.3应该是一个可重复的元素，具有可选的规格、包装配置、储存条件和制造商属性。如果技术上可行，建议至少需要四个属性中的两个。","超出范围 ","推迟\n批准Q&A（2012年6月）","请参阅CTD-Q\nQ&A第77问"]
[1570,"PhRMA","PhRMA","编写规范，附录4和6。意见和示例文本。","评论文本（附录4和6中的例子）建议制剂规格作为剂型属性的延伸“应提供包含规格的剂型名称，即tablet-5mg”。我们建议在描述制剂剂型的eCTD属性中删除所有对制剂规格的引用考。","超出范围 ","推迟\n批准Q&A（2012年6月）","请参阅CTD-Q\nQ&A第70问修订版"]
[1580,"PhRMA","PhRMA","eCTD规范版本3.2附录7","对于在eCTD中提交的文件，PDF/A-1是否是可接受的PDF文件格式？","PDF/A-1是一种存档格式，不符合与eCTD配套使用的ICH评审要求。将确定跨区域的存档格式要求，并持续监控新兴技术，以确定合适的存档格式。","批准Q&A","纳入eCTD规范v3.2.1，第7-1页（在Q&A第47问中解决）\nQ&A #80（2013年11月）"]
[1590,"Datafarm inc.","PhRMA","规范v3.2和/或Q&A文档","在上一次ETICS研究中，很明显物理CRF文件的存储不一致。Datafarm遵循基于Q&A #25的ICH规则。当答案被撤回时，我们需求区域指导。\n我们目前将leaf放在适当的CTD元素下进行研究，物理文件存储在研究文件夹中的5.3.7文件夹下。\n问题：\nFDA：我们应该将CRF文件放在哪里？\nEU/HC：我们应该将CRF文件放在哪里？您是否想要5.3.7中或提供研究文件的章节下的所有CRF？\nJP：我们应该将CRF文件放在哪里？您是否想要5.3.7中或提供研究文件的章节下的所有CRF？\n所有：我们是否可以在v3.3.3之前或之后期待来自ICH或区域监管机构的更新的规范/指南？\n","这个问题已在Q&A第42问中得到解决","超出范围","纳入eCTD规范v3.2.1，第3-13页（在Q&A第42问中解决）"]
[1600,"eCTDconsultancy Ltd","EFPIA","M2 eCTD样式表","更改M2 eCTD样式表，以便：\n1.各章节以逻辑CTD结构呈现，而不是根据底层XML格式化2.单个序列中多个leaf指向一个文档时，可以显示。以这种方式呈现的好处是，如果指南改变并且包括对供应商关于查看和处理元数据的建议，则这种在生命周期中处理/查看的方式将解决当前与替换结构元数据相关的问题。","有多种方法可以通过样式表显示数据；通过当前样式表支持通用视图。ICH没有计划修改当前接受的样式表。","拒绝","无"]
[1610,"PhRMA","PhRMA","eCTD规范版本3.2，标题元素3.2.A.3","当前的变更请求＃1290建议更新ICH M4Q，以适应3.2.A.3新型赋形剂中数据内容的建议文件夹结构，与3.2.S中提供的结构相似，但没有提供额外的定义。\n标题元素3.2.A.3要求子文件夹结构与3.2.S原料药相似。目前的M4Q指导规定，应提供“与3.2.S所包含的数据相似的”数据。为了最大限度地提高新型赋形剂数据的可检查性，建议将额外的子元素引入eCTD XML主干中，以提供与3.2.S所述相似的内容组织。为了避免与其他类似命名的标题元素混淆，建议将新的子章节命名为3.2.A.3.1，或者正式将新型赋形剂作为3.2.S下的原料药处理，并提供区分活性成分与新型赋形剂的标准。","这已在之前的CR＃1290中讨论过，并推迟到将来考虑。","推迟\n","请参阅CTD-Q"]
[1620,"PhRMA","PhRMA","编写规范，附录4","1）为了支持在所有国家/地区更加一致地实施eCTD规范，所有可选的文件名和文件夹名称都应以斜体表示。目前，该文件中有多种解释，个别卫生当局对该规范的解释达到了极端的程度（例如比利时）。\n2）应缩短规范中强烈推荐但可选的文件名。\n3）eCTD文件夹名称也应缩短或可选，以帮助减少路径长度。","m2-m5文件夹中的所有ICH定义的文件和文件夹名称都是可选的。强烈推荐的目录和文件名称在规范的附录4中提供。如果文件和文件夹名称以斜体显示，则申请人将根据自己的命名惯例用文件名替换这些名称。另请参阅Q＆A第15问和eCTD规范版本3.2，第2-1、2-5和4-1页。\n\n另见CR＃110和1550","拒绝","纳入eCTD规范v3.2.1"]
[1630,"PhRMA","PhRMA","eCTD v3.2","eCTD标准的完全实用性受到无法准确生成申请的当前视图的限制，这将“当前，已批准”与“当前，已提交”区分开来。\n应鼓励工具供应商开发一种机制，允许申办方控制所提交信息的显示，从而将申报资料上市后变更的“当前，已提交”视图与变更的“当前，已批准”视图区分开来。","这是对支持生命周期管理的要求的补充。这些要求将在eCTD规范的下一个主要版本中予以考虑。","推迟","下一个主要版本\n作为区域实施指南主题解决"]
[1640,"PhRMA","PhRMA","ICH M2规范附录3、附录4和附录8 3.2.A.1","在附录3中，模块3质量下的一般注意事项，在表3-3中，将3.2.A.1的描述从“设施和设备（名称、制造商）”更改为“设施和设备（名称、制造商、设施）”。\n在附录4文件组织中，将项目123的标题从“设施和设备（名称、制造商）”更改为“设施和设备（名称、制造商、设施）”在附录8 XML eCTD DTD中：允许使用新的可重复元素3.2.A.1. 设施和设备（名称、制造商、设施）","请参阅CTD-Q。","推迟\n批准Q&A（2012年6月）","请参阅CTD-Q\nQ&A第78-79问"]
[1650,"PhRMA","PhRMA","ICH M2规范附录4第39项","审查M5中使用统一术语或“原料药名称”受控词汇的标准制定进展：药物词典的数据元素和标准，因为它可能与该模块3 eCTD属性的统一方法有关。","推迟到定义了标准术语之后","推迟","无"]
[1660,"PhRMA","PhRMA","ICH M2规范附录4第39项","关于使用强制性eCTD属性，ICH M2指南中“substance-1”显示的原料药名称，可以软化附录4第39项下关于CMC属性“substance-1”的意见，允许当前选择或选择使用[较短的]内部公司代码，或规定属性和文件夹名称不需要完全相同，以减少路径长度。","附录4第39项下的措辞将予以修订。","批准规范变更","纳入eCTD规范v3.2.1，附录4"]
[1670,"EFPIA","EFPIA","eCTD规范，版本3.2，第2-3页、第5-2页和eCTD DTD。","对eCTD中的内容创建和管理每个leaf的MD5校验和的要求是eCTD的任何创建者的主要负担。众所周知，单个MD5的创建和管理本身并不是特别繁琐。但是，即使只创建少数几个MD5，也很快会变得繁琐不堪。\n在维基百科中校验和定义为：“校验和是一种冗余校验，一种通过检测通过空间（电信）或时间（存储）发送的数据中的错误来保护数据完整性的简单方法。它的工作原理是将消息的基本组件（通常是断言位）相加，并存储结果值。任何人都可以在以后对数据执行相同的操作，将结果与真实的校验和进行比较，并且（假设总和匹配）得出消息可能没有被破坏的结论。” \neCTD中包含的校验和未以这种方式使用。无效的校验和应表明存在损坏，并且应导致不处理申报资料。然而，典型的用法是只看到出现一个标志，但是继续处理。\neCTD中的校验和可以是为整个申报资料创建的单个校验和，以便在传输期间和一段时间内提供文档完整性的度量。\n该变更请求建议取消校验和作为每个叶子的属性。\n该变更请求进一步建议完全取消校验和或仅作为整个申报资料的计算值保留。","将作为下一个主要版本的需求收集的一部分进行讨论。","推迟","下一个主要版本\nNMV Req #ICH108和#ICH110"]
[1680,"FDA","FDA","eCTD规范，版本3.2，第2-5页，附录3。","当前的eCTD规范规定了在发布eCTD申报资料时要使用的特定文件夹名称。此外，当前规范要求最大路径长度为230个字符，以使监管机构能够添加其他字符。经验表明，试图利用规定的命名约定的提交者经常会超过230个字符的限制，导致操作系统处理时路径的完整性丧失。此变更请求建议修改有关文件夹命名的建议，并减少建议的最大路径长度。","将作为下一个主要版本的需求收集的一部分进行讨论。","推迟","纳入eCTD规范v3.2.1，附录2"]
[1690,"Datafarm inc.",null,"STF样式表v2.2a","版本2.2a有一个新名称，这使得它很难在任何现有的eCTD或即将完成的eCTD中实现。\n此外，这将导致一些系统中的代码更改，这将在补丁发布和升级中引入复杂性。\n1.我们可以将样式表名称更改为ich-stf-stylesheet-2-2.xsl吗？这样我们就不必对STF XML文件进行任何更改。\n2.  当将来只更改组中的某些组件时，请考虑维护文件名。","声明样式表版本的标准方法是通过其文件名。命名约定的审查将在下一个主要版本中完成。有关详细信息，请咨询区域当局。","批准","下一个主要版本\nNMV Req #ICH127和ICH130"]
[1700,"CHINOIN Ltd.","EFPIA/EU","ich-ectd-3-2.dtd","如何将M3.2.S.2章节（制造商）的OPEN（申请人）和CLOSED（受限制）部分插入制剂的eCTD中？","这是一个区域性问题。","超出范围","无"]
[1710,"Sahmed","EFPIA","eCTD规范（节点扩展）","是否可以使用eCTD来管理组合医疗器械药品（例如，药物洗脱支架）的器械章节？","有关节点扩展的使用，请参阅区域指南。","超出范围","无"]
[1720,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （区域校验和）","变更请求1330建议所有区域检验均应发布在M2/ESTRI网站上。人们认识到，这可能会耗费时间，而且维护起来很麻烦。可否更改此建议，并在M2/ESTRI网站上提供与校验和相关的区域网站链接？","同意","批准","更新ESTRI网站"]
[1730,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 (index-md5.txt)","是否可以对“index-md5.txt”文件的格式提供其他指导？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #48"]
[1740,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （属性值）","可否提供关于如何处理缺失属性值的额外指导？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #49"]
[1750,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （样式表）","ICH eCTD Q&A的问题30，申请人应就提供自己的样式表的可接受性寻求区域指导。ICH M2/ESTRI网站已经发布了ICH样式表的校验和，我们知道如果提供的样式表的校验和与发布的值不匹配，某些eCTD验证工具将报告问题。\nICH是否可以对申请人创建的样式表的可接受性给出任何进一步的指导？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #50"]
[1760,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （util文件夹）","对util/dtd和util/style文件夹的内容是否有任何限制？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #51"]
[1770,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 (leaf ID)","Leaf ID在eCTD序列中或XML实例中是唯一的吗？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #52"]
[1780,"ICH M2 IWG","ICH M2 IWG","STF规范，v2.6","是否允许从同一主干实例或另一个序列中的多个leaf引用单个STF文件？","由于管理每个使用实例的生命周期需求的潜在问题，不建议这样做。不得提交具有同一研究ID的多个STF。","批准Q&A","Q&A #60"]
[1790,"ICH M2 IWG","ICH M2 IWG","STF规范，v2.6","是否允许在STF文件中引用同一主干实例或另一个序列中的另一个eCTD元素中的leaf元素？\n\n是否允许从同一主干实例或另一个序列中的多个leaf引用单个STF文件？","由于管理每个使用实例的生命周期需求的潜在问题，不建议这样做。不得提交具有同一研究ID的多个STF。","批准Q&A","Q&A #61"]
[1800,"ICH M2 IWG","ICH M2 IWG","STF规范，v2.6","为了符合STF规范中题为“在CTD的不同子章节中呈报一项研究的信息”的章节的规定，是否允许在主干的两个不同位置提供具有同一研究ID的多个STD文件？","在提交与多个eCTD子章节相关的一项研究的结果时，应创建一个STF，并将其与单个子章节相关联。对于该研究涉及的额外的每个子章节，申办方应提交一份文件，记录可以找到STF的子章节。\n\n如果希望能够保留在单个子章节下控制研究报告生命周期的能力，而不是提交单个文件，您应提交额外的STF文件和附带的leaf。多个STF的研究id应由独特的研究标识符组成，其附加有澄清后缀，例如，ADME123-absorption、ADME123-distribution。不得提交具有同一研究ID的多个STF。","批准Q&A","Q&A #62"]
[1810,"ICH M2 IWG","ICH M2 IWG","STF规范，v2.6","为了遵守STF规范中题为“区分CTD同一子章节中的时间特异性分析”的章节的规定，是否允许在同一位置提供具有同一研究ID的两个STF文件，并使用研究标题区分这两组分析？是否允许或建议给研究ID中添加后缀以区分这两组分析？","具有同一研究ID的两个STF文件将被解释为同一研究。不可能通过研究标题进行区分。给研究id添加后缀将支持区分，例如，abc123-6month、abc123-12month。","批准Q&A","Q&A #63"]
[1820,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （书签）","eCTD中的所有PDF文件都必须有书签吗？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #53"]
[1830,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （文件夹）","eCTD文件夹结构是否可以包含空文件夹（即，不包含其他文件夹或文件的文件夹）？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #54"]
[1840,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2 （PDF文件）","eCTD规范建议PDF 1.4是所有地区唯一可接受的版本。ICH对其他PDF文档属性是否有任何建议？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #55"]
[1850,"ICH M2 IWG","ICH M2 IWG","eCTD规范，v3.2（适用版本）","如何使用leaf说明中的申请版本属性？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #56"]
[1860,"ICH M2 IWG","ICH M2 IWG","eCTD规范， v3.2 (xml:lang)","可否澄清xml:lang的正确用法？","在ETICS II研究中提出以下问题 ","批准Q&A","Q&A #57"]
["1870","MHLW","MHLW","eCTD规范v3.2.2，附录4，第4-10至4-16页","在eCTD规范3.2.2，第6-2页，表6-2之前的两段，表示：\n“对于每个系列，引用此文件的leaf元素的操作属性）始终是‘new（新建）’。”\n在日文中，它并不是总是“new（新建）”。\n为了将其正确纳入规范，应该写明：\n“有关引用文件的leaf元素的操作属性，请参阅区域指南。”","错误地纳入eCTD规范v3.2.2。Q&A #24仍然是正确的","批准下一个次要版本","Q&A #24"]
["1880","EFPIA","EFPIA","eCTD规范v3.2.2","许多工具供应商假设3.2.S和3.2.P章节的元数据值与模块3目录结构中的文件夹名称之间存在明确的链接。该假设造成原料药和制剂属性的元数据值的总文件夹/文件路径长度特别长的潜在问题。","ICH M2了解所描述的问题。","批准Q&A","Q&A #58"]
["1890","Extedo ","EFPIA","eCTD规范v3.2.2","模块3和模块5中的属性（如“substance（物质）”，“manufacturer（制造商）”和“indication（适应症）”）通常由eCTD工具逐字复制为相关文件夹名称。这导致一些非常长的路径名称，这些路径名称在提交过程中偶尔会被截断。在如上所述的情况下，如果遇到这样的长路径并且eCTD的提交者希望通过提交使用缩写文件夹名称的同一申请的新序列来纠正这一点（不再匹配属性或以前提交的文件夹名称），是否建议这样做？这是否会导致接收机构出现生命周期问题？","产品生命周期中的文件夹名称维护问题将在Q&A中解决","批准Q&A","Q&A #59"]
["1900","EFPIA","EFPIA","MD5 check for index-md5.txt","Q36检查第11项写着：“确保每个文件的校验和等于相关主干文件（即，index.xml、xx-regional.xml）中所述的相关校验和。”\n由于这个措辞，有些人已经解释说这个语句排除了检查index.xml文件的MD5校验和是否应该与index-md5.txt中的值匹配，因为这个值没有被录在主干文件中。\n建议更新该语句，以“……在相关主干文件（即，index.xml、xx-regional.xml）或index-md5.txt中”包括校验和。",null,"批准Q&A","Q&A #36修订版"]
[1910,"DataPharm","PhRMA","eCTD规范版本3.2.2","请求需要属性为delete（删除）时的leaf标题","Q&A #36第20项已经过修改，以反映该问题的区域实施差异。","批准Q&A","Q&A #36修订版"]
[1920,"ePharmaCMC, LLC",null,"eCTD DTD","除了单独的leaf元素级别外，应该在模块3的标题元素级别（3.2.S、3.2.P、3.2.A.1）允许生命周期的delete（删除）操作）。","当前规范中不具备此功能。","推迟","下一个主要版本\nNMV Req #ICH59和#ICH60"]
[1930,"ePharmaCMC, LLC",null,"eCTD DTD","在eCTD中难以实现多项申请中包含的相同信息的交叉引用。虽然美国在技术上可以做到这一点，但引用只适用于单个leaf元素。对于质量数据，通常最有用的是引用标题元素3.2.S、3.2.P、3.2.A.1的整个内容作为不同申请中的完整实体。该概念可以进一步扩展，以适用于标题要素3.2.P.4和3.2.P.7，其中通用信息可以保存在一个档案中，并被引用或“用于”多项申请。\n为了实现e-working的真正好处，并最小化以eCTD的名义新创建的冗余活动，需要更改DTD以允许引用或“指向”整个标题元素，这些元素在另一项上市许可申请下已经被卫生当局审查并接受。","当前规范中不具备此功能。","推迟","下一个主要版本\nNMV Req #ICH59和#ICH60"]
[1940,"Wyeth on behalf of the IRISS group","PhRMA","安全","很多时候，会收到来自发布供应商的引用，其使用安全性以拒绝更改pdf文件。由于版权法支持以这种方式使用安全性，因此我们请求修改规范以使其保持一致。",null,"推迟","需要进一步审查"]
[1950,"eCTD Consultancy Ltd",null,"M2 eCTD样式表","更改M2 eCTD样式表，以便：\n1.章节以逻辑CTD结构的形式呈现，而不是根据底层XML进行格式化单个序列中多个leaf指向一个文档时，可以显示。\n以这种方式呈现的好处是，如果指南改变并且包括对供应商关于查看和处理元数据的建议，则这种在生命周期中处理/查看的方式将解决当前与替换结构元数据相关的问题。","请参阅变更请求#1600。","拒绝","无"]
[1960,"EFPIA","EFPIA","ICH eCTD规范， v3.2.2，附录7，第7-3至7-4页。","大多数自动将源文件转换为PDF的工具都会将weblinks转换为URL的活动超链接（请参阅ICH eCTD规范附录5第5-1页）。\nICH M2可否提供一些关于是否应该将weblinks转换为活动超链接的指导，以及申请人应该采取什么步骤来检查目标并记录链接的有效性？例如，ICH M2是否建议对weblinks进行测试，并且在提交的封面函中包含声明，说明测试的日期。或者，ICH M2是否建议weblinks根本不应转换为活动的超链接。","一般而言，申请人引入的参考文献应包括在申报资料中（参见模块5.4的M4E (R1)指南和eCTD规范v3.2.2附录2，链接，第2-2页)。由于无法保证网站链接在文档的生命周期内保持活动状态，因此不得使用URL链接。","批准Q&A","Q&A #64"]
["1970","Lexicode","EFPIA","1. eCTD DTD\n2. eCTD规范\n3. eCTD XSLT样式表","根据2001年6月27日发布的当前W3C XLink建议，XLink命名空间使用URI“http://www.w3.org/1999/xlink”，而不是“http://www.w3c.org/1999/xlink”，如eCTD标准所述。在eCTD中使用后一个URI会在基于标准的XML申请和XSLT样式表中造成命名空间冲突，这些申请和样式表碰巧使用或依赖于前一个正式的XLink命名空间声明。这是因为您不能使用相同的前缀“xlink”来引用两个不同的URI。","回顾引用的eCTD文档，结果表明，该错误存在于eCTD规范的多个位置，但不影响eCTD的可用性。\n\n正确的引用应为“http://www.w3.org/1999/xlink”。","批准规范变更","下一个主要版本\n重新评估与eCTD NMV的相关性"]
["1980","GSK","PhRMA","ICH eCTD规范，v3.2.2","在eCTD规范的附录4中，模块3 leaf元素的建议“标题”条目包含DS的术语“(name, manufacturer)（名称、制造商）”和DP的术语“(name, dosage form)（名称、剂型）”。\n\n目前，许多阅读工具（包括ICH样式表）仅在相应章节的顶部显示这些eCTD属性（基于XML属性与CTD章节元素的关联而不是单个leaf元素）。在某些情况下，阅读工具会自动将在章节级别分配的属性信息附加到申办方在每个leaf元素的标题字段中提供的信息中。\n\n申请人是否需要在eCTD的leaf标题中包含已经在模块3文档的eCTD章节级别的元数据（例如产品名称、剂型、制造商）中捕获的信息？","附录4中提供的示例仅用于说明目的。leaf <title>值应该简洁而有意义。这些章节的属性选择由申请人（例如，manufacturer-1（制造商-1）、all（所有)）自行决定。","批准","评论措辞修订版：下一次规范更新中的附录4 leaf标题"]
["1990","BMS","PhRMA","ICH eCTD规范，v3.2.3","ICH规范指出：“所有ICH区域卫生当局都能够阅读并同意接受保存为PDF版本1.4的PDF文件。”  \n此更改请求是为了更新ICH规范，使其与当前ISO 32000标准保持一致。","SENTRI目前正在审查ISO 32000标准在所有ICH区域的适用性，并将在ICH ESTRI网站（estri.ich.org）上提供有关PDF使用的最新建议。","批准","推迟到SENTRI工作组"]
["2000","FDA","FDA","STF规范，v2.6.1","FDA已采用非临床、临床和分析数据集的数据标准。FDA继续接受和接收非标准或遗留格式的数据。用于描述这些数据集的当前file-tags（文件标签）的描述性不足以正确识别这些数据集的格式，这会对评审和操作人员处理这些数据集产生负面影响。\n\n删除当前的“us”文件标签：“data-tabulation-dataset”和“analysis-dataset”。\n添加以下“us”文件标签：“data-tabulation-dataset-send”、“data-tabulation-dataset-sdtm”、“data-tabulation-dataset-legacy”。\n添加以下“us”文件标签：“analysis-dataset-adam”、“analysis-dataset-legacy”。","标签“data-tabulation-dataset-send”适用于根据CDISC SEND标准格式化的非临床制表数据。标签“data-tabulation-dataset-sdtm”适用于根据CDISC SDTM标准格式化的临床制表数据。标签“data-tabulation-dataset-legacy”适用于不符合这两个备选标准之一的所有制表数据集。\n\n标签“analysis-dataset-adam”适用于根据CDISC ADaM标准格式化的分析数据集。标签“analysis dataset-legacy”适用于未根据CDISC ADaM标准格式化的分析数据集。\n\n这项变更将包含在有效值3.0版本中，并将取代当前STF规范v2.6.1中提供的信息。\n\n有关这项变更的实施计划，请咨询地区当局。","批准规范变更","更新ESTRI网站上的Valid Values（有效值）文件，并包含在下一版本的STF规范中"]
["2010","M8","M8","eCTD规范v3.2.2","针对PDF 1.7 (ISO 32000)的ESTRI建议得到了支持，但也有一些限制。ICH应该澄清哪些版本的PDF现在可以接受。\n","所有ICH监管机构现在都接受PDF 1.4、1.5、1.6和1.7，其限制条件如M2建议中所述。","批准Q&A","Q&A #71"]
["2020","PhRMA","PhRMA","eCTD规范v3.2.2","第2-3页，Name（名称），规定文件名中不允许使用“低线”字符“_”，也称为下划线。下划线由SAS软件创建，该软件在FDA和全球范围内用于执行数据集的统计分析。下划线字符不会干扰生成格式良好的XML。\n我们建议更改规范以允许文件名中使用“低线”字符。\n\n","规范变更推迟到v4.0。\n有关当前可接受性，请参阅区域指南。","批准规范变更","下一个主要版本"]
["2030","FDA","FDA","eCTD规范v3.2.2","撤回此ICH eCTD问答（见附录A），因为：\n• 2003年的插图并未反映标准的eCTD实践。申办方通常不在赋形剂属性中命名药典赋形剂（例如硬脂酸镁），因为3.2.P.4中提供的信息很少。此插图（使用药典赋形剂）可以生成多个文件，每个文件只包含一个句子。最终的结果对评审人员并不友好。\n• 尚未就如何最好地处理3.2.P.4.5和3.2.P.4.6主题达成ICH CTD-Q共识。2003年的Q&A与赋形剂粒度的新Q&A的内容相矛盾（见附录B的重点章节）。\n\n",null,"批准Q&A","Q&A #72-75"]
["2040","IRISS CMC Topic Group","PhRMA","eCTD规范v3.2.2","推荐的eCTD附录4原料药和制剂的文件名不一致，这些微妙的差异会导致验证问题。"," ICH v3.2.2规范明确规定附录4中显示的文件和文件夹名称不是强制性的。ICH建议不要根据附录4验证eCTD文件名。","拒绝"]
["2050","IRISS CMC Topic Group","PhRMA","eCTD规范v3.2.2","并非所有的eCTD标题都与ICH M4Q相匹配；即3.2.P.5.6\n","推迟至eCTD v4.0","推迟","下一个主要版本"]
["2060","IRISS CMC Topic Group","PhRMA","EU区域规范","欧盟eCTD验证具有180个字符的路径长度限制，这可能是3.2.P.5的问题，特别是对于用于剂型的较长的欧盟标准术语。","请咨询区域当局。","拒绝"]
["2070","IRISS CMC Topic Group","PhRMA","eCTD规范v3.2.2","问题：ICH eCTD Q&A澄清了可以提供一般制造商条目（例如，“all（全部）”）而不是特定条目；有关完整的Q&A，请参阅表1。这是为了补充这个属性是必需的，而不是可选的。\n\nICH M4Q承认，“很可能......不同的过程将在同一相关章节中描述”；有关本Q&A文件的完整段落，请参阅表2。\n\n在大多数eCTD申请中，仅注册了1个制造工艺。如果有多个工艺，使用不同的规范并不可行。因此，使用一般属性正在成为行业标准。\n\n解决方案：使Substance Manufacturer（物质制造商）属性可选，即，将制造商CDATA设置为#IMPLIED。\n","有关v3.2.2的实施，请参阅Q&A #66。M8将考虑v4.0的变更。","推迟","下一个主要版本"]
["2080","FDA","FDA","Valid-values.xml内容","当前的文件标签集不足以满足当前的需求。E3 IWG确定需要额外的编码。将这些转发给M8。其他要添加的值是：\n\nassay-validation（测定方法验证）\nbiomarkers（生物标志物）\ndata-monitoring-review-committees（数据监测审查委员会）\ndevice-information（器械信息）\ndiagnostic-tests（诊断检验）\ngene-therapy（基因治疗）\npatient-reported-outcomes（患者报告的临床结局）\npharmacodynamics（药效学）\npharmacogenomics（药物基因组学）\npharmacokinetics（药代动力学）\nquality-of-life（生活质量）\nstem-cells（干细胞）\nabuse-liability（滥用倾向）\nantibody（抗体）\nhealthcare-utilization（医疗保健利用率）\nother-data-not-specified（其他未指定数据）\nPK-PD-relationship（PK-PD关系）\nspecialty-report（专业报告）\nforeign-clinical-studies-not-under-ind（未处于IND的国外临床研究）\nbimo（生物研究监测） \n",null,"批准","更新有效值"]
["2090","CTD-Q","M8","eCTD规范v3.2.2","当前的eCTD规范V 3.2.2可以在3.2.P.8.3标题下产生许多leaf元素文件，它们的顺序可以根据所使用的阅读工具而变化。我们建议今后的规范为这个元素提供可选的可重复性，具有适当的属性（例如，“stability（稳定性）”）。\n同样，3.2.S.7.3可以保证可选的重复章节。\n","规范变更推迟到v4.0。","批准规范变更","下一个主要版本"]
["2100","FAGG","EU","ICH eCTD规范， v3.2.2，附录7，第7-1页。","在标题Version（版本）中：在eCTD规范的下一个次要更新中删除以“PDF/A-1”开头并以“review needs for use with an eCTD（审查需要与eCTD一起使用）”结束的短语。\nPDF/A-1虽然在单独的ISO规范中描述，但也是PDF，其中某些功能（例如外部引用）被禁用，而其他功能是强制性的（例如字体嵌入），以确保长期存档。它与ICH M2的建议非常相似。规范中短语的出现可能会给人留下这样的印象：在申报资料中不需要长期归档的功能，而监管机构则对长期存档解决方案感兴趣。很可能，PDF/A-1或PDF/A-2不适合审阅的印象不是由于格式，而是由于PDF阅读器的配置。PDF/A的ISO规范明确确认可以使用PDF间超链接。继承缩放在PDF/A中有效。","ICH将评估包括PDF/A在内的其他PDF类型是否符合ICH区域要求。","推迟\n批准Q&A（2013年11月）","请参阅M2\nQ&A #80"]
["2110","WSMI","WSMI","Q&A 55","eCTD Q&A第55问（只允许使用pdf版本1.4）与Q&A第71问不一致（将接受pdf版本1.4至1.7（有限制））。",null,"批准Q&A","Q&A #55修订版"]
["2111","EFPIA","EFPIA","ICH eCTD规范版本3.2.2.","为了应对ICH Q8和Q10（ICH Q10定义了控制策略并描述了其支持质量体系的功能，ICH Q8定义了控制策略的提交要求），已经确定了两个文件需要3.2.P.5和3.2.S.4中的其他粒度选项。这两个文件，即“原料药控制策略”和“制剂控制策略”，被视为关于原料药和制剂质量的关键信息，将关键质量属性与实际控制联系起来，因此，应直接放在3.2.S.4和3.2.P.5下。\neCTD规范应包括其他粒度选项，以便允许文件直接放在3.2.S.4和3.2.P.5级别。建议修改规范，允许每个文件在3.2.S.4和3.2.P.5级别使用建议的文件名“ctrlstrat-VAR.pdf”\n","超出范围\nCTD-Q的回答：\n是的。将控制策略总结放在S.4.5和P.5.6以外的章节是可接受的，例如，3.2.S.2.6和3.2.P.2或者3.2.S.4*和3.2.P.5*。具体位置由申请人决定。但是，因为控制策略摘要在模块3中无特定位置，申请人应在模块2.3（例如，2.3 引言）中说明摘要的位置。\n*虽然这种将文件放在标题3.2.S.4和3.2.P.5下的方法似乎不符合ICH M4(R3)组织（粒度附件），但是对于eCTD申报资料仍然是可接受的，并且符合eCTD规范v3.2.2。如果使用该方法，则建议文件名称为“ctrlstrat.pdf”。\n","推迟\n批准Q&A","请参阅CTD-Q\nQ&A #81"]
["2112","FDA","FDA","eCTD规范v3.2.2\neCTD DTD v3.2","当前的XML内容模型：<!ELEMENT m3-2-p-2-pharmaceutical-development ((leaf | node-extension)*)>\n \n建议的XML内容模型：\n<!ELEMENT m3-2-p-2-pharmaceutical-development ((leaf*, m3-2-p-2-1-components-of-the-drug-product, m3-2-p-2-2-drug-product, m3-2-p-2-3-manufacturing-process-development, m3-2-p-2-4-container-closure-system, m3-2-p-2-5-microbiological-attributes, m3-2-p-2-6-compatibility))>…\n[以及相应的内容模型添加，用于将下级XML元素添加到映射到CTD-Q标题的m3-2-p-2-2和m3-2-p-2-3中]\n",null,"推迟","请参阅CTD-Q"]
["2113","M8","M8","eCTD规范v3.2.2","eCTD v3.2.2 Q&A应该说明现在应该参考的eCTD文档提交格式规范。尽管v3.2.2规范具有提交格式章节，但它不再是最新的。Q&A还应说明实施者应参考区域指南，了解何时适用于该地区。",null,"批准Q&A","Q&A #82"]
["2114","FDA","M8","有效值","通常，进行HF（人为因素）研究以评估产品的用户界面。因此，在开发制剂时，可以在HF研究中评估产品用户界面的设计，以确保消除或减轻与制剂品相关的使用相关危害，从而降低患者发生不良事件和用药错误的风险。由于人为因素验证研究方案和研究报告是作为eCTD申请的一部分提交的，因此请求将以下文件标签添加到valid-values.xml文件中以促进有效审核。\n\n建议的文件标签：\nHF-validation-protocol（HF验证方案）\nHF-validation-report（HF验证报告）\nHF-validation-other（HF验证-其他）\n",null,"批准","更新有效值"]
["2115","FDA","M8","STF样式表(ich-stf-stylesheet-2-2a.xsl)","该问题似乎与自v9.0以来的所有Internet Explorer版本以及Chrome和Firebox有关，并在下面进一步详细介绍。\n\n根据当前的XSL规范，新浏览器的基准URL取自xsl文件位置。如果（例如）将doc-content标签的xlink:href属性从../../../../../../../0255/index.xml#...改为../../../0255/index.xml#...，则stf文件将正常运行。（xsl文件位置util/style/ich-stf-stylesheet-2-2.xsl）\n看起来这种行为似乎与XSL第3.2点转换规范（https://www.w3.org/TR/xslt）相关\n","这种行为得到了证实。STF样式表v2.3应该可以解决这个问题。","批准","更新STF样式表"]
["2116","Regulatory Professionals, Inc./Elizabeth Narciso","M8","STF样式表(ich-stf-stylesheet-2-3.xsl)","使用最新的STF样式表（版本2.3），STF在外部/独立的eCTD阅读器（例如Rosetta）中无法查看。此外，无法在IE v11中启动和查看STF。\n\n该问题是否是整个行业的问题？可否就我们如何处理这个问题提出建议？","4月/5月在神户进行了讨论——需要确定样式表的问题（例如，纳入序列号）","批准","更新Q&A以反映当前指南。"]

{"sheet":"Retired Q&A","index":5,"n_rows":38,"n_cols":6,"rows_kept":38,"cut":false,"hidden":false,"merged":[[4,0,5,0],[4,4,5,4]],"flags":["formulas_cached_only"]}
["编号","问题","回答","获批日期","状态"]
[1,"纸质CTD可能包含同一文档的多个副本。在eCTD中，是否必须包含文件的多个副本？","对于文件的每项引用，XML主干中单独的条目可以满足该需求。该文件应包含在文件夹结构中的适当位置，且仅出现一次。避免文件重复。","2003年2月","纳入eCTD规范v3.2.1，第6-5页，文件重用"]
[2,"eCTD中应如何提供交叉引用？","在eCTD中可以通过使用超链接支持CTD交叉引用。","2003年2月","纳入eCTD规范v3.2.1，第2-2和3-1页"]
[3,"是否可以更改先前分配给XML node（节点）属性的值（例如，indication（适应症）中未放置任何值或放置了错误的值，后来确定需要一个值/不同的值的情况）？","目前为否。\n\n该问题由变更请求00200和00210生成。","2003年2月","纳入eCTD规范v3.2.1，附录4和6"]
[4,"很难弄清楚如何为模块3（3.2.P.4）“赋形剂控制”章节构建有效的index.xml文件，而不必复制主干中的条目，且不会偏离预期的CTD结构。CTD预计，每种赋形剂\n都可以提供一个单独的章节（从3.2.P.4.1至3.2.P.4.4），3.2.P.4.5和3.2.P.4.6是单独的文件。eCTD无法提供一种结构，在文件夹结构中或作为主干的条目，不会重复3.2.P.4.5和3.2.P.4.6的条目。\n\n该问题由变更请求00100生成。","构建主干的一种方法如下：\n重复每种赋形剂的元素m3-2-p-4-control-of-excipients，并对每个重复元素的excipient（赋形剂）属性赋值（例如，硬脂酸镁和纯化水）。其中每一项都包括涵盖3.2.P.4.1、3.2.P.4.2、3.2.P.4.3和3.2.P.4.4的leaf元素。此处没有必要包括3.2.P.4.5和3.2.P.4.6的leaf元素。然后创建元素m3-2-p-4-control-of-excipients的另一个重复元素，并将excipient（赋形剂）属性赋值为“animal-human-novel”。此处包括3.2.P.4.5和3.2.P.4.6的leaf元素。\n\n目录/文件结构可能如下所示：\n\n\n\n\n\n\n\n而index.xml文件的结构将类似于下一页的图像：\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n","2003年2月","2011年11月撤销\n（参见Q&A第72-75问）"]
[]
[5,"DTD不需要某些TOC标记。目前尚不清楚是否需要完成这些内容：1）如果可能，始终需要完成，2）仅当重复该元素时需要完成，3）仅当区域当局要求时需要完成。请澄清。","为了与CTD一般Q&A一致，请始终包含以下属性：\n- 物质\n- 制造商\n- 产品名称\n- 赋形剂\n- 适应症\n- 剂型","2003年2月","纳入eCTD规范v3.2.1，表6-8"]
[6,"附录4提供了某些章节的特定文件夹名称，并指出其他章节通常可以作为单个文件提交。“通常”的定义是什么？当它们不典型时应该怎么做？","现在对于ICH关于“人用药品注册通用技术文件组织”的指南中提供的文件粒度的建议有明确的定义。其描述了CTD的每个章节以及因此eCTD被认为适当的粒度。如果组织文件中未提供定义，申请人可以自由地构建他们认为合适的申报资料，只要其符合eCTD规范中规定的文件夹和文件命名约定。","2003年2月","纳入eCTD规范v3.2.1，第4-1页\n"]
[7,"在eCTD规范中是否对用于适应症的术语有任何控制？","否","2003年2月","纳入eCTD规范v3.2.1，附录4：第32和 335行\n"]
[9,"卫生当局的问题是否将使用该规范以电子方式提出？","eCTD规范提供了从申请人到监管机构的单向传输机制。\n\n该问题由变更请求00220生成。","2003年2月","纳入eCTD规范v3.2.1，第1-1页"]
[10,"建议将根文件夹的名称作为药品的申请号或注册号。不幸的是，在一些欧洲国家，公司在提交申请前未获得申请号。对于MRP，每个国家/地区将给出不同的数字，造成了根文件夹命名的问题。在某些国家/地区，每个包装尺寸和/或规格都会给出申请号，难以识别唯一申请号。因此，在欧洲很难实现诸如FDA申报资料的唯一标识符。","联系监管机构获取指导。","2003年2月","纳入eCTD规范v3.2.1，第6-1页"]
[11,"对于ID属性，是否允许使用内部申请人标识符，或者是否需要更易理解以便支持合理的人为识别（例如，在评审人员与申请人关于某一问题的通信中）。","ID属性旨在成为申报资料中的唯一编号，可用于从XML文档中的另一个项引用该项。XML要求ID以字母字符或下划线开头。如果内部ID生成器仅使用数字，则将数字附在可以用作ID的首字母字符后，即可创建ID。有关此属性值组成的信息，请参阅W3C网站上的XML-ID建议（http://www.w3.org/TR/xml-id/#processing）","2003年2月\n\n\n\n\n2008年3月更新","纳入eCTD规范v3.2.1，表6-8"]
[13,"该规范目前规定，ICH网站上有一个eCTD空文件夹模板。但未找到该空文件夹模板。它在哪里？\n\n该问题由变更请求00390生成","现在可以在ICH网站上找到可以下载并运行以创建eCTD空文件夹模板的文件。","2003年7月","纳入eCTD规范v3.2.1，第2-1页"]
[15,"规范附录4中提到的文档的文件名是强制性的还是可选的？\n\n该问题由变更请求00110和00120生成","eCTD中的文件名是可选的。但强烈建议使用提供的文件名。为了帮助评审人员在同时打开几个相似文件时识别不同的文件，可以考虑可以提供唯一的、可理解的文件名的其他命名约定。文件命名的一般规定见本规范附录6。","2003年7月","纳入eCTD规范v3.2.1，第3-1和4-1页"]
[17,"是否可以引入eCTD规范中未规定的子文件夹级别来协助申报资料构建过程？\n\n该问题由变更请求00140生成","是","2003年7月","纳入eCTD规范v3.2.1，第3-1页"]
[18,"书签应该展开还是折叠？表格和图形的书签应该是单独的结构吗？\n\n该问题由变更请求00270生成","各机构没有足够的经验对此提供任何正式指导。将所有书签打开可能不合适，因为在某些情况下，这些书签可能非常多，以至于它们对评审无用，并且可能影响Web浏览器中的“刷新”时间。同样，将书签完全关闭可能没有用，因为评审人员总是必须打开它们。因此，建议申请人考虑如何显示书签对评审人员的有用性，并使申报资料各类似文档类型具有某种程度的一致性。","2003年7月","纳入eCTD规范v3.2.1，第7-4页"]
[19,"可否澄清应该包含哪些“font library（字体库）”属性值？\n\n该问题由变更请求00300生成","目前，所有监管机构均未打算使用该属性，因此无需提供指导。","2003年7月","纳入eCTD规范v3.2.1，表6-8"]
[21,"使用“delete（删除）”操作属性时，需要提供校验和。由于没有提供文件来分配校验和，如何使用此checksum（校验和）属性？\n\n该问题由变更请求00130生成","建议在checksum（校验和）属性中设置一个空条目，即双引号之间没有条目 (“”)。","2003年7月","纳入eCTD规范v3.2.1，表6-3"]
[23,"单个文件的文件名是否从生命周期的开始到结束都是固定的？\n\n该问题由变更请求00590生成","否，除了在eCTD规范或区域指南中预定义的名称，例如index.xml。","2004年6月","纳入eCTD规范v3.2.1，表6-4至6-6"]
[25,"根据ICH E3临床研究报告的结构和内容，病例报告表应位于附录16.3，个体患者数据列表应位于附录16.4，出版物和参考文献应位于附录16.1.11和16.1.12。CTD组织规定了模块5.3.7中病例报告表和个体患者数据列表的位置以及模块5.4中参考文献的位置。这些项目实际上应该放在CTD和eCTD的什么位置？\n\n\n该问题已提交给CTD实施协调组。","CTD和eCTD中的处理不同。对于eCTD：\n病例报告表和个体患者数据列表的PDF文件应按研究组织在模块5.3.7的文件夹中。但是，在index.xml文件中，病例报告表和个体患者数据列表的leaf元素应包含在与其他研究报告文件相同的标题下，并且任何随附的研究标签文件中都包含其他信息。此外，重复使用的leaf元素可以放在标题5.3.7病例报告表和个体患者数据列表下。如果该区域要求，则数据集应根据区域指南进行组织。\n\n出版物和参考文献的文件应位于模块5.4的文件夹中。但是，在index.xml文件中，出版物和参考文献的leaf元素应包含在与其他研究报告文件相同的标题下，并且任何随附的研究标签文件中都包含其他信息。此外，重复使用的leaf元素应放在标题5.4参考文献下。\n\n该回答已被撤销。参见Q&A #42","2004年6月 \n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n2006年10月","撤销"]
[28,"所有ICH区域均应澄清是否可以在模块2-5中使用节点扩展\nICH规范允许在模块2-5中使用节点扩展，而在模块1中使用节点扩展则是区域性问题。FDA规定，申报资料的任何部分都不支持节点扩展，其将使ICH规范无效。生成欧洲申报资料的经验表明，需要使用节点扩展来为模块4和5提供可导航的结构。目前，这意味着eCTD不能在各区域重复使用，并将给行业造成大量的重复工作。FDA应接受模块2-5中的节点扩展。\n\n\n该问题由变更请求00560生成","应根据具体情况与FDA逐一讨论节点扩展的使用。其他区域能够接受符合eCTD规范的节点扩展的适当使用（即，除非没有其他可行的方式来提交资料，否则不鼓励使用节点扩展）。\n\n有关可以使用的具体情况，请参阅EU和MHLW区域指南。","2004年11月\n\n\n\n2005年5月","纳入eCTD规范v3.2.1，表6-8和示例6-15"]
[29,"是否可以构建单一的全球化eCTD申报资料并传输到多个区域，每个区域当局都可以忽略或删除其他区域的申报资料？\n\n该问题由变更请求00700生成","不建议这样做。","2005年5月","纳入eCTD规范v3.2.1，第1-2页"]
[30,"是否允许申请人提供样式表？\n\n该问题由变更请求00710生成","请参阅区域指南","2005年5月","纳入eCTD规范v3.2.1，第1-1页"]
[31,"是否需要区域MD5校验和文件（xx-regional-md5.txt）？\n\n该问题由变更请求00720生成","不需要，index.xml包含该文件的校验和。","2005年5月","纳入eCTD规范v3.2.1，第5-2和6-2页"]
[32,"日文字符是2个字节。日语文件/文件夹名称是否仍可使用64个字符？\n\n该问题由变更请求00730生成","规范3.2不允许在文件夹和文件名称中使用日文字符。","2005年5月","纳入eCTD规范v3.2.1，第2-3页"]
[33,"提交序列号是否必须连续，即必须在0004之后提交0005？\n\n该问题由变更请求00760生成","对于日语申报资料，需要顺序编号。对于所有其他区域，首选连续编号，但不是必需的。对于所有区域，序列号在整个申请过程中应该是惟一的。","2005年5月","纳入eCTD规范v3.2.1，第6-1页"]
[34,"operation（操作）属性“new（新建）”可否用于其同一节点已经有一个文件的后续提交？\n\n该问题由变更请求00820生成","是的，但在模块2-5中可能没有太多适用这种情况的机会。这可能更适用于模块1，其中包括封面函和申请表等项目。有关operation（操作）属性的正确使用，请参阅规范3.2的表6-3。","2005年5月","纳入eCTD规范v3.2.1，表6-3"]
[37,"eCTD规范支持引用先前提交的文件的能力，例如，通过在序列0005中包含一个Operation Attribute（操作属性）为“new（新建）”的leaf来引用在0000中提交的文件。是否有可能向评审人员表明他们以前已经收到并评审过该文件？可否考虑使用其他Operation Attribute（操作属性）进行此类交叉引用或重复使用？\n\n\n该问题由变更请求01080生成\n","在eCTD实施的这个阶段，四个操作属性（new（新建）、append（补充）、replace（替换）和delete（删除））将保持不变，不会增加其他属性。根据现有规范，在技术上可以确定文件不在当前序列中，而是来自先前的序列。\n\n鼓励eCTD阅读工具的供应商开发一种可视化方式，用于显示引用当前序列中的文件的leaf与引用先前序列中的文件的leaf之间的差异。\n\n在这种情况下，请注意，在Q&A第36问下要检查的项目列表应该允许xlink:href引用另一序列的文件，而不是阻止另一申请人/监管机构查看eCTD。\n\n有关引用先前提交文件的许可，请参阅区域指南。","2005年11月","纳入eCTD规范v3.2.1，第6-5页，文件重用"]
[38,"eCTD规范建议在一个序列中不要包含一个文件多次。如果多个leaf引用打算在eCTD中的多个位置显示一个文件，是否可以向评审人员表明该文件在该序列中被引用了不止一次，这可能会提醒评审人员该文件出现多次？ \n\n可否考虑使用其他Operation Attribute（操作属性）进行此类交叉引用或重复使用？\n\n该问题由变更请求01080生成","在eCTD实施的这个阶段，四个操作属性（new（新建）、append（补充）、replace（替换）和delete（删除））将保持不变，不会增加其他属性。根据现有规范，在技术上可以确定文件被链接到同一序列中的多个leafs。鼓励eCTD阅读工具供应商开发在发生这种情况时使用的可视化的显示方式。","2005年11月","纳入eCTD规范v3.2.1，第6-5页，文件重用"]
[39,"在模块2-5中，是否可以提交XML文档，而不提交pdf文档？\n\n\n\n该问题由变更请求01250生成","人们认识到，存在用XML描述文档内容的一般趋势。但是，当前规范仅支持将XML用于结构化信息。由此可以理解，目前的规范不支持以XML格式提交摘要、报告和其他叙述性文档。该规范还规定，监管当局和申请人可以同意在区域范围内使用其他格式（包括以与上述不同的方式使用通用格式）。因此，如果申请人希望将XML用于叙述性文档，他们应该与区域监管机构联系，了解其他监管机构可能不接受这些XML文件。\n\n从长远来看，M2可能采用一种标准来说明XML的叙述性文档。","2005年11月","纳入eCTD规范v3.2.1，第7-5页"]
[40,"PDF版本1.4是否适用于所有区域？","下一个版本将更改eCTD规范，以表明PDF版本1.4是所有地区唯一可接受的版本。申请人应尽快过渡。\n该回答已被撤销。参见Q&A第46问。","2005年11月\n\n2007年5月","撤销"]
[41,"M4粒度文档规定，文档的所有页面都应该包含一个唯一的页眉或页脚，用于简要地识别其主题。\n\n使用eCTD，评审人员可以获得大量元数据来方便地识别相关文档，而无需在页眉或页脚中放置标识符。是否有必要在仅以电子方式提交的文件中包括唯一标识符？\n\n该问题由变更请求1310生成。\n","进行电子提交时，仍然存在适合在文档的每一页（页眉或页脚）放置唯一标识符的情况，例如，在打印文档或同时在屏幕上查看多个文档时。唯一标识符不一定必须包含CTD章节标识符或其他元数据。应足以识别文件的一般主题，例如，研究标识符、批号。","2006年6月\n","纳入eCTD规范v3.2.1，第7-2页，页眉和页脚"]
[42,"根据ICH E3临床研究报告的结构和内容，病例报告表格应分别位于附录16.3、附录16.4中的个体患者数据列表以及附录16.1.11和16.1.12中的出版物和参考文献。CTD组织规定了模块5.3.7中病例报告表和个体患者数据列表的位置以及模块5.4中参考文献的位置。这些项目实际上应该放在CTD和eCTD的什么位置？\n\n\n该问题已提交给CTD实施协调组。","病例报告表、数据集和个体患者数据列表应根据区域指南进行组织。\n\n出版物和参考文献的文件应位于模块5.4的文件夹中。但是，在index.xml文件中，出版物和参考文献的leaf元素应包含在与其他研究报告文件相同的标题下，并且任何随附的研究标签文件中都包含其他信息。此外，重复使用的leaf元素应放在标题5.4参考文献下。","2006年10月\n","纳入eCTD规范v3.2.1，第3-13页"]
[43,"请确认单个文件是否可以替换来自以前各个序列的多个文件。","否，单个leaf操作只能针对单个leaf元素。区分leaf元素和文件很重要。eCTD规范规定了leaf元素的管理，而不是文件的管理。","2007年5月\n","纳入eCTD规范v3.2.1，第6-4页"]
[44,"请确认eCTD生命周期中的单个文件是否可以进行多次替换","否，申请中的一个leaf元素被替换后，将不再被视为当前leaf。只应替换后续序列中的当前leaf。","2007年5月\n","纳入eCTD规范v3.2.1，第6-4页"]
[45,"如果（例如，USP/NF或欧洲药典显示）赋形剂的名称发生变化，应如何更新eCTD？赋形剂的名称必须包含在eCTD的元数据中。甚至反映在3.2.P.4下的文件夹名称中。在药品生命周期中，使用的特定赋形剂的名称可能随时间而改变，但不会改变制剂。\n\n如何在eCTD层面上处理特定药典赋形剂名称的改变？\n\n如何在eCTD层面上处理特定非药典赋形剂名称的改变？\n","eCTD规范没有在生命周期中对属性进行更改的明确机制。为了解决这个问题，申请人会删除存在错误excipient（赋形剂）属性的元素中的所有leaf，并在具有正确excipient（赋形剂）属性的元素中重新提交这些leaf。这种解决方案将适用于药典和非药典赋形剂。在执行此操作之前，请咨询监管机构。","2007年5月\n","纳入eCTD规范v3.2.1，附录4和6 （另可参见Q&A #3）"]
[46,"ICH eCTD第40问询问是否所有区域均可提交PDF V1.4文件。虽然给出的答案是肯定的，但实际上远远不止eCTD必须使用V1.4版本所表现的“可接受性”这么简单。","Q&A 40即将取消，并将创建新的Q&A：所有区域都同意接受PDF 1.4。请参阅区域指南以提交其他版本的PDF。","2007年5月\n","纳入eCTD规范v3.2.1，第7-1页"]
[47,"对于在eCTD中提交的文件，PDF/A-1是否是可接受的PDF文件格式？","PDF/A-1是一种存档格式，不符合与eCTD配套使用的ICH评审需求。","2007年5月\n","纳入eCTD规范v3.2.1第7-1页\nQ&A 80（2013年11月）","原文中无划线。"]