Stuart R. Gallant, MD, PhD
The first part of this two-post series addressed knowledge management and knowledge mapping. In this second part, the use of these tools will be discussed.
The Knowledge Base
In the first part, a knowledge map for CMC activities was provided:
Here are some thoughts on the use of this type of knowledge map:
- A knowledge map represents an expectation which is placed on the development team. Team members are asked to save documents from their emails and populate the knowledge structure. Fortunately, as more and more documents begin to occupy the various niches, the team will start to see the advantages of sharing information, and they will proactively start to use the structure.
- Periodically aligning the map and the actual practices of the team are important. Directories that the team adds within Dropbox, should be added to the map document. Also, it will happen that directories are mistakenly created and documents are misfiled—in that case, the documents should be moved to their correct location within the structure.
- Encouraging a simple internal structure to each subdirectory with the current version of a file visible and older versions swept into an archive subfolder is helpful. Upon opening a given subdirectory, a user sees:
Of course, some subdirectories will contain multiple files; the point is to clear older version out of the way without completely discarding them.
Knowledge Events and Report Writing
From time to time, knowledge events occur (for example, technology transfer of manufacturing process to a new CMO, manufacture of a new lot of drug substance or drug product, occurrence of a significant manufacturing deviation which requires significant effort to resolve). In these events, learning takes place. After completion of the event, it is important to capture this learning in the form of one or more reports.
Reports are the opportunity to reflect on events, analyze data, document lessons learned, and commit to paper insights that could be lost otherwise. As such, they are the heart of learning. In the 2013 film The Challenger Disaster, the significance of the report writing process to scientific inquiry is shown [1]. Richard Feynman is shown traveling to multiple sites collecting data on the Challenger crash, then he spends hours typing his insights into an early word processor to share with the other members of the accident investigation team. As shown in the film, knowledge events provide the opportunity for learning by: 1) reflection and then 2) committing what is learned to an electronic record in the form of a report.
Some reports to consider writing include:
- Formulation: this report is very helpful in supporting the drug in the clinic and ties together with the investigator brochure and the pharmacy manual
- Process manufacturing reports: some prefer to write individual reports for each manufacturing step; others prefer to write one or two larger reports. Either is acceptable.
- Analytical method reports: reports on unique methods (rather than standard USP methods) are helpful. Reports by CMOs tend to focus on what rather than why, so the pharmaceutical startup is benefitted by writing its own top level reports in some cases.
- Campaign summary reports: after each manufacturing campaign, the CMO typically writes a report, but often those reports don’t emphasize learning—they are more about what happened, rather than why. The pharmaceutical startup should write its own top level campaign summary reports to tie things together and maximize learning.
- Knowledge base report: where everything is and what is there. This can be a fairly brief report—an inventory really.
As the program processes the number and variety of reports will expand, providing a resource to the existing team to remember what happened in the past and to new team members to learn why the project is designed in the way that it is.
The Value of the Knowledge Base
As a pharmaceutical startup develops its knowledge base for its drug, many benefits accrue to the company:
- Writing filings (INDs, annual reports, NDAs) becomes easier.
- At the point of a regulatory audit (for example a pre-approval inspection), the knowledge base acts as a multilayered system of armor against any questions that may be posed by regulators.
- This system captures knowledge from the team members within the pharmaceutical startup, but also from the scientists and engineers at CROs and CMOs employed on the project. Memorializing this type of external knowledge facilitates site to site and lab to lab technology transfers, as well as answering regulatory questions. To maximize this type of value internal employees have to be aligned on capturing that external knowledge, ensuring that assay validation reports, cleaning validation reports, raw materials information, and other types of information which is not typically included with executed batch records is captured.
- Having this type of robust knowledge base makes success in the manufacturing suite and in the clinic more likely because decisions are made with the most robust possible data set.
- The existence of this type of knowledge base is helpful on the business side by giving reassurance to potential investors, partners, and purchasers about the solid technical state of the business.
- As the project transitions from an early-stage project to a late-stage project, additional knowledge resources can be brought to bear more easily, platforming on the initial knowledge base:
- Process and analytical method validation
- Statistical process control
- Enterprise software
- Engineering modeling software
- Continuous improvement
- Process history and training
- Post-approval commitments
[1] www.youtube.com/watch?v=vXGnOROO0Yw
Disclaimer: PharmaTopoTM provides commentary on topics related to drugs. The content on this website does not constitute technical, medical, legal, or financial advice. Consult an appropriately skilled professional, such as an engineer, doctor, lawyer, or investment counselor, prior to undertaking any action related to the topics discussed on PharmaTopo.com.