FDA Guidance on Clinical Decision Support Software
By Mitch on Friday, 6 January 2023, 13:24 - Regulations - Permalink
The latest version of the FDA Guidance on Clinical Decision Support Software (CDSS) was published in September 2022. Here is a review of the document and a short comparison with the status of CDS with regard to the MDR.
The purpose of this guidance is to give rationale to exclude CDSS from the medical device regulation scope. The rationale is based on 4 criteria (see below). CDSS itself very sounds like medical device software intended use, according to the definition of medical device laid in article 2 of the EU Medical Device Regulation (MDR).
Let’s see how much CDSS can be treated differently, according to these 4 criteria in the US regulation, and according to the MDR definition of medical device (a.k.a MDRDef below in this post).
The Four Criteria
Here are these criteria present in the US Regulation, after the amendment of the FD&C Act, and how they can be seen from a EU MDR standpoint.
CDSS function can be excluded if they meet all of the following criteria:
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
- That first criterion is quite similar in its intent to the MDRDef. There is not much to say. CDSS not matching this criterion are medical devices.
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)
- This one looks a bit like the question 3 (Q3) of the MDCG 2019-11. However, "Analyzing" goes beyond that question 3 and may have a SW fall in the scope of the MDRDef.
- The examples given further in the Discussion section of the guidance for criterion 2 suggest that this is not the software, which analyzes medical information, but the HCP user. In this case, this is aligned with MDCG 2019-11 Q3, and the SW function is outside the scope of the MDRDef.
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
- The explanations given in the Discussion section of the FDA guidance on prevention, diagnosis, or treatment of a disease or condition are definitely in the scope of the MDRDef. Especially the wording sounds like Informing clinical management present in the IMDRF SaMD risk categorization framework, and Annex 1 of MDCG 2019-11.
- Examples contain CPOE, definitely considered as medical device within the EU MDR. The FDA guidance distinguishes software used to enhance, inform, influence HCP's decision making from software used to substitute, replace, or direct HCP's judgment. Such distinction is not present either in the MDRDef or in the MDCG 2019-11. Thus, software with such mode of action would fall in the MDR scope.
- Likewise, software for remote surveillance of patients, not intended to support time-critical decision making would match criterion 3. Conversely, that non time-critical remote surveillance definitely falls in the EU MDR scope.
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
- Once again, this sounds very much like the MDRDef. SW function that outputs recommendations, to make a clinical diagnosis or treatment, two purposes present in the MDRDef.
- The property of not relying primarily on such information can’t be taken as a rationale to exclude CDSS from the MDRDef.
- The discussion on criterion (4) is absolutely not audible with regard to the MDR. As soon as a software function presents recommendations for diagnosis or treatment purpose, it's in the MDR scope. Yet, it may be informing patient management but that doesn't save the software function from the MDR claws and class IIa infection.
- The FDA insists in the discussion on labelling to exclude the software function from the US medical device regulation. This is totally not receivable with the MDR. No such rationale can exist.
- The fourth criterion is probably the one, which introduces the biggest gap between the FD&C Act and the EU MDR. It allows excluding SaMD with such intended use and labelling from US regulatory scope, whereas such SaMD will remain in MDR scope.
- One remark on AI/ML algorithms: They can't meet the sub-criterion (4)(c)(i) as long as explainability of ML algorithm isn't scientifically proved. However, rules engines can meet this criterion. Usually, rule engines can exhibit the rule(s), which data rely upon, to output the result.
Examples of NonDevice CDS Software Functions
The FDA guidance contains a long list of examples of CDSS not regulated according to US regulation. The table below show the differences in regulatory status that we can expect between US regulation and EU regulation.
The rationale for MDR qualification in the rightmost column makes use of the Question 3 found in the MDCG 2019-11: 'Is the software performing an action on data different from storage, archival, communication, simple search, lossless compression''.
| Software Function | Detail | MDR qualification |
|---|---|---|
| Evidence-based clinician order sets for an HCP to choose from, tailored for a particular condition, disease, or clinician preference: | Software function that provides groupings of standard order sets, consistent with clinical guidelines, for patient admission to critical care. | Can be probably seen as "simple search", not MD. The Manual on Borderline and Classification V1.22 of 2019 contains a somewhat similar case at section 9.4. Qualification of software for interpretation of a guideline. |
| Software function that provides a list of diagnostic and treatment order options to an HCP based on clinical guidelines for the care of adult patients presenting with pneumonia symptoms | Can be probably seen as "simple search", not MD. Same comment as above. | |
| Matching patient-specific medical information from records or reports to reference information (e.g., clinical guidelines) that is routinely used in clinical practice: | Software function that matches patient-specific medical information (e.g., diagnosis, treatments, allergies, signs or symptoms) to reference information routinely uses in clinical practice (e.g., practice guidelines) to facilitate assessments of specific patients. For example, a software function that uses a patient’s diagnosis and other medical information to provide an HCP with current practice treatment guidelines for common illnesses or conditions such as influenza, hypertension, and hypercholesterolemia |
Can be probably seen as "simple search", not MD |
| Software function that matches patient-specific medical information to peer-reviewed literature publications on related topics. | Can be probably seen as "simple search", not MD | |
| Contextually relevant reference information about a disease or condition: | Software function that provides HCPs with recommendations on the use of a prescription drug for a disease (as indicated in the patient’s medical record) that that are consistent with the current version of drug’s FDA-approved labeling | Communicating, displaying medical data, not MD |
| Software function that provides HCPs with available treatment options, including drug, device, surgical and/or lifestyle changes for heart failure patients based on their disease stage and clinical guidelines. | Can be probably seen as "simple search", not MD | |
| Drug-drug interaction and drug-allergy contraindication notifications to avert adverse drug reactions: | Software function that identifies drug-drug interactions and drug-allergy contraindications, based on the current version of FDA-approved drug or device labeling or other up-to-date and peer-reviewed sources and patient-specific information, to attempt to prevent adverse drug reactions. | Drug prescription assistance software is qualified as MD as per European Court of Justice decision and is at least in class IIa. |
| Software function that enables an HCP to enter multiple drug names and provides information regarding known drug-drug interactions. | ||
| Software function that identifies drug-disease interactions and contraindications, such as notifying an HCP that a patient with asthma should not be prescribed a non-selective beta-blocking drug | ||
| Drug formulary guidelines: | Software function that provides HCPs with a list of medications on a formulary for a given disease or condition. | Communicating, displaying medical data, not MD. |
| Software function that provides alerts to HCPs regarding changes in a formulary and recommends alternatives. | Communicating, displaying medical data, not MD. | |
| Duplicate testing or medication error prevention notifications (e.g., medication reconciliations and test reconciliations): | Software function that provides an alert to notify an HCP of redundant test orders and advise discontinuation of the order. | Probably more than "simple search" and more than communicating medical data. Such alerts have an impact on decisions on diagnosis and/or treatment. They are seen as MD functions with the MDR, they provide information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. |
| Software function that flags patient results for an HCP based on specific clinical parameters (e.g., out of range test results where the reference ranges are predetermined by the lab or HCP) in response to a medication order. Example: Software function that flags low potassium and/or magnesium levels in a patient in response to a prescription for digoxin. |
Probably more than "simple search" and more than communicating medical data. Flagging low levels can be seen as alerts, MD functions with the MDR. Alerts are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. | |
| Reminders for preventive care or clinician’s orders: | Software function that provides an HCP with reminders for preventive care (e.g., breast cancer screening or immunizations) for a patient based on practice guidelines using medical information in the patient’s medical record. | Can be probably seen as "simple search", and communicating medical data. A reminder is not an alert, not MD. |
| Software function that provides an HCP with reminders for orders for Hemoglobin A1C tests for diabetic patients using patient-specific medical information from the medical record (e.g., the patient’s diagnosis, date of prior Hemoglobin A1C test) based on practice guidelines | Can be probably seen as "simple search", and communicating medical data. A reminder is not an alert, not MD. | |
| Patient data reports and summaries (e.g., discharge papers): | Software function that uses medical information from the patient’s medical records to provide an HCP with recommended assessments prior to discharge, such as a pain assessment. | Can be probably seen as "simple search", and communicating medical data. Recommendations are not alerts, not MD. |
| Software function that aggregates possible post-operative care instructions, medication needs, and follow-up instructions to assist an HCP in assembling discharge papers for a patient. | Can be probably seen as communicating and displaying medical data, not MD. | |
| List of preventive, diagnostic or treatment options: | Software function that provides a list of appropriate cholesterol-lowering drugs to HCPs to consider based on a patient’s cholesterol levels and demographics found in the electronic health record (EHR). | Borderline case: could be seen as "simple search". However, using demographics data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Such list provide information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above |
| Software function that analyzes medical information on a patient’s asthma diagnosis and demographics from the patient’s medical record and provides an HCP with a list of FDA-approved treatment options for asthma. | Borderline case: could be seen as "simple search". However, using diagnosis and demographics data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Such treatment options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. | |
| Software function that provides to an HCP a list of FDA-approved chemotherapeutic agents for a cancer type identified through analysis of medical information on the patient’s diagnosis and pathologist confirmed biopsy result. | Borderline case: could be seen as "simple search". However, using demographics and biopsy data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Thus in class IIa or above. | |
| Software function that analyzes family history, prior mammogram results, and BRCA1 status from the medical record and recommends that an HCP consider increased mammography frequency or supplemental breast ultrasound for the patient. | Borderline case: could be seen as "simple search". However, using such data found in patient-specific EHR could be seen as more than "simple search" and as an aid to treatment. Such information is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. | |
| Software function that enables an HCP to input the specific mutation results of an FDA-authorized Epidermal Growth Factor Receptor Mutation (EGFR) test for a patient with non-small cell lung cancer (the same clinical condition for which the FDA-authorized EGFR test was clinically validated) and identifies FDA-approved treatments for non-small cell lung cancer indicated for use with the FDA- authorized EGFR test. | Borderline case: could be seen as "simple search". However, using such data found in patient-specific EHR could be seen as more than "simple search" and as a function similar to drug prescription assistance software. Thus in class IIa or above. | |
| Prioritized list of preventive, diagnostic or treatment options | Software function that analyzes the type of arthritis diagnosis in the patient’s medical record and identifies prioritized treatment options available for that condition. | Probably more than "simple search", with the "prioritized" list. The software function analyzes data found in patient-specific EHR and outputs information seen as an aid to treatment. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. |
| Software function that analyzes patient-specific symptoms to provide a prioritized list of diagnostic tests for the HCP to consider. | Probably more than "simple search", with the "prioritized" list. The software function analyzes data found in patient-specific EHR and outputs information seen as an aid to diagnosis. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. | |
| Software intended for HCPs that analyzes patient-specific medical information to determine which over-the-counter (OTC) allergy drug class is likely to be most effective in alleviating the patient’s seasonal allergies and provides a list of available medications in that drug class. | Probably more than "simple search", with the "prioritized" list. The software function is a function similar to drug prescription assistance software. Thus in class IIa or above. | |
| Software function that analyzes information on a patient’s glaucoma diagnosis in the patient’s medical record and provides HCP with a list of prioritized treatment options to consider for that patient. | Probably more than "simple search", with the "prioritized" list. The software function analyzes data found in patient-specific EHR and outputs information seen as an aid to treatment. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. | |
| List of follow-up or next-step options for consideration (e.g., after a physician office visit, hospitalization, procedure): | Software function that analyzes a patient’s age, sex, gender, and radiologist’s report for findings of low bone density and micro cervical fractures in order to provide an HCP with a list of follow-up options for consideration, such as performance of periodic bone-densitometry scans, nonpharmacological management (e.g., weight-bearing exercise), or referral of the patient to a specialist. | Probably more than "simple search", using such data found in patient-specific EHR could be seen as an aid to diagnosis and/or treatment. Such follow-up options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. |
| Software function that tracks and analyzes a chronic obstructive pulmonary disease (COPD) patient’s age and average number of steps walked per day in order to provide a list of follow-up options for the HCP to consider (e.g., office visit, chest CT, spirometry) to evaluate disease progression. | Probably more than "simple search", using such data found in patient-specific EHR could be seen as an aid to diagnosis and/or treatment. Such follow-up options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. | |
| Software function that analyzes blood glucose laboratory test results and pre- diabetes diagnosis from a patient’s medical record and provides an HCP with a list of next-step options to consider, such as more frequent office visits or referral to a specialist. | Probably more than "simple search", using such data found in patient-specific EHR could be seen as an aid to diagnosis and/or treatment. Such next-step options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. | |
| Software function that interprets daily results of a basic metabolic panel for a hospitalized patient and recommends several options for IV fluids that may be beneficial to ensure proper hydration and to prevent acidosis. In some cases, this software function may also provide recommendations for potential follow-up testing options. | Probably more than "simple search", using such data found in patient-specific EHR to provide potential follow-up testing options could be seen as an aid to diagnosis and/or treatment. Such recommendations are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. | |
| Software function that inputs information about a patient’s cancer progression and treatment history and other medical information from a patient’s medical record and recommends, in addition to prioritized treatments, that the healthcare practitioner also consider one or more legally marketed companion diagnostic tests. | Probably more than "simple search", using such data found in patient-specific EHR to pinpoint companion diagnostic tests could be seen as an aid to diagnosis. Such recommendation is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. (IVDR status also to consider) |
Examples of NonDevice CDS Software Functions - Criterion 4
The FDA guidance also contains examples of CDSS excluded by US regulation, with specific rationale for criterion 4. The table below shows the differences in regulatory status that we can expect between US regulation and EU regulation. As written above, the difference of regulatory status is striking.
| Software Function | Detail | MDR qualification |
|---|---|---|
| Software function that analyzes patient-specific medical information (e.g., end stage renal disease (ESRD) diagnosis, lab test results, and patient demographics from the patient’s medical record) and provides an HCP with a list of treatment options for ESRD based on implementation of practice guidelines. To enable the HCP to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, the software labeling and function provide the following information to the HCP: | The intended use, HCP user, and patient population are clearly identified. The intended use is not time-critical, and the intended HCP is expected to have sufficient time and training to understand the practice guidelines that are the basis of the recommendations; | More than "simple search": using such data found in patient-specific EHR and outputting data according to this intended use is an aid to diagnosis. Such treatment options are information which is used to take decisions with diagnosis or therapeutic purposes and are in class IIa or above. |
| The input medical information is clearly identified and relevant, with data quality requirements to ensure compatibility to enable relevant medical information to be extracted from the EHR; | Such labelling won't save the software from MDR scope. | |
| A plain language description of the underlying algorithm development and validation that forms the basis for any recommendations is provided. In addition, the practice guidelines being implemented are clearly identified to the HCP, and the guidelines contain sufficient information on their development and clinical studies underlying the recommendations for ESRD treatment options; and | ||
| The recommendations are provided to the HCP with relevant patient-specific information including a description of how the patient-specific information matches the criteria for treatment options in the practice guidelines. The output indicates whether any expected input medical information from the medical record was missing. | ||
| Software function that recommends a prioritized list of FDA-approved chemotherapeutic agents (approved for the patient’s diagnosed cancer type) to an HCP based on analysis of reported outcomes in a database of clinical studies using the patient’s diagnosis and demographics from the medical record. To enable HCPs to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, the following information is provided to the HCP: | The intended use, HCP user, and patient population are clearly identified. The use is not time-critical, and the intended HCP is expected to have sufficient time and training to assess the clinical studies that are the basis of the recommendations; | More than "simple search" and a "prioritized" list: using such data found in patient-specific EHR and outputting data according to this intended use is an aid to treatment and can be seen as a drug prescription assistance software. Such prioritized list is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. |
| The cancer diagnosis and patient demographics are clearly identified as the inputs being used in the database search and analysis; | Such labelling won't save the software from MDR scope. | |
| Information about how the clinical studies included were selected, the full reports of the clinical studies being relied upon are clearly identified, with a brief summary of the strength of each study (e.g., number of patients, outcome metrics, randomization, comparison arm), and the key elements of the diagnosis or demographics searched for in the medical record are noted; | ||
| The prioritized list of FDA-approved chemotherapeutic agents and the basis of the prioritization is provided to the HCP, and the studies that most closely matched the patient-specific diagnosis and demographics are identified. Other considerations, such as the warnings and contraindications from the current version of the FDA-approved drug labeling, are also provided to the HCP for consideration prior to making a final decision. | ||
| Software function that analyzes a COPD patient’s age and average number of steps walked per day in order to provide a list of follow-up options for the HCP to consider (e.g., office visit, chest CT, spirometry) to evaluate disease progression. To enable HCPs to independently review the basis for the recommendations presented by the software so that they do not rely primarily on such recommendations, but rather on their own judgment, the following information is provided to the HCP: | The intended use, HCP user, and patient population are clearly identified. The use is not time-critical, and the intended HCP is expected to have sufficient time and training to assess the clinical studies that are the basis of the recommendations; | More than "simple search": using such data found in patient-specific EHR and outputting data according to this intended use is an aid to diagnosis and/or treatment. Such list of follow-up options is information which is used to take decisions with diagnosis or therapeutic purposes and is in class IIa or above. |
| The patient’s age and average number of steps walked per day and the date of the measurement are clearly identified as the input information. The software also describes how this information is collected; | Such labelling won't save the software from MDR scope. | |
| A plain language summary is provided to the HCP describing how the algorithm is analyzing patient age and steps walked to assess activity and any validation studies, as appropriate; | ||
| The list of follow-up options is provided to the HCP to consider. The average metrics of the patient over time are shown in comparison with a subset of subjects from the underlying database with similar age, disease severity and demographics. The algorithm identifies limitations to consider, such as number of days with missing step information or high variability in daily measurements, which could impact the analysis or the follow-up recommendation based on the HCP’s judgement. |
Report on risks and benefits to health of non-device software functions
The FDA also published a Report on risks and benefits to health of non-device software functions in December 2022. The executive summary concludes: In general, the analysis found more benefits than risks to patient safety and health related to these software functions.
If we dig a bit, there is a specific section for Certain Clinical Decision Support. This section highlights evidence found in literature of a positive impact on patient safety, benefits and risks to health.
Even though they are not regulated, CDSS achieve a satisfying level of performance and safety. No need to regulate such low-risk software, then!
Conclusion
This FDA guidance on CDSS allows to exclude SaMD from the medical device scope of US regulations, when all 4 criteria are met. We saw above that this doesn't allow to exclude such CDSS from the EU MDR scope for approximately 50% of CDSS examples.
The winner is the US medical device market, attracting medical device manufacturers with their regulation exclusion policy for low risk software.
And the looser is the EU medical device market. Once again, the stricter qualification scope and up-classification by MDR rule 11 act as a scarecrow for medical device manufacturers. The amended FD&C Act and the resulting FDA guidance just make things better in the US, and by a mirror effect, worse in the EU.
The MDR doesn't need anybody to dig its hole. Unfortunately (or fortunately, it depends on the point of view), the US regulation adds a shovel of earth to the MDR grave.
Please, don't do SaMD in Europe and stay away from EU MDR unless you have very very good reasons! Especially for low risk and low profit software.
Believe me, or you won't sleep at night.
