Challenges Incorporating Mobile Devices into Medical Devices

[Mark Meer]

I'd like to start a thread to discuss challenges associated with incorporating mobile devices into medical devices.

There are several applications:

1. Mobile device is intended to replace an existing wireless controller. This was discussed briefly in another thread.
2. Mobile device used to configure a medical device (but not involved in actual therapeutic use).
3. Mobile device used to passively gather data from the medical device.

In anycase, there are several challenges that I'm not clear on how to deal with. Specifically the challenge that there are hundreds of potential devices out there, and each has an obsolescence cycle of 6 months to a year. So, you could certainly specify minimum requirements (e.g. "any device running Android 7, with XYZ minimum hardware requirements"), but there are still lingering questions:

• What level of evidence is expected to make such a generalized statement? Surely not all permutations of operating system versions and hardware is required to be tested? Is there some guidance as to the appropriate level of testing?
• How do you deal with EMC safety? In particular with respect to case (1) above - the mobile device, acting as a controller, is essentially part of the medical device. Again, surely the expectation is not that you've 60601-1-2 tested every compatible mobile device?

Unfortunately, despite huge potential in this area (as mobile devices become ubiquitous), it's difficult to plan out a development project without a clear sense of the regulatory expectations. Any input, or links to guidances/regulations dealing with these concern much appreciated!

 

[Mark Meer]

I've started reading through the IMDRF's documents regarding software as a medical device (SaMD), and am already not clear. In the first document, "Key Definitions" it says (5.1):

The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.
...
“without being part of” means software not necessary for a hardware medical device to achieve its intended medical purpose;
Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device
....

Does this mean that the MD device hardware must be able to operate independently of the SaMD? What if this is in the context of use-case #2 I described in the original post - mobile device is used to configure a MD device? In this case you could technically still use the device, but you wouldn't achieve optimal results without proper configuration (via the mobile app).

Also, what does it mean "its intended purpose is to drive a hardware medical device"? Does this mean that the use-case #1 I outlined in the original post - mobile device replaces an existing controller - the app installed on the mobile device would not be considered SaMD?

Document N12 (Possible Framework for Risk Categorization) also give the following example of what is NOT SaMD:

Software required by a hardware medical device to perform the hardware’s medical device intended use is not SaMD even if/when sold separately from the hardware medical device.

So...what status of such software? An accessory (even though it is required by the hardware)?