Use Cases

Here we list a number of use case scenarios that are used to elicit requirements for the Personal Health Train architecture.

Use case 1

A patient visits his doctor. The doctor needs information from the patient's personal locker to copy to his local information system.

Use case 2

from ZIN pilot

A hospital able to perform intra-arterial therapy (IAT) needs to collect data from other health providers in order to have a full assessment of the time-to-groin (the time between the patient started presenting the symptoms and the IAT is performed). Patients may deal with different health providers before reaching IAT-hospital such as ambulance services and regional hospitals. Therefore, in order to be able to have a comprehensive time-to-groin indicator, the IAT-hospital needs to collect its own data about patients treated with IAT and more data from each of the involved health providers from the moment the patients started presenting the symptoms until the treatment has been performed.

Use case 3

from ZIN pilot

A person has just deployed his/hers Personal Data Locker and needs to start populating the Locker with data about him/her available in different sources such as in the information systems form general practitioners, hospitals, pharmacies, etc.

Use case 4

Learning from Distributed Healthcare Data:

Bringing the Algorithm to the Data in German University Medical Centers

The German Federal Ministry of Research supports the establishment of "data integration centers" (DICs) at German university hospitals and partner institutions as part of its Medical Informatics Initiative (https://www.bmbf.de/de/medizininformatik-3342.html ). The overarching goal of the DICs is to bridge the gap between healthcare and biomedical research by integrating healthcare data as well as disease specific research data sets in DICs and make these data usable for research and healthcare. The sensitive nature of the healthcare data and the special legal protection this data benefits from under state, federal, and European law, including the EU General Data Protection Rules (EU-GDPR) restricts the use of naive data sharing approaches such as data pooling across sites.

An alternative to exchanging data is the exchange of algorithms, which gives access to the local data only in a tightly regulated manner without revealing the primary data directly to the requesting researcher or physician. At the same time, we would like to achieve results that are similar in quality to the application of the method to naively pooled data. Possible application scenarios might be patient recruitment across sites (cohort selection), development of statistical models, or machine learning for treatment decision support systems.

Example user story:

• The end user is a data scientist who wants to train a model to predict the outcome of cardiovascular disease events based on related clinical and paraclinical data.
• There are three data integration centers (DICs) hosting possibly relevant datasets integrated across a wide range of heterogeneous sources.
• DICs data is private, the user can not access the data directly.
• Data schemas are public, can be accessed by the algorithm developer.
• The end user designs an algorithm via interacting with schemas, generates relevant metadata and a query to interact with DICs via a user interface, and ship it.
• The submitted package is sent to a third party, which will plan the route of the train by negotiating with DICs, and ship it.
• DICs will receive the request, iteratively (re-)train the model and send the trained model back to the third party. The third party will direct the model to the next DIC.
• When the route is completed, the third party will send the trained model back to the end user.

Use case 5

Use case 6