Common technical document structure

The common technical document (CTD) (ICH M4) is now a requirement. The CTD is the agreed common format for the preparation of a well-structured application to the regulatory authorities and has had an impact on all organisations as database integration and electronic submissions become more common. 

Directive 75/318/EEC required that the dossier be presented in four highly structured parts Parts I, II, III, and IV. Directive 83/570/EEC was the amending Directive, which introduced the requirements for a draft SPC to be produced by the applicant. Volume 2B of The Rules Governing Medicinal Products in the European Union gave a detailed breakdown of the structure of a European regulatory dossier. This format was accepted until the end of June 2003 when a new format known as the Common Technical Document (CTD) became mandatory (see later). 

As more than 95% of new medicines are worked out in the ICH regions the technical requirements for the safety, efficacy and quality of new medicines is determined at large by ICH technical guidelines. The application format for registration (marketing authorization) of new medicines in ICH and associated countries (such as Canada, Switzerland and Australia) has to follow The Common Technical Document (CTD) which provides harmonized structure and format for new product applications. This Common Technical Document is divided into four separate sections and 5 modules (see Fig. 1). The four sections address the application organization (M4 Organization), the Quality section (M4Q), the... 

Guidance on the content of the Nonclinical Overview (NCO) is given in ICH M4S, Common Technical Document for the Registration of Pharmaceuticals for Human Use—Safety, CHMP/ ICH/2887/99 Rev 1 Safety. This guideline also gives information on the structure and content of the narrative and tabular summaries that contain the more detailed information. 

International Conferences on Harmonisation. URL http // www.ich.org. The ICH Web site provides information on the structure and purpose of this consensus-building initiative, as well as the process for evolving recommendations regarding technical requirements for human drug registration worldwide. Separate sections address existing Guidelines, the Common Technical Document, and MedDRA. 

Common Technical Document for the Registration of Pharmaceuticals for Human Use (CTD) ICH, 2001) The CTD provides for a harmonized structure, content, and format for new product applications. The document is divided into four separate sections. The four sections address the application organization (M4 organize), the quality section (M4Q), the safety section (M4S) and the efficacy section (M4E) of the harmonized application. Drug metabolism and pharmacokinetic data should be summarized in the safety section that includes the nonclinical overview, nonclinical written summaries, and nonclinical tabulated summaries. More specifically, in Section 2.6.4.S metabolism (interspecies comparison) of the written summaries, the following data should be included ... 

The approach of bringing the supplier on board at this stage will assist in the structuring of the URS the supplier will know what he or she needs to see in the URS to provide a meaningful proposal for a technical solution and how the design documentation is structured. It is not common for such close alliance to be established in these types of projects, but the potential for successful and efficient project delivery makes putting out some effort in this direction worthwhile. 

Due to these features, AHEAD is ahead of state of the art systems for project, workflow, or document management. In particular, these systems cover only parts of the managerial configuration and do not integrate the managerial with the technical level. Common workflow management systems lack the support of dynamic changes within the task structure, which occur frequently in development processes. 

Systems engineering is a structured multidisciplinary approach to defining concepts and requirements for complex multifaceted problems that include conception, implementation, and validation. This is an ideal approach to developing solutions to clinical problems because they often involve more than one technical and clinical specialty. A concepts and requirements definition document creates a common interface that allows engineers and... 

---