Guidance for the Content of
Premarket Submissions for Software
Contained in Medical Devices
2016/7/13
Presenter: WEI-CHIH HSU
Adviser: Dr. Yeou-Jiunn Chen
Dr. Sandy Lu
1
Date: 2009/12/8
outline
► Introduction
► Purpose
► Methods
► Conclusion
► Future
Works
► Reference
2016/7/13
2
Introduction
Scope
►
Firmware for software-based control of medical devices.
►
Stand-alone software applications.
►
Software intended for installation in general-purpose computers.
►
Dedicated hardware/software medical devices.
►
Accessories contain or are composed of software.
2016/7/13
3
Introduction
This guidance document applies to all types of premarket
Submissions
►
Premarket Notification (510(k))
►
Premarket Approval Application (PMA)
►
Investigational Device Exemption (IDE)
►
Humanitarian Device Exemption (HDE)
2016/7/13
PMA：上市前批准
510(k)：上市前通知
4
Introduction
Software Development Life Cycle
User needs
Requirements
Specification
Understand
Design
Specifications
2016/7/13
Confirm
Products
Source code
5
Introduction
Software Tester v.s. Software Developer
Microsoft
►
52,000 Staff
 Developer of 10,000
 Tester of 15,000
► Windows
2000
 Developer of 1,700
 Tester of 3,200
► IE4
 Development time 6 months
 Test time 8 months
2016/7/13
6
Purpose
What is a software verification
►
Product development life cycle activities
►
To meet the functional and user requirements
►
Analysis, Verify, Review, Test
►
Software Engineering & Quality Management System
2016/7/13
7
Methods
Verification and Validation
► Verification
 Are we building the product right ?
► Validation
 Are we building the right product ?
2016/7/13
8
Methods
User needs
Design
Input
Design
Process
Verification
Validation
2016/7/13
Design
Output
Medical
Device
9
Methods
General Principles of Software Validation
►
Is a component, part, or accessory of a medical device.
►
Is itself a medical device.
►
Is used in manufacturing, design and development, or other
parts of the quality system.
2016/7/13
10
Methods
Software Documentation
►
Level of Concern
►
Software Description
►
Device Hazard Analysis
►
Software Requirement Specification
►
Architecture Design Chart
►
Software Design Specification
2016/7/13
11
Methods
Software Documentation
►
Traceability Analysis
►
Software Development Environment Description
►
Verification and Validation Documentation
►
Revision Level History
►
Unresolved Anomalies
2016/7/13
12
Methods
Level of Concerns
►
Major Level
 The failure or latent flaw could indirectly result in minor injury to the patient or
operator.
► Moderate
Level
 The failure or latent design flaw could directly result in minor injury to the patient or
operator.
► Minor
Level
 The failures or latent design flaws are unlikely to cause any injury to the patient or
operator.
2016/7/13
13
Methods
Software Description
►
Software Control
 Role、Interface、Control
►
Main Features
 Functions、Advantages、Methods
►
Hardware and software platform
 Development language、Operating system
2016/7/13
14
Methods
Device Hazard Analysis
►
Identification of the hazardous events
►
Severity of the hazard
►
Causes of the hazard
►
Method of control and Corrective measures taken
►
Verification
2016/7/13
15
Methods
Device Hazard Analysis
 Failure mode and effect analysis
2016/7/13
Level
Frequency
Level
Effect
10
Highest
10
Death
8
High
8
Permanent
6
Occasional
6
Serious
4
Low
4
Mild
2
Less Impossible
2
Minor
1
Impossible
1
No effect
16
Methods
Failure mode and effect analysis
 Risk Chart
10
8
ALARP
Acceptable
Frequency
Not Acceptable
6
4
2
1
1
2016/7/13
2
4
6
Effect
8
10
17
Methods
Software Requirement Specification (SRS)
►
Software Requirements

►
Minor

►
The summary functional requirements section from the SRS
Moderate and Major

►
Function, Performance, Interface, Design, Development
The complete SRS document
Software Requirement Specification





2016/7/13
Function Objective
Definitions and Symbols
Functional Requirements
Non-functional Requirements
Interface Requirements
SRS：軟體需求規格
18
Methods
Architecture Design Chart
►
Flowchart


►
Major functional
Hardware and Data flows
Moderate and Major Level of Concern devices

Detailed information
►
►
2016/7/13
State Diagram
Flow Charts
19
Methods
Software Design Specification (SDS)
►SRS V.S.
► Design





2016/7/13
SDS
Decision
Design and Tools
Structures
System Flow
Software Component Specifications
Interface Design Specifications
SRS：軟體需求規格
SDS：軟體設計規格
20
Methods
Traceability Analysis
Design
requirements
Design specifications
V&V Test
Risk prevention
SAS001
SDS102
V&V201
FMEA005
2016/7/13
21
Methods
Software Development Environment Description
►
Software Development
 V model
 Water fall model
 Spiral model
►
Software Project Quality Management
 Project Management Plan
 Software Test Plan
 Construction and Maintenance Management Plan
2016/7/13
22
Methods
Verification and Validation Documentation
Report






2016/7/13
Test Item Number
Software Version
Testers
Names、Purposes 、Devices、Tools
Methods、 Specifications 、Environmental requirements
Standards、Results
23
Methods
Revision Level History
Number
2016/7/13
Date
Version
content
Relation
24
Methods
Unresolved Anomalies
► Problem
► Impact
on device performance
► Any plans or timeframes for collecting the problem
2016/7/13
25
Conclusion
► Software
► Complete
V&V and Test
software specification
► Software
life cycle management and Risk
Management
2016/7/13
26
Future Works
►
IEEE standard for software Verification and Validation
►
Software Engineering Course
►
Medical Device Review
2016/7/13
27
References
►
This document supersedes Guidance for the Content of Premarket
Submissions for Software Contained in Medical Devices, issued May 29,
1998, and Reviewer Guidance for a Premarket Notification Submission
for Blood Establishment Computer Software, issued January 13, 1997.
►
醫療器材軟體確效管理及軟體開發流程/測試/驗證實務 長庚大學資訊工
程系 副教授 林仲志博士
2016/7/13
28
Thank you for your attention
2016/7/13
29