Why Android will be the biggest selling medical devices in the world by the end of 2012

Android and the iPhone are on the way to be the biggest selling medical devices in the world.

But – will FDA software device scrutiny stop the tsunami of healthcare apps or simply slow down the wave?

By the end of the summer 2012, there will be about  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 may be more appealing to consumers than  Android phones (and that is arguable considering the success of Samsung Galaxy 2 and Galaxy 3 outside the US);  the combination of developer sex-appeal and low platform price will probably drive sales of healthcare apps for Android far beyond iPhone in the long run.

As of July 2012, there were over 500 Top selling paid apps in the medical category on Google Play.

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 medical device developers to embed special purpose hardware and their own software apps into a single integrated phone platform.

But – whether software device or integrated hardware and software device – it’s still a medical device that requires the FDA clearance process.

The FDA has a 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.

The 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).

Consider an Android app that performs glucose and heart rate measurements

Consider a healthcare app running for patients that runs on an Android 4.1 device that performs glucose 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.)

It seems like we have the secure healthcare information exchange thing covered – and we didn’t have to write out a 7 figure check for a big complex software from GE Healthcare ( eHealth Information Exchange) or a 6 figure check to develop and deploy a secure server side application that runs on Amazon EC2  (The Amazon Elastic compute cloud) and a 5 figure check for penetration testing and HIPAA certification of your secure service side application for standards-based infrastructure to integrate clinical data from  disparate systems.

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

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 beginning to issue wakeup calls to medical device vendors to implement more robust protocols and tighten up software security of their devices.

Here’s 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 Objective C for iOS , be ready for the FDA looking more closely at in the near future.

As it stands, the problems from software are increasing and so will be the FDA’s scrutiny of your software.

We are expecting an update to the IEC 62304 the beginning of next year, and as soon as we know what the changes are, we’ll let you know.

forward to a friend