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
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
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
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
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