This paper discusses background information related to RM regulatory requirements and industry challenges, and then highlights key principles to consider in setting up a risk-based RM management approach and control strategy. This paper then provides an example of how to translate those key principles into a detailed RM risk assessment methodology, and how to apply this methodology to specific raw materials. To better illustrate the diversity and nuance in applying a corresponding RM control strategy, a number of case studies with raw materials typically utilized in the manufacture of biological medicinal products have been included as well as discussion on phase-based mitigations.
One of the hallmarks of a quality culture is learning from our past experiences, to eliminate repeat mistakes and to reproduce success. The more times you do an activity, the more you learn, and the better you get (within limits for simple activities). Knowledge management is an enabler of quality systems, in part, to focus on learning and thus accelerate learning across the organization as a whole, and not just one person or a team.
This is where the” lessons learned” process comes in. There are a lot of definitions of lessons learned out there, but the definition I keep returning to is that a lessons learned is a change in personal or organizational behavior as a result from learning from experience. Ideally, this is a permanent, institutionalized change, and this is often where our quality systems can really drive continuous improvement.
Lessons identified is generate, assess, and share.
Updated processes (and documents) is contextualize, apply and update.
Identify Lessons Learned
Identifying lessons needs to be done regularly, the closer to actual change management and control activities the better. The formality of this exercise depends on the scale of the change. There are basically a few major forms:
After action reviews: held daily (or other regular cycle) for high intensity learning. Tends to be very focused on questions of the day.
Retrospective: Held at specific periods (for example project gates or change control status changes. Tends to have a specific focus on a single project.
Consistency discussions: Held periodically among a community of practice, such as quality reviewers or multiple site process owners. This form looks holistically at all changes over a period of time (weekly, monthly, quarterly). Very effective when linked to a set of leading and lagging indicators.
Incident and events: Deviations happen. Make sure you learn the lessons and implement solutions.
The chosen formality should be based on the level of change. A healthy organization will be utilizing all of these.
Level of Change
Form of Lesson Learned
Consistency discussion After action (when things go wrong)
Retrospective After action (weekly, daily as needed)
Retrospective After action (daily)
Successful lessons learned:
Are based on solid performance data: Based on facts and the analysis of facts.
Separate experience from opinion as much as possible. A lesson arises from actual experience and is an objective reflection on the results.
Generate distinct lessons from which others can learn and take action. A good action avoids generalities.
In practice there are a lot of similarities between the techniques to facilitate a good lessons learned and a root cause analysis. Start with a good core of questions, starting with the what:
What were some of the key issues?
What were the success factors?
What worked well?
What did not work well?
What were the challenges and pitfalls?
What would you approach differently if you ever did this again?
From these what questions, we can continue to narrow in on the learnings by asking why and how questions. Ask open questions, and utilize all the techniques of root cause analysis here.
Then once you are at (or close) to a defined issue for the learning (a root cause), ask a future-tense question to make it actionable, such as:
What would your advice be for someone doing this in the future?
What would you do next time?
Press for specifics. if it is not actionable it is not really a learning.
Update the Process
Learning implies memory, and an organization’s memories usually require procedures, job aids and other tools to be updated and created. In short, lessons should evolve your process. This is often the responsibility of the change management process owner. You need to make sure the lesson actually takes hold.
Differences between effectiveness reviews and lesson’s learned
What can we learn from this change for the next change?
Effectiveness reviews are 1 and 2 (based on a risk based approach) while lessons learned is 3. Lessons learned contributes to the health of the system and drives continuous improvements in the how we make changes.
Lesson learned management model for solving incidents. (2017). 2017 12th Iberian Conference on Information Systems and Technologies (CISTI), Information Systems and Technologies (CISTI), 2017 12th Iberian Conference On, 1.
Fowlin, J. j & Cennamo, K. (2017). Approaching Knowledge Management Through the Lens of the Knowledge Life Cycle: a Case Study Investigation. TechTrends: Linking Research & Practice to Improve Learning, 61(1), 55–64.
Michell, V., & McKenzie, J. (2017). Lessons learned: Structuring knowledge codification and abstraction to provide meaningful information for learning. VINE: The Journal of Information & Knowledge Management Systems, 47(3), 411–428.
Milton, N. J. (2010). The Lessons Learned Handbook : Practical Approaches to Learning From Experience. Burlington: Chandos Publishing.
Paul R. Carlile. (2004). Transferring, Translating, and Transforming: An Integrative Framework for Managing Knowledge across Boundaries. Organization Science, (5), 555.
Secchi, P. (Ed.) (1999). Proceedings of Alerts and Lessons Learned: An Effective way to prevent failures and problems. Technical Report WPP-167. Noordwijk, The Netherlands: ESTEC
While most of the advanced technologies already exist today, few pharmaceutical companies have yet to see any significant benefits. On one side, quality leaders struggle to define a clear business case for the technological changes, and thus fail to bring to management attention to the significant impact potential associated with lab digitization or automation. On the other side, companies often neglect the development of a clear long-term lab evolution strategy and blueprint, which can lead to some costly investments with unclear benefits.
— Read on https://www.pharmamanufacturing.com/articles/2018/the-future-of-quality-control/
“If it Isn’t Written Down, then it Didn’t Happen” is a guiding principle of the quality profession.
There are four major types of writing in quality: instructional, informational, persuasive and transactional. When evaluated against the three major document types instructional is a functional document, informational is a report and transactional is a record. This is not to say that all transactional business writing should be considered a record, the traditional argument against emails in quality systems for example.
It is important to understand these differences as they require differences in writing style, format and grammar. An SOP (instructional/functional) is very different that an informational/report). When building your writing competencies it is important to remember these are different (with a common foundation).
We utilize reports in our quality systems (and everywhere else) to act, to communicate information, to capture work completed, to record incidents, to finalize projects and recommendations, and to act as an archive. A well written report allows the reader to easily grasp the content and, if applicable, make informed decision. Report writing is a cornerstone of a CAPA system (from incident identification to root cause through CAPA completion and effectiveness review), validation, risk management and so much more.
In short, reports are our stories, they form the narrative. And how we tell that narrative determines how we think of an issue, and how we will continue to thing of it in the future.
We tend to mix and match two modes in our report writing — Story thought and system:
Story thought emphasizes subjective human experience, the primacy of individual actors, narrative and social ordering, messiness, edge cases, content, and above all meaning.
System thought emphasizes 3rd-person descriptions of phenomena from a neutral perspective, the interchangeability of actors and details, categorical or logical ordering, measurements, flow, form, and above all coherence.
We tend to lean more heavily on system thought in quality,the roots of the discipline and the configuration of our organizations make us predisposed to the system thought mode. This means that over time, best practices accumulate that favor system thought, and many of our our partners (regulatory agencies, standard setting bodies, etc) favor the measurable and the reducible. However, by favoring the system thought mode we are at jeopardy of missing how human beings function in our organizations and how our organizations need to deal with society. And we make mistakes. Me make bad decisions. We fail to deal with the truly complicated problems.
It is time to learn how to utilize story though more in quality.
On my.ASQ.org the following question was asked “The Device History Record is a form in fillable PDF format. Worker opens the PDF from a secure source within the local network. The only thing they can change is checkmark Pass/Fail, Yes/No and enter serial numbers in the allowed fields. Then after the assembly process is done for each procedure, the worker prints the DHR, signs and dates it by hand, to verify the accuracy of data entered. No re-printing or saving PDF’s is allowed.”
This comes up a lot. This is really a simple version of a hybrid situation, where both electronic and paper versions of the record exists.
Turning to the PIC/S draft guidance we find on page 44 of 52 “Each element of the hybrid system should be qualified and controlled in accordance with the guidance relating to manual and computerised systems”
Here would be my recommendation (and its one tried and tested).
The pdf form needs to be under the same document management system and controls as any other form. Ideally the exact same system. This provides version control and change management to the form. It also allows users to know they have the current version at all times.
Once it is printed, the paper version is the record. It has a wet-signature and it under all the same predicate record requirements. This record gets archived appropriately.
Where I have seen companies get messed up here is when the pdf exists in a separate, usually poorly controlled system from the rest of your document management. Situations like this should really be evaluated from the document management perspective and not the computer systems life-cycle perspective. But its all data integrity.