By Reade Harpham
Mobile device owners have developed an insatiable appetite for mHealth-related applications. According to industry estimates, by 2015, over half a billion people will be using mHealth apps.
The market has noticed, and to meet demand application developers are cranking out healthcare apps as fast as they can for a variety of uses. Some apps help people manage their own wellness. Others are used by healthcare professionals to access patient electronic health records. And some apps can even control medical devices, or display images and data that can be used by physicians to diagnose and treat disease.Some apps can even control medical devices, or display images and data that can be used by physicians to diagnose and treat disease.
While the technology platforms have changed, the humans using these products haven’t. Application manufacturers must still have the same concern for patient risk and safety as manufacturers of any other healthcare product.
Software innovators often ask: How do I know if my app is a medical device; and if it is, how do I know whether it’s subject to regulation?
Section 201(h) of the FD&C Act
defines the boundaries for what constitutes a “medical device.” If a product is made that is intended for use in the diagnosis, treatment, or prevention of a disease or other health condition, it can be considered a medical device. Under this definition, most healthcare apps likely fall into this category.
However, the FDA has indicated
that it does not intend to enforce regulation on every app that meets the definition of a medical device. Rather, it intends to use discretion in those cases where the app’s use (or potential misuse) poses a low risk to patients.
According to p.7 of the guidance, the FDA defines a “mobile medical app” as an app that “is intended to be used as an accessory to a regulated medical device; or to transform a mobile platform into a regulated medical device."
The first criterion is the easiest to understand. If your app connects to a regulated device in some way, it is reasonable to assume that it should be considered an extension of that product. For example, consider an app that controls an insulin pump. Because the pump is a regulated device, any app that connects to and controls the pump would likely be considered an extension of that device as well.
The second definition applies to technology that already exists and is just being converted into mobile form. For example, if you develop an app that is intended to replace an older electrocardiograph (ECG) machine with a streamlined version that runs on a mobile interface, that app would likely meet the same regulatory threshold as the original machine because it would still be receiving, measuring, and displaying ECG signals for analysis.
But if a mobile app is not intended to do any of those things, the FDA has stated that it intends to exercise discretion. Examples contained in the guidance document include apps that help patients self-manage their own conditions, track their health information, communicate potential medical conditions to healthcare providers, and so forth. In most cases, these types of apps might not be subject to regulatory enforcement. (Of course, you should always review the guidance and contact the FDA if you have any question over which category your app falls into.)
Regardless of whether or not your app is a medical device, you should still use a strong human-centric approach when developing it. Include human factors activities, research, and testing into your development plan. Not only is it the best way to prevent patient harm, it’s also the best thing you can do to maximize user satisfaction and long-term adoption once it hits the app store.
Reade Harpham is a Director for Battelle Human Centric Design where leads a multidisciplinary team of designers, behavioral scientists, human factors engineers, cognitive psychologists, design researchers, and modeling and prototyping experts. The purpose of the Human Centric Design team is to understand end user needs and translate them in to product or service opportunities. This team also designs and executes formative and summative human factors usability studies to meet FDA requirements. In his role, he is actively involved in the design process from initial opportunity qualification, proposal planning and execution, through detailed design and development.