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.