One of the more consequential changes between the draft and final guidances is the removal of the software risk framework published in 2014 by the International Medical Device Regulators Forum (IMDRF). This apparently allowed the FDA to eliminate the draft’s use of a binary condition used to start the process of determining the regulatory status of a CDS, a distinction based on whether the CDS informed rather than drove clinical management. This inform-versus-drive question intersected with the question of whether the software was used in the context of a non-serious, serious or critical situation for the patient, resulting in a matrix that specified the inherent risk of the CDS. The removal of the IMDRF risk framework appears to have left the FDA with more leeway to devise a novel approach to oversight of CDS software.
Not all CDS products fall within the scope of this guidance, as it excludes software that is part of a combination product. Labeling requirements for CDS disseminated by or on behalf of the sponsor of a drug or biologic product also fall outside the scope. The FDA’s policies for CDS and other product types are circumscribed by the 21st Century Cures Act, which established four criteria for determining whether software is a device. Per the Cures Act, software must meet each of four criteria to be deemed non-device software, which are that the device is:
- Not intended to acquire, analyze or process medical images or signals from an in vitro diagnostic, or a pattern or signal from a signal acquisition device;
- Intended for the purpose of displaying, analyzing, or printing medical information about a patient, or other information;
- Intended to support or to provide recommendations about a patient’s care to a health care professional (HCP); and
- Intended to enable an HCP to independently review the basis for the recommendation without relying primarily on the recommendation provided by the CDS.
Under the terms of the final guidance, images that were not originally acquired for a medical purpose become medical images under the first criterion, which was not stated in the draft. There is also more detail as to the meaning of a pattern, which the final guidance describes as multiple, sequential or repeated measurements of a signal or from a signal acquisition system.
Discrete and Continuous Measurements Incur Different Regulatory Risks
The draft’s explanation of the second criterion is brief relative to the final guidance, which adds several conditions, much of which falls into the question of analyzing medical information rather than merely displaying or printing medical information. One of these is a discussion of sampling frequency as a determinant as to whether the software is medical information and therefore potentially a device. This distinction hinges to some extent on whether the measurement is a discrete rather than a continuous measurement. The example given is the comparison between a lab-based glucose test and the continuous sampling of the same physiological phenomenon provided by a continuous glucose monitor (CGM). The CGM would provide a pattern or signal, and thus is a device whereas the lab-based glucose test would not be disqualified as a non-device or a device under enforcement discretion under the first criterion. This distinction between one-off versus continuous measurement would presumably apply as well to devices used to measure other physiological processes, such as blood pressure.
However, the more potentially impactful part of the final guidance’s description of the second criterion is how the term “medical information about a patient” is defined. The final guidance defines the term in part as “the type of information that normally is, and generally can be, communicated between HCPs in a clinical conversation.” This also applies to conversations between HCPs and patients, but is conditioned on the requirement that the relevance of that information is “well understood and accepted.” There is little detail in the guidance as to what sort of information is presumed to be typically communicated between HCPs and between an HCP and a patient, and this lack of detail also plagues the question of what would constitute “well understood and accepted” information.
There are a few passages in the final guidance that can help the developer understand where the line might be drawn between a regulated software device versus software that is either not a device per the Cures Act or is a device that is under enforcement discretion. The final guidance cites automation bias as a source of concern, describing automation bias as the propensity to over-rely on a suggestion from an automated system. Among the FDA’s concerns about automation bias are:
- Errors of commission (the HCP follows incorrect advice provided by the CDS);
- Errors of omission (the HCP fails to act because the CDS failed to prompt a given course of action); and
- The likelihood that automation bias will prevail when the software provides a user with only one output or solution rather than a list of options.
Much of this set of concerns is related to a failure of the software to present other available information to help inform the HCP’s decision, but a related concern for the FDA is whether the HCP lacks sufficient time to adequately consider other information. This section of the final guidance seems to at least tangentially harken back to the draft guidance’s use of the IMDRF risk framework and the non-serious/serious/critical scenarios to determine the inherent risk of the software. However, it does so in a manner that seems to eliminate some of the draft’s constraints on the agency’s ability to determine the software’s risk on a case-by-case basis.
Other FDA Digital Policies Affected
One of the difficulties in navigating the implications of this final guidance is that several other guidances have been revised to account for these changes in FDA policy. Among these are the guidance for device software functions, which includes mobile medical apps, a guidance with a large footprint in the digital health space. Our message to software developers is simple, even if following this recommendation will be anything but: Review the CDS and other guidances and examine your existing and pending market authorizations now rather than incur the risk of receiving a communication from the FDA that your product is misbranded. The agency has provided a policy navigator that may be of some assistance.
One of the more conspicuous changes in the final guidance was a complete elimination of the draft’s discussion of functions that are eligible for enforcement discretion, something that was acknowledged on the FDA’s Oct. 18 webinar on the guidance. We found the webinar to be of little assistance in clarifying a number of issues, however, such as how the agency defines “time-critical.” There was also little meaningful information about how the agency would handle a CDS product that the sponsor believes is now subject to regulation as a result of the policies described in the CDS guidance. Brendan O’Leary, the acting director of the Digital Health Center of Excellence (DHCOE), said that no products that were previously unregulated or under enforcement discretion should be subject to regulation merely because of the guidance.
