ISO 62304 & TIR 45
•Transferir como PPTX, PDF•
10 gostaram•22,021 visualizações
ISO 62304: Defines processes that are required in any given SDLC to ensure that it compiles with the creation or maintenance medical device software Andy Stopford has over 16 years experience leading teams to deliver pioneering software solutions that enable business goals to be achieved. With experience drawn from the e-commerce, financial, insurance, banking and healthcare sectors he is committed to creating quality software that adheres to best practices and delivers solutions that are robust and help clients achieve business goals. Andy is a software engineer by trade and is a published book author and keen writer with 200 magazine and journal articles over his career. He has a great depth and breadth of knowledge in a variety of technologies and is passionate about all things software engineering. Andy leads the HAVAS HEALTH SOFTWARE team of software engineers to develop solutions that focus on the best possible outcome for the end user that ensure the business needs are met. @andystopford
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Semelhante a ISO 62304 & TIR 45
Semelhante a ISO 62304 & TIR 45 (20)
Mais de Havas Lynx Group
Mais de Havas Lynx Group (14)
Último
Último (20)
ISO 62304 & TIR 45
- 1. ISO 62304 & TIR 45
- 2. ISO 62304
- 3. Assumptions You have a RISK 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
- 5. ISO 62304 Defines processes that 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 classification as 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 − Unless classified 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 [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
- 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 [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.
- 19. 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
- 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. AMMI TIR45:2012
- 22. Can 62304 work withAgile? − 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 activities mapped to 62304
- 24. Aligning on values Individuals and 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 a hard 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 − Document configuration 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 what holds 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 − Risk management 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 programming can 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 Process monitoring − 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 architecture is 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 sure it 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, Technical Director − 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. THANKS