Clinical Decision Support (Cont.)

Beyond that passage, we would add that historically there have been two key features for most unregulated software.

  1. The data are entered manually; they are not inputted directly from any machine that touches the patient or a patient specimen. That's important to avoid becoming an MDDS device or an accessory to a medical device.
  2. Depending on how the data get entered, the output amounts simply to providing the stored data back to the patient or professional. The system does not automatically guide the diagnosis or treatment, nor does it guide any medical instrument. In other words the software does not contain any algorithms that provide clinical-like functions that go beyond what FDA often refers to as library functions. It merely displays the data for the user to read and interpret.

Much software does indeed fit this category of unregulated software. But remember, if your software is intended to help with any part of cure, mitigation, treatment, or prevention of disease or a medical condition, FDA may consider it a device. Understanding the limits on the unregulated category is probably best explained, though, by looking at the other two categories.

  • FDA Regulated Software not Subject to Premarket Clearance

    Since the late 1980s, FDA has been publicly declaring that there exists a category of software that technically qualifies as a medical device but for which FDA has no intention of requiring the submission of a premarket notification or approval application. For those who are really interested in this topic, it probably makes the most sense to start with the "FDA Policy for the Regulation of Computer Products, 11/13/89 Draft". 

    In that policy, there are two categories of software products that were technically regulated but also considered exempt from the major requirements:

    1. General purpose articles as defined in an FDA regulation; and
    2. Software that involves competent human intervention.

    In its classification process, FDA has adopted certain general purpose or low-risk exemptions that cover software, such as laboratory information management systems (LIMS) (21 CFR 862.2100) used as calculators or data processing modules for clinical use. Unfortunately FDA never got around to actually codifying the competent human intervention exemption. 

    About 7 years after FDA published the 1989 draft policy, it appeared FDA was moving toward formalizing its computer product policy. In addition to publicly announcing that intention, FDA hosted a large meeting in Washington and invited many stakeholders to discuss what the policy should be.  In preparing for that meeting, FDA drafted a summary of what it considered to be its then existing policy on computer products.  Those workshop materials explained that much of the software the agency was seeing constituted accessories to medical devices, and the competent human intervention concept was only intended to apply to truly standalone software.  The agency also argued that the concept of what constitutes competent human intervention had become increasingly complex and difficult to administer.  FDA observed: 

    "In general, to permit competent human intervention, the software decision process must be completely clear to the user, with a reasonable opportunity for challenging the results. There must also be adequate time available for reflection on the results."

    But again, FDA never followed through to adopt a new regulation or policy. Instead, based on the following preamble from the proposed MDDS rule, FDA comprehensively reconsidered its software policy. 

    "Since 1989, the use of computer-based products and software-based products as medical devices has grown exponentially. In addition, device interconnectivity and complexity have grown in ways that could not have been predicted in 1989. This growth and expansion have created new considerations for elements of risk that did not previously exist. FDA realized that the Draft Software Policy was not adequate to address all of the issues related to the regulation of computer based and software-based medical devices. Based on this history and the complexity and diversity of computer software, FDA decided it would be impractical to prepare one 'software' or 'computer' policy that would be able to address all the issues related to the regulation of computer- and software based medical devices."

    While FDA finalized its MDDS proposal early in 2011, FDA is just now beginning to shed light on what it views as the scope of CDS.

  • When Does CDS Require Premarket Review?

    Honestly, we don't know. Until FDA publishes its draft guidance on CDS, the best anyone can do is look at a variety of risk factors to figure out which side of the premarket review line a piece of software falls.  Based on FDA comments and actions over the last 20 years, we believe the following list of factors has guided the dividing line historically.

    1. Whether the software is intended or designed to provide any real time, active, or online patient monitoring functions.
    2. Whether the software has the capability to display, create, or detect alarm conditions, or actually sound an alarm, or the capability to create alarms that are not already present from the connected medical device.
    3. The seriousness of the particular disease or condition that the CDS is intended to diagnose, cure, mitigate, treat, or prevent.
    4. How the software contributes to the user's decision-making for diagnosis or clinical management of the patient. For example, is it software designed to call attention to imminent hazard conditions or does it provide diagnostic support for chronic disease?
    5. The amount of time available before using the information provided by the CDS, i.e., the time until a therapeutic or additional diagnostic intervention must be implemented by the health care provider after the results of the software have been provided. For example, is the device an EKG reading and analysis package whose output is "SHOCK NOW" or does it provide a proposed reading with notation that the rhythm itself should be checked?
    6. Whether the data output is provided or manipulated in a novel or non-traditional manner. For example, do the system's algorithms, parameters, internal decision trees, or other output manipulations depart from customary use or traditional data presentation?
    7. Whether the CDS provides individualized patient care recommendations, e.g., whether the software suggests or recommends specific treatment for a specific patient. For example, how specific is the software output with regard to particular patients? Is the software providing general advice or information, like a library, article, or textbook, or is the software designed to provide a specific recommendation for a specific patient whose individual data have been entered as input?
    8. Whether the mechanism by which the CDS arrives at a decision is hidden or transparent, i.e., does the product use undisclosed parameters or internal decision trees or other mechanisms that are not available for review by the health care provider. For example, how transparent is the software manipulation to the intended user community? Included in transparency is the extent to which limitations on the process are made known to the user, such as data compression, deletion, editing, or simplification. Also, how are comparisons made to normative databases and how are normative databases created?
    9. Whether the product provide new capabilities or intended uses for the user.

Until FDA publishes its CDS guidance, consideration of these practical factors should help a company decide whether in FDA's eyes the software is risky enough to require premarket clearance. As we indicated, you won't find this in any existing FDA guidance or regulation. These are just our observations of FDA's decision-making process.

Read More:
Clinical Decision Support (Cont.)