Decentralized Patient Centric e-Health Record Management System using Blockchain and IPFS
©©2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in anycurrent or future media, including reprinting/republishing this material for advertising or promotional purposes, creating newcollective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in otherworks.Accepted to be published in 2019 IEEE Conference on Information and Communication Technology.DOI: 10.1109/CICT48419.2019.9066212 a r X i v : . [ c s . CR ] S e p ecentralized Patient Centric e-Health Record Management Systemusing Blockchain and IPFS Gaganjeet Singh Reen
Network Security & Cryptography LabIIIT AllahabadAllahabad, [email protected]
Manasi Mohandas
Network Security & Cryptography LabIIIT AllahabadAllahabad, [email protected]
S. Venkatesan
Network Security & Cryptography LabIIIT AllahabadAllahabad, [email protected]
Abstract —Electronic Health Records(EHR) are gaining a lot ofpopularity all over the world. The current EHR systems howeverhave their fair share of problems related to privacy and security.We have proposed a mechanism which provides a solution to mostof these problems. Using a permissioned Ethereum blockchainallows the hospitals and patients across the world to be connectedto each other. Our mechanism uses a combination of symmetricand asymmetric key cryptography to ensure the secure storageand selective access of records. It gives patients full control overtheir health records and also allows them to grant or revokea hospital's access to his/her records. We have used IPFS(interplanetary file system) to store records which has the advantageof being distributed and ensures immutability of records. Theproposed model also maintains the statistics of diseases withoutviolating the privacy of any patient.Keywords: Blockchain, IPFS, e-Health Records, DecentralizedStorage
I. INTRODUCTIONIn 2014, 76% of hospitals in the United States had adoptedbasic EHR systems [5]. While a lot of hospitals in thedeveloping nations still lack the facilities required to shiftto an EHR system, the adoption of EHR has been on a riseglobally. The traditional EHR systems however have a lot ofproblems when it comes to privacy, security and ease of use.The records are completely controlled by the hospitals thatcreated the record. These records can be misused if the hospitaldoes not have adequate security measures in place. There isalso a considerable lack of uniformity in the records that arecreated and stored. The records stored by one hospital mightnot be accessible or may be incomprehensible to the doctorsat another hospital. This primarily occurs because differenthospitals use different providers to design their EHR softwaresystems.Recently there have been several ransomware attacks inwhich the hackers install malware on the medical organizationsservers. They make the data inaccessible and release it onlyonce their demands have been met. Two recent incidents[6] at Howard University Hospital, Washington proved thatadequate data security measures are required in the field ofe-Health Records. On May 14, 2013, one of the hospitalsmedical technicians was charged with violating HIPAA(HealthInsurance Portability and Accountability Act), as she had soldprivate patient information. In another incident in the same hospital, a contractor had downloaded nearly 34000 patientsfiles to his personal laptop.In India, National eHealth Authority(NeHA) [7] is a pro-posed organization which aims to set certain regulations inthe field of eHealth care. This is being done to ensure stan-dardization of eHealth records which would facilitate secureaccess to these records while ensuring privacy. The modelproposed in this paper could be used for this very purpose.In order to provide absolute privacy and security, we haveput to use the concepts of cryptography, blockchain and IPFS.Blockchain is an immutable list of records, which are storedin blocks with each block being linked to the previous block.In a Blockchain every transaction made between the accountsincluding between a user and a smart contract account is storedin a block. These transactions are public and irreversible oncethey have been stored in a block. So everyone can see whohas accessed which smart contract.We have used the Ethereum blockchain because it enablesus to use smart contracts. We are making use of a permissionedversion where select participant nodes are miners. The actualrecord data is stored off the blockchain and on the networknodes which are a part of IPFS(Inter Planetary File System).II. COMPARISON WITH EXISTING WORKSMedRec [1] is one of the earliest suggested models fora blockchain based medical record management system. Itutilizes the Ethereum Blockchain and Smart Contracts to storeaccessibility details of the health record. The actual healthrecord is not stored on the Blockchain, it is stored on theHealthcare Providers database which is operated by a thirdparty. Hence these records are still susceptible to attack ormisuse. The primary difference between MedRec and ourapproach is that we store the records in a distributed mannerand do not rely on a third party. Also, the use of hashes inIPFS guarantees the immutability of records.In Blockchain for Healthcare [2], the patient data is storedon the blockchain after being encrypted with the patientsprivate key. This data can be decrypted using the patientspublic key which is provided to users such as hospitals andresearchers to whom the patient has given permission. Thisis in stark contrast to our approach in which the patientsave complete control over who can view their data. In ourmodel, the patients private key is required to decrypt the datainstead of encrypting it. Also, we do not store the data on theblockchain but instead use IPFS for the same.Blockchain For Health Data and Its Potential Use in HealthIT and Health Care Related Research [3] makes use of theblockchain to store encrypted medical record details suchas where it is stored(hashed pointers) and who has accessto it. Only the owner of the data can change the accesscontrol policies. All the data is stored in a data lake. Foridentity authentication the suggested method in this modelis a biometric system which would be more secure than apassword.The difference between this approach and ours is thedistributed nature in which the data is stored in our system.Qi Xia et al [13] proposed the blockchain based healthrecord sharing model using the cryptographic keys and smartcontracts. Alevtina Dubovitskaya et al. [14], has proposed asecure and trustable health record sharing method based onBlockchain technology. They concentrated on the Oncologydepartment of hospitals and the assumption is access to allrecords or no access at all. It is not possible for a patient todisclose some of the records because the same key is used toencrypt all records. In our approach, the patient can specifywhich records it wants the hospital to gain access to.Considering the existing works and their shortcomings, thispaper proposes a secure and efficient model to store and accessthe health record in the presence of the outside attackers.III. REQUIREMENTS AND PRELIMINARYThe main requirements that need to be satisfied in anelectronic medical record management system are- • The patient must have complete control over who canview his/her records. • The patient should be able to grant and revoke access tohis/her records as and when he/she deems fit. • The patient records once stored should be immutable andchanging them should be infeasible. • The hospital should not be able to deny creating therecord at a later point of time and the patient shouldnot be able to claim that a record was created in his/herabsence.In this EHRS model there are primarily two types of users:Patient and Hospital. The patient is the only type of user whocan grant and revoke access to the health records.The hospital enters the health record details on the websitewhere it is encrypted and stored in IPFS using the patientspublic key ( P Pub ). Hence, it can be decrypted by using thepatients private key ( P Priv ) only. If the hospital wishes to haveaccess to this record they can request the patient to give themaccess. This access can be revoked at any point of time. Thehospital has a database which stores the patient name patientID and contact details.IV. PROPOSED MODELAll the participating nodes on the network i.e. hospitals,patients, Insurance agency, etc. are required to be a part of two networks- the permissioned blockchain and IPFS. Howevernot all of them are not required to keep the entire blockchainstored(light nodes).Health Record Structure:
Patient IdGenderAgeDiseaseDiagnosisLocationMedicationSuggestionNext ReviewNotesDateDoctor’s NameHospital Id
Fig. 1: Structure of Health RecordIn a Permissioned Blockchain a group of participants aredecided in advance who in turn validate blocks and transac-tions. The miners do not need any incentive to mine blocks inthis model of the blockchain. Thus the concept of gas cost hasno significance in a permissioned blockchain. In our model,the hospitals will be the miners. The hospitals should haveno problem agreeing to spend heir computational power andmine blocks because in the absence of such a system, thehospitals would have had to pay large sums of money to theorganisations handling their data and interfaces. If the conceptof gas and ether does not play a role in the blockchain, itis apparent that Proof of Stake or Proof of Work cannot beused as consensus protocols. As a result, for our use case, wepropose using
Proof of Authority [15] as a suitable consensusprotocol. A Permissioned Blockchain serves as an immutableledger for all the activities that take place on the network. Theterm activities used here refers to actions like :- • A hospital creating a record for a patient. • A patient accessing a record. • A patient granting privileges to or revoking privileges ofa hospital to view his/her records. • A hospital accessing a record.The sample structure of a health record is shown in Fig. 1,and Fig 2. is a representation of the proposed system. Thereare three smart contracts in our proposed system :- • The first one contains a mapping from P Pub to the hashesof the patient’s records. • The second one contains a mapping from the combinedpatient and hospital public key ( PH Pub ) to the record thatthe hospital has access to. • The third smart contract is used to store the number ofcases of each disease being reported.Any hospital wishing to access patient records will haveto do so by sending a request to the patient and the patientig. 2: Architecture of e-Health Record Management Systemin turn will grant access by encrypting the records with thehospital public key ( H Pub ) and storing the hash of the record inthe second smart contract mentioned above. This storage willbe registered as a transaction to the second smart contract.As a result, everyone will know which hospital has access tothe records of which patient. Also, when a hospital creates arecord, a corresponding transaction is created to the first smartcontract which is again visible to all the participating nodeson the system.In IPFS data can be accessed only using the SHA-256 hashvalue stored in base58 format. So without the hash, data isinaccessible. The hashing operation can be represented as f { } * → { } n where f is the hash function and n =256(because the hashing algorithm used is SHA 256).In IPFS each data entry is stored in the form of a merkleDAG so any changes in the data would not be possible as thehash value will change. Hence it is tamper resistant which isa desired property for health records. A. SignUp Phase1) User SignUp:
The SignUp phase is required so thatusers can access their records and grant and revoke accessfrom machines other than the ones they used to become apart of the blockchain. Signing up allows them to access theirprivate keys from systems other than their own. The user musthowever make sure to clear the browser cache and history afteraccessing the system from a machine which can’t be trusted.We also need to ensure that a particular patient joins theblockchain just once i.e. a single patient should not be as- sociated with multiple accounts. To ensure this, the privatekeys of the patients should be derived from something that isunique to a patient like a fingerprint[17].In order to signup and become a part of the network, the usermust join the permissioned Ethereum blockchain by providinghis/her fingerprint so as to derive the Ethereum blockchainprivate key . The public key of the node(which is used toencrypt the records) is extracted from this particular privatekey. The combination of the public key and the private key isencrypted with the patients fingerprint(biometric encryption)and is then stored securely in a database.We use both symmetric key cryptography as well as asym-metric key cryptography.The symmetric key cryptography iswhere the decryption password (derived from the fingerprintof the user) comes into play. The user provides his fingerprintand the password derived from it is used to encrypt a filecontaining the public key of the user stored in conjunctionwith the private key of the user. This encrypted file is storedin the local storage of the users browser and a copy is alsostored on the server in the event that the local storage copygets deleted.If the file is available on the local storage, no request is sentto the server for the file. Even though the file is stored on asecure server, its safety is further guaranteed by the fact that itis stored in an encrypted format and the password to decryptis possessed by no one other than the user. We have usedAES block cipher encryption [10] to encrypt the file with the This private key is not directly stored anywhere assword derived from the fingerprint of the user.When the user wishes to perform operations like viewrecords, create records or grant/revoke access to records, theuser provides his/her fingerprint which is then used to decryptthe retrieved user public and private key. The private key canbe used to decrypt only those records which were encryptedusing the users public key. Correspondingly the public key canbe used to encrypt fresh records. The public key of a user isaccessible to all the other users of the system.
2) Hospital SignUp:
Considering that a hospital cannot beregistered using a fingerprint, a different approach would haveto be followed for Hospital SignUp. The authenticity of ahospital would have to be tested physically by a committeefollowing which a public-private key pair would be generatedand assigned to the hospital. The hospitals will also be allowedto create a login password which in turn would be used toencrypt and decrypt the file containing the public key of thehospital stored in conjunction with the private key of thehospital. As a result, there will exist a list of all the hospitalsin the blockchain. This list will later be used for verificationof transactions by smart contracts.
B. Hospital Functionality
A member of the hospital staff can log in using the hospitalID and password(this essentially decrypts the file containingthe hospital public and private key). After this the hospitalcan either view records or enter a new record. To submit arecord the doctor fills out the record details. On submitting,the Patient ID is used to obtain P Pub and this public key isused to encrypt the data. The encrypted record is then storedin IPFS while the SHA-256 hash retrieved from IPFS is storedin the smart contract storage along with the patient public key.Along with the hash, a signed copy of the hash(signed withthe Patients Private Key) is sent to the smart contract as well.The contract first verifies the validity of the signature usingthe patients public key and also check whether the hospitalpublic key is listed in the registered hospitals list. If boththese conditions are validated, only then is the data storedin the smart contract. Only the patient can decrypt this recordusing P Pri . Before the record is stored in IPFS, the third smartcontract is accessed and in the smart contract the count of thenumber of cases of the reported disease is increased by one.
IPFS Patient Record ← Enc P Pub (cid:104)
N ewlyCreatedRecord (cid:105)
The hospital can view the records they have access to byentering the decryption password which decrypts the publicprivate key combination file stored in the local storage of thebrowser. The unavailability of the record causes the systemto fetch the same from the database. The H Pri so obtained isused to decrypt the record. The hospital is required to enterthe patient id of the patient whose records the hospital wishesto fetch. The id is used to fetch the patient public key andthe combined hospital patient public key is in turn sent to thesmart contract which stores the mapping between the key andthe record hashes. Once the desired entry in the map is found,the hash(es) are returned to the hospital which in turn uses thehash to fetch the record from the IPFS network. If the patient revokes access, the hospital will no longer beallowed to view the record as the entry containing the IPFShash will be removed from the smart contract. Hospital Record ← Dec H Pri (cid:104)
IP F SHospitalRecord (cid:105)
C. Patient Functionality
A patient can log in to the application using their patientID and password(fingerprint). Now the patient can view theirrecords and can grant and revoke access to hospitals and otherusers.To view their records, the patient has to enter the decryptingpassword which is used to decrypt the public private keycombination file stored in the local storage of the browser.The unavailability of the file on the browser causes the systemto fetch the same from the database. P Pri can then be usedto decrypt the data as the encryption was done using thecorresponding public key.
Patient Record ← Dec P Pri (cid:104)
IP F SP atientRecord (cid:105)
To grant access the user specifies the hospital ID and thelist of records that the hospital should be given access to.These records are then decrypted and then re-encrypted usingthe H Pub and stored in IPFS. The combined key, which is aconcatenation of P Pub and H Pub is stored in the smart contractalong with the IPFS hash. A signed copy of the hash(signedwith the Patients Private Key) is sent to the smart contractas well. The contract first verifies the validity of the signatureusing the patients public key and if the signature is valid, onlythen is the data stored in the smart contract.
IPFS Hospital Record ← Enc H Pub (cid:104)
P atientRecord (cid:105)
To revoke access, this entry is deleted from the smartcontract. The patient sends the hospital patient combined keyto the smart contract in order to delete the entry. The patientalso has to send a signed copy of the combined key as well asthe hospital key individually to the smart contract. The contractwill first combine the hospital key with the patients public keyand then verify the signature. If it is valid, the entry will bedeleted. This prevents any random patient from deleting someother patient's entry in the smart contract. The record is alsodeleted by the patient from his own system. This howeverdoes not ensure that the record is deleted all across the IPFSnetwork because the hospitals that accessed the records havethe data stored in their local systems(because of how IPFSworks). Thus, the patients must also send a notification to theconcerned hospitals to delete the corresponding copies of theparticular record from their local systems as well.
The patientscan then check if anyone still has copies of the file by usingthe command :- ipfs dht findprovs (cid:104) f ilehash (cid:105) . If any of thehospitals whose access has been revoked pop up, legal actioncan be taken against them.
D. Statistical Analysis
It is very important to maintain the statistics and makingthe information available to the public without violating theprivacy of the patients. The proposed model has the provisionto maintain the statistics without violating the patient privacy.ospitals posting health record hash to the smart contractshould also update the disease count.Consider two records R and R . Let the diseases updated bythe records be D and D respectively. Let there be an attacker A such that A (cid:104) R i (cid:105) = D i represent that the attacker correctlyestablishes the disease count transaction that corresponds toa particular record storage transaction. In order to ensurethat the attacker cannot conclusively establish the mapping Pr (cid:104) A (cid:104) R i (cid:105) = D i (cid:105) = 1/2 . To ensure this, the hospital must updatethe count of atleast two diseases at a time. However there arethe following issues in maintaining the privacy Gender based disease distinction : If a hospital updates fortwo patients (female and male) say pregnancy and diabetesrespectively. It can be easily mapped that the female ispregnant and male is having diabetes.
Solution : Since the blockchain does not hold the patientidentity details, establishing a relation between the patient anddisease will not be possible.
Specialized Hospital : If any hospital is specialized fortreatment of a particular disease then it can be more easilyidentified because it always updates the count for the samedisease.
Solution : Even though patient blockchain address and per-sonal details cannot be mapped, the blockchain address anddisease can be mapped. However, there are cases where patientmay not have the disease. For example, if we say hospital posts10 hash transaction and 9 disease count update to blockchainthen disease and blockchain address cannot be mapped. Itgives high probability but it is non-deterministic.To access the statistical information, the third smart contractis being used in the system. It can be used to retrieve thenumber of cases of each disease that have been encountered.It basically stores a mapping between the name of the diseaseand the number of records reporting that disease. It doesnot contain any details about the patients having the diseasewhatsoever. The functionality can be extended to allow numberof cases of a particular disease to be reported location wise aswell. In that case, the map would contain the location and thedisease being mapped to the number of cases of the particulardisease. V. ALGORITHMS USEDAlgorithm 1 is used for storing the IPFS hash in the smartcontract. Once the hash for an IPFS record is obtained, it cannot be stored in the smart contract directly because it is toolarge to be converted to the Bytes32 format. Thus, we firstsplit the hash into two parts. After this, a random character isadded at the end of each part as a security measure. Followingthis, the two parts of the hash are converted into the Bytes32format and then correspondingly stored in the smart contract.
Algorithm 1
Storing the IPFS hash in the smart contract
Input:
IPFS Hash of the record ihash ← IPFS hash of the record p1 ← ihash.substring (cid:104) , (cid:105) p2 ← ihash.substring (cid:104) , (cid:105) p1 r1 ← p1 +randomCharacter p2 r2 ← p2 +randomCharacter finalpart1 ← convertToBytes32( p1 r1 ) finalpart2 ← convertToBytes32( p2 r2 ) Store finalpart1 and finalpart2 in smart contract with amapping to the combined key/patient keyAlgorithm 2 explains the process followed to retrieve thehashes from the smart contract and correspondingly convertthem to a usable IPFS hash. The data stored in the smartcontract is in Bytes32 format. The smart contract returns thehash of a record as a single string with the two parts of thehash separated by a comma. We first split the string on thecomma. Then each of the parts obtained is first converted intothe Base58 format. Following this, the random character thatwas added at the end of each part while storing it in the smartcontract is removed. The two parts are then concatenated toobtain the original IPFS hash of the record.
Algorithm 2
Retrieving the IPFS hash from the smart contract
Input:
Patient public key/ Combined key
Output:
IPFS Hash of the record contracthash ← hash retrieved from the smart contract finalpart1 ← contracthash.splitonComma[1] finalpart2 ← contracthash.splitonComma[2 ] p1 r1 ← convertToBase58(finalpart1) p2 r2 ← convertToBase58(finalpart2) p1 ← p1 r1 -r1 p2 ← p2 r2 -r2 hash ← p1 + p2 VI. OPTIMISATION OF STORAGE ONBLOCKCHAINIn the method proposed above, we have used smart contractsto store our mapping between patient/combined key and theipfs hash values. This works for us because of the fact thatour system uses a
Permissioned Blockchain instead of a PublicBlockchain as in the case of the latter, the cost to store sucha large amount of data in the smart contract would render itinfeasible. Smart contracts were not designed for the purposeof storing large amounts of data as storing large amountsof data on the blockchain would essentially slow down andadd additional load on the entire system. Hence, we havesuggested an alternative mechanism where we use IPFS tostore the patient public key to hash mapping instead of thesmart contractIn this method, the patient public key to hash mapping isstored in the IPFS network. The hash of this map is storedin a smart contract. Whenever a hospital or patient needs toretrieve the hash of a particular record, they first fetch theash of the map from the smart contract. After this, they canaccess the record hash using the patient/combined key. Theprimary advantage of this method is that the only thing thesmart contract stores is the hash of the map.There will be a total of three smart contracts in this method.1) A smart contract storing the hash of the map stored inthe IPFS network. This smart contract is also used by apatient to view his/her records.2) A smart contract which is accessed by the patient whenthey want to grant or revoke access to a hospital.Thissmart contract also stores the combined patient andhospital key to hash mapping. Revoking access wouldsimply delete the required entry in the map while grant-ing access would store the hash of the newly encryptedrecord in the mapping.3) A smart contract which is accessed when a hospitalcreates a particular record and need to store the cor-responding record in IPFS. This smart contract in turnaccesses the first smart contract to get the hash of themap.It then accesses the map and adds the required entryto the map.The hash of the updated mapping is thenstored back in the first smart contract.The reason we transfer only one of the mappings to IPFS isthat the other two maps in our system i.e. the combined key tohash map and the disease name to occurences of disease mapboth involve entries that need deletion and updation. Whilewe can add additional things to a record in IPFS and store itefficiently using data deduplication, that will not be possiblewhen deletions and updations are required. Thus every changeto the map will result in the creation of a new map in thesystem which will lead to the wastage of a lot of space.VII. RESULTSThe record creating/viewing interface has been created usingReact js and the backend is pure javascript. Mongo DB hasalso been used to store the patient and hospital ids and theirpublic keys. In order to create a simulation of blockchainnetwork, we have used ganache-cli as our test blockchain.We have also used Web3 js to interact with the blockchain.For testing the IPFS network we have used INFURA, whichprovides a secure, reliable and scalable access to the IPFSgateway. It provides TLS enabled IPFS gateways which canin turn be used to access up and running IPFS nodes.The test model has been implemented on a system having2.2 GHz Intel Core i5-5200U processor with Intel HD Graph-ics 5500, 3 MB cache, 2 cores and a 1 TB 5400 rpm SATAHard Drive. For generating the results, the MongoDB databasewas hosted on AWS(Amazon Web Services) using mlab. Thisgave us an idea of what a standard cloud service providerresponse time would be like. The network being used was astandard 4G connection. Fig. 3: Record Retrieval Time ComparisonThe results in Fig 3 give a time vs number of recordscomparison when using IPFS and also if MongoDB was usedin place of IPFS to store records. The fetch speed from IPFSdepends on a number of factors such as the number of systemsstoring the records, location of the closest system containingthe record etc. Thus, it is not possible to properly analyse theIPFS fetch time on a simulation of the actual system such asours.Even if the fetch speed is slightly slower than a traditionalcloud service, IPFS is still the ideal choice for our model be-cause it provides immutability of records and decentralisation.Fig. 4 shows the amount of time that it takes to retrieve hashesof records from the smart contracts while varying the numberof participants in the network. Considering that this has beentested using ganache-cli, the variation in retrieval time withthe number of participants is not substantial.Fig. 4: Hash Retrieval from Smart Contract Time ComparisonVIII. DISCUSSION
AND
LIMITATIONSWhile the main e-Health requirement is confidentiality, thisis also one of the main challenges. Although the proposedsystem prevents the hospital from gaining access to the recordwithout the patient’s permission, there is no mechanism torevent the hospital from taking a photograph or copying thecontents of the record when uploading the record or duringthe time they have access to the record.Another challenge is that in a developing countries it isdifficult to enforce a digital system as many people do nothave access to the internet or would be unaware of how touse such a system [8]. Additionally, in IPFS, if data is tobe shared to other systems, the system containing the recordmust be online failing which the transfer will not be possible.If multiple systems contain the record, at least one of themmust be online for record transfer to be possible.The primary advantage of using blockchain in this scenariois that it provides a completely decentralized and immutablelogging system in which everyone can view who gave permis-sion to a particular hospital, who revoked access of a particularhospital, who created or accessed which record etc. The factthat this immutable logging of data is available to all theparticipants in the blockchain makes it more secure and misuseof data and records can be easily identified. The use of IPFSalong with blockchain makes it a completely decentralisedsystem which does not require on any organisation for loggingor storing of data. IPFS ensures immutability of patientrecords while blockchain ensures the immutability of loggedtransactions. The use of biometric encryption ensures that evenin a scenario in which a patient is in a critical conditionand can not provide access to his/her records, the recordscould still be accessed using his/her fingerprints. However,the following points need to be taken into consideration whichmight not make Blockchain and IPFS(in it’s current form) thebest technologies for such a system :- • In IPFS, the data is initially stored on the system thatadds it to the IPFS network. When the data is accessedby other systems, the data is sent through the networkto those systems as well which in turn can the act as theprovider of the data. The more widespread the data is, thefaster is the performance of the system. In this scenariohowever, the data is originally stored with the hospitalthat creates it and the only person who will ever fetchthe data is the patient. Thus, in a normal scenario, everyrecord will have a replication factor of 2 at maximumwhich will not allow the IPFS network to function to itspotential. To avoid this, a plausible solution would be toconfigure IPFS to have a replication factor of atleast 20for each record. • The fact that the Blockchain will keep a track of whichpatient visited which hospital can be considered as aprivacy infringement in itself as each user’s hospital visitis being broadcasted over the network. It should howeverbe considered that all the users are identified using theirpublic keys in the system and their names are not exposedto the people on the system. Thus, correlating whichpublic key corresponds to which patient will not be aneasy task. • It is also impossible for a user to delete all copies ofa record on an IPFS network by himself/herself. Eventhough the user can track who stores the copy of the records even when the hash has been deleted from thesmart contract, this does not seem like an ideal solutionto the problem. • There is also the fact that a transaction containing thestorage of the deleted hash in the smart contract will alsoalways exist as a part of the blockchain. Thus, with aconsiderable amount of effort, a hospital might be able toregain the hash of the record that the patient deleted(whenrevoking the access of the hospital). A viable solutionfor this particular problem could be using
IPNS(InterPlanetary Naming System) [16] records to point to suchrecords for which a user might have to revoke access tolater. As a result, only the hash of the IPNS record willbe registered in the blockchain and not the hash of themedical record directly. • Storage of data on a Blockchain is also not recommended.It would greatly limit the extent to which such a mecha-nism can scale. Considering that IPFS cannot be used tostore the contents of both the smart contracts, a workingsolution might involve using cloud storage which woulddamage the decentralised nature of the system. • In the current version of our system, the hospital existsas a single entity on the blockchain. This, however, isnot very appropriate as a hospital would have severaldepartments with several doctors in each department andone particular department or doctor should not be able tocreate or view the records of another department withoutpermission. IX. FUTURE WORKSThe above proposed system has currently been tested usingganache-cli and the IPFS test nodes provided by INFURA.However, in order to realise the full potential and limitationsof the system it needs to be tested on an actual permissionedblockchain with a proper IPFS network setup. A proper setupwill further help us evaluate how the system behaves whenmillions of users try to store IPFS data, access and updatesmart contracts, mappings stored on the IPFS network, etcsimultaneously. X. A
CKNOWLEDGEMENTS