Re: Docket No. FDA-2017-D-6569: Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff

Transcription

1 701 Pennsylvania Avenue, NW Suite 800 Washington, D.C Tel: Fax: February 6, 2018 Division of Dockets Management (HFA-305) Food and Drug Administration 5630 Fishers Lane, Room 1061 Rockville, MD Re: Docket No. FDA-2017-D-6569: Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff To Whom It May Concern: The Advanced Medical Technology Association ( AdvaMed ) appreciates the opportunity to provide comment on the Food and Drug Administration s ( FDA or Agency ) Draft Guidance titled Clinical and Patient Decision Support Software ( CDS Draft Guidance ). 1 AdvaMed represents manufacturers of digital health technologies, medical devices, and diagnostic products that are transforming health care through earlier disease detection, less invasive procedures, and more effective treatment. Our members range from the smallest to the largest medical technology innovators and companies. It is essential that FDA adopt the right policies to promote and encourage the development of safe and effective medical devices, while also enabling efficient development of these technologies. We believe the CDS Draft Guidance takes an important step in clarifying the types of software that are, or are not, subject to FDA s regulatory oversight. However, while the CDS Draft Guidance assists firms in determining the regulatory status of a particular product, we believe FDA should issue additional guidance describing how it will regulate CDS that is subject to the Agency s rules and regulations. Similarly, we suggest FDA provide a risk-based framework to determine when certain CDS tools should not be regulated as a medical device due to its risk profile (i.e. low-risk CDS). We also appreciate FDA s discussion here of artificial intelligence and machine learning processes. Nevertheless, the concept of transparency conveyed in this CDS Guidance should remain focused on the information underlying the recommendation within an artificial intelligence and/or machine learning process, rather than the algorithm itself. Lastly, we note that there a number of FDA guidance documents in the digital health space that deem particular functions subject to FDA s enforcement discretion. AdvaMed supports publication of guidance documents and appropriate exercise of enforcement discretion when understood and properly executed across the Agency. While the use of enforcement 1 Clinical and Patient Decision Support Software: Draft Guidance for Industry and Food and Drug Administration Staff (Dec. 8, 2017), available at pdf. Bringing innovation to patient care worldwide

2 Docket No. FDA-2017-N-4301 February 6, 2018 Page 2 of 2 discretion can offer a degree of flexibility and allow FDA to quickly address policy matters for new technologies, we believe FDA should ultimately undertake an effort to codify its existing enforcement discretion policies by establishing regulations and product codes for these devices by defining them as Class I devices exempt from premarket notification and the requirements of the Quality System Regulation, and other FDA regulatory requirements as appropriate. We believe doing so will provide long-lasting clarity and reduce any regulatory concerns companies may have. Our specific comments to the Draft Guidance can be found in the attached chart. * * * AdvaMed would like to thank the FDA for its ongoing work related to digital health technologies and looks forward to continuing to work with the Agency on these important issues. Please do not hesitate to contact me at or zrothstein@advamed.org if you have any questions. Respectfully submitted, /s/ Zachary A. Rothstein, Esq. Associate Vice President Technology and Regulatory Affairs Attachment

3 AdvaMed Comment Form 1 General We recommend revising the phrase approved drug labeling to approved drug or medical device labeling whenever used in the CDS Draft Guidance We recommend adding after approval requirements: (otherwise referred to as enforcement discretion) We recommend revising the text as follows: This guidance does not address other FDA statutory or regulatory requirements that may apply to certain decision support software, including software disseminated by or on behalf of a sponsor, for use with one or more of its drugs or biologics, such as requirements applicable to drug or biologic labeling or combination products. To the extent a software (device) and drug/biologic product meet the definition of a combination product, the requirements for the device constituent part should not change. If FDA plans on creating separate guidance to implement section 3038 of the 21 st Century Cures Act, then this statement should be updated to reflect that these topics are (or will be) described in separate guidance Lines and express different concepts. Lines state the intended use of the basis of the recommendation (rationale or sources) is to inform the user s own judgement. However, lines states that the user should be able to reach the same conclusion. We recommend revising the language in per our comments below to be consistent with the previous statement. Also, when a manufacturer provides the supporting information, it is not clear whether this means the information that is used by the software to CDS tools could analyze individual patient data to suggest medical device treatment based on FDAapproved medical device labeling. This change maintains consistent terminology. This statement is overly limiting, and it should be clarified or deleted. The requirements for software should be the same regardless of whether is it provided for use with a drug, biologic, or device. This statement may conflict with the inclusion of examples associated with medication reminders and drug interactions. The phrase, independently confirm the recommendation could be interpreted differently than providing the basis for the recommendations. The guidance should use consistent phrasing for these concepts. 1 When applicable, additions are marked as underlined text and deletions are struck. These additions and deletions are also in red font.

4 inform selection of a recommendation or information to allow the intended user to perform an independent/parallel assessment. To be clear, these are not always the same Replace lines with the following text: III. DEFINITIONS For the purposes of this guidance, FDA is defining the terms Unregulated CDS and Unregulated PDS based on section 520(o)(1)(E) as follows: Unregulated Clinical Decision Support: Those software functions that are (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; (2) intended for the purpose of displaying, analyzing, or printing medical information (such as peer-reviewed clinical studies and clinical practice guidelines); (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; 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. Unregulated Patient Decision Support: Those software functions that are (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; (2) intended for the purpose of displaying, analyzing, or printing medical information about a patient or other medical information (such as information derived from peer-reviewed clinical studies and clinical practice guidelines); (3) intended for the purpose of supporting or providing recommendations to a patient or non-health care professional caregiver, in terms that are understandable to the patient or non-health care professional caregiver, about prevention, diagnosis, or treatment of a disease or condition; and (4) intended for the purpose of enabling such patient or nonhealth care professional caregiver to independently review the basis for the recommendation so that it is not the intent that such patient or non-health To improve overall clarity, unregulated CDS and PDS should be defined using a common structure, in the same section of the guidance (proposed as Definitions ), and without references to 520(o)(1)(E) in either definition. We recommend that FDA only define unregulated CDS and unregulated PDS to the extent the statutory provisions of section 3060 of the 21st Century Cures Act apply. Section 3060 of the 21 st Century Cures Act only defines unregulated CDS; it does not purport to define broadly what tools may be considered CDS (which could include products that are not subject to FDA oversight). Indeed, FDA s proposed definition of CDS is not consistent with well-understood parameters of what may constitute CDS and is inconsistent with other governmental and industry organizations definitions of CDS. Accordingly, limiting the definition simply to what the 21 st Century Cures Act defines as unregulated CDS will limit confusion. 2

5 care professional caregiver rely primarily on any of such recommendations to make a decision regarding the patient ; Footnote 2 We recommend moving the definition of physiological signals to the body of the guidance. The definition of signal acquisition systems is too broad and could apply to smartwatches and activity monitors that contain algorithms or that analyze data. It is also unclear whether the term includes the electrochemical response detected by a CGM sensor. As a result, we suggest modifying the definition as follows: Physiological signals are those signals that require use of either an in vitro diagnostic device or signal acquisition system. In the context of an in vitro diagnostic device, a physiological signal is typically an electrochemical or photometric response generated by an assay and instrument that must be further processed by software to generate a clinical test result. A signal acquisition system is the electronic circuitry and control processor that receives, as inputs, signals from sensors that are within, attached to (e.g., EEG, ECG), or external to (e.g., CT, MRI) the human body or sample from the human body (e.g., digital pathology). The fidelity with which a physiologic signal is captured, processed, and analyzed is often critical to the overall performance of a device We recommend revising the following text, or analyze and interpret genomic data (such as genetic variations to determine a patient s risk for a particular disease). To: or analyze and interpret genomic data to identify a patient s genetic variations for the purpose of determining a patient s risk for a particular disease. This is the first instance of FDA defining and using this term, making it important to provide additional clarity to ensure that the term signal is well understood. To that end, we recommend adding the suggested language. Clearly, software (either as part of an IVD instrument or as standalone software) that is used to process raw signal measurements, such as the electrochemical or photometric responses generated by IVD assays and instruments, is regulated as a device. Such software typically converts these signals to a test result, such as PaO2 test result or a hemoglobin A1c test result. These test results may then be used by CDS software to make clinical recommendations. As highlighted in Section IV of this guidance (and specifically in the examples described in lines and ), there are examples of CDS functions that utilize such IVD test results and are not considered devices. As such, we believe it important to make clear in the guidance that, in the context of IVDs, signal refers to the electrochemical or photometric response generated by the IVD and not necessarily the final test result. Otherwise, FDA could unintentionally regulate any result, including for example a result residing in an electronic health record, which we do not believe is FDA s intent. We believe this language is clearer. 3

6 8 187 We suggest including a discussion concerning the differences between MDDS and CDS Revise text to read: Revise text to read: FDA interprets this to include software functions that display, analyze, or print patient-specific information, such as demographic information, symptoms, and test results, and/or medical information, such as clinical practice guidelines, peer-reviewed clinical studies, textbooks, approved drug labeling, and government agency recommendations, and aggregated historic information, such as real world evidence, on multiple patient treatments. This means that software functions that support or provide recommendations to patients not health care professionals are not excluded from included in the definition of device Provide more information about the ways that manufacturers can provide the information identified in lines , and whether the information needs to be built into the software tool We recommend FDA revise the phrase, the intended user should be able to reach the same recommendation on his or her own without relying primarily on the software function. To: The relationship between CDS and MDDS isn t clear, particularly after reading this section. Aggregate or statistical information on patient diagnosis, treatment and outcome by specific medical devices (bigdata mining) may support a HCP in the diagnosis and treatment for specific patients. This change would help clarify that, under the second prong of the exclusion, data mining software are not regulated as devices. These products aggregate patient data, generally through the cloud, without processing the data (images or signals), besides presenting statistics on the data, such as averages, standard deviation, etc. An example of these statistics are procedure time, disposable utilization, patient demographics, treatment parameters used, and treatment success rates. This change is more consistent with the language of the statute, which indicates that the definition of device shall not include the software functions identified by the provisions. While the legislative language included a series of double negatives, the guidance document would be clearer if they were removed when possible. It would be helpful to understand FDA s thinking on the appropriate ways of providing this information. For example, is it sufficient to provide a reference in the software tool? Can the information be provided in documentation that accompanies the software (user guide, sell-sheet, or specifications)? What are the ways that FDA anticipates this information to be provided? Lines and imply different concepts regarding what the basis for the recommendation is intended to provide for the user. The first says the intended use of the basis of the recommendation (rationale or sources) is to inform the user s own 4

7 intended to enable health care professionals 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, to make clinical decisions for individual patients. judgement and the second says that the user should be able to reach the same conclusion We recommend FDA clarify what is meant by easily accessible, understandable, and well understood. For example, information may be easily accessible even if proprietary (e.g., curated database), when accessible by request to a subscriber Industry interprets this statement to mean that either providing the underlying rationale or the sources of supporting information are valid approaches on presenting the basis of the recommendation We recommend revising the text as follows: and publicly available to the intended user (e.g., clinical practice guidelines, published literature, and real world evidence) We recommend FDA provide rationales for the assigned regulatory designation for all of the examples contained within the CDS Draft Guidance We recommend FDA provide examples of scoring algorithms that are not devices. We appreciate clarification of the transparency element of section 520(o)(1)(E)(iii), but the terms used in the guidance are subjective and could lead to greater confusion and inconsistency in practice. Greater clarity and examples would be helpful. Also, the literature and other sources (even peerreviewed) do not always agree; in fact, they often do not. It should be recognized that software functions may include judgments based on the weight of the evidence, but still remain within the transparency element. The CDS Draft Guidance is not clear that FDA will accept either method as a mechanism for satisfying the fourth criterion. We recommend this change as there may be clinically relevant content that is used as input to the software function that may not be available to the general public but would be available to the healthcare professional. It would be helpful to include rationales for each example explaining why the described software is or is not a medical device. FDA does an excellent job providing such rationales in its recently issued Guidance, Deciding When to Submit a 510(k) for a Software Change. We recommend the Agency do the same here. It is helpful to use examples to facilitate the understanding of requirements around the independent evaluation of the recommendation. Section IV.B includes an example of a software function that uses a proprietary algorithm for which the basis of the 5

8 recommendation is not available for review. It would be helpful to understand what makes the basis available for review. For example, novel software algorithms may be published in the medical literature. Does this satisfy the requirement that the user can independently evaluate the basis of the recommendation? The Draft CDS Guidance should address whether it applies to software functions that are part of a medical device by inserting the following language after line 238: CDS that is incorporated into a device, but does not impact the intended use of the device, is still considered CDS We recommend revising the text to: Software that helps to identify drugdrug interaction and drug-allergy contraindication alerts, based on FDAapproved drug labeling or other sources and patient-specific information, to prevent adverse drug events We recommend revising the text to: Software that provides health care professionals with recommendations on the use of a prescription drug or medical device that are consistent with the FDA-required labeling, or that are described in other sources such as those identified in the definition of CDS We propose adding the following language: Software that uses rule-based tools that compares patient-specific signs.... Devices contain highly modular software and even separate computers. Not all drug-drug interactions are described in approved drug labeling. To reduce patient risk, all available information on drug interactions should be included in this example, not just in a footnote (in this case, footnote 6). CDS tools could also provide recommendations on the use of medical devices. The scope of information contained in this software should be expanded to match the description in lines Limiting the example to information found in the FDA-required labeling could interfere with a physician s ability to prescribe medication in a way that is most beneficial to the patient. This restrictive approach is not consistent with the remainder of the draft guidance, which relies on the judgement of the physician. If information is included that is not consistent with the drug s labeling, this should be made transparent to the user. We are concerned that reference to rule-based tools is unnecessarily limiting given the speed of software innovation. The concept of transparency conveyed in this CDS Guidance should remain focused on the information underlying the recommendation. 6

9 Clarify what is meant by available practice guidelines and state that local, non-published, hospital guidelines are an institutional guideline We propose adding the following language: based) or real world evidence data to recommend We recommend revising the example to read: Software that presents and prioritizes alternatives to orders, drugs, or therapies using practice guidelines and other generally accepted practices, such as rule-based tools allowing health care professionals to efficiently select diagnostic tests, drugs, devices or therapies in accordance with clinical practice guidelines, peer-reviewed clinical studies, textbooks, real world data or other appropriate sources, and their approved or cleared labels We recommend adding the following example to Section IV.A. (Examples of CDS Functions that are not Devices) of the document: Software that generates patient specific surgical plans by analyzing patient specific information with respect to available sources to assist health care professionals in making diagnosis or treatment decisions, but ultimately the health care professional must rely primarily on their own judgment to make clinical decisions for individual patients. Local, non-published, hospital guidelines should be authoritative medical sources as they meet the requirements listed in Footnote 3 on page 8, are available to the user, and therefore, are considered an institutional guideline under this example. There may be clinically relevant content that is used as an input to the software function that may not be available to the general public but could be made available to the healthcare professional that uses the device. For many disease states, the current standard of care is not included in the labeling for the medical products. Not including all available information will increase patient risk. This should be excluded from the device definition to differentiate between the examples given for products that are devices that also talk about patient specific plans. In this proposed example, the product does not meet the definition of a medical device because: (1) it does not acquire, process or analyze medical image or a signal from an IVD or a pattern or signal from a signal acquisition system, (2) it is intended for the purpose of displaying and analyzing medical information about a patient, (3) it is intended for the purpose of supporting or providing recommendations to a HCP about diagnosis or treatment of a disease or condition, and (4) it is intended to enable HCPs to independently review the basis for the recommendations so that it is not the intent that the HCP relies primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient. 7

10 We recommend adding the following example to Section IV.A. (Examples of CDS Functions that are not Devices) of the document: Software that provides real world evidence to a health care provider to facilitate discussions with the patient regarding their recovery; or helps health care providers confirm appropriateness of treatment; or provides benchmarking service for health care providers to compare their patients outcomes (e.g., to national norms) We recommend adding the following examples to Section IV.A. (Examples of CDS Functions that are not Devices) of the document. Example: Data flags are typically set by a healthcare provider (HCP) and are used in conjunction with lab policies and procedures to make additional sample processing decisions. Data flags are used to analyze patient results, for the purpose of providing supporting information to the HCP, while allowing the HCP to independently review the basis for such recommendations, and does not play the primary role in making a clinical diagnosis or treatment decision. Example: Software that uses rule-based tools to compare patient specific results to HCP-set or confirmed normal ranges We recommend adding the following example to Section IV.A. (Examples of CDS Functions that are not Devices) of the document: Software tools that analyze stored clinical information to flag patient This type of information for HCPs meets the criteria for exclusion from the definition of a device, as it meets all four of the criteria in section 520(o)(1)(E) In comparing this draft guidance with the simultaneously released 21 st Century Cures draft guidance, FDA applies inconsistent standards to the regulation of software. For example, in the 21 st Century Cures draft guidance, FDA maintains its jurisdiction over software that generates alarms or alerts because the tool analyzes results. In contrast, FDA removes CDS from its jurisdiction in this guidance so long as the HCP can independently review the basis for such recommendations and does not rely primarily on the CDS recommendation in making a clinical diagnosis or treatment decision. Arguably, data flags are far more simple and straightforward than CDS and under the control of the HCP. Data flags are used in conjunction with lab policies and procedures. Therefore, the HCP does not rely primarily on the data flag or alert in making a clinical diagnosis or treatment decision. Data flags are used to analyze patient results for the purpose of providing supporting information to the HCP, while allowing the HCP to independently review the basis for such recommendations and to also apply specific lab procedures and policies with regard to additional sample processing decisions. FDA should apply the same risk-based approach to alerts and flags as is applied to CDS. This example appears in lines of the 21 st Century Cures draft guidance and should be included in this guidance, instead of an example of a software function that is not a device. It contains many similarities to the 8

11 results based on specific clinical parameters (e.g., out of range results, potential drug interactions, opportunities for complementary tests, create disease registries, summarize patient- specific information in an integrated report, and/or track a patient s treatment or disease outcome) provided that the healthcare professional does not rely primarily on the recommendation and does not represent a unique interpretation function but rather summarizes standard interpretation of individual variables that healthcare practitioners could do themselves. examples already provided and should be excluded from the device definition because: (1) The software function is not intended to analyze a signal (as defined in the guidance) or medical image from an IVD or from a signal acquisition system; (2) The software function is intended for the purpose of displaying and analyzing patient or medical information; (3) The software is intended to support recommendations to an HCP about prevention, diagnosis, and treatment of a disease or condition; and (4) The software function enables the HCP to independently review the basis for the recommendation and it is not intended that the HCP rely primarily on the recommendation - the flags are based on established guidelines and are readily available for independent review by an HCP We recommend revising the example to read: Software that helps create custom implants and/or customizes the patientspecific surgical plan and instrumentation based on analysis of imaging and device characteristics for orthopedic implant or dental implant procedures We recommend providing additional examples of medical episodes that may be assessed in real time by software functions that use inputs from regulated medical devices We recommend revising this example to: Software intended for health care professionals where the basis for the recommendation is not disclosed to the user to analyze patient information (including noninvasive blood pressure (NIBP) monitoring systems) to determine which anti-hypertensive drug class is likely to be most effective in lowering the patient s blood pressure. The current proposed language creates confusion, particularly with respect to patient specific plans. It is unclear if the end goal is to focus on implant only procedures and associated instrumentation that has been customized for those procedures. There are examples of patient specific plans that clearly meet the definition of a clinical decision support product that does not meet the definition of a medical device. FDA has provided two examples: heart attack and narcolepsy. It would be useful to provide examples that are more nuanced and to explain whether medical episodes that are not medical emergencies (e.g., depression, Attention Deficit Hyperactivity Disorder, Parkinson s Disease) would also be included. It is critical to revise these examples to explain that FDA s thinking about the medical device status in the example is due to the fact that the basis for the recommendation has not been provided. 9

12 We recommend revising this example to: Software that analyzes a patient s laboratory results to recommend a specific radiation treatment, for which the basis of the recommendation is unavailable for the HCP to review Add the following example to Section IV.B. (Examples of CDS and Other Software Functions for Health Care Professionals that Remain Devices): Software intended to generate an alarm or an alert to notify a caregiver, and the caregiver relies primarily on this alarm or alert to take immediate clinically relevant action Replace lines with the following text: FDA does not intend to enforce compliance with applicable regulatory requirements for PDS that enable the patient or non-health care professional caregiver to independently review the basis for the recommendation so that it is not the intent that such patient or non-health care professional rely primarily on any of such recommendations to make a decision regarding the patient. It is critical to revise these examples to explain that FDA s thinking about the medical device status in the example is due to the fact that the basis for the recommendation has not been provided. This example is currently in the 21 st Century Cures draft guidance and should be referenced in this guidance as well because it discusses the threshold at which data transported through MDDS is analyzed by a CDS tool. PDS is defined earlier in the document (section II) so there is no need to include lines in Section V. The latter portion of the sentence uses existing text from lines We recommend providing additional examples for the rationale or support for the recommendation for a patient or non-healthcare professional for a PDS We recommend providing additional examples of the kinds of explanations that a health care professional may understand versus a patient s understanding due to educational and experience differences We recommend including the following example: Software that provides information or general instructions to patients or nonhealthcare professional caregivers that are not specific to any drug, biologic, or medical device labeling, such as pre- and post- surgical care preparation and instructions. Examples would be helpful to clarify the type of rationale that patients would be able to understand. It would be helpful to understand FDA s thinking on what patients should be able to understand. This type of information for patients meets the criteria proposed by FDA as being under enforcement discretion We recommend revising the text to read: Medication reminders and information should be 10

13 Software that provides information to a patient about the use of a prescription drug that is consistent with the FDA-required labeling or the patient s prescription, such as reminding the patient how or when to take a prescribed drug. Such software does not recommend changes in dose or drug discontinuation that healthcare providers do not oversee (unless drug labeling includes such recommendations). available to patients who are taking medication in accordance with their prescription, which often represents the standard of care. This limitation could interfere with a physician s ability to prescribe medication in a way that is most beneficial to the patients and the specifics of their disease state, and could increase patient risk We recommend including additional examples of PDS that would be subject to FDA oversight. The CDS Draft Guidance contains only one PDS example. Additional examples would be helpful to further understand the boundary between the PDS that FDA intends to regulate and those they do not. 11