Consumer mHealth App or Regulated Medical Device?

The line between consumer a consumer mHealth app and a regulated medical device comes down to what kind of user data is being collected and how it’s being used.

March 4, 2015

6 Min Read
Consumer mHealth App or Regulated Medical Device?

The line between consumer a consumer mHealth app and a regulated medical device comes down to what kind of user data is being collected and how it’s being used.

Reade Harpham

When is an app more than an app? mHealth is one of the fastest-growing segments of the digital marketplace, with more than 100,000 health and fitness apps available in the Apple iTunes store alone and tens of millions of downloads each year. The vast majority are consumer-focused apps that are not subject to FDA regulation. But when developers cross the line and start providing medical information or advice, they enter a whole new world of liability and regulation. How do you know when your app has become a medical device? And what steps do mHealth developers need to take to reduce their risks?

The line between a consumer mHealth app and a regulated medical device comes down to what kind of user data you are collecting and whether that data is used to make a medical decision by the user, by the user’s doctor, or by the app itself. The popular LoseIt app, which allows users to track calorie intake and activity levels for weight loss, falls clearly on the consumer side. An app designed to help diabetics track blood sugar levels and determine how much insulin to take is clearly a medical device. But others are not be so clear-cut. Is an app that allows users to input daily blood pressure readings a medical device? If it’s simply a log, probably not. But if it offers advice or diagnosis based on those readings or transmits the information to a doctor to allow them to monitor a patient’s health, it has crossed the line.

Questions that developers should be asking themselves include the following:

  • Does the app diagnose a medical condition or provide information that allows a doctor to make a diagnosis?

  • Is the app designed to help a patient monitor a chronic medical condition?

  • Does it transmit information between a patient and a healthcare provider?

  • Does it provide data or advice to help patients or healthcare providers make decisions about medication or other treatment options?

If the answers to any of these questions are yes, the app is probably considered a medical device and subject to FDA requirements for both safety and security.

mHealth apps are bringing healthcare out of the clinic and putting more power and control into patients’ hands—often literally. They can provide a critical link between patients and healthcare providers between visits, improve the quality of health data for better medical decisions, and empower consumers with on-the-go access to healthcare information. But when apps become medical devices, the potential for user harm can be high. FDA is starting to take notice. mHealth apps that provide diagnostic or prescriptive data are subject to the same FDA requirements for safety and security that traditional medical devices must meet. Safety means the app will not cause patient harm. Security means the app cannot be hacked or tampered with in ways that put patient health and safety or their data security at risk. mHealth app developers need to have processes in place to assess and mitigate four types of potential risks:

Human error. End users, whether patients or healthcare providers, may use the app in unintended and unanticipated ways that could result in substantial risks to health and safety. Some user errors may result from poorly designed interfaces or overly complex instructions. Others may result from making the app too hard for the intended user to access or too easy for unintended users. Think about a medical app that must be simultaneously easy enough for an 85-year old woman to access when she needs it and hard enough to keep her 4-year-old grandson from accidentally impacting it when he plays with grandma’s phone. The wider the pool of potential users, the greater the chances are that some users will make mistakes. One app developer learned this the hard way when an app designed to help diabetics monitor blood sugar levels found an international audience. Because the United States and UK use different units to measure blood sugar, UK users who relied on the app to help them make insulin decisions could have made a potentially fatal error if they did not notice or understand the different units.

Hardware failure. What are the risks to patient health and safety if the device running the app stops working? Is critical data backed up so it can be restored on a new device? What if the iPhone being used to display the information runs out of batteries? Is the device still able to function? How do you compete with the other cognitive distractions when using an mHealth device? Developers must think through the potential risks related to hardware failure and make sure their app is designed with these failures in mind.

Software failure. Bugs, security holes and software compatibility risks can present tremendous challenges for mHealth developers. Apps must be designed to work across all of the potential devices and operating systems that end users may have and when operating systems are updated, developers must be prepared to reevaluate the app to ensure that no new security risks or compatibility issues have been introduced.

Malicious tampering. As healthcare becomes mobile and networked, we also introduce the potential for deliberate hacking. Sessions at the 2013 and 2014 BlackHat conferences demonstrated a variety of ways that patients could be put at risk by hacking devices such as insulin pumps or pacemakers. mHealth apps may also be vulnerable to deliberate Denial of Service (DOS) attacks that could prevent timely transmission of critical health data between doctor and patient. In some cases, hackers may be deliberately trying to harm patients. In other cases, hackers may be after patient data, your intellectual property or seeking a back door entrance into hospital networks.

Developers wishing to move into the world of mHealth apps need to put comprehensive risk profiles together in order to protect patients, data and intellectual property. For apps and connected medical devices, this means looking at both human factors and cybersecurity risks. Human factors testing has long been part of the FDA regulatory process for traditional medical devices, and developers of medical apps must make it part of their development process as well. Because cybersecurity is a relatively new issue in the medical device world, guidance from FDA is more limited. In 2014, FDA released draft guidance for the industry in its publication Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. As the industry evolves, we can expect to see more emphasis on cybersecurity in FDA’s regulatory framework for medical apps. For now, medical app developers must be able to evaluate the potential vulnerabilities in their software and anticipate future cybersecurity regulations.

A comprehensive risk management plan for mHealth apps includes three critical elements:

  1. Usable design (incorporating the specific needs of the intended user population from the beginning).

  2. Vulnerability assessment (characterizing, modeling and measuring existing threats).

  3. Secure design (cybersecurity, anti-tampering and anti-counterfeiting measures.).

The mHealth revolution is just beginning. As more apps start to cross the line from consumer novelties to true medical applications, the potential benefits for patients and providers are enormous. So are the potential harms. By building safety and security in from the start and carefully anticipating potential risks, developers can move healthcare into the mobile world safely and securely.

Reade Harpham is director of human centric design at Battelle, a nonprofit research foundation with extensive experience in both cybersecurity and human centric design for the medical community.


Sign up for the QMED & MD+DI Daily newsletter.

You May Also Like