D6 4 1 Risk Management report 20140228 v4 - Sifem-project · ENT& Ear,&nose,&and&throat& ......

D6.4.1 Risk Management report Version: v4 – Final, Date: 28/02/2014

Project Title: SIFEM Contract No. FP7-‐600933

Project Coordinator: National University of Ireland, Galway www.SIFEM-‐

project.eu

of 41

SIFEM FP7-‐ICT-‐2011-‐9-‐600933

Semantic Infostructure interlinking an open source Finite Element tool and libraries with a model repository for the multi-scale Modelling and 3d

visualization of the inner-ear

Deliverable D6.4.1 Risk Management report

Responsible Partner: Institute of Communications and Computer Systems (ICCS)

Status-‐Version: Final

Date: 28/02/2014

EC Distribution: Public




project.eu

of 41

Project Number: FP7-‐600933

Project Title: SIFEM

Title of Deliverable: Risk Management report

Date of Delivery to the EC: 28/02/2014

Work-‐package responsible for the Deliverable: WP6 – SIFEM Infrastructure Integration

Main Editor(s): ICCS

Contributor(s): ICCS, ISVR, UCL, BioIRC, RTV, INTRASOFT, DERI

Reviewer(s): INTRASOFT

Approved by: All Partners

Abstract: This document constitutes the deliverable D6.4.1 Risk Management report. The objective of this document is to report identified risks and the appropriate contingency plans and mitigation actions. More specifically, this deliverable describes and identifies the (technically caused) hazards associated with each part of the system, estimate and evaluate the risks associated with these hazards, control these risks, and monitor the effectiveness of that control limitations. The description is based on the published protocol and standards in the area of system risk management.

Keyword List: Risk management, hazards, contingency plan, software risks, standards and protocols

Document revision history




project.eu

of 41

Version Date Modifications Introduced

Modified by Modification Reason

1 28/01/2014 ICCS The Table of Contents (ToC) was formed and sent to all partners

2 11/02/2014 INTRASOFT, RTV Contribution form INTRASOFT and RTV

2.1 13/02/2014 ICCS Updated contribution from ICCS and document update

3 25/02/2014 ISVR Contribution and updated risks from ISVR

3.1 26/02/2014 BioIRC Contribution and updated risks from BioIRC

3.2 27/02/2014 ICCS Updated risks form ICCS and consolidated document

3.3 27/02/2014 DERI Contribution from DERI

4 28/02/2014 ICCS Final Version from ICCS




project.eu

of 41

1 GUIDELINES

Overview

The following report denotes the deliverable D6.4.1 Risk Management report.

Prerequisites

D2.1 State of the Art: The research conducted during this deliverable is necessary to identify state of the art inner ear modelling techniques and identify the innovation of SIFEM.

D2.2 User Requirements and Data Availability Analysis: This deliverable recorded the requirements of the SIFEM users and guides activities that are undertaken during Task 2.4 System Architecture and Functional Specifications and reported in this D2.3 SIFEM System Architecture.

D2.3 SIFEM System Architecture: A detailed report providing a thorough description of the hardware and software components of the SIFEM system, together with their functionalities.

D3.1 Delivery of the SIFEM FEM Tool v1: First version of the software for the SIFEM Finite Element Modelling tool, which will integrate open source FE libraries and corresponding tools and service.

D4.1 Quantification of the fluid pathways in the cochlea: Report regarding the quantification of the compliant fluid pathways in the cochlea for the BC inner ear modelling.

Moreover, this deliverable takes into account the outcome of the meetings held up to now.

No Other Prerequisites are needed.

Responsibilities

Each technical partner that has responsibilities in the design and the development of a specific part of the SIFEM should clearly define the major hazards and risk that would be introduced by its software or hardware part. The Technical Manager would be responsible for the circulation of the ToC and final version of the consolidated deliverable.

This deliverable will expand in parallel to the development and research activities of the project and more risks will be identified and recorded in the second version of the deliverable.




project.eu

of 41

Table of Contents

1 GUIDELINES ............................................................................................ 4

2 INTRODUCTION .................................................................................... 14

3 STATE OF THE ART OF RISK MANAGEMENT STANDARDS ..................... 16

4 RISK MANAGEMENT .............................................................................. 18

4.1 Introduction ............................................................................................................ 18

4.2 Risk Management Steps .......................................................................................... 19

5 SOFTWARE RISK MANAGEMENT ........................................................... 23

5.1 Software risk Management ...................................................................................... 23

5.1.1 Semantic Infostructure and Storage Capabilities ............................................... 23

5.1.2 Integrate the Semantic Infostructure stored RDF data with the LOD Cloud ...... 23

5.1.3 FEM models requests via the Search interface .................................................. 24

5.1.4 Incorporation of VPH models ............................................................................. 24

5.1.5 SIFEM facing technology replacement issues .................................................... 24

5.1.6 Semantic Annotation Tool Usage ....................................................................... 24

6 RISK ASSESSMENT ................................................................................ 29

6.1 Introduction ............................................................................................................ 29

6.2 Estimation of Risks .................................................................................................. 29

6.3 Measures ................................................................................................................. 30

6.4 Risk Assessment Steps ............................................................................................. 31

6.5 Risk Categories ........................................................................................................ 32

6.6 Risk Evaluation ........................................................................................................ 33

7 RISK CONTROLS AND EVALUATION OF RISK ACCEPTANCE ................. 34

8 CONCLUSIONS ...................................................................................... 41




project.eu

of 41

List of Figures

Figure 1: Example of assessment of the identified risk according to its probability and severity levels ............................................................................................................................................................ 22

Figure 2: The probability of occurrence vs severity for risks ............................................................... 39




project.eu

of 41

List of Tables

Table 1: The levels of probability and severity ................................................................................... 30

Table 2: Description of abbreviations ................................................................................................. 32




project.eu

of 41

Definitions, acronyms and abbreviations

Acronym Title

Modelling

BM Basilar membrane

TM Tectorial membrane

RM Reissner’s membrane

OHCs Outer hair cells

IHC Inner hair cell

St Stereocilia

C Cortilymph

SV Scala vestibule

ST Scala tympani

SM Scala media

OC Organ of Corti

HC Hensen’s cell

DC Deiter’s cell

RL Reticular lamina

IS Inner sulcus

HS Hensen’s stripe

IP Inner pillar cell

OP Outer pillar cell

Mod Modiulus

BC Bone Conduction

ENT Ear, nose, and throat

OAE Otoacoustic emissions




project.eu

of 41

DPOAE Distortion product otoacoustic emissions

CM Cochlear Microphonics

Other Methods and Processes

FE Finite Element

FEM Finite Element Method

SNHL Sensorineural hearing loss

PTA Percutaneous transluminal angioplasty

TTS Temporary threshold shift

RTAE Requirements and Technology Assessment Exercise

PACS Picture archiving and communication system

DICOM Digital Imaging and Communications in Medicine

2D Two dimensions

3D Three dimensions

Project Management

CB Consortium Board

CCB Change Control Board

CO Confidential, only for members of the consortium (including the Commission Services)

CR Change Request

D Demonstrator

DL Deliverable Leader

DM Dissemination Manager

DMS Document Management System

DoW Description of Work

Dx Deliverable (where x defines the deliverable identification number e.g. D1.1.1)




project.eu

of 41

EC Ethical Committee

EM Exploitation Manager

EU European Union

FM Financial Manager

FP Framework Programme

MS-‐ Microsoft Corporation

MSx project Milestone (where x defines a project milestone e.g. MS3)

Mx Month (where x defines a project month e.g. M10)

O Other

P Prototype

PC Project Coordinator

PM Partner Project Manager

PO Project Officer

PP Restricted to other programme participants (including the Commission Services)

PU Public

QA Quality Assurance

QAP Quality Assurance Plan

QDF Quality Function Deployment

QM Quality Manager

R Report

RE Restricted to a group specified by the consortium (including the Commission Services)

RUP Rational Unified Process

s/w Software

STEP Standard Technology Evaluation Process




project.eu

of 41

STM Scientific and Technical Manager

TL Task Leader

WP Work Package

WPL Work Package Leader

WPS Work Package Structure




project.eu

of 41

Lexicon

Term Description

Basilar Membrane

The basilar membrane within the cochlea of the inner ear is a stiff structural element that separates two liquid-‐filled tubes that run along the coil of the cochlea, the scala media and the scala tympani

Reissner's membrane Reissner's membrane (vestibular membrane, vestibular wall) is a membrane inside the cochlea of the inner ear. It separates scala media from scala vestibuli.

Finite Elements

In mathematics, the finite element method (FEM) is a numerical technique for finding approximate solutions to boundary value problems for differential equations. It uses variational methods (the calculus of variations) to minimize an error function and produce a stable solution

Organ of Corti The organ of Corti, found only in mammals, is part of the cochlea of the inner ear and is provided with hair cells or auditory sensory cells

Scala tympani

Scala tympani is one of the perilymph-‐filled cavities in the cochlear labyrinth of the human ear. It is separated from the scala media by the basilar membrane, and it extends from the round window to the helicotrema, where it continues as scala vestibuli.

Scala vestibuli Scala vestibuli is a perilymph-‐filled cavity inside the cochlea of the inner ear that conducts sound vibrations to the scala media.

internal auditory meatus

The internal auditory meatus (also meatus acusticus internus, internal acoustic meatus, internal auditory canal, internal acoustic canal, or IAC) is a canal in the petrous part of the temporal bone of the skull that carries nerves from inside the skull towards the middle and inner ear, namely cranial nerve VII and cranial nerve VIII. There are two internal auditory meatus in most individuals, one on the left side of the skull and one on the right

Modiolus The modiolus is a conical shaped central axis in the cochlea. It consists of spongy bone and the cochlea turns approximately 2.5 times around it

Bone Conduction Bone conduction is the conduction of sound to the inner ear




project.eu

of 41

through the bones of the skull. Bone conduction transmission can be used with individuals with normal or impaired hearing

Stereocilia

In the inner ear, stereocilia are the mechanosensing organelles of hair cells, which respond to fluid motion in numerous types of animals for various functions, including hearing and balance. They are about 10–50 micrometers in length and share some similar features of microvilli.

Hair cells

Hair cells are the sensory receptors of both the auditory system and the vestibular system in all vertebrates. In mammals, the auditory hair cells are located within the organ of Corti on a thin basilar membrane in the cochlea of the inner ear.




project.eu

of 41

2 INTRODUCTION The following report denotes the draft version of the deliverable D6.4.1 Risk Management report. The deliverable describes and identifies the (technically caused) hazards associated with software development, estimate and evaluate the risks associated with these hazards, control these risks, and monitor the effectiveness of that control limitations. The description is based on the published protocol and standards in the area of system risk management.

The safety of any medical software system is dependent on the application of a disciplined, well-‐defined, risk management process throughout the product life cycle. Hardware, software, human, and environmental interactions must be assessed in terms of intended use, risk, and cost/benefit criteria.

Risk analysis is employed by any medical software company and is responsible for all new and existing medical hardware/software developed. All hardware/software developed must be proven to be safe and efficient core to safe hardware/software is the hazard analysis and risk management process.

This report addresses these issues in SIFEM Platform hardware and software. Risk Analysis identifies the risks and potential obstacles to the future exploitation of a project's results.

The structure of the description of each component follows the ISO standard for risk management reports.

In our approach we used the ISO 149711: “Medical devices -‐ Application of risk management to medical devices” standard. This International Standard was developed specifically for medical device/system manufacturers using established principles of risk management. It could also be used as informative guidance in developing and maintaining a risk management system and process.

Each partner establishes documents and maintains throughout the life-‐cycle an on-‐going process for identifying hazards associated with a medical device, estimating and evaluating the associated risks, controlling these risks, and monitoring the effectiveness of the controls. This process shall include (1) risk analysis, (2) risk evaluation, (3) risk control and (4) production and post-‐production information.

Each partner within the consortium had to follow this specific methodology in order to make a complete risk analysis about the module they had to develop. The results were collected and analyzed and the outcome was a universal risk analysis report.

1 http://www.iso.org/iso/catalogue_detail?csnumber=38193




project.eu

of 41




project.eu

of 41

3 STATE OF THE ART OF RISK MANAGEMENT STANDARDS Healthcare Failure Modes and Effects Analysis2 (HFMEA) has been designed by the VA National Centre for Patient Safety3 (NCPS) specifically for healthcare. HFMEA streamlines the hazard analysis steps found in the traditional Failure Modes and Effects Analysis (FMEA) process by combining the detectability and criticality steps of the traditional FMEA into an algorithm presented as a Decision Tree. It also replaces calculation of the risk priority number (RPN) with a hazard score that is read directly from the Hazard Matrix Table. This table was developed by NCPS specifically for this purpose.

Healthcare FMEA Steps

1. Define the HFMEA Topic -‐ Define the topic of the Healthcare FMEA along with a clear definition of the process to be studied

2. Assemble the Team -‐ The team is to be multidisciplinary including Subject Matter Expert(s) and an advisor

3. Graphically Describe the Process 4. Conduct a Hazard Analysis 5. Actions and Outcome Measures

Root cause analysis4 (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to address, correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is more probable that problem recurrence will be prevented. However, it is recognized that complete prevention of recurrence by one corrective action is not always possible. Conversely, there may be several effective measures (methods) that address the root cause of a problem. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement.

RCA is typically used as a reactive method of identifying event(s) causes, revealing problems and solving them. Analysis is done after an event has occurred. Insights in RCA may make it useful as a pro-‐active method. In that event, RCA can be used to forecast or predict probable events even before they occur. While one follows the other, RCA is a completely separate process to Incident Management.

Root cause analysis is not a single, sharply defined methodology; there are many different tools, processes, and philosophies for performing RCA analysis. However, several very-‐broadly defined approaches or "schools" can be identified by their basic approach or field of origin: safety-‐based, production-‐based, process-‐based, failure-‐based, and systems-‐based.

2 http://www.whaqualitycenter.org/Portals/0/Tools%20to%20Use/Collecting%20Data%20and%20Information/HFMEA%20Steps.pdf 3 http://www.patientsafety.va.gov/ 4 http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1292997/




project.eu

of 41

Context about regulation and standards

The specific need for the creation and the development of such standard is the requirement for a presentation of documentation for the maintenance of quality assurance and manage risk in the area of medical devices.

ISO 9001: 2000 The International Organization for Standardization (ISO) provide the first version of a non-‐industry-‐specific quality system standard (ISO 9001) in the mid 1980s. Its update version ISO 9001:1994 became the leading standard for quality systems worldwide. The draft version of this specific standard includes the ISO 13485: 1996. The main advantage of the final updated version of ISO 13485: 2003 was its harmonization with the medical device regulatory requirements for quality management systems. Additionally, it includes features as continuous improvement and customer satisfaction that were not contained in documentation for the regulation of medical device industry.

ISO 13485: 2003 is an international standard that specifies requirements for a quality management system where an organization needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and regulatory requirements applicable to medical devices and related services. The introduction of the revised ISO 13485 standard in 2003 marked the shift from procedure-‐based to process-‐based quality management systems. Process-‐based standards can be viewed as a continuum of activities, inputs and outputs that become the inputs of the next activity, whereas a procedure-‐based system considers the quality system in parts or separate functions, such as design control, production and process control. A common issue of the ISO 13485: 2003 standard is the initial development to product realization and the quality of the organization assesses and manages risk. A main document that is referred for the risk assessment is ISO 14971: 2007—Medical devices – Application of risk management to medical devices.

ISO 14971: 2007 document is not a simple guidance text including requirements but it includes recommendations that should be followed by the manufactures considering their applicability during the design and the development of the product. Identification and traceability also is an important theme, in terms of product lots or batches, which carry with them supporting identification markings and records throughout the process. The ability to finely tuning is a significant value to any medical device company. Actually this is the main goal of the Risk management process. Its clear role is “process for a manufacturer to identify the hazards associated with medical devices, including in vitro diagnostic medical devices, to estimate and evaluate the associated risks, to control these risks and to monitor the effectiveness of the controls.”

Risk management is a crucial part to effective quality assurance systems because justification for quality system decisions should be documented based on risk. Risk often is evaluated from two perspectives: safety risk and business risk. Safety risks are analyzed based on the class of medical product and the intrinsic risk that it poses. For this component, safety risk can be described as likeliness of resulting in serious injury or death or as causing harm.




project.eu

of 41

4 RISK MANAGEMENT

4.1 INTRODUCTION There are a variety of risk analysis techniques available these days. Each has its strengths and weakness, depending on the needs and practices of the project team. So, selecting the right technique is essential.

All of these techniques involve identifying and prioritizing the risks to the quality of the system under test. Typically, the risks are grouped or organized by major risk categories, such as functionality, performance, security, and so forth. A cross-‐functional team of project stakeholders usually identifies the risks. Rather than rely only on the stakeholders’ opinions and recollections, the analysis should also draw upon historical bug and field failure data from past projects, requirements and design specifications, sales figures, market research, and anecdotal information from customers, competitors, or clients.

In our approach we used the ISO 14971: “Medical devices -‐ Application of risk management to medical devices” standard. This International Standard was developed specifically for medical device/system manufacturers using established principles of risk management. It could also be used as informative guidance in developing and maintaining a risk management system and process.

It deals with processes for managing risks, primarily to the patient, but also to the operator, other persons, other equipment and the environment.

As a general concept, activities in which an individual, organization or government is involved can expose those or other stakeholders to hazards which can cause loss of or damage to something they value. Risk management is a complex subject because each stakeholder places a different value on the probability of harm occurring and its severity.

It is accepted that the concept of risk has two components:

a) The probability of occurrence of harm;

b) The consequences of that harm, that is, how severe it might be.

The concepts of risk management are particularly important in relation to medical devices because of the variety of stakeholders including medical practitioners, the organizations providing health care, governments, industry, patients and members of the public. All stakeholders need to understand that the use of a medical device entails some degree of risk. The acceptability of a risk to a stakeholder is influenced by the components listed above and by the stakeholder’s perception of the risk. Each stakeholder’s perception of the risk can vary greatly depending upon their cultural background, the socio-‐economic and educational background of the society concerned, the actual and perceived state of health of the patient, and many other factors. The way a risk is perceived also takes into account, for example, whether exposure to the hazard seems to be involuntary, avoidable, from a man-‐made source, due to negligence, arising from a poorly understood cause, or directed at a vulnerable group within society. The decision to use a medical device in the context of a particular clinical procedure requires the residual risks to be balanced against the anticipated benefits of the procedure. Such judgments should take into account the intended use, performance and risks associated with the medical device, as well as the risks and benefits associated with the




project.eu

of 41

clinical procedure or the circumstances of use. Some of these judgments can be made only by a qualified medical practitioner with knowledge of the state of health of an individual patient or the patient’s own opinion.

As one of the stakeholders, the manufacturer makes judgments relating to safety of a medical device, including the acceptability of risks, taking into account the generally accepted state of the art, in order to determine the suitability of a medical device to be placed on the market for its intended use. This International Standard specifies a process through which the manufacturer of a medical device can identify hazards associated with a medical device, estimate and evaluate the risks associated with these hazards, control these risks, and monitor the effectiveness of that control.

4.2 RISK MANAGEMENT STEPS Each partner establishes documents and maintains throughout the life-‐cycle an ongoing process for identifying hazards associated with a medical device, estimating and evaluating the associated risks, controlling these risks, and monitoring the effectiveness of the controls. This process shall include the following elements:

• risk analysis

• risk evaluation

• risk control

• production and post-‐production information

A schematic representation of the risk management process is shown in Figure 1. Depending on the specific life-‐cycle phase, individual elements of risk management can have varying emphasis. Also, risk management activities can be performed iteratively or in multiple steps as appropriate to the medical device. Annex B contains a more detailed overview of the steps in the risk management process. Compliance is checked by inspection of appropriate documents.




project.eu

of 41

Figure 1: Risk management process

Each partner within the consortium had to follow this specific methodology in order to make a complete risk analysis about the module they had to develop. The results were collected and analyzed and the outcome was a universal risk analysis report.

The consortium compiled documentation on known and foreseeable hazards associated with the medical device in both normal and fault conditions.

During the risk analysis the factors that should be recorded are:

1. Module within the hazardous situation may occur

2. Function of the module

3. Identification of the hazardous situation

4. What caused the hazard




project.eu

of 41

5. What is expected to be the effect of the hazard

6. Estimation of the probability and severity for the hazard

7. Measures that should be taken

8. Type of measure that manages a hazard

• Safety by Design

• Instructions for Use (Manual)

• Training

• Defect prevention

• Software Testing

• Service Manual

• Label/symbol

• Instructions for Service

The risk management process will be ratified through an iterative cycle of risks identification and evaluation as well as their respective controls. To successfully accomplish this process a horizontal activity has been inserted to the lifecycle of the SIFEM project (Task 6.6 Technical Risk Management) starting from M13 and extended to the rest of the project duration in order to ensure the proper risk identification, analysis and control through each phase of system implementation. The risk management is supported by a risk analysis document, which will be regularly updated following the development process. Each partner estimates and evaluates the associated risks, the respective controls, and monitors the effectiveness of the controls. This process will include the following elements:

• Risk analysis: Identify the risks according to their probability and severity and classify them to three main categories:

o General and administrative project risks

o Technical and scientific related risks

o Exploitation and outreach risks

• Risk evaluation: Risk evaluation determines the quantitative and qualitative values of risk related to a concrete situation or a recognized hazard. Each partner contributes to the risk assessment process by the definition and the identification of the different kind of risks and hazards that might be generated by a specific module of the SIFEM platform. The collection and classification of the risks needs specific description and formulation in a unique matrix for each subsystem/module in order to be feasible their systematic analysis.

The risk, will be considered as low for 1-‐7 (green), medium for 8-‐14 (yellow) and high 15-‐30 (red). The axes (Figure 1) include the severity level and the probability level (for simplicity rating from 1 to 4).




project.eu

of 41

Figure 1: Example of assessment of the identified risk according to its probability and severity

levels

• Risk Control: Specify the contingency plan for each risk and the respective control/action that should be taken to eliminate the severity or probability of risk.

6 6 12 18 24 30

5 5 10 15 20 25

4 4 8 12 16 20

3 3 6 9 12 15

2 2 4 6 8 10

1 1 2 3 4 5

1 2 3 4 5

Prob

ability of O

ccurance (P

)

Severity (S)




project.eu

of 41

5 SOFTWARE RISK MANAGEMENT

5.1 SOFTWARE RISK MANAGEMENT

5.1.1 Semantic Infostructure and Storage Capabilities A basic service offered by the Semantic Infostructure is related to storing image file data (such as micro-‐CT images) as well as RDF data either a) from data extracted from image metadata or b) RDFized FEM models. This fundamental capability is the basis of all tools that are included in SIFEM platform including the Annotator Tool, the Search Tool etc.

A potential risk that exists refers to the ability of the platform to store the increasing number of data, after its long time usage. This in turn refers to the disk space that is required to handle all such data in the pilots’ site. The severity and occurrence of such a case can be quite high, the resolvance however of the issue is straightforward and includes the usage of larger disk space, as well as incorporating compression algorithms.

5.1.2 Integrate the Semantic Infostructure stored RDF data with the LOD Cloud One of the most important services that run in the background is the Linking Component that allows RDF instances included in SIFEM repositories to be integrated with other external resources of public RDF entities that might exist the Linked Open Data cloud. This allows data that are not maintained or curated by people participating in SIFEM, to be brought “closer” to our platform to be used in analysis, help a user extend his understanding for a disease etc.

However useful this process of linking is, it does suffer from various problems that are not manageable by SIFEM developer or pilots. The problem in linking data is a multi-‐faceted one, with the basic aspects being the following:

a) data quality can be rather low, either in terms of the ontologies used, or even the way some ontologies might be used

b) the availability of these data via SPARQL points is not stable, with the HTTP 404 being the norm c) the variation of data existing in such is not large




project.eu

of 41

For all the above reasons, one can understand that the occurrence and severity of this risk can be high. The measure that can be taken for this action is to investigate other more generic and well curated repositories that can be used (such as the case of DBpedia), as well as investigate the possibility of incorporating data from within SIFEM (such as extracted knowledge from partners papers).

5.1.3 FEM models requests via the Search interface Another important feature of the platform regards searching SIFEM related data (either images, RDF FEM models etc). The basis of this capability is the SPARQL query processing that is created via a User Interface that allows a user to graphically request data and receive the results.

One of the main issues that might occur refers to the actual usage of the interface to request data. The user might not be able to handle such a tool to find what s/he needs. We do consider this risk however of low occurrence, since there the interface is created in collaboration with the pilots, as well as there is the intention of creating a manual that will help train the user in the whole platform.

5.1.4 Incorporation of VPH models SIFEM is a project that acknowledges the importance of connecting to the VPH community either by promoting its own software in the VPH Network-‐of-‐Excellence (NoE) Community, or re-‐using tools, data and models. However, apart from contributing our code, the re-‐usability of things from VPH NoE might not be able to perform such a task, as models or data from VPH might not be related to SIFEM. The occurrence and the severity is quite high, however the SIFEM Consortium will try and resolve this by a) aligning our SIFEM Concept Model with other open ontologies that are related to VPH, and b) providing ETL processes that can help convert tools to models in VPH and vice-‐versa.

5.1.5 SIFEM facing technology replacement issues The project incorporates a great number of technologies that are of standard use and are considered to be state-‐of-‐the-‐art in terms of data management, services composition etc. However, there exists a risk of these technologies to be outdated by the end of the project, resulting in a system that a community (such as an open source one) might not be able to extend. The severity and occurrence of such a situation can be rather high, resulting in a project that will not survive the face of time.

Our approach to deal with this problem, is to keep up with the latest technologies as well as making all tools as modular as possible, that minimizing the chances of having large pieces of software becoming obsolete in the future.

5.1.6 Semantic Annotation Tool Usage This tool is responsible for allowing a user to annotate more knowledge to a data entity, thus extending its capabilities to appear in search results. This however, suffers from a problem of mis-‐annotating the data, thus resulting in situations that data appear in search result, when they should not. The severity and occurrence of this can be rather high; however it is believed that it is a manageable situation, with the creation of manuals that will help train the user to avoid such situations.




project.eu

of 41

5.1.7 PREPROCESSING AND MESHING

In pre-‐processing and meshing procedure of inner ear modeling there are several risks that should

be taken into account.

5.1.7.1 Pre – processing

The following risks are identified as significant for the successful inner ear modelling:

1. Complex geometry of the inner ear.

Inner ear is not always macro mechanical model. When only mechanical behavior of the inner ear

and cochlea is considered, the inner ear can be modelled with simplified geometry on one scale. If

active model of the cochlea is modelled then in the model Organ of Corti should be included, which

has several time smaller dimensions then the rest of the inner ear, so multi – scale approach is

necessary.

Figure 2: Inner ear structure (left) and Organ of Corti (right)

Organ of Corti consists of the many, very small and tiny inner hair cells and outer hair cell, which are

responsible for generation of the electrical current through exchange of the potential and

generation of impulses which goes to the brain. As a product of outer hair cells behavior generated

force is applied on basilar membrane, and affects mechanical behavior of the system, as a backward

feedback. For active model complex geometry and multi – scale modelling will be applied.

2. Inappropriate images obtained from CT and micro CT -‐ means images with poor resolution,

which cannot be properly segmented.




project.eu

of 41

More realistic results should be obtained for solving real patient data, model created from CT and

micro CT images. These images can be useful, but it needs to be with appropriate quality,

resolution, so the process of segmentation can be applied with satisfactory accuracy.

Figure 3: Micro CT image with proper resolution for creation of the real model of the cochlea.

Beside resolution, one of the problems in pre – processing of real model is size of the images. Size of

the images should not exceed certain values – model must not be with large number of nodes and

elements, because calculation efforts may be very large. Calculation may take a few days or week,

even parallel computing is applied.

3. Data collected from laboratory tests, animal tests and human tests are not sufficient in

number to produce a quality computational model.

Finite element method used for modelling of the inner ear needs to be verified with enough

number of data obtained from clinical measurement. Without enough number of experimental

results, simulation technique could not be validated.

27

5.1.7.2 Meshing

1. Poor mesh quality on some segments.

In the certain parts of the model, where geometry is complex, tetrahedral mesh may not be correct.

In that case mesh should be checked and corrected manually.

Figure 4: Poor mesh quality in the curved shapes.

5.1.8 FEM SOLVER

Finite element method solver – PAK is used for modelling inner ear. First task in inner ear modelling

is to define appropriate mathematical model – equations which will represent system behavior with

certain correctness. Several approaches were tested in order to obtain the best agreement with

current analytical and experimental results. For mechanical model of the cochlea the best results

were obtained using fluid-‐structure strong coupling, with acoustic equation for modelling behavior

of the fluids in the chambers and Newtonian dynamics for modelling behavior of the basilar

membrane.

By using finite element methods there are several risks that may occur:

1. Convergence

28

One of the biggest issues in finite element method is definition of the convergence criteria. In PAK

solver for convergence criteria is used quotient of Euclidean norm of unknown variable increment

and Euclidean norm of the last known solution, from previous iteration. When this ratio is less that

given tolerance, convergence is achieved. In case of convergence problem, different criteria for

convergence should be implemented.

2. Too many nodes and elements.

Model should not be with large number of nodes and elements, because in that case calculations

will take too long, or will not be possible to perform. Models should not be simply, but they also

should not be with very fine mesh, especially in the areas that do not contribute too much to

solution. Optimal meshing algorithm should be implemented.

3. Implementation of the equations for the active model of the cochlea.

Finite element method software, PAK, should be adapted with equations for electrical model. There

can appear certain difficulties with electro – mechanical coupling or convergence. Then it should be

started from simplified model and then integration to more complex model.

29

6 RISK ASSESSMENT

6.1 INTRODUCTION The Grey – Box Diagrams split the architecture of a system, whose risks are analysed, in smaller blocks. The granularity of the blocks is a subjective decision, here is required to use the common sense and reduce the system architecture in a meaningful number of blocks.

Input and output describe the desired physical interaction that the system has with the environment. Immission and emission are the not desired physical interaction (e.g. disturbances) that the system get and release from and to the environment. For each of this block the possible risks must be analysed. Many of the risk found within one block will be also present in other blocks, or are treated (a measure is adopted) within other blocks, therefore it is meaningful to use references inside the risk table. The Grey-‐Box diagrams appeared in the Appendix I.

6.2 ESTIMATION OF RISKS

As we have already mentioned the concept of risk has two components: probability and severity. This does not mean that the two factors are multiplied to arrive at a risk value. One way to describe risk and to visualize the meaning of the definition could be done by a two-‐dimensional risk chart. Every single risk is given a score for its probability and severity. Once the risks are identified, each risk is assigned a level—a measure of its degree of importance.

The probability of harm should take into consideration the level or extent of exposure. This includes answering the following types of question.

• Does the hazardous situation occur in the absence of a failure?

• Does the hazardous situation occur in a fault condition?

• Does the hazardous situation occur only in a multiple-‐fault condition?

• How likely is it that a hazardous situation will lead to harm?

Table 1 demonstrates the point system we used to describe the levels of probability.

The normal condition of use is defined out of 1000 patients a year with a yearly use of 50 days.

OP

Occurrence probability

Definition Max cases per year

SD

Severity Degree

6 often

≥ 1 out of 100

500 5 catastrophic

5 probable

< 1 out of 100 and ≥ 1 out of 1.000

50 4 very critical

4 sporadic < 1 out of 1.000 and ≥ 1 out of 10.000

5 3 critical

30

3 remote

< 1 out of 10.000 and ≥ 1 out of 100.000

0.5 2 marginal

2 improbable < 1 out of 100.000 and ≥ 1 out of 1.000.000

0.05 1 insignificant

1 unlike < 1 out of 1.000.000

Risk evaluation

Acceptable range

Risk is low compared to the benefits. No action is required to reduce risk

Not acceptable range

Risk is not acceptable. Risk must be reduced to the acceptable range. If not, the benefit over

the risk must be explained.

Table 1: The levels of probability and severity

To categorize the severity of the potential harm, the manufacturer should use descriptors appropriate for the medical device. Estimating the severity of harm requires an understanding of the medical use of the IVD examination results, the analytical performance requirements for each application and the extent to which medical decisions are based on IVD examination results. For this reason, qualified medical input to the risk estimation process is essential. Severity is, in reality, a continuum. However, in practice, the use of a discrete number of severity levels simplifies the analysis. In such cases, the manufacturer decides how many categories are needed and how they are to be defined.

6.3 MEASURES For every risk we use one or more of the following risk control options in the priority order listed:

a) inherent safety by design b) protective measures in the medical device itself or in the manufacturing process c) information for safety

What is most important on measures we take is the following three factors

31

1. Implementation of each risk control measure is verified.

This verification is recorded in the risk management file. The effectiveness of the risk control measures is verified and the results are recorded in the risk management file.

2. Risk/benefit analysis If this evidence does not support the conclusion that the medical benefits outweigh the residual risk, then the risk remains unacceptable. If the medical benefits outweigh the residual risk, then the risk can be accepted.

3. Completeness of risk control The manufacturer shall ensure that the risk(s) from all identified hazardous situations have been considered. The results of this activity shall be recorded in the risk management file.

As we have already indicated risk management procedure contains a step during which measures are taken to eliminate the probability and severity of a risk. The measures are divided in 8 categories:

1. SbD Safety by Design

2. IfU Instructions for Use (Manual)

3. Tra training 4. DP Defect prevention

5. SwT Software Testing

6. SM Service Manual

7. Lbl Label/symbol

8. IfS Instructions for Service

6.4 RISK ASSESSMENT STEPS Risk assessment is a step in a risk management procedure. Risk assessment is the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized hazard. Each partner contributes to the risk assessment process by the definition and the identification of the different kind of risks and hazards that might be generated by the specific module of the SIFEM platform. The collection and classification of the risks needs specific description and formulation in a unique matrix for each subsystem/module in order to be feasible their systematic analysis. The abbreviations that are utilized are reported in Table 2 and the collected matrixes are presented in Appendix.

32

Table 2: Description of abbreviations

Measure description of measure adopted

Standard Regulatory norm that applies

Type (of measure adopted): SbD: Safety by Design

IfU: Instructions for use (user manual)

Tra: Training

DP: Defect prevention

SwT: Software testing

SM: Service Manual

Lbl: Label/Symbol

IfS: Instructions for Service

Decision Yes if applied, No if not applied

Resp. Project partner responsible

Verification Type of document for the verification of the measure

OP Probability that the error occurs: 1 (low) to 6 (high)

SD Severity of the error / risk to users, patients and third parties: 1 (low) to 5 (high)

R Risk

N/A non-‐applicable or not relevant

# cause/effect ID in case refers to same hazard/cause

6.5 RISK CATEGORIES Risk analysis reports from every partner have been gathered and analyzed. Risks were initially separated according to whether they occur in hardware or software of the system. ISO standard 9621 describes the quality attributes found in software, provides a more structured approach and reduces the likelihood of missing some major risk elements. It follows industry-‐standard quality characteristics. In order to group the risks and make a complete report of the total risks we had to somehow group them. For ISO 9126 “quality risks analysis” techniques, one should use the quality characteristics and sub characteristics described in the ISO 9126 system quality standard as the categories for the risk analysis. The six main characteristics of quality are:

• Functionality

• Reliability

33

• Usability

• Efficiency

• Maintainability

• Portability

6.6 RISK EVALUATION The risk evaluation process is the establishment of a qualitative or quantitative relationship between risks and benefits, involving the complex process of determining the significance of the identified hazards and estimated risks to those organisms or people concerned with or affected by them. It is the first step in risk management and is synonymous with risk-‐benefit evaluation. In this stage the range of the risks could be defined as acceptable or not. In the case of the acceptable ranges the risk is low compared to the benefits and thus no actions are required to reduce the risk. On the other way, if the risk is not acceptable, the risk must be reduced to the acceptable range. If not, the benefit over the risk must be explained.

34

7 RISK CONTROLS AND EVALUATION OF RISK ACCEPTANCE

Function Control

# Descript

ion Hazard # Effect

Comment

OP

SD

R # Measur

e Type

Description

OP

SD

R Comment

0 #N/A #N/A

#N/A

0

1 3D Reconstruction

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

1.1

Upload Images from local Hard Disk for reconstruction

Patient Sensitive information is Uploaded

1 Information is uploaded to the SIFEM Infostructure

3 4

-1

2 Anonymize Data

SbD

1 4

1

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0 0

0 #N/A #N/A

#N/A

0

2 3D Visualization

Low Computer Resources

1 The visualization cannot proceed

3 3

-1

3 Utilize the Grid Parallel Processing Infrastructure

SbD 0

1 3

1

0 #N/A #N/A

#N/A

0

3 Semantic Infostructure

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

Semantic Infostructure and Storage Capabilities

Low Computer Resources in terms of disk space

Not enough disk space to add more micro-‐CT images or RDF triples

3 3

-1

7 Provide means of larger disk space as well as data compression

DP 0

1 1

1

0 #N/A #N/A

#N/A

0

Integrate the Semantic Infostructure stored RDF data with the LOD Cloud

Data available in the Linked Open Data cloud are not associated (linked) with produced SIFEM-‐related data

SIFEM Data not well integrated with outside data sources

3 3

-1

4 Incorporate other linked data sets and not from LOD

DP 0

1 1

1

35

A user that is agnostic to the platform requests FEM models via the Search interface

Data are available, but user unable to request them due to not being able to understand the Search Interface

Will not receive the data of interest

1 4

1 1 Train the User

Tra 0

1 4

1

Incorporation of VPH models

Models from VPH NoE might mit be used

VPH Bridging will not proceed as required

3 3

-1

6 Provide means of ETL processes, ontology alignments

DP 0

0

SIFEM facing technology replacement issues

Technologies could be selected that might be outdated till the end of the project

Projects continuity after the end of funding, could be damaged

3 3

-1

5 Keeping up with latest libraries in all technologies

DP 0

1 1

1

User misuses the Semantic Annotation Tool

User has attached not relevant semantic annotations to an RDF entity

RDF entity might appear in search results that is not related too, thus confusing the search user

4 3

-1

1 Train the User

Tra 0

2 1

1

0

4 Inner ear

Modelling

0 #N/A #N/

A #N/A

0

0 #N/A #N/A

#N/A

0

MS4 is due in April 2014 (M14) and its verification is "Deliver a fully functional geometry model of the cochlea after gathering data in WP2, meshing and reconstruction the cochlea

Delay of work in WP3 and WP4

Canot achieve MS4 on time

The definition and meshing of the "full3D model" is not yet complete.

5 4

-1

2 Anonymize Data

SbD

1 1

1

36

from histological data and micro-‐CT images in WP3 and modelling in WP4."

Results from PAK box model are not the same as those from the MATLAB box mdoel

Validity of PAK box model

Affect further validation and use of the PAK box model

Models in PAK and MATABL should generate identical results

5 3

-1

2 Anonymize Data

SbD

1 1

1

Compatibility between the skull model and the coiled cochlear model

Prediction accuracy

Mis-‐matched interface between the skull model and the coiled cochlear model can affact input excitation for the bone conduction simulation

The interior surface of the cochlear cavity in the skull model is meshed in a compatible way as the external surface of the coiled cochlear model

2 4

-1

2

1 1

1

PAK model functions

less user-‐friendly

Canot attract new users

A model should be user-‐friendly and can meet basic research purpose

2 3

1 2

1 2

1

Tasks progress monitor

Tasks delay

delay of milestones or deliveralbes

Monitor tasks progress can help to make sure each task is going in a right direction and can be completed on time

2 4

-1

2

1 1

1

Compatibility of geomtrical models

meshing efficiency and computational cost

Bad geometry will cause problems in meshing

A good geometry should avoid extremely small

5 4

-1

2 Anonymize Data

SbD

2 2

1

37

process or increase computational cost

structures.

0 #N/A #N/A

#N/A

0

the electrical model may not produce meaningful results

Although people have done electrical finite element modelling of the cochlea before, that has been in the context of cochlear implants rather than in the context of coupling of fields generated by hair cells in a cochlea that does not have an implant. Whether the lumped parameter model will apply to the finite element model is not yet known. A reason why it may not relate to the great difference between the size of the hair cells generating the fields,

3 5

-1

#N/A #N/A

#N/A

3 5

-1

38

and the cochlea structures through which the fields propagate.

0 #N/A #N/A

#N/A

0

3 Complex geometry

Inappropriate model

Calculation can not be performed

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

4 Size of the model

Too fine mesh, large number of nodes and elements


0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

5 Insufficiently clinical data

Difficulties in measuring

FEM model can not be verified

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

6 Poor mesh quality

Required manual correction of the mesh


0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/ #N/A

0

39

A

0 #N/A #N/

A #N/A

0

7 Convergence

Inappropriate criteria


0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

8 Electrical model in FEM

Difficulties for implementation

Lack of validation of the model

0 #N/A #N/A

#N/A

0

0 #N/A #N/A

#N/A

0

A way of applying acceptability criteria is by indicating in a matrix which combinations of probability of harm and severity of harm are acceptable or unacceptable. Such charts are usually specific to a product and its particular intended use. This matrix shows the number of hazards corresponding in each category. The horizontal axis indicates the level of severity from 1 to 5, while the vertical axis indicates the level of probability from 1 to 6. The green part indicates acceptable levels of risk while the red part indicates a hazardous situation for which measures are mandatory.

After merging the risks the outcome was really satisfying. We calculated a total of 14 risks. Below we can see 2 tables that demonstrate the risks.

Figure 5: The probability of occurrence vs severity for risks

Further analysis of the merged risks by category gives us a better picture of the risks that may occur in the system.

40

Modification of performance In the risk management procedure a further step is to re-‐calculate the probability and severity of a risk so a new table is created that shows these values after the measures have been taken.

41

8 CONCLUSIONS Risk analysis is a procedure that has many benefits for any system. The incredible wealth of information that risk analysis provides about the identified risk. Of course, is a cost-‐effective and a more in-‐depth, numerical approach to analyzing risk, which is something performed on risk to have a substantial impact on the project objectives. The additional information that risk analysis provides arms you with what you need to deal with them in the best way possible. And as one could imagine, risk analysis, as a result of the information we have obtained, increases the confidence level of controlling and dealing with risk. The risk management team is able to develop better decisions, more effective responses, as well as justify responses and recommendations made. Risk analysis involves looking at future impacts and decision-‐making. On that note, it allows us to control risk with greater success. SIFEM platform will be making much more informed and educated recommendations and responses. This increases the level of success that the risk response plan will have. Risk analysis helps to determine alternatives, if available, and notice that much of this provides supportive information. It is like having a little window to a risk that allows you to peek inside and shows you how the risk comes about and the damage or the opportunity that it can result it. Something else that should be mentioned is that risk deals heavily with uncertainty. Risk analysis aims at lessening this level of uncertainty by clarifying the impact and the potential outcomes. We can put together what seems like a solid schedule but there are always looming internal and external factors that can destroy our plans. Risk analysis is meant to help us foresee what could happen and prepare to deal with those scenarios. In conclusion risk analysis plays a central part of risk management. After the assessment and evaluation of the risks and the application of each measure the majority of the risk for software development, processes and user interaction were considered as acceptable. As for the conclusion we should notice that through the risk management process a researcher or a clinician has the opportunity to revise and identify the large majority of the risks and the hazards that exists with the inner ear modeling as well as the interaction with the SIFEM system. Although SIFEM platform is not a life-‐threatening system that might harm patients in a high degree or to become dangerous for his life, the risk management process is the essential process that aims at the improvement of the quality of the platform increasing its overall reliability.

D6 4 1 Risk Management report 20140228 v4 - Sifem-project · ENT& Ear,&nose,&and&throat& ......

Documents

Transcript of D6 4 1 Risk Management report 20140228 v4 - Sifem-project · ENT& Ear,&nose,&and&throat& ......