Downloaded 317 times
![Software Development Plan [Class A, B, C]
− Processes, Methods, Tools
− Deliverables
− Functional Requirements
− Traceability between requirements and delivery
− software driven alarms/warnings/messages
− Security requirements
− UX requirements that sensitive to human error and training
− acceptance requirements
− What is the RISK PROCESS?
− What is the VERIFICATION PROCESS?](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-14-2048.jpg)
![Architecture and Design [Class B, C]
− Describes the software structure and identifies software items
− Describes the interfaces for software items
− Detailed designs for software items and interfaces
− Describes the system, functional and performance requirements
of SOUP software items
− RISK PROCESS
− Describe segregation between software items [Class C]
− VERIFICATION PROCESS](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-15-2048.jpg)
![Software Testing [Class B, C]
− Acceptance Plan/Process/Results
− Additional items required for Class C
− Unit Plan/Process/Results
− Integration Testing Plan/Process/Results
− Regression Plan/Process [Class A, B, C]
− RISK PROCESS
− VERIFICATION PROCESS](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-16-2048.jpg)
![Software Risk Process [Class B, C]
− Risk analysis for software
− Risk analysis for software changes
− Risk control measures
− VERIFICATION of risk control measures
− TRACEABILITY of risk controls
− Maintain a RISK MANGEMENT FILE](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-17-2048.jpg)
![Configuration Management [Class A, B, C]
Identify configuration items
− Software
− Hardware
Identify SOUP configuration items
− Both external and internal items
Document configuration items
− SOP how the items are configured, by who, when etc.](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-18-2048.jpg)
![Change Management [Class A, B, C]
− Records of change requests
− Change requests have to be approved prior to implementation
− Cross check software classification as a result of change
− VERIFICATION of change
− TRACEABILITY of change](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-19-2048.jpg)
![Software problem resolution [Class A, B, C]
− Prepare problem reports
− type, scope and critically
− Investigate the problem
− Advise relevant parties
− Use change control process
− Maintain records of problems, resolutions and VERIFICATION of resolution
− Update RISK MANGEMENT FILE if required](https://image.slidesharecdn.com/3827cehlshealth20marchpresentation-140804052957-phpapp01/75/ISO-62304-TIR-45-20-2048.jpg)
Uploaded byHavas Lynx Group
ISO 62304 & TIR 45
The document discusses ISO 62304 and TIR 45 in the context of software development for medical devices, underlining the requirements for risk and quality management processes. It outlines the software development lifecycle (SDLC) processes including software development, maintenance, risk management, and configuration management, emphasizing the classification of software systems based on potential harm. Additionally, it addresses the adaptability of ISO 62304 for Agile methods, mapping Agile principles to regulatory standards and emphasizing the importance of documentation and risk management.
More Related Content
ISO 62304 & TIR 45
- 1. ISO 62304 &TIR 45
- 2.
- 3. Assumptions You have aRISK PROCESS and QUALITY MANAGEMENT PROCESS − ISO 13485 − ISO 14971 It is requirement that both are present in a system. − The software is a medical device − EU - COUNCIL DIRECTIVE 93/42/EEC Article 1(2a) − US - Section 201(h) of the Federal Food Drug & Cosmetic (FD&C)Act
- 4.
- 5. ISO 62304 Defines processesthat are required in any given SDLC to ensure that it compiles with the creation or maintenance medical device software − Software development process − Software maintenance process − Software risk management process − Software configuration management process − Software problem resolution process It is not prescriptive of the SDLC but does explain how adaption can work i.e. WATERFALL, INCREMENTAL, and EVOLUTIONAL.
- 6. ISO 62304 terms– HARM physical injury, damage, or both to the health of people or damage to property or the environment “ ”
- 7. ISO 62304 terms– RISK combination of the probability of occurrence of HARM and the severity of that HARM “ ”
- 8. ISO 62304 terms– TRACEABILITY degree to which a relationship can be established between two or more products of the development “ ”
- 9. ISO 62304 terms– VERIFICATION confirmation through provision of objective evidence that specified requirements have been fulfilled “ ”
- 10. ISO 62304 terms– SOUP software of unknown provenance (acronym) SOFTWARE ITEM that is already developed and generally available and that has not been developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as ‘off-the-shelf software’) or software previously developed for which adequate records of the development PROCESSES are not available “ ”
- 11. Safety classification Safety classificationas defined in ISO 62304 − Refer to country specific requirements for classification − MHRA, FDAetc Classes − ClassA: No injury or damage to health is possible − Class B: Non-SERIOUS INJURY is possible − Class C: Death or SERIOUS INJURY is possible SOFTWARE SYSTEM classification is based on the severity of the HAZARD resulting from failure of the software, assuming that the failure will occur (100% probability)
- 12. Safety Classification − Unlessclassified otherwise Class C applies − If a subpart of the system has a classification then all inherited parts have the same classification − If a subpart has a higher classification (Class B over ClassAfor example) then everything is treated as Class B). − Unless you document the rationale why − Classification can change − Change requests − New functional requirement (if not change request) − Hardware change
- 13. ISO 62304 :Software development process
- 14. Software Development Plan[Class A, B, C] − Processes, Methods, Tools − Deliverables − Functional Requirements − Traceability between requirements and delivery − software driven alarms/warnings/messages − Security requirements − UX requirements that sensitive to human error and training − acceptance requirements − What is the RISK PROCESS? − What is the VERIFICATION PROCESS?
- 15. Architecture and Design[Class B, C] − Describes the software structure and identifies software items − Describes the interfaces for software items − Detailed designs for software items and interfaces − Describes the system, functional and performance requirements of SOUP software items − RISK PROCESS − Describe segregation between software items [Class C] − VERIFICATION PROCESS
- 16. Software Testing [ClassB, C] − Acceptance Plan/Process/Results − Additional items required for Class C − Unit Plan/Process/Results − Integration Testing Plan/Process/Results − Regression Plan/Process [Class A, B, C] − RISK PROCESS − VERIFICATION PROCESS
- 17. Software Risk Process[Class B, C] − Risk analysis for software − Risk analysis for software changes − Risk control measures − VERIFICATION of risk control measures − TRACEABILITY of risk controls − Maintain a RISK MANGEMENT FILE
- 18. Configuration Management [ClassA, B, C] Identify configuration items − Software − Hardware Identify SOUP configuration items − Both external and internal items Document configuration items − SOP how the items are configured, by who, when etc.
- 19. Change Management [ClassA, B, C] − Records of change requests − Change requests have to be approved prior to implementation − Cross check software classification as a result of change − VERIFICATION of change − TRACEABILITY of change
- 20. Software problem resolution[Class A, B, C] − Prepare problem reports − type, scope and critically − Investigate the problem − Advise relevant parties − Use change control process − Maintain records of problems, resolutions and VERIFICATION of resolution − Update RISK MANGEMENT FILE if required
- 21.
- 22. Can 62304 workwithAgile? − AMMI TIR45:2012 − FDArecognised in 2013 − Adaption of ISO 62304 and 21 CFR 820 toAgile process − Not prescriptive ofAgile process i.e. SCRUM etc − Adapts INCREMENTAL and EVOLUTIONARY lifecycles in 62304 toAgile process − Describes how theAgile manifesto maps to the key requirements of medical device regulatory standards (such as ISO 13485) − Lots of videos and blogs that explain other approaches − TIR45:2012 is official and the best – worth the price
- 23. TIR45 :Agile activitiesmapped to 62304
- 24. Aligning on values Individualsand interactions over process and tools − Tools should be a supporting act − Discipline Working software over documentation − Documentation that has value Customer collaboration over contract negation − Customer roles in the process and requirements − Is the product owner representative of the customer Responding to change over following a plan − Planning is a partAgile − Ability to show it occurs and how
- 25. DOD Make DOD ahard requirement − Validated controls − Sign off − Verification is critical (tests, reviews etc.) − Who, how? − Documentation from the DOD steps − Design Inputs = Design Outputs STORY AND ACCEPTANCE CRITERIA DOCUMENTATION IS PRESENT AND VALIDATED ACCEPTANCE TESTS PASS INTERGRATED TESTS PASS TDD/TESTS PASS PAIR PROGRAMMING/C ODE REVIEW Backlog Development UAT Release
- 26. Configuration Management − Documentconfiguration to create a baseline − Do this either at the start (iteration zero for example) − Do this at the end of an iteration prior to release (hardening iteration) − Keep it simple and repeatable to align to baseline − Dev Ops − Puppet/Chef − Control SOUP − Vital configuration item − At the start − At the end
- 27. Documentation − Produce whatholds business value − Stories − Acceptance criteria − DOD, do we have enough to start and finish? − What have we documented and how? − Evidence − Can we prove what we did and how we did it? − Apply DOD to the documentation − Varies in degrees − Requirements for example − Sign Off
- 28. Manage Risk − Riskmanagement is critical − Include at every level − Reassess with every change − Control change requests − Reassess with every completion − Story − Increment − Release − Make it a validated part of the DOD
- 29. Pair programming Pair programmingcan be an effective review technique − Acceptance criteria is present − Qualifications of reviewers − Independence − Switch pairs for the review − Is this achievable or is a formal code review required? − Results of the pairing session are recorded − Code − Actions/Outcomes
- 30. Stop the line Processmonitoring − Burn down, velocity impact − Left shift − Context switching − Defect count increase − Regression results showing defect increase − DOD not being met Visualize, Fix CAPA
- 31. Architecture − Emergent architectureis fine − Documented before a release − Reassess with every story as part of the DOD before work starts − Verify the architecture − Align that with TDD, Pair programming and demos − Specify where architecture work may be done − Iteration zero − At the end of a iteration − During stories
- 32. Verification − Make sureit is a DOD!! − Customer demos/UAT − TDD − Acceptance testing − Pair programming − Continuous Integration − Continuous automated testing − Regression testing − QAoutput − Test plans − Test output
- 33. Andy Stopford, TechnicalDirector − Leading software engineer with 19 years’ experience within the industry − Experience built in the E-commerce, Insurance & Financial sectors − Manages a team of 30+ software engineers − Author, writer & industry speaker − Technical advisory to Microsoft &Apple − ISO 13485Auditor − @andystopford
- 34.