Center for Devices and Radiological Health Software ... · March 16, 2000 Software Engineering Standards and Medical Devices 8 Center for Devices and Recognition Example 1 Radiological

Center for Devices and Radiological Health

Software Engineering Standards and Medical Devices

10th Annual AAMI/FDA International Standards ConferenceMcLean, Virginia

Thursday March 16, 2000

John F. Murray JR.

March 16, 2000 Software Engineering Standards and Medical Devices 2

Center for Devices and Radiological HealthWhat I Plan to Cover

uThe Long Term Goal

uRecognition Model

uCurrently Recognized Standards


Center for Devices and Radiological HealthLong Term Goal 1

uCreate a regulatory environment that

eliminates the need for the pre-market

submission of software documentation.


Center for Devices and Radiological HealthLong Term Goal 2

uGlobal Harmonization

– Do it once

– Do it right

– Move on

uEliminate repackaging and restructuring


Center for Devices and Radiological HealthAchieving the Goal

uDevelop Standards that benefit the Public

Health, the Regulator, and the Industry

uDevelop standards that address the safety

and effectiveness of software


Center for Devices and Radiological HealthFocus on the Fundamentals

u Safe Software requires sound “safety” system engineering

uAgreement on what affects software safety and effectiveness

uCommon framework and language

u A working partnership


Center for Devices and Radiological HealthRecognition Model

u Software STG

– Traceability to ODE Guidance

– Risk Pyramid

– Understanding the risk

– Must be a Standard

– Facilitate the Partnership


Center for Devices and Radiological HealthRecognition Example 1

u ISO/IEC 12207 Software Life Cycle– Recognized

– International Standard– Product of ISO/IEC JTC1



uUL 1998 Software in Programmable Components– Recommended for Recognition

– National Standard– Product of the Underwriter’s Laboratory



u IEEE 830 Software Requirements

– Not Recognized

»Recommended Practice

»Not a Standard



u ISO 9000-3 Quality Systems for Software

– Not recognized

»Guidance Document

»Not a Standard


Center for Devices and Radiological HealthRecognized Standards

u ISO/IEC 12207 Software Life Cycle Processes

u IEEE/EIA 12207

u IEEE 1074 Standard for Developing Software Life Cycle Processes


Center for Devices and Radiological HealthRecommended

u IEEE 1012 Standard for Software Verification and Validation

u

uUL 1998 Software in Programmable Components


Center for Devices and Radiological HealthSummary

u Sound Engineering Meets Regulatory

Requirements

uMust address the needs of all Customers

u Partnership a must for success

16-Mar-2000

Copyright 2000 SoftwareCPR 1

AAMI Medical Device Software Engineering Standard

Status and Content OverviewAlan Kusinitz

CRISIS PREVENTION AND RECOVERY, LLCSOFTWARECPR

781-721-2921

2

SCOPE

F Life cycle requirements for software engineering

F Development and maintenanceF All medical device software – embedded

and standaloneF Minimum requirementsF Intended to support conformity assessment

16-Mar-2000


THE SOFTWARE DIVERSITY ISSUE

FLEXIBILITY IN APPROACH IS REQUIRED AND PROVIDED

Different intended uses, types of products, potential hazards, risk level

Standalone software and software/firmware as part of a device

Different size companies and software teams

4

SOME DEFINITIONS

F Life cycle model– framework of processes, activities, and tasks

…F Process

– A set of interrelated activities, which transform inputs into outputs

F Supporting Process– A supporting process is employed as needed

during the execution of another process

16-Mar-2000


5Process and Activity Summary

*Problem Resolution

Software &documentation

Documentation

6.2.2 Design & Development

6.2.3 Maintenance

Software Hazard Mgmt

6.1.5 Changes

6.1.4 Verification

6.1.3 Mitigation

6.1.2 Analysis

*5.2Maintenance

*5.2.2 Problem &Modification Analysis

5.2.4 Migration5.2.3 Implementation

Verification

6.4.2.8 Documentation

6.4.2.6 Integration

6.4.2.5 Code

6.4.2.4 Design

6.4.2.2 Requirements

6.4.2.7 System Testing

6.4.2.3 Architecture

*5.1 Development

5.1.5 Code &test

5.1.3 ArchitecturalDesign

*5.1.2 Req Analysis 5.1.4 Detailed Design 5.1.6 Integration

5.1.7 SystemTest

*5.1.8 Validation

5.1.9Release

AAMI STD

*ISO/IEC 14971for MEDICAL DEVICE RISK MANAGEMENT

*ISO 13485 for MEDICAL DEVICE DESIGN CONTROL AND QUALITY SYSTEM

*6.3.4 Status

*6.3.2 ID

*6.3.3Control

*Configuration Mgmt

Development Process

Maintenance Process

6Required Elements for No Hazard Software (Prior to Mitigation)

*Problem Resolution

Software &documentation

Problem &Modification Analysis

*ISO/IEC 14971for MEDICAL DEVICE RISK MANAGEMENT

*ISO 13485 for MEDICAL DEVICE DESIGN CONTROL AND QUALITY SYSTEM

*6.3.4 Status

*6.3.2 ID

*6.3.3Control

*Configuration Mgmt

Maintenance ProcessRequirements

AnalysisValidation

Development Process

16-Mar-2000


7

KEY POINTSF Flexible – not prescriptive

– No organizational requirements– No specific life cycle model

required– No specific organization of

documentation, plans, or procedures

FPrimary vs. supporting processes (as in 12207)

FSpecification of deliverables to support conformity assessment

8

KEY POINTS (cont.)F Includes software hazard

managementFRepresents minimum requirementsF Two hazard levels addressed: none,

someFExtensive informative Annex –

provides rationale and explanationFOff-the-shelf software is addressed

throughout lifecycle

16-Mar-2000


9

SUMMARY

F Scope: Product Software

F Model: ISO/IEC 12207

F 2 Hazard Levels– None prior to mitigation– Some prior to

mitigation

F 2 Normative References– ISO 13485 (Quality

System)– ISO 14971 (Risk

Analysis

F 2 Primary Processes– Development– Maintenance

F 5 Supporting Processes– Software Hazard

Management– Documentation– Configuration

management– Verification– Problem resolution

10

AAMI SW Std. Next Steps

FComplete BallotingFFinal revisionsFFDA recognitionF International Standards work

item

16-Mar-2000


11

Available on Web Site

F Ballot draft of AAMI software engineering standardF Updates on status of this standardF Other related information and reference documents

www.softwarecpr.comExpertise on Software Safety and FDA Regulation

Alan Kusinitz – 781-721-2921 – [email protected]

Using the CDRH Off-the-Shelf Guidance: A Practical Approach

from the User's Perspective

Stan HamiltonStan Hamilton

CytometricsCytometrics

OTSS Guidance OverviewOTSS Guidance Overview

• Definition of OTSS is broad : covers all software delivered to customers but not developed in-house under design control

• Does not include manufacturing software, quality system software, or software “tools”

• Describes itself as a safety-based approach to risk management consistent with international standards (IEC 60601-1-4) and defines qualitative methods required based on Level of Concern

OTSS DocumentationOTSS Documentation

• If Minor Level of Concern without mitigation:– Hazard Analysis– Basic Documentation

• If Minor Level of Concern with mitigation:– Also provide summary of hazard mitigations

• If Moderate Level of Concern– Also describe and justify residual risk

• If Major Level of Concern– Also provide Special Documentation

Basic DocumentationBasic Documentation

• Description and why appropriate

• Hardware configuration

• End user considerations

• Specific function in device

• Testing

• Configuration control

Special Documentation

• Supplier audit of software development methodology

• Demonstrate V&V adequacy, including supplier performed

• Demonstrate ability to maintain and support software configuration independent of supplier

Mapping to Basic Documentation

OTSSDocumentation

Project Documents

Hardware Configuration ConfigurationManagement Plan “XXX”

End User Considerations Human FactorsDocuments

System Risk Analysis

Specific Function inDevice

System/Software DesignSpecifications

Software RequirementsDocuments

Testing SRS Test Results OTSS V&V File

Configuration Control Software ConfigurationControl Plan

Software Risk DeterminationSoftware Risk Determination

• In general, risk for a component failure is probability times severity (R = P x S)

• For formal risk analysis, software failures are generally considered to be systematic

• A numeric probability of failure cannot easily be calculated, so it is assumed a software failure will occur...

S/W Risk = Severity X Unknown Probability (1)

Software Quality Measures

From 60601-1-4 Annex CCC…Qualitative method for establishing safety

integrity:• Inherently safe design architecture

(mitigation) • Development methodology and techniques

• Quality Assurance systems (Test)

“Safety Integrity Risk Factor”

COMPLEXITY

SQA MEASURES

COMPLEXITY

DESIGN CONTROL + TEST

OR...

OTSS Concern?

COMPLEXITY

DESIGN CONTROL + TEST

Usually unknown System level can be thorough

Typically higher than if custom developed

OTSS Risk ManagementOTSS Risk Management

• Without considering “Safety Integrity Risk Factor”, all OTSS components will be leveled in risk analysis by worst case hazard severity-complexity or ability to test not considered

• Can lead to spending undue effort mitigating low risk OTSS components

• Level of rigor should be prioritized by risk- this includes improving the “safety integrity risk factor” through qualitative methods

Mitigation of OTSS RiskMitigation of OTSS Risk

• Level of Concern is determined post-mitigation

• Test counts toward “safety integrity risk factor”- but not as a mitigation

• Mitigations in order of precedence:

– Inherent safe design,

– protective measures,

– and user labeling (warnings)

• Avoid any undetected single point OTSS failure of major severity

OTSS Mitigation ExamplesOTSS Mitigation Examples

Real-time operating system scheduler:

• Can’t mitigate failure of every function- what is critical? If a few task schedules are very critical, implement a multi-function watchdog external to the OS environment.

Signal Processing Library Functions:

• What is critical? Calculation that feeds a result leading to a clinical decision… Possibly implement a simpler “checking algorithm” that gives a result close enough to mitigate hazard severity.

OTSS V&VOTSS V&V

• Use the risk analysis as an input to software test planning

• Document how that formal software requirements testing cover OTSS critical functions- get credit for all tests related to OTSS functions

• Create a file documenting other factors that demonstrate software reliability- number of installations, bug listings, user group reports, etc.

ConclusionsConclusions

• The OTSS Guidance is just an extension of good risk management practices to OTSS

• The Guidance indicates certain qualitative methods that should be used to increase the “Safety Integrity Risk Factor” depending on severity

• OTSS Component Residual Risk is: Post-Mitigation Severity * “Safety Integrity Risk Factor”

• Risk management of OTSS should occur early in design process, with emphasis on mitigating OTSS failures of major severity

Copyright 2000 Underwriters Laboratories Inc.c1

ANSI / UL 1998Safety of Software in

Programmable Components


Product levelstandards and

regulations

ChangeManagement

SoftwareRisk Analysis

Verification,Validation, and

Test

Design for Safety

UL 1998 CORE REQUIREMENTS


Software Risk AnalysisUL 1998, Section 3

• Risk Identification

• Initiating causes

• Software risk management

• Traceability


ISO/IEC DIS 14971:Medical Devices – Application of risk management to medical devices


Process DefinitionUL 1998, Section 4

• Defined inputs and outputs

• Integrated risk management

• Traceability

• Verification


ISO/IEC 12207: Information technology – Software life cycle processes


Design for Software Safety UL 1998

• Software Design

• Critical and Supervisory Sections

• Measures to Address Microelectronic Failure Modes

• Product Interfaces

• User Interfaces



• Traceable

• Verifiable, testable, maintainable

• Defined interfaces

• Partitioning

• Initialization of variables to non-hazardous state

• Risk-addressed states and state transitions



• Fault-handling• Redundant software

• Redundant hardware• Self diagnostic routines • Data integrity


Verification UL 1998, Section 11

• Software Analysis• Software Testing

• Failure Modes and Stress Testing


Software Testing

• Development & Post-release testing

• Test Cases traceable to Risk Analysis

• Traceable to the safety requirements


Failure Mode & Stress Testing• Operator errors

• Microelectronic Hardware failure

• Error in data received from other sources

• Negative condition branch

• Out-of-range

• Boundary condition

• Type mismatched values for parameters


Software Validation

FDA/CDRH’s Guidance for Industry: General Principles of Software Validation

“establishing [define, document, implement] by objective evidence that all software requirements have been implemented correctly and completely and are traceable to system requirements.”


• Software Safety Plan

• Risk Analysis Approach and Results

• Configuration Management Plan

• Product Summary and User Documents

• System Architecture

Documentation


• System and Software Requirements Specification

• System and Software Design Specification

• Verification, Validation and Test Plans

• Verification, Validation and Test Results

• Software Safety Reference Manual

Documentation


Change ManagementUL 1998, Section 14

•Software shall contain a unique identifier.

•Changes or patches to a programmable electronic system shall not increase risk.

•Each time a change or patch is incorporated in the software, a new identifier shall be assigned.


Off-The-Shelf (OTS) Software

UL 1998, Section 13

• Risks addressed • Identification of Version Release number

• List of known anomalies• Evidence of verification• Configuration Management plan


UL 1998FDA Standards Recognition

• All medical devices containing software• 510(k), IDE, PMA, HDE


FDA Submissions

SoftwareDocuments MINOR MODERATE MAJORSoftwareDescription SUBMIT SUBMIT SUBMITDevice HazardAnalysis SUBMIT SUBMIT SUBMIT

SRS SUBMIT SUBMIT SUBMITReleaseVersion No. SUBMIT SUBMIT SUBMIT


FDA SubmissionsMinor / Moderate LOC

SUBMIT• UL 1998 compliance

DON’T SUBMIT• Architectural

Design*

• Design Specification*

• Traceability

• Validation

• Development*

• Revision History*


Global Engineering Documents

TEL: (800) 845-7179FAX: (303) 397-2740

e-mail: [email protected]


THANK YOU FOR ATTENDING

FOR MORE INFORMATION CONTACT UL at :

[email protected]

telephone toll-free: 11--888888--857857--63816381

Global Round-up: Software Standards

10th Annual AAMI/FDA International Conference on

Medical Device Standards and RegulationMarch 16, 2000

Sherman Eagles

Medtronic CRM


Part One – What’s Happening in International Software

Standards

International Standards Applicable To Medical Device

Software Come From:

l Medical committees

– IEC TC 62, ISO TC 210, ISO TC 215

l Functional committees

– IEC TC 65, ISO TC 176

l Technology committees

– ISO/IEC JTC1/SC7

Medical Committee Standards (IEC 62A WG 22)

l IEC 60601-1-4 Safety Requirements for Programmable Electrical Medical Systems

– Amendment 1 approved 1999

– Removed: Requirement to document integrity levels

– Added: New requirement for a problem resolution system

Medical Committee Standards (IEC 62A WG 22)

l IEC 60601-1 (3rd edition)

– Includes section for Programmable Electrical Medical Systems (PEMS) (from 60601-1-4)

– New requirements for devices connecting to networks

l New Software Process Standard (proposed)

l New Requirements for Networks (proposed)

Medical Committee Standards (Health Informatics - ISO TC 215)

l Message descriptions and development of messages

l Point-of-care medical device communications (4 standards)

– Domain information model for generalized virtual medical device

l Domain model for health information

l Ownership and access rights to electronic healthcare records

Functional Committee Standards(Quality - ISO TC 176)

l ISO 9000-3 Guidelines for applying 9001 to software

– Revision based on 9001:2000 to be completed in 2001

– Revision to be done by JTC1/SC7, not TC 176

Functional Committee Standards(Safety - IEC TC 65)

l IEC 61508 Functional Safety

– All parts published as international standards

– Part 3 – software requirements

Technology Committee Standards(Software Engineering - JTC1/SC7)

l ISO/IEC 12207 Software lifecycle processes

– Amendment under development

l ISO/IEC 15288 System lifecycle processes

– New system engineering standard under development


Part Two – A Big Picture Look

Medical Device Software Regulation – Some Future Issues

l Hardware that looks a lot like software

l Platforms and families of products often differentiated only by software

l Much more software in medical devices

l Software is evolving into new roles

l Internet tidal wave

Software Evolution

Time

Am

ou

nt

of

So

ftw

are

Software for Hardware Control

Software for new User Functionality

Medical Device Software Regulation – Some Future Needs

l Predictable and fast reviews

l Risk based review criteria

l Evolution of software regulation to match evolution of software use in devices

l How to regulate the integration of medical devices and information technology

Medical Device Software Regulation How Can Standards Help?

l Create a common language

l Establish common expectations

l Facilitate trust between regulator and manufacturer

l Provide an industry-wide mechanism for improvement

Medical Device Software Standards – Some Problems

l Consensus standards can’t keep up with changes

l Not enough benefit in using standards

l Standards often define “best practice” rather than minimum requirements

What we need to do

l Keep the goal in mind – delivering safe devices that help patients

l Demand minimum, usable standards - and help develop them

l Identify ways standards can benefit both regulators and manufacturers

Contact Information

Sherman EaglesFellowMedtronic, Inc.7000 NE Central AveMinneapolis, MN 55432

763-514-4250763-514-6197 (fax)[email protected]