Top IP, FDA, and Compliance Issues for Medtech Companies Transitioning to Data-Enabled Product Solutions

Our medtech IP advisors have a unique understanding of and capabilities in advising companies regarding their IP protection strategies in the emerging fields of SaMD, SiMD, software and AI in medical technologies. Key topics identified for medtech companies include:

1. How to Strategically Diversify IP Protection

1. Patent the device and consider patenting the software it utilizes.
2. Alternatively, or additionally, consider protection of methods, AI/ML learning mechanisms and software as a trade secret.
3. Ensure non-compete and confidentiality agreements with employees are in place, to the extent possible given jurisdictional constraints.
4. Consider exclusive licensing of training/learning databases to exclude others from developing similar solutions using these databases.
5. Albeit narrower protection, copyright and trademark as appropriate.

2. Whether to Patent or Keep Innovations as Trade Secret 

Generally speaking, the ability to reverse engineer is the key inquiry in deciding if patent or trade secret is the appropriate mode of protection for a company’s data-enabled invention, along with the evolving laws around eligibility of patenting of such inventions (See IP Point 4, below). 

1. Patenting must reveal details, which can be challenging when protecting data-enabled software that includes AI/ML aspects, broadly. Thus, patenting is best for devices and for protecting the interplay of physical products and software.
2. Trade secret requires you to maintain and protect secrecy indefinitely, but can be imitated if your idea garners attention. It is often best for software, manufacturing methods, or products that are costly or difficult to imitate.

3. If Patenting, How to Balance Breadth and Abstraction in Patent Claims to Maximize Protection 

Claiming software uses necessary functional language* to describe the invention… which can be too abstract for protection by patent law if at too high of a level. Nevertheless, patentees will always seek to broadly cover their invention, thus resulting in the tension that exists between breadth and abstraction levels in software patent drafting. 

* What is Functional Language? – Functional language explains what the invention does rather than what it is. 

1. Strike a balance in the claims between permissible breadth and amount of abstraction in the claim. Functional abstraction through pseudocode/native code should be covered in varying claim structures. Protection Cost Copyright Copyright Trademark Trademark Trade Secret Licensing Trade Secret Patent Patent
2. Be more detailed in the specification. Draft full descriptions of examples and use pictures to depict examples and describe both the functional abstraction level of detail through the pseudocode/native code in the specification.

4. Keeping Up with the Evolution of Subject Matter Eligibility in Patents 

U.S. law does not allow patenting of abstract ideas** or laws of nature.*** In 2014, the U.S. Supreme Court broadened this concept, giving the U.S. Patent Office additional ways to reject applications for AI-based patents and for trial courts to invalidate them. This decision has made it more challenging to obtain software and AI-based patents in the United States. There are creative ways to use the evolving case law and to present inventions to fall outside of this prohibition, but it is important to remain diligent of the volatile state of the industry. 

** Abstract ideas include (i) mathematical concepts, (ii) methods of organizing human activity and (iii) mental processes. 

*** Laws of nature include natural phenomena and products of nature. A discovery of something that is a natural law, not an invention. 

5. Artificial Intelligence Considerations: Permission, Assignments, Copyleft and Open Source 

1. Ensure you have permission to use the data.
2. Consider inventorship and get assignments from individuals who: (i) select the data acted upon by AI, (ii) review results or outputs of an AI engine, (iii) select ML algorithms used to train AI model, and/or write the source code to implement AI.
3. Be careful about open source usage and avoid copyleft.

Our medtech FDA advisors, including former regulatory counsel at FDA’s Center for Devices & Radiological Health (CDRH), partner with clients to develop and implement pre- and post-market strategies, prevent and resolve pre- or post-market issues and guide lifecycle management, with a keen understanding of how FDA works and how to leverage regulatory mechanisms and pathways to achieve clients’ business objectives. Key topics identified for medtech companies include: 

1. Use of Real-World Evidence in Regulatory Decision Making 

Real-world evidence (RWE) can be used for a variety of regulatory purposes, including to support bringing new devices to market, to evaluate the safety and effectiveness of existing devices for new uses, and to assess the continued performance and safety of marketed devices. 

Developers interested in utilizing RWE for regulatory purposes should select appropriate real-world data (RWD) sources based on their suitability to address specific regulatory questions. In particular, developers should consider the relevance and reliability of the Abstraction of Claims Breadth of Coverage Source Code Data Structure Design Execution Pseudocode / Native Code Abstract Data Type Functional Abstraction sources and their specific elements as FDA assesses these factors in determining whether the RWD sources can be used to generate evidence that is sufficiently robust for a regulatory purpose. 

2. Cybersecurity Concerns and Laws 

Cybersecurity has become an area of increasing FDA scrutiny. In recent years, for example, FDA has issued a number of safety communications related to cybersecurity vulnerabilities. Further, a number of medtech companies have initiated recalls to correct cybersecurity vulnerabilities. 

The FDA expects manufacturers to take a total product lifecycle approach to minimize cybersecurity vulnerabilities. Consider the following for developing and maintaining a cybersecurity risk management program: 

1. Premarket considerations
   1. Address cybersecurity during device design and development, including the establishment of design inputs related to cybersecurity and a cybersecurity vulnerability and management approach, as part of software validation and risk analysis.
   2. Understand the type of documentation related to cybersecurity to include in a premarket submission to FDA.
2. Post-market considerations
   1. Implement a comprehensive cybersecurity risk management program to monitor, identify, and promptly address cybersecurity vulnerabilities and exploits.
   2. Understand whether changes to medical devices for cybersecurity vulnerabilities require reporting to FDA.

3. Regulation and Categorization of Digital Health Products 

With the generation of repositories of data comes potential opportunities for the development of new stand-alone digital health products. A threshold question for digital health products is whether such products are actively regulated by FDA. Digital health products fall into one of three regulatory categories: 

1. Not a medical device: Many digital health products do not meet the statutory definition of a “device” and, therefore, are not regulated by FDA. This includes, for example, certain types of clinical support software (CDS).
2. Enforcement discretion: FDA has established a number of “enforcement discretion” policies, whereby FDA chooses not to actively enforce regulatory requirements applicable to medical devices. For example, FDA exercises enforcement discretion for a number of mobile medical applications that it views to be low-risk.
3. Actively regulated medical devices: Though FDA continues to explore other potential approaches, it generally applies the traditional framework for regulation of medical devices to all other digital health products

An understanding of these categories is essential as digital health products marketed without the requisite FDA marketing authorization may be, and have been, the subject of not only administrative action but also removal from distribution. 

4. Unique Regulatory Concerns of AI/ML-Based Medical Devices 

The FDA has stated on multiple occasions that the traditional paradigm of medical device regulation was not designed for adaptive AI/ML-based technologies, and it continues to consider multiple aspects of the regulatory framework for these technologies, including the following: 

1. Transparency of AI/ML-based devices
2. Good ML practices
3. Modifications to FDA-cleared AI/ML-based devices

Companies developing and marketing AI/ML-based devices should stay aware of FDA’s guidance on such technologies. 

5. Nimble Adoption and Tracking of FDA Guidance 

Stay aware of guidance relating to: 

1. Content of Premarket Submissions for Device Software Functions (Draft Guidance; November 2021)
2. Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (Draft Guidance; April 2022)
3. Risk Categorization for Software as a Medical Device: FDA Interpretation, Policy, and Considerations (Draft Guidance; anticipated)
4. Marketing Submission Recommendations for a Change Control Plan for AI/MLEnabled Device Software Functions (Draft Guidance; anticipated)
5. Clinical Decision Support Software (Final Guidance; anticipated)

Our medtech compliance advisors consist of an industry-leading team of healthcare regulatory lawyers who advise medical technology and diagnostic companies on a range of legal and regulatory compliance issues. Key topics identified for medtech companies include: 

1. Data Collection, Use and Sharing 

Medtech-enabled data platform companies need to be mindful to take appropriate care of data, including: 

1. Patient data
2. Drug development data
3. Customer/provider data
4. AI/ML-developed data sets

2. Adapting to Evolving Interactions with Physicians, Patients and Other Stakeholders

1. As the landscape moves from a treatment/provider-centric approach to a preventative/patient-centric one, interactions with patients present a host of additional compliance issues.
2. Company relationships with healthcare providers and customers are changing, especially as technology allows for greater real-time monitoring of patients and real-time data entry.
3. Enhanced data collection means increased collaboration with stakeholders

3. New Regulatory Regimes Around Donation of EHR, Cybersecurity Technology and Information Blocking

1. As HHS implements new regulatory requirements around topics like the donation of EHR & cybersecurity technology, companies needs to be mindful of tracking these donations and transparency requirements, ensuring that each arrangement is supported by legitimate need and addressing topics like updates and replacements.
2. New rules on information blocking and defined standards of “interoperability” could have an impact on medtech-enabled data platforms.

4. Addressing Value-Based Care Considerations and the Federal Anti-Kickback Statute Safe Harbors 

Medtech-enabled data platform opportunities include: (i) streamlining and coordinating care, (ii) real-time quality and outcomes measurement, (iii) more narrowly tailored, patient-centric solutions, (iv) enhanced data view when coupled with machine learning, and (v) cost savings. However, companies should carefully examine federal Anti-Kickback Statute safe harbors and align their practices to these regulatory requirements. 

5. Navigating Through the Lack of Advanced Industry Standards 

Medtech-enabled data platforms reflect a new evolution in the medtech industry, and there is a need for more advanced industry compliance standards beyond the typical topics addressed by industry codes of ethics, like the AdvaMed Code. While codes currently focus on traditional sales and commercial arrangements, a growing industry requires new industry-wide thinking on topics like the ethics of data and AI, data sharing among companies and with customers, information blocking, and avoiding corporate practice of medicine limits.