Medical Devices cyber risks and threats David Grainger Senior Medical Device Specialist MHRA
The challenges of software medical device regulation. david.grainger@mhra.gov.uk
Current framework 1998 In Vitro Diagnostics Medical Device Directive 98/79/EC 1993 Medical Device Directive 93/42/EEC 1990 Active Implantable Medical Device Directive 90/385/EEC UK Medical Device Regulations 2002 The directives
What is a medical device? A thing, used on humans, that the manufacturer says can be used for: Prevention of disease, Diagnosis, monitoring, treatment or alleviation of disease, an injury or handicap, Compensation for an injury or handicap, Investigation, replacement or modification of the anatomy or of a physiological process, Control of conception And doesn t act principally as a medicine. This intended use is determined by claims on the device, label, instructions or promotional material.
But I have a disclaimer! It should be noted that general disclaimers (for example this product is not a medical device ) are not acceptable if medical claims are made or implied elsewhere in the product labelling or associated promotional literature. Manufacturer needs to consider use that can be reasonably foreseen prior to placing a product on the market A device does not need to diagnose to be considered to be used for diagnosis! Nor does it have to treat to be considered as for treatment
Function creep! Adding extra functionality can change qualification and classification as a device. e.g. The addition of QRISK calculator to a basic GP database will make the system a device. Can be managed by CE marking modules.
Can software be a device? 1993 - Medical Device Directive - 93/42/EEC Software on its own not specifically included. including the software necessary for its proper application Microsoft releases Windows 3.11, Office 4.0 and MS-DOS 6.0. DOOM released 1994 European guidance - MEDDEV 2.1/1 Distinction of software influencing Software related to the functioning of a medical device may be part of a device or a device in its own right if it is placed on the market separately from the related device. Macintosh System Software - System 1
Software as a device? 1998 IVD Medical Device Directive 98/79/EC This directive s definition of a medical device does not include software, only including the software necessary for its proper application IVDMD definition does not include mention of software. Win98 2007 Amending Directive 2007/47/EC (UK March 2010) Specifically adds software into the MDD definition of a medical device. Adds software specific Essential Requirement on validation & verification to the MDD only. iphone (1 st generation)
Classification rules Risk based classification system: I, IIa, IIb, III Rules based mainly on physical hazards / interactions: E.g. invasive devices, active devices No specific software rules. Software is considered to be an active device Implementing rule for software that drives or influences a device. Most standalone software will be class I unless allowing direct diagnosis. The directives
Conformity routes Depends on Class. Class I device manufacturers self declare. Class II usually by full QA and declaration. Class III usually full QA, design dossier exam and declaration. The directives
The regulations and how we enforce them MHRA is the designated competent authority that administers and enforces the law on medical devices in the UK. It has a range of investigatory and enforcement powers to ensure their safety and quality. To ensure that medical devices placed on the market and put into service in the UK meet these regulatory requirements we perform the following activities: assess all allegations of non-compliance brought to us, using a risk-based system. monitor the activity of notified bodies designated by MHRA to assess the compliance of manufacturers investigate medical devices as a result of adverse incident reports or intelligence indicating a potential problem carry out proactive risk-based projects with other member states in Europe to identify emerging risks
2015 Insulin dosing apps
Action Contacted author requesting details of the apps mentioned Identified those apps that should have been be CE marked. We wrote to the developers asking them to CE mark or remove from the market. (As class I device, this is not an onerous process self certify & register) All UK developers chose to remove their apps from the market (or the medical function from the app). We informed other EU member states of apps developed in their countries. (they are responsible for action) Non EU apps blocked through app stores. Report to: devices.compliance@mhra.gov.uk
Action We have also taken similar action against non CE marked software manufacturers making medical claims for: Assessment of Moles and melanoma Monitoring of Parkinson s disease progress Bio-resonance products Cardiovascular risk calculators Report to: devices.compliance@mhra.gov.uk
App - guidance
Revision of the directives Starting in 2012: extension of the scope of legislation, better supervision of independent assessment bodies, clear rights for economic operators, and stronger requirements for clinical evidence. Guidance written into the regulations. The regulations
MDRs 2017 (Now in force) General and Active Implantable Medical Device Regulations 26 May 2020 (+ 2 years if certified) UK Law In Vitro Diagnostics Medical Device Regulations 26 May 2022 (+ 4 years if certified) The regulations
The new regulations Will apply to medical devices placed on the market or put into service from 26 May 2020. Will include any updates to existing software devices. (A new device will have been put into service.) Certified medical devices (by a Notified body) have up to an extra 2 years to be in compliance. The regulations
Changes for software? In house developed devices will now be regulated a bit! Essential requirements updated and will now specifically cover security and unauthorised access. There is a specific software rule (Rule 11) -. Software intended to be used to take decisions with a diagnostic or therapeutic purpose will be at least class 2a. If a device is up classified from a class 1 device under the regs, it must be removed from the market until it is certified by a NB. Guidance has been incorporated into the regulations. The regulations
In-house conditions Don t need to fully CE mark as long as: not transferred to another legal entity, manufacture and use of the devices occur under appropriate quality management systems, the health institution justifies that the target patient group's specific needs cannot be met, or cannot be met at the appropriate level of performance by an equivalent device available on the market, Appropriate documentation a technical file; the health institution has a publicly available declaration. Article 5(5)
Consultation: https://www.gov.uk/government/consultations/he alth-institution-exemption-for-ivdrmdr Article 5(5)
Classification of Software
Rule 11 - Software How is this interpreted? 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 [serious] 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. Annex VIII
Rule 11 Use the IMDRF approach? To treat or to diagnose Treating and diagnosing infers that the information provided by the SaMD will be used to take an immediate or near term action: To drive clinical management Driving clinical management infers that the information provided by the SaMD will be used to aid in treatment, aid in diagnoses, to triage or identify early signs of a disease or condition will be used to guide next diagnostics or next treatment interventions: To Inform clinical management Informing clinical management infers that the information provided by the SaMD will not trigger an immediate or near term action: Critical situation or condition Situations or conditions where accurate and/or timely diagnosis or treatment action is vital to avoid death, long-term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health. IV III II Serious situation or condition Situations or conditions where accurate diagnosis or treatment is of vital importance to avoid unnecessary interventions (e.g., biopsy) or timely interventions are important to mitigate long term irreversible consequences on an individual patient s health condition or public health. III II I Non-Serious situation or condition Situations or conditions where an accurate diagnosis and treatment is important but not critical for interventions to mitigate long term irreversible consequences on an individual patient's health condition or public health. II I I
Rule 11- Guidance? Significance of incorrect decision. Related to timescale of implementation of the diagnosis/treatment. High Prompt diagnosis or treatment Medium, Drives clinical management Low, Informs clinical management. (Everything else) Critical situation or condition III IIb Serious situation or condition Non-serious situation or condition (everything else) IIb IIa
Class I software devices? Is almost certain to be up-classified to IIa or above. Must be taken off the market on 26 th May 2020 (no certificate extension). Will need Notified Body involvement before placing back on the market. Manufacturers need to be consulting NBs soon!
Unique Device Identifier Will feed into EUDAMED
UDI Software requirements UDI Device Identifier (model) & UDI Production Identifier (batch) A new UDI-DI shall be required whenever there is a modification that changes: (a) the original performance; (b) the safety or the intended use of the software; (c) interpretation of data. new or modified algorithms, database structures, operating platform, architecture or new user interfaces or new channels for interoperability Minor software revisions shall require a new UDI-PI and not a new UDI-DI. E.g. bug fixes (enhancements that are not for safety purposes, security patches or operating efficiency) Annex VI 6.5
Duties of the supply chain
Importers & distributors Supply chain responsibilities: Shall verify that requirements are met: the device has been CE marked and that the EU declaration of conformity of the device has been drawn up; The device is accompanied by the information to be supplied by the manufacturer Manufacturer and Authorised representative identified Check that UDI requirement met Importers to add their details to the packaging/documentation. Contact manufacturer/ca if they believe the device is not in compliance. Record and pass on details of any complaints. Articles 13,14 & 16
Changes to the essential requirements Here are the general safety and performance requirements that will apply to software.
14. Construction of devices and interaction with their environment: 14.2. Devices shall be designed and manufactured in such a way as to remove or reduce as far as possible: (d) the risks associated with the possible negative interaction between software and the IT environment within which it operates and interacts; 14.5. Devices that are intended to be operated together with other devices or products shall be designed and manufactured in such a way that the interoperability and compatibility are reliable and safe. Annex I
17. Electronic programmable systems 17.3. 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). 17.4. 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
18. Active devices and devices connected to them 18.8. Devices shall be designed and manufactured in such a way as to protect, as far as possible, against unauthorized access that could hamper the device from functioning as intended. Annex I
22. medical devices intended for use by lay persons 22.1. Devices for use by lay persons shall be designed and manufactured in such a way that they perform appropriately for their intended purpose taking into account the skills and the means available to lay persons and the influence resulting from variation that can be reasonably anticipated in the lay person's technique and environment. The information and instructions provided by the manufacturer shall be easy for the lay person to understand and apply. 22.2. Devices for use by lay persons shall be designed and manufactured in such a way as to: ensure that the device can be used safely and accurately by the intended user at all stages of the procedure, if necessary after appropriate training and/or information, reduce as far as possible the risk of error by the intended user in the handling of the device and, if applicable, in the interpretation of the results. 22.3. Devices for use by lay persons shall, where appropriate, include a procedure by which the lay person: can verify that, at the time of use, the device will perform as intended by the manufacturer, and if applicable, is warned if the device has failed to provide a valid result. Annex I
Chapter III Requirements regarding the information supplied with the device 23. Label and instructions for use including eifu 23.4. Information in the instructions for use (ab) 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. Annex I
Guidance Work is progressing on EU level guidance at the moment and we will see outputs soon. Guidance on software classification is due in June/July 2018.
Cyber-security
Cyber security Currently considered to be abnormal use and have not been considered reportable by manufacturers. Plan to produce Vigilance guidance on cyber issues. These should be reported by users/manufacturers. Manufacturer action considered to be FSCA
About copyright Crown copyright 2017 All material created by the Medicines and Healthcare Products Regulatory Agency, including materials featured within these Medicines and Healthcare Products Regulatory Agency presentation notes and delegate pack, is subject to Crown copyright protection. We control the copyright to our work (which includes all information, database rights, logos and visual images), under a delegation of authority from the Controller of Her Majesty s Stationery Office (HMSO). The Medicines and Healthcare Products Regulatory Agency authorises you to make one free copy, by downloading to printer or to electronic, magnetic or optical storage media, of these presentations for the purposes of private research, study and reference. Any other copy or use of Crown copyright materials featured on this site, in any form or medium is subject to the prior approval of the Medicines and Healthcare Products Regulatory Agency. Further information, including an application form for requests to reproduce our material can be found at www.mhra.gov.uk/crowncopyright Material from other organisations The permission to reproduce Crown copyright protected material does not extend to any material in this pack which is subject to a separate licence or is the copyright of a third party. Authorisation to reproduce such material must be obtained from the copyright holders concerned. 40