SPK’s Vice President of Engineering, Carlos Almeida presents an out of the box demo of the PTC Integrity Risk Management software.
Transcript:
Hi, this is Carlos Almeida from SPK and Associates. This video is created to demo the out of the box risk management integrity solution. I’ve imported the risk and analyst view set. And I’ve populated a project called demo with a hazard analysis document, a bunch of risk analysis documents, and some risk control documents, and also put together a functional spec, in terms of the DI. So, before we begin, let’s look at some basic concepts. The diagram here on the right is taken from the ISO risk management for medical devices standard, and it talks about the different phases of risk management. The areas highlighted in red are the areas that integrity directly supports.
So, let’s go through this. The first box is risk analysis. The steps here are to first identify the intended use and the characteristics related to the safety of the medical device. Once we’ve scoped the purpose of that device and its intended use, then we have to identify the hazards for the medical device. And the hazards are an abstract view on the risk for the end user patient.
So, an example of a hazard might be if it’s an infusion pump, over-medication, or overdosing the patient. We’re not identifying the root cause of that hazard or its potential risk which contribute to the hazard. We’re just saying there is a hazard. So, the patient is going to receive too much medication and we describe the outcome of that hazard in terms of things like a coma or death or minor organ damage. So, once we’ve identified the hazard we have to break those hazards down into individual risks. We have to look at the hazardous situations and estimate those risks. This is where we would identify all the sources of the hazard, what ways a user can overdose.
One risk might be that if you gave the patient control to ramp up the amount of medicine being delivered and there’s not enough feedback mechanisms to the user to indicate maybe they’re overmedicating themselves. So, the estimation of those risks are all about identifying the severity of that risk and the probability of occurrence. So, this is one key distinction between the top-down approach to risk management and how some companies are doing FMEA from bottom-up. FMEAL often talks about severity occurs and the detection of probability of detecting a problem or detecting the risk. The top-down approach doesn’t care about detect-ability. It assumes the end user has no ability to detect there’s a problem because you never know what kind of state the patient is in. If they’re in the emergency room or they’re unconscious, their ability to detect risk is pretty low. So, you can’t make any assumption about detect ability. So, severity and occurrence are two ways that we classify or categorize risk. Then we evaluate whether that risk is acceptable, unacceptable or needs investigation.
There’s no specific guideline on what type of severity or occurrence equates to acceptable or unacceptable. It’s up to the device manufacturer up front in start of the lifecycle of that product to define what the criteria is. To define what they mean by severity, what they mean by occurrence and what combinations of that fall into acceptable, unacceptable or needing investigation. So, once we’ve evaluated the risk and determined whether it is acceptable or unacceptable, those unacceptable risks, or risks needing further investigation need to be controlled. So, we do an option analysis on risk control. This box here – we need to identify whether to control that risk through a control measure. That is inherent safety by design, meaning we’re actually changing the product design in order to reduce or eliminate that risk. A protective measure, putting some sort of change in place. As an example there is a surface of some medical device that maybe is ungrounded, that causes electrical shock. Maybe we need to put some sort of encasement around it so the user can’t touch it. Inherent by design would be finding the source of that shock and fixing it, so it’s also different in a protective measure.
And then if you measure for safety, that’s where you get into labeling packaging, warnings for the user. It doesn’t really prevent the risk from occurring. It’s simply education. So, the idea is you’re supposed to evaluate the weight of risk and choose your option in that priority. You should first identify if it is possible to resolve that risk through safety by design. If not, it’s not cost effective or appropriate, then you should consider protective measure. And then failing that information for safety is a catchall in the end. Once you’ve implemented risk control, you need to do a residual risk evaluation. You need to reevaluate the severity in occurrence now that you’ve implemented control measures to see if you reduce it sufficiently. It may be that the protective measure only covers certain circumstances and that there is more work to do. So, that’s what the residual evaluation is for. And also any risk that we do implement control measures for, they need to go back through the cycle to see if we’ve introduced any new risk.
And then the last two are mostly reporting, evaluating overall risk acceptability. So across a product, how much residual risk is left in the product, documenting any reasons or justification as to why you’re going to leave it as is. So, the FDA doesn’t say you have to completely eliminate all risks to your product. The FDA just says if you don’t, you have to justify and provide documentation. That’s really the FDA’s decision whether to approve that product or not, based on that residual risk. And the final output is just a report that you file away and be able to produce for the FDA if they ever ask for it… that report also has signatures. So, how does risk management work inside integrity?
Integrity satisfies that by three documents domains. One for hazard analysis, which consists of a hazard item. One for risk, which is a risk item. And then a control measure, which contains a control measure item. The relationships between that of a hazard is a cause by a risk, which is then mitigated by a control measure and then implemented by requirement or design specification. That’s an optional, if it isn’t inherent a safety by design, both of these can be verified or validated by a test case. So, let’s start off by looking at an infusion pump. I have imported a bunch of data here for infusion pumps. Infusion pumps are notorious for issues, etc. and so let’s open that up. So the hazardous document identifies the potential hazards that this product presents. Here are some examples of abstract high level hazards.
We have overdose, maybe under-dose, your energetic thermal energy of the device runs too hot. We have chemical and biological. With the hazard analysis, what the ISO standard asks you to do is to enumerate your hazards. So, for each hazard you identify the foreseeable sequence of events. So, if we’re saying this is an overdose, the foreseeable events are: improper measurements or incorrect algorithmic functions or a superfluous amount of drug dispensed. The hazardous situation that occurs is overdose. The user receives more drug than required to maintain desirable levels. The harm that occurs, or causes, is minor organ damage, decreased consciousness, coma or death. Once you enumerate all the hazards, then you need to identify all the risks for those hazards. Let me close that up. Okay, let me look at my risk. So, we have operational risks, software risks, hardware risks, electrical risks, biochemical risks for the infusion pump, and also risk analysis for the multi-parameter bedside monitor. Why don’t we open up the software.
The goal is to have a complete list of risks for each hazard. So, this is what a risk document looks like. You’ll notice that in the hazard and risk analysis document view, I collapse the outline view on the left, because often these are pretty flat documents and customers are usually accustomed to using Excel to store all this information. The problem with Excel is that trace-ability links are pretty hard to maintain. So, within the risk document we describe the risk. Risk is much more of a technical view on a hazard. It decomposes a hazard into all the potential and more technical risks that can occur. We note what causes these risks and what defect can be. Then we categorized the risk by severity. How critical is that risk and the probability of occurrence. So, the values that are used in severity and occurrence are configurable.
The ISO standard does not make any recommendation in terms of what those should be labeled or how many picked values there should be. It can be three by three, five by five, ten by ten. It doesn’t matter as long as you define it and you adhere to that process. We’ve seen some customers just pick three values. Here we’ve implemented a five by five and some customers will also change the labels on occurrence for them to be more quantitative. They may say improbable is .001 in 1,000 units or frequent might be 10 in 1,000 units. So, there’s many different ways to express severity and occurrence. What’s really important here is really this third computed field, which is a combination severity and occurrence. And whether that is acceptable, unacceptable or needing a further investigation. We store them in a computation. Every company may define their acceptable level of risk differently, based on the intended use of their product, based on the geography they are selling to. The FDA allows them to be pretty flexible as long as you define it before you start.
What you’ll find is that acceptable risk typically means no further action is required. Unacceptable means you need to reduce or eliminate that risk through a control measure. Investigate means you need to do the ISO term is ALARP, as low as reasonably possible. They don’t quantify what reasonably or reasonably possible means. So, the final report you’ll produce from this is that you document and export all this information at a table and then in that table you would highlight the justification as to why it has not been reduced further. We’ve identified hazards, we’ve identified risks. Now, the real key is to do that trace-ability. So, now let’s go look back at the hazard document and then let’s look down at the traces. Okay, let me close this guy. Go to my hazards document, and I’m going to do content, relationships, downstream traces. Okay, so let’s look at this hazards for infusion pump, for a particular hazard overdose.
Here are all the example risks that we’ve enumerated in our sample data that contribute to an overdose. The point of this trace diagram is as a risk analyst, or risk engineer, you can easily look at all these hazards for this product, find the risks and see what its risk level is. If it is unacceptable or investigate, then the idea is you need to create a risk control measure. Let’s go back to my risk control document. Again we’ve implemented a document domain called risk control where we’ve placed all that information in there. Let me close this trace out and we’ll go over here to my risk control. All right. So, we have the concept of a risk control document. Every product should have a risk control document. And so in the risk control document, we are going to identify what action we are taking to reduce that risk described in a text field here. We’ll also identify the residual severity and residual occurrence and based on this particular control measure. So, the idea is that we’re implementing this control measure to reduce the minor severity and minor occurrence.
Thereby they become acceptable or remote occurrence. So, we have a category to distinguish each type of control measure we have implemented. So, if I bring this down the inherent safety by design, protective measure, or information for safety. Okay, so let’s take a look at the trace over here. Close this off. And we’ll go back to our hazards document. Downstream traces. Okay, so let’s take a look at free flow. And here we’ve placed this requirement with this inherent safety by design is now acceptable. So we’ve been able to mitigate that to an acceptable level. So, with this trace report here, we can easily see what areas are acceptable now, mitigated as well as those are unacceptable, it requires further work. So one of the example reports that we can run from this out of the box is our risk analysis report.
So here I’ve run a risk analysis report and it’s walking the tree from hazard all the way down to the risk. The control measure and back to the implemented by requirement to take care of this. And up on top we can see the various columns that are available for us. Also what we have available is the use of our dashboard. Close this up. So here I’ve put together different charts that are specific to risk management. I can show all my hazard documents, the ones I own, my risk analysis ones, my risk controls. And then we can chart it. And furthermore, these are live charts, so I can click into here and see what my unmitigated risks are. This is customizable. So essentially what you would need to give to us is what you want to see, these are simply queries here. And how you want the data represented. That completes the risk management demo for out of the box, thank you.
