FDA Congratulates Itself on Apple’s New Medical Apps

The agency is encouraging innovation in digital health. But is software really so fundamentally different from hardware that it can’t be regulated in the same way?

Image source: Pixabay

In a recent blog post, FDA’s Commissioner Dr. Scott Gottlieb found great merit in the agency’s handling of Apple’s two “marketing authorizations” for medical apps to run on the Watch Series 4. These authorizations were via the DeNovo route to market. Thus, the apps were not “cleared,” which applies to the 510(k) process, and they certainly weren’t “approved,” which is a term reserved for Class III devices that go through Premarket Approval. Gottlieb asserted that these authorizations were “a significant step forward for the agency’s overall approach to the development of digital health.”

It might be noted that Apple’s claim to be first in this arena was challenged by a number of sources including AliveCor, which has made an ECG band for the Apple Watch since 2014, and that device was cleared through a 510(k). However, the AliveCor data must be reviewed by a physician rather than being available to the lay user. In addition, the accuracy of other products of this type has been previously questioned.

It was explained in the blog that these apps were authorized apart from the underlying platform on which they run. This was said to be consistent with “existing guidance,” but the link to such guidance from the blog was to a page of 21 digital health guidances dating from 1999 to 2017, so it isn’t clear exactly what guidance(s) FDA used in this case.

Of perhaps greater interest is that these apps don’t simply run software on the underlying platform—they use sensors in that platform. The blog notes that in this case the apps depended on a sensor built into the watch from which the apps draw their functionality. Yet Gottlieb found this to be consistent with FDA’s general approach of not looking at the platform when considering software. Further, it was stated that “sensors that are general purpose can also be decoupled from review of a medical app.” But the “general purpose” of this sensor is to detect heart signals, which certainly makes it sound like a medical device. More broadly, the idea here seems to be that an app can be marketed without looking at where the input to that app comes from. This is a potential reincarnation of the old yet still true computing expression of garbage in/garbage out.

Further explanation in the blog touts the decoupling of the review of the app from regulating “the entire platform" as a medical device “just to enable a platform to host software with medical functionality.” But this ignores the fact that what was decoupled was not just a software engine but also a sensor and that somehow the sensor gets a pass because it was already part of the watch. This suggests the curious situation that a sensor built into a consumer “every-day health” product need not be regulated even though it then drives an app that is a medical device. On the other hand, if that same sensor was in a medical device and used to drive medical software, it would be regulated.

In addition, Gottlieb says that by focusing the agency's review on the functionality of the software, the FDA aim is to encourage greater innovation in digital health, including the use of artificial intelligence (AI) and clinical decision support software (CDS). But AI and CDS also can’t possibly be valuable if they operate on unreliable data.

We continue to be assured that digital health tools have a “vast potential” to improve diagnosis and treatment, that they give patients more control over their health, and they will help in redesigning physician workflow to better coordinate patient care. This assurance then somehow suggests that digital health devices need less and/or different levels of scrutiny than other medical devices. This is part of the software industry’s claim that software is so fundamentally different from hardware that it can’t be regulated in the same way. This means in part that such old-fashioned notions as design controls can’t or shouldn’t be applied to software because software is inherently iterative. But is this really because it can’t be, or is it because coders simply don’t want to be constrained under that level of design discipline? Actually, all design is iterative, especially if you don’t bother to be careful during the process and you rely on “upgrades” to fix the things you did wrong.

William A. Hyman

William A. Hyman is a professor emeritus in the department of biomedical engineering at Texas A&M University and adjunct professor of biomedical engineering at the Cooper Union. Reach him at [email protected].

500 characters remaining