Introduction
mHealth evolved largely an application for developing countries, due to the rapid growth of mobile phone penetration in low-income nations.
But mHealth is now a game-changer for clinical trials, enabling electronic patient reported outcomes and integration with medical devices using standard hardware and mobile operating systems.
There are 3 key use cases of mHealth in medical device clinical trials:
1. ePRO – patient reported outcomes using smartphone apps that integrate with EDC APIs
2. As a mediation layer for medical devices, enabling a medical device to obtain connectivity to the EDC by communicating with a mobile app over BLE (blue tooth low energy).
3. As a mobile medical device in its own right
Why Android is the biggest selling medical device in the world
After a short marketing review of why Android is already the biggest selling medical device in the world, I’ll review FDA requirements for clearing mobile medical devices which need to be taken into account before bringing mHealth (mobile medical apps) into your connected medical device clinical trial.
Connected medical device vendors moving into clinical trials need to consider the regulatory requirements in advance since they are in a near-real-life situation with patients during their trials and will probably be using a similar configuration in post-marketing.
The marketing stats
In 2016, publishers of mobile health apps brought to market 100,000 more apps, a 57% increase over 2015. This brought the total to 259,000 health apps globally available to consumers, according to new study mHealth App Developer Economics 2016 conducted by health research group Research 2 Guidance. By 2017 there were 325,000 mobile health apps available online and Android is now the leading mHealth platform
With its global popularity and a large developer community – Android is a natural choice as a tool for data management in your clinical trial or as middleware for your connected medical device.
Android and iPhone – the biggest selling medical devices in the world.
Connected medical devices are everywhere.
Consider the popular Runkeeper app and how it fits nicely into a community of runners and then consider how a support group for people with diabetes can use their diabetes management app to share information and reinforce their diet and exercise habits.
As of summer 2012, there were 13,000 health apps intended for use by consumers available in Apple’s AppStore, according to Consumer Health Apps for Apple’s iPhone.
Most of these are available for Android also – and due to it’s Linux and open source background, Android has a big advantage over iOS when it comes to developing healthcare apps and exchanging healthcare information between patients and physicians in a secure, standard and vendor-independent fashion.
While the iPhone has a better design than Android phones; the combination of developer sex-appeal and low platform price is driving development and sales of healthcare apps for Android far beyond iPhone in the long run.
But something more fundamental will drive medical device developers to Android instead of iOS; and that is the Android Open Source Project Apache 2.0 license. Android is about freedom and choice. The purpose of Android is promote openness in the mobile world and this openness enables connected medical device developers to embed special purpose hardware and their own software apps into a single integrated phone platform.
Beyond the marketing and into your clinical trial
Validation and verification
The FDA has a process for clearing healthcare apps. V&V is central to this process and if you are developing a mobile medical device – you need to understand and be able to execute V&V.
First of all, we need to clarify that the FDA is concerned with patient safety, not privacy (that’s HIPAA and the HHS) and not how well the healthcare app was written and whether it has an outstanding UI design.
The FDA process for clearing healthcare apps
First of all, we need to clarify that the FDA is concerned with patient safety, not privacy (that’s HIPAA and the HHS) and not how well the healthcare app was written and whether it has an outstanding UI design.
In 2011, the Food and Drug Administration (FDA) proposed guidelines that outline the small number of mobile apps the agency plans to oversee—medical apps that could present a risk to patients if the apps don’t work as intended. The proposed guidelines are posted on the Federal Register website. For more information, visit FDA’s Mobile Medical Apps page.
FDA policy advisor Bakul Patel says that mobile healthcare apps are designed to help consumers manage their own health and wellness—like the National Institutes of Health’s LactMed app, which gives nursing mothers information about the effects of medicines on breast milk and nursing infants.
Other apps are aimed at helping health care providers improve and facilitate patient care—like the Radiation Emergency Medical Management (REMM) app, which gives health care providers guidance on diagnosing and treating radiation injuries. There are even apps to aid diagnosis of rashes and heart irregularities.
The FDA has already cleared a handful of mobile medical apps used by health care professionals, such as a smartphone-based ultrasound and an application for iPhones and iPads that allows doctors to view medical images and X-rays.
FDA is also keenly aware that software defects are the root cause of threats to patient safety:
The FDA strongly recommends that manufacturers of all mobile apps that may meet the definition of a device follow the Quality Systems14 regulations (which include good manufacturing practices) in the design and development of their mobile medical apps and initiate prompt corrections to their mobile medical apps, when appropriate, to prevent patient and user harm. The FDA has found that the majority of software-related device failures are due to design errors. In one study, the most common problem was failure to validate software prior to routine maintenance.
Establishing a level of concern for a healthcare app (its a software medical device)
The first thing that you do when you start thinking about submitting your Android healthcare app for a 510(k) premarket notification is establish a “level of concern” for patient safety. There are 3 levels of concern – major, moderate and minor.
A major level of concern means can a person be killed or seriously damaged by using the medical device or in our case, a healthcare app for Android or iOS.
The FDA uses the term “minor injury” to mean any injury that does not meet the definition of a serious injury as defined in 21 CFR 803.3(bb)(1). This regulation defines serious injury as an injury or illness that:
1. is life threatening;
2. results in permanent impairment of a body function or permanent damage to a body structure or
3. necessitates medical or surgical intervention to preclude permanent impairment of a body function or permanent damage to a body structure.
The term permanent is defined as “irreversible impairment or damage to a body structure or function, excluding trivial impairment or damage.” 21 CFR 803.3(bb)(2).
Transmission security is not enough
Consider a healthcare app running for patients that runs on an Android device that performs glucose measurement and heart rate measurements and transmits them to the physician’s Android device using Orbot Tor for Google Android devices. By the way, you can also do this on iOS using the Onion Browser for iPhone.
(Tor (short for The Onion Router) is a system intended to enable online anonymity. Tor client software directs internet traffic through a worldwide volunteer network of servers to conceal a user’s location or usage from anyone conducting network surveillance or traffic analysis.)
A naive developer might assume use of Tor is sufficient since it assures anonymity, but transmission security is only 1 out of over 40 cyber-security controls required by the HIPAA Security Rule. In order to actually collect the data and provide a UI, we still need to develop, deploy and sustain security for application services that run on Amazon EC2 (The Amazon Elastic compute cloud). In addition, we will need to perform a threat analysis, conduct penetration testing and verify proper procedures for breach notification in order to comply with FDA Cybersecurity guidance for medical devices.
What is the level of concern?
Lets try and classify our mobile healthcare for glucose and heart rate measurements as to what the FDA calls “Level of concern”
Prior to mitigation of hazards, could a failure of the Software Device result in death or serious injury, either to a patient or to a user of the device? If so – it is a “major level of concern”.
If the answer to any one question below is Yes, the Level of Concern for the Software Device is likely to be Major.
1. Does the Software Device control a life supporting or life sustaining function? No
2. Does the Software Device control the delivery of potentially harmful energy that could result in death or serious injury, such as radiation treatment systems, defibrillators, and ablation generators? No
3. Does the Software Device control the delivery of treatment or therapy such that an error or malfunction could result in death or serious injury? No
4. Does the Software Device provide diagnostic information that directly drives a decision regarding treatment or therapy, such that if misapplied it could result in serious injury or death? No
5. Does the Software Device provide vital signs monitoring and alarms for potentially life threatening situations in which medical intervention is necessary? No
If the Software Device is not Major Level of Concern and the answer to any one question below is Yes, the Level of Concern is likely to be Moderate.
1. Is the Software Device an accessory to a medical device that has a Moderate Level of Concern? No
2. Prior to mitigation of hazards, could a failure of the Software Device result in Minor Injury, either to a patient or to a user of the device? No
3. Could a malfunction of, or a latent design flaw in, the Software Device lead to an erroneous diagnosis or a delay in delivery of appropriate medical care that would likely lead to Minor Injury? Maybe
Using this analysis, it seems that our Android healthcare app that measures glucose level using nail bed or ear lobe measurements and transmits results to the physician is probably a minor level of concern and not more than a moderate level of concern.
If we take this healthcare app to the next level and transmit data to the insulin pump on the patient in order to complete the feedback loop – we have a good shot at killing the patient because of a software bug – and that is a already a major level of concern.
At Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin
pumps. Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary
food).
Following the proof of concept attack on ICDs by Daniel Halperin from
the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio
Attacks and Zero-Power Defenses” – the FDA is started to issue wakeup calls to medical device vendors to implement more robust protocols and tighten up software security of their devices.
This is a heads up from the FDA – don’t say you weren’t warned.
If you have software in your mobile healthcare app whether it’s written in Java for Android or Swift for iOS , be ready for the FDA looking more closely at your mobile medical app in the near future. As it stands, the cybersecurity problems from software are increasing and so will be the FDA’s scrutiny of your software.
