While the original Apple Watch was a genuine consumer product with fitness tracking and health-oriented capabilities, the adjunct of the ECG app and irregular heart rhythm notification has transformed this product into a Medical Device (MD). Like any MD manufacturer, Apple had to comply with the regulation and get clearance from the FDA to market its ECG app for its smartwatch as an MD Software (SW) in the US. This product may be the most iconic, but it is not the only one offering multiple functions where some meet the definition of a Medical Device Software. We can speculate it is going to be more and more common with the development of e-health platforms hosting different modules with clinical, educational, or administrative capabilities. In this context, the FDA has recently published a new guidance document entitled Multiple Function Device Products: Policy and Considerations.
The FDA could have found a catchier title to make this new guidance stand out during this busy summer but, despite the bleak title, the document is worth reading.
The first statement sets the scene: “Medical products may contain several functions, some of which are subject to FDA’s regulatory oversight as medical devices, while others are not”. The intension of this guidance is to state the FDA policy in this context and their expectations for manufacturers with respect to product development including software, regulatory approval, and postmarket activities.
They introduce new vocabulary such as:
- Device function – a function that meets the definition of a device
- Other function – in short “non-device function”
- Device function-under-review – function for which FDA is conducting the premarket review (as opposed to FDA “enforcement discretion”)
In essence, in the case of a product with multiple functions, including both non-device and device functions, the FDA may assess the impact the non-device function has on the device element. This will include assessing the safety and effectiveness of the device function regardless of whether it is software-based, hardware-based, or both. The FDA intends to review the device function(s) for which clearance or approval is being sought and not device functions that are subject to an enforcement discretion policy.
The FDA recommends a separation in design and implementation of the device function from “other functions” (e.g., logical separation, architectural separation, code, and data partitioning). They emphasize aspects related to architecture at an early stage and the benefits of separation for cybersecurity.
Manufacturers should determine and document if an “other function” impacts either negatively or positively the safety or effectiveness of the device function-under-review. The guidance provides a flowchart and a set of questions to proceed with this assessment. The FDA expects the rationale for a manufacturer’s determination of the impact of the “other function(s),” to be present in a premarket submission either if the “other function” could adversely impact the device function-under-review or if the device function-under-review could be positively impacted by the “other function” and the labeling reflects the positive impact.
This document also details the content of all sections of the premarket submission in this context (Indications for use, Device description, Labelling, Architecture and design, Device hazard analysis, Requirements and Specifications, Performance Testing, Submission Summary).
The guidance covers the aspects related to modifications made to the “other function”. They should result in an assessment to determine if the change could significantly impact the safety or effectiveness of the device function that was the subject of FDA review.
In the context of the postmarket, the guidance indicates that if an “other function” is suspected to be the cause of a reportable event, the manufacturer should report the event to the FDA.
In the appendix, the FDA gives several examples to illustrate different cases with multiple function device products. Provided for educational purposes, these case studies may constitute a good starting point for e-health manufacturers to get a concrete idea of what has to be done in their own context.
To conclude, we would strongly recommend the reading of this guidance not only to regulatory affairs responsible but also to the development managers. Based on this guidance, they should consider amendments to their development and document processes in order to have the proper assessment of “other functions” in place and required documentation.