The use of smartphones in healthcare is old news. Despite the decade-old trend, many challenges still exist with utilizing a patient’s smartphone, especially with optimizing both safety and patient experience. Simple use cases like allowing patients to log actions, get appointment reminders, or just see their test results can be easily addressed. But, as more software as a medical device (SaMD) applications emerge for smartphones, new challenges arise. Medical device companies should embrace these challenges as opportunities to both reduce their system costs and, more importantly, improve patient outcomes.

The challenges of using smartphones for medical device use

For device companies, there are some real engineering and field support challenges to address before the obvious benefits can be realized. The open platform means users can update their OS or add applications that may compete for resources (e.g., Bluetooth)—both of which represent additional complexity for developers who are most likely used to a tightly controlled operating environment.   

The implications of this are evident in the market. Between 2023 and early 2024, there have been at least three recalls of insulin pumps due to issues related to supporting software applications designed for open platforms. Interestingly, each of these recalls demonstrates a different type of system challenge; one had inconsistencies with the install process, a second with user operation within a simplified interface, and a third with an unintended side effect on the pump itself due to an operating mode of the software.

Related:Promoting AI’s Value for Patients

The move from a closed hardware system for the deployment of regulated software can, in some cases, represent a significant paradigm shift for medical device software organizations. The breadth of the failure modes, many in areas not historically considered, creates design risks across many different use cases.

The variety—and version management—of operating systems alone creates significant testing challenges. Add to this the implications of different combinations of installed and active commercial applications and the testing regime becomes an enormous matrix of variables rather than a single controlled device. 

It is easy to understand given this backdrop why device manufacturers have been slow to embrace the goal of full deployment on devices that are not in their control. However, the push from the patient user community is strong and growing, making it increasingly a business imperative to fully support this type of use. 

Related:AI-Enabled Medical Devices: Regulatory Trends in the United States & Beyond

A plan for successful smartphone support

There are steps that can be taken that will ease the transition to a BYOD (bring your own device) world, some of which can be adopted from the commercial application market. Here are a few of the key considerations:

• Handset management strategy: Whitelist, greylist, or blacklist.

• Update strategy: How many versions are you planning to support, and how will you ensure that patients complete upgrades successfully?

• Self-diagnostics: How does the application know that it is operating in a stable environment (e.g., does the application know if the phone it’s running on has been rooted)?

• Verification strategy: How are you planning to test the application, and in how many different configurations? 

Rigorous control over whitelist, greylist, and blacklist handsets will eliminate support for more difficult, unstable, or limited volume handsets, thereby reducing the testing and support scope. Beyond picking the approach, you must decide how the list will be managed over time. For example, if a whitelist approach is being used, what is the criteria for adding a new handset?

Accommodating an untrained user who may also be non-technical requires a deeper review of installation, update, and failure modes. Everyday issues, such as handsets being out of range or intermittent loss of internet connectivity, will necessitate much more robust error identification and recovery processes. Everyday issues, such as alarms, alerts, and notifications, need to be rethought to address this same issue of untrained users. 

It must also be internalized that these open handsets will not be under the control of trained IT departments. Operational errors will occur. Rethinking design processes to adopt standard embedded control software approaches around safety control and device monitoring will ensure a more solid basis for overall system operation. Real effort must be put into implementing self-diagnostics to capture application issues during operation and adverse outcomes and supporting external queries to identify hardware or software failures in external devices.

Finally, reconsidering the testing process itself will be required. Manufacturers will no longer be testing a single integrated system. Incorporating techniques utilized within the commercial software industry, such as building a powerful DevOps toolchain, will streamline the process of testing applications against a broad range of deployment environments and use modes.

In conclusion, the move within healthcare to give patients more control over their care will have a decidedly positive impact on the lives within patient communities. Couple that with the reduction of manufacturers’ hardware costs, continued innovation in smartphone applications on patient owned devices is inevitable. Rather than doubling down on historical medical device development models, embracing the change will open doors to rapid evolution of internal development processes. In the end, this will reinvigorate your team while also significantly improving the fielded products.