Sage Journals: Discover world-class research

Abstract

The electronic sharing of medical imaging data is an important element of modern healthcare systems, but current infrastructure for cross-site image transfer depends on trust in third-party intermediaries. In this work, we examine the blockchain concept, which enables parties to establish consensus without relying on a central authority. We develop a framework for cross-domain image sharing that uses a blockchain as a distributed data store to establish a ledger of radiological studies and patient-defined access permissions. The blockchain framework is shown to eliminate third-party access to protected health information, satisfy many criteria of an interoperable health system, and readily generalize to domains beyond medical imaging. Relative drawbacks of the framework include the complexity of the privacy and security models and an unclear regulatory environment. Ultimately, the large-scale feasibility of such an approach remains to be demonstrated and will depend on a number of factors which we discuss in detail.

Keywords

blockchain data sharing decentralization interoperability medical imaging

Introduction

Imaging studies are one of the leading drivers of modern medical decision-making,¹ and thus, their accessibility to healthcare providers and patients is of critical importance. However, current techniques for transferring medical imaging data are inconvenient and occasionally wholly inadequate. In 2014, 15 percent of patients who visited a healthcare provider in the United States reported having to bring a radiological study or other test result to their appointment personally, and 5 percent needed to have a test or procedure repeated due to the unavailability of prior results.² Given the costs of medical image acquisition and the risks associated with delayed access to imaging results, facilitating the secure electronic sharing of radiological studies provides a natural target for improving healthcare efficiency and patient outcomes.

In this article, we outline a framework that utilizes blockchain technology to enable patients to delegate electronic access to their medical imaging data in a secure manner. We discuss the appropriateness of blockchain technology for this indication, and we describe the relative merits and drawbacks of this approach relative to several alternatives.

Medical image sharing

Despite the widespread availability of digital imaging and high-speed network connectivity, the persistent paradigm for medical image sharing requires that a physical copy (e.g. a CD or DVD) be couriered between providers. There is clear inefficiency and waste inherent in transcribing a digital asset onto optical media which commonly is read only once during image import at the receiving site.³ Moreover, this workflow imposes an undue responsibility upon the patient to ensure that the images are not lost, damaged, or intercepted in transit.

In order to address the shortcomings of physical media transfer, the Radiological Society of North America (RSNA) developed the Image Share Network (ISN), which represents the current state of the art for electronic transmission of medical images.⁴ Briefly, the sites participating in the ISN centralize image distribution through a third-party Clearinghouse. Acquired images are uploaded to the Clearinghouse, where they are stored, indexed by the cryptographic hash of a secret token, for 30 days. Within this window, a patient can authorize a personal health record (PHR) vendor to download his or her data by divulging the token needed to reproduce the hash. The images stored in the PHR represent the virtual analog of the optical disc, and the patient can subsequently permit his or her healthcare providers to access these data. The ISN architecture is schematized in Figure 1.

Figure 1.

The RSNA Image Share Network. Arrows indicate the flow of imaging data through the network. Dashed transfers require patient interaction and authorization via the PHR. Circles represent the conceptual owners of imaging data, rounded rectangles symbolize data producers or consumers, and block rectangles denote third parties.

Although the ISN eliminates the need for physical media transfer, its design raises concerns regarding the involvement of intermediaries and the centralization of the sharing infrastructure. For example, the ISN workflow includes the Clearinghouse and PHR vendors as new entities with access to protected health information (PHI); these represent additional points at which an internal or external malicious actor may compromise the network and gain access to sensitive data. Moreover, the provider fulfilling the critical Clearinghouse role is able to exert significant control over the network by limiting which imaging centers and PHR vendors have access to the ISN ecosystem. At the time of this writing, less than a dozen radiology centers are enrolling patients in the network, exactly four PHR vendors (one of which is also the Clearinghouse operator) are authorized to retrieve ISN images, and less than 30 percent of patients whose images are sent to the Clearinghouse ever download their data into one of these approved PHRs.^4,5 In examining these issues, the concept of a decentralized architecture presents itself as an option that may decrease the barriers to entry and encourage more widespread adoption of the image sharing network.

Blockchain technologies

The recently introduced blockchain concept has been the principal innovation driving several prominent decentralized endeavors, and it is thus appropriate to consider its applicability to the task of medical image sharing. A blockchain is, quite simply, a data structure consisting of an ordered sequence of batched entries, termed blocks. The ordering of these blocks is established by storing a cryptographic hash of the immediate prior record within each block (Figure 2). The use of an irreversible hash function as the chaining mechanism also serves to verify the integrity of the previous block, and it is this characteristic that gives rise to the key emergent property of the blockchain as a data store: immutability. Any attempt to tamper with the data in an established block is easily detected since it changes the hash of the altered block and consequently, the hashes of all subsequent blocks in the chain.

Figure 2.

A simple blockchain. In addition to the data records, each block also contains a cryptographic hash of the previous block, thus ensuring block ordering and data integrity.

A blockchain is maintained by a set of nodes, entities without a pre-existing trust relationship that are connected through a peer-to-peer network. For the blockchain to be useful, there must be some mechanism by which the nodes can mutually agree upon the next valid block in the chain. The two most widely deployed schemes for establishing such a distributed consensus are summarized as follows:

Proof-of-work is the archetypal process for block validation in which nodes compete to generate the next block by expending computational effort to solve a challenging mathematical problem. The first node to arrive at a solution broadcasts the result to the network; the solution is verified by the remaining nodes, and work begins on the next block.⁶

Proof-of-stake algorithms forego the computational challenge, but offer only a randomly selected subset of nodes the opportunity to produce each block. The probability of selection is weighted by each entity’s level of existing investment in the system, typically quantified as the value or duration of asset holdings relevant to that particular blockchain.^7,8

Blockchains thus enable many separate parties to converge upon a single, immutable record without requiring an authoritative intermediary. As we show below, these properties provide a sufficient core upon which to deploy a decentralized image sharing network.

Design

Although the primary application of blockchain technology to date has been to establish ledgers of transactions involving virtual tokens (i.e. cryptocurrencies), our design decisions are driven by a different set of objectives. Specifically, we intend to use a blockchain to store: (1) a list of imaging studies and the patient to whom each study belongs, (2) the set of entities authorized by the patient to access each study, and (3) the endpoint from which each study may be retrieved. In this section, we develop such a system, keeping our description intentionally general to maintain focus on the overall framework.

The anticipated users of this data structure include the imaging centers at which the studies are acquired and stored (a group that includes both hospitals and outpatient imaging facilities), the patients themselves, as well as any healthcare providers, PHR vendors, cloud services, or other designees granted access to an imaging study. All of these entities are represented on the blockchain by the public portion of an asymmetric key pair. Each imaging study is referenced by its globally unique DICOM Study Instance UID, hashed before publication to prevent leakage of PHI.⁹

Block structure

Each block is composed of two primary categories of data elements. Block header elements provide important metadata necessary to establish the sequencing and integrity of the blockchain. These include items such as the hash of the prior block (Figure 2), as well as a unique block identifier, timestamp, and total size of the block. Many header fields are conserved between blockchain implementations, and we defer to their detailed descriptions available elsewhere^6,8 in order to maintain focus on the defining characteristics of the image sharing blockchain.

The other main category of block data consists of transaction elements. These are the unique data fields that differentiate this blockchain, and their definitions fully determine the types of information that the blockchain structure is able to store. The image sharing blockchain is characterized by the transactions enumerated below. For clarity, we suppress the transactional metadata (unique identifier, timestamp, etc.) and envision a patient $P$ who undergoes a radiographic examination $X$ while at hospital $H$ and wishes later to share those images with primary care doctor $D$ . The sequence of transactions is outlined diagrammatically in Figure 3, and below, we describe the process using conventional security protocol notation such that $K_{α}$ and $K_{α}^{- 1}$ represent the public and private keys, respectively, of actor $α$ , while ${μ}_{K_{α}^{- 1}}$ denotes a message µ $μ$ signed under the private key. We then have the following minimal transaction set:

Define Source: This transaction establishes a source of medical imaging data by linking a public key to a uniform resource locator (URL). In our example, hospital $H$ signs a transaction associating its public key with the URL endpoint that it uses to service image transfer requests from authorized entities (Figure 3, Block A). This need be done only once. The transaction thus establishes the signed tuple ${K_{H}, {URL}_{H}}_{K_{H}^{- 1}}$ . We note that the Define Source transaction does not require the participation of any parties other than the hospital; a valid signature over the tuple verifies that the posting entity controls the private key corresponding to $K_{H}$ (depicted in red in Figure 3).

Define Study: This transaction establishes a source as the creator and a patient as the owner of a radiological study with a particular unique identifier UID. The tuple stored in the blockchain is ${K_{H}, {K_{P}, K_{H}, Hash ({UID}_{X})}_{K_{P}^{- 1}}}_{K_{H}^{- 1}}$ . This doubly signed transaction is analogous to a document bearing the signatures of both the patient and a hospital representative. The patient asserts that he or she underwent an imaging study (identified by the hashed DICOM Study Instance UID, as above) at the hospital; the hospital confirms this statement and commits to making the study available at the endpoint it defined in an earlier block. In practice, we expect that the patient’s signed claim will be elicited via a mobile application that will also save the values needed for future Allow Access transactions (see below). The hospital will then co-sign the patient’s claim and broadcast the transaction for incorporation into the blockchain.

Allow Access: This transaction enables the owner of a radiological study to authorize another party to retrieve his or her imaging data from the source endpoint URL. Patient $P$ signs a transaction granting this ability to doctor $D$ in our example. The inclusion of the signed tuple ${K_{P}, K_{D}, K_{H}, Hash ({UID}_{X})}_{K_{P}^{- 1}}$ within a validated block embeds this consent into the blockchain. As shown in Figure 3, the patient posts this transaction after an in-person verification of keys with the physician. After de-anonymizing themselves to each other in this way, the patient can trust that he or she is granting access to the appropriate person, and the physician can associate any received images for $K_{P}$ with the correct local medical record number.

Figure 3.

Blockchain image sharing sequence diagram.¹⁰ The blockchain/timeline is shown at left with four blocks/timepoints lettered for reference in the main text (see the “Design” section for additional details). The middle column depicts interactions between entities at each stage, and the assertions at right reflect the semantic meaning of both the on- and off-blockchain transactions enabling decentralized image sharing.

These three types of transactions are sufficient for the image sharing blockchain to satisfy the primary objectives of the ISN. Additional transaction types not explored here may provide further functionality, such as enabling patients to revoke future access to their data and allowing imaging centers to change their URL endpoints. We note that third parties, such as PHRs, are unnecessary in this scheme; however, should a patient wish to collect their images in a PHR for personal archival or other purposes, the PHR vendor would perform the same actions as the physician in our given example.

Image transfer

There are no medical images stored on the blockchain; the chain of transactions instead represents only a list of the key owners that are permitted to access each study. The actual image transmission requires that the image recipient send a signed request to the URL endpoint of the imaging source that created the study. This requesting entity may be any individual or service that the owner (patient) has authorized to access this particular imaging study. We leverage the existing work by the Integrating the Healthcare Enterprise (IHE) initiative, which has specified a standard form for retrieving documents across domains, the ITI-43 transaction.¹¹

The image source public key and hashed study UID satisfy the required elements of the ITI-43 request, respectively termed repositoryUniqueId and documentUniqueId in IHE parlance. Moreover, we require that the requesting entity authenticates itself by digitally signing the transaction using the private key corresponding to the public key that was previously granted access by the patient.¹² In Figure 3, the physician transmits this ITI-43 request at timepoint D.

Upon receipt of such a request, the image source verifies that the signature is correct, checks that the repositoryUniqueId specifies its own public key, confirms that the hashed UID corresponds to a study that it previously published for the patient (as in Figure 3, Block B), and confirms—via the blockchain—that the patient has granted the requester access to these images (as in Figure 3, Block C). If all criteria are satisfied, the source returns an ITI-43 response containing the imaging study. Both the request and response are transmitted over a transport layer secured link to prevent eavesdropping.

Validation and consensus

Special consideration must be devoted to the process of block creation and validation in the setting of medical image sharing. Proof-of-stake systems for achieving distributed consensus have the advantage of imposing minimal computational and energy burdens on their participants. This property is critical for our application as there is no token of intrinsic value or scarcity being offered on this blockchain—we are producing a distributed database of access permissions, not a cryptocurrency system—and we do not wish to impose significant new healthcare costs to enable image sharing. In this setting, however, we must still somehow motivate the block generators to ensure that valid blocks are produced in a timely fashion, and that a single chain quickly predominates any forks. Alternatively, we may instead develop a disincentive for block producers to engage in malicious or noncontributory behavior. This latter approach is similar to the concept of bonded validators in cryptocurrency proof-of-stake systems; in that construct, only nodes that have established a security deposit may participate in chain extension, and any misbehaving node is forced to forfeit its investment.¹³ In such a system, there is no particular advantage to producing the most blocks, but rather there is a penalty for not producing a block when selected by the network to do so.

We note that the nature of the blockchain provides for straightforward auditing of each node’s activities, including the number of blocks generated, failures to produce a block when eligible to do so, and attempts to publish invalid blocks. In addition, a node operator is able to prove its ownership of a node simply by signing a message with the private key corresponding to that node’s identifying public key.

Given these preliminaries, we build the image sharing blockchain using a proof-of-stake scheme in which the probability of a node producing the next block is driven by the number of Define Study transactions designating that node’s public key as the image source. This choice effectively restricts the block generation process to facilities that acquire and store medical images—a group expected to be responsive to monetary incentives put forth by a large (e.g. governmental) payer. By linking reimbursement rates to the results of periodic reviews of the relevant nodes’ activities on the blockchain, we can ensure participation that yields a reliable chain of valid blocks produced at regular intervals.

Discussion

Deploying a blockchain as a distributed access control list to enable the sharing of medical records represents an unexplored application of a nascent technology, and a thorough discussion of its anticipated benefits and limitations is thus warranted. In this section, we outline the major points of consideration when implementing a blockchain of the form described above.

Advantages and interoperability

As constructed in the previous section and schematized in Figure 4, the image sharing blockchain achieves the objective of enabling patient-controlled image sharing without the need for a central Clearinghouse. Moreover, the PHR is no longer a required additional intermediary, but rather a tool that the patient may optionally utilize to manage health records. In addition to this disintermediation, the blockchain architecture provides several additional key benefits, many of which have been explicitly targeted by the Office of the National Coordinator for Health Information Technology (ONC) as critical to the development of an interoperable health system. We reference the criteria enumerated in the ONC nationwide interoperability roadmap¹⁴ throughout this section as a convenient benchmark for assessing the utility of the framework we have proposed.

Figure 4.

The image sharing blockchain. Each participant operates a node (o) on the network which establishes the blockchain (). The patient provides access to chosen entities by posting blockchain transactions. Imaging data are transferred directly from the source to these authorized recipients; no central intermediary is required.

For example, we have selected a proof-of-stake system with implicit bonding, which facilitates auditing of each entity’s involvement in the system and provides a simple means for large payers (e.g. the Centers for Medicare & Medicaid Services) to motivate participation. Effectively, the institution deposits resources into the study at the time of image acquisition. In order to recover the most value from that investment (i.e. receive the full reimbursement), payers require that the institutions have also produced valid blocks when selected by the proof-of-stake algorithm, an easily audited metric. The payers prefer to impose this requirement because accessible imaging data improve outcomes for their patients, and the institutions prefer to produce blocks when selected because doing so requires minimal resources and maximizes the return on their investment. The blockchain design thus greatly simplifies the process of establishing an economic environment in which interoperability is a sound business decision, an explicit priority identified in the ONC’s roadmap.¹⁴

Moreover, the peer-to-peer network of nodes and associated blockchain architecture represent design decisions that effectively address another interoperability criterion: the sharing of PHI with patient-authorized recipients over a secure, private, tamper-resistant network infrastructure.¹⁴ As described above, the chaining mechanism results in an inherently immutable data record, such that any attempt to modify established blocks is immediately evident. Beyond this, the transactions that define the image sharing blockchain are based on well-tested and widely deployed practices utilizing public key cryptography; as long as an entity secures its private key, all information on the blockchain signed by that entity may be trusted. This cryptographic construction not only protects patients against attempts to forge their consent but also shields the image sharers against any false claims of unauthorized sharing.

We further note important properties of the transaction types that define the image sharing blockchain. For example, a signed Allow Access transaction provides a straightforward representation of authorization to access electronic health information. In addition, the set of Define Source transactions on the blockchain effectively establishes a directory of resource locations that can be easily referenced to locate and request imaging studies. These transactions thus directly fulfill additional important criteria of an interoperable health system.¹⁴

One of the blockchain’s most unique strengths lies in its ability to establish an anonymous record while still enabling participants to authenticate themselves when required. We recall that patients are represented on the blockchain as randomly-generated public keys. As long as entities use unique key pairs to manage each study and the private keys are kept secure, patients cannot be identified by analyzing the blockchain record. When needed, however, any entity can prove ownership of a public key simply by signing a message with the corresponding private key. As previously suggested, an imaging center may be required to do so when undergoing an audit to determine reimbursement rates. In this manner, the asymmetric cryptography driving the blockchain satisfies the need for verifiable identity and authentication of all participants,¹⁴ while at the same time protecting privacy.

Interestingly, this same property solves the problem of cross-domain identity matching, another requirement of an interoperable health system.¹⁴ Existing patient matching techniques relying on standardized demographic data and other heuristics yield suboptimal match rates, particularly across geographic regions or health systems.¹⁵ The public key identity system avoids the problems associated with incomplete, inaccurate, or outdated demographic data entirely; instead, all studies associated with provably patient-owned public keys are included in that patient’s medical record. Although the concept may seem initially unfamiliar, if appropriately implemented, we expect that members of the general public will indeed be able to manage public keys as a form of digital identity. An exemplary model is that of the Estonian national identification card which assigns each citizen a unique public key that can be used to sign documents electronically, an implementation that has enjoyed great popularity.¹⁶ The “HIE of One” proposal and others also rely on public keys are identifiers for patients and physicians.^17,18

Throughout the construction of the blockchain, we have endeavored to make best use of existing standards, file formats, and infrastructure.¹⁴ We continue to leverage the ubiquitously supported DICOM format for medical imaging data, and we rely on the existing standards developed by IHE to perform the actual image transfer. Furthermore, we continue to use imaging centers, many of which have already invested substantially in data storage and archiving technology, as the repositories of imaging studies to make the most efficient use of existing infrastructure.

Considering all of these elements, the image sharing blockchain concept may eventually lead to the ultimate objective of an interoperable health system: a greater ability for patients to electronically access their health information and share it at their discretion.¹⁴ Finally, although we have focused on medical image sharing as the motivating use case while developing the framework, we note that the bonded proof-of-stake blockchain architecture and the underlying cryptographic elements are application-independent. The concepts presented here can thus be trivially generalized to enable the secure, patient-controlled cross-domain transfer of many forms of health information, with possibilities including laboratory results, digitized pathology slides, and electrocardiograms, among others.

Limitations

Privacy concerns are, justifiably, major considerations when using blockchain technologies to share health information. Historically, the dominant principle for protecting health-related data has been to keep the records themselves generally inaccessible except to those directly involved in a patient’s care. The blockchain privacy model, however, is more similar to one often used when conducting medical research: the data records themselves are widely accessible, but the patients to whom they refer are either secret or anonymized. In this setting, we must take steps to minimize the risk that an analysis of the blockchain transactions, perhaps combined with outside information, will permit a public key to be linked definitively to a particular individual. We have alluded previously to the requirement that patients and the entities with which they share images should generate a new key pair for each study. Using a new public key (effectively a new virtual identity) to manage each study, a patient prevents unauthorized actors from linking multiple studies to a single identity, a process that may result in the leakage of PHI; a similar technique is used to provide anonymity on cryptocurrency networks.⁶ It is equally important for the recipients of imaging data to mask their identities in a similar manner since sharing images with a public key known to be associated with an oncologist, for example, leaks information about a patient’s diagnosis. We consider this privacy model to be a relative drawback of the blockchain technique as it is error-prone and requires multiple parties to act in a very deliberate manner in order to preserve patient privacy.

The security model also differs significantly between the ISN and the image sharing blockchain. On one hand, the blockchain removes a central point of failure—the Clearinghouse, a breach of which exposes all imaging studies flowing through the ISN. Nevertheless, because the ISN is a highly restricted network, it may simply reject all network traffic from unauthorized addresses, thus forcing any attack to relay via one of the small number of imaging centers or PHR vendors authorized to communicate with the Clearinghouse. No such filtering is possible on the image sharing blockchain, an open network with no central authority limiting participation. The attack surface is thus much larger; each imaging center must adequately secure its URL endpoints, and each node operator must take care to ensure the secrecy of its private keys. We note, though, that due to the decentralized architecture, the exposure of any single private key is unlikely to affect as large a number of individuals as an ISN Clearinghouse breach. The ultimate reliance on asymmetric cryptography also means that the loss of a private key results in an inability to manage the corresponding resource, requiring some off-blockchain recovery process to re-establish ownership. As with privacy, decentralization results in a more complex security model, likely overall more prone to breaches than a centralized scheme.

In addition, we note that the concept of “stake” carries dual meanings in our construct. The blockchain quantifies stake as simply the number of imaging studies (or other types of health information) that each center makes accessible. Due to the obscuration of data elements and privacy considerations mentioned above, it is not possible for the proof-of-stake algorithm to assign greater stake for certain types of data. The economic stake, however, may vary significantly by type of study: for example, a positron-emission tomography study represents a much larger institutional investment compared to a radiograph. The discrepancy between these definitions means that facilities that produce a large number of low-cost information elements will be selected for block creation more often than those generating fewer but higher-cost data. Nevertheless, we consider this a minor limitation; given the negligible energy cost of generating a block in a proof-of-stake system, we do not expect that sites will find it worthwhile to refuse to generate blocks due to this imbalance. If such a scenario were to emerge, it could be readily addressed by payers adopting a graded penalty system that accounts for volume and relative value units.

We must also consider the issue of whether a blockchain-based sharing network is even permissible given current regulations. Several sections of the Code of Federal Regulations (C.F.R.)¹⁹—specifically, the HIPAA Privacy Rule—are relevant in assessing the feasibility of the proposed approach. For example, it remains to be determined if the use of random public keys and hashed study identifiers provides sufficient de-identification to exempt covered entities from the standard disclosure restrictions (45 C.F.R. §§ 164.502(d)(2), 164.514(a) and (b)). If no such exemption is possible, then we must also investigate whether patients’ digital signatures on blockchain transactions serve as adequate documentation to authorize the release of PHI (45 C.F.R. § 164.508(c)). Additional federal and local regulations also likely apply, and given the severe penalties associated with the unlawful disclosure of PHI, healthcare institutions are expected to be hesitant in their adoption of this unconventional sharing architecture.

Finally, aside from the technical and regulatory considerations, the practical usefulness of the proposed framework will likely depend heavily upon the end user experience. Blockchain transactions encapsulate cryptographic concepts that we expect are unfamiliar to a vast majority of the population. Nevertheless, the proposed scheme requires patients to generate and manage key pairs, provide cryptographic signatures, and post transactions authorizing access to their imaging data. The complexities underlying these actions will need to be hidden behind a sufficiently user-friendly interface, likely deployed as a web and/or mobile application. Optimizing the end user experience is a challenge even for the more conventionally structured ISN, which relies on the familiar password or shared secret model for authentication; more than 75 percent of ISN help desk requests relate to patient-specific issues, as opposed to technical issues with the ISN infrastructure.²⁰ We observe that patient utilization of the blockchain for image sharing may be quantified by the number of Allow Access transactions, and it will be important to monitor this metric to detect potential issues hindering adoption. The user experience for healthcare providers must also be considered, and we note that the blockchain itself does not address broader problems in health information exchange; for example, the ability to share data does not alone ensure its usability if supporting information about clinical context is unknown.

Alternatives

Although an exhaustive comparison with all related efforts is beyond the scope of this article, we briefly review here the main differences between the image sharing blockchain and several prominent similarly oriented endeavors. Throughout this article, we have drawn comparisons to the RSNA ISN, and we wish to note for completeness that the ISN also targets other potential use cases that we have not directly addressed in this work. The ISN, for example, allows for the transfer of images between sites with pre-existing trust relationships for clinical or research purposes in the absence of patient interaction.⁴ We note that the image sharing blockchain is also capable of supporting these use cases; the acquiring site needs only to generate an additional key pair to represent the clinical or research effort, assign that key as the study owner in the Define Study transaction and then use that key to grant access to collaborating institutions. Again, in these scenarios, the blockchain mechanism avoids transmitting medical images via a superfluous third party, minimizing the exposure of PHI.

A number of other parallel works specifically promoting blockchain technologies for health information sharing also warrant comparison.^21–23 Some have advocated storing encrypted health information directly on the blockchain itself.^24–26 In the context of image sharing, this approach has the disadvantage of abandoning significant existing investments in medical image storage and archiving. In addition, storing the encrypted—and thus incompressible—imaging studies of all patients would result in an enormous blockchain, far too large for a node running on a mobile device or even a modern workstation to download, store, and validate. Blockchain size is a problem under active study and has been shown to be a limiting factor even for chains that store simple transactional data, much less the massive blocks that would be required to store medical imaging studies.^27,28 More importantly, if a successful attack was ever developed against the encryption algorithm used to obfuscate the health records on the blockchain, all of the patient health information encrypted with that cipher would become public; the early blocks in the chain cannot be revoked or modified if, decades later, weaknesses are discovered in encryption methods or implementations. For this reason alone, it seems prudent to store only the minimum necessary metadata on what is essentially a distributed, public database.

Linn and Koo²⁶ have outlined a general framework similar to that presented here, in which the blockchain is used to store access control lists. They require, however, that all health records be encrypted and uploaded to a third party “data lake.” It is unclear what entity would be responsible for hosting such a large data store and for what motivation. The authors claim that such a collection would be useful for general data mining and machine learning; however, in the current state-of-the-art, computations on encrypted data remain prohibitively time-intensive except in very limited special cases.^29,30 In addition, entrusting a third party with encrypted health information raises the same concerns mentioned previously regarding the consequences in the setting of future advances in cryptanalysis.

In addition, we note that some have promoted the concept of “private” blockchains in which participation is limited to a set of trusted organizations.^31,32 This approach may be useful in the exploratory stage as institutions examine the feasibility of blockchain technologies for various applications. In addition, this architecture may be preferred in research settings—for example, the ModelChain framework utilizes a private blockchain to enable multiple institutions to contribute health data to train a machine-learning model without disclosing their individual health records.³² Ideally, however, solutions should be favored that eliminate single or limited points of failure. Our proposed solution is not optimal in this sense, either; it may be argued that by linking block generation to reimbursement rates, the image sharing blockchain would indirectly be controlled by and susceptible to the decisions of relatively few large payers and imaging centers.

Finally, we acknowledge the efforts of the HEART Working Group in developing the the User-Managed Access (UMA) profile.³³ This represents a unique approach to distributing access control that divides the role of the image source into that of a resource server, which stores and provides the images, and an authorization server, which verifies that requesting parties have access to the images. UMA provides many of the same benefits as the blockchain architecture, and it also suffers from similar limitations. However, the decoupling of authorization from the image source raises the question of what incentive drives the operators of the authorization servers. If there is not sufficient benefit to be gained from providing such a service, the UMA scheme has the potential to degenerate into a more centralized network.

Conclusion

We have reviewed the basic principles of blockchain technologies and provided an overview of a blockchain implementation that may serve as a tool to enable the patient-controlled, cross-domain sharing of medical images without the need for a central authority. There are a number of unique advantages to such an approach and we have specifically highlighted the ways in which the blockchain satisfies many of the requirements of an interoperable health system. However, there are also several important limitations to this technology, and it will be essential to remain cognizant of these and to consider the relative merits of available alternatives prior to embarking upon any large-scale implementation of a blockchain as a basis for sharing health information.

Footnotes

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article.

ORCID iD

Vishal Patel

References

Pandharipande

Reisner

Binder

, et al. CT in the emergency department: a real-time study of changes in physician decision making. Radiology 2016; 278(3): 812–821.

Patel

Barker

Siminerio

ONC data brief, no. 30: trends in consumer access and use of electronic health information. Washington, DC: Office of the National Coordinator for Health Information Technology, 2015.

Erickson

BJ.

Experience with importation of electronic images into the medical record from physical media. J Digit Imaging 2011; 24(4): 694–699.

Langer

Tellis

Carr

, et al. The RSNA image sharing network. J Digit Imaging 2015; 28(1): 53–61.

Mendelson

DS.

Sharing medical images with patients & providers with RSNA image share validation (The Sequoia Project). Chicago, IL: Healthcare Information and Management Systems Society, 2016.

Nakamoto

Bitcoin: a peer-to-peer electronic cash system, 2008, http://bitcoin.org/bitcoin.pdf. (accessed 5 October 2016).

King

Nadal

PPCoin: peer-to-peer crypto-currency with proof-of-stake, 2012, https://peercoin.net/assets/paper/peercoin-paper.pdf (accessed 5 October 2016).

Nxt Community. Whitepaper:Nxt, 2016, https://nxtwiki.org/wiki/Whitepaper:Nxt (accessed: 5 October 2016).

Kamauu

Duvall

Avrin

DE.

Using Java to generate globally unique identifiers for DICOM objects. J Digit Imaging 2009; 22(1): 11–14.

10.

FontAwesome. Icons used and adapted under the CC-BY-4.0 license, 2017, https://fontawesome.com/license (accessed 27 August 2017).

11.

IHE International. IHE IT infrastructure technical framework, 2016, http://www.ihe.net/Technical_Frameworks/ (accessed 5 October 2016).

12.

Bartel

Boyer

Fox

, et al. XML signature syntax and processing. 2nd ed, 2008, https://www.w3.org/blog/news/archives/288 (accessed 5 October 2016).

13.

Zamfir

Introducing Casper “the friendly ghost,”

https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/ (accessed 5 October 2016).

14.

Office of the National Coordinator for Health Information Technology. Connecting health and care for the nation: a shared nationwide interoperability roadmap, 2015, https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf

15.

Morris

Farnum

Afzal

, et al. Patient identification and matching final report. Washington, DC: Office of the National Coordinator for Health Information Technology, 2014.

16.

Tallinn

Pihl

100 million digital signatures will be issued in Estonia in the near future, 2012, https://www.id.ee/index.php?id=30609&read=36057

17.

Gropper

Powering the physician-patient relationship with HIE of one blockchain health IT, 2016, https://www.healthit.gov/sites/default/files/7-29-poweringthephysician-patientrelationshipwithblockchainhealthit.pdf (accessed 27 August 2017).

18.

Prakash

Adoption of blockchain to enable the scalability and adoption of accountable care, 2016, https://www.healthit.gov/sites/default/files/13-71-blockchain_for_healthcare_paper_final.pdf (accessed 27 August 2017).

19.

U.S. Government Publishing Office. Code of federal regulations. Annual ed. Washington, DC: Office of the Federal Register, National Archives and Records Administration, 2015.

20.

Awan

Fossett

, et al. Patient engagement: the experience of the RSNA image share patient help desk. J Am Coll Radiol 2015; 12(12 Pt A): 1289–1292.

21.

Angraal

Krumholz

Schulz

WL.

Blockchain technology: applications in health care. Circ Cardiovasc Qual Outcomes 2017; 10(9): e003800.

22.

Kuo

Kim

Ohno-Machado

Blockchain distributed ledger technologies for biomedical and health care applications. J Am Med Inform Assoc 2017; 24(6): 1211–1220.

23.

Mettler

Blockchain technology in healthcare: the revolution starts here. In: Proceedings of the IEEE 18th international conference on e-health networking, applications and services (Healthcom), 2016, Munich, 14–6 September 2016, pp. 1–3. New York: IEEE.

24.

Yue

Wang

Jin

, et al. Healthcare data gateways: found healthcare intelligence on blockchain with novel privacy risk control. J Med Syst 2016; 40(10): 218.

25.

Ivan

Moving toward a blockchain-based method for the secure storage of patient records, 2016, https://www.healthit.gov/sites/default/files/9-16-drew_ivan_20160804_blockchain_for_healthcare_final.pdf (accessed 27 August 2017).

26.

Linn

Koo

Blockchain for health data and its potential use in health IT and health care related research, 2016, https://www.healthit.gov/sites/default/files/11-74-ablockchainforhealthcare.pdf (accessed 27 August 2017).

27.

Wilkinson

Lowry

MetaDisk: a blockchain-based decentralized file storage application, 2014, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.692.8781&rep=rep1&type=pdf (accessed 26 August 2017).

28.

Croman

Decker

Eyal

, et al. On scaling decentralized blockchains. Berlin; Heidelberg: Springer, 2016, pp. 106–125.

29.

Wang

Chen

, et al. Accelerating fully homomorphic encryption using GPU. In: Proceedings of the IEEE conference on high performance extreme computing, Waltham, MA, 10–12 September 2012, pp. 1–5. New York: IEEE.

30.

Dowlin

Gilad-Bachrach

Laine

, et al. CryptoNets: applying neural networks to encrypted data with high throughput and accuracy (Microsoft Research), 2016, http://proceedings.mlr.press/v48/gilad-bachrach16.pdf

31.

Azaria

Ekblaw

Vieira

, et al. MedRec: using blockchain for medical data access and permission management. In: Proceedings of the international conference on open and big data (OBD), Vienna, 22–24 August 2016, pp. 25–30. New York: IEEE.

32.

Kuo

Hsu