In this article, we go through some of the general technical validation requirements and how to better understand them. 

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 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 ICH’s 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 the preparation of the eCTD submission and its receipt by the national health authority, 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 national health authorities 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 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 the conversion is complete, the applicant should always verify that the 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 filename 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 review ability.

The ICH Document Type Definition (DTD)

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 on 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 filename 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 ensure 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, display, and group the individual eCTD submission dossiers, 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 content itself is made up of multiple files. It contains a leaf element for each of these files. The leaf title is used to easily identify the file when using a dynamic table of contents or eCTD review tool. Each leaf element has associated attributes that provide important information about the file to which the leaf element relates. This includes things such as the location of the file in the folder structure, its unique ID, version number, and a meaningful title. 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 lifecycle 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 M2 eCTD specification and regional specification are highly recommended. If an applicant wishes to submit multiple files in one section, where only one recommended name is available, suffixes can be added to the filename, such as using the file name-var.pdf. Reasons for invalidity related to file naming could be that the variable part of the name contains illegal characters. Legal characters include lowercase characters such as a-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 with regard to the published validation sets by authority. 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 on the agency side.

Some agencies use a 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 subsequent submissions. There are several validation rules to ensure that UUIDs are well formed in accordance with 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 cost associated with rejection and re-submission, which ultimately leads to a reduced time to market. If you have any questions or need help validating your submissions, reach out to us now. We’re here to help.

whiteWaveTop

Latest Blog Posts

500

Singapore's Transition to eCTD

500

Bertelsmann Investments Announces Another Major Investment in the Growing Pharma Tech Market

500

Interview: Meet EXTEDO’s Regulatory Intelligence (RI) Module!

500

Optimizing Life Sciences: EXTEDOpulse powered by CARA Unleashes the Power of Master Data Management in Regulatory Information Management (RIM)