SHARIF: Solid Pod based Secured Healthcare Information Storage and Exchange Solution

(1)

Author:Munish Sharma

Bachelor Degree Project

SHARIF: Solid Pod based Secured

Healthcare Information Storage and

Exchange Solution

(2)

Health Informatics has enlightened by the recent development in the internet of medical things 4.0. Healthcare services have seen greater acceptance of Information and Commu- nications Technology (ICT) in recent years; in light of the increasing volume of patient data, the traditional way of storing data in physical files has eventually moved to a digital alternative such as Electronic Health Record (EHR). However, the conventional healthcare data systems are plagued with a single point of failure, security issues, mutable logging, and inefficient methods to retrieve healthcare records. Solid (Social Linked Data) has been developed as a decentralized technology to alter digital data sharing and ownership for its users radically. However, Solid alone can not address all the security issues posed to data exchange and storage. This work combines two decentralized technologies, Solid ecosystem and Blockchain technology, to tackle potential security issues using Solidity-based Smart Contracts, thereby providing a secure patientcentric design. This research evaluates a model solution for secure storage, emphasising secure auditing of accessing the data stored. The architecture will also come with algorithms that will provide developers with logical instructions to implement the artefact.

Keywords— Access management, Auditability, Decentralization, Solid Pod, Blockchain Technology, Solidity, Healthcare Data

(5)

1 Introduction

This is the era of industry 4.0 and it has evolved the health informatics extensively. Doc- umenting treatments and nursing data is a vital indicator of effective delivery of patient care.

Documentation related to patient care can be traditional paper-based or digitally stored data.

Despite the method used to generate and store this data, documentation of this sort must be carried at the prominent standard to ensure the delivery of safe and high-quality healthcare services [1].

This Bachelor thesis aims to provide a secure access management and auditability for healthcare data in a decentralized manner. The traditional way involves a central authority to store healthcare data, posing various threats to user privacy, interoperability, and data security [2]. This project uses a design science approach to propose a possible decentralized solution based on Solid PODs to overcome security issues for healthcare data.

1.1 Background

Every day, many Electronic Health Records (EHR) are generated, processed, and accessed by the healthcare industry worldwide. For instance, a large number of reports could be generated when a patient undergoes some laboratory tests. EHRs are further stored and accessed by physicians [3]. This whole process involves one or more servers providing this data to various parties involved. As for emerging new diseases(Covid -19), a patient might be sent to several hospitals to diagnose further and treat. It requires medical records access for all concerned parties like physicians, nurses, and caretakers, making it necessary to have a cross-domain secure data-sharing platform. The patient has limited power to control EHR data access of various medical institutions in this cross-domain data-sharing platform. On the other hand, doctors, nurses, and other healthcare service professionals access this data by registering themselves to the medical institutions [4].

It is also important to audit the access to patient data. It could be challenging to achieve this when an individual has met with an accident and is unconscious. In this case, it might not be possible to provide required access permission for the individual’s health records. Such situations require access to health data for ambulance personnel on the place without having

(6)

the patient’s consent. The system providing such access must be configured to handle accountability and authorization to prevent access by malicious actors [4]. Moreover, there can be various copies of exact data in encrypted form. Different staff members could access the data and store it using an encryption scheme designed for their occupation, resulting in occupying larger storage space.

Traditionally, database management systems (DBMS) are used to store such amount/type of data. DBMS can further be divided into systems implementing Structured Query Language (SQL) and systems having a NoSQL foundation [5]. Regardless of the benefits these variants of DBMS come with, there are disadvantages of using these storage systems as follows [5]:

• DBMSs involve central management, which gives users an impression that they are controlling centralized data. However, the underlying servers can be physically distributed.

Moreover, centralized storage can be targeted easily by potential hackers. Software up- gradation is required in the case of a centralized structure, leading to a halt in operations executed by servers.

• Create, delete, update and read functions are well supported by traditional DBMS. These functions make DBMS entries mutable which might be harmful to stakeholders in any medical system.

• The system administrator usually administers DBMS. Thus system administrators might have access to modify digital assets, which is a threat to user data provenance(data ownership).

• The biggest issue in the centralized storage system is that the central server gets corrupted, resulting in all sensitive data compromised.

One of the most promising solutions for the issues mentioned above is the decentralization of data storage. Blockchain implementations have received much attention because of their decentralized nature from industry and various organizations; the healthcare domain has emerged as one of the most significant zones where various technology applications have been identified. Blockchain 3.0 has gone under research for its claiming use cases and proven to be a fit

(7)

for the healthcare sector as underlying technology helps overcome issues such as counterfeit- ing, privacy, and stakeholder collaboration; however, since blockchain is a relatively immature technology, grey papers, as well as the press releases, contributes to a significant amount of unreliable knowledge, considerations, and dilemmas concerning its potential usefulness in the healthcare industry [6] [7].

1.2 Related work

For access control management and secure data storage, Zyskind et al. advocated using blockchain technology. According to the paper, encrypted data is stored in trusted third- party hosting providers, and events are logged on the blockchain [8]. Another research was done by Asaph Azariaet al; proposed a decentralized system to handle EHR data. The proposed blockchain-based system was inefficient as miners and bookkeepers accessed data on the blockchain network [9]. One more research is conducted by Xia et al. to provide auditing and access management by combining cloud services and blockchain technology [10]. Cloud services inherent involvement of administration which violates privacy demands of healthcare data.

Similarly, Lee and Yang suggested a system based on using a public key and private key pair for uploading sensor data in a blockchain network [11]. Another privacy-preserving scheme was proposed by Zheng, in which data should be encrypted before uploading to the server using symmetric keys. Traditional public key sharing schemes will split the symmetric key into multiple shares that will be distributed among various key keepers. The ciphertext can only be decrypted if the data requestor receives enough key shares. Data leakage would not occur if any key keepers were compromised [12].

As discussed above, earlier researches have introduced blockchain technology, public-key encryption integrated with blockchain technology to achieve access management and audibil- ity. However, neither access is patient-centric, nor the data is handled entirely in a decentralized manner. Thus the outcome of this thesis will provide a complete decentralized solution with secure access management and auditing of the tasks performed.

(8)

1.3 Problem Formulation

Industry and academia have focused a lot of attention and study on EHR sharing; however, traditional systems are designed around centralized databases. It becomes vital to address the essential concerns being a single point of failure, privacy protection, security for data, and interoperability among various healthcare bodies. Verizon reports state that there have been 798 data breach-related incidents in 2020, out of which around 10% of incidents were caused by privilege misuse. The report claims that 88% of actors involved in these breaches had financial motives. Surprisingly, figures in the Verizon report show that internal threat actors sum up to 48% of the total [2]. A decentralized approach to storing data can mitigate security issues posed by the centralization of data. Literature studies show that many decentralized solutions are proposed to solve healthcare data storage. However, healthcare data decentralization requires both secure auditing of access management and secure storage. This degree project proposes the possible solutions to examine the following question:

How can we assure secure auditing of access management in a decentralized ecosystem for the healthcare domain?

1.4 Scope/Limitation

This research is focused on finding a way to provide auditing of access management using a decentralized storage solution. Using design artefact, a model solution, and algorithms satisfying the model’s requirements will be provided. However, Due to time constraints and the number of persons allowed to work on thesis work, complete implementation could not be performed. Another limitation of the project is that only one blockchain platform (Ethereum) was considered, but there might be other feasible solutions.

1.5 Design Requirements

As mentioned in Subsection 1.1, the centralized way of sharing and storing healthcare data poses several security issues, specifically access management and auditing; this project will focus on developing a model solution using the design science approach to mitigate these problems in the healthcare domain. To achieve that, the architecture must support decentralized storage and secure access management to the data stored. Moreover, the design is required to

(9)

provide a way to secure auditing for access to data.

In other words, similar to traditional healthcare data systems, the proposed model solution should consider identity management and secure authentication for the users. The user might be dealing with different healthcare organizations, and probably at geologically other locations, where the user must provide healthcare records for successful treatment. The system must handle this situation securely by facilitating user with an upload option for health records.

Earlier sections discussed unauthorized access to healthcare data, a well-known threat to user privacy and data security. Unlike centralized storage, the access to uploaded files and existing ones must be managed by the user in the proposed solution. In this patient-centric solution, the user is referred to a patient, and a doctor, based on their role identification process and control over access to storage should be different. The design must offer secure auditing of all tasks, from registration to mere reading the files.

1.6 Target group

This project is aimed at healthcare informatics scientists and information security researchers interested in establishing secure ways for data sharing and exchange. The paper might be of use to companies responsible for providing various storage services to health organizations. The end-users also benefit from getting aware of a solution providing true ownership and immutable auditing of data.

1.7 Outline

This report has the following structure. Chapter 2 presents the detailed theoretical background by stating components used in this project and the state of the art of decentralization in the healthcare domain. Chapter 3, Method motivates the Design Science approach chosen for this degree project. This chapter demonstrates how and which parts of design science were utilized. The artefact development is presented in Chapter 4. An architecture was proposed to fulfill the requirements derived from user scenarios discussed in Section 1.5, algorithms for the system combining Solid ecosystem and blockchain technology are derived and presented in this chapter. Chapter 5 evaluates the proposed artefact against the requirements defined in Section 4.1. Finally, the conclusion and future work is discussed in Chapter 6.

(10)

2 Theoretical Background

This chapter presents a further explanation of different components and terms used in this degree project. Moreover, Section 2.4 offers the state of the art of topic.

2.1 Blockchain Technology

Blockchain technology has received much attention in recent years from researchers to investigate its use in the healthcare domain. Satoshi Nakamoto introduced blockchain in order to omit the central financial institutions between two parties to fix the uncertainty that exists in financial transactions. Nakamoto proposed that the records should be stored as digitally signed chains. As shown in Figure 1, each participant in the chain digitally signs the hash of previously signed records, making it nearly impossible to edit without raising concerns [13]. As

Figure 1: Digitally signed chain by Nakamoto [13]

the fifth revolutionary computing archetype, blockchain has gone through many development phases for various needs of industry and applications. Blockchain 1.0 has evolved around financial transactions, Blockchain 2.0 deals with more sophisticated solutions for the economy, and Blockchain 3.0 has introduced applications related to government, healthcare, and supply chain management. All versions of blockchain have contributed to resolving the issues of centralization of data and double-spending [14].

Blockchain can further implement public, private, and hybrid solutions on three different

(11)

levels based on the nature of the domain and users. A public blockchain is generally known as a permissionless ledger where any participant can join the network. On the contrary, a private blockchain provides a permissioned ledger, and access is restricted to selected participants only. The private variant of blockchain blocks are encrypted using a private key and can only be interpreted by the intended person. Finally, the third variant of blockchain is also called consortium blockchain. This blockchain is not entirely decentralized, and it presents a combination of a private and public blockchain. To support access control in a blockchain network, Blockchain 2.0 postulated smart contracts. A smart contract defines a collection of rules for transactions in a blockchain network written in an object-oriented programming language. Smart contracts execute automatically and are considered a part of transactions.

2.1.1 Blockchain Smart Contract Formation

Unlike a traditional contract signed between different parties to hold their intentions intact, a smart contract is a digital form of contract deployed on the blockchain and used to execute the terms of the contract. Smart contract deployment on the Ethereum network for the proposed system can be found in Appendices A.1. A smart contract omits the requirement of third-party trust among transacting parties and mitigates the possibility of unintended or fraudulent events.

The smart contract runs independently and automatically on each node in the network. Smart contracts are dependent on the information that will be used in the initial operations [15]. Smart contracts are usually written in an objective-oriented programming language and executed on specific schedules. A developer can mold a smart contract as per requirements that could authenticate a user, registering a user on the blockchain and verifying the authenticity of data before it gets released on the blockchain. Moreover, these digital contracts provide mentioned services in a reliable, efficient, and secure manner to identify licit users. All tasks conducted using smart contracts are distributed on the enduring blockchain network [15].

2.2 Solid ecosystem

This work proposes Solid Personal Online Datastores (Solid Pods) implementation for providing true ownership, decentralization of data for users. Sir Tim Berners-Lee has presented a

(12)

distributed data service solution based on existing Web standards called Solid [16]. This version of the Web enables users to create their online data storage to store photos, comments, health records, and other personal information securely. Solid uses WebID instead of usernames, which internally include a user’s POD since WebID offers globally identifiable decentralized identifiers. Solid implementation of the Web provides users with rights to give access to their data on different levels. Using their WebIDs, users can grant access to a specific directory from their POD to any application, person, or organization [16] [17].

2.2.1 Solid Authentication Process

The solid authentication process consists of three major components: Identity server, resource server, and client [18]. In a Solid ecosystem Identity provider (IdP) may be a user- controlled or an identity-as-a-service vendor. Most probably, the user may be authenticating from an application or a browser. The basic authentication process in the Solid ecosystem consists of the following steps [18], and shown in Figure 2.

Figure 2: Solid Authentication [18]

Step 1: The client requests a non-public resource from the resource server.

Step 2: The resource server(RS) requests a OAuth 2.0 Demonstration of Proof-of-Possession (DPoP) -bound access token from the client by sending 401 with a WWW-AuthenticateHTTP

(13)

header.

Step 3: The client presents the client identifier and associated secret to RS, and the authorization code is requested.

Step 4: If the client fulfills the demand by RS, a client presents the Authorization code and DPoP proof to the token endpoint.

Step 5: The client gets the OIDC ID token (OpenID Connect Core) and DPoP-bound access token from the token endpoint.

Step 6: The client presents the Access token to the resource server(RS).

Step 7: The resources server validates the signature on the Access token using the client’s public key provided by IdP.

Step 8: RS returns the requested resource if the DPoP proof and Access Token are valid.

2.2.2 WAC & ACL

Web Access Control inherits the access control schemes used in many file systems and ap- plies it cross-domain for decentralized systems. WAC deals with providing access to resources for different agents, including individual users, group of users, applications and more. The critical components of WAC can be described as follows:

• The URLs can identify any web document or resource. In this project, a patient uses a URL for the EHR directory to share it with a doctor.

• Web access controls are declarative, i.e. they can be reversed if needed.

• All entities, including users, resources or applications deployed using Solid implementation, can be identified using URLs.

The systems using WAC are contained with Authorization statements that describe the type of access and the agent who has this access. These statements are called Access Control Lists collectively.

2.3 Identification - Self-sovereign identity

Self-sovereign identity (SSI) can be considered a revolutionary model that enables corpora- tions and individuals to build and share identity traits in a regulated and interoperable manner.

(14)

By implementing Decentralized identification (DID), blockchain facilitates SSI. Moreover, to support SSI, blockchain provides a globally unique identifier omitting the centralized registration authority [19]. In a decentralized system, a subject associated with a verifiable claim is referred to as a DID [20]. Furthermore, Solid POD supports SSI in more or less the same way as blockchain technology. In Solid implementation, the decentralized extension of OpenID Connect authenticates unique IDs of users, omitting central authorities.

Figure 3: A model for self-sovereign identity [21]

This work proposed to use the DIDs and SSI to identify users referencing European Block- chain Service Infrastructure [21]. Standard Specifications such as eDelivery, eSignature, and eIDs are the foundation of European Blockchain Services infrastructure (EBSI). This implementation provides higher reusability as specifications are widely implemented in the software development industry to provide secure and reliable delivery of digital services [21]. Figure 3 shows the process of identifying a user with the use of eID block. This block implements digital identification, Authentication, and trust Services, collectively called eIDAS (electronic IDentification, Authentication and trust Services). In this paper, a connection between the proposed architecture and eIDAS is assumed to establish trust in the identification process. Verifier credentials are checked using signed DID documents that include the issuer’s public keys and the verifier’s eID identification. As a result, in the healthcare context, by relying on conventional knowledge about identities, the deployment of SSI infrastructure-based community-wide

(15)

eHealth systems reduces the administrative burden of validations and source authentication for healthcare bodies and patients.

As shown in Figure 3, a user owns an identity, i.e., their credentials to login on the blockchain network and WebId for her Solid Pod. These credentials are controlled by the issuer and verifier, and identity is confirmed, recorded on the digital ledger with immutable public key pairs of issuer and verifier.

2.4 State of the art

This section presents the related research conducted to provide decentralized solutions for data storage and exchange. Blockchain technology has gained prominence as a distributed ledger, following the paper published by Bitcoin in 2008 [13]. The fundamentals of Bitcoin emphasized a promising solution to remove centralized third parties while exchanging coins.

Traditionally digital transactions are traded with reliance on a trusted provider such as a bank. A trusted party may get corrupted, malicious, or face fatal system failures resulting in an insecure system for such practice. Moreover, the third party charges transaction fees, and there might be inevitable delays because of regulations for an international transaction. Bitcoin proposed a system to overcome these limitations with third-party involvement [13] [22].

Bitcoin, Monero, Dash, and Litecoin have contributed to Blockchain 1.0, which can be thought of as the first generation of blockchain technology. This version was more centric towards transactions between parties in a secure, immutable manner. Blockchain 2.0, generally knows as the second generation of the blockchain introduced smart properties in blockchain technology and smart contracts. With the emergence of Blockchain 3.0, the research found direction towards developing non-financial applications of blockchain. This version has found many applications with several utilities of technology such as identity management, insurance validations, and management systems for supply chain, to name a few [14] [22].

Research conducted in 2018 tells about 33 articles proposing blockchain implementation in the healthcare domain, and only 5% of proposed architecture based on blockchain were implemented [6]. One of the researches performed on use case scenarios of blockchain shows that there are six most discussed blockchain application areas: financial transaction, smart contracts and process application logic, data management, storage, communication, and ranking

(16)

[23]. Another research tells about the hurdles faced by blockchain implementations. The author draws attention to confidentiality issues in data storage using blockchain technology and scalability issues [24]. Blockchain data in the form of transactions are transparent to every peer in the network, resulting in higher vulnerability for data, which violates having secure decentralized data storage. The transactions might contain personal healthcare data, medical history, and other records combining to make Terabytes of data, which require a greater level of confidentiality, and the size of data might overflow blockchain’s storage capacity [25].

Following the related areas of applications where blockchain can be helpful is crucial and preliminary. Analyzing academic papers or practice-based work done in the same research realm will help understand this premise. However, a review of these research papers reveals that not all of the conceptual ideas for blockchain technology in healthcare have been realized as working prototypes. Understanding the real-time prototype of the blockchain working among the current applications of blockchain technology in the healthcare domain is, therefore, both essential and crucial [7]. A number of studies have found that the blockchain provides a de- pendable solution for specific healthcare function problems, such as protection, data security, data integrity, disruption, interoperability, access management, and simultaneous updates for medical information, assuming it is implemented correctly. However, there is a considerable number of constraints with blockchain deployment in the healthcare area. As others have found [6] [7], a practical implementation of blockchain to store healthcare-related assets raises many doubts, and there are significant challenges for researchers which require further investigation.

The healthcare industry is made up of many sectors that specialize in providing health- related services and goods. This domain is described as an industry that includes hospital, medical, and dental activities supervised by nurses, physical therapists, physicians, patholo- gists, and other allied health professionals. Healthcare works on preventing, diagnosing, and treating diseases, illnesses, accidents, and other physical and mental conditions to maintain and improve one’s health. As defined in the Introduction section, EHR systems require a specific set of security parameters when implementing using blockchain, which can be defined as (1) Privacy Concerns: Healthcare data should not be exposed to unauthorized parties. (2) CIA aspect of security: C stands for confidentiality which states that data can be accessed only by authorized users. I stand for integrity, which defines that data on storage, off the storage, or in

(17)

transit must not be altered. A stands for availability, which defines the data must be available to authorized user, whenever and wherever they request. (3) Auditablity: a critical element of security, Audit records, for example, primarily provide information about who has access to which EHR (or basic PHR), for what purpose, along with specifying the time of access. (4) Accountability: A person or an entity will be audited and held accountable for their actions.

(5) Authenticity: Authenticity is the ability to validate the identities of individuals requesting data. (6) Anonymity: For the sake of anonymity, organizations have no identifiable identifier.

Absolute anonymity is difficult to achieve, so pseudo-anonymity is more popular.

In order to achieve the security characteristics mentioned, the most critical requirement are storage, identification, and auditing for healthcare data. When safe storage is achieved, data protection should be guaranteed. The authors of Ref. [26] used private and public blockchain to store big data. The public chain holds the person’s storage address, and the private chain is storing the person’s data. In the storage scheme, two parallel chains are used. The authors used this scheme to assess the student’s learning behavior and the teacher’s teaching behavior.

The private chain is kept in distributed storage, while the public chain is kept in centralized storage. The achievements, credits, and rewards are stored in the distributed chain. In contrast, the record achievement, recognition, and bonuses, including images, audios, and image data, are stored in the central. The authors of Ref. [27] concentrated on the higher education system, where the same university has many campuses. A blockchain-based structure has been proposed to handle encrypted transactions to achieve immutability, including student records and certification.

Authors in their research have pointed out the limitation of blockchain technology in the educational field [26] [27]. Blockchain technology comes with an issue: the participation of every peer in the same chain and every peer in the network must validate the transactions. This approach could be a big issue for peers who do not want to involve in the validation process, who do not need to access the whole set of information [28]. In another proposal to strengthen the digital education framework, the authors of Ref. [29] suggested using blockchain-based storage to store the candidate’s digital credentials. The blockchain is a decentralized platform that allows for easy record tracking. This consortium chain is used to store the answers from students for a Quiz. These answers are matched against the right solutions available on the

(18)

public chain. However, the authors have not mentioned how consensus is reached or how transactions are disseminated using this method [30]. The shortcomings of these proposals, mentioned in earlier parts of this section, are that authors have neglected the scalability in the perspective of a larger size of data.

Another big concern with EHR on the blockchain is data storage for such a massive amount of data. Blockchain architecture will suffer a considerable burden by increased computational overhead if data is stored on the blockchain. There have been several pieces of research sug- gesting off-chain and on-chain solutions for such data storage. This approach might combine the traditional way of storing assets resulting in less burden on the blockchain. Users can also exit and rejoin the system at any time, with the index retrieved from the most recent block in the blockchain providing links to their historical record [31].

Zheng proposes a blockchain-cloud storage solution to store data generated by wearables devices for an extended time. One can buy this data for research purposes, and perform machine learning if user has enough permissions [12]. Similarly, researchers have proposed an architecture to store data on external storage to relieve the blockchain network [32]. A similar approach is proposed in a paper by Azaria. The use of off-line database cache storage as healthcare data with database gatekeeper [9]. Data requestors may access data in the cloud that includes an extraction signature to check the authenticity and legitimacy of the requested data [11].

Healthcare data comes in different formats such as images, texts, records, etc. Storing this sort of data on the blockchain is a big challenge. Patel et al. [33] presented a cross-domain framework to access medical images providing users with authority over data to delegate electronic access to others. Sun et al. [34] suggested trusted third-party database inclusion in the scheme to ensure data privacy. In this scheme, the user’s request signature is validated against the unique attributes already stored on the system.

The majority of the applications in the preceding parts use a traditional database architecture. Modern database services such as cloud computing ensure Quality of Service storage and the required capacity to process data with a latency cost in communication. Due to an extended set of services, this architecture has gained widespread acceptance. However, depending on third-party providers increases the likelihood of a single point of failure. Meanwhile, some

(19)

enigmatic cloud servers could be collecting confidential patient data without permission.

Few researchers have addressed the problem of third-party databases by introducing the In- terPlanetary File System (IPFS) combined with immutable blockchain technology. This proto- col is intended to resolve the problem of unnecessary file redundancy in a decentralized manner.

IPFS comes with different characteristics, such as files indexed on a hash value of file content instead of traditional paths that prevent storing the same file multiple times. Because of IPFS’s decentralized character, any files are permanently saved and can be shared. IPFS can generate duplicate data for high-frequency request data based on the previous request route. These data can be read directly locally in the subsequent request [35].

In Ref. [36], the authors created a framework that combines Blockchain 2.0 with IPFS to boost access management and decentralized character of data storage. Another research has proposed a system where data IPFS is used with an encryption scheme to make data confidential. Files are encrypted using a symmetric key with an AES (Advanced Encryption Standard) scheme. One more layer of security is applied by encrypting the hash value received from IPFS and uploaded as the transaction to the blockchain. For file retrieval, user authorization is checked using smart contracts. If necessary access rights are fulfilled, the user can download the file and decrypt it [37].

Although IPFS provides decentralization for nodes in the network, there are some disadvantages mentioned by some researchers. Ethereum is proposed along with smart contracts as a blockchain solution with IPFS to create a viable network. This approach is associated with the mining of blocks, and additional storage might be required [37]. Another challenge is getting permissions for multiple nodes in such a network, making the whole system expensive and complex. Furthermore, the default file size for IPSF is 256kb resulting in the segmentation of larger files. Research shows that the IPFS system does not delay as file size increases. Still, when IPFS associated with a blockchain for access control shows a bit slower delay [38].

As mentioned above, blockchain could be a solution for sharing data in a trustworthy environment as many validators are involved, and cryptography hashes are used to secure the integrity of transactions. Moreover, fine-grained access control can be created using smart contracts provided by blockchain platforms such as Ethereum. An inherited property, the immutability of blockchain offers data security in many aspects and for many sectors, including healthcare.

(20)

IPFS has been discussed as one of the most robust solutions for storage challenges in blockchain technology. Many researchers have presented a practical approach to combine blockchain with IPFS to achieve a greater level of decentralization. Some researchers have found performance issues in this strategy as well, as mentioned above in the report.

This document proposes a combination of Solid Pods and blockchain to achieve complete decentralization, secure access management and immutable logging. Linked Data Resources, Decentralized Web, Pod Servers, and Solid Applications are the four essential layers that make up the Solid ecosystem. Users own the Linked Data Resources, which they can store in their online data stores (PODs) through the Decentralized Web. Solid Applications must first acquire an identity profile from the Pod Servers before accessing data in the user’s pod to access Linked Data Resources. In the scheme this document offers, when a Solid application or Solid individual users requests a linked data resource, an authorization control is done with the help of smart contracts using blockchain. Users are authenticated by blockchain, and further access is given if the proper access is acquired.

(21)

3 Method

This project principally practices design research methodology as described by Peffers et al. in [39]. The author describes this method as developing various types of artefacts in the form of an Algorithm, construct, framework, instantiation, approach and model. A model is defined as representing a possible solution to a problem, whereas deriving algorithms imply an approach of describing a process in the model by a set of instructions. Furthermore, Johan- nesson et al. [40] have described five activities for the design research method. Activity 1, Problem explication, investigate the practical problem and its significance in real-life scenarios. Activity 2, Define Requirements which outlines demands on the proposed artifact. With Activity 2, problems are transformed into requirements for artifacts to achieve desired results.

Activity 3, Design and development, consist of creating an artifact to address the explicated problems in Activity 1. Demonstration of the developed artifact is conducted as Activity 4, which presents how the proposed artifact solves the problems defined in Activity 1. Finally, Activity 5 evaluates the artifact for its efficiency and reliability for solving the practical problems which prompted the research.

This degree project is focused on solving the problem by defining a model with the required constructs. Model creation is generally linked with multiple sub-activities such as idea generation, assess & select, sketch & build [40] [39]. This project will follow a combination of germinal and transformational methods for idea generation activity, where the germinal way is where the researcher starts with a clean paper and starts to brainstorm, and transformational approaches to develop models can be defined as generating ideas by modifying existing ideas.

The second sub-activity to derive a model solution is choosing one or more ideas generated during the idea generation phase. This process requires the researcher to think convergently over different approaches presented earlier to develop an artefact. Following idea generation and asses & select sub-activities, the final sub-activity creates a sketch of the artefact based on analysed ideas during previous sub-activities. The sketch will be used to build the architecture in this thesis project.

Researchers have classified evaluation strategies for model solutions in Ex-ante and Ex-post evaluations [40]. Ex-ante evaluation can be defined as evaluating artefacts without being im-

(22)

plemented or fully developed for a real-life scenario. In contrast, the Ex-post strategy requires artefact to implemented and employed to assess. Ex-ante evaluation strategy is considered suit- able for this project the most as it comes with benefits; no significant resources are needed, no real users are required to interact with the artefact. Instead, the researcher can use illustrative scenarios to evaluate the artefact by setting up functional and non-functional requirements [40]

[39]. Following this evaluation approach, the requirements will be set for the model solution, and algorithms will be derived to address the requirements. Finally, this project will evaluate requirements with step by step discussion illustrating the utility of the artefact.

3.1 Reliability and Validity

All requirements are explicitly mentioned to bring reliability to this project, and their fulfill- ment will be evaluated. The thought process and derived algorithms to achieve success in the project are graphically and textually described. Only peer-reviewed documents are followed during the development of the artefact. Moreover, the theoretical background on constructs used to develop artefact is presented in detail, referencing peer-reviewed papers. Since this approach of storing and exchanging data is relevantly new, a comparison of existing similar methods is presented in Section 5.3. Artefact will be proved theoretically with the help of existing knowledge and the utilization of well-established protocols. However, the artefact must be developed carefully, and excessive testing should be done to prove its reliability before implementation in a real-life scenario.

3.2 Ethical considerations

Since the project will provide a reference architecture to solve the problem, human data is not required at this stage; hence there are no ethical considerations involving individuals.

Blockchain technology has provided many security attributes to the artefact, but the researcher has well-considered power consumption by the mining process in the blockchain network, which might not be environment-friendly.

(23)

4 Result: The design artefacts

This Chapter presents the Design and development of the artefact. This process involved existing researches, brainstorming, sketch and build and justify the proposed artefact. Further- more, Section 4.1 presents the functional and non-functional requirements and motivation for their existence for the model solution and offers further layout of this chapter.

4.1 Requirements

During the project development phase, requirements for reference architecture emerged, and algorithms in this project were defined to fulfil these requirements. The requirements are not ambiguous and are explicitly stated in table below and will be discussed in this section. All requirements will be referred to by their numbering as the sections follow, e.g., REQ(x).

REQ1 The artefact must support secure auditing.

REQ2 User must be able to register on the system.

REQ3 User must be able to upload a file.

REQ4 User must be able to provide access to a file.

REQ5 User must be able to read or append a file.

Table 1: Requirements for architecture

REQ1: The literature studies conducted during the project have pointed at a potential threat of denial of unauthorized user’s actions in the healthcare domain. A user might access the data with malicious intent and might alter information for social benefits. Moreover, some medical agencies might be involved with money craving companies selling medical equipment; hence there might be chances of unnoticed access to data that those companies might use to target patients based on their medical background. In other words, authorized users with malicious intent should be accounted with the help of immutable logging. By fulfilling this requirement, the system will provide the user with non-repudiation by recording all the actions, including identification, authentication, and access to resources. REQ2: The model solution must ac- commodate different entities like patients, doctors, hospitals, insurance companies, etc. Still,

(24)

Like any other domain, the user must have the right to accept or deny services provided by the healthcare domain. This requirement is derived to get user’s to consent to register on the system and facilitate user with the proposed solution.

REQ3: In some scenarios, there might be different medical organizations involved in treatment. A patient might need to get treatment from another country than origin; in that case, the system must provide a user with an upload service so that delays occur because of data sharing process by the middle parties can be omitted. REQ4: Healthcare data possess users’ personal information; this project emphasizes that access to these records must be limited to desired entities. This requirement is set to provide the user with complete control over access management of personal healthcare data. REQ5: In a medical infrastructure, patients have the right to read personal health records, and a doctor must have access to read and append patients’ healthcare records if needed. This requirement for the system advocates these fundamental rights of users.

The Chapter further presents the architecture developed in Section 4.2 to answer REQ 1.

Furthermore, to address REQ 2 - 5, algorithms for proposed architecture are derived. The Table 2 lists the Sections and Algorithms along with their corresponding targeted requirements and evaluated requirements:

Sections / Algorithm Requirement(s) 4.2 Architecture Development 1

4.3 Justification of Artefact 1

Algorithm 1 1, 2

Algorithm 2 1, 3

Algorithm 3 1, 4

Algorithm 4 1, 5

Table 2: Sections addressing Requierments

(25)

4.2 Architecture Development

The proposed architecture for Electronic health record sharing and mutability is presented in Figure 4. This architecture offers separation between different parties on different levels of access to the system. Hospitals, Medical stores, Insurance companies, laboratories, and patients are various nodes in the system. All the nodes are connected to their respective Solid Pods. Users are in charge of choosing the storage capacity for their PODs, depending on the purpose of POD. Data is transferred and accesses as per Solid Pods specified protocols. The use of blockchain technology in this architecture provides immutability, a layer of authentication, non-repudiation to any action performed by parties.

All nodes are authenticated two times, once when connected to the blockchain network and secondly when they login to their Solid Pods. In this approach, it has been assumed that data on the pods is encrypted using some reliable encryption scheme. The system contains the following entities to keep the data secure and available:

• Patients: A patient is a centric user of the proposed system with a unique WebID, public key pair provided by blockchain technology. The user themselves is responsible for their encrypting her data and managing the personal online data servers. Users can decide where to store the PODs, like users may choose to keep their POD on the local machine, alternatively on cloud storage.

• Hospital: A hospital is another crucial user with a unique WebID, public key pair provided by blockchain technology. Hospitals are responsible for healthcare in any region.

Hospitals might generate electronic health records, inform and update other concerning parties about individuals’ health status.

• Doctor: A user with a unique WebID and public key and password to login on to a blockchain technology platform. The doctor is responsible for creating a patient record and might be a frequent requester for patient data.

• Laboratory: Another user of the system possesses the same authenticating attributes as Doctor, Patient, and Hospital. The laboratory is responsible for examining patients as asked by the doctor.

(26)

Figure 4: Proposed Architecture

• Medical Shops: A user connected to the decentralized web with a WebID and keys to communicating using a blockchain network. These shops are responsible for providing prescribed medicine to patients.

(27)

• Governmental Authority: This document assumes that Government should be a top-level organization controlling all necessary measures for healthcare and its citizens.

User is referred to any entity in the proposed system. A User is responsible for managing their PODs. As of Solid specification, the user is responsible for data security on the personal servers with measures such as encryption. A user creates a subdirectory in their public or private directory for sharing it with other parties. The user is accountable for managing access to any resource on the Solid Pod. A usual flow of granting access to a WebId is presented in Figure 5.

Figure 5: Flow of providing access to users

The structure of the patient node and records sharing and accessibility can be described as follows:

Record Structure {PA, PW ebID, ResourceU RL, Fh, DW ebID }: This includes the public id of the patient, and the PA is the unique URL presenting a patient. Resource URL is the URL for the linked resource and RH is the hash of the record, and DW ebIdis the doctor’s unique WebId on the Solid ecosystem.

Node Structure of a patient {PW ebId, PA, DW ebId, PACL, H}: WebId is a unique id for the patient to log in to Solid PODs. Ppub is the public id used to login into a blockchain network, DW ebIdis the unique id for the doctor who might need access to the directory in PODs. DW ebId

can be replaced with any other entity of the architecture. PACLrepresents the access list created by the patient in which many users as accessors can be defined. H represents the hash of all the

(28)

components.

4.3 Justification of Artefact

A Solid implementation with blockchain is the core of the proposed architecture. Solid provides users with ownership, decentralization of data, while blockchain provides immutability, secure access logs, and an extra layer of authentication using blockchain API. Figure 6 presents crucial components of the proposed network for trust establishment and immutability.

• Solid Applications: To demonstrate the architecture, a simple web application is implemented tightly connected with Solid Pod and blockchain.

• Blockchain Network: Proposed blockchain network in this architecture is a permissioned blockchain implemented on the Ethereum network for testing purposes. Smart contracts are used to validate and authorize users in this network. This network consists of sub- mitting peers providing client interface for users such as doctors, patients, hospitals, to name a few, endorsing peers working on the backend to validate transactions. Blockchain network will record any action by Solid after reaching the consensus among peers.

• POD Servers: User deploys their personal online data servers on publically available cloud services (Solid Community and Inrupt at time of writing) or self-hosted. Unlike the traditional way of managing data, a pod server is an entirely user-controlled server. Users provide access to their PODs using requesters WebId in the Solid ecosystem. Moreover, since data is written in the resource description framework, which is standardized for existing applications over the web, users can also provide permissions for applications like 1177.se, Spotify, etc.

• Decentralized Web:

– In the proposed architecture, every user is responsible for their data.

– Peers monitor blockchain.

– All the requests made to some POD are recorded and distributed as an encrypted transaction throughout the network.

(29)

• Linked Data Resources: In the proposed architecture, all folders under a Solid node- server, including public and private, are considered linked data resources. However, there are technical differences between linked and non-linked data, which are not emphasized in this architecture.

Figure 6: Solid with Blockchain

A general flow for requesting and accessing some data in the proposed implementation is presented in Figure 6.

Step One: A user logs in to the blockchain network and Solid PODS, using the public key and WebID, respectively.

Step Two: When a user interacts with API to request and access some data, authorization is validated and recorded on a new transaction on the blockchain network.

Step Three: POD Servers and decentralized web continuously monitor the blockchain network if all the blocks are expected

Step Four: If a blockchain network authorized a request, a successful transaction is made, then POD/ decentralized web provides the linked data resource to Solid applications.

(30)

4.4 Algorithm Derivations for Artefact

This section presents the derived algorithms for Smart Contracts during the design and development activity of the design science research process. Smart contract in the proposed system contains several functions as presented in Figure 7 for every object: (1) A controller:

stores the different users’ lists, authenticates the users, and authorizes the users. (2) user nodes support uploading files, providing permission on linked sources, and getting access to file functions. Each algorithm is demonstrated and evaluated against the defined requirements in Section

Figure 7: Functios in Smart Contract

4.1 by the supervisor at Linnaeus University. The main acronyms used in the proposed scheme are presented in Table 7. Algorithms are presented below with their corresponding requirement:

REQ2: User must be able to register on the system

Algorithm 1 provides the user with registration functionality on the system. The assumption are made for this function that, a correct role is presented while registration on Solid ecosystem, as shown in Appendices A.4 and three lists Doctor List (DL), PL, and W ebIdL, are populated with public addresses of users and WebId of users, respectively. With the help of Web3 API and Solid libraries, the Algorithm checks if the entered Ethereum address and associated WebId exists in the lists. In case of existence, the registration request is discarded.

(31)

Algorithm 1: Algorithm to register a User

1 Step 1 Check I1 ==(msg.sender is in (DL||PL)), if blockchain address is already registered and exists in either list of doctors or in list of patients.

2 Step 2 If I1 == true discard the request and go to Step 9

3 Step 3 userW ebId == msg.sender.WebId, check if I2 == W ebIdL.exists(userW ebId) the WebId associated with the blockchain address already exists in list of WebIds

4 Step 4 If I2 == T rue then discard and go to Step 9

5 Step 5 Check registered role for the user in Solid PODs (R = userW ebId.Role), R result in "Doctor" or "Patient" for this implementation

6 Step 6 if R == "Doctor" then

7 if role retrieved is Doctor, then store the address DL.push(msg.sender) in list of doctors.

8 else

9 else push (PL.push(msg.sender)) the blockchain address to patients list

10 Step 7 emit Print a message of successful registration.

11 Step 8 Stop.

REQ3: User must be able to upload a file.

Algorithm 2 is used to upload the file into the system. According to the need for healthcare data, this access is given to both parties, doctor, and patient as shown in Appendices A.6. For instance, in a region where a patient must collect their laboratory results themselves and inform the doctor, upload a file is required. The doctor should have permission to upload health records on the patient’s PODs and inform the patient about the health situation. To perform an upload, the algorithm checks that the parameters I1 and I2 are fulfilled, i.e., the user is logged in and registered on the system, and both platforms are connected, as shown in Appendices A.3. If the user is a patient, then the conditional check is omitted for this user as a POD owner. If a doctor uploads the file, a WebId must go under conditional operations to check if the requestee acquire the rights to do so. The proposed system assumes that the patient hosts her POD with encryption service for data on rest. Because of data sensitivity, the system provides encryption when a doctor uploads a file, and a symmetric key is provided to the patient to view the data.

(32)

Finally, Smart contract generates the block for the transaction as shown in Appendices A.2, Algorithm 2: Algorithm for Uploading File

1 Step 1 User logs in using her public key pair generated in blockchain platform registration process

2 Step 2 Check if (I1&&I2) blockchain address exists in Doctor/Patient list and WebId associated with blockchain address exists in the W ebIdL

3 Step 3 Check registered role for the user in Solid PODs (R = userW ebId.Role), R result in "Doctor" or "Patient" for this implementation

4 Step 4 if (R == "Doctor") then

5 D_{W ebId}== user_{W ebId}retrieve the WebId of current user, then check

6 if (PW ebId.get(PACL).exists(DW ebId)) then

7 if (DW ebId.HaveP ermissionT oU pload) then

8 CF = E(K, Fr) Create cipher-text of the file

F_h = HashAlgorithm(C) Create hash of the cipher-text

9 else

10 Discard go to Step 7

11 else

12 Discard go to Step 7

13 else

14 R is a patient and owner of her Solid Pod. Thus this user is allowed to create, read, update and delete (CRUD) files.

15 Step 5 Tid + +, increase the counter of Transaction id

16 Step 6 Generate transaction (TX = (Tid, Hid, DA, PA, DW ebId, PW ebId, Fh, D, T, L, K), by including transaction id, hospital id, public addresses of doctor and patient,

WebIds of both receiver and sender, hash value of encrpted file, date, time, location and symmetric key.

17 Step 7 Stop and Print a message accordingly.

following Algorithm 2, and the transaction is distributed over the network.

(33)

REQ4: User must be able to provide access to a file.

Algorithm 3 is a patient-centric function. This algorithm is used to add the permissions for the users, must have access to the resources. In this paper, a doctor appointed at a hospital taking care of a specific patient is considered to have permissions to create, read, update and append to exiting information. In the algorithm, initial authentication is controlled. If the user exists on the system, the user proceeds to provide permission for a WebId, or first create a directory and provide permission for the concerned requestees. This function terminates with generating a transaction, including all required parameters.

REQ5: User must be able to read or append a file.

Algorithm 4 is responses call for reading and append by the user. User’s actions are verified and checked with the help of conditional statements; if valid, proceed further, else rejected by the system. Control is performed to check the requestee’s role and permission provided by the owner of POD. If the WebId is matched with the proper role, the user can read or append. The patient is forbidden to change/overwrite her health records, so only read permission is provided to existing information. Lastly, all tasks performed are recorded on the ledger using blockchain.

(34)

Algorithm 3: Algorithm for Sharing a File Input: DW ebIdis required for providing access.

1 Step 1 User logs in.

2 Step 2 Check if (I1 == true) && If (I2 == true)

3 Step 3 Check registered role for the user in Solid PODs (R = userW ebId.Role), R results in "Doctor" or "Patient" for this implementation

4 Step 4 Check

if (R == "Doctor") then

5 Print "This WebId belongs to a doctor currently working at Hospital(Hid). To proceed with this action, a patient WebId is required."

Discard and go to Step..

6 else

7 Fetch the directory

8 I₃ = (P_{W ebId}.exists(D_share) if (I3 == true) then

9 I₄ = D_share, store shared directory in a variable to perform operations.

10 else

11 Create a Directory to Share ((PW ebId).create(D_share)) I4 = Dshare

12 Step 5 Get the current Access List on the directory (I4.getAccessList())

13 Step 6 Give required permissions

(I4.getAccessList().setP ermissionsF or(PLS, DW ebId)) for a specific WebID

14 Step 7 Tid + +, increase the counter of Transaction id

15 Step 8 Generate transaction (TX = (Tid, PA, DW ebId, PW ebId, PLS, D, T, L, K), by including transaction id, hospital id, public addresses of doctor and patient, WebIds of both receiver and sender, hash value of encrypted file, date, time, location and symmetric key.

(35)

Algorithm 4: Algorithm for Reading/Appending a File

Input: userW ebId for a doctor/patient is required for providing access and URL for requested Dshare

1 Step 1 User logs in.

2 Step 2 Check if (I₁ == true) && If (I₂ == true)

3 Step 3 Check registered role for the user in Solid PODs (R = userW ebId.Role), R results in "Doctor" or "Patient" for this implementation

4 Step 4 Check the role and request made by user

5 if (R == "Doctor" || "Patient" && R_LS == ”Read” ) then

6 if (R == "Doctor" && RLS == ”Read”) then

7 Iterate through the Access List PACL,

(I5 == (I4.getP ermissionsF or(DW ebId) == PLS.Read)), if I5 == true, the doctor accesses and read the file else discard and go to Step ..

8 else

9 If requester is Patient herself, an access is recorded.

10 else

11 if (R == "Doctor" && RLS == ”Append”) then

12 Iterate through the Access List PACL,

(I5 == (I4.getP ermissionsF or(DW ebId) == PLS.W rite)), if I5 == true, the doctor accesses and update the file else discard and go to Step 7

13 else

14 If requester is Patient herself, an access to write on existing health record is denied. Step 7 is executed.

15 Step 5 T_id + +, increase the counter of Transaction id

16 Step 6 Generate transaction (TX = (Tid, userW ebId, Dshare, RLS, PLS, D, T, L), including transaction id, requester’s WebId, requested URL, requested access type, permissions found for requester, date, time, location.

(36)

5 Evaluation & Discussion

This chapter presents the Evaluation of requirements defined in Section 4.1 against developed artefact. Subsection 5.1 presents a conceptual evaluation for REQ1 , and REQ2-5 are evaluated in Subsection 5.2:

5.1 Security Analysis

The architecture presented in Section 4.2 assumes that the connection between a patient/

doctor and a device is secure. Users understand their responsibility to handle the devices hold- ing their credentials securely. Public keys for blockchain and WebIds for Solid PODs must be saved securely. It is assumed that users are well-educated with the use of the system and related vulnerabilities with their keys. Any third person without having proper permission to access resources can be thought of as a malicious actor. This section presents how the proposed architecture addresses EHR data security attributes found during research in Section 2.4.

Confidentiality: Data confidentiality is assured at two levels in our proposed architecture. Ac- cording to Solid POD specification, the user can store data on the local server or any other cloud storage provider, where the user is responsible for the security of data, i.e., if the user wishes, an encryption service can be bought [16]. However, in the derived Algorithm 2 for artefact, the user must be aware that healthcare records stored on a personal online data server must be encrypted and in order to do that, user can adapt to any standard encryption solution for data, based on hosting choices for PODs. Moreover, whenever a user uploads the file to the system, the file is encrypted (CF = AES(K(Fr))) using AES symmetric key (K), key is further encrypted using the intended receiver’s public key (PA/DA) and logged on the blockchain network. For instance, if a Doctor uploads a patient’s health record, doctor must be logged in using blockchain public key (DA) and Solid WebId (DW ebId); while uploading the file(F r), AES key(K) is used to encrypt the file, and the key is encrypted using patients public key(PA) and logged on the blockchain ((TXincludesK¹ = E(PA(K))). To decrypt the file Patient must use the private key (PP ri). Hence intended user can access the file, and confidentiality is achieved.

The solid implementation supports TLS 1.3, so the proposed architecture requires users to con-

(37)

figure TLS encryption to secure data in transit.

Integrity: The system uses a well-developed way of comparing hash values of files to maintain integrity in the system. When a user uploads a file, the system generates a hash H of the file before uploading it to the Solid pod. So, according to the system proposed, previous record meta-data is provided along with the file requested. An integrity check in the system can be explained as in the Algorithm 5.

Algorithm 5: Integrity check of the file.

Input: User has access to the uploaded files (F_r:1, F_r:2, F_r:3, F_r:4...F_r:n)

1 User requests a file using Algorithm 4

2 User receives meta-data (Fh:1, F_h:2, F_h:3, F_h:4...F_h:n) of the files along with files.

While uploading a file, the meta-data for the file Fh:2is computed using the previous file metadata i.e. H(Fh:1||F_r:2)

3 User request a file, to say Fr:12, the user gets the metadata of previous file Fh:11 4 A mapping is done by hashing Fr:12 and I6 == (F_h:11||F_r:12)

5 if I6== true then

6 File is not tempered and integrity achieved.

7 else

8 Reject the file and inform the relevant parties.

Availability: Users can create PODs on a local server and the same POD on a cloud server to introduce redundancy. Users can have multiple cloud accounts to store the PODs linked to the same userW ebId so that in case of failure of one site, data can be retrieved from another site.

At the time of writing, only two cloud providers avail their services for Solid PODs: Solid Com- munity network and Inrupt Services. As proposed algorithms suggest, users, to have their POD on both service providers in such way that Availability = (SolidCommunity||InruptServices).

Moreover, Blockchain transactions are stored in a decentralized manner; hence, even if some peers are compromised, access logs and smart contracts will be available on the network.

Hence, data availability can not be harmed if one point failure occurs.

Privacy of Users:The architecture proposed in Section 4.2 puts Solid ecosystem and Blockchain together to achieve a decent amount of decentralization in healthcare data communications

(38)

among different parties. Decentralization characteristics of the system eliminate the requirement for a intermediate authority, ensuring the privacy of users. Moreover, the proposed system provides decentralized storage as every user owns the data, i.e., POD, and data transfer is carried out in a decentralized way. Furthermore, blockchain technology is the core of the proposed system, which secure privacy by:

• Data verification and time stamping of transactions(TX) on all nodes in a network prevent replicated identities.

• Hashing algorithms secure data against tampering.

• Manipulation in data processing is prevented using several consensus mechanisms such as proof of work, proof of stake, to name a few.

REQ1:The architecture must support secure auditing.

Access Control and authorization:The proposed system provides users with registration functionality and access to resources based on the user’s role. In this system, the Ethereum blockchain platform with the use of smart contracts is suggested. Several algorithms are created for smart contracts in the Section 4 to check the user’s role for different actions a user can perform. For instance, if a user has a role "patient" on the system, a request for writing or deleting a file is discarded.

Furthermore, the Solid ecosystem uses Access Control Policies (ACP) along with Web Access Control (WAC) depending on configuration, to accomplish authorization of data sources [41]. An agent in Solid implementation can be an individual, an organization, the group that has a WebID as an identity as shown in Appendices A.5. A user is in control of access management for these identities for different users with WebIds. In the proposed system, a user permits different agents like doctors, hospitals, nurses, insurance, to name a few. Appendices A.6 demonstrates where a user has ownership of data, and a doctor named "Doctor01" has provided edit permissions on a file. For instance, in the proposed system, whenever a doctor requests the system for reading a patient’s health record, as described in Algorithm 4, WebId is looked for the patient’s access list after successful authentication. If permission exists for requested action, the doctor can go further; otherwise, access is denied, and an error message is displayed.

SHARIF: Solid Pod based Secured Healthcare Information Storage and Exchange Solution

Bachelor Degree Project