martes, 1 de octubre de 2019

FDA Issues a Second Draft Guidance for Clinical Decision Support Software

FDA Issues a Second Draft Guidance for Clinical Decision Support Software

Link to FDA Law Blog

Posted: 30 Sep 2019 08:36 PM PDT
By Adrienne R. Lenz, Senior Medical Device Regulation Expert —

On September 27, 2019 FDA issued several updates to advance their digital health policies.  One of these updates was a new draft guidance, Clinical Decision Support Software (“Guidance”).  This draft guidance replaces the 2017 draft guidance, Clinical and Patient Decision Support Software (“Prior Draft”), which we blogged on here.

For background, clinical decision support (“CDS”) is a broad term that encompasses providing “health care professionals (HCPs) and patients with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care.”  Guidance at 5. Section 3060(a) of the 21st Century Cures Act (“Cures Act”) amended the Federal Food, Drug, and Cosmetic Act (“FD&C Act”) to add section 520(o), to exclude certain CDS software functions from the definition of a device.  Software functions that meet all of the following four criteria are not considered medical devices:

  1. 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 (section 520(o)(1)(E) of the FD&C Act);
  2.  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) (section 520(o)(1)(E)(i) of the FD&C Act);
  3. intended for the purpose of supporting or providing recommendations to a health care  professional about prevention, diagnosis, or treatment of a disease or condition (section  520(o)(1)(E)(ii) of the FD&C Act); and
  4. intended for the purpose of 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 (section 520(o)(1)(E)(iii) of the FD&C Act).
Id. at 6 – 7.

Like the Prior Draft, the purpose of the Guidance is to clarify CDS software functions that:

  1. do not meet the definition of a device as amended by the Cures Act;
  2. may meet the definition of a device but for which, based on our current understanding of the risks of these devices, FDA does not intend at this time to enforce compliance with applicable device requirements of the FD&C Act, including, but not limited to, premarket clearance and premarket approval requirements; and
  3. meet the definition of a device and on which FDA intends to focus its regulatory oversight.
Id. at 5-6.

Much of the text of the Guidance is new or revised compared to the Prior Draft, which is likely why it has been issued again in draft.  Two changes are worth noting.  First, the Guidance provides an expanded discussion of FDA’s interpretation of criterion (1) of the Cures Act, specifically with respect to “a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system.”  The Guidance states that they consider “physiological signals” to be included within this definition, and defines “physiological signals” as those signals that require use of either:

  • An in vitro diagnostic device, which typically includes an electrochemical or photometric response generated by an assay and instrument that may be further processed by software to generate a clinical test result, or
  • A signal acquisition system that measures a parameter from within, attached to, or external to the body for a medical purpose and often includes:
    • use of sensors (e.g., electrocardiogram (ECG) leads) along with electronics and software function that is used for signal generation (e.g., ECG);
    • collections of samples or specimens such as tissue, blood, or other fluids, (e.g., conducting a pathological study using software such as digital pathology); or
    • use of radiological imaging systems (e.g., computed tomography (CT)) and a software function for image generation.
Id. at 10.

The most significant change in the Guidance is the application of International Medical Device Regulators Forum (“IMDRF”) Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations (“IMDRF Framework”).  The IMDRF Framework evaluates software as a medical device (“SaMD”) using two categories to establish a risk-based classification.  First is the assessment of the significance of the information provided by the SaMD to a health care decision into one of three categories: treat or diagnose, drive clinical management, and inform clinical management.  Second is the assessment of the state of the health care situation or condition as critical, serious or non-serious.  The Guidance provides the IMDRF Framework’s definitions of each of these criteria and provides discussion of their interpretation.  The following table from the Guidance summarizes the SaMD Categories established in the IMDRF Framework.

State of health care situation or conditionSignificance of information provided by SaMD to health care decision
Treat or diagnoseDrive clinical managementInform clinical management
CriticalIVIIIII
SeriousIIIIII
Non-seriousIIII
Id. at 13.

The Guidance states that functions that inform clinical management are considered CDS functions, but functions that drive clinical management or treat or diagnose would not be considered CDS functions.  Functions that inform clinical management are those functions where “the information provided by the SaMD will not trigger an immediate or near term action: [t]o inform of options for treating, diagnosing, preventing, or mitigating a disease or condition [or t]o provide clinical information by aggregating relevant information (e.g., disease, condition, drugs, medical devices, population, etc.).” Id. at 13.  Software functions used as an aid in diagnosis or treatment, or to guide next diagnostics or treatment interventions would be considered to drive clinical management and software functions classified to treat or diagnose are those that lead to immediate or near-term action in treatment or diagnosis.

The Guidance then discusses whether FDA considers these functions that inform clinical management to be device-CDS functions, non-device CDS functions or device-CDS functions for which FDA intends to exercise enforcement discretion.  As noted in criterion (4) of the Cures Act, CDS functions not regulated as devices must allow for independent review of the basis for recommendations that the software presents.  To meet the criteria, the Guidance states that Non-Device CDS software functions should describe: the purpose or intended use of the software function, the intended user, and the inputs used to generate the recommendation and the basis for rendering a recommendation.  The Guidance, however, is clear that the complexity or proprietary nature of the algorithm is not the distinguishing factor as much as the ability of the healthcare provider to confirm the output independently, using the same inputs and basis.  Thus, software functions using artificial intelligence or machine learning are not automatically precluded as long as they can provide information to allow users to independently confirm the basis for recommendations.  Additionally, the Guidance indicates that FDA will exercise enforcement discretion for CDS functions used by HCPs that inform clinical management of non-serious conditions when the user is unable to independently review the basis of the recommendation.  The Guidance uses the IMDRF Framework to define non-serious conditions as those “situations or conditions where an accurate diagnosis and treatment is important but not critical for interventions to mitigate long term irreversible consequences on an individual patient’s health condition or public health.” Id. at 15.

Per criterion (3) in the Cures Act, for a CDS function to not be a device, it must be “intended for the purpose of supporting or providing recommendations to a health care professional” and thus any CDS function intended for supporting or providing recommendations to a patient or caregiver would not be included.  The Prior Draft included a separate section for Patient Decision Support Software and also included “patient” within the title.  In the Prior Draft, FDA indicated that, though not within the scope of the Cures Act, they intended to adopt an enforcement discretion policy that parallels the policy for HCPs.  FDA still discusses CDS functions used by the patient or caregiver in the Guidance, but their enforcement discretion will not be as broad, and CDS functions used by patients or caregivers that inform clinical management of serious or critical conditions will remain under regulatory oversight.  However, the Guidance maintains enforcement discretion for CDS functions used by patients or caregivers that inform clinical management of non-serious conditions when the user can independently review the basis of the recommendation.

In summary, the Guidance provides the following table of its regulatory policy for CDS software functions:

 Intended User is HCPIntended User is Patient or Caregiver
IMDRF RiskCategorizationCan the UserIndependently

Review the Basis?*
FDA RegulationFDA Regulation
InformX

Critical
YesNot a DeviceOversight Focus
NoOversight FocusOversight Focus
InformX

Serious
YesNot a DeviceOversight Focus
NoOversight FocusOversight Focus
InformX

Non-Serious
YesNot a DeviceEnforcement Discretion**
NoEnforcement Discretion**Oversight Focus
* “Can the User Independently Review the Basis?” asks whether the function is intended for the purpose of enabling the user to independently review the basis for the recommendations so that it is not the intent that user relies primarily on any such recommendation (part of criterion (4)).

** “Enforcement Discretion” indicates that, based on our current understanding of the risks of these devices, FDA does not intend at this time to enforce compliance with applicable device requirements.

Id. at 17.

Although FDA will not be enforcing compliance, they still encourage developers of CDS software functions that are not medical devices or are medical devices for which they will exercise enforcement discretion to implement a quality management system and apply good cyber hygiene consistent with their digital health guidance documents.

Overall, the Guidance may be considered a positive step for developers of CDS software functions used by HCPs that inform clinical management of non-serious conditions where the basis of the recommendation cannot be independently reviewed as additional enforcement discretion will be exercised.  For developers of CDS software functions used by patients and caregivers that inform clinical management of serious conditions, however, it may be a disappointment as these software functions will remain under FDA oversight.

No hay comentarios:

Publicar un comentario