Webinar-Managing Life Cycle Requirements For Medical Device SW Pre IEC

Suresh Wadhwani IBM Software, Rational
How to achieve compliance with IEC 62304 for medical device software development
Innovation for a smarter planet

2011 IBM Corporation
Software and Systems Engineering | Rational
IEC 62304 Overview
Standards Landscape
Key elements of IEC 62304
IBM Rational solution
Recommendation
Conclusion
IEC 62304 Overview

IEC 62304:2006 Medical device software Software life cycle processes Software use should not cause any unacceptable risk with respect to safety and effectiveness of the device Focused on software development and maintenance processes for medical devices but does not specify the methodologies, artifacts or life cycle models themselves Derived from ISO/IEC 12207, a general standard for software processes Adoption
FDA Consensus Standard since September 2008 FDA regards complying with IEC62304 as fulfilling Software Development Environment Description section of the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices Normative standard in Europe for conformance marking
Standard available for purchase from ISO website (~$225 USD) 3
IEC 62304 Structure

Set of interrelated or interacting activities that transforms inputs into outputs
Processes
Activities
Set of interrelated or interacting tasks
Tasks
Single piece of work that needs to be done and results in a deliverable
What IEC 62304 does not do

Does not cover validation and final release of a medical device
Does not specify an organizational structure
You can do have a hierarchical, matrix, or mixed organization
Does not specify the content of the documentation to be developed

You need to show traceability through all the artifacts but not in some set format
Does not prescribe a specific lifecycle model

Waterfall, Iterative, Evolutionary, it is all up to you
Standards Landscape
Quality management system RISK MANAGEMENT Software safety classification Software development PROCESS Software development planning Software requirements analysis Software ARCHITECTURAL design Software detailed design
SOFTWARE UNIT implementation and verification

Software integration and integration testing SOFTWARE SYSTEM testing Software release
Software maintenance PROCESS

Software RISK MANAGEMENT PROCESS Software configuration management PROCESS Software problem resolution PROCESS
Source: European Medical Device & Technology, June 2010
Note: ISO 14971 is a Normative standard for Risk Management Process 6
IEC 62304 Software Development Lifecycle - Model

DEFINITION / DEVELOPMENT System Requirements Phase TEST / VERIFICATION
System & Stakeholder Requirements Definition
Output: System Requirements Doc. (SRD) Traceability for Test Coverage
System Verification Test

Output: System Verification Test Procedure (SVTP) and Results (SVTR)
Software Requirements Phase
Coding Phase
Configuration Management
Risk Management and Safety Assessment Process
Traceability SRS to SRD
System Design & Analysis Software Requirements Def Safety Classification

Output: Software Requirements Spec. (SRS)
Traceability for Test Coverage
H/W - S/W Integration Test

Output: S/W Verification Cases and Procedures (SVCP) and Results (SVR)
Software Design Phase
Planning Process
Traceability SDD to SRS
Software Design Definition

Output: Software Design Description (SDD)
Traceability for Test Coverage
Unit/Integration Testing
Output: S/W Verification Cases and Procedures (SVCP) and Results (SVR)
Traceability SC to SDD
Coding
Output: Source and Object Code
Traceability Test Coverage
Code Review
Output: Source Code Review and Analysis Data
Configuration Management Change Management (Problem Reporting) Quality Assurance Phase
IEC 62304 Software Risk Management - Process

Analysis of software contributing to hazardous situations Software risk management in addition to ISO 14971 (see also IEC 80002 for specifics) Adds RISK CONTROL measures to Requirements Includes software to control MEDICAL DEVICE RISKS Allows for Design Risk Management (Bottoms
Customer Needs
Develop Concept
Product Definition
Product / System Build
Product / System Deliver
Run / Support / Maintain
Requirements Capture & Analysis Reporting, Version & Change Mgmt Systems Analysis & Design
System Acceptance
(Sub-)System Integration & Test
Up)
Complements Functional Risk Management (Top
SW Design Module Integration & Test
Down)
Risk Management applied recursively throughout product lifecycle Documentation various tools, safety assurance 8 cases
Risk Management File
Implementation & Unit Test Best Practices
IEC 62304 Risk Management - Approach

Anticipate possible failures of the system Define control measures Inherently safe Preventive Corrective Informative Systematic risk analysis is to anticipate failures Top-down: Function analysis - ISO 14971, FTA o Hazard Analysis Bottom-up: Design/ Process Analysis FMEA o Failure Modes and Effects Analysis Each failure leads to risk control (RCM) measures Each RCM leads to requirements implemented in product hardware, software or documentation Risk Management File documents traceably risk to control measure, to verification of control measure Risk Management Activities continue after release
User Needs System Sub-system Design Implementation Product Function
Hazards Failures
Design RCMs Requirements

IEC 62304 Risk Management Traceability, Verification

Document TRACEABILITY of software HAZARDS From hazardous situation to the SOFTWARE ITEM From SOFTWARE ITEM to the specific software cause From the software cause to RISK CONTROL measure From RISK CONTROL measure to VERIFICATION of RISK CONTROL measure
Customer Needs Develop Concept Product Definition Product / System Build Product / System Deliver Run / Support / Maintain
Requirements
Requirements Capture & Analysis
User Needs System Sub-system Design Implementation
Reporting, Version & Change Mgmt Systems Analysis & Design
System Acceptance
SW Design
Module Integration & Test

Safety & Fault Tree Analysis
Implementation & Unit Test
Best Practices
10
62304 Safety Classifications
The software safety classes shall initially be assigned based on severity as follows: Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible
Class C 100% of 62304 activities apply Class B 93% Class A 43%
11
62304: Software Systems, Items, & Safety Classifications

Software Systems are comprised of Software Items Software Systems are assigned a Safety Classification Software Items inherit the Safety Classification of the System If the HAZARD could arise from the failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100%
Unless
Higher classification applies unless there is a documented rationale in a Risk Management file to justify lower safety class for software items
12
Segregation of Software Items
SOFTWARE SYSTEM
SOFTWARE ITEMS
13
Safety, risk, and risk management process

Safety is freedom from unacceptable risk.
Safety is not security!

Security is protection of information and data so that unauthorized people or systems cannot read or modify them , and so that authorized people or systems are not denied access to them.
Risk is a product of severity and probability of occurrence Software Risk Management Process: - identify software items that could contribute to a hazardous situation - identify causes of contribution to a hazardous situation - define risk control measures - verify risk control measures
Document traceability: Hazardous situation to software item to specific software cause to risk control measure to verification of risk control measure
14
Hazard and Fault Tree Analysis
Fault Tree Analysis determines what combinations of conditions or events are necessary for a hazard condition to occur
Fault Tree Analysis allows the developer to identify, control and lower the risk to an acceptable level
This is critical in the IEC 62304 standard
Example Fault Tree Analysis
16
Design Redundancy for Safety
The key to safe systems is to analyze the system and to identify the conditions and events that can lead to hazards
Fault Tree Analysis (FTA) determines what logical combination of events and conditions lead to faults
By adding ANDing-redundancy, architectural redundancy can be added
17
Recommendations
Determine compliance with IEC 62304 by performing gap analysis

Create a chart that maps IEC 62304 clauses and subclauses to company procedure(s) The mapping chart can be a standalone document, or it can be an appendix to a companys procedure(s).
Address open issues revealed in gap analysis

Establish missing processes Amend deficient processes Deploy appropriate software development tools that execute or enforce your processes
Document updated software development process showing compliance with IEC 62304
Mapping chart should now have 100% coverage of IEC 62304 clauses within your processes
18
Some Typical Issues

Reuse of existing documents and data
Risk Analysis
Qualification of requirements
Must have, want to have, nice to have, source, product version etc.
Traceability
Multiple levels required due to the complexity of the systems
Change Control
Who made a change, when the change was made, why the change was made, and analysis of the impact.
Auditable record compliance

Electronic signature and document management
Import All Your Data & Create Documents

MS-Word
MS-Word
Word Direct Entry Microsoft HTML RTF ASCII

MS-Word
PowerPoint
Excel Outlook
RTF OLE ASCII
Spreadsheet
DOORS
MS-Project
Spreadsheet
MS-Project Tool Integrations*

FrameMaker ReqIF (XML) Print Rational Publishing Engine
Tool Integrations*
FrameMaker RIF (XML)
Example DOORS Templates and Pre-Defined Views

Verification and Validation Plan
Risk Assessment View in Design
Risk Management Plan Design and Development Plan
Some Typical Issues

Risk Analysis
Traceability
Change Control

DOORS Database View

Unlimited hierarchy of Projects/Folders supports scalability
Folders Projects DOORS Documents
Organize Your Projects

DOORS Document Views

Everything you need in one window!
Spell check
Context
Requirements
OLE
Improves productivity, reduces errors, increases quality

DOORS views
Change bars and link indicators; instant traceability
See status quickly and concisely

DOORS views
Attribute columns in a spreadsheet-like view
Rich information; one window

Unlimited user defined attributes

Unlimited number of attributes in a spreadsheet-like view Values can be calculated for metrics collection Automates your regulatory persons ability to show compliance
Model Driven Analysis and Design

using Rational Rhapsody and Rational DOORS Visualize requirements and build architecture Integrates requirements, design and implementation Execution validates requirements Facilitates communication across disciplines Impact analysis of changes in requirements or design
Trace requirements to design and implementation
Requirement information generated in code 28 2011 IBM Corporation
Connecting FTA to Requirements (TraceToReq)
29
Some Typical Issues

Risk Analysis
Traceability
Change Control

Traceability is the key to compliance

User Needs
1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy?
Requirements Specifications
1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design Identify impacted elements due to a change in another element 1.1. and development activities 1. Capture design and related informationand define responsibility for implementation. 1. Capture design and related information Traceability Reports: consistency with driving design elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data Impact Reports: other design elements affected information sources The plans shall 1.2. Reference external information sources identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external Links to impacted design elements in, input to 1.3. Reference external documentation the design and development process. 1.3. Reference external documentation
Test Cases
1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1. Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3. Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4. Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6. Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1. Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines
1.1.1. Create backward traces to design elements within and across any organizational
2.
3.
4.
5.
6.
The plans Store design and related information shall be reviewed as design and development evolves. 2. Store design and related information procedure The plans shall be updated as elements 2.1. Identify and tag design information as unique design design and development evolves. 2.1. Identify and tag design information as unique design elements Traceability Reports: Procedure Attribute The 2.2. Organize design elements plans shall be approved as design and development evolves. 2.2. Organize design elements 1.1.2. Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Traceability Reports: MilestoneOrganize by inter-relationships 2.2.2. Organize by inter-relationships Design Input 2.2.2. Attribute 2.1. Each 2.3. Ensure all design elements are availablemanufacturer shall establish procedures to ensure that the design requirements relating to backward traces to design elements within and are available 2.3. Ensure all design elements across Design Control 1.1.3. Create a device are appropriate and address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Design Control Guidance Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements and patient. 2.3.2. Store design elements and their historical values 2.3.2. Store design elements and their historical values Traceability Reports: Linked design elements 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the 1.1.4.of the user needs Create forward impacts to design elements within and across any organizational Manage all user needs 3. Manage all user needs and procedure 3.1. Identify the source of the user need patient. 3.1. Identify the source of the user need 2.3. 3.2. Identify all user types (groups) The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure Identify all user types (groups) 3.2. Attribute 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer (s) 3.3. Identify the customer and 1.1.5. Create forward impacts to design elements within(s) across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Impact Reports: Milestone State the intended use of the product (family) 3.5. State the intended use of the 2.6. The design input requirements shall be documented by a designated individual(s). product (family) 3.5. Attribute 2.7. each user input 3.6. Capture the acceptance criteria forThe designneed requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and acrosseach user need 3.6. Capture the acceptance criteria for Design Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, Manage design input requirements 4. Manage design input Impact Reports: Linked design elements requirements shall 4.1. Identify the source of the requirement be documented. 4.1. Identify the source of the 1.2. Associate changed design elements with related elements requirement 2.10. 4.2. Identify the associated user need Questions. 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of with affected design element(s) Link Change Design Object 4.3. Capture requirement description and attributes 4.3. Capture requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. Capture acceptance criteria Traceability Links and Reports from affected design element(s) 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. Assign responsibility for each Impact Links and Reports from affected design element(s)requirement 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects with following Attributes: 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity 5.3. Document the results of every user need acceptance test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2. Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Change Design Object Traceability Link on Procedure Attribute Manage change 6. Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain on Procedure element changes Change Design Object Impacts Link history of design Attribute 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history 1.2.3. Provide associations within and across any project milestone available 2.10.3.14. reliability 6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational procedure on Milestone Attribute Change Design Object Traceability Link history within and across any project milestone 2.10.3.15. statutory and 6.1.3. Maintain history within and across any project milestone regulatory requirements 6.1.3. Maintain 2.10.3.16. voluntary Guidance Change Design Object Impacts Link on Milestone Attribute any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control standards Elements 6.1.4. Maintain history within and across 2.10.3.17. 6.2. Capture frequency and nature of element changes manufacturing processes 6.2. Capture frequency Control of element Elements 1.2.4. Provide associations within and across Design and natureGuidance changes 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide to traced change Change Design Object Traceability Linkrationale for design elements 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made 2.10.3.20. design history files (DHFs) Change Design Object Impacts Link to linked design elementschange 6.2.3. Identify approval authority for the change 6.2.3. Identify approval authority for the 2.10.4. For the specific design covered, how were the design input requirementsMange the change process 1.3. identified? 6.2.4. Capture date, time, and signature of approving authority 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For another element 6.3. Identify impacted elements due to a change in the specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in another element Design adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone
Object History Object History Reports Versions Baselines
Initial user needs should be decomposed to detailed requirements, then to design specification, tests, etc.
Decomposition creates traceability relationships

Relationships define your traceability model Your traceability model is a reflection your process Enforce your traceability model; improve your process
Traceability: drag-and-drop linking
Drag-and-drop to link within a document . . .
. . . or from document to document

Traceability view
User Needs
1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy?
Requirements
Specifications Test Cases

1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1.Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2.Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3.Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4.Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5.Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6.Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1.Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2.Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3.Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4.Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines
1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design Identify impacted elements due to a change in another element 1.1. and development activities 1. Capture design and related informationand define responsibility for implementation. 1. Capture design and related information Traceability Reports: consistency with driving design elements 1.1. Input electronically formatted data 1.1. Input electronically formatted data The plans shall identify and describe the interfaces with different groups or activities that Impact Reports: other design elements affected information sources provide, or result 1.2. Reference external information sources 1.2. Reference external Links to impacted design elements in, input to 1.3. Reference external documentation the design and development process. 1.3. Reference external documentation
1.1.1.Create backward traces to design elements within and across any organizational
The plans 2. Store design and related information shall be reviewed as design and development evolves. 2. Store design and related information procedure The plans shall be updated as elements 2.1. Identify and tag design information as unique design design and development evolves. 2.1. Identify and tag design information as unique design elements Traceability Reports: Procedure Attribute The 2.2. Organize design elements plans shall be approved as design and development evolves. 2.2. Organize design elements 1.1.2.Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Traceability Reports: MilestoneOrganize by inter-relationships 2.2.2. Organize by inter-relationships Design Input 2.2.2. Attribute 2.1. Each 2.3. Ensure all design elements are availablemanufacturer shall establish procedures to ensure that the design requirements relating to backward traces to design elements within and are available 2.3. Ensure all design elements across Design Control 1.1.3.Create a device are appropriate Element 2.3.1. Store design elements by Design Control Guidance and address the intended use of the device, including the needs of the user Elements 2.3.1. Store design elements by Design Control Guidance Element Guidance and patient. 2.3.2. Store design elements and their historical values 2.3.2. Store design elements and their historical values Traceability Reports: Linked design elements 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the 1.1.4.of the user needs Create forward impacts3.to design elements within and across any organizational 3. Manage all user needs Manage all user needs and procedure 3.1. Identify the source of the user need patient. 3.1. Identify the source of the user need 2.3. 3.2. Identify all user types (groups) The procedures shall include a mechanism for addressing incomplete requirements. Impact Reports: Procedure Identify all user types (groups) 3.2. Attribute 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. Create forward impacts to design elements within(s) across any project milestone 3.3. Identify the customer and 1.1.5. 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Impact Reports: Milestone State the intended use of the product (family) 3.5. State the intended use of the 2.6. The design input requirements shall be documented by a designated individual(s). product (family) 3.5. Attribute 2.7. each user input 3.6. Capture the acceptance criteria forThe designneed requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and acrosseach user need 3.6. Capture the acceptance criteria for Design Control 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage design input requirements 4. Manage design input Impact Reports: Linked design elements requirements shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the 1.2. Associate changed design elements with related elements requirement 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of with affected design description Link Change Design Object 4.3. Capture requirementelement(s) and attributes 4.3. Capture requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. Capture acceptance criteria Traceability Links and Reports from affected design element(s) 2.10.2. 4.5. Assign responsibility for each requirementFrom what sources are design inputs sought? 4.5. Assign responsibility for each Impact Links and Reports from affected design element(s)requirement 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1.Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements information 2.10.3.1. intended use 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical 4.9. Approve all requirements 4.9. Approve all requirements Change Decision Objects with following Attributes: 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety 5. Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need 2.10.3.6. risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. toxicity 5.3. Document the results of every user need acceptance test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2.Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Change Design Object Traceability Link on Procedure Attribute 6. Manage change 6. Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain on Procedure element changes Change Design Object Impacts Link history of design Attribute 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available 6.1.1. Make complete change history 1.2.3.Provide associations within and across any project milestone available 2.10.3.14. reliability 6.1.2. Maintain history within and across any organizational procedure 6.1.2. Maintain history within and across any organizational procedure Change Design Object Traceability Link on Milestone Attribute project milestone 2.10.3.15. statutory and 6.1.3. Maintain history within and across any project milestone regulatory requirements 6.1.3. Maintain history within and across any 2.10.3.16. voluntary standards Elements Change Design Object Impacts Link on Milestone Attribute any Design Control Guidance Elements 6.1.4. Maintain history within and across any Design Control Guidance 6.1.4. Maintain history within and across 2.10.3.17. manufacturing processes 6.2. Capture frequency and nature of element changes 6.2. across Design Control of element Elements 1.2.4.Provide associations within andCapture frequency and natureGuidance changes 2.10.3.18. sterility 6.2.1. Provide rationale for change 6.2.1. Provide to traced change Change Design Object Traceability Linkrationale fordesign elements 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made 2.10.3.20. Change Design Object Impacts Link to linked design elementschange 6.2.3. Identify approval authority for the change design history files (DHFs) 6.2.3. Identify approval authority for the 2.10.4. For the specific design 1.3. identified? 6.2.4. Capture date, time, and signature of approving authority covered, how were the design input requirementsMange the change process 6.2.4. Capture date, time, and signature of approving authority 2.10.5. For another element 6.3. Identify impacted elements due to a change in the specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to a change in another element Design adequacy? 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.1. Create backward traces to design elements within and across any organizational procedure Design Change Reports 6.3.2. Create backward traces to design elements within and across any project milestone 6.3.2. Create backward traces to design elements within and across any project milestone
Object History Object History Reports Versions Baselines
End-to-end visual validation in a single view

Traceability Verification or Completeness
Increases customer confidence

Detect missing links Creation and deletion of links is recorded in history
Traceability through an Orphan report shows missing links

Standard DOORS Traceability Tools
Link Matrix Object Properties Link Popups Traceability Columns
Traceability Explorer
Some Typical Issues

Risk Analysis
Traceability
Change Control

What are Suspect Links?
If documents are linked
a change by this user here
shows up as a warning flag to this user here.
Suspect Links
Suspect links are visible directly in the document as indicators or as a full description
Clear on a right click
Never miss a change again

History and Baselines

Current Version
Previous Baseline
Change History
Baseline Compare
Provides a concise list of differences as a single report

Differentiating Change Management
Lifecycle Change Management

Rational Change, ClearQuest or Team Concert for multiple, configurable processes Flexible process, user definable states Integrated into full lifecycle change process Multiple approvers
DOORS Change Proposal System - CPS

Providing a built in change process for requirements Predefined process Changes only applied on approval
Manage Change for Good Manufacturing Practice (GMP) Establish an integrated change process across the lifecycle
Capture customer requests & market driven enhancements Manage Portfolio & Product Priorities
Execute Tests
Testing Eco-system
Collaboration, Process, Workflow

Integrated Change Management
Capture & manage requirements
Configuration Management
Develop Model-Driven System -> Software
Collaborate across Development Disciplines Software Electrical Mechanical

42
Integrate Suppliers
Some Typical Issues

Risk Analysis
Traceability
Change Control

Electronic Signature
Electronic signature against baselines directly in DOORS provides:
Accountability
Audit capability Quality procedures Verification of intent Documented consensus and decision making Conformance with FDA 21 CFR part 11
Provides full accountability without external tools
High Quality, Compliant Documents in minutes

using Rational Publishing Engine
Template driven document generation ensures the output complies with any required formatting standards and contains correct branding and legal information Support for multiple output formats (MS Word, HTML, PDF, XSLFO)
Flexible output
45 2011 IBM Corporation
IBM Rational Software Platform for Systems

Full coverage of the systems engineering lifecycle
Product / System Build Product / System Deliver Run / Support / Maintain
Customer Needs
Develop Concept
Product Definition
Spans the entire systems and software lifecycle Integrates complex systems, embedded software and IT to create innovative products Achieves end-to-end traceability
Requirements Capture & Analysis Reporting, Version & Change Mgmt Systems Analysis & Design
System Acceptance
SW Design
Module Integration & Test
Implementation & Unit Test Best Practices
Provides proof of compliance
46
IBM Rational Solution for Medical Devices

Execute best practices and collaborate through an integrated product lifecycle solution
Deliver medical devices that address market needs through portfolio management Provide clear audit trail across the development lifecycle with requirements management Validate designs early with model driven development Integrate change processes to coordinate development Automate document generation for compliance Drive quality throughout the product lifecycle
Powered by
47
48
Learn more at: IBM Rational software IBM Rational Software Delivery Platform Process and portfolio management Change and release management Quality management Architecture management
Rational trial downloads Leading Innovation Web site developerWorks Rational IBM Rational TV IBM Business Partners IBM Rational Case Studies
Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBMs sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
Back-up
Safety-Related Concepts
Accident is a loss of some kind, such as injury, death, or equipment damage Risk is a combination of the likelihood of an accident and its severity: risk = p(a) * s(a) A Hazard is a set of conditions and/or events that leads to an accident.
Hazards are predictable and therefore controllable A safety-relevant system contains two kinds of hazards Intrinsic hazards - due to the inherent job and operational environment of the system Technology hazards - due to the addition of specific technological solutions
A safety control measure is an action or mechanism to improve the safety of the system by either
Reducing the severity of the accident Reducing the likelihood of the accident
A fault is the nonperformance of a system or component and may be either random or systematic Fault Tree Analysis determines what combinations of conditions or events are necessary for a hazard condition to occur
Allows the developer to lower the risk of a Safety violation, critical for IEC 62304
51
Safety Metamodel
52
Fault Tree Analysis is defined in IEC 61025
53
Show link to IEC sections
Develop Systems and Software in a Model-Driven way
Visually develop complex systems using a structured approach

Traceability from requirements -> implementation Automate FDA documentation submission Visual modeling manages complexity Generates production quality code Reduce testing time with model-driven testing Leverage existing code for documentation
54
Show link to IEC sections
Automate Document Generation
Generate the right document at the right time

Increase productivity by allowing engineers to focus on engineering
NOT formatting concerns
Maintain accuracy through quick one-click document generation

Captures last minute changes from data held in different source applications
Enhance documentation quality thru template reuse
55
Manage Requirements across the Product Lifecycle
Capture, define, analyze, and manage requirements

Improves visibility and collaboration
Accurate documentation for regulatory audits and reviews
Supports FDA CFR21 Part 11 compliant electronic signatures Integrates with:

Portfolio management Modeling change management Quality management solutions
56

Webinar-Managing Life Cycle Requirements For Medical Device SW Pre IEC

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Webinar-Managing Life Cycle Requirements For Medical Device SW Pre IEC

Hochgeladen von

Copyright:

Verfügbare Formate

Suresh Wadhwani IBM Software, Rational

Innovation for a smarter planet

Software and Systems Engineering | Rational

IEC 62304 Overview

IBM Rational solution

2011 IBM Corporation

Software and Systems Engineering | Rational

IEC 62304 Overview

Standard available for purchase from ISO website (~$225 USD) 3

2011 IBM Corporation

Software and Systems Engineering | Rational

IEC 62304 Structure

Set of interrelated or interacting tasks

Single piece of work that needs to be done and results in a deliverable

2011 IBM Corporation

Software and Systems Engineering | Rational

What IEC 62304 does not do

Does not specify the content of the documentation to be developed

Does not prescribe a specific lifecycle model

2011 IBM Corporation

Software and Systems Engineering | Rational

SOFTWARE UNIT implementation and verification

Software maintenance PROCESS

Note: ISO 14971 is a Normative standard for Risk Management Process 6

2011 IBM Corporation

Software and Systems Engineering | Rational

IEC 62304 Software Development Lifecycle - Model

System Verification Test

Software Requirements Phase

Risk Management and Safety Assessment Process

Traceability SRS to SRD

System Design & Analysis Software Requirements Def Safety Classification

Traceability for Test Coverage

H/W - S/W Integration Test

Software Design Phase

Traceability SDD to SRS

Software Design Definition

Traceability for Test Coverage

Traceability Test Coverage

Configuration Management Change Management (Problem Reporting) Quality Assurance Phase

2011 IBM Corporation

Software and Systems Engineering | Rational

IEC 62304 Software Risk Management - Process

Product / System Build

Product / System Deliver

Run / Support / Maintain

(Sub-)System Integration & Test

2011 IBM Corporation

Software and Systems Engineering | Rational

IEC 62304 Risk Management - Approach

Risk Management File

Software and Systems Engineering | Rational

IEC 62304 Risk Management Traceability, Verification

Requirements Capture & Analysis

User Needs System Sub-system Design Implementation

Reporting, Version & Change Mgmt Systems Analysis & Design

(Sub-)System Integration & Test

Module Integration & Test

Risk Management File

Implementation & Unit Test

2011 IBM Corporation

Software and Systems Engineering | Rational