Digital Health: Check Your Legal Vitals

By Todd Basile and Charles C. Dunham, IV 

Numerous digital health technologies are being created, enhanced, and defined in real time through machine learning or other artificial intelligence techniques, such as Clinical Decision Support (CDS); Mobile Health (mHealth); Medical Device Data Systems (MDDS); Robotically-Assisted Surgical (RAS) Devices.   

 These technologies can be used as a medical product, incorporated into a medical product, or used as a companion or adjunct to a medical product, including diagnostics and therapeutics. 

The U.S. Food and Drug Administration (FDA) has certain authority and requirements governing the production and distribution of medical devices in the U.S. market pursuant to the Food, Drug, and Cosmetic Act (FD&C Act) and its implementing regulations. These laws and regulations govern, among other things, product design, development, manufacturing, packaging, labeling, marketing, distribution, promotion, import, export and post-market surveillance. Unless an exemption applies, each medical device commercially distributed in the United States requires premarket authorization — either 510(k) clearance, PMA, or grant of a de novo classification.  Each of these regulatory pathways to market a medical device can be expensive, time consuming, and lengthy.   

The 21^st Century Cures Act (“Cures Act”) was enacted, in part, to promote innovation in digital health technologies to improve the quality of health care through revisions to agency regulation and oversight.  The Cures Act contains numerous provisions intended to amend FDA’s authority, codify historical enforcement discretion policies issued by the FDA, and accelerate the FDA approval pathway for new medical devices while maintaining the same standard for safety and effectiveness. While the Cures Act was signed into law on Dec. 13, 2016, the rulemaking process is still ongoing across multiple federal agencies; however, there have been numerous important developments with respect to digital health technologies.    

• Excluded Devices:  Section 3060 of the Cures Act excluded software functions from the definition of a medical device, and thereby, removed certain digital health products from the FDA’s premarket clearance and oversight. The primary consideration is whether and how the software function will analyze or interpret medical data.  The Cures Act does leave the FDA with authority to regulate any software function if the agency makes a finding that it would be reasonably likely to have serious adverse health consequences and certain substantive and procedural criteria are met.  In April 2021, the FDA reviewed all device classification regulations and amended the “identification” description of eight classification regulations to conform to the medical software provisions of the Cures Act.

• Exempt Devices: Section 3054 of the Cures Act requires FDA to identify additional types of Class I and Class II devices that no longer require a 510(k) notification to the agency. Classification of a device is important because the class to which a device is assigned determines, among other things, whether and what type of FDA premarket authorization is needed, if any. 

• Breakthrough Devices: Section 3051 of the Cures Act mandated FDA to create a program to expedite pre-market approval of “breakthrough” medical devices that (i) offer a significant advantage over existing treatments or diagnoses for life-threatening or irreversibly debilitating diseases; (ii) represent a breakthrough technology; (iii) address a condition for which no treatment exists; or (iv) the availability of the device is in the best interest of patients.  This is of particular importance to the medical device industry’s policy agenda toward expansion of coverage and reimbursement of technology-based services, as many devices FDA-designated as breakthrough technology will be instantly covered under the Medicare program for up to four years (or two years after the market authorization by FDA).  However, the Biden Administration is currently attempting to reverse course and repeal the Medicare Coverage of Innovative Technology final rule which is scheduled to become effective on December 15, 2021.

• Digital Health Innovation Action Plan: The FDA’s Digital Health Innovation Action Plan (DHIA) is focused on reducing premarket requirements on digital health products to promote innovations and general wellness through population use.

Protecting Valuable Digital Health Technology

Software and data are at the forefront of digital health technologies. Whether it is use of augmented reality to assist in surgery, the use of machine learning to improve diagnostics, or the use of data collected by connected medical devices to derive valuable insights about product functionality and usage, software and data have quickly become some of the most important assets of digital health companies. There are several ways savvy digital health companies can protect such valuable intellectual property and thereby gain a competitive edge.

Clarify Ownership. Digital health companies interact with developers, industry partners, customers, end-users, and other parties throughout the development and commercialization of digital health products. With so many parties involved, disputes can arise if ownership rights are not clearly documented. For example:

• Developers may be under the impression they are customizing and licensing their platforms to the company rather than creating a “work for hire” to be owned by the company;

• Companies partnering to commercialize a new product may disagree as to how new technology created under the partnership, as well as valuable data collected from customers and end-users, can be used by one another; and

• Ownership questions may arise when digital health companies adopt customer suggestions for new software features and functionality. 

Accordingly, agreements with employees, developers, industry partners, customers, and end-users should clearly carve up rights in technology and data amongst the parties and include assignment provisions and license grants as appropriate. Companies should also update their terms and conditions to ensure that the company owns the data it collects from end-users, or at least has the end-user’s permission to use such information for the actual purposes envisioned by the company. Because data is often collected from medical devices and may include personal identifiable information (PIIA) of users, digital health companies should also make sure their software and data collection practices meet data security and privacy guidelines. Non-compliance with privacy regulations such as HIPAA and European General Data Protection Regulation (GDPR) may result in civil or even criminal liabilities.

Maintain Control. Smart digital health companies will also use contracts to control development and use of their software and data. Well-drafted development agreements set forth detailed specifications, performance requirements, milestones, payment schedules, and other criteria intended to keep the project on track, as well as any constraints the company may wish to place on the developer’s use of the deliverables with other clients. 

Development agreements should provide strict guidelines if open-source software (OSS) will be included in the deliverables, since some OSS is subject to copyleft licensing terms that may force unwitting digital health companies to publish their source code and/or provide their software for free. Further, removing OSS often involves costly redesigns to avoid potential copyright infringement going forward. Companies should track their use of OSS and third-party software and ensure its agreements require developers to adhere to the company’s policies and identify all such software components included in their deliverables.  

Digital health companies may also want to maintain close control over valuable data shared with third parties. In such cases, confidentiality provisions can take on even greater importance and should specifically address things like who at the third party can access the shared data and for what purpose, as well as include strict obligations requiring the shared data to be returned or destroyed immediately upon request by the company. It can also be helpful to include a provision in which the third party agrees that its breach of the confidentiality provisions may entitle the company to immediate injunctive relief in an effort to mitigate further damages associated with unauthorized use or disclosure.

Terms of Use should also define how customers and end-users are permitted to use the software and prohibit activities that may compromise underlying intellectual property such as reverse engineering and allowing unlicensed users to access the software. Likewise, terms of use should provide the company freedom to add/remove/modify features, implement design-arounds to navigate IP infringement claims, and perform maintenance without violating service level warranties.

Guard Trade Secrets. A digital health company’s success is often attributable to its confidential information and know-how. Accordingly, companies might consider implementing strong safeguards and policies to keep valuable information proprietary to the company. 

At a minimum, companies should ensure that all employees, contractors, visitors, and potential partners sign written non-disclosure agreements (NDA). A well-drafted NDA will not only require the recipient of confidential information to avoid disclosure to third parties, but also will constrain the recipient’s use of the confidential information to a limited purpose (e.g., evaluating the compatibility of the company’s technology with the recipient’s product). This tends to make recipients more mindful of protecting the company’s information. 

Even with such contractual safeguards in place, digital health tech companies should also implement procedures to restrict access to its trade secrets on a “need-to-know” basis. For example, companies may configure their IT systems so certain technical information is accessible only to engineers or scientists that need such information to perform their job and is not accessible to other departments. Likewise, software-related trade secrets can be protected by providing customers and authorized third parties with access only to APIs and executable files, and no access to the underlying source code, libraries, and databases where a company’s “secret sauce” typically resides. Finally, if a situation arises when the trade secrets need to be disclosed, for example, as part of a joint venture, the companies should have procedures ensuring that trade secrets are disclosed only to the extent absolutely necessary and only after execution of a strong NDA.

This article is presented for informational purposes only and it is not intended to be construed or used as general legal advice nor as a solicitation of any type.