DSI has seen a lot of pharmaceutical development reports ranging from several hundred pages to a summary of conclusions attached to stacks of data. The latter can make things difficult when it’s time to put a regulatory filing together. It’s become clear that capturing development decisions and data from the outset in a living document is good practice and whether the data collected thus far is supporting development goals. It’s a reference point for what has been completed and what still has to be done.
While, ideally, a development report should be close to a final state at the time of filing, it’s not absolutely necessary, says Kyriakos Michailaros, Head of Drug Product Services at DSI, a ProductLife Group company.
Kyriakos, better known as Q, says the development report is intended to tell the story of the drug’s development. It should identify the initial goals, background science, experiments, data and anything that steers the process development and determines the final formulation and manufacturing process.
Start with a plan
Every development program has to start with a plan. Close to project kick-off, organizations should draft a Quality Target Pharmaceutical Profile (QTPP) that summarizes what the product is intended to treat, administration, dosing, and other relevant attributes. A Gantt chart lays out the milestones and timeline to accomplish this from early phase potentially through filing, Q says. Some of the milestones along that path include excipient compatibility, finalizing your formulation, process development, phase two, optimization, and potentially end of phase three.
“At those points, it's important to have a report or a risk assessment documenting the data collected and the conclusions and decisions made based on that data for the development program,” Q says. “Better yet, a characterization report outlines your critical process parameters and demonstrates that you can consistently make the product.”
A common problem is data tends to be in disparate reports up until the time of filing. When considering development programs evolve over years and there is often turnover within the development team. So, how do you stay on top of these different parts of the process and capture the entire history of the program? The answer lies in having an updated living document.
“Having your development data and conclusions automatically downloaded to a common document means you have all the critical information that you’re basing your development program on in one place,” Q says. “So, if you’re having a meeting with the FDA or planning a filing, you know where to find all the relevant information.”
It also means capturing information that wasn’t used in the development, since every good program conducts risk assessments along the way to demonstrate that major concerns have been addressed.
Piecing it all together
As CMC consultants, Q and his team typically find that the development story involves piecing together a jumble of somewhat organized – or often disorganized – data summaries, assessments, batch records and reports that may, or may not, be complete.
A major benefit of a working development document is to keep everything in one place, creating a common understanding of where to find things. This saves time and avoids confusion among members of a development program. This makes it easy to see the data upon which decisions have been based, and what's missing.
Even if a company decides only to take a product to the IND stage before seeking a buyer, having a complete summary of development work thus far helps potential buyers with the due diligence process. Alternatively, a good approach would be to have a working document repository with a file structure that can be easily followed in order to piece together a report.
Q says, “I think it's actually more important in a situation like that, where you don't want to take a project all the way to completion, to have a working document because you're not then scrambling to get something together that's coherent if and when you enter talks with a potential buyer.”
Addressing the gaps
As companies get closer to milestones it’s important to determine what are the gaps in their development program. That’s where CMC experts, such as Q, come in to provide a gap analysis.
When doing a gap analysis, “The first thing I would check is that a company has the appropriate stability information,” he says. “Is the stability on the finalized packaging configuration or formulation or process in line with expiry data? It takes time to acquire stability data, so fixing this issue will take some time.”
Other areas to assess are, have the process control parameters been appropriately characterized? Do they make sense for the drug product and the processes being used to make it?
Drug products come in many forms and it’s necessary to take a product-specific approach when reviewing. It’s critical to know which regulations apply and to understand the rationale for decisions being made.
“At the minimum, you need to check the boxes,” Q says. “You need to have the particular issues that are known for the type of formulation, for the type of drug product, for the type of packaging configuration, pretty well covered because they’ll be scrutinized.”
Start early, stay up to date
As drug product subject matter experts, Q and his team have worked on many submissions where source documents were not organized and were incomplete. Fixing this is not only time-intensive, but also leaves questions of whether some development work might not have been fully captured.
“It’s never too early to start your development report to have the story of the development complete and summarized by the time you're making an NDA submission,” Q says.
“With information easily available, it becomes simpler to put forward arguments to the reviewers, present explanations and justifications for certain data, and tackle difficult issues head-on, rather than wait for reviewers to notice the problematic data during the review,” adds Ed Narke, DSI principal and chief regulatory scientist.