Risk Assessment in Pharma Processing Applications

With the ubiquity of personal computers and mobile devices like smartphones and tablets at an all-time high, nearly everyone has become well-acquainted with the experience of computer glitches. These glitches can range from minor annoyances — like a window closing when you didn’t want it to — to serious problems, such as a program crashing without saving its data or a complete system shutdown. While these issues can be frustrating when they happen on a personal computer, the consequences of a potential controls malfunction when it comes to your pharmaceutical processing application can be far greater.

The costs of process downtime or lost batches as a result of a controls failure can be enormous. Given this, it seems as though repairing aging or obsolete software would be well worth the costs involved– especially when weighed against the risks of operating malfunctioning controls. Even so, software updates can be difficult to justify. For users unfamiliar with computer programming languages, process controls may seem like a virtual “black box;” because they cannot access or otherwise understand the complex code that constitutes a given piece of software, they cannot determine where the problems are occurring and where changes will be made– or if they are even necessary. This makes it complicated to assess which modifications will ultimately be worth the effort and cost of re-validation.

We understand that equipment, applications, controls and process requirements can differ greatly from one user to the next. Depending upon the status of your system’s controls, making modifications to the software can be very costly, and potentially not worth the expense. Our solution is to provide users with risk assessment documentation to evaluate the risks of modification based on the proposed or desired changes to the control software.

Risk assessment is a cost-effective way to determine the best course of action to satisfy your specific software/control requirements. Before making any changes to your software’s code, we first analyze it and generate a risk matrix to identify any potential errors or bugs and evaluate the objective risk. Customers can then use the risk matrix to assess whether or not the risk of repairing any potential problems is greater than the risk of continuing to run the software with them in place.

The risk matrix will also determine:

1. The severity of the bug’s impact.
   Will it cause a window to close, or will it cause the entire system to fail? If the bug’s impact is negligible, modifications to the software may not be worthwhile.
2. The probability of the bug’s occurrence.
   What are the chances that users will experience the bug? If a user never uses a particular feature that causes the bug to occur, no modifications may be necessary.
3. The probability of the bug’s detection.
   Are users likely to notice the bug? If a bug causes a window to close, users are likely to detect it; however, if a bug causes a value to calculate incorrectly, users may not notice it at first.