| Literature DB >> 30069284 |
William J Gordon1,2,3, Christian Catalini4,5.
Abstract
Interoperability in healthcare has traditionally been focused around data exchange between business entities, for example, different hospital systems. However, there has been a recent push towards patient-driven interoperability, in which health data exchange is patient-mediated and patient-driven. Patient-centered interoperability, however, brings with it new challenges and requirements around security and privacy, technology, incentives, and governance that must be addressed for this type of data sharing to succeed at scale. In this paper, we look at how blockchain technology might facilitate this transition through five mechanisms: (1) digital access rules, (2) data aggregation, (3) data liquidity, (4) patient identity, and (5) data immutability. We then look at barriers to blockchain-enabled patient-driven interoperability, specifically clinical data transaction volume, privacy and security, patient engagement, and incentives. We conclude by noting that while patient-driving interoperability is an exciting trend in healthcare, given these challenges, it remains to be seen whether blockchain can facilitate the transition from institution-centric to patient-centric data sharing.Entities:
Keywords: Application programming interface; Blockchain; Clinical data; Data exchange; Interoperability
Year: 2018 PMID: 30069284 PMCID: PMC6068317 DOI: 10.1016/j.csbj.2018.06.003
Source DB: PubMed Journal: Comput Struct Biotechnol J ISSN: 2001-0370 Impact factor: 7.271
Fig. 1(A) Example of institution-driven interoperability for clinical EHR data. Bi-directional clinical data exchange occurs (i) through an intermediary like a Regional Health Information Organization (RHIO) or (ii) directly between health care organizations with specific business agreements. In both cases, data interfaces are entity-to-entity, not entity-to-patient. In this example, since organization #2 and #3 do not have a specific relationship, there is no bi-directional data flow; providers from organization #2 can request data from organization #3 via one-off requests (like a fax). If a patient receives care at all three organizations, their health data will be scattered across all three EHRs.
(B) Example of patient-driven interoperability. Data sharing centers on the patient; in this example, using patient-facing APIs, a patient can directly retrieve their clinical EHR data from organization #1 and organization #3. Once retrieved, the patient can share with other organizations directly. Data flow can be bidirectional. RHIOs and entity-to-entity relationships may still exist as parallel functions.
(C) Blockchain-enabled patient-driven interoperability. In this example, the patient can still retrieve data directly from organization #2; however, through blockchain-enabled smart contracts, the patient can authorize sharing of clinical EHR data between organization #2 and organization #3, which do not have a formal business relationship. The blockchain layer stores these authorization rules, along with patient public keys (to ensure entity resolution), as well as data access audit logs. Each organization will manage linking a patient's public key to their own internal enterprise master patient index system independently, and patients can update the smart contract-driven authorization rules as appropriate (for example, adding a new institution if they are seeing a new provider).
Blockchain features that could enable patient-driven interoperability, with examples.
| Blockchain Feature | Example of Application to Patient-Driven Interoperability |
|---|---|
| Digital access rules | Clinical data—stored off-chain or on-chain—is linked to the public key of a patient. The patient can use properties of the blockchain, like smart contracts, to assign access rules for the data. For example, authorizing release to a research patient registry for a fixed period of time. |
| Data aggregation | A patient connects to different institutional interfaces with institution-specific logins (like a patient portal), and provides that institution with their blockchain public key, along with permission to securely transmit data (or metadata) to the blockchain. Done across multiple institutions, clinical data (or references towards clinical data) can thus be aggregated using the technology. |
| Data liquidity | Highly time sensitive clinical data—for example, advanced care planning “code status” or medication allergies, can be published on a public blockchain, ensuring ready, liquid access to this information as appropriate. |
| Patient identity | Patients can manage their public keys—perhaps through a multi-sig wallet or mobile device—and use the public-key infrastructure (PKI) to establish their identity for retrieving clinical data from the blockchain, as well as adding new information (like home monitoring devices). PKI ensures providers and institutions can trust that the patient is generating the data. |
| Data immutability | Clinical data (or metadata) is securely distributed across multiple entities, ensuring integrity, lowering the risk of loss, and offering an audit trail (in case of malicious actor). Append-only model of blockchain ensures all providers with access to information have complete clinical picture. |
Barriers to blockchain-enabled patient-driven interoperability with mitigation.
| Challenge | Mitigation |
|---|---|
| Transaction volume of clinical data | Focus data exchange on summarized clinical data; for example, a radiology report instead of full DICOM images Permissioned blockchains for local geographies built to handle large transaction volumes without time-intensive validation New technologies and research in blockchain scaling methodologies |
| Privacy and security | Permissioned, member-only blockchain consortium to minimize public exposure Data storage off-chain, with on-chain focused around permissions or other meta-data |
| Patient engagement | Patient-friendly “app” ecosystem of intermediaries to manage public keys and permissions |
| Incentives | Continued federal incentives to expand API coverage, like VA data pledge Association of open data with value for reimbursement Competitive pressure of API-enabled systems to encourage non-enabled systems to invest in API infrastructure |