Interoperability for EU DSM: Implementation of CEF building blocks in the Smart4Health project - success stories and lessons learned

The Smart4Health project objective

The Smart4Health project, which was funded by the European Union’s Horizon 2020 research and innovation programme (grant agreement No. 826117), follows a truly multidisciplinary approach with a project team constituted by 18 beneficiaries from eight different European Union member states and the United States of America, including ICT developers, hospitals, social sciences researchers, physiotherapists, nurses, informal caregivers, regional government, research centres, universities and SMEs. The consortium (funded in period 2019-2023) aims at empowering EU Citizens with an interoperable European Electronic Health Record (EHR) exchange that supports EU citizens to manage and bridge their own health data throughout the EU and beyond, thereby advancing their own and societal health and wellbeing.

The key objective of Smart4Health is to place the citizen at the centre of decisions with regard to their own healthcare by enabling the possibility of sharing health data with different clinicians, healthcare facilities, local and international societies, for research activities as well as to engage directly with healthcare providers.

The S4H platform allows citizens to collect, store, manage, access and share their own health and healthcare data, through an easy-to-use, secure, constantly accessible and portable prototype; within the EU and beyond. Citizens are able to upload and share data with health care professionals in situations when reliable health information is essential to ensure efficient health care as well as with other persons of trust such as family members. Finally, citizens willing to support science can provide their data to the scientific community. Smart4Health will contribute to a positive impact on EU citizens’ health and wellbeing, for building today a healthier tomorrow.

The Smart4Health architecture

This section explains relevant aspects of the S4H software application that are needed to assess the feasibility of the integration of CEF DSIs. Figure 1 shows the system architecture. The S4H platform is divided into the Citizen Health Data Platform (CHDP) and the Research Platform (RP). The CHDP holds all citizen data in encrypted form. Only the citizen can access their own data, the platform provider only receives it in the backend in encrypted form, according to the privacy-by-design principle, which ensures data confidentiality and security. Together, the Citizen Health Data Platform and the Research Platform combine into the so-called 4HealthPlatform (backend). The 4HealthNavigator functions as user interface (frontend) to access the 4HealthPlatform. Details are available in D2.1 4HealthPlatform detailed prototype plan and specifications requirements report (Smart4Health Deliverables, 2019-2022). As a result, all operations on the citizen data happen on the client-side, e.g., in third-party apps. When citizens provide their health data for research purposes, it is de-identified via the MyScience app and stored in the RP, from which approved researchers can then access it. The CHDP includes a web application called User Portal, where the citizens can access basic functionality such as viewing, managing, sharing, and providing their health data to research. The connection between the User Portal and the CHDP is enabled by a software development kit (SDK) that takes care of the authorization and en-/decryption processes for external applications. The health data stored and transferred into CHDP follows the Fast Healthcare Interoperability Resources (FHIR) standard. Moreover, third-party apps can also connect to CHDP using the SDK, if they are registered by the platform provider and granted access by the user.

Figure 1. System architecture of the S4H software application.

Together, the two components Citizen Health Data Platform and the Research Platform combine into the so-called 4HealthPlatform, which is accessible to the user via the 4HealthNavigator (user-facing frontend).

Different healthcare and consumer health data sources can be connected to the CHDP, either through an ingestion pipeline, or through applications connected via the SDK. The data stored in the platform uses the FHIR standard, which requires preparatory steps such as data harmonization and quality validation.

In the process of providing data for research, the data is de-identified and converted to follow the OMOP Common Data Model specification. Subsequently, researchers can access the data using the Researcher Portal, which is also part of the RP. This enables them to conduct analytical queries as well as work on machine-learning algorithms. From there, data can be exported to external, 3^rd. party research infrastructures, as conducted in the project with ELIXIR.

The basic infrastructure of the CEF DSIs in the Smart4Health project

This section describes the basic infrastructure of the CEF DSIs and the current implementation in the Smart4Health project. We highlight the CEF DSIs that qualify for the inclusion into the S4H software application: eID, eSignature, eTranslation, eDelivery, and the patient Summary as part of the eHealth DSI. Each DSI section is separated into several subsections describing the CEF usage, implementation in its current status and an outlook. Another article, which covers parts of the preparatory work of this article, can be found on arxiv.org (doi: arXiv.2001.01477).

As Smart4Health is managing confidential information (medical and health-related data), secure data transfer as well as robust identification and authorisation functionalities are of utmost importance. This feature is especially relevant in a cross-border or pan-European setup. The Connecting Europe Facility programme funds different projects that implement Digital Service Infrastructures. More general DSIs, called CEF building blocks, such as eID and eTranslation, can be reused by other projects and larger DSIs, including eHealth. An overview of the possible CEF building block integration and their Smart4Health implementation is described in the following chapters and is shown in Figure 2.

Figure 2. Overview of possible CEF building block integration in Smart4Health.

The current implementations of eID and eTranslation are described in the following sections. Note that the 4HealthPlatform consists of the Citizen Health Data Platform and the Research Platform, whereas the 4HealthNavigator describes the user-interface of the S4H platform.

CEF building block eID

The CEF eID building block enables cross-border identification for EU citizens when accessing online services by using their national electronic identification (eID) schemes, such as smartcards (CEF Digital, 2020). EU citizens will be able to use their eID credentials to access digital public services in EU Member States that are different to their eID issuing country. The mutual recognition of national eID schemes across the EU is laid down in the eIDAS regulation. It defines aspects such as notifications, assurance levels, and a minimum data set, which are explained as follows.

The notification process monitors that national electronic identification schemes comply with certain criteria to ensure interoperability (Art. 9 eIDAS). The process roughly consists of pre-notification, peer-review, and notification. The notification of a national eID scheme is voluntary, however, only notified schemes need to be recognized by other Member States. Assurance levels refer to the “degree of confidence in the claimed or asserted identity of a person” (Art. 8(2) eIDAS). To be recognized by other Member States in cross-border identification, the assurance level needs to be substantial or high.

The Commission Implementing Regulation (EU) 2015/-1501 lays down technical and operational requirements of the interoperability framework. This ensures that the interoperability of the electronic identification schemes which Member States notify to the Commission are compliant with the eIDAS regulation. It defines a “minimum data set of person identification data, uniquely representing a natural or legal person, pursuant to Article 12(8) of the eIDAS Regulation”. For example, for a natural person, the mandatory attributes are current family name(s), current first name(s), date of birth and a unique identifier. Note that every citizen who is applying for an eID will have an own eID card and therefore a distinct unique identifier. The unique identifier is determined as “constructed by the sending Member State in accordance with the technical specifications [as set out in article 12 of regulation 2015/-1501] for the purposes of cross-border identification and which is as persistent as possible in time”. This is implemented differently by Member States, Germany for example creates a pseudonym that depends on the smartcard and the requesting Member State (for public-sector bodies) or the relying party (for non-public-sector bodies); other countries use tax codes or national personal identification codes.

The mutual recognition between member states is implemented by the decentralized eIDAS network that consists of eIDAS nodes. Every Member State needs to implement and maintain its own node. A node can receive and send eIDAS requests in a common format and translate between the national eID scheme and the eIDAS request.

Usage in Smart4Health

Within the Smart4Health project, the eID is integrated as an alternative authentication method to using email and password. In order to use this authentication method, an account must be created first, to which the eID may then be added.

Administrative prerequisites

From the administrative side, before starting the technical implementation, a certificate of authorisation was needed to be obtained by the responsible authorities. It was necessary to communicate internally applied measures and compliance for data protection matters, the intended eID information request (family name, name at birth, first name, date of birth, unique identifier), as well as a description of the intended use within the service planned.

The certificate in the context of the Smart4Health project was issued by the German Federal Office of Administration (Bundesverwaltungsamt). Subsequently, an eID service provider was contracted to establish the necessary technical eIDAS connection to the respective country nodes. As a part of the signed agreement, the service provider will not only provide the technical information needed to implement the infrastructure but also assists further with the handling of technical difficulties or occurring error messages.

Technical integration

For enabling the eID login, a split of the user authentication from the cryptographic operations needed for the en-/decryption of the users data, was necessary.

User interface

Users can connect their eID to their account via the account settings. The user chooses the issuing country of their e-ID and is subsequently directed to the correct national eID service provider portal, see Figure 3. After going through the steps to connect their eID with the external eID service provider, the user gets redirected to the S4H account settings. The eID status window now shows the successful eID connection to the account. Users can remove their eID, for instance to protect their account in case they lose their eID, or to replace it with a new eID in the future.

Figure 3. Smart4Health citizen registration: Country list to select the eID issuing country.

For the user authentication flow, the design was optimized by adding an eID sign-in option using a new button on the sign-in page. Anticipating that some people might not be familiar with the concept of eID, it was suggested to add a modal to offer some guidance. The modal appears after clicking “What’s e-ID?” and briefly explains what eID is, how eID could improve the experience for the user, and how the user could connect an eID to their account, see Figure 4. Once the user clicks “Sign in with e-ID”, they are led to an overview of supported countries (Figure 3). The procedure is then identical to the establishment of the eID account connection. After successful authentication via the external eID service provider portal, the user is redirected to the S4H overview screen, and has access to the usual functionalities.

Figure 4. Smart4Health citizen registration: Sign in option using eID with available additional information displayed.

Technical background

The technical integration is centred around the concept of eIDAS tokens. An eIDAS token is a document implementing the TR-03110 specification (BSI TR-03110 specification, 2021). Examples of such tokens are federal ID cards or electronic residence documents. The notion of eIDAS token and eID card will be used synonymously in this document. eIDAS tokens contain an RFID chip that stores encrypted data fields with holder’s data such as names, address, etc. It also offers to execute functions and return their results as if they were normal data fields. The German ID card, as an example, offers age verification, where during card initialization, a probe age (e.g., 18 years) is sent to the chip which will reply with either true or false, thus not revealing the actual birth date. Another function of the German ID card is the restricted ID. Given an application ID (called sector-specific ID in eID parlance), it uses hard-coded card data (like a serial number) to deterministically derive an application-specific pseudonym. The returned value will be the same whenever “reading” that pseudonym from the same card using the same sector-specific ID. This restricted ID is used in eIDAS as the unique identifier.

Specific design goals and decisions were applied to implement eID in Smart4Health. Firstly, the unique identifier is used as an alternative user ID. To re-recognize a user during login, only the eIDAS token needs to be re-recognized. Hence, the unique identifier from the eIDAS token needs to be read and associated with a user account as an alternative user ID. Second, the unique identifier is kept in the backend only. The decryption of the unique identifier its storing and checking are activities carried out by services in the backend of Citizen Health Data Platform (CHDP). Hence, there is no reason to transfer the unique identifier to the browser. Last, to encapsulate the integration component in an internal layer, the integration component, known as the eService, implements the eID/eIDAS protocol and is hosted in the backend.

Interaction flow

Once the user is in the web application, they have two options (use cases): (1) Signing in - while being in the WebAuthApp, or (2) Connecting an eID to the user account - while being in the account settings page. The user will be presented with a country list (country codes) from which they select the issuing country of their eID. Next, the Smart4Health platform generates a random value called a verifier and stores it in the app's secure storage.

The browser will then follow a sequence of HTTP redirects, during which the user will be asked to interact with a connected card reader device, a mobile phone app, or any other option, depending on the protocol of the respective country. In detail, this URL contains a challenge query parameter which is the SHA256 hash of the aforementioned verifier. The navigation to the liftoff URL leads to a sequence of HTTP GET redirects or HTTP POST bounces and eventually to either an “AusweisApp” popup or eIDAS interaction. If successful, the eID data (here: the encrypted unique identifier) will be sent to the eService as a SAML response from these HTTP GET or HTTP POST requests where the eService then decrypts and keeps the unique identifier for a predefined amount of time (currently two minutes).

Finally, the browser will re-enter the S4H app from where the user started and command the CHDP to retrieve the unique identifier from the eService to execute what the selected use case requires. For instance, issuing an access token for signing in or amending the user account for connecting an eID. The app sends the verifier to the CHDP which uses it to retrieve the corresponding unique identifier.

Current status and outlook

The technical integration has been successfully completed and rolled out to the productive system. Currently, 7 out of the 13 EU Member States supported by our service provider are successfully connected and available to S4H users (cf. Table 1). The service provider currently engages with the pending Member States in order to bring the pending Member States into our integration. As Austria is listed as a pre-notified member state since 27/09/2021, it is expected to be added soon.

The setup of this monitoring capability is currently still in progress as the events must be defined in detail and need to be technically implemented subsequently.

CEF building block eSignature

The eSignature CEF building block provides a sample implementation to create and validate electronic signatures. In the eIDAS regulation, three types of electronic signatures are defined. In this section, the differences between available electronic signatures are highlighted. Moreover, certificates, electronic signature creation devices and electronic seals are described.

First, a basic electronic signature is “data in electronic form which is attached to or logically associated with other data in electronic form, and which is used by the signatory to sign” (Article 3(10) eIDAS), while the signatory is a natural person (Article 3(9) eIDAS). This means, an electronic signature can simply be a name typed under an email or a checkbox clicked by a user. An advanced electronic signature “is uniquely linked to the signatory, capable of identifying the signatory created, using electronic signature creation data that the signatory can, with a high level of confidence, use under his sole control, and linked to the data signed therewith in such a way that any subsequent change in the data is detectable” (Article 26 eIDAS). This, for example, can be accomplished using a digital signature based on a certificate (see Figure 5 for details).

Figure 5. Overview of the creation and validation of a digital signature.

Alice wants to sign a document and send it to Bob. The data is signed by creating a hash, encrypting it with Alice’s private key, and attaching it to the document When Bob receives the signed data, he creates the hash himself and decrypts the signature using Alice’s public key, which usually is stored in a certificate. If both hashes match, the signature is valid; it means that Alice is the signer and the document was not changed (adapted from Digital Signature Generation, 2019).

The most powerful type of electronic signature is the qualified electronic signature that has “the equivalent legal effect of a handwritten signature” (Article 25(2) eIDAS). It is “an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures” (Article3(12) eIDAS). A certificate for electronic signatures is “an electronic attestation which links electronic signature validation data to a natural person and confirms at least the name or the pseudonym of that person” (Article 3(14) eIDAS). A qualified certificate for electronic signatures is “a certificate for electronic signatures, that is issued by a qualified trust service provider” (Article 3(15) eIDAS) and moreover, meets certain criteria laid down in the eIDAS regulation, such as that it contains “details of the beginning and end of the certificate’s period of validity” (Annex I eIDAS).

An electronic signature creation device is “configured software or hardware used to create an electronic signature”. To become a qualified electronic signature creation device, it must meet further requirements, such as to ensure that “the confidentiality of the electronic signature creation data used for electronic signature creation is reasonably assured” (Annex II eIDAS). The German eID smartcard, for example, is an electronic signature creation device that holds a qualified certificate for electronic signatures and is capable to create qualified signatures. Electronic seals follow similar regulations as electronic signatures but are applicable to legal persons instead of natural persons (available via the eSeal building block). Primarily, the type of certificate needed for a qualified electronic seal differs.

Usage in Smart4Health

Within the Smart4Health project, use cases such as signing informed consent forms or as proof of origin are conceivable. These use cases comprise data flow through the ingestion pipeline and are also applicable for data exchanges between health care professionals beyond Smart4Health.

First, eSignature can support the validation of signatures needed for the informed consent forms. To be able to use the different services within the Smart4Health program, the user or citizen needs to agree on different types of informed consent forms. Examples for these services are the platform usage consent or data donation consent in case health-related data is transferred from the citizen health data platform to the research platform.

Moreover, the use of eSignature as proof of origin for third parties in ingestion is possible. Assume, for example, that a health care provider (e.g., a hospital) shares a medical document. The provider can sign it digitally using eSeal to make sure that (1) the medical document was not changed after signing and (2) it was issued by this specific health care provider. Electronic seals follow similar regulations as electronic signatures but are applicable to legal persons instead of natural persons. Primarily, the type of certificate needed for a qualified electronic seal differs. This could be especially reasonable if the citizen that receives the document shares it with another health care provider, for example their general practitioner, that also might want to ensure the integrity and origin of the document. Currently, the Smart4Health architecture uses a registered SDK for data ingestion and encryption, with which the integrity and origin are always ensured.

Furthermore, eSignature could be used as proof of origin for professional user. In general, health care providers who are not part of Smart4Health, which means they are not connected through the ingestion pipeline, shall also be able to upload content for the user. To ensure data integrity and proof the origin of uploaded content, a digital signature could be used. Currently, this use case implementation is under consideration. We are aware that using eSignature can increase trust and facilitate the delivery of digital public services across borders. Therefore, this will be further investigated.

Implementation plan and status

As a first step, the consortium has asked for a legal opinion by Dierks&Co, which concludes:

Considering the eSignature pan-European context, discussions were carried out with the eID and eSignature development teams. Following this, it was communicated that the eSignature sample implementation Digital Signature Service (DSS) would need to be adapted to fit into the pan-European context. The consortium is closely monitoring the ongoing developments and pro-actively follow-up with the CEF development teams. As eSignature is building on eID and is currently not blocking the developments, we have focused on the realisation of eID as described before.

Considering that a basic electronic signature is sufficient for all Smart4Health-related use cases, we see the efforts and risks to implement eSignature will be too high, and currently resort to other methods such as ticking a checkbox, e.g., within the Authentication Service, D3.2 4HealthNavigator portal user sign-up, login, and record deletion, or signing with a handwritten, yet digital signature, e.g, within the Dynamic Consent Service, D3.3 4HealthNavigator: Dynamic Consent, and Sharing (Smart4Health Deliverables, 2019-2022). For the consent forms signed for the participation in the use cases, paper-based signatures are used.

CEF building block eTranslation

Providing a service to support translations in a multi-language user community is also the aim of the cross-border platform Smart4Health. The CEF eTranslation building block is a translation service based on neural machine translation. It was trained on the Euramis translation memories that include over one billion sentences in the 24 official EU languages, most originating from legislative documents. Therefore, eTranslation can translate between all these languages and is particularly suited for the needs of EU policy documents (Euramis eTranslation Documentation, 2022). An ongoing discussion with the responsible teams at the commission indicated a strong interest to broaden the text-corpus and to include medical terminology.

As an input, either plain text or formatted files in various formats (e.g., docx, pdf, html) can be provided. The service is accessible in two ways, either via a web-interface for human-to-machine use, or through an API for machine-to-machine use.

Usage in Smart4Health

In Smart4Health, eTranslation shall be used to translate medical content that is either not in the citizen’s preferred language or that should be shared with parties speaking other languages. In this way, the Smart4Health infrastructure supports and provides interoperability with cross-border health systems interactions. Additional to the translation of medical documents, the meaning of medical codes in structured data could be translated by eTranslation but generally they are already available in multiple languages.

The eTranslation component could be included in Smart4Health as a translation service, so that data sets can be translated into the needed language on demand. An example could be when a citizen gets injured in their vacation outside their country of origin. The citizen can provide the pre-existing health documents to the local health care professional in a foreign language. After the treatment, the citizen receives medical documents in a foreign language. Therefore, eTranslation could help to directly translate these documents from and into the mother language of the citizen.

Moreover, another use case is in the context of communication, training, and education to reach citizens, medical, research and ICT communities. A goal could be to translate direct communication, education and training materials that are developed in the Smart4Health context within WP6 Dissemination, Exploitation, Sustainability and Communication for tasks T6.1 Helpdesk and assistance hubs, T6.2 Massive Open Online Courses, T6.3 Training and education: User-targeted education, and T6.5 Communication and Visibility Plan (Smart4Health Deliverables, 2019-2022).

Technical integration and evaluation

This section describes the usage of CEF eTranslation as part of the project internal communication, the evaluation of it, and the envisioned architecture to include it in Smart4Health.

Project communication

The language is a big challenge when one wants to support and reach people in Europe. Therefore, Smart4Health is successfully using the eTranslation language tool (2021) provided by the Connecting Europe Facility (CEF). For instance, concerning the Helpdesk, eTranslation is used to enable a quick support of non-English speaking citizens during the project phase: it has been used successfully to translate enquiries from German and Portuguese into English. For now, Smart4Health curate the answers to citizens and the automatically generated template answers available in the internal knowledge base, provided by native speakers that are part of project consortium. The public knowledge base provides information in all supported languages (English, German, Portuguese, French, Italia, Dutch, Spanish) utilizing the eTranslation language tools to provide the information with an appropriate disclaimer. News posts on the website also make use of eTranslation for all supported languages using a disclaimer. The actual website content is currently curated with the consortium before taking it live due to the very specific domain language. For further information also see D6.14 2nd Training and education modules and events: education campaign (Smart4Health Deliverables, 2019-2022).

CEF eTranslation evaluation

To evaluate and compare CEF eTranslation to three other commonly used machine translation services in the biomedical context, a master’s thesis work was conducted at HPI. The other machine translation services are DeepL, Google Translate, and IBM Watson Language Translator. A publication of the results is planned but a short overview is given below.

Different biomedical corpora were identified that include the same text in different language pairs. According to a power analysis, a final corpus was assembled from the identified corpora. Sentence pairs presented in English-French, English-German, and English-Spanish were included, based on their availability in the identified corpora. Then, machine translation services were used to translate sentences from French, German, and Spanish to English. Based on their similarity to the expected English sentence, the translations were evaluated using established measures in Natural Language Processing. Finally, the similarity scores were statistically evaluated, accompanied by a human validation of the results. The evaluation pipeline is depicted in Figure 6.

Figure 6. Evaluation pipeline to compare different machine translation services.

Concerning the quality of translation, all the translation services performed well. Two translation services, DeepL and Google Translate, significantly outperformed the CEF eTranslation, but with small effect size. With respect to translation speed, CEF performed worst. This is probably due to its asynchronous implementation. However, when it is used as a service in Smart4Health, we assume that slightly higher response times are acceptable.

Regarding data protection and privacy, we consider CEF eTranslation the best of the four options, since it is being developed, deployed, and used in the environment of the European Commission. As of now, the identifiable health data needs to be sent to that environment, so S4H highly encourage CEF to provide on-premise solutions to minimize security and privacy concerns. CEF eTranslation supports PDF document translation, which is a valuable feature in the Smart4Health context. Therefore, CEF eTranslation appears as a reasonable choice to be used in Smart4Health project. Additionally, according to its documentation, eTranslation supports language detection of the source language, which would be another useful feature; however, it currently only available via the web service.

Embedding in Smart4Health architecture

Users can trigger translations directly from their smartphones using the Translation App. The decrypted health data is then sent to a separate backend service, the Translation Connector, which forwards it to the Translation Service, i.e., CEF eTranslation, receives the translation, and sends the translated data back (see Figure 7). A separate backend was implemented to (1) send the request and (2) abstract the translation service and make the asynchronous CEF eTranslation service flow usable for smartphones. However, it shall be noted that sending data to an external service violates the privacy-by-design principle and requires informed user consent. It is currently deployed in a secure on-premises environment at the HPI.

Figure 7. Embedding of eTranslation in the S4H architecture.

eTranslation App

The eTranslation App has the responsibility of moving health data between the CHDP and the Translation Connector. The translation workflow of the Translation App is shown in Figure 8. Users see a list of resources that are available for translation, select which ones should be translated and what the target language should be, and the app handles uploading, checking for results, and storing results in the CHDP automatically.

Figure 8. The Translation App translation workflow.

CEF eTranslation does not have language detection capabilities, nor could any automatic language detection be considered perfect, so another important function of the eTranslation App is to manage the original language of resources. New resources without existing language information are assumed to be in the language of the user's device, or, if that language is unsupported, English. Users may override this assumption for all resources or on a case-by-case basis.

After a resource is translated, the original language, whether it was inferred or set by the user, is embedded as FHIR extension data within the newly translated resource, along with other metadata. Downstream consumers, including the eTranslation App itself, can then understand that a resource was automatically translated between a pair of languages, and process it accordingly. In the case that a translation was done with an incorrect original language, or in the case that a resource was translated again with the same language pair, previous translated resources are updated with additional FHIR extension data marking them as “deprecated”.

CEF building block eDelivery

The CEF eDelivery building block works independently of a specific technical environment and defines the technical requirements for secure and reliable data exchange between different parties (eDelivery Documentation, 2022). It is based on encryption and digital signatures, and provides legal assurance that data is delivered once (and only once), even when the receiving party is temporarily unavailable.

The building block is structured in a so-called 4-corner model, where the communicating systems do not interact with each other directly but via Access Points that exchange data based on specific standardized protocols (eDelivery Access Points, 2019).

For all components, sample implementations exist. The software components are intended to be deployed as part of a backend setup on an application server with a dedicated database. Additionally, the CEF eDelivery Public Key Infrastructure service can be used to issue and manage digital certificates for signing and encrypting messages.

Usage in Smart4Health

Within the Smart4Health project, eDelivery can be used to perform data transfer from the Research Platform to ELIXIR-LU, from the Research Platform to researchers, and communication with eHealth National Contact Points. These uses cases will be described as follows: First, considering data transfer to ELIXIR-LU, the initial process for transferring data from the Research Platform will be manually transfers of dedicated data dumps. For an automation, eDelivery can be considered whereby the Smart4Health infrastructure would be connected to one access point and ELIXIR-LU to the other access point. However, after evaluating the use case of data provisioning from 4HP-RP to ELIXIR-LU’s platform, which is between two trusted services, we concluded that the eDelivery is not necessary for this process and would likely become an overhead.

Currently, researchers access data directly, which could be supported by the eDelivery CEF building block to directly transfer data from the Research Platform to researchers. Smart4Health have further examined that data should not be transferable to the researchers (e.g., via a download). Thus, further elaborations on secure measures concerning the data transfer are not necessary.

For the data transfer with eHealth National Contact Points, eDelivery could be of interest. Smart4Health assessed how data is transferred and how security of the data transfer is ensured. Moreover, whether eDelivery is a reasonable solution also depends on the architecture of national contact points (NCPs).

Implementation plan and status

Currently, Smart4Health project partners do not see useful scenarios to incorporate eDelivery in the S4H system. But a close monitoring of the ongoing developments will be made, plus pro-actively keep following-up with the CEF development teams, and further inspecting other use cases and scenarios.

Patient Summary as part of the eHealth DSI

The eHealth DSI (eHDSI) is being developed in an ongoing EU project and aims to provide services and infrastructures that enable cross-border healthcare facilities (CEF Digital, 2017). It is defined by two main use cases that are particularly of importance abroad: The Patient Summary that holds key health data of a patient, which supports health professionals in unplanned care encounters, and ePrescription that describes a process to enable digital prescription and dispensation from a health care provider to a patient. To ensure interoperability between countries, the eHDSI architecture consists of only few central services, including facilities for configuration and terminology. The focus lies on distributed services per Member State, in form of national contact points for eHealth (NCPeHs, in the following called NCPs). NCPs of different countries can exchange health data, such as Patient Summaries and ePrescriptions, on top of national data formats and schemes in a standardized way.

Due to the eHealth Digital Service Infrastructure both ePrescriptions and Patient Summaries can be exchanged between EU countries. Looking at the official website (European Union, 2021), the currently operational exchanges are visualised in Figure 9. It was found that

Figure 9. Currently possible ePrescription and Patient Summary cross-border exchange (European Union, 2021).

Background map from (Nations Online Project, 2021), own visualisation.

Usage in Smart4Health

In the context of Smart4Health, being a citizen-centred solution, the project is not addressing the actual ePrescription process but enables the inclusion of the incorporated data of this process to be available to citizens. Smart4Health incorporates the international patient summary, which contains medications, allergies and intolerances etc. This is well aligned with the efforts of the policy owner of the eHDSI, the eHealth Network (eHN). As reported in their 16^th annual meeting planned actions:

To clarify the difference between the process (ePrescription/Dispensation) and the incorporated data (medication plan) a renaming is documented in D7.5 1st Risk management, quality assurance and contingency strategy report (Smart4Health Deliverables, 2019-2022). More information regarding the international patient summary formats and their usage in Smart4Health is described in D3.4 4HealthNavigator User Portal (Smart4Health Deliverables, 2019-2022).

Implementation plan and status

The cross-border exchange of the international patient summary is central in the Smart4Health project and is directly addressed in the so-called Citizen Use Case 2. For this, Smart4Health is connecting the healthcare providers directly. How a connection to the eHDSI via the National Contact points could be established needs to be further discussed. The Smart4Health consortium partners have established the connection to the gematik GmbH on April 27^th, 2020, to establish a close collaboration and follow up on the developments of a German NCP. Also, UNINOVA has established links with SPMS for the Portuguese NCP. Smart4Health is also following closely the developments of the eHDSI, and the eHealth Network. An investigation on interoperability and status of the NCPs is provided in D6.20 (M36).