Software as a Medical Device – Part II

Since the 2007 amendment to the Medical Devices Directive (93/42/EC)1 aimed at clarifying its scope in relation to standalone software, there has been much debate on what types of standalone software should be qualified as medical devices and, subsequently, how they should be classified. An article titled ’Software as a Medical Device’, published in the December 2011 issue of In Compliance, referred to a guideline document that was being worked on by the EU Commission for this purpose. This guideline was finally published in January 2012 as MEDDEV 2.1/62.

MEDDEVs are guidelines aimed at promoting a common approach by manufacturers and notified bodies involved in the conformity assessment procedures, and by the competent authorities of the member states charged with safeguarding public health.

Our purpose here is to provide an overview of what the Commission guidance really means for developers and suppliers of standalone software for use in a healthcare setting. A future article will provide an overview of the standards development activity as it relates to standalone software and healthcare IT solutions in general.

This article does not cover how the guidance should be interpreted in relation to the In Vitro Diagnostic Medical Devices Directive 98/79/EC.

The guidelines are not legally binding, and it is recognised by the Commission that under given circumstances (for example, as a result of scientific developments) an alternative approach may be possible or appropriate to comply with legal requirements.

So what is “stand alone” software?

Before drilling down into the content of the guidance, it is important to first define what we mean by standalone software. In the context of Medical Devices Directive (93/42/EC) (MDD) and this guidance, standalone software ‘means software which is not incorporated in a medical device at the time of its placing on the market or its making available’. Any software that is embedded in a medical device, at firmware or application level, is assessed as part of the medical device and is therefore outside the scope of MEDDEV 2.1/6. The meaning of the term ‘placing on the market’ and other terms used in this article are as defined in MEDDEV 2.1/6.

Meeting the criterion of not being incorporated in a medical device is only one consideration – the standalone software must also meet the definition of a medical device to be qualified. For example, an enterprise resource planning (ERP) billing software application is not considered to be a medical device, as it does not have a medical purpose although used in a healthcare setting.

The intended purpose of the standalone software is also relevant – if the use for which the device is intended according to the manufacturers documentation is not for a medical purpose, then the standalone software is not to be qualified as a medical device.

It should also be noted that standalone software that does not meet the definition of a medical device but is intended to be used as an accessory to a medical device, is not in scope for MEDDEV 2.1/6 but is covered by the MDD.

Qualification Criteria

The qualification criteria to be applied in the process of deciding whether or not standalone software is a medical device are varied and complex. In addition to the medical purpose and ‘used as intended’ criteria, considerations such as the function performed by the standalone software being for the benefit of an individual patient or for the analysis of population data must be factored in.

In an attempt to model the decision framework, the guidance document contains a decision tree diagram which, if applied properly, should help in achieving a consistent application of the guidance by all stakeholders. The diagram, copied in Figure 1, guides the reader through a series of six decision steps.

Figure 1: A decision diagram to assist qualification of software as a medical device.

Some key points:

• Only the intended purpose as described by the manufacturer of the product is relevant.
• If the software is not a computer program (e.g., a DICOM clinical image file), it is not a medical device (Decision Step 1). But the PACS system that manages DICOM files may be a medical device.
• If the software is incorporated in a medical device, it must be assessed as part of the process for that medical device and not as a standalone software (Decision Step 2).
• Decision Step 3 will be a key consideration for many suppliers of software systems – if the software does not perform an action on data, or performs an action limited to storage, archival, communication, simple search or lossless compression, it is not a medical device. However, where the software alters the representation of data for a medical purpose or where a search function provides interpretative results, it could be considered a medical device.
• The software must be used for the benefit of individual patients to be considered a medical device; i.e., software used to analyze population data, or provide generic treatment pathways is not a medical device (Decision Step 4).
• The software must have a medical purpose as defined in the MDD Article 1(2)a. Software for staff planning/rostering or invoicing in a healthcare environment are not to be considered as a medical device (Decision Step 5).
• If the software is an accessory to a medical device (e.g., it drives, monitors, or influences the performance or the use of a medical device), it is not itself a medical device but is covered by the MDD (Decision Step 6).

Annex 1 of the guidance contains some examples of qualification of software used in a healthcare setting, a selection of which are included in Table 1.

(*) see section on modular/multi-function software later in this article
Table 1

The types of applications listed in Table 1 are representative of recent advances in information technologies, and the healthcare IT or eHealth sector is currently experiencing rapid growth in both the bringing to market of innovative solutions and their increasing adoption by providers and other stakeholders into the delivery of healthcare services.

The EU Commission acknowledges this fact, and indeed are a key player in driving its development. Consequently it is the intention that MEDDEV 2.1/6 and the Manual on Borderline and Classification in the Community Regulatory Framework for Medical Devices3 will be ‘living’ documents, updated as necessary in line with advances in the state of the art in relation to standalone software.

Classification of Standalone Software

Once a standalone software is qualified as a medical device by applying the logic outlined in Figure 1, the next question to be answered is into what classification it should fall.

The MDD defines possible classes for medical devices as being either Class I, IIa, IIb or III and provides a set of rules for deciding on the appropriate classification for a device. These rules, called implementing rules, are contained in Annex IX of the MDD.

Section 1.4 of Annex IX states clearly that ‘standalone software is considered to be an active medical device’:

“Any medical device operation of which depends on a source of electrical energy or any source of power other than that directly generated by the human body or gravity and which acts by converting this energy. Medical devices intended to transmit energy, substances or other elements between an active medical device and the patient, without any significant change, are not considered to be active medical devices. Stand alone software is considered to be an active medical device.”

This means that implementing rules 9, 10, 11 and 12 may apply, depending on the function and purpose of the stand alone software.

To assist suppliers of standalone software in interpreting these rules and to ultimately decide on the appropriate classification, the guidance document contains in Section 3 examples of how some typical standalone software applications should be classified in the context of implementing rules 9 through 12. Table 2 contains a selection of these examples.

Table 2

Multi-function or Modular Software

In a healthcare setting, users will employ software applications for a mixture of purposes, some medical and others not – for example, admission and discharge of patients, electronic prescription, email communications with insurance providers, clinical decision support. Increasingly, vendors of software applications will market suites of software that include many of these functions in one software package. Each of the functions provided by the suite can be considered as a ‘module’.

This mixture of medical and non-medical purpose in the functionality of the software suite makes it more difficult for suppliers of software systems to decide on how to approach conformity assessment and CE Marking of the software.

The guidance document offers the following advice:

• The modules (functionality) that have a medical purpose and are defined as a medical device must comply with the requirements of the MDD and be CE Marked.
• Non-medical modules are not subject to the MDD.
• The boundaries and interfaces ofthe various modules must be identified by the manufacturer during design and development, based on intended use.

Where it gets further complicated is that some medical purpose modules will interface with other non-medical purpose modules and/or equipment. Essential requirement 9.1 of the MDD (copied below) requires that the overall combination must not impair the safety and performance of the medical purpose modules:

“If the device is intended for use in combination with other devices or equipment, the whole combination, including the connection system must be safe and must not impair the specified performances of the devices. Any restrictions on use must be indicated on the label or in the instructions for use.”

Standards – Demonstrating Conformity

As with other directives under the EUs New Legislative Framework (NLF) the most accepted method of demonstrating conformity with the essential requirements of the MDD is through the application of harmonized standards published in the Official Journal of the European Union (OJEU). This will also be the most favored route chosen by manufacturers of standalone software, once the standards are published.

Which standards apply to standalone software ?

Once a standalone software is qualified as a medical device, then the design, development and maintenance of that software becomes subject to a similar conformity assessment regime as is applied to hardware medical devices. The purpose of this regime is to ensure that such software, when used as intended, will protect the safety of patients.

Considerations during the development process will need to address items such as risk management, software development life-cycle processes, test and validation addressing implementation, use, and decommissioning phases of such software (systems).

As reported in a draft technical report issued in May 2011 by the International Standards Organization (ISO)4, e-Health systems (in which software plays a major role) ‘have the potential to play a key role in eliminating or mitigating documented threats to patient safety and quality of care ..’. The report goes on to identify a number of international standards which already exist, and further standards that are under development, aimed at addressing safety in health software:

• ISO TS 25238:2007 Health informatics – Classification of safety risks from health software
• ISO 14971:2007 Medical devices – Application of risk management to medical devices
• IEC 62304:2006 Medical device software – Software lifecycle processes
• IEC 80001-1:2010 Application of risk management for IT networks incorporating medical devices,
• Part 1 – Roles, responsibilities and activities

The IEC 80001 series of standards represent an interesting departure from the typical design/development pre-market considerations relevant for manufacturers, in that it stipulates requirements to be considered when adding or removing a medical device (including software that is a medical device) into a network, wired or wireless, within a healthcare delivery organization (HDO). HDOs will be responsible for continued safe operation of the HDO network and will in turn place stringent requirements on suppliers of network and medical devices to demonstrate application of adequate levels of risk assessment/mitigation during development.5

While this is an ISO report to be developed in conjunction with the International Electrotechnical Commission (IEC), its recommendations will most likely be adopted by the European standards development organizations CEN and CENELEC. Once adopted, these standards will more than likely be ratified by the EU Commission and published in the OJEU for use by manufacturers to demonstrate conformity with the MDD.

As we see the beginning of a market developing for healthcare related apps6, it will be interesting to observe how many of these standards the suppliers of the apps will be included on the Declaration of Conformity with the MDD.

Notes

1. Directive 2007/47/EC of the European Parliament and of the Council of 5 September 2007 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:1993L0042:20071011:EN:PDF
2. MEDDEV 2.1/6 – Medical Devices: Guidance document – Qualification and Classification of stand alone software, http://ec.europa.eu/health/medical-devices/files/meddev/2_1_6_ol_en.pdf
3. http://ec.europa.eu/health/medical-devices/files/wg_minutes_member_lists/borderline_manual_ol_en.pdf
4. ISO/TC 215 / SC WG4 N856 Health Informatics – Guidance on standards for enabling safety in health software
5. A future article will cover in detail the current and future standards framework for medical software, including standalone software qualified as a medical device.
6. http://www.ehi.co.uk/insight/analysis/848/is-there-a-regulation-for-that_tcq

Brian Mcauliffe is currently employed as a Senior Engineer with Dell Inc. based in Ireland and working in the Global Regulations & Standards group. Brian has worked in compliance for 20 years with compliance testing laboratories and a number of product development companies in the telecoms and ITE sectors. He is active in the standards development process being an expert member of CENELEC and IEC technical committees and has been Chairperson of TechAmerica Europe Standards & Certification working group since 2009. Brian is currently studying part time for an M.Sc. in Health Informatics from the University of Limerick (www.ul.ie). These materials are not offered as and do not constitute legal advice or opinions. Seek independent legal advice with respect to compliance or any particular issue. The content of this document reflects the opinions of the individual author and may not reflect the opinions of Dell Inc.