What Causes the Year End Blues?

A quarter of all new applications to the FDA are submitted in December. That’s three times the number you would expect if submissions were distributed evenly throughout the year. December is the due date for many corporate, personal, and team goals, making the end of the year a genuinely busy time.

I think the main cause of the blues comes down to poor planning and communication. If RegOps is unable to negotiate reasonable timelines, or if teams do not communicate their plans enough in advance, you could easily end up singing the blues.

Avoiding the Blues

There are a couple strategies that can help avoid the December blues. The first is remarkably simple, and it’s something that your colleagues in Accounting have been doing for years. Every November, Accounting publishes a date by which all expense reports and invoices must be turned in order to get paid that year. RegOps doesn’t have the power of the purse, but there’s no reason you can’t follow Accounting’s lead. For example, set a deadline that all scheduled submissions will go in no later than Dec 15. Of course, emergent submissions like safety reports may have to go in after that, but push to have all planned submissions out the door by the middle of the month, so that RegOps can participate in the same end-of-year activities as everyone else.

The second strategy is to communicate your timelines to everyone. Map out how long a typical submission takes to go through the publishing process, and talk about competing submissions. Explain that a team’s December 31 goal doesn’t mean that they get a holiday break while you work on their submission. People understand this, but if RegOps isn’t represented when they create their timelines, you could end up singing the blues.

Finally, on those big, corporate goal submissions, map out the process so that an end of the year deadline means all documents are delivered to RegOps by the end of November. This may take some negotiation so start early.

This stuff seems obvious, but keep reminding people every chance you get. If you want to relax by the pool sipping drinks out of a coconut next December, lay the groundwork now. There may be some submissions where the data comes in late and you have to work over the holidays. With some up-front strategy and a bit of follow through, you can make that the exception, not the rule.

Happy new year to all my Regulatory Operations friends and colleagues. I hope this is a joyous and successful year for you, and that next December is a good one, not a blue one.

First, recognize that module 3 is probably the most complicated section of any eCTD submission to publish, and has the least upstream resources available to help with formatting. It’s important to start with a set of templates that can assist authors with basic formatting steps that will improve the quality of PDF renditions.

Second, build trust with the authors. They’re mostly scientists whose day jobs don’t involve writing submissions. They tend to view document formatting as both unimportant and someone else’s responsibility. Help them understand what you need and how you’ll help them. And follow through. Pay special attention to tables they want to paste into the templates.

Third, CMC authors tend to be very process-oriented, but that doesn’t mean they’ve mapped out the process for reviewing their documents. Help them figure this out. Start by creating an inventory of all the documents that go in m3, and identify responsible authors for each one. The biggest challenge is uncovering all the groups that will have to sign off on the documents. This may include development partners, contract manufacturing organizations (CMOs), and Quality groups. Identify contacts with each group, and any special requirements they may have. Figure out where in the process data verification will be done. Map out the process so everyone is on the same page.

Finally, recognize that some of the documents will have to be written before all the data is in. This presents an interesting challenge. The people who are working closely with the data and the documents will probably develop of level of comfort with finalizing the document and then dropping in the data. They may view the document as “done”. Other groups that are farther away from the process, like CMOs, development partners, and QA often insist on conducting their final review after the data is dropped in. Make sure to get these types of assumptions ironed out early in the process. Try to plan final reviews around groups of documents, such as all of 3.2.s.2, so that reviewers can see the information in context.

Help CMC authors in whatever ways you can. RegOps success depends on them. At the same time, make sure that authors understand that their job is not complete until they hand off final documents to RegOps, and that once they do, they can’t make any more changes. Help the authors with formatting early and often, so they learn what’s involved and how it can improve the presentation of their data. If possible, show the authors the current view of m3 in another eCTD submission so they can see what the end product will look like and how it will benefit them. Module 3 will always be complex, so RegOps needs to be proactive to ensure a successful submission.

Due Diligence

The path to a partnership agreement starts with due diligence activities where prospective buyers sign a confidentiality agreement and check out the seller’s goods. Those goods include key clinical and preclinical study reports, an overview of manufacturing and process development, and records of correspondence with regulatory agencies. For products that are already in the clinic, the easiest way to present this information to prospective partners is to give them access to the contents of the regulatory archive.

The message to Regulatory Operations groups: manage your archive well and you’re always ready for due diligence. Most RegOps groups already have a well-organized archive of all submissions and correspondence. To be ready for due diligence you also need a chronological list of all submissions and correspondence. If your company doesn’t have a document management system, you can replicate this chronological list in a spreadsheet or simple database. Whatever system you use should track the application and sequence (or serial) numbers, date, submission or correspondence type, and a brief description of each item. If you want to get fancy you can create a link from the list to each submission. This list serves as a nice table of contents to your archive that will allow people performing due diligence to quickly find what they are looking for.

Virtual Data Rooms

To facilitate due diligence and reduce travel costs, many companies now use a virtual data room (VDR). A VDR is a secure web site that provides authorized individuals access to documents, but prevents the reader from saving or printing documents. It’s a simple process to provide someone access to the VDR for a defined period of time, and then review log files to see who looked at which documents. VDRs can be created on an isolated part of a company’s internal system, but more often use a separate, hosted solution. VDRs are used widely in the financial industry for mergers and acquisitions, so most have well-established security models. Using a VDR can dramatically simplify the due diligence process, allowing the selling company to work with several potential buyers at the same time. Without a VDR, the company with the information has to host several day-long sessions in a secure conference room as each potential buyer comes through. A VDR enables companies to get through that process more quickly and move on to serious negotiations.

For Regulatory Operations, it should be a simple matter to load the archive of information, including the table of contents, into the VDR. Often there are other documents loaded into a VDR, but the submission archive is usually the bulk of the material. If possible, highlight clinical protocols and study reports, key toxicology reports, and major manufacturing changes in the table of contents, since those are the documents most people will look for.

Collaboration Platforms

Once a deal is signed, the partners need to establish a common set of working practices. One of the first things set up is a way to share the large number of documents that will need to go back and forth between the two companies.  This usually starts with the information provided during due diligence, but expands rapidly from there. Often one of the companies (usually the larger, more established partner) will have an existing system that they want to use to share documents. Sometimes the use of this system is written into the contract.

It’s important to remember that a platform for collaboration is not the same as an archive. One of the partners typically owns the system, and neither partner puts all their documents on the system. It’s most useful for everyone involved to make contact with their counterparts at the other company to work out the details of sharing information. RegOps is often left out of this process, but talking early can head off misunderstandings down the road.

Here are a few suggestions for how to manage the collaboration platform:

• Identify the process owners for the system at both companies, who are usually from project management or alliance management
• Agree on a high level folder structure to manage the breadth of information the project requires
• Identify which documents need to be shared, who is responsible for uploading them, and timeliness requirements for uploading new information
• Periodically clean up the organic growth of folders and documents
• Determine which documents from your partner should be downloaded into your company’s systems
  • Set up processes to maintain these documents as if they were your own company’s confidential information
  • Determine who is responsible for downloading new documents and create a schedule for that
• Set up notification procedures on the system so that the project team gets an email informing them of recent changes, such as new documents
• Treat the collaboration platform as a temporary site for sharing information, not an archive

Document Development and Review

Partnerships usually start with the best intentions on both sides. There is broad agreement on common goals, and a sense of shared excitement as people join the project. When it comes time to conduct joint reviews of documents, people are often surprised to realize that the companies have very different goals for the project. Often, partners divide projects geographically, so that one partner has marketing rights in the US, and the other in the EU or rest of world (ROW). This can lead to challenges, if, for example, FDA guidance from an end of phase 2 meeting differs from European scientific advice. Resentment can easily build if authors under deadline face the prospect of optimizing their submission at their partner’s expense or slowing down to try to accommodate the needs of both partners.

One of the challenges of the review process is that the smaller company usually has the technical experts who know the molecule, while the larger company has more drug development experience.  Big company processes can appear ponderous and labor-intensive to small companies, while large companies may not be comfortable having to rely on the expertise of people who may not have as much drug development experience. Unfortunately, these kinds of issues tend to come out during the document review process.

To try to head off this kind of friction, it’s useful to have a well-defined document development and review process that includes both partners.  One of the key steps is to try to get agreement on strategic issues before writing begins.  Circulating well-developed templates or model documents that include key messages is a great way to identify potential issues at a time in the process when they can be more easily addressed.  Too often, companies wait until they have a first draft before sharing it with their partner.  If the partner then raises substantial issues during the review process it can lead to an escalating tide of resentment and frustration.

There are some nice online tools that can help facilitate large review processes.  These types of tools bring transparency to the process and help eliminate multiple iterations of the same comment.  Allowing reviewers to see each other’s comments also tends to encourage people to take a more positive approach in their comments.

Organizational Structure

People at the smaller company may get frustrated as they try to navigate the larger organization. Often, the organizational structures do not line up exactly.  For example, in smaller companies, Regulatory and QA often report to the same person, while in larger companies they usually don’t. Larger companies also have geographic diversity, so a clinical development team in the US might be working with a manufacturing group in Europe, or vice versa. This situation can be especially challenging for Regulatory Operations, since publishing groups at larger companies are often viewed as service providers, and are not included in collaboration activities with partners.

Transferring a Product

Sometimes, based on reaching a development milestone, a product or an application gets transferred from one partner to the other. This is another reason RegOps should have a well-organized archive. To ease the transfer, establish contact with the partner’s RegOps group, if possible. Also, talk to someone in your company who can explain the legal requirements of the transfer and get a copy of the agreement, if possible. Most of these agreements allow the partner that is letting the product go to maintain an archive copy, for example, but it may need to be segregated from other product information. The receiving partner should do an inventory of the material they receive and work with the other RegOps group to understand how they have organized the files. Both parties need to understand any agreements about future documentation.

If the transfer involves legacy eCTD submissions, the receiving partner will have to import those submissions into their publishing system so they can maintain the application lifecycle. There are subtle differences in the way publishing vendors implement agency guidance into their systems, as well as changes in guidance and DTDs over the years. These differences can make the import process a challenge, and may be another source of friction between the companies.

Conclusion

There are many challenges to strategic partnerships, but they are a fact of life in the biopharmaceutical industry. Even for companies that are not involved in partnerships now, it’s prudent to plan for them in the future. For Regulatory Operations, setting up and managing a comprehensive archive is essential. That archive is like the crown jewels during the due diligence process.  RegOps also has an important role to play in helping set up and maintain collaboration platforms and managing or assisting with the document development and review process. A little forward thinking and good communication with your company’s partner can make this process go more smoothly.

What Do You Really Need to Manage?

The best place to start is by determining what you need to manage. There is no one-size-fits-all answer to this question, since every company has a different set of systems, people, and issues, but there are a few things that I think apply to all submissions:

• Regulatory Operations needs a way to track every document that will go into the submission and when they expect to receive them. Depending on the RegOps process, they may need to track documents as they move through formatting, rendition, publishing, and QC steps. This kind of plan can help determine resource needs during the final publishing effort.
• Functional areas need to track their internal workload and deliverables schedule to ensure that they can meet submission timelines without overly stressing their organization.
• Program Managers and Senior Management need to have visibility into submission projects to ensure that resources are allocated appropriately and corporate timelines will be met. This may mean that risk factors need to be identified and tracked along with timelines to give early indications of potential problems.
• For companies working on several simultaneous submissions, it’s helpful to develop a submission schedule to manage resources across projects. The key here is to capture information about upcoming submissions early in the process to identify potential conflicts. Most submissions seem to get scheduled on the 15th and 30th of the month. Spreading things out a little makes the publishing process much more manageable.

Each of these needs is real and must be addressed by whatever solution is adopted. In an ideal world, an integrated approach to submission management would allow functions to manage their own work while seamlessly reporting status information to management and downstream groups like RegOps. Unless your company has such a solution, you can manage with a set of simple tools and good communication.

Different Tools for Different Jobs

The goal in managing a submission project is to ensure that everyone crosses the finish line together, without burning out the resources in any given area.  To meet that goal, you need to ensure that your plan helps you identify risks early and highlights areas that would benefit from additional resources. For most marketing applications, documents trickle in over several months, and then a tsunami arrives in the final weeks. If you made a graph of documents received by RegOps over time, the curve would look like a hockey stick. By the time you reach the vertical portion of the graph it’s too late to adjust timelines and resources. An added wrinkle to most submissions is that teams are distributed geographically, and often include CROs, consultants, development partners, and CMOs. A successful project plan has to address these realities.

Here are some approaches that I think make sense:

• For Regulatory Operations, a spreadsheet that lists every document in the submission is a great way to track what’s due when. Add columns for due date, author, date received, and any RegOps process steps you want to track. Think of this as your inventory tracking system. I created an example you can modify for your own use, here.  It lists all the sections of a US eCTD and the basic RegOps process steps.
• Functional areas may want to use a Gantt chart to track authoring and review cycles. Don’t forget to include any outside groups, such as QA, partners, and CMOs that need to review final content. Make sure to include a milestone for the handoff to RegOps.
• For management and development partners, a high-level timeline that tracks sections of the submission and identifies risks to the timeline may be more appropriate. If you already have a corporate dashboard, you may be able to feed into that. Otherwise, determine the key indicators that will demonstrate the project is in control and will be delivered on time.

It’s critical to develop a process for integrating the information from each system to the others. Each system should be the official keeper of one or more types of information. For example, RegOps tracks which documents are complete, while the functions track their own review processes. In order for the submission to be successful the parts must come together, so communicating status and risk without drama is an important skill to embed in your team culture.

Web-based Tools

There is a new breed of web-based project management tools available that are worth investigating.  These tools were designed to help manage geographically dispersed teams and projects, and are generally less complex and more user-friendly than MS Project. These tools were built from the ground up with collaboration in mind. The simplest approach to collaboration allows people to comment on tasks. More sophisticated tools enable you to associate tasks with risk factors and model potential outcomes. There are dozens of these tools available and many provide free trials. Most are priced at about $25/user/month, so you can get started without too much overhead. Here’s an article from Web Worker Daily that outlines some points to consider in adopting these kinds of tools.

Conclusion

Submission project management is not a static discipline. A submission project may require a variety to tools to meet the needs of different parts of the organization. The main thing is to recognize the way your organization works and the way information moves through the organization, then find a set of tools that works for you.

Additional Resources

• Blog post on eCTD project management

Why Do Final QC?

Final QC serves 2 main purposes. The first is to give authors one last chance to look at their content in the format the agency will be reviewing. The second is to have someone outside the publishing group verify that all the documents published correctly. Both issues are important. The first is a subtle way to check the content, and the second is a more direct way to check the formatting.

Types of Errors Often Found

The types of errors that turn up in Final QC address both content and format. Sometimes formatting is unclear and the publishers have to decide how a document should look. Final QC allows authors to verify that decisions made during the publishing process didn’t adversely affect their content. Perhaps the most important aspect of Final QC is that it allows authors to look at their content with a fresh set of eyes. As submission deadlines near, there is typically a mad dash to finalize documents and hand them off to Regulatory Publishing. Authors are so anxious to meet their deadline that they may overlook simple mistakes. Final QC gives them a chance to catch those mistakes before the documents go to the agency.

I think this process works because the authors look at the documents differently. While on deadline, their focus becomes the deadline. When they do Final QC, their focus is on quality. The fact that they had a few days away from the document while it was in publishing helps, as does the fact the authors hand off Word documents and QC PDFs. This should not be an opportunity for authors to check every data point. That level of QC needs to be done before handing documents off for publishing.

Process

To manage Final QC for a large submission, I find it helpful to assign responsibility to a key person in each function. Those people can then assign document-level responsibility to knowledgeable authors for each section. I generally provide a 5 minute orientation to the submission so everyone knows how to navigate, and a checklist for the Final QC process. Typically, I ask authors to check the following items during Final QC:

• This is the correct document or report, and it is properly identified in the eCTD structure
• The document is complete and accurate, and contains the correct versions of all relevant tables, figures, appendices, and amendments
• There are no blank, extraneous, or unreadable pages, and all pages are oriented correctly on screen
• Every hyperlink, except those in the TOC, points to the correct table, figure, section , or file, and that the referenced information is relevant to the source material

The final step, checking the hyperlinks, is critically important. A publisher can easily interpret an instruction to link to Table 7, but they may not be able to determine whether Table 7 is actually relevant to the material in the source paragraph.

Once the Final QC is complete, Regulatory Publishing needs to determine how to fix any issues discovered during the process. Depending on the severity of the issue and the amount of time left before deadline, you may chose not to fix some issues.

Using an eCTD Viewer

Final QC is an excellent opportunity to familiarize authors with the capabilities of your company’s eCTD viewer. The more the Final QC environment mimics the agency review environment, the more the authors will take Final QC seriously. Using an eCTD viewer helps authors begin to understand the impact of document lifecycle decisions. Some viewers now have the capability to manage review comments, which makes capturing findings during Final QC very easy. If your viewer does not have this capability, you can easily devise a paper system to track any QC findings. Here’s a link to a sample QC sheet in MS Word format that you can modify for your own use: Final QC Sheet.

Conclusion

Final QC is an important part of every submission. A well-designed process is very efficient, and can be scaled to include many people. It helps authors see their documents the way that reviewers will look at them, and can virtually eliminate silly mistakes.

What Are eCTD Leaf Titles?

As files are attached to the eCTD backbone, several pieces of associated metadata are stored in the index.xml file, including file names and leaf titles.  Here’s an example:

<leaf ID="a4928335f5a5bc2e59361e91"

application-version="Acrobat 5 (1.4)"

checksum="0a805abd4cc668a49a1994a"

checksum-type="md5"

operation="new"

xlink:href="m2/24-nonclin-over/nonclinical-overview.pdf"

xlink:type="simple" xml:lang="en" xmlns:xlink="http://www.w3c.org/1999/xlink">

<title>Nonclinical Overview</title>

</leaf>

Let’s examine the metadata in detail:

• The first line tell us that this is a leaf, and gives its unique ID number.  This ID number is used to track lifecycle operations in later sequences.
• The next lines of metadata tell us that this is a pdf document, and give its checksum and checksum type.  The checksum is used to verify that a file hasn’t changed since it was published; any change to the file invalidates the checksum.
• Then we get the operation type, which in this case is new.
• The xlink information is a link to the file.  The first line provides the path from the index.xml to the file, including the file name.  The second line defines what type of link it is.
• Finally, we get to the title attribute, in this case, Nonclinical Overview.
• The last line ends the description of the leaf.

Recommendations For Leaf Titles

Regulatory agencies have been clear that they want concise, descriptive leaf titles to aid their reviewers.  Most publishing tools have reasonably good default values, but some leaf titles require input from the publisher to make them useful.  Remember that leaf titles, not file names, are displayed when reviewers navigate your submission using an eCTD viewer.

Here are a few rules of thumb:

• Always keep leaf titles short.  Titles appear in eCTD viewers the way that bookmarks appear in Acrobat.  Try to limit titles to about 60 characters so that reviewers can get all the information in one view.
• For leaves with an operation of new, you can often use the leaf titles that the publishing software provides.
• For replace or append operations, it’s helpful to indicate that the leaf points to new information.  For example, if we replaced the file above, we might provide the title Updated Nonclinical Overview.  If you can succinctly describe what’s new that’s even more helpful.  If this document was part of an IND submission, a relevant title might be Updated Nonclinical Overview With Chronic Tox Results.
• Ask study report authors to provide a short title, like Phase 3 Study in Relapsed Patients, instead of A Randomized, Double-Blind, Placebo Controlled, etc.  It’s often helpful to include the study number in the title: Phase 2 Dose Ranging Study 123456.
• For granular study reports, it’s helpful to establish a convention that you follow consistently in all studies.  An example might be the study number followed by a description of the file: 123456 List of Investigators or 123456 Protocol Amendment 2.
• Datasets and CRFs also have leaf titles.  It’s much easier to find a dataset titled 123456 Antibody Data rather than AB.xpt.  For case report forms a useful convention might include a combination of study number, site number, and patient number.

Conclusion

Adding useful leaf titles to your submissions doesn’t take much effort, and it makes reviewers’ jobs easier.  There is not much detail on leaf titles in agency guidance, but reviewers consistently ask for better leaf titles in their presentations to industry.  The suggestions above should get you started on the path to better leaf titles.  For more information, search for “leaf title” in the documents below:

FDA Reviewer’s Perspective on Leaf Titles

EMEA Guidance with Leaf Title Information

What To Look For In A Viewer

There are a few things to look for in buying a viewer, besides cost. (Many viewers are bundled with eCTD validation packages. While these packages are essential to the publishing process, they are not essential for viewing.) Here are the characteristics I look for in a viewer:

• Fast loading: people don’t like waiting for windows to load. A good viewer should load a large submission in under a minute.
• Clear presentation of document lifecyles in Current and Cumulative view. Cumulative view shows everything that’s been submitted, Current view hides documents that have been replaced or deleted. Both views should clearly display different lifecycle operations.
• The ability to easily navigate an application with hundreds of sequences. Sometimes you just want to look at one sequence, sometimes you want the whole thing. You should be able to switch with a couple clicks.
• Window management. I like to be able to close the navigation pane when I’m viewing a document and open it when I’m looking for something. For people with laptops this makes a huge difference (and most of your executives probably have laptops).
• Clear presentation of study tagging files (STFs). STFs often contain hundreds of files — too many to scroll through. The viewer should present each file tag as a virtual folder, allowing you to look at case report forms by site, or just the analysis datasets.
• Clear presentation of submission metadata, such as indication, dosage form, sequence number, and submission date. Regulatory people love this, since it makes it easy to understand the chronology of events.

Other Considerations

There are a couple additional points I would consider when selecting a viewer. The first is whether or not the viewer can present non-eCTD submissions. It can be incredibly useful to have a single viewing archive of all submissions, paper and electronic, so this is a plus. The second is that I prefer web-based viewers over desktop viewers. Web viewers are easier to deploy, since you don’t have to install software on everyone’s desktop, and they are usually faster to load submissions. Desktop viewers have to parse all the xml files every time they load an application. Web viewers cache the information in a database, so it loads more quickly. Web-based viewers also provide an extra level of security, in that people can’t get to the submission archive through the viewer.

Cultural Issues

The biggest issue you may encounter in deploying an eCTD viewer is cultural, not technical. In many companies, Regulatory Affairs does not provide access to submissions to people outside the department. I encourage you to buck this trend. Limiting access leads people to create shadow copies of submissions, or worse still, treat drafts of documents they sent to Regulatory as official. Giving people direct access to authoritative documents virtually eliminates these problems. Some viewers allow you to limit access on an application by application basis. This can be useful, but managing those permissions can be a big job. At one company I worked at over 150 people had a legitimate reason to have access to a particular submission. Adding people to that list became a tiresome chore.

Conclusion

The most important thing is to get out and show people how to use the viewer. The viewer applications are generally easy to use, but the eCTD concepts are not. Even if you’re just starting with eCTD using a free desktop viewer, get out and show people what granularity means in m3, and create demo submissions so they can see how document lifecycles work. The best investment you can make is to educate your teams about eCTD.

Study Tagging Files

In the eCTD world, both study report formats require study tagging files (STFs) for submission to the FDA. For legacy reports, the STF provides metadata about the report, including the report number, title, and in some sections, route of administration, duration, etc. STFs for granular reports contain the same information they would for a legacy report, but they also act as a table of contents that organizes the files in the report. Every file associated with an STF is identified with a piece of metadata called a file tag. The file tag identifies the type of information contained in that document. Examples of file tags include report body, synopsis, case report forms, datasets, and listings. File tags enable eCTD viewers to organize the report content into virtual folders, making it easier to navigate the hundreds of files that can make up a clinical study report. You can find more details on study tagging files in this ICH guidance document: ICH STF Guidance. (If you want to see an interesting discussion of the probable future of STFs, check out this post on Kathie Clark’s excellent blog, The eCTD Summit: eCTD Summit.)

Legacy Format

In the eCTD, most nonclinical reports are still submitted in legacy format. There are a couple of reasons for this. The first is that the use of datasets for nonclinical studies is still relatively new, and the standardized formats for that data have not been adopted as widely as the similar formats for clinical reports. Clinical reports generally contain a lot more data, so there was more emphasis on clinical data standards early in the development of the electronic submission standards. The CDISC consortium develops and maintains these standards. You can find more information about CDISC here: CDISC.org, and information about the FDA’s implementation of these standards here: FDA Study Data Specification

The other main reason that nonclinical reports are usually submitted in legacy format has to do with the QA process for those reports. Nonclinical reports are often written by CROs, and they often contain sub-reports that cover a specific discipline or type of analysis. The CRO has to sign off on the quality of the entire report, and then hand it off to the sponsor. The logistics of CRO QA processes and the relatively small size of these reports mean that most CROs prefer to stick with the legacy report format. As sponsors increasingly request granular reports and accompanying datasets, I think this situation will change, but right now there doesn’t seem to be a rush to transition.

It is not common to submit clinical reports in legacy format in eCTD submissions. FDA encourages sponsors to submit clinical reports in the granular format with accompanying datasets. Given the size of most of these reports, not having to assemble everything into one document is actually a time saver for sponsors. The term legacy format refers to the way reports used to be assembled. Since some submissions contain study reports that may have been completed years ago, this option is still available for use as needed. I recommend not preparing new clinical reports in the legacy format if your company submits in eCTD format.

Granular Format

The granular report format actually makes it easier to publish a large clinical study report, but, of course, it brings its own challenges. Not having to assemble and paginate a 10,000 page report is a nice bonus, but requires more focus on the document management process. It’s important to keep track of all the files that make up the report and make certain that they all end up in the right place in the submission. Every document still needs a leaf title and a file tag for the STF. The file tags allow eCTD viewers to group similar files together under headings. For example, case report forms are grouped by site. This grouping makes it easier for reviewers to navigate the hundreds of files that can make up a large report.

I strongly recommend that Regulatory Publishers work with Medical Writers and Statistical Programmers to help them understand how reports are organized in the eCTD. In particular, pay attention to file tags, leaf titles, and, most importantly, the table of contents of study reports as described in the ICH E3 guidance: ICH E3 Guidance.

In the eCTD world it is highly advantageous for clinical study reports to follow the numbering and heading titles of the E3 guidance. In the legacy format, Medical Writers had more flexibility to adjust the table of contents to their liking. In the eCTD world, that flexibility makes the Regulatory Publisher’s job a nightmare. There is some flexibility in the organization of section 14 of the report, since that is part of the report body. There is no flexibility in section 16, since each section requires its own file tags and leaf titles, based on the E3 table of contents. If a particular part of section 16 is not applicable to a given report, leave it out, but don’t change the numbering. It is not necessary to assemble all the components under a given file tag, however. Each document can go in separately, as long as the leaf titles differentiate the individual files.

Conclusion

While the legacy report format is still commonly used for nonclinical reports, clinical reports that will be submitted to an eCTD application should be in the granular format. It is important to coordinate between the Medical Writers, Statistical Programmers, and Regulatory Publishers to ensure that granular reports can be easily published in the eCTD submission. Once this coordination is in place, granular report publishing becomes an exercise in document management, where the focus turns to getting each file into it’s proper place in the submission, with clear leaf titles and accurate file tags.

This is a complex topic with many nuances not covered in this post. Please post any follow up comments or questions below.

Background

First, it’s important to remember why the forms are useful. For companies using the Electronic Submissions Gateway (ESG), the forms provide a way for submissions to get to reviewers without requiring human intervention. The gateway is programmed to look for files named 1571.pdf or 356h.pdf. If those files were created with the fillable forms, the gateway reads the application and sequence numbers from the form and automatically routes the submission. This is the fastest way to get submissions from your company to reviewers.

If you don’t use the fillable forms, your submissions end up in the Electronic Document Room, where someone has to open up the pdf file to figure out the submission and sequence numbers. This process can delay delivery of your submission to reviewers by up to a week.

So how best to implement the forms? There are 2 basic approaches: use Acrobat self-sign certificates, or send unsigned forms with a scanned version of the printed form. I’ll describe how each approach works.

Fillable Form Plus Scanned Form With Signature

If you are uncomfortable digitally signing the form, you can send an unsigned fillable form along with a scanned version of the signed, printed form. Both forms go in the same place in m1. The fillable form needs to be named 1571.pdf or 356h.pdf. The scanned form can be named something like scanned-form.pdf, but the name must not contain the form number.

Fillable Form With Electronic Signature

To streamline this process, consider using Acrobat self-sign certificates. These certificates enable anyone with Acrobat to add their digital signature to a document. Before you begin you have to send a non-repudiation letter to the agency stating that your company recognizes digital signatures as the equivalent of paper signatures. This is a simple letter, but you may want to discuss its contents and implications with your legal and QA departments before sending.

To implement the process, you go to each potential signatory’s computer and help them create a certificate from within Acrobat (it varies slightly depending on which version of Acrobat you’re using). The signers should save a copy of the signature file on their laptop (in case they need to sign something while traveling) and a second copy in a secure location on your network. They need to use a password that they will remember–they have to use the password each time they sign a document.

Once you’ve set this up it’s very easy to actually sign a document. A signer clicks on the signature block on the form, selects their certificate file, enters their password, and selects a reason for signing from the popup list. The whole thing takes only slightly longer than a paper signature.

For more information on digital signatures and fillable forms, check out this FDA guidance: Electronic Signatures Guidance

It’s often challenging to figure out best practices under time pressure, so I’ve outlined some strategies to address this situation before it arises.

Challenges

The problems with agency responses usually fall into 3 areas:

• Updating portions of existing documents under deadline
• Responding to a request for information that doesn’t usually go into a submission
• Balancing the often conflicting needs to answer the question and maintain clean document lifecycles

Updated Previously-Submitted Information

The first issue arises when the agency requests updates to information that’s already been submitted. For example, the original submission contained a discussion of 3 month stability data and the agency wants an update with 6 month data. It’s tempting, under deadline, to simply append the new information to the old, but this is penny wise and pound foolish. Authors and Regulatory professionals can be reluctant to replace what they’ve already submitted, preferring to append. Regulatory Operations often has to persuade them to take the time to update documents in order to use the Replace, rather than Append eCTD lifecycle operation. This is one of those situations where you have to convince people that you really are looking out for their long-term interests, and not trying to make their life difficult by insisting on process for the sake of process.

Sending Information That Isn’t Normally Part of a Submission

Sometimes the agency requests information that wouldn’t normally be included in a submission. For example, they may request SOPs related to cleaning-in-place procedures, but the company doesn’t normally include SOPs in submissions. If you do submit them, you want them to stand apart from the submission, so that you’re not setting a precedent, but still make it easy for the reviewers to find the information. In this case, I would include the information in module 1 and link to it from the cover letter. Putting the SOPs in module 3 suggests that’s where they would normally go. Putting them in module 1 suggests they’re part of a response to questions, not part of the normal submission.

Updating Information Separate From the Response

The third situation arises when you want to update certain information, such as the stability data in the first example, but also respond to the original question outside the normal eCTD structure. In this case, I recommend updating the stability information using the Replace lifecycle operation, and placing a response to questions document in module 1. It’s important to explain what you did in the cover letter and include a link to the response document. You should also include links from the response document to the updated information in modules 2-5. This approach ensures that you’ve checked the box by responding to the question, and you’ve only included information in modules 2-5 that you want to be part of the ongoing record of that submission. In the future, people can refer back to module 1 to see the responses, but the key data has been included in the relevant technical sections following good document lifecycle practices. Ultimately, you can’t control where the agency goes with their review, but you can control how you present and organize the information you submit.

When it comes to responding to agency questions, there is not a one-size-fits-all solution. Take advantage of the structure of the eCTD to organize your responses in a way that makes sense to you and will be easy to explain to your colleagues.