Fulltext01 PDF
Fulltext01 PDF
Fulltext01 PDF
Abstract
During this project, the risk management of a medical device under devel-
opment that deals with drug administration has been done. The aim of the
project is to evaluate if part of the device is safe according to the current reg-
ulations in Sweden.
The complexity of the risk management processes, particularly in health-
care, together with the lack of standardised methods to develop these kind of
processes leads to a need of new tools to reduce the time, resources and com-
plexity in this stage of the development. That is why two tools have been used
and tested in order to assess the suitability under medical device development
regulation conditions: the Hazard Ontology (HO) and a Fault Injection Sys-
tem (FIS). HO is a novel tool used to identify all hazards and threads from a
predefined system in a structured way. On the other hand, FIS is a testing tech-
nique that aims to help with the study of systems when they are under faulty
conditions.
To ensure that the current regulations in Sweden regarding medical device
are fulfilled, the EN ISO 14971 has been used as a guide for the methods
applied during the work.
The results of the project are exposed for every step of the process. At the
end, the main result of the risk management process is a list of the mitigation
measures that must be included as safety specifications of the device.
Both tools, HO and the FIS, have proofed to be suitable with the current
regulations as well as being useful for the process. HO gave as output a list of
the main hazards of the system and the FIS have been used in the verification
step of the mitigation measures. Three mitigation measures to test with the
FIS has been chosen. They deal with faults regarding a speed sensor, a poten-
tiometer and the PWM signal controlling the motor. The mitigation measures
have been verified for both PWM signal and the potentiometer faults. How-
ever, a faulty condition that leads to an unsafe behaviour has been found for
the speed sensor.
Therefore, we demonstrated that the medical system under study has still
many control measures to implement, verify or improve before it can be said
that it is a safe medical device.
iv
Sammanfattning
Under detta projekt, har en riskhantering av medicinsk utrustning som han-
terar läkemedel gjorts. Målet med projektet är att utvärdera om utrustningen
är säker enligt de svenska bestämmelserna.
Komplexiteten med riskhanteringsprocessen, speciellt inom sjukvård, till-
sammans med brist på standardiserade metoder för utveckling av dessa typer
av processer leder till behov av nya verktyg för att minska tiden, resurserna och
komplexiteten i detta skede av utvecklingen. Det är därför två verktyg som har
använts och testats för att bedöma lämpligheten under de bestämmelserna för
medicinsk utrustnings utvecklingsförhållande: Riskontologin (HO) och felin-
jektionssystem (FIS). HO är en ny metod som används för att identifiera alla
faror och hot för ett identifierat system på ett strukturerat sätt. Å andra sidan är
FIS en testteknik vars syfte är att hjälpa att studera systemet när det är under
felaktiga förhållande.
För att försäkra sig att de svenska bestämmelserna rörande medicinsk ut-
rustning är uppfyllda, har EN ISO 1497 använts som en guide för de metoder
som applicerats under projektet.
Resultatet av projektet är synligt för varje steg av processen. Till slut, är
det huvudsakliga resultatet av riskhanteringsprocessen en lista av de mildran-
de åtgärder som måste vara inkluderade som säkerhetsspecifikation av utrust-
ningen.
Båda verktyg, HO och FIS, har visat sig vara lämpliga med nuvarande be-
stämmelser och användbara för processen. HO gav oss, som data en lista med
de huvudsakliga farorna av systemet och FIS användes i verifieringssteget av
de mildrande åtgärder. Tre begränsningsåtgärder att testa med FIS har valts.
De åtgärdar de fel för hastighetssensor, en potentiometer och PWM signalen
som driver motorn. De begränsningsåtgärderna har verifierats för både PWM-
signalen och potentiometerfelen. Emellertid har ett felaktigt tillstånd som leder
till ett osäkert beteende hittats.
Därmed visade vi att det medicinska system som studeras fortfarande har
många kontrollåtgärder för att genomföra, kontrollera eller förbättra Innan det
kan sägas att det är en säker medicinteknisk produkt.
Contents
1 Introduction 1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 HEALTH 5G project . . . . . . . . . . . . . . . . . . 3
1.3.2 AMASS project . . . . . . . . . . . . . . . . . . . . . 3
1.4 Report structure . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background 5
2.1 Drug therapy . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Drug therapy misuse: non-adherence and abuse . . . . 6
2.1.2 Dose personalisation . . . . . . . . . . . . . . . . . . 10
2.1.3 The medical device solution . . . . . . . . . . . . . . 11
2.2 Safety and security . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 State-of-the-art: Combined development life cycle for
safety and security . . . . . . . . . . . . . . . . . . . 13
2.3 Contribution to the project . . . . . . . . . . . . . . . . . . . 16
2.3.1 Medical device simplification . . . . . . . . . . . . . 16
2.3.2 Development lifecycle simplification - Risk Manage-
ment . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Methods 18
3.1 ISO 14971 - Risk Management of Medical Devices . . . . . . 18
3.1.1 Risk analysis . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Risk evaluation . . . . . . . . . . . . . . . . . . . . . 24
3.1.3 Risk control . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.4 Evaluation of residual risk . . . . . . . . . . . . . . . 26
3.1.5 Production and post-production information . . . . . . 26
v
vi CONTENTS
4 Results 30
4.1 Risk Management - Safety specification for the device . . . . . 30
4.1.1 Risk analysis . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2 Risk evaluation . . . . . . . . . . . . . . . . . . . . . 33
4.1.3 Risk control . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Testing of mitigation measures . . . . . . . . . . . . . . . . . 35
4.2.1 Design of the Fault Injection System . . . . . . . . . . 35
4.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 40
Bibliography 50
List of Figures
vii
viii LIST OF FIGURES
4.5 Front view of the Fault Injection System. Front panel with
main control components on the top of the picture and motor,
encoder and electronic circuits inside the box. . . . . . . . . . 39
4.6 Inside view of the Fault Injection System. There is the DC-
motor on the left, the encoder system in the middle and part
of the electronic circuits in the top of the picture. . . . . . . . 39
4.7 Velocity variance in rpm of the motor when no failure is injected. 40
4.8 Velocity variance in rpm of the motor when speed sensor fail-
ure is injected after approximately 4.2 seconds from the start. . 41
4.9 Velocity variance in rpm of the motor when speed sensor fail-
ure is injected from the very beginning. . . . . . . . . . . . . 42
4.10 Velocity variance in rpm of the motor when potentiometer fail-
ure is injected after approximately 6.5 seconds from the start. . 43
4.11 Velocity variance in rpm of the motor when PWM signal fail-
ure is injected after approximately 8 seconds from the start. . . 43
List of Tables
ix
Chapter 1
Introduction
1.1 Overview
Drug therapy, or pharmacotherapy, is a broadly used term to define the use
of medication to treat a specific disease. While drugs can be categorized ac-
cording to many parameters, all of them have several related problems such as
non-adherence, interaction between medications, lack of efficacy, treatment
duplication and inappropriate drug prescription. Despite the existence in the
market of medical devices dealing with these kind of issues, they have been
proofed insufficient or inefficient. Additionally, patients tend to underestimate
the importance of strictly following the prescription as well as overestimate
their adherence to the treatments [1, 2].
The goal of the master thesis project is to collaborate in a real world en-
vironment project through the development of a medical device dealing with
these problems: the OnDosis medical device. Since it is a project involving a
lot of resources and a high complexity, the specific contribution had to be well
delimited in order to fit in the expectations of a master thesis project.
As all of the medical devices, it is considered a safety-critical system. In
other words, it is a system whose failure may lead to a major consequence
for people, the equipment and/or the environment. Therefore, it is of foremost
importance to be sure that these systems are safe, efficient and reliable. During
this thesis, a risk analysis of the medical device is performed as part of the
safety analysis. In addition, two innovative tools will be evaluated in order
to see if they are suitable tools for risk management according to the current
regulations in Sweden.
1
2 CHAPTER 1. INTRODUCTION
During the process of answering the main research question, other ques-
tions will be answered that will help to follow an appropriate direction during
the master thesis development:
1.3 Framework
The implementation of the project has been carried out within the facilities
of Alten Sweden AB which is an engineering and technological consultancy
with a lot of experience in medical technology. Therefore, it has been done
under direct contact with experts that hold a huge experience in similar projects
that contributed with a wide variety of resources such as technical, material
and human. During the process, the project has been supervised and guided
by the Royal Institute of Technology (KTH) in Stockholm.
The master thesis project is framed in two different larger European re-
search projects where the company collaborates: Health 5G and AMASS.
CHAPTER 1. INTRODUCTION 3
• Chapter 3, Methods: State and explains the decisions made with regards
to the implementation of the project.
• Chapter 4, Results: Presents the results from the work stated in Meth-
ods.
Background
5
6 CHAPTER 2. BACKGROUND
their own adherence to the treatments [2]. The abuse problem is mostly related
to those medication treatments with addictive drugs. And, finally, the dosage
personalisation affects to most of the patients receiving treatment since the op-
timal dosage hardly ever matches the available in the market when it comes to
pill medication.
Impact
As it can be easily deduced, both non-adherence, non-persistence and abuse
have a great impact on the patient therapy. Specifically, non-adherence and
lack of persistence lead to an increase in mortality and morbidity from a large
variety of diseases and, moreover, to an increase of the healthcare cost of the
patients [10].
Regarding the economic impact of non-adherence. While it has been widely
proved that non-adherence is highly correlated with a cost increase for the
healthcare system, it is important to take into consideration each case sepa-
rately. For instance, the overall expenses related to medication non-adherence
is approximately of US$100 billion in the USA, US$1.5 billion in Europe and
US$7 billion in Australia [11][economic impact] .
Risk factors
Like all the medical conditions, these drug related problems have some risk
factors that make easier to identify the group of patients with highest probabil-
ity to undergo non-adherence or abuse of medication. Physicians use the risk
group to prevent patients to experience the problems through some interven-
tions to promote adherence and avoid abuse. According to recent literature
regarding the main predictors and risk factors for non-adherence to medical
treatment they can be sorted in patient factors, prescriber factors, shared fac-
tors and system factors [2, 1, 12]. Patient factors are the ones related to features
that belong to the patient and that cannot be changed by any of the healthcare
actors such as age and disease. Prescriber factors are related to the prescriber
side of the therapy. For instance, poly-pharmacy and the complexity of the
treatment. The shared factors concern issues such as lack of trust from the
patient and bad communication. Finally there are system factors that can be
as important as the other. Clear examples can be found at the healthcare ac-
cessibility and drug costs.
8 CHAPTER 2. BACKGROUND
Direct measures
Directly observed therapy Best accuracy Unfeasible in most situations
Measurement of biologic marker Objective Expensive, not always accurate
Indirect measures
Highly subjective and possible
Patient self-report Inexpensive, easiest to implement
errors
Objective, quantifiable, easy Highly subjective and possible
Pill counts
to implement errors
Not directly related to medication
Rates of prescription refills Objective, easy to obtain intake, closed pharmacy system
required
Measurement of physiologic Markers may vary due to other
Easy to implement
markers reasons
Electronic medication
High precision, time monitoring Expensive, not easy to implement
monitoring systems
Table 2.1: Current strategies and solutions for measuring adherence to medi-
cation
• Monitoring: it will have a communication system that will let the health-
care system to know in real time if the patient is complying with the
prescribed treatment. It will be more objective than most of the current
monitoring techniques and it will help the doctors to understand the level
of adherence of patients.
Figure 2.1: Safety and Security development lifecycle. Figure from [21]
16 CHAPTER 2. BACKGROUND
Additionally, the master thesis project covers part of the "Design" group of
activities. Specifically, the output from the previous activities is used to define
the control measures that are part of the safety and security specifications.
Finally, these control measures are verified as stated in the scaling-up shown
in figure 2.3.
Figure 2.2: Scaling-up from the figure 2.2. It defines the scope of the mas-
ter thesis according to the State-of-art defined in the section 2.2.4. Picture
exctracted from [21].
Chapter 3
Methods
As stated in the previous chapters, the main goal of this thesis is to answer
the defined research questions. In order to do that, the following methods were
defined according to the goal of the project and the delimitation present during
the research.
As one of the main requirements was to conform the current regulations
in Sweden, all the methods are closely related to one of the main standards
dealing with the safety of medical devices, specifically the risk management.
That is, the "EN ISO 14971 - Risk Management for Medical Devices" [18].
Doing that, we are sure that the answer to the main research question complies
with the most demanding regulations of the sector and, hence, it is a valid
answer for our purposes.
Moreover, it will help us to discern if the novel tools under study applied
during the research are suitable to the current regulations for medical devices
in Sweden. Therefore, the secondary research questions will be answered ac-
cordingly.
18
CHAPTER 3. METHODS 19
• Residual risk: risk remaining after risk control measures have been
taken.
Figure 3.1: Risk management process. Scheme of the main phases and main
activities. Adaptation from [18]
Hazard identification
Regarding hazard identification, there is some guidance defined in the stan-
dard. Nevertheless, the guidelines are only recommendations and it is up to
the organization to choose the methodology for this step. The main techniques
recommended are Preliminary Hazard Analysis (PHA), Fault Tree Analysis
CHAPTER 3. METHODS 21
(FTA), Failure Mode and Effects Analysis (FMEA) and Hazard and Operabil-
ity Study (HAZOP). PHA is used early in the development process to identify
the hazards and events that can induce to a harm. FTA is used for the iden-
tification and prioritization of hazards and for analysing their adverse events.
FMEA is commonly used in more advanced stages of the design and it deals
with identifying an effect or consequences of individual components. Finally,
HAZOP are useful to verify and optimize design concepts or changes. There-
fore, they are used in latter stages of the development.
However, as explained in the introduction and background, a novel tool
will be applied to identify the hazards that will be then analysed during the risk
management process. This tool is an Ontological Approach to Safety Analy-
sis of Safety-Critical Systems [23]. This technique, named Hazard Ontology
(HO), was developed by Jiale Zhou at Mälardalen University Sweden in 2017.
The main motivation for developing such a tool was that the current practice
applied in early stages of safety analysis lacked a common standardised ap-
proach. Therefore, in most of the cases, the identification of hazards and their
causes are identified in accordance to the intuition and experience of the an-
alysts. The HO solution propose an ontological interpretation of the hazard
concept, an approach to identify hazards in early stages of development, an
approach to identify the causes of certain hazards and an heuristic approach to
safety requirements elicitation. All the steps from the HO used in this project
are defined in the section 3.2 below. After applying this tool, we will have a
list of the main risks of the system.
Risk estimation
As explained in the beginning of the section, a risk is the combination of
both the probability of the hazard and the severity of the corresponding harm.
Hence, the risk estimation step is defined in the standard as the process used
to assign values to the probability of occurrence of harm and the severity of
that harm.
Several methods can suffice to estimate risks. Even though the Interna-
tional Standard does not need a specific method to be used for this step, it
requires that risk estimation is considered. Quantitative methods are prefer-
able when proper data are available. However, qualitative methods can suffice
when no suitable data is available.
Regarding the probability estimation, some advice is given in the docu-
mentation. For instance, a list of the most recommended approaches. The
list consists of prediction of probabilities using analytical or simulation tech-
22 CHAPTER 3. METHODS
Figure 3.2: Scheme representing the definition of risk of a hazard with regards
to probability and severity. Extracted from [18].
Figure 3.3: Table showing the definition for each level of probability and sever-
ity used during the project. Extracted from [18].
A 3x3 risk matrix is then produced using the probability as rows and the
severity of the harm as columns. Then, the risks found in the previous step
(R1, R2, R3,...) are sorted into different kind of risk correlated to the level of
severity and probability assigned.
An example of a potential result is shown in figure 3.4.
Figure 3.4: Table showing the final result of the risk estimation step. The risks
found in the risk identification step are sorted according to their corresponding
level of severity and probability. Extracted from [18].
24 CHAPTER 3. METHODS
Figure 3.5: Table presenting the expected results after risk evaluation step.
Risks sorted according to probability and severity and the threshold defining
which risks are acceptable (white cells) and which ones are unacceptable (gray
cells). Extracted from [18].
CHAPTER 3. METHODS 25
When some of the above situations occur, the information should be fed
as input of a new iteration in the risk management process. Therefore, new
changes in the design or other control measures can be implemented during
the post-production stage.
A good example to see the difference between kind and role is the situation
of being a "person" and a "pilot". A person is necessarily a person during all
the existence. However, a pilot stops being a driver when he/she leaves the
plane. Therefore, "person" is a kind object and "pilot" is a role object that
can be played by the person. On the other hand, if we consider "plane" as
another kind and "being piloted" as a role that it plays, then "piloting" can be
considered the relator connecting them.
2. For each kind achieved in 1), identify all roles it can play.
3. For each role from 1), identify the relator that connect this role with all
the other suitable roles.
4. For each role obtained in 1), 2) and 3), identify all kind that can play
this role.
2. Select the kind objects playing that mishap victim role, the relator con-
nected to the chosen victim and the roles connected to that relator. Ev-
erything, taken into account the system described in 3.2.1.
4. For each Hazard Element from 3), identify the kind elements that can
play it. It will be identified as environmental object.
5. Finally, select the next victim until all of them are analysed and go back
to step 1.
Results
The results chapter is divided in two main parts. In the first section 4.1, the
results from the risk management process according to ISO 14971 is exposed.
This section includes detailed results from the Hazard Ontology tool since it is
an important part to answer the corresponding research question. The output
of the process that concludes in 4.1 is a list of mitigation measures to reduce the
risk estimation of the unacceptable risks. The second part, 4.2, corresponds
to the description and results from all the verification process regarding three
particular mitigation measures obtained in 4.1.
It is important to state that not all the results obtained during the project
are presented. Only the results from part of the work are presented. That is
because, similar to what explained in 3.4 above, a greater exposition of results
would not have lead to different answer of the research question, but only to a
poorer understanding of the main outcomes of the work. Therefore, the main
results or an extract of them are presented for each step of the process.
30
CHAPTER 4. RESULTS 31
The second step was to identify all mishap victims among the roles defined
in the previous steps. The identified mishap victims are:
Table 4.1: List of identifies mishap victims in step 2 from the HO.
Regarding the third step, the results for the "Drug delivery" activity are
shown in figure 4.2. The output from this step is a list of the Harm TruthMakers
for each identified hazard element in the whole system.
Figure 4.2: Image representing the hazard population step regarding the "Drug
delivery" part of the medical device
Table 4.2: Results from "Risk identification" step. List of main causes found
for the "Damaged mechanism" and "Incorrect instructions from processor"
Harm TruthMakers.
Each one of these causes (and all the other causes from other Harm Truth-
Makers) are the output of the HO and are used the list of risks for the next step:
risk estimation.
Risk estimation
After identifying the maximum number of hazards of the system and their
possible causes, the risk estimation for each one of them was performed. Risk
by risk, severity and probability was guessed according to the methods de-
scribed in chapter 3.1.1. The result regarding the explained risks from above
can be found in the following table:
Severity
Negligible Moderate Significant
High
Probability Medium R2, R6 R3, R4, R7
Low R5 R1
chapter. We can see in red those risk that are not acceptable. The acceptable
risks are shown in black.
Severity
Negligible Moderate Significant
High
Probability Medium R2, R6 R3, R4, R7
Low R5 R1
Risk Mitigation
R1: Patient do not press the button in
M1: Reminder system
scheduled time (forgets intake time)
R2: Patient introduces incorrect drug to the device M2: ID check system
R3: Wrong data sent from sensor
M3: Check up system before dose administration
(wrong calibration or misalignment)
R4: Excessive power supply M4: ISO 60601 - I
R5: Failure in encoder sensor transmission
M5: Failure detection system
(no data received)
R6: Error in the communication
M6: Failure detection system
with potentiometer
R7: Lack of signal from
M7: Failure detection system
the controller due to wire breakage
Functional specifications
The designed system will replicate the main components from the system un-
der study and the main functionalities are:
• The system should have a way to modify external variables such as the
amount of dose prescribed by the doctor.
• The system should have a method to inject the selected failures into the
system.
In short, the system should be able to start when a person presses the start
button. Then, the motor should start rotating at the desired speed. The desired
speed is the variable simulating the prescribed dose. During the performance
of the motor, failures can be injected. And finally, the researcher can see if
the system is able to detect the failures and stop the system as it is required
from the safety specifications or, otherwise, it has an undesired and unsafe
behaviour.
Component specifications
According to the functional specifications and like it can be seen in figure 4.3,
the designed system has:
• Encoder wheel and sensor: they simulate the same wheel-sensor system
implemented in the medical device. It is used as a feedback signal to
have a better control of the motor performance.
• Fault injection switch: system responsible to inject failures into the sys-
tem. They are removable switches that, when removed, introduce the
failure into the system.
• Feedback LEDs: component that helps with the visualization of the cur-
rent state of the system. They show if the system is running as expected
(green), degraded (yellow) or if there is a detected failure (red).
• Fault reset button: component that resets the system after a failure is
detected and the system stops.
Figure 4.3: Schematic showing the main components of the Fault Injection
System.
4.2.2 Implementation
In order to build the designed system, many techniques were used. In the
beginning, electronic knowledge was used to solder and connect all the compo-
nents properly. CAD knowledge was also used to design, for instance, brackets
38 CHAPTER 4. RESULTS
for the motor and the metal axis. At the end of the implementation, program-
ming skills in C++ were used in order to integrate the controlling firmware
into the testing box with all the components and their input and output signals.
Pictures of the fault injection embedded test workbench are shown below.
Figure 4.4: Image from the front panel of the Fault Injection System. It can be
seen many of the key components such as the failure switches, the feedback
LEDs, the USB for the communication, the potentiometer, the buttons and the
outputs to sense the signals of the system.
CHAPTER 4. RESULTS 39
Figure 4.5: Front view of the Fault Injection System. Front panel with main
control components on the top of the picture and motor, encoder and electronic
circuits inside the box.
Figure 4.6: Inside view of the Fault Injection System. There is the DC-motor
on the left, the encoder system in the middle and part of the electronic circuits
in the top of the picture.
40 CHAPTER 4. RESULTS
4.2.3 Analysis
Finally, after the implementation of the system was done, the real testing
of the mitigation measures started. The performance of the motor was anal-
ysed in four different situations: during normal behaviour and when injecting
three different failures. The failures injected are the failures found in the risk
management process and selected in section 4.1.3: speed sensor failure (R5),
potentiometer communication failure (R6) and signal from controller to motor
failure (R7).
The selected variable to analyse the performance of the motor was the
speed in terms of revolutions per minute (rpm). We chose this variable since
it is the greatest indicator of the behaviour of a motor and it will indicate how
well is the performance when injecting a failure compared to the normal and
expected behaviour.
Normal behaviour
To begin with, a test of the performance of the motor under normal cir-
cumstances was done. It is an important test since it will be our reference to
compare the behaviour when injecting the failures. The result can be seen in
the figure 4.8 below.
Figure 4.7: Velocity variance in rpm of the motor when no failure is injected.
As shown in the plot, the normal behaviour of the motor when no failures
are injected is the one that could be expected. The motor accelerates until
CHAPTER 4. RESULTS 41
it reaches a velocity close to the desired speed and then the acceleration de-
creases as it is closer to the target speed. Once the motor reaches the target, it
keeps an almost constant velocity with soft fluctuations through the time.
Figure 4.8: Velocity variance in rpm of the motor when speed sensor failure
is injected after approximately 4.2 seconds from the start.
The first test regarding the speed sensor signal shows that when the failure
is injected after some seconds of normal functioning, the system was able to
detect the failure and stop the motor. It has to be said that the system, not only
stopped the motor, but it also turned on the red LED showing that a failure was
detected.
However, an additional test was performed with the results presented in
figure 4.10. The test consisted on injecting the failure from the beginning,
simulating a failure before the execution of the action, i.e. before the patient
presses the button.
In this case, the system was not able to detect the failure. The behaviour
observed openly, was an acceleration of the motor until it reached top speed.
However, in the plot we are not able to see it because the actual speed was
bigger than the capacity of the encoder system to sense it. That is why we
42 CHAPTER 4. RESULTS
Figure 4.9: Velocity variance in rpm of the motor when speed sensor failure
is injected from the very beginning.
In this case, the system was not able to detect the failure. The behaviour
observed openly, was an acceleration of the motor until it reached top speed.
However, in the plot we are not able to see it because the actual speed was
bigger than the capacity of the encoder system to sense it. That is why we
obtained undefined values in the beginning. After approximately 6.5 seconds
of performance, the failure was removed and the system was able to sense an
abnormal and unexpected speed and, hence, stopped the motor.
In this case, the failure was detected, the feedback LED turned on and the
motor stopped.
In the test where the failure was injected from the beginning, the system
was also able to detect it and the motor did not start rotating.
Figure 4.10: Velocity variance in rpm of the motor when potentiometer failure
is injected after approximately 6.5 seconds from the start.
Figure 4.11: Velocity variance in rpm of the motor when PWM signal failure
is injected after approximately 8 seconds from the start.
In this test, the motor stopped right after the injection of the failure, because
44 CHAPTER 4. RESULTS
of the missing signal. However, the system was able to detect the failure and
the LED was turned on. When the failure was injected before starting the
action, the system was also able to detect the failure and the motor stood still.
Chapter 5
5.1 Discussion
This chapter will be organized according to the research questions presented
in the introduction. The discussion will go through all the raised questions and
it will try to validate the answer based on the results presented in the previous
chapter.
45
46 CHAPTER 5. DISCUSSION AND CONCLUSIONS
If the final result of the process would have been that the mitigation prob-
lems were mitigated and, hence, the probability or severity lowered, the risks
would have been accepted. Even in this case, we would not have been able to
say that the system is safe because there are many more mitigation measures
to verify.
The point is that this was not the case. During the verification of the mit-
igation measure 5, we found a case where a failure was not detected by the
detection system of the device. Therefore, we were not able to verify the miti-
gation control for that hazardous situation. Hence, neither the probability nor
severity could be lowered and the pertinent risk remained unacceptable.
On the other hand, mitigation controls 6 and 7 were completely verified.
However, as explained in methods, there is a last step needed before accepting
the risks: validating that the control measure is included in the device.
Nevertheless, if we answer the question in a general way without being spe-
cific to the particular example, the answer would be probably positive. We can
say that because the system that we analysed is a system that is currently being
developed and this kind of analysis are made, precisely, to identify the weak-
nesses of the design and improve it. Moreover, all the mitigations proposed
and the fault of the mitigation 5 are problems that do not have any reason for
not being solved. They are engineering problems that, based on other similar
cases and similar medical devices with similar technologies, we can be pretty
much sure that can be solved. Therefore, we have no reason to think that the
final design of a medical device with such characteristics cannot be safe.
CHAPTER 5. DISCUSSION AND CONCLUSIONS 47
Based on the experience of this project we can openly say that Hazard
Ontology tool is completely appropriate as a method for the identification of
hazards according to the ISO 14971. We can say that because the main goal of
this phase is to "systematically use available information to identify hazards".
Moreover, during the project we have seen how this methodology allowed us
to identify possible harms and hazards of a predefined system in a methodical
way. Additionally, the output of this tool has been used as the input for the
next step according to the ISO, making obvious the suitability of the tool with
respect to the current existing regulations in Sweden. Therefore, we can say
that it is a method as valid as any of the ones described and recommended in
the standard.
48 CHAPTER 5. DISCUSSION AND CONCLUSIONS
Finally, we will discuss about the suitability of the fault injection system
used to verify the mitigation measures selected in the control step of the risk
management process.
According to the results obtained, we can clearly say that the Fault Injec-
tion System is suitable as a verification tool of the risk management according
to the ISO 14971. The verification process is used to determine if a control
measure is actually lowering the probability or severity of a particular risk.
Moreover, using this tool we have been able to verify that control measures 6
and 7 fulfill the requirements to say that the corresponding risk are acceptable.
Additionally, the tool permitted the identification of a particular case where the
mitigation control 5 was not acting as expected. Therefore, we can say that the
tool can be used to verify and test the mitigation controls and, hence, it is a
suitable tool that can be used in the verification phase of the risk management
process for medical devices described in the ISO 14971.
5.2 Conclusions
Based on the experience of this project, many conclusions can be stated.
We demonstrated that the safety and development lifecycle, particularly
the risk management, is a tedious and really complex process that takes many
resources as time, manpower and effort. Additionally, the current standards
regarding this topic are mostly recommendations and requirements with no
helps on the procedures. Therefore, it is not yet a greatly efficient field and
companies spend a lot of resources in this stage of the development of medical
devices.
That is why there is a need of tools that help companies to undertake these
tasks in the most efficient possible way. For this reason, we tested two tools
that we expected to be suitable with the process: the Hazard Ontology and
the Fault Injection System. At the end of the project, we can say that both
tools have demonstrated to improve the process by making it more efficient
and straightforward.
Regarding the risk management of the medical system, the conclusions are
that many control measures have been defined as safety requirements. From
CHAPTER 5. DISCUSSION AND CONCLUSIONS 49
those, only three were tested and two of them (detection system for motor
and potentiometer signal) successfully passed the test. The third one, dealing
with the speed sensor fault, have been demonstrated to be deficient and further
development needs to be done.
Finally, we can say that additional work has to be done in the same direc-
tion before we can assure that the analysed system is a safe medical device.
Specifically, all the mitigation measures for the identified risks must be veri-
fied and the residual risk must be accepted.
Bibliography
50
BIBLIOGRAPHY 51
[20] Erwin Schoitsch. “Design for Safety and Security of Complex Embed-
ded Systems: A Unified Approach”. In: (Jan. 2005). doi: 10.1007/1-
4020-3381-8_9.
[21] Zhendong Ma and Erwin Schoitsch. “Combined safety and security de-
velopment lifecylce”. In: (July 2015). doi: 10.1109/INDIN.2015.
7281940.
[22] L. Piètre-Cambacédès and M. Bouissou. “Cross-fertilization between
safety and security engineering”. eng. In: Reliability Engineering and
System Safety 110.C (2013), pp. 110–126. issn: 0951-8320.
[23] Jiale Zhou. “AN ONTOLOGICAL APPROACH TO SAFETY ANAL-
YSIS OF SAFETY-CRITICAL SYSTEMS”. eng. In: Mälardalen Uni-
versity Press Dissertations 251 (2017).
TRITA TRITA-CBH-GRU-2019:139
www.kth.se