Blockchain-based Bidirectional Updates on Fine-grained Medical Data
BBlockchain-based Bidirectional Updates onFine-grained Medical Data
Chunmiao Li , Yang Cao , Zhenjiang Hu , Masatoshi Yoshikawa National Institute of Informatics, Japan Kyoto University, Japan SOKENDAI (The Graduate University for Advanced Studies), Japan University of Tokyo, Japan
Abstract —Electronic medical data sharing between stakehold-ers, such as patients, doctors, and researchers, can promote moreeffective medical treatment collaboratively. These sensitive andprivate data should only be accessed by authorized users. Given atotal medical data, users may care about parts of them and otherunrelated information might interfere with the user-interesteddata search and increase the risk of exposure. Besides accessingthese data, users may want to update them and propagate toother sharing peers so that all peers keep identical data after eachupdate. To satisfy these requirements, in this paper we propose amedical data sharing architecture that addresses the permissioncontrol using smart contracts on blockchain and splits data intofined-grained pieces shared with different peers then synchronizefull data and these pieces with bidirectional transformations.Medical data reside on each user’s local database and permission-related data are stored on smart contracts. Only all peers havegained the newest shared data after updates can they start todo next operations on it, which are enforced by smart contracts.Blockchain-based immutable shared ledge enables users to tracedata updates history. This paper can provide a new perspectiveto view full medical data as different slices to be shared withvarious peers but consistency after updates between them are stillpromised, which can protect privacy and improve data searchefficiency.
Index Terms —medical data, blockchain, update, bidirectionaltransformations
I. I
NTRODUCTION
Now a lot of medical data are digitalized so as to be storedand accessed conveniently. A medical record is producedafter a patient goes to see a doctor and often resides on thehospital’s database. Medical records usually contain highlysensitive information about patient privacy. HIPPA PrivacyRule [1] in the U.S. regulates the use and disclosure ofpersonally identifiable health information to protect patients’privacy. However, it is hard to make sure that all medicalinstitutes would follow these rules because they may exposepatient privacy for profit. Hence, transparency in medical datamanagement system is important. Moreover, patients mightvisit different hospitals and leave their records scattered [2]in different places, so that it is hard for them to managerecords efficiently. Patients should better to be provided witha platform to manage and review their historical medical datathat are from different hospitals in case of exposure or beingtampered. In addition to providing data to doctors, sharingmedical data could also benefit other stakeholders such asresearchers or policy makers. For example, researchers can identify public health risks and then develop better treatmentby analyzing large-scale medical data [3].To protect patients’ data from being exposed or tampered,shared medical data could reside in encrypted formats on atrusted cloud storage server and can only be accessed byauthorized users. However, in that case, centralized accesscontrol might lead to a single point of failure and becomethe bottleneck of the sharing system. Some decentralizedmedical data sharing systems [4]–[6] have been proposed tomanage authentication based on blockchain [7] technology,which achieves consensus among distributed nodes. The ac-cess control logic of medical data on smart contracts [4] orChaincode [8] can be used as a criterion to judge whethera user can be allowed to access medical data. Only a usersatisfies that permission information can his access be agreedby the majority of nodes, which means he is authorized fromthe blockchain side.Still, we identified a limitation on current works. Considerthat a full medical record can have many attributes, whiledifferent parties may be only interested in specific parts ofthem. For example, given a medical record, researchers areinterested in the attribute of the mechanism of medicineaction, whereas patients care more about the medicine dosagestandard attribute. Moreover, additional but unnecessary in-formation might influence or even mislead users’ judgment.Imagine that doctors may add some symptom description onrecords which might put patients in confusion and fear [9].Besides, treatment steps are exclusive to a hospital and shouldnot be directly accessed by other users.To fill this gap, we propose an idea that a full medical data(i.e., data source) could be split into lots of smaller pieces (i.e.,data views). From the perspective of relational databases, thesekinds of smaller pieces can be seen as view tables derivedby querying a few but not all attributes on the base (source)table. A user can share different fine-grained data pieceswith different users based on predefined protocols. Imaginea doctor can share dosage usage with a patient and medicinemechanism with a researcher respectively. In this way, onlyuser-concerned data are exposed to them which can avoidadditional data interference and protect private proprietary dataof data providers from being leaked.However, if we adopt this idea, we have to dispose of twoissues as follow.Firstly, we need to handle the synchronization between a r X i v : . [ c s . S E ] A p r ource and multiple views after updates on those fine-grainedviews occur. Consider this scenario: a researcher updates themedicine mechanism on shared data with a doctor. Note herethe shared data is actually a view from the full medicaldata (source) on the doctor side. Thus the doctor needs tosynchronize this change on view to create a new source. Tosolve this problem, we apply bidirectional transformations[10] to synchronize them after updates on either one side.For example, we can invoke put direction of a BX programto reflect modifications on shared data in the full data and get to produce shared data from full data. Because differentviews produced from the same source might have overlappingdata. After the updates on shared data are reflected to doctor’ssource, the doctor still has to judge whether he needs to modifythe shared data with patients by reproducing a new view.Secondly, we need to conduct access control on fine-grainedview data. Existing blockchain-based access control solutions,such as [4], focused on permission control on the full record.However, we can adapt it to work with the fine-grainedviews. For example, we can encode permission informationof views into smart contracts. Shared data management shouldbe conducted after the peer has been authorized.In this paper, our contributions are as follows.1) We proposed an idea that a full medical record can bepartitioned to multiple fine-grained data pieces sharedwith different peers and all data should reside on eachuser’s local database.2) We solved the data synchronization between a full recordand fine-grained data views after updates on a view bybidirectional transformation technology.3) We designed a decentralized medical data sharing archi-tecture and applied blockchain to control permission forfine-grained data views.The remainder is organized like this. Section II gives somepreliminaries about blockchain and bidirectional transforma-tions. Section III sketches our system design and providesan implementation architecture. Section IV discuss securitythreats of our system and potential countermeasures as ourfuture work. Section V compares our work with existing onesto clarify our improvement over them. Section VI concludesand directs our future work.II. P RELIMINARIES
A. Blockchain
Proposed with Bitcoin [7] in 2008, blockchain technologyhas been widely used in many fields. Blockchain provides asolution for data storage, data transfer and consensus protocolin a distributed and decentralized environment. Generallyspeaking, blockchain is a shared ledger and replicated byall nodes on a distributed network, which records the validhistorical transactions in chronologically chained blocks. Thenodes which generate new blocks by solving a computationalpuzzle (the proof-of-work problem) are called miners.Not only can support the platform of cryptocurrency, butblockchain can also be applied to other scenes. Ethereum [11] extends Bitcoin with a built-in Turing-Complete programminglanguage so that one can use this scripts (i.e., Ethereum VirtualMachine (EVM) bytecodes) to write programs (i.e., smartcontracts ) on the blockchain. For example, we can writea smart contract in Solidity and then compile it to EVMcode. Besides the user accounts controlled by private keyslike in Bitcoin, the accounts for smart contracts are allowedin Ethereum. Anyone can build decentralized applicationswhich consist of a collection of smart contracts. Once atransaction involving smart contract creation gets confirmed,an address is generated for the contract and later anyone cansend transactions to this address to execute the programs on it.A smart contract transaction is enforced when a miner includesit in a new produced block. Other nodes will validate it andre-run contracts if it is valid. B. Bidirectional transformations
Maintaining consistency between different data represen-tations having overlapping contents is important [12]. Forexample, in databases, a view table can be produced byquerying a base source table; this view table can be modified,in which case we will want to “restore consistency”, i.e.,we need to change the source such that the modified viewcoincides with the result of the query on the changed source —this is the well-known view update problem [13]. To achievethis, one may consider providing two separate programs torepresent the two directions to propagate updates from oneside to the other. But it is hard to prove that the source andview can still be kept consistent after updates. Bidirectionaltransformations (BXs) were proposed [14] to solve this.BX programs can be invoked in two ways as forward andbackward transformations. A forward transformation (denotedas get ) extracts some information from the source to build anabstract view, and the backward transformation (denoted as put ) embeds information of the view back into the sourceand produces an updated source. This pair of transformationsshould satisfy the round-tripping laws (also referred to as well-behaveness ) called PutGet and
GetPut . get ( put ( source , view )) = view ( PutGet ) put ( source , get ( source )) = source ( GetPut )Intuitively,
GetPut states that no update should be performedon the source when there is no change on the view, while
PutGet hints that put should take all updates on the viewinto account so that the view can be regenerated from theupdated source by get . The most distinguished point of BXis that a view can contain only a part of a source. Withrespect to some consistency between a source and a view,BX programs can synchronize the source and view, and theirwell-behavedness guarantees that the source and view are Hyperledger and others still provide platforms to write smart contracts. https://solidity.readthedocs.io/en/v0.5.2/ The BXs we refer to in this paper are asymmetric lenses [15], one of thesynchronization models studied by the BX community. put is not a simple inverse of get . Instead, it accepts the view and theoriginal source as input and produces an updated source as output. ept consistent after updates on either side. There are somelanguages for constructing well-behaved BX programs, suchas Boomerang [16], BiGUL [17] and HOBiT [18].III. S YSTEM ARCHITECTURE
In this section, we first describe a scenario of distributedmedical data sharing among doctor, patient, and researcherin Section III-A and propose a system architecture to modelthis scenario in Section III-B. Then we present the solutionsfor synchronization between full medical record and viewsusing BXs and access control on views applying blockchainin Section III-C. Our system can not only allow updates onshared data but other operations such as creating data, whichare described in Section III-D and explained by a concretecase in Section III-E.
A. Scenario description
Table ”Full medical records” in Figure 1 shows patients’ fullmedical records which includes seven attributes: a0. patient ID,a1. medication name, a2. clinical Data, a3. address, a4. dosage,a5. mechanism of action, a6. mode of action. Suppose there arethree users: Patient, Researcher, and Doctor. Each user onlystores some attributes of full records on their local databases.For instance, Patient only keeps the attributes from a0 to a4on Table D1 and Researcher retains attribute a1, a5 and a6 onTable D2. Doctor manages attributes a0-a2, a4, and a5 on TableD3 and generates two view tables D31 and D32 by queryingspecial attributes from D3. D31 and D32 are used to be sharedwith Patient and Researcher respectively. Note that D13 andD31 are identical tables but D13 is stored in Patient’s databaseand D31 resides in Doctor’s database. Similarly, attributes a1and a5 are shared between Researcher and Doctor, which areshown in the view Table D23 on Researcher’s database andTable D32 on Doctor’s storage. We note that the formats andcontents of shared data are predefined by sharing peers.
B. System architecture
Our system architecture is shown in Fig. 2, which containsfollowing components: • Client side controls the interaction between users andother components. • Server App acts as a mediator to interact with othercomponents. • Blockchain keeps the manage permission of shared dataon smart contracts and notifies sharing peers the changeon them. • Database manager disposes of the synchronization be-tween shared data and local data according to consistencylogic relations. These synchronizations are implementedby executing BX programs. • Database : each user has a full database and many datapieces shared with other users. The latter (seen as a view)can always be reproduced from the former (seen as asource).Now we discuss details about this architecture. a0. Patient ID a1. MedicationName a2. Clinical Data a3. Address a4. Dosage188 Ibuprofen CliD1 Sapporo one tablet every 4hD1 (Patient)a0. Patient ID Medication Name Clinical Data Mechanism of Action Dosage188 Ibuprofen CliD1 MeA1 one tablet every 4h189 Wellbutrin CliD2 MeA2 100 mg twice dailyD3 (Doctor)a0. Patient ID a1. Medication Name a2. Clinical Data a4. Dosage188 Ibuprofen CliD1 one tablet every 4hD13 (also D31)a1. Medication Name a5. Mechanism of Action a6. Mode of ActionIbuprofen MeA1 MoA1Wellbutrin MeA2 MoA2D2 (Researcher) D23 (also D32)a1. Medication Name a5. Mechanism of ActionIbuprofen MeA1Wellbutrin MeA2Full medical recordsa0. Patient ID a1. MedicationName a2. Clinical Data a3. Address a4. Dosage a5. Mechanism of Action a6. Mode of Action188 Ibuprofen CliD1 Sapporo one tablet every 4h MeA1 MoA1189 Wellbutrin CliD2 Osaka 100 mg twice daily MeA2 MoA2a0. Patient ID a1. Medication Name a2. Clinical Data a5. Mechanism of Action a4. Dosage188 Ibuprofen CliD1 MeA1 one tablet every 4h189 Wellbutrin CliD2 MeA2 100 mg twice daily
Fig. 1. Data distribution
Researcher
Client sideServer sideServer AppBXBXDatabase ManagerBlock Block Block Block BlockBlockchain Doctor Client sideServer sideServer AppDatabase ManagerBXBXSend updated dataRequest updated data
Fig. 2. System Architecture irstly, medical data always stay in each peer’s localdatabase and data transfer only exists between sharing peers,which avoid data being leaked to the third party so as to keepshared data security. The data can not only be provided bydoctors. Instead, each node can be a shared data provider. Asreferred in [19], many clinics encourage patients to collect databy themselves that are supposed to be gathered by doctorsand expect to increase clinic efficiency and promote patientawareness.Moreover, blockchain’s consensus protocol scheme keepsthe shared data between sharing peers the same after updatessince each peer will receive the notification from contracts andrequest new shared data from other sharing peers. Additionally,any modification on shared data can be recorded on theblockchain. Blockchain properties such as immutability, au-ditablility, and transparency enable nodes to check and reviewupdate history on shared data. Still, simultaneously updates tothe same shared data by multiple peers are forbidden. Smartcontracts dispose of the updates according to received requestsin chronological order. If a transaction for updates on shareddata has been included in a block, then other requests on thisshared data will not be accepted, i.e., one block can containone transaction at most on some shared data at one time. Thiscan promise that only when all sharing peers have had thenewest shared data can they execute further operations.
C. System design1) Synchronization between source and views:
As we saidbefore, BX programs are used to synchronize the full data andshared data. Shared data can be seen as views which can beproduced from full records named as sources. For examplein Fig. 1, Table D13 is shared by Patient and Doctor andcan be produced from D1 by BX -get (i.e., applying the getdirection of the BX program between D1 and D13). If D13 ismodified, then D1 need to be updated from original D1 andD13 by using BX -put (i.e., invoking put the direction of theBX program between D1 and D13) to ensure that the modifiedD13 can be regenerated from the updated D1.In our design, shared data between any two peers arenot exposed to the third party, which can keep data privacybetween them to some degree. For example, any operations onD23 or D32 can only be known by Researcher and Doctor andPatient has no information about this. However, If D31 andD32 have some overlapping data, after D32 is modified, D31might need to be regenerated by using BX -get on modifiedD3 which can be produced by applying BX -put .
2) Access control on views:
Figure 3 presents a metadatacollection table which dictates the update permission on eachattribute of the shared data. These kinds of tables residein smart contracts on the blockchain. Each metadata entrycorresponds to a shared table. For example, the entry for D13or D31 declares that it is shared by Patient and Doctor andDoctor can update all attributes value but Patient can onlychange the clinical data. The “Latest Update Time” showswhen the metadata was modified most recently. The value onthe attribute “Authority to Change Permission” indicates the
Metadata ID Sharing peers Write permission Last Update Time Authority to change permissionD13 & D31 Patient, Doctor 2018.12.22 DoctorD23 & D32 Doctor, Researcher 2018.12.23 ResearcherMedication Name Dosage Clinical DataDoctor Doctor Patient, DoctorMedication Name Mechanism of ActionDoctor, Researcher Researcher
Fig. 3. Metadata collection in smart contract user who can modify other users’ permission. For instance,because D13 and D31 are initially produced by Doctor andshared with Patient and then Doctor can change Patient’saccess permission. Doctor can change the permission forupdating “Dosage” from “Doctor” to “Doctor, Patient” so thatPatient can also update the “Dosage” later.If users want to share data, they need to form an agreementon the structure of the shared table and register the correspond-ing metadata on smart contracts. Suppose Doctor initiates thedata sharing with Patient. According to their agreement, hewill deploy a smart contract on blockchain which stipulatesthe metadata about the shared data, such as sharing peers (i.e.,Patient and Doctor) and so on.
D. Data Management
In Fig. 4, we briefly sketch the procedures for CRUD(i.e., Create, Read, Update, Delete) operations on shared dataconsidering entry level or table level. For Read operation, sinceshared data stay in users’ local databases, they can just executea query to get the shared data. We describe the workflow forupdating an item on Section III-E.
Researcher
Client sideServer sideServer AppBXBXDatabase ManagerBlock Block Block Block BlockBlockchain Doctor Client sideServer sideServer AppDatabase ManagerBXBXSend updated dataRequest updated data
Entry Level/ Table LevelCreate, Update, Delete 1. A user tries to execute operation locally and send a request (a transaction) to smart contract.2. Smart contracts verify permission.3. If this user is authorized then execute following steps. (If permission denied, then this request failed)4. Smart contracts notify sharing peers of modification.5. Sharing peers fetch this update on shared data.6. Update metadata on contract.7. Sharing peers conduct BX programs to reflect the change on shared data in complete data.Read Query local database directly
Fig. 4. CRUD operations on shared data . Case analysis for updating shared data
Figure 5 depicts a scenario where the researcher initiatesthe update the shared data. We use notations in Fig. 1. Thenumbers indicate the corresponding operations sequence. Thered and blue circles indicate the updated places. Steps 1 - 5and Steps 7 - 11 perform procedures for an operation on Fig.4. Notably, Step 6 checks whether D32 and D31 have somedependencies since they might have some overlapping data.Our work leaves the initialization of shared data to future workand we only consider management on existing shared data.
Doctor Researcher Patient
Blockchain
D3 D32D31 BX - get BX - put D13D1 BX - put D23D2 BX - get Smart Contract
123 4567891011 BX - get nodenodenode nodenode nodenode Fig. 5. A workflow for updating data fields of shared data
Let us try to describe this workflow using the data in Fig. 1.After updating the “MeA1” on D2, the Researcher wants topropagate the update to the shared data D23 so he uses the BX -get to regenerate D23 (Step 1). Then he will call asmart contract via a trusted node connected to blockchain bysending the request for updates to the D23 (Step 2). Notethat the smart contract in Fig. 3 records all permission infoabout that D23. The smart contract will be executed until allnodes form a consensus on this update request, which meansResearcher is permitted to update D23. Each node will conductthe smart contract locally. The entry related D23 & D32 of thecontract is modified and the Doctor will receive notificationthat D32 needs to be modified (Step 3). Then he will ask fordata from Researcher by sending a data request message anduse the latest shared data to refresh D32 (Step 4). After that,Doctor will use BX -put to reflect the change on D32 inD3, i.e., update the “MeA1” to a new name (Step 5). SinceDoctor shared some data (D31) with Patient, he needs to checkwhether D31 needs to be reproduced (Step 6). (If there is noneed to reproduce, Step 6 - 11 will not be performed.) Forexample, Doctor may want to modify the “Dosage” on D31.He will use BX -get to regenerate D31 (Step 7) and requestsmart contract for permission to update D13 (Step 8). Onceallowed, Patient will receive a notification about the change on “Dosage” (D31) (Step 9) and ask Doctor to send the updatedD31. After Patient gets the modified D31 (Step 10), he willuse this to update D1 via BX -put (Step 11).IV. T HREATS AND COUNTERMEASURES
In this section, we identify some threats to our system andpropose relating countermeasures.
1) Throughput:
We might employ smart contracts to controlaccess to shared data. Usually, the block creation time isapproximately 12 seconds on Ethereum. We argue that thistime interval is acceptable since nodes may choose to collecta lot of updates and then send requests to contracts. It is notso urgent for a patient or doctor to get the immediate updatedshared data.
2) Correctness of smart contracts:
Smart contracts mightbe inconsistent with specifications. We may apply some theo-rem prover such as Coq [20] to verify the correctness of smartcontracts to prevent these attacks.
3) Public blockchain:
Once deployed to the publicEthereum blockchain, transactions related to our systemsmight not be chosen into a block by miners. So a privateblockchain might be a better choice for our system.
4) Incentive:
Like in [21], we do not include any incentivefor mining beyond the use of our system. We presume thatall nodes on the blockchain already have incentives to keepmedical data from being illegal access or updates.V. R
ELATED WORK
In this section, we review existing blockchain-based re-search on the medical data sharing field and list the advantagesof our system compared with them.The idea of introducing Blockchain technology to healthcarewas presented firstly in [22] where they use blockchain fordata storage to guarantee that medical data cannot be modifiedby anyone. Also, they designed a Healthcare Data Gateway(HDG) to control access to the shared data. However, themedical data size can become huge so that the data becomeburdens for blockchain nodes’ storage since each node hasthe same copy of blockchain. Usually, the size of metadata issmaller than data. (It also depends on the structure of metadataand data.) We store metadata on smart contracts so as to reducethe storage pressure for each blockchain node.MedRec [4] chose to store raw medical data on providers’database and patients can download the data from it afterauthorized by smart contracts on the blockchain. They aimedto enable patients to engage in their healthcare. Whereas in oursystem, all parties, such as doctors, patients, and researcherscan benefit from sharing data with others. MedRec recognizedthat not all provider data such as physician intellectual prop-erty can be exposed to patients [23], [24] so that they donot claim to manage contents automatically from physician’soutput. Instead, we allow each node to share a piece of medicaldata not total but still keep consistency between them after theupdates to the shared ones. Additionally, any modifications ondata shared by two nodes will not be disclosed to the thirdparty which keeps the consistency only exists in sharing peers.oreover, since all shared data with others can be a part ofeach nodes’ local total databases, we can decide whether oneshared data have some influence on the other shared piecesand then propagate this change to the third party.Dubovitskaya et al. gave an architecture for managing andsharing medical data for cancer patient care [8]. They storedencrypted categorized shared data on the cloud and relatedmetadata in blockchain and implemented the prototype onHyperledger [25]. The access control policy is defined in thechaincode Logic by patients. Whereas we think that each dataprovider, not just patients can use smart contracts to encodethe control policy when they deploy them to blockchain.Notably, these three solutions and others [5], [6], [21], [26],[27] mostly targeted the access problem on shared data but didnot pay much attention to updates on them. Additionally, theypresumed that different parties can share the same data. Unlikethem, we aim to solve the update issues on the shared dataand allow one party to split full data (i.e., source) into multiplepieces (i.e, views) which are shared with different parties butstill keep consistency between source and views.VI. C
ONCLUSION
Medical data sharing is necessary and important, whichallows stakeholders on medical scenarios to contribute theirknowledge to better the medical treatment. Users may havedifferent interests in the same full medical record. Somepeers might update some values of fields in the existing data.These updates need to be propagated to sharing peers. Ourarchitecture divides a record into pieces that shared withdifferent users separately, which can protect data privacy bylimiting essential data between two peers and reduce theunrelated data interference. Any updates on data pieces can besynchronized to full records by bidirectional transformations.Moreover, based on smart contracts on the blockchain, wecan promise that only authorized users can update the existingshared data and only when all peers have updated to the latestdata contents can they continue the operations on shared data.We are still developing the prototype to implement our idea.In the future, we will use real patient data to do experimentsbut use some de-identification technology to protect patientdata from being exposed.R
EFERENCES[1] H. Centers for Medicare & Medicaid Services et al. , “Hipaa adminis-trative simplification: standard unique health identifier for health careproviders. final rule.”
Federal register , vol. 69, no. 15, p. 3433, 2004.[2] J. Zhang, N. Xue, and X. Huang, “A secure system for pervasive socialnetwork-based healthcare,”
IEEE Access , vol. 4, pp. 9239–9250, 2016.[3] O. of the National Coordinator for Health Information Technology,“Report to congress: Report on health information blocking,” 2015.[4] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “Medrec: Usingblockchain for medical data access and permission management,” in
Open and Big Data (OBD), International Conference on . IEEE, 2016,pp. 25–30.[5] K. Fan, S. Wang, Y. Ren, H. Li, and Y. Yang, “Medblock: Efficient andsecure medical data sharing via blockchain,”
Journal of medical systems ,vol. 42, no. 8, p. 136, 2018.[6] Q. Xia, E. B. Sifah, A. Smahi, S. Amofa, and X. Zhang, “Bbds:Blockchain-based data sharing for electronic medical records in cloudenvironments,”
Information , vol. 8, no. 2, p. 44, 2017. [7] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[8] A. Dubovitskaya, Z. Xu, S. Ryu, M. Schumacher, and F. Wang, “Secureand trustable electronic medical records sharing using blockchain,” in
AMIA Annual Symposium Proceedings , vol. 2017. American MedicalInformatics Association, 2017, p. 650.[9] T. Delbanco, J. Walker, J. D. Darer, J. G. Elmore, H. J. Feldman, S. G.Leveille, J. D. Ralston, S. E. Ross, E. Vodicka, and V. D. Weber, “Opennotes: doctors and patients signing on,”
Annals of internal medicine , vol.153, no. 2, pp. 121–125, 2010.[10] Z. Hu, H. Pacheco, and S. Fischer, “Validity checking of putbacktransformations in bidirectional programming.” in FM , 2014, pp. 1–15.[11] G. Wood, “Ethereum: A secure decentralised generalised transactionledger.”[12] F. Abou-Saleh, J. Cheney, J. Gibbons, J. McKinna, and P. Stevens,“Introduction to bidirectional transformations,” in Bidirectional Trans-formations . Springer, 2018, pp. 1–28.[13] F. Bancilhon and N. Spyratos, “Update semantics of relational views,”
ACM Transactions on Database Systems (TODS) , vol. 6, no. 4, pp. 557–575, 1981.[14] K. Czarnecki, J. N. Foster, Z. Hu, R. L¨ammel, A. Sch¨urr, and J. F.Terwilliger, “Bidirectional transformations: A cross-discipline perspec-tive,” in
International Conference on Theory and Practice of ModelTransformations . Springer, 2009, pp. 260–283.[15] J. N. Foster, M. B. Greenwald, J. T. Moore, B. C. Pierce, andA. Schmitt, “Combinators for bidirectional tree transformations: Alinguistic approach to the view-update problem,”
ACM Transactions onProgramming Languages and Systems (TOPLAS) , vol. 29, no. 3, p. 17,2007.[16] A. Bohannon, J. N. Foster, B. C. Pierce, A. Pilkiewicz, and A. Schmitt,“Boomerang: resourceful lenses for string data,” in
ACM SIGPLANNotices , vol. 43, no. 1. ACM, 2008, pp. 407–419.[17] H.-S. Ko, T. Zan, and Z. Hu, “BiGUL: A formally verifiedcore language for putback-based bidirectional programming,” in
Proceedings of the 2016 ACM SIGPLAN Workshop on PartialEvaluation and Program Manipulation , ser. PEPM ’16. NewYork, NY, USA: ACM, 2016, pp. 61–72. [Online]. Available:http://doi.acm.org/10.1145/2847538.2847544[18] K. Matsuda and M. Wang, “Hobit: Programming lenses without usinglens combinators,” in
European Symposium on Programming . Springer,2018, pp. 31–59.[19] C.-F. Chung, “Using personal informatics data in collaboration amongpeople with different expertise,” Ph.D. dissertation, 2018.[20] G. Huet, G. Kahn, and C. Paulin-Mohring, “The coq proof assistant atutorial,”
Rapport Technique , vol. 178, 2004.[21] G. G. Dagher, J. Mohler, M. Milojkovic, and P. B. Marella, “Ancile:Privacy-preserving framework for access control and interoperabilityof electronic health records using blockchain technology,”
SustainableCities and Society , vol. 39, pp. 283–297, 2018.[22] X. Yue, H. Wang, D. Jin, M. Li, and W. Jiang, “Healthcare datagateways: found healthcare intelligence on blockchain with novel privacyrisk control,”
Journal of medical systems , vol. 40, no. 10, p. 218, 2016.[23] U. D. of Health, H. Services et al. , “Individuals right under hipaa toaccess their health information 45 cfr 164.524,” 2017.[24] C. Grossman, W. A. Goolsby, L. Olsen, and J. M. McGinnis, “Clinicaldata as the basic staple of health learning: creating and protecting apublic good,”
Washington, DC: Institute of Medicine , 2011.[25] Hyperledger, “Hyperledger,” 2017.[26] J. Liu, X. Li, L. Ye, H. Zhang, X. Du, and M. Guizani, “Bpds: Ablockchain based privacy-preserving data sharing for electronic medicalrecords,” arXiv preprint arXiv:1811.03223 , 2018.[27] S. Amofa, E. B. Sifah, O.-B. Kwame, S. Abla, Q. Xia, J. C. Gee, andJ. Gao, “A blockchain-based architecture framework for secure sharingof personal health data,” in2018 IEEE 20th International Conference one-Health Networking, Applications and Services (Healthcom)