In the EU, Japan and the US – the regions that are party to the International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) – the Common Technical Document (CTD) is used by applicants for making marketing authorisation applications for new medicinal products. It defines the organisation of modules, sections and documents to be used in the process. Now, however, the electronic CTD (eCTD) can be used as an interface for transferring regulatory information, as well as providing a template for the creation, review, life-cycle management and archival of an electronic submission.
In embracing eCTD, the industry has had to look closely at how it manages internal systems that generate relevant data in order to manage the process of electronic submissions with greater efficiency and accuracy, which not only implies investment in new systems, but also efforts to integrate elements of existing IT infrastructure with the requirements of eCTD. Most pharmaceutical companies have implemented document management systems to produce and store submission documents in a controlled way, but use of business intelligence (BI) tools is increasingly seen as an effective way to keep track of the submission documents.
The key principles of eCTD (see ‘The ins and outs of eCTD’,) are its reliance on a data infrastructure based on XML, and its requirements for the structuring of data in a specific form, which are accepted as important ways of simplifying submissions.
"I work in data sciences and I have a lot of experience in clinical data management, so I know about the technologies involved in eCTD submissions," says Dainius Ulpis, deputy general manager of data management at Mitsubishi Pharma Europe. "It is all about making submissions in XML format, whereas once, the process would involve a truckload of documents. XML has made submissions much easier to compose. The way we submit data to the FDA and other agencies is similar (although not the full eCTD format), but the documents come from the same XML backbone."
Mitsubishi Pharma Europe is the European headquarters of one of Japan’s largest pharmaceutical companies, Mitsubishi Tanabe Pharma Corporation. Based in London, the company is engaged in the clinical development of new drugs for European markets, and it is actively engaged in clinical trials of new products for the treatment of diabetes, cardiovascular and renal conditions. Its first European product launch came in 2005, when Argatroban – a small-molecule direct thrombin inhibitor acting as an anticoagulant – came onto the market.
In late 2013, the company announced the launch of non-absorbed phosphate binder BindRen (colestilan), used in the treatment of hyperphosphataemia in adult patients with chronic kidney disease, having received marketing authorisation from the European Medicines Agency in January.
Ulpis, which deals with the core technologies of data management and therefore has an insight into how they can be integrated with the existing office tools that are used in the preparation of submissions, has seen the eCTD submissions process at work. He believes that the format it lays down is essentially a reflection of what well-structured data should look like within a pharmaceutical company performing clinical trials.
"The way you organise data is very important, even without eCTD technology in place," he says. "You can’t afford to have a lot of unstructured data, so data management is a vital component in the process of developing a new treatment. Clinical development can take five to ten years to complete, so it would be very difficult to recall how all of the related documents were generated.
"There is no simple recipe for data organisation that works in every instance, but there are some basic principles that should always be applied. These are as simple as version control and naming conventions for files, which must be consistent. Different templates might be required for reports or compiling instructions, but the same principles apply."
Leaves on the data tree
While the requirements of eCTD have influenced the way companies organise data from clinical trials with a view to the submissions process, Ulpis believes that companies should develop and stick to their own methods, rather than slavishly following a format imposed from outside.
"With eCTD, you should not stick to a particular technology; eCTD should not dictate everything," says Ulpis. "Nevertheless, if you need to apply visualisations of data then you need to take the principles of eCTD into account. Remember that it is only for prepared data, which is a subset of your overall data that is distilled from the contents of your file system. You would need to organise data for any type of submission, and eCTD is just one more type."
The structure of eCTD is organised around five modules – Administrative Information and Prescribing Information, Common Technical Document Summaries, Quality, Nonclinical Study Reports and Clinical Study Reports – and thus provides a template that suggests an approach to data management.
"The idea of using modules would suggest that the best way to structure data would be by using XML databases," says Ulpis. "Electronic signatures could be done using XML technology. So, eCTD does suggest an idea of how to organise data internally, but it is not something that should dictate how a company organises data on a day-to-day basis. Having said that, it does have some benefits. It requires you to know where your files are, and it focuses an organisation on issues such as knowing that files have been QC’d or peer reviewed. But these are things that you should be on top of anyway."
The data tree companies create should, if data is well managed, be easily adaptable to the needs of eCTD submissions.
"The eCTD structure is a tree-like structure with the documents as leaves. That just reflects day-to-day good practice in data management. eCTD just takes a sample that you cut out of your data set, so applying the principle of growing an information tree may help you to distil information for the regulators when it comes to the submission stage," says Ulpis.
System integration
In dealing with many of the systems that contribute to data management and, ultimately, eCTD submissions, Ulpis believes it is a priority to focus on the integrity of data as well as on the way information is organised internally.
"For many years, the main focus has been on the quality of data," he says. "Data has to be fit for purpose, even if you can’t get 100% quality. It must be good enough to enable you to make the right decisions. Everything is risk-based now. The highest risk comes with the information and systems that support submissions, so we pay more attention to those elements. Data quality only ever improves incrementally, but over time the incremental changes may lift you to a higher level of operation. eCTD, too, has grown to its current requirements and method of implementation as a result of many incremental changes."
In an environment where regulatory teams use Excel-based tools to support the submissions process, BI tools are deployed to track submissions documents, and a host of systems collect and store clinical data, integration is a priority.
"Technology changes so quickly now, and has moved forward especially fast in the last few years with the advent of big data," explains Ulpis. "Now, we have XML databases that can store data in XML format, which is very different to the traditional database approach. It can be hard to select the right technology at a strategic level, as it is not easy to prove that the technology will be fit for purpose over five to ten years. But that is a problem that must be overcome, and which extends far beyond the requirements of making submissions using eCTD technology.
"In analysing business processes, we must look at the basic common procedures defined by the technology that is available. Most technology is capable of doing more than it is currently used for. Making any changes to the way data is managed has to take into account the way in which the data is generated."
Above all, Ulpis believes that whatever changes are made to the systems architecture for data organisation and, ultimately, eCTD submissions, they must not disrupt the most important element of the trials process: the clinical work that underpins innovation.
"We don’t want there to be too much impact on the processes used by the people who are generating the data through clinical practice, though obviously they must comply with the necessary regulations," he says. "But their principles of clinical practice should not be interfered with. Internal process to add value have more impact internally on data management practices than eCTD, which just wraps around the data that you have been collecting for years."
The ins and outs of eCTD
History:
Since June 2003, applicants for marketing authorisation of a new medicine within the International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH) region have been able to submit an electronic Common Technical Document (eCTD) in parallel with the paper submission (CTD).
This option became available following sign-off by the ICH Steering Committee of the eCTD specification document at step four, and the adoption of this specification document by the Committee for Proprietary Medicinal Products (CPMP).
In November 2003, the ICH M2 group revised the specification for the eCTD to version 3.2, which is still the current version.
Since January 2010, the EMA has only accepted submissions received in the mandatory eCTD format, although in circumstances where applicants are unable to comply with this electronic requirement, the EMA will still accept paper submissions.
Since January 2013, it has been possible to send all eCTD submissions through the dedicated submission channels: eSubmission Gateway or the related eSubmission Web Client.
Data structure
The eCTD is a message specification for the transfer of files and metadata from a submitter to a receiver, and it requires certain primary technical components, including:
- a high-level folder structure
- an XML ‘backbone’ file that provides metadata about content files and life-cycle instructions for the receiving system
- an optional lower-level folder structure, for which recommended folder names are provided in appendix 4 of the eCTD specification
- associated document type definitions (DTDs) and style sheets.