This week, I will outline a step by step approach for performing a risk assessment. Your company probably has a procedure for doing this so you should follow along with that. If your company does not have one, you should write one. Need help? Drop me a line.
Okay, you are developing a system with multiple features. You have a vague idea how the system may or may not impact patient safety, product quality, or data integrity. You may even be able to loosely prioritize your features on a scale of “important” to “not so important”. However, do you know how severe the impact to the patient, product, or data would be if something were to go wrong with your system? Do you know what the chances are that something will go wrong?
These questions are at the heart of risk assessment. What are the chances something will go wrong and how bad would it be if it did?
Step 1: Know your system
Gather up or create your drawings, flow diagrams, User and Functional Requirements, Design Specifications (if you are that far along). Assemble experts. Assemble other smart people who may not be experts but might offer a unique perspective.
Step 2: Impact Assessment
First, you need to know whether validation will be required at all. In simplest terms, if this system were to malfunction, would there be any quality related consequences? If not, then good software development and engineering practices are probably sufficient. If there would be a quality impact, would that be a direct impact or an indirect impact? Answering this question will give you a clue as to how extensive validation will need to be.
Step 3: Identify Risk Scenarios
What could go wrong? There are a number of techniques for doing this. All involve some type of brainstorming. Think about your system (see step 1) and come up with as many ideas regarding what could go wrong as possible. It is important to do this in groups with a good facilitator. The facilitator will make sure that you extract all of the good ideas from the intelligent people in the room. Remember that there is no such thing as a bad idea at this point. Even if something seems highly improbable (e.g. lightening strikes), it is still valuable to write it down and analyze it to some extent.
A well defined risk scenario will state a) what the failure is and b) what the consequence of that failure would be. The consequence should always relate to patient safety, product quality, or data integrity.
Step 4: Assess Probability
This is where you get to de-prioritize the asteroid protection system. While an asteroid impact would be devastating, it is highly unlikely. Using a pre-defined scale, assign a probability of occurrence for each scenario. I like numbers such as a scale of 1 to 10, but you could use high, medium, low; red, yellow, green; good, bad, ugly; or whatever works for you.
Step 5: Assess Severity
Again, use a pre-designed scale to document how bad it would be if it did happen. Forget probability – focus on the consequence if it did happen. This is where the asteroid fans get to talk about how devastating an asteroid impact would be. As with probability, use numbers or words to assign a severity to each scenario.
Step 6: Assign Risk Priority
Combine the Probability and Severity from Steps 4 and 5 to arrive at a risk priority. If you used numbers, multiply; if you used words, use a matrix. However you decide to do it, you will end up with a risk priority for your system or feature. Some risk assessment approaches include probability of detecting an imminent occurrence of an event (e.g. FMECA). This is a bit more sophisticated but takes a bit of explanation. Tune in to a webinar or take a class to learn more.
Hopefully, this recipe will help you measure the risk level of your system and of each feature within the system. Next time I will describe what you can do with this information to scale your validation effort based on risk.