EU eCTD Specification 2.0 - Are You Prepared?

On September 1^st, implementation of the Module 1 EU Specification update from Version 1.4.1 to Version 2.0 becomes mandatory.

The period up to the September deadline will of course be a busy time for software vendors, who will need to incorporate the updates into their software; but Marketing Authorisation Holders will also need to plan carefully to ensure that their eCTDs comply with the new specifications.

How Will the Updates Affect Me?

I was recently in contact with someone who was unsure whether the changes to Module 1 would affect their company at all.

My response – they will.

Whether you submit eCTDs across all EU procedure types, or within the National procedure alone, the September deadline will affect you.

Changes to the content and structure of Module 1 are listed on the eSubmission website (http://esubmission.ema.europa.eu/eumodule1/index.htm) so I will not repeat those changes here at length.  Despite the fact that changes to the content and structure of Module 1 seem relatively minor, the important consideration is that updates to the EU DTD and Stylesheet mean that your eCTDs will be different to those you’re submitting now, whether or not (on the face of it) they look any different at all.

The bottom line is this – if you submit an eCTD with an EU Specification v1.4.1 Module 1 after September 1^st 2013, it will be rejected.

How Can I Prepare for the Deadline?

There are a number of ways you can prepare for September 1^st, to ensure that you don’t find yourself caught out by the deadline…

1.       Bring the Deadline Forward!

Implementation of EU Specification v2.0 must be before 1^st September, but can take place any time after 1^st July.

If over the coming weeks you don’t have much submission activity (as is normally the case over the Summer holiday period), and you’re able to do so, use this time to upgrade to EU v2.0 to ensure you aren’t caught out when submission activity picks up and the deadline looms...

Remember: Once you update to EU v2.0 you can NOT then submit v1.4.1 for any subsequent sequence. Failure to comply with this rule will mean that your later sequence will fail validation (see sections 3.4 and 3.5 of the Validation Criteria 5.0).

2.       Talk to your Software Vendor

It may well be the case that you can’t update when you like, but you should talk to your software vendors to find out when they plan to implement the updates, whether you can update within a certain timeframe, and whether the update will affect ongoing submission activity.

Submission software can vary a great deal, so you should find out exactly how the implementation will take place and how long it will take. Don’t get caught out at the last minute.

3.       Plan Your Workload

It sounds obvious, but given the potential for disruption to your submission activity, it might be a good idea to prioritise your workload to ensure that those submissions without important deadlines are left until the deadline has passed and the heat is off.

4.       Work out a Submission Strategy

For those submissions which simply can’t move, you should prepare a strategy to ensure that the potential for rework is kept to a minimum. For example, would it be possible to publish Modules 2 – 5 first and leave Module 1 until the end? This is a typical eCTD strategy anyway, however you wouldn’t want to prepare your Module 1 early only to find out that most of the work will need to be performed again.

Remember: The September update relates only to Module 1. Modules 2 – 5 remain unchanged.

There are of course other ways the deadline might affect the way you work, and other things you can do to prepare, so the above list is not exhaustive. However the lesson is this: plan ahead for all outcomes now, and ensure you aren’t bitten when the deadline arrives.

eCTD: Literature in the Article 8(3) Mixed Application (EU)

This short post concerns the submission of Literature References in "Full Mixed" applications under Article 8(3). I don't think it is discussed in any eCTD specific guidance (or if it is, I couldn't find it!) so I thought it might be useful to share this information with you.

Article 8(3) applications are full MAA applications detailed in Directive 2001/83/EC. This type of application normally requires the submission of the results of both pre-clinical and clinical trials in Modules 4 and 5.

There does exist, however, the option to submit what is described as a "full mixed" application which contains literature references in place of (rather than to supplement) Study Reports. The content of these references must therefore fulfil the requirements of the Directive:

A justification for not having performed certain tests/trials and for providing literature references instead, should be provided as to why the references provided by the applicant can replace the study reports, and how the results presented fulfil the requirements as set out in the Annex I to Directive 2001/83/EC.

For publishing purposes, temptation (and logic) might suggest that these references are placed in either Module 4.3 or 5.4 depending upon the type of report the references replace.

However, the EMA's "Innovative Products Q&A" suggests otherwise:

Such literature references, when replacing required study reports, should be included in the relevant Module 4/5 indents and should be summarised in Module 2 as required for any other study report. “Supportive-only” literature references (i.e. provided in addition to study reports), should be provided in the CTD sections for "references" and do not need to be summarised in Module 2.

So, for the purposes of the "full mixed" application, it is important to remember that there exists two types of Literature, which for the purposes of eCTD, will need to be treated differently.

Those references which replace Study Reports must be placed in the relevant Module 4 or 5 Study Report folder where the "replaced" Study Report would otherwise sit, whereas those which support Study Reports will need to be placed in either 4.3 or 5.4.

________________________________________________________

Source: EMA "Innovative Products Q&A, Question 3: What will be the legal basis for my application?" http://www.ema.europa.eu/ema/index.jsp?curl=pages/regulation/q_and_a/q_and_a_detail_000021.jsp&mid=WC0b01ac0580022711

Say hello on LinkedIn! http://www.linkedin.com/profile/view?id=96057986

Using Reference Leafs in eCTD

One of my clients has recently asked me about the use of reference leafs in the eCTD and if you're not familiar with their use, they can seem pretty puzzling. So, I thought I'd write a (long overdue) post about the topic.

What are reference leafs?

For each PDF document submitted within an eCTD there is a corresponding XML leaf entry, with its own leaf id, title, checksum and operation.

<leaf ID="id0B6A38B66711478490FD13870E2744D2" operation="new" xlink:href="10-cover/emea/emea-cover-part1.pdf" checksum-type="md5" checksum="ffdcde626be104da4b2e53e85abfb636" xlink:type="simple" xmlns:xlink="http://www.w3c.org/1999/xlink">
          <title>Cover Letter MAA</title>
        </leaf>

The above is an example of an eCTD leaf, whose operation is 'new', title is 'Cover Letter MAA' and which points to the document located here: 10-cover/emea/emea-cover-part1.pdf

But whilst every document needs an XML entry, not every XML entry needs its own document.
You could submit, for example, a study report as part of an MAA in Module 4 which is relevant in two separate eCTD sections. In cases like this it might be useful to have two different XML entries which refer to one instance of the PDF. This is the purpose of the reference leaf.

<m2-2-introduction>
      <leaf operation="new" xlink:href="m2/22-intro/introduction.pdf" xlink:type="simple" checksum-type="md5" ID="id-3728-223465" application-version="PDF 1.4" checksum="e383fee2e3af572e8f45c4de18718b7e">
        <title>Introduction</title>
      </leaf>
    </m2-2-introduction>
    <m2-3-quality-overall-summary>
      <leaf operation="new" xlink:href="m2/22-intro/introduction.pdf" xlink:type="simple" checksum-type="md5" ID="id-3728-223466" application-version="PDF 1.4" checksum="4510c264dc6ad2753662cd0139a0bc27">
        <title>Quality Overall Summary</title>
      </leaf>
    </m2-3-quality-overall-summary>

In the example above (which I've created for the purpose of explanation - this circumstance would never arise!) the leaf entry for section 2.3 Quality Overall Summary refers to the Introduction document which physically resides in section 2.2 (emboldened). If you were to click on the link to 2.3 in the XML backbone, it would take you to the document in 2.2. The leaf entry for section 2.3 is therefore an example of a reference leaf.

A reference leaf, then, is an XML entry for one CTD section, which links to a PDF document located in a different section (or sequence) of the eCTD.

Benefits

There is a number of benefits to this approach. Firstly, the overall size of the submission is kept to a minimum. In smaller submissions this might not be an issue, but for MAAs it could mean the difference between burning one or two CDs. Secondly, the PDF document will need to be linked only once, which in the case of large clinical study reports, could save valuable time.

In theory reference leafs can also be used across different sequences. For example, if you need to refer to a document submitted in an earlier sequence, you could include a reference in the current sequence to that document which physically resides elsewhere. This approach can cause lifecycling problems, and I believe it should be avoided. I'll explain why later in this post.

Problems

I'm sometimes asked whether the use of reference leafs will create problems when documents are replaced in future lifecycles. For example, what if you want to replace one of the documents referenced by two XML entries, but not the other?
Well, here it might be useful to note the following. The act of 'replacing' a document does not physically delete the PDF document from the folder structure of an earlier sequence, it merely removes that instance of the XML leaf from the current view and replaces it with another. The leaf i.d. for the 'referenced' document, and that of the reference leaf will be different, so it is possible to replace one instance of the document without affecting the other.

Of course, whilst the above is theoretically true, your eCTD publishing tool might prevent you from using reference leafs to full effect, so I would always advise that you check with your software vendors that this feature is enabled.

The major problems I have found with reference leafs relate to their use across different sequences, to make a previously submitted document appear in the current XML.
The first problem is that whilst the referenced document might be 'current', it could contain hyperlinks to other documents which have since been replaced by newer versions. The hyperlinks in previously submitted PDFs do not update when their target documents are replaced in the eCTD, so you should be aware of the fact that the reviewer might follow hyperlinks to out-of-date information.
The second, and possibly less obvious problem, concerns eCTD lifecycling. Some publishing tools I've used are unable to distinguish between reference leafs used within eCTD sequences and those used across eCTD sequences. Therefore, when reference leafs are used, the "operation" type has always been "new". If you create a reference leaf to a document from a previous sequence and the operation is "new", this will create a duplicate entry in the "current view" of the eCTD application (i.e. the same document will appear twice when the agency uses a viewing tool to review the entire eCTD). For this reason, I believe that the use of reference leafs to refer to documents submitted in earlier applications should be avoided. (N.B. In theory it might be possible to use the "replace" operation with a reference leaf and refer to a document submitted in an earlier eCTD sequence, however I've never seen it before, so it might be interesting to find out whether this might work in practice.)

Conclusions

Reference leafs can save a lot of time and effort when they're used to refer to documents which need to be submitted in two or more sections of an eCTD sequence. In theory, they could be used to refer to documents submitted in earlier sequences (and I know that this is useful particularly in the US) however I would offer a word of caution when using this approach to ensure that your document lifecycling is not affected.

Fixing a broken MD5 checksum

Some eCTD publishing software comes with a tool which allows for the creation of xml files and valid MD5 checksums for eCTDs which have been published and then edited in the eCTD output folder. ISI’s eCTDXpress and eCTD Office are two publishing tools which incorporate this handy feature.

This feature is especially useful when making minor changes to the published eCTD, such as PDF file open settings, creating a new hyperlink or bookmark, etc., without the need to republish the entire eCTD in order to create the valid MD5 checksums.
Without such a tool, changes have to be made to source documents, usually within a document management system (DMS), and the entire eCTD will need to be republished.

Recently I’ve been using a publishing tool which does not include this handy function, and making these minor changes has been a needlessly annoying and time consuming task.
Fix MD5 is a useful (and importantly, free) tool for eCTD publishers who need to make small changes to an eCTD after it has been published.

Example: After QC checking a technically valid eCTD I find a document which contains an incorrect hyperlink. As I’m pushed for time I don’t want to amend the document within the DMS and republish the entire submission, so I make the change on the eCTD output drive.

The eCTD is now of course, invalid:

Running Fix MD5 will fix the broken checksums, meaning that your eCTD will become technically valid. And it takes only a matter of seconds:

1. Download and extract the Fix MD5 files onto your local computer. This only needs to be done once.

2. Open the Fix MD5 program:

3.  Click “Browse” and select the eCTD sequence folder which you wish to ‘fix’. Then click on “Fix It!” to fix the broken checksum(s):

4. That’s it! The MD5 checksums have been fixed. Run a validation report to ensure that the eCTD is completely valid:

PDF Hyperlinking within the eCTD

The use of hypertext links in eCTD submissions to aid navigation within and between PDF documents is commonplace. Along with the use of bookmarks, links can play a vital role in accelerating and facilitating the eCTD review process. Whilst an eCTD will not necessarily fail technical validation if hyperlinks aren’t created correctly, validation tools should still show errors where this is the case, reporting a failure to comply with eCTD best practice rules.

eCTD Validation Criteria v3.0 (which will come into force September of this year) states that:

            “The applicant should make every effort to address these areas [failure to comply with best practice criteria] before the eCTD is submitted to the agency.  The applicant should be prepared to include justification for any Best Practice criteria not met in the submission cover letter/reviewer's guide.”

The best practice criteria address some of the link formatting issues which any eCTD publisher will face. These will be addressed in the sections which follow.

When to link

The use of links within and between documents submitted in eCTD format is an important consideration for any submission publisher. There is no absolute rule set in stone which determines how many links should be created in any document, but the eCTD spec. v3.2.2 states that:

            “Hypertext links throughout the document to support annotations, related sections, references, appendices, tables, or figures that are not located on the same page are helpful and improve navigation efficiency.”

The purpose of hypertext links, then, is to help the reviewer navigate through and between documents, and so this should always be in the mind of the publisher. Links to sections on the same page, for example, might not help the reviewer at all, and so such linking is merely an unnecessary waste of time.

Link Properties

The properties associated with any link are governed by the eCTD validation criteria v3.0 and the eCTD specifications v3.2.2. They are as follows:

16.BP2

PDF Files

Hyperlinks within documents, or between documents within the same sequence, have a valid target

This means that each link in any PDF included as part of an eCTD submission (a single sequence) must open to a valid document, or section within a document, within that sequence. A link must not be broken. For example, if the name of a document within the eCTD changes, all links (if not corrected) directing to that particular document will break.

16.BP4

PDF Files

Hyperlinks to targets within documents in a different sequence in the same application have a valid target

As above, but this refers to links to documents which are located within a different eCTD submission belonging to the same application (i.e. with a different eCTD sequence number).

16.BP9

PDF Files

All PDF hyperlinks are relative

A link will be relative if its path recognises only the folders and files which are included in the overall eCTD structure. If the link path contains the drive name and folders which sit outside the eCTD structure, the link will break. This is because the drive and folder setup outside the eCTD folder structure will be specific to your computer, and so the agency’s computer will not be able to follow the same path.

For example:

If a link appears as follows: ..\..\..\m1\eu\10-cover\emea\emea-cover-lou then its path relates only to those folders included within the overall submission structure. It is therefore a relative link.

If however, the link path is: Mark\Submissions\calcium\0002\m1\eu\10-cover\emea\emea-cover-lou then it relates to folders (namely “Mark” and “Submissions”) which sit outside of the overall eCTD structure, and so the link will not work on the agency’s computer. This link is said to be “absolute”.

16.BP6

PDF Files

All bookmarks and links are set to "inherit zoom"

The “inherit zoom” property means that when the link is used, the reviewer’s view settings (i.e. the page zoom level) for the PDF document will not change. Some settings will change how the PDF is viewed, which could slow the reviewing process.

Link Appearance

The eCTD specifications state that a link may appear either with a thin line appearing around the text, or with the link text turned to blue:

Blue text should be used where the document has been created in a Word Processing tool such as MS Word and rendered to PDF. A thin line should be used where this is not possible, for example where a scanned document is being included in a submission (although scanned documents should undergo OCR, it may still not be possible to change the link text to blue).

How do I change the properties of my document hyperlinks?

Adobe Acrobat will let you change properties of document links, however there are numerous Adobe Acrobat third party plug-ins which will enable your submission publishers to change the properties of hyperlinks within eCTD submission documents by batch. Such applications will save hours of document publishing time. Some eCTD publishing tools will also automatically change such properties (and other document properties, e.g. document open properties) when publishing the eCTD.

If you would like any advice choosing the right software for your needs, please feel free to visit our website at www.apexregulatory.co.uk and contact us by phone or using our contact form and we’ll be glad to help.

Document Granularity within the eCTD Structure

Deciding where a document should begin and end is one of the key considerations when drafting certain documents which are to be submitted as part of an eCTD submission. For the most part, the eCTD structure allows no legroom when deciding where and how to include a document as part of an eCTD.  For example, your Cover Letter (section 1.0) and Application Form (section 1.2) cannot be submitted as one merged PDF document in either section.

In some sections of Modules 2 and 3, there is some scope to choose how to submit your documents. For example, it is possible to submit one document in 2.3 which covers all CTD sections below this level; or you may submit one document per CTD section (e.g. 2.3.S.1, 2.3.S.2…). The second approach is said to be the more “granular” approach as documents are broken down into smaller sections. Document granularity, therefore, means the level into which documents are broken down for submission. The screenshot below displays the documents which can be submitted at more than one level.

Also, it is possible to submit documents such as QP and GMP certificates separately (per certificate) or merged together.

Similarly, in Modules 4 and 5, study reports can be submitted either with all appendices attached to the study itself, or as separate documents within the same document section. The latter may be preferable in the case of documents which, when combined with annexes, would exceed the applicable size limits for individual files.

Before deciding the appropriate granularity for your documents, it’s worth considering some of the practical eCTD implications of adopting either approach.

For example - You decide to submit a complete 2.3 QoS section as one document in your initial eCTD sequence. If at some point you need to update only section 2.3.S Drug Substance, it would not be possible to submit in the new sequence only the updated Drug Substance section. This is because it’s not possible to replace a complete 2.3 with only a 2.3.S – If you were to do this, all of the other non-Substance related data (e.g. 2.3.P, 2.3.A and 2.3.R) would be deleted from the eCTD current view. You would therefore have to update the entire 2.3 document with only the changes made in 2.3.S, and replace the ‘old’ 2.3 document in the eCTD.

The real advantage to this ‘less granular’ approach is that the overall number of documents to be submitted will be kept to a minimum, improving the manageability of the CTD sections.

There are however, quite a few disadvantages to this approach…

The first major disadvantage is the potential for more linking and bookmarking in sections which have not been updated but are still submitted as part of the greater ‘complete’ document. This may well increase the time it takes to publish a submission.

Secondly (and probably most importantly), where sections will be authored by more than one individual, updating only one document could lead to possible errors or omissions and an overall delay in the authoring process.

Thirdly, this approach provides more scope for publishing error. For example, if in your initial submission you submit three QP Declarations submitted as a merged document, one of which subsequently needs to be updated, your submissions specialist will need to: be aware of which certificate has been updated, delete the old certificate within the originally submitted PDF and insert the new certificate in its place, then replace the old document in the eCTD outline. If the certificates had been submitted separately there would be no need to manipulate the documents, but only to replace the old document in the eCTD outline.

Lastly, the time it takes to review the dossier will be longer if currently approved sections are included in the eCTD dossier. The reviewer will need to know which sections have been updated, and scroll through the pages of sections which haven’t.

You should consider various things carefully before deciding which method to adopt:

Is the dossier particularly large and complex?

Is there a need for multiple Drug Product or Drug Substance sections?
How often will the dossier need to be updated?

Without considering the particulars of any individual scenario, my preferred approach is to submit documents in a more granular fashion. In this way the potential for authoring and publishing errors is kept to a minimum, and one of the overall ideals of eCTD – that the dossier should be easy to review – is achieved.

If you would like advice regarding document granularity, or any other eCTD issues, please visit us at www.apexregulatory.co.uk, contact us using our contact form, or give us a call on the number at the top of the site.

Preparing Documents for Submission

The preparation of documents for submission in CTD format can be a time consuming and arduous task. Your document authors should be well aware of the restrictions and requirements for such documents, and take care to ensure that their output remains compliant.

Some of the considerations to bear in mind are:

1. Is the document formatted correctly?

Best practice guidelines exist which regulate such things as the size and type of font used, the size of page margins, the use of headers and footers, page sizes, etc… When your documents are reviewed, are these guidelines taken into consideration as well as the document content itself?

2. Does the document follow the correct granularity guidelines?

Whilst there is flexibility regarding the granularity of documents in some CTD sections, in others there is not. Documents submitted in eCTD format cannot simply be submitted wherever and however you like – it may fail technical validation if you’re not careful. Even where there is flexibility, you should consider which is the best level of granularity to submit documents, bearing in mind eCTD lifecycle considerations. With existing eCTD applications this will largely depend upon how documents have been submitted in previous sequences. Replacing a high-level CTD document with a low level document will mean that some sections are lost from the current view.

3. Where should the document be linked?

Much of the time, the document author will have a better idea of where a document should contain a link to another document or section in order to facilitate its review. Where the document referenced was submitted in a previous lifecycle, would it be obvious to your eCTD compiler that this is the case? Consider changing the colour of text to blue in the source document to make the lives of your eCTD publishers a little easier.

There are many more considerations than those outlined above; however some of these provide common examples of how the use of document templates can greatly reduce the time it takes to create and publish documents for use in submissions. How can templates help you?

• All formatting (font size, style, margins, heading styles etc…) can be preloaded into the template. This would remove the need to format individual documents before, during or possibly even after authoring; greatly reducing the time it takes to create them, ensuring that they’re completely compliant whilst maintaining a professional and standardised style across all CTD sections and eCTD lifecyles.

• Automatic bookmarking using heading styles. It is possible to set up your templates in such a way that when converted to PDF, multilevel bookmarks are automatically generated. This can save hours when publishing submissions.

• Consistent and compliant granularity. If CTD templates are used, there will be no worrying about inconsistency of granularity when documents are authored.

If you’d like to know more about the preparation of CTD templates, and how they can benefit your authors, Apex would be happy to help. After consultation, Apex will even be able to create them for you. Please get in touch with us via our website: www.apexregulatory.co.uk. We’re also on Twitter, and LinkedIn!