Health Data Ownership in IoT and the Cloud

Technological advances within the healthcare industry (e.g., mHealth) have created an unprecedented amount of user-generated, health-related data [199,

257]. Data ownership and the implications on personal and data privacy from third parties attempting to connect to these devices in order to access, capture, analyze, and share this data remains an under-explored area from a policy and regulatory perspective [199, 237]. Thus, there is a clear need for transparent regulations and requirements for health-related data ownership and sharing.

IoT Data Ownership Challenges

Although ownership and protection of health data is an obvious concern within the healthcare field, the use of loT-based health devices makes the issue more complex. In particular, some of the factors that further complicate establishing data ownership include the unobtrusive nature of the loT device and its portability, and users' mobility, patterns, and preferences. Further, a vast majority of loT devices feature unconventional user interfaces, which increases the difficulty of performing a large number of tasks (e.g., user consent and authentication). Given the diverse nature of loT user interfaces, there currently is no "one size fits all" solution. Developing unique solutions for each loT device further complicates the endeavor of developing standardized data ownership regulations.

Consent for Data Capture

A multitude of loT-based health devices are continually capturing data from the outside environment. Due to the nature of continuous data collection, the data resulting from this process has the potential to include data sourced from nonconsensual collection, i.e., data collected from individuals without authorization or informed consent, or data collected from individuals unaware of the data collection. In these scenarios, it is difficult to designate the data owner: should the data belong to the owner of the loT device, or should it belong to the individual whose data is being captured? While traditional loT devices, such as smart doorbells, are in use, the owner of the device is often responsible for ensuring that any captured data is not violating privacy laws, irrespective of whether or not they are operating the device. Depending on these local laws, the owner might need to obtain authorized or informed consent from all individuals before they are captured by the device.

However, the ability to obtain authorized or informed consent through an loT device is especially challenging due to its inherent characteristics (e.g., ubiquity, transparency). As an example, placing a physical sign regarding the data collection policies of an loT device could easily go unnoticed, thereby not constituting authorization or informed consent from the recorded individual [101]. Whether or not an individual or user were to observe a physical sign, notice, or warning, the unique interfaces used in a vast number of loT devices may prevent the individual from providing authorized consent. For example, audio interfaces used by voice assistants (e.g., Siri, Google Assistant) may not have a visual interface for the user to provide consent in a trivial manner. The ubiquity of loT devices makes this process impractical since a user may need to authenticate and provide consent in a location with a large number of devices. Furthermore, multiple requests for consent have the potential to create user fatigue, thereby making user consent invalid and impractical [101].

In a healthcare setting, several of the challenges associated with obtaining authorized and informed consent of data collection from loT devices can be resolved as part of the registration process for new patients. Similarly, in clinical research, researchers can obtain informed consent for all data collected by any loT device used within a study as part of the standard informed consent process approved by their Institutional Review Board (IRB). In addition, loT devices that collect clinically-relevant data outside of healthcare settings should be designed to only collect identifiable data from their consenting subject. Enabling real-time, on-device data processing may help to overcome this challenge. As an example, the Apple Watch provides a Noise app that performs local audio processing to enable users to understand the sound levels in environments that could negatively impact hearing. The Noise app performs local processing without recording audio content and thus does not currently require consent from inadvertently recorded bystanders in areas where it is available [14]. Additional frameworks for obtaining consent from loT devices where these methods are impractical have been proposed, such as implementing informed consent through gateway devices- either directly from users or indirectly through a centralized registry [101]. For example, The Privacy Coach [76] scans RFID tags within loT devices to compare the device's specifications to the user's privacy preferences.

Verifying Data Ownership: Local Identity Management and Authentication

Many loT devices used in healthcare are primarily used as sensor devices to collect data. Since the data collected from these devices is being used in an increasing number of clinical decision-making processes, the sensor data can be manipulated in an adversarial manner to change clinical practice. In a potential future clinical situation without a human in the loop, these data integrity issues can lead to significant security gaps, as studied in the field of adversarial machine learning [171 ]. Even with a human in the loop, healthcare providers will rely on loT-collected data to make clinical decisions that may be impacted by false data. This data integrity issue requires mechanisms for local user identity management and authentication in healthcare regardless of whether or not the device can provide direct access to clinical data. In practice, these adversaries could be third parties looking to cause harm, or patients looking to alter data for personal gain, such as a patient working to manipulate his data in order to be prescribed a controlled substance.

The distinct interfaces of loT devices can make local authentication challenging. Even if alternative devices can be used to authenticate loT devices through proximity, it can create enormous user burden and fatigue with ubiquitous loT deployment. Developers of loT devices that collect healthcare-relevant data must therefore balance the need for authentication with user burden to promote device compliance and limit security risks.

In addition to loT devices that produce clinically-relevant data, some devices may consume produced data and provide feedback to users. Secure authentication is increasingly vital for these devices because of their potential to leak personally identifiable clinical data. In particular, these devices could reveal personally identifiable information (Pll) that is traditionally respected as sensitive both within and outside of healthcare environments.

In order to assist in securing patient information, several loT device authentication schemes have been proposed. Although these schemes are not widely accepted, they support the non-traditional interfaces of many loT devices and could be applied to health devices. These authentication mechanisms vary in their overhead and burden to the user, and therefore may need to be considered on a device-by-device basis. These authentication mechanisms may also need to be used in conjunction with other mechanisms (either as an additional or alternative factor) to meet specific device requirements.

A non-comprehensive overview of several authentication mechanisms relevant to healthcare is listed below:

• Proximity-based Authentication: Several loT device authentication approaches rely on the device's proximity to other user-owned devices, often acting as a physical authenticator. Relying on the prevalence of mobile devices such as smartphones, these mechanisms can require varying degrees of interaction with the user. At the simple extreme, proximity- based authentication might involve automatically authenticating devices within a specific range of proximity. On the more stringent extreme, when user attention is deemed necessary, proximity-based authentication mechanisms can require specific user action. Move2Auth [394] is an example of an interactive authentication scheme, wherein it requires users to perform specific hand gestures with a smartphone near the loT device in order to authenticate. Because of their potential security vulnerabilities, proximity- based authentication schemes must be carefully evaluated before adoption in healthcare environments. Although elliptic curve cryptography (ECC)- based radio-frequency identification (RFID) loT authentication schemes have been deployed in healthcare environments, all implementations might not have security requirements that are suitable for healthcare deployment [160]. Proximity-based and other physical authenticators may also be used to de-authenticate after proximity or physical contact has ended. [1]

devices can use heartbeat or capacitive sensors to detect when the device is removed and thus should be de-authenticated [368]. Because these factors themselves may be considered personal data, storing them directly on devices for authentication is highly discouraged. Instead, the configuration of loT devices for biological authentication should utilize raw sensor data to train a mathematical model such that the original personal data cannot be reconstructed. Apple's TouchID technology used in select iPhones, iPads, and computers utilizes a similar approach [1].

  • Proxy-Based Authentication: Proxy-based authentication relies on a secure channel between a specific proxy and the loT device [86]. In this approach, a proxy (e.g., a clinician) would verify the user's identity and authenticate the device to the user. This proxy access could be granted to the clinician for a specific device to limit the possibility of this privilege being misused. Generally, when proxy-based authentication is required, devices should not de-authenticate with other factors in order to decrease burden on both the users and the proxies (often healthcare providers).
  • Behavioral Authentication: The less commonly deployed strategy of behavioral authentication relies on non-biological behavior data to identify a user [286]. By relying on behavioral data, the user authentication process can often be implicit, with limited user burden. Although challenging, the development of novel secure behavioral identification techniques would have payoffs that could significantly improve the usability, and, therefore, the adoption of loT device authentication. Current implementations have been developed that identify habits based on user data such as phone calls and locations, but are currently only suitable as secondary factors within multifactor authentication architectures [179, 328].

Healthcare Data Ownership

Much of the data currently used by healthcare providers is stored within health information technology systems. This data often takes the form of an electronic medical record (EMR), electronic health record (EHR), or personal health record (PHR). While these terms are often used interchangeably, there are some significant differences to these terms with regards to health data ownership. EMRs are traditionally owned by a single office or organization and are mainly a digital version of a traditional paper medical record [15]. EHRs are similar to EMRs in that they are owned by a healthcare organization, yet differ in the context that EHRs are designed to enable sharing with providers across healthcare organizations [15]. In contrast, PHRs defer ownership to the patient who collects and stores information across healthcare systems [4]. While EHRs are in widespread use today in the United States, personally owned records may become more widespread as patients begin sharing data collected by their own loT devices with healthcare providers. These record systems are examined in further detail in the remainder of this subsection.

Electronic Health Record (EHR)

EHRs have achieved widespread adoption within the United States with 84% of hospital [292] and 53.9% of office-based physicians [11 ] adopting a basic EHR.1 Adoption of fully functioning systems with additional features is lower. While the ideal EHR would allow for complete data federation across all healthcare providers, this is far from the case in many current isolated deployments. While there is limited work estimating EHR fragmentation, several studies have explored the extent of incomplete health data in EHR systems [70, 240], which can lead to patient harm such as medication errors [61].

The EHR is a healthcare organization-owned system in which patients have limited ownership of their own data. Although regulation, such as the Health Information Technology for Economic and Clinical Health (HITECH) Act in the United States [66], provides incentive for allowing electronic patient access to EHRs, some data remains unavailable. These restrictions can be beneficial, as direct access to test results has been shown to lead to anxiety and increased rates of patient visits [305]. However, allowing direct patient access has also been linked to increased patient engagement and is highly valued among patients [339, 361].

Although electronic health data is not widely used in research, their use in the clinical decision making process is increasing [167], and patients may be willing to share such data for research purposes [192]. With universal interoperability, the EHR can theoretically enable research leading to significant public-health benefits when fully adopted. For example, data trends can be used to

  • 1 increase accuracy in influenza strain predictions for vaccinations,
  • 2 evaluate treatment effectiveness in specific sub-populations, and
  • 3 identify emerging drug resistance.

However, attempts at EHR interoperability face familiar barriers such as missing data [203]. In scenarios where complete interoperability has not been achieved, the EHR remains a healthcare organization-owned record. This can lead to a lack of efficiency but could also have harmful patient effects, such as redundant imaging [210], as patients visit healthcare providers using different EHR systems. Finally, there is prevailing belief that patients should have a right to accept the consequences to access and manage their own data [361], regardless of the potential risks [305]. This belief is related to the ethical principle of patient autonomy, and accepted practice of informed consent.

Personal Health Record

The PHR is a patient-centered form of medical record in which data is stored on a patient-owned portable device, or cloud service that the patient is able to

!A basic EHR, as defined by DesRoches et al. [110], includes support for patient demographics, patient problem lists, medication lists, clinical notes, prescription order entry, viewing laboratory results, and viewing imaging results.

access. This ensures that a patient's personal medical records are always available to them. When the patient moves from their primary care provider, to an urgent care clinic, to a medical testing facility, they are able to bring their record with them to be populated regardless of the record system used by the practice.

The PHR can also solve many of the data federation concerns associated with EHRs, as the patient is responsible for maintaining a single record which can be accessed by all care providers. Two well-known PHR systems were Google Health [232, 233] (closed in 2011) and Microsoft HealthVault [10] (closed in 2019), both of which originated from the Personal Internetworked Notary and Guardian (PING) or Indivo systems [12, 247, 332]. These PHR systems provided users with a single portal through which they could access their health information by linking with existing EHRs via interoperability standards such as the Continuity of Care Record [132]. Beyond that, these systems provided functionality for fine-grained data sharing as well as integration with personal health devices and health apps [10]. Unfortunately, the universal PHR systems have waned in favor of fragmentation, reminiscent of the current state of EHR [52]. In this fragmented model, users are connected to healthcare provider-owned EHRs as well as siloed commercial PHR systems such as the ones provided by pharmacies or fitness trackers. This fragmentation has occurred in context of a trend toward patient-driven self-care, including quantified self-tracking (e.g., PatientsLikeMe, 23andMe, Fitbit) [350], resulting in many, often datatype-specific, PHR systems. Beyond the inconvenience of maintaining several record systems, the integration of these systems could limit patient harm by decreasing the prevalence of incomplete medical records [70].

However, the tide may be turning back toward a universal PHR system as tools such as Apple Health continue to gain in popularity and achieve high user satisfaction [7, 103, 283]. Apple Health is significantly different from Google Health and Microsoft HealthVault, in that it is a product of the smartphone era with the interface and data localized to an owner's device rather than an Internet portal. The obvious consequence of this is privacy: by retaining health data encrypted locally on a user's device, a user does not need to be as concerned about data misuse or the compromise as with an Internet-hosted portal. However, by hosting the PHR locally on an owner's device, Apple Health is also less able to provide two-way data transport: the app is able to collect data from healthcare providers, rather than currently providing data to providers. While the two-way data transport does not solve the problem of incomplete EHRs, Apple's CareKit [2], a developer framework for applications that allow patients to share health data with healthcare providers is touted as the potential solution. Apple Health utilizes an improved interoperability standard for accessing EHR data from participating healthcare providers [62], which is discussed in detail in Section 9.6.

Bridging Medical Data Ownership: Combining EHR and PHR

Currently, healthcare providers continue to maintain and collect patient data within EHRs, and patients collect personal data within (perhaps fragmented)

PHRs. It therefore follows that EHR-PHR interoperability will be an important step for mHealth and personal loMT data utilization in healthcare. A simplified model of EHR-PHR interoperability that federates data sharing between both healthcare provider and personally owned loMT devices is shown in Figure 9.1.

A simplified model of interoperability between an EHR and PHR system that can be used to integrate personal and enterprise loMT devices

Figure 9.1: A simplified model of interoperability between an EHR and PHR system that can be used to integrate personal and enterprise loMT devices. The PHR hosted locally on a user's smart phone can be replaced with a cloud-hosted PHR without modifying the model.

While this simplified model directly shows only a single EHR and universal PHR, additional EHRs could connect with the universal PHR via the same mechanism. By linking multiple EHR systems through a single universal patient- owned PHR, interoperability of both healthcare provider-owned and personally owned health records can, in effect, be achieved to prevent gaps in medical data. Additional architecture details for enabling health information exchange, such as cloud-hosted PHRs and 5G loMT sensors, are discussed in Section 9.5.

In addition to mitigating EHR silos, combining EHR and PHR systems in this fashion also addresses a significant limitation associated with PHRs. As discussed previously, EHRs provide repositories of aggregated patient data that can be mined for public health and precision medicine research. Unless PHRs are hosted together, the PHR may lack the ability to serve as a research data repository [369]. While many EHR systems share only basic amounts of data, some large EHR networks, such as Epic [6], maintain interoperability between their EHR systems by including medical data that may be derived from loMT devices. The integration of PHRs with these large connected EHR systems can produce data that would allow for public health research. It should be noted that access to care from providers that are part of these EHR network-based data warehouses may be limited for some populations, such as those with unequal access to care. Until universal access to these systems is established, clinical use of this data must therefore account for this skew.

  • [1] Biological Authentication: Other loT devices, especially those that alreadyincorporate biometric sensors, may rely on biological authentication. Somebiological factors that are used for authentication include fingerprints, face,heartbeat, iris, or voice [166]. Similar to proximity-based authenticators,some biological authentication mechanisms, in combination with otherbiological or non-biological factors, can also be used to de-authenticateafter the biological factor changes or is removed. For example, loT fitness
< Prev   CONTENTS   Source   Next >