Journal:Emerging and established trends to support secure health information exchange

Full article title	Emerging and established trends to support secure health information exchange
Journal	Frontiers in Digital Health
Author(s)	Spanakis, Emmanouil G.; Sfakianakis, Stelios; Bonomi, Silvia; Ciccotelli, Claudio; Magalini, Sabina; Sakkalis, Vangelis
Author affiliation(s)	Foundation for Research and Technology, Sapienza Università di Roma, Fondazione Policlinico Universitario Agostino Gemelli
Primary contact	Email: spanakis at ics dot forth dot gr
Editors	Pattichis, Constantinos S.
Year published	2021
Volume and issue	3
Article #	636082
DOI	10.3389/fdgth.2021.636082
ISSN	2673-253X
Distribution license	Creative Commons Attribution 4.0 International
Website	https://www.frontiersin.org/articles/10.3389/fdgth.2021.636082/full
Download	https://www.frontiersin.org/articles/10.3389/fdgth.2021.636082/pdf (PDF)

Abstract

This work aims to provide information, guidelines, established practices and standards, and an extensive evaluation on new and promising technologies for the implementation of a secure information sharing platform for health-related data. We focus strictly on the technical aspects and specifically on the sharing of health information, studying innovative techniques for secure information sharing within the healthcare domain, and we describe our solution and evaluate the use of blockchain methodologically for integrating within our implementation. To do so, we analyze health information sharing within the concept of the PANACEA project, which facilitates the design, implementation, and deployment of a relevant platform. The research presented in this paper provides evidence and argumentation toward advanced and novel implementation strategies for a state-of-the-art information sharing environment; a description of high-level requirements for the national and cross-border transfer of data between different healthcare organizations; technologies to support the secure interconnectivity and trust between information technology (IT) systems participating in a data-sharing “community”; standards, guidelines, and interoperability specifications for implementing a common understanding and integration in the sharing of clinical information; and the use of cloud computing and prospectively more advanced technologies such as blockchain. The technologies described and the possible implementation approaches are presented in the design of an innovative secure information sharing platform in the healthcare domain.

Keywords: interoperability, health information exchange, eHealth, blockchain, security, patient consent

Introduction

Information technology (IT) has long been identified as a cornerstone for efficient, cost-saving, timely, and reliable healthcare delivery. The availability of healthcare information and patient records in digital form facilitates the persistence and posterity of valuable information and greatly supports the decision-making process, and even the extraction of new knowledge at both the individual and population levels. In our previous work, we have emphasized the current state of the art about cybersecurity in the healthcare domain, with emphasis on current threats and methodologies. Paraphrasing the famous words of John Donne, “no IT system is an island, entire of itself.” Today, in a highly connected world where geographic boundaries have been largely eliminated and people can freely move between cities, states, countries, or continents, the requirement for two different information management systems to exchange a person's clinical data or medical history becomes vital and persistent. Sharing health information (e.g., via health information exchange [HIE]) through electronic means greatly improves the cost, quality, and patient experience of healthcare delivery.

To better secure the IT system's potential for interconnectivity and cooperation with other systems, the use of interoperable technologies and standards is needed. Depending on the extent and scope of the envisaged shared information spaces, there may be different levels of interoperability. Figure 1 shows a proposed “maturity” model for interoperability in eHealth. The model consists of five levels that, incrementally, describe a more mature version of an interoperable infrastructure, starting from Level 1 for non-connected eHealth applications; Level 2 where a single eHealth application is directly linked to another application for simple data exchange; Level 3 for distributed systems that agree on protocols used, data formats, message exchange patterns, etc.; Level 4, where eHealth applications from different suppliers that serve a common goal are linked but the applications do not need to have common objectives; and finally, at the “universal” Level 5, where diverse eHealth applications connect to an open, interoperable infrastructure possibly spanning multiple countries.

Figure 1. A maturity model for interoperability in eHealth, adapted from Van Velsen et al. 2016.

Interoperability and data sharing in the healthcare domain is additionally challenging due to the multiplicity of the stakeholders, that is, the entities that operate (or are involved in any way) in this domain and which will be affected by any “disruption” or reform of the system. Some of the most important stakeholders or actors are therefore the following:

• the patients who are actually treated or, in general, are the recipients of the health services;
• the medical professionals (physicians and medical personnel) to provide the medical care;
• the healthcare organizations (HCOs) (healthcare providers) as represented by their board of directors, who actually administer the health delivery from a business perspective;
• the insurance companies that provide health coverage plans;
• the pharmaceutical companies that produce and market medications to be prescribed by physicians for the treatment of patients; and
• the governments and other regulatory parties who control, coordinate, and set the rules, rights, and obligations of any involved party.

All these actors could have an influence in the design of a data sharing system and can also set important—and conflicting in some cases—requirements. For example:

• Patients would like to have their medical record shared, but only after their approval and only with specific authorized personnel in specific circumstances.
• An HCO can be extremely cautious about sharing the data of their patients with another organization because they are concerned by the security and availability of their systems.
• Governments of E.U. member states can impose strict laws about the transfer of their citizens in cross-border healthcare treatment scenarios.
• Medical professionals require fast and effortless access to a patient's medical history in emergency situations, which cannot be the case if time-consuming authorization processes are the norm.

Given these and similar requirements, and even though the objective is to design a technical solution for the sharing of clinical data, it is imperative that all these constraints and requirements are considered and addressed in a satisfying manner.

From a strictly technical point of view, the sharing platform may need to be interoperable with a large number and diverse set of IT systems, each with their own protocols, data formats, etc. Some of the most important systems that manage patient-related data, and could be used as data sources for information sharing, include electronic health records (EHRs), personal health records (PHRs), laboratory information systems (LISs), and picture archiving and communication systems (PACS). EHRs are patient-centered systems that store and manage clinical information, such as a patient's medical history, diagnoses, medications, immunization dates, allergies, radiology images, and lab and test results. They are managed by authorized personnel, usually in the context of a single HCO, although they can span beyond that. PHRs are electronic applications that are used by people managing their own health information in a private and confidential environment. They are simpler systems than EHRs, and in some cases, they can be connected (temporarily or otherwise) to more enterprise-level HCO systems (e.g., EHRs or other hospital information systems). An LIS is used inside hospitals and clinics to record, manage, and store data for clinical laboratories in a patient-centric way (e.g., sending laboratory test orders to lab instruments, tracking those orders, and then recording the results in a searchable database). And PACS are systems used in a clinical setting for the storage and convenient access to medical images from multiple modalities (source machine types). Digital Imaging and Communications in Medicine (DICOM) is the standard format and suite of protocols for the storage and transfer of images from PACS services. Of course, in a health ecosystem there may be additional systems, for example, for the management of insurance claims and for clinidal diagnoses (e.g., clinical decision support systems [CDSSs]).

In the general context, information sharing involves more than one party (healthcare providers, organizations, etc.,) that need to cooperate and agree on the way the exchange of information happens, and what the rules and policies are that govern it. Interoperability involves many different aspects, such as legislation and guidelines, contracts, and agreements between exchanging parties, governance and maintenance, shareable workflows, standardized data elements, semantic and syntactic choices, applications, technical infrastructure, and safety and privacy issues. The Refined eHealth European Interoperability Framework (EIF) is a set of recommendations that specify the standards, protocols, procedures, and policies that when deployed can improve the interoperability of eHealth applications within the E.U. and across its member states by providing specific recommendations for all these aspects. Figure 2 depicts how these aspects can be represented in interoperability “levels” that permit two different organizations to communicate.

Figure 2. Alignment of interoperability levels between two communicating organizations.

This framework provides a great overview of the needed “glue” so that two or more healthcare environments can collaborate and serve as a common, multilevel, and multi-perspective model on the interoperability requirements. The six different levels of the (refined) EIF are:

• Legal and regulatory: This level represents the legislation and regulatory guidelines that define the boundaries for interoperability not only across borders, but also within a country or region.
• Policy: This level represents the contracts and agreements between the sharing organizations so that trust is established and responsibilities are assigned.
• Care process: This level represents the shared workflows that define how the integrated care is delivered and how these workflows are managed.
• Information: This level defines the data models, the concepts and their values, the terminologies, and controlled vocabularies that cater for the common understanding of the exchanged electronic messages.
• Applications: This level defines how the data are extracted from and imported to the healthcare information systems and how the transport of the data takes place using health-specific technologies and standards.
• IT infrastructure: This level represents the lowest level and corresponds to general-purpose communication and network protocols.

This generic EIF is highly relevant for the use cases of the health information sharing since sharing is greatly facilitated between interoperable systems and organizations. Here, we focus on the sharing of health-related information across HCOs and even across countries and continents. This is an important use case to improve the secure and efficient delivery of health care across Europe. The importance of cross-border health care in Europe has been recognized since 2011's Directive 2011/24/EU, which established patients' rights to access safe and high-quality healthcare, including across national borders within the E.U., and their right to be reimbursed for such healthcare. As can be deduced by considering the Refined eHealth EIF (Figure 2), the cross-border sharing of clinical information is a complex scenario due to the fact that data need to be transferred between different countries and therefore, requires overcoming barriers such as establishing a common trust framework, uniquely identifying citizens, and translating between different schemas and terminologies. This paper presents current approaches to address most of these issues in the European context while presenting and evaluating emerging technologies such as blockchain that have been in the limelight recently. Our objective is to take advantage of both well-established and novel technologies that complement each other in order to design an architecture for the secure exchange of clinical information in the European context.

Materials and methods

Current status on standards-based health data exchange

In the healthcare industry, large standards developing organizations have defined numerous standards, data formats, terminologies, and more in order to support the design and building of interoperable IT systems. Perhaps the most well-known and most important standards are the ones introduced by Health Level 7 (HL7) and SNOMED CT, which can be used as a foundation for the development of data exchange standards among eHealth systems. Two more standards organizations are Integrating the Health Enterprise (IHE), which focuses primarily on integration and interoperability, and the Clinical Data Interchange Standards Consortium (CDISC). CDISC produced the Operational Data Model (ODM) to “facilitate the regulatory-compliant acquisition, archive, and interchange of metadata and data for clinical research studies.” ODM is an XML-based format that provides a number of constructs for modeling electronic case report forms (CRFs) and can also be used in sending forms data from a clinical trial system to an EHR system. In the area of medical devices, the Continua Health Alliance, a non-profit, open-industry coalition of healthcare and technology companies working to establish a system of interoperable personal health solutions, develops an ecosystem of connected technologies, devices, and services that will enable the more efficient exchange of fitness, health, and wellness information. Among its proposed standards, Continua proposes specifications and standards such as Bluetooth, USB, ISO/IEEE 11073 (for medical devices), and HL7 to enable patients to use home-based devices to monitor their weight, blood pressure, and glucose and blood oxygen levels, as well as to share these data with their healthcare professionals.

The exchanged information can be in multiple data formats based on the type of data, device category, etc. Some of the most common formats based on the health applications using them are the following:

• For medical imaging, the use of DICOM is almost universal and defines not only the content (DICOM file format) but also communication protocols for the exchange of medical images.
• In the area of DNA sequencing and other -omics data formats, we have FASTQ file format, which is used to store sequence information, and the standard flowgram format (SFF), which is used to encode sequence reads.
• The majority of the EHR systems adopt the HL7 standard clinical document architecture (CDA) as the interoperable data format. CDA is part of the HL7 Version 3 family, and it is based on a reference information model (RIM) that serves as a semantic model that consists of a set of structural components (e.g., classes with data types) and semantic relations that are used to represent clinical notes in the form of an extensible markup language document.

The use of controlled vocabularies and terminologies allows for the unambiguous representation of important value sets such as "diagnosis" and "prescribed medicines." The following are examples of such terminologies:

• The International Classification of Diseases (ICD) provides a common language for reporting and monitoring diseases, used throughout the world to compare and share data in a consistent standard way between hospitals, regions, and countries and over periods of time. It is used to classify diseases and other problems for payment, management, and research, as recorded on many types of health records including medical records and death certificates. ICD-11 is the latest version of it, whereas ICD-10 (released in 1993) remains widely used.
• SNOMED CT, already mentioned above, is the most comprehensive multilingual clinical healthcare terminology available. It is used in EHR systems to facilitate clinical documentation and reporting and to retrieve and analyze clinical data. SNOMED CT is both a coding scheme, identifying concepts and terms, and a multidimensional classification, enabling concepts to be related to each other, grouped, and analyzed according to different criteria.
• Logical Observation Identifiers Names and Codes (LOINC) provides a set of universal identifiers for medical laboratory observations. LOINC provides codes for the observation names (e.g., eye color), not the observation finding (e.g., blue eyes). LOINC therefore provides codes for questions, and where needed, other vocabularies, such as SNOMED CT, provide codes for the answers.
• The Unified Medical Language System (UMLS) is an important terminology resource, intended for use mainly by developers of health information systems. The UMLS “Metathesaurus” uses several different source vocabularies and seeks to reflect and preserve the meanings of concept names and relationships from these sources. It is therefore a valuable resource for the translation between the different source vocabularies.

Application-level interfaces are also needed to support the communication and exchange of the standards-based encoded information. The role of HL7 is principal on this front: HL7's name comes from “Level Seven,” which, according to the Open Systems Interconnection (OSI) model that standardizes communication functionality in IT, corresponds to application layer. From its establishment in the late 1980s, HL7 was therefore focused on exchanging information within hospitals. The focus remains almost the same today, but HL7 has progressed from different paradigms over the years, in order to describe the structure, semantics, and management of the exchanged information. The development of HL7 Version 3 (HL7v3) started around 1995 in order to introduce more consistency between the implementations of Version 2 following an object-oriented development methodology. The most recent proposal by HL7 is Fast Healthcare Interoperability Resources (FHIR), which leverages web technologies to overcome the complexity of HL7v3.

On the other hand, the IHE initiative has defined a number of “integration profiles,” which are detailed specifications for communication among systems to address key clinical use cases, all based on established standards. IHE profiles organize and leverage the integration capabilities that can be achieved by coordinated implementation of communication standards, such as DICOM, HL7, W3C, and other security standards. Some of the IHE integration profiles that might be interesting in the context of interfacing health information systems and sharing of clinical information include:

• Cross-Enterprise Document Sharing (XDS): Allows EHR documents to be shared and discovered among healthcare enterprises, physician offices, clinics, acute care in-patient facilities, and PHRs.
• Patient Demographics Query (PDQ): Enables applications to query by patient demographics (e.g., name) for patient identity from a central patient information server.
• Patient Identifier Cross Referencing (PIX): Allows applications to query for patient identity cross-references between hospitals, sites, HIE networks, etc.
• PDQ HL7 v3 (PDQv3): Extends the PDQ profile leveraging HL7 Version 3.
• PIX: Extends the Patient Identifier Cross-Reference profile leveraging HL7 Version 3.
• Cross-Community Access (XCA): Allows the query and retrieval of patients' EHRs held by other communities.
• Cross-Enterprise Document Reliable Interchange (XDR): Exchanges health documents between health enterprises using a web service-based point-to-point push network communication.

There are two main architectural approaches for the implementation of an information sharing platform: a centralized approach and a federated approach. In the centralized approach, a central data warehouse and accompanying services act as middlemen for the exchange of information and a single source of patient data that are shared among the participating organizations. On the other hand, in the federated architecture, a central infrastructure is also in place, but in this case, it merely acts as a facilitator for locating the data sources. An example of this case would be a common registry that stores only the links to the original patient records, medical images, and other types of data while the linked data are not transferred outside their primary premises unless explicitly requested by any interested client system. In addition to these opposite approaches for designing a distributed information sharing platform, there are also various hybrid options, such as using messaging with “publish-subscribe” communication that can be introduced to complement either the centralized or federated architectures.

There are advantages and disadvantages in all of the abovementioned deployment options. For example, in the federated approach, there are more strong concerns about the privacy, security, and availability of the data shared and their original sources. The operation of a mission-critical radiology information system (RIS) in a hospital can be severely affected if multiple peers request DICOM images from its PACS, and this poses an additional burden and cost for the acquisition and management of adequate infrastructure in the source organization. Instead, a centralized strategy allows for easy access to the whole information shared but also leads to a concentration of the costs for maintaining the infrastructure needed and can be problematic at the operation level (a “single point of failure”). Furthermore, there are more costs on integrating the different data sets under a common “schema,” resolving conflicts or even supporting the timely update of the persisted information when a source system acquires new or modified data.

Emerging supportive technologies: Blockchain

Blockchain is a decentralized, distributed data structure used to store transactions (aggregated in blocks) across many computers. Blockchain has been extensively used for Bitcoin. In the realm of healthcare, we have seen Kuo et al. perform a systematic review on how blockchain can be used in healthcare applications. Blockchain core is the embedded distributed ledger technology able to support data integrity, authenticity, and origin. In blockchain, each block is linked to the previous one through a cryptographic hash, and each block is a data structure that allows the storage of a list of transactions. In the blockchain, a transaction abstracts and allows the tracking of an exchange or interaction between two entities. Transactions are created and exchanged by peers of the blockchain network and modify the state of the blockchain data structure. An efficient categorization and comprehensive overview of the latest privacy-preserving mechanisms and policies regarding smart electric grids, focusing on the use of the blockchain technology and the multi-authority access control paradigm, is offered by Triantafyllou et al. and Radoglou et al.

Concerning data access, we can have the following:

• Public blockchain: There are no restrictions on reading blockchain data and submitting transactions for inclusion into the blockchain.
• Private blockchain: Direct access to blockchain data and submitting transactions is limited to a predefined list of entities.

Concerning data management, we can have the following:

• Permissioned blockchain: Transaction processing is performed by a predefined list of peers with known identities.
• Permissionless blockchain: No restrictions on identities of transaction processors (i.e., blocks creators).

Combining the two perspectives, we can have four categories, as depicted in Figure 3.

Figure 3. Blockchain classification overview.

Blockchain supports auditability and transparency, as any reader is able to verify the correctness of the state of the system. Indeed, by storing all the transactions, it is possible to replay (starting from a correct checkpoint) the entire history and check that the current state is consistent with the set of recorded transactions. It is important to note that, when using a blockchain to store data, there exists an inherent tradeoff between transparency and privacy. Indeed, if the primary requirement is to have a fully transparent system, we need to accept that anyone is allowed to see any piece of information (sacrificing privacy). Conversely, if the primary requirement is to have a private system, it will not provide transparency. A tradeoff between transparency and privacy is however possible, but it will come at the cost of efficiency, as it would require employing complex cryptographic primitives.

Results and discussion

A novel view on information sharing

Nowadays, the sharing of a patient's clinical information between two HCOs (e.g., hospitals) usually requires a great amount of manual work in order to check and validate patient's consent (by consulting signed papers) or, at worst, results in privacy loss by extending the trust circle, e.g., to all physicians from the requesting organization. The main limitation of the current sharing pattern can be summarized in the following way:

1. Sharing medical data may require time and possibly multiple interactions, also involving the patient in the loop.
2. Sharing medical data is currently a physical point-to-point interaction. If the same set of data needs to be shared with multiple parties, it would require multiple sharing patterns to be in place.
3. Sharing is currently asymmetric. Organization A may have the consent to share patient's data with organization B, but the inverse may not be true.

In order to overcome these deficiencies, we aim to design a platform—the Innovative Secure Information Sharing Platform (InSISP)—that is able to support a fast and efficient medical information sharing at both national and cross-national levels, taking into account sharing constraints, including those imposed by the General Data Protection Regulation (GDPR). It is imperative that patient's consent is central in this framework, and one of the challenges is to make the consent management robust, simple, and secure. A sequence diagram of the possible interactions to support the data sharing is shown in Figure 4.

Figure 4. InSISP sharing pattern for medical data.

From an abstract point of view, InSISP can be seen as a data repository that can be accessed by HCOs (i.e., clients) to store and retrieve shared data by using a common interface and format (e.g., CDA Release 2 using standard vocabularies such as SNOMED and LOINC). The shared data repository is surrounded by a federation of collaborating entities (organizations/clients) that is dynamic and evolving. Once the federation is established, participating entities can start sharing data according to the data processing consent provided by patients. To this aim, we can identify two additional functionalities: (i) data sharing and (ii) data processing consent management. Figure 5 summarizes a possible decomposition of the InSISP and highlights the three storage components.

Figure 5. InSISP functional decomposition.

Federation management

The federation management functionality has the aim to manage the federation life cycle, and in particular, it should allow new HCOs to join and HCOs no longer interested in participating in the federation to leave. In particular, this functionality supports the following operations:

1. Join the federation: HCOs should be able to become part of the federation at any time. When considering a membership service, all the members are assumed to be uniquely identified. So from the perspective of the InSISP development, there should be an external service that is able to support the identification of members and to provide them with a digital identity.
2. Leave the federation: HCOs may decide to leave the federation at their will, and the InSISP should support the removal of the entity from the membership and should notify the end of the sharing to connected entities.
3. Get the federation membership: Allows an HCO participating in the federation to get the current membership and know the set of HCOs potentially involved in the sharing, including their identification, public keys, and the categories of data that are currently available for the sharing.

Federation management intrinsically relies on the execution of a distributed protocol running, and thus, there are two main options to implement a federation membership service: (i) client/server or (ii) peer to peer. In the client/server case, the current membership of the system is maintained by a trusted third party (TTP). When a new HCO wants to join the federation, it simply needs to contact the TTP and identify and authenticate itself with the TTP that will proceed by adding it to the current view. Similarly, when an HCO in the federation wants to leave, it simply needs to notify the TTP that will remove it from the current view. The current membership can be obtained again by querying the TTP. The main advantage of this option is that all the complexities of the membership management are delegated to the TTP. However, this also implies that the TTP is clearly a single point of failure for the system as well as its main bottleneck. In the peer-to-peer approach, HCOs collaborate to maintain a consistent view of the system by exchanging messages and trying to reach a consensus on the sequence of views generated to include new members and to remove old ones.

Chockler et al. discussed in detail the formalization and the specification of the group membership service, while more recently, Aguilera et al. considered the problem of building a reconfiguration service to support the development of a distributed shared storage. However, let us note that in all these cases, the emphasis is on how to provide a consistent view to all the members. To the best of our knowledge, there does not exist any approach investigating the cost of realizing a membership service using blockchain technologies.

The main advantage of the peer-to-peer approach is its intrinsic resilience. In addition, in peer-to-peer settings, it is also possible to consider a blockchain-based approach to construct the sequence of consistent views providing the "view auditability" property for free. The main drawback is the cost imposed by the management of consistent views, as it requires to run coordination and synchronization protocols among all the participants that would bring poor scalability in case of a highly dynamic federation.

Data processing consent management

The data processing consent management function has the aim to support the development of a digital data processing activity registry to store and access patients' data processing consent. The data processing consent is granted by a patient for a specific set of data to a specific set of entities and for a specific purpose and period of time. In order to support the automatic verification of patients' consent, such information must be stored and managed by the HCO in an electronic form (e-Consent). Also, every patient has the right to modify their consent and has the right to be forgotten; i.e., at any point in time, they may ask to revoke all their previous consent (while also erasing any data identifying them).

To this aim, the data processing consent management functionality should offer the following operations:

1. Provide new consent: It should allow the addition of a new entry to the table, specification of the beneficiary entities, and seting of the expiration time of the consent.
2. Update consent: It should allow the modification of existing consent by allowing sharing with a new beneficiary or by removing a beneficiary.
3. Remove (all) consent: It should basically implement the right to be forgotten by deleting all the consent previously provided by a specific patient.

Discussion about possible design and deployment options

Let us note that the data processing consent management function supports every HCO in managing its own data processing activity registry. Thus, from this point of view, we can say that it is local to every HCO.

As a consequence, the most appropriate choice is to design it as a local data store managed and accessed only by one HCO. Of course, in order to increase the resiliency and security of the storage, it can be also replicated, but all the replicas will still be managed by the same HCO.

However, a distributed design raises a privacy issue in patients' information. Indeed, even if data in the registry are not sensible by themselves, they could be easily correlated to infer sensitive information about patients and would result in a privacy violation; e.g., by looking to the list of HCOs where Bob did his analysis, you may infer that Bob is affected by a specific disease. To solve this issue, it is necessary to employ anonymization scheme generation, an extra cost without any particular advantage in terms of reliability or security.

Data sharing management

Data sharing is the core functionality of the InSISP, as it manages the real transfer of medical data between parties. It offers just one main operation, i.e., Get Data, which is used to retrieve a specific piece of data for a specific patient and transfer it according with the patient's consent.

We can consider three main options to design and deploy this functionality: client/server, peer-to-peer with message exchanges, and peer-to-peer with shared memories. In the client/server case, data available for sharing are copied and pushed toward a centralized TTP that will take care of satisfying the sharing request. In order to be GDPR-compliant, a specific consent to move data to the TTP must be signed, as well as the consent to share data with all the federation members. (Let us note that this second set of consent could be removed if every HCO provides the TTP a copy of its data processing activity registry. However, as mentioned above, this would add the complexity of finding a good anonymization scheme that allows to preserve patients' privacy still allowing the TTP to check consent.) Figure 6 shows an overview of a possible client/server design.

Figure 6. Overview of the client/server design with a trusted third party (TTP).

In the peer-to-peer case, the idea is that the sharing is realized by letting HCOs in the federation cooperate with each other. We can distinguish two cases: cooperation realized through message exchange and cooperation realized through shared memory.

In the message exchange case, the sharing is realized using an ad hoc request–reply communication pattern, as shown in Figure 7.

Figure 7. Overview of the peer to peer with message exchange design.

In the peer to peer with shared memory design (Figure 8), each HCO creates a shared memory space where it stores all the pieces of data that can be shared according to the data processing activity registry. As an example, let us consider the case where Bob provided the consent to HCO₁ to share his X-ray images with HCO₂. This means that HCO₁ and HCO₂ create locally a shared space where they will store a copy of all Bob's X-ray images (the red slice in Figure 8).

Figure 8. Overview of the peer to peer with shared memory design.

Discussion about possible design and deployment options

Technically, all the three considered designs are feasible. However, as anticipated in the previous section, the client/server scenario poses several challenges from the point of view of the consent needed in order to make it compliant. In particular, the main issue is the large set of consent data that is necessary, and that patients may be reluctant to provide consent in the first place. Instead, the two point-to-point designs solve this issue, as they exploit locally the consent information and move data only toward authorized HCOs.

Summary of recommendations

According to the considerations discussed in the previous sections, Table 1 summarizes the viable options for the design of each functionality of the InSISP.

Table 1. Summary of design options and recommendations.

Evaluation of emerging technical solutions: Blockchain

In order to evaluate if blockchain is a valid option to support the InSISP deployment, the methodology presented by Staderinin et al. has us considering the following three steps:

1. Perform a requirements analysis to assess blockchain benefits.
2. Evaluate the most appropriate blockchain solution where the designer is guided on the choice of the most suitable blockchain category, based on blockchain-specific criteria, depending on who are readers and writers of the data and who is allowed to generate data.
3. Select the blockchain configuration, which assists the designer throughout the decision-making process for the configuration of the blockchain compliantly with the chosen category and the given project requirements.

Let us remark that blockchain is intrinsically a distributed system, and it makes no sense trying to use it when a distributed setting is not appropriate, which means that it can be used for the federation membership and for the data sharing functionalities of InSISP. In the following, we will evaluate the suitability of blockchain-based solution by adoption of the methodology described by Aguilera et al.

In fact, trying to evaluate the blockchain technologies for the data sharing scenarios and design solutions described above, the first step is the analysis of requirements related to the component under analysis in order to understand the benefit of adopting a blockchain-based solution for its low-level design and development. The factors that are considered in this step include:

• Data or state storage: The first element to consider is to check if the module under analysis needs to store data or system states. If no information needs to be stored, clearly no blockchain is needed.
• Immutability and data integrity: With immutability, we refer to the property of a piece of data to never change (i.e., a constant value that is never updated). If immutability is a requirement, then blockchain is certainly an option, as this is probably the most distinctive property of any blockchain. Integrity is strictly related to immutability, and this is why they are analyzed together, also considering that they are both closely related to cryptography. If a component requires data protection from unauthorized modifications, then this requirement can be met with blockchain.
• Non-repudiation: Non-repudiation means that the author of some message/data cannot deny that it produced the message. This is another fundamental property that can be easily satisfied using blockchains.
• Multiple writers. This criterion considers the multiplicity of entities in charge of writing data in the storage. If only one entity is a writer, then a common database is probably more appropriate than a blockchain, especially from the performance perspective, i.e., in terms of throughput and latency.
• TTP always online: A TTP is an entity that facilitates interactions between mutually mistrusting entities. If in the system a TTP is required and it is planned to be always online, entities can delegate write operations to it as transactions, or as state changes. Therefore, the TTP plays the role of a trusted deliverer and verifier. In this case, a blockchain, known for being a trustless technology, becomes useless, and the methodology brings to the related output. Otherwise, it can happen that the involvement of a TTP is planned but not for being always online: in this case, it could play the role of an authority giving authorizations for permissioned blockchains. Alternatively, a TTP may not exist at all. In the latter situations, it is not possible to exclude the recommendation of using a blockchain.
• Writers are known and trusted If all the entities interested in writing know and mutually trust each other, a blockchain is superfluous and not recommended (again mainly for performance issues).

The flowchart of this analysis step is shown in Figure 9. Tables 2 and 3 then answer the relevant questions for the assessment of blockchain in the federation management and data sharing operations according to the decision flowchart in Figure 9.

Figure 9. Flowchart: blockchain, yes or no? adapted from Staderini et al. 2018.

Table 2. Assessment of blockchain in the federation management..

Table 3. Assessment of blockchain for data sharing operations.

Going back to the maturity model flowchart in Figure 1, we at first glance may be led to believe that blockchain is not recommended to support the implementation of the federation membership mainly because there exists a basic level of trust between members of the federation. In addition, we may be led to assume that the federation membership is also relying on a trusted external service providing digital and secure identities to participants. However, we must highlight the opportunity to consider a non-repudiation requirement; as such, we considered the importance of preserving data integrity (i.e., to ensure that the current membership cannot be altered). Thus, if these two requirements become more relevant or if assumptions on the identity platform or about trustworthiness of participant cannot be met, then blockchain immediately becomes a viable solution.

Using the same process, at first, we are led to believe that blockchain is recommended to support the implementation of data sharing mainly because it would efficiently support the data integrity requirement, i.e., it allows the traceability of data accesses and verifies their authorship and integrity. However, we should keep in mind that medical data are mostly read-only, and in our context, they are shared between trusted parties. Thus, the main benefit we can get by adopting a blockchain-based solution is the support for data integrity verification and data auditability. Yet even still, this feature must be carefully balanced with the “right to be forgotten” requirement (i.e., a MUST requirement imposed by the GDPR regulation) and its implication on the adoption of a blockchain-based solution. In order to support the implementation of the “right to be forgotten,” we need to guarantee that data can be deleted from the blockchain when the data owner asks for it to be done. Currently, deleting data efficiently from a blockchain is still an open research problem, and the few existing solutions are currently based on the adoption of computationally expensive cryptographic techniques. Furthermore, when dealing with medical data, there is also the additional complexity following the huge heterogeneity of data to be considered (i.e., text, images, and images/sounds). Blockchain technologies have been originally designed to deal with transactional data, of small size and in the form of numbers or strings. Currently, it is not clear how to extend the paradigm to work with heterogeneous data. A possible solution to this issue could be to keep such heterogeneous medical data stored locally in a classical database and store in the blockchain only its hash. However, it is still not clear how much privacy lawyers consider such metadata as an expression of a personal data, and thus, the issue may remain.

Conclusions

Information sharing in the health domain is a complex and challenging process given the many stakeholders involved, the different and sometimes competing standards and solutions to choose from, and the important security, ethics, and regulation-related constraints for any proposed solution to comply with any "security as a service" attempts, e.g., as outlined by Markakis et al. HIE is a key building block for the realization of Connected Health in Europe, which “speaks to the health journey of the person, through the entire lifespan, leveraging a variety of technologies to do so.” Based on what we've discussed in this work, it is important to consider the following aspects when building a new platform for sharing medical information:

• Patient consent is of utmost importance, and infrastructure should be in place for its registration, enforcement, and withdrawal.
• Compliance with GDPR and national laws is vital, as is implementing solutions to address significant requirements, such as the “right to erasure.”
• Effective interoperable solutions are produced by linking and integrating with well-established standards such as document and data formats (e.g., CDA and DICOM) and metadata and value lists (e.g., SNOMED and LOINC) in order to support common understanding and integration.
• Such solutions should be able to andle the whole security spectrum, including authentication and authorization of users, as well as support for data privacy, audits for “post-mortem” analysis and non-repudiation, data integrity, and machine-enforced trust among the sharing organizations.
• Such solutions will also enable the unique identification of patients while at the same time exposing the minimal set of personal information in order to protect their privacy.
• Performance, scalability, and availability of the whole platform should be high in order to support the health-related processes efficiently.
• The solution should be part of the healthcare ecosystem, which means allowing easy integration with existing infrastructure by featuring interoperable “ports and adapters” interfaces.

Additionally, the IHE profiles should not be neglected. In the 2015/1302 Commission Decision, after consulting the European multistakeholder platform on information and communications technology (ICT) standardization and sectoral experts, 27 IHE profiles have been identified for referencing in public procurement, such as XDS, XDS-I, PIX, and PDQ.

Cloud computing is now used everywhere and provides an important set of features, such as, adaptive scalability, performance, and benefits from the business perspective. In particular, the sharing of clinical information in the cloud can be very advantageous, especially in cases where central repositories or central coordination are needed. But organizations should also be wary about the data protection, privacy, and access control mechanisms that should be in place, either offered by the cloud provider or built in-house, in order to properly handle sensitive data and comply with regulations such as GDPR.

Blockchain is a highly interesting technology that can be put to good use in information sharing, more specifically for supporting decentralization, data integrity verification, and data auditability. These inherent features of blockchain have been praised and discussed in the context of healthcare as valuable tools. Nevertheless, there are some major issues to be resolved, such as the compliance with GDPR's “right to be forgotten” requirement, which, unless the blockchain implementation is adapted, requires the deletion of data from the blockchain when the data owner asks to do it, which is not feasible, by design, in the “traditional” blockchain implementations. Furthermore, there is also the additional complexity followed by the huge heterogeneity of medical data (i.e., text and images) that do not fit exactly to the original design of blockchain. It is evident that such requirements imposed by GDPR and the application domain present challenges and introduce additional trade-offs related to the management of data, administration, and overall governance. For example, storing the health data “off-chain” (i.e., external to the blockchain network) and only metadata “on-chain” may introduce problems of availability, performance, data protection, and integrity. Therefore, careful considerations of the available options should be made before committing to such cutting-edge technologies.

Acknowledgements

Author contributions

ES, SS, SB, and CC made core contribution to the design of the study, collection of information, guidelines, established practices, and standards and made an extensive evaluation on new and promising technologies for the implementation of a secure information sharing platform for health-related data including blockchain evaluation. SM and VS coordinated the work in respect of the project PANACEA. All authors contributed to the article and approved the submitted version.

Data availability statement

The original contributions generated for the study are included in the article/supplementary material; further inquiries can be directed to the corresponding author/s.

Funding

This work has been supported by the PANACEA project, which has received funding from the European Union's Horizon 2020 research and innovation program under the Grant Agreement No. 826293.

Conflict of interest

The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.

Notes

This presentation is faithful to the original, with only a few minor changes to presentation, though grammar and word usage was substantially updated for improved readability. In some cases important information was missing from the references, and that information was added.