defensible compliance for iec 62304:2006 matrix model for software item safety classification...

Defensible Compliance ForIEC 62304:2006

Matrix Model forSoftware 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

2© Copyright 2012 Certified Compliance Solutions, Inc.

All rights reserved.


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.




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.




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




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).




Current Situation: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.

7

Unit 1

Unit 2 Unit 3 Unit 4

Unit 5 Unit 6 Unit 7

Unit 8 Unit 9

Unit 10

Unit 11



Software Item Safety Classification

What is the Solution?



What is the Solution?Step 1: Create a Block Diagram of the Software

ArchitectureFor example:




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:




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:




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:




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:




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:



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




Software Item Safety Classification Please contact us for assistance in implementing

the Matrix Model for software item safety classification

11665 Avena Place Suite 203San Diego, CA 92128

www.certifiedcompliance.com(858) 675-8200



http://www.certifiedcompliance.com/

defensible compliance for iec 62304:2006 matrix model for software item safety classification...

Documents

software items

software system

standalone software

decomposition of software

software safety classification

original software item

defensible compliance

certified compliance