webinar-managing life cycle requirements for medical device sw pre iec

8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC

1/56

2011 IBM Corporation

Innovation for a smarter planet

How to achieve compliance with IEC 62304 for medicaldevice software development

Suresh WadhwaniIBM Software, Rational


2/56


Software and Systems Engineering | Rational

2

IEC 62304 Overview

Standards Landscape

Key elements of IEC 62304

IBM Rational solution

Recommendation

Conclusion


3/56



3

IEC 62304 Overview

IEC 62304:2006Medical device software Software life cycle processes

Software use should not cause any unacceptable risk with respect to safety andeffectiveness 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 Descriptionsection of the Guidance for the Content of Premarket Submissions for Software Contained in MedicalDevices

Normative standard in Europe for conformance marking

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


4/56



4

IEC 62304 Structure

Activities

ProcessesSet of interrelated or interactingactivities that transforms inputs intooutputs

Tasks

Set of interrelated or interacting tasks

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


5/56



5

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 setformat

Does not prescribe a specific lifecycle model

Waterfall, Iterative, Evolutionary, it is all up to you


6/56



6

Standards Landscape

Source: European Medical Device & Technology, June 2010

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 integrationtesting

SOFTWARE SYSTEM testing

Software release

Software maintenance PROCESS

Software RISK MANAGEMENTPROCESS

Software configuration managementPROCESS

Software problem resolution PROCESS

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


7/56 2011 IBM Corporation


7

IEC 62304 Software Development Lifecycle - Model

System

Requirements

Phase

Configuration

Management

SoftwareDesign

Phase

Coding

Phase

Software

Requirements

Phase Software Requirements Def

Safety ClassificationOutput: SoftwareRequirements Spec. (SRS)

Software Design DefinitionOutput: Software DesignDescription (SDD)

CodingOutput: Source and ObjectCode

Code ReviewOutput: Source CodeReview and Analysis Data

Unit/Integration TestingOutput: S/W VerificationCases and Procedures(SVCP) and Results (SVR)

H/W - S/W Integration TestOutput: S/W VerificationCases and Procedures(SVCP) and Results (SVR)

DEFINITION / DEVELOPMENT TEST / VERIFICATION

TraceabilitySRS to SRD

TraceabilitySDD to SRS

Traceabilityfor Test Coverage


TraceabilityTest

Coverage

Change Management (Problem Reporting)Configuration Management

System & StakeholderRequirements DefinitionOutput: SystemRequirements Doc. (SRD)

TraceabilitySC to SDD

System Verification TestOutput: System VerificationTest Procedure (SVTP) andResults (SVTR)


PanPo

Quality Assurance Phase

RskMameaSeyAemePo

System Design & Analysis




8

IEC 62304 Software Risk Management - Process

RequirementsCapture & Analysis

SystemsAnalysis & Design

SystemAcceptance

(Sub-)SystemIntegration & Test

ModuleIntegration & TestSW Design

Implementation& Unit Test

CustomerNeeds

DevelopConcept

Product /SystemBuild

ProductDefinition

Product /SystemDeliver

Run /Support /Maintain

Reporting,Version &

Change Mgmt

BestPractices

RiskManagement

File

Software risk managementin addition to ISO 14971(see also IEC 80002 forspecifics)

Adds RISK CONTROLmeasures to Requirements

Includes software to controlMEDICAL DEVICE RISKS

Allows for Design Risk

Management (BottomsUp)

Complements Functional

Risk Management (TopDown)

Risk Management appliedrecursively throughoutproduct lifecycle

Documentation various

tools, safety assurancecases

Analysis of software contributing to hazardous situations




9

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, FTAo Hazard AnalysisBottom-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 inproduct hardware, software or documentation

Risk Management File documents traceably risk tocontrol measure, to verification of control measure

Risk Management Activities continue after release

Hazards

Failures

RCMs

Requirements

User Needs

System

Sub-system

Design

Implementation

Risk ManagementFile

Product Function

Design




10

IEC 62304 Risk Management Traceability, Verification

Requirements

User Needs

System

Sub-system

DesignImplementation

Risk Management File



SystemAcceptance


ModuleIntegration & Test

SW Design


CustomerNeeds

DevelopConcept


ProductDefinition



Reporting,Version &

Change Mgmt

BestPractices

Safety & FaultTree Analysis

Document TRACEABILITY of software HAZARDSFrom hazardous situation to the SOFTWARE ITEMFrom SOFTWARE ITEM to the specific software causeFrom the software cause to RISK CONTROL measureFrom RISK CONTROL measure to VERIFICATION of RISK CONTROL measure




11

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%


12/56


13/56



13

Segregation of Software Items

C

BC

C C C A A

AC

B B

SOFTWARE SYSTEM

SOFTWARE ITEMS


14/56



14

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 modifythem , 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 riskcontrol measure


15/56



Hazard and Fault Tree Analysis

Fault Tree Analysis determines what combinations of conditions or events are necessary for ahazard condition to occur

Fault Tree Analysis allows the developer to identify, control and lower the risk to anacceptable level

This is critical in the IEC 62304 standard


16/56



16

Example Fault Tree Analysis


17/56



Design Redundancy for Safety

The key to safe systems is to analyze the system and to identify the conditions and eventsthat can lead to hazards

Fault Tree Analysis (FTA) determines what logical combination of events and conditions leadto faults

By adding ANDing-redundancy, architectural redundancy can be added

17


18/56



18

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


19/56



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 ofthe impact.

Auditable record compliance

Electronic signature and document management


20/56



Import All Your Data & Create Documents

DOORS

ASCII

Spreadsheet

MS-Project

Tool Integrations*

FrameMaker

HTML

PowerPoint

Word

Outlook

ExcelMicrosoft

MS-WordRTF

OLEASCII

Spreadsheet

MS-Project

Tool Integrations*

FrameMaker

MS-Word

RTFMS-Word

Print

Direct Entry

Rational Publishing EngineReqIF (XML)RIF (XML)


21/56



Verification and Validation Plan

Risk Management Plan

Example DOORS Templates andPre-Defined Views

Design and Development Plan

Risk Assessment View in Design


22/56



Some Typical Issues


Risk Analysis



Traceability


Change Control

Who made a change, when the change was made, why the change was made, andanalysis of the impact.




23/56



Unlimited hierarchy of Projects/Folders supports scalability

Organize Your Projects

DOORS DocumentsFoldersProjects

DOORS Database View


24/56



Everything you need in one window!

Improves productivity, reduces errors, increases quality

DOORS Document Views

OLE

Context

Requirements

Spell check


25/56



See status quickly and concisely

Change bars and link indicators; instant traceability

DOORS views


26/56



Attribute columns in a spreadsheet-like view

Rich information; one window

DOORS views


27/56



Unlimited number of attributes in a spreadsheet-like view

Values can be calculated for metrics collectionAutomates your regulatory persons ability to show compliance

Unlimited user defined attributes


28/56



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 requirementsto design and

implementation

Requirementinformation

generated in code

Model Driven Analysis and Designusing Rational Rhapsody and Rational DOORS

28


29/56



29

Connecting FTA to Requirements (TraceToReq)


30/56



Some Typical Issues


Risk Analysis



Traceability


Change Control





31/56



1.

820.30(b) Design and DevelopmentPlanning

ach manufacturershallestablish and maintain plans thatdescribe or reference the design and development

activities and define responsibility forimplementation.

The plans shallidentifyand describe the interfaces with differentgroups or activities thatprovide, or result

in, inputto the designand developmentprocess.

The plans shallbe reviewed as design and developmentevolves.

The plans shallbe updated as design and developmentevolves.

The plans shallbe approved as design and developmentevolves.

2. 820.30(c) DesignInput2.1. Each manufacturershallestablish procedures to ensure thatthe design requirements relating toa

device are appropriate and addressthe intended useof the device, including the needs of the user

and patient.

2.2. Each manufacturershallmaintain procedures to ensure thatthe design requirements relating to adevice are appropriate and addressthe intended useof the device, including the needs of the user

and patient.

2.3. The procedures shallinclude a mechanism for addressing incomplete requirements.2.4. The procedures shallinclude a mechanism for addressing ambiguous requirements.2.5. The procedures shallinclude a mechanism for addressing conflicting requirements.2.6. The design inputrequirements shall be documented by a designated individual(s).2.7. The design inputrequirements shall be reviewed by a designated individual(s).2.8. The design inputrequirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature ofthe individual(s)approvingthe requirements,

shallbe documented.

2.10.Questions.2.10.1. Summarize the manufacturer's written procedure(s)foridentification and control of

design input.

2.10.2. From whatsources are design inputs sought?2.10.3. Do design inputprocedures cover the relevantaspects, such as:(Mark all thatapply and

listadditionalaspects.)

2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environmentof intended use2.10.3.11. human factors2.10.3.12. physical/chemicalcharacteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historicaldata2.10.3.20. design history files (DHFs)

2.10.4. For the specific design covered, how were the design inputrequirements identified?2.10.5. For the specific design covered, how were the design inputrequirements reviewed for

adequacy?

Comply with FDA Design ControlGuidance GMP Regulation

1. Capture design and related information1.1. Inputelectronically formatted data1.2. Reference externalinformationsources1.3. Reference externaldocumentation

2. Store design andrelated information2.1. Identify and tagdesign information as unique design elements2.2. Organize design elements

2.2.1.Organize byDesign ControlGuidance Element2.2.2.Organize byinter-relationships

2.3. Ensure alldesign elements are available2.3.1.Store design elements byDesign ControlGuidance Element2.3.2.Store design elements andtheir historicalvalues

3. Manage alluser needs3.1. Identify the source of the user need3.2. Identify alluser types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended useof the product(family)3.6. Capture the acceptance criteria foreach user need

4. Manage design inputrequirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirementdescription andattributes4.4. Capture acceptance criteria4.5. Assign responsibility for eachrequirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approveallrequirements

5. Manage acceptance5.1. Ensure the acceptance ofeveryuser need5.2. Ensure the acceptance ofeverydesign inputrequirement5.3.

Documentthe results of every user need acceptance test5.4. Documentthe results of every design inputrequirements test

5.5. Make acceptance results available6. Manage change

6.1. Maintain history of design elementchanges6.1.1.Make complete change history available6.1.2.Maintain history within and acrossany organizationalprocedure6.1.3.Maintain history within and acrossany projectmilestone6.1.4.Maintain history within and across any Design ControlGuidance Elements

6.2. Capture frequency and nature of element changes6.2.1.Provide rationale forchange6.2.2.Describe decisions made6.2.3.Identify approvalauthority for thechange6.2.4.Capture date, time, and signatureof approvingauthority

6.3. Identify impacted elements due to a changein another element6.3.1.Create backward traces to design elements within and acrossany organizationalprocedure6.3.2.Create backward traces to design elements within and acrossany projectmilestone

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 elements1.1.1.Create backward traces to design elements within and across any organizational

procedure

Traceability Reports: Procedure Attribute1.1.2.Create backward traces to design elements within and ac ross any project milestone

Traceability Reports: Milestone Attribute1.1.3.Create backward traces to design elements within and across Design Control

Guidance Elements

Traceability Reports: Linked design elements1.1.4.Create forward impacts to design elements within and across any organizational

procedure

Impact Reports: Procedure Attribute1.1.5.Create forward impacts to design elements within and across any project milestone

Impact Reports: Milestone Attribute1.1.6.Create forward impacts to design elements within and across Design Control

Guidance Elements

Impact Reports: Linked design elements1.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 DevelopmentPlanning

ach manufacturershallestablish and maintain plans thatdescribe or reference the design and development


The plans shallidentify and describe the interfaces with differentgroups or activities thatprovide, or result


The plans shallbe reviewed as design and developmentevolves.

The plans shallbe updated as design and developmentevolves.

The plans shallbe approved as design and developmentevolves.

2. 820.30(c) DesignInput2.1. Each manufacturershallestablish procedures to ensure thatthe designrequirements relating toa


and patient.

2.2. Each manufacturershallmaintain procedures to ensure thatthe design requirements relating to adevice are appropriate and addressthe intended useof the device, including the needs of the user

and patient.

2.3. The procedures shallinclude a mechanism foraddressing incomplete requirements.2.4. The procedures shallinclude a mechanism foraddressing ambiguous requirements.2.5. The procedures shallinclude a mechanism foraddressing conflicting requirements.2.6. The design inputrequirements shall be documented by a designated individual(s).2.7. The design inputrequirements shall be reviewed by a designated individual(s).2.8. The design inputrequirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature ofthe individual(s)approvingthe requirements,

shallbe documented.

2.10.Questions.2.10.1. Summarize the manufacturer's written procedure(s)foridentification and control of

design input.

2.10.2. From whatsources are design inputs sought?2.10.3. Do design inputprocedures cover the relevantaspects, such as:(M ark allthat apply and

listadditionalaspects.)

2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environmentof intended use2.10.3.11. human factors2.10.3.12. physical/chemicalcharacteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)


adequacy?

Comply with FDA Design Co ntrolGuidance GMP Regulation


2. Store design andrelated information2.1. Identify and tagdesign information as unique design elements2.2. Organize design elements




4. Manage design inputrequirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirementdescription andattributes4.4. Capture acceptance criteria4.5. Assign responsibility for eachrequirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approveall requirements

5. Manage acceptance5.1. Ensure the acceptance ofeveryuser need5.2. Ensure the acceptance ofeverydesign inputrequirement5.3.

Documentthe results of every user need acceptance test5.4. Documentthe results of every design inputrequirements test

5.5. Make acceptance results available6. Manage change

6.1. Maintain history of design elementchanges6.1.1.Make complete change history available6.1.2.Maintain history within and acrossany organizationalprocedure6.1.3.Maintain history within and acrossany projectmilestone6.1.4.Maintain history within and across any Design ControlGuidance Elements

6.2. Capture frequency and nature of element changes6.2.1.Provide rationale forchange6.2.2.Describe decisions made6.2.3.Identify approvalauthority for thechange6.2.4.Capture date, time, and signatureof approving authority

6.3. Identify impacted elements due to a changein another element6.3.1.Create backward traces to design elements within and acrossany organizationalprocedure6.3.2.Create backward traces to design elements within and acrossany projectmilestone


procedure

Traceability Reports: Procedure Attribute1.1.2.Create backward traces to design elements within and ac ross any project milestone


Guidance Elements


procedure



Guidance 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






User Needs Requirements Test CasesSpecificationsTraceability is the key to compliance

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


32/56



Drag-and-drop to link

within a document . . .. . . or from

document to

document

Traceability: drag-and-drop linking


33/56



1. 820.30(b) Design and DevelopmentPlanningach manufacturershallestablish and maintain plans that describe or reference thedesign and development


The plans shallidentify and describe the interfaces with differentgroups or activities thatprovide, or result


The plans shallbe reviewed as design and development evolves.The plans shallbe updated as design anddevelopmentevolves.

The plans shallbe approved as designand developmentevolves.



and patient.

2.2. Each manufacturershallmaintain procedures to ensure that the designrequirements relating to adevice are appropriate and addressthe intended useof the device, including the needs of the user

and patient.

2.3. The procedures shallinclude a mechanism foraddressing incomplete requirements.2.4. The procedures shallinclude a mechanism foraddressing ambiguous requirements.2.5. The procedures shallinclude a mechanism foraddressing conflicting requirements.2.6. The design inputrequirements shallbe documented by a designated individual(s).2.7. The design inputrequirements shallbe reviewed by a designated individual(s).2.8. The design inputrequirements shallbe approved by a designated individual(s).2.9. The approval, including the date and signature ofthe individual(s)approvingthe requirements,

shallbe documented.

2.10.Questions.2.10.1. Summarize the manufacturer's written procedure(s)foridentification and controlof

design input.

2.10.2. From whatsources are design inputs sought?2.10.3. Do design inputprocedures cover the relevantaspects, such as:(Mark allthat apply and

listadditionalaspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environmentof intended use2.10.3.11. human factors2.10.3.12. physical/chemicalcharacteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historicaldata2.10.3.20. design history files (DHFs)


adequacy?



2. Store design andrelated information2.1. Identify and tagdesign information asunique design elements2.2. Organize design elements





5. Manage acceptance5.1. Ensure the acceptance ofeveryuser need5.2. Ensure the acceptance ofeverydesign inputrequirement5.3. Documentthe results of every user need acceptance test5.4. Documentthe results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design elementchanges

6.1.1.Make complete change history available6.1.2.Maintain history within and acrossany organizationalprocedure6.1.3.Maintain history within and across any projectmilestone6.1.4.Maintain history within and acrossany Design ControlG uidance Elements

6.2. Capture frequency and nature of elementchanges6.2.1.Provide rationale forchange6.2.2.Describe decisions made6.2.3.Identify approvalauthority for thechange6.2.4.Capture date, time, and signatureof approving authority

6.3. Identify impacted elements due to a changein another element6.3.1.Create backward traces to design elements within and across anyorganizationalprocedure6.3.2.Create backward traces to design elements within and across anyproject milestone


procedure

Traceability Reports: Procedure Attribute1.1.2.Create backward traces to design elements within and across any project milestone


Guidance Elements


procedure



Guidance 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 authorityinformation






1. 820.30(b) Design and DevelopmentPlanningach manufacturershallestablish and maintain plans that describe or reference thedesign and development


The plans shallidentifyand describe the interfaces with differentgroups or activities thatprovide, or result


The plans shallbe reviewed as design and development evolves.The plans shallbe updated as design anddevelopmentevolves.

The plans shallbe approved as designand developmentevolves.



and patient.

2.2. Each manufacturershallmaintain procedures to ensure that the designrequirements relating to adevice are appropriate and addressthe intended useof the device, including the needs of the user

and patient.

2.3. The procedures shallinclude a mechanism foraddressing incomplete requirements.2.4. The procedures shallinclude a mechanism foraddressing ambiguous requirements.2.5. The procedures shallinclude a m echanism foraddressing conflicting requirements.2.6. The design inputrequirements shallbe documented by a designated individual(s).2.7. The design inputrequirements shallbe reviewed by a designated individual(s).2.8. The design inputrequirements shallbe approved by a designated individual(s).2.9. The approval, including the date and signature ofthe individual(s)approvingthe requirements,

shallbe documented.

2.10.Questions.2.10.1. Summarize the manufacturer's written procedure(s)foridentification and controlof

design input.

2.10.2. From whatsources are design inputs sought?2.10.3. Do design inputprocedures cover the relevantaspects, such as:(Mark allthat apply and

listadditionalaspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environmentof intended use2.10.3.11. human factors2.10.3.12. physical/chemicalcharacteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historicaldata2.10.3.20. design history files (DHFs)


adequacy?



2. Store design andrelated information2.1. Identify and tagdesign information asunique design elements2.2. Organize design elements





5. Manage acceptance5.1. Ensure the acceptance ofeveryuser need5.2. Ensure the acceptance ofeverydesign inputrequirement5.3. Documentthe results of every user need acceptance test5.4. Documentthe results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design elementchanges

6.1.1.Make complete change history available6.1.2.Maintain history within and acrossany organizationalprocedure6.1.3.Maintain history within and acrossany project milestone6.1.4.Maintain history within and acrossany Design ControlGuidance Elements

6.2. Capture frequency and nature of elementchanges6.2.1.Provide rationale forchange6.2.2.Describe decisions made6.2.3.Identify approvalauthority for thechange6.2.4.Capture date, time, and signatureof approving authority

6.3. Identify impacted elements due to a changein another element6.3.1.Create backward traces to design elements within and across anyorganizationalprocedure6.3.2.Create backward traces to design elements within and across anyproject milestone


procedure

Traceability Reports: Procedure Attribute1.1.2.Create backward traces to design elements within and across any project milestone


Guidance Elements


procedure



Guidance 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 authorityinformation






Traceability view

End-to-end visual validation in a single view

User Needs Requirements Test CasesSpecifications


34/56



Increasescustomerconfidence

Detect

missing links

Creationand deletionof links is

recorded inhistory

Traceability through an Orphan report shows missing links

Traceability Verification or Completeness


35/56



Standard DOORS Traceability Tools

Link Matrix

Object Properties

Link Popups

Traceability Columns

Traceability Explorer


36/56



Some Typical Issues


Risk Analysis



Traceability


Change Control





37/56



What are Suspect Links?

a change by

this user here

shows up as a

warning flag to thisuser here.

If documents are linked


38/56



Suspect links are visible directly in the document -

as indicators or as a full description

Never miss a change again

Suspect Links

Clear on a right click


39/56



Current

Version

Previous

Baseline

Change

History

History and Baselines


40/56



Provides a concise list of differences as a single report

Baseline Compare


41/56



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


42/56



42

Manage Change for Good Manufacturing Practice (GMP)Establish an integrated change process across the lifecycle

Testing Eco-system

ManagePortfolio &

ProductPriorities

DevelopModel-Driven

System -> Software

Collaboration,Process, Workflow

ExecuteTests

Capture &manage

requirements

IntegratedChange

Management

Configuration Management

Integrate Suppliers

Capture customerrequests & market

driven enhancements

Mechanical

Collaborate acrossDevelopment Disciplines

Electrical

Software


43/56



Some Typical Issues


Risk AnalysisQualification of requirements


Traceability


Change Control





44/56



Electronic Signature

Electronic signature against baselines directly in DOORS provides:

Accountability

Audit capability

Quality procedures

Verification of intent

Documented consensus

and decision making

Conformance withFDA 21 CFR part 11

Provides full accountability without external tools


45/56



High Quality, Compliant Documents in minutes

Template driven document generation ensures the output complieswith any required formatting standards and contains correctbranding and legal information

Support for multiple output formats (MS Word, HTML, PDF, XSL-FO)

Flexibleoutput

using Rational Publishing Engine

45


46/56



46

IBM Rational Software Platform for SystemsFull coverage of the systems engineering lifecycle

Spans the entire systemsand software lifecycle

Integrates complex

systems, embeddedsoftware and IT to createinnovative products

Achieves end-to-endtraceability

Provides proof ofcompliance



SystemAcceptance


ModuleIntegration & TestSW Design


CustomerNeeds

DevelopConcept


ProductDefinition



Reporting,Version &

Change Mgmt

BestPractices

S f d S E i i | R i l


47/56



47

IBM Rational Solution for Medical Devices

Deliver medical devices that address market needs throughportfolio 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

Execute best practices and collaborate through anintegrated product lifecycle solution

Poweredby

S ft d S t E i i | R ti l


48/56



48

S ft d S t E i i | R ti l


49/56



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 warrantiesor 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 onmarket 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 aretrademarks 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.

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

http://www.ibm.com/software/rationalhttp://www-306.ibm.com/software/info/developer/index.jsphttp://www-306.ibm.com/software/rational/offerings/lifecycle.htmlhttp://www-306.ibm.com/software/rational/offerings/scm.htmlhttp://www-306.ibm.com/software/rational/offerings/testing.htmlhttp://www-306.ibm.com/software/rational/offerings/design.htmlhttp://www.ibm.com/developerworks/rational/downloads/?S_TACT=105AGX23&S_CMP=RCDhttp://www-306.ibm.com/software/rational/leadership/leaders/http://www.ibm.com/developerworks/rationalhttp://www-306.ibm.com/software/info/television/index.jsp?cat=rational&media=video&item=en_us/rational/xml/M259765N40519Z80.xmlhttp://www-306.ibm.com/software/rational/partners/http://www-01.ibm.com/software/success/cssdb.nsf/topstoriesFM?OpenForm&Site=rationalhttp://www-01.ibm.com/software/success/cssdb.nsf/topstoriesFM?OpenForm&Site=rationalhttp://www-306.ibm.com/software/rational/partners/http://www-306.ibm.com/software/info/television/index.jsp?cat=rational&media=video&item=en_us/rational/xml/M259765N40519Z80.xmlhttp://www.ibm.com/developerworks/rationalhttp://www-306.ibm.com/software/rational/leadership/leaders/http://www.ibm.com/developerworks/rational/downloads/?S_TACT=105AGX23&S_CMP=RCDhttp://www-306.ibm.com/software/rational/offerings/design.htmlhttp://www-306.ibm.com/software/rational/offerings/testing.htmlhttp://www-306.ibm.com/software/rational/offerings/scm.htmlhttp://www-306.ibm.com/software/rational/offerings/lifecycle.htmlhttp://www-306.ibm.com/software/info/developer/index.jsphttp://www.ibm.com/software/rational


50/56



Back-up



51/56



51

Safety-Related Concepts Accidentis a loss of some kind, such as injury, death, or equipment damage

Riskis a combination of the likelihood of an accident and its severity:

risk = p(a) * s(a)

A Hazardis 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

systemTechnology hazards - due to the addition of specific technological solutions

A safety control measureis an action or mechanism to improve the safety of the system byeither

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 orsystematic

Fault Tree Analysis determines what combinations of conditions or events are necessary for ahazard condition to occur

Allows the developer to lower the risk of a Safety violation, critical for IEC 62304



52/56



52

Safety Metamodel



53/56



53

Fault Tree Analysis is defined in IEC 61025

Software and Systems Engineering | RationalShow link to IEC sections


54/56



54

Develop Systems and Software in a Model-Driven wayVisually 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

Software and Systems Engineering | RationalShow link to IEC sections


55/56



55

Automate Document GenerationGenerate the right document at the right time

Increase productivity by allowingengineers to focus onengineering

NOT formatting concerns

Maintain accuracy through quickone-click document generation

Captures last minute changesfrom data held in different sourceapplications

Enhance documentation qualitythru template reuse



56/56


Manage Requirements across the Product LifecycleCapture, define, analyze, and manage requirements

Improves visibility and collaboration

Accurate documentation forregulatory audits and reviews

Supports FDA CFR21 Part 11

compliant electronic signatures

Integrates with:

Portfolio management

Modeling

change managementQuality management solutions