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.