1 Introduction

1.1 Oncological aftercare

With 497,900 newly diagnosed cases and about 229,600 deaths in 2018, cancer is one of the most common diseases and the second most common cause of death in Germany [1]. In 2020, 2.7 million people in the European Union were diagnosed with cancer, and another 1.3 million people lost their lives to it [2]. Clinical cancer treatment is widely based on surgery, chemotherapy, radiotherapy, and their combinations [3]. Cancer therapy in addition to the immediate effects may also entail significant after-effects for patients. They often suffer from a reduced well-being and quality of life for a long time after leaving the clinic [4]. After primary treatment, many cancer patients have significant burden from issues related with lack of social support, fatigue, poor sleep, pain, emotional distress, tumor recurrence, and metastatic disease [5,6,7,8]. Maintaining a healthy lifestyle and having access to psychosocial resources are crucial for adapting well to the post-treatment phase.

However, patients can receive only limited medical support outside of the highly specialized clinical environment. To a major extent, they are left to their own devices to overcome the after-effects of treatment. Even regular consultation hours allow only limited exchange of information between health-care professionals and patients at certain intervals. The individualized planning of tailored supportive actions based on little data is, in turn, a major challenge for health-care professionals. The correct independent implementation of supportive actions is also a complex and possibly error-prone task for patients.

1.2 Scientific state-of-the-art

This situation coincides with the the conceptual, methodical, and technological state-of-the-art documented in the scientific literature. The clear potential benefit of software-assisted patient support is common sense, but adequate solution approaches would require integrated workflow concepts and interoperability with existing software environments [9]. The many patient-centered mobile applications released in the recent years are mostly standalone systems, which do not connect to the patients’ electronic health records or allow for a close communication with the health-care professionals [10, 11]. The vast majority of clinical decision support systems is designed for assisting health-care professionals mostly in prediction and diagnosis and not in treatment optimization or patient monitoring [12, 13]. Furthermore, the functionality of these systems is based on single methods of artificial intelligence (AI) with a clear focus on knowledge-based systems and only few approaches featuring advanced data analysis with machine learning (ML) or deep learning (DL) or approaches featuring explainable artificial intelligence (XAI).

1.3 A hybrid artificial intelligence concept

The main health-related goal of the EU project ONCORELIEF is to support cancer patients in regaining their well-being and quality of life after treatment [14]. This goal is achieved by establishing a closed-loop workflow featuring AI methods, which connects health-care professionals and patients by means of assistive digital solutions and supports them with suitable automation of difficult work steps. This workflow allows intensive cooperation beyond consultation hours and digitally assisted individualized planning and close monitoring of supportive actions.

The patients use a mobile application installed on their smartphones in combination with smart wearable sensors for the documentation of supportive actions and their monitoring, which is done automatically by AI methods. The data collected with the mobile application are transferred to a web application, and there combined with data from the patients’ electronic health records. The health-care professionals use this web application for the analysis of the patients’ needs for supportive actions and the planning of these actions. The analysis of needs and the planning make use of a wide range of AI methods suited for different analytic tasks. The newly planned supportive actions are then transferred to the patients’ mobile applications, thereby closing the loop.

Compared with the scientific state-of-the-art, the ONCORELIEF solution approach features an integrated workflow concept with connectivity in particular to electronic health records, a wide range of differently designed AI methods for data analysis and planning of supportive actions, a close communication of patients and health-care professionals, and patient-centered software features for documentation and monitoring.

1.4 Contents

This paper presents in Sect. 2, the methods used for analysis of needs for supportive actions, their planning and monitoring. Section 3 describes the practical application for an illustrative case scenario of colorectal cancer. Section 4 assesses the achieved research and development results.

2 Material and methods

2.1 Workflow concept

Fig. 1
figure 1

Solution approach with the core components and main data flows: documentation of supportive actions by patients in their mobile applications and monitoring with the apps (upper right part in blue) and connected smart watches (central right part in gray), automated analysis of patient data with different AI methods (lower part in red), and planning of supportive actions by health-care professionals (upper left part in green) (Icons: Line Icons (iconsmind.com), Windows 8 Icons (icons8.com))

Full size image

Figure 1 schematically depicts the workflow of AI-based aftercare for cancer patients with its main elements.

2.1.1 Patient data

The considered data about patients are of different types and levels of detail.

  • Contents of the patients’ records, in particular the oncological diagnoses, and observed symptoms form the core data for the planning of supportive actions for aftercare.

  • Measurings of vital signs conducted with wearable sensors provide data about the patients’ current health status.

  • Patients’ answers to standardized questionnaires describe the patients’ personal health perceptions after clinical treatment.

  • Patients’ feedback on the course and outcome of supportive actions give insight to the progress of aftercare.

2.1.2 Data analysis

The acquired patient data enter the data analysis with methods from an AI framework, which allow for a processing of input data with respect to different analytic tasks based on individual configurations.

  • A purely model-based approach relies on a rule-based system for identifying relevant supportive actions based on digitized health knowledge.

  • A purely data-driven approach analyses patients’ needs with ML/DL methods trained on comparative data from former patient cases.

  • A combination of data-driven and model-based concepts identifies relevant supportive actions with statistical analysis by assigning patient cases to clusters of former cases.

2.1.3 Planning of patients’ support

The results obtained with the AI-based data analysis of considered patient cases enter the planning of supportive actions. Here, the health-care professionals use the patient data and results of analysis for selecting the suitable supportive actions and adapting them to the patients’ individual needs. The ONCORELIEF solution approach provides three kinds of supportive actions:

  • Standardized questionnaires allow for an assessment of the patients’ health situations in general or with respect to certain symptoms observed.

  • Text messages provide patients with individual information from their health-care professionals.

  • Structured supportive actions guide patients in the implementation of aftercare measures and allow for an automated monitoring according to the requirements of health-care professionals.

2.1.4 Implementation of supportive actions

The planned supportive actions are transferred to the mobile application on the patients’ smartphones, which supports them during aftercare in different ways:

  • The reporting about the patients’ health perceptions happens with standardized and mostly symptom-specific questionnaires.

  • There is patient empowerment in the form of the guiding information from text messages.

  • The course of individual aftercare is documented by entering the data requested about the structured supportive actions.

  • A monitoring with feedback happens by a computation of structured supportive actions on documented data.

The mobile application transfers all collected data to the web application for further processing and planning of the next supportive actions. From a conceptual perspective, this closed-loop workflow thus follows the principles of sequential decision-making [16].

2.1.5 Technology

The ONCORELIEF solution approach from a technical perspective comprises the following core components:

  • The web application runs on an Azure cloud, is implemented in PHP, and connects to the surrounding services such as the AI engine and the user interfaces with Docker and Apache technology.

  • The patient data from electronic health records located at hospitals are transferred into the web application via a VPN connection and SFTP server. It is then transformed and further processed into the FHIR standard and in JSON format [18].

  • The important case data and the acquired patients’ health and sensor data are administrated in a FHIR and an InfluxDB database, respectively [17].

  • The relevant FHIR data categories contain information about the patients’ registration, patient information, medical history, concomitant medication, adverse events, laboratory examination, comorbidities and symptoms, and the status of their supportive actions.

  • The AI framework and the recommendation planner are implemented in Python and Django. The mobile application is implemented in JavaScript, TypeScript, and ReactNative. Data exchange takes place via APIs and file-based interfaces based on the FHIR standard and JSON format.

2.1.6 Data protection and data security

The data analysis, the planning of supportive actions, and the communication between web application and mobile application comprise the processing of highly sensitive patient data. These work steps thus require the implementation of sufficient measures for data protection and data security:

  • Access to the web application requires protected user accounts for the authorized health-care professionals. The patient cases contained by the web application are assigned to the health-care professionals in charge and can be accessed only by them.

  • All patient data processed in ONCORELIEF come from patients who have agreed on the use of their data for these purposes by signing a clinical consent form. The patient data undergo a de-identification as far as the analytic and planning tasks allow this.

  • The connection from a patient’s mobile application to the web application requires an authorization step, and the transfer of sensible data between the applications uses encryption mechanisms.

2.2 Modeling of aftercare

2.2.1 Patients cohort and questionnaires

The ONCORELIEF solution approach to aftercare for cancer patients in its current configuration addresses acute myeloid leukemia (AML) and colorectal cancer (CRC) [19, 20]. These oncological disease patterns relate to 11 major reported symptoms and patients’ needs requiring advanced aftercare, see the first and second column in Table 1.

Table 1 Considered disease patterns, related symptoms or patients’ needs, and corresponding questionnaires
Full size table

The assessment of the patients’ health perceptions with respect to these symptoms and needs is done with corresponding standardized questionnaires, see the last column in Table 1. These questionnaires contain 5–30 single questions with standardized ordinal value ranges for the answers, which allow for a clear interpretation from good to bad. This way of collecting data guarantees meaningful and comparable results, and the answers also allow for an easy transfer into numerical values suited for a smooth processing in data analysis. In general, the questionnaires allow for a symptom-based data retrieval and planning of supportive actions for aftercare. Further medical details about disease patterns, symptoms, patients’ needs, and questionnaires are given in [21].

2.2.2 Supportive actions

A review of medical guidelines for the considered disease patterns has led to the specification of altogether 25 supportive actions [4]:

  • Acupuncture

  • Anti-depressant therapy

  • Group therapy

  • Healthy nutrition

  • Medical treatment

  • Mindfulness-based stress reduction

  • Nutrition consultation

  • Patient information

  • Physical activity

  • Positive social relationships

  • Psychiatric consultation

  • Psycho-educational therapy

  • Psychological consultation

  • Recommendations against appetite loss

  • Recommendations against hair loss

  • Recommendations against the hand-foot syndrome

  • Recommendations against lack of sexual interest

  • Recommendations against sleep disturbances

  • Recommendations against sleep problems

  • Recommendations against sore mouth

  • Recommendations against weight changes

  • Recommendations against weight loss

  • Scrambler therapy

  • Supportive care

  • Treatment of medical causes

Each supportive action is in particular applicable for certain symptoms arising from one of the considered disease patterns.

Structure of supportive actions: Actions are specified in the following way:

  • An action is described in terms of its parameters with their individual identifier, value type, value range, position, and multiplicity in the action.

  • Each action parameter is visualized individually with a label, surrounding text, and type of initialization including optional initial values and privacy settings.

  • An action contains arbitrarily many logical conditions encoded in second-level predicate logic on the action parameters, text descriptions, and optional quality scores [24].

Supportive action parameters: The parameter structures of supportive actions look like the following one for the exemplary action Physical Activity:

figure a

The indentation and brackets represent the hierarchical tree structure with nodes and leafs. The items represent the parameters with their identifier, value type, and multiplicity. Supported value types are text, nominal, ordinal, integer, float, date, and node. Feasible multiplicities are at most once, exactly once, at least once, and arbitrary.

All supportive actions share the general structure of Action information, Action status, and Action documentation in order to allow for their easy handling by patients in the mobile application. They also all contain the nominal parameter Action progress, which indicates whether the action has not started yet, is running or was interrupted, canceled, or finished. Furthermore, they all contain the parameter Action result, which encodes the outcome on an ordinal scale with 7 values. These two parameters allow for clear interpretability and comparability of status and outcomes of actions in data analysis. The actions thus feature an action-oriented data collection and course-based planning in aftercare and thus complement the symptom-based approach followed with the questionnaires.


Visualization of supportive actions: The visualization of a supportive action in the mobile application follows the tree structure of its parameters and thus provides patients with a comprehensible and intuitively organized display of information. The specification of the action visualization also defines the privacy of action parameters. This means for the considered action Physical activity that Action information and its child nodes can be only edited by health-care professionals and Action status only by patients. Action documentation is shared, i.e., patients can add and edit nodes of the type Activity entry and its children, whereas the other child nodes are reserved for health-care professionals. These privacy settings make sure that the patient–individual configuration of a supportive action cannot be changed unintentionally by a patient.

Logic of supportive actions: The action Physical Activity contains 15 logical conditions with corresponding text messages and evaluations, which gives a good impression of the amount of monitoring logic contained in a single supportive action. The conditions are used for an automated quality management for the documentation of actions and also their monitoring in the mobile application according to the requirements of health-care professionals.

(NOT (EXISTS Action_documentation.Activity_entry

FULFILLS (Activity_entry.Activity_date GREATEROREQUAL

(CURRENT_DATE MINUS

Action_documentation.Frequency_recommendation))))

This condition checks whether there is no node entry Activity entry with an Activity date within the period determined by Frequency recommendation and the CURRENT DATE. It is thus part of the automated quality management in the documentation of actions. CURRENT DATE and the other key words written in capital letters represent operators in the used logic language. The point between Activity entry and Activity date is another operator for switching from a node to one of its children. Many logic languages like the Arden syntax encode conditions in a procedural format, which is difficult to comprehend for users without knowledge in formal mathematics and computer science [25]. The logic language used in this context encodes conditions in a readable format, which can be easily understood and validated by health-care professionals. Once the conditions are formulated, their dependency on certain action parameters allows for an easy individualization of actions by just a modification of parameter values. This again follows the preferable approach for the use of AI methods [15]. An explicit editing of conditions would have required an advanced understanding of certain concepts from formal mathematics and computer science.

(EXISTS Action_documentation.Activity_entry FULFILLS ((Activity_entry.Activity_date GREATEROREQUAL (CURRENT_DATE

MINUS Action_documentation.Frequency_recommendation))

AND (Activity_entry.Duration SMALLER

(Action_documentation.Duration_recommendation MULTIPLY 0.8))

AND (Activity_entry.Activity_date ALIAS Short_activity_date FULFILLS

(NOT (EXISTS Activity_entry FULFILLS ((Activity_entry.Activity_date

GREATEROREQUAL Short_activity_date) AND (Activity_entry.Duration

GREATEROREQUAL

Action_documentation.Duration_recommendation)))))))

This condition checks, if there is a node of type Activity entry with an Activity date within the period determined by Frequency recommendation and CURRENT DATE and a Duration below 80% of the Duration recommendation specified by the health-care professional, and there is no other Activity entry with a more recent Activity date, for which the Duration recommendation was fulfilled. In the event that this condition is fulfilled, the mobile application shows a reminding text message to the patient that he/she should fulfill the recommended duration of the physical activity specified by his/her health-care professional.

Usage and computational expense: The considered Physical activity as one of the most complex supportive actions contains six parameters that may require an individual adaptation by a health-care professional to a patient’s individual needs. There is Action date, Action description, Action duration, Activity type, Duration recommendation, and Frequency recommendation. For most of these parameters, this adaptation means only a selection of an another value than the default setting from a predefined value range. Health-care professionals will typically provide their patients with new instructions on a time scale of several weeks, and there are typically by far less than 10 supportive actions running in parallel for one patient. Hence, the accumulated manual effort of a health-care professional for providing a cancer patient with good support in aftercare is small.

Physical activity is also one of the most complex supportive actions from a patient’s perspective. A patient must edit the three parameters Action start, Action progress, and Action result once and every few days, depending on the Frequency recommendation by his/her health-care professional, create a new instance of Activity entry with value entries for Action date, Action duration, and Rating of perceived exertion. Some of these parameters like Action date may obtain their initial values by the mobile application, and all of them can be edited by simple selection from a predefined value range. The total documentation effort for a patient is thus rather small, in particular in view of the obtained benefit of automated monitoring and generally improved guidance by his/her health-care professional.


The two presented conditions contain 8 and 25 single logical or arithmetic operations with unary or binary operators, which gives an idea of the typical complexity of monitoring conditions. Although quantor operators such as EXISTS (...) FULFILLS may require computations for multiple parameter entries like Activity entry, the computational expense for a single condition is very low. The rather small number of conditions belonging to a single supportive action and the small total number of actions running in parallel yield an accumulated computational expense, which can be processed easily by a smartphone CPU in real time.

Maintenance effort: The questionnaires and supportive actions form the core contents of the considered model for aftercare in cancer patients and shall thus reflect the current state of knowledge in cancer therapy and patient support. Therefore, the development of medical knowledge requires regular updating of the models according to the establishment of new questionnaires or publication of new treatment guidelines designed especially for patients. Such new questionnaires or modifications of guidelines typically take place every few years, which defines the time interval for the required model updates. For the ONCORELIEF solution approach, such an update means in particular a revision of the supportive actions contained in the register and possibly the integration of new actions. The establishing of the current model has shown that the most time-consuming step in converting the guideline description of a recommendation and its application into a supportive action of the aftercare model is the joint conceptual work of health-care professionals and IT experts. Once this work is finished, the creation and testing of a new supportive action is a matter of at most about an hour. The accumulated maintenance effort is thus sufficiently small.

2.3 AI-based data analysis

The method approach for analyzing patient data in order to generate results suited for the planning of supportive actions depends not only on the acquired patient data, but also strongly on the comparative data available for relating the considered patient case to. The ONCORELIEF solution approach, therefore, contains several alternative approaches for data analysis.

2.3.1 Graphical data exploration

A straightforward approach to the planning of supportive actions is software-assisted manual exploration of patient data. The web application for this purpose provides a graphical user interface for accessing the databases, see Fig. 2 for the InfluxDB database containing the acquired sensor data. This user interface allows for a search of patient cases, their visualization in a dashboard and a data exploration with methods from signal processing and by graphical means.

Fig. 2
figure 2

Dashboard of the patient database: patient case with visualization of vital signs data (top) and functionality for configuring the visualization and exploring the data (bottom)

Full size image

2.3.2 Rule-based systems

In the event that too little comparative data are available for configuring an ML/DL method with, ONCORELIEF provides a purely model-based approach to infer appropriate supportive actions from patient data. In this approach, logical rules are formulated in which patient case situations which supportive actions should be considered for application [26]. Computation of these rules for the considered case yields the principally applicable actions. Table 2 provides examples, how disease patterns and reported symptoms connect semantically with relevant supportive actions.

Table 2 Exemplary semantic connections between reported symptoms and relevant supportive actions
Full size table

It is then counted for each supportive action according to how many fulfilled rules it is in principle applicable for a considered patient case. These numbers are then transferred to the planning step, where they provide the health-care professional with a first orientation which actions to consider for aftercare in the specific planning situation.

2.3.3 Machine learning methods

Availability of many former patient cases for comparing the considered patient data allows for classical purely data-driven AI approaches. For such purposes, the ONCORELIEF solution approach contains a range of more than 10 AI-powered standalone method components. The provision of these methods for analytic tasks and the conduction of these tasks happen with the AI engine, which facilitates the design and configuration of an AI analytics pipeline for any ML/DL algorithms. These algorithms have been trained with suitable comparative case data to provide a specifically-oriented outcome. The expected input of the pipeline is explicitly defined and may range from batch data stored in storage areas to near real-time data directly sent to trigger the execution of the analytic task. The desired output can be provided in two different ways, as a visualization that can be saved by the health-care professional or as raw data that can be retrieved from another component.

The services bundle in the AI engine consists of the analytics configurator, the visualization and reporting engine, and the analytics execution service. The analytics configurator practically serves as the interface of the AI engine for the creation of AI analytics pipelines, their application for analytic tasks, and the exploration of the obtained results, see 3.

Fig. 3
figure 3

Interface of the AI engine: libraries for the four block types, namely, data input, data pre-processing, analytics model, and data output (upper left), with the lists of available blocks for selection (lower left), canvas display for creating AI analytics pipelines with the blocks from the libraries through drag-and-drop functionality (center), and menu with individual configuration options offered for each selected block (right)

Full size image

The creation of an AI analytics pipeline essentially comprises the selection and configuration of the input data, the specification of their step-by-step pre-processing and analysis, and the configuration of the export of results. The analytics configurator for this purpose provides libraries of easily configurable algorithmic blocks, such as filtering and aggregation methods, statistical methods, or ML and DL models in pre-trained and customizable form [27,28,29]. A data analytics expert selects the required blocks from the libraries menu and arranges and connects them in a canvas display of the analytics pipeline with a drag-and-drop functionality. He/she then configures the single algorithmic blocks and their connections by clicking on them and entering suitable method parameter settings. This editable flowchart view of AI analytics pipelines allows for their intuitive specification without any interaction on the level of method implementations. New methods can be added easily by just importing their executables into the libraries of the analytics configurator.

The visualization and reporting engine is an integral part of the AI engine services bundle, as it gives the ability to visually gain insights from specific health data elements and/or analytic results. The engine allows for the creation of reports, which may combine various visualizations as well as data samples. The visualization and reporting engine works closely together with the analytics execution service to ensure that the results are properly displayed in the preferred way selected by the user.

The analytics execution service is responsible for executing analytic tasks as specified with the analytics configurator. This service is triggered according to the execution schedule defined during the configuration of the particular analytic task and shall guarantee for the necessary computing and memory resources. The results of each task are saved and can be retrieved later, if necessary.

A larger amount of data about a patient case and of comparative data from former cases allows for more meaningful results of AI-based analysis for the planning of supportive actions compared with the previous purely model-based approach. Furthermore, many of these AI methods amend the results of analysis with context information about their occurrence in terms of some performance indicators. Such information can help health-care professionals during the planning phase for assessing the soundness of a result correctly. This is illustrated in [30] for results from a random forest method, which provides sensitivity and specificity, the majority vote and variable importance values as context information [31]. Such a method approach follows the conceptual goal of XAI methods to provide more insight into the origin and quality of results of analysis [32].

The AI engine thus targets data scientists and possibly people with a background on AI, who understand the algorithmic concepts, sequential processing of large data sets, trial-and-error analyses, etc. The interface of the analytics configurator allows data scientists to build pipelines in an effective and less time-consuming manner, utilizing ready-made models and analytic functions offered as components, and to experiment with the outputs, train models, and eventually expose the results either via visualization dashboards, or through APIs to feed them into other applications.

2.3.4 Statistical analysis

The availability of sufficiently many comparative data also motivates the application of statistical methods for generating empirical value about how to handle new patient case scenarios. The ONCORELIEF solution approach, therefore, provides several clustering methods for analyzing comparative case data of different types and for different purposes. For example, a data situation with rather homogeneously distributed and not too sparse data can be addressed with the DBSCAN algorithm, which does not require a predefined number of clusters and can also find arbitrarily shaped clusters [33]. This situation corresponds to the scenario of a yet not examined and sufficiently large cohort of representative patient cases. The analysis of data sets of rather small dimension could, for instance, be done with the the K-nearest neighbors (KNN) algorithm, which is typically a good choice for classifying new patient cases to existing clusters of former patient cases [34]. This corresponds to the practical scenario of a steadily growing set of comparative data. Such classification of new cases could also be done with gradient boosting, which is often a good choice for processing inhomogeneous and incomplete data, a pretty common situation in a medical context [35].

After examining the created clusters for suitable supportive actions, the previously described rule-based approach can be also used for an assignment from clusters to actions. Performance indicator values such as the homogeneity of the cluster, which a patient case was assigned to, again provide helpful context information for a more qualified interpretation of the result. Hence, the transfer of such information into the planning phase again follows the general objective of XAI.

2.4 Decision support for health-care professionals

The results of the AI-based data analysis serve as input for the planning of supportive actions by the health-care professionals. The planning module of the ONCORELIEF framework is configured with the supportive actions provided by a register. This register contains descriptions of the standardized questionnaires and the supportive actions in the form of structured files. New supportive actions are made available for planning by a simple file import and validation into the web application. The imported results of analysis are matched with the supportive actions contained in the register based on their names.

2.4.1 Planning of supportive actions

The search for suitable actions and their selection is treated as a multi-criteria decision problem in the web application [36]. Here, the names of the supportive actions and the optional performance indicators from the AI method form the planning criteria, and the AI results provide the evaluations in the criterion space. An example for a additional performance indicator beyond the pure AI classification result is discussed in [30], where the majority vote of a random forest method provides information for a ranking of the suggested supportive actions and the selection of the most suitable ones.

Health-care professionals can use search, sort, and filter functionality on these criteria, then select one or more desired supportive actions and finally adapt them to the individual needs of the patients’ by entering the values of the parameters released for editing. At the end of planning, the adapted actions are transferred to the mobile application on the smartphone of the individual patient. This happens by means of regular requests for new data from the mobile application to the web server.

The web application as a whole thus implements a division-of-labor approach. The potentially time-consuming and error-prone search for relevant actions is handled by AI methods, but the outcome-critical decision about which supportive actions to implement is up to the health-care professionals. With this approach, planning of aftercare follows the preferable approach for the ethically correct use of AI by keeping the human in the loop [15].

2.5 Patient empowerment and monitoring

2.5.1 Configuration of the mobile application

The mobile application has methods for the retrieval and interpretation of supportive actions and the processing of their contents. This processing includes the visualization of actions, the provision of features for their documentation, and methods for the evaluation of the entered data in monitoring. The mobile application is thus generic over the application-specific content. This separation allows for a configuration of the mobile application also with newly registered supportive actions without any software update.

2.5.2 Documentation of actions

The display and processing of supportive actions in the mobile application on the patients’ smartphones takes place analogously to the web application. Patients document the implementation of an action via the parameters released for this purpose. Most of these parameters have predefined value ranges and only a few support entries of free text. This allows for a easy usability based on value selection, guarantees a high quality of the crucial data, and their comparability in data analysis. The entered data are stored in the mobile application and transferred to the web application for data analysis upon the patient’s request. This ensures patients’ sovereignty over their own data.

2.5.3 Monitoring of actions

The monitoring of actions is done by computing the logical conditions, which were configured by health-care professionals for the patients’ individual needs, on the data entered by the patients. This approach ensures a clearly predictable behavior of the mobile application according to the instructions of the health-care professionals and enables patient care without permanent involvement of health-care professionals. After each editing in an action, the corresponding logical conditions are evaluated on the entered data, which again corresponds to the principle of sequential decision-making. A fulfilled condition triggers a text message to a patient, following the XAI objective to communicate results in a transparent way [32]. Completion of actions is at the patients’ behest followed by a data transfer to the web application for another step of AI-based data analysis. This would then trigger an adaptation of the ongoing supportive actions by the health-care professionals and thereby close the loop shown in Fig. 1.

3 Results and discussion

3.1 Medical evaluation

The ONCORELIEF method and technology framework for the AI-based planning of aftercare for cancer patients is being evaluated in an ongoing clinical study located at two hospitals in Germany and Italy. At the current time, which is May 2023, this study includes 46 CRC patients and 24 patients with AML. Details about this study such as inclusion and exclusion criteria, recruitment, enrollment, instruments, and actions are provided in [21].

3.1.1 Exemplary patient case

In this context, the solution approach is demonstrated for an artificial patient case inspired by the clinical study. This case features a female patient diagnosed with stage 2 colorectal cancer, who had a surgery followed by chemotherapy as adjuvant treatment without an ostomy. Some time after leaving hospital, the patient has reported mild depressive symptoms and early fatigue.

3.2 Data analysis and planning

The data imported and acquired about such patient cases are collected and administrated in the databases of the AI framework. These databases allow for a search of patient cases, their visualization in a dashboard, and an exploration of this data with graphical methods, see Fig. 2 in Sect. 2.3. This visualization of patient data provides health-care professionals with more detailed information about the specific planning situation beyond the results of AI-based data analysis and the suggestions of supportive actions in the recommendation planner.

3.2.1 Model-based planning

The patient case with the diagnosed disease pattern and reported symptoms may directly enter the recommendation planner for model-based planning. Initial configuration of the recommendation planner happens by initializing the register of supportive actions with the structured files, which specify the questionnaires and supportive actions of Sect. 2.2. Furthermore, the file describing the semantic connections between symptoms and actions in the form of rules is imported, see Sect. 2.3. Computation of the rules for the exemplary patient case gives the result of analysis shown in Fig. 4.

Fig. 4
figure 4

Model-based planning of supportive actions: survey of the most relevant actions with their proximity values

Full size image

For each supportive action, the number of fulfilled rules suggesting the application of this action is shown as a proximity measure. Larger values indicate higher relevance of an action. The two exemplary rules provided in Sect. 2.3 are both fulfilled and thus yield a proximity value of 2 for the action Physical activity. This purely model-based planning approach uses little patient data and no comparative data from former patient cases. Hence, the results may be rather imprecise and require thorough further consideration by health-care professionals.

3.2.2 Statistical data analysis

The statistics approach allows for an assignment of the considered patient to a cluster of patients with the similar constellation of disease pattern and reported symptoms and needs. Such assignment allows for conclusions on the most suitable supportive actions. The 46 CRC patients enrolled in the study mostly suffer of the symptoms of appetite loss, anxiety, and fatigue, which are reported with the corresponding questionnaires EORTC-QLQ C30, HADS, and BFI, respectively, see Table 1. The data of these patient cases were analyzed with the k-means clustering method and principle component analysis (PCA) and gave evidence of the following five clusters [22, 23]:

  • Cluster 1 (“Feeling well”): Patients report that they have good appetite, no mouth soreness, do not feel nauseated (EORTC-QLQ C30), and have positive attitude (BFI).

  • Cluster 2 (“Fatigue, vomiting, and negative attitude”): Patients report that they feel pain and vomit (EORTC-QLQ C30), have a low level of energy and a negative attitude (HADS), and feel tired (BFI).

  • Cluster 3 (“Gastrointestinal symptoms and positive attitude”): Patients report that they experience diarrhea and pain interfering with daily activities, feel nauseated and vomit (EORTC-QLQ C30), but have a positive attitude (HADS).

  • Cluster 4 (“Gastrointestinal symptoms and negative attitude”): Patients report that they experience diarrhea and observe a lack of appetite, feel nauseated and vomit (EORTC-QLQ C30), and have a negative attitude (HADS).

  • Cluster 5 (“Fatigue and no vomiting, negative attitude”): Patients report that they feel a potential lack of appetite, experience no mouth soreness or vomitting (EORTC-QLQ C30), experience fatigue (BFI), and a negative attitude (HADS).

The negative attitude, fatigue, and absence of gastrointestinal symptoms bring the exemplary patient case closest to Cluster 5. Close consideration of the former cases assigned to the cluster would then, based on the symptoms reported there, yield analogous conclusions about the relevant supportive actions than in the previous section.

3.2.3 Data-driven planning

More meaningful results can be obtained with a data analysis using ML/DL methods trained on the comparative data of similar former patient cases. The exemplary patient case enters the AI engine for an analysis with AI analytics pipelines that were already configured for the specific cohort the patient belongs to or that may have been individually established for identifying a specific patient’s needs, see Fig. 3 in Sect. 2.3. Figure 5 illustrates, how the planning of supportive actions may happen in such a situation based on the obtained results of analysis.

Fig. 5
figure 5

Data-driven planning of supportive actions: survey of all available actions with their assessments for individual relevance (left) and selection of actions for further adaptation (right)

Full size image

The recommendation planner displays all the supportive actions with their respective relevance computed by the AI method in use for further exploration with the available planning functionality. In this situation, the health-care professional has sorted the actions according to their relevance and selected the actions Psychologic consultation and Physical activity. He/she has then adapted the Physical activity to the patient’s needs by entering suitable values for the accessible recommendation parameter. Since the patient has not undergone an ostomy and thus does not have a stoma bag, Recommended activity can be set to the value Swimming. The values for Recommended duration and Recommended frequency are also suitably chosen. In the sense of the division-of-labor approach followed by the ONCORELIEF planning framework, health-care professionals have full freedom of decision for the selection or adaptation of actions for their patients. After completing the planning phase, the individually adapted actions are transferred to the mobile application on the patients’ smartphone.

3.3 Processing of supportive actions

3.3.1 Answering of questionnaires

The mobile application provides the patient with a survey of the questionnaires to answer as shown in Fig. 6 (left). After selecting a questionnaire, the application switches to a full-screen view for this questionnaire, which can be navigated by answering the single questions. Here, the patient has first opened the questionnaire PHQ, then answered the first questions, and now deals with the open ninth out of ten questions as shown in Fig. 6 (right). In this view, the patient selects one of the answer options and thereby creates data in a meaningful and comparable format, which is suited well for further processing in the AI-based data analysis.

Fig. 6
figure 6

Processing of questionnaires with the mobile application: survey of questionnaires (left) and full-screen view of a single questionnaire with single questions (right)

Full size image

3.3.2 Documentation of actions

The mobile application also provides the patient with a survey of the course of previous and current supportive actions as shown in Fig. 7 (left). After selecting an action, the mobile application switches to a full-screen view for this action, which can be navigated by clicking the views for the contained nodes. Here, the patient has first opened the action Physical activity and then clicked on the node Action documentation to obtain the view shown in Fig. 7 (middle). In this full-screen view, the patient obtains the specific data entered by the health-care professional about how to apply the supportive action and is provided with input options for its documentation.

The patient documents the considered action Physical Activity by adding instances of the node parameter Activity Entry, which, in turn, contain the parameters Activity date, Duration, and Rating of Perceived exertion (RPE) [37]. These parameters have predefined value ranges, making the data entered clearly interpretable and comparable among multiple instances of themselves. The same applies to the node Action status and the contained parameters Action start, Action progress, and Action result, which are filled in to document the perceived course and outcome.

Fig. 7
figure 7

Processing of supportive actions with the mobile application: survey of actions (left), full-screen view of a single supportive action for information and documentation (middle), and monitoring feedback on this action (right)

Full size image

3.3.3 Monitoring of supportive actions

Every documentation activity in a supportive action automatically triggers an evaluation of the associated logical conditions. A fulfilled condition triggers a text message to the patient, which is displayed in the supportive action view as shown in Fig. 7 (right). In the considered situation, the patient has documented the Physical activity as required with a new entry of the type Activity entry and has implemented the supportive action according to the requirements by the health-care professional and thus receives the according text feedback from the mobile application.

4 Conclusions

This work presents a solution approach for providing AI-based and digitally assisted aftercare for cancer patients developed in the EU project ONCORELIEF. The approach is developed for the exemplary disease patterns of colorectal cancer and acute myeloid leukemia. The generic concept of the approach, however, allows for a transfer into other medical and non-medical fields of application. The solution approach addresses the requirements and development opportunities for a viable solution described in the scientific literature in the following way:

  • The contained methodical and technological components connect to each other and thus allow for an integrated closed-loop workflow. Furthermore, there is interoperability with electronic health records of patients and thus connectivity to existing clinical software environments.

  • A web application designed for health-care professionals provides a broad range of methods for analyzing patient data. Situations with little available data can be dealt with model-based approaches relying on encoded medical knowledge. For scenarios with highly complex patient data and many former patient cases to compare with, the framework offers several ML/DL methods. Methods from statistical analysis cover a hybrid approach featuring both model-based and data-driven elements.

  • Based on the patient data and the obtained results of analysis, the web application also assists health-care professionals in the selection of standardized symptom-specific questionnaires for collecting data about patients’ health perceptions and the efficient planning of supportive actions adapted to patients’ individual needs. For this purpose, a recommendation planner provides interactive decision-making functionality and a register with questionnaires and supportive actions in the form of structured file templates.

  • A mobile application assists cancer patients in the answering of received questionnaires and the documentation of ongoing supportive actions. The mobile application also runs a monitoring on the collected patient data in order to guide patients in the sense of the health-care professionals. Hence, digital assistance is provided to all the involved stakeholders with separate software systems.

  • A regular data transfer between mobile application and web application supports patients in effective aftercare guided by health-care professionals without their permanent involvement and beyond regular attendance of medical consultation hours, thereby ensuring a close communication and cooperation of patients and health-care professionals.