Medical Device Software - Software Life Cycle Processes - SoftwareCPR
Transcript of Medical Device Software - Software Life Cycle Processes - SoftwareCPR
![Page 1: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/1.jpg)
18/14/2008
Medical Device Software -Software Life Cycle Processes
IEC 62304
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 2: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/2.jpg)
28/14/2008
Credits• John F. Murray
Software Compliance ExpertU.S. Food and Drug Administration
• Marcie R. WilliamsM di l D i F llMedical Device FellowPh.D. Candidate, Georgia Institute of Technology
• IEC 62304 Working Group
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 3: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/3.jpg)
38/14/2008
History of IEC 62304y
• Good Manufacturing Practices – 1976g• Quality Systems Regulation – 1996
– (Design Controls)(Design Controls)• General Principles of Software
Validation 1998 2002Validation – 1998-2002• SW68 – 2001• IEC 62304 - 2006
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 4: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/4.jpg)
48/14/2008
There is no known method to guarantee 100 % SAFETY forguarantee 100 % SAFETY for
any kind of software.(Annex B.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 5: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/5.jpg)
58/14/2008
Software Assurance• Establishing the safety and effectiveness
of medical device software (Introduction ¶ 1)
• Method:– Define the intended use of the software– Demonstrate that the software fulfills those
intentionsDemonstrate that the software does not cause– Demonstrate that the software does not cause any unacceptable risks
(Introduction ¶ 1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 6: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/6.jpg)
68/14/2008
Purpose of IEC 62304p• To define the life cycle requirements for medical
device software(Introduction ¶ 2)
• To establish a common framework for medical device software life cycle processes– Life cycle should be well described and broken into
processes, activities, and tasks which will be performedperformed
– Testing is not sufficient to establish safety(1 Scope, 1.1 & Annex A.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 7: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/7.jpg)
78/14/2008
Field of Applicationpp
• Development and Maintenance of Medical pDevice Software
(1 Scope, 1.2)
• Medical Device Software =– Software which is a medical deviceSoftware which is a medical device– Software which is part of a medical device(1 Scope, 1.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 8: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/8.jpg)
88/14/2008
Compliancep• Quality Management System
ISO 13485– ISO 13485(4 General Requirements, 4.1)
• Risk Management ProcessRisk Management Process– ISO 14971(4 General Requirements, 4.2)
• Implement the processes, activities, and tasks described in this standard (IEC 62304)
N ifi i ti l t t f th– No specific organizational structure for the manufacturer is specified
(1 Scope, 1.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 9: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/9.jpg)
98/14/2008
General Requirementsq• Documentation of tasks shall be produced
– No specific format for this documentation is specified
(Introduction ¶ 7)(Introduction ¶ 7)
• A life cycle shall be established– Map processes, activities, and tasks in this
standard to the life cycle model of the manufacturer’s choosingmanufacturer s choosing
– No particular life cycle is specified(Introduction ¶ 8)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 10: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/10.jpg)
108/14/2008
Classification SchemesSoftware Safety Classification Level of ConcernClassification
IEC 62304(4 General Requirements, 4.3)
Guidance for the Content of Pre-market Submissions for Software Contained in Medical
Devices
Cl A N i j d t Mi F il l t t d i flClass A: No injury or damage to health is possible
Minor: Failures or latent design flaws are unlikely to cause any injury
Class B: Non Serious injury is Moderate: Failure or latent designClass B: Non-Serious injury is possible
Moderate: Failure or latent design flaw could directly or indirectly result in minor injury
Cl C D th S i i j M j F il fl ld di tlClass C: Death or Serious injury is possible
Major: Failure or flaw could directly or indirectly result in death or serious injury
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 11: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/11.jpg)
118/14/2008
Software Safety Classificationy
• Risk ControlRisk Control• Segregation of Software
Software SystemSoftware System(Class C)
Software Item Software Item X
(Class A)Y
(Class C)
(4 General Requirements, 4.3)
Software Item Z
(Class C)
Software Item W
(Class B)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
( q , )
![Page 12: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/12.jpg)
128/14/2008
Benefits of IEC 62304
• Enhances the reliability of the software by y yrequiring detail or rigor in the design, testing, or verification(Annex A.1)
• Enhances the safety of medical device softwaresoftware
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 13: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/13.jpg)
138/14/2008
Life Cycle Processesy
• Software Development Processp• Software Risk Management Process• Software Configuration Process• Software Configuration Process• Software Problem Resolution Process• Software Maintenance Process
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 14: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/14.jpg)
Customer Needs or Maintenance Request
Software Development Planning
Software Requirements Analysis
Establish Software Maintenance Plan
Problem and modification analysis
Software Architectural Design
Software DetailedSoftware Detailed Design
Software unit implementation and verification Modification
Implementation
Risk Management Configuration Management
Problem Resolution
Software integration and integration testing
Software system
Implementation
Software system testing
Software Release
Customer Needs and Maintenance Requests Satisfied(Introduction, Figures 1 & 2)
![Page 15: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/15.jpg)
158/14/2008
Software Development
Software Development Planning
Software Requirements Analysis Software Development
ProcessSoftware Architectural Design
Software Detailed
5.1 Software Development Planning
Design
Software unit implementation and verification
PlanningSoftware integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 16: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/16.jpg)
168/14/2008What is Software Development
Planning?Planning?• Thinking through the softwareThinking through the software
development process and creating a document which describes all of thedocument which describes all of the events that will occur during the software life cyclelife cycle– Planning performed before you DO the work– Allows for allocation of time and resources– Allows for allocation of time and resources
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 17: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/17.jpg)
178/14/2008
Planning is an iterative activity that should be re-examined and updatedshould be re examined and updated
as development progresses.(Annex B.5.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 18: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/18.jpg)
188/14/2008
Software Development Planp• Manufacturer shall establish a plan
Pl h ld b i t t th• Plan should be appropriate to the scope, magnitude, and software safety classifications of the system to be developedof the system to be developed
• Documentation of tasks to be performed may be in a single plan or multiple plansbe in a single plan or multiple plans– May also reference previously existing policies and
procedures for the manufacturer
(5 Software Development Process, 5.1.1 and Annex B.5.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 19: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/19.jpg)
198/14/2008System Engineering vs. Software
EngineeringEngineering• Software requirements shall reference
system requirements
• Plan should coordinate software development with a quality managementdevelopment with a quality management system
(5 Software Development Process, 5.1.3)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 20: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/20.jpg)
208/14/2008
Types of Planningyp g
• Software Integration Planningg g• Software Verification Planning• Risk Management Planning• Risk Management Planning• Documentation Planning• Configuration Management Planning
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 21: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/21.jpg)
218/14/2008
Software Development Planning
Software Requirements Analysis
5.2 Software Software Architectural Design
Software Detailed
Requirements AnalysisDesign
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 22: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/22.jpg)
228/14/2008What is Software Requirements
Analysis?Analysis?• Establishing and verifying software requirements• Software requirements are:
– Formally documented specifications of what the software does to meet the customer needs
• System and software requirements might be the same if the software is a software only devicesame if the software is a software-only device(Annex B.5.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 23: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/23.jpg)
238/14/2008Value of Software Requirement AnalysisAnalysis
• Establishing verifiable requirements is essential for:Establishing verifiable requirements is essential for:– Determining what is to be built– Determining that the software exhibits acceptable behavior– Demonstrating that the software is ready for use
(Annex B.5.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 24: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/24.jpg)
248/14/2008
Software Requirements• Content:
Functional and capability requirements– Functional and capability requirements– Software system inputs and outputs– Interfaces between the software system and other
systems– Software-driven alarms, warnings, and operator
messagesmessages– Security requirements– Usability engineering requirements sensitive to human
errors and trainingerrors and training(5 Software Development Process, 5.2.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 25: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/25.jpg)
258/14/2008
Software Requirements• Content, continued:
D t d fi iti d d t b i t– Data definition and database requirements– Installation and acceptance requirements – Requirements related to methods of operation and– Requirements related to methods of operation and
maintenance– User documentation to be developed– User maintenance requirements– Regulatory requirements
(5 Software Development Process, 5.2.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 26: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/26.jpg)
268/14/2008 Risk Control & Software RequirementsRequirements
• Requirements should include risk control measures
• When software requirements are established, risk analysis should be re-, yevaluated and kept updated(5 Software Development Process 5 2 3 & 5 2 4)(5 Software Development Process, 5.2.3 & 5.2.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 27: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/27.jpg)
278/14/2008Characteristics of Good Software RequirementsRequirements
• Implement system requirements (including risk control)risk control)
• Are traceable to system requirements• Can be uniquely identified• Can be uniquely identified• Do not contradict each other• Language is not ambiguous• Language is not ambiguous• Permit establishment of test criteria • Permit performance of tests to evaluate if• Permit performance of tests to evaluate if
test criteria have been met(5 Software Development Process 5 2 6 and Annex B 5 2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
(5 Software Development Process, 5.2.6 and Annex B.5.2)
![Page 28: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/28.jpg)
288/14/2008
Software Development Planning
Software Requirements Analysis
5.3 Software Software Architectural Design
Software Detailed
Architectural DesignDesign
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 29: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/29.jpg)
298/14/2008
Software Architectural Design
• Architecture describes software structure and identifies software items
• Describes interfaces for software items• Identifies segregation necessary for risk
controlcontrol(5 Software Development Process, 5.3.1-5.3.5)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 30: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/30.jpg)
308/14/2008 Architectural Design and Off the Shelf SoftwareOff-the-Shelf Software
• Specifies functional and performance requirements of off-the-shelf software
• Specifies hardware and software required p qby off-the-shelf software(5 Software Development Process 5 3 1-5 3 6)(5 Software Development Process, 5.3.1 5.3.6)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 31: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/31.jpg)
318/14/2008
Software Architecture Verification
• Verify and Document that:y– Architecture implements system and software
requirements, including risk control– Architecture supports interfaces between
software and hardware– Architecture supports proper operation of off-
the-shelf software
(5 Software Development Process, 5.3.6)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 32: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/32.jpg)
328/14/2008
Value of Architectural Designg
• Risk Managementg• Allocation of Resources• Problem Definition• Problem Definition
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 33: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/33.jpg)
338/14/2008
Software Development Planning
Software Requirements Analysis
5.4 Software Detailed Software Architectural Design
Software Detailed
DesignDesign
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 34: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/34.jpg)
348/14/2008
What is Detailed Design?g• Refining software items described in the
architecture to create software units and interfaces
• Each software unit can be tested separately• The software design fills in the details necessary
t t t th ftto construct the software– Programmers should not be required to make ad hoc
decisions during codingdecisions during coding
(Annex B.5.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 35: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/35.jpg)
358/14/2008
Detailed Design
• Develop detailed design for each software unit
• Develop detailed design for interfacesp g• Verify and document that the software unit:
– Implements the architectural designImplements the architectural design– Is free from contradiction with the architecture
(5 Software Development Process, 5.4.1-5.4.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 36: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/36.jpg)
368/14/2008
Value of Detailed Design• Form of design control
Allows for review and management oversight– Allows for review and management oversight
Mi i i d f t i ti• Minimizes defect insertion
• If the detailed design contains defects, the code will not implement the requirements p qcorrectly(Annex B 5 4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
(Annex B.5.4)
![Page 37: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/37.jpg)
378/14/2008
Software Development Planning
Software Requirements Analysis
5.5 Software Unit Implementation and
Software Architectural Design
Software Detailed Implementation and Verification
Design
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 38: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/38.jpg)
388/14/2008What is Unit Implementation and
Verification?Verification?• Translating the detailed design into source
code • This is the point where decomposition of
the specifications ends and composition of the executable software begins.
• To consistently achieve desired results, coding standards should be used.
• The source code should be verified.(Annex B.5.5)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 39: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/39.jpg)
398/14/2008
Implementation and Verification
• Implement each software unit– Unit should have a configuration ID
• Verify each software unit according to procedures established by the manufacturerprocedures established by the manufacturer
(5 Software Development Process 5 5 1 & 5 5 2)(5 Software Development Process, 5.5.1 & 5.5.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 40: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/40.jpg)
408/14/2008
Acceptance Criteria• Manufacturer must establish acceptance criteria for each software unit• As appropriate criteria should address:• As appropriate, criteria should address:
– Software requirements– Conformance with programming procedures or coding standards
Event sequence– Event sequence– Data and control flow– Resource allocation
Fault handling– Fault handling– Initialization of variables– Self diagnostics
Memory management– Memory management– Boundary Conditions
(5 Software Development Process, 5.5.3 & 5.5.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
( p , )
![Page 41: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/41.jpg)
418/14/2008
Value of Unit Implementationp
• The medical device software should perform as intended if the code correctly implements a properly developed detailed p p p y pdesign
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 42: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/42.jpg)
428/14/2008
Software Development Planning
Software Requirements Analysis
5.6 Software Integration Software Architectural Design
Software Detailed
and Integration TestingDesign
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 43: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/43.jpg)
438/14/2008
What is software integration and testing?
C bi i ft it t f t• Combining software units to form aggregate software items
• Combining software items into higher aggregated software items
• Verify that the resulting software items behave as intended(Annex B.5.6)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 44: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/44.jpg)
448/14/2008
Integration• Integrate software units according to integration plan
• Test integrated software according to integration plan
• Evaluate test results and procedures for correctness
• Perform regression tests on previously integrated software as appropriate
(5 Software Development Process, 5.6.1-5.6.5)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 45: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/45.jpg)
458/14/2008
Integration Testingg g• Focus on transfer of data and control across a software
item’s internal and external interfacesitem s internal and external interfaces
• Rigor of testing and level of detail commensurate with:g g– the risk associated with the device– the device’s dependence on software for potentially hazardous
functions– the role of specific software items in higher risk functions
• Items that have an effect on safety should be subject to• Items that have an effect on safety should be subject to more direct, thorough, and detailed tests.(Annex B.5.6)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 46: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/46.jpg)
468/14/2008Types of Testing
The Toolbox-The Toolbox-• White Box Testing
Gl B– Glass Box– Structural– Clear Box– Open Box
• Black Box TestingBehavioral– Behavioral
– Functional– Opaque-box– Closed-box
(Annex B.5.6)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 47: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/47.jpg)
478/14/2008
Integration Records and Problem Resolution
• Integration records should include:g– Test results and a list of anomalies– Information to permit a repeat of the test
Identification of tester– Identification of tester
• Problem Resolution– Anomalies shall be entered into the software problem resolution
process
(5 Software Development Process, 5.6.7-5.6.8)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 48: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/48.jpg)
488/14/2008
Value of Integrationg
• Verifies that the software behaves as intended
• Verifies that transfer of data and controlVerifies that transfer of data and control across interfaces performs correctly
• Provides assurance commensurate with• Provides assurance commensurate with the risk of the device’s dependence on softwaresoftware
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 49: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/49.jpg)
498/14/2008
Software Development Planning
Software Requirements Analysis
5.7 Software System Software Architectural Design
Software Detailed
TestingDesign
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 50: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/50.jpg)
508/14/2008
What is Software System Testing?y g
• Performing tests and verification gprocedures on the entire software system following integrationg g
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 51: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/51.jpg)
518/14/2008
System Testing• Establish and perform tests on software system
E t li i t ft bl l ti• Enter anomalies into software problem resolution process• Retest if changes are made• Verify that:• Verify that:
– Verification methods and test procedures are appropriate– System test procedures trace to software requirements– All software requirements have been tested or verified– Test results meet the require pass/fail criteria
(5 Software Development Process, 5.7.1 – 5.7.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 52: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/52.jpg)
528/14/2008
Planning for System Testingg y g• Software and hardware tests can be performed in a
simulated or actual environmentsimulated or actual environment• Test responsibilities can be dispersed across various
locations and organizations– It is ultimately the manufacturers responsibility to ensure that the
software functions properly for its intended use• Anomalies that are identified should be evaluated for
their effect on the safety of the device– If it is decided that these anomalies will not be fixed a rationale
for this must be documented
(Annex B.5.7)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 53: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/53.jpg)
538/14/2008
Value of System Testingy g
• Testing (attempts to) demonstrate that the g ( p )specified functionality exists by verifying that the requirements for the software qhave been successfully implemented.
• Results in a Finished Device(Annex B.5.7)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 54: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/54.jpg)
548/14/2008
Software Development Planning
Software Requirements Analysis
5 8 Software ReleaseSoftware Architectural Design
Software Detailed 5.8 Software ReleaseDesign
Software unit implementation and verification
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 55: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/55.jpg)
558/14/2008
Prior to Software Release• Ensure verification is complete
D t k id l li• Document known residual anomalies• Evaluate known residual anomalies• Document released versions• Document released versions• Document how software was created• Ensure activities and tasks in design plan are complete\g p p• Archive software• Assure repeatability of software release
(5 Software Development Process, 5.8.1-5.8.8)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 56: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/56.jpg)
568/14/2008Value of Software Release
ControlsControls• Ensures that the manufacturer documents the
version of the medical device being releasedversion of the medical device being released• Allows manufacturer to demonstrate that the
software was developed using a quality systemg y y• Allows manufacturer to retrieve the software and
the tools used for its generation in case it is needed for future useneeded for future use
• Provides documentation for the device master record and the device history record (820.181 & 820 184)820.184)(Annex B.5.8)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 57: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/57.jpg)
578/14/2008
GPSV IEC 623045 2 1 Q lit Pl i 5 1 S ft d l t l i5.2.1 Quality Planning 5.1 Software development planning
5.2.2 Requirements 5.2 Software requirements analysis
5.2.3 Design 5.3 Software architectural design 5.4 Software detailed design
5.2.4 Construction or Coding 5.5 Software unit implementation and ifi tiverification
5.6 Software integration and integration testing
5.2.5 Testing by the software developer 5.5 Software unit implementation and verification5.6 Software integration and integration testingg5.7 Software system testing
5.2.6 User Site Testing 5.7 Software system testing
5 2 7 M i t d S ft Ch 6 S ft M i t PThe CDRH Software Education Program
Center for Devices and Radiological HealthUS Food & Drug Administration
5.2.7 Maintenance and Software Changes 6 Software Maintenance Process
![Page 58: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/58.jpg)
588/14/2008
Where’s Waldo?
• Software Development Processp• Software Risk Management Process• Software Configuration Process• Software Configuration Process• Software Problem Resolution Process• Software Maintenance Process
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 59: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/59.jpg)
598/14/2008
Software Risk Management ProcessRisk Management
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 60: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/60.jpg)
608/14/2008Important Concepts for Risk
ManagementManagement• Software risk management is a part of overall medical
device risk managementdevice risk management– Cannot be adequately addressed in isolation
• Risk Management process in this standard provides additional risk control requirements specifically foradditional risk control requirements specifically for software
• This process is included because:– Manufacturers and regulators need to understand the minimumManufacturers and regulators need to understand the minimum
risk control measures necessary in their area of responsibility (software)
– The general risk management standard (ISO 14971) does not specifically address the risk control of software and its place inspecifically address the risk control of software and its place in the software development life cycle
(Annex B.7.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 61: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/61.jpg)
618/14/2008
Requirements of Risk Management q gProcess
• Use of a process that is compliant with ISO 14971• Use of a process that is compliant with ISO 14971• Must have a documented software risk management
plan• Hazard analysis must identify hazardous situations and
risk control measures to reduce the probability and/or the severity of these situations to an acceptable level
• Risk control measures will be assigned to software functions that are expected to implement those risk control measures(Annex B.7.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 62: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/62.jpg)
628/14/2008
7.1 Software and Hazardous SituationsRisk Management
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 63: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/63.jpg)
638/14/2008
7.1 Software and Hazardous Situations
• Identify software items that contribute to a yhazardous situation
• Identify potential causes of this hazard(7 Software Risk Management Process, 7.1.1 & 7.1.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 64: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/64.jpg)
648/14/2008
7.1 Software and Hazardous Situations
E l t P bli h d SOUP li li t• Evaluate Published SOUP anomalies list– If SOUP is a potential cause of a hazardous
i isituation– Identify any sequence of events that could
l d t h it tilead to such a situation(7 Software Risk Management Process, 7.1.3)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 65: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/65.jpg)
658/14/2008
7.1 Software and Hazardous Situations
D t• Document:– Potential causes of the software item
ib i h d i icontributing to a hazardous situation– Sequences of events that could result in a
h d it tihazardous situation(7 Software Risk Management Process, 7.1.4 - 7.1.5)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 66: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/66.jpg)
668/14/2008
7.2 Risk Control MeasuresRisk Management
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 67: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/67.jpg)
678/14/2008
Define Risk Control Measures
For each potential cause of the software pitem contributing to a hazardous situation documented in the risk management file, gthe manufacturer shall define and document risk control measures.(7 Software Risk Management Process, 7.2.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 68: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/68.jpg)
688/14/2008
Implement Risk Control Measuresp
• Manufacturer is required to:– Include the risk control measure in the
software requirementsA i ft f t l t th ft– Assign a software safety class to the software item based on the possible effects of the hazard that the risk control measure ishazard that the risk control measure is controlling
– Develop the software item in accordance with the software development process
(7 Software Risk Management Process, 7.2.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 69: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/69.jpg)
698/14/2008
7.3 Verification of Risk Control MeasuresRisk Management
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 70: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/70.jpg)
708/14/2008
Verification• Each risk control measure must be
documented and verified– Verification must also be documented
• The manufacturer shall evaluate risk control measures to identify any new sequences of events that could result in a h d it tihazardous situation(7 Software Risk Management Process, 7.3.1 & 7.3.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 71: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/71.jpg)
718/14/2008
Traceabilityy• Document traceability :
– From the hazardous situation to the software item– From the software item to the specific software cause– From the software cause to the risk control measure– From the risk control measure to verification of the
risk control measurerisk control measure
(7 Software Risk Management Process, 7.3.3)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 72: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/72.jpg)
728/14/2008
7.4 Risk Management of Software ChangesRisk Management
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 73: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/73.jpg)
738/14/2008
7.4 Risk Management of Software gChanges
Analyze changes with respect to safety• Analyze changes with respect to safety• Analyze the impact of changes on risk
control measures• Perform risk management activities based
on this analysis(7 Software Risk Management Process, 7.4)( g , )
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 74: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/74.jpg)
748/14/2008
Value of Risk Management gProcess
Method used to identify items of medical• Method used to identify items of medical device software associated with hazards
• Method used to identify hazards that need software as a risk control measure
• Method used to determine allocation of resources and the appropriate critical parts of software
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 75: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/75.jpg)
758/14/2008
Software Configuration Management ProcessConfiguration
Management
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 76: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/76.jpg)
768/14/2008
What is Software Configuration gManagement?
A process of applying administrative andA process of applying administrative and technical procedures throughout the
software life cycle to identify and definesoftware life cycle to identify and define software items, including documentation
(Annex B.8)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 77: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/77.jpg)
778/14/2008
8.1 Configuration Identificationg
• Establish a scheme to identify yconfiguration items
• Configuration items should include SOUPConfiguration items should include SOUP• Document configuration items and their
versions within the software systemversions within the software system(8 Software Risk Management Process, 8.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 78: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/78.jpg)
788/14/2008
8.2 Change Controlg
• Approve Change Requestspp g q• Implement Changes• Verify Changes• Verify Changes(8 Software Risk Management Process, 8.2.1 – 8.2.3)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 79: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/79.jpg)
798/14/2008
8.2 Provide Means for Traceabilityy
• Audit trail for:– Change requests– Problem reportsp– Approval of change requests
(8 Software Risk Management Process 8 2 4)(8 Software Risk Management Process, 8.2.4)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 80: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/80.jpg)
808/14/2008
Value of Software Configuration gManagement
Necessary to recreate a software item• Necessary to recreate a software item• Necessary to identify the constituent parts
of a software item• Provides a history of the changes that
have been made to a software item(Annex B.8)( )
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 81: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/81.jpg)
818/14/2008
Software Problem Resolution ProcessProblem Resolution
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 82: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/82.jpg)
828/14/2008
What is software problem presolution?
A process for analyzing and resolving• A process for analyzing and resolving problems, whatever their nature or source.
Thi i l d th bl di d– This includes those problems discovered during the execution of development, maintenance or other processesmaintenance, or other processes.
(Annex B.9)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 83: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/83.jpg)
838/14/2008
Prepare Problem Reportsp p
• Problem reports should be classified paccording to:– Typeyp– Scope– CriticalityCriticality
(9 Software Risk Management Process, 9.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 84: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/84.jpg)
848/14/2008
Investigate the Problemg• The manufacturer shall:
– Investigate the problem and identify the causesE l t th bl ’ l t f t– Evaluate the problem’s relevance to safety (using Risk Management Process)Document the outcome of the investigation– Document the outcome of the investigation and evaluation
– Create a change request as needed or g qdocument rationale for taking no action
(9 Software Risk Management Process, 9.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
( g )
![Page 85: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/85.jpg)
858/14/2008
Advise, Maintain, and Analyze, , y
• Advise relevant parties of the problemp p• Maintain records of problem reports and
their resolutiontheir resolution• Analyze problems for trends(9 Software Risk Management Process, 9.3 – 9.6)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 86: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/86.jpg)
868/14/2008
Value of Problem Resolution Process
Ensures that discovered problems are• Ensures that discovered problems are analyzed and evaluated for possible relevance to safetyrelevance to safety
• Ensures that problems are handled in a fway which conforms with quality systems
and risk management processes(Annex B.9)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 87: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/87.jpg)
878/14/2008
Software Development Planning
Establish Software Maintenance Plan
Software
Planning
Software Requirements Analysis
Maintenance Plan
Problem and modification analysis
Software Maintenance
Software Architectural Design
Software Detailed Design
ProcessSoftware unit implementation and verification Modification
Implementation
Software integration and integration testing
Software system testing
Software Release
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 88: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/88.jpg)
888/14/2008
Maintenance Process1. Establish Plan
2. Problems and Modification Analysis
3. Implement Changes
(6 Soft are Maintenance Process)(6 Software Maintenance Process)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 89: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/89.jpg)
898/14/2008
Maintenance Process vs. Software Development Process
Manufacturer may use a smaller process• Manufacturer may use a smaller process than the full software development process to implement rapid changes toprocess to implement rapid changes to urgent problems
f• The manufacturer not only addresses the problem but also satisfies local regulations(Annex B.6.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 90: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/90.jpg)
908/14/2008
Establish Software Maintenance Plan
Problem and modification analysis
6.1 Software Maintenance Planmodification analysis
Modification Implementation
Plan
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 91: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/91.jpg)
918/14/2008
Maintenance Plan• Should address the following
Proced res for recei ing doc menting e al ating resol ing and– Procedures for receiving, documenting, evaluating, resolving, and tracking feedback after release of the medical device software
– Criteria for whether feedback is considered a problem– Use of the risk management process– Use of the problem resolution process– Use of the configuration management process– Procedure to evaluate and implement upgrades, bug fixes, patches,
and obsolescence in off-the-shelf software
(6 Software Maintenance Process, 6.1)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 92: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/92.jpg)
928/14/2008
Establish Software Maintenance Plan
Problem and modification analysis
6.2 Problem and Modification Anal sismodification analysis
Modification Implementation
Modification Analysis
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 93: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/93.jpg)
938/14/2008
Change Requests• Evaluate and approve change requests
hi h dif l d ft d twhich modify released software products
• Inform users and regulators about– Problems in release software and the
consequences of continued unchanged use– Available changes to the software and how to
obtain and install the changes(6 Software Maintenance Process, 6.2.4 & 6.2.5)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 94: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/94.jpg)
948/14/2008
Establish Software Maintenance Plan
Problem and modification analysis
6.3 Modification Implementationmodification analysis
Modification Implementation
Implementation
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 95: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/95.jpg)
958/14/2008
Modification Implementation
• Use software development process to implement modifications
• Re-release modified software according to gsoftware release plans (5.8)(6 Software Maintenance Process 6 3 1 & 6 3 2)(6 Software Maintenance Process, 6.3.1 & 6.3.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 96: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/96.jpg)
968/14/2008
Maintenance and Problem Resolution Actions
• Safety related problem reports are addressed and reported to y p p pregulatory authorities and users
• Software products are re-validated and re-released after modification
• The manufacturer considers what other products might be affected• The manufacturer considers what other products might be affected and takes appropriate action
• Analyses problem reports and identifies all implications of the problem
• Decides on a number of changes and identifies all their side-effects• Implements the changes while maintaining consistency with
configuration management and risk management• Verifies the implementation of the changes• Verifies the implementation of the changes
(Annex B.6.2)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 97: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/97.jpg)
978/14/2008
Value of Software Maintenance Process
Software is always changing• Software is always changing • A smaller process for maintenance can be
used than the full software development process
• Process allows the manufacturer to modify released software while preserving its integrity
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 98: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/98.jpg)
988/14/2008
Software Development Planning
Establish Software Maintenance Plan
Customer Needs or Maintenance Request
Software Requirements Analysis
Software Architectural
Problem and modification analysis
Software Architectural Design
Software Detailed Design
Software unit implementation and verification
S ft i t ti
Modification Implementation
Risk Management Configuration Management
Problem Resolution
Software integration and integration testing
Software system testing
Software Release
Customer Needs and Maintenance Requests
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
Customer Needs and Maintenance Requests Satisfied(Introduction, Figures 1 & 2)
![Page 99: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/99.jpg)
998/14/2008
Regulatory ContextRegulatory Context
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 100: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/100.jpg)
1008/14/2008
Future of 62304
• Harmonization by EUy• Recognition by FDA
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 101: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/101.jpg)
1018/14/2008
Relationship to Other Standards
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 102: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/102.jpg)
1028/14/2008Traceability Tables
Annex CAnnex C
• IEC 62304 vs ISO 13485• IEC 62304 vs. ISO 13485• IEC 62304 vs. ISO 14971• IEC 62304 vs. IEC 60601-1:2005• IEC 62304 vs. IEC 60601-4:2005• IEC 62304 vs. ISO 12207
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 103: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/103.jpg)
1038/14/2008
Guidance for the Content ofPremarket Submissions for Software IEC 62304Premarket Submissions for Software
Contained in Medical DevicesIEC 62304
Level of Concern Software Safety Classification (4.3)
Software Description Software Requirements Analysis (5.2)
Device Hazard Analysis Analysis of Software Contributing to Hazardous Situations (7.1)( )
Software Requirements Specifications Software Requirements Analysis (5.2)
Architecture Design Chart Software Architectural Design (5.3)
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 104: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/104.jpg)
1048/14/2008Guidance for the Content of
Premarket Submissions for Software IEC 62304Contained in Medical Devices
Software Design Specifications Software Detailed Design 5.4
Traceability Analysis Throughout IEC 62304, including;5.1.1, 5.2.6, 5.7.4, 7.3.3, 8.2.4
S ft D l t E i t S ft D l t Pl 5 1Software Development Environment Description
Software Development Plan 5.1
Verification and Validation Throughout IEC 62304, including;Documentation 5.2.6, 5.3.6, 5.4.4, 5.5.5, 5.6.3, 5.6.7,
5.7.5, 7.3.1, 9.7, 9.8Revision Level History Configuration Staus Accounting
8.3
Unresolved Anomalies Maintain Records of Software Problem Resolution 9.5
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 105: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/105.jpg)
1058/14/2008
Questions
• What additional needs do you have?y– Educational Materials– Tools– Policy Statements
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration
![Page 106: Medical Device Software - Software Life Cycle Processes - SoftwareCPR](https://reader031.fdocuments.us/reader031/viewer/2022020702/61fb24a22e268c58cd5aa7c5/html5/thumbnails/106.jpg)
1068/14/2008
Contact Information
• John Murrayy– Phone: (240) 276-0284– [email protected] y@ g
The CDRH Software Education ProgramCenter for Devices and Radiological Health
US Food & Drug Administration