1 Introduction

Europe is experiencing significant changes in Information and Communication Technologies (ICT), as outlined in annual or multiannual Action Plans (AP) by the European Union (EU). These plans focus on various key areas such as employment, healthcare, migration challenges, and sustainable finances [1].

One notable AP is the eHealth plan for 2012–2020, emphasizing the potential of ICT in health systems to improve citizens’ health, quality of life, and generate financial and social benefits. E-health involves the extensive use of ICT in healthcare, encompassing its integration into services, development of ICT-driven products, and optimization of processes for holistic healthcare improvements [2].

One significant barrier to eHealth adoption is achieving technical interoperability, acknowledged not only in Electronic Government (eGov) but also in the broader European Interoperability Framework (EIF) [3]. Despite the EIF, the specific needs of eHealth led to the creation of the eHealth EIF (EEIF) by the European Commission (EC) in 2013 and the Refined EEIF (REEIF) was developed in 2015. The eHealth Network (eHN) reached a consensus to adopt REEIF, providing a framework and methodologies to address challenges hindering the exchange of health information, such as diverse standards, data formats, stakeholder complexity, and privacy concerns [4]. The eHN, established under Directive 2011/24/EU, consists of EU Member States (MS) participating voluntarily. MS are obligated to establish National Contact Points for eHealth (NCPeH) to facilitate health-related information exchange within their territories [5].

The establishment of an interoperable eHealth network is a top priority for the EU, crucial for efficient health information exchange, improved healthcare services, and the well-being of citizens. In the evolving eHealth landscape, disruptive technologies like BC gain importance. BC’s relevance is emphasized in the EU eGOV Rolling Plan (RP) of 2023, integrated into the IEEE P2141 series standards, focusing on BC for enterprise information systems and combating corruption. Given the historical centralization in the eHealth domain, BC’s decentralization capabilities have the potential to enhance transparency, security, and data integrity in health data exchanges. Therefore, this paper seeks to address the following key questions:

  • RQ1. How can BC technology enhance transparency in the eHealth domain, while ensuring interoperability among the various systems?

    RQ2. How can BC enhance security by design in a highly centralized eHealth ecosystem?

    RQ3. How can a BC improve data quality in eHealth, networks while safeguarding sensitive data from unauthorized access?

    RQ4. How can a BC supported eHealth network be GDPR compliant to protect data sovereignty and rights?

In summary, BC technology holds great promise in transforming the eHealth domain by addressing these critical questions related to transparency, security, data quality, and GDPR compliance. Its decentralized nature offers a unique opportunity to reshape how health data is managed, shared, and protected in a rapidly evolving digital healthcare landscape.

2 Background and research review

The Digital Single Market (DSM) strategy, introduced by the EC in 2015, driven by economic considerations, includes initiatives to remove obstacles in cross-border e-commerce, invest in high-speed broadband infrastructure, and promote innovation in the ICT sector [6]. The DSM has accelerated advancements in various sectors, particularly in cross-border data and services exchange, notably in healthcare. As the exchange of resources becomes crucial, technological advancement, interoperability, and policy alignment are essential for facilitating collaboration among agencies and countries [7].

Facilitating the mobility of EU citizens relies on information exchange infrastructure across MS, particularly in eHealth, allowing Healthcare Professionals (HP) to access medical data of individuals across borders [8]. This exchange faces legal, technical, and security challenges, addressed through decentralized PS and cross-border eP systems. The EU emphasizes healthcare standards enhancement through collaboration, implemented via the Cross-Border Health Directive (2011/24/EU), enabling EU residents to access healthcare services within its boundaries [9]. The expected rise in cross-border medical treatment would increase the exchange of patient information, subject to the EU’s GDPR and the Patient’s Rights Directive, providing a benchmark for patient confidence in such activities [10].

ICT plays a crucial role in creating essential infrastructure for cross-border data exchange, addressing challenges like interoperability, confidentiality, security, data integrity, and data sovereignty. The Interoperable Europe Act establishes a strategic cooperation mechanism for interoperability. The RP for ICT Standardization, drafted annually by the EC in collaboration with the European Multi-Stakeholder Platform on ICT Standardization, links EU policies with ongoing ICT standardization efforts [11]. The 2023 ICT standardization RP includes BC and Distributed Digital Ledger Technologies policy, recognizing BC’s potential to establish a framework for trusted, decentralized services beyond the financial sector [12] by reshaping transactions, information storage, data sharing, and enabling secure sharing of e-health records (EHR) with patient control over data access, addressing communication disruptions, disparities in medical records, and incompatible ICT interfaces among stakeholders [13]. BC applications in healthcare cover secure handling of EHRs, patient consent management, drug traceability, and data security in clinical trials [14].

The eHealth sector is set to improve through strategic measures like the adoption of eP/PS services, enhancing cross-border healthcare access and collaboration among MS [15]. The European Health Data Space (EHDS) regulation, including MyHealth@EU services, builds on the European Patient Smart Open Services (epSOS) pilot and the eHDSI project funded under the Connecting Europe Facility (CEF) and now part of the EU4Health program until 2027 [16]. In this study, the cross-border services offered via eHDSI are commonly denoted as “MyHealth@EU,” and the terms eHDSI and MyHealth@EU are utilized interchangeably. The EC launched the EHDS in 2022, with two goals, the first goal is focusing in Primary Use of Data by HP by empowering individuals to have authority over their health data, both within their own nation and when crossing borders, and the second goal is focusing in the Secondary Use of Data, by enhancing the utilization of health data for research, innovation, and policy formulation [17].

Europe is transitioning to a digitally-oriented era, emphasizing a comprehensive approach to secure and transparent eHealth services across MS while facilitating citizen mobility. The paper will delve deeper into the eHDSI network’s architecture and core services, particularly eP and PS, identifying research deficiencies and proposing solutions.

2.1 The eHealth digital services catalogue

The eHDSI platform facilitates cross-border health data exchange among EU MSs, involving two countries: Country A (patient’s home) and Country B (treatment location). Current services include eP and PS, with the upcoming MyHealth@EU network introducing the Original Clinical Document (OrCD) service.

The MS Deploying Country manages the NCPeH, ensuring availability of Generic Services (GS). DG SANTE, as the eHDSI Solution Provider (SP), makes Core Services (CS) accessible for interoperable health data exchange. The eHDSI Service Catalogue (SC) lists CS, and gateway services establish connectivity between national infrastructures and the CS platform. The eP and PS SC, as showcased on the official MyHealth@EU website by reference [18], encompasses a range of offerings depicted in Table 1; Fig. 1. Services like the Monitoring Services, the Terminology Services, encompassing the Master ValueSet Catalog (MVC) and Master Translation/Transcoding Catalog (MTC), must adhere to the eHDSI Requirements Catalog to ensure seamless functionality across MS and to uphold the availability, security, integrity, and interoperability of health data.

Fig. 1
figure 1

Service offering > solution provider perspective according to DG SANTE official MyHealth@EU documentation

Full size image
Table 1 DG SANTE MyHealth@EU services catalogue from official documentation
Full size table

2.2 The eHealth digital services requirements catalogue

Under eHDSI, fall two main cross-border use cases, the eP/eD and the PS. The objective of the PS use case [19] is to enable HP in Country B (country of treatment) to access the PS of a patient from Country A (country of affiliation) who is seeking healthcare, whether it be for occasional or regular visits. The patient’s rights cross-border Directive (2011/24/EU) describes PS a distinct collection of information that encompasses essential health details necessary for HP to guarantee the delivery of safe and secure healthcare. The normal sequence diagram of the use case is shown in Fig. 2. Currently, MyHealth@EU handles patient authentication based on national policies without using an electronic ID. Each MS is obligated to establish and maintain its national patient and document search database.

Fig. 2
figure 2

Patient summary use case normal sequence according to DG SANTE MyHealth@EU official documentation

Full size image

The objective of eP/eD use case [20] is to enable a patient to obtain prescribed medication in Country B, when the prescription originates from Country A, where the patient possesses valid healthcare identification. The normal sequence diagram of the use case is shown Fig. 3. Within this sequence diagram, four main functional requirements are identified that need to be addressed. The first, is to ensure the security of the service, encompassing aspects like identification, authentication, and patient consent to enable information access between different countries. The second, is to support accurate interpretation of the information, which includes semantic correctness and the correct identification of prescribed medicines. The third, is to define the essential information required to facilitate all stages of the service, including prescription, dispensation, and informing about the dispensation. The fourth, is to provide transparency regarding a country’s processes, including its legislation, to other participating countries.

Fig. 3
figure 3

ePrescription/eDispensation use case normal sequence according to DG SANTE MyHealth@EU official documentation

Full size image

The requirements align with those in the PS use case, focusing on accurately identifying the patient, exchanging high-quality information, and providing the eP document to the HP. The fourth requirement involves managing medication dispensation, following legal regulations in the patient’s treatment country. Country B’s NCPeH transmits dispensation information to Country A, adhering to MyHealth@EU semantic format.

The new use case, OrCD, empowers Country B’s HP to retrieve an OrCD from Country A, associated with a patient seeking medical care. Implementation is supported by an EU Direct Grant in the 2023 EU4Health program. National Competent Authorities are designated for funding, but this paper won’t analyze this use case further.

3 Motivation

The foundational document for secure cross-border data exchange in the eHDSI network is the Interoperability Specifications document from DG SANTE [21]. This document establishes NCPeHs as trustworthy entities, requiring mutual recognition of assertions made by NCPeHs. The Circle-of-Trust among participating nations is emphasized, ensuring acknowledgment of assurances from other countries in the eHDSI network. The primary assurances incorporated into the security framework include:

  • The accurate identification and authentication of data consumers and producers in Country B.

  • The presence of patient consent for participation in the eHDSI.

  • Confirmation of a treatment relationship with the patient and authorization of Country B’s data consumers and providers by the patient.

  • Ensuring the integrity of shared data.

  • Verification of the origin and authenticity of the data shared.

The eHDSI MultiLateral Agreement establishes common conduct, assurances, and standards for participants, facilitating the creation of a Circle-of-Trust. This agreement ensures a secure, access-controlled, and resilient environment for confidential health information exchange, with key information requirements:

  • The entity or legal authority responsible for issuing and/or authenticating the captured information.

  • The identifier of the HP for whom the information was collected, along with their human-readable name.

  • The organization or entity under which the HP underwent authentication.

  • The time at which the identity information was initiated and when it will expire.

  • The specific context in which the HP’s identity was verified.

  • The legal authentication of all the recorded information by the responsible party, typically the NCPeH-B.

It is crucial to maintain the authenticated identity of healthcare providers persistently within transactions to ensure traceability, linkability, and non-repudiation. Authenticity and data integrity of medical data must be verifiable by recipients, and attached information regarding data source identity must remain unaltered during cross-border transmission.

DG SANTE’s Interoperability Specifications document outlines shared requirements for user identification, authorization, transparency, security, data quality, and privacy protection in both PS and eP/eD. Proposing the integration of a BC framework and modules into eHDSI components, communications, and mechanisms, we aim to enhance interoperability and security while aligning with GDPR requirements. The BC network’s advantages, such as an immutable ledger, tamper-proof records, decentralized communication, and the use of digital signatures, timestamping, and smart contracts, contribute to achieving these objectives [22, 23].

4 Blockchain in the eHealth digital services infrastructure

To establish the foundation for adopting BC in the eHealth sector, determining the suitable BC network is crucial. Two main types are public and private BCs. Examples of public BCs include Bitcoin and Ethereum, known for digital currency and various business applications [24, 25]. Public networks are open to everyone, but businesses hesitated to expose sensitive information. Private BC networks gained prominence, retaining immutability, decentralization, and automation benefits but with different governance and consensus models. Consensus involves agreement among nodes on transaction validity, and governance grants authority to permit or forbid network participation [26]. Private BCs often have authorization levels, restricting unauthorized access based on user roles.

Given the crucial considerations of privacy and security in the eHealth sector, a private BC network emerges as the sole viable choice for operations like eP/eD and PS within eHDSI [27]. The network architecture, distinct between national infrastructures and gateways (NCPeH), ensures central connection through NCPeH. Direct communication between foreign NCPeH and national infrastructures is strictly prohibited. Requests must go through the respective MS’s NCPeH, functioning as a mediator and gateway for local infrastructure communication.

This high-level network infrastructure, involving multiple NCPeH, can adopt a private BC network for authentication, permissioned authorization, and a consortium model governed by deploying organizations [28]. Each NCPeH functions as a node, preserving ledger data in this decentralized network architecture. The CS, overseen by DG SANTE as the SP, should also participate as BC node in this network, governing new NCPeH entrance. Figure 4 illustrates an architectural design that showcases the incorporation of a private consortium-based BC for specific transactions.

Fig. 4
figure 4

Blockchain architecture to support eHDSI network

Full size image

Transactions without personal data are recorded on the BC ledger, crucial for auditing interactions among multiple parties. Each MS maintains existing databases alongside a newly integrated BC component for Trust Services, Data Discovery and Exchange Services, Data Transformation Services, Support Services, and Audit services. The SP retains MVC and MTC services in designated databases, utilizing the BC ledger to store non-sensitive data. The BC acts as a permanent tamper-proof repository, providing evidence of authenticity and non-repudiation while eliminating single points of failure. With only significant auditing-related incidents written on the ledger, the approach minimizes overhead. Detailed implementation for the Audit Trail Service using BC ledgers is explained in Sect. 4.1 for transparency.

4.1 Blockchain for transparency while ensuring interoperability

BC’s transparent and immutable ledger provides a comprehensive record of transactions and data exchanges within an ecosystem. SmC automate processes and uphold data sharing agreements, ensuring compatibility with interoperability standards.

The architectural design ensures an indisputable audit trail of transactions on the immutable ledger, devoid of personal information [29]. For the eHDSI network, each NCPeH, must maintain an Audit Trail Writer (ATW) creating an Audit Trail Log (ATL) for transparency. Auditing captures high-level events, while logging deals with lower-level activities, stored in an Audit Repository for retrieval [30]. NCPeH must provide electronic evidence for non-repudiation, ensuring the BC ledger, recording transactions unchangeably, serves as a source of verification, guaranteeing non-repudiation. We propose the system’s architecture design along with the necessary BC components for the abovementioned reasons in Fig. 5. The presented procedure outlines a simplified version of actions during PS retrieval by a HP. Some steps related to processing and additional audit logging are omitted for simplicity.

Fig. 5
figure 5

Blockchain architecture for audit trails logging in patient summary use case

Full size image

In this setup, each NCPeH operates as a node in the BC network, holding a copy of the shared BC ledger. A SmC on the BC network monitors the ATL of NCPeH. When a specific event, like a PS request, needs auditing, the SmC is activated after the event is recorded in the ATL, creating a duplicate in the BC’s ATL. The BC ATL, stored securely with immutability, includes timestamps and digital signatures for each transaction, following standard BC practices.

The combination of an unchangeable record and the digital signature from the respective NCPeH service ensures transparency, enabling authorized network users or services to view and verify the transaction. The digital signature guarantees non-repudiation of the executing service, and the transaction is permanently recorded on the BC ledger, ensuring data integrity. This design doesn’t impact cross-border data exchange or hinder interoperability, as BC records do not alter the evidence structure.

4.2 Blockchain for security in a centralized ecosystem

BC enhances security through cryptographic features and consensus mechanisms, reducing the risk of a single point of failure and enhancing data security [31]. Access control, encryption, and private/public key pairs are integrated into the BC architecture for added security.

In the highly centralized eHealth sector, certain processes, as detailed in Sect. 4.1, can be executed in a decentralized manner. For the ATL in the PS use case, privacy and security can be enhanced by encrypting the audit trail records on the BC ledger. Alternatively, a more secure approach involves storing only the cryptographic digest, a fixed-length string generated by a hash function, ensuring data integrity verification [32] for data integrity verification. The method presumes that the real data is stored in a separate location from the BC. It enables the submission of a data identifier and a corresponding hash of this data to the BC. Subsequently, at any point, it is possible to verify the authenticity of the actual data by comparing it with the hash stored on the BC. Additionally, specific implementations of private BCs, like Hyperledger Fabric (HLF), offer the option to establish distinct channels within the network, essentially forming subnetworks to restrict access to only specific participants in the network [33].

Consider a simplified private, consortium-based HLF BC network. Each country maintains a ledger copy, even if not interconnected on the eHealth network, allowing for shared data. Connected countries (e.g., Country 1 and 4) exchange sensitive cross-border health data through a private channel, managed by access control lists, ensuring restricted access [34]. Transactions within the private channel remain private, but anchoring records on the main shared ledger provide proof in case of disputes, simplifying evidence provision for dispute resolution while maintaining security and privacy. Countries 1 and 3 are not yet interconnected on the eHealth network, however, they both possess a copy of the main BC ledger.

In terms of security, the consensus mechanism ensures that all network participants or participants in a specific channel must reach an agreement on the validity of a transaction for it to be added to the ledger. If consensus is not achieved, the transaction is marked as invalid, maintaining the security and integrity of the BC network. Additionally, the presence of redundant ledger copies addresses the single point of failure issue, contributing to overall network resilience. Figure 6 illustrates the architectural layout of this BC solution.

Fig. 6
figure 6

Hyperledger Fabric Blockchain with private channel

Full size image

4.3 Blockchain for improving data quality and privacy protection

BC ensures data quality by providing a tamper-proof and auditable transaction history. Additionally, BC enables patients to manage their health data consent, ensuring that sensitive information is shared only with authorized entities. Data quality, in this context, refers to the degree to which data conforms to specified requirements, emphasizing measures such as accuracy, completeness, consistency, and validity within a dataset [35]. The BC’s ability to establish an auditable chain of interconnected blocks organized in a Merkle tree, in which each leaf value (representing a transaction) can be authenticated by comparing it to the known root, ensures data integrity [36].

The inherent immutability of the BC ledger provides a transparent historical record of all transactions in the network, ensuring verifiability and serving as evidence of data integrity. The consensus process confirms the structural integrity of each transaction, contributing to data consistency and validity. In terms of privacy protection, BC can implement authentication and authorization policies. In a private consortium-based setting, governance rules, such as unanimous decisions for network entry or specific organizations holding decision-making privileges, enhance privacy [37]. In the eHDSI network, the EU SP can be responsible for granting access to organizations meeting prerequisites, creating BC accounts linked to their NCPeH credentials, containing the digital certificate to use for digitally signing transactions [38]. Finally, within a HLF implementation, privacy protection can be further improved by utilizing private channels, as demonstrated in Sect. 4.2.

4.4 Blockchain and GDPR compliance in eHealth sector

A GDPR-compliant BC architecture should include data anonymization, user consent management, and mechanisms for data rectification and deletion. However, as mentioned, consent management, data anonymization, and portability fall beyond the scope of this study.

The GDPR poses challenges for businesses adopting BC technology, especially in relation to data protection, privacy, consent management, and data deletion/modification [39]. BC’s append-only ledger, once validated, prevents erasure or alteration, a challenge when individuals seek data control or updates due to inaccuracies.

To address GDPR compliance challenges with BC adoption, two approaches can be implemented. Firstly, personal data can be excluded from the ledger, and if necessary, stored in a separate off-chain database, using anchoring techniques for data integrity. A linkage for the hash that is stored on-chain can then be removed from the off-chain data, and this leads to a logical deletion of the data. Secondly, a consensus mechanism designed for block removal from the BC could be established, ensuring informed consent from each node or governing authority [40].

An alternative approach to ensure GDPR compliance involves storing data in an encrypted format on the ledger. However, this method is not recommended for personal or sensitive data due to the uncertainty surrounding the future security of encryption algorithms and the potential vulnerability of the data to decryption, as observed with previous encryption methods.

5 Discussion

Our research has limitations, focusing on network and service aspects of eHDSI’s cross-border health data exchange, excluding examination of processes between NCPeH and local infrastructures. This limitation does not compromise research quality within this network segment. Future studies should explore issues related to informed consent management, anonymization, and data portability. The adoption of BC in the eHDSI network may introduce additional overhead with increased cross-border transactions. Private BCs proposed in solutions may cause minor delays and impose additional costs on MS. Anticipation of new services under MyHealth@EU by 2027, including OrCD, laboratory results, and images, along with EHDS regulation, will pose challenges to eHealth network design and delivery as it, will necessitate even greater conformity with eHealth standards aimed at safeguarding and fortifying the security of sensitive eHealth data.

6 Conclusions

In conclusion, our study explores how BC enhances transparency in eHealth, offering an auditable record and automation through SmCs. The architectural design ensures secure data storage, non-repudiation, and maintains interoperability without impeding data exchange. BC enhances security in eHealth by leveraging cryptographic features, consensus mechanisms, and decentralized distribution. It contributes to data quality by providing a tamper-proof transaction history. In privacy protection, BC can enforce access policies in a consortium setting. GDPR compliance challenges involve reconciling BC’s immutability with rights like the right to be forgotten, suggesting solutions such as off-chain storage and consensus mechanisms. Our findings are applicable beyond eHealth to sectors with centralized structures, personal data, and cross-border data exchange needs, emphasizing BC’s practical value in real-world scenarios.