iso 62304 & tir 45

ISO 62304 & TIR 45

ISO 62304

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

Medical device standards

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.

ISO 62304 terms – HARM

physical injury, damage, or both to the health of people or damage to property or the environment“

”

ISO 62304 terms – RISK

combination of the probability of occurrence of HARM and the severity of that HARM“

”

ISO 62304 terms – TRACEABILITY

degree to which a relationship can be established between two or more products of the development“

”

ISO 62304 terms – VERIFICATION

confirmation through provision of objective evidence that specified requirements have been fulfilled“

”

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

“

”

Safety classification

Safety classification as defined in ISO 62304−Refer to country specific requirements for classification−MHRA, FDA etc

Classes−Class A: No injury or damage to health is possible −Class B: Non-SERIOUS INJURY is possible −Class C: Death or SERIOUS INJURY is possible

SOFTWARE SYSTEM classification is based on the severity of the HAZARD resulting from failure of the software, assuming that the failurewill occur (100% probability)

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 Class A for 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

ISO 62304 : Software development process

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?

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

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

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

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.

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

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

AMMI TIR45:2012

Can 62304 work with Agile?

− AMMI TIR45:2012− FDA recognised in 2013− Adaption of ISO 62304 and 21 CFR 820 to Agile process− Not prescriptive of Agile process i.e. SCRUM etc− Adapts INCREMENTAL and EVOLUTIONARY lifecycles in 62304

to Agile process− Describes how the Agile 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

TIR45 : Agile activities mapped to 62304

Aligning on valuesIndividuals 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 part Agile− Ability to show it occurs and how

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 TESTSPASS

INTERGRATEDTESTSPASS

TDD/TESTS PASS

PAIR PROGRAMMING/C

ODE REVIEW

Backlog Development UAT Release

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

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

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

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

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

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

Verification

−Make sure it is a DOD!!−Customer demos/UAT− TDD− Acceptance testing− Pair programming−Continuous Integration−Continuous automated testing− Regression testing

−QA output− Test plans− Test output

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 13485 Auditor−@andystopford

THANKS