- Change in design
- Change in process – Protective measures (in medical device itself or manufacturing process)
- Information (such as labeling, user manual)
- Standards and compliance
“A risk management process complying with ISO 14971 shall be performed”.
A dispute we encounter in many organizations.
Can the risk mitigation reduce the severity, or just the probability?
RPN is calculated by Severity * Probability
In some cases, companies use Detectable with is another factor used to calculate the RPN.
Is it relevant just in software risk management?
We will be happy to hear your input
In some occasions, test case is traced to a risk in order to assure mitigation. I believe this traceability used for risk mitigation is wrong.
The correct flow is adding a risk control, and then add traceability from the test case to the risk control (can be software requirement, user manual reference, etc.)
The test case will be used to verify that the control implemented is actually reduce the risk
So the test case is used for verification of the risk control and NOT as risk mitigation.
The Goal is to provide objective evidence that the software meets all the specified requirements
> building the thing right
The Goal is to confirm that the software meets the user needs and intended uses
> building the right thing
You can add custom field “Required Mitigation” in order to indicate which mitigations are required for a specific risk:
Risk mitigation types
I have encountered the following question more than once:
Do we manage traceability from risk to software requirement (saying: this risk is derived from the linked software requirement) or do we link software requirement to risk (saying: this software requireemnt is used as risk control (mitigation) for the linked risk)?
The regulation requires management of the following traceability: Software requirement -> risk
The following process is based on QPack FMEA Risk Management Module.
You can build a risk assessment document in QPack and add the safety related questions.
Example: Add risk assessment document and add safety related questions by category
Set the paragraph to be of type “Safety Question”
The paragraph has a short and simple workflow:
Open – new safety question was added
Estimated – the safety related question was responded by risk object
NA – safety question is not applicable for this product.
Now start identifying risks to your product. Each risk is linked to the safety question so can verify that every question was addressed by risk.
Example: Safety questions traceability
The outcome of this phase is the risk category (failure mode) as shown here:
Example: Risk category list (failure mode)
Setup risk status to “Identify Hazard”
Use QPack to add new risk object.
Setup risk name, and failure mode.
Example: Setup new risk
Risk name: Failure in power supply
Failure mode: Energy Electromagnetic
Cause of failure: Short circuit
Effect of failure: Shock to patient
change risk status to “Estimation”
Use QPack Risk estimation form in order to calculate the RPN
Set the RPN parameters in order to calculate the risk zone (Acceptable/Alarp/ Unacceptable):
Example: Calculate RPN before mitigation
- Probability (P1)
- Detectability (D1)
- Severity (S1)
Change risk status to “Identify Controls”
Identify preventive actions in order to reduce risk severity/probability, or improve detectability.
Example: Risk recommended actions
Risk reduction: Front panel lights will not be off indicating power supply fault.
At this phase, or in later phases, we will setup risk estimated cost, assign to the relevant person and setup due date
Example: Risk cost, due date and assignment
In case a software requirement is used as a recommended actions – add a software requirement in your SRS
Setup requirement “Risk Mitigation” indication to “Yes”
Example: Add software requirement for mitigation
Software requirement: Use the alert mechanism to control warning lights in front panel
Link the software requirement to the relevant risk for mitigation traceability. Use the “Risk Mitigation” link type.
Example: Software requirement is linked to the risk
Based on the risk mitigation – setup the new RPN value
Example: Revised RPN is automatically calculated
Software team will develop the software requirement
Once software requirement is finished, the software requirement status is changed to “Done”
Example: software requirement is implemented
Show a filter of all software requirements that are used for risk mitigation, in status “Done”
Example: report of implemented software requirements used for mitigation
Open the related risk of each requirement and change the risk status to “Control Implemented”
Example: risk controls are implemented
Add a software test case to the STD and link it to the software requirement in the SRS
Example: traceability of test case to software requirement used for mitigation
SQA team execute the tests, and when test passes its status is set to “Pass”
Example: Get all requirements that are used for risk mitigation and trace their verification status (derived from test execution status)
When all tests were passed for the software requirement – open the related risk and change the risk status to “Verified”
Example: risk is set to “Verified”
Create a filter that retrieves all risk items
Example: risks report
Build the risk management document in QPack based on your template and embed the risk report filter in the relevant chapter.
Example: risk management document in QPack
Generate the risk management document and save it as attachment
Example: Generated risk and hazards document