Digital Healthcare 2023

Introduction

In the near future, “digital healthcare” will become just “healthcare” as data and digital healthcare technologies and practices are integrated into most fields of patient care and medical research. Data, AI and the internet of medical things (IoMT) are critical to the power and efficacy of digital healthcare, and accelerating advances in them require accelerated innovation in structuring and drafting healthcare technology and data agreements.

New forms of agreements that address the issues of data, AI and the IoMT are necessary to implement advances in digital healthcare.

Data, AI and Machine Learning

Data and actionable insights

Data becomes valuable in healthcare when it is converted into information, and information becomes valuable when it is converted into actionable insights. These insights are what lead to advances in clinical medicine and research.

Data does not manage itself

Data is not technology and data does not manage itself. Data must be collected, transmitted and analysed using digital healthcare technologies. Medical devices that are connected together in computer networks constitute the IoMT. These connected devices collect data from multiple sources and provide it for multiple purposes, including use in AI, to generate insights that can be acted upon.

AI is not a single technology

AI is not a single technology but a series of technologies. These include algorithms, which are a set of instructions that tells a computer how to process data.

Machine learning and “augmented” intelligence

Machine learning is a form of AI in which one or more algorithms process data without having to rely on rules that are programmed into the algorithm. Algorithms are developed by human programmers, but increasingly AI refines and generates new algorithms without direct human involvement. Machine learning uses data to train the algorithms to identify patterns in the data and generate correlations and predictions, such as whether a spot on a medical image is a tumour and whether the tumour is benign or cancerous. The algorithm assigns weight to different factors in reaching its “conclusion” that a tumour is, or is not, benign.

Because the weight assigned by machine learning is part of the so-called “black box” of AI, physicians need to know what weight was assigned to different factors in order to trust the outcome and use it in patient care. As a result, AI in healthcare is “augmented intelligence” rather than “artificial intelligence” because it is machine learning in combination with doctors’ skills that create the healthcare benefit.

AI and the IoMT do more than collect data. They also generate new data, which in turn further trains the algorithms. Moreover, the collection, creation and use of data and machine learning complicate the application of IP law to data in particular and to digital health technologies in general. Accordingly, contracts should be used to bring more clarity to the allocation of ownership, licensing and sharing rights in data and machine learning outputs. Such contractual allocation is important in the multi-technology, multi-vendor, multi-user, multi-stakeholder environment that characterises both hospitals’ healthcare systems, healthcare institutions and healthcare providers (henceforth “hospitals”) and their technology and data providers.

Most digital healthcare agreements are combined data, technology and IP agreements subject to various healthcare, data protection, privacy and other regulations. The regulatory overlay adds complexity to contract negotiations when different jurisdictional requirements apply to hospitals and/or their providers.

The impact of COVID-19 on digital healthcare technology use

COVID-19 has accelerated the development and deployment of digital healthcare technologies (including the use of telehealth and remote medicine), and in many cases made existing agreements inadequate for digital health. COVID-19 has increased the opportunities for technology vendors to provide upgraded digital health technologies to hospitals and regulations have changed to remove obstacles to the use of digital healthcare technologies for telehealth services.

IT infrastructure

Most current hospital IT systems are not designed to handle the volume of data now generated by the IoMT, including networks formed by connecting multiple IoMT subnetworks, or to conduct the sophisticated data analytics made possible by advances in AI technology. As a result, the use of digital healthcare technology requires the upgrading of IT infrastructures and negotiating the agreements that provide for those upgrades, which often involve moving to cloud computing and data storage environments with their attendant security risks. Here legal departments and outside counsel must co-ordinate with the hospital IT and medical departments. Similarly, technology vendors must ensure a fair allocation of rights and responsibilities when they contribute to parts of the overall technology infrastructure.

AI as a change agent

To use AI as a change agent to improve healthcare, a hospital’s chief digital medicine officers and other data professionals must work together with IT departments to implement the desired transformation in data analytics and use of the IoMT. This is another example of the need to upgrade IT infrastructures. In addition, successful use of AI as a change agent requires the involvement of a hospital’s legal compliance officers. In designing new data management systems, it is easier to build-in regulatory compliance than to retrofit it.

Connected Devices

Examples of connected devices in healthcare are wearables (eg, sensors and data collection devices attached to the skin), implantables (eg, pacemakers), ingestibles (eg, diagnostic pills that transmit images), smartphones and similar devices, real-time location sensors (for hospital staff and medical equipment) and virtual reality and augmented reality devices (which are used in surgery and medical student training). Even drones, used in the healthcare aspects of disasters, and devices that transmit medical images and data between ambulances and emergency rooms are part of the system of connected devices.

5G Wireless Networks

The advent of 5G networks will add power to digital healthcare technology and bring advances in patient treatment. 5G networks are fifth-generation wireless networks that will replace the current 4G (fourth generation) networks and bring significantly greater speed, greater bandwidth and reduced latency, all of which means that more and richer data can be transferred in the same amount of time.

Connected devices create volumes of data that 5G can transmit between devices and the hospital’s general IT systems. As a result, connected devices in the IoMT will receive data more quickly and process it faster for increased functionality of machine learning.

Telehealth is an area where 5G can improve patient care by delivering newly created medical images to a physician’s desk during patent visits, allowing remote treatment by specialists located in distant medical centres, reducing the need for seriously ill patients to travel and providing medical care to rural and inner-city areas. 5G-enabled telehealth can be used within hospitals to connect emergency rooms with specialists and allow doctors at the main location of a hospital system to connect with doctors and patients at other facilities in the same system.

Preventative Healthcare

The types of connected devices in the IoMT include:

• physical healthcare devices subject to regulatory approval (such as by the Food and Drug Administration (FDA) in the United States);
• software as a medical device (SaMD), which essentially constitutes virtual machines, also subject to FDA approval;
• devices that collect, store and transmit health data in digital form, where the data is subject to healthcare regulatory schemes as well as privacy laws (including pursuant to the Health Insurance Portability and Accountability Act (HIPAA) in the United States); and
• wellness and fitness devices that are not subject to FDA or similar regulatory approval and that can transmit data without being subject to HIPAA and other healthcare data protection regimes (although privacy laws of general applicability may apply).

The combination of data from these devices combines traditional patient data with wellness data that creates rich data sets and enables a growth in preventative healthcare, which is distinguished from medical interventions such as surgery.

Preventative healthcare also requires updated technology and data agreements in order to collect, generate and share data from medical and non-medical devices from different sources and for the use of data for overlapping purposes.

The “Solid” Internet Protocol and Individual Control of Personal Health and Wellness Data

The combination of health and wellness data will lead to a demand for individuals to have greater control over how this data is used and for what purposes. This includes the ability of individuals to monetise their data by providing it to various institutions for a range of research, product development, data analytics and other purposes. A means to accomplish this is provided by the “Solid” protocol, which stands for “socially linked data”.

Solid has been developed by Sir Tim Berners-Lee, the inventor of the World Wide Web, in collaboration with the Massachusetts Institute of Technology. It is a Web 3.0 “web decentralisation project” designed to give individuals more control over which persons and things access and use their data; “things” refers to the applications on the internet. In this sense, Solid is designed to provide more individual control than exists in the current World Wide Web where individuals have limited control over how their data can be collected and used.

Solid makes use of “pods” (personal online data storage), which are storage areas controlled by individuals and which function as secure, personal web servers for data. Each pod has access rules that are specific to it. Individuals have the right to grant or revoke access to data in their pods (an individual can have more than one pod). Any person or application that accesses data in a pod uses a unique ID. Solid’s access control system uses these IDs to check whether an entity or internet application has the right to access and use data in the pod.

The connection between AI and Solid is that an individual can use AI to determine which data to load into the pod. The individual controls the machine learning algorithm and can change algorithms and thus the data loaded into the pod. The algorithm can be trained to screen for data features to be included and excluded from the pod. Because a pod controls access to and use of the data, it indirectly controls the use of a third-party AI to which the pod owner has granted use rights. Individuals can also use self-service AI to perform machine learning and data analytics on their own data and to determine whether the data set includes all or only part of health and wellness data.

From another perspective, such data analytics can guide individuals in deciding which data to include in their pod, or if they have more than one pod, to decide which data to include in each pod. Each pod can in turn operate according to separate rules for access and use of data sets by third parties and by “things” such as software programs.

A Proposed Licensing Paradigm: “Decision Rights”

At a technology company and healthcare institutional level, sharing data requires licences. As a practical matter, it is often difficult for parties to a transaction to reach an agreement on ownership of data because the scope of ownership and its status under IP rights is unclear under the present state of the law. A party is often concerned that by assigning ownership rights it will be giving up rights it may need in the future. Accordingly, parties focus on sharing data and the scope of use rights under sharing arrangements.

If we shift the focus from ownership to data use – because that is often the real issue involved – then we need a legal framework to govern the scope of use and sharing with particularity, in order to protect both providers and users of data sets.

This article proposes “Decision Rights” as that legal framework. Decision Rights is a licensing model that defines the purpose of conducting analytics and the use of the results in terms of decisions that can be made based on them. The model also provides the entity controlling the data with a mechanism to grant (and enforce) rights in the same data to different users for different purposes, thus enhancing data monetisation and revenue generation. Decision Rights protect against regulatory sanctions by putting boundaries on the data use that constrain the use rights on downstream parties. Under a Decision Rights framework, those entities owning or controlling a database would grant a set of rights defined by the decisions that can be made and, if desired, limit the rights to a business unit or even specific individual.

Addressing Cybersecurity Risks in Connected Devices

The IoMT gives rise to cybersecurity risks on various levels:

• the level of the device itself;
• when the device is connected into an IoMT;
• the connection of different IoMT networks to each other; and
• the connection of the IoMT networks to the hospital’s main computer systems and its IT infrastructure generally.

These risks have led the FDA to issue regulatory guidance in its “Cybersecurity in Medical Devices: Quality Systems Considerations and Content of Premarket Submissions”. The FDA issued this guidance in April 2022. This was not a set of formal regulations but guidance that the FDA provides to medical device manufacturers to meet in submitting devices for regulatory approval (ie, premarket submissions to the FDA). The background for this guidance is based on the following factors: (i) the very sophistication of advanced medical devices results in an increased risk to the safety and effectiveness of the device; and (ii) past cyberattacks have in fact rendered medical devices and hospital networks inoperable and disrupted the delivery of patient care.

The FDA guidance addresses these risks by requiring device manufacturers to adopt “security by design” (as an analogue to “privacy by design”) and to incorporate cybersecurity measures in the design and manufacture of medical devices. The guidance provides details on how the FDA will approach whether or not to approve the security of a medical device. It assumes that cybersecurity vulnerabilities exist now and that new threats will arise in the future. It therefore requires that manufacturers plan for future threats by having plans in place to mitigate risks that will arise, even if the exact nature is not yet known. The cybersecurity guidance focuses on the following areas, among others.

Security Risk Management

Security risk management includes threat modelling, or a process to identify security objectives, risks and vulnerabilities. This applies not only to the device itself but to the system in which it operates (including the applicable IoMT). Manufacturers are to define their countermeasures to prevent or mitigate the effects of threats during the device’s life cycle. The approach assumes “zero trust” (ie, that an adversary already controls the relevant IoMT). The guidance also requires the publication of a “Software Bill of Materials” (SBOM). The SBOM is to identify the components that are provided by the manufacturer itself and the components that originate with specific third parties. These are both hardware and software components (including open-source software). The SBOM must also identify which are the dependences of different components upon other components. While this is to allow hospitals to identify and assess the vulnerabilities of the components and their combination, it can also be viewed in some respects as shifting of vulnerability assessments to the hospitals.

Security risk easements of uncured defects must be identified to the FDA when the device is submitted for approval. A total product life cycle approach is required. There is to be a continuous refresh of security risk management activities to ensure timely identification of security risks and their mitigation.

Security architecture

Security architecture requirements include a set of security controls in specified categories including programming code integrity, security event detection, cryptography and “patchability”; ie, how software vulnerabilities will be remediated by patching the software on an ongoing basis. Security architecture assessments are to be made at the system or network level with a focus on both internal and external interfaces. Overall, the guidance is intended to ensure that manufacturers design devices to be capable of addressing future security threats that may arise.

Cybersecurity testing

Four types of security testing are to be conducted on medical devices during design verification and design validation stages. These are:

• security requirements;
• effectiveness of threat mitigation;
• vulnerability testing; and
• penetration testing.

Buying Technology to Build Technology

Risks resulting from changes in components in a device

Technology companies that build medical devices in particular and digital healthcare products in general need to buy technology in order to build their own technology. Digital healthcare products and services often consist of hardware components, software, services and raw materials provided to the product manufacturer or service provider by subcontractors, business partners and other third parties. The risks that arise, especially with connected devices made part of an IoMT, are as follows.

• If a third party changes a component included in the overall device, the substituted component may result in a changed device that no longer qualifies as an approved device. Put another way, the product will have to be approved as a new product with the required expenditure of time and funds.
• A change in a third-party component may decrease the functionality of the device as a whole. This is a risk that applies whether or not the device requires regulatory approval.

A change in a component may result in a change to a device that adversely affects the performance of other devices connected to it or otherwise dependent upon it (eg, for the generation of data).

Contractual steps to address these risks

Digital healthcare technology companies can use contracts to address the risks introduced by changes in constituent components. The technology company can require approval of changes or substitutions in components of raw materials. Another solution, especially when continued regulatory approval prohibits changes in components, is to require the subcontractor to continue producing the old version of the product along with the new version. This way the technology company can be assured of a supply of conforming components.

Similarly, the technology company can require the subcontractor to produce a large quantity of the old version of the component for the company to use even as the subcontractor provides the new version to other customers. The technology company as buyer can build a substantial inventory of the required component for its use, even if the subcontractor changes the component. The contract can require the provision of this inventory when both parties know that the component will change either because of supply change problems or because of advances in technology. Finally, the technology company can secure alternative backup suppliers, which also may mitigate the dangers of supply chain problems for products manufactured in certain countries.

Backward compatibility

Another issue that digital healthcare technology companies face is ensuring that new versions of components continue to work with the prior versions of the components. To address this, the technology companies can require that subcontractors and suppliers design components to be backwards compatible with prior versions. A common approach is to require the new version to be backward compatible with the earlier two versions of the component. (Among other things, this will allow the technology to support and maintain products that it sold to customers before the new version was released.) The contract should define what backward compatibility means. It may require that the component be backward compatible with external devices that connect with the technology company’s product.

Backward compatibility should include, where applicable, requirements that the new version connects with, interfaces with, integrates with and otherwise works in conjunction with the external devices and the prior versions of the component.

Forward compatibility

The success of backward compatibility is increased if each version of the component is designed to be forward compatible with planned new versions. This is implemented by technology requirements in contracts.

Cybersecurity requirements

Backward and forward compatibility are an important part of implementing “security by design”. Contracts should address the risk that new versions of a component will introduce cybersecurity risks that did not exist before or that become an avenue for a cyber-attack on a hospital’s IT infrastructure or an avenue to make unknown changes to data use in machine learning that, in turn, can have an adverse effect on medical care.

Virtual Assistants

Virtual assistants, such as Amazon’s Alexa, will increasingly become the user interface with digital healthcare technologies as well as part of a system of connected devices, and they raise several issues. They can expose the IoMT networks to cybersecurity attacks and data breaches. They can enable unauthorised access to personal health information. Depending on the role they serve in part of a system of connected devices, they may be required to meet regulatory requirements (eg, the requirements for “Business Associate Agreements” under HIPAA under US law) when they are providing services to healthcare institutions that are under an obligation to securely store and transmit digital personal health information.

They also raise the following legal questions.

• What privacy requirements apply to communications transmitted through the virtual assistant and to conversations recorded by the device?
• How long will hospitals need to retain recordings for legal compliance purposes and for the hospital’s policies for research and patient care?
• Will records be accessible by regulators and what is the permitted scope of use by regulators?
• How will recordings be used in litigation?
• What is the scope of liability of the relevant parties that can arise for unauthorised use of an IoMT or data?
• How will virtual assistants be used in training algorithms for machine learning?

Open-Source Software

Open-source software is attractive to academics. However, professors and researchers often do not understand that open source is not free software but a free licence to use the software and that licences have restrictions and provide benefits. They are often not aware that there are nine basic open-source licences and that they have different terms. Some licences can result in a loss of IP rights. Accordingly, legal departments should establish rules governing the internal and external use of open-source software with a focus on protection of intellectual property rights.

Conclusion

The IT ecosystem of AI, data and the IoMT requires contracts that provide the necessary interoperability and data exchange between connected devices and also impose technology requirements to address cybersecurity risks. This in turn requires contracts that require co-operation from the manufactures of devices and providers of services used in the IoMT. Accelerating advances in AI and data analytics and the technological capabilities of software and physical devices will improve patient care and speed up medical research. All this requires thoughtful contracts so that all technology companies and hospitals can meet opportunities and mitigate risks as digital healthcare evolves.