Protecting Electronic Health Records in Transit and at Rest

Abstract:

Healthcare providers need to communicate and exchange the clinical and administrative data from Electronic Health Records of patients. The Health Insurance Portability and Accountability Act (HIPAA) of 1996 requires the safeguarding and protection of Electronic Health Records when in transit and in storage. This paper presents a solution to protect Electronic Health Records in both states, in transit and at rest. Our secure data container guarantees data confidentiality and integrity and supports different data formats, including text and images. It can work in environments with limited Internet connectivity, which is important at times of disease pandemics or natural disasters. The potential benefit of this solution for healthcare providers would allow emailing data to patients in the form of our data container without using a HIPAA-compliant email server. This technology supports the ability to send and receive medical record documents, for a single encounter or encounters related to a condition, (1) allowing patient to download and keep their personal health record; (2) sharing continuity of care information with a provider referral to ensure medication reconciliation, for instance, with providers who are outside the information exchange network; and (3) delivering medical records securely to an insurance company who requires notes for a submitted claim. To address the problem of clinical and administrative data exchange between different healthcare providers across multiple networks, states and countries, our methodology allows patients to download and store their Electronic Health Records locally.

SECTION I.

Introduction

Health Insurance Portability and Accountability Act of 1996 (HIPAA) requires that Personal Health Information (PHI) must remain private at all times. However, cybersecurity vulnerabilities still pose a serious threat to PHI privacy. In February 2015, “Anthem, Inc. disclosed that criminal hackers had broken into its servers,” [1] potentially affecting the exposure of 78.8 million patient's PHI [2].

Our solution protects Electronic Health Records (EHRs), while storing and transferring them. An EHR is stored in a Protected Spreadsheet Container with Data (PROSPECD), which incorporates watermarked clinical and administrative data and access control policies in encrypted form. Our approach supports role-based and attribute-based access control and allows patients to download and keep their personal health records in a protected HIPAA-compliant form. Patients can also access their health records locally. Furthermore, PROSPECD can be used by healthcare providers instead of faxes to email patients their clinical data in a protected form via non-HIPAA compliant email services.

The rest of the paper is organized as follows: Section II presents an overview of the related work, in Section III the core design is presented, experimental results are discussed in Section IV, and Section V concludes the paper.

SECTION II.

Related Work

Currently, in approaches for facilitating the communication between clinicians, researchers, and hospitalists, EHRs rely on the Continuity of Care Document (CCD) or Continuity of Care Record (CCR) standard for information exchange. EHRs sold by the private sector employ data exchanges using the CCD/CCR standard within a network. If a participating vendor is not within the same information exchange network (i.e., DirectTrust® [9]), then sharing CCD/CCR is only possible through fax transmission, often using the registry at a Health Information Exchange (HIE) [3]–​[5].

A major spending thrust of the US government on information technology for healthcare is the use of application-based information to further the capability of EHRs. Apple®1 released the HealthKit® [6] framework that centralizes storage and enables sharing of data from both health and fitness applications. Moreover, it allows patients to compile medical data on a local device. The vision is that the information provided from these healthcare applications could be added or deleted from an EHR such that the end-user can draw the information, and is especially of value for the push into precision medicine and new visualizations for understanding population health extents [7]. Even so, certain information such as PDFs and radiological images [7], [8] are not accessible. Furthermore, patients agree to waive certain protections, leaving their health information unencrypted on these personal devices. PROSPECD stores data in encrypted form in transit and at rest, and is operating system-agnostic. It supports different data formats, including texts and images.

DirectTrust® [9] is a non-profit organization that allows healthcare vendors to use their network for the secure sharing and exchange of messages and attachments containing PHI. Our approach to protect data does not require a central authority for PHI decryption and for policy enforcement. Decryption keys are generated on-the-fly.

Research Electronic Data Capture (REDCap®) is a HIPAA-compliant web-based application developed by Vanderbilt University in 2004 that “captures data for clinical research and create databases and projects” [10]. This application uses web forms and surveys as data capture tools. Our approach supports data input in various forms, such as input from spreadsheet editors or from automated scripts. Furthermore, our solution does not need a Trusted Third Party (TTP) for policy enforcement.

Storing encrypted data together with access control policies in the same container is similar to a concept of a privacy-preserving data dissemination, presented in [14]. Our solution, however, can detect several types of data leakages that can be made by authorized insiders to unauthorized parties. Additionally, PROSPECD is digitally signed. The signature and data origin are verified each time when the data request arrives to PROSPECD. The substantial difference between a PROSPECD and an Active Bundle [11]–​[13], [15] concept is that PROSPECD does not store a policy enforcement engine together with data and metadata. Access control policies can be enforced on a TTP, or locally on a client's host, in a trusted standalone application, or in a Microsoft®2 Excel Add-in. Data container proposed in [18], in contrast with our solution, only supports centralized policy enforcement on a TTP and does not verify the data origin.

Tun and Mya in [25] proposed a solution to encrypt/decrypt the desired cells in a spreadsheet file, protecting integrity with a hash value of its content. In contrast, in a PROSPECD all data worksheets are encrypted with the on-the-fly generated separate keys, providing a fine-grained role-based and attribute-based access control. A PROSPECD contains the access control policies, in encrypted form, is digitally signed and supports detection of several types of data leakages.

SECTION III.

Core Design

A. Protected Spreadsheet Container with Data (Prospecd)

PROSPECD is a data container that incorporates encrypted watermarked data and access control policies in encrypted form. PROSPECD is implemented as a digitally signed spreadsheet file with encrypted data worksheets, one separate worksheet per data subset, and one encrypted worksheet with access control policies and metadata. PROSPECD is used to store EHR, one PROSPECD per patient. It is similar to the SDC container proposed in [18], but supports a local policy enforcement, data origin verification and a more secure communication between a client and an Authentication Server (AS) with using X.509 certificates for identity management. Each separate data worksheet “is encrypted with a separate 256-bit AES key, generated on-the-fly, based on hash values of the following inputs” [18]:

• Metadata worksheet, including access control policies.

• AS's private key (AS PrivKey). Only an authorized web service can get this information from the AS after AS verifies the service's X.509 certificate and identity.

• Worksheet's name.

PROSPECD generator operates on a trusted site and encrypts the metadata worksheet first with a key derived as follows: SHA-256(SHA-256(AS PrivKey) ∥ SHA-256(AS PrivKey)) The generator takes a plaintext spreadsheet file and creates a spreadsheet file with encrypted data worksheets, following the AES key derivation scheme, described above.

PROSPECD supports two options for the policy enforcement engine location:

• Trusted back-end server (Node.js®3 server) - see Fig. 1.

  

  Fig. 1:

  TTP-based EHR management system architecture

  Show All

• Microsoft® Excel Add-in or a standalone application, installed on a client's host. Details are discussed in the subsection “Decentralized EHR Access”.

A mechanism to enforce policies on a trusted back-end server (or on TTP) is similar to the one for the Secure Data Container (SDC), described in [18]. To make a data request, a client must first access the server, running at www.smpad.net:3000. and provide credentials that are validated by the AS. For valid credentials, AS redirects the client's request over an HTTPS communication channel to the unique URL for a web service, corresponding to client's role, that runs as a back-end service. Same as in [18], this unique URL includes an encrypted and RSA-signed Authentication Token (AT). The AT contains client's attributes, token expiration time and a hash value of AS's private key. “Back-end server extracts AT from the request, verifies the signature, and extracts the AT fields for policies, attributes and metadata evaluation.” [18]. As a result, the server derives symmetric keys for the accessible data worksheets, decrypts them and responds to the client. To derive the correct decryption key, the input hash values must be the same as those used for encryption key generation.

B. Decentralized Ehr Access

We have created an application-based solution that provides role-based access control in the form of an encrypted Microsoft® Excel file accompanied with an Add-in written in C#®. In order to download an EHR file, a user must first access the server, running at www.smpad.net:3000. and provide valid credentials. User also needs to download and install the Microsoft® Excel Add-in. Once the EHR file is opened locally, the user must navigate to the Add-in tab and activate the “EHR Decrypt” button. The Add-in verifies the digital signature [24] of the spreadsheet file to ensure it is an appropriate EHR. Once the user is authenticated in the Add-in, keys are generated to decrypt the accessible worksheets in the EHR file. If this is the first time the Add-in has been used, an HTTPS request is sent to an AS to retrieve the hash value of its private key, which is needed to generate the right decryption key. Then, the hash is stored in an encrypted configuration file for future use. This enables decentralized access to EHR, which is essential for limited Internet connectivity environments. Each user within a given role is only allowed to see the data worksheets that they are allowed to access, based on access control policies evaluation made by the Add-in. Access control policies are identical to those on the trusted back-end server and are illustrated on Fig. 2. The Add-in also disallows file saving during operation. This helps to prevent data leakage.

For users without access to Microsoft® Excel, we developed a cross-platform standalone application that performs the same actions as the Add-in and allows to view encrypted spreadsheet files in a Read-Only mode. This application, written purely in C++, Iso/iec 14882:2017(e), and can be compiled to run on Windows®, MacOS®, and Debian-based Linux®4 distributions.

Fig. 2:

Access control policies for data worksheets

Show All

Our approach guarantees that data worksheets from PROSPECD can only be accessed by authorized clients, based on their role and attributes that include versions of an operating system and a web browser, as well as authentication method and type of the client's device. PROSPECD is compatible with the Microsoft® Excel and supports RESTful API. System workflow diagram is illustrated on Fig. 3.

Fig. 3:

Workflow diagram

Show All

To address the issue of data leakages and unauthorized data distribution, PROSPECD contains visual and digital watermarks. Visual watermarks include background text on the data worksheets and on web pages for a client's session. Visual watermarks have been used in law to prove data ownership. Digital watermarks include watermarks embedded into EHR data images by means of a pixel transformation function [26]. Our watermark classifier checks whether the image, included in a PROSPECD, is watermarked. A web crawler scans public directories in the network to check whether the discovered EHR image is supposed to be where it is found. Same as in [26], X.509 certificates are used for identity management. Similarly to [18], digital watermarks also include a special string recorded in a “Metadata” worksheet. Removing this string would make a PROSPECD data unreadable since modifying a metadata makes the derivation of the right decryption key infeasible.

SECTION IV.

Evaluation

To evaluate the performance overhead, we collected data request Round-Trip Time (RTT) by measuring the time starting from a web service's data request to PROSPECD and ending with the receipt of the response from PROSPECD. RTT is the sum of times spent for authentication, evaluation of access control policies and the client's attributes, decryption key derivation, data decrytion and retrieval. The ApacheBench®5 utility (version 2.4) was used for RTT measurements. We measured RTT as an average of 1000 data requests, ranging the amount of requested data, from 0.5 to 421.1 kilobytes, and the number of concurrent threads requesting data, from 1 to 100. Data belong to a “synthetic patient” and are not real. Similarly to [18], a web service (client) requesting data, an AS, and the PROSPECD are located on the same host to exclude network delays from RTT measurements. Below is the description of a system configuration where experiments were run:

CPU: Intel®6 Xeon 1241-v3 @ 3.9 GHz; RAM: 32GB DDR3 @ 2400 MHz; Network Interface: Intel® 1000Base-T; OS. Microsoft® Windows® 10 Pro, 64 Bit Web Framework: Node.js®, ver. 10.16.3

Fig. 4:

Prospecd data request round-trip time

Show All

Having N concurrent threads in ApacheBench® makes N requests open in a single experiment with 1000 total requests. “Node.js® is a single threaded language which in background uses multiple threads to execute asynchronous code.” [23]. Due to these features of ApacheBench® and Node.js® server, as it can be seen in Fig. 4, the average RTT for 10 or 100 concurrent threads is smaller than for one thread. As a baseline experiment, the same amount of data is retrieved, using one thread, from an encrypted JavaScript Object Notation (JSON) file instead of a PROSPECD, where Excel® data are decompressed to XML first and then to JSON. RTT includes the evaluation of access control policies and data decryption (the key is pre-defined and not derived on-the-fly). PROSPECD implementation adds 10% performance overhead for retrieving 421.1 kilobytes of data and 380% performance overhead for retrieving 0.5 kilobytes, but it offers an extra-protection layer (on-the-fly key generation), attribute-based access control and stores data as a spreadsheet file.

SECTION V.

Conclusions

This paper presented a HIPAA-compliant solution to store and transfer an EHR as a Protected Spreadsheet Container with Data (PROSPECD). PROSPECD provides confidentiality and integrity of clinical and administrative data. Our approach protects data in transit and at rest and works in environments with limited Internet connectivity, which is important at times of disease pandemics or natural disasters. The solution allows patients to download their encrypted EHRs and access them locally. Healthcare providers can use PROSPECD instead of faxes to email patients their clinical data in a protected form via non-HIPAA compliant email services.

ACKNOWLEDGMENT

We thank Yuliya Durova, Aleks Malkhasov, and Braxton Westbrook for their help with the project implementation.