Medical device domain

A wide range of the functions provided by todays medical devices rely heavily on software. Research indicates an increasing importance and use of software and embedded systems, controlled and managed by software in the medical device industry (Allen 2014; Bovee et al. 2001; Chunxiao et al. 2013; Lindberg 1993; McCaffery et al. 2005; Méry & Kumar Singh 2010).

In the Medical Device Directive (MDD) 93/42/EEC (European Council 1993) the term “medical device” is defined as: “Medical device means any instrument, apparatus, appliance, material or other article, whether used alone or in combination, including the software necessary for its proper application intended by the manufacturer to be used for human beings for the purpose of:

• Diagnosis, prevention, monitoring, treatment or alleviation of disease.

• Diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap, investigation, replacement or modification of the anatomy or of a physiological process.

• Control of conception (birth control, solve infertility, miscarriage etc.).”

It is important to notice that it is the manufacturer’s purpose and the operation of the product that decides if the product is classified as a medical device, not the designer or the user.

Medical devices can be safety-critical devices, which means that they have the potential of causing harm to people or the environment. In the standard IEC 62304 (IEC 2006a) safety is defined as “freedom of acceptable risk” and according to Bowen and Stavridou (1993) safety can be defined as “freedom from exposure of danger or exemption from injury or loss”. Further, in a safety-critical system functionality handling safety has to be designed into the system during the design phase and not later in the development process. In health care, there are many different safety critical systems, for example, defibrillators, dialysis machines, surgical devices and pacemakers. It is therefore essential to demonstrate that the safety-critical devices are safe and have high quality. This can be done through the application of a structured development process that is compliant with a safety standard. Examples of safety standards are IEC 61508 (IEC 2010a), which is a safety standard for electrical, electronic, and programmable electronic safety-related systems, and IEC 61511 (IEC 2003), which covers integration of components developed according to IEC 61508 (Gall 2008). Companies must comply with the regulatory requirements of the country in which they wish to market their medical devices. How strict and detailed the manufacturer’s processes have to be depends on the safety classification of the product.

The requirements for medical devices are defined in Europe in the Medical Device Directive (European Council 1993) and amendment MDD 2007/47/EC (European Council 2007) and in the US, the Food and Drug Administration, FDA, (FDA 2006) is responsible for the medical device regulation and compliance. Standalone software can, according to the amendment MDD 2007/47/EC (European Council 2007), be classified as an active medical device in its own rights. Every member state in the EU must adopt and publish laws, regulations and administrative provisions to implement the directive. There are some variations in national requirements; most of these concerns the need to notify the Competent Authorities, for example, in Sweden the Medical Products Agency (MPA), when medical devices are placed on the market in their countries. Duplication of registration procedures for a medical device placed on different markets is needed, even if it is the same

Background and related work

medical device. For example, a medical device placed on both the US and the European market, needs duplicate registration depending on the various prevailing laws and regulations. In order to market a medical device in Australia the device must be approved and registered by the Therapeutic Goods Administration (TGA), in China the approval must be obtained by the State of Food and Drug Administration (SFDA) and there are similar regulatory bodies in other countries throughout the world, for example, South Korea, Japan, Brazil and Mexico. In the work of harmonising regulations and standards, the International Medical Device Regulators Forum (IMDRF), is working towards global harmonisation in medical device regulations. IMDRF has permanently replaced Global Harmonization Task Force (GTHF) and consists of voluntary representatives from national medical device regulatory authorities. GTHF consisted of both voluntary representatives from national medical device regulatory authorities and from medical device industry. The goal was standardisation of medical device regulation across the world, the same goal as IMDRF, who also aim to accelerate towards harmonisation and convergence. IMDRF has more member countries than GTHF and they have the World Health Organisation (WHO) as an official observer.

Medical devices in the EU are divided according to the Medical Device Directive (European Council 1993) into different classes according to risk level, as presented in Table 1 and also with examples of medical devices in the respective class. All medical devices on the European market are classified in one of these classes based on the level of control necessary to assure safety and effectiveness.

Table 1. Medical device classification

Class Risk potential Example

Class I Low Syringe (non active)

Class Is (supplied sterile) Low Bandage (non active) Class Im (measurement

function)

Low Thermometer

Class IIa Moderate Patient monitor

system

Class IIb High Ventilators

Class III Very high Pacemakers

The manufacturers themselves classify the medical device. For medical devices classified in Class I the manufacturers themselves assess if they fulfil laws and regulations. The manufacturing process however, shall be controlled by a third part, often a Notified Body (NB). For medical devices in Class IIa a limited third part assessment is required where certain aspects are assessed. For the medical devices with the high risk potential classified in Class IIb and Class III it is required a full third part assessment. The classification is built upon the risks, which the human body can be exposed to due to the design, the use or the mode of manufacture of the medical device.

Medical information systems are systems, handling medical information such as information about the patient, images, diagnosis, medication, planned and completed treatment and so on, these systems are also classified. For example, transportation and storage of information (without affecting the information) are classified in Class I, imaging (CT, x-ray) in Class IIa, and control of treating radiological equipment in Class IIb.

The classification in the US differs from the European classification.

They have three different classes, based on the level of control, necessary to assure safety and effectiveness. A medical device is assigned to one of these three regulatory classes and the three FDA classes are:

• FDA Class I require General Controls,

• FDA Class II require General controls and Special Controls

• FDA Class III require General Controls and Premarket Approval (PMA)

General controls are the baseline requirements of the Federal Food, Drug, and Cosmetic Act (FDA 2006) that applies to all medical devices.

The manufacturer has to register their establishment and their device with FDA, comply with the labelling regulation, design and produce devices under good manufacturing practices (GMP), and submit a premarket notification [510(k)](FDA 1995) to FDA. The premarket notification [510(k)] is submitted to demonstrate that the device be market is safe and effective. FDA Class III is the most stringent regulatory category and usually contains devices that support or sustain human life and medical devices classified in Class III must have a premarket approval (PMA) from the FDA.

Concerning software, medical device software is regarded as a medical device when the manufacturer has specified the use of the software to be intended for one or several medical purposes defined above. Medical

Background and related work

device software can be a part of a medical device, a stand-alone software/IT-system or accessory to a medical device.

An analysis of medical device recalls by the FDA in 1996 (Wallance and Kuhn 2001) found that the software was increasingly responsible for product recalls. A subsequently made analysis showed that between 2006 and 2011, 5294 recalls were reported to the FDA and nearly 23 % of them were due to computer related failures. According to fault classes and risk levels, there is a dominance of software-related failures, but looking at the total number of devices, hardware-related recalls have a larger impact than software (Alemzadeh et al. 2013). To address such issues, various standards, laws and recommendations regulate the development of medical device software. In general, these standards describe software life-cycle models that shall be implemented by manufacturers. For example IEC 62304 (IEC 2006a) a key standard for medical device software development, covering the software life-cycle processes, ISO 13485 (ISO 2003) specifying requirements for medical device quality management system, EN 60601-1 (EN 2006) medical electrical equipment general requirements for basic safety and essential performance. EN 60601-1 (EN 2006) is the main standard containing the other standards, 60601-1-* and 60601-2-* covering, for example radiological equipment, EMC, alarm, electrosurgical equipment and electrocardiographs. Manufacturers are obliged, according to IEC 62304 (IEC 2006a) to assign safety classes to the software. The software at system level shall be assigned a safety class based on the most patient critical functions in the system. Parts in the software can be assigned a lower risk level than the whole system but not higher. The software safety classes are assigned according to the possible software hazard effects on patients, medical staff or other people resulting from a hazard to which the software can contribute. The classes are assigned based on severity as follows (IEC 2006a):

Class A – no injury or damage to health is possible.

Class B – non-serious injury is possible.

Class C – death or serious injury is possible.

Serious injury means life-threatening injury, permanent injury or when treatment is needed to prevent permanent injury.

ISO 13485 (ISO 2003), mandates that the medical device organisation’s risk management process is documented and the standards IEC 62304 (IEC 2006a) and EN 60601-1 (EN 2006) specify basic risk management process actives. In practice, there is a high degree of

freedom in instantiating the processes.

The regulatory requirements do not specify the use of any particular development process when developing medical device software. However the standard IEC 61508 (IEC 2010a), a safety standard for electrical, electronic and programmable electronic safety-related systems recommends the use of the V-model to, for instance, achieve traceability (Smith and Simpson 2011). In the medical domain, it is shown that developers often use plan-driven software process models such as the waterfall model or the V-model (Lindholm & Höst 2008; McCaffery et al. 2012; McHugh et al. 2013). Though the use of agile practices within software development is increasing (Conboy & Fitzgerald 2010; Gary et al. 2011) the rate of adapting to agile practices within medical software development is slow (McHugh et al. 2013). However, McHugh et al.

(2014) has found that there are no existing external barriers to adopt agile practices within the medical domain, on the other hand there are perceived barriers against adopting these practices. For example, agile practices are perceived to be contradictory to regulatory requirements and have insufficient coverage of risk management activities (McHugh et al. 2014). To show that it is possible to adopt agile practices to the development of regulatory compliant software, the Association for the advancement of medical instrumentation (AAMI) successfully mapped suitable agile practices to the stages of development in IEC 62304 (IEC 2006a) and presented this in a technical report (AAMI TIR 45:2012).

Gary at al (2011) are also arguing that agile practices can contribute to safety critical software development and that they allow including activities related to risk reduction such as fault-tree analysis (FTA) and failure mode effects analysis (FMEA). Rottier and Rodrigues (2008) showed that adapting Scrum and map it to current process in a medical devices company and still satisfy standards and regulation is possible. It is also possible to combine participatory design with agile methods, even if this is not straightforward work (Abelein et al. 2013). When the agile process is tailored to meet the need of regulated environments and appropriate tools support the process, the agile approach is highly suitable in a regulated environment according to Fitzgerald et al. (2013).

To comply with the regulatory requirements of the medical device domain, it is essential to have traceability from requirements, including risks, throughout the whole development and maintenance process (Casey & McCaffery 2013). The requirement should be documented prior to development and this can be perceived as a barrier for adapting

Background and related work

agile practices (McHugh et al. 2014), however McHugh et al. (2014) have concluded that the FDA General principle of software validation, accept iterative software development models and that they thereby enables for the use of agile practices.