Medical Data Spaces in Healthcare Data Ecosystems

Abstract

Exchange of sensitive medical data between healthcare providers and researchers requires a particularly high level of trust and security. Involving patients and citizen into this process increases transparency and may improve the outcome of preventive, diagnostic, and therapeutic measures. We propose to build the structure of a healthcare ecosystem on the basis of “apps” that not only hold (and exchange) health data but support user interaction and healthcare process management. Emphasis on process support may also be used to improve data quality, which is an important prerequisite for evidence-based medicine and the training and usage of future AI tools.

1 Introduction

The state of digital transformation in the healthcare sector shows a very heterogeneous picture. While radiology departments use advanced AI tools to more accurately interpret their medical images, many resident physicians still rely on fax communication. Patients use their smartwatch to record ECGs, while their doctor records blood pressure in a paper file.

The biggest challenge currently is the transfer of relevant information between different organizations in the healthcare system. This is particularly relevant in a complex healthcare system such as in Germany. Different public and private healthcare providers (hospitals, resident practitioners, and specialized centers) have specific roles in this system. While providers use information technology for their own purposes, an overarching digital infrastructure is just starting to appear. One of the reasons is the lack of agreements or regulations concerning the provision or use of data by actors in the healthcare sector.

We are looking at this sector from a data ecosystem perspective. In a data ecosystem, exchange of data results in an overall benefit. In this case, patients should receive a more effective and more efficient treatment enabled by a collaboration of healthcare providers. For example, continuous treatment after a hospital visit should be facilitated. A technical infrastructure for data exchange is necessary, but not sufficient. Digital workflows also require harmonized processes and data structures. Healthcare providers need incentives (or regulations) from the ecosystem to establish collaborative workflows. A technical infrastructure alone will not push the digital transformation of the healthcare system.

A further challenge for the healthcare sector is to collect high-quality datasets of significant size for the introduction of precision medicine. Again, the technical challenge is being able to share datasets among organizations, but equally important is the harmonization of the procedures the data are based on. Appropriate incentives are necessary to reflect the value of such datasets and to properly share the benefit among the research community.

And finally, patients and consumers have to be integrated into this ecosystem, both as providers of their personal data and consumers of data-based prevention, diagnosis, and treatment.

Similar to logistics, healthcare is largely a real-time process, aiming at an immediate outcome to the patient’s benefit. In contrast, medical research has often been a separate process where the results slowly flow back into healthcare via publications and, later, formal guidelines. In precision medicine, the processes of healthcare and associated research are much more integrated. Patient data, such as genome sequences, are immediately used to identify the best therapy in the light of available data from recent cases. Subsequent patient engagement and patient monitoring will directly deliver detailed outcome information for the benefit of future patients.

In the case of precision medicine, digital processes not only benefit efficiency and customer experience, but will be indispensable for more effective therapies and successful prevention. Therefore, we expect this sector to be the key driver to the digital transformation of the healthcare system in the future.

Therefore, building a medical data space is contingent on establishing innovative data-based healthcare concepts. Technical developments and healthcare innovation have to go hand in hand. In this paper, we are trying to capture a sufficient part of the heterogeneous healthcare ecosystem via three representative scenarios:

1. Health and disease management

2. Integrated care

3. Precision medicine

In most of these scenarios, we have been involved in multiple innovation projects. We have tried to compile the experiences in a more abstract way in these scenarios.

2 Elements of Medical Data Spaces

The main healthcare providers are hospitals and resident practitioners, including various forms of collaborative medical institutions. Each healthcare provider needs to keep electronic medical records for all patients seen and treated. In countries with a centralized healthcare system, all providers are part of the same organization and can share medical records, while in countries such as Germany, the healthcare providers are independent and partially competing with each other.

But even within organizations, various independent information systems exist. For example, while a hospital uses a hospital information system (HIS) to organize the care process, various specialized information systems, such as radiology information systems (RIS) or operating room management systems, often from different vendors, cover more specialized needs. Each information system manages a subset of patient-related data.

This already constitutes the example of a data space. A data space is a collection of independently administered data sources or repositories [1]. Their independence promotes modularity in the overall technical and socioeconomic system, which in turn fosters local specialization and innovation.

In medicine, there are already approaches for such data spaces within organizations. Medical data protection regulations might already restrict visibility and use of certain data within the organization. The IHE (Integrating the healthcare enterprise) standards, particularly HL7/FHIR® (Fast Healthcare Interoperability Resources; [2]), define data exchange protocols and formats needed to synchronize the different information systems along specific workflows (see Fig. 18.1).

Fig. 18.1

Using the IDSA architecture to aggregate patient data from different healthcare providers

The architecture defined by the International Data Spaces Association [3] is an example how a data space can be constructed from individual data providers and consumers. The key is a suitable meta-model that allows participants to define and execute data exchange contracts in a trusted way.

We talk about a data ecosystem when different organizations are involved [4,5,6]. In this case, a contractual relationship typically needs to be established [7]. Medical data transfer requires a legal basis, for example, by laws concerning medical registers or by informed consent of the patients. The receiving institution might also have to rely on quality standards implemented by the sending institution to trust the data.

3 Scenario 1: Health and Disease Management

Many diseases require monitoring and treatment over an extended period of time. Specifically for chronic diseases, treatment regimes can be lifelong, such as in diabetes. Others are resolved into a stable state over the course of months or years. In such a situation, both patients and healthcare providers profit from a disease-oriented data exchange platform that facilitates and documents decisions and interventions and improves outcomes and quality of life.

SALUS is a project financed by the German Innovationsfonds that implements a new approach to health management for glaucoma patients.¹ In the SALUS approach, progression of a glaucoma disease is monitored with the help of an electronic health record app that includes multiple doctor visits and also allows data to be collected at home reducing time-consuming hospital visits. Usually, a profile of the intraocular pressure (the main parameter influencing the progression of the disease) of 4 h interval measurements is created over several days to assess day-and-night variation of the pressure. This currently necessitates hospitalization. Using a new consumer-operable measurement device in conjunction with a specialized app, SALUS avoids this hospitalization for both financial and comfort benefits.

The process is supervised by a resident ophthalmologist who can interact with the app in this role. A web-based information system collects the data and the status of the process. A web-based system is used because:

• the new protocol will be used by hundreds of ophthalmologists that do not use the same OS,

• data will be sent from the mobile devices directly to the system using interfaces that traditional medical information systems are not equipped with,

• the patient should have access to the information via a mobile device.

SALUS intends to improve therapy by optimizing medication and improve decisions for interventional measures. Medication is obviously relevant for other medical decisions outside ophthalmology and will also be documented (partly) in other information systems. Information about any previous interventions would also be maintained elsewhere. While the SALUS app currently interfaces with manufacturer apps of the measurement devices (Fig. 18.2 shows an example view of measurements), it would be highly desirable to exchange medication and intervention data as well.

Fig. 18.2

Partial display of the SALUS “app” that allows different healthcare providers to enter and view data related to glaucoma treatment. The display here shows results of a 24 h blood pressure measurement as a reference for the possible variation in intraocular pressure

4 Scenario 2: Integrated Care

The World Health Organization (WHO) defines integrated care as:

A concept bringing together inputs, delivery, management and organization of services related to diagnosis, treatment, care, rehabilitation and health promotion. Integration is a means to improve services in relation to access, quality, user satisfaction and efficiency [8].

As pointed out by the “European Commission Report on the Impact of Demographic Change” [9], the European healthcare systems are facing several challenges because of the growth of the ageing population, combined with an increasing number of chronic diseases. These challenges demand a search for integrated care solutions that promote a longer stay of patients at home, improving their quality of life and optimizing the use of health resources. This section presents the results of the PICASO project,² a project partially funded by the European Union’s Horizon 2020 research and innovation program under grant agreement No.: 689209. The PICASO solution supports a coordinated care of patients who have multimorbid chronic conditions (rheumatoid arthritis, together with a cardiovascular disease, and Parkinson, together with a cardiovascular disease) that involve different medical specialists and caregivers across multiple organizations. It enables the sharing of a patient’s complete clinical pathway with tools to monitor the health status, predict risks, collaborate, and adjust care.

The platform and its tools have been tested at two pilot sites with patients in Germany and Italy.

The PICASO platform consists of three major cloud components:

• Multiple legacy care information systems (Hospital Information Systems, HIS), each operating as a private cloud or cloud-like internal business structure with strict access control and limited access rights including secure storage of patient data. Within PICASO, this is called the Care System Private Cloud. This includes components such as the traditional EHR within the hospital, together with different security and privacy components and an Operational Data Store (ODS) which translates the information between PICASO and the clinical EHR.

• The PICASO Integration Platform Public Cloud operating as a public cloud solution providing the central integration service platform such as management of secure data exchange between the multidisciplinary actors, secure data collections from patients’ homes, and secure execution of care plan services. In this cloud, the patient data are pseudonymized.

• Multiple patient and environment monitoring systems running in the patients’ homes. Each of them exposes cloud web services and is thus regarded as the Patient Private Cloud.

Figure 18.3 schematically shows the interaction between these components. All software for care management and decision support is hosted in the public cloud, while the patient data resides inside the care organizations.

Fig. 18.3

PICASO platform overview [10] © 2021, Richter et al. [CC BY 4.0]. No changes made

A Distributed Validation Authority (DIVA) ensures that data is only shared if all policies and transaction-specific privacy and security requirements are met. DIVA combines an Access Manager, Identity Manager, and Policy Manager [10, 11], which ensure the following:

• A secure connection to the PICASO Public Cloud as well as communication between Public and Local Clouds.

• Identification and authentication of users.

• Verification of data transactions.

The complete system was tested at the two pilot sites, with a positive feedback from patients and clinicians, especially from the perspective of improvement in the management of the clinical processes and patient empowerment. The system also demonstrated the integration of different clinical data spaces into a homogeneous environment.

PICASO developed the following applications.

4.1 Care Management as a Service

PICASO offered a complete solution for the management of care plans across different organizations, so that clinicians can follow up the different treatments of the patients in different institutions. That reduces the risk of polypharmacy and facilitates the coordination of tests, together with the stop/start of different medications (see Fig. 18.4).

Fig. 18.4

PICASO Care Plan Manager entry page

4.2 Patient Self-Monitoring as a Service

The Patient Self-Monitoring Solution is supported by a patient dashboard and an app. Unlike existing solutions, this service integrates all three types of monitoring schemes:

• Scheduled vital signs measurements with medical devices.

• Continuous activity and behavior monitoring using wearable sensors.

• Patient self-assessment and medication recording (PROMs—Patient-reported outcome measures).

4.3 Risk Manager

The Risk Manager provides patient-specific risk estimates, merging standard charts with novel risk scores into one single tool. The novel risk scores use machine learning to merge data from an entire patient’s history into a single integrated risk score.

4.4 Data Resource Browser and Patient Data Viewer

Clinicians can browse all available patient data in the Data Resource Browser, with an intuitive user interface. In the Patient Data Viewer, the clinician can look at patient data received by other care providers if authorized to do so and see what measurements have been performed, together with interventions and care plans (see Fig. 18.5).

Fig. 18.5

PICASO Patient Data Viewer (dashboard view)

This example shows that it is important to support a hierarchy of apps. For example, the risk manager uses data collected by other apps. While the PICASO components were developed together, in a healthcare ecosystem, it should be possible for the risk manager to have a flexible interface for data collection so that it can interoperate with a variety of primary apps.

5 Precision Medicine

Genome sequencing technology has advanced in the recent years, so that whole genome sequencing can be routinely employed as a diagnostic mechanism (e.g., in rare diseases) and as a selection criterion for therapy optimization (e.g., in cancer). This technology has been introduced in many countries. In most of these countries, it has necessitated a new organization of healthcare provision due to the demands of the technology.

Genome sequencing is a high-throughput laboratory technique that produces huge datasets. The main challenge of data analysis is to decide which of the thousands of genomic variations of an individual are of diagnostic or therapeutic relevance. This knowledge increases rapidly and is tightly bound to data analysis within larger datasets. Data analysis employs many special tools at the research level.

To make this technology applicable for regular patient care, the sample processing and data analysis have been centralized in larger, research-oriented units. The actual patient care is also provided by specialized regional centers, which are distributed throughout the country to give all patients equal access. Because genomic data are very sensitive, they are typically kept in a specially secured environment, while the clinical data of the patient reside with the specialized regional centers. Furthermore, genomic data together with standardized clinical records can also be shared internationally when the patient permits.

In this situation, data are distributed between at least three different organizations. The clinical data are highly disease-specific and can also vary with healthcare providers, while the genomic data are more standardized for exchange (see Fig. 18.6).

Fig. 18.6

Longitudinal record of a cancer patient with different aspects of the patient collected by different organizational units

The collaboration among the different (sub-)organizations is typically defined by regulatory procedures. Although these procedures vary between countries, the overall structure is pretty similar. This field, therefore, provides a sufficiently complex example of a medical data space. In some countries with centralized healthcare systems, IT has been centrally organized in this area. Other countries with a decentralized healthcare system still struggle with establishing the necessary infrastructure. Germany has recently started an initiative to introduce this model into the German healthcare system (genomDE³). It will be based on a federated and distributed data structure.

Because of the highly sensitive nature of genomic data, not all patients will agree to share their data. Therefore, techniques of remote algorithm execution are needed [12, 13] to enable researchers to comparatively and statistically analyze genomic variation in large cohorts.

6 Healthcare Data Ecosystems

In healthcare, the model of data providers connected to data consumers is too simple because most data are personal. The Personal Data Ecosystem Consortium (PDEC)⁴ therefore introduces the “Principal” role, which in healthcare corresponds to the patient.

Quite often, patients are regarded as passive subjects. In a patient-centric healthcare system, patients have an active role, executing their sovereignty over their personal data maintained by other parties and also adding further input into the process via personal monitoring. A further role distinguished by the PDEC is the “Custodian.” This role is important because few patients are actually data managers, so they might employ another party to help managing data and to coordinate with the other actors.

Therefore, a crucial element of a healthcare data space is the patient role. Patients may take actions on the usage of their personal data, but they are also the “end-customers” of healthcare services and active players on behalf of their own health (patient empowerment). The aspect of personal data coupled with an active participation of each person has not yet been addressed in detail in data space research.

Furthermore, the view of a data provider either as a repository (as in data management) or as a data stream (as in the Internet of Things) mostly ignores that healthcare data are typically generated as part of a healthcare service, such as an examination or an intervention. The data are a result of an interaction of patient, caregiver, medical devices, and IT services. Examples are:

• Visiting a general practitioner. The anamnesis data are entered into the local patient record.

• Medical imaging. Data are stored, e.g., in a radiology imaging system.

• Blood analysis in a lab. Data are sent to the general practitioner (on paper).

• Blood pressure or blood sugar measurement on a personal device. Data are collected via a mobile app.

To avoid the confusion between healthcare services (which are legal and financial transactions as well as personal interactions) and IT services (which are operated to manage the former), we will use the term “app” to refer to an interactive IT service that interacts with a user (doctor/patient) or a medical device to manage and coordinate healthcare services. In that sense, data providers and data consumers in a healthcare data space on the one hand represent human or organizational actors, but on the other hand have corresponding “apps” that manage the digital transcript of the interaction.

In the digital ecosystem view, actors may not only be providers of traditional healthcare services but also information providers, disease management systems, study companions, or procurement services. Actors and the supporting apps are typically regulated with respect to safety and security, as well as reimbursement and documentation.

7 Structure of a Healthcare Data Space

The technical components of a healthcare data space are interactive information systems (owned by independent service providers) called “apps” that encapsulate functions and data. Functions may include data capture from users and technical devices, data analysis, data visualization, and remote interaction. Functions may also include execution of transactions such as appointments and referrals and (maybe bidirectional) data transfer to other apps. Apps support multiple users in different roles. These apps are distributed among different organizations and connected through an appropriate technical platform, ideally a modern, flexible, and trustworthy multi-cloud such as the Gaia-X architecture.⁵

Apps can support processes like

• (A) Intra-organizational care, e.g., in a hospital using a hospital information system (HIS).

• (B) Inter-sectoral collaborations, e.g., outpatient management and home care.

• (C) Personal monitoring and prevention, e.g., fitness tracking or diabetes monitoring.

Another reason to use the “app” terminology is that we want to incorporate mobile technology from the beginning. While category C is already built on a consumer perspective through wearables and mobile devices, B and A still mostly face the transformation task to a modern digital platform.

There are numerous examples of such digital apps. However, most of them are specialized for particular diseases, interventions, or risks. Many of them aggregate data relevant for the decision process in a certain context, e.g., a disease-specific guideline. Apps have to be specialized to be useful, effective, and user-friendly.

For example, in diabetes management it is not sufficient to just collect data (glucose level, weight, etc.) and display them. Most diabetes management services include coaching and social interaction mechanisms with different roles (e.g., doctor/coach/other participants). Apps that include medical devices or are classified as medical products themselves will also include more advanced data analysis functionalities.

While apps can tailor therapies for the individual patient based on the data collected, apps can also provide data for medical research and healthcare system optimization. This is particularly relevant both for chronic and rare diseases. Effectively, the healthcare system will learn from as many examples as possible.

While early smartphone apps stored data on the phone itself, most apps now use some form of cloud storage to provide a backup and to allow cross-device usability. While medical data protection in typical cloud implementations is seen as problematic, just storing the data on the device is no alternative in terms of backup and sharing. Therefore, healthcare apps should use an appropriately certified cloud service or should not store the data themselves at all, but directly acquire them from another certified app or medical record service.

8 User-Centered Concepts in a Healthcare Data Space

An important feature of a healthcare data ecosystem is to permit the patient to exercise sovereignty over their personal data. The difficulty with this goal is that we typically cannot expect (elderly) patients to be expert data managers, in particular in situations when they are in direct need of healthcare. Internet privacy is plagued by similar issues, e.g., when consenting to the use of cookies.

Data spaces are typically described from the perspective of data owners. Each institution is owner of the data it maintains and could provide to others. In digital health, the situation is a little bit more complicated. The concept of ownership is not directly applicable, as both patient and healthcare institutions have different legal rights and obligations on the same data. Therefore, patients have dual roles as legal entities and as additional users with a consumer perspective distinguished from the provider perspective of the healthcare providers.

8.1 Trusted Users

All users (patients as well as healthcare professionals) need a trusted identity in a healthcare ecosystem. This ensures that data can only be exchanged with trusted participants. In the projects described above, such a service is specifically set up for each project. A national or regional healthcare system, however, needs to establish such a system. It should cover an extensive range of users including home care personnel, medical supply stores, or even relatives as trustees or guardians. Fortunately, technical interfaces for identity management are mostly standardized, as they are also used in other business areas. All apps in a healthcare data ecosystem should be prepared to employ such a system-wide identity service.

Trust is established by a service provider certified via IDSA-compatible processes that lets individual users register and validates their identity. For example, an insurance company could be the identity provider for its customers, while associations of medical professionals could do the same for their members. Authentication preferably uses mobile devices (plus other factors) for ease of use.

8.2 Single Entry Point

For ease of use and convenience, every user should have a single entry point to the ecosystem. For patients, this is called the health account, and it provides

• A directory of apps that the person subscribes to/has accounts with. Accessing the app will execute a login action to this app or show the dashboard (e.g., if I am a trusted relative).

• A directory of consents given to each app and to each data exchange channel between apps. Each consent should have a legal document, and explanatory document, a date of signature, and a way of withdrawing the consent. Preferably, electronic consent should be promoted.

• A transaction log of any data exchange between apps, being able to inspect which data were exchanged when.

Informed consent is an important element in data protection. In a data space, consent is primarily given at the level of apps (instead at the level of institutions and/or data elements). The main advantage is that apps themselves can establish and control fairly detailed rules on who can access which data in what role. For example, if I fill the general practitioner (GP) role in an app with my preferred GP, the access rights follow from that role. In an app about mental disorders, a psychiatrist would be authorized to look into my detailed protocols, while the GP role would only see a brief summary (if the GP role is filled at all).

Of course, this means that apps have to be trusted to implement access rights correctly. Given that medical apps will be regularly scrutinized for various properties in the future, in particular for safety and security, this should pose no additional problems. While this is a relatively coarse granularity of user influence, it is much more user-friendly than highly granular access rights, as the latter have a high error potential even for experienced users.

In a data space, in addition to influencing who will fill each role, patients can give permission for one app to exchange standardized data with another. A typical example would be a medication plan. While a medication plan could be maintained centrally, an app would have to manage it anyway unless the central service is mandatory for all patients. Managing the medication plan inside the app also gives the possibility to extend the data stored useful for a particular use case, while only the exchange would stay at the standard definition.

Therefore, we have defined exchange permissions as a central task in the patient’s health account.

8.3 Unified Health Report (aka Virtual Health Record)

One of the usage scenarios of a common EHR is that actors not originally involved in the treatment of the patient should be able to get a brief overview of patient status and history as relevant to health-related use cases. For example, in ophthalmology, people in care of an elderly person should be aware of a glaucoma diagnosis, any medication, and the need to regularly visit an ophthalmologist. Such a summary could be provided in a common EHR, but it can also be provided as a health dashboard of the glaucoma app.

The EHR solution has the advantage that the data by the different apps could be analyzed by further tools (maybe using artificial intelligence) to detect interactions. It requires the summaries to be fairly standardized, though. Just visualizing the information in the health dashboard makes the apps more independent of each other and is fairly easy to implement by each app. The medical data space provides both options.

There is a standard interface to call up a health dashboard from all the roles that are authorized by the patient (see Figs. 18.3 and 18.7). This may particularly apply to care personnel and relatives, which are easily enabled to participate in the care process, even remotely. The advantage is that in the dashboard, the visualization can be optimized towards general information demands for specific diseases, distinguished by the levels of relatives, professional caregivers, and general practitioners. Again, no specific permissions have to be given by the patient except assigning a person to the particular role.

Fig. 18.7

Draft design of a patient dashboard that is composed from individual displays from several different apps

9 Data Quality in the Medical Data Space

A common problem with EHRs is reliability of data generated by a different organization or even by the patient. With a health record regarded as just a set of data, even secure audit trails provide only limited context about how the data have been generated. With health records maintained by apps, it is one of the main purposes of the app functionality to encourage or guarantee a quality management process. The quality of the data depends on appropriate measures being implemented by the app. Data quality in this scenario is highly dependent on the quality of the app.

For example, in SALUS there are provisions to make sure that data are correctly handled by the patients. Furthermore, a review process tries to detect suspicious data. The data quality of the SALUS data is not just provided by the database, but by the treatment process organized around the SALUS app. The SALUS system allows ophthalmologists to review measurements in a context of the source devices, subsequent examinations, and general consistency as regards the disease. The whole process determines the final quality of the data. Therefore, an app that stimulates a quality-driven process establishes trustworthiness of the data for other uses. In SALUS, data may be uploaded by the patient, but they are reviewed by an ophthalmologist. Consequently, the data and in particular the data summary can be reliably used by other specialties or by nurses and caregivers.

For medical research, a hierarchical aggregation process of such data is necessary. Quality-controlled data exported from an app can be converted into a structure suitable for big data analytics and combined with other data sources. This aggregation can be performed using ad hoc techniques, but assuming that apps like SALUS will be much more common in the future, it will be easily possible to establish permanent pipelines of data using IDSA broker services as aggregators. User consent will be necessary for such studies, but with a transparent mechanism, it is much easier for users to give (and redraw) such consent. For the research process, an important aspect are the anonymization and pseudonymization of data, which will allow the aggregation of data coming from different patients as input to different machine learning algorithms and data analytics processes facilitating new research and diagnostics tools for clinicians, as in the PICASO project.

10 Conclusion

The architecture presented here is a promising approach to handle future demands for a health data ecosystem. However, just like the whole ecosystem, the architecture will have to evolve as well. Currently, we are trying to validate the approach in many different areas from prevention and healthcare to medical research and epidemiology. A particular emphasis will be on the new role of the patient. Further studies have to be conducted that find out what is a most appropriate level of control and how we can simplify the interaction and still inspire trust.