Webinar debrief: Applying Human Factors Engineering to Software as a Medical Device

By Merrick Kossack and Cory Costantino

On March 20, 2024, our Senior Research Director Merrick Kossack and Design Director Cory Costantino delivered a webinar on applying Human Factors Engineering (HFE) to Software as a Medical Device (SaMD). This debrief highlights some of the key topics presented during the webinar.

What is Software as a Medical Device?  

The term Software as a Medical Device (SaMD) is used to describe software that is intended to be used for one or more medical purposes and performs its actions without being part of a hardware medical device. Notably, software that is integrated within medical device hardware—such as the graphical user interface of a blood pressure monitor—is not considered software as a medical device because it is not independent from the medical device hardware. However, if a blood pressure monitor were to send readings to a mobile app—where the readings were stored and the patient’s progress monitored—this would be considered SaMD because the software (the app) is serving a medical purpose (to monitor readings over time) and not the hardware (the phone).  

Expectations for HFE process with SaMD 

SaMD is subject to the same regulatory HFE expectations as other medical devices. However, the FDA provides specific guidance related to SaMD. The FDA guidance adopts part of the International Medical Device Regulators Forum’s (IMDRF) SaMD documents, which provide key definitions, a risk categorization framework, quality management guidance, and guidance related to the clinical evaluation of the SaMD.  

The guidance replicates the IMDRF’s SaMD WG/N41 Final:2017 document “Software as a Medical Device (SAMD): Clinical Evaluation”, which, among other things, describes the expectations for the “SaMD Clinical Evaluation Process” as presented below. 

A key takeaway here, from a human factors perspective is that Clinical Validation must demonstrate a positive impact of a SaMD on the health of an individual or population, which would include testing in the target population and for intended use. In other words, validation will also need to include whether users can achieve clinically meaningful outcomes through predictable and reliable use (i.e., usability validation). 

Another key takeaway from the guidance is its risk categorization scheme. Notably, this scheme, as indicated in the table below, attempts to capture the unique characteristics of SaMDs. For example, categorizing the significance of the information provided to a healthcare decision is particularly relevant to this type of product.  

Therefore, it gives manufacturers a useful way of considering differences between different types of SaMDs. However, more classic forms of risk analysis should not be ignored or superseded by this guidance. Terms such as “critical” and “serious” can become confusing when considering that such terms are also used in human factors and risk guidance elsewhere. For example, the potential severity of a “Healthcare situation” as described in the table above does not necessarily correlate to the severity assigned to potential harm defined in a typical risk matrix table, such as the one below, that is used to enumerate risks and identify critical tasks in the parlance of human factors validation.  

Ultimately, both tables can be used to drive HFE activities (e.g., risk mitigation). The IMDRF’s “significance of the information” can be used to help frame hazardous situations (e.g., by considering how the information will be used, and what hazards might therefore ensue), while the classic risk rating approach can still be used to assign the specific severity of harms (not severity of situation) that can occur as a result of, for example, use errors.  

Considerations for SaMD UI design  

Designing a SaMD user interface should employ all of the same techniques and best practices as a typical graphical user interface. Of the many principles discussed in the webinar, below are a couple that are particularly significant in the context of a SaMD:   

Convey the software’s underlying mechanisms with transparency. The application of many SaMD programs is to assist the user with decisions. In a patient-facing SaMD, this can involve medication dose tracking or dose calculation such as a diabetes management app that considers blood sugar readings and meal sizes and calculates a recommended dose of insulin. In an HCP-facing SaMD, this can involve assisting with disease detection or diagnosis, as with AI-powered software that detects potentially cancerous lesions. Where SaMD is making decisions, the mechanisms should be transparent to the user (e.g., by presenting the equation used to calculate the recommended dose or the parameters the AI uses to detect lesions). This will help align the user’s mental model with the SaMD’s operation and will prevent users from questioning or misunderstanding the SaMD’s assessment.  

Design with the use context in mind. The introduction of SaMD can sometimes change clinical workflows, and disruptions to existing workflows could lead to patient harm. Where the SaMD is misaligned with user needs or expectations, users might seek alternative pathways to achieve a certain result, otherwise called a workaround. As such, it is vital to design with the full clinical workflow in mind. If there are other devices or processes that will provide inputs to the SaMD, or that will be driven by the outputs of the SaMD, these other devices and workflows should be considered during the SaMD’s design.  

There are an increasing number of devices that rely on software to assist diagnosis and assess or control the delivery of therapy to patients. Many of these devices incorporate artificial intelligence (AI) or the Internet of Things (IoT). Software as a Medical Device is still a medical device, and just like other medical devices, the development of SaMD should include a rigorous HFE process grounded in risk management. This process should aim to identify potential use-related risks, control them through the software’s design, and then evaluate and validate the effectiveness of the risk control measures with the intended users. 

Contact our global team to learn more about applying HFE to Software as a Medical Device. Or, sign up for a complimentary account with OPUS, our team’s software platform that includes software design training and tools to support the development of your SaMD.