key: cord-0488188-u9g2dk9t
authors: Schlatt, Vincent; Sedlmeir, Johannes; Traue, Janina; Volter, Fabiane
title: A Decentralized Electronic Prescription Management System
date: 2021-09-12
journal: nan
DOI: nan
sha: 46b8e7010050e54476a571912f8a507d2852e75f
doc_id: 488188
cord_uid: u9g2dk9t

The ongoing digital transformation of the medical sector requires solutions that are convenient and efficient for all stakeholders while protecting patients' sensitive data. One example involving both patients and health professionals that has already attracted design-oriented research are medical prescriptions. However, current implementations of electronic prescriptions typically create centralized data silos, leaving user data vulnerable to cybersecurity incidents and impeding interoperability. Research has also proposed decentralized solutions based on blockchain technology as an alternative, but privacy-related challenges have either been ignored or shifted to complex or yet non-standardized solutions so far. This paper presents a design and implementation of a system for the exchange of electronic prescriptions based on the combination of two blockchains and a digital wallet app. Our solution combines the bilateral, verifiable, and privacy-focused exchange of information between doctors, patients, and pharmacies based on a verifiable credential with a token-based, anonymized double-spending check. Our qualitative and quantitative evaluations suggest that this architecture can improve existing approaches to electronic prescription management by offering patients control over their data by design, a sufficient level of performance and scalability, and interoperability with emerging digital identity management solutions for users, businesses, and institutions.

The ongoing digital transformation of the healthcare sector affects its stakeholders in various ways. Healthcare providers, public institutions, and patients alike face a constant pressure to develop and use digital tools in the healthcare sector. As recent developments caused by the Covid-19 pandemic indicate, this pressure is often exacerbated by the need to balance privacy requirements and adequate digital healthcare provisioning [1] . However, this apparent dichotomy appeared before the pandemic, too, for example in the context of digital health records or electronic medical prescriptions [2, 3] . Medical prescriptions refer to authorizations issued by qualified healthcare practitioners that allow patients to obtain medication and services for medical treatment. These authorizations typically manifest as physical, paper-based documents signed by a qualified physician, which patients present to pharmacies or health service providers. However, such paper-based medical prescriptions suffer from various drawbacks. For example, due to their format, they proved to be susceptible to manipulation, unauthorized reproduction, and errors [4] . Paper-based prescriptions also delay the widespread adoption of telemedicine. In addition, they are rarely used for processes that might benefit from the exchange of verifiable and machine-readable prescription data, such as claiming reimbursement from health insurances or checking for cross-reactions of pharmaceuticals [5] . Furthermore, the respective documents are inconvenient to use and susceptible to the disclosure of private information if not handled adequately.

In the hope of obliterating the flaws of a paper-based approach, several attempts to introduce medical prescriptions in an electronic format have emerged in recent years. Electronic medical prescriptions are usually implemented as digital references or documents, whose validity status and sometimes content are stored in databases run by parties that are regarded as trustworthy to prevent fraud [5] . As such, existing approaches to electronic prescriptions (e-prescriptions) are typically reliant on highly centralized infrastructures and data silos. Consequently, they serve as attractive targets for attackers aiming to capture sensitive health information on a large scale [6] , as recent examples indicate [7] . They also pose the socio-economic threat of creating monopolies or oligopolies of the corresponding platform owners [8] . Providers of the centralized infrastructures might further gain insights into patient data, resulting in privacy concerns for patients [5] . Also, centralized implementations of e-prescriptions are often not interoperable as they create lock-in effects. Consequently, patients, healthcare practitioners, or pharmacies need to purchase proprietary and expensive software [9] .

To eliminate these drawbacks of centralized approaches, researchers recently proposed alternative solutions based on decentralized infrastructures. These approaches rely on distributed data storage and aim to provide higher security, privacy, and interoperability than centralized approaches [10] while at the same time delivering a comparable level of convenience to users. As such, decentralized approaches solve several issues of both paper-based and centralized electronic approaches to medical prescriptions. Extant literature often builds on blockchain technology to serve as the underlying infrastructure for decentralized approaches to e-prescriptions. A major advantage of using blockchain technology for e-prescriptions is its function as a synchronized single source of truth, allowing the avoidance of, e.g., manipulating or double-spending (i.e., redeeming more than once) e-prescriptions [11] .

Nevertheless, several issues remain, and new problems emerge in current implementations based on blockchains. In particular, privacy concerns arising from the transparency of patient data may be exacerbated due to redundant data storage as well as the immutability of blockchains that renders later deletion practically impossible [10, 12] . This affects not only patients' privacy and data security interests but also compliance with associated regulatory requirements, such as the EU general data protection regulation (GDPR), the California consumer privacy act (CCPA) or the U.S. health insurance portability and accountability act (HIPAA). Furthermore, interoperability often remains a problem, as the suggested implementations are not built upon common standards, and sensitive data is regularly not shared bilaterally but involves decentralized yet third-party infrastructures. Besides, the existing suggestions often impose the management of cryptographic keys directly to the users or rely on yet another smartphone app (or device) that users need to use specifically for e-prescriptions.

In recent years, an alternative approach for exchanging verifiable data in a decentralized way emerged through portable identities managed in so-called "digital wallets". This paradigm is often termed self-sovereign identity (SSI) [13] . SSI offers standards and protocols for end-to-end encrypted bilateral communication and practices for selective and verifiable information disclosure based on digital certificates [14, 15] . However, preventing the double-using of e-prescriptions that are purely based on digital certificates is not possible solely by bilateral communications, as one pharmacy cannot know whether an e-prescription certificate has already been redeemed at another pharmacy. We hence propose that the combination of blockchain technology for double-spend prevention and SSI for the verifiable exchange of sensitive e-prescription data and key management potentially offers properties solving the shortcomings of current solutions to e-prescription management. Thus, we pose the following research question:

How to design and implement a decentralized system for e-prescription management using blockchain technology and digital wallets?

To answer this research question, we collect requirements of e-prescription management systems in a literature review and develop an architecture that aims to address them. To evaluate our architecture's practicability and implications, we subsequently implement and evaluate the design as a technical artifact. Thus, we propose an alternative solution to the problems of present designs of e-prescription management systems and evaluate its technical implementation. In this course, we contribute an extensive discussion regarding the role of blockchain technology in decentralized architectures that involve the sharing of sensitive data and the impact of regulatory requirements on the design. Our contribution to practice is a referential architecture for designing an e-prescription system and an assessment of its current technical feasibility.

The remainder of this study is structured as follows. In section 2, we present and discuss the concepts of e-prescriptions, blockchain technology, SSI and digital wallets. We then review related work on decentralized e-prescription systems and derive requirements for our prototype in section 3. Section 4 provides an overview of our architecture, while the following section 5 presents our technical implementation and evaluation. Subsequently, we discuss the resulting implications and conclude the paper in section 7 by providing a summary, limitations of our work, and avenues for future research.

In the UK alone, nearly 1.5 million medical prescriptions are processed on a daily basis [5] . Similarly, 11.6 prescriptions were filled in US-pharmacies per capita in the year 2019 [16] . The value of prescription pharmaceuticals prescribed globally every year accounts for approximately $1 trillion [17] . To account for limitations of existing approaches to handling the increasing number and value of medical prescriptions, researchers and practitioners alike aim to optimize the process of prescribing and dispensing pharmaceuticals. Accordingly, e-prescription systems have been introduced, which can help to increase both the accuracy and the efficiency of medication to ensure patients' safety while streamlining processes [5, 18, 19] . Submitting and exchanging prescription information digitally is considered to reduce medication errors, minimize overhead due to paperwork, and increase patients' convenience [5, 18] . Accordingly, e-prescription management systems enable the creation of prescriptions and their transmission to a pharmacy purely digitally. As such, e-prescriptions serve as a medium for medical data exchange and corresponding systems allow to redeem prescriptions electronically.

However, e-prescription systems come with several challenges. While paper-based prescriptions can be physically invalidated upon redemption, e-prescriptions must have a sophisticated mechanism for preventing doublespending [20] , as copying electronic documents has close to zero marginal costs. This requires some degree of transparency about whether an e-prescription has been already used, particularly when the ecosystems involves several different stakeholders and in particular many independent pharmacies and doctors. These transparency requirements, however, are to be balanced with data security and privacy. As health data is of high sensitivity, it requires special protection according to the GDPR within the European Union (EU). This includes aspects like the right to erasure ("Right to be forgotten"), meaning that users can request their data to be deleted at any point in time (Article 17 GDPR) [21] . Besides, the data specified in a prescription must also be secure from alteration by unauthorized parties. A further challenge for e-prescription systems is posed by the need for standardization. Moreover, transmitting, receiving and processing data between many stakeholders requires the systems to be interoperable [20] ; and achieving this in an established system likely requires strong network effects or regulatory obligation.

Countries such as the United States, Australia, the United Kingdom, Spain and Denmark have already introduced e-prescription systems that are now in productive operation [5, 9] . The respective systems are usually not standalone products but embedded in more comprehensive e-health systems including, e. g., electronic health records of patients. A comparative study conducted by Aldughayfiq and Sampalli [5] found that most implementations build on centralized designs employing a central database for storing prescriptions. A centralized design choice, in which the associated platform is involved in basically any transaction related to the e-prescription, can effectively enforce interoperability and the compliance with business logic (such as double-spend prevention) and provide fine-grained access management rules. However, it also bears considerable risks. First, a centralized approach represents a single point of failure, meaning that the system is more vulnerable to attacks [8] , as past privacy breaches in centralized systems illustrate [22] . Second, patients cannot be sure that the operator of a centralized system or database does not sell or distribute sensitive data to third parties. Instead, data is available for any participant integrated in the infrastructure with the necessary access rights [5] , and the patient needs to rely on the effectiveness of regulation and audits to enforce their data privacy. Third, custom solutions challenge the interoperability of systems. For example, Bruthans [9] found that e-prescription systems in Europe suffer from a lack thereof as authentication mechanisms are not compatible. Fourth, due to network effects, centralizing control over data and operations tends to cause monopolies, which can hinder productive collaboration [23] .

Decentralized systems aim to address some of these problems. For example, Surescripts, an e-prescription management system in the US, allows entities such as caregivers to access patient information from patients' pharmacies and health insurance companies through the system [5] . However, such approaches impose significant responsibility regarding IT security and access management on pharmacies and health insurances, which might be particularly problematic for small businesses. Furthermore, in Surescripts, patients have to choose a specific dispensing pharmacy when their prescription is created, which decreases user flexibility and convenience. Consequently, researchers have continued searching for better solutions, and in recent years, they have considered blockchain technology as a viable solution for solving the above-mentioned problems of e-prescription systems [8] .

Since an individual or group under the pseudonym Satoshi Nakamoto unveiled the first application of blockchain as the technological backbone of the Bitcoin network [24] , an increasing number of companies and government agencies have recognized the potential of the technology to improve cross-organizational processes [25] . This has led to the emergence of a large number of use cases and projects at varying stages of maturity, especially in the healthcare sector [26] .

At its core, blockchain technology provides a distributed data structure that redundantly stores transactions grouped in blocks on each node of a peer-to-peer network [27] . Aiming to obliterate the need for a central trusted authority [24] , the nodes of the peer-to-peer network repeatedly agree on the state of the system by following a consensus protocol [27, 28] . Each block in a blockchain is linked to the previous block through a cryptographic hash pointer. The blocks, therefore, form a chain, creating a tamper-proof historical data record [29] . Thus, blockchains create a single point of truth between all participants in the distributed ledger [30] . As such, they provide a solution to the double-spending problem, which implies that a specific digital token can be spent more than once at a time [24] . Due to their technical structure, blockchain systems provide several important properties. Resulting from the resistance to crashes or malicious behavior of a small number of nodes, blockchain systems are highly available and decentralized digital infrastructures [31] . To participate in consensus or interact with the peer-to-peer network and authorize transactions, users of a blockchain system must authenticate using public-key cryptography. As a result, blockchain systems also offer an integrated public key infrastructure.

To account for the requirements of different use cases, various concepts of blockchain technology emerged. A prominent conceptualization by Peters et al. [32] distinguishes blockchains along two dimensions. First, transactions in public blockchains are publicly visible, while transactions in private blockchains are only visible to authorized parties. Second, permissionless blockchain systems allow anyone to participate in consensus, while this right is retained to authorized parties only in permissioned blockchain systems. As the technology gained increasing prominence, developers introduced advanced concepts building upon the inherent properties of blockchains. Smart contracts, which can be defined as computer programs that are executed redundantly on virtual machines on the nodes of the blockchain system's peer-to-peer network [33, 34] , enable a large variety of transactions that go well beyond the transfer of cryptocurrencies [35] . One specific application area of smart contracts is the exchange a broad variety of digital assets. These so-called blockchain tokens are value containers that can be transferred among the participants in a blockchain system [36, 37] . The opportunities related to the "tokenization" of physical and digital objects are considered an essential trend for the economy [38] . The inherent value of respective tokens can also aid in implementing incentive mechanisms and, thus, co-ordinate large scale processes among mutually distrusting parties [39] .

Nevertheless, several tradeoffs and challenges remain in currently available blockchain systems [40] . Depending on the field of application, blockchains can introduce disadvantages regarding scalability and data protection due to the synchronous and redundant execution of transactions [41] . Furthermore, energy consumption is an often-mentioned issue. Yet, while blockchains are not the most efficient solution from a resource perspective due to the redundancy in their computation, several implementations of blockchain and in particular permissioned blockchains are by far not as energy-intensive as reports about Bitcoin and Ethereum suggest [42] . Finally, the information exposure due to the replicated storage and execution in blockchains also implies significant challenges both from the perspective of natural persons' data protection as well as sensitive business data. The pseudonymization through public keys as addresses does not considerably mitigate this problem, as the aggregation of information from different domains can provide sufficient means for de-anonymization [43] . While permissioned blockchains partially address this problem through restricting participation in the network, still all of these participants can see each other's transactions by design; so from the perspective of an attacker that intends to retrieve sensitive information, a permissioned blockchain is a centralized system with yet more attack vectors [44] . While concepts such as private transactions through encryption have been implemented in permissioned blockchains to address enterprises' requirements (e. g., in Hyperledger Fabric and Quorum), they restrict the functionality of smart contracts, as these typically cannot run on encrypted or hashed data. Cryptographic tools such as zero-knowledge proofs (ZKPs), multiparty computation, and (fully) homomorphic encryption can be used to bring some of this functionality back, but can come at significant computational cost and complexity [11] . Therefore, utilization of blockchains is not a good approach to solve privacy challenges in the first place and should be considered an additional tool that must be carefully utilized, weighing its pros and cons.

The underlying idea behind the concept of SSI is the provision of digital identities that are not tied to a certain place or organization, and which can be used across organizations with the identity owners' consent [45] . SSI involves three distinct types of entities [46] : the issuer of an identity document, the holder of the respective document, and the verifier of properties described in the document. An analogy from the physical world serves as an illustration of the basic interactions [13] : An SSI system builds upon digital objects comparable to physical ID cards [47] . Appropriate organizations, such as government authorities, issue the respective ID cards to their holders, who subsequently store them in a physical infrastructure of their choice, such as a wallet. The ID cards were designed to be tamper-proof by their issuers and follow a certain schema, which has been made public by their issuer. As a result, the integrity of ID cards can be verified by third parties in bilateral interactions with their holders.

The building blocks of an SSI system can be derived from this analogy. Physical ID cards relate to verifiable credentials (VCs), which are cryptographically signed digital objects containing claims about the identity of their holder [13, 15, 48] . Holders store these VCs in an (typically mobile) application called "digital wallet". To prove properties, or claims, described in their VCs to a verifier, holders generate verifiable presentations (VPs). These VPs are tamper-proof presentations of evidence derived from one or multiple VCs to address the requirements posed by a verifier [15, 48, 49] . This can either be achieved by presenting the signed credential itself, e. g., a JSON Web Token or an X.509 certificate, or by creating a cryptographic ZKP, for example from an anonymous credential [50, 51] . The latter method allows data minimization in the form of selective disclosure, where only a subset of the attributes contained in a VC can be revealed. The verifier, who requests proofs of claims contained in one or more VCs, can be an organization as well as an individual or even an object. Additionally, the verifier must trust the issuer to recognize VCs as trustworthy [15, 48] .

Entities within an SSI system use so-called decentralized identifiers (DIDs), unique identifiers following a standardized schema [52] , as identifiers and to create a standardized end-to-end encryption between two parties. DIDs of public institutions can be made publicly discoverable as an alternative to certificate authority (CA)-based binding of public keys and domain names or IP-addresses. To avoid opportunities for correlation, it is recommendable for natural persons to use a new DID in each interaction. While these building blocks provide a solid foundation for an SSI system, a neutral infrastructure is necessary: information about issuers of VCs, such as their current signing keys, and revocation-related information must be publicly available to verify the correctness of VPs. By proving knowledge of the issuer's digital signature and non-inclusion of their VC in a public but privacy-protecting revocation registry (in the form of a cryptographic accumulator), holders can convince a verifier that their VC has not been revoked without having to contact the credential issuer. Furthermore, schemas of VCs must be publicly available to verify the integrity of VPs. Due to its properties as a decentralized and highly available data structure, blockchain technology is often used for this purpose [14, 46] . Lately, the concept of SSI and digital wallets has been applied in a variety of endeavours [53] .

We conducted a structured literature review to identify relevant previous work investigating the potential of decentralized technologies for e-prescriptions following the guidelines proposed by Kitchenham and Charters [54] . Accordingly, we derived our search string on the basis of our research question [54] : "blockchain AND prescription AND health". We decided against using synonyms for blockchain technology as it is regarded the most prominent concept associated with decentralization and often serves as a solution for implementing e-prescriptions in a decentralized way [12, 19, 55] . We screened the databases ACM Digital Library, AISeL, arXiv, IEEE Xplore, Google Scholar, ScienceDirect and Web of Science as they represent the prevailing databases in the computer science and information systems research domain. The initial search yielded 6,009 results in total (see figure 1 ).

Generally, we included research in English language only. During the title screening of our initial search results, we excluded papers which did not mention blockchain and health (or synonyms) in their titles to ensure the relevance of our article set. As Google Scholar yielded 5770 results, we screened the titles of all results until no papers related to our research question could be identified for the last 50 results displayed, sorted by relevance. Afterward, we screened the contents of the remaining papers. First, we excluded papers which did not focus on solutions for e-prescriptions. Second, following the goal of our literature review to identify existing propositions for e-prescriptions, we also excluded papers which do not cover a specific solution architecture. Last, we excluded duplicates from our article set. We found that although blockchain is often mentioned as a viable technology for the health care sector in general [56] [57] [58] , extant literature only rarely explicitly proposes architectures for the management of e-prescriptions. In contrast, the current literature body is placing its focus on blockchain-enabled medical supply chains [17, 59, 60] , electronic health records [61, 62] , and the management of medication histories [63, 64] . Furthermore, while some authors address e-prescriptions explicitly, they focus on implementations and requirements in a specific country, hindering the generalization of their findings [65] . Resulting from the content screening, we identified seven papers in total which explicitly propose or survey blockchain-based solutions for e-prescription processes. After we identified the final article set, we extracted information about the requirements mentioned by the authors, proposed solution architecture, advantages, and challenges. To ensure intercoder reliability, every paper was coded by at least two authors. In the following, we will analyze these papers depicted in Thatcher and Archarya [3] as well as Thatcher and Archarya [19] propose an e-prescription management system that integrates a blockchain-based "immutable database of prescriptions". While the proposed design ensures accountability for processing e-prescriptions, the authors acknowledge that it dismisses patients' privacy [3] , thereby highlighting an essential requirement for e-prescriptions. In contrast, He et al. [12] acknowledge the presence of privacy-related issues in current approaches to decentralized e-prescription systems and suggest a permissioned blockchain for the management of e-prescriptions. However, their proposed architecture still stores sensitive patient data on-chain and hence leaves it vulnerable to cyber-attacks as discussed in section 2.2. Furthermore, patients do not have control over which data is shared. The latter problem is addressed by Li et al. [68] , who outline how a blockchain for medication management can be integrated into the existing e-prescription processes in the USA. The design ensures that only the patient can decrypt data saved on the ledger upon request by pharmacies.

As a result, stakeholders other than the patient are unable to access the encrypted data. Thus, it seems that the authors chose blockchain not as an infrastructure for data sharing, but for the sole purpose of achieving data integrity. However, simpler means to achieve data integrity are not considered (beyond their implicit role within the blockchain network for authentication): Digital signatures can be used without facing challenges of compliance related to the immutable storage on blockchain. In addition, the permanent storage of encrypted data in a blockchain system may become an attack vector in the future due to the increase of computing power over time and the potential availability of sufficiently powerful quantum computers within the next decades. This concern is manifested by ongoing controversial debates in the European Union whether encrypted data should be classified as personally identifiable information or not [69] . Furthermore, while the system proposed by Li et al. [68] is based on a public key infrastructure, the authors do not address how the users' private and public keys should be managed. In addition, the architecture does not prevent the double-spending of e-prescriptions. Meena et al. [2] investigate how patients' privacy may be preserved in a blockchain-based approach to e-prescriptions. The authors propose a prototype based on a permissioned blockchain that allows patients to encrypt and decrypt medical records including e-prescriptions. However, in parallel to Li et al. [68] , the added value of using blockchain as an underlying infrastructure remains unclear, as its sole purpose seems to be the provision of immutability. Furthermore, the authors neglect important user-centric aspects like the management and sharing of keys between patients and pharmacies. It remains unclear how patients are enabled to interact with various involved stakeholders. Similarly, while Ying et al. [2019] propose an architecture that ensures privacy throughout the process of dispensing drugs, they omit the integration of central stakeholders such as the users in their considerations. Cadoret et al. [2020] suggest storing prescription data in private, permissioned blockchains or using ZKP for addressing privacy challenges, but do not provide details how the associated access management would work or on which layer the sensitive data could be exchanged.

Our structured literature review also reveals two concepts building upon SSI in the underlying context. Gropper et al. [2016] propose an SSI-based system for overcoming the current challenges of electronic medical records. However, the authors do not give details how multiple usages of e-prescriptions can be prevented: If there is only one pharmacy where the e-prescription can be spent, a serial number in the VC that needs to be revealed can be used to prevent repeated redemptions. However, in the case of multiple pharmacies one would either need to synchronize the serial numbers of redeemed VC among all pharmacies, resulting in the need for yet another central service or a decentralized solution like a blockchain as a single source of truth, or require interactions between pharmacies and doctors, where the pharmacy redeeming the prescription asks the doctor to revoke the credential. This approach would, however, introduce significant additional complexity.

In summary, we identified three prevailing patterns of decentralized solutions for e-prescriptions. First, some authors suggest using a blockchain as a medium for storing sensitive patient data, but neglect privacy-related issues. Also, methods for efficiently and conveniently managing and exchanging decryption keys are lacking in the proposed solutions. Second, proposed architectures often lack considerations of stakeholder integration. Users or pharmacies are either not a part of the solution architecture or need to rely on third-party services or specialized, new applications. Third, also SSI has been suggested for processing e-prescriptions but does not provide reliable means for preventing double-spending. As interoperability and extensibility to related use cases, privacy considerations, and stakeholder integration have not yet been aligned in current approaches to decentralized e-prescriptions, we hence suggest an alternative approach in the following.

We derive a set of requirements for an e-prescription architecture from our previous analysis of existing approaches to implementing systems for the management of e-prescriptions. Both existing paper-based and e-prescription processes demonstrate certain requirements that must be fulfilled. For example, the current redemption process of paper-based prescriptions ensures that each prescription may be redeemed only once. Accordingly, also e-prescription systems must provide a reliable mechanism to prevent double-spends. Furthermore, our systematic literature review reveals the strengths and weaknesses of decentralized propositions, which allows to derive additional requirements. For example, Li et al.

[2019] highlighted that users must be able to control with whom they will share their data. Table 2 summarizes the requirements and their context. The derived requirements serve as a basis for the remainder of this paper and inform and guide the design and implementation of our proposed system architecture. They also represent the objectives along which we evaluate our artifact in section 5.

Requirement Context References

Users must be able to choose who to share their health data with, including e-prescriptions.

[66], [67] , [12] , [68] , [2] , [3] , [70] R.2 No data silos To prevent the abuse of patient data through operators of centralized solutions and large-scale data breaches of sensitive health data, no centralized data silos containing patient data must exist.

[66], [12] , [68] , [2] , [3] R.3 Pharmacy independence

To ensure competition and free choice of patients, the user must not be bound to a specific pharmacy for redeeming the prescription. [12, 67] R.4 Key management

The developed system must be convenient to use and should not create unnecessary overhead due to key management exposed to the users.

[68], [2] , [3] R.5 Interoperability Current implementations for e-prescriptions differ significantly, hindering interoperability and thereby adoption as a result. Interoperability could furthermore extend the application areas of e-prescription systems.

[66], [67] , [68] , [19] R.6 Scalability and performance

The e-prescription management system must be able to quickly handle a sufficient number of prescriptions redeemed on a large scale, even at peak times.

[66], [67] , [12] R.7 Doublespending prevention

To prevent fraud, prescriptions must not be redeemed twice, or not more frequently than the number of times intended in the case of periodic prescriptions.

[19]

Personal health data is highly sensitive. Therefore, confidentiality must be ensured, often stipulated by regulatory efforts. Furthermore, data integrity is required to guarantee the correctness of medication information. Availability ensures the independence of users and supposed functionality of the system.

[66], [67] , [12] [68], [2] , [3] , [19] Table 2 Requirements for an e-prescription management system 4 Architecture and Implementation

The architecture that we propose in this paper builds upon the two major paradigms for decentralized digital interactions discussed in section 2: To address the challenges of existing solutions for e-prescriptions, we employ a hybrid approach leveraging SSI and digital wallets for the bilateral and verifiable information exchange between stakeholders and blockchain technology to prevent double-spends. The overall architecture including the three types of stakeholders -doctors, patients, and pharmacies -is illustrated in figure 4.1.

In our architecture, doctors and pharmacies are each running a digital wallet deployed on servers on-premise or in the cloud. The patient is carrying a digital wallet on their smartphone and interacts bilaterally with the doctors and pharmacies of their choice. No direct communication between doctors and pharmacies is necessary, as the authenticity of VPs derived from VCs can be verified through the issuer's signature on the VC and the accumulator state of a revocation registry on a blockchain. An intuitive solution for e-prescription management that is purely based on SSI may be designed as follows: The patient visits their doctor, and the doctor creates an e-prescription in the form of a VC. Subsequently, the doctor issues this VC to the patient's smartphone wallet through a bilateral, end-toend (E2E) encrypted communication channel. The patient can then connect with their pharmacy either remotely or in a branch and give a VP of the e-prescription VC that convinces the pharmacy of its correctness and validity (potentially including a proof of non-revocation), provided the pharmacy lists the doctor (more precisely, the doctor's public DID or public key) among a collection of entities that they trust.

To prevent double-spends without the need for an intermediary, we link a blockchain-token that does not carry sensitive or correlatable information to the e-prescription VC. In order to provide an efficiently and conveniently usable key management associated with the token, the e-prescription VC includes the private key that can be used to control the token: As the patient trusts the doctor and the pharmacy concerning the prescription that they want to spend, it is not necessary that the patient has exclusive control over the token at any point in time -the patient can simply carry information that is necessary to retrieve and invalidate the token for double-spend protection in the e-prescription VC. As a result, we extend our architecture as follows: Doctors and pharmacies both run a blockchain client, and upon onboarding, a doctor creates a (long-term) key pair (sk doctor , pk doctor ) and deploys a smart contract granting the doctor the right to create new tokens. When the doctor wants to issue an e-prescription, they generate a new keypair (sk presc , pk presc ) that is only used for this one specific prescription. Next, the doctor creates a new token that can only be spent by the controller of pk presc , i.e., by anyone who knows sk presc , in the smart contract by signing an associated transaction with sk doctor . The doctor then includes the smart contract's address and sk presc in the e-prescription VC that includes prescription-specific information such as the name of the patient, the name of the pharmaceutical, and the quantity the patient can claim. Consequently, any party that receives a VP of an e-prescription VC that reveals sk presc can potentially invalidate, i.e., spend, the associated token if the blockchain with the smart contract is public. Thus, the patient should not reveal this attribute on the e-prescription VC to a party that they do not trust. However, selective disclosure still allows to use the e-prescription VC for VPs towards entities the patient does not trust regarding the token. Spending the e-prescription involves minimal effort, as all necessary information is contained in the VC: When patients go to the pharmacy, they present the relevant attributes contained in the e-prescription VC to the pharmacy, including the smart contract address and sk presc , in a VP. The pharmacy can verify the authenticity of the VP by verifying the associated proof. Subsequently, the pharmacy can use their blockchain client to invalidate the respective token, as they can control it using sk presc , which they learned from the VP. As the transactions in a blockchain are ordered, even in case the patient tries to spend the e-prescription at many pharmacies in parallel, only one of the transactions that these pharmacies send to the blockchain will be the first after ordering and succeed in retrieving the token; all the others will return an error message.

Following the description of our generic architecture, we now illustrate how we implemented the architecture in our prototype. To this end, we again follow the two major building blocks of our design to structure our argumentation. The components of our proposed architecture are illustrated in figure 3 . We set up a Quorum network, which is a permissioned variant of the Ethereum blockchain, for deploying the smart contracts on which doctors create the tokens. We decided for the permissioned option due to its high throughput, low latency, low energy consumption, and low transaction costs (see also section 2.2). Doctors and pharmacies consequently run Quorum clients for token creation and spending. Figure 4 presents the smart contract that a doctor can deploy for a simple token management to prevent double-spends. The smart contract specifies that a Prescription token must have two attributes, namely its issuer (the doctor's public key) and an indicator of how often it can be spent at most. On instantiation, the contract creates a registry for such prescriptions, i.e., a mapping 1 pragma solidity^0.5.16; Fig. 4 The e-prescription smart contract implementation in Solidity that each doctor deploys for the token management of the e-prescriptions that they issue. of public keys (pk presc ) to prescription tokens, and specifies that only the creator of the contract (the admin, i.e., the doctor) can create new prescription tokens. The smart contract furthermore ensures that only someone who signed a spending request for a token owned by pk presc with sk presc can spend it, and only as often as initially specified by the doctor in count. We also deployed node.js clients for doctors and pharmacies, which invokes transactions for creating resp. spending tokens, given the contract address and pk presc resp. the contract address and sk presc . Furthermore, we set up a three-node Hyperledger Indy blockchain network that provides the functionality to store a schema defining the attributes of e-prescriptions ("template"), doctor-specific credential definitions (specifying a doctor's signing key) and revocation registries based on cryptographic accumulators that allow the patient to create ZKPs of non-revocation in their VP. In addition, we deployed an instance of the Aries Cloud Agent in Python, which acts as an Indy-client and a REST-API for bilateral communication, issuance of VC and the creation of verification of VPs, for doctors and pharmacies. Furthermore, we implemented a web-application (frontend) with the Django framework in Python. This web-application can be used for the doctor's onboarding process (deploying the smart contract) as well as connecting to patients and issuing an e-prescription to them (resp., making a VP in the case of the pharmacy). To implement the required functionality for the patient, we employed a smartphone digital wallet app based on the .NET implementation of the Hyperledger Aries protocol. The wallet has been developed by the IT company esatus AG and is available for free in the Google Playstore for Android and the App Store for iOS. It is not built for a specific use case like e-prescriptions but for the generic exchange of verifiable information (such as ID cards, credit cards or diploma) based on standards that are related to the W3C DID and VC standards [15, 52] . The wallet is also interoperable with the Aries Cloud Agent implementations in .NET and Python. Beyond the basic capabilities provided by Hyperledger Aries, such as ZKP-based selective disclosure, it additionally supports custom Hyperledger Indy networks, provides backup functionalities, and recently, it was demonstrated that the content of the esatus wallet (including cryptographic keys and VCs) can be exported to and imported from another wallet by the provider called Trinsic [71] . Similar wallets are also offered by Evernym (Connect.me wallet) and the German IDunion consortium (LISSI wallet).

The aforementioned smartphone wallets can connect with a cloud agent through scanning a QR-code. Alternatively, existing communication channels such as an e-mail can be used for the initial exchange of information, e. g., in the form of a link, on how to establish a connection. The QR-code contains the cloud agent's uniform resource locator (URL) endpoint as well as further meta-information. It can be static or personalized, and it must be accessible to the patient, e.g. when checking in at the doctor or on a pharmacy's website. After the connection has been established, the doctor can fill out the contents of the e-prescription on a simple web interface or further automated programs, as they would do for any electronic and machine-readable prescription. By selecting the connection to the patient, a doctor can trigger the issuance of the e-prescription VC to the patient and the creation of the associated token in the doctor's smart contract. At the pharmacy's branch or website, the patient then only needs to scan a static QR-code, which the wallet can again use to establish an E2E encrypted connection to the pharmacy. This action automatically triggers a proof request from the pharmacy. Consecutively, the patient must select the e-prescription they want to spend and confirm that they want to share the requested attributes. During all these processes, the patient has full control over which of their personal data is shared, which connections they have established yet, and also an overview of the data that they have shared. We present screenshots resp. sections thereof from the wallet during and after the process in figure 6.

Our proposed solution aims to harmonise the requirements that we determined in section 3. In the following, we evaluate our design and implementation along the derived requirements.

We address multiple requirements of digital e-prescription management systems by building upon the SSI paradigm. To this end, we rely on SSI for the interactions of the involved stakeholders, enabling bilateral and hence decentralized data exchange. First, this approach allows users to be in control of their data, as the standardized VCs, containing prescription-related information and the spending key of the associated token, is transferred to patients and stored only in their digital wallet of choice. Furthermore, the SSI paradigm allows patients to interact bilaterally with their doctors and pharmacies. As the authenticity of VPs derived from VCs can be verified through the issuer's signature, no direct communication between doctors and pharmacies is necessary to verify the correctness of information included in the e-prescription. Accordingly, analogous to a paper-based prescription, users are in control of their data and with whom they share it. In contrast to centralized architectures, our solution does not bear one central control point aggregating patients' data and thus also avoids a single point of failure, a requirement that authors have emphasized in the past [8] . Furthermore, storing the data in the users' wallets also implies pharmacy independence. This is due to two reasons. First, as the data is under control of the user rather than being stored in a central database, patients themselves can permit access rather than doctors specifying access rights at the time of creation. Second, as the tokens' spending key is stored in the VCs, any pharmacy that can access the smart contract (in our design, this is a trivial condition as the blockchain is public) and the public revocation registry is able to verify, accept, and invalidate e-prescriptions. Thus, our architecture enables patients to select their pharmacy of choice for redeeming their e-prescriptions, including online pharmacies, as the entire process is digital.

Storing the tokens' spending key in the VCs also implies that keys do not have to be transferred to the user through an additional technical component. Accordingly, token-related key management does not involve patients directly, which decreases complexity for them throughout the prescribing and redeeming process. Instead, our architecture requires patients to use one digital wallet that they may already use in other contexts. The digital wallet enables patients to receive VCs from their doctors and present them to pharmacies. Our demonstration uses a wallet of esatus AG, which beyond supporting the Hyperledger Aries standards supports custom icons, backups, and is interoperable with the Trinsic wallet. Furthermore, we rely on a Hyperledger Indy blockchain for providing information about doctors' signing keys, revocation registries, and schemas as well as credential definitions on a neutral and decentralized infrastructure. However, while Hyperledger Indy represents current standards with regards to SSI frameworks, our implementation is not dependent thereof and could be substituted in case alternative frameworks emerge that support the described standards. The Decentralized Identity Foundation has already collected dozens of DID resolvers that support multiple blockchains for publishing DIDs, and there is ongoing work to also provide the distinct functionalities of Indy, such as cryptographic accumulators for revocation, on other blockchains. Thus, we argue that our architecture ensures interoperability. However, we also identify potential for future research with regards to this aspect. As large-scale health systems often embed e-prescriptions, integration with existing systems like e.g., electronic health records, should be tested for. Nevertheless, by avoiding lock-in effects induced by data silos and using generic components like standardized digital wallets, we argue that our architecture will likely integrate into other systems without major design changes.

Apart from leveraging digital wallets with the SSI paradigm, to satisfy various requirements of decentralized e-prescription systems, we rely on a combination with blockchain technology to address additional requirements. In specific, we ensure double-spending prevention through the use of blockchain tokens. In our proposed solution, each e-prescription VC issued involves the creation of a corresponding blockchain token. In analogy to paper-based prescriptions, the doctor can specify the number of times the e-prescription can be redeemed at the time of issuing the e-prescription token, which is of particular importance for long-term medication plans. This is due to the reason that the pharmacy redeeming the prescription will only dispense a pharmaceutical if the associated token has not already been spent. We employ separate blockchains for storing SSI-related information and managing the tokens due to their respective properties enabling optimized service provision for the required operations. In theory, however, one blockchain would be sufficient for all operations related to our design.

To ensure the practicability of our system, aspects regarding scalability and performance must be considered, including throughput, latency, and costs. Besides, we also assess performance metrics like the end-to-end duration of the e-prescription creation and spending process for our prototype. Regarding costs, several observations of the system can be made. If the smart contract described in figure 4 was implemented on the public Ethereum blockchain, creating the token would currently cost around 15 USD, and the redemption of an e-prescription around 2 USD 1 . Moreover, the throughput would currently be limited to around 10 tx/s, and the latency for creating and sending the token would be on the order of a minute and highly volatile. For this reason, we propose to use a permissioned blockchain as long as the throughput of public blockchains is very limited and transaction costs are high. In the near future, second layer solutions such sharding (splitting the blockchain into sub-chains with a lower degree of redundancy), zk-rollups (a subgroup of participants creates succinct proofs of the correctness a large number of transactions in a batch so that only very little storage computational resources are required for verifying the correctness of the aggregate update), and "side channels" (infrequent on-chain settlement and off-chain transactions based on multi-signatures and fraud-proofs) [72] could enable implementing this architecture also on public permissionless blockchains with acceptable costs.

To estimate whether the throughput of existing permissioned blockchains is sufficient for a hypothetical large-scale e-prescription management system, we conducted a performance analysis with the distributed ledger performance scan (DLPS) [73] : To simulate a cross-European e-prescription system, we deployed a Quorum network in Amazon Web Services, with 8 nodes each in the data centers in Frankfurt, Dublin, Milan and Stockholm. As mentioned above, we chose IBFT as consensus mechanism as it is more fault-tolerant (and, thus, also has a reduced performance compared to RAFT). This makes our network comparable to the design currently deployed by European blockchain service infrastructure (EBSI), where every member state of the European Union is supposed to run a private Ethereum node 2 . For these 32 nodes, we used instances from the AWS EC2 m5.2xlarge series that have 8 vCPUs and 16 GB RAM. This specification is on the lower bound of what EBSI lists as requirements for running a node. 1 The Gas costs for creating a prescription in public Ethereum are approximately 85,000 Gas. 1 Gas currently costs around 10 11 Wei. One Ether corresponds to 10 18 Wei, i.e., 1 Gas corresponds to 10 −7 Ether. One Ether currently costs more than 1000 USD, so ccreate ≈ 1, 000 USD × 1.5 · 10 5 10 7 ≈ 15 USD.

Gas for spending a prescription again depends on the amount to around 14,000 Gas, i.e., around 1 USD -cheaper, but still way too expensive for our use case. 2 Although EBSI does not run Quorum nodes but Hyperledger BESU instead, Quorum and BESU are at the core both based on very similar protocols [74] . Also, regarding their consensus mechanisms, they have similarities: BESU runs IBFT2, an upgrade of the IBFT consensus mechanism in our Quorum network. We concentrated our benchmarking efforts on the createPrescription method, as spendPrescription is significantly less computationally expensive 3 . Using the DLPS, we found a maximum sustainable throughput of around 630 tx/s with a latency of 2.0 ± 0.3 s in the described setting (see figure 7) .

On the other hand, there are currently 4.5 billion prescriptions a year filled in the U.S. [17] and 1.5 million prescriptions per day in the UK [5] . The maximum of these is 14 prescriptions per citizen and year on average. In the EU, this would therefore hypothetically amount to approximately 6.1 billion prescriptions per year, so an average throughput of 200 tx/s for each creating and spending e-prescription token is required. We assume that prescriptions will probably be created and spent mainly on working days between 08:00 and 17:00 and there also will be fluctuations. Thus, a multiplier of at least 5 should be taken into account, which means that around 2,000 tx/s are required. Note that a larger throughput than 550 tx/s can be achieved with smaller network sizes, better hardware, or using the RAFT instead of IBFT consensus mechanism. Thus, we conclude that a large-scale implementation of our proposed solution can be considered realistic with existing technology. We also expect performance improvements caused by efficiency enhancements, optimizations like second-layer solutions as described above, and the opportunity to set up two or three separate blockchain networks for token management by the time that all prescriptions in Europe have been digitized. Concerning costs, even running 10 of the the described Quorum blockchains would cost only around 1,000,000 USD per year for server provision on AWS, which amounts to less than 10 −3 USD per e-prescription [75] .

The latency for the createToken and spendToken methods that the doctor respectively the pharmacy need to invoke during issuing respectively verifying an e-prescription in our implementation each take around 2.5 s at low throughput when the block-time of IBFT is configured to 1 second. Our measurements also yield that at higher throughput, latency does not increase considerably.

The steps involved in an SSI-based interaction (establishing a connection, issuing a VC or verifying a VP) as described do not provide a significant challenge regarding scalability as the interactions are conducted bilaterally: We found that a single cloud agent that the doctor and the pharmacy run can issue and verify at least two VCs per second, which should be sufficient even for a medical office with several doctors. Moreover, these clients can be scaled horizontally if necessary. The processes conducted on the Hyperledger Indy network do not negatively affect scalability: Doctors can update their revocation registries in batches, e. g., once a day; and revocation is likely to happen only rarely anyway. The creation of credential schemas or credential definitions only has to be conducted during onboarding processes of doctors and thus does not require high throughput. Finally, a single Indy node can serve several hundred reads per second 4 , so a medium-sized Indy network with a two-digit number of nodes can handle sufficiently many read requests per second. Note that if no proof of revocation is necessary and a pharmacy stores the DIDs and public keys (credential definitions) of the doctors in their vicinity and only updates this local copy occasionally, a VP would not even need a single write or read operation on the Indy blockchain. We conclude that our e-prescription management system provides sufficient scalability and performance for hundreds of millions of users.

Regarding the patient-side processes, it takes around 15 seconds for the patient to open their wallet, establish a connection with the doctor and accept that the e-prescription is issued to and stored in the patient's smartphone wallet (this involves two user-side confirmations). A similar time is needed from the patient opening their wallet, scanning the QR code for the redemption process until the pharmacy has verified the VP and that the token has not been spent yet. We consider this a reasonable time for the end-to-end automation of the paper-based process (having in mind future optimizations of the cryptographic libraries in use and workflow improvements regarding smartphone wallets), although practical trials would ultimately need to confirm patient's satisfaction with the process' speed.

Apart from ensuring sufficient scalability of the prototype, an important requirement for e-prescriptions relates to information security, which is usually achieved through the confidentiality, integrity, and availability of data [76] . First, we ensure confidentiality through bilateral data exchange and providing patients with an option for selective disclosure of information within their e-prescriptions. Centralized, platform-based approaches to storing and managing e-prescriptions bear risks regarding security and expose shortcomings in terms of user control and interoperability as well as potential performance downsides on large scale. Thus, we adopt digital wallets as the main layer for the exchange of e-prescription related data. Accordingly, the physical prescription is digitized through a VC that is stored only on the patient's device. The patient can then present information from the VC in a VP to other entities, in particular to a pharmacy, in a way that is verifiable without the need to contact the issuer, i.e. the doctor. The data minimization capabilities offered by existing implementations of digital wallets and in particular the opportunity to leverage selective disclosure gives patients privacy and the maximum control over which data they share. Second, in addition to confidentiality, we aim to address data integrity through the use of digital signatures in VCs, which prevent counterfeiting e-prescriptions. Third, to achieve availability, we rely on a decentralized and, thus, highly resilient blockchain infrastructure for functionalities that cannot be resolved bilaterally. This includes the prevention of double-spending tokens as well as, e.g., revocation registries for VCs issued by a doctor. All additional data required for processing e-prescriptions is stored on a device by the patient. These entities (including, e.g., a doctor or even a patient) can also decide to rely on cloud agents to facilitate a high availability of their digital wallets.

During the literature analysis, we identified the requirement "Pharmacy independence". Fulfilling this requirement necessitates some way of synchronization among pharmacies to prevent double-spending. One way would be to create a centralized platform on which the pharmacies can exchange information, which would, however, again raise the problem of interoperability and security. Alternatively, the pharmacy could ask the doctor for revocation as soon as they get a VP involving an e-prescription. However, this again requires a lot of connections between doctors and pharmacies that need to be maintained and protected.

In case the patient already has a digital wallet for some other digital documents, such as a state-issued digital id-card, a digital credit card or digital diploma, patients' can rely on existing infrastructure, meaning they do not need to install and get used to another app. These use cases are currently being explored on implementations of digital wallets in the public and private sector, for example, by the United States Department of Homeland Security, the Canadian provinces British Colombia and Ontario, or the German IDunion consortium. They are implementing on common interoperable standards that are close but not yet fully compliant with the world wide web consortium (W3C) standards DID and VC that we described in section 2.3. There are several implementations for smartphone wallets, like Evernym's connect.me and wallets by Trinsic, lissi and esatus that are freely available. Moreover, there are open-source implementation of server-based, so-called cloud-agents, such as the Hyperledger Aries Cloud Agent in Python or .NET. The named wallets are largely interoperable (sometimes there are small version conflicts as code development of the wallets and the open-source Hyperledger Aries project that defines these standards evolve quickly;

Centralized, platform-based approaches to storing and managing e-prescriptions bear risks regarding security and expose shortcomings in terms of user control and interoperability as well as potential performance downsides on large scale. Thus, we adopt the SSI and digital wallet paradigm as the main layer for the exchange of e-prescription related data instead. Accordingly, the physical prescription is digitized through a VC that is stored only on the patient's device. The patient can then present information from the VC in a VP to other entities, in particular to a pharmacy, in a way that is verifiable without the need to contact the issuer, i.e. the doctor. The data minimization capabilities offered by existing implementations of digital wallets and in particular the opportunity to leverage selective disclosure, gives patients' control over which data they share. Furthermore, the approach allows to use an already reasonably standardized infrastructure for e-prescriptions.

After all, the doctor can refuse to issue a prescription or invalidate it (through revocation) in any case, and the pharmacy could always refuse to accept an e-prescription either (moreover, through the authenticated and thus non-repudiable information flows in blockchains and in bilateral communication with digital wallets, the patient could even demonstrate that they misbehaved in some scenarios).

Opening the wallet and establishing a connection by scanning the QR-code at the doctor takes around 10 s for the patient.

Straight confirmation (without reading all the details what they disclose) takes the patient around 16 s from opening the wallet over scanning the QRcode until the pharmacy gets the requested attributes including a proof of correctness, a proof of non-revocation, and a confirmation from the blockchain that the token has not been spent yet and the remaining Redemption attribute of the prescription token has been reduced.

This gives the patient maximum control over the data that they share, removes vulnerable data silos, and also increases system resilience and scalability as there is no bottleneck through which all interactions need to pass (and read access for getting the revocation status on blockchains scales well with the blockchain size).

Conceptionally, there is no need to have two blockchains, but currently there is no blockchain that provides support both for the identity-related functionalities of Indy and customizable smart contracts as we need them for creating a smart contract in which the doctor can issue tokens. Moreover, if the contract address indicated in the prescription uniquely specifies the blockchain and the methods that need to be called to check and invalidate the token, different doctors could even deploy their contracts on different blockchains (however, a large number would likely increase complexity as different, as compatible client applications need to be implemented). The doctor can specify these properties as the pharmacy will need to trust the doctor to accept e-prescriptions issued by them; so they will accept the way that the doctor provides to them to make double-spending checks

To overcome the challenges of current approaches to the management of medical prescriptions, we design, implement, and evaluate a decentralized e-prescription management system using blockchain technology and digital wallets. We develop and benchmark the proposed system along requirements derived from a thorough literature review. Thus, we contribute a generic design as well as an illustrative implementation of an e-prescription management system. The findings deduced from our evaluation offer insights into the opportunities and remaining challenges regarding the development of decentralized systems dealing with sensitive data and business-logic that involves multiple stakeholders. Our design and implementation also aid practitioners in developing systems beyond the health sector with similar requirements. The following chapter includes a discussion of four important implications related to our design to provide additional context. We subsequently conclude the paper by identifying our work's limitations and highlighting opportunities for future applications and research.

First, the role and necessity of applying blockchain in the context of SSI systems remain debatable. In our design, we deliberately chose to use a blockchain for several distinct purposes. As a transparent, highly available, and tamper-resistant neutral decentralized infrastructure, one blockchain serves as a permanent ledger storing information of public interest in the context of SSI: profiles of issuing doctors, privacy-preserving revocation registries for e-prescriptions, and schemas thereof. These functionalities are relevant in the context of any SSI system, which is why we deem it reasonable to include a blockchain for these purposes in the respective designs. Nevertheless, these functionalities are also achievable using centralized infrastructures, however giving up some of the advantages coming with a blockchain such as independence from CAs (in the context of e-prescriptions) and availability. In many SSI applications, re-use of VCs is desired, such as for national ID VCs. However, in our case, avoiding possibilities for double-spending e-prescriptions is of utmost importance. As a result, we incorporated a second blockchain managing unique tokens corresponding to each e-prescription VC which prevent doublespending. In principle, a centralized system could also be used for this purpose, as the data required for the double-spending check is no more confidential in our construction. We suggest a design that separates the double-spending check from the layer of exchange of confidential data for any SSI use case requiring a restricted number of usages in VCs. Separating the restriction regarding double-spending (token) from invalidation (revocation) also allows to prevent multiple redemptions but at the same time reusing the VC for information exchange, e. g., to check for cross-reactions of medicals, without a limit.

Second, it is important to note that SSI and blockchain technologies are characterized by open-source software philosophies and are often freely available. Moreover, the respective technologies do not include a central, controlling party by design. Therefore, the stakeholders need to establish adequate governance structures to ensure the creation of a functioning ecosystem, including secure processes outside of the technical system proposed. In the context of prescriptions, the central entities in the respective communities could take up important roles in this regard. For example, stakeholders must agree on mechanisms for certifying doctors or the attributes including their data types specified in e-prescription VCs. Due to the technical nature of this publication, we omitted recommendations about governance; however, valuable work on this topic exists, both in the realm of blockchain technology [35] and SSI [77] .

Third, prior research indicates that the acceptance and usefulness of e-prescriptions increases when the required functionalities are embedded in a larger ecosystem [78] . This could, for example, include generic systems for managing and exchanging patient health data. To this end, the generic nature of the components used in SSI systems can provide several promising opportunities. Network effects can occur through the interplay of a VC-based e-prescription with other VCs such as digital insurance cards, ID cards, or vaccination credentials. Thereby, the mutual utility of such VC can be improved, making the e-prescription framework even versatile, e. g. for a proof of identity in telemedicine, communicating with an insurance company, or digitizing the reimbursement process for prescriptions.

Fourth, by combining SSI and blockchain, we suppose that our solution addresses several regulatory requirements, especially those imposed by the strict EU GDPR. These include principles for processing personal data such as data minimization, integrity, and confidentiality, as well as lawfulness, fairness, and transparency (Article 5 GDPR) [21] . We address data minimization and confidentially by relying on ZKP through using selective disclosure and releasing only the data requested by the pharmacy. No third parties have access to this data. This is complemented by the use of unique DIDs for each connection as well as E2E encrypted connections to provide a private connection between the parties involved and to minimize the risk of unintended correlation. Nevertheless, ZKPs have been rarely used for signature schemas in practice so far and are thus still uncharted territory from a regulatory perspective. We also respect the rights of data subjects, such as the right to erasure ("right to be forgotten") (Article 17 GDPR), as no patient-related data or metadata is stored on the ledger. Rather, by relying on the SSI paradigm, we give the user the responsibility for their own data such that the right to erasure and the right to rectification are also adhered to (Article 16 GDPR). This design choice also addresses the right to data portability (Article 20 GDPR) as we use components oriented at the DID and VC standards and interoperable wallets for implementing the paradigm.

Our research is not without limitations. In the current design, we provide confidence on the verifier side (pharmacy) that a user is actually eligible to redeem a prescription through cryptographic keys and VCs that are stored in their device but that could potentially be retrieved. Many SSI implementations and the digital wallets that we discuss in this paper support a mechanism that allows to prevent not only theft but also the selective sharing of credentials without the necessity to reveal a publicly correlatable id (like a common public key) in the software, but they do not yet include secure hardware in every place. In general use cases, such as telemedicine, mechanisms offering higher levels of assurance are of utmost importance, but on the other hand, in the case of the redemption of an e-prescription, credential sharing might be even desirable. However, to date credential delegation mechanisms that allows a patient to forward their e-prescription VC (including the spending key) to another user are not integrated in Hyperledger Indy and Aries. Building on the theoretical work of Camenisch et al. [2017] , the implementation is currently in progress. Further investigations are also required on whether the revocation registry can be stored on a blockchain from a regulatory perspective or whether it should be held in central databases to ensure data protection and security for data subjects. Despite believing that we comply with the current GDPR policies through the cryptographic accumulator-based design of revocation registries, we suggest considering our presented solution in light of other data protection regulations such as the CCPA or the U.S. HIPAA data protection rules. Interviews with legal experts may support a thorough evaluation of the regulatory compliance of the proposed system and its implementation.

The missing functionality of credential delegation also implies that certificate chains are currently not supported in our prototype. As a result, if a doctor wanted to delegate the issuance of e-prescription VCs to their employees, these would currently need their own public DID and credential definition on the Indy blockchain to be individually recognized by pharmacies as trusted issuers of e-prescriptions, and their own prescription smart contract. The support of certificate chains and delegation in SSI could make such a system substantially easier to implement, govern, and scale. A delegation mechanism for the e-prescription smart contract is also not yet implemented, but could easily be included, for example by adding a method that allows the admin to add further public keys whose controllers are allowed to create new tokens.

Moreover, with long-term private key pairs used by doctors for deploying smart contracts, one can see how many prescriptions a doctor has issued in our current implementation. This shortcoming could be addressed through the usage of ZKP in future work: Like in cryptocurrencies such as Z-Cash or anonymity pools such as Tornado Cash on Ethereum, introducing a single pool for creating and spending e-prescription tokens and replacing the currently used anonymized valid and redeemed e-prescription tokens by cryptographic commitments and nullifiers can prevent the tracking of doctors' activities. Furthermore, we have also not tested our prototype in practice so far. As the system's potential users are highly heterogeneous, a field test and subsequent evaluation in practice is still a significant limitation and will be one of the next steps in our research. However, when we presented our prototype to students and practitioners with expertise on blockchain and SSI, their reactions were very positive and gave us confidence that the proposed architecture can experience acceptance by different stakeholders.

We derive several promising avenues for future research from the discussion and limitations of our work. First of all, researchers should explore technical limitations, such as a strong binding of VC to users when a high level of assurance is required, e. g, through link secrets, biometrics, secure hardware, but also flexible enough to allow for easy usage in settings where only a low level of assurance is sufficient [79] . Further, support for certificate hierarchies is important for key management in large ecosystems, and a discussion of advantages and disadvantages of blockchain-and CA-based public key infrastructures (PKIs), as well as decentralized or centralized double-spending protection, could be started based on first successful implementations. Furthermore, we urge researchers to implement and evaluate similar designs in other use cases in practice. Due to the novelty of the applied technologies in our proposed system, studies about the interactions of users with respective systems are still rare. Thus, corresponding research endeavours could study the respective interactions and resulting implications as well as improvements for the implementation of our design.

The health sector is currently undergoing rapid changes due to the constantly advancing digitalization of society. Health data is highly sensitive and therefore requires the application of secure and privacy-preserving technologies. Owing to their properties in those regards, both blockchain and SSI, and in particular their combination, offer promising opportunities for the digital transformation of the health care sector. However, the need for a high degree of user control on confidential data is also present in many other scenarios, such as interactions of citizens with their government, or business-to-business interactions. We encourage researchers and practitioners alike to take up our work and further advance the future of health care as well as cross-organizational workflows in business and public administration.

[7] Lord, N.: Top 10 Biggest Healthcare Data Breaches of All Time (2020). https://digitalguardian.com/blog/ top-10-biggest-healthcare-data-breaches-all-time Accessed 2021-07-24

Emerging Digital Technologies to Combat Future Crises : Learnings From COVID-19 to be Prepared for the Future

Preserving Patient's Privacy using Proxy Re-Encryption in Permissioned Blockchain

Pharmaceutical Uses of Blockchain Technology

A System for Secure Electronic Prescription Handling

Digital Health in Physicians' and Pharmacists' Office: A Comparative Study of e-Prescription Systems' Architecture and Digital Security in Eight Countries

State of Cybersecurity & Cyber Threats in Healthcare Organizations

Toward Blockchains for Health-care Systems: Applying the Bilinear Pairing Technology to Ensure Privacy Protection and Accuracy in Data Sharing

The state of national electronic prescription systems in the eu in 2018 with special consideration given to interoperability issues

Characteristics of a blockchain ecosystem for secure and sharable electronic medical records

Security and privacy on blockchain

BlockMeds: A Blockchain-Based Online Prescription System with Privacy Protection

Self-Sovereign Identity als Grundlage für universell einsetzbare digitale Identitäten

Search of Self-sovereign Identity Leveraging Blockchain Technology

Verifiable Credentials Data Model

Kaiser Family Foundation: Retail Prescription Drugs Filled at Pharmacies per Capita

How an Enterprise Blockchain Application in the U.S. Pharmaceuticals Supply Chain is Saving Lives

Transmitting and Processing Electronic Prescriptions: Experiences of Physician Practices and Pharmacies

RxBlock: Towards the Design of a Distributed Immutable Electronic Prescription System

E-Prescription across

General Data Protection Regulation (GDPR)

DPKI: A Blockchain-Based Decentralized Public Key Infrastructure System

Digital platform ecosystems. Electronic Markets

Bitcoin: A Peer-to-peer Electronic Cash System

Blockchain research, practice and policy: Applications, benefits, limitations, emerging research themes and research agenda

Blockchain in Healthcare Applications: Research Challenges and Opportunities

Pervasive Decentralisation of Digital Infrastructures: A Framework for Blockchain enabled System and Use Case Analysis

Blockchain for the iot: Privacy-preserving protection of sensor data

Blockchains: A Systematic Multivocal Literature Review

Blockchain Research in Information Systems: Current Trends and an Inclusive Future Research Agenda

The Evolution of an Architectural Paradigm -Using Blockchain to Build a Cross-Organizational Enterprise Service Bus

Understanding Modern Banking Ledgers through Blockchain Technologies: Future of Transaction Processing and Smart Contracts on the Internet of Money

white paper-a next generation smart contract and decentralized application platform-vitalik-buterin

Toward trust in internet of things ecosystems: Design principles for blockchain-based iot applications

Governance in the Blockchain Economy: A Framework and Research Agenda

To Token or not to Token: Tools for Understanding Blockchain Tokens

Blockchain Technology: Principles and Applications

Data Privacy-preserving Distributed Knowledge Discovery Based on the Blockchain

Trade-offs between Distributed Ledger Technology Characteristics

Core Concepts, Challenges, and Future Directions in Blockchain: A Centralized Tutorial

The Energy Consumption of Blockchain Technology: Beyond Myth

An Analysis of Anonymity in the Bitcoin System

Information Privacy in Decentralized Applications. EAI/Springer Innovations in Communication and Computing

The Path to Self-Sovereign Identity

A Survey on Essential Components of a Self-sovereign Identity

Decentralized Identity: Where Did it Come From and Where is it Going?

Self-Sovereign Identity: Decentralized Digital Identity and Verifiable Credentials

A Gentle Introduction to Verifiable Credentials

An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation

No Paradox Here: ZKPs Deliver Savvy Trust

Decentralized Identifiers (DIDs)

Blockchain-based Identity Management: A Survey from the Enterprise and Ecosystem Perspective

Guidelines for performing Systematic Literature Reviews in Software Engineering

Blockchain-based Electronic Healthcare Record System for Healthcare 4.0 Applications

Hitching Healthcare to the Chain: An Introduction to Blockchain Technology in the Healthcare Sector

Applications of Blockchain in Healthcare: Current Landscape & Challenges

Opportunities for Using Blockchain Technology in E-Health: E-Prescribing in Germany

A Novel Medical Blockchain Model for Drug Supply Chain Integrity Management in a Smart Hospital

Authentic Drug Usage and Tracking with Blockchain Using Mobile Apps

Healthchain: A Novel Framework on Privacy Preservation of Electronic Health Records Using Blockchain Technology

Blockchain Technology Use Cases in Healthcare

Patient-centric Medication History Recording System using Blockchain

Can Blockchain Technologies Help Tackle the Opioid Epidemic: A Narrative Review

An Electronic Prescription System Powered by Speech Recognition, Natural Language Processing and Blockchain Technology

Proposed Implementation of Blockchain in British Columbia's Health Care Data Management

Powering the Physician-Patient Relationship with HIE of One Blockchain Health IT

DMMS: A Decentralized Blockchain Ledger for the Management of Medication Histories

Blockchains and Data Protection in the European Union

A secure blockchain-based prescription drug supply in health-care systems

Sovrin: Interoperability Series: Sovrin Stewards Achieve Breakthrough in Wallet Portability

SoK: Off The Chain Transactions

The DLPS: A Framework for Benchmarking Blockchains

Amazon EC2 On-Demand Pricing

Principles of Information Security. Cengage Learning

Decentralized SSI Governance, the Missing Link in Automating Business Decisions

Decentralized SSI Governance the missing link in automating business decisions Accessed

The Development and Evaluation of an Integrated Electronic Prescribing and Drug Management System for Primary Care

Using Biometrics to Fight Credential Fraud

Acknowledgments. We want to express our special thanks to Matthias Babel for his support with the e-prescription smart contract, to Jana Glöckler for her groundwork on connecting the Hyperledger Aries Cloud Agent in Python with the Django framework, and to Jonathan Lautenschlager for his valuable feedback and suggestions for improvement.