Safety and Portability in Medical Devices

Download Report

Transcript Safety and Portability in Medical Devices

Safety & Portability in Medical Devices
November 01, 2006 – Timo Taalas
Agenda
•Introduction
> Environment, products, regulations
•Safety
•Portability
Testing, QA
Detailed design,
implementation
Software
architecture
Requirements
Pre Market Analysis
Quality attributes
© Varvana Myllärniemi, 2006
Post Market Analysis
Functionality
2/
GE /
July 7, 2015
Introduction
3/
GE /
July 7, 2015
Regulations & Directives
• Regulations and Directives are legal documents
> Have the force of law
> Intended to ensure products are safe and effective.
• Standards are used to prove compliance to the laws.
• All standards are voluntary but often expected by the
market.
• The FDA accepts national and European standards to prove
compliance to the Quality System Regulations.
• Most other countries accept European standards as proof
of compliance to their regulations.
Need to identify standards that prove compliance
4/
GE /
July 7, 2015
Regulation sources
Governments have product regulations or directives related to
the following categories:
• Product Safety (FDA, MLHW, EC, CCC, …)
• Information Transmission
– Wireless, Ethernet, Telecom (FCC, IEEE, EC, ...)
• Health/Safety/Ergonomic/Human Factors (EHS, OSHA, EC, ...)
• Environment/disposal (EPA, EC, …)
• Privacy (HIPPA, …)
• Trade Agreements and Restrictions (GATT, NAFTA, …)
Need to Identify Regulations that apply to product design
5/
GE /
July 7, 2015
Safety
6/
GE /
July 7, 2015
Safety - a measure of the absence of
unsafe software conditions. The
absence of catastrophic
consequences to the environment
Barbacci, Mario; Klein, Mark H.; Longstaff, Thomas H. & Weinstock, Charles B.
Quality Attributes (CMU/SEI-95-TR-021). Pittsburgh, PA: Software Engineering
Institute, Carnegie Mellon University, 1995.
Safety – Freedom from unacceptable
risk.
ISO 14971
7/
GE /
July 7, 2015
Safety in Our Case
•No harm to the patient
•No harm to the care givers (nurses,
physicians)
•No harm to technicians
•No harm to by standers
•No harm to the environment
8/
GE /
July 7, 2015
Definitions
Harm:
Physical injury or damage to health, property, or the
environment.
Hazard:
A potential source of harm. (I.e. sharp object, electrical
shock, loss of data…etc.)
Hazardous Situation:Exposure to multiple hazards and/or time exposure
element of hazard
Safety:
Freedom from unacceptable harm
9/
GE /
July 7, 2015
What is Risk Management?
Risk Management is a process to:
• Identify the hazards associated with
devices;
• Estimate and evaluate the associated
risks;
• Control these risks and monitor the
effectiveness of that control throughout the
It is more
than a life
Riskcycle.
Analysis – It is a process of managing risks
devices
10 /
GE /
July 7, 2015
Each Manufacturer has Slightly
Varying Risk Management Process
11 /
GE /
July 7, 2015
Risk Management Process (ISO
14971)
Risk Analysis
• Intended use/purpose
• Hazard Identification
• Risk estimation
Risk
Assessment
Risk Evaluation
• Risk acceptability
decisions
Risk Control
• Option analysis
• Implementation
• Residual Risk evaluation
• Overall Risk Acceptance
Risk
Management
Production data
• Validation data
• Review of risk management experience
Post-Production data
•After release data
• Review of risk management experience
Lessons Learned
• Feedback for next generation products
and upgrades.
12 /
GE /
July 7, 2015
Risk Assessment & Control
13 /
GE /
July 7, 2015
Typical Risk Equation & Elements
ISO 14971
Another
model
PoH:
Probability of Harm
Pocc:
Probability X
of Occurrence
LOH:
Likelihood
of Harm
X
Severity
=
RISK
X
Severity
=
RISK
PoH = Pocc x LOH
Probability of Harm may be divided into subparts as shown
14 /
GE /
July 7, 2015
Definitions
Severity :
Magnitude, or degree of physical harm.
Defined as High, Medium, Low, None
Probability of occurrence (P occ):Rate at which the hazard occurs. Defined as
High, Medium, Low, Negligible. Maybe be
based on random failure, or systematic
failure.
Likelihood of harm ( LoH) :
Risk:
Estimation of rate at which physical injury, or
damage to health, would actually occur, once
the hazard has occurred. Defined as High,
Med, Low.
Combination of the probability of occurrence
of harm, and the severity
15 /
GE /
July 7, 2015
Example: Hospital Bed
“A patient rolls out of a hospital bed and hits
the floor, the severity of the harm could
potentially be high due to head injuries, spine
injuries, etc. To decrease the risk, designers
must reduce the probability, reduce the
severity, or both. Probability of harm could be
reduced through the use of protective
measures, such as bed rails, to prevent the
patient from rolling out of bed. Severity of harm
could be reduced by placing soft, thick mats on
the floor.”
Regulatory Affairs Focus Magazine December 2004.
http://www.raps.org/s_raps/rafocus_article.asp?TRACKID=&CID=61&DID=24509
16 /
GE /
July 7, 2015
Typical Risk Equation & Elements
ISO 14971
PoH:
Probability of Harm
Pocc:
Probability X
of Occurrence
LOH:
Likelihood
of Harm
X
Severity
=
RISK
X
Severity
=
RISK
PoH = Pocc x LOH
Probability of Harm may be divided into subparts as shown
17 /
GE /
July 7, 2015
Severity
•Life-threatening—death could occur
•Severe—permanent significant disability
•Moderate—transient but significant disability;
permanent minor disability
•Limited—transient minor disability; annoying
complaints
•None—no disability or physical complaints
anticipated
United States Food and Drug Administration, Office of Regulatory Affairs.
Regulatory Procedures Manual, March 2004, Effective 6 May 2004, Chapter 7,
Attachment D1, 7.41(a)(4)(2).
18 /
GE /
July 7, 2015
Example: NIBP Cuff Inflated
It is possible for non-invasive blood pressure pump to
remain inflated for an unintended length of time. It is
theoretically possible that this could result in nerve
damage, or circulation problems that, in the extreme,
could result in loss of limb. However, a search of over
10 years in the ECRI and FDA MDR databases, as
well as a review of clinical literature, does not report
this extreme result as ever occurring. Therefore, the
severity of prolonged inflation of an NBP cuff, in this
instance, would be Medium, rather than High
19 /
GE /
July 7, 2015
Typical Risk Equation & Elements
ISO 14971
PoH:
Probability of Harm
Pocc:
Probability X
of Occurrence
LOH:
Likelihood
of Harm
X
Severity
=
RISK
X
Severity
=
RISK
PoH = Pocc x LOH
Probability of Harm may be divided into subparts as shown
20 /
GE /
July 7, 2015
Probability of Occurrence
•Some authors think that probability for
software is always 100% – if there is bug,
executing it will cause the occurrence 100%
•However experience shows that some bugs
occur more often than others
> Bug in constantly used feature
> Bug in feature that is used once a year
> Bug that requires several preconditions to be met
21 /
GE /
July 7, 2015
Typical Risk Equation & Elements
ISO 14971
PoH:
Probability of Harm
Pocc:
Probability X
of Occurrence
LOH:
Likelihood
of Harm
X
Severity
=
RISK
X
Severity
=
RISK
PoH = Pocc x LOH
Probability of Harm may be divided into subparts as shown
22 /
GE /
July 7, 2015
Likelihood of Harm
•Estimate realistic clinical possibility
•Assume “good clinical practices” - except for
common user errors
•Evaluate effect of labeling
•The rate at which the harm can develop
•Detectability
23 /
GE /
July 7, 2015
Risk Evaluation
If risk is above predefined limit, it requires
mitigation
24 /
GE /
July 7, 2015
Risk Mitigation Methods
1.
2.
3.
4.
5.
6.
Eliminate hazard by design
Provide safety mechanism
Warning mechanism
Labeling or training
Accept risk (requires justification)
Change intended use
25 /
GE /
July 7, 2015
Example: Frozen Numbers
Failure Mode: Numbers in the screen are
frozen
Hazard: Incorrect information presented
Harm: Incorrect diagnosis
Some mitigations:
1) Update numbers once a second even if
value doesn’t change
2) Add watchdog to graphic library/processor
26 /
GE /
July 7, 2015
Example: Alarm
Failure Mode: Speaker is broken
Hazard: Alarm sound is missing
Harm: Delayed treatment
Some mitigations:
1) Alarm is shown also in the message field
2) Blinking background behind related number
3) Blinking led
27 /
GE /
July 7, 2015
Example: Read Only Memory Error
Failure Mode: Value changes in permanent
memory
Hazard: Alarm limit is incorrect
Harm: Delayed treatment
Mitigations: None since the probability is so
low. Years ago when quality of memory was
lower, data was duplicated in the memory.
28 /
GE /
July 7, 2015
Risk Assessment & Control
29 /
GE /
July 7, 2015
Residual Risk
•Index can be acceptable (Category IV),
tolerable (III), undesirable (II), or critical (I)
•Index affects how risk is managed
> IV is broadly acceptable
> III is acceptable if “As low as reasonably possible” (ALARP)
> II & I Require risk benefit analysis
•Risk can’t be automatically be assumed
ALARP
•Overall residual risk
30 /
GE /
July 7, 2015
Other
•Risk Benefit Analysis
•Acceptable based on the current values of
society
> Consensus standards
> Established practices – ex. Single fault principle
> Comparison with devices in use
•Checklists
>
Medical Device Directive Annex I, part II (1-14)
> IEC 60601-1-4 Checklist
31 /
GE /
July 7, 2015
Portability
32 /
GE /
July 7, 2015
Portability - the ease with which a
system or component can be
transferred from one hardware or
software environment to another
Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary:
A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.
33 /
GE /
July 7, 2015
Which one is more portable?
Java or C++
It depends - what do you exactly
mean with portability?
34 /
GE /
July 7, 2015
Java
C++
•Java language is more
strictly defined
•Java class libraries
•No recompilation needed
for new environment
•Guaranteed to run
(almost) the same way in
every environment
•C++ compiler available to
most OS’s
•C++ available for most
processors
•Supports every hardware
component
35 /
GE /
July 7, 2015
Our Needs for Portability
•In embedded SW hardware (components)
changes often
•Need to support more than one processor
family
•Need to support several operating systems
•Need to support several graphics libraries
•Need to scale to 486 75MHz
36 /
GE /
July 7, 2015
Hardware Abstraction Layer
DGas
Default
DEcg
DSpo2
DPMem
Parameter
Digit Field
Gas Comm
Network
Manager
Gas Param
UI
MDN
Alarms
Waveform
Communication
Module
Comm
Manager
Module Stxx
Protocol
Alarm
Handlers
Patient Data
Archive
Patient Case
Manager
GraphicsMgr
Alarm
Engine
Hardware
Flash Driver
Network
Driver
OS
SWToolkit
Clock
Sound
Common
Setting
Management
Exception
Manager
37 /
GE /
July 7, 2015
38 /
GE /
July 7, 2015
39 /
GE /
July 7, 2015
Cost/Benefits of Portability
•It requires more CPU time – or does it?
•It limits your ability to use
> COTS
> Tools
•Need for embedded knowledge is smaller
40 /
GE /
July 7, 2015
Did we Really Need to be Portable?
•Every single hardware
component has changed
•We have products using
D G as
D efault
D E cg
D S po2
D P M em
P aram eter
D igit F ield
> Intel 486, Intel Pentium M, ARM,
Power PC
> Linux, Windows CE, AMX, Nucleus,
Windows 2000
> X-Window, PEG, Win32, GSP, VGA
(frame buffer)
G as C om m
N etw ork
M anager
G as P aram
UI
MDN
A larm s
W aveform
C om m unication
M odule
C om m
M anager
M odule S txx
P rotocol
A larm
H andlers
P atient D ata
A rchive
P atient C ase
M anager
G raphicsM gr
A larm
E ngine
H ardw are
H W T oolkit
N etw ork
D river
OS
S W T oolkit
C lock
S ound
C om m on
S etting
M anagem ent
E xception
M anager
41 /
GE /
July 7, 2015
Network and parameter API
We have one well
defined interface for
networking and
parameter modules.
•3 module
communication protocols
•2 network protocols
The API and
implementation is used in
other products too
D G as
D efault
D E cg
D S po2
D P M em
P aram eter
D igit F ield
G as C om m
N etw ork
M anager
G as P aram
UI
MDN
A larm s
W aveform
C om m unication
M odule
C om m
M anager
M odule S txx
P rotocol
A larm
H andlers
P atient D ata
A rchive
P atient C ase
M anager
G raphicsM gr
A larm
E ngine
H ardw are
H W T oolkit
N etw ork
D river
OS
S W T oolkit
C lock
S ound
C om m on
S etting
M anagem ent
E xception
M anager
42 /
GE /
July 7, 2015
Questions?
43 /
GE /
July 7, 2015