|
# |
Requestor |
M2
Sponsor |
Specification
Component |
Description |
Comments |
Status |
Action |
|
00010 |
CTD-E
FDA |
FDA |
m5-3-5 |
Multiple Indications |
Resolved by CTD group, no implication for eCTD |
Out of scope |
|
|
00020 |
Liquent |
EFPIA
FDA |
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 |
|
00030 |
EFPIA |
EFPIA
FDA |
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.
Page 6-5
…Use the full path to refer to files. The full path is not
shown in these examples. |
Not relevant |
Rejected |
|
|
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 |
|
|
00070 |
EFPIA |
EFPIA
FDA |
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
Table 6-8 |
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 |
|
00100 |
EFPIA
EU |
EFPIA
EU |
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 |
|
00110 |
EFPIA
EU |
EFPIA
EU |
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 |
|
00120 |
EFPIA
EU |
EFPIA
EU |
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 |
|
00130 |
EFPIA
EU |
EFPIA
EU |
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 |
|
00140 |
EFPIA
EU |
EFPIA
EU |
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 |
|
|
00160 |
EFPIA
EU |
EFPIA
EU |
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 |
|
00340 |
EFPIA |
EFPIA
|
|
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 |
Validation criteria will be published on ICH website by the
end of the year as a Q&A |
|
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. |
Deferred |
For clarification in the next version of the specification |
|
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 major 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 |
|
660 |
Centocor BV |
EFPIA |
Specification v3.2 |
File organisation for 3.2.P should follow the same
principles as for 3.2.S. with respect to differentiation
between manufacturers. 3.2.S has a folder organisation by
substance/manufacturer, 3.2.P has no such organisation below
product. A folder structure should be introduced for each
manufacturer.
|
Refer to CTD Q to determine how they want the organisation
of 3.2.P and its subsections. |
Out of scope |
Refer 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. |
Deferred |
Next meeting
|
|
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. |
