IMDRF Proposes QMS Principles for Software as a Medical Device

In recent years, general-purpose devices such as personal computers, smartphones and wearables have enabled the proliferation of “software as a medical device” (SaMD) products.

The International Medical Device Regulators Forum (IMDRF) is considering a new document that explores how quality management system (QMS) principles can apply to software as a medical device (SaMD) development.

Background

IMDRF was formed in 2011 to “accelerate international medical device regulatory harmonization” after the dissolution of the Global Harmonization Task Force on Medical Devices (GHTF).

IMDRF has identified software as an increasingly critical area of healthcare product development, and has recognized two distinct types of medical purpose software:

• software in a medical device (sometimes referred to as “embedded” or “part of”)
• software as a medical device (SaMD)

The main distinction between the two is whether the software is used “to drive a hardware medical device.” The proposed document, Software as a Medical Device (SaMD): Application of Quality Management System, considers the latter of these two.

In order to promote a harmonized approach to the development and regulation of SaMD products, IMDRF has developed a series of documents concerning their definition and categorization. In 2013, IMDRF’s SaMD Working Group released its Software as a Medical Device (SaMD): Key Definitions, to create a standard terminology for SaMD. The following year, IMDRF adopted its Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations, which proposes a method for categorizing SaMD based on the seriousness of the condition the SaMD is intended to diagnose or treat.

QMS Principles for SaMD

For traditional medical devices with a software component, manufacturers should follow QMS principles for medical devices as well as any good software engineering practices that may apply. While many QMS principles that apply to traditional medical devices, such as those found in ISO 13485:2003, translate to SaMD, companies developing SaMD products will also need to make some additional considerations.

Some of the factors SaMD developers should consider are:

• User-based risks: Is the SaMD product appropriate for all intended users? For instance, are there risks posed by visual acuity for an elderly user, or for patients with peripheral neuropathy?
• Application-based risks: Should a SaMD application be available on any device, or should it be restricted to certain devices in such a way that it could help to mitigate user risk?
• Device-based risks: Is a device with a smaller screen such as a smartphone adequate for the intended application, can a smaller screen display a large set of information without losing the information or making it cumbersome to the users in a way that could affect patient safety.
• Environment-based risks: Is continuity of use (and therefore, safety) of the SaMD product compromised when there are environmental disruptions (e.g., what happens with use interruptions, background noise, loss of network connectivity during use, etc.)
• Security-based risks: Analysis should include evaluating the security threats to SaMD product software code during manufacturing, maintenance and in-service use. Analysis can also include intrusion detection, penetration testing, vulnerability scanning and data integrity testing to minimize system and patient risks.

Developers should also consider the risk posed by the platform or operating system (Windows, Mac OS, iOS, Android, etc.) a SaMD product is installed to. This includes designing SaMD products that take into account “unanticipated upgrades to the underlying platform.”

Software as a Medical Device (SaMD): Application of Quality Management System