EU MDR Deep Dive: Software/Digital Health Implications for Manufacturers/Developers. 19 JUNE 2018 ASQ RAPS MASSMEDIC Waltham Woods

EU MDR Deep Dive: Software/Digital Health Implications for Manufacturers/Developers 19 JUNE 2018 ASQ RAPS MASSMEDIC Waltham Woods Glen Emelock Sr. Partner, The CRO Group Lead Auditor, Technical Expert, NSAI

The Fine Print All opinions expressed by Glen Emelock during and after this presentation are solely his and do not reflect the opinions of ASQ, RAPS, MassMedic, NSAI, or affiliates, and may have been previously disseminated by him in other presentations, or on the Internet or via another medium. You should not treat any opinion expressed by Glen as a specific requirement for certification or approval or part of a particular regulatory strategy for such certification or approval, but only as an expression of his opinion. Glen s opinions are based upon information he considers reliable, but neither ASQ, RAPS, MassMedic, NSAI, nor affiliates and/or subsidiaries warrant the completeness or accuracy, and it should not be relied upon as such. Emelock, ASQ, RAPS, MassMedic, NSAI, and affiliates and/or subsidiaries are not under any obligation to update or correct any information provided during this presentation. This presentation is intended to provide specific requirements and details of the European Medical Device Regulation. As such, it cannot address all requirements or details of the EU MDR, and thus, the information presented including but not limited to a sample of regulatory requirements, standards, guidances, and related information mentioned should be carefully reviewed and considered as part of a baseline towards establishing an overall, well balanced plan to address applicable essential requirements appropriate for your specific situation. 2017, All rights reserved. The CRO Group, Inc.

The Line in the Sand (is getting blurrier) Wellness>>>>>>>>>>>>Medical Device/Accessory Apple Watch (heart rate, exercise) Sports Watch w/ non clinical oximeter Layperson Otoscope/(flashlight + photo) app for wellness Dementia (did I take my pills?) App Snore/sleep pattern (microphone + haptic smartphone/watch app Sunscreen Reapplier Apple Watch app Apple Watch Afib/Arrhythmia App ECG/Afib electrode watchband for Apple Watch + App Hearing Aid Adjustment (+ Audiology Dx) App on smartphone Bone Fracture Dx App on smartphone CPAP/TENS Adjustment App on smartphone Endoscope App on smartphone or tablet

Diagnosis /Treatment Use vs. Well BeingHealth Converge or is it Collide? Clarifying Software In Its Own Right Intended Uses (Medical Device Purpose) Device vs. Accessory Compatibility Interoperability 2017, All rights reserved. The CRO Group, Inc.

Clarifying Software In Its Own Right It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life style and well being purposes is not a medical device. The qualification of software, either as a device or an accessory, is independent of the software s location or the type of interconnection between the software and a device. (Whereas #19)

Intended Uses of Medical Devices 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, and which does not achieve its principal intended action by pharmacological, immunological or metabolic means, in or on the human body, but which may be assisted in its function by such means. (Article 2, (1))

Accessory MDR: an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose(s); (Article 2, Definitions (2)) Accessories for a medical device and for a product listed in Annex XVI shall be classified in their own right separately from the device with which they are used. Annex VIII, 3.2 MDD: an article which whilst not being a device is intended specifically by its manufacturer to be used together with a device to enable it to be used in accordance with the use of the device intended by the manufacturer of the device Article I, Definition 2b. Accessories are classified in their own right separately from the device with which they are used. Annex IX, 2.2

Compatibility ability of a device, including software, when used together with one or more other devices in accordance with its intended purpose, to: (a) perform without losing or compromising the ability to perform as intended, and/or (b) integrate and/or operate without the need for modification or adaption of any part of the combined devices, and/or (c) be used together without conflict/interference or adverse reaction (Article 2, (25))

Interoperability ability of two or more devices, including software, from the same manufacturer or from different manufacturers, to: (a) exchange information and use the information that has been exchanged for the correct execution of a specified function without changing the content of the data, and/or (b) communicate with each other, and/or (c) work together as intended.(article 2, (26))

Software an Active Device MDR: Software shall also be deemed to be an active device. (Art 2, Definition (4)) MDD: Stand alone software is considered to be an active medical device. (Annex IX, Rule 1.5)

Other Rules 3.3. Software, which drives a device or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right. 3.5. If several rules, or if, within the same rule, several sub rules, apply to the same device based on the device's intended purpose, the strictest rule and sub rule resulting in the higher classification shall apply.

Rule 11 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.

Classification: IIB or not IIB? Software/Device MDD Rule 10 MDR Rule 11 Software diagnoses/predicts hearing loss, myopia, osteoporosis I IIA Software performs post stroke physical therapy I IIB Software predicts risk of future heart attack, stroke, etc. I III Software provides prognosis from Chemo or Radiation Tx I III Software suggests diathermia machine, Bili lights dose IIA IIB Software analyzes chest images for rib fracture, alerts of lung cancer IIA III

Repeatability, reliability, performance, SFR redux Devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, shall be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance. (Annex I, GSPR 17.1)

SOTA: SDLC, RM, CYBER, V&V For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation. (Annex I, GSPR 17.2)

Designed for Mobile Software referred to in this Section that is intended to be used in combination with mobile computing platforms shall be designed and manufactured taking into account the specific features of the mobile platform (e.g. size and contrast ratio of the screen) and the external factors related to their use (varying environment as regards level of light or noise).(annex I, GSPR 17.3)

Hardware, IT networks/security Manufacturers shall set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. (Annex I, GSPR 17.4)

Additional Software /IT Environment Risk Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts; (GSPR 14.2(d))

Instructions for Use: Select Right Software The instructions for use shall contain all of the following particulars: where applicable, information allowing the healthcare professional to verify if the device is suitable and select the corresponding software and accessories; (GSPR 23.4(f))

Instructions for Use: Min H/W, IT net/security The instructions for use shall contain all of the following particulars: for devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorised access, necessary to run the software as intended. configurations and, where applicable, operating systems identified in the information supplied by the manufacturer); (GSPR 23.4(ab))

Technical Documentation The documentation shall contain the results and critical analyses of all verifications and validation tests and/or studies undertaken to demonstrate conformity of the device with the requirements of this Regulation and in particular the applicable general safety and performance requirements. (It shall include) detailed information regarding test design, complete test or study protocols, methods of data analysis, in addition to data summaries and test conclusions regarding in particular: software verification and validation (describing the software design and development process and evidence of the validation of the software, as used in the finished device. This information shall typically include the summary results of all verification, validation and testing performed both in house and in a simulated or actual user environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating systems identified in the information supplied by the manufacturer) (Annex II, 6.1(b))

UDI for SaMD (Annex VI) UDI Assignment Criteria (6.5.1) New UDI DI Criteria (6.5.2) UDI PI for minor software changes (6.5.3) UDI Placement Criteria (6.5.4)

Clinical Evaluation A clinical evaluation may be based on clinical data relating to a device for which equivalence to the device in question can be demonstrated. The following technical, biological and clinical characteristics shall be taken into consideration for the demonstration of equivalence: Technical: the device is of similar design; is used under similar conditions of use; has similar specifications and properties including physicochemical properties such as intensity of energy, tensile strength, viscosity, surface characteristics, wavelength and software algorithms; uses similar deployment methods, where relevant; has similar principles of operation and critical performance requirements; (Annex IV, 3)

Clinical Investigation The investigator's brochure (IB) shall contain the clinical and non clinical information on the investigational device that is relevant for the investigation and available at the time of application. Any updates to the IB or other relevant information that is newly available shall be brought to the attention of the investigators in a timely manner. The IB shall be clearly identified and contain in particular the following information: Pre clinical evaluation based on relevant pre clinical testing and experimental data, in particular regarding in design calculations, in vitro tests, ex vivo tests, animal tests, mechanical or electrical tests, reliability tests, sterilisation validation, software verification and validation, performance tests, evaluation of biocompatibility and biological safety, as applicable. (Annex XV, 2.3)

Piece O Happy MDR Certification! Are European Commission/NBs ready for AI/Machine Learning? Subscription Based (Your diagnosis is important to us ) Interface of GDPR with MDR / Patient Data / Repairs SaMD combining well being and medical intended uses Many, many more!