The FDA has, at long last, finalized a major piece of its overall framework for regulation of digital health technologies and software as a medical device (SaMD). The final guidance on regulation of clinical decision support (CDS) software attempts to clarify the Agency’s increasingly complex approach to determining what types of software are subject to the FDA’s oversight. Unfortunately, rather than establish a predictable rubric to define what software qualifies for the statutory exclusion, the new policy requires a highly subjective, case-by-case analysis. This approach will do little to reduce the flood of new regulated software that everyone (including the FDA) anticipates is coming down the pike. Software developers and the medical device industry need to tread carefully and re-think any strategy that was developed based on the FDA’s 2019 draft version of this guidance.
The stated purpose of the final CDS guidance is to describe the FDA’s interpretation of Section 520(o)(1)(E) of the Federal Food, Drug & Cosmetic Act (21 U.S.C. § 360j(o)(1)(E)), which establishes an exclusion from the definition of device for certain software that are commonly referred to as CDS software. The statutory exclusion states that software that meet all of the following criteria are not subject to FDA regulation.
Criterion 1 – The software is not intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system.
Criterion 2 – The software is intended for displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines).
Criterion 3 – The software is intended for supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition.
Criterion 4 – The software is intended for enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.
By facilitating a better understanding of which CDS software functions are excluded from the definition of device, this final guidance attempts to also define the scope of software the Agency intends to regulate. Under this new approach, the FDA has pivoted away from its prior proposal of using the IMDRF Risk Classification Framework as a basis for determining what software would be subject to regulation (although, as described further below, some of the fundamental concepts remain intact). Below is an analysis of the Agency’s interpretation of each of the four criteria for the statutory exclusion.
To meet Criterion 1, the data being acquired or analyzed by the software must not consist of:
The FDA explains that an image that was “not originally acquired for a medical purpose” but is subsequently processed or analyzed for a medical purpose would be considered a medical image. For example, if an image is used for facial recognition to access a security system and is subsequently analyzed for evaluating muscle tone for purposes of identifying patients who might be at risk of a neurological condition, the image would be considered a medical image even though the original image was captured for a non-medical purpose by a non-medical device.
While the guidance appears to define the statutory term signal, it does so by identifying what types of technologies generate signals (i.e., IVDs, medical devices, and sensors that capture data for a medical purpose). The guidance also defines the statutory term pattern, as referring to “multiple, sequential, or repeated measurements of a signal or from a signal acquisition system,” providing examples for ECG monitors, next generation sequencers, and continuous glucose monitors.
It is noteworthy that the guidance states that the FDA will continue to regulate as a medical device any software that is intended to acquire, process, or analyze a signal from a sensor that measures a parameter for a medical purpose but does not appear to apply the same concept articulated for determining what constitutes a medical image for purposes of evaluating whether Criterion 1 is satisfied when the image is not originally acquired for a medical purpose. Put differently, data from a sensor that measures a parameter for a non-medical purpose even if subsequently used for a medical purpose does not appear to constitute a signal or pattern. For example, a motion sensor that is part of a home security system can generate data about an individual’s movements. If such motion data, which was captured for a non-medical purpose, is subsequently analyzed by software for a medical purpose (e.g., to determine whether an elderly patient has fallen or is otherwise in poor health condition), the FDA appears to allow such data and the analysis thereof to satisfy Criterion 1. The same would appear to be true in the scenario where a smartphone microphone is used to capture the voice of an individual using a notetaking mobile app. In theory (according to the CDS guidance), the microphone sensor and the digital voice recording data could subsequently be analyzed for a medical purpose (e.g., to identify whether an individual has a mental health condition or has a speech pathology suggestive of a neurological condition) and still satisfy Criterion 1 because the original sensor was measuring a parameter (i.e., the sound waves emanating from the voice) for a non-medical purpose (i.e., for notetaking). Contrast this scenario, however, with the example provided in the CDS guidance where “sound waves [are] captured when users cough or recite certain sentences” for the purpose of “diagnos[ing] bronchitis or sinus infection”, which the FDA says would not satisfy Criterion 1 because the sound waves in this example constitute a signal or pattern.
Interestingly, the FDA’s broader regulatory framework has created inconsistencies when it comes to determining whether the underlying sensor is regulated. Historically, sensors are regulated as medical devices in three general circumstances: (1) certain stand-alone sensors like ECG or EEG electrodes; (2) sensors incorporated into a finished product if the product meets the statutory device definition; and (3) sensors that are classified as accessories to a medical device. However, in some cases, sensors are completely unregulated, despite appearing to fit into the second or third category. Take the Apple Watch, for example, which incorporates a photoplethysmography (PPG) sensor and ECG electrodes. The FDA decided (incorrectly and inappropriately in many people’s opinions) that neither the PPG sensor, the ECG electrodes, nor the watch were regulated as a medical device even though the sensors are essential to the signal generation (just like ECG electrodes are essential to the signal generation for a regulated cardiac monitor). Instead, the FDA decided that only the software app that resides on the watch would be regulated as a medical device. Because the scope of the CDS guidance is limited to the regulation of software, it is not clear whether the Agency is shifting its thinking as to the regulatory status of the underlying sensor. The FDA takes the time in this guidance, though, to specify that “activity monitors or other signal acquisition systems that measure physiological parameters that are not specifically intended or marketed for a purpose identified in the device definition are not medical devices.” Nonetheless, empirical data suggests that the policy is shifting away from this special case established for Apple and a few other big tech companies, but only time will tell how the Agency proceeds in its application of this policy. Unfortunately, the FDA seems increasingly willing to move the goal posts without explanation or notice to the public.
Criterion 2 is fairly straightforward with the exception of a distinctly head-scratching aspect of the Agency’s clarification. The FDA explains that this element of the statute involves the display or analysis of 1) patient-specific information or 2) other medical information. The patient-specific information includes demographic information, symptoms, certain test results, patient discharge summaries, and information that is typically “communicated between HCPs in a clinical conversation or between HCPs and patients in the context of a clinical decision”. This type of information is such that its relevance to the clinical decision is “well understood and accepted”. Other medical information that falls within the scope of this criterion includes:
What’s particularly head scratching is that the FDA indicates that “data/results from devices (including IVD test(s)), when used in a manner consistent with FDA-required labeling” is included in the scope of Criterion 2 so long as Criterion 1 is met. It takes quite the cerebral contortion to figure out how data from a medical device can be used to meet both Criterion 1 and Criterion 2. The statute is quite clear that Criterion 1 is not met if the software involves the analysis of a “pattern or signal from a signal acquisition system”; a plain language reading would mean that analysis of data from a medical device would not meet Criterion 1. To thread this needle, the FDA distinguishes medical device data that falls under medical information of Criterion 2 from a signal or pattern under Criterion 1 based on the sampling frequency of the medical device data. The guidance includes the specific example of “[a] single, discrete test or measurement result that is clinically meaningful (e.g., a blood glucose lab test result)” as medical information, while “a more continuous sampling of the same information (e.g., continuous glucose monitor readings) is a pattern/signal.”
What the FDA appears to be trying to say is that, if the medical device data is contained in a lab test report, electronic health record, or other static record, the medical device data are medical information under Criterion 2 rather than a signal or pattern under Criterion 1. While it might make sense that static data that happened to be generated by a medical device could be medical information, the FDA has nonsensically indicated that a blood pressure result (e.g., 120/80 mmHg) from a legally marketed medical device would also fall within Criterion 2 rather than Criterion 1. Logic would suggest, then, that a single blood glucose value from a legally marketed glucometer that indicates the patient is hypoglycemic would be medical information rather than a signal from a signal acquisition system. While the logic follows, the notion presented by the FDA is incongruous given that the Agency actively regulates software that analyzes outputs from glucometers (particularly to detect single, discrete hypoglycemic events) in the same way that the Agency actively regulates software that analyzes outputs from blood pressure monitors (e.g., to identify single, discrete cardiac events).
What the FDA further fails to explain is how many “single, discrete test or measurement results” must be strung together and over what period of time before the medical information becomes a signal or pattern. The examples provided in the guidance indicate that sampling five sequential measurements (of an RR interval on a Holter monitor), every 30 minutes (for glucose measurements), or hourly (for pulse oximetry and heart rate) constitutes a signal or pattern. The guidance does indicate that daily measurements of heart rate, SpO2, blood pressure, or other output from a wearable product would be medical information under Criterion 1 (at least in the context of predicting heart failure hospitalization). What’s not clear is whether four sequential measurements or sampling daily or weekly of the other types of parameters or in other contexts constitutes medical information. Unfortunately, the line between medical information and a signal or pattern is highly subjective and rather difficult to determine without further input from the FDA.
What’s more, the FDA relegates to a footnote the meaning behind the requirement that the device data must be used in a manner consistent with FDA-required labeling. Unfortunately, since the FDA did not elaborate these critical distinctions in a clear manner and did not offer the public an opportunity to comment, these details will require case-specific analysis and will likely cause much consternation for software developers as well as for the FDA reviewers responsible for implementing this guidance.
Criterion 3 has become more important under the final guidance than in the 2019 draft version. Previously, this aspect of the statute simply seemed to require that the output of the software be targeted to an HCP (as opposed to a patient or caregiver) and that the output serve the purpose of “informing clinical management” (as defined in the IMDRF Risk Classification Framework). In the final guidance, the FDA has significantly expanded the criticality and explanation of this element. The final guidance indicates that, to satisfy this statutory criterion, the output of the software must merely “enhance, inform, and/or influence” the clinical decision as opposed to replacing or directing the HCP’s judgment. In this way, the FDA has distinguished a recommendation from a directive.
To further articulate the distinction, the guidance explains that a recommendation consists of a list of options or complete information for the HCP user to consider, including a list of preventive, diagnostic, or treatment options (whether prioritized or not) or a list of follow-up or next-step options. In contrast, a specific preventive, diagnostic, or treatment output for time-critical decision-making or a single, specific, selected output or solution (e.g., treatment plan or risk probability score) would constitute a directive. In defining a directive, the FDA has added a time-critical element (which is not found in the statute) as a means to prevent “automation bias” and the potential to prevent the software from replacing the HCP’s judgment. Unfortunately, the FDA has conflated this Criterion 3 with the requirement in Criterion 4. To meet Criterion 3, the software output would need to be limited to a list of options, such as the following (among others):
The guidance reiterates that Criterion 3 requires that the software output be intended for use by an HCP rather than a patient or caregiver, the latter of which are actively regulated medical devices if all else is equal.
In sum, to satisfy this Criterion 3, the FDA seems to be applying the IMDRF Risk Classification Framework approach simply without using the inform/drive/treat terminology. Many people (including myself) objected to the wholesale incorporation of the IMDRF approach on the basis that not only was the quality of the IMDRF document wanting but the failure of the FDA to obtain input from the public on its approach was inappropriate. In the public notice announcing that the CDS guidance has been finalized, the FDA acknowledged this objection but noted that the guidance merely removed the “complementary information” from the IMDRF document not its underlying principles. Indeed, the final guidance points the public to the IMDRF Risk Classification Framework “[f]or additional information regarding risk categorization and considerations that may apply to certain software functions.” It is unclear how much the Agency will rely on the IMDRF approach as it implements this policy on a case-by-case basis.
The most complex of the statutory requirements for the CDS software exclusion is articulated in Criterion 4. To satisfy this requirement, the FDA has indicated that the software or its labeling must include:
In addition, the software output must:
The relevant sources that support the recommendation must also be identified, made available to the intended user, and be understandable by the intended user. The FDA explains that, to the extent clinical practice guidelines are relied upon, for example, the date or version of the guidelines should be presented to the user. It is not clear, though, whether sources that are behind a paywall, for example, would be considered available to the HCP. It is likewise not entirely clear what satisfies the understandable requirement. The guidance indicates that recommendations/data points that are presented should have a meaning that is well understood by the intended user and that “the quality and robustness of the datasets or clinical studies [relied upon] are described.” As with the other criteria, these gaps create uncertainty for software developers and opportunity for FDA reviewers and compliance officers to apply the requirements inconsistently and arbitrarily to the detriment of all involved.
The FDA’s new guidance adds to an evolving and increasingly complex framework for the regulation of SaMD. The Agency has taken a largely subjective approach to distinguishing unregulated CDS software from other types of software that may or may not be regulated SaMD. As a result of the policy established for CDS software, the FDA has updated several existing guidance documents, including its general software policy guidance, its guidance on medical device data systems, and several radiological imaging guidances.
In an effort to make heads or tails of the various policies, the table below looks at the different types of software from a systems perspective. Depending on the policy (including broader digital health policies), the combination of inputs and outputs (or the purpose of the outputs, including the intended user) can be employed to determine whether the product meets the statutory definition of a device and is subject to active regulation by the FDA.
Keep in mind that the CDS guidance (and the framework as synthesized here) does not address requirements when such software is used as part of a combination product or with respect to labeling requirements when the software is associated with a drug or biological product.
Now that the CDS guidance is final, software developers must integrate its policy requirements into its existing product development strategy to ensure the desired regulatory status is achieved. In particular, any strategies developed based on the 2019 draft guidance must be reviewed and updated. Unfortunately, the complexity of the FDA’s framework is becoming increasingly untenable and incomprehensible as opposed to consistent and predictable. Moreover, the CDS guidance leaves open many critical details for determining how to meet the stated requirements. For example, the FDA has failed to adequately describe what constitutes a plain language description of the algorithm (particularly for AI/ML-enabled software) and how to ensure that the sources for the recommendations are available and understandable. Likewise, the FDA has not provided guidance on how they expect the information to be presented to the user. No doubt, software developers will come up with numerous, clever ways of doing so but they will be doing so with blind faith that their approach will pass the scrutiny of the enforcement arm of the Agency, which often is not fully synchronized with those creating the policy. As such, software developers need to take the time to understand how their products fit within this and the broader software framework and regularly evaluate changes in software functionality and product labeling to ensure the regulatory status has not been affected.
Thankfully, the FDA has reaffirmed in this guidance the statutory obligation under Section 520(o)(2) of the Federal Food, Drug & Cosmetic Act (21 U.S.C. § 360j(o)(2)) and the multiple functions guidance, that software can be made up of non-device CDS software functions and device software functions (whether CDS or otherwise). This means that HCP-facing portions of the software could be non-device CDS software while patient-facing portions could be regulated SaMD. Whether and to what extent the FDA will actually apply this policy appropriately will bear out over time. Software developers should heed the Agency’s recommendations for how to distinguish device functions from so-called other functions. Concepts articulated in the FDA’s draft guidance on software submissions (which is expected to be finalized soon) can be helpful in achieving the functional separation and documentation necessary to communicate that separation to the Agency.
Finally, the process by which the FDA created this important policy should concern stakeholders across the spectrum. The ease with which the Agency was willing to go straight to a final guidance announcing substantial changes to the policy described in the draft guidance, without seeking input from industry is remarkable and raises concerns that the many types of software that fall under enforcement discretion could as easily become subject to regulation without any notice to the public. This concern has been expressed for more than a decade as the FDA has slowly defined how it intends to regulate digital health technologies, including software and related hardware. Typically, this concern has been dismissed as unlikely; however, the approach taken with the CDS guidance unfortunately substantiates the concern that the FDA may continue to make substantial policy decisions without obtaining input from affected stakeholders. At a minimum, the Agency should have published a summary of the comments submitted in regards to the 2019 draft version and provided its reasoning for accepting or rejecting such stakeholder input so that the public can have confidence that the FDA has considered its feedback and developed a policy that promotes and protects the public health. While the Agency should be applauded for its attempt at interpreting a poorly drafted statutory provision, the process taken to establish this final guidance leaves much to be desired.
Stay in the loop with exclusive insights and valuable updates about the medical device industry and FDA approval!