Recently published guidance and, in particular, the decision trees it contains, can help manufacturers determine if their software should be regulated as a medical device. But the forthcoming recast of the medical device directives may add a few new twists and turns.
The European Union currently is overhauling its medical device law and medical software regulation and clarifying the scope of the EU medical device law with respect to software used in clinical settings. This paper analyses EU regulation of clinical decision support (CDS) software and is a companion paper to one published on 28 December 2011 on FierceHealthIT.1 In this paper, we intend to provide the EU perspective on regulation of CDS software.
We have kept the structure identical to facilitate comparing the regulations under both jurisdictions. Since the US regulatory framework in relation to software is more detailed and developed and EU law has a different approach to certain issues, we expect the comparison to be valuable for companies that have an interest in both jurisdictions. To that end, we will address the same four questions that were addressed in the previous paper:
In addition, we will make several comparisons and examine the differences between the US and EU approaches to the regulation of CDS software to help companies operating in both jurisdictions.
2 Past regulation
CDS software has fallen within the scope of the EU medical device directives2 (MDD and AIMDD) since 1990. As in the United States, no CDS-specific guidance documents have been published thus far, but there are guidance documents that address software more generally. For example, MEDDEV 2.1/1 from April 1994 already identifies software for diagnostic and therapeutic purposes as being explicitly within the scope of the MDD, but it does not specifically mention CDS software purposes.3
EU law, like in the United States, divides software into two categories: (1) stand-alone software and (2) accessories. Software that comes pre-installed on a device when the device is placed on the market is not regulated as a separate medical device. Accessories are defined as software that is not intended to be used as a stand-alone product but, instead, is intended specifically by the manufacturer to be used together with a device (which can be stand-alone software) from another manufacturer. This combination enables the software to be used in accordance with the use of the device (as intended by the device manufacturer).4
Understanding that framework is important because it determines the regulatory requirements that apply to a given piece of software. If the software is designed to analyse data downloaded from a blood glucose meter, for example, the software is an accessory and will be regulated in the same manner as the blood glucose meter. The classification and most of the EU regulatory requirements will be dictated by how the parent medical device is regulated. Stand-alone CDS software, by contrast, is regulated or not based on its own merits, without regard to another medical device.
2.2 Regulatory status
If you are sure of the regulatory category in which your CDS software falls, you can determine its regulatory status. Typically that would be one of the following three options:
Software that does not meet the legal definition of a device would be, for example, a system that would not serve any of the intended purposes set forth in the definition of device in the MDD:5
If the software falls within the scope of the MDD, the manufacturer must take another step to determine specifically how the software is regulated—as a general medical device or as an in vitro diagnostic device. The latter category is regulated under yet another EU directive, the In-Vitro Diagnostic Devices Directive (IVDD). 6 Software is regulated under the IVDD if it meets the definition of a medical device, as stated above, and is, moreover, intended to be used in vitro for the examination of specimens, including blood and tissue donations, derived from the human body, solely or principally for the purpose of providing information:
With CDS specifically in mind, software that is intended to create or modify medical information might be qualified as a medical device. If such alterations are made to facilitate the perceptual and/or interpretative tasks performed by healthcare professionals when reviewing medical information (for example, when searching a medical image for findings that support a clinical hypothesis involving diagnosis or evolution of a therapy), the software could be a medical device.
2.2.1 Unregulated software
Software that is outside the scope of the MDD is not regulated. This typically concerns “software for general purposes when used in a healthcare setting.”7 However, all software “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, is a medical device.”8 So, software that is not specifically intended by the manufacturer to be used as a medical device is not covered—that would include general database and spreadsheet software. Generally speaking, if the software does not perform an action on data, or performs an action limited to storage, archiving, communication, “simple search” or lossless compression (i.e., using a compression procedure that allows the exact reconstruction of the original data), it is not a medical device.9
There is some difference in opinion about whether patient file database software (i.e., an electronic health record) is regulated or not. For example, Sweden requires that all electronic patient file software be certified. CDS software, if it is provided as a stand-alone product, would normally fall within Class I, as the default classification rule in the MDD defines stand-alone software as an “active medical device.”10
2.2.2 Software that can be self-certified
Class I devices are not subject to review by a third party but may be self-certified by the manufacturer. As stated above, all CDS software by default falls into Class I, and is, therefore, subject to self-certification with some exceptions (see 2.2.3). Self-certification involves assembling a technical file and designing a quality system that is in conformity with ISO 13485, for example.
2.2.3 When does software need to be certified by a third party?
The default classification for all CDS software is Class I, unless an applicable classification rule bumps it up to Class IIa, IIb or III. If the CDS software has functionality that allows it to drive a device or influence the use of a device, it falls automatically into the same class as that device.11 CDS software that implements a recommended action by exercising control over another Class IIa or higher device would be subject to this. A specific example is CDS software that assists a cardiologist in interpreting data transmitted via WiFi from a patient’s pacemaker and then, following the cardiologist’s approval on a suggested reconfiguration, remotely reconfigures the patient’s pacemaker.
2.3 Examples of currently regulated CDS software
Here are examples of CDS products that are currently regulated:
The following summarises the similarities and differences between the historical approach to regulation of software in the United States and the European Union.
3 Stand-alone software MEDDEV and expected changes in review
There are two ongoing developments that will likely influence the way CDS software is regulated in the European Union: new EU guidelines on the qualification and classification of stand-alone software under the medical device directives,2 and the review of the two oldest medical device directives.13 Together, these instruments will be the most important documents for CDS software. Since both of these projects are in the works, what the final texts will look like are currently unknown.
3.1 Stand-alone software MEDDEV
A new MEDDEV guidance document titled Guidelines on the Qualification and Classification of Stand Alone Software Used in Healthcare within the Regulatory Framework of Medical Devices (the “MEDDEV”) has just been released.14 The MEDDEV addresses all of the medical device directives and includes two convenient decision trees to determine if particular software is regulated under the MDD or the IVD Directive. The decision tree for the MDD is shown in Figure 1.
It seems to be a refined version of the decision tree for software that COCIR published in 2010.15 Let’s clarify the steps.
1. Computer program?
The first step is to determine if the software is a “computer program”. Both COCIR and the MEDDEV propose to use the definition from ISO/IEC 2382-1:1993: “A computer program is defined as a syntactic unit that conforms to the rules of a particular programming language and that is composed of declarations and statements or instructions needed to solve a certain function, task or problem.” If you answer no to question 1, the software does not contain any instructions or subroutines in any programming language and you are probably dealing with an electronic document containing a protocol (such as a Word document in which a treatment protocol has been written out).
2. Embedded or incorporated?
If the software is incorporated in a medical device, rather than being a stand-alone product, it must be considered to be part of that medical device for regulatory purposes. Updates to the software at a later stage are regulated as changes to the device.
3. Action different from storage, archival, lossless compression, or simple search?
If the software performs an action on data at all or performs an action on data that is limited to storage, archival, communication16 or simple search,17 it should not fall within the scope of a medical device. In all other cases, actions on data to assist the user for a medical purpose would likely make the software a medical device. Such assistance would typically be facilitation of perception and interpretation. An example would be software that filters out noise in images or that provides decision support based on its interpretation of patient data.
4. For the benefit of individual patient(s)?
The software must be intended to produce results for a specific patient or group of patients, anonymous or otherwise, for it to qualify as a medical device.18 Software not intended to produce results for specific patients includes, for example, software for statistical, research, registry, or data aggregation purposes. This software—even if used in clinical trails—is not a medical device. Software providing generic diagnostic or treatment pathways (software that displays a treatment protocol as a flowchart, for example) also would not be software for the benefit of individual patients, according to COCIR.19
5. Action in scope of intended use regulated under medical device directives?
The intended use must fall within the definition of a medical device under the MDD. This is a hard question for software developers to answer. As a start, it is helpful to consider what the manufacturer of the software intends it to do. Is it something medical or a general function, such as invoicing or planning, that could be used for any purpose? If the answer is that the software is to be used specifically for a medical purpose, the next step is to check if this medical purpose is regulated under the MDD (see Section 2.2 above). The intention of the manufacturer of the software determines the purpose, not how a user decides to use the software.
6. Accessory to medical device?
As explained above in Section 2.1, accessories of medical devices are regulated as medical devices in their own right. Software that is not itself a medical device and does not constitute an accessory to a device typically would be software for all types of uses in a medical setting but not with a regulated intended purpose. An example would be software that is used for reimbursement purposes, staff scheduling or some other similar function. Software that is an accessory will influence a medical device in some way and assist it to achieve its intended purpose but does not itself fall within the scope of the definition of a medical device. An example of this would be an iPad app that allows a nurse to monitor and control infusion pumps in the ward from the nurse’s station.
In Vitro Diagnostics
The decision tree for IVDs included in the MEDDEV is mainly concerned with demarcation of the MDD and the IVDD. The IVDD typically regulates expert systems that interpret data from IVD devices. If the data comes from diagnostic devices that are covered under the MDD but not under the IVDD (because the data is not derived from in vitro examination of a specimen derived from the human body), the software falls under the MDD and not under the IVDD. The same questions with respect to the accessory status must be answered for IVDs.20
1. In scope of MDD?
To determine if the CDS software is within the scope of the MDD, first apply the decision tree shown in Figure 1 and then proceed with the IVD tree (Figure 2).
2. IVD functionality?
For CDS software to fall within the scope of the IVDD, the manufacturer’s intended use must be the examination of in vitro specimens derived from the human body (including blood and tissue donations) solely or principally for the purpose of providing information
CDS software with another functionality that is also not an accessory falls outside the scope of the IVD Directive.
3. Source of data—only from IVD?
The next step is to determine the sources of the data. If the data comes from any source other than an IVD, there is a demarcation issue because the device concerned is a combination device. Combination devices are contemplated in the IVDD:21 if the IVD is intended for use in combination with other (medical) devices or equipment, the whole combination, including the connection system, must be safe and must not impair the specified performance of the devices. Any restrictions on use must be indicated on the label and/or in the instructions for use.
4. Source of data—only from medical device?
If the software obtains the data only from one or more medical devices that are not IVDs, the IVDD does not apply and the software is regulated under the MDD.
5. and 6. Accessory of an IVD?
A device can fall outside the scope of both directives (as explained above in relation to accessories) but still be subject to regulation as an accessory to a medical device or to an IVD.
The MEDDEV also regulates software that is a module of a larger interoperable software package that falls within the scope of the MDD. However, it is up to the manufacturer to define correctly the boundaries of the module(s) and to identify clearly what is regulated and what is not. The MEDDEV does not provide guidance on how to make such a determination but instead refers to the existing rule in Annex I MDD and IVDD for combination devices: “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 and/or in the instructions for use.”22
It may be challenging for manufacturers to identify how the different modules of a larger software system relate to each other and where medical functionality starts or ends. Indeed, the rule in Annex I that the MEDDEV refers to was written for modular physical medical devices rather than software. Furthermore, manufacturers must ensure that the whole system is safe and does not impair the specified performance of the modules that are subject to the medical device directives if medical functionality modules are combined with nonmedical functionality modules. On the other hand, medical device regulations in the European Union are appreciated for their flexibility, allowing manufacturers to present evidence in a way that works for them.
The European Union is currently in the process of preparing a first draft review of the MDD, which will probably be a single regulation that incorporates both directives.23 The IVDD also will be reviewed but will not be incorporated in the same regulation.
This review process will take time and the new legislation probably will not go into effect before 2015, at the earliest. We mention this development, though, because we believe that the new legislation will impact CDS software in the following ways:
The following summarises the similarities and differences between the regulatory framework for stand-alone software and the expected regulatory changes in the United States and European Union.
4 Potentially Affected Types of Software
So what types of present day software uses might end up in the regulated CDS software category when applying the decision trees from the draft MEDDEV? Here are our best guesses.
5 Open Issues
Resolving the broad issue of what types of CDS software US FDA should regulate will require a detailed analysis of at least the following six areas:
In the European Union and the United States, the regulatory approach to CDS software is in flux and important developments are slated for 2012. If the future of this software category is important to you, you'll want to monitor developments closely and become engaged. As table 1 shows, this approach should account for the many essential similarities between the systems on both sides of the pond. The majority of differences lie in the underlying documentation requirements prescribed by the broader regulatory framework of each jurisdiction. Companies that want to stay ahead of the regulatory compliance curve should learn to take advantage of the similarities while efficiently accounting for differences. The observant reader will have noticed, for example, that the open issues in the fifth paragraph are virtually identical for both jurisdictions. Time will tell how the United States and the European Union choose to resolve these open issues; we hope the approaches will remain largely convergent.
2. Directive 93/42/EE on medical devices and Directive 90/385/EEC on active implantable medical devices
3. http://ec.europa.eu/health/medical-devices/files/meddev/2_1-1___04-1994_... , para. 1.1 (f)
4. See definition of accessory, Directive 93/42 article 1 (2) (b)
5. Directive 93/42, article 1 (2) (a)
6. DIRECTIVE 98/79/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 October . 1998 on in vitro diagnostic medical devices
7. Directive 2007/47, recital 6
8. Directive 2007/47, recital 6
9. MEDDEV 2.1/6 Qualification and Classification of stand alone software, explanation of decision step 3 in respect of medical devices decision tree, p. 12
10. MEDDEV 2.4/1 Rev. 9 http://ec.europa.eu/health/medical-devices/files/meddev/2_4_1_rev_9_clas..., p. 10 and Directive 93/42 Annex IX, point I.1.4
11. Directive 93/42, Annex IX, sub II, point 2.3
12. MEDDEV 2.1/6 Qualification and Classification of stand alone software
13. Directive 93/42 on general medical devices and 90/385 on active implantable medical devices
14. MEDDEV 2.1/6 Qualification and Classification of stand alone software, January 2012
16. COCIR suggests to define “communication” in accordance with IEEE 620.10-1994: “the flow of information from one point, known as the source, to another, the receiver.”
17. “Simple search” is limited to the searching functionality only: retrieval of records by matching record metadata against record search criteria and not, for example, identifying, marking or drawing attention to portions of record data or portions of images that match the search criteria.
18. See COCIR decision tree explanation sub 5
19. See COCIR decision tree explanation sub 5
20. See the definition of ”accessory” in article 1 (2) (c) of the IVD directive
21. See Annex I, B.3.1 IVDD
22. See Annex I, 9.1 MDD and Annex I, B.3.1 IVDD
23. For the roadmap, see http://ec.europa.eu/governance/impact/planned_ia/docs/2008_sanco_081_pro...
24. Such services may be regulated by another regulatory agency under separate statutory authority.
25. Article 1 (2) (f) MDD
Erik Vollebregt is a Founding Partner at Axon Lawyers, Piet Heinkade 183, 1019HC Amsterdam, tel +31 88 650 6500, fax +31 650 6555, email firstname.lastname@example.org, URL www.axonlawyers.com
Bradley Merrill Thompson
is a Member of the Firm, Washington, DC Office, Phone: 202/861-1817
Fax: 202/861-3517, 1227 25th Street, NW, Suite 700, Washington, DC 20037-1156, email@example.com
M. Jason Brooke
is associate at Epstein Becker & Green, Washington, DC Office
1227 25th Street, NW
Washington, DC 20037-1156