Software is increasingly used as a medical device, transforming the healthcare industry with the goal of improving patient outcomes. However, developing software as a medical device involves navigating complex and evolving regulatory frameworks. Regulatory frameworks can complicate the already complex problem of innovation in software and can often run roughshod over the distinctions between software, artificial intelligence, machine learning, and deep learning. Development in each of these areas is known to progress in leaps and pauses and can occur at any point from data collection to testing, design, development, or deployment. Yet as human involvement leads to opportunities for technological improvements, human touchpoints can also lead to mistakes and biases. If it was ever the case that decisions on intellectual property (I.P.) protection and/or due diligence could be performed intermittently or delayed, this is not the case today in the field of software-based medical devices.
This article provides an update on how the FDA regulates software as a medical device and explores intellectual property strategies available to protect software-based medical devices. Awareness of changes at the FDA, and how these changes may influence your approach to the Patent Office, are important to secure a competitive advantage for your business but also for achieving the stated goal of improving patient outcomes. Errors and bias can be introduced at each human touchpoint, from data collection to algorithm implementation. Bias may translate to poor patient outcomes, and the FDA and companies implementing best practices will be looking internally to eliminate or reduce such bias. Analogously, an invention that functions to remove bias may also be worthy of patent protection and should be identified early so that appropriate protection can be obtained. Continuous assessment of research and development for I.P. and bias is the wave of the future.
FDA Regulation of Software as a Medical Device
The FDA classifies medical devices based on associated risks into one of three classes. The high-risk Class III devices need an authorized Premarket Approval Application (PMA) under Section 515 of the FFDCA before they are marketed, while other devices may be approved under Section 510 of the FFDCA (note that, unlike for Section 515, patents on products receiving Section 510 approval are not eligible for Patent Term Extension).
Software as a Medical Device (SaMD) is defined as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”[1] Software as a medical device generally falls under 510k, but determining whether an individual product is “software as a medical device” and is appropriate for a 510k designation is determined as a case-by-case issue and is beyond the scope of this article. The FDA uses “key attributes” to identify a SaMD, including the level of dependence or reliance by a user upon the output information from the medical device. Note, however, that the FDA manages a public list of medical devices utilizing AI/ML technologies approved by the FDA Center for Devices and Radiological Health. The list currently includes over 520 devices, with a large majority approved under a 510k designation. The FDA also makes a distinction between software as a medical device (SaMD), software in a medical device (SiMD), and software used in the manufacture or maintenance of a medical device.
In part due to the challenges to AI development mentioned above, the FDA is adapting and trialing pilot programs to accommodate the risks and fast-paced changes characteristic of the industry. A recent AI commission recommended a risk-based approach to AI regulation, wherein “as-necessary required” regulations would apply to AI applications with negligible risk to privacy, health, safety, or fundamental rights.[2] The FDA’s Software Precertification (Pre-Cert) Pilot Program is such a program designed to streamline the regulatory process for software as a medical device (SaMD) developers. The program is based on the idea that the regulatory focus should be on the development process, rather than the individual products. Under the program, SaMD developers can apply for pre-certification, which would allow them to bring their products to market without undergoing the traditional FDA review process. Instead of reviewing a completed medical device, the FDA would assess the developer’s software development process and determine if they meet certain criteria for quality and safety. If approved, the developer would be granted pre-certification, which would allow them to bring their SaMD products to market faster and with less regulatory burden. The pilot program is currently ongoing, with several SaMD developers participating in the program.
Engaging in such a program could impact your strategic decisions regarding your intellectual property. For example, how will a valuable idea be identified, and when will a patent application be filed? These decisions might not be appropriate to be delayed until a 510K filing. Also, an innovation that one might prefer to be kept as a trade secret may be inevitably revealed as part of ongoing due diligence. In order to protect software innovations, companies that design SaMD are often faced with the decision of whether to rely on trade secrets or patent protection. Both approaches have their advantages and disadvantages, and striking the right balance between them can be crucial.
Intellectual Property Protection for Software as a Medical Device
In this section, we’ll explore the intellectual property protection available for software as a medical device. SaMD may be covered by both utility patents and design patents (covering the user interface, or the look and feel of the software). U.S. patent law surrounding software protection has earned a reputation for being stricter on eligibility for software patents, especially since the Alice decision.[3] Yet, AI now appears in 18% of all utility patent applications the USPTO receives. In fact, there are many features of SaMD that are still patentable, such as novel methods for improving the accuracy or reliability of medical diagnoses or treatment plans, and adaptable software platforms that can be tailored to specific patient needs or medical contexts.
This past year, in response to an Executive Order on drug price competition, patent examiners at the USPTO have been undergoing cross-training with the FDA to search all information that FDA makes available on drug products and medical devices. Some concerns were raised to both agencies that companies were making inconsistent statements about their products being modest changes to the FDA while claiming significant innovations at the USPTO. We note, however, that seemingly inconsistent statements may arise simply because something may be non-obvious under the USPTO’s standards, but still qualify as predictable and safe for the FDA. The impact of any cross-training remains to be seen, and Examiners currently review Orange Book listings and other publicly available information on FDA databases. Coordination between statements to the FDA and USPTO highlights the importance of a rigorous I.P. evaluation process throughout the lifecycle of SaMD development—from conception to FDA approval and is needed to best protect SaMD innovations.
As an alternative to patent protection, companies designing software as a medical device may pursue trade secrets directed to, for example, algorithms used to analyze medical data, proprietary software code, and other confidential information. Trade secrets refer to confidential information that a company keeps secret to gain a competitive advantage. The trade secret route could forgo the costs associated with filing a patent application, but companies will need to memorialize and protect the trade secrets from disclosure, including having detailed procedures in place to protect against disclosure of the trade secrets. This proactive process of identifying your intellectual property and memorializing trade secrets, even if opting out of patent protection, is particularly helpful when an employee leaves the company and a dispute over ownership of technology arises. Legal recourse for misappropriation of a trade secret is available if reasonable steps are taken to secure the trade secrets, including advising employees that trade secrets exist in the organization and obtaining agreement from the employees that they will hold any confidential information including trade secrets in strict confidence. Typically, these restrictions are included in employee handbooks and employment agreements.
Strategies for Navigating the Regulatory Landscape
In this last section, we’ll provide a potential strategy for developers looking to navigate the complex regulatory and legal landscape surrounding software as a medical device. As above, we recommend proactively identifying your intellectual property, which may entail filing patent applications early and often. An idea may be considered ripe for patenting when it meets the legal requirements for patentability (such as novelty, and non-obviousness) and is sufficiently developed to be described in a patent application; however, ripeness can be a difficult determination.
A valuable approach to address this uncertainty is to file a provisional patent application including all disclosure available at that time and update the filing during the priority year as the invention evolves or more supportive data is produced – a process referred to as the “rolling provisional.” A provisional application remains unpublished for a year, at which point it may be converted into a utility patent application or an international application (PCT). By using the rolling provisional approach, the originally filed provisional application is updated with the new data and disclosure and then the new application is filed as a second provisional application. This process can be repeated throughout the priority year as more data and disclosure becomes available, filing successive provisional applications. Upon conversion of the first filed provisional application into the utility application or international application, the utility application or international application will claim priority to all the successively filed related provisional applications and in this manner, the evolving embodiments developed over the priority year can be protected. Because provisional applications are not published, the filing of a provisional application can also be used to memorialize the conception date for an invention or for memorializing a trade secret. For example, one may memorialize a trade secret in a provisional application, and expressly abandon the application or allow it to lapse by not converting it to a utility application or international application. By this approach, the application having the trade secret will not publish but a record of the trade secret is memorialized with the patent office. Finally, best practices include compartmentalizing ideas that you want to keep as a trade secret. However, if you are in an FDA precertification program, for example, and unintentionally disclose a trade secret, there is a one-year grace period for public disclosures during which you may still file patent applications in the U.S. (though this grace period is not applicable in most countries outside of the U.S.).
In conclusion, developing software as a medical device is a complex process requiring careful attention to both FDA and USPTO regulatory frameworks. Yet by understanding how the FDA regulates software as a medical device and the patent protection available, developers can create innovative solutions that improve patient outcomes while protecting their intellectual property.
[1] https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd
[2] https://www.uschamber.com/technology/u-s-chambers-ai-commission-report-highlights-the-promise-of-ai-while-calling-for-a-risk-based-regulatory-framework
[3] Alice Corp. Pty. Ltd. v. CLS Bank Int’l – 573 U.S. 208, 134 S. Ct. 2347 (2014)
Subscribe for News and Updates
