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
March 16, 2000 Software Engineering Standards and Medical Devices 3
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.
March 16, 2000 Software Engineering Standards and Medical Devices 4
Center for Devices and Radiological HealthLong Term Goal 2
uGlobal Harmonization
– Do it once
– Do it right
– Move on
uEliminate repackaging and restructuring
March 16, 2000 Software Engineering Standards and Medical Devices 5
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
March 16, 2000 Software Engineering Standards and Medical Devices 6
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
March 16, 2000 Software Engineering Standards and Medical Devices 7
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
March 16, 2000 Software Engineering Standards and Medical Devices 8
Center for Devices and Radiological HealthRecognition Example 1
u ISO/IEC 12207 Software Life Cycle– Recognized
– International Standard– Product of ISO/IEC JTC1
March 16, 2000 Software Engineering Standards and Medical Devices 9
Center for Devices and Radiological HealthRecognition Example 2
uUL 1998 Software in Programmable Components– Recommended for Recognition
– National Standard– Product of the Underwriter’s Laboratory
March 16, 2000 Software Engineering Standards and Medical Devices 10
Center for Devices and Radiological HealthRecognition Example 3
u IEEE 830 Software Requirements
– Not Recognized
»Recommended Practice
»Not a Standard
March 16, 2000 Software Engineering Standards and Medical Devices 11
Center for Devices and Radiological HealthRecognition Example 4
u ISO 9000-3 Quality Systems for Software
– Not recognized
»Guidance Document
»Not a Standard
March 16, 2000 Software Engineering Standards and Medical Devices 12
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
March 16, 2000 Software Engineering Standards and Medical Devices 13
Center for Devices and Radiological HealthRecommended
u IEEE 1012 Standard for Software Verification and Validation
u
uUL 1998 Software in Programmable Components
March 16, 2000 Software Engineering Standards and Medical Devices 14
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
Copyright 2000 SoftwareCPR 2
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
Copyright 2000 SoftwareCPR 3
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
Copyright 2000 SoftwareCPR 4
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
Copyright 2000 SoftwareCPR 5
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
Copyright 2000 SoftwareCPR 6
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
Copyright 2000 Underwriters Laboratories Inc.c2
Product levelstandards and
regulations
ChangeManagement
SoftwareRisk Analysis
Verification,Validation, and
Test
Design for Safety
UL 1998 CORE REQUIREMENTS
Copyright 2000 Underwriters Laboratories Inc.c3
Software Risk AnalysisUL 1998, Section 3
• Risk Identification
• Initiating causes
• Software risk management
• Traceability
Copyright 2000 Underwriters Laboratories Inc.c4
ISO/IEC DIS 14971:Medical Devices – Application of risk management to medical devices
Copyright 2000 Underwriters Laboratories Inc.c5
Process DefinitionUL 1998, Section 4
• Defined inputs and outputs
• Integrated risk management
• Traceability
• Verification
Copyright 2000 Underwriters Laboratories Inc.c6
ISO/IEC 12207: Information technology – Software life cycle processes
Copyright 2000 Underwriters Laboratories Inc.c7
Design for Software Safety UL 1998
• Software Design
• Critical and Supervisory Sections
• Measures to Address Microelectronic Failure Modes
• Product Interfaces
• User Interfaces
Copyright 2000 Underwriters Laboratories Inc.c8
Design for Software Safety UL 1998
• Traceable
• Verifiable, testable, maintainable
• Defined interfaces
• Partitioning
• Initialization of variables to non-hazardous state
• Risk-addressed states and state transitions
Copyright 2000 Underwriters Laboratories Inc.c9
Design for Software Safety UL 1998
• Fault-handling• Redundant software
• Redundant hardware• Self diagnostic routines • Data integrity
Copyright 2000 Underwriters Laboratories Inc.c10
Verification UL 1998, Section 11
• Software Analysis• Software Testing
• Failure Modes and Stress Testing
Copyright 2000 Underwriters Laboratories Inc.c11
Software Testing
• Development & Post-release testing
• Test Cases traceable to Risk Analysis
• Traceable to the safety requirements
Copyright 2000 Underwriters Laboratories Inc.c12
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
Copyright 2000 Underwriters Laboratories Inc.c13
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.”
Copyright 2000 Underwriters Laboratories Inc.c14
• Software Safety Plan
• Risk Analysis Approach and Results
• Configuration Management Plan
• Product Summary and User Documents
• System Architecture
Documentation
Copyright 2000 Underwriters Laboratories Inc.c15
• 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
Copyright 2000 Underwriters Laboratories Inc.c16
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.
Copyright 2000 Underwriters Laboratories Inc.c17
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
Copyright 2000 Underwriters Laboratories Inc.c18
UL 1998FDA Standards Recognition
• All medical devices containing software• 510(k), IDE, PMA, HDE
Copyright 2000 Underwriters Laboratories Inc.c19
FDA Submissions
SoftwareDocuments MINOR MODERATE MAJORSoftwareDescription SUBMIT SUBMIT SUBMITDevice HazardAnalysis SUBMIT SUBMIT SUBMIT
SRS SUBMIT SUBMIT SUBMITReleaseVersion No. SUBMIT SUBMIT SUBMIT
Copyright 2000 Underwriters Laboratories Inc.c20
FDA SubmissionsMinor / Moderate LOC
SUBMIT• UL 1998 compliance
DON’T SUBMIT• Architectural
Design*
• Design Specification*
• Traceability
• Validation
• Development*
• Revision History*
Copyright 2000 Underwriters Laboratories Inc.c21
Global Engineering Documents
TEL: (800) 845-7179FAX: (303) 397-2740
e-mail: [email protected]
Copyright 2000 Underwriters Laboratories Inc.c22
THANK YOU FOR ATTENDING
FOR MORE INFORMATION CONTACT UL at :
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
Global Round-up: Software Standards
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
Global Round-up: Software Standards
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]