Prepared By: Certified Compliance Solutions, Inc. August 2012

Slides:



Advertisements
Similar presentations
Building a Cradle-to-Grave Approach with Your Design Documentation and Data Denise D. Dion, EduQuest, Inc. and Gina To, Breathe Technologies, Inc.
Advertisements

Medical Device Software Development
System Integration Verification and Validation
By Eva Freund, The IV&V Group, Inc.
OBP Research Oy for simpler creation of embedded systems.
EQUIPMENT VALIDATION.
Agile and Medical Device Software
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
1 SYSTEM and MODULE DESIGN Elements and Definitions.
Project Documentation and its use in Testing JTALKS.
Breakout Group 2: Software Quality Assurance Outcome 8/18/10 1.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
SISTEMA Example One. Schneider Electric – Sistema Example 1 – June Example 1: Start/Stop Facility with Emergency Stop Device Circuit Diagram.
Models for Software Reliability N. El Kadri SEG3202.
MethodGXP The Solution for the Confusion.
EOSC Generic Application Security Framework
Introduction to Software Quality Assurance (SQA)
Product Quality, Testing, Reviews and Standards
ISO Tor Stålhane IDI / NTNU. What is ISO ISO 9001 was developed for the production industry but has a rather general structure ISO describes.
CLEANROOM SOFTWARE ENGINEERING.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
VTT-STUK assessment method for safety evaluation of safety-critical computer based systems - application in BE-SECBS project.
Safety-Critical Systems 6 Certification
Moving to Agile in an FDA Environment
ESA/ESTEC, TEC-QQS August 8, 2005 SAS_05_ESA SW PA R&D_Winzer,Prades Slide 1 Software Product Assurance (PA) R&D Road mapping Activities ESA/ESTEC TEC-QQS.
Product Development Chapter 6. Definitions needed: Verification: The process of evaluating compliance to regulations, standards, or specifications.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Software Engineering Introduction and Overview Takes customer-defined goals and constraints and derives a representation of function, performance, interfaces,
© 2012 Cengage Learning. All Rights Reserved. This edition is intended for use outside of the U.S. only, with content that may be different from the U.S.
© 2011 Underwriters Laboratories Inc. All rights reserved. This document may not be reproduced or distributed without authorization. ASSET Safety Management.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Level 2 Unit 3 Engineering Applications of Computers Engineering Diploma Level 2 Unit 3 Engineering Applications of Computers In this unit you will discover.
BE-SECBS FISA 2003 November 13th 2003 page 1 DSR/SAMS/BASP IRSN BE SECBS – IRSN assessment Context application of IRSN methodology to the reference case.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
1 Introduction to Software Engineering Lecture 1.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Safety Critical Systems 5 Testing T Safety Critical Systems.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 1 Chapter 13 Finalizing Design Specifications.
Request for Proposal (RFP)
Practical Investment Assurance Framework PIAF Copyright © 2009 Group Joy Pty. Ltd. All rights reserved. Recommended for C- Level Executives.
Safety-Critical Systems 7 Summary T V - Lifecycle model System Acceptance System Integration & Test Module Integration & Test Requirements Analysis.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Over View of CENELC Standards for Signalling Applications
11 STANAG 4586 Working Group Jan 2010 Mike Meakin.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Software Architectural Views By the end of this lecture, you will be able to: list and describe the views in the 4+1 view model of software architecture.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
SISTEMA Example Four.
Thursday August 20, 2009 John Anderson Page 1 Accelerator Interlock System Issues Flow Down of Requirements from the Safety Order to Engineered Safety.
4+1 View Model of Software Architecture
Lectures 2 & 3: Software Process Models Neelam Gupta.
© ABB Inc. - 1 A robust portfolio of interoperable solutions Getting started with Industrial IT Certification Document# 3BSE042726, September 2005.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
Copyright © 2007, Oracle. All rights reserved. Managing Items and Item Catalogs.
의료용 S/W 기술문서 심사 방법 원 찬 요 유엘 코리아 발표자 소개 년 2 월 한양대 전자공 졸업 ~ : ㈜ 금성사 ( 현 LG 전자 ) 연구원 ~ : ㈜ 메디슨 규격팀 팀장
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
Medical Device Software Development
7. Modular and structured design
SYSTEM ANALYSIS AND DESIGN
Product Support BCA Exercise – JRATS/JTAMS
Software Requirements
BU IS GIG Chemical, Oil & Gas
Engineering Processes
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Standards.
PSS verification and validation
© Oxford University Press All rights reserved.
SISTEMA Example Three.
Presentation transcript:

Prepared By: Certified Compliance Solutions, Inc. August 2012 Defensible Compliance For IEC 62304:2006 Matrix Model for Software Item Safety Classification Prepared By: Certified Compliance Solutions, Inc. August 2012 © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Industry Challenges: IEC 62304:2006 is an FDA-recognized standard applicable to medical devices that contain software, accessories to medical devices that contain software, and "standalone software" that meets the definition of a device or accessory. IEC 62304:2006 requires manufacturers to define a life-cycle model that maps to the processes, activities and tasks described in the standard. Software item safety classification is required © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Current Situation: IEC 62304:2006 section 4.3 defines the following criteria for the decomposition of software into safety classes: 4.3 d) When a software system is decomposed into software items, and when a software item is decomposed into further items, such software items shall inherit the software safety classification of the original software item (or software system) unless the manufacturer documents a rationale for classification into a different software safety class. Such a rationale shall explain how the software items are segregated so that they may be classified separately. 4.3 g) For each software system, until a software safety class is assigned, Class C requirements shall apply. © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Current Situation: The only example of “segregation” provided in IEC 62304:2006 is listed below: 5.3.5 NOTE: An example of segregation is to have software items execute on different processors. The effectiveness of the segregation can be assured by having no shared resources between the processors. © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Current Situation: Other references in IEC 62304:2006 suggest the definition of safety class should be based on the software items directly associated with safety risks. References include: 7.2.2 b) assign a software safety class to the software item based on the possible effects of the hazard that the risk control measure is controlling; 7.1.1 The manufacturer shall identify software items that contribute to a hazardous situation identified in the medical device risk analysis activity of ISO 14971 © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Current Situation Risk is also discussed in the FDA’s General Principles of Software Validation, Final Guidance (GPSV). Note: There is no reference to hierarchical design in the FDA’s GPSV. Section 5.2.5 The magnitude of effort to be applied throughout the testing process can be linked to complexity, criticality, reliability, and/or safety issues (e.g., requiring functions or modules that produce critical outcomes to be challenged with intensive testing of their fault tolerance features). © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Current Situation: Unit 1 Unit 2 Unit 3 Unit 4 Unit 5 Unit 6 Unit 7 Unit 8 Unit 9 Unit 10 Unit 11 Hierarchical Decomposition of Software: Frequently imposed as a result of an attempt to support traceability from a Requirements Specification to a Design Description to Code. Targeted to a user audience and not the designer or programmer. © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Software Item Safety Classification What is the Solution? © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 What is the Solution? Step 1: Create a Block Diagram of the Software Architecture For example: © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 What is the Solution? Step 2: Create a Matrix Model that allows functional aspects of the Software to be mapped to software architecture items For example: © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 What is the Solution? Step 3: Populate the Functional Aspects Column of the Matrix Model from corresponding major sections of the Software Requirements Specification. For example: © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 What is the Solution? Step 4: Populate the Functional Safety Class (A, B, C) Column of the Matrix Model in accordance with the Device Risk Analysis and IEC 62304:2006 criteria. For example: © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 What is the Solution? Step 5: Populate the SW Items column based upon the SW Architecture Diagram. Complete the Matrix Model by filling in the safety class of the Functional Aspect(s) relevant to each SW Item. For example: © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 What is the Solution? Step 6: Complete the bottom row of the Matrix Model, Overall Component Safety Class, according to the highest safety class of each software item. For example: © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Conclusion A pure hierarchical decomposition of software requirements to software design in order to document traceability from software requirements to software design is of questionable value and creates a gap from the user view to the design view This Matrix Model aligns safety requirements with contemporary software engineering design methods to more easily define the safety classification for software items © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.

Defensible Compliance for IEC 62304:2006 Software Item Safety Classification Please contact us for assistance in implementing the Matrix Model for software item safety classification 11665 Avena Place Suite 203 San Diego, CA 92128 www.certifiedcompliance.com (858) 675-8200 © Copyright 2012 Certified Compliance Solutions, Inc. All rights reserved.