23 February 20246 minute read

IMDRF publishes draft software risk classification document

The International Medical Device Regulators Forum (IMDRF) has published a revised software risk classification technical document, entitled, “Medical Device Software: Considerations for Device and Risk Characterization.”

Released by IMDRF’s Software as a Medical Device (SaMD) Working Group on February 2, 2024, the document proposes an updated framework designed to help industry and regulators around the world characterize devices and associated risks.

When compared to IMDRF’s 2014 technical document, titled, “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations,” the latest draft document broadens IMDRF’s focus from SaMD to include other instances of software used in healthcare settings and adopts a different approach when assessing risk.

The document is open for comment until May 2, 2024. Below, we provide background on the IMDRF as well as key details and takeaways on the new technical document.

IMDRF and the SaMD Working Group

The IMDRF is a voluntary group of medical device regulators from around the world who collaborate on projects in support of international medical device regulatory harmonization and convergence. The Forum is currently chaired by Jeffrey Shuren, director of the Food and Drug Administration’s (FDA) Center for Devices and Radiological Health. The chair position is assigned to an individual from a different management committee member country on a rotating basis.

Starting in 2013, the IMDRF’s SaMD Working Group issued an initial series of technical documents for SaMD products before dissolving. In September 2022, a new SaMD Working Group convened to evaluate how the landscape has changed since publication of the original group’s documents, and to refresh guidance as necessary. The current group is co-chaired by representatives from Health Canada and FDA.

Scope of 2024 software risk classification document

This first technical document issued by the new SaMD Working Group refers to a broader set of “medical device software” products. The document provides several examples to help illustrate the types of products that fall under that category, including software that is:

  • Intended to generate information for use in achieving one or more medical purposes
  • Part of a hardware medical device
  • Not part of a hardware medical device and independent of other medical devices
  • Necessary for a hardware medical device to achieve its intended use/intended purpose
  • Driven or influenced by another medical device
  • Generating output intended for a human user, medical device, and/or non-medical device, and
  • Using inputs from humans, medical devices, and/or products that are not medical devices.

IMDRF’s document splits characterization into two major areas: (1) characterization of the medical device software and (2) characterization of the risk associated with that software.

Device and risk characterization

Characterization of medical device software allows stakeholders to fully understand the device and characterize the associated risks and benefits. This involves developing (1) an intended use/intended purpose statement and (2) a device description. These steps are fundamental areas of interest for regulators. The document elaborates on these areas, providing a harmonized set of considerations the industry and regulators should take.

The document further encourages consideration of the context in which the software will be used – for example, whether the software will be used in a healthcare setting or home, and whether the user will be a medical professional or lay-user. Aspects such as appropriate output of the software and general usability rely heavily on this context of use.

In discussing risk characterization, IMDRF’s document flags three key points for consideration:

  • Medical device software can yield direct and indirect harms – assess the risks of both. For example, a software error could cause the device to administer an incorrect dose of medication, which would be a direct harm. At the same time, a software failure could cause a delay in diagnosis and/or treatment, which serve as indirect harm.
  • Medical device software harms can result from reductions in effectiveness. This is because hazards from medical device software can often be information based. For example, incorrect information outputted to the user could lead to incorrect follow-up actions. In these cases, in addition to potential safety issues, effectiveness-related issues should also be considered. A reduction in device effectiveness due to a software error poses an indirect harm to patients.
  • Potential harms from medical device software may be largely dependent on the device’s specific intended use. Therefore, careful attention should be paid to intended use when characterizing risk. The device characterization efforts described in the prior section are designed to support this.

The IMDRF’s document provides common considerations regarding device characterization and risk characterization, but does not follow the 2014 technical document approach of assigning specific risk categories. Such decision seems to mirror FDA’s 2022 decision to no longer to include reference to the four-part risk classification approach in its guidance on Clinical Decision Support (CDS) software (FDA CDS Guidance).

In fact, the 2024 IMDRF document aligns well with FDA’s approach to regulating software, as the draft includes increased focus on how software inputs and outputs influence risk classifications and considerations for defining software risk similar to those outlined in FDA CDS Guidance.

Intersection with AI

IMDRF’s proposed document acknowledges the intersection between medical device software and AI. The document specifically references the Association for the Advancement of Medical Instrumentation’s (AAMI) document TIR34971, titled, “Application of ISO 14971 To Machine Learning In Artificial Intelligence—Guide.”

In addition, the IMDRF clarifies that the document “is not intended to replace or conflict with existing IMDRF publications such as those published by the [AI] or Cybersecurity Working Groups; however, it is acknowledged that there are direct relationships and overlap with those publications, and this document is intended to be complementary.”

Looking forward

Through this document, the IMDRF (and its participant regulatory authorities) acknowledge the importance of updated thinking on software regulation – and that the relationship between software and medical devices extends beyond the traditional concept of SaMD.

The publication is part of a trend of international organizations tackling digital health regulation on a global scale. Since the start of the year, the Organisation for Economic Co-operation and Development (OECD) published a paper entitled, “Collective action for responsible AI in health,” the World Economic Forum launched its global initiative to advance digital and AI-driven transformation of healthcare systems and the World Health Organization (WHO) launched its Global Initiative on Digital Health. Among other things, these initiatives aim to support cooperative learning and digital health harmonization.

Industry stakeholders are encouraged to review the IMDRF technical document in full. Stakeholders may submit comments to influence the direction the proposed guidance, using the instructions found on this page, ahead of the May 2, 2024 deadline.

For more information on the document or the rapidly evolving digital health regulatory landscape, please contact your DLA Piper relationship partner or the authors of this alert.

Print