State of the Practice: Development of Implantable Medical Devices

1
State of the Practice Development of
Implantable Medical Devices
Software in Safety Critical Systems Meeting
2
System Context

• Implantable Defibrillator / Pacemaker
• Monitors heart rhythms
• Controls pacing or shock therapy
• Collects patient and device diagnostics
• Leads
• Connects sensors
• Delivers therapy
• PC based Programmer
• Main user interface
• Configures defibrillator / pacemaker
• Retrieves and displays data

3
Defibrillator / Pacemaker Context

• Constraints
• Size
• 24 cc total
• 7 cc battery, 6 cc output capacitor
• 11 cc control electronics and connectors
• Power
• 1500 mAH battery, 7 year longevity
• 28 µa average current drain
• System metrics
• 2,783,000 custom transistors
• 33,000,000 OTS transistors
• 30 KLOC full function
• 3 KLOC limited function safety core

4
Regulatory Context

• World wide
• FDA in USA
• CE Mark in Europe
• Various country dependent agencies (example,
  Japan)
• Standards
• EN 1441, Medical Devices - Risk Analysis (ISO/DIS
  14971 Risk Management)
• IEC 61508-3, Functional Safety of Electrical /
  Electronic / Programmable Electronic
  Safety-Related Systems - Software Requirements
• IEC 60601-1-4, Medical Electrical Equipment
  Part 1 General Requirements for Safety, 4 Safety
  Requirements for Programmable Electronic Medical
  Systems
• FDA Guidance, Medical Device Use-Safety
  Incorporating Human Factors Engineering into Risk
  Management
• AAMI HE 48, Human Factors Engineering
• AAMI SW68, Medical device software - Software
  Life Cycle Processes
• ISO 12207, Information Technology - Software Life
  Cycle Process
• FDA Draft Guidance, General Principles of
  Software Validation 
• FDA Guidance for Off-the-Shelf Software Use in
  Medical Devices
• FDA Guidance for the Content of Premarket
  Submissions for Software Contained in Medical
  Devices

5
Development Methodology

• Modified Waterfall development methodology
• Concept
• Requirements
• Design
• Implementation
• Validation
• Modified with feedback loops

6
Safety Advocate

• Role
• Plan and maintain the safety case
• Perform or coordinate the various risk analyses
• Analyze and resolve safety issues through life
  cycle
• Monitor development with safety perspective
• Review field reliability feedback

7
Product Development Model
PG Design
Elect.Design
Mech.Design
FW Design
FWImplementation
Elect.Implementation
Mech.Implementation
8
PG Model
Add Statecharts
Activities/Features
PG Design Model (in DOME)
PG Reference Architecture
9
Requirements Phase

• PG system models
• System Requirements Model
• Statemate Magnum by I-Logix, Inc.
• Event driven behavioral view (Harel Statecharts)
• Hierarchy identical to architecture view
• System Architecture Model
• DOME (Domain Modeling Environment) by Honeywell,
  Inc.
• Architecture view
• Functional and structural decomposition
• Captures
• interfaces and hierarchy
• Intent and rationale
• Non-behavioral requirements
• In-house tools
• Merge DOME and Statemate information to produce
  document views

10
System Safety Requirements

• Pervades model
• Dedicated architecture activities
• Safety core
• Output monitors
• Interface protocols
• Arm, fire, and disarm sequences
• Behavioral
• Deadline timers
• Non-functional
• Interaction constraints (TBD behavioral?)

11
Architecture Goals

• Get a handle on complexity
• Identify interdependencies
• Contain change
• Minimize interdependencies
• Provide extensibility to anticipated changes
• Isolate platform specifics
• Maximize reusability of requirements, tests,
  designs, implementations, tooling and other
  decisions
• Establish key qualities of the system
• Safety and Fault Tolerance
• Testability

12
Safety Activity Map
13
Functional Failure Analysis (FFA)

• Some system / software failure modes
• Failing to perform a required function
• Performing an unintended function
• Getting the wrong answer
• Issuing the wrong control instructions
• Doing the right thing but under inappropriate
  conditions
• Performing functions at the wrong time or in the
  wrong order
• Failing to recognize a hazardous condition
  requiring corrective action
• Producing the wrong response to a hazardous
  condition

14
Feedback Loop to system model

• Fault Tree Analysis
• Inputs
• Development feedback
• Lessons Learned Database
• Problems discovered during development of other
  related products
• Reliability feedback
• Field data collected from returned product and
  customer complaints
• Historical hazards database
• Functional failure analysis
• Outputs
• Identify causes
• Assign risk levels
• Develop mitigations
• Feedback into model

15
Peer Reviews / Walkthroughs

• Peer reviews very effective (Boehm and Basili)
• Undirected reviews catch 60 of defects
• Perspective-based reviews catch 35 more defects
  than undirected reviews
• Check List Targeting Safety (Lutz)
• Contains 18 questions aimed at uncovering the two
  most common causes of safety-related errors
• Inadequate interface requirements
• Discrepancies between the documented requirements
  and the actual requirements

16
Design Phase

• Architecture model decomposed at the leafs of the
  hierarchy into software and hardware activities
• Corresponding state charts capture the behavior
  each activity

17
Hazard and Operability Analysis (HAZOPS)

• Peer review of data and control flows using
  checklists and guide words
• Examples omission, commission, early, late,
  value, none, part of
• Also provides review for completeness of
  requirements

18
Tools

• Relex
• Supports FMECA and FTA
• SAM 2000
• Supports FFA, Event tree, FMECA, FTA and HAZOPS

19
Implementation Phase

• What are the components of the implementation and
  how do they interact?
• Computational activities threads, services,
  hardware, interrupt service routines
• Communication interrupts, signals, messages,
  functions calls, parameters, return values,
  global variables, queues
• Executive services scheduling, interrupt
  mapping, memory management, timeout handling,
  signal and message queues
• Resources memory, semaphores, timers, static data

20
Fault response classes

• Class 1 System reset if fault occurred within
  10 minutes of last system reset, additional
  response is to transfer operation to safety core
• Class 2 System reset each time fault occurs
• Class 3 No system reset

21
Rationale for resets as a response

• Resets can be accomplished in 2-3 second time
  frame
• System unavailability for this time is acceptable
• Assumes transient fault first
• An unexpected set of data has caused a sequence
  that enables a design fault or component failure.
• Restart hardware and firmware state machines from
  a known state and retry with a new set of data
  (time redundancy)
• If fault is not transient, operation is
  transferred to safety core (functional redundancy)

22
Use of Monitors

• Safety Monitors
• Excessive shocks
• High voltage leakage
• High rate pacing
• Low rate pacing
• Memory errors (SEU)

• Wellness Monitors
• Analog sensing (TBD)
• Battery / Power supply
• Beeper (TBD)
• Critical support hardware
• Data integrity
• Deadline timers

• Reed switch
• HV capacitor
• HV output switches
• Memory and register access
• Oscillator
• Leads

23
Fault Tolerant Techniques used

• Data redundancy
• Time redundancy
• Safety Kernel
• Timing Deadlines

24
Safety Core

• Strategy
• Very limited functionality
• Reduce potential exposure to faults
• Current products use ROM based µP control
• Working toward hardware based control
• Pacemaker
• Mostly hardware based, no programmability
• Defibrillator
• Uses common output hardware limited
  programmability

25
Safety Case

• A safety case presents a clear, comprehensive and
  defensible argument supported by calculation and
  procedure that a system is acceptably safe to
  operate in a particular context.

26
Goal Structuring Notation (GSN)

• Graphical approach to representing the entities
  and relationships used in a safety argument
• Components
• Goal a requirement, target, or constraint to be
  met by the system
• Strategy a rule to be invoked in the solution of
  goals
• Justification reason or evidence that supports a
  strategy
• Constraint restricts the way in which goals can
  be solved
• Context bounds the argument
• Solution individual pieces of analysis,
  evidence, test results, references to design
  material, etc.

27
GSN Example
28
Q A

• ?