To Provide or Not: Bring Your Own Device vs. Kitted

As a consultant to medical device developers, I frequently observe this decision being made. Companies must choose whether they want to support the Bring Your Own Device (BYOD) route or supply a smartphone with the medical device (i.e., kitted). Further, this choice can be significant to the developer, as it can entail substantial ongoing costs. At a minimum, this decision needs to be made in advance, regardless of the option selected. 

First, let me back up and start at the beginning. 

Suppose you are a medical device developer, and your latest product supports communication between the device and a smartphone. This almost always means communication is performed via Bluetooth Low Energy (BLE). This also means the smartphone will be running either Android or iOS. (I recognize there are other alternatives, such as HarmonyOS, KaiOS, Tizen, etc., but these are niche-market players and can be ignored.)

Consideration needs to be paid to the intended role of the smartphone:

• Is the smartphone the primary user interface for a medical device? (Tip: Avoid this, if at all possible.)
• Can the smartphone change the medical device’s operation and/or settings?
• Is protected health information being exposed on the smartphone?
• How is a user authenticated to the smartphone? Remember, the user may be in pain or otherwise experiencing cognitive impairment when they need to use the app. Can they remember a pin during this scenario?
• Does the app have support for alarms and alerts (i.e., increased regulatory concern)?

The answers to all of these questions will guide the nature of your utilization of smartphones.

The first decision is to select what the app(s) are going to be written in. This can be a native programming language (e.g., Kotlin, Java, Swift, etc.) specific to a given operating system, or a cross-platform framework such as Flutter or React.

While writing and testing a single app may sound advantageous, the use of a cross-platform framework does introduce several potential issues:

• Increased code size: Due to the inclusion of the framework’s engine in the executable
• Increased latency: Having multiple layers to execute through does not increase performance
• Sensors: Potential problems with novel sensors on specific smartphone platforms
• BLE: Trying to use non-customary BLE features such as “data length extension” or concurrent BLE connections can be difficult or impossible. Both can be extremely valuable for an app that interfaces to a medical device (those are very in-depth technical topics worthy of an article all on their own).

Native languages bring a second codebase to develop/test/maintain, but this means your app will have full access to the “features” available on a given type of platform, such as the aforementioned BLE connection items.

Unless this is an extremely simple app with limited features, future growth, and BLE connectivity, the correct choice is to use a native programming language.

The next decision is even more challenging to make. Do we support BYOD, where the end user supplies their own smartphone platform upon which to execute your app, or provide a kitted device? Each option comes with its own set of pros and cons. 

We’ll begin with the BYOD approach and the pros this option provides. 

• You don’t have to pay for a smartphone; the end user incurs that expense (that is, if they are among the 1% of the population without a smartphone already). 
• The app is easily distributed (and updated) via the Play Store or App Store service of the given platform.
• The only cybersecurity consideration is the app, not the platform upon which the app is being executed, which simplifies design/testing/maintenance.

Among the cons of the BYOD approach are:

• You need to officially support a small set of smartphones for validation testing. This list is getting smaller every year, however, due to manufacturers leaving the smartphone industry.
• Ongoing validation testing needs to be re-performed post-market frequently due to updated operating systems being released.
• Initial authentication between the medical device and the app is performed by the end user while the device is in the field, thus adding an additional step for the end user.

Now, let’s examine the pros of the kitted approach:

• There is only one app and one operating system to develop/test/maintain.
• Validation testing is simplified.
• Initial authentication between the medical device and the app can be securely performed during manufacturing.

Among the cons of the kitted approach are:

• The manufacturer will have to buy a large lot of smartphones.
• Each lot of smartphones incur the chance of being slightly different, both in hardware and operating system.
• The smartphone manufacturer will, at some point (usually measured in months), cancel production of the model of smartphone selected.
• The FDA considers the physical smartphone to be a “medical device accessory” and, as such, needs all the same level of design/development considerations.
• The smartphone needs to be “hardened,” which means configuring all “features” of the smartphone to be as secure as possible—both hardware and software.
• The smartphone may be required to be configured in a “single app” kiosk mode, where only one app (the medical device app) can run on the smartphone. No Angry Birds or Candy Crush for users.
• The smartphone will be required to be managed by the manufacturer for its entire operating life. This includes updates to the app as well as updates and security fixes to the operating system. This requires the use of mobile device management tools, such as Hexnode, Scalefusion, Miradore, Ivanti Neurons, VMware Workspace ONE UEM, etc. Additionally, these tools come with an ongoing cost.
• Similarly, malware detection and integrity agents need to be present on the smartphone, reporting back to the manufacturer. These tools also come with an ongoing cost.
• How replacement units will be provided and paid for needs to be determined. 
• How those same replacement units will be pre-authenticated to the medical device in the field also needs to be resolved.

It is not uncommon to have a mix of off-the-shelf commercial products supported in a medical device system, such as smartphones, tablets, and laptops. They are usually broken up by the user’s role, such as patient, loved one, healthcare provider, caregiver, surgeon, etc. In addition, each of these devices may employ either a BYOD or a kitted approach, so you are likely to have a mix of approaches for a given system.

So, which one is correct for each use case for your next product? Unfortunately, no one else can answer that question. The developer needs to consider all of the topics, pros, and cons provided in this article before making a final determination. One final note: generally speaking, the use of BYOD is the easiest, fastest, and cheapest approach, but it isn’t always the right choice.

MORE FROM THIS AUTHOR: Questioning the Continued Lack of a Focus on Cybersecurity

Christopher Gates is the founder and CEO of arsMedSecurity, a medtech cybersecurity consulting firm. He is a recognized thought leader in medtech cybersecurity and the current co-chair for H-ISAC’s MDSC. Gates has over 50 years of experience developing and securing medical devices and works with numerous device manufacturers. He frequently collaborates with regulatory and standard bodies, including the CSIA, Health Sector Coordinating Council, H-ISAC, and Bluetooth SIG.