Is It Time For A Standardized CMC Knowledge Base?
By Sue Wollowitz, Ph.D., president, Wollowitz Associates LLC
At small pharma companies, most of the CMC (chemistry, manufacturing, and controls) knowledge base is generated by a global array of outside providers. The companies are challenged to create and manage a high-functioning knowledge base of information with little or no support staff. Let’s start with some examples of the current state.
A CDMO has posted all of its documents, from meeting minutes to batch records, on a share site for use by each of its clients. The client wants the documents in its own library, organized differently, and therefore pulls and places each document into its own library. These are added to the documents from other CDMOs that are typically sent by email (to at least four people at the sponsor), and then someone uploads them to the library. The client subsequently partners with another organization that also wants all the documents in its own system. Each of hundreds of CMC documents for the project is again uploaded to a new site that is essentially a duplicate of the client’s, and yet never truly integrates into the partner’s system.
In large companies, the knowledge may be spread across multiple departments or databases that make it hard to extract a full tech transfer package (all GMP records, all development reports, all decisions and project assessments) in an organized way, but even this can impact small pharma.
A small company has in-licensed drug candidates from a large pharma company. Technical transfer means a large e-pile of documents, but not in an organized fashion. Whenever a piece of information is needed, the company peruses the files, picks what it needs, and adds it to its database. The small pharma finds that the e-pile is incomplete due to the amount of coordination that would have been required at the large pharma to fully extract all the required information.
In today’s drug development world, we know that almost all documents will be shared across companies at least once, and the above is the norm, not the unusual. So why do we keep doing this?
The Difficulty Of Managing Information
In small companies as well as large, in sponsors and CDMOs, the need to have a functional repository, or library, of knowledge is critical. We are awash with documents that we want to manage: everything from GMP documents to process/product/analytical development reports, meeting minutes, and project analysis documents. The demands placed on a system today are different from 25 years ago. Specifically, (1) they must accommodate data and documents from multiple sources, none of which is wholly dedicated to a given sponsor, and (2) they are often shared and transferred as corporate ownership of projects changes. In addition, (3) with off-the-shelf file systems, companies don’t spend two years designing custom systems, but, likewise, they don’t build library systems with features valuable to company and project growth. Finally, (4) the ease of file sharing today and the leanest of companies means that libraries have limited curation, yet people want more data mine-ability.
Each sponsor company creates its own library system based on the organizational structure and history of the company. Companies that developed their library systems long before the outsourcing revolution can be challenged by how to incorporate documents from outsourced providers or partners into their systems. Those companies whose knowledge is generated mostly by CDMOs have different ways to organize multi-CDMO information. On the other hand, each outsourced provider has different ways of organizing its own data, different styles to capture information, and, sometimes, different names for document and activities. While one CDMO may include IPC data within the batch record, another may consider it a separate document. Likewise, deviation and investigation reports may be incorporated or not. Evaluation of solubility and stability may be part of a large process development report or as a stand-alone report from a preformulation team. There may be meeting minutes provided by the CDMO’s project manager, or not. Joint project decisions may be captured in a document generated by the CDMO or by the sponsor or not at all. Having a library structure built around a single company’s system inevitably leads to appearance of false gaps in information or a lot of documents with no place to go.
The various GMP records, development records, and project management documents are often transferred to the sponsor by email (and sit in multiple in-boxes) or through setting up a share site or single document box for large documents. Some are password protected, others are not. While it is great that all these are possible, it means that there are inconsistencies in where to grab documents, who gets them, who knows they are there.
There are a number of software systems for managing GxP documents and workflows, though they may be too complex for a small client company with one or two products and a simple supply chain. But for the CDMO, just like for the client, every interface may be different; one or several people at the CDMO that provide documents and data have to respond to client-specific preferences.
If a company has multiple projects, or multiple departments work on a project, libraries are often not project-modular, even though we know that many projects change hands during the course of development. Each type of document may be associated with the same type of document from other projects. All specifications are together, all reports out of the solid-state characterization team are grouped together, etc. One can extract all project-specific documents from the various systems, but they have then lost their file structure and a new one must be rebuilt temporarily, or permanently, making data-mining less efficient and effective; the knowledge base has lost value.
With the current options for databases that require only limited IT involvement, it is almost too easy to create file folders and subfolders, drop in, rename, revise, and move documents, and to add tags on the fly. The library itself becomes a continuous work in progress even as the understanding of what is needed widens and the wish list for searchability gets longer. Other companies with older custom systems are stuck with rigid systems, difficult to incorporate newer features. The time and money it takes to change systems means that companies limp along with inefficient and/or poor-quality libraries long after they have outgrown them. That this happens again and again in companies, each with the same needs and goals, is wasteful.
Many software companies offer document management and workflow systems for GMP information and document management, but in small sponsor companies these systems are often too structured for internal or contracted QA processes. Transferablity to such systems as the company grows can again be problematic.
What Should Our Libraries Do For Us?
Lean organizations require multitasking with little administrative support. A library accessible to all often means a library that can be edited by all. As new people join a company, library organization becomes a problem or documents just don’t get uploaded. This is exacerbated by the multisource problem above.
And yet a library is only as good as its ability to find documents and data (that should be in it). Being able to confidently find the right information for regulatory submissions is a common search goal. New ideas, or new problems with our old ideas, also send us back to our knowledge base to seek information, clues, and solutions. And there will inevitably be the forensic readers – people who have limited knowledge about project history or about the people and/or companies that carried it out. They may be in-licensing the project, want to evaluate intellectual property, or find answers to manufacturing issues.
So what would a standardized library look like? To start with, it would be modular for each project (or several modules for each project). It would be pre-configured for the knowledge base purpose. It would be flexible in the company-specific definition of documents. It would allow direct entry of documents by each CDMO in a secure fashion. The organization and metadata types would be familiar to all so that CDMOs, sponsors, new personnel, and forensic readers would all know where things go and where to find them. It would be more than a library, but also a tool for work management. Being preconfigured, rather than custom-built by the client, it would easily allow for upgrades and platform changes as the demands and technology evolve.
Having such a system would simplify the interface between CDMOs and their clients and would increase searchability and efficient data-mining for the client sponsor’s research, regulatory CMC, manufacturing, and QA personnel, whether familiar or new to the company. Likewise, due diligence personnel could quickly assess project state and tech transfer to an in-licensing organization could begin by easy modular transfer of the standard formatted library.
Personally, I think we’re ready. Comments welcome — share yours in the Comments section below.
About The Author:
Sue Wollowitz, Ph.D., is a pharmaceutical development consultant and educator. She is interested in CMC tactics and strategies in small companies that increase operational quality and best support project goals. Wollowitz has led pharmaceutical operations at Medivation, Inc. and held various positions at Cerus Corp. and Dow Chemical Corp. She is the holder of 32 patents and the author of over 20 publications. Wollowitz has a Ph.D. in organic chemistry from the University of Wisconsin-Madison and further training at CNRS in France and at the University of Chicago. She can be contacted at suewollowitz@gmail.com or on LinkedIn.