Talk:Electronic common technical document

Follow the eCTD Specification

This article must the eCTD Specification, including the terminology.

I agree to a point. There is no reference to a "Data Structure" in the specification so why is this term introduced here? On the other hand, those of us who work with eCTDs daily and who continue to evolve the processes at the regulatory authorities have evolved our thinking. This is very much a protocol for transferring information and instructions to the receiving system. At the FDA they would like to move to an approach that has no fixed folder structure.

The reference to the site that promotes Xdossier and Open eCTD does not belong here. There is no relationship between the eCTD and Xdossier. Neither is supported by ICH or any of the regulatory agencies. Links should go only to ICH or regulatory agency sites (or those of related standards bodies such as w3.org), except in the products section.

eCTDguy 00:32, 28 January 2007 (UTC)[reply]

Follow the eCTD Specification - take 2

I mean, it must follow as much as possible the eCTD Specification; in particular, the terminology used in the Specification. Indeed, some parts are copied nearly verbatim from the Specification on purpose. Though, one should try to make it clearer, put it in historical context, link to software and other relevant materials, etc. --Carrasco 13:41, 8 November 2006 (UTC)[reply]

No, the aim of an encyclopeedy is to be synthetic - It must summarize the knowledge on a subject, not be the copy of a document that already exists --Leridant 23:43, 6 December 2006 (UTC)[reply]

I agree. Indeed, when I started the article, I made the global structure different from the specification for the sake of clarity. However, I followed the terminology of the specification and whenever possible I copied bits of texts and adapted it. --Carrasco 11:20, 10 January 2007 (UTC)[reply]

IT point of view

Personally, I don't view this section as particularly relevant. Really, the statements below don't appear to be that useful.

JamesErrico (talk) 22:54, 20 May 2008 (UTC)[reply]

The section IT point of view is described following the traditional IT approach:

Data structure: the whole eCTD data structure
- Header: the file index.xml (backbone)
Protocol: the business process

Taking the email as a parallel example:

Data structure: Internet Message Format
- Header: Internet Message Format: 2.2. Header Fields
Protocol: Simple Mail Transfer Protocol

--Carrasco 14:15, 8 November 2006 (UTC)[reply]

Changes to eCTD (data structure)

This comments are mostly directed to the user 74.0.243.189.

Please before editing lets have a discussion in this area.

I reversed and added some more information to address what it seem to be your concern. Also I explain below why I made the changes.

A question of form: as the information is of a list type, it should be a list.

The section "Changes to eCTD (data structure)" should only contain aspect of the data structure. In particular, it should not contain information about the general definition of the eCTD and the business process (lifecycle, etc).

A)

The eCTD is a message specification for the transfer of files and metadata from a submitter to a receiver.

This addresses the whole eCTD and not just the eCTD data structure. Hence it should go to first section "Electronic Common Technical Document (eCTD)". But note that the text there is copy nearly verbatim from the eCTD Specification.

B)

The primary technical components are: 1) a high level folder structure (required);

The eCTD Specification uses both terms:

Folder structure
Directory structure

The choice of directory structure is because of the context and because it is used more often: in Appendix 2 the is a section with this title.

C)

2) an XML "backbone" file which provides metadata about content files and lifecycle instructions for the receiving system;

There is a section for the backbone. For the lifecycle, it should go into "Business process (protocol)"

D)

3) an optional lower level folder structure (recommended folder names are provided in Appendix 4 of the eCTD specification);

4) associated DTDs and stylesheets. Each submission message constitutes one "sequence". A cumulative eCTD consists of one or more sequences. While a single sequence may be viewed with web browser and the ICH stylesheet provided, viewing a cumulative eCTD requires specialized eCTD viewers.

I expanded this. Also, Business process, protocol, message, lifecycle and similar should go into the section

"Business process (protocol)"

--Carrasco 11:09, 24 November 2006 (UTC)[reply]

Web ready

I put this back because it explain the reasoning behind the data structure; indeed, it is copy nearly verbatim from Appendix 2.

The link to the Xdossier give more detailed reasoning.

--Carrasco 11:12, 24 November 2006 (UTC)[reply]

Editing of eCTD (data structure)

Please do not reserve the editing. If somebody disagree, login (no anonymous editing) and discuss it in this section. Otherwise, this is starting to be vandalism.

--Carrasco 11:09, 10 January 2007 (UTC)[reply]

Vandalism to the section "eCTD (data structure)"

Please stop reverting the editing to this section. If somebody disagree, discuss in this section.

--Carrasco 20:50, 14 January 2007 (UTC)[reply]