This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Journal of Medical Internet Research, is properly cited. The complete bibliographic information, a link to the original publication on http://www.jmir.org/, as well as this copyright and license information must be included.
Blockchain has the potential to disrupt the current modes of patient data access, accumulation, contribution, exchange, and control. Using interoperability standards, smart contracts, and cryptographic identities, patients can securely exchange data with providers and regulate access. The resulting comprehensive, longitudinal medical records can significantly improve the cost and quality of patient care for individuals and populations alike.
This work presents HealthChain, a novel patient-centered blockchain framework. The intent is to bolster patient engagement, data curation, and regulated dissemination of accumulated information in a secure, interoperable environment. A mixed-block blockchain is proposed to support immutable logging and redactable patient blocks. Patient data are generated and exchanged through Health Level-7 Fast Healthcare Interoperability Resources, allowing seamless transfer with compliant systems. In addition, patients receive cryptographic identities in the form of public and private key pairs. Public keys are stored in the blockchain and are suitable for securing and verifying transactions. Furthermore, the envisaged system uses proxy re-encryption (PRE) to share information through revocable, smart contracts, ensuring the preservation of privacy and confidentiality. Finally, several PRE improvements are offered to enhance performance and security.
The framework was formulated to address key barriers to blockchain adoption in health care, namely, information security, interoperability, data integrity, identity validation, and scalability. It supports 16 configurations through the manipulation of 4 modes. An open-source, proof-of-concept tool was developed to evaluate the performance of the novel patient block components and system configurations. To demonstrate the utility of the proposed framework and evaluate resource consumption, extensive testing was performed on each of the 16 configurations over a variety of scenarios involving a variable number of existing and imported records.
The results indicate several clear high-performing, low-bandwidth configurations, although they are not the strongest cryptographically. Of the strongest models, one’s anticipated cumulative record size is shown to influence the selection. Although the most efficient algorithm is ultimately user specific, Advanced Encryption Standard–encrypted data with static keys, incremental server storage, and no additional server-side encryption are the fastest and least bandwidth intensive, whereas proxy re-encrypted data with dynamic keys, incremental server storage, and additional server-side encryption are the best performing of the strongest configurations.
Blockchain is a potent and viable technology for patient-centered access to and exchange of health information. By integrating a structured, interoperable design with patient-accumulated and generated data shared through smart contracts into a universally accessible blockchain, HealthChain presents patients and providers with access to consistent and comprehensive medical records. Challenges addressed include data security, interoperability, block storage, and patient-administered data access, with several configurations emerging for further consideration regarding speed and security.
Health care is a data-intensive domain with vast amounts of information generated, accessed, and disseminated daily. Unfortunately, patient records are typically isolated in institution-centric
Traditional health information exchange follows 1 of the following 3 models:
Blockchains are distributed and decentralized repositories of information secured by various cryptographic primitives. Ideally, participants (eg, patients, providers, and payers) upload data to the chain in a secure, authenticated fashion. The result is a comprehensive medical record accessible by those with patient permission as enforced by smart contracts. As participants only need to communicate with the blockchain using recognized interoperability standards (eg, FHIR), once trust is established, all information is securely exchanged. That is, instead of having multiple points of connection, document formats, and exchange protocols to follow (each a security risk and potentially costly to address), a universally accessible blockchain minimizes the overall risk to the participating entity while simultaneously enriching information exchange and patient engagement.
More specifically, deploying blockchain in health care is suggested to break down information exchange barriers inherent in disparate, siloed EHR systems; empower patients through data consolidation and access controls and enabling (eg, secure and verifiable authorizations, form completion, discharge instruction review, and patient-generated data contribution); improve quality of care while reducing costs and fraud; promote data integrity, validation, and provenance; track medical devices and pharmaceuticals; facilitate clinical trial accountability and auditability; and support research through access to large-scale, longitudinal, aggregated patient records [
Herein, we submit technical solutions to address these concerns, culminating in a detailed framework and open-source proof-of-concept tool—
Heralded as a disruptive technology, blockchain research has intensified in recent years. Researchers and developers in health care have proposed, conceptualized, and implemented blockchain-based platforms to transform patient data sharing and information interoperability.
OmniPHR is a patient-centered blockchain emphasizing the distributed and interoperable principles of
Beyond patient-centric applications, other blockchain solutions have been presented in a health care setting including supply chain management [
A
Each block is identified by a
Point 1 seeks to prevent
Block schematic with sample financial data and hashes.
Blockchain diagram with several blocks, including the foundational genesis block, and noted hash connections.
Before Ateniese et al’s
Smart contracts, popularized by cryptocurrencies such as Bitcoin and Ethereum, have many practical applications in health care. Patients, for instance, can provide authorization through smart contracts to participate in studies or share information. They can codify rules leading to patient notification, for example, data accessed or communication received. They can also be used as a form of context-based access control, stipulating access rights to covered entities, business associates, and subcontractors [
PRE enables the
Most PRE schemes use
Proxy re-encryption process overview.
Herein, an overview of the HealthChain framework is presented in
As a patient-centric framework, HealthChain presents patients with a holistic view of their medical record, restoring agency through interaction. It encourages the accumulation, modification, generation, and review of information; ensures data integrity; authenticates identities; promotes unambiguous exchange; and executes user-granted access rights through smart contracts. Thus, HealthChain does not suffer from the common ailments plaguing PHR adoption such as data security and validity concerns, interoperability challenges, trust, and technological barriers to adoption [
HealthChain is defined as a
Patient centered
Permissioned blockchain: nodes and users
Interoperability: nationally recognized interoperability standards
Mixed-block blockchain: log and patient blocks
Smart contracts: permissioned interoperability
Health Insurance Portability and Accountability Act of 1996 and HealthChain: legal requirements and supporting components
Patient-managed health information systems must conform to nationally recognized interoperability standards to be successful [
Although not yet federally required, HL7 FHIR is, according to the 2019 Interoperability Standards Advisory by ONC, under consideration for 26 interoperability needs [
The proposed blockchain integrates 2 semantically distinct block types:
Mixed-block blockchain adaptation of
Log blocks are an immutable, historical account of operations on the blockchain, such as added patients and blocks, patient block modification metadata, and the issuance and execution of smart contracts. Hence, traditional hashing algorithms (eg, Secure Hash Algorithm [SHA]-256) suffice. In addition, as the data are not sensitive (ie, contain no identifying information), encryption is unnecessary. Thus, log blocks are added to the blockchain following contemporary means (eg, through consensus).
Structurally, patient blocks consist of plaintext metadata (eg, unique identifier, type flag, patient’s anonymous identifier, timestamp, hash, and the issuing miner’s identifier and signature), encrypted patient data, and smart contracts. Principally, they adhere to Ateniese et al’s redaction scheme [
When a patient requests an account, an authorized node prepares a block and submits it through a selected consensus method for inclusion. This represents the only instance of consensus in the patient block process (
Redaction addresses 3 shortcomings of immutable blocks and patient transaction isolation. The first is data fragmentation. Immutable blockchains insert new transactions in contemporaneous blocks, splintering medical records, which are collections of temporal events, rather than isolated, for example, financial, transactions (
Patient account (ie, block) establishment, redaction, and logging processes in HealthChain.
Initial and subsequent patient data entry in a traditional blockchain.
Information retrieval in an immutable blockchain versus HealthChain.
Once appended to the blockchain, a block’s hash cannot change; otherwise, the chain breaks. Redaction, therefore, precludes traditional hash functions (eg, SHA-256) as, by definition, different inputs produce distinct hashes. Hence, the deployment of chameleon hashing.
Ateniese et al [
Classified as
Traditional symmetric (eg, AES) and asymmetric (eg, ECC) primitives are insufficient as they compel 1 of the 3 insecure or infeasible information exchange solutions [
PRE facilitates information exchange through dedicated third parties without exposing sensitive information. Beyond proposing PRE, we identified 4 operations critical to securing and validating stored and exchanged data in the proposed framework: (1) encryption and decryption, (2) re-encryption, (3) sign and verify (eg, digital signatures), and (4) encrypt sign and decrypt-verify (eg, encrypted sign and verify).
Operations 1 and 2 are instrumental in securing and sharing sensitive information and are the foundation of any PRE scheme. Operation 3 facilitates message authentication and data integrity. A message
Moreover, some PRE-derived ciphertexts (eg,
PRE is traditionally deployed for key exchange [
EC PRE is slower and larger than AES because of key and
A comparison of Advanced Encryption Standard encrypted blocks with proxy re-encryption encrypted keys to proxy re-encryption encrypted blocks.
Property | AESa block encryption | PREb block encryption |
Encrypt and decrypt speed | Faster | Slower |
Size of ciphertext | Smaller | Larger |
Key operations | Decrypt and encrypt | Decrypt only |
Rekeying ciphers | Decrypt then encrypt | Multiplication |
aAES: Advanced Encryption Standard.
bPRE: proxy re-encryption.
Smart contracts herein enable conditional information exchange. Their mutability (from patient block storage) permits modification and revocation without duplicate, conflicting, or vulnerable contracts remaining on the blockchain. During instantiation, a template is automatically populated (once authorization is furnished); no programming is necessary. On execution, an engine hardcoded into the server platform applies a series of instructions, given a contract’s parameters. There are several reasons for this approach. The proposed smart contracts are structurally uniform (eg, identifiers and signatures of involved parties, terms, and re-encryption keys), eliminating the need for arbitrary code support. Furthermore, logical errors [
Although granting access with PRE is simple, revoking it is not. Consider the following, 2 parties enter into a 1-week smart contract. If the delegatee notes the re-encryption key during valid execution, nothing explicitly prevents it from decrypting the delegator’s block after contract termination.
A naïve refinement to close this vulnerability is implementing PRE as originally defined—proxies decrypt delegator data, then encrypt for delegatees [
To address revocation, we submit 2PD (
Smart contract initiation using standard proxy re-encryption.
Smart contract execution using standard proxy re-encryption. FHIR: Fast Healthcare Interoperability Resources.
Smart contract initiation using 2-party proxy re-encryption decryption.
Smart contract execution using 2-party proxy re-encryption decryption. FHIR: Fast Healthcare Interoperability Resources; PRE: proxy re-encryption.
There are several additional 2PD factors to consider. First, it demands an intermediary be
Administrative rule 45 CFR section 164.524 grants patients the right to request copies of their records, which are to be delivered
Systems in this space must be HIPAA compliant.
Health Insurance Portability and Accountability Act of 1996 administrative rule specifications (privacy rule and security rule) and submitted HealthChain components supporting compliance.
Specification | Rule: 45 CFRa section 164 | HealthChain |
Authorization and revocation (PRb) | 508, 510 | Smart contracts, sign and verify, and encrypt-sign and decrypt-verify: confidential communications and verifiable requests and authorizations |
Restriction requests (PR) | 522(a)(1) | Smart contracts, sign and verify, and encrypt-sign and decrypt-verify: confidential communications and verifiable requests and authorizations |
Amendments (PR) | 526 | Smart contracts, sign and verify, and encrypt-sign and decrypt-verify: confidential communications and verifiable requests and authorizations |
Confidential communications (PR) | 522(b)(2) | Encrypt-sign and decrypt-verify: message integrity, verifiable identity, and encryption |
Unique user authentication (SRc) | 312(a)(2)(i) | Unique encryption and hashing key pairs, sign and verify, and encrypt-sign and decrypt-verify: verifiable identity (key possession and signing) and patient block hashes and patient block encryption |
Encryption and decryption (SR) | 312(a)(2)(iv) | Unique encryption and hashing key pairs, sign and verify, and encrypt-sign and decrypt-verify: verifiable identity (key possession and signing) and patient block hashes and patient block encryption |
Integrity (SR) | 312(c)(1) | Unique encryption and hashing key pairs, sign and verify, and encrypt-sign and decrypt-verify: verifiable identity (key possession and signing) and patient block hashes and patient block encryption |
Audit controls (SR) | 312(b) | Log blocks |
Person or entity authentication (SR) | 312(d) | Sign and verify, encrypt-sign and decrypt-verify, re-encryption key layering, and delegatee re-encryption: verifiable identity (verification algorithms and construction of the delegatee re-encryption process) |
Transmission security—integrity controls and encryption (SR) | 312(e)(1), (2)(i), and (2)(ii) | Patient block encryption, intermediary re-encryption, sign and verify, and encrypt-sign and decrypt-verify (layering): verifiable identity and transfer of encrypted data only by design |
aCFR: 45: Code of Federal Regulations.
bPR: privacy rule.
cSR: security rule.
The experimental design facilitates the examination of HealthChain’s novel components. Additional services such as permissioning and consensus along with a comprehensive distributed network were not evaluated for the following reasons. First, although essential to the framework’s practical implementation (whereas here we are exploring new functionality), no improvements to those areas were proposed in this work; hence, testing is unwarranted. Second, ancillary services and an arbitrarily sized experimental network inject considerable overhead (potentially orders of magnitude above the measured item) into the process, rending the subject of analysis indistinguishable from noise. As such, we intentionally limited the components implemented in the proof of concept to only those necessary to successfully evaluate the processes defined in the subsequent sections.
Regarding experimental block operations, recall that as patient blocks are generated during account initialization, all subsequent actions necessitate redactions to said block section Patient Blocks). Therefore, all experiments conducted herein are redactions.
HealthChain operations are dictated by 4 configurable modes (see
The second is the
Comparison of full block and incremental storage mode options.
Property | Full block | Incremental |
Transactions | 1 | 1 or more |
Cipher padding | Negligible | Potentially considerable |
Record isolation | No | Yes |
Speed of transmission | Slow | Potentially fast |
Size of transmission | Large | Potentially small |
Third is
Advanced Encryption Standard (AES) configurable experimental mode abbreviations and descriptions.
Mode | Description |
AF | AES-encrypted data, full block storage |
AI | AES-encrypted data, incremental storage |
ADF | AES-encrypted data, dynamic encryption key full block storage |
ADI | AES-encrypted data, dynamic encryption key incremental storage |
ASF | AES-encrypted data, static encryption key full block storage |
ASI | AES-encrypted data, static encryption key incremental storage |
AFN | AES-encrypted data, full block storage no server-side encryption |
AFY | AES-encrypted data, full block storage server-side encryption |
AIN | AES-encrypted data, incremental storage no server-side encryption |
AIY | AES-encrypted data, incremental storage server-side encryption |
ADFN | AES-encrypted data, dynamic encryption key, full block storage, no server-side encryption |
ADFY | AES-encrypted data, dynamic encryption key, full block storage, server-side encryption |
ADIN | AES-encrypted data, dynamic encryption key, incremental storage, no server-side encryption |
ADIY | AES-encrypted data, dynamic encryption key, incremental storage, server-side encryption |
ASFN | AES-encrypted data, static encryption key, full block storage, no server-side encryption |
ASFY | AES-encrypted data, static encryption key, full block storage, server-side encryption |
ASIN | AES-encrypted data, static encryption key, incremental storage, no server-side encryption |
ASIY | AES-encrypted data, static encryption key, incremental storage, server-side encryption |
Proxy re-encryption (PRE) configurable experimental mode abbreviations and descriptions.
Mode | Description |
PF | PRE-encrypted data, full block storage |
PI | PRE-encrypted data, incremental storage |
PRE-encrypted data, dynamic encryption key full block storage | |
PDI | PRE-encrypted data dynamic encryption key incremental storage |
PSF | PRE-encrypted data, static encryption key full block storage |
PSI | PRE-encrypted data, static encryption key incremental storage |
PFN | PRE-encrypted data, full block storage no server-side encryption |
PFY | PRE-encrypted data, full block storage server-side encryption |
PIN | PRE-encrypted data, incremental storage no server-side encryption |
PIY | PRE-encrypted data, incremental storage server-side encryption |
PDFN | PRE-encrypted data, dynamic encryption key, full block storage, no server-side encryption |
PDFY | PRE-encrypted data, dynamic encryption key, full block storage, server-side encryption |
PDIN | PRE-encrypted data, dynamic encryption key, incremental storage, no server-side encryption |
PDIY | PRE-encrypted data, dynamic encryption key, incremental storage, server-side encryption |
PSFN | PRE-encrypted data, static encryption key, full block storage, no server-side encryption |
PSFY | PRE-encrypted data, static encryption key, full block storage, server-side encryption |
PSIN | PRE-encrypted data, static encryption key, incremental storage, no server-side encryption |
PSIY | PRE-encrypted data, static encryption key, incremental storage, server-side encryption |
A total of 5 system dimensions are measured over 16 mode combinations for AES-128 and EC-256: transmission size, network latency, client processing time, server processing time, and smart contract execution.
Each of the 16 mode combinations was evaluated by insertion and scaling costs. Insertion costs are determined by adding records en masse to a clean system instance (only contains the account request profile). Insights are garnered on cost amortization and limits associated with bulk and single record processing without existing record influences (eg, re-encryption and retransmission), which may direct policy on block synchronization. Moreover, 4 datasets of observations (1 per day) were synthetically generated for testing (
Scaling is scrutinized by gauging the effect existing records have on insertions. As this system accumulates records, these experiments facilitate the examination of existing medical records on overall performance. For insertion, care was taken to avoid interaction between new and existing data. Here, the reverse is of interest on how existing data affect record insertions. The results inform decisions on configuration selection and synchronization strategy. Testing began by instantiating a system with 1 of the 3 datasets (
Number of records and byte range per record by experimental dataset (all records were formatted as Health Level-7 Fast Healthcare Interoperability Resources [FHIR] JSON messages using HAPI FHIR).
Experiment | Records | Bytes/record (average) | Notes |
Insertion | 1 | 400 | 1 day |
Insertion | 30 | 400 | 30 days |
Insertion | 365 | 400 | 1 year |
Insertion | 1461 | 400 | 4 years |
Scaling | 334 | 395-761 (581) | 26 encounters, 33 conditions, 145 medication requests, and 130 observations |
Scaling | 945 | 395-768 (675) | 27 encounters, 159 conditions, 624 medication requests, and 135 observations |
Scaling | 2361 | 394-770 (732) | 109 encounters, 119 conditions, 2029 medication requests, and 104 observations |
The testing environment aligns with the minimal requirements defined in the Experimental Design section. In its simplest form, HealthChain is a medium of information exchange between an entity (eg, patient) and a server (eg, node). Every process in HealthChain can be reduced to a series of entity-server interactions; therefore, our testing environment emulates this 2-machine structure.
The first machine is a Lenovo T540p running Windows 7 Enterprise with 16 GB of memory, an Intel i7-4800 MQ processor, and a wired, consumer internet connection. The second is a Dell Optiplex 9010 running Linux Mint 17.1 with 8 GB of memory, an Intel i7-3770 processor, and a wired, business internet connection. Communication rates (download/upload in megabits per second [Mbps]) are as follows: 32.1/5.9 and 955.4/176.3 Mbps for each respective machine [
To facilitate direct processing time comparisons between client and server, 1 machine (the Lenovo) assumed both roles. This colocation, however, failed to address networking concerns. Thus, experiments incorporating transmission costs (ie, client processing time and smart contract execution) were duplicated using both machines, which are situated 5 miles apart. These times replaced those in the 2 identified measures for a more realistic outcome while still affording client and server relative performance comparisons.
The proof of concept facilitates the examination of the novel HealthChain elements as specified in section Experimental Design; it is not a production-ready blockchain system. The realization of the proposed framework requires the blending of the components defined herein with an existing blockchain technology such as Hyperledger Fabric or Ethereum. The proof of concept consists of 2 systems and 2 libraries written primarily in Java 8 and JSP and uses HAPI FHIR for document formatting [
The first system,
The second system,
Regarding libraries, the first provides chameleon hash support by way of PCCH [
Here, transmission size is analyzed by insertion (
In
Regarding overhead, dynamic options include 9137 bytes per smart contract (one here), ADI and ADF incorporate a new 397-byte AES PRE key, PDI uses a 384-byte scalar, and all send a 96-byte block hash.
To scaling (
Transmission size in kilobytes and bytes per record by the number of records inserted. ADF: AES-encrypted data, dynamic keys, full block storage; ADI: AES-encrypted data, dynamic keys, incremental storage; AES: Advanced Encryption Standard; ASF: AES-encrypted data, static keys, full block storage; ASI: AES-encrypted data, static keys, incremental storage; PDF: PRE-encrypted data, dynamic keys, full block storage; PDI: PRE-encrypted data, dynamic keys, incremental storage; PRE: proxy re-encryption; PSF: PRE-encrypted data, static keys, full block storage; PSI: PRE-encrypted data, static keys, incremental storage.
Transmission size in kilobytes per record added given an existing record set. ADF: AES-encrypted data, dynamic keys, full block storage; ADI: AES-encrypted data, dynamic keys, incremental storage; AES: Advanced Encryption Standard; ASF: AES-encrypted data, static keys, full block storage; ASI: AES-encrypted data, static keys, incremental storage; PDF: PRE-encrypted data, dynamic keys, full block storage; PDI: PRE-encrypted data, dynamic keys, incremental storage; PRE: proxy re-encryption; PSF: PRE-encrypted data, static keys, full block storage; PSI: PRE-encrypted data, static keys, incremental storage.
AES and PRE cipher sizes are dissected in
AES is slightly larger on average than the underlying data (0.7%-4.1%) regardless of mode. PRE incremental is extensively padded (26.5%-97.3%), whereas minimal in full block mode (3.1%-5.2% beyond 1 insertion). Thus, PRE is subject to extreme variability, relative to AES, on input file size.
Incremental storage: byte range per file and average Advanced Encryption Standard- and proxy re-encryption-encrypted cipher sizes by dataset (insertion and scaling).
Dataset | Bytes/file range (average) | AESa average (difference, %) | PREb average (difference, %) |
130,365, and 1461 | 400 | 416 (4.0) | 789 (97.3) |
334 | 395-761 (581) | 585 (0.6) | 802 (38.0) |
945 | 395-768 (675) | 679 (0.7) | 840 (24.3) |
2361 | 394-770 (732) | 737 (0.7) | 926 (26.5) |
aAES: Advanced Encryption Standard.
bPRE: proxy re-encryption.
Full block storage: total bytes per dataset and average Advanced Encryption Standard- and proxy re-encryption-encrypted cipher sizes by dataset (insertion and scaling).
Dataset | Total bytes | AESa average (difference, %) | PREb average (difference, %) |
1 | 400 | 416 (4.0) | 789 (97.3) |
30 | 12,000 | 12,368 (3.1) | 12,624 (5.2) |
365 | 146,000 | 150,112 (2.8) | 153,066 (4.8) |
1465 | 584,400 | 600,848 (2.8) | 613,053 (4.9) |
334 | 193,815 | 196,304 (1.3) | 200,406 (3.4) |
945 | 637,934 | 644,688 (1.1) | 658,026 (3.1) |
2361 | 1,727,714 | 1,744,032 (0.9) | 1,779,981 (3.0) |
aAES: Advanced Encryption Standard.
bPRE: proxy re-encryption.
Network latency is analyzed in isolation to understand client-to-server (
Client-to-server network latency in seconds per inserted record (ie, insertion) and seconds per record added given an existing record set (ie, scaling) — includes connection establishment, termination, and transmission time. ADF: AES-encrypted data, dynamic keys, full block storage; ADI: AES-encrypted data, dynamic keys, incremental storage; AES: Advanced Encryption Standard; ASF: AES-encrypted data, static keys, full block storage; ASI: AES-encrypted data, static keys, incremental storage; PDF: PRE-encrypted data, dynamic keys, full block storage; PDI: PRE-encrypted data, dynamic keys, incremental storage; PRE: proxy re-encryption; PSF: PRE-encrypted data, static keys, full block storage; PSI: PRE-encrypted data, static keys, incremental storage.
Client-to-server network latency (transmission only) measured in megabits per second and milliseconds per fragment by the number of records inserted. ADF: AES-encrypted data, dynamic keys, full block storage; ADI: AES-encrypted data, dynamic keys, incremental storage; AES: Advanced Encryption Standard; ASF: AES-encrypted data, static keys, full block storage; ASI: AES-encrypted data, static keys, incremental storage; PDF: PRE-encrypted data, dynamic keys, full block storage; PDI: PRE-encrypted data, dynamic keys, incremental storage; PRE: proxy re-encryption; PSF: PRE-encrypted data, static keys, full block storage; PSI: PRE-encrypted data, static keys, incremental storage.
Server-to-client network latency (transmission only) measured in milliseconds and megabits per second by the number of records transmitted to the client. AES: Advanced Encryption Standard; AF: AES-encrypted data, full block storage; AI: AES-encrypted data, incremental block storage; PF: PRE-encrypted data, full block storage; PI: PRE-encrypted data, incremental storage; PRE: proxy re-encryption.
Client processing time is explored for insertions (
All configurations require a similar amount of time per
Concerning scaling (
Client processing time in seconds and milliseconds per record by the number of records inserted. ADF: AES-encrypted data, dynamic keys, full block storage; ADI: AES-encrypted data, dynamic keys, incremental storage; AES: Advanced Encryption Standard; ASF: AES-encrypted data, static keys, full block storage; ASI: AES-encrypted data, static keys, incremental storage; PDF: PRE-encrypted data, dynamic keys, full block storage; PDI: PRE-encrypted data, dynamic keys, incremental storage; PRE: proxy re-encryption; PSF: PRE-encrypted data, static keys, full block storage; PSI: PRE-encrypted data, static keys, incremental storage.
Client processing time in milliseconds per record added given an existing record set. ADF: AES-encrypted data, dynamic keys, full block storage; ADI: AES-encrypted data, dynamic keys, incremental storage; AES: Advanced Encryption Standard; ASF: AES-encrypted data, static keys, full block storage; ASI: AES-encrypted data, static keys, incremental storage; PDF: PRE-encrypted data, dynamic keys, full block storage; PDI: PRE-encrypted data, dynamic keys, incremental storage; PRE: proxy re-encryption; PSF: PRE-encrypted data, static keys, full block storage; PSI: PRE-encrypted data, static keys, incremental storage.
Server insertion costs are presented in
Regarding scaling (
Server processing time in seconds and milliseconds per record by the number of records inserted. ADFN: AES-encrypted data, dynamic keys, full block storage, no server-side encryption; ADFY: AES-encrypted data, dynamic keys, full block storage, server-side encryption; ADIN: AES-encrypted data, dynamic keys, incremental storage, no server-side encryption; ADIY: AES-encrypted data, dynamic keys, incremental storage, server-side encryption; AES: Advanced Encryption Standard; ASFN: AES-encrypted data, static keys, full block storage, no server-side encryption; ASFY: AES-encrypted data, static keys, full block storage, server-side encryption; ASIN: AES-encrypted data, static keys, incremental storage, no server-side encryption; ASIY: AES-encrypted data, static keys, incremental storage, server-side encryption; PDFN: PRE-encrypted data, dynamic keys, full block storage, no server-side encryption; PDFY: PRE-encrypted data, dynamic keys, full block storage, server-side encryption; PDIN: PRE-encrypted data, dynamic keys, incremental storage, no server-side encryption; PDIY: PRE-encrypted data, dynamic keys, incremental storage, server-side encryption; PRE: proxy re-encryption; PSFN: PRE-encrypted data, static keys, full block storage, no server-side encryption; PSFY: PRE-encrypted data, static keys, full block storage, server-side encryption; PSIN: PRE-encrypted data, static keys, incremental storage, no server-side encryption; PSIY: PRE-encrypted data, static keys, incremental storage, server-side encryption.
Server processing time in milliseconds per record added given an existing record set. ADFN: AES-encrypted data, dynamic keys, full block storage, no server-side encryption; ADFY: AES-encrypted data, dynamic keys, full block storage, server-side encryption; ADIN: AES-encrypted data, dynamic keys, incremental storage, no server-side encryption; ADIY: AES-encrypted data, dynamic keys, incremental storage, server-side encryption; AES: Advanced Encryption Standard; ASFN: AES-encrypted data, static keys, full block storage, no server-side encryption; ASFY: AES-encrypted data, static keys, full block storage, server-side encryption; ASIN: AES-encrypted data, static keys, incremental storage, no server-side encryption; ASIY: AES-encrypted data, static keys, incremental storage, server-side encryption; PDFN: PRE-encrypted data, dynamic keys, full block storage, no server-side encryption; PDFY: PRE-encrypted data, dynamic keys, full block storage, server-side encryption; PDIN: PRE-encrypted data, dynamic keys, incremental storage, no server-side encryption; PDIY: PRE-encrypted data, dynamic keys, incremental storage, server-side encryption; PRE: proxy re-encryption; PSFN: PRE-encrypted data, static keys, full block storage, no server-side encryption; PSFY: PRE-encrypted data, static keys, full block storage, server-side encryption; PSIN: PRE-encrypted data, static keys, incremental storage, no server-side encryption; PSIY: PRE-encrypted data, static keys, incremental storage, server-side encryption.
Smart contract execution by time and per record is assessed in this section, with results conveyed in
In absolute terms, AFN, AFY, and AIN are the fastest, followed by PFN and PFY (progressing from 1% to 20% slower), AIY (23%-183%), PIN (46%-854%), and PIY (94%-1679%). Incremental server-side encryption is considerably expensive, doubling PRE and tripling AES times. Network latency accounts for around 9% of incremental and 19% of full block time. Per record, AIY, PIN, and PIY noticeably level-off by 365, and AFY, PFN, and PFY by 1461. AFN and AIN, however, descend beyond 3822 (2361+1461) at 2%.
Smart contract execution time in seconds and milliseconds per record by the number of records processed. AES: Advanced Encryption Standard; AFY: AES-encrypted data, full block storage, server-side encryption; AFN: AES-encrypted data, full block storage, no server-side encryption; AIN: AES-encrypted data, incremental block storage, no server-side encryption; AIY: AES-encrypted data, incremental storage, server-side encryption; PFN: PRE-encrypted data, full block storage, no server-side encryption; PFY: PRE-encrypted data, full block storage, server-side encryption; PIN: PRE-encrypted data, incremental block storage, no server-side encryption; PIY: PRE-encrypted data, incremental storage, server-side encryption; PRE: proxy re-encryption.
The impracticality of full block approaches is apparent from the patient’s vantage point. Whether inserting or scaling, block formation and transmission are resource intensive. For those with basic computers or mobile devices, or those operating on metered or low-bandwidth networks, these options should be avoided.
Catering to constrained environments are ASIN, PSIY, PDIN, PDIY, PSIN, and PSIY. ASIN, ASIY, PSIN, and PSIY are constant in bytes and server processing time, with decreasing client processing time because of network latency amortization over an otherwise constant process. PDIN and PDIY are constant in bytes and amortize latency as do the previous but irregular for the server (ie, server-side rekeying). Overall, ASIN and ASIY are the top performers. They require minimal time and bandwidth for record insertion, hold constant when scaling, and quickly execute smart contracts (refer to the section on Smart Contract Execution for details). The compromise is security. Static approaches, although fast, are susceptible to attacks (see the section on Smart Contracts and
PRE incremental methods are byte intensive because of excessive padding of the small experimental files and slow during smart contract execution. This is mostly mitigated through full block approaches. Unlike AES, the variability of PRE cipher size is vast. It has the potential to be compact and efficient or bloated and wasteful. PSIN and PSIY are subject to the same static key vulnerabilities as ASIN and ASIY and are more expensive. One must decide if cipher malleability justifies increased resource expenditure.
PDIN and PDIY are the only viable dynamic options. Server processing is insignificant for record insertions (a few milliseconds) but rises with scale. From 1 to 2361, PDIN is 1% to 7% and PDIY 4% to 11%, the magnitude of the client. Server processing is projected to eclipse client by around 40,000 and 37,000 records for PDIN and PDIY respectively. However, with appropriate hardware and in-memory databases, this cost can be reduced. Compared with ASIN and ASIY, both are marginally slower on the client, but roughly twice in bytes and latency.
Ultimately, several candidates emerge. ASIN and ASIY for speed, PSIN and PSIY for malleability, and PDIN and PDIY for malleability and security. Refer to
Relative comparison of client and server processing time in milliseconds and transmission size in kilobytes per record by insertion and scaling. ADFN: AES-encrypted data, dynamic keys, full block storage, no server-side encryption; ADFY: AES-encrypted data, dynamic keys, full block storage, server-side encryption; ADIN: AES-encrypted data, dynamic keys, incremental storage, no server-side encryption; ADIY: AES-encrypted data, dynamic keys, incremental storage, server-side encryption; AES: Advanced Encryption Standard; ASFN: AES-encrypted data, static keys, full block storage, no server-side encryption; ASFY: AES-encrypted data, static keys, full block storage, server-side encryption; ASIN: AES-encrypted data, static keys, incremental storage, no server-side encryption; ASIY: AES-encrypted data, static keys, incremental storage, server-side encryption; PDFN: PRE-encrypted data, dynamic keys, full block storage, no server-side encryption; PDFY: PRE-encrypted data, dynamic keys, full block storage, server-side encryption; PDIN: PRE-encrypted data, dynamic keys, incremental storage, no server-side encryption; PDIY: PRE-encrypted data, dynamic keys, incremental storage, server-side encryption; PRE: proxy re-encryption; PSFN: PRE-encrypted data, static keys, full block storage, no server-side encryption; PSFY: PRE-encrypted data, static keys, full block storage, server-side encryption; PSIN: PRE-encrypted data, static keys, incremental storage, no server-side encryption; PSIY: PRE-encrypted data, static keys, incremental storage, server-side encryption.
Comparison of practical configurations by cipher malleability; security; insertion, scaling, and smart contract execution time; and transmitted bytes.
Property | ASINa | ASIYb | PSINc | PSIYd | PDINe | PDIYf |
Cipher malleability | No | No | Yes | Yes | Yes | Yes |
Security—dynamic keying | No | No | No | No | Yes | Yes |
Security—server-side encryption | No | Yes | No | Yes | No | Yes |
Client insertions time | Fastest | Fastest | Fast | Fast | Fast if >30 | Fast if >30 |
Client insertions bytes | Smallest | Smallest | Largest | Largest | Largest | Largest |
Server insertions time | Fast | Slow | Slowest | Slow | Fast | Slowest |
Client scaling time | Fastest, constantg | Fastest, constantg | Fastest, constantg | Fastest, constantg | Fast, constantg | Fast, constantg |
Client scaling bytes | Smallest, constant | Smallest, constant | Small, constant | Small, constant | Small, constant | Small, constant |
Server scaling time | Fast, constant | Slow, constant | Fast, constant | Slower, constant | Slower | Very slow |
Smart contract execution | Fastest | Fastest | Very slow | Very slow | Slowest | Slowest |
aASIN: Advanced Encryption Standard–encrypted data, static keys, incremental storage, no server-side encryption.
bASIY: Advanced Encryption Standard–encrypted data, static keys, incremental storage, server-side encryption.
cPSIN: proxy re-encryption–encrypted data, static keys, incremental storage, no server-side encryption.
dPSIY: proxy re-encryption–encrypted data, static keys, incremental storage, server-side encryption.
ePDIN: proxy re-encryption–encrypted data, dynamic keys, incremental storage, no server-side encryption.
fPDIY: proxy re-encryption–encrypted data, dynamic keys, incremental storage, server-side encryption.
gConstant time if latency, which is amortized over records, is not factored.
Our study has the following limitations. First, the results are consistent with AES-128 and EC-256 alone. It is impossible to extrapolate the effects a change may have. Second, the small experimental files resulted in excess PRE cipher padding. Although the records were legitimate, EHR data may produce different results. Third, only 1 smart contract, which dynamic options regenerate during an update, was present for testing. With many contracts and few existing records, overall performance may diminish. In addition, smart contract regeneration was not optimized as the entire contract was reproduced and transmitted instead of just the re-encryption keys. This modification has the potential to decrease the size by 41%. Finally, server-side encryption only operates in dynamic mode. A static or periodic (eg, daily or after
In this study, a proof-of-concept patient-centered blockchain—HealthChain—was presented. The posited framework promotes patient engagement and facilitates secure, mediated information exchange between patients and providers. Redactable patient blocks, by way of chameleon hashing, were introduced to minimize data fragmentation, allow for in-place editing, and reduce resource consumption. PRE, smart contracts, and HL7 FHIR form the foundation of our proposed information exchange model, along with our 2PD PRE scheme and signature methods. A total of 16 experimental configurations were examined over 5 system dimensions by the cost of record insertion and scaling. Results indicate ASIN was the fastest and least bandwidth intensive, whereas PDIY was the best cryptographically, although the ultimate configuration rests with implementers and their desired level of speed and security.
Furthermore, 3 areas are targeted for future work. First, Barreto-Lynn-Scott [
Proxy re-encryption mathematical foundation, proposed extensions, and proofs.
Experimental configurations.
Source code files.
2-party proxy re-encryption decryption
Advanced Encryption Standard
AES-encrypted data, dynamic keys, full block storage, no server-side encryption
AES-encrypted data, dynamic keys, incremental storage
AES-encrypted data, dynamic keys, incremental storage, no server-side encryption
AES-encrypted data, dynamic keys, incremental storage, server-side encryption
AES-encrypted data, full block storage
AES-encrypted data, full block storage, no server-side encryption
AES-encrypted data, incremental block storage, no server-side encryption
AES-encrypted data, incremental storage, server-side encryption
AES-encrypted data, static keys, incremental storage
AES-encrypted data, static keys, incremental storage, no server-side encryption
AES-encrypted data, static keys, incremental storage, server-side encryption
Code of Federal Regulations
elliptic curves
elliptic curve cryptography
electronic health record
Fast Healthcare Interoperability Resources
Federal Information Processing Standard
Health Insurance Portability and Accountability Act of 1996
Java Pairing-Based Cryptography library
megabits per second
The Office of the National Coordinator for Health Information Technology
Public-coin chameleon hash
PRE-encrypted data, dynamic encryption key full block storage
PRE-encrypted data, dynamic keys, incremental storage
PRE-encrypted data, dynamic keys, incremental storage, no server-side encryption
PRE-encrypted data, dynamic keys, incremental storage, server-side encryption
PRE-encrypted data, full block storage
PRE-encrypted data, full block storage, no server-side encryption
personal health record
PRE-encrypted data, incremental storage
PRE-encrypted data, incremental block storage, no server-side encryption
PRE-encrypted data, incremental storage, server-side encryption
proxy re-encryption
PRE-encrypted data, static keys, full block storage
PRE-encrypted data, static keys, incremental storage
PRE-encrypted data, static keys, incremental storage, no server-side encryption
PRE-encrypted data, static keys, incremental storage, server-side encryption
Secure Hash Algorithm
None declared.