Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ISO 62304 & TIR 45


Published on

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.


Published in: Healthcare
  • There is no such standard as ISO 62304 the Standard is IEC 62304
    Are you sure you want to  Yes  No
    Your message goes here

ISO 62304 & TIR 45

  1. 1. ISO 62304 & TIR 45
  2. 2. ISO 62304
  3. 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
  4. 4. Medical device standards
  5. 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. 6. ISO 62304 terms – HARM physical injury, damage, or both to the health of people or damage to property or the environment “ ”
  7. 7. ISO 62304 terms – RISK combination of the probability of occurrence of HARM and the severity of that HARM “ ”
  8. 8. ISO 62304 terms – TRACEABILITY degree to which a relationship can be established between two or more products of the development “ ”
  9. 9. ISO 62304 terms – VERIFICATION confirmation through provision of objective evidence that specified requirements have been fulfilled “ ”
  10. 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. 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. 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. 13. ISO 62304 : Software development process
  14. 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. 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. 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. 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. 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. 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. 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. 21. AMMI TIR45:2012
  22. 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. 23. TIR45 :Agile activities mapped to 62304
  24. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 34. THANKS