Engineers are dedicated to making things work, so a focus on how they might fail and harm someone can seem alien.
Managing risk, however, is essential for all medical products- medical devices, including those involving software, have produced some painful examples of poor risk management with serious consequences. Experience has shown that there is a better way, that it is possible to manage risk in a changing business and technical world.
Regulatory bodies are placing increased emphasis on risk management, and technology shifts are introducing new sources of risk. Newer Lean-Agile methods are recognized by the FDA as a good way to accomplish risk management.
Techniques for risk management are well established, but require specific interpretation when applied to software. In this session, we will show a way of knitting risk management into the development process, so that it is integral to product development, not a ten ton caboose dragging the train back down the mountain.
Why you should attend:
Perhaps your engineering team is beginning its transition to an Agile approach - or perhaps you have a seasoned Agile team and youīre just beginning work on FDA-regulated products. You know that risk management is required, but itīs not at all clear how you should address it as you go through your backlog grooming, iterations, and end-user demonstrations. The process in ISO 14971 seems "linear" and unsuited to a highly iterative, dynamic lifecycle. How can you fit it into your approach?
Areas Covered in the Session:
Software has introduced (or been blamed for) some serious safety hazards
All medical device standards intersect on the topic of risk management
Risk analysis starts with the intended use statement
Risk information is available from multipl sources - use them!
Note that safety is an emergent property
Changes are often the biggest sources of risk
Donīt ignore the human factors side; understanding your users is crucial to safety
Applying engineering risk methods to software requires us to translate some concepts
Though standards draw a roadmap for risk management, WE must figure out the route
Risks often arise when we add new features - so incremental risk management is the most effective
Forget the notion that "software canīt hurt anyone"
Never conduct risk analysis by using a checklist from 14971
Exploding technology brings numerous chances for risk to multiply
Day 1 Schedule
Software brings great capability to medical devices, but also creates hazards
Consider how the key standards lay out the roadmap for managing risk
Understand the key concepts - hazard, risk, and harm
Walk through ISO 14971 in detail - and consider IEC 80002-1 for specific software concerns
Day 2 Schedule
Fault tree analysis and FMEA complement each other for risk analysis
Risk analysis for software is different from hardware - and needs a place in the lifecycle
Story mapping helps bring risk management directly into development
An incremental approach manages both risk and quality
Brian Shoemaker consults for healthcare products companies on computer system validation, software quality assurance, and electronic records and signatures. He has conducted validation both on product software and on internal software, developed software quality systems, audited software quality processes (including agile methodology), and evaluated 21 CFR Part 11 compliance. He has had clients in clinical diagnostics, medical device engineering, medical imaging, medical-device fabrics manufacturing, contract lyophilization, clinical trial software, dental prosthetics, and bone-repair implants. He has worked with companies in Germany and Switzerland as well as the U.S.