-
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
2/56
2011 IBM Corporation
Software and Systems Engineering | Rational
2
IEC 62304 Overview
Standards Landscape
Key elements of IEC 62304
IBM Rational solution
Recommendation
Conclusion
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
3/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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)
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
4/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
5/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
6/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
7/56 2011 IBM Corporation
Software and Systems Engineering | Rational
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
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)
Traceabilityfor Test Coverage
PanPo
Quality Assurance Phase
RskMameaSeyAemePo
System Design & Analysis
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
8/56 2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
9/56 2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
10/56 2011 IBM Corporation
Software and Systems Engineering | Rational
10
IEC 62304 Risk Management Traceability, Verification
Requirements
User Needs
System
Sub-system
DesignImplementation
Risk Management File
RequirementsCapture & Analysis
SystemsAnalysis & Design
SystemAcceptance
(Sub-)SystemIntegration & Test
ModuleIntegration & Test
SW Design
Implementation& Unit Test
CustomerNeeds
DevelopConcept
Product /SystemBuild
ProductDefinition
Product /SystemDeliver
Run /Support /Maintain
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
11/56 2011 IBM Corporation
Software and Systems Engineering | Rational
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%
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
12/56
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
13/56
2011 IBM Corporation
Software and Systems Engineering | Rational
13
Segregation of Software Items
C
BC
C C C A A
AC
B B
SOFTWARE SYSTEM
SOFTWARE ITEMS
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
14/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
15/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
16/56
2011 IBM Corporation
Software and Systems Engineering | Rational
16
Example Fault Tree Analysis
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
17/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
18/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
19/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
20/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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)
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
21/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Verification and Validation Plan
Risk Management Plan
Example DOORS Templates andPre-Defined Views
Design and Development Plan
Risk Assessment View in Design
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
22/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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, andanalysis of the impact.
Auditable record compliance
Electronic signature and document management
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
23/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Unlimited hierarchy of Projects/Folders supports scalability
Organize Your Projects
DOORS DocumentsFoldersProjects
DOORS Database View
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
24/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Everything you need in one window!
Improves productivity, reduces errors, increases quality
DOORS Document Views
OLE
Context
Requirements
Spell check
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
25/56
2011 IBM Corporation
Software and Systems Engineering | Rational
See status quickly and concisely
Change bars and link indicators; instant traceability
DOORS views
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
26/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Attribute columns in a spreadsheet-like view
Rich information; one window
DOORS views
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
27/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
28/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
29/56
2011 IBM Corporation
Software and Systems Engineering | Rational
29
Connecting FTA to Requirements (TraceToReq)
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
30/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
31/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
activities and define responsibility forimplementation.
The plans shallidentify and 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 designrequirements 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 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)
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 Co ntrolGuidance 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. 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
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
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
32/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Drag-and-drop to link
within a document . . .. . . or from
document to
document
Traceability: drag-and-drop linking
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
33/56
2011 IBM Corporation
Software and Systems Engineering | Rational
1. 820.30(b) Design and DevelopmentPlanningach manufacturershallestablish and maintain plans that describe or reference thedesign and development
activities and define responsibility forimplementation.
The plans shallidentify and describe the interfaces with differentgroups or activities thatprovide, or result
in, inputto the designand developmentprocess.
The plans shallbe reviewed as design and development evolves.The plans shallbe updated as design anddevelopmentevolves.
The plans shallbe approved as designand developmentevolves.
2. 820.30(c) DesignInput2.1. Each manufacturershallestablish procedures to ensure thatthe designrequirements 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 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)
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 asunique 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. 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 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
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 across 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 authorityinformation
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 DevelopmentPlanningach manufacturershallestablish and maintain plans that describe or reference thedesign 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 development evolves.The plans shallbe updated as design anddevelopmentevolves.
The plans shallbe approved as designand developmentevolves.
2. 820.30(c) DesignInput2.1. Each manufacturershallestablish procedures to ensure thatthe designrequirements 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 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)
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 asunique 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. 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 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
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 across 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 authorityinformation
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
Traceability view
End-to-end visual validation in a single view
User Needs Requirements Test CasesSpecifications
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
34/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Increasescustomerconfidence
Detect
missing links
Creationand deletionof links is
recorded inhistory
Traceability through an Orphan report shows missing links
Traceability Verification or Completeness
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
35/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Standard DOORS Traceability Tools
Link Matrix
Object Properties
Link Popups
Traceability Columns
Traceability Explorer
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
36/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
37/56
2011 IBM Corporation
Software and Systems Engineering | Rational
What are Suspect Links?
a change by
this user here
shows up as a
warning flag to thisuser here.
If documents are linked
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
38/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
39/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Current
Version
Previous
Baseline
Change
History
History and Baselines
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
40/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Provides a concise list of differences as a single report
Baseline Compare
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
41/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
42/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
43/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Some Typical Issues
Reuse of existing documents and data
Risk AnalysisQualification 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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
44/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
45/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
46/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
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
S f d S E i i | R i l
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
47/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
48/56
2011 IBM Corporation
Software and Systems Engineering | Rational
48
S ft d S t E i i | R ti l
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
49/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
Software and Systems Engineering | Rational
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 -
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
50/56
2011 IBM Corporation
Software and Systems Engineering | Rational
Back-up
Software and Systems Engineering | Rational
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
51/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
Software and Systems Engineering | Rational
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
52/56
2011 IBM Corporation
Software and Systems Engineering | Rational
52
Safety Metamodel
Software and Systems Engineering | Rational
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
53/56
2011 IBM Corporation
Software and Systems Engineering | Rational
53
Fault Tree Analysis is defined in IEC 61025
Software and Systems Engineering | RationalShow link to IEC sections
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
54/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
55/56
2011 IBM Corporation
Software and Systems Engineering | Rational
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
Software and Systems Engineering | Rational
-
8/4/2019 Webinar-Managing Life Cycle Requirements for Medical Device SW Pre IEC
56/56
Software and Systems Engineering | Rational
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