[ad_1]
Facing novel, swiftly evolving technologies in the digital
health space, the US Food and Drug Administration has been trying
to balance fostering innovation with providing reasonable assurance
of safety and effectiveness under a regulatory framework for
devices that dates back to 1976. Major changes impacting digital
health companies came with the passage of the 21st Century Cures
Act in 2016, which carved out certain categories of software from
FDA oversight. Since then, the FDA has issued numerous guidance
documents providing details on these carve outs, as well as the
agency’s general approach to regulating digital health
technologies.
In its early digital health guidance documents, the FDA sought
to harmonize its thinking with that of the international community, but it also
announced specific areas of enforcement discretion for
low-risk devices. On September 28, 2022, however, the FDA
issued three new final guidance documents in the digital health
space – on clinical decision support (CDS) software, mobile medical applications and medical device data systems – as well as
a report summarizing its findings on the Software Precertification (Pre-Cert) Pilot
Program. The FDA’s recent efforts signal that the agency is
moving toward more oversight of digital health companies. With more
than 500 medical device approvals and clearances involving artificial intelligence (AI) and machine learning
(ML) under its belt, the agency has a better understanding of
the regulatory pressure points for these products, and in response,
it has updated its current thinking on how it can regulate software
as a medical device, given the Cures Act carve outs.
The most significant revision to the FDA’s current
interpretation of the Cures Act is the recently finalized guidance on CDS software, in which the agency
provides a more detailed interpretation of several statutory
elements. On December 15, 2022, the FDA also updated its Digital Health Policy Navigator, a tool
developed by the agency’s Digital Health Center of Excellence,
to help industry understand the Cures Act analyses, including the
non-device CDS exemption. Below, we’ve analyzed the practical
implications of the most significant of these changes.
CDS software guidance
Per the Cures Act, software functions that meet the following
four criteria are not devices under the Federal Food, Drug, and
Cosmetic Act (FDCA):
- It 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. - It is intended for the purpose of displaying, analyzing, or
printing medical information about a patient or other medical
information (such as peer-reviewed clinical studies and clinical
practice guidelines). - It is intended for the purpose of supporting or providing
recommendations to a healthcare professional about prevention,
diagnosis, or treatment of a disease or condition. - It is intended for the purpose of enabling a healthcare
professional to independently review the basis for recommendations
that the software presents, but not rely primarily on those
recommendations to make a clinical diagnosis or treatment decision
regarding an individual patient.1
While the agency cites this same statutory language in previous
CDS draft guidance documents, as well as the newly issued final
guidance document, the FDA’s new interpretation as explained in
the final guidance includes parameters not specifically delineated
by the statute.
Three key takeaways from the final CDS guidance
The final CDS guidance on its face appears to be significantly
different from the previous draft guidance. Some changes, however,
are more to form than substance. For example, rather than include a
table indicating that CDS software that provides outputs focused on
caregivers or patients does not qualify for the non-device CDS
carve out and is instead subject to enforcement discretion, the FDA
refers readers to its other Cures Act guidance documents announcing
enforcement discretion policies for low-risk devices, such as its
mobile medical applications guidance or general wellness policy for low-risk devices.
Similarly, the International Medical Device Regulators Forum
(IMDRF) framework is now referenced only in passing,2
although several principles from that framework, such as the
reference to intended use based on “label and instructions for
use” (rather than FDA’s broader intended use
regulation3), remain. The FDA acknowledges in this final
CDS guidance that while the IMDRF provides “additional
information regarding risk categorization and considerations that
may apply to certain software functions,” it no longer
embraces this framework as the foundation for the FDA’s revised
current thinking as it did in the previous draft guidance.4
Beyond these changes intended to streamline the guidance, there are
three areas where the agency’s current interpretation appears
to narrow the non-device CDS exemption, particularly when compared
to the 2019 draft guidance and the plain statutory language.
FDA’s current interpretation restricts non-device
CDS inputs
The final guidance includes newly announced definitions for
“medical image,” “signal” and
“pattern” as those terms are used in Criterion 1.
“Medical image” includes not only those images generated
by medical imaging systems to view any parts of the body, but also
images acquired for a medical purpose.5 Further,
“pattern” refers “to multiple, sequential, or
repeated measurements of a signal or from a signal acquisition
system.” Notably, these definitions serve to exclude virtually
all CDS functions that analyze continuous monitoring data, data
from DNA sequencing or systems that track medical information over
time. Recognizing that none of these technologies can qualify for
the Cures Act carve out, the FDA falls back on the statute, noting
that such products may be exempted if they do not qualify as a
medical device based on their intended uses. Of course, the CDS
carve out would be superfluous if it only applied to products that
did not meet the device definition in the first place – i.e.,
products not intended to cure, mitigate, treat, prevent, or
diagnose a disease or other condition, nor to affect the structure
or any function of the body.
The FDA’s interpretation further restricts CDS inputs by
narrowly defining “medical information” as the type of
information that normally is, and generally can be, communicated
between healthcare providers in a clinical conversation, or between
healthcare providers and patients in the context of a clinical
decision. This narrow reading could exclude from the non-device CDS
carve out functions that can provide real value and time savings to
healthcare providers, such as AI-driven technology and algorithms
that aggregate and sort data, including data from sources that may
be overlooked in current medical practice but may give insight into
medical diagnoses or treatment. Taken together, the FDA’s broad
interpretation of “medical image,” “signal” and
“pattern” in Criterion 1, and the agency’s narrow
interpretation of “medical information” in Criterion 2,
restrict the allowable inputs for the non-device CDS exemption.
FDA’s final guidance is at odds with the
agency’s approach to the ‘practice of
medicine’
Perhaps the most significant change in the final guidance is the
FDA’s interpretation of Criterion 3, including a newly
announced focus on the potential for automation bias, particularly
for time-sensitive decision making.6 Specifically, the
FDA voices a concern that healthcare providers may “over-rely
on a suggestion from an automated system,” which could lead to
poor outcomes if the system provides inaccurate information or an
erroneous treatment option. To account for this risk, FDA suggests
that non-device CDS software functions provide healthcare providers
a prioritized list of treatment options, rather than one
“specific preventive, diagnostic, or treatment output or
directive.”7 The FDA further explains that it
“considers software that … identifies a risk probability or
risk score for a specific disease or condition” to fall
outside the non-device CDS exemption, as such software functions
provide a “specific preventive, diagnostic, or treatment
output.”8
The CDS guidance also notes that functions “intended to
support time-critical decision-making” likely would not be
exempted because the agency posits that for “situations that
require urgent action, automation bias increases because there is
not sufficient time for the user to adequately consider other
information.”9 The guidance similarly takes aim at
devices that provide an alarm. Per the final guidance, software,
including software “that provides time-critical alarms or
alerts intended to trigger potential clinical intervention to
assure patient safety,” would not satisfy Criterion
3.10 For software functions that provide specific
recommendations in time-sensitive situations, FDA has signaled that
it would expect sponsors to seek agency premarket review rather
than view such products as non-device CDS.11
This prohibition on non-device CDS that utilizes alarms or
scoring functions appears to significantly narrow non-device CDS in
emergency rooms where alarms are often used, and ignores the fact
that healthcare practitioners who are specifically trained in
emergency medicine must “regularly ‘make instantaneous
decisions often without the benefit of medical histories,
consultation, or time for reflection.'”12 It is
also curious that the cited support for this concern is a 2004
article, written three years before smartphones began gaining
traction across the globe as a common element of daily
life.13 In today’s world, many professionals,
including healthcare professionals, are accustomed to receiving
information from automated systems, such as text messages,
throughout the day. Moreover, the FDA’s interpretation of this
element appears on its face to run counter to the agency’s
long-standing precedent to defer to the judgment of healthcare
practitioners.14
While statutory language for Criterion 3 of the CDS carve out is
consistent with the FDA’s approach to defer to “the
practice of medicine” – in that it states that a product
is not a device and therefore not regulated by FDA if it is
“intended for the purpose of supporting or providing
recommendations to a health care professional about prevention,
diagnosis, or treatment of a disease or condition“
(emphasis added) – the FDA’s newly announced
interpretation of Criterion 3 does not reflect this deference
required by the FDCA and generally supported by the
courts.15 Whereas the FDCA expressly allows for even
off-label uses given the physician’s ability to make judgments
in the best interest of patient care, in its interpretation of
Criterion 3, the FDA is skeptical of physician decision making such
that automated tools that provide specific recommendations or
probability scores aimed at assisting providers in making clinical
decisions do not appear to qualify for the non-device CDS
exemption.
There is further tension in the FDA’s interpretation for
Criterion 3, when contrasted with its interpretation of Criterion
4, in which the agency requires software to “identify the
required input medical information” with a “plain
language description of the underlying algorithm development and
validation that forms the basis for the CDS implementation,
including a summary of the logic or methods relied upon to provide
the recommendations.”16 The FDA’s
interpretation of Criterion 4 would arguably address any
“automation bias” concerns because the clinicians would
have to be provided with details about the software inputs and
outputs.
FDA’s guidance requires labeling even for exempted
products
Lastly, the agency’s interpretation of Criterion 4 raises a
question about the agency’s reach over products intended to be
exempted from its jurisdiction. The FDA explains in its Criterion 4
analysis that to fit within the non-device CDS exemption, software
should include labeling that describes its purpose and intended
use, the required inputs and medical information, and the
underlying algorithm, among others. Yet if the product is exempted
from the device definition, can the FDA really require specific
labeling for such products? Additionally, given the agency’s
long-standing approach to the intended use analysis,17 it is
unclear whether the FDA would be satisfied with express labeling
only to determine whether a product can qualify as non-device CDS,
or whether it would engage in a broader intended use
analysis.18 Perhaps this interpretation is a holdover
from the IMDRF framework, in which intended use is determined on
the “Label and Instructions for Use for Medical Devices”
only.19 In any event, to the extent the FDA appears to
be requiring products exempted from agency oversight to carry
specific labeling, the agency’s interpretation of Criterion 4
potentially raises First Amendment concerns.
Practical considerations
The FDA’s interpretation of the non-device CDS carve out as
announced in the final guidance will, at a minimum, require
software developers and device manufacturers to have an increased
understanding of FDA labeling requirements and conform descriptions
of their software to a format and level of detail that the FDA
finds acceptable. Given the FDA’s interpretation of Criterion
4, this is essential even for products that ultimately are exempted
from FDA regulation. Developers also should pay particular
attention to the language used in designing the user interfaces and
promoting CDS software products, keeping in mind the principles in
the FDA’s final guidance. For example, the difference between
the FDA regulating a product as a device and the same product being
exempt as non-device CDS software could hinge not only on the
express language the agency suggests for Criterion 4, but also on a
description of the software output as a consideration, rather than
a risk score or probability. Additionally, developers need to keep
in mind that diagnostic devices almost always will require FDA
clearance or approval, as the non-device CDS exemption does not
apply to diagnostic devices.
In addition to more careful device and output descriptions,
software developers must take care to plainly “show their
work” to qualify for the non-device CDS
exemption.20 In other words, to be excluded from the
definition of a device, the software function must enable
healthcare providers to independently review the basis for the
recommendations presented by the software. In the final guidance,
the FDA presents a few examples of labeling and device functions
that fulfill this requirement. For example, in the case of a
hypothetical software function that analyzes patient-specific
medical information regarding end-stage renal disease and provides
a list of treatment options based on practice guidelines, the FDA
outlines a laundry list of required information that must to be
provided to the healthcare provider to satisfy Criterion 4,
including the intended use, patient population, medical
information, data quality requirements, a plain language
description of the underlying algorithm development and validation
that forms the basis for recommendations, etc.21 This,
according to the FDA, enables healthcare providers to rely on their
own judgment, rather than such recommendations, to make clinical
decisions for individual patients. Software developers should be
prepared to provide adequate background information in plain
language on the input(s), algorithm, datasets, validation and more,
and they must describe in detail how their software functions
analyze and calculate data to determine the recommendations they
provide. This requirement, however, assumes that physicians have a
sophisticated understanding of software and hence requires
non-device CDS software to clearly explain the outputs such that a
healthcare provider knows the full bibliography of information
analyzed by the software. However, many physicians do not have data
science or software engineering backgrounds, and requiring
sophisticated algorithm development and validation to be explained
in “plain language” could therefore be an exercise in
futility.
Although the FDA has approved and cleared many devices with
AI/ML and digital health technologies, undoubtedly many newly
regulated devices will need to utilize the De Novo clearance
process due to a lack of adequate predicate devices for these novel
products.22 Thus, large companies that are already
familiar with the De Novo process and have existing regulatory
departments well-versed in FDA clearance and approval processes may
be at an advantage in ultimately getting CDS products to market.
Smaller companies interested in innovating will need guidance from
those experienced in these areas to determine whether novel
software might qualify for the non-device CDS exemption, given the
final guidance, and also analyze software under the FDA’s
enforcement discretion policies as explained in the mobile medical application, software as a medical device, medical device data systems and general wellness guidance documents.
Digital Health Policy Navigator
In the wake of the FDA’s final guidance, it is even more
important to lean into FDA’s long-standing practice of
analyzing software devices on a function-by-function
basis.23 Recognizing this need, FDA established the Digital Health Policy Navigator on September
28, 2022, to help determine whether a software function is subject
to or the focus of the FDA’s regulatory oversight as a device,
and it provides considerations that could be useful to determining
the applicable FDA-specific legal and regulatory requirements and
recommendations. Each step in the navigator is crafted to answer a
question about the device function and often corresponds to a
specific FDA-issued guidance document on the topic. For example,
Step 6 helps determine if the software function is intended to
provide clinical decision support.
Although the Digital Health Policy Navigator was announced when
the final CDS guidance was published on September 28, the FDA only
updated this tool with details on Question 6, which is the CDS
analysis question, on December 15. We had wondered whether the FDA
might share additional insights with industry on how to interpret
the CDS analysis through the navigator’s answers to Question 6,
but the FDA’s analysis with this tool merely tracks the
examples provided in the CDS guidance. For example, the navigator
explains that software with outputs rooted in clinical guidelines
– such as physicians’ order sets, software linking
patient-specific information to established clinical guidelines or
reminders for preventive care based on such guidelines –
could meet the elements required for the exemption. Similarly, the
navigator notes that software identifying drug-drug interactions or
drug-allergy interactions to avoid adverse events for patients may
be exempted.
While the navigator does a good job of pulling the various
digital health guidance documents into one streamlined
questionnaire, the FDA makes certain to point out that the
navigator’s results “are not a formal FDA device
determination for your product.” The navigator can be useful
for individuals without an FDA background to get a general idea of
whether their software may be regulated by the FDA as a medical
device. However, many novel devices raise more nuanced issues or
questions regarding software functions that do not fit squarely
into the questionnaire. In this case, a more comprehensive review
of the FDCA, its implementing regulations and the FDA’s various
guidance documents will be required to determine the appropriate
regulatory pathway for software functions.
What’s next?
While some developers may wait in the wings to see how the FDA
enforces this new guidance given the agency’s limited resources
and risk-based approach to enforcement, the most likely impact of
the final CDS guidance is an anticipated increase in the number of
premarket submissions to the FDA for CDS products. Because
premarket applications are not made public by the FDA until
clearance or approval, it may be months or even years before we can
evaluate the impact of this guidance on the volume of
applications.
Footnotes
1. 21 US Code § 360j(o)(1)(E).
2. See, Policy for Device Software Functions and Mobile
Medical Application: Guidance for Industry and Food and Drug
Administration Staff at 13.
3. 21 CFR § 801.4
4. See, Clinical Decision Support Software: Draft Guidance
for Industry and Food and Drug Administration Staff (September
19, 2019) at 13. (“This guidance uses factors from the
International Medical Device Regulators Forum (IMDRF) Framework to
apply a risk-based policy for CDS software functions. This approach
is consistent with FDA’s commitment to implement IMDRF
documents specifically and advance global medical device regulatory
harmonization generally.”)
5. See, Clinical Decision Support Software: Guidance for
Industry and Food and Drug Administration Staff at
7.
6. Id. at 11 (“Automation bias is the
propensity of humans to over-rely on a suggestion from an automated
system. In the context of CDS, automation bias can result in errors
of commission (following incorrect advice) or omission (failing to
act because of not being prompted to do so).”) (citing M.L.
Cummings, Automation Bias in Intelligent Time Critical Decision
Support Systems. American Institute of Aeronautics and
Astronautics 1st Intelligent Systems Technical Conference,
Vol. 2, 2004, pp. 557-62).
7. Id. at 12.
8. Id. at 12-13.
9. Id. at 11.
10. Id. at 12.
11. Id.
12. See, Miranda v. National Emergency Services,
Inc, 35 Cal. App. 4th 897 (1995) (citing James v. St.
Elizabeth Community Hospital, 30 Cal. App. 4th 73 (1994))
(“Physicians covering emergency rooms must make instantaneous
decisions, often without the benefit of medical histories,
consultation, or time for reflection”).
13. See supra n. 9.
14. 21 USC § 396; see also e.g., Wash Legal
Found. v. Friedman, 13 F. Supp. 2d 51 (D.D.C. 1998), at 66
(“FDA does not purport to regulate the practice of medicine,
and the agency has long recognized that, in general, physicians may
use an approved drug or device for an unapproved
use”).
15. 21 USC § 360j(o)(1)(E)(iii); see also e.g.,
Judge Rotenberg Educ. Ctr., Inc. v. U.S. Food & Drug
Admin., 3 F.4th 390 (D.C. Cir. 2021); United States v.
California Stem Cell Treatment Center, Inc., No. EDCV 18-1005
JGV (C.D. Cal. Aug. 30, 2022). But see United States of America
v. Regenerative Sciences, LLC, 741 F.3d 1314 (D.C. Cir.
2014).
16. See, Clinical Decision Support Software: Guidance for
Industry and Food and Drug Administration Staff at
14.
17. See, e.g., United States v. Travia,
180 F. Supp. 2d, 115 (D.D.C. 2001) at 199 (“It is also well
established that the ‘intended use’ of a product, within
the meaning of the Act, is determined from its label, accompanying
labeling, promotional claims, advertising, and any other relevant
source”) (quoting Hanson v. U.S., 417 F. Supp. 30, 35
(D. Minn.)). In the FDA’s public statement in 2020 regarding
types of evidence the agency considers when determining intended
use, the FDA clarified that a manufacturer’s knowledge of a
healthcare provider’s use of a medical product for unapproved
use is not sufficient to establish the product’s intended use.
In issuing this statement, the FDA reaffirmed its
“longstanding position … that, in evaluating a product’s
intended use, any relevant source of evidence may be
considered.”
18. Id.
19. See, “Software as a Medical Device”: Possible
Framework for Risk Categorization and Corresponding
Considerations at 7.
20. Id. at 13.
21. Id. at 19.
22. At present, devices generally are reviewed by the
review division within the FDA’s Center for Devices and
Radiological Health (CDRH) that has jurisdiction over the disease
or condition that will be addressed by the device, with input by
CDRH’s Digital Health Center of Excellence as necessary. An
open question is whether, with a large influx of new software-based
device applications, CDRH will continue to review CDS products in
this manner or whether we will see increased involvement by the
Digital Health Center of Excellence in these
submissions.
23. The FDA traditionally has analyzed medical devices on
a function-by-function basis. Per the FDA’s guidance on multiple function device
products: “In accordance with existing policies, FDA
intends not to review a device function subject to an enforcement
discretion policy merely because it is part of a multiple function
device product. Instead, FDA intends to review the device
function(s) for which clearance or approval is being sought (e.g.,
the device function-under-review). For example, if a manufacturer
seeks clearance or approval for a device function (e.g., analysis),
and not the device function for which FDA has expressed its
intention not to enforce compliance (e.g., trend), then FDA intends
to only review the analysis function and assess the trend function
only insofar as it could negatively impact the analysis function.
In that instance, because FDA is reviewing the analysis function
only, FDA’s decision to clear or approve applies only to the
analysis function.”
The content of this article is intended to provide a general
guide to the subject matter. Specialist advice should be sought
about your specific circumstances.
[ad_2]
Source link
