Medical Device Software Do You Understand How Software is Regulated? By Gregory Martin
Agenda Relevant directives, standards, and guidance documents recommended to develop, maintain, and validate medical software according to the state of the art. Determine if software is covered by an EU medical directive for CE Marking, and if so how you classify the software. Overview of basic concepts from the key software standard EN 62304 and guidance document MEDDEV 2.1/6. 26/11/2015 2
Directives, Standards, and Guidance Documents Directives - Mandatory Harmonized Standards* Nonharmonized Standards** Guidance Documents*** 93/42/EEC (MDD) 90/385/EEC (AIMDD) 98/79/EC (IVDD) EN ISO 14971 EN ISO 13485 EN 62304 EN 60601-1 EN 62366 ISO/IEC 12207 MEDDEV 2.1/6 IEC/TR 80002-1 NB-MED/ 2.2/Rec4 * Harmonized standards provide a presumption of conformity with the essential requirements of the directives. ** Use of non-harmonized standards can help provide compliance with directives. *** Guidance documents are agreed upon (by Competent Authorities, Notified Bodies, Industry, etc.) directive interpretations and if followed, ensure uniform application of relevant directive provisions Legally not binding 3
Definition of Active Medical Device Active Medical Device - Any medical device relying for its functioning on a source of electrical energy or any source of power other than that directly generated by the human body or gravity. Note: Medical Device Directive states that a medical device can be software. 26/11/2015 4
MDD 93/42/EEC M5 (2007/47) Changes 1. Article 1: Change of Definition of Medical device - medical device means any instrument, apparatus, appliance, software, material or other article 2. New sub-clause ER 12.1a: For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification. 3. Annex IX Active Medical Device definition in the classification criteria added Stand alone software is considered to be an active medical device. 5
Definition of Accessory Accessory - 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. 26/11/2015 6
CE Mark Process Conform with Directives Determine classification of the device MDD 4 classes AIMDD 1 Class IVDD 4 Classes Conformity Assessment Procedures (CAP) available are based on Classification Use 1 or a combination of 2 Annexes to form the CAP route for MDD and AIMDD Issue a Declaration of Conformity (DoC) Place a CE Mark on the Product A notified body does not issue a CE Mark; they assess and issue certificates for the annexes the manufacturer uses. It is the manufacturer s responsibility to draw up and sign the DoC and place the CE Mark on the product. That signifies the manufacturer claims the product conforms with the provisions of the directive which applies to them. 7
Medical Device Classification Directive Classification Accessory AIMD Directive All AIMDs are one classification (considered high risk) All AIMD accessories are given same high risk classification MD Directive Rule-based Accessories are classified in their own right IVD Directive List, not rule-based (List A - high -or- List B - moderate risk devices) Accessories are classified in their own right * If SW is embedded in a medical device, it takes on the classification of the medical device * 8
European Harmonized Standards (for MDD) Standard EN 62304:2006 / AC:2008 EN ISO 13485:2012/ AC:2012 EN ISO 14971:2012 EN 60601-1:2006/ AC:2010 or EN 60601-1:2006/ A1:2013 EN 62366:2008 Topic Medical device SW SW lifecycle processes Medical devices - Quality management systems Requirements for regulatory purposes Medical devices Application of risk management to medical devices (Note: Normative reference in EN 62304) Medical electrical equipment General requirements for basic safety and essential performance Section 14: Programmable electrical medical systems (PEMS) (Note: Not harmonized to IVD Directive) Application of usability engineering to medical devices 9
International Guidance Guidance MEDDEV 2.1/6 (2012) Topic Guidelines for the qualification and classification of standalone SW used within healthcare within the regulatory framework of medical devices IEC/TR 80002-1:2009 Medical device SW - Part 1: Guidance on the application of ISO 14971 to medical device SW NB-MED/2.2/Rec4 SW and Medical Devices (2001) NB-MED EN 62304:2006 - Frequently Asked Questions (2013) Frequently Asked Questions related to the Implementation of EN 62304:2006 with respect to MDD 93/42/EEC 10
MEDDEV 2.1/6 Scope is stand alone software (no embedded software) Defines criteria for software being a stand alone medical device (qualification criteria) Potential risk arising from the use of stand alone software is not enough to qualify the software as a medical device Explains application of classification rules for stand alone software 26/11/2015 11
Software is a Medical Device if... (A) Software is a computer program (B) Software is not incorporated in a medical device (C) Software action is more than basic data processing (D) Software has benefit for individuals (E) Intended purpose is acc. to medical directives or SW is an accessory acc. to medical directive s definition Software falls under medical directive regulations 26/11/2015 12
MEDDEV 2.1/6: Criterion (A) Software is a Computer Program Not a medical device: DICOM files ECG recordings Data in electronic patient record 13
MEDDEV 2.1/6: Criterion (B) Software is not Part of a Medical Device Software as integral part of a medical device Not a device on its own Software program used with general purpose hardware 14
MEDDEV 2.1/6: Criterion (C) Software Action More Than Basic Data Processing "more than Storing, archiving, lossless compression 15
Criterion (C) Software Performance More Than Basic Data Processing "more than Data transfer (communication) Location A Location B Presentation of information for embellishment purposes Before After 16
Criterion (C) Software Performance More Than Basic Data Processing "more than Performing simple search Examples of simple search : Searching for blood glucose values measured within January 2015 Number of digital X-ray images taken within March 2015 17
MEDDEV 2.1/6: Criterion (D) Benefit for Individuals Patient Benefit Not a medical device: Software which processes population data for scientific purposes Digitized medical literature Anonymized Test Population 18
MEDDEV 2.1/6: Criterion (E) Purpose of the Software is Medical Medical intended purpose according to 93/42/EEC MEDDEV 2.1/6: If the manufacturer specifically intends the software to be used for any of the purposes listed in Article 1(2)a of Directive 93/42/EEC, then the software shall be qualified as a medical device. We have learned: Software is a medical device if: Intended use is medical Software is not a medical device if: only basic data processing is performed 19
Certification of Stand Alone Software (Annex IX 93/42/EEC) Definition: Stand alone software is an active device Non invasive devices Invasive devices Additional rules applicable to active devices Special rules Rules 1 to 4 Rules 5 to 8 Rule 9 Rule 10 Rule 11 Rule 12 Rules 13 to 18 Applicable active device rules 20
Classification of Stand Alone Software (Annex IX 93/42/EEC) Rule # Summary Classification 9 All active therapeutic devices intended to administer or exchange energy 10 Active devices intended for diagnosis 11 Active devices to administer or remove medicines, body liquids, or other substances 12 All other Active Devices ( fall through rule) Class IIa unless potentially hazardous way then Class IIb Class IIa or Class IIb (e.g. ionizing radiation) Class IIa unless potentially hazardous way then Class IIb Class I * Annex IX, 2.3: SW which drives a device or influences the use of a device, falls automatically in the same device class * 21
EN 62304 Software can contribute to hazards 62304 expects you to risk classify software as A, B, or C based on possible effects on the patient, operator, or other people. The higher the class, the more requirements need to meet in 62304. SW - safety class A No INJURY or damage to health is possible SW - safety class B Non-SERIOUS INJURY is possible SW - safety class C Death or SERIOUS INJURY is possible 26/11/2015 22
EN 62304 Shock Patient Must consider hazards that could be indirectly caused by software Framework of lifecycle processes: Software Development Process Software Maintenance Process Software Risk Management Process Software Configuration Management Process Software Problem Resolution Process Does not prescribe a specific lifecycle model 26/11/2015 23
Safety Classification of Software Components Documented rationale that segregation is effective is required Software system C Software component X Software component Y Documented rationale that segregation is effective is required A C Softwarecomponent W Softwarecomponent Z C B 24
Reducing the Software Safety Classification Documented rationale that segregation is effective is required C software component X A software component Y B software system C software component Y Hardware risk control measure 25
Reducing the SW Safety Classification Acc. To EN 62304 Reduction not possible from C (initial) to A (final) Reduction only B A or C B Reduction only if hardware mitigation measures are implemented User is not (explicitly) defined as hardware mitigation Reduction not possible if software controls software (e.g. C software component is controlled by another C software component as mitigation) The probability of a failure of software system to behave as specified that can cause a hazard shall be assumed to be 100 percent when assigning safety classification. 26
IEC 62304 Amd. 1:2015 Two of the main amendments/clarifications are: Making it clear how to apply IEC 62304 to legacy software (not developed in compliance with IEC 62304). Alternative methods that may apply. Consideration of factors external to the software is allowed to reduce the risk (including probability) of harm and could lower the safety classification. 2006 version used to state only hardware risk control measures Now allowed to reduce safety classification from C all the way down to A unlike 2006 version. 26/11/2015 27