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

From LIMSWiki
Revision as of 19:45, 8 June 2021 by Shawndouglas (talk | contribs) (Saving and adding more.)
Jump to navigationJump to search
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)
Emblem-important-yellow.svg This article should be considered a work in progress and incomplete. Consider this article incomplete until this notice is removed.

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.

Introduction

Information technology (IT) has long been identified as a cornerstone for efficient, cost-saving, timely, and reliable healthcare delivery.[1][2] 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.[3] 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.[4] 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[5]; Level 3 for distributed systems that agree on protocols used, data formats, message exchange patterns, etc.[6]; 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[7]; and finally, at the “universal” Level 5, where diverse eHealth applications connect to an open, interoperable infrastructure possibly spanning multiple countries.[8][9]


Fig1 Spanakis FrontDigHlth2021 3.jpg

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

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.[10] Figure 2 depicts how these aspects can be represented in interoperability “levels” that permit two different organizations to communicate.


Fig2 Spanakis FrontDigHlth2021 3.jpg

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.[11][12] 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.[13] 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.[14] 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.”[15] 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.[16] 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.[17] 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.[18]
  • In the area of DNA sequencing and other -omics data formats, we have FASTQ file format[19], which is used to store sequence information, and the standard flowgram format (SFF), which is used to encode sequence reads.[20]
  • The majority of the EHR systems adopt the HL7 standard clinical document architecture (CDA) as the interoperable data format.[21] 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."[22] 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.[23]

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.[24] 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.[25] 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.[26] 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.[27][28] Blockchain has been extensively used for Bitcoin.[29] In the realm of healthcare, we have seen Kuo et al.[30] 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.[31] 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.[32] and Radoglou et al.[33]

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.


Fig3 Spanakis FrontDigHlth2021 3.jpg

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.


Fig4 Spanakis FrontDigHlth2021 3.jpg

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.


Fig5 Spanakis FrontDigHlth2021 3.jpg

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.[34] discussed in detail the formalization and the specification of the group membership service, while more recently, Aguilera et al.[35] 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).[36][37][38] 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.


Fig6 Spanakis FrontDigHlth2021 3.jpg

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.


Fig7 Spanakis FrontDigHlth2021 3.jpg

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 HCO1 to share his X-ray images with HCO2. This means that HCO1 and HCO2 create locally a shared space where they will store a copy of all Bob's X-ray images (the red slice in Figure 8).


Fig8 Spanakis FrontDigHlth2021 3.jpg

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


References

  1. ↑ U.S. Congress, Office of Technology Assessment (September 1995). "Bringing Health Care Online: The Role of Information Technologies" (PDF). U.S. Government Printing Office. https://ota.fas.org/reports/9507.pdf. 
  2. ↑ Kolodner, R.M.; Cohn, S.P.; Freidman, C.P. (2008). "Health Information Technology: Strategic Initiatives, Real Progress". Health Affairs 27 (Supp. 1): w391–5. doi:10.1377/hlthaff.27.5.w391. 
  3. ↑ Spanakis, E.G.; Bonomi, S.; Sfakianakis, S. (2020). "Cyber-attacks and threats for healthcare - A multi-layer thread analysis". Proceedings of the 42nd Annual International Conference of the IEEE Engineering in Medicine & Biology Society: 5705–08. doi:10.1109/EMBC44109.2020.9176698. PMID 33019270. 
  4. ↑ 4.0 4.1 Van Velsen, L.; Hermens, H.; d'Hollosy, O.-N. (2016). "A maturity model for interoperability in eHealth". Proceedings of the IEEE 18th International Conference on e-Health Networking, Applications and Services: 1–6. doi:10.1109/HealthCom.2016.7749533. 
  5. ↑ Chronaki, C.E.; Chiarugi, F.; Mavrogiannaki, E. et al. (2003). "An eHealth platform for instant interaction among health professionals". Proceedings of the Computers in Cardiology 2003: 101–4. doi:10.1109/CIC.2003.1291100. 
  6. ↑ Spanakis, M; Lelis, P.; Chiarugi, F. et al. (2005). "R&D Challenges in Developing an Ambient Intelligence eHealth Platform". IFMBE Proceedings 11 (1): 1727–983. http://139.91.210.27/CBML/PROCEEDINGS/2005_EMBEC/Embec%202005/Abstracts/Abstract791.html. 
  7. ↑ Tsiknakis, M.; Spanakis, M. (2010). "Adoption of innovative eHealth services in prehospital emergency management: A case study". Proceedings of the 10th IEEE International Conference on Information Technology and Applications in Biomedicine: 1–5. doi:10.1109/ITAB.2010.5687752. 
  8. ↑ Spanakis, E.G.; Psaraki, M.; Sakkalis, V. (2018). "Congestive Heart Failure Risk Assessment Monitoring through Internet of things and mobile Personal Health Systems". Proceedings of the 40th Annual International Conference of the IEEE Engineering in Medicine and Biology Society: 2925-28. doi:10.1109/EMBC.2018.8513024. PMID 30441013. 
  9. ↑ Spanakis, M.; Sfakianakas, S.; Sakkalis, V. et al. (2019). "PharmActa: Empowering Patients to Avoid Clinical Significant Drug⁻Herb Interactions". Medicines 6 (1): 26. doi:10.3390/medicines6010026. PMC PMC6473432. PMID 30781500. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6473432. 
  10. ↑ "eHealth Network: Refined eHealth European Interoperability Framework" (PDF). European Union. 23 November 2015. pp. 24. https://ec.europa.eu/health/sites/default/files/ehealth/docs/ev_20151123_co03_en.pdf. 
  11. ↑ Katehakis, D.G.; Pangalos, G.; Prentza, A. (2017). "Security Improvements for Better and Safer Cross-Border ePrescription and Patient Summary Services". International Journal of Reliable and Quality E-Healthcare 6 (1): 2. doi:10.4018/IJRQEH.2017010102. 
  12. ↑ Tinholt, D.; Carrara, W.; Tol, T. et al. (18 June 2013). "Final Report - Study on Analysis of the Needs for Cross-Border Services and Assessment of the Organisational, Legal, Technical and Semantic Barriers (SMART 2011/0074)". European Commission. doi:10.2759/10003. https://ec.europa.eu/digital-single-market/en/news/final-report-study-analysis-needs-cross-border-services-and-assessment-organisational-legal. 
  13. ↑ Peeters, M. (2012). "Free movement of patients: Directive 2011/24 on the application of patients' rights in cross-border healthcare". European Journal of Health Law 19 (1): 29–60. doi:10.1163/157180912x615158. PMID 22428388. 
  14. ↑ Benson, T. (2012). Principles of Health Interoperability HL7 and SNOMED (2nd ed.). Springer. doi:10.1007/978-1-4471-2801-4. ISBN 9781447128014. 
  15. ↑ Kuchinke, W.; Alerts, J.; Semler, S.C. et al. (2009). "CDISC standard-based electronic archiving of clinical trials". Methods of Information in Medicine 48 (5): 408–13. doi:10.3414/ME9236. PMID 19621114. 
  16. ↑ Carroll, R.; Cnossen, R.; Schnell, M. et al. (2007). "Continua: An Interoperable Personal Healthcare Ecosystem". IEEE Pervasive Computing 6 (4): 90–94. doi:10.1109/MPRV.2007.72. 
  17. ↑ Marias, K.; Sakkalis, A.; Roniotis, C. et al. (2009). "Clinically Oriented Translational Cancer Multilevel Modeling: The ContraCancrum Project". Proceedings of the 2009 World Congress on Medical Physics and Biomedical Engineering: 2121–27. doi:10.1007/978-3-642-03882-2_564. 
  18. ↑ Larobina, M.; Murino, L. (2014). "Medical Image File Formats". Journal of Digital Imaging 27: 200–06. doi:10.1007/s10278-013-9657-9. 
  19. ↑ Cock, P.J.A.; Fields, C.J.; Goto, N. et al. (2010). "The Sanger FASTQ file format for sequences with quality scores, and the Solexa/Illumina FASTQ variants". Nucleic Acids Research 38 (6): 1767–71. doi:10.1093/nar/gkp1137. PMC PMC2847217. PMID 20015970. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2847217. 
  20. ↑ Leinonen, R.; Sugawara, H.; Shumway, M. et al. (2011). "The sequence read archive". Nucleic Acids Research 39 (DB1): D19–21. doi:10.1093/nar/gkq1019. PMC PMC3013647. PMID 21062823. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3013647. 
  21. ↑ Dolin, R.H.; Alschuler, L.; Beebe, C. et al. (2001). "The HL7 Clinical Document Architecture". JAMIA 8 (6): 552–69. doi:10.1136/jamia.2001.0080552. PMC PMC130066. PMID 11687563. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC130066. 
  22. ↑ Freitas, F.; Schulz, S.; Moraes, E. (2009). "Survey of current terminologies and ontologies in biology and medicine". RECIIS 3 (1): 239–49. doi:10.3395/reciis.v3i1.239en. 
  23. ↑ Bender, D.; Sartipi, K. (2013). "HL7 FHIR: An Agile and RESTful approach to healthcare information exchange". Proceedings of the 26th IEEE International Symposium on Computer-Based Medical Systems: 326–31. doi:10.1109/CBMS.2013.6627810. 
  24. ↑ Kondylakis, H.; Petrakis, Y.; Leivadoros, S. et al. (2019). "Using XDS and FHIR to Support Mobile Access to EHR Information Through Personal Health Apps". Proceedings of the 2019 IEEE 32nd International Symposium on Computer-Based Medical Systems: 241–4. doi:10.1109/CBMS.2019.00058. 
  25. ↑ Eckman, B.A.; Bennett, C.A.; Kaufman, J.H. et al. (2007). "Varieties of interoperability in the transformation of the health-care information infrastructure". IBM Systems Journal 46 (1): 19–41. doi:10.1147/sj.461.0019. 
  26. ↑ Nikoloudakis, Y.; Pallis, E.; Mastorakis, G. et al. (2019). "Vulnerability assessment as a service for fog-centric ICT ecosystems: A healthcare use case". Peer-to-Peer Networking and Applications 12: 1216–24. doi:10.1007/s12083-019-0716-y. 
  27. ↑ Nofer, M.; Gomber, P.; Hinz, O. (2017). "Blockchain". Business & Information Systems Engineering 59: 183–7. doi:10.1007/s12599-017-0467-3. 
  28. ↑ Vergne, J.P. (2020). "Decentralized vs. Distributed Organization: Blockchain, Machine Learning and the Future of the Digital Platform". Organization Theory 1 (4). doi:10.1177/2631787720977052. 
  29. ↑ Macdonald, M.; Liu-Thorrold, L.; Julien, R. (February 2017). "The Blockchain: A Comparison of Platforms and Their Uses Beyond Bitcoin". ResearchGate. doi:10.13140/RG.2.2.23274.52164. https://www.researchgate.net/publication/313249614_The_Blockchain_A_Comparison_of_Platforms_and_Their_Uses_Beyond_Bitcoin. 
  30. ↑ Kuo, T.-T.; Rojas, H.Z.; Ohno-Machado, L. (2019). "Comparison of blockchain platforms: A systematic review and healthcare examples". JAMIA 26 (5): 462–78. doi:10.1093/jamia/ocy185. PMC PMC7787359. PMID 30907419. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7787359. 
  31. ↑ Chowdhury, M.J.M.; Ferdous, S.; Biswas, K. et al. (2019). "A Comparative Analysis of Distributed Ledger Technology Platforms". IEEE Access 7: 167930–43. doi:10.1109/ACCESS.2019.2953729. 
  32. ↑ Triantafyllou, A.; Jimenez, J.A.P.; Torres, A.D.R. et al. (2020). "The Challenges of Privacy and Access Control as Key Perspectives for the Future Electric Smart Grid". IEEE Open Journal of the Communications Society 1: 1934–60. doi:10.1109/OJCOMS.2020.3037517. 
  33. ↑ Grammatikis, P.R.; Sarigiannidis, P.; Efstathopoulos, G. et al. (2020). "ARIES: A Novel Multivariate Intrusion Detection System for Smart Grid". Sensors 20 (18): 5305. doi:10.3390/s20185305. PMC PMC7570496. PMID 32948064. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7570496. 
  34. ↑ Chockler, G.V.; Keidar, I.; Vitenberg, R. (2001). "Group communication specifications: A comprehensive study". ACM Computing Surveys 33 (4): 427–69. doi:10.1145/503112.503113. 
  35. ↑ Aguilera, M.K.; Keidar, I.; Malkhi, D. et al. (2011). "Dynamic atomic storage without consensus". Journal of the ACM 58 (2): 1–32. doi:10.1145/1944345.1944348. 
  36. ↑ Coiera, E.; Clarke, R. (2004). "e-Consent: The design and implementation of consumer consent mechanisms in an electronic environment". JAMIA 11 (2): 129–40. doi:10.1197/jamia.M1480. PMC PMC353020. PMID 14662803. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC353020. 
  37. ↑ Bergmann, J.; Bott, O.J.; Hoffmann, I. et al. (2005). "An eConsent-based System Architecture Supporting Cooperation in Integrated Healthcare Networks". Studies in Health Technology and Informatics 116: 961–6. PMID 16160382. 
  38. ↑ Bergmann, J.; Bott, O.J.; Pretschner, D.P. et al. (2007). "An e-consent-based shared EHR system architecture for integrated healthcare networks". International Journal of Medical Informatics 2–3: 130–6. doi:10.1016/j.ijmedinf.2006.07.013. PMID 16971171. 

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.

Retrieved from "https://www.limswiki.org/index.php?title=Journal:Emerging_and_established_trends_to_support_secure_health_information_exchange&oldid=43014"