Technical Validation: A Bottleneck in the Drug Registration Process?

Health authorities maintain standards to ensure the quality, safety and efficacy of authorized medicinal products. In support of this, highly controlled medicinal product registration processes approve or decline the issue of pharmaceutical product marketing authorizations or licenses. With these standards being continually updated and the potential for misinterpretation being high, ensuring that submissions are valid can at times be challenging. In this article, we’ll go through some of the general technical validation requirements and how to better understand them.

The Electronic Common Technical Document (eCTD)

Many years back, National Health Authorities (NHAs) started accepting the International Conference on Harmonisation’s (ICH) common structure for registering drugs called the Common Technical Document (CTD). Over the years, this standard has been updated to accept modern digital documentation, and the electronic Common Technical Document (eCTD) format is now used widely around the globe. eCTD provides an electronic implementation of the original CTD content.

The technical files within an eCTD submission include:

• index.xml, which acts as a navigation file through the whole submission (m1-m5);
• cc-regional.xml, which acts as a navigation file through module 1; and
• the util folder, which contains technical auxiliary files, like Document Type Definitions (DTDs) and stylesheets.

To ensure that the dossier has remained unchanged between preparation of eCTD submission and its receipt by the NHA, an “MD5 checksum” is stored in the index-md5.txt which is transmitted as part of the eCTD submission.

To ensure that submitted dossiers comply with ICH requirements, all NHAs publish a set of validation criteria. These include things such as PDF configurations and naming conventions for files and folders.

Successfully Passing Technical Validation

To successfully pass technical validation, the applicant needs to prepare not only the final submission, but also a set of supporting source documents. Creating these source documents from scratch ensures that the applicant won’t face problems after eCTD compilation. However, in the case that these documents are not created using Microsoft Word but by scanning paper files, it is also necessary to ensure that files are searchable and allow the reviewer to copy and paste text for editing in other documents. Optical Character Recognition (OCR) software is most commonly used for this task. Once conversion is complete, the applicant should always verify that processed text is converted accurately and in its entirety.

For viewing the XML, navigating the table of contents and accessing documents within the submission, a stylesheet is needed. A standard stylesheet for viewing the eCTD submission is defined and provided by the ICH M2 EWG. However, other authorities also accept non-ICH stylesheets. Validation rules exist to ensure that the file name of the stylesheet is correct and that it is placed within the correct folder. In addition, only one regional XML is allowed per sequence to ensure reviewability.

The ICH Document Type Definition

A DTD defines the legal building blocks of the XML document and outlines the document structure through a list of allowed elements and attributes. The ICH defines this DTD based around the eCTD standard. In addition, a regional DTD can exist which defines the regional DTD for Module 1. Various validation rules exist to ensure that the required file name for the ICH DTD is used, that the file is placed in the correct folder, and that a current version of the DTD is used. To make sure the applicant is using an acceptable version, the applicant needs to always be up-to-date with the current ICH eCTD specification. It is also important to consider the case where the applicant may be submitting a follow-up sequence that dates back to an earlier DTD version. This is not allowed when a newer DTD version has already been used for that eCTD dossier. 

To identify the individual eCTD sequence, there is always an envelope. Various validation rules check the envelope attributes, e.g., submission unit type, related sequences and procedure type. Their aim is to eliminate any potential inconsistencies in the submitted sequences.

The eCTD contains multiple files, each file contains a leaf element. Validation rules exist to ensure that for every leaf the 'title' attribute is not empty and that the ID is unique. The leaf also has a life cycle attribute. Valid values for this include “new,” “append,” “replace” and “delete.” Validation rules exist to ensure that all leaves with an operation attribute value of new, replace or append must have a value for a cross-referenced file and that the referenced file exists in the same or a previously submitted sequence within the same eCTD application.

Make Sure You Get Your Files in Order

The eCTD file naming conventions described in the ICH eCTD specification and regional specification are highly recommended. Suffixes can be added to the file name whenever needed. Reasons for invalidity related to file naming could be that the variable part of the name contains illegal characters. Legal characters include lower case characters such as A to Z, digits 0-9 and hyphens. These are all documented in the ICH eCTD specification. It could also be that file names, including the extension, exceed the maximum allowed number of characters; folder names exceed the maximum allowed number of characters; or the total file folder path length exceeds the maximum allowed character number. It is important to note that counting starts from the first digit of the sequence number in the sequence number folder name.

In addition, there are validation rules to ensure that submitted sequences do not contain corrupted files, rules that check the size of included files regarding the published validation sets by authority and files that exceed authority defined limits should be avoided due to potential archiving issues and to make the assessment easier.

Simple to View and Easy to Identify

It is essential for reviewers in different health authorities to be able to easily navigate through the dossier, between interlinked documents and within any individual document. To ensure this, technical validation checks to confirm that there aren’t broken bookmarks or hyperlinks. Also, bookmarks or hyperlinks to destinations outside the eCTD are not allowed as they will not be accessible by reviewers when submission is on the authority side. Other validation rules will ensure that absolute links and bookmarks will be detected. It is recommended to have relative links and bookmarks that will continue to work when the submission is copied and loaded into the new environment at the agency side.

Some agencies use Universal Unique Identifier (UUID) to enable automated processing. This UUID is generated when the first sequence in eCTD format is sent. It is then kept as a reference for follow-up submissions. There are several validation rules to ensure that UUIDs are well-formed in accordance to ISO/IEC 11578:1996 and ITU-T Rec X.667 | ISO/IEC 9834-8:2005. UUIDs are identical in all envelopes and in the case that it is a follow-up sequence, the UUID in the latest sequence will be identical to the one in the previous sequence.

Having experience and being familiar with the individual validation criteria of each authority you submit to will ensure that you are able to eliminate any technical validation errors before the submission is made. This can save you the time and costs associated with rejection and re-submission and which ultimately lead to a reduced time to market.