RISK MANAGEMENT IMPLEMENTATION FOR SOFTWARE AS MEDICAL DEVICE

RISK MANAGEMENT IMPLEMENTATION FOR SOFTWARE AS MEDICAL DEVICE UNDER THE EUROPEAN MEDICAL DEVICE REGULATION 2017/745 Researcher: Atacan Demiralp Supervisor: Prof. Tomasz P. Michalak, Phd External Advisor: Andreas Heimdal, Phd Keywords: MDR, 2017/745, risk management implementation, medical device development, stand-alone software, Sa. MD, EN ISO 14971, risk management, medical software

Case: Medical Device Regulation (EU) 2017/745 published on 26 May 2017 High Level Problem: Enhanced and stricter requirements - Challenges for MD manufacturers - Challenges for importers and distributors - Challenges for regulatory authorities - Newly introduced - Very limited time (will be effective on 26 May 2020) Major Topics: - Stand-alone software (Software as Medical Device) - Risk Management Exploratory Research: - Secondary research: reviewing literature - Informal qualitative approach: discussions/feedbacks from employees Our Solution: New risk management implementation fulfilling the MDR requirements, aligned with the EN ISO 14971: 2012.

WHAT IS MEDICAL DEVICE? 2018 Market Value: 425. 5 Billion USD Definition: Any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes: - diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, - diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability, - investigation, replacement or modification of the anatomy or of a physiological or pathological process or state, - providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations Wellness apps, investigational devices, educational software NOT MD Stand-alone software is medical device Sa. MD: software intended to be used for medical purposes and is able to perform its medical purpose without being embedded in a hardware medical device.

HOW MEDICAL DEVICES REGULATED MDD: 60 p, MDR: 174 p 78% of medical device companies states that they do not have adequate understanding of the EU MDR legislation (KPMG, RAPS, 2018) There are more than 500, 000 types of medical device currently available in the European market (Med. Tech Europe, 2018) Switching from the MDD to the MDR will disrupt the industry and medical device companies will be negatively affected (EY, 2016)

PIP SCANDAL • French company Poly Implant Protheses , used industrial-grade silicone instead medical-grade in breast implants. • High rate of rupture • Leakage into the body • about 400, 000 patients worldwide had implants • 70 cases of breast cancer observed with the patients • 1 patient died from Anaplastic Large Cell Lymphoma • Removed from market in 2010 • Companies offered free removal The scandal triggered the new Regulations era. DOI: 10. 5999/aps. 2015. 42. 1. 4

BREAKING NEWS IN THE MDR Some MDR contents: - The word “safety” 290 times whereas the MDD has it 40 times - Stand-alone software now considered as medial device on its own behalf MD Classes: Class I, Class IIa, Class IIb, Class III Expanded scope of MD Stricter post market surveillance, including unannounced audits and product sample tests Rigorous clinical evaluations verifying the safety Manufacturers must establish a QMS for risk management Risk management must be assessed for the entire life-cycle of the device and updated with the data from Post Market Surveillance Risk based Software Classification system is introduced, causing most of the devices to be classified as higher risk-type devices. Risk Management: The quality procedures used in design and manufacture processes the life cycle of the medical device to identify, evaluate and mitigate the safety risks. Medical devices should not cause harm to patients, users, or any people. risk means the combination of the probability of occurrence of harm and the severity of that harm We focused on Sa. MD development and risk management process of the device

WHAT WE HAVE DONE • Investigated the risk management requirements for Sa. MD in the MDR • Adopted the QMS: EN ISO 14971: 2012 Medical Devices – Application of Risk Management to Medical Devices • Adopted the IEC 62304: Software Life Cycle Processes • Forged a new risk management guidance • Gave templates and examples • Got reviews from a healthcare company in terms of regulatory and risk management, modified our study as needed • Proposed the new Risk Management Implementation

RISK MANAGEMENT SYSTEM The ISO 13485 Medical Devices: Quality Management System ISO 14971: 2012 Medical Devices – Application of Risk Management to Medical Devices “Manufacturers shall establish, document, implement and maintain a system for risk management as described in Section 3 of Annex I. ” (Article 10 P 2)

HOW TO IDENTIFY RISKS Usability Task Analysis Identify the possible failures Methods for identifying the possible failures: 1. Use Errors (Human Impact) causing hazards -> Usability Task Analysis 2. Software defects causing hazards -> Software DFMEA 3. Cybersecurity defects causing hazards -> Cybersecurity FMEA 4. Manufacturing/assemble defects causing hazards -> PFMEA 5. Service defects causing hazards -> PFMEA 6. Defects during the distribution, causing hazards -> PFMEA: Failure Modes and Effects Analysis A method to identify the failures and associated causes

USABILITY TASK ANALYSIS Sample image RFR = Risk Functional Requirement

SOFTWARE REQUIREMENTS

SOFTWARE DESIGN FMEA Sample image There might be dedicated Cybersecurity FMEA, however in this example we made analysis under the Software Design FMEA since the cybersecurity is a part of software design.

PROCESS FMEA For Sa. MD, manufacturing and distribution may not be valid. Service may be the only sub-process to take into the Process FMEA

CMT – ONE FAILURE TABLE TO RULE ALL

SAMD CLASSIFICATION Rule 11 in the MDR Annex VIII : Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: - death or an irreversible deterioration of a person's state of health, in which case it is in class III; or - a serious deterioration of a person's state of health or a surgical intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I.

RISK MANAGEME NT ACTIVITY FLOW

CONCLUSION Research questions: 1. What are the MDR requirements associated with the risk management? 2. What could be good practices of risk management for stand-alone software development under the MDR? Our study has been reviewed in a healthcare company in term of regulatory and risk management context by the company professionals. Our solution has been confirmed that the implementation is applicable to the stand-alone software as medical device and provides good practices for risk management requirements of the EU MDR.

Q&A

SUPPORTING SLIDES

ESTIMATE, EVALUATE, CONTROL RISKS

RISK MANAGEMENT ACTIVITY FLOW