Since connectivity runs on software, and some medically related software is a medical device, and medical devices are regulated by the FDA, those involved in connectology must pay at least some attention to what the FDA is saying about the subject of medical software that is not an inherent part of some other medical device.  In this regard the FDA speaks in multiple ways, ranging from regulations, to final guidance documents (fGD), to draft guidance documents (dDG), to more casual public comments. Recently (since October 1st) the FDA has been busy in the software space by releasing several new fGDs and dGDs that specifically address software. I will outline these here. Overall the FDA identifies over 20 guidances with "digital health content".  In addition, other general guidance might also be relevant to medical software even if software is not their named focus.

There have been two final guidances related to software since October 1st, along with 16 other new fGDs. The first of particular interest to us is Deciding When to Submit a 510(k) for a Software Change to an Existing Device which I have already addressed here. The second is Software as a Medical Device (SAMD):Clinical Evaluation. We discussed a draft of this document back in December, 2016. SAMD is software that on its own is a medical device, as opposed to software that is in or part of another medical device. Like medical devices generally, SAMD  devices have to be shown to be safe and effective (or maybe only substantially equivalent) via the appropriate regulatory pathway, and this may involve a clinical evaluation. This guidance is a product of the International Medical Device Regulators Forum (IMDRF), a voluntary group of medical device regulators from around the world including the FDA.

There have been 8 dGDs in the same period, two of which relate explicitly to software. One of these is Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act. That act removed certain types of medically related software from the definition of a medical device, and correspondingly removed them from FDA regulation even if the FDA wasn't actually regulating them. Four categories of software are addressed in this dGD. These are:

(1) software for the administrative support of a health care facility,

(2) software for maintaining or encouraging a healthy lifestyle,

(3) electronic medical record software, and

(4) software intended for transferring, storing, converting formats, or displaying data and results.

Some existing guidances associated with these types of software will be revised in as yet unknown ways. These include (with date of issue)

The on-line versions of each of these now carry the notice that "The 21st Century Cures Act (12/13/2016) amended the definition of “device” in the Food, Drug and Cosmetic Act to exclude certain software functions, including some described in this guidance document. FDA is assessing how to revise this guidance to represent our current thinking on this topic".  In addition. the FDA says that one current guidance,  Submission of Premarket Notifications for Medical Image Management Devices (2000), will eventually be withdrawn.

Another new dGD which is also a response to the Cures Act is Clinical and Patient Decision Support Software - Draft Guidance for Industry and Food and Drug Administration Staff. Here the FDA explains what kinds of Clinical Decision Support (CDS) programs are considered medical devices and what kinds are not. One distinction is that a CDS that has a transparent basis such that the professional user could replicate the logic of the advice provided may not be a medical device subject to some other provisions. Therefore science and guideline based CDS systems could be not medical devices, but machine learning based systems would be medical devices since the latter offer no underlying explanation other than we looked at alot of cases. CDS's that process images or signals from a medical device also remain as medical devices. The FDA also newly defined Patient Decisions Support (PDS) systems in order to declare that PDS were medical devices depending on their risks and functionality because the Cures Act exemptions are expressly limited to systems for professional users. This risked based analysis may include the interesting category of "yes it is a medical device but we aren't going to regulate it anyway", a category that may be familiar from Medical Device Data Systems (MDDS) for which the FDA has previously stated that it "does not intend to enforce compliance with the regulatory controls that apply to MDDS devices", which is different from those regulatory controls not applying. It is also good to remember that things that aren't medical devices are still subject to other post-market government regulations such as those from the CPSC if there are safety issues and the FTC which has express interest in products that have health claims.

Clearly software developers should be aware of and in compliance with FDA's current and evolving regulations, and software customers should be aware of whether or not products they are considering are, or should be, in compliance with these regulations. The latter is always a good question for a customer to ask, and the potential answer of "this isn't a medical device" should be subject to further scrutiny.