FDA to begin rejecting eCTDs for significant technical issues

Due to the increased adoption of the eCTD and number of submissions received by the U.S. FDA, submission quality is receiving increased focus and attention at the U.S. FDA. In recent conversations with FDA officials, they have expressed a commitment to increase their diligence and oversight with respect to submission quality and have signaled their intention to begin rejecting eCTD sequences having significant technical issues. Although no specific date has been established for this step, expect an announcement of intent early in 2009, with enforcement beginning some months later.

What are Significant Technical Issues?

Significant technical issues are those defined in eCTD validation criteria However, expect these criteria to be updated and re-issued based on several factors:

Enhancement of FDA's Validation Software. FDA recently updated their validation software (GlobalSubmit VALIDATE Version 5). The updated software detects additional errors not documented in the current validation criteria. These error checks were added based on feedback from FDA IT staff and reviewers. The new software went live in CBER on November 18th, and in CDER on November 24th.

Analysis of Error Trends. The new software also allows the FDA to fulfill a PDUFA mandate to report back to sponsors on eCTD errors. Specifically, PDUFA IV Information Technology Plan, DRAFT, December 2007, requires reports on “Total number of standards-based electronic submissions that fail to comply with FDA electronic submission standards, along with a distribution of these submission failures across categories of failure or problem type”. After studying the distribution of eCTD submission errors, FDA may choose to re-classify the severity of some of the errors.

Issues and Inefficiencies Caused by Problematic eCTDs. FDA also experienced problems with invalid data (especially application and sequence numbers) in the course of moving to VALIDATE 5 and integrating with other databases and systems at FDA. This caused a significant amount of manual processing to address the problems and resulted in delays in the upgrade and integration process. As the number of eCTD sequences received by the FDA is growing exponentially, they cannot continue to accept sequences that need to be manually corrected before they can be loaded and made available to reviewers.

Groundwork Already Established

This action should not come as a major surprise to sponsors. FDA has been laying the groundwork for this step for some time. FDA validation criteria defines the impact of a high severity error as “The error is a serious technical error which prevents the processing of the submission and will require resubmission. The submission is considered not received by FDA.”

In the guidance document “Guidance for Industry: Providing Regulatory Submissions in Electronic Format — Receipt Date”, they say:

The FDA will consider a technically deficient application not received until the technical deficiencies are resolved and the application is resubmitted. Examples:

Defect in media, lack of electronically readable application form, re-use of sequence number, missing index.xml and/or us-regional.xml, virus

High priority errors identified in validation criteria

Sanctions are also discussed in Section IIH of "Providing Regulatory Submissions in Electronic Format - Human Pharmaceutical Product Applications and Related Submissions Using the eCTD Specifications".

Impact and Recommendations

FDA anticipates that the step may result in the rejection a few percent of all sequences, based on the quality of submissions currently being received. It is not their intent to issue Refuse to File for a rejection, but it will prevent the PDUFA clock from starting, resulting in a significant cost impact to sponsors. Delays also increase the chance of a complete response - which stops or extends the PDUFA clock.

I strongly recommend that all organizations who produce eCTDs establish quality processes and procedures to ensure the quality of submissions. Tools that support eCTD review and validation are essential to ensure the overall quality and integrity of the submission to avoid costly errors and the potential rejection of the submission sequences. However,even the best tool must be used in combination with a thorough, repeatable, documented process in order to yield consistently excellent results.

[Note in the interest of full disclosure - I presently serve as the Director of Professional Services for GlobalSubmit.]

Common eCTD Mistakes - as Described by FDA (Part 2)

Continued from last time... Notes from my discussion with Virginia Ventura.

Virginia mentioned lack of a cover letter, or lack of a useful cover letter, as a significant issue. Although the cover letter is not a regulatory requirement, it serves as the reviewers' "Road Map" to the submission, and Virginia can't understand why a sponsor would not take advantage of the opportunity to provide clarity on the structure and contents of the submission. Her recommendations here:

• When you reference documents in your cover letter, provide hyperlinks to those documents.
• Review your cover letter closely for accuracy. Mistakes in the cover letter can cause significant confusion.

We discussed the concept of providing more detailed reviewer guides as well. Again, these are not a regulatory requirement, but some companies consistently provide well-structured guides that make reviewing much easier. These should not just reproduce the TOC, but might included details and discussions such as the following:

• How the eCTD was constructed (for example, using which software package) and how it was submitted (via the gateway, etc.)
• Version of specs used
• Brief description of pivotal studies, with mention of where they are located and hyperlinks to key documents and summary sections
• Discussion of how study reports were constructed (ICH granularity, etc.)

You also may wish to discuss placement issues (for example, when a study could legitimately be placed in more than one section), instances when the same document was submitted in more than one section, etc.

As a reminder, FDA has organized documents related to electronic submissions on http://www.fda.gov/cder/regulatory/ersr/. This is a great collection of resources, and Virginia mentioned that not all sponsors are aware that this page exists before they contact her.

Specifically pertinent to this post, FDA has a posted presentation, eCTD Validation, available on their website. This was presented by Don Duggan in February at DIA EDM in Philadelphia.

Common eCTD Mistakes - as Described by FDA

I recently had a great chance to talk to Virginia Ventura of FDA's Electronic Submission Support Team about the common mistakes made by sponsors in preparing eCTDs. Virginia told me that mistakes are not confined to small or inexperienced companies. In many cases, these errors result from a lack of basic QC. Here are some examples:

Not updating documents that were created based on templates intended for paper.

Of course, adding hyperlinks is a big part of this. In some cases, sponsors have not only failed to add hyperlinks, but have retained references to paper volumes, which are of course useless in the eCTD environment.

My colleague Shannon Strom, Director of Regulatory Operations at Cato Research, gave a great example of the need to change practices at a recent presentation: consider the previous practices of using a sentence such as:

Tables 1-3 Indicate The Significant SAEs Reported For Each Clinical Study.

This was fine in the paper world, but in the eCTD world, it gives the publisher no way to hyperlink to Table 2! Thus a better structure is:

All Significant SAEs Reported For Each Clinical Study Are Indicated In Table 1, Table 2, And Table 3.

Bottom line: make sure your documents have been updated for proper presentation in an electronic environment, and as always, keep the reviewer in mind! Virginia says that the FDA has received a number of submissions that were essentially "un-reviewable" due to lack of hyperlinking.

Lack of consistency in the Application Number
The application number appears in four places in an eCTD:

The regional backbone (us-regional.xml in the US)

The root folder of the eCTD content

The application form

The cover letter

It's really important that the application number matches in all four places. (By the way, if it does not match, the FDA will consult your cover letter for arbitration - so heaven help you if it's wrong!)

That also brings up the topic of using the PDF Fillable Form provided by FDA for your application form. They really want you to do this!! Virginia says that lack of a fillable form is the #2 error that the FDA sees for eCTDs. (Interestingly, the #1 error is clicking twice when submitting via the gateway - this causes your submission to be submitted twice, resulting in a number of errors, as you would expect.)

More on my talk with Virgina next time...

Cross Application Links in eCTD

A little while ago, a client asked me about referencing documents submitted in one application from another application. Her question was in the context of an IND and an NDA, both submitted in eCTD format - did she have to re-submit documents in her NDA that had already been submitted in her IND?

The ICH guidance is basically silent on this subject, although the structure does not specifically prohibit any valid relative link. EMEA has stated that it is not allowed - in "EU Region Question and Answer and Specification Change Request Document", see question 13:

"In the EU it is possible to refer to a file located in the same sequence or any previous sequence of the same eCTD. It is not possible to refer to other eCTDs."

If you think about it a little, it requires each agency to maintain a specific set of folders in order for the links to work, and for the sponsor to understand what that structure is.

For example, if the agency stores eCTDs in a known folder path like this:


then I could provide a relative file path from my "NDA" 222222 back to files in my "IND" 111111. But if the agency does not maintain that exact folder structure, my links will break.

Gary Gensinger of FDA has said in several presentations that FDA will accept references to documents in other applications.

In order to do this, your publishing tool must be able to handle this scenario. A leaf must exist in your new application (you cannot reference leafs from other applications, only content files). You will need to know:

Name of the file

Location in Original Submission

Access in through the hlink:xref element, and the operation attribute is NEW.

Gary provided the following example:



With the following commentary:

You want to reference a leaf submitted in 0000 of your IND 012345 for NDA282166, sequence 0000 - Your file is named study-report.pdf in 5.3.5.2. Using the following relative path will allow you to reference the study report:

../../IND012345/0000/m5/5352/study-report.pdf

../ gets you out of the 0000 submission in NDA 282166
Adding ../ gets you out of the NDA 282166
Adding IND012345/0000/m5/5352 gets you to your files location


What I haven't heard is how many people are taking FDA up on this offer.

By the way, the RPS specification will be designed to allow cross application referencing from the start, and will not reply on a relative folder path.

Update to FDA Guidance

On June 11th, 2008, FDA issued a Revision 2 of "Providing Regulatory Submissions in Electronic Format - Human Pharmaceutical Product Applications and Related Submissions Using the eCTD Specifications" (http://www.fda.gov/cder/guidance/7087rev2.pdf). The previous version, Revision 1, dated from April 2006.

So what's new? Very little.

The updates are all administrative in nature, and basically consist of:

• Revisions to title page for FDA's new address
• Minor revisions in language to remove references to hybrid submissions and eNDAs, which are no longer accepted without a waiver
• Updated reference to ICSR guidance in the Periodic safety update reports section

The latter update is merely the replacement of the previous text:

"You should provide bookmarks for each of the sections and subsections of this report. ICSR and ICSR attachments should be provided as described in the guidance for industry Providing Regulatory Submissions in Electronic Format — Postmarketing Periodic Adverse Drug Experience Reports. "

with:

"ICSR and ICSR attachments should be provided as described in FDA’s guidance for industry on electronic submission of postmarketing ICSRs (Available under the topic "Electronic Submission" on CDER and CBER’s guidance Web pages)."

One anticipated change that did not appear in this document was the decrease of the maximum recommended path length. ICH/FDA guidance currently states that the path length can be up to 230 characters. However, for those using the gateway to submit, the gateway adds characters to the path. FDA said at DIA in June that they recommend limiting the path to 150 characters, and reminded the audience that FDA reviewers do not see the folder names so their significance in the US is minimal. Path length problems can result in documents not being seen in the agency's viewer because it is not given all of the necessary information.

ANDA Checklist

Another fairly recent CTD/eCTD related update was the revision of the ANDA checklist on May 28th. (the previous version was dated October 17, 2007). It is posted as PDF (http://www.fda.gov/cder/ogd/anda_checklist.pdf) and MS Word (http://www.fda.gov/cder/ogd/anda_checklist.doc). The Word version is more useful as the PDF is not a fillable form. Changes here include:

• Addition of the Model Bioequivalence Data Summary Tables in 2.7
• Removal of the requirement for MS Word for 5.2 Tabular Listing of Clinical Studies

This brings up a topic that not everyone is aware of - the OGD wants MS Word versions submitted for the QOS and Clinical Summary (Bioequivalence). In presentations, their reviewers have also said that they prefer the QOS submitted as a single document, rather than in modular components.

Some news from the regulators

I attended a session at the DIA annual meeting where the regulators spoke about the status of eCTD in their regions. I'll give some updates from EU and Japan in my next post; today's post focuses on FDA updates.

Gary Gensinger gave the US eSubmission update. The most interesting point that Gary made was in the "myth busting" department. Gary told us "There is no advantage to submitting in paper over electronic. In fact, it's the opposite - you are likely to get more questions." This stands to reason if you put yourself in the reviewer's shoes. For eCTD, the reviewer finds all of the documents organized in a well understood structure, can search for documents using a full text index, and can access documents instantly. For paper, the reviewer must determine which volume he or she needs, retrieve it from a document room, and deal with the delay if someone else has already checked it out.

Gary listed the advantages of eCTD as seen by FDA as:

• Supporting a better, more comprehensive review


• Providing for a more efficient and effective review process


• Promoting standardization


• Promoting operational efficiency

Gary was enthusiastic about the gateway, especially combined with the eCTD format. He mentioned that with an eNDA, a submission took two to three days to reach reviewers, but an eCTD submitted through the gateway reaches reviewers in as little as an hour. The agency persective dovetailed nicely with what I have been hearing from sponsors. For example, Monte Levinson of Zymogenetics, as part of the excellent presentation "IND in eCTD Format: eCTD on a Shoestring", mentioned that use of the gateway is a key part of his company's motivation for moving to eCTD, and that cutting days off the schedule for printing, binding, and delivery is seen as a huge benefit in his organization. Other sponsors were interested to learn that the gateway can be used even if submissions are outsourced provided the right authorizations are filed.

In another session, Joe Montgomery of the FDA addressed recent problems some applicants experienced with the gateway. It turns out that submissions of > 70 GB sometimes time out - FDA expects this problem to be fixed soon.