Impact of Apple Watch FDA Approvals

FDA is firmly committed to thoughtfully regulating software, but questions remain

Last time out we talked about how virtual clinical trials have the potential to revolutionize medical research, and why Apple is uniquely well-positioned to capitalize on this trend. In a similar vein, today we’re going to do a deep dive into the 2 FDA approvals Apple has received for the Apple Watch and what they mean for the future of software-driven medical devices.

Given the rise of digital technology and the low barrier to entry for software development, there has been an explosion in the number of software applications focused on health and wellness in the past few years. These applications have presented the FDA with a series of regulatory conundrums, as in many ways, software is fundamentally incompatible with traditional medical device regulations, which were written for hardware devices.

To provide some clarity, the FDA issued a guidance for “Mobile Medical Applications” in 2013 that defined 3 categories of medical software applications: (1) apps that are not medical devices, (2) apps for which FDA does not intend to enforce regulations, and (3) apps for which FDA intends to enforce regulations. Teasing apart the differences between these categories would require its own article, but the simple summary is that FDA is focused on regulating the highest-risk software applications. We’re going to zero in on this group for now and explore what Apple has done on this front.

To date, Apple has received two FDA approvals for the Apple Watch — one for the electrocardiograph (ECG) app, and one for the algorithm that can identify irregular heart rhythms. Both approvals fall firmly within the 3rd category we mentioned earlier, meaning that Apple would have needed approval from the FDA to market the features within their Watch. But what do they tell us about FDA’s approach to regulating medical software applications?

Regulating Medical Software Apps is Tricky

You might be wondering why Apple received 2 separate approvals from the FDA for a single product (the Apple Watch). It’s a great question that hits on a major challenge with regulating medical software applications. If a medical software application is designed to be used with an ‘off-the-shelf’ (i.e., non-medical) hardware platform, do you treat the hardware as being a component of the medical device, along with the software application? Do you treat the hardware as being completely separate from the medical device, and only regulate the software application?

Let’s take the first path for a second, and assume that FDA treated the Apple Watch hardware as a medical device component. While this might be the most conservative approach for protecting patient safety, it would have created serious headaches for Apple. They would’ve been forced to overhaul their entire manufacturing process for the Watch to meet medical device regulations, conduct additional testing to satisfy a higher safety standard, and label each product with all of its medical risks and limitations. Or they would’ve had to split their product line into a consumer version of the Watch (w/o medical features) and a medical version. Considering the vast majority of Apple Watch features are non-medical and the vast majority of Apple Watch users are buying the product for non-medical purposes, this approach seems overly burdensome and inappropriate.

What about the second path, in which only the software is regulated as a medical device? While less burdensome, this approach raises serious safety and efficacy questions — how would FDA ensure the hardware was able to capture electrical signals accurately enough to produce an ECG or detect irregular rhythms? While it’s not clear the FDA has all the answers, the Apple Watch approvals do provide a few clues as to how the FDA is thinking about regulating medical software applications.

Apple Watch Approvals Show Commitment to SaMD

Historically, software, when present in medical devices, has been an embedded part of hardware. Embedded software does not raise the same regulatory questions as the Apple Watch apps because with embedded software, it is clear that regardless of the software component, the hardware needs to meet medical device requirements as well. The difference with the Apple Watch apps, on the other hand, is that the software is the medical device, and the hardware by itself would not be a device. This has led to the delineation of a new category of medical software — Software as a Medical Device (SaMD) — defined as software intended for medical purposes without being part of a hardware medical device.

FDA’s approach to regulating SaMD is nascent and evolving, and the Apple Watch is one of the earliest case studies of the agency’s approach. The first place to look is in the labeling, in which both approvals clearly fit the bill for SaMD by stating that they are “software-only” mobile applications intended for use with the Apple Watch. This labeling choice is reflected in the level of special controls FDA deemed appropriate for approval as well, requiring more testing for the hardware than a consumer product, but less than a full-blown medical device. As one example, traditional devices that come into contact with skin during usage would require biocompatibility testing, but this is not mentioned in the Apple Watch approvals.

A few other interesting points come up in the special controls for the two approvals. Both call out a certain amount of testing that must be performed on the hardware to ensure it is able to properly detect signals to pass along to the software. The ECG app leverages a pre-determined dataset to validate the detection algorithm performance, and the irregular rhythm feature requires bench testing to ensure the hardware can detect ‘adequate signal quality.’ From the public approval letters alone, it’s hard to glean more of what this looks like in practice (e.g., what constitutes ‘adequate’ signal quality). Nevertheless, it’s clear that FDA is trying to define a middle ground for SaMD that lies in between regulating the hardware platforms as medical devices, and ignoring them completely.

One thing that was surprisingly missing from both approvals is any mention of a specific Apple Watch model or version. This is another regulatory nuance of SaMD, as software apps are often designed to work across hardware platforms and models, unlike embedded software which may be designed specifically for a single hardware device. FDA’s silence on Apple Watch models in these 2 approvals is a good sign that the agency is being flexible on this front, and is focusing on imposing special controls that are hardware-agnostic rather than tying SaMD to specific hardware models.

Approvals Leave Many Questions Unanswered

Nevertheless, these approvals still leave many important questions unanswered for how SaMD will be regulated. It’s important to take any Apple FDA approvals with a grain of salt, because Apple has an inside track on understanding FDA’s latest thinking around regulating software through the digital health pre-certification program. In addition, as the world’s most popular wearable, the Apple Watch also has a wealth of real-world safety data already that other platforms wouldn’t be able to leverage as evidence.

Both approvals came with a rather lengthy list of limitations, which are often used to reduce the burden for clearance. The ECG app is very clear about the fact that it does not provide a complete diagnosis of cardiac conditions, and the irregular rhythm feature is not intended to detect every episode of atrial fibrillation. This is in line with other SaMD approvals to date, which have generally shied away from (or been unable to pursue) standalone treatment or diagnosis claims. It remains to be seen whether the approach and approval threshold the FDA applied with the Apple Watch will be the same for other, higher-risk SaMDs with more ambitious claims.

As digital technology continues to move into medicine, new regulatory frameworks are needed to mitigate the risks of software while enabling its benefits. While the FDA does not have all the answers today, it’s clear that the agency is committed to thoughtfully regulating SaMD, leaving the door open for developers to create compelling, safe, and effective applications.