These experiments show some preliminary evidence that the color assignment in risk matrices might influence people’s perception of risk gravity, and therefore their decisionmaking with regards to risk mitigation. We found that individuals might be tempted to cross color boundaries when reducing risks even if this option is not advantageous (i.e., the boundary crossing effect). However, this effect was not consistently found when we included exploratory analyses of risk mitigations at different impact levels.
Pending future research replicating these results, the cautious recommendation is that the potential biasing effects of color should be considered alongside the goal of communication. If the purpose of communication is informing individuals in an unbiased way, these findings suggest it might be worth eliminating colors from risk matrices in order to reduce the risk of the boundary-crossing effect. On the other hand, if the goal of communication is to persuade individuals to implement certain risk mitigation actions, it might be that assigning colors so as to elicit the boundary-crossing effect would facilitate this. This could be the case, for example, when designing risk matrices that communicate action standards (i.e., severity level at which risk mitigation should be implemented) (Keller et al., 2009). This advice might be particularly relevant in the case of semiqualitative risk matrices, where color assignment might be arbitrary due to the absence of clear numeric cut-off points separating risk severity categories, and to situations where the users of the risk matrix are expected to be of higher numeracy and not have prior training in the design and use of risk matrices.
Proto, R., Recchia, G., Dryhurst, S., & Freeman, A. L. J. (2023). Do colored cells in risk matrices affect decision-making and risk perception? Insights from randomized controlled studies. Risk Analysis, 43, 2114–2128. https://doi.org/10.1111/risa.14091
Well, that is thought-provoking. I guess I need to start evaluating the removal of a lot of color from SOPs, work instructions, and templates.
Inevitably, in biotech, with our manufacturing processes such as cell culture, fermentation, and purification, we ask the question (especially with continuous manufacturing), “Just what is a batch anyway.” Luckily for us, the ISA S88.01 provides a standard, with models and terminology, to give us a structured framework to define, control, and automate batch processes effectively
ISA S88.01 (ANSI/ISA-88) standardizes batch control terminology by providing a consistent set of models and terminology for describing all the aspects of batch processing. This standardization helps improve communication between all parties involved in batch control, including users, vendors, and engineers.
Models and Terminology: ISA S88.01 defines a set of models and terminology to describe batch control’s physical and procedural aspects. This includes the physical model, which outlines the hierarchical structure of equipment, and the procedural control model, which details the sequence of operations and phases involved in batch processing.
Physical Model: The physical model begins at the enterprise level and includes sites, areas, process cells, units, equipment, and control modules. This hierarchical structure ensures that all physical components involved in batch processing are consistently described.
Procedural Control Model: This model consists of recipe procedures, unit procedures, operations, and phases. Each level in this hierarchy represents a different level of detail in the batch process, from high-level procedures to specific actions performed by equipment.
Recipe Types and Contents: ISA S88.01 standardizes the types of recipes (general, site, master, and control) and their contents, which include the header, formula, equipment requirements, procedure, and other necessary information. This ensures recipes are consistently structured and understood across different systems and organizations.
State Definitions: The standard defines various states that units or phases can transition through during their operation, such as idle, running, held, paused, aborted, and completed. These states provide a standardized framework for interaction between recipe phases and control system equipment.
Data Structures and Guidelines: ISA S88.01 provides guidelines for data structures and batch control languages, simplifying programming, configuration tasks, and communication between system components. This helps ensure that data is consistently managed and communicated within the batch control system.
The Batch Record
Batch records are the primary documentation that captures the real-time performance of production records. Batch records are crucial to confirming that all expected and required actions have been completed within parameters to produce a product that meets specifications and complies with quality standards.
The Master Batch Record (MBR) is the version-controlled documentation necessary to trace the complete cycle of manufacture of a batch of product, from the dispensing of materials through all processing, testing, and subsequent packaging to the dispatch for sale or supply of the finished product. This documentation includes quality control, quality assurance, and environmental data relevant to the intended manufacturing.
The MBR may be segmented on intended manufacturing and testing stages, each part controlled separately.
The Production Batch Record (PBR) is issued for manufacturing one (or more) batches from the MBR and is compiled during manufacturing.
The MBR and PBR may be controlled in the document management system, within a manufacturing execution system (MES)/electronic batch record (EBR) platform, or some hybrid. Parts may also be found within the LIMS, data historian, and other electronic systems. A critical part of building the MBR is ensuring the correct connections between it and data in specific electronic platforms.
Electronic System
Description
Master Production Record
Master Recipe
Contains product name or designation, recipe designation or version, formulas, equipment requirements or classes, sequence of activities, procedures, normalized bill of materials (quantity per unit volume to produce)
Work Instructions
Additional detailed instructions – may include electronic SOPs or SOP references
Critical Process Parameters
Required Process Parameters that are to be checked or monitored or are to be downloaded to other systems such as automation
Production Batch Record
Control Recipe
A Master Recipe dispatched or otherwise made available in manufacturing-related areas for Execution. Includes Master Recipe information with the addition of schedule, specific quantity to make, actual target bill of materials quantities, and other data for the batch and production instance
Electronic Production Record
A store of data and information created by systems or entered by personnel during execution of Control Recipes May be located in one or more systems or databases Data may or may not be stored in human readable format
Production Report
Data and information in human-readable format, presented either in electronic or paper format for activities such as review, disposition, investigation, audit, and analysis.
I don’t like the term validation deviation, preferring to use discrepancy to cover the errors or failures that occur during qualification/validation, such as when the actual results of a test step in a protocol do not match the expected results. These discrepancies can arise for various reasons, including errors in the protocol, execution issues, or external factors.
I don’t like using the term deviation as I try to avoid terms becoming too overused in too many ways. By choosing discrepancy it serves to move them to a lower order of problem so they can be addressed holistically.
Validation discrepancies really get to the heart of deciding whether the given system/process is fit-for-purpose and fit-for-use. As such, they require being addressed in a timely and pragmatic way.
And, like anything else, having an effective procedure to manage is critical.
Validation discrepancies are a great example of building problem-solving into a process.
Proper pronoun use is a small but significant step towards building a more inclusive, respectful, and equitable workplace. It helps create a culture where all individuals feel seen, heard, and valued, which is essential for fostering a positive and productive work environment.
Practical Steps to Ensure the Use of Preferred Pronouns at Work
1. Lead by Example
Include Pronouns in Signatures: Encourage employees to add their pronouns to email signatures, LinkedIn profiles, and other digital communication channels.
Introduce with Pronouns: Leaders and managers should model the behavior by introducing themselves with their pronouns in meetings and communications.
2. Use Gender-Neutral Language
Address Groups Inclusively: Use terms like “team,” “folks,” or “everyone” instead of gendered terms like “ladies and gentlemen”.
Inclusive Terms: Replace gender-specific terms such as “maternity leave” with “parental leave” and use “partner” or “spouse” instead of “husband” or “wife”.
3. Provide Education and Training
Regular Training Sessions: Conduct mandatory training on using correct pronouns and inclusive language.
Continuous Learning: Offer ongoing education opportunities rather than one-time sessions to ensure the practice becomes ingrained in the company culture.
4. Create a Supportive Environment
Encourage Voluntary Disclosure: While promoting pronoun sharing, ensure it remains voluntary to avoid pressuring employees who may not be ready to disclose their gender identity.
Normalize Pronoun Sharing: Make sharing pronouns a regular part of introductions and communications to normalize the practice.
5. Address Mistakes Appropriately
Correct and Apologize: If someone uses the wrong pronoun, they should correct themselves, apologize, and try to use the proper pronoun in the future.
Practice Pronouns: Encourage employees to practice using correct pronouns to prevent mistakes and create a more inclusive environment.
6. Implement Policies and Consequences
Anti-Discrimination Policies: Ensure that company policies explicitly prohibit discrimination based on gender identity and expression, including intentional misgendering.
Consequences for Misgendering: Include intentional misgendering and deadnaming in the formal definition of harassment and outline clear consequences for such behavior.
7. Visible Support from Leadership
Senior Leadership Engagement: Ensure senior leaders actively support and participate in pronoun initiatives to demonstrate the company’s commitment to inclusivity.
I have a little trick when reviewing a Quality Risk Management SOP. I go to the process/procedure map section, and if I see only the illustration from ICH Q9, I know I am looking at an organization that hasn’t actually thought about risk management.
A risk management process needs more than the methodology behind individual risk management (assess, control, review). It needs to include the following:
Risk Plan: How do you manage risk management holistically? Which systems/processes have living risk assessments? What are your planned reviews? What significant initiatives around quality risk management are included?
Risk Register: How do you manage your entire portfolio of risks? Link to quality management review.
Selection of tools, and even more importantly, development of tools.
Mechanisms and tools for risk treatment
Improvement strategy for the quality risk management program. How do we know if the program is working as intended?
How to define, select, and train risk owners
How to engage the appropriate stakeholders in the risk process
Too many quality risk management SOPs do not read like process or procedure. They read like a regurgitation of ICH Q9 or the ISO31000 documents. Neither is a good thing. You must go deeper and create an executable process to govern the system.
Investigations of a Dog 