Enabling IoMT Information Sharing in Healthcare

This section examines the strategies necessary for the federation of loMT data in healthcare. The section starts by focusing on strategies for the health information exchange of traditional medical records. The section then discusses several challenges with federating loMT data via similar mechanisms as well as current solutions, where available.

Collecting Data from IoMT Devices

Logically, the first step in being able to use data from loMT devices is to collect the data generated by the loMT devices and sensors. Since the loMT devices used for support operations in hospitals are entirely enterprise owned, we will focus on loMT devices operating within their 'clinical' use case.

At a high level, the collection of healthcare data from loMT devices, whether the devices are enterprise owned or personally owned, has broad similarities. In both cases, there are two main considerations that need to be addressed for effective data collection. First is managing the enormous amounts of data that loT devices are capable of generating. Decisions need to be made on what data is collected and the frequency of data collection. Several aspects of personalized medicine depend on integrating vast amounts of collected medical data for clinical research. However, this need should be balanced with identifying the important pieces of data since the amount of data collected also directly ties into the network resources required to transmit the data to the cloud or an alternate data storage location. Data thinning techniques should be applied to retain only essential data, so as to help reduce overhead in transport and data processing needs at a later stage. Second, and more important, is security. Personal data transmitted by devices that monitor health must be secure to protect personal privacy.

However, the primary differentiation between enterprise loT devices as opposed to personal healthcare devices and Mobile loT sensors is the user. The average user is not knowledgeable enough to make decisions on the magnitude of determining the collection frequency for personally owned loT devices. Users also tend to be more at-risk for security exploits than enterprises practicing good software hygiene.

Traditional Health Record Information Exchange for Informa tion Federation

Health information exchange is the sharing of patient-level electronic health information for assessment, cost reduction, and quality improvement in healthcare [369]. The HITECH Act mandates a limited level of health information exchange to be eligible for incentive payments in the United States [369]. Traditional information formats for medical record information exchange are discussed in Section 9.6.2. While healthcare provider relationships can enable exchange without significant technological access control requirements, additional considerations must be made when sharing data between patients and healthcare providers. The methodologies for traditional medical record information exchange can vary across emergency and non-emergency situations, and provide insights for the integration of personal loMT and mHealth data into EHR systems [344].

Regulating Provider Access to PHR Data

Multiple fine-grained access control methods for PHR data have been described to provide secure information sharing of health data. Such an approach would allow for patients to have control over which users are able to access specific information contained within the patient's encrypted PHR. In order to enforce such control over their health records, patients would have the authority to generate and provide decryption keys based on the information they wish to provide to the receiving party. This method of access control would enable the secure sharing of PHR data with authorized healthcare providers while protecting the patient's personal data from unauthorized parties. However, many of these fine-grained access control methods result in high overhead costs when applied to scenarios involving multiple users, and thus impacting system usability. A finegrained access control framework for PHR data with reduced overhead has been proposed by Li et al. [220]. This approach involves users generating their own sets of attribute-based encryption (ABE) keys. To account for the linearity of ABE encryption, the system is divided into multiple domains which are associated with various user subsets.

Providing Emergency Data Access

Although access control of medical records can be achieved through the previously discussed methods, in the case of required emergency access to data contained within the PHR and EHR, personal health data may become available without prior authorization. Currently, emergency data access to protected records within a single EMR system often follows a "break the glass" procedure. This procedure involves a healthcare provider self-granting access to a patient's medical record and protected health information (PHI) that can be utilized in the event of an emergency. Each instantiation of the "break the glass" procedure is documented and is later audited and reviewed to ensure that the patient's medical record and PHI were accessed under justifiable circumstances. Because an auditing, review, and accountability process exists under the "break the glass" procedure, it is not clear how this approach can be implemented for the sharing of health records across organizations using separate EMR systems or for granting access to PHRs in the case of emergencies.

The current practice of utilizing the "break the glass" procedure in emergency circumstances presents the risk for providing unnecessary access to patient information. One method of differentiating between users who should be granted emergency access to patient data and users who should be denied access integrates both Role Based Access Control (RBAC) and Experience Based Access Management (EBAM) strategies [398]. In order to test the effectiveness of this approach, the resulting algorithm, "Roll-Up", was applied to log data collected from Northwestern Memorial Hospital Center. Results from this case study indicate that a combination of RBAC and EBAM strategies is able to predict the conceptual position of a user requesting access to a patient's EMR data with 82.3% accuracy [398].

In the case of Li et al.'s proposed fine-grained access control framework, the issue of handling the security risks associated with providing data access during an emergency is handled using decryption keys [220]. This trapdoor method involves the patient selecting which parts of their PHR data they wish to be accessible in advance of a health emergency. The patient is able to delegate access of this data to the emergency department by providing a decryption key for each part of the pre-selected PHR data. These decryption keys would be stored within the emergency department's database of patient information. If an emergency occurs, a staff member would be able to query the database and obtain the patient's decryption keys from the emergency department. Once the patient's medical condition has returned to normal, the patient's PHR system could then compute re-keys for their PHR data and submit this update to the emergency department for future use. Although naturally supported by the framework proposed by Li et al., it remains unclear if this "break the glass" method would be able to scale and work across multiple hospital locations, given that the patient must be able to provide decryption keys to a particular emergency department in advance of any emergency incident. In order for this emergency data access method to be used across hospitals, the decryption keys provided by the patient would have to be stored in a centralized database, causing a host of other security and scalability issues.

Digital Rights Management (DRM) schemes can also be considered as a way to secure PHR and EHR data from unauthorized insider access. Kunzi et al. propose a data-centric model for the protection of health records in which encrypted health data is able to be accessed in an emergency with use of an emergency license [194]. Under such circumstances, an emergency key is issued in order to decrypt the patient's health data. Similar to the "breaking the glass" protocol, emergency access is documented and audited to ensure appropriate record access. However, in order to prevent against system compromise, a compromised emergency key will have a limited effect on the system. Additionally, the system design of this approach also ensures the dependability of the system while operating offline.

Ensuring Data Integrity from IoMT Sensors

Unlike traditional EHR-integrated sensors, the collection of data from mHealth and loMT devices involves connections to large numbers of devices outside of the control of the healthcare organization. These devices may integrate via local gateways, connect directly to the EHR, or connect to cloud-hosted data warehouses. Regardless of the connection mechanism, the data collected from these devices will integrate with a health record system (likely an EHR or PHR). With potentially numerous connected devices, it is important to maintain a device inventory and validate that unaltered sensor data is being transmitted and received.

A simple mechanism to mitigate integrity risks for direct sensor device transmissions would be to utilize cryptographic encryption and signing, with validation performed based on public keys stored within a centralized device inventory. In this model, an mHealth or loMT device would periodically be registered with the health record system, in which the device generates a key pair and shares the public key with the system's sensor device inventory. The mHealth or loMT sensor would also receive a public key to encrypt the data sent to the health record system. The sensor could then encrypt and sign traffic to the health record system, which could be decrypted and then validated. The health record system would then tag the data source for each piece of received data. This method would help to ensure only data from valid, inventoried sensors is shared with the health record system, and provide a basic method for tracking the sources of received sensor data.

Privately Replicating and Sharing Large Datasets

In the EHR-PHR interoperability mechanism discussed previously, data is replicated and stored across numerous health record systems. As collected data sources become larger, such as when dealing with genome sequences, replicating data in its entirety across several cloud systems becomes impractical. A more efficient solution would be for record systems to use a "link" to a single instance of the data. The record systems which do not store the data in its entirety could initially download the data and compute any summary statistics necessary to store locally, before deleting the data. These calculated summary statistics might be used directly by the organization, such as common single nucleotide polymorphisms (or SNPs) from genomic data, or the number of steps traveled from motion data. Future calculations or analysis could be performed by simply downloading the file from the "link" again, or utilizing an application programming interface (API) provided by the file host.

This solution for enabling the sharing of large datasets does not address the ownership of the large file that is linked to by other sources. Naively, it could be proposed that the owner of the connected device that provides the data must also host these files. For example, if a patient received a genetic test from 23andMe, then 23andMe would be responsible for hosting the results indefinitely. While it is clear how this would work with tests from 23andMe or imaging from a healthcare provider, certain other scenarios aren't quite so straightforward. For example, how would motion data from personally owned devices be stored? What would happen if the company hosting the data went out of business? Would a user be responsible for paying to host their own data in order to receive the best care? Furthermore, when a single entity is responsible for hosting a data file, ensuring redundancy and availability can be prohibitively expensive.

An alternate solution is for these data files to be hosted using a consensus mechanism, in which small pieces of data are stored in a distributed fashion across several source hosts. These data pieces can be stored redundantly and in fault-tolerant fashion, such that if a single data host becomes unavailable, its shards would remain available from other hosts [59]. As a single file is replicated across additional sources, these sources would individually need to store less of the overall data. These data hosts can include EHR providers, commercial data providers or device manufacturers (e.g., 23andMe or Fitbit), and user-owned cloud storage that may be reimbursed by insurance providers or governments. Some published mechanisms for achieving this distributed data storage method would be suitable for this application in healthcare. The Security-Aware Efficient Distributed Storage (SA-EDS) model proposed by Li et al. requires data packets to be retrieved from a set of cloud storage providers before yielding the original data [219]. Similarly, Shafagh et al. propose a blockchain-based mechanism for secure distributed storage and sharing of time series data [325] that can also be modified to include genomic or other large non-time series data.

Maintaining Consensus in Large Scale Federated Systems

Not all loMT data is large enough to require efficient distributed storage. For smaller data sets that can be replicated across several medical records, there is an opportunity for maintaining consensus. Today, much of this burden falls on the patient. For example, although vaccination records are shared between healthcare providers, it is likely to be the patient who would catch a healthcare provider mistakenly administering a vaccination that they have already received. Often, these small mistakes may go unchecked, but, when caught, may lead to changes in treatment. For example, in a 2004 study of a computerized medication reconciliation tool, physicians changed the discharge orders for 94% of patients when discrepancies were identified by nursing staff [308].

Traditional software-only consensus solutions are inadequate in such situations as patients may report or present different information to different providers. For example, a patient might not take a medication prescribed by one physician and might not report (intentionally or unintentionally) taking the medication to another. In situations such as these, having the medical records retain a history of change would be a welcome feature. This would allow medication reconciliation software to automatically detect the discrepancy and allow healthcare providers to clarify information with the patient to update the record, which will retain the complete history of the reconciliation.

In medical records, retaining complete history is a necessary step for medical record reliability as allowing for the free deletion of medical records can allow patients to significantly affect the behavior of healthcare providers [381]. To ensure record reliability, changes to medical record values should not be allowed in EHR systems. In patient-controlled PHR systems, updated records should be assigned a new identifier such that they are shared with EHR systems as a new value. While some laws may locally require that patients are able to delete medical data stored in EHR systems [381 ], these deletions do not need to propagate-thus requiring patients to request their records be deleted across all EHR providers. This limitation would help prevent against the compromise of medical records within a large-scale federated health record system.

Providing Emergency Access to Real Time IoMT Data

The collection and access of real-time loMT data currently presents a potential challenge in the event of an emergency. loMT devices are able to collect a variety of health data from users, including biometric data such as a user's heart rate, physical activity, and sleep cycle. Due to the high sampling rates of loMT health monitoring services and applications, personal health monitoring devices have the ability to produce large sets of health data for each user. In the case that emergency access to this data is required for medical treatment, the volume of available patient data could result in finding the discernible 'signal' within this big data noise to be a challenging problem requiring the retrieval, sorting, and selection of relevant data.

Among these challenges is the issue of ensuring that the real-time data retrieved by the emergency department is the most up-to-date data collected from the patient's loMT device. Currently, these devices may not sync to provide updates to a patient's EHR on a timely basis. Thus, the loMT data retrieved under emergency circumstances may not be an accurate representation of the patient's current (or near-current) state of health. In order to obtain access to the patient's real-time loMT data, the Emergency Department would likely have to be able to physically access the patient's personal loMT collection device. This alternative access method may not be feasible in emergency situations as it relies on the assumption that a patient is conscious and able to give consent to allow for the emergency department to access to their loMT device. Even if consent for emergency access to a personal device is granted, such access poses the risk of creating additional patient privacy concerns.

A potential path forward is for loMT devices to enhance data availability by having the user select an interval where the device would update the user's realtime health data and offer a selected subset to emergency departments. This data update interval could include a range of data transfer periods for user selection. For example, when initially setting up their loMT device, a user could decide to have their loMT device automatically send their collected data to a selected emergency department(s) in hourly, daily, or weekly intervals. The emergency departments could then choose the interval in which previously received, and now out-of-date, data is discarded.