June 26, Division of Dockets Management (HFA-305) Food and Drug Administration 5630 Fishers Lane, Room 1061 Rockville, MD 20852

Transcription

1 701 Pennsylvania Avenue, NW Suite 800 Washington, D.C Tel: Fax: June 26, 2018 Division of Dockets Management (HFA-305) Food and Drug Administration 5630 Fishers Lane, Room 1061 Rockville, MD Re: Docket No. FDA D-1339: Multiple Function Device Products: Policy and Considerations; 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 further input on the Food and Drug Administration s ( FDA or Agency ) Draft Guidance for Multiple Function Device Products ( 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. We commend FDA s decision to apply the policies espoused in the Draft Guidance to all medical devices with multiple functions, regardless of whether they contain software. However, we believe it is critical that the Draft Guidance clarify that FDA does not intend to review a function simply because it is part of a multiple function device product, that is: Not a device, a class I exempt device, a class II exempt device, or a device subject to enforcement discretion. We are concerned that, without this clarity, an inconsistent approach to the review of exempt products would occur because different reviewers may come to different conclusions when assessing the two key questions described by the Draft Guidance: (1) Does the other function impact the safety and effectiveness of the device function under review, and (2) does the impact result in increased risk or have an adverse effect on performance? By way of example, FDA recently exempted IVD calibrators and controls. Under the Draft Guidance, however, a reviewer may now find reason to request data previously submitted for calibrators and controls, defeating the purpose of the exemption. Such a scenario would create an unpredictable review process. Accordingly, FDA should make clear in the Draft Guidance that it will review the device function(s) for which clearance or approval is sought and assess only the impact of such other functions on the device-under-review. We believe this approach represents an effective use of Agency resources and is consistent with the least burdensome approach. 1 Multiple Function Device Products: Policy and Considerations (April 27, 2018), available at Bringing innovation to patient care worldwide

2 Docket No. FDA-2018-D-1339 June 26, 2018 Page 2 of 2 Our specific comments to the language of the Draft Guidance can be found in the attached document. * * * AdvaMed would like to thank the FDA for its consideration of these comments. 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 We recommend changing the definition to: Products with at least one device function subject to FDA oversight and at least one other function that is not subject to FDA oversight are referred to as multiple function device products We recommend adding the following language: The use of partitions in software systems can be an effective strategy to limit hazardous situations. Documentation of impacts on other functions are critical to completing a thorough risk analysis We recommend the following revisions: developing appropriate hardware and software resource specification(s) for the product with multiple functions to ensure performance of the other function(s) when used with minimal impact of the other function(s) on the performance of the device function-under-review; and We recommend the following revisions: how to ensure appropriate actions are taken by the end user when using the other function(s) with the device function-under-review with the other function(s) We recommend the following revisions: Do the other function and the device function-under-review share the same output screen Graphical User Interface? The definition should be aligned with the definition on lines Without this recommended addition, all medical devices could be considered a multiple function device. To be consistent with software terminology used in IEC62304, terms such as partition of functionality and limiting hazard situations should be used. The suggested wording provides clarity and avoids confusion since performance of other function(s) is not subject to FDA review. Since the objective of this section is to provide guidance on minimizing impact of the other function(s) on the performance of the device function-under-review, the language here should focus on preventing any potential adverse effect from the other function(s) when using the device function-under-review. Clarification of language It is unclear what FDA means by the phrase share processing time. Microprocessors can assess multiple simultaneous calculations, so any function would be viewed as sharing processing time It is unclear what FDA means by the phrase share memory. Devices, such as smartphones, have multiple types of memory (ram, dram, etc.). Any function could be viewed

4 as sharing memory We are concerned that while FDA states it will only assess the impact of the other function on the device-under-review, it does not appear that FDA has streamlined any of the documentation requirements necessary to demonstrate the impact. Consistent with the principle of the least burdensome approach, we encourage FDA to require only the necessary information to answer the specific regulatory question concerning the impact of the other function. Otherwise, the documentation and testing of the impact of the other function could require the same amount of documentation and testing for the function-under-review We recommend adding the following language after the introductory paragraph (lines ) in Section VII: If based on the sponsor s assessment, the other function could not adversely impact the device function-under-review (i.e., there is no impact on the safety and effectiveness of the device function-under-review and it is therefore low risk), the sponsor is not required to submit the supporting documentation described in this section. However, the sponsor is required to document the impact assessment and justification for their determination within their quality system Manufacturers should be permitted to limit the indications for use to the device function under review, but also be encouraged to consider the needs of the customer and the potential for confusion The Draft Guidance is not aligned with the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices with respect to Architecture documentation for Minor Level of Concern Software contained in a medical device. N/A Under Section VI. A of the Draft Guidance, we believe many, if not most, common scenarios would result in a determination of performance impact. It also appears that FDA expects, in Appendix 2, that all of the examples would require the submission of supporting documents described in Section VII of the Draft Guidance. We believe that there are relevant scenarios where the impact of the other function(s) on the performance of the device function-under-review is very limited and therefore low risk on the safety and effectiveness of the device function-under-review. Limiting indications for use to the device function under review may be unduly burdensome and/or confusing in some cases. Increasingly, we are seeing situations in which functions that are not regulated in the US may be regulated in other countries, and the inclusion of other functions in the indications will allow for multijurisdictional labeling. Table 3 in the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 11, 2005) states architecture is not required for software with a Minor level of concern in a Class II device. 2

5 We recommend the following revisions: When required, the risk analysis included in the premarket submission FDA must clarify that only functional requirements are needed for Minor Level of Concern Software, consistent with the Agency s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 11, 2005) We recommend deleting the sentence beginning with for example, and replacing it with: Software requirements should describe the functional and non-functional requirements of the software system We recommend adding BLA to Table 1, so it states: Device function under review (510(k), PMA, BLA, IDE, De Novo, or HDE) We recommend deleting the phrase: The smartphone s computing platform performance may not be adequate to support the software functions including the algorithm intended to detect skin cancer. The scope of the Draft Guidance is not limited to software devices. The risk analysis explained in this subsection would not generally be required for a product that does not contain software. FDA may also consider using the term Hazard Analysis to cover minor level of concern software issues, consistent with the Agency s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 11, 2005). Table 3 in the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 11, 2005) states that only functional requirements are required for software with a minor level of concern. The example of providing system memory necessary is a very narrow example and may lead to confusion. Per lines in Section III of the Draft Guidance and in Section 520(o)(4)(B) of the FD&C Act, it seems that the Draft Guidance is intended to encompass device functions intended (i.e. for use in the manufacture and transfusion of blood and blood components), which are subject to BLA requirements. It would therefore provide clarity if BLA is specifically called out in Appendix 1. Given that the product detects skin cancer from photos of suspicious lesions of moles, the application does not seem to provide the diagnosis in a real-time treatment scenario. In which case, computing performance will not be of concern. If a less powerful platform is used, the algorithm will either be slow or will not be able to execute at all. In either case, it will only delay diagnosis, but will not cause misdiagnosis. Computing performance 3

6 will only be a factor in time-critical decision-making scenarios, such as the one described on line 460 where a delay in diagnosis may exacerbate injury to the patient Inclusion of Indications for Use as described in Section VII. A. into each example in Appendix 2 would be appropriate to differentiate between the device function-under-review and other functions as it pertains to incorporation (or excluding) into the indications for use We recommend adding the highlighted text: determine if the user has suffered from Traumatic Brain Injury (TBI) in the acute period after an injury Examples should allow for analysis/assessment, not just testing (e.g., wireless coexistence). Lines suggest that the indication for use should only include the device function-under-review, but the Appendix 2 examples do not include example indications for use. See rationale in response 16. Testing may not always be required to assess the impact of designs and changes. For example, TIR69 allows for a risk-based approach with respect to the need for wireless coexistence testing. 20 Appendix 2 (line ) 21 Appendix 2 (line ) The examples should clarify whether FDA expects to evaluate the documentation cited as part of the premarket review or, instead, as part of the Design History File. The draft guidance states that the policy may be applied to products that are not just software. A non-software example of device-function and nondevice function would be helpful for context. We believe documenting the information in the DHF but not submitting it for FDA review, particularly where the documentation shows no adverse impact, would represent the least burdensome approach. N/A 4