.png)
Software as a medical device (SaMD) may seem like a niche product category, but it encompasses a wide range of products, such as artificial intelligence (AI) algorithms that process digitized pathology slides. Thanks to the International Medical Device Regulators Forum, there is a considerable amount of regulatory harmonization for SaMD, but there are several key differences that must be taken into account.
Where regulation is concerned, SaMD is largely distinct from software in a medical device (SiMD), hence the separate treatment in this blog. The questions surrounding regulation of SaMD are too numerous to cover in a single blog, so we’ll review several key aspects, such as:
- How SaMD is defined;
- Which functions create a regulatory liability for SaMD; and
- How risk is determined for SaMD.
The 2002 regulation for the UK’s Medicines and Healthcare Products Regulatory Agency (MHRA) provides no definition of SaMD, but that is likely to change with the pending overhaul of regulations in the U.K. The draft proposal would define software as “a set of instructions that processes input data and creates output data.” Oddly, this definition is drawn from Section 2.1 of the MEDDEV guidances under the EU’s legacy Medical Device Directives, a regulation that is now out of service thanks to the implementation of the Medical Device Regulation (MDR).
MHRA published a guidance in 2014 which states that a software module might qualify as SaMD when part of a larger software system. One example of this is software that is part of a clinical system when used to indicate a specific patient’s risk of developing a disease, based on data entered for that patient. This guidance classifies a similar set of functions as non-device software as other regulators, such as storage and/or transmittal of data without a change to the data. Software that provides only reference information that is used to help an HCP use their knowledge to make a clinical decision is also outside the definition of a device, hence leaving many clinical decision support (CDS) systems outside the realm of regulation.
In terms of risk categorization, MHRA proposes to follow the 2014 guidance for SaMD risk by the International Medical Device Regulators Forum (IMDRF), but this is a rather complex set of considerations. Category IV, the highest of the risk categories, applies when the patient’s condition is critical and the SaMD provides information that is used to diagnose or treat the condition in question. At the other end of the spectrum, class I risk is when the patient’s condition is non-serious and the SaMD does nothing more than provide information for clinical management of the patient. The IMDRF document states also that the SaMD’s risk category is entirely independent of any hardware device or software (including other SaMD) with which it might interface.
Health Canada is one of the more progressive regulators when it comes to harmonization, adopting many ISO standards and IMDRF guidances. Health Canada uses the IMDRF definition of SaMD, although this definition is refined as meaning that the software does not need a hardware medical device to fulfill that purpose. HC provides some additional context to distinguish between SaMD and SiMD, such as by stating that software does not qualify as SaMD if its purpose is to “drive a hardware medical device.” SaMD may interface with a hardware medical device and other SaMD software, and still fall under the rubric of SaMD.
HC excludes medical device data systems from the definition of SaMD assuming there is no modification of the data or the display of the data, and that the MDDS does not control the functions or parameters of a medical device.
HC’s approach to determining whether software is a regulatable medical is clarified by stating that the definition includes software that is intended to acquire, process or analyze a medical image or a signal from an invitro diagnostic or pattern or signal from an acquisition system. The agency describes CDS software as intended to provide recommendations to health care professionals and/or patients regarding diagnosis, treatment or mitigation of a disease or condition. However, software used by clinical staff only to support a clinician’s (or patient’s) decision or diagnosis is not a device. The distinction seems to be whether the software will trigger an immediate or near-term action on the part of the patient or health care professional. When this is the intended use, the software is regulated. Wellness apps as commonly understood are not regulated products under HC’s framework.
Multiple FDA Guidances Reference Software Definitions
The FDA has a number of digital health policy documents and guidances, a number of which directly or indirectly implicate SaMD. The primary guidance of interest is the 2017 guidance for clinical evaluation of SaMD, which references a number of IMDRF guidances, such as the 2014 IMDRF guidance for SaMD risk. The agency relies on another IMDRF document, the December 2013 key definitions guidance, for definitions, which provides some language on the scope of the definition of SaMD. However, for definitional purposes, the FDA guidance for device software definitions as mandated by the 21st Century Cures Act is a clarifying statement of scope.
Among the functions that are excluded from the definition of a device are software that display and store clinical lab test results. However, software that analyzes medical device data in order to provide an alert, notification or flag to a health care professional is a device. Conversely, software used in tissue transfusion clinical sites does fall under the definition of a device. The FDA’s 2019 draft guidance excludes CDS products from the definition of a device if it is used to support or provide recommendations only when the health care professional can review the basis for that recommendation. Otherwise, the CDS is a device.
The Medical Device Coordination Group has provided guidance on the Medical Device Regulation, but the content of the guidance seems to make no regulatory distinction between SaMD and SiMD. Guidance MDCG 2019-11 applies to both the MDR and the In Vitro Diagnostic Regulation (IVDR), and states that medical device software (MDSW) is software that is used either alone or in combination with a hardware or another software medical device. That software must have a medical purpose of its own to qualify as MDSW, while software that has no medical purpose of its own other than to drive or influence the use of a hardware device may be classified as an accessory.
Any software that alters the representation of data for a medical purpose would qualify as MDSW, as does software that can provide information that would immediately influence or trigger a medical decision. However, software that is used to provide a simple search function for the retrieval of information would not be a regulated product.
According to the MDCG guidance, software that is used to provide information used to make decisions for diagnosing or treating a condition is a class IIa product. However, that software becomes a class III device if that decision or diagnosis could lead to death or an irreversible deterioration of the patient’s health. This is part of a matrix that largely mirrors the IMDRF risk classification scheme.
MHRA Guidance Addresses Intended Use
Most of the guidances from these agencies avoid any discussion of the legal aspects of intended use statements, but the 2014 MHRA guidance delves into this question, an unusual feature for a product-specific guidance. This question has been very much at the forefront for device makers doing business in the U.S. for some time, and it may be pertinent to examine the MHRA’s approach on the chance that this policy informs its thinking across product categories as a new regulatory structure unfolds.
The guidance states that the intended use can be inferred from advertisements, information found on the developer’s website, and any content on the developer’s social media channels. Disclaimers that the product is not a medical device will not suffice to insulate the product from regulatory liabilities if descriptions of the product’s function make clear that the product falls into the definition of a device. Interestingly, MHRA goes on to say that the developer’s stated view of the product is not the sole determinant of whether the product is a device.
Labeling, instructions for use, the device’s mode of action and manner of use “as perceived by the consumer” can be used to suggest intended use, the MHRA guidance stated, along with the “surrounding circumstances.” This is not entirely dissimilar to the FDA’s policy on intended use, which employs the “all relevant evidence” standard. It is not clear from a brief reading of both agency’s documents whether the FDA’s approach to this is wider in scope, but both developers of SaMD and manufacturers of hardware devices should remain mindful of both agencies’ policies regarding intended use.
