1 Introduction

While various industries benefit from the opportunities offered by digitization, the healthcare sector continues to face challenges in implementing these in a targeted and broadly supported manner. This is particularly important in the exchange of patients’ data, as many healthcare stakeholders rely on accurate information about previous treatments to provide the best possible care (Poston et al. 2006). Information Systems can enable fast and accurate communication, which modernizes today’s healthcare processes where medical reports are primarily sent by post and coordination usually takes place by telephone or fax (Foronda et al. 2016). Personal health records (PHRs) have the potential to substantially improve communication in healthcare such that authorized stakeholders have immediate access to patient health data in real time (White and Danis 2013). This would significantly reduce misunderstandings, redundant examinations, adverse drug events and delays in treatment (Chao et al. 2013). In addition, the transparent access to personal health data might increase health awareness of the patient (Meier et al. 2019). Given their numerous advantages, PHRs have been established in many countries worldwide, such as the Netherlands, USA, Canada New Zeeland, Estonia and Scandinavian countries (Al-Aswad et al. 2013; Amelung et al. 2016). In contrast, the adoption of PHRs in other developed countries, e.g. Germany, is hampered by data privacy and data security concerns (Hoerbst et al. 2010; Nohl-Deryk et al. 2018; Adelmeyer et al. 2019). The anxiety associated with unauthorized persons gaining access to sensitive patient data through security breaches is regularly confirmed by hacker attacks on PHR providers (Healthcare-IT-News 2018; Gillum et al. 2019; Kerkmann and Micijevic 2019).

Similar to the healthcare industry, the financial sector handles sensitive and private data that must be effectively protected from unauthorized access, manipulation and misuse. Since Nakamoto introduced Bitcoin in 2008, blockchain technology has gained tremendous popularity in various fields of application (Nakamoto 2008; Beck et al. 2017). In particular, blockchain technology improves the traceability of transactions and contributes to disintermediation, thus strengthening the required trust between (business) partners in their shared transactions and data (Weber et al. 2016; Rückeshäuser 2017). Given the decentralized system and consensus mechanism, each transaction is unchangeably recorded. Blockchain was subsequently discussed as a promising solution in the healthcare environment as well (Mettler 2016). Estonia, as a pioneer in digitization—especially e-government—already implemented an EHR in 2008. Eight years later, the Estonian eHealth Foundation started a new era in securing healthcare data by safeguarding off-chain stored EHRs using blockchain technology that logs all data access activities (Einaste 2018). The blockchain ensures that users own and control their personal data. Our system respects the fact that the user owns the data and only gives access to the data to healthcare professionals after approval by the user. The access control is fine-grained, thus strengthening compliance with data privacy and data security. For example, users can revoke access authorizations at any time or grant one-time access only. Moreover, the accesses are logged transparently and traceably.

However, since the legal and organizational requirements of healthcare systems are highly heterogeneous in different countries, existing solutions are not unrestrictedly transferable into other healthcare systems. In addition, an EHR requires healthcare institutions to administrate the data. By using PHRs and by considering open standards and interfaces, both patients and healthcare providers can continue to use their own familiar systems. Various generic architectures have been suggested in the scientific literature in the healthcare informatics and information systems domain (Roehrs et al. 2017; Ekblaw et al. 2016). However, to the best of our knowledge the generation of design principles (DP) and recommendations for a blockchain-secured PHR are currently missing. This motivates us to address the following research question (RQ) in order to make design knowledge for blockchain-secured PHRs applicable and transferable:

RQ:

How can a patient-centered blockchain-secured PHR that stores health related data and is managed by the patient be designed and evaluated regarding user’s acceptance?

To answer the RQ, we conducted a systematic literature review to identify relevant issues. These issues were consolidated into meta-requirements (MRs) and transformed into three DPs. We subsequently considered the DPs by developing the PHR OSHealthRec which manages the authorization and access rights via a blockchain and stores the data off-chain within a 1-year research project. The system was evaluated in four iteration cycles with three feedback loops to achieve the best possible user acceptance.

Our findings reveal relevant insights for research and practice. The systematic development of three DPs as well as the findings from our evaluation cycles may serve as valuable knowledge for further developments (Gregor and Jones 2007; Beck et al. 2016). Moreover, the medical practice and decision-makers for the implementation of PHR systems gain substantial insights into the potentials of user-centered blockchain-secured PHR solutions.

2 Background and related work

2.1 Evolution of personal health records

In the scientific literature, as well as in practice, there are numerous different terms for PHRs (Angst et al. 2006; Al-Aswad et al. 2013; Heart et al. 2017). In the comparison of international literature in particular, various terms are used for the same concepts, and the same terms are simultaneously used for different concepts (Haas 2017). Therefore, this chapter defines the evolution of PHRs and which conceptual understanding of a PHR is the basis of our research.

First, a distinction must be made between patient records and personal health records. Patient records are administrated by healthcare professionals and usually imply that someone is ill and/or has a treatment within a healthcare institution. The initial type of electronic health record (EHR) was the digital storage of patient-related documents within an institution, for example by scanning medical reports (internal electronic patient files). In the context of increasing cooperation between healthcare professionals, patient data should be stored in electronic files that can easily be shared across institutions in the next step (cross-institutional electronic patient records). However, each patient record still implies that a person is having a treatment in at least one healthcare institution.

In contrast, a personal health record is administrated by the user him- or herself and does not require any institutional treatment or therapy (Burrington-Brown et al. 2005). Without having health-related issues, users can track their health status and health-related data, and they can pursue health prevention. In addition to professional health data, users can store wellness data, such as vital signs, measured by wearables (Gay and Leijdekkers 2015; Meier et al. 2019). Apart from the advantages of data sovereignty and self-determination, a patient-centered health record causes problems with regard to data quality and completeness of the record. Patients have the opportunity to conceal important information because they might feel uncomfortable about it and cannot assess the relevance of this information for other potential treatments (Tang et al. 2006). Typical examples of withheld information are infection with AIDS or the use of Viagra, which could be kept secret because patients might feel ashamed. Nevertheless, patient-centered health records appear to be better accepted by patients, who seek more self-determination with regard to their health-related information (Klecun 2016).

The advantages of a PHR are its continuous availability; time-, location- and device-independent access; and increased transparency (White and Danis 2013; Haas 2017). To date, many healthcare systems are comparable to a black box, to which only healthcare professionals have access (Busse et al. 2013); usually patients only have access to their own data on request. Presuming that the data are safe and protected against manipulation, a PHR contributes to better involvement of the patient in his or her healthcare treatment. This increased empowerment can motivate him or her to better comply with therapy instructions. In addition, PHRs support efficient communication and information exchange, and they avoid redundant treatments, which enable time and cost savings for healthcare systems (Chao et al. 2013; Haas 2017).

2.2 Blockchain in healthcare

Given the advantages of blockchain technology, including being tamper-proof (Risius and Spohrer 2017; Kumar and Mallick 2018), a strengthening in required trust in transactions between (business) partners as well as the permanent traceability of transactions (Swan 2015; Weber et al. 2016; Rückeshäuser 2017), its use is currently being discussed, field-tested and evaluated in various sectors (Beinke et al. 2018; Friedlmaier et al. 2018). These advantages make blockchain particularly attractive for healthcare scenarios in which highly sensitive patient data are transmitted. However, there are also challenges, for example in terms of data protection. In the health sector in particular, extremely sensitive personal data is collected, stored and processed. With the General Data Protection Regulation (GDPR), the European Union has adopted a comprehensive set of data protection regulations. For example, articles 17 and 18 of the GDPRFootnote 1 guarantee the right to delete or modify data. Furthermore, the GDPR contains explicit guidance on the handling of health data (e.g. articles 35, 45, 53, 54, 55).Footnote 2 The right to modify or delete data would not be feasible with a blockchain that stores the data in a tamper-proof manner. Therefore, we have decided to use off-chain data storage and thus follow the recommendation of the European Parliamentary Research Service (Finck 2018). The off-chain storage of personal data enables us to delete (or modify) data. By using a private blockchain we deliberately restrict the circle of blockchain operators. Potential operators in this case would be, for example, a consortium of doctors’ and pharmacists’ associations and health insurance companies.

Various researchers, such as Linn and Koo (2016), Mettler (2016), Stagnaro (2017), Gordon and Catalini (2018) and O’Donoghue et al. (2019), have investigated the potentials of blockchain use cases in health, IT and healthcare-related research. Rono (2016) developed, implemented and evaluated an eHealth interoperability platform for Nairobi health facilities to enable fast and secure data exchange between healthcare stakeholders. Kuo et al. (2017) identified explicit use cases for blockchain in healthcare and derived the key benefits of improved medical record management, enhanced insurance claims, accelerated clinical or biomedical research and advanced biomedical or healthcare data ledgers. Apart from the high potential, the authors also identified key challenges such as transparency and confidentiality, speed and scalability, and the threat of a 51% attack.

Further research focused on the use of blockchain technology to secure PHRs, such as studies by Roehrs et al. (2017), da Conceicao et al. (2018), Dagher et al. (2018) and Beinke et al. (2019). Leeming et al. (2019) identified 11 solutions for blockchain PHRs, five of which—Guard Time, Carechain, Dovetail, MedRec and Medical Chain—are published in Whitepapers. So far, only a few approaches have been implemented and evaluated, such as OmniPHR by Roehrs et al. (2017), MedRec by Ekblaw et al. (2016) and FHIRChain by Zhang et al. (2018).

2.3 Best practices of blockchain-based personal health records

Medrec is a blockchain-based EHR on the basis of Ethereum smart contracts (Ekblaw et al. 2016). The system provides comprehensive information to a patient and allows for integration into existing information systems by healthcare professionals. The authors claim that Medrec constitutes a proof of concept about the ability of blockchain to secure medical information within an interoperable environment and to increase transparency in healthcare (Ekblaw et al. 2016).

OmniPHR Roehrs et al. (2017) present the development, prototype implementation and evaluation of the blockchain-based OmniPHR, which works with the interoperability standard openEHR. Systematic evaluation with a performance experiment revealed three major findings: (1) the combination of the “openEHR standard with the blockchain technology created a unified and interoperable view of health data.” (Roehrs et al. 2017); (2) the Chord algorithm for data replication seems to offer a more efficient and scalable solution than using crypto-currency platforms, which is an essential benefit for an area-wide and uniform solution; and (3) an empirical evaluation demonstrated an adequate network-level performance of OmniPHR. Overall, the authors propose the use of blockchain to effectively integrate PHRs for a large number of patients by considering interoperable health data standards.

FHIRChain Zhang et al. (2018) systematically identified the requirements and their implications for a blockchain-based PHR to share clinical data and accordingly developed an architecture for the FHIRChain. The system was subsequently evaluated within a case study of collaborative decision-making for remote cancer care. The key findings were that FHIR provides “trustless, decentralized storage for necessary meta information and audit logs” (Zhang et al. 2018). Moreover, the system enables fast data exchange without necessary uploads and downloads and the maintenance of access rights.

In addition to prototype solutions from research projects, Estonia, which is one of the pioneers of the digitization of public services, is using a productive blockchain-based EHR. A nationwide EHR was already established in 2008, and in 2016, the country launched a new EHR using KSI blockchain technology (e Estonia 2020; Guardtime 2020). It is organized such that every physician potentially has access to all available PHRs. All access is unchangeably tracked in the blockchain, and if a patient detects unauthorized access by any physician, he or she can report this at a complaint office. In case of unauthorized use, the physician can lose his or her approval.

To accelerate the use of blockchain in healthcare, more research on design knowledge is necessary to validate the currently limited results. This motivates us to analyze the requirements for a blockchain-secured PHR, implement the solution in an operational prototype and subsequently to evaluate the prototype in a multi-methodological and iterative research approach.

Within the scope of our research we define a blockchain-secured PHR as a patient-centered platform that stores health-related data. The authorization and access management is unchangeably traced in a blockchain to avoid manipulation or misuse. In this approach the content is efficiently stored in an off-chain database while the access is secured by a blockchain (Esposito et al. 2018). In contrast to the Estonian model, healthcare professionals can only access the PHR with permission of the patient. However, once someone get access he or she can see the complete medical record. This avoids the above mentioned problem, that patients may hold back relevant information.

3 Research approach

In the course of eHealth evolvement, new interdisciplinary research fields such as health informatics were established to successfully implement technology in the healthcare sector. However, the systematic assessment of requirements, the construction of architectures and the development of prototypes remain the core competences of information systems research. In the information systems discipline, the development of research artifacts, such as our blockchain-secured PHR, is often conducted by following the design science research (DSR) paradigm proposed by Hevner et al. (2004). In addition to a rigorous use of methods and theories from the knowledge base, a constant exchange with the application domain ensures the relevance of the artifact. Holmström et al. (2009) point out in their contribution that in the DSR paradigm the knowledge base is expanded if either existing kernel theories are reviewed with existing IT artifacts or new artifacts are developed. Our contribution can be assigned to the latter. Through our approach we first develop a prototype and at the end of the article we draw conclusions about possible theoretical implications. Following the approach of Beck et al. (2016), we argue that currently available blockchain applications are still rare. Nevertheless, first applications demonstrate the potential of blockchain technology, e.g. it is possible to establish trust between transaction partners (in our example: doctor and patient) and to reduce transaction costs by a digital blockchain-based solution. To test such theories, however, functioning prototypes are required. Therefore, in this paper we present a prototype, built upon our derived design principles for blockchain-secured PHRs, which can be used by other researchers as well as practitioners.

For a structured implementation, Peffers et al. (2007) transferred the design guidelines into a six-phase iterative methodology, which was used as a framework for the design of our prototype. To identify the related work from science and practice and to elaborate the existing problems and solutions in the domain, a systematic literature review and a market analysis were carried out in the first iteration. We conducted the literature review according to Webster and Watson (2002) and vom Brocke et al. (2009). Given the implementation of the first blockchain-based application (Bitcoin in 2008), the period to be investigated was set at 2008 onwards (Nakamoto 2008). Within this period, we searched the EBSCOHOST, AISeL, Google Scholar, Sciencedirect and Springerlink databases with the following search string: (“personal health record” OR “electronic health record”) AND (“blockchain” OR “distributed ledger”). Since insights from EHR research may also affect PHR systems, we included EHR into our literature review. After filtering the contributions by abstract and title, and with subsequent evaluation of each paper’s relevance for our study and a forward/backward search, we included 52 papers in our analysis. The market analysis was carried out to identify and analyze existing applications in the field of blockchain-based EHRs and PHRs. For this purpose, we performed an open search with Google and the startup databases CrunchBaseFootnote 3 and Angellist.Footnote 4 During the entire development, the market was regularly screened for additional (new) applications.

With the results of the literature review and market analysis, three design thinking workshops were held (Plattner et al. 2009), each with seven participants from the fields of computer science, information systems and healthcare, and the initial issues and MRs for the blockchain-secured PHR were elaborated in these sessions. Derived from the MRs, a first draft of the DPs was defined. The DPs guided the development of a first prototype, by using SCRUM and prototyping (Dey et al. 2001). This prototype comprised the functional scope of the blockchain-secured PHR, consisting of a unified database with the associated blockchain, web services for interaction with this database and a web platform for the various stakeholders (doctors, patients, employees). During the first evaluation, we presented the system to the participants. Multiple scenarios (e.g. saving documents, data queries by the physician) were presented from the perspective of the individual stakeholders. The research approach including the individual steps is summarized in Fig. 1.

Fig. 1
figure 1

Research approach and structure of this contribution

Full size image

4 Derivation of design principles for blockchain-based access control to personal health records

Based on our literature review, we identified issues (Is) regarding the use of PHRs. The issues result in requirements, which were summarized in meta-requirements (MRs). In the next step the MRs were consolidated in initial design principles (DPs) for the development of a blockchain-secured PHR.

Digitalization and the use of information technology have fundamentally transformed the healthcare sector (Feldman et al. 2018). The dissemination of technology is accompanied by a variety of different systems (I1) (Dugas et al. 2016). Healthcare systems are especially characterized by a great heterogeneity of information systems for different stakeholder groups such as hospitals, doctor’s offices, pharmacies, insurances, laboratories, therapists and care services. To ensure data compatibility, a PHR must be able to be integrated into the existing information systems (MR1), and the integration should consider the high heterogeneity of the data (I2) (Oemig and Blobel 2014). Particularly data must be structured and harmonized within the PHR (MR2) (Veseli et al. 2012). Therefore, the requirement for the internal structuring and standardization of data as well as the integration of a PHR into existing systems results in the following DP:

DP1:

Provide the PHR with a unified data structure, which delivers the data via interfaces to all involved systems. Therefore, the PHR integrates easily into an existing digital health ecosystem.

With a unified data structure, it is possible to share the data almost error-free with different systems. However, the risk exists that the data may be manipulated (I3) from the outside, primarily because of unauthorized access to the data (I4) (Nohl-Deryk et al. 2018; Gillum et al. 2019). As a result, a PHR relies on a secure and reliable infrastructure (MR3) that is supported by clearly defined authorization and authentication mechanisms (MR4) and a detailed and adaptable role concept (MR5). In the case of data manipulation, there is often no access tracking and modification history (I5), which is why the PHR must have traceability mechanisms (MR6).

DP2:

Implement the PHR on a safe and reliable infrastructure with traceability mechanisms. This ensures that sensitive data cannot be accessed without permission and that misuse can be traced back.

Current health record systems are mostly exclusive to the healthcare professionals. In addition, PHRs are in an early stage of development, and the adoption is consequently not yet far advanced. As a result, few PHRs are available to citizens (I6), and the reception of patient health data remains delayed (I7). Furthermore, because of the lack of user experience with a PHR, it must be designed in a user-centered way to achieve high acceptance (MR7) (Tavares and Oliveira 2016). MR7 is also supported by the fact that the existing PHRs do not provide sufficient opportunities for users to control rights over stored documents for healthcare stakeholders such as doctors and pharmacists (I8) (Seitz and Wickramasinghe 2017). One of the reasons for the insufficient assignment of access rights is that users find it difficult to use PHRs (I9). From I8 and I9, it follows for MR8 that the interface should be information-focused so that users know to whom they are granting rights to their health data.

DP3:

Provide the PHR with an easy-to-use and information-focused interface with comprehensive authorization mechanisms. Users can then deliberately determine who has access to their personal health information.

Figure 2 summarizes the connections between issues, meta-requirements and initial design principles.

Fig. 2
figure 2

Issues, meta-requirements and initial design principles for blockchain-secured PHRs

Full size image

5 Blockchain-based access control to personal health records

5.1 Use case

Section 2 discussed the current use of PHRs in healthcare and the use of blockchain technology to improve the traceability of access to PHRs. Since the development of a PHR for the entire healthcare system is too extensive in the first place, the development of our prototype will initially focus on the communication between the treating doctors, their associated employees and the patients.

For this purpose, our PHR OSHealthRec manages patients’ documents. To do so, both the patient and the attending physician need a personal account. The patient provides access to his or her personal health information by scanning his or her attending physician’s individualized QR code. This ensures that both the physician and the patient agree to the authorization. The physician and his or her employees can then upload treatment reports and other files to the patient’s account, and the patient is able to continuously track his or her treatment record. To ensure the security of the therapy, the patient can only read the documents but cannot change them or upload his or her own files. All process regarding access management are carried out via blockchain. The documents are stored outside the blockchain, as it would otherwise become too large and inefficient. When accessing and storing files, the blockchain provides the user with the access information (Esposito et al. 2018).

5.2 Data structure and system architecture

At the beginning of the development in December 2018, the choice for a blockchain was limited to a few providers, including Hyperledger, R3Corda and Ethereum, and that choice was made based on the following criteria: functional extent, support, cost and interfaces. We finally chose Hyperledger Fabric and Hyperledger Composer, which are part of the Hyperledger Project founded by the Linux Foundation and is intended to develop enterprise applications based on a private blockchain. It is based on a modular system that offers different components, such as services for membership or ordering (Sousa et al. 2018). With Hyperledger Composer a business network consisting of participants, assets, access controls and transactions can be formed. Participants and assets are defined with their attributes in a model file. Based on the model file, the transactions between participants and assets in the business network are described using JavaScript. The access controls are used to define the access rights of participants to assets, transactions and other participants. These components are then used to create the business network archive, which can be published on an existing Hyperledger Fabric instance.Footnote 5

Hyperledger Composer does not offer sufficient possibilities to save documents (e.g. medical reports). Therefore, the Hyperledger Fabric application must be supported by a separate off-chain storage. For this purpose, a system extension was created to manage the documents. The blockchain application is used to manage the path to the file, with which the corresponding document can be retrieved from the system. To enable the user to easily interact with the PHR, a web application was developed that can call up the functions of the application via REST services. Through implementation of a responsive web application, it is possible for every browser-enabled device to retrieve the data and to visualize the information in an attractive way. An external identity provider (e.g. GitHub or Google) handles the authentication for the web application as well as the Hyperledger application. The described architecture is illustrated in Fig. 3. General information about the participants and the assets is communicated and maintained directly with the Hyperledger Fabric application, and each report is stored as a document. Therefore, every user can store and access the reports, so that the prototype addresses DP1. To store and retrieve documents, the corresponding transaction is first initiated in the Hyperledger Fabric application and checked for authorization. Afterwards, the access path via which the document is requested from the document server is shared. This process is represented by the red circled numbers in Fig. 3. First, the user sends a request to the web application (1) which queries the Hyperledger API (2); then, the Hyperledger Fabric application checks the eligibility of the transaction and executes the transaction with the necessary permission (3). Thereafter, the API answers the request with the respective access path (4), and with this information, the web application which is authenticated for access to the document server retrieves the data from the document server (5, 6). Finally, the web application makes the documents available to user via a link with an access token so that they can view the document (7).

Fig. 3
figure 3

System architecture for OSHealthRec

Full size image

To create the model file that describes the participants and assets, the first step was to identify the actors in the use case and to represent them using a UML class diagram (Fig. 4a). In total, three classes of actors are involved in the use case: patients, doctors and employees. Accordingly, there is the abstract class Person, which defines the key attributes of a person, such as birthday and name. For Patients, this class is used to record treatment-related data as well as the verified doctors and uploaded reports. In addition, patients can add or delete the access permission to doctors and their employees. For Doctors, information about the medical practice and the medical specialty is recorded. In addition, the system records which employees work for the doctor, who retrieves which data and which patients are treated by which doctor.

Fig. 4
figure 4

UML class diagram and model file

Full size image

The doctors can provide reports for the patients and add or delete staff and patients. For example, one employee can work in a shared office for multiple doctors. We considered this by adding an employee attribute that indicates the doctor for whom he or she works, and employees can add reports to patients on behalf of the doctors as well as add or delete doctors. The reports that can be added by doctors or employees have an ID, creation date, title, description and details for and by whom the report has been uploaded. The ref_location additionally specifies the path to the report in the document system, since the report should not be saved in the blockchain. Storing the reports directly in the blockchain increases its size significantly. Moreover old versions of the documents would remain immutable in the blockchain even if changes are made (Finck 2018). This would violate privacy regulations such as GDPR. For example, the transfer of the Person, Patient and Doctor classes, described in the UML class diagram, into the format of the participants is illustrated in the model file in Fig. 4b.

The functions defined in the UML class diagram are defined as transactions in Hyperledger Composer via the script file. Figure 5a depicts the function add_report_for_patient. The required parameters are passed to the function. The first step checks whether the report has already been made available to the patient. The report for the patient is then added, and the patient is updated in the application. Since the function add_report_for_patient may only be executed by doctors and employees, the rules must be defined in the access control. Figure 5b displays the rules for the doctor. For this purpose, the rule DoctorAddReportForParticipantTransaction specifies that all participants of the type Doctor have permission to create the transaction add_report_for_patient. Within the rule DoctorAddReportForPatient, the doctor is then allowed to make a change using the transaction within the participant of the type Patient, if the doctor has been defined as the treating doctor.

Fig. 5
figure 5

Script file and access controls

Full size image

The described architecture and implementation of the Hyperledger Fabric application ensures that the healthcare actors and patients communicate the reports securely. Every access and retrieval is stored within the application by the blockchain, and it is possible to trace and, if necessary, retrace every interaction. In this way, we addressed DP2 in our prototype.

5.3 Application interface design

For secure use of the PHR, it is essential that users know how to correctly use the system (Tavares and Oliveira 2016). The screenshots in Fig. 6 illustrate how the interface was designed considering DP3. The aim was for users to be able to easily interact with the system and be confident in administrating access rights. This ensures that users always know who is allowed to provide reports and who has access to the information therein.

Fig. 6
figure 6

User interfaces of the prototype. a Patient document view, b patient approval view and c doctor’s QR code generation view

Full size image

Since the individual groups of actors require different functions, the web interface provides a separate view for each group. The access works via a common login page. During the login process, the system checks the group to which the user belongs; then, the user receives the respective view of his or her group. For each view, the user’s personal information is displayed first. The different views are described next. Figure 6a, b depict the views of the patients. In addition to the profile, there are menu items titled Documents and Approvals. Under the menu item Documents, illustrated in Fig. 6a, all reports of the patient are listed in tabular form. The ID, the title, a short description, the creation date and the responsible physician are displayed. Via a button, the corresponding document can be downloaded, and using a search function, patients can filter the documents in the individual categories according to search criteria.

The Approvals tab, presented in Fig. 6b, lists all physicians to whom the patient has already granted access to his or her data. The title, name, address and specialization of the respective doctors are displayed here. Furthermore, the permitted authorization to the individual doctors can be revoked, and the user has the option to grant further doctors permission to access their data under this tab. Patients have two options for this. First, with the manual search, all physicians in the system are listed, and using a search function, users can search for the corresponding physician and grant him or her access to their accounts. Second, by means of the share scan, a doctor’s QR code can be scanned via the camera of the device; this automatically gives the doctor access to the patient.

The doctor’s view includes the following four tabs: Profile, Staff, Patients and Generate QR Code. Under Staff, all employees of the doctor are listed with name and date of birth. In addition, further employees can be added, or existing employees can have their authorization withdrawn.

The patient’s tab lists all patients who granted the doctor permission to access their reports, together with their key information. By choosing a patient, the physician can access the overview of the respective patient with information about the person and all reports. In addition, the doctor can create new reports for this patient. The Generate QR Code tab, depicted in Fig. 6c, displays a QR code with the associated doctor’s ID. This QR code can be printed out to subsequently pass on to new patients for easier approval.

6 Evaluation

Within the design process, four major evaluation cycles were carried out. All evaluations were conducted according to the design cycles as described in Sect. 3. The continuous evaluation essentially serves to ensure continuous improvement and to eliminate identified weaknesses as quickly as possible. The formative evaluation of the prototype was divided into four cycles with different focuses and respective methods according to Table 1 (Venable et al. 2016).

Table 1 Overview of evaluation cycles
Full size table

In the first evaluation cycle, focus groups were asked to perform certain tasks with the PHR. These tasks were embedded in scenarios; for example, incorrectly entered X-ray images were to be replaced by new (correct) ones. The scenarios aimed at testing all functionalities of the application from the perspectives of all involved stakeholders (patients, doctors and employees). The participants in the focus groups were experts from the IT and healthcare sectors. The subsequent group discussions followed few and open guidelines, and they were recorded, transcribed and analyzed. In general, a focus group has the advantage of making it more difficult for participants to provide a desired answer. Instead, they must debate with one another and try to explain their own impressions, opinions, feelings and ideas and eventually convince other participants (Lune and Berg 2017). With the overview of the system, the participants evaluated the prototype in the first iteration regarding its utility. This ensured that the prototype did not lack any important functionalities for the use case. Therefore, three focus groups, each with four participants, were conducted. Each focus group attempted to gather experts from different fields to evaluate the solution from different perspectives. The results of the evaluation were used to expand the system in the second iteration. First, the MRs and DPs were revised, and the prototype was further developed analogous to the procedure of the first iteration. With the adapted range of functions, the prototype was evaluated in the second iteration with regard to usability. Eight expert interviews with future patients were conducted to ensure that the solution meets users’ requirements. Through the interviews, further necessary adjustments to the solution were identified, and they were implemented in the third iteration after adaptation of the MRs and DPs. This iteration was concluded with an evaluation of the implementation of the DP in a focus group with eight participants. The evaluation revealed that the DPs were sufficiently considered in the solution. Finally, the system was evaluated through a survey with regard to its acceptance by future patients. Based on the positive evaluation of the prototype, no further adjustments regarding the DPs and the prototype were identified.

  • I. Evaluation cycle: utility

In the first evaluation cycle, some features of our prototype were positively highlighted. These included the possibility to access all information and data at any time without additional effort (e.g. searching for the treating physicians) and the associated traceability of the history as a useful benefit. This highlights the advantages of providing all information to healthcare professionals by default. Only if a patient actively wants to constraint information, e.g. in order to receive a second independent and unbiased opinion, he or she should be given the opportunity to block a report or diagnosis.

More information, such as the specialization of the physician or the position of an employee in the organization, was desired by the participants. Furthermore, the name of the doctor’s office or hospital, along with information about the last visit to the doctor and current complaints, is missing in the patient's profile. According to the participants, it would also be helpful to include the physicians who are no longer approved, in order to trace the history of the treatment even better. We recommend future PHR provider to enrich every uploaded entry with detailed meta data, e.g. the author’s contact data. In addition, the participants wished for a more thorough sorting of the information or data in the file. A practical recommendation was the subdivision of the documents into, for example, reports and images. However, other participants perceived the structure of the document list as convenient. Moreover, the recognized document standards in the medical field must be considered. Overall, the loading time was evaluated as critical for the future use of such a PHR. Within the scope of further development, it was possible to address the technical challenges in particular (improvement of loading times, subdivision into various document types) as well as the finer division of information (e.g. appointment or treatment history).

  • II. Evaluation cycle: usability

Similar to the first evaluation cycle, the insufficiently detailed information provided by the actors in the prototype was again critically discussed. More information, such as the profession of the doctor or the position of employees in the organization, was desired. Furthermore, the interviews revealed that the use of the QR code is not intuitive—finding the scan function and saving the code in particular caused problems for the participants. Moreover, given the missing specialization of healthcare professionals, the participants criticized the process of searching for a doctor for being confusing. Then, with regard to the loading time, which was negatively noted in the first cycle, it was improved adequately, such that it was no longer mentioned as a critical issue. The feedback regarding the performance confirmed that off-chain storage of health data and blockchain-secured access management provides the best combination of security and efficiency. In addition, the interviewees valued the clearly arranged user interface and its intuitive use. As a result of the responsive web design of the application, mobile use was also positively evaluated. For further improvement, it was stated that additional icons should be added to the existing text elements to make the user experience even more appealing and intuitive. We recommend PHR providers to ensure an intuitive use by presenting the features with distinctive icons.

During the interviews, possible functional enhancements were discussed. Some ideas for future extensions, such as a QR code on the medical card or geographically related searches, were mentioned. However, these were not taken into account, since we developed a prototype in the first place to demonstrate the feasibility of blockchain technology for PHRs. Future implementations of PHRs should consider these recommendations.

  • III. Evaluation cycle: design principles

Throughout the first two evaluation cycles, the initial design principles were refined. In order to ensure that the DPs are precisely formulated and that the prototype reflects them, the focus group critically reviewed both. Questions and concerns about the rights of the actors (e.g. in the release process) were discussed in depth. With the help of the rules in Hyperledger Composer, an authorization and authentication procedure was subsequently implemented. Thus, during the login process, the role and rights of the user are checked. This prevents insufficient data sovereignty and enables an adaptable and detailed role concept, and errors or deliberate manipulations by unauthorized users are prevented. Moreover, the rules of the prototype guarantee the assignment of information to the correct target person. Furthermore, the arrangement of design elements was discussed, and their use on mobile devices in particular was positively emphasized.

In addition, the DPs were formulated according to Gregor et al. (2020) to take into account important components such as aim, implementer, context, mechanism and rationale and to transfer them into a structure that enables researchers as well as practitioners to incorporate them into their own work. After the revision, the workshop concluded that the DPs were successfully applied in the prototype, so that the prototype can be evaluated for user acceptance. The final DPs are presented in Table 2.

Table 2 Design principles for blockchain-secured PHRs
Full size table

  • IV. Evaluation cycle: user acceptance

A survey was conducted during the last evaluation cycle. The technology-acceptance model (TAM) (Davis 1986) served as the theoretical basis—perceived ease of use (PEOU), perceived usefulness (PU) and intention to use (ITU)—which was supplemented by three further constructs, namely, privacy (PR), security (SE) and control (CO) (Davis 1986, 1989). Both the constructs and the underlying items were systematically derived from the literature (see “Appendix”). The decision to extend the TAM with the privacy, security and control constructs was based, on the one hand, on the fundamental considerations of improving security (and privacy) through blockchain technology and, on the other hand, on the feedback from the previous evaluation cycles, to afford the user full control over the system and his or her own data (control).

Prior to the survey, the respondents received an introductory text describing the current challenges and opportunities of digital patient records. They were also provided with a link to the blockchain-secured PHR developed by us, and they were asked to test it in detail from the perspectives of a patient, a doctor and an employee. In this evaluation cycle we have allowed and encouraged the participants to take the perspectives of both patients and healthcare professionals. This gives the participants an impression which data the employees can access.

The survey was answered from the perspective of a patient, since (almost) everybody can understand the requirements of a PHR as a patient. Furthermore, the views of healthcare professionals were already taken into account in the first cycles. A total of 92 respondents were recruited for the survey. To achieve the highest possible data quality, 28 data sets were excluded for various reasons (e.g. incomplete questionnaires), resulting in 64 data sets being included in the analysis. In general, the number of participants here is relatively low; however, since the survey represents only a part of the evaluation, the number of participants is sufficient and provides initial findings for the acceptance of blockchain-secured PHRs. Of the 64 participants, 42 (65.6%) were male and 22 (34.4%) were female. The age of the participants was between 18 and 49 years (average age: approximately 25.56 years).

Prior to the evaluation, we conducted various analysesFootnote 6 to ensure the validity and reliability of the collected data. Therefore, various quality measures were calculated and interpreted based on Weiber and Mühlhaus (2014). In a first step, Cronbach's alpha (CA) was calculated (see Table 3). Cronbach's Alpha measures the internal consistency of a scale and can range from − 1 to 1 (Cronbach 1947; Cronbach and Meehl 1955). The closer Cronbach's alpha approaches 1, the better a set of items explains a single unidimensional latent construct (Peter 1979; Nunnally and Bernstein 1994). For all constructs, the threshold value of 0.7 was exceeded and can therefore be considered as reliable (Weiber and Mühlhaus 2014). Furthermore, the corrected inter-scale correlation (CISC) and the inter-item correlation (IIC) were examined to check the constructs for internal consistency. IIC is another measure to evaluate reliability at the overall construct level. It represents the average correlation of all items assigned to a construct an can range from − 1 to 1 (Revelle 1979; Weiber and Mühlhaus 2014). The corrected inter-scale correlation can also range from − 1 to 1 and indicates how strongly an item correlates with the other items of a construct. Thereby it can be measured how distinctly the items differ from each other (Nunnally and Bernstein 1994; Weiber and Mühlhaus 2014). Again, the respective threshold values (CISC ≥ 0.5 and IIC ≥ 0.3) were met (Weiber and Mühlhaus 2014) Therefore, the internal consistency of the constructs can be evaluated as fulfilled. Composite reliability (CR) and average variances extracted (AVE) were also used as additional quality measures. The required thresholds were also exceeded for these indicators (CR ≥ 0.6 and AVE ≥ 0.5) (Fornell and Larcker 1981; Bagozzi and Yi 1988); therefore, the reliability of the measurement is assumed. Furthermore, we used the Fornell–Larcker criterion to measure the validity of discriminants. This requires that a latent construct average shares a higher variance with the respective indicators (items) than with the other constructs of the model under investigation (Fornell and Larcker 1981).Footnote 7 Overall the results show that our items and constructs are reliable and well-functioning and that further evaluation can be started (Fig. 7).

Table 3 Reliability and validity
Full size table
Fig. 7
figure 7

PLS-SEM model

Full size image

After testing the reliability and validity, we investigated the relationship of the dependent variables. This was carried out using partial least squares structural equation modeling (PLS-SEM) (Hair et al. 2012, 2014). The analysis of the model confirms strong statistical correlations between CO and PEOU as well as between SE and PU and between PU and ITU. In addition, a (statistically) weaker correlation between PEOU and ITU was identified. The relatively low path correlation and the statistically insignificant correlation between PR and PU are also noteworthy. When interpreting the PLS-SEM model, interesting correlations can be identified. For example, the influence of SE (compared to PR) on PU is significantly higher. The participants consequently see the benefit more in in the high security of a blockchain-secured PHR and less in better privacy. This is also understandable in terms of argumentation, since the data are still stored online, as one user pointed out in the survey. Nevertheless, the detailed access management and tracking offers advantages for users. Furthermore, it must be noted that although the prototype we developed offers suitable usability (see PU and the PU–ITU relationship), PU has a significantly greater influence on ITU than PEOU. This is understandable in terms of argumentation for two main reasons. First, the application developed is still a prototype that can be improved. Second, it makes sense that with a PHR perceived usefulness is in the foreground. For example, one user noted that function and security are priorities for him, while “the design is rather secondary.” Furthermore, the average ratings for all constructs also indicate clearly positive evaluations (on average approximately 1.45 on a scale of − 3/3). When analyzing the average values, it can also be seen that the PU of the blockchain-secured EHR in particular was positively highlighted. Furthermore, the participants were asked to use free text fields to point out the strengths and improvement potential of the prototype. In particular, an improvement in accessibility (e.g. for people with visual impairments) and an emergency data set were suggested.

After each evaluation cycle, we gathered potential improvements from the received feedback; a summary is presented in Table 4. The next step of the evaluation should be in a field test. However, some adjustments are still required to perform this. To reach as many users as possible, additional interfaces to existing systems (e.g. hospital information systems) should be provided. This would enable the different actors in the health sector, in the long term, to achieve high or rapid adoption. In this context, analysis possibilities of the available data in terms of data analytics should also be discussed. For example, users could voluntarily and anonymously provide their data to the community (e.g. to research institutions) or offer them in the private (health) sector. Especially in this context, user attitudes regarding acceptance and privacy must be continuously recorded and analyzed, as our survey did not cover everyday use.

Table 4 Feedback from evaluation cycles
Full size table

7 Discussion and implications

So far, the promising benefits of PHRs have usually been outweighed by data security and privacy concerns (Hoerbst et al. 2010; Adelmeyer et al. 2019). Blockchain technology has recently been discussed in the literature as an instrument to overcome this barrier (Beinke et al. 2019). In contrast to existing prototypes such as MedRec, OmniPHR or FHIRChain, we systematically identified issues, derived MRs and consolidated them into three DPs. Our findings contribute to the design knowledge base and might be transferred to further technological solutions in healthcare or other industries. The key findings for each DP are summarized in Table 5.

Table 5 Key findings for the identified design principles
Full size table

The suggested improvements were implemented in our blockchain-secured PHR. It can be customized to individual demands and serves as a secure, document-based platform (e.g. cloud repository) to exchange health-related information between patients and healthcare professionals. However, the developed solution is still a prototype intended to demonstrate access management for personal health records via blockchain and evaluating users’ trust in such a solution. Therefore, challenges regarding to GDPR might occur. So far, some personal data (e.g. name, birthday) is stored in the blockchain. The personal data would have to be stored encrypted in an off-chain database. In this context, it has to be noted that the encryption key is stored in the blockchain and could therefore be accessed by the peer operators. In a productive solution, this could be solved by using a key management server that can be requested by the user.

7.1 Implications for practice

The implications for practice primarily affect patients and healthcare professionals. Patients mainly benefit from OSHealthRec because of the warranty of the data security. The blockchain supports that only authorized persons may access their health data. Compared to the status quo, in which the healthcare system is often a black box for patients, the transparency and traceability of OSHealthRec constitutes a major improvement. Patients are empowered to self-manage and self-determine their data, and they can easily track the course of treatment. This reduces mistakes and unnecessary double treatments. In order to avoid the problem that patients hold back important information because they feel ashamed or they cannot assess the relevance, a healthcare professional can see all health information about a patient by default once he is authorized to access the data. However, if a patient wants an unbiased second opinion about a diagnosis he or she should be able to block specific files or information for a specific healthcare professional. This additional function could be implemented in a further development of our prototype. In cases of fraud or medical mistakes, every step is unchangeably tracked in the blockchain. Another benefit is the independence of central governmental organizations, as we recommend the formation of a consortium to operate the private blockchain. This consortium could, for example, be made up of associations of physicians, pharmacies and health insurance companies.

However, the self-administration of a PHR requires the motivation and effort of patients to learn the correct use and to continuously manage their personal account. Many patients, especially elderly people, might be deterred because they fear doing something wrong. Therefore, healthcare providers must encourage patients to use the PHR. Another potential problem is that trust in the blockchain technology requires an understanding of how it works. Therefore, given its novelty and complexity, healthcare professionals must explain and promote the technology to their patients.

Similar to the patients, the implementation of a blockchain-secured PHR would have implications for healthcare professionals as it affects their everyday work. First, a blockchain-secured PHR would increase cooperation with other healthcare providers. This requires clear communication and standardized files. The transfer of patient data and respective documents would also be easy without sending a fax or e-mail, which requires the correct address of the recipient. Second, improving the efficiency of administrative tasks allows doctors to spend more time with their patients. In addition, the tracking of every transaction makes it possible to reproduce treatment history and to detect mistakes or misuse. At the same time, this transparency reduces liability risks in case of unauthorized access. Furthermore, from the medical research perspective, healthcare professionals may use anonymized data from PHRs to investigate new diseases and therapies.

7.2 Implications for research

Apart from the implications for patients and healthcare professionals, determining the operator or operators of a blockchain remains necessary so that a blockchain-secured PHR can be implemented. It is essential that users trust the operators, since they are the only ones who can influence the transactions (Beck et al. 2018). Therefore, the question arises as to which actors (e.g. government, health insurance companies) are explicitly involved in the operation of the blockchain-secured EHR. Our proposal is that the operation should be run by a consortium of all relevant stakeholders (government, health insurance companies, associations, doctors etc.). The research task here is to weigh up competing interests and make a decision that puts the well-being of the patient first.

As development in the field of blockchain technology is rapidly advancing, it should be mentioned that the used Hyperledger Composer was deprecated in August 2019 and is therefore no longer being actively developed. It has been replaced by Hyperledger Fabric v1.4, which offers improvements in the programming model and further enhancements. In the meantime, Hyperledger Fabric has reached version 2.1, which shows the fast development of the technology. We are currently working on transferring our prototype to the current Hyperledger version to ensure permanent access to it. The functional enhancements of Hyperledger Fabric already provide better performance. Furthermore, since the main intention of our prototype is to generate design knowledge and determine its acceptance by users in the healthcare system, many options exist for further development. For example, the security of the solution can be improved, while the documents are available only encrypted on the document server and the key is stored in the document asset in the blockchain, thereby ensuring that only authorized users can decrypt the document. In addition, the application should be opened for further interest groups and, if necessary, made available to other institutions such as health insurance companies. In this way, the application would support even more use cases and experience broader acceptance. Finally, by preparing and integrating medical reports, the findings can be structured more clearly, and better correlations between the reports can be identified.

Overall, we conclude that blockchain technology constitutes a suitable solution for privacy concerns with regard to health-related data. A document-based online system requires no investments in hardware or software, and it can easily be accessed from any device with a web browser. Our findings make a contribution to the discipline of information systems. By applying DSR for the development of the PHR, design knowledge is generated and evaluated. It enhances the existing knowledge base and can be used by other researchers. According to Gregor and Hevner (2013) the developed artifact and corresponding DPs of type “Level 2: Nascent Design Theory” and mainly contribute to the prescriptive knowledge that describes how artifacts are designed. With the results of the final evaluation, we also contribute to descriptive knowledge by analyzing the effects of the implementation of the system.

8 Conclusion

While the advantages of PHRs are indisputable, their adoption is still hampered by data security and privacy concerns. Blockchain technology constitutes a promising solution to increase the trust in and safety of PHRs. Within a 1-year DSR project, we developed a blockchain-secured PHR. First, we identified nine domain-specific issues that were necessary to consider within the development phase. In the next step, we derived eight MRs that were consolidated in three DPs for blockchain-secured PHRs. After developing a prototype on the basis of Hyperledger Fabric, we conducted four evaluation cycles and continuously incorporated the feedback into the system. Our evaluation cycles do not represent a sufficient sample size for an international rollout. Quantitative field studies are required to investigate trust in and acceptance of blockchain technology within health-related use cases. Given the novelty and complexity, many patients are reluctant to trust an unknown security mechanism. However, we conclude that blockchain technology offers promising potential to substantially improve healthcare. In future investigations the cooperation between the various stakeholder groups, such as pharmacies, hospitals, laboratories, and care services on a blockchain-secured system should be addressed.