1

2
Interoperable Healthcare Using Smart Contracts and Proxy 59
60
3 Re-Encryption 61
4 62
5 63
6
Bhavye Sharma Jawar Singh Raju Halder 64
7
Maharaja Agarasen Institute of Indian Institute of Technology Patna Indian Institute of Technology Patna 65
8 Technology jawar@iitp.ac.in raju@iitp.ac.in 66
9 Rohini, Delhi 67
10 68
11
ABSTRACT 2 INTRODUCTION 69
12 A clear and well-documented LATEX document is presented as an Over the last decade the value of data has been realized, more and 70
13 article formatted for publication by ACM in a conference proceed- more organizations try to collect as much data about their users to 71
14 ings or journal publication. Based on the “acmart” document class, allow them to provide better services and learn from their behaviour. 72
15 this article presents and explains many of the common variations, Such a model allows for organizations with access to more data 73

.
as well as many of the formatting elements an author may use in gain and the edge over their competitors. Consent to access of data

n. ft
16 74
17 the preparation of the documentation of their work. is very loosely handled by many service providers, often storing 75

io ra
18 more information than required to avail their services leaving them 76
19 CCS CONCEPTS prime targets for many hackers and data breaches. 77

ut d
20 • Computer systems organization → Embedded systems; Re- Electronic Health Record (EHR) is a collection of digital data 78
dundancy; Robotics; • Networks → Network reliability. proposed by HITECH Act to provide meaningful insights to the data

ib ing
21 79
22 stored by hospitals while protecting data confidentiality, privacy 80
23 KEYWORDS and trust[ref][ref]. It allowed for electronic prescribing of medi- 81
cation, access control, protection of data integrity, encryption of
24
str rk 82
datasets, neural networks, gaze detection, text tagging
25 data in transit as well as at rest. The limitation of this Act was 83
26 ACM Reference Format: the lack of interoperability between two separate EHR schemes, 84
di o
27
Bhavye Sharma, Jawar Singh, and Raju Halder. 2018. Interoperable Health- hospitals were incetivised to implement this technology on their 85
or d w

care Using Smart Contracts and Proxy Re-Encryption. In Woodstock ’18: own and did not impose any restriction to data standards and cause
28 86
ACM Symposium on Neural Gaze Detection, June 03–05, 2018, Woodstock, NY . ambiguity either semantically or syntactically. HL7 Fast Health-
29 87
ACM, New York, NY, USA, 4 pages. https://doi.org/10.1145/1122445.1122456
30 care Interoperability Resources (FHIR) is a technological standard 88
adopted widely to build API standards in data formats like XML
t f he

31 89
32
1 ABSTACT and JSON to overcome this limitation of interoperability by using 90
The development a robust, transparent and interoperable E-healthcare a RESTful architecture[ref][ref]. Inspite of the billions of USD in-
No lis

33 91
34 infrastructure has been a difficult task due to many regulations and vested in Health Informatics, the cost of healthcare in USA has been 92
35 legislatures like HIPAA (full form) and GDPR (full form)[ref][ref]. steadily increasing making it less and less accessible. 93
b

36 Healthcare service providers prefer to store data about their pa- Blockchain technology as proposed by Bitcoin allows for cre- 94
pu

37 tients in locked up silos, behind often inadequate layers of security ation of an immutable distributed replicated ledgers for storage and 95
38 and firewalls. Such an approach also limits the ability to get a holis- validation of transactions between pseudo-anonymous identities. 96
tic view of the performance of a healthcare scheme of a country. It uses Proof-Of-Work consensus algorithm to make commitments
Un

39 97
40 Concerns of privacy of patient medical data is another point of of new blocks to the blockchain by running repeated hashing cal- 98
41 contention. culations to find a valid commitment. This led to blockchain hav- 99
42 In this paper, we propose a national consortium blockchain ing bad notoriety by governments and regulating authorities. But 100
43 framework for managing of funds and patient record for a health- with the advent of Ethereum it allowed developers to build appli- 101
44 care scheme, introducing a transparent insurance claim process cations beyond just cryptocurrencies by using “solidity" turing 102
45 for service providers and giving the ownership of medical data to complete language to write automated codes containing business 103
46 the beneficiaries, allowing them to delegate access to healthcare logic[ref][ref]. This ability to write open sourced smart contracts 104
47 providers using an end-to-end encryption scheme made possible that automatically execute upon fulfillment of certain preconditions 105
48 by atomic proxy re-encryption. allow for a wide range of transparent computations to be done on 106
49 the Ethereum Blockchain. Almost 56% of healthcare stakeholders 107
50
Permission to make digital or hard copies of all or part of this work for personal or plan to implement a blockchain based solution in their stack by 108
Unpublished working
classroom use is granted without feedraft.
providedNot for distribution.
that copies are not made or distributed
51 for profit or commercial advantage and that copies bear this notice and the full citation
2020[ref][ref]. 109
52 on the first page. Copyrights for components of this work owned by others than ACM One major reason that blockchain technology has been a non- 110
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, starter for many industries is due to it’s complete transparency and
53 111
to post on servers or to redistribute to lists, requires prior specific permission and/or a
54 fee. Request permissions from permissions@acm.org. openness. If many stakeholders were to join a blockchain network 112
55 Woodstock ’18, June 03–05, 2018, Woodstock, NY then their data would be able to be accessed by anyone else, even 113
56
© 2018 Association for Computing Machinery. malicious third parties. Hence, privacy is a major feature that needs 114
ACM ISBN 978-1-4503-9999-9/18/06. . . $15.00
57 https://doi.org/10.1145/1122445.1122456
to be built by design into a blockchain architecture for it to be 115
58 2019-07-07 09:25. Page 1 of 1–4. 116
 Woodstock ’18, June 03–05, 2018, Woodstock, NY Bhavye, et al.

117 adopted, especially in the case of healthcare data which is one of infrastructure of developed countries like USA and France, majority 175
118 the most sensitive kind of personal information. Should it be leaked of the developing countries in the world still are overly dependent 176
177
119 by some health provider, it would leave them liable to lawsuit and on paper-based medical records. These paper based records have 178
120 expensive fines by HIPAA and would expose the patients to being been a cripple to the advancement of better healthcare, due to their 179
180
121 exploited by malicious parties.[seems incomplete, or re-phrase it, inconvenience in distributing between healthcare providers, insur- 181
122 UPDATED]. ance companies, pharmacies etc. We often see patients waiting 182
123 In 2019, there is a lot of talk in developing as well as developed outside a doctors office with a folder of documents, X-ray scans, 183
184
124 countries to build a better and transparent health care system. The prescriptions = 185
125 US government just issued a new executive order to reveal hidden 186
126 healthcare costs in a transparent manner. India has launched the 4 PRELIMINARIES 187
188
127 ’world’s largest’ health insurance scheme i.e. Aayushman Bharat Yojna 189
128 to provide a health cover of 5,00,000($6,900) to every family below
4.1 Blockchain 190
191
129 poverty line according to Socio Econonmic Caste Consensus 4.2 Smart Contracts 192
130 2011 but there have been concerns to whether or not sufficient fund- 4.3 Zero Knowledge proofs 193
131 ing will be provided to cover the 10 crore families (10,00,00,000) 194

.
4.4 Symmetric cryptography 195

n. ft
132 under this scheme. 196
133
4.5 Asymmetric cryptography 197

io ra
198
134 2.1 This paper makes the following
135 4.6 Proxy Re-encryption 199
contributions

ut d
200
136
• We propose a novel EHR sharing architecture using dis- 5 PROPOSED SYSTEM 201
202

ib ing
137
tributed and centralized ecrypted cloud storage reposito- The current flaws in the healthcare system can be overcome by 203
138
ries for storage of EHR’s and other medical documents. We utilizing the fault toleranance, immutability automation features 204
205
139
use a ERC721 token to delegate access to service providers of blockchain technology. We propose a layered smart contract 206
140
str rk
to read and write data to the cloud on patients behalf. To approach to manage access control permissions, insurance claims 207
141 208
achieve security and end to end encryption we utilize proxy and proof of identity for medical data in the context of India. 209
di o
142
re-encryption algorithm that converts ciphertext atomically 210
143
or d w

without ever decrypting data on the cloud. The insurance 5.1 Stakeholders 211
144 212
claims are automated by predefined costs of services offered Since our objective is to promote interoperability between the dif- 213
145
by healthcare providers. ferent healthcare institutes, governemnt and beneficiaries we shall 214
146 215
• We explore the concept of zero knowledge proofs of iden- list out all the stakeholders involved in our proposed solution.
t f he

147 216
tity [CITATION] to link identity of a patient with his dig- 217
148 • Federal Government: The responsibility of providing fund-
ital identity (aadhar) using zero knowledge succinct non- 218
ing for insurance under the PM-JAY scheme is of the federal
No lis

149 219
interactive arguments of knowledge (ZkSnarks) and it’s li-
150 government. They will be responsible for deployment of the 220
brary Zokrates for implementation on Ethereum Blockchain. 221
151 insurance smart contract and will have an initial balance
b

• We perform a comparative study between implementation 222

152 equal to 2,000 crore as per the scheme. This balance will 223
pu

of Healthcare EHR’s in USA, Estonia, and make suggestions 224

153 get distributed amongst beneficiaries as they are onboarded
to implement National Health Stack in India. 225
154 on to the scheme and the contract. The government will 226
The remainder of the paper is organized as follows.Section 2
Un

155 also have the capability audit the insurance claims made by 227

156 describes the flaws in current EMR data management and sharing utilizing event logging and state variables of smart contracts.
228
229
157 infrastructure. Section 3 introduces blockchain concepts and it’s • National Hospitals: Due to the lack of proper infrastruc- 230
158 main components to be utilized in this paper. Section 4 introduces ture in majority hospitals to run full blockchain nodes that 231

159 state-of-the-art studies towards building more privacy preserving perform the consensus algorithm, Only national hospitals
232
233
160 and scalable blockchains. In section 5, we propose an architecture such as AIIMS (All India Institutes of Medical Sciences) are 234

161 for interoperable healthcare infrastructure controlled by a govern- given the responsibility to run consortium blockchain. Upon
235
236
162 ment along with it’s smart contract implementation. In section 6, genesis of the blockchain these hospitals also have to respon- 237
163 we observe the landscape of blockchain and it’s SWOT analysis. sibility of performing the trusted setup[CITATION] phase 238

164 We finally draw conclusions in section 7. of zk-Snarks to generate the system paremeters for identity
239
240
165 verification smart contract. 241
166 3 EXISTING SYSTEMS • Healthcare Providers: These include all the third party 242
243
167 We’ve all experienced the frustration of moving from one doctor to hospitals (public and private) and service providers that will 244
168 another, be it the repeated tests, overlapping prescriptions or an- be able to request access to EHR’s of beneficiaries while 245
246
169 other initial diagnosis. The culprit of this frustration is the inability also being able to generate new EHR’s and claim insurance 247
170 of healthcare providers to view a complete, holistic and accurate amount depending on the services they provide. 248
171 health record data. When healthcare professionals have complete • Beneficiaries: The 10 crore families under the poverty line 249
250
172 and up-to-date information then can make better, well-informed de- as per Socio Economic and Caste Consensus will be eligible to 251
173 cisions. Setting aside the well-developed Electronic Health Record claim the benefits of the PM-JAY scheme. They will be given 252
253
174 2019-07-07 09:25. Page 2 of 1–4. 254
 Interoperable Healthcare Using Smart Contracts and Proxy Re-Encryption Woodstock ’18, June 03–05, 2018, Woodstock, NY

255 smart cards to store their public and private key generated The work flow of Registration and key generation is illustrated 313
256 from their Aadhar number in a deterministic manner using in Fig. 1. The description of each step numer is summarized as 314
315
257 ID-based cryptography[CITATION]. follows. 316
258 317
(1) The beneficiary uses any national identity or state issued 318
259
5.2 Setup phase identity such as aadhar card, family card to prove identity at 319
260
Since our solution will be utilizing ZK-snarks utilizing the Pinno- registration desk. 320
261 321
chio procedure[CITATION] it is necessary to generate the system (2) The registration manager queries the latest SECC database 322
262
parmeters that will be used by everyone who interacts with smart after verifying the identity of beneficiary from the given 323
263
contract to generate proofs. Zcash has a detailed explanation of how identity document. 324
325
264
they performed this parameter generation using 6 geo-graphically (3) Depending on whether or not benficiary family is eligible the 326
265
seprated computers[Citation]. This process involves generation of database will respond the details of beneficiary. If eligible, a 327
266 328
a proving key and verification key, the proving key needs random 160 bit digital ID will be created for the beneficiary. 329
267
to be shared to all the stakeholders and the verification key This digital ID along with a passphrase decided by benficiary 330
268
needs to be properly disposed off, since if anyone who gets access will be used to deterministically generate public/private key 331
269 332
pair for the benficiary(e.g. PBKDF2). This process must be

.
to this will be able to generate fake proofs and perform malicious 333

n. ft
270
activity. Zokrates [CITATION], the zk-skark library we will be deterministic since in case of lost smart card, they should 334
271
be able to generate key pair again. Similarly a symmetric 335

io ra
272 utlizing for Proof of concept takes care of disposing the verification 336
key by itself after it deploys a identity verifier smart contract. key needs to be generated which will be used to encrypt all 337
273

ut d
This smart contract lives on the blockchain and uses eliptic curve EHR’s. !!!ADD MATH FORMULA HERE!!!. 338
274 339
pairing to verify correct execution of a program without revealing (4) The registration manager will register this public address as 340

ib ing
275
the inputs to the program. This feature will be utilized to generate a beneficiary, setting it’s balance as the insurance coverage(5 341
276
Proof of Private Key Ownership, for private key of beneficiaries Lakh) and causing an event to be triggered. 342
277 343
.Newer development in Multiparty computations and Trusted Exe- (5) The Registration manager will encrypt the symmetric key 344
278
str rk
cution Environment like Intel SGX or AMD SEV allow for secure using public key of beneficiary and sign it using beneficiary’s 345
279
generation and disposal of these keys. private key before uploading it Proxy Re-encryption cloud 346
347
di o
280
server. The 348
281
or d w

(6) A smart card will be issued to the beneficiary with his newly 349
282 5.3 Registration of beneficiaries 350
generated public/private key pair and the digital Health ID 351
283
The beneficiary families eligible for insurance coverage under PM- stored on board. 352
284 353
JAY scheme have to be issued unique digital Health IDs as proposed
t f he

285 354
by NITI Aayog [CITATION] in the form of public and private key. 5.4 Insurance claim and data sharing 355
286
Their public key will be used to identify them on the blockchain. In this subsection, we introduce two functionalities i.e. secure data
356
No lis

287 357
This registration process can be done at any hospital help desk sharing and access control using proxy re-encryption and auto- 358
288
that is included under the scheme. Also, in order to be able to mated insurance claims using smart contracts on blockchain. The 359
289
b

employ a scalable proxy re-encryption framework for access control, smart contracts allow for functions to be executed in a distributed
360
290 361
pu

a symmetric encryption key (any 256bit scheme like AES256 or and verifiable manner, providing an audit trail of events and trans- 362
291
RSA) will need to be generated and should be stored in Proxy actions. 363
292 364
Re-encryption cloud after encrypting the key with private key of The flow diagram in Fig. 2 explains how our approach allows for
Un

293 365
beneficiary. a more transparent and convenient method, explained as follows. 366
294 367
295 (1) The beneficiary will visit on of 100,000+ empanelled hospitals 368
296 and present the smart card issued to him. 369
370
297 (2) The hospital uses the private key present on the smart card 371
298 to generate re-encryption key[GA07 CITATION] and call a 372
373
299 function of Zokrates identity verifier smart contract with 374
300 a proof of private key of beneficiary and the re-encryption 375
301 key. 376
377
302 (3) If the proof evaluates as "accept" the re-encryption key will 378
303 be added to the mapping of the beneficiary in permissions 379
304 smart contract. This will trigger an event which can be lis- 380
381
305 tened to by the cloud and auditors. 382
306 (4) The hospital will fetch data stored on IPFS by checking 383
384
307 the hashes of EMRs in the Health Insurance smart contract. 385
308 These files will be all encrypted by a symmetric key. 386
309 (5) The hospital sign a token with its private key to send a 387
Figure 1: The flow of benficiary registration and key gener- 388
310 request for patient data access to Cloud proxy re-encryption 389
311 ation server. 390
391
312 2019-07-07 09:25. Page 3 of 1–4. 392
 Woodstock ’18, June 03–05, 2018, Woodstock, NY Bhavye, et al.

393 4 using SafeMath for uint256 ; 451

394 5 452
6 PermissionsContract permissionsContract ; 453
395 454
7 /* DATA VARIABLES */
396 455
8 456
397 9 address private contractOwner ; // Government 457
398 10 bool private operational = true ; 458
399 11 mapping ( address = > uint256 ) private walletBalance ; 459
12 mapping ( uint = > uint256 ) treatmentCost ; 460
400
13 address [] private healthcareProviders ; 461
401 14 462
463
402 15 struct EHR {
464
403 16 bytes32 id ; // unique ID for each visit 465
404
17 string hash ; 466
18 uint treatmentCode ; 467
405
19 address provider ; 468
406 20 address beneficiary ; 469
407 21 bool isClaimed ; 470

.
22 471

n. ft
408 }
472
23 mapping ( bytes32 = > EHR ) EHRDetails ;
409 473

io ra
24 mapping ( address = > EHR []) EHRHistory ; 474
410 25 475
411 26

ut d
} 476
412 477
6.0.2 Identity Verifier smart contract. This smart contract is gener- 478

ib ing
413
479
414 Figure 2: EHR access and generation with insurance claim ated by Zokrates and utilizes Cryptographic Pairings over Barreto- 480
415 Naehrig Curves[citation]. Zokrates allows us to use a high level 481
DSL(Domain Specific Language) similar to python to write Qua- 482
416
str rk
417
(6) The cloud server will check whether a re-encryption key dratic arithmetic programs which can be used to generate zero
483
484
exists on the permissions smsart contract. If so, it will re- knowlege proofs[Citation]. Recently Zokrates extended it’s stan- 485
di o
418
419
encrypt the symmetric key for the hospitals public key and dard library to use ECC to derive public key from a private key[CITATION]486
or d w

487
420
send it to the hospital. while allowing the prover to hide the private key from getting ex- 488

421
(7) The hospital will Decrypt all the files it has fetched from posed, hence zero-knowledge. This feature can be used by health- 489

422
IPFS and use it to gain better insights for patient treatment. care providers to generate proof-of-identity using the private key
490
491
(8) The hospital will generate new EMRs after treating the ben- on beneficiaries smart card [CITATION].
t f he

423 492

424
eficiary and send the hash of the EMR along with the treat- 493
ment code to Health Insurance smart contract. 6.0.3 Permissions smart contract. This smart contract will be the 494
No lis

425
(9) The hospital will upload data to IPFS via the EHR cloud, this core contract responsible for storage of permissions granted by 495
496
426
will cause the EHR cloud to update the smart contract and beneficiaries to different healthcare providers. Since we will be 497
427
b

transfer due insurance amount to the beneficiary depending using Non-interactive proxy re-encryption algorithmcitation we 498
428 499
can store re-encryption keys on the blockchain itself without fear
pu

429
on the treatment code. NEED TO DISCUSS WITH PROF. 500
of revealing any private key. The healthcare providers will interact 501
430
6 SMART CONTRACTS IMPLEMENTATION with this contract via the App contract and the cloud server per- 502
Un

431 503
forming proxy re-encryption will lookup for re-encryption keys in
432 To separate the application logic for easier upgradibility and unit- 504
this smart contract and listen to any events generated by it. 505
433 testing we propose a two layered architecture for separation of 506
434 the Data (SHA256 hash of EHRs, Re-encryption permissions ) and 507

435 the business logic (management of insurance funds, Verification 508

509
436 of Identity). This allows for only unidirectional flow of data and 510

437 control from Logic contract to Data contract. This design pattern 511
512
438 is also know as the eternal storage smart contract. We will 513
439 use events to communicate with our cloud database and other 514

440 microservices. 515

516
441
6.0.1 App smart contract. This smart contract is responsible for 517
518
442
maintaining all the business logic according to the national health 519
443
scheme.It will have a mapping to store cost of all 1350 ailments 520
444
covered by the PM-JAY scheme, along with balances of all the 521
522
445
registered stakeholders (Beneficiaries and service providers). The 523
446
skeleton implementation of such a smart contract is given below. 524
447 525
1 pragma solidity ^0.4.24; 526
448 2 527
449 3 contract HealthcareScheme { 528
529
450 2019-07-07 09:25. Page 4 of 1–4. 530