Manage risk mitigation types

April 13th, 2011 Posted by Software Lifecycle Management 0 thoughts on “Manage risk mitigation types”

You can add custom field “Required Mitigation” in order to indicate which mitigations are required for a specific risk:

Risk mitigation types

Click to enlarge

Risk and software requirements traceability

April 12th, 2011 Posted by ISO 14971, Risk Management 0 thoughts on “Risk and software requirements traceability”

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

FMEA Risk management best practice (ISO 14971)

April 5th, 2011 Posted by ISO 14971, Risk Management, Validation and Verification 0 thoughts on “FMEA Risk management best practice (ISO 14971)”

The following process is based on QPack FMEA Risk Management Module.

Phase 1: Risk Assessment – Intended use and safety related characteristics

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.

Click to enlarge

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

Click to enlarge

The outcome of this phase is the risk category (failure mode) as shown here:

Example: Risk category list (failure mode)

Click to enlarge

Phase 2: Hazard Identification

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

Click to enlarge

Click to enlarge

Phase 3: Risk estimation

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)

Click to enlarge

Phase 4: Identify and setup risk control

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.

Click to enlarge

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

Click to enlarge

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

Click to enlarge

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

Click to enlarge

Based on the risk mitigation – setup the new RPN value

Example: Revised RPN is automatically calculated

Click to enlarge

Phase 5: Completeness of risk control

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

Click to enlarge

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

Click to enlarge

Open the related risk of each requirement and change the risk status to “Control Implemented

Example: risk controls are implemented

Click to enlarge

Phase 6: Risk verification

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

Click to enlarge

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)

Click to enlarge

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”

Click to enlarge

Phase 7: Risk management report

Create a filter that retrieves all risk items

Example: risks report

Click to enlarge

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

Click to enlarge

Generate the risk management document and save it as attachment

Example: Generated risk and hazards document

Click to enlarge

Wireless medicine and mobile health

April 4th, 2011 Posted by Software Lifecycle Management 0 thoughts on “Wireless medicine and mobile health”

Some links on this subject:

The wireless future of medicine:

Risk Management, FMEA and ISO 14971

April 3rd, 2011 Posted by ISO 14971, Risk Management 0 thoughts on “Risk Management, FMEA and ISO 14971”

The risk management standard required by medical device manufacturers is ISO 14971.

The ISO14971 talks about risk management plan, risk management file, risk analysis, risk evaluation, risk control, production and post production, verification methods and more.

The FMEA (Failure Mode Effect Analysis) or FMECA (Failure Mode Effect Cause Analysis) is an acceptable risk management application that supports some parts described in ISO 14971.

Safety classification and level of concern

March 15th, 2011 Posted by FDA, Medical Device Directive 93/42/EEC 0 thoughts on “Safety classification and level of concern”

Software safety classification required by the CE (According to IEC 62304) is based on the product type. The classification is 1, 2a, 2b, 3 (major).

The FDA safety classification is called level of concern, and it talks about the potential harm to the patient/user. There is Class I, II, III.

There is a list of questions to ask in order to determine the safety classification, such as “Is the software part of a product with high risk”

The risk management is on system level and is not related to the level of concern

What is FMEA Technic for Risk Management

March 15th, 2011 Posted by ISO 14971, Risk Management 0 thoughts on “What is FMEA Technic for Risk Management”

FMEA – Failure Mode and Effect Analysis


A methodology to identify, quantify, prioritize and evaluate potential failure mode


Failure mode: What could go wrong

Effect analysis: How would it happen, how likely is it to go wrong, how bad would that be


  1. Reduce risk of failure
  2. Ensure failures are detectible
  3. Prevent failure from happening.

Prevention: A way to figure out what can go wrong and what can be done in order to avoid it


Ahead of time or during the project lifecycle when a potential risk is discovered

We do FMEA for procedures that can be risky or costly


Preventing problem is cheaper than cleaning it

Some things are too risky or costly to incur mistakes


Gather all relevant participants from several verticals to give their insight of potential risks

  1. Analyze risks
  2. Define the most critical and include them in the control plan

Define potential failure mode for each Process (can have several failure modes)

  • Cause of failure (Root cause) – what might cause this failure mode
  • Effect of failure (Impact of failure)
  • Current control – what is done today in order to prevent the failure
  • Hazard Score (RPN=Risk Priority Number, is the product of Severity, Occurrence, and detection rating)
    • Occurrence/Probability (how likely to occur) [F]
    • Detection [D]
    • Severity [S]
  • Prevention/Mitigation/Control (recommended actions)
  • Revised RPN – after hazard mitigation

IEC 62304 main processes

March 9th, 2011 Posted by IEC 62304 0 thoughts on “IEC 62304 main processes”

IEC 62304 addresses the following main processes:

  • Software development plan
  • Software development
  • Software requirements analysis
  • Software architectural design
  • Software detailed design
  • Software unit implementation and verification
  • Software integration and integration testing
  • Software system testing
  • Software release
  • Software maintenance
  • Software risk management (refers to ISO 14971)
  • Software configuration management
  • Software problem resolution

Time consuming activities in medical device documents management

March 9th, 2011 Posted by Software Lifecycle Management 0 thoughts on “Time consuming activities in medical device documents management”

Following are activities that consume most of the time in maintenance and preparation of the documents for submission:

  1. Manual Signatures
  2. Traceability maintenance
  3. Document audit trail
  4. Manual management of changes and comments

I will discuss each on my next posts

The challenge of 510(k) De Novo submission decision

March 8th, 2011 Posted by Software Lifecycle Management 0 thoughts on “The challenge of 510(k) De Novo submission decision”

There is a real challenge for a medical device company whether to go for 510 (k) De Novo submission.

First – lets understand some facts :

  • For some historical reason – there is a dependency between risk level (Class I, II and III) and submission required  (510(k)/PMA)
  • For risk level of class I and II – the medical device company is required to be 510(k) cleared
  • For risk level of class III – a PMA submission is required

But what is the case when the product is not based on exisitng product and the risk level is not Class III?

If the company succeeds to prove this claim – a 510(k) De Novo submission is allowed

This submission process expose the comapnies to competition. Once the company is 510(k) De Novo cleared – it means that their product is an existing product…. now the competitors can create a competitive product and submit the 510(k) based on the “existing” company product. Another issue is the efforts need to be invested in order to convince the FDA that the risk level is not class III.

and finally – there is a risk in the exposure of the company IP by the FDA during the risk level re- evaluation process.

Due to these reasons the medical device company sometimes choose to go for the PMA.

Page 16 of 18
1 14 15 16 17 18


8 Tozeret Ha'aretz Street
Tel Aviv, Israel

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use