Analysis and Development of Telemonitoring Applications: A Model-Based Approach

1. Introduction

The digitalization of the German healthcare system is still at a low level compared to other European countries [1, 2]. Examples of this are the physician’s letter, medical prescriptions, doctor’s appointments, or the storage of treatment and personal health data [3]. While it was possible to provide unlimited treatment services with the help of video consultations during the coronavirus pandemic, this exceptional arrangement has been limited again to 30 percent of the number of cases and service volumes [4]. According to recent surveys, a majority of German citizen welcome the use of digital medical solutions [5, 6], digital or telemedical health applications (DHA) that enable patients to manage themselves. Nevertheless, DHAs primarily focusing on therapy-supporting processes so far have not been widely used to date [7].

The reasons for this are mainly the skepticism of the healthcare providers towards new, digital applications, the lack of evidence due to heterogeneous or inconsistent data from clinical studies, the complexity of DHAs, and the sometimes-missing therapeutic adherence of the patients themselves. As of today there exist a large number of telehealth applications that are used in projects or operated on the basis of selective contracts. So far they have not yet been integrated into standard care, at least not into the German healthcare system. In addition, the current Telematics Infrastructure 1.0 of the German healthcare system prevents the integration of mobile and telemedical solutions from third-party providers due to the restrictive, hardware-based access of the eHC to the secured network [8].

Only a comprehensive, end-to-end digitalized healthcare system offers the advantage of reducing frequent media disruptions and thus accelerating process chains between doctors, patients, health insurance companies, and manufacturers. In order to intensify the use of digital health applications, the necessary awareness and user skills also must be improved on both, doctor’s and patient’s side. In a broader context, this also requires the digitalization of administrative processes in health care so that both doctors and patients experience positive user experiences.

The German government recognized this challenge and took up several political initiatives in order to accelerate the end-to-end digitalization of the German healthcare system. With the corresponding legislative procedures, the Federal Ministry of Health has recently shown how a common platform for digital applications can be established in Germany’s federal and self-governing healthcare system [9, 10, 11]. At a technical level, the first underlying conditions for this have already been defined by the integration of DHAs into the German telematics infrastructure (TI) [8]. For example, approved DHAs will in future have to write their recorded health data into the electronic patient record (ePA) via a backend interface according to Section 374a SGB V [12]. The establishment of standardized data structures (so-called DiGA MIOs [13]), e.g., for the integration of measurement data from medical devices or wearables into the ePA, is also central to this.

One of the central tasks in the German healthcare system is therefore to successively integrate the stand-alone DHAs into the future IT healthcare infrastructure TI 2.0 and to define the necessary technical and organizational steps towards this. With digitalization of healthcare processes, doctors and patients could access the same treatment data in order to keep themselves closely informed about the course of disease. The data collected via telemedicine could be used by physicians to make data-driven therapeutic decisions and motivate patients in their everyday lives. Prescription or ordering processes for apps and medical devices could also be faster, and digital services could be accessed more quickly. As with conventional therapies, the acceptance of digital applications and adherence are crucial factors for the positive, sustainable effect of a DHA.

2. DiGA.Pro project goals and impact on telemonitoring applications

For this reason, an analysis of exemplary DHAs is to be carried out as part of the DiGAPro project in order to identify the optimization potential for even more patient-centered digitalized care services [14]. Current “Digitale Gesundheitsanwendungen” (dt. DiGA/engl. DHA) listed in the BfArM directory are predominantly focusing on patient self-management [15]. The existing reimbursement model of the “App on prescription” does not yet cover data access by doctors or remote interventions in the therapy process based on digitally assessed data. Therefore, based on an analysis of the current state of DHAs one project objective is to demonstrate the possibilities of a more comprehensive and consistent interaction of IT-based care processes and their associated potential. Digital health applications should therefore be an integral part of digitally supported care and not only cover the narrowly defined subprocess of self-management.

How can such comprehensive care processes be created around DHA in the future? The DiGA.Pro project aims to investigate how linking DHA with other digital applications or analog healthcare services leads to overarching care processes in such a way that good and needs-based processes are created not only for patients, but also to the same extent for healthcare service providers, which effectively support everyday treatment. The project aims to develop solutions how DHA’s, in conjunction with the eHR and other digital applications and services, can support data-driven, patient-centered, and hybrid care processes. The project takes up gematik’s considerations on the further development of the Telematics Infrastructure (TI 2.0) and fits in with the BMG’s activities to implement its digital strategy.

By analyzing innovative approaches on the market, from German Innovation Fund projects [16], from special care contracts, and from good practices in the healthcare systems of other countries, the DiGA.Pro project designs how user-centered digitalization can create added value for patients and other stakeholders in specific care scenarios. The considered scenarios range from technology-driven topics such as connecting aids to DHA to integrated forms of care across sectors and professions, such as digitalized Disease Management Programs (DMP). All scenarios considered in the DiGA.Pro project are hybrid, i.e., they aim to integrate medical, nursing, and digitally provided services. Patient-centricity, personalization, and performance measurement form cross-sections across all scenarios considered. In order to develop and analyze these care scenarios, a model-based approach was chosen.

3. The DiGA.Pro approach

The fact that the end-to-end digitalization of care and administrative processes can have many positive effects is to be verified in this article using the model-based approach and proven on the basis of the quality metrics applied. For this purpose, individual care processes such as the prescription of a DHA, the ordering of a medical device, or access to treatment data by the doctor are broken down into their atomic process steps and modeled. In this way, the basic interactions can be assessed, typified, and stored with value sets so that a more in-depth analysis of the enabling and hindering parameters is possible. In contrast to the large number of telemedical test projects carried out, a model-based approach has the advantage that, based on prior knowledge and empirically collected values, more generalized considerations can lead to comparability, harmonization, and standardization of care processes and environmental parameters. The model-based approach also has the advantage that the graphical notation can be used to visualize the complex relationships between care processes, IT infrastructures, and digital health or sensor applications in order to understand their workflows. An initial analysis of these relationships can be carried out during the requirements analysis and design phase to identify necessary features and interactions even before the actual implementation of the functionality starts. A model-based approach can also be used to visualize and analyze the processes and relationships for already existing IT applications.

Based on the case studies, this article will show how DHAs are used in their status quo and what the migration path toward end-to-end digitalized processes chains would look like. In particular, the detailed concept for TI 2.0 will be used to compare the status quo and the target picture [8]. The model-based approach can be used to identify the underlying process and software architecture patterns of DHAs that are similar to the components and services of the TI of the German healthcare system. This allows us to identify the potential for adapting these components to the concepts of the TI and, vice versa, the potential for aligning the components and services of the TI with the DHAs. Finally, by modeling different evolutionary phases of development, the migration path for a gradual integration of DHAs into the TI 2.0 can be shown.

4. The German telematic infrastructure 2.0

The Telematic Infrastructure (TI) 2.0 aims to increase acceptance through a user-centric approach. To reach this goal a technology leap is deemed necessary to establish an architecture enabling developments in new areas besides outpatient and inpatient care like digital health apps (DHA). To reach this goal the TI must become more technology independent and dissolve data silos to enable mobile patient-centric solutions. Hence, key properties of the TI 2.0 are:

• A flexible and user-friendly identity management

• Universal availability of TI services

• Robustness and adaptive modern security concepts (zero-trust)

• Intersectoral and international interoperability (FHIR and more)

• Data sovereignty in distributed services

• Services and application over spanning integration of data.

In the TI 1.0 service availability is limited through the necessary use of the so-called TI Konnektors functioning as secure hardware or cloud gateways. This necessity will be obsoleted through the introduction of the zero-trust concept in the TI 2.0, where services and users are constantly monitored and evaluated against a security model. This environment will be part of the basic services provided by the gematik upon which enhanced services can be provided by trusted and certified third-party vendors. Together with the new federated identity management, this will enable a more open participation of new user groups interacting with a broader range of services.

Through the TI 2.0, the gematik will still provide core infrastructure services such as OSCP and VSDM used for key functionality like key and certificate management and encryption. On top of these services, the gematik will provide additional services in cooperation with partners like:

• Basic services of the health insurance like:

  • ePA (“elektronische Patientenakte”) which is the electronic health record containing all the recorded relevant data about the patient.

  • eID (“GesundheitsID” /identity) represents the digital identification mechanism for the patient within the TI.

  • eMP (“elektronischer Medikationsplan”) represents the electronic medication plan stored in the ePA to be accessed by physicians.

  • NFDM (“Notfalldatenmanagement”) contains the important data about a patient in case of an emergency.

• Services provided by billing centers of pharmacies like:

  • eRezept allowing pharmacies to hand out prescriptions and to bill them accordingly.

• Mostly independent third party will provide additional services like:

  • KIM (“Kommunikation im Medizinwesen”) is secure email-like asynchronous communication.

  • TIM (TI Messenger) provides messaging capabilities to the TI 2.0.

Every service and service provider will need to be certified by the gematik to participate in the TI 2.0. This is also valid for typical TI 2.0 client systems like:

• DHA (“Digitale Gesundheitsanwendung”) is a personal digital health app for patients.

• PVS (“Praxisverwaltungssystem”) is a practice management system for general practitioners.

• KIS (“Krankenhausinformationssystem”) is a hospital information system.

Based on these new concepts, the TI 2.0 is likely to become an innovative ecosystem for user-centric applications, medical research, and industry [17].

5. A model-based approach for analysis and adaptation of telemonitoring applications in healthcare processes

Model-based approaches encompass a set of methodologies that revolve around the utilization of models for comprehending, designing, and developing complex systems. Models can serve as abstract representations of real-world characteristics, system’s structures, behavior, and requirements, capturing its essence and facilitating communication among stakeholders and system developers. By employing models as central elements, model-based approaches aim to enhance the consistency, accuracy, and efficiency of system development.

The core principle of model-based approaches lies in creating a common language and shared understanding of the system through the use of models. Models serve as blueprints, enabling stakeholders across various disciplines to collaborate effectively and ensure that the system aligns with their expectations. By establishing a common language for communication, models break down knowledge silos and foster a cohesive approach to system development [18]. Model-based approaches also promote the reusability of design elements and specifications, streamlining the development process and minimizing redundancies. By capturing the essence of the system in models, developers can easily reuse and adapt existing models, reducing the need for repetitive work and accelerating the development cycle [18]. Furthermore, through models, systems also can be simulated and analyzed, providing valuable insights into their functionalities and potential areas of improvement. Hence, model-based approaches facilitate early detection of errors and inconsistencies within the system. As models become integral to the development process, they serve as testing grounds for identifying and addressing potential issues before implementing them. This proactive approach to error detection saves time and resources in the long run [19].

A primary challenge in applying the model-based approach is finding the right level of abstraction. Too much simplification can lead to the loss of crucial details, while insufficient abstraction can result in overly complex models that are difficult to interpret and use. To be able to compare alternatives in processes and models it must be ensured that the models are modeled at the same abstraction to gain meaningful insight. In our project, the chosen modeling language must also be able to capture healthcare processes and reflect the dynamic nature of health care.

To analyze and improve telemonitoring applications and their surrounding processes in the DiGA.Pro project, a model-based approach has been chosen. Modeling of conventional and digitalized care processes can help to define patterns for needed harmonization and standardization of care processes and IT infrastructures. Up to the present day, BPMN has been recognized for its graphical notation, which is intended to be comprehensible by all business users. The model-based simulation of potential process outputs can result in cost-effectiveness before implementing and evaluating these processes in real life.

By providing a reliable description of the care process underlying information exchange and data management, the application of standard-based solutions becomes more straightforward. This is particularly crucial in healthcare settings, where multiple systems need to interact seamlessly to provide efficient and effective patient care [20, 21, 22]. Despite its potential to facilitate common understanding and promote automation, BPMN has witnessed some usage in health care, attributed to the complexity inherent in healthcare processes and the domain’s highly regulated environments [23].

The utilization of a model-based approach in health care is illustrated by studies like those of Bowles et al. [24] and De Ramón Fernández et al. [25]. These studies demonstrate the effectiveness of business process management (BPM) in optimizing healthcare resource planning and improving process efficiency in clinical settings. Such evidence underscores the usefulness of model-based approaches in enhancing healthcare process efficiency and quality. Bowles et al. annotated BPMN models for optimized healthcare resource planning. Through the utilization of precise metrics on BPMN diagrams, a quantitative examination of healthcare processes was made feasible, facilitating a more focused and significant analysis that ultimately produced valuable insights into the annotated BPMN models [24].

In their 2020 study, De Ramón Fernández et al. delve into the application of BPM in the healthcare sector, focusing specifically on clinical processes. The research aims to assess the effectiveness and quality improvements gained through BPM methodology in clinical settings. A systematic literature review was conducted, analyzing 18 articles that met predefined criteria. The findings indicate that BPM is an effective tool for designing, optimizing, and automating clinical processes. The study also highlights the need for comprehensive follow-up, better technological support, and greater clinical staff involvement to fully realize BPM’s potential in health care. This research supports the use of BPM as a methodology to enhance process efficiency and quality in healthcare environments [25].

By mapping out the sequence of activities, decision points, and interactions between healthcare professionals, BPMN diagrams provide a comprehensive view of how patient care unfolds. This visualization aids in identifying bottlenecks, redundancies, and opportunities for improvement [26]. BPMN models can be used for what-if analysis. By altering process parameters or introducing hypothetical scenarios, healthcare organizations can anticipate the impact of changes before implementing them. This proactive approach minimizes risks and ensures that process modifications are evidence-based [27]. BPMN models can be enriched with additional information, highlighting touchpoints and interactions from the patient’s perspective. This perspective ensures that healthcare processes are designed with the patient’s well-being and experience in mind [24].

Nevertheless, evaluating DHA and care processes has several challenges when using the model-based BPM approach: The lack of harmonized evaluation methods across various domains creates a significant barrier to comparing and assessing the effectiveness of solutions, impeding informed decision making and adoption of optimal practices [25]. Generic BPMN models, while useful, often fail to fully represent the intricacies of health care, overlooking factors like patient outcomes and healthcare provider satisfaction [28]. Data integration difficulties with existing healthcare systems further are leading to data silos and hampering effective data utilization [29]. Additionally, data quality and reliability concerns significantly impact decision making, necessitating robust data management strategies [30]. Finally, the fragmented ownership and decision making in digital health initiatives hinder collaboration and effective implementation in care processes, calling for a more coordinated approach to ensure alignment and shared responsibility [31].

Addressing these challenges is crucial for modeling and analyzing digital health solutions in the healthcare sector. Furthermore, to apply models effectively in health care, the definition and application of appropriate metrics are crucial. Therefore, these metrics should accurately reflect the analysis goals, aiding in the measurement and evaluation of process efficiency and effectiveness. Only by this the model-based approach allows for identification of improvement areas, leading to optimized healthcare processes.

5.1 The DiGA.Pro metamodel

In the DiGA.Pro-project a metamodel and an analysis matrix were defined to analyze the underlying technical and application processes. The metamodel (Figure 1) describes all actors, the processes, and process steps, the communication paths used, and the processed data as classes in object-oriented modeling using UML class notation. Based on the DHAs considered, the overarching system relationships were reflected in a metamodel, which serves as the basis for analyzing the processes and applying the metrics. It allows the assignment of individual activities for composite care and treatment processes. Each class of the analysis matrix contains individual value sets. The value sets make it possible to assign attributes to the classes of the metamodel. In the DiGA.Pro metamodel, the following classes are represented:

A care or treatment process consists of one or more process steps. The process step is defined as a semantic unit in order to group inherent or successive activities. In a process step, one or more activities can be carried out by one or more actors. Activities are divided into medical, technical, or organizational activities. They can be carried out by a technical system (a technical component), a physical person (doctor, patient, administrator, etc.), or an organization (practice, health insurance company, etc.) and can have various artifacts (data, documents, etc.) as input or output.

For concretization of the metamodel, the business process model and notation framework (BPMN) was used. The BPMN standard is maintained by the Object Management Group and is supported by several tool manufacturers [32]. Providing a set of standardized graphical elements and an underlying XML-based syntax, BPMN allows to represent activities, messages, or data flows carried out by the participating actors within complex and parallel processes. This allows to create and to visualize complex process maps. In the DiGA.Pro project the concepts of flow object (activity, gateway, and event), connecting object, pool, and swimlane, were primarily used to record and subsequently to analyze the different implemented telemonitoring applications at the process-level theses. The open-source desktop modeler Camunda 8, which supports all standardized BPMN 2.0 elements, was used to model the care and application processes [33]. For each subprocess, we created different process models. In total, we modeled 36 subprocesses (see therefore also chapter 5).

The exemplary model in Figure 2 shows which optimization potentials arise with end-to-end digitized process chains on the future Telematics Infrastructure 2.0 of the German healthcare system.

After developing the metamodel, the appropriate metrics were chosen. The selection and application of metrics were important for evaluating and comparing different DHAs and their corresponding processes. Each metric chosen has its relevance and potential to provide insights into the evaluation of the DHA underlying a certain care process. Therefore, the selected metrics should:

• enable the evaluation of the number of interactions between people and system

• provide the ability to quantify the amount of manually entered data

• assess the number of duplicate manual data entries in order to quantify the degree of duplication in manual data entry

• quantify the time for data entry by doctors, patients, and practice staff in order to evaluate the efficiency of documentation and system usage.

• enable the evaluation of the number of media disruptions to identify inefficient communication or lack of integration

• assess the number of analog (paper) and digital data transmissions to quantify the degree of digital transmission methods and identify potential bottlenecks or inefficient use

• assess the number of different digital services used in a system or organization.

• evaluate the quality of information based on various criteria such as completeness, timeliness, accuracy, consistency, and comprehensibility.

• enable the recording and evaluation of the technical quality of a medical device or a medical service, including security, availability, reliability, accuracy, performance, and safety.

Each metric was derived using the GQM approach [34]. This involves setting a specific goal, formulating a relevant question, and then determining the appropriate metric. For example, in analyzing “Interactions Between People and Systems,” the goal might be to enhance communication efficiency in healthcare processes. The corresponding question could examine the frequency and effectiveness of these interactions, while the metric would involve counting occurrences of actor and communication keywords in BPMN diagrams. This systematic approach allows for a detailed and objective evaluation of each aspect of healthcare processes. In detail in the DiGA.Pro project, the following GQM metrics were applied (Table 1).

Goal	Question	Metric
Reduce manual data entry	How often is data put in manually?	Number of manually entered data Number of twice manually entered data
Make communication more efficient	How frequently does switching between digital and analog and analog and digital occur?	Number of media disruptions
Make interaction more efficient	How time consuming is the usage of the applications?	Time for data input New, additional time expenses Time to reach a process or subprocess goal
Understand the IT-landscape	How many different digital services are used?	Number of different digital services and applications
Improve communication efficiency	How frequent are data transmissions?	Number of digital data transmissions Number of analog data transmissions
Improve security	How frequent are verification steps taken and how many steps are there?	Number of verification steps

Table 1.

Selected metrics for DHA process evaluation.

The metrics were then applied to the BPMN models in order to quantify individual results of the analysis (for results see Chapter 9).

6. Modeling of telemonitoring applications and healthcare processes

Once the metamodel had been developed, the object of the study was narrowed down. For this purpose, the care scenario to be examined was defined as “telemonitoring with reduced monitoring requirements.” In this type of therapy-accompanying telemonitoring, vital and health data are recorded on an ad hoc or less continuous basis, because the diseases to be observed require a lower density of measurement points. The patients in question are not high-risk patients, but primarily patients with chronic or long-term diseases. Telemonitoring is carried out by general practitioners as part of their everyday practice and must therefore be as easy as possible to integrate into the outpatient treatment process.

Use cases for telemonitoring with reduced monitoring requirements are therapies that require frequent individual adjustment of the therapy or medication plan, based on symptoms or certain parameters that are collected via health assessments or measurements of vital and movement data. Examples include treatment of cancer, neurological diseases (multiple sclerosis and Parkinson’s disease), chronic respiratory diseases (asthma and COPD) as well as cardiovascular diseases such as heart failure or chronic heart failure. The different types of telemonitoring applications were defined as follows:

Telemonitoring is generally defined as remote monitoring and analysis of health-related data [35]. This also includes the collection of health data on patient’s site in everyday life and the transmission of this data to medical staff [36]. Areas of application for telemonitoring differ in particular with regard to the density of data collection from the patient. Depending on the clinical picture, a distinction can be made between continuous 24/7 monitoring and punctual monitoring. Continuous forms of 24/7 telemonitoring are often used in high-risk patients to monitor vital parameters (especially in cardiology) [37]. Punctual types of telemonitoring are used for indications with a reduced need for monitoring (e.g., high blood pressure) [38].

The building blocks of telemonitoring applications for patients and practitioners are shown in Figure 3. They include functionalities for planning and visualization of therapy measures and medication (e.g., medication plan), assessment of health condition and therapy progress (e.g., diaries or questionnaires), vital data acquisition by sensors or medical devices, integrated communication features (e.g., mail, messages, or videoconferencing), secure transmission of vital and treatment data, and storage of health data.

7. Data acquisition and analysis

After defining the scope of the study, a systematic review of the current DHA directory [39] and the German Innovation Fund projects [40] of the last 3 years was carried out. Therefore, publicly available sources of the projects (including project and application descriptions, publications, operating instructions, etc.) were considered.

A total of 48 DHAs and 118 innovation fund projects (focus on new concepts of care services—status ongoing) were documented. Of the 48 DHAs, a majority of 28 applications contained telemonitoring components. Especially DHAs have a high number of monitoring components overall (28 out of 48), particularly due to the automatic recording of therapy or program progress in self-study courses for improving health competence.

In innovation fund projects, telemonitoring has so far been used to a lesser extent. Of the 118 projects, only 32 integrated telemonitoring components in their application. In the analyzed projects predominated digital forms of medical documentation (e.g. case records) for cross-sectoral treatment, the usage of telemedical consultation services and questionnaire-based digital data collection to answer scientific questions. For five innovation fund projects, no final classification could be made due to insufficient information.

For the 60 digital health applications with telemonitoring components, the way in which way data is collected was also acquired (see Figure 4). To date, the data required for monitoring has largely been entered manually by the patient (n = 40). This can be data on the state of health (questionnaires, assessments, scales, and medication taken), diary entries, or notes. The second most common method identified was the automatic recording of progress (e.g., for a completed learning unit or therapeutic exercise) in the therapy program (n = 26). Recording of vital data by sensors is also quite common (n = 20). Manual input by medical staff on site (n = 5) is predominantly used in geriatric applications.

The analysis showed that a good third of the DHA (60 out of a total of 166) include monitoring components. So far, however, simple forms of monitoring have predominated, such as manual data entry and occasion-related transmission by patients or periodic retrieval of health data by practitioners. This indicates that the data is not time critical for treatment and is therefore loosely related to the actual treatment process. The majority of the projects examined are still at the testing stage or in a scientific evaluation process. None of the projects or digital applications have standardized interfaces to services of the Telematics Infrastructure (TI) of the German healthcare system.

After the systematic review, expert interviews were conducted for seven selected digital applications to identify all central and secondary processes of the actors involved in the care scenarios. In detail, it was determined which processes and treatment steps are supported by the digital application and which actor or which technical component collects and processes the data in which situation and for what purpose. This step served as preparation for modeling the technical processes and the interactions between doctor, patient, digital application, and other actors within the care scenario. After the detailed modeling of user interactions and analysis of the technical components, it was worked out which of the components contain their own application-specific logic and which components are generic and therefore could be implemented using standard components of the TI.

8. Analysis and modeling of the DiGA.Pro care scenarios

For analysis and modeling of the whole processes, two care scenarios were examined in more detail using the elements of the metamodel. Resulting from the real-life scenarios, the process patterns and architectural software patterns should be identified. These process and architecture patterns can help future providers of telemonitoring applications to adapt their software components to the requirements for integration into the TI. The two care scenarios are described in detail below.

8.3 Identified processes

From the modeling and analysis of the two care scenarios, it became apparent that the process steps for prescribing, obtaining, and using a DHA are largely similar despite some slight differences in detail. For this reason, only the generalizable process steps for both applications are shown in Figure 5. To simplify the readability, only the process steps and activities from user’s and from system’s perspective are described in accordance with the DiGA.Pro metamodel. To improve the overall clarity of the diagram, the temporal relationships between input and output and the assignment of actors to the activities have been not considered. At the level of the analysis model, however, this information was considered with its corresponding level of detail.

The user’s process steps can be taken to reconstruct the usage and functional scope of DHAs. This ranges from the prescription of the app by the doctor (1), the commissioning of app (2) and sensors or medical devices (3–4) to its use (5–8), and remote care or follow-up visits to the doctor (9). Depending on the design of the DHA, process steps for information, communication, measurement, and assessment are also integrated. However, the process steps and corresponding activities can vary in their chronological sequence depending on the application logic and the built-in treatment process of the DHA. Information (7) and communication (8) are mostly accompanying process steps alongside the lifecycle of the DHA. They are separated here only for better readability of the illustration.

In the next step, user activities were assigned to technical actions and responses from a system perspective, thereby identifying the technical process steps and activities. For the use of a DHA, the central technical process steps for rollout and operation of an IT application are carried out. These range from accounting functions (1), the installation (2, 4) and secure operation of IT applications (5–9), customer relationship systems (3, 9) as well as user and problem management right up to dedicated technical processes such as network and database management.

The correlation of user and technical processes illustrates how complex the procurement and commissioning of DHAs and sensor technology or medical devices is, right up to the first connected usage of app and sensors or medical devices. A large number of organizations and their technical systems are involved in the preceding administrative processes, whose procedures and data processing processes have to be coordinated with each other. To analyze and to compare the four care processes more in detail, we applied selected metrics to the BPMN models.

9. Application of selected metrics to the models

By comparing the four different care processes in detail, we gained the following insights: Although the telemonitoring applications for Parkinson’s and for heart failure address different indications, they are currently used in a very comparable way and have a similar range of functions. The four modeled digital health applications comprise a total of 623 activities. The following Table 2 provides an overview of the distribution of technical, organizational, and human activities that were modeled for the four care processes. Since the direct interaction of patient and doctor with the telemonitoring system was analyzed primarily, human (n = 254) and technical activities (n = 310) predominate over organizational activities (n = 59). For the modeling of organizational activities, only those accompanying subprocesses were considered that are directly necessary for purchase and usage of a digital application of the DHA. These include, for example, the redeeming of doctors’ prescriptions, the dispensing of medication in the pharmacy, the ordering and shipping of medical aids, or the billing of services by the health insurance companies. To this extent, it is plausible that there are no major differences in the number of organizational activities between the current status of implementation and the porting of care processes to TI 2.0 (SOTA = 30/TI = 29).

When analyzing the aggregated activities, it is also noticeable that porting the current telemonitoring applications to the TI 2.0 can reduce the number of necessary human activities for both care processes (SOTA = 142/ TI = 112). This indicates a moderately optimized interaction between users (patient/doctor) and technical systems, as the migration of individual user’s process steps to technical actions of the TI 2.0 allows them to run more automatically in the background. Again, this includes redeem of prescriptions, registration processes, ordering processes, and doctor-patient appointments. As a result, the number of technical actions increases significantly when porting the current DHAs to the TI 2.0 (SOTA = 124/TI = 186). The significant increase in technical activities is plausible insofar as the services available via TI 2.0 are more modularized and must be addressed individually due to its zero-trust architecture.

In the following sections, the analysis results based on the aggregated data will now be examined in more detail. The following observations for the entire care process were made using the metrics (Table 3).

From interpretation of the metrics, we derived the following results: Porting the telemonitoring applications onto the TI 2.0 is accompanied by a significant reduction in “manual data entry” (SOTA = 27/TI = 5). This is due to the central authorization and identity management of the TI 2.0. In contrast to the stand-alone telemonitoring applications, the use of the TI infrastructure eliminates inconvenient registration and authorization processes, as they can be configured either centrally by the user in the ePA or by the identity providers of the health insurance companies. Due to the centrally implemented set of access rules, the TI 2.0 services exchange authentication and authorization information during the subprocesses “installation of the DHA” and “doctor-patient conversation” in the background.

Surprisingly, we found little or no evidence of “duplicate manual data entry” in the processes (SOTA = 2/TI = 0). This is obviously due to the fact that DHAs with telemonitoring are only involved in a specific part of the care process, namely digital therapy support. As the treatment is largely based on digital technologies, the amount of duplicate data entered manually is low or negligible overall. Nevertheless, a large number of manual data entries must be made, especially for the use of the proprietary DHA, as was determined with Metric 1.

As can be seen from the “Media disruptions” metric, porting the stand-alone telemonitoring applications to TI 2.0 would reduce the number of media disruptions by half (SOTA = 42/TI = 19). The large number of media disruptions in the stand-alone applications results on the one hand from the conventional prescription and billing processes for medicines and medical aids and on the other hand from the fact that patients still have to make appointments by telephone. The introduction of the ePrescription service and electronic appointment allocation via TIM or other appointment allocation services could minimize these media disruptions.

We arrive at an even better result by the metric “paper-based interactions” (SOTA = 19/TI = 0). This includes printing out prescriptions, submitting prescriptions to the health insurance company, or sending activation codes for a DHA by letter. All of these paper-based interactions can be eliminated with end-to-end digitization of these processes on the TI 2.0.

However, the “number of digital data transmissions” is slightly increasing due to the fact that more data must be transferred between the DHAs and the corresponding distributed TI 2.0 applications, in particular ePA or health insurance app (SOTA = 36/TI = 43).

As can be seen from the metric “Used number of different digital services and applications,” the complexity of the overall systems is approximately the same. All DHAs must support the processes “installation and startup,” “access and identity management,” and “data transfer” between sensor, smartphone, and backend in the same way. In addition, they are integrated into the same healthcare system environment (e.g., for billing or ordering). The metrics differ only slightly, as the TI 2.0 architecture names the individual components in a more differentiated way and provides them as separate services (SOTA = 56/TI = 63).

Using the “Number of verification steps” metric, we were able to show that there are more verification steps on the TI 2.0 than in the stand-alone applications (SOTA = 20/TI = 34). However, this does not mean more effort for users, as the verification steps usually run in the background. The TI 2.0 was designed as a zero-trust architecture in which the services and devices encapsulated must temporarily verify themselves for each interaction and data transfer. It also can be assumed that the stand-alone telemonitoring applications have integrated sufficient security-relevant verification steps into their overall systems in order to meet the high data protection requirements when processing health data.

When analyzing the subprocesses in more detail, we made the following findings based on the metrics:

10. Discussion

In this chapter, we developed a model-based approach for assessing and analyzing technically supported care processes. The approach in this report focused on quantifying both the activities of users (patients/medical staff) and technical systems and their interactions. Therefore, we developed and used the DiGA.Pro metamodel that enabled us to categorize activities and assign these activities to actors. By modeling from the user’s perspective, we wanted to capture and visualize the individual process steps and information flows, ranging from prescription of a DiGA, installation, and usage all the way to the next doctor-patient consultation. Our process models should therefore reflect the reality of users as directly as possible.

The application of the metrics produced useful, comparable, and insightful outcome, although the models do not represent the detailed information about technical implementation details. The outcome is traceable and represents “hard facts” and helps to put hard numbers on the potential of optimizations. The insights gained through the metric results are traceable back to the model for a better understanding through “visual impression.” Patterns and process groups could be identified during the process of modeling, allowing further analysis into optimization (through, e.g., the introduction of new common services for the TI 2.0).

To differentiate the application context of telemonitoring applications, we first provided an overview of current products and projects with telemonitoring components in medical care and research and identified different forms of application. Based on the overview and the interviews conducted, we were able to identify the central process and architecture patterns for the implementation of care processes with telemonitoring and developed an information table of the process steps.

The exemplary modeling of the two care scenarios was then carried out in BPMN notation on the basis of the interviews and with the aid of further system documentation. The modeling of four medical care processes from prescription and usage to remote care and the final doctor-patient conversation was carried out with a focus on the direct interaction of users with the technical systems. The state of implementation (SOTA) was supplemented by modeling the same application on the German Telematics Infrastructure (TI 2.0).

By applying the established metrics to the modeled care processes, the findings could be quantified, and options presented as to how the existing telemonitoring application could be migrated to TI 2.0. At the same time, the metrics helped to identify optimization potential in the respective implementation of the telemonitoring application. Based on the metrics, the following main results were quantified right down to the subprocess level:

The number of TOM process steps in both care scenarios is similarly distributed regardless of the different indications, which suggests that the care processes of telemonitoring applications with reduced monitoring requirements are comparable and possibly also generalizable.

Porting the telemonitoring applications to the TI 2.0 can reduce the number of necessary human activities across the entire care process (SOTA = 142/ TI = 112) and leads to a significant reduction in manual data entries (SOTA = 27/TI = 5).

The number of media disruptions can be halved by porting the applications to TI 2.0 (SOTA = 42/ TI = 19), and the number of paper-based interactions can even be reduced to zero (SOTA = 19/TI = 0).

The complexity of the systems and the number of data transfers on the TI 2.0 increase slightly due to its zero-trust architecture and the more modular system architecture of separable services such as ePA, eML, EMP, and TIM. (SOTA = 56/ TI = 63). This finding also correlates with the increasing number of authentication and authorization steps on the TI 2.0 (SOTA = 20/TI = 43).

The accompanying optimizations by migrating the telemonitoring applications can be identified primarily in the secondary processes such as prescription, installation, ordering processes of aids or medical devices, appointment allocation, remote communication, and less in the actual use, since the usage of the DHA is based on its local application logic (e.g., sensor coupling or assessment of the state of health, vital data measurements).

Some metrics such as “time for data entries” or “number of interactions between human and technical system” could not be implemented due to the high degree of abstraction of the models. However, this or the detailing of the models could be realized in subsequent work, for example, on the basis of simulations or empirical values.

From the technical metrics (device quality, availability, reliability, safety, and security), only the metric for determining security could be implemented to some extent. Here too, there was a lack of information at model level about the specific implementation of these requirements at system level.

11. Limitations and lessons learned

We have derived the following lessons learned from the chosen procedure in the DiGA.Pro project:

The chosen approach, consisting of a combination of interviews and the study of existing documents as the basis for modeling the technically supported care processes, was successful. This allowed modeling the telemonitoring applications to a sufficient level of detail and applying the selected metrics to the models. The models also helped to understand the telemonitoring applications and their processes in detail.

Our metamodel can be used to model clinical pathways and decision-making situations during clinical processes. These processes in clinical pathways always consist of interaction and communication with technical systems, people, and institutions. The comparative modeling of different technically supported care processes can lead to harmonization and standardization of care processes and environmental parameters and helps to understand the workflows. In addition, BPMN process models could also be used as a tool for modeling medical guidelines and establishing shared protocols between doctors and patients [41].

It should be mentioned that we only applied SW-specific metrics for capturing and analyzing acceptance, usability, and security. This approach can be supplemented by measuring the quality of use via questionnaire-based assessments, as commonly used in usability evaluations [28, 42, 43]. By applying the metrics, we did not focus on visualizing business process optimizations or effects nor on aspects of quality improvement in care processes [23]. For these analytical questions (e.g., profitability, efficiency increase), we would have had to develop other metrics. Our metrics only reveal where the interaction between users and systems can be improved. However, since decision model and notation (DMN) [44] can also be used to model and execute decision-making processes, we would like to point out that it may be necessary to discuss the ethical implications and possible risks of automated process chains for patients and doctors [31].

BPMN provides a comprehensible set of graphical notation elements. In our modeling process, a common level of abstraction was found that helped to compare the two telemonitoring applications. Patterns and process groups could be identified during the process of modeling, allowing further analysis into optimization (through, e.g., the introduction of new common services for the TI 2.0). The intensive discussions about how to model a process step also helped to identify similar process steps in both applications and to model them in a comparable way.

Nevertheless, during our modeling efforts, we realized that we need a common understanding of how to model the individual process steps and name them so clearly that even others without in-depth process knowledge can quickly grasp and understand them. The problem of process comparability can arise if identical process steps are modeled differently. For future work, it is therefore necessary to establish modeling guidelines to harmonize and, if necessary, standardize the way processes are modeled in the healthcare sector. Also, a standardized naming of process steps in medical care processes and their definition in taxonomy could help to integrate and harmonize the various existing concepts [45].

The modeling process was very time consuming, and the models were frequently adapted. This requires a high level of willingness to reconsider and change models that have already been created. Due to the limited time available, we had to freeze the models for analysis at a certain point. The models could therefore be further detailed, and the granularity of the models could be further harmonized. The accuracy and correctness of the modeling are the foundation for the application of the metrics. In our project, we ensured the quality assurance of the modeling using a 4-eyes principle. In the future, however, the application of quality metrics to BPMN modeling could also help to achieve models that are as reliable and reusable as possible [46, 47].

During modeling, we also faced the problem of finding the right level of abstraction. Although we conducted preparatory interviews for the modeling and analysis with the application experts, we discovered during the modeling that we were missing certain pieces of information (lack of information). For this reason, we have to point out that our models may deviate from reality to some extent.

12. Conclusion and outlook

Finally, we would like to give the following conclusion and prospect for further work.

In our opinion, the visualization of processes can help to illustrate the complex human, technical, and organizational interrelationships in care processes and thus increase acceptance of these processes. Combining an analysis of business processes with a focus on the user experience (UX) seems to be a suitable approach to gain insights into how digital technologies are used in everyday life.

The balance of metrics for technical, organizational, and human activities is a good measure to determine which activities predominate in the process and may need to be adjusted from a users’ perspective. The detailed analysis of TOM activities at the level of the individual swim lanes can provide information on where there may be an overload of human or organizational activities and where a higher level of technical activities can lead to greater automation and finally to better usability and acceptance from the user’s and participating institutions’ point of view.

In addition, the separate evaluation of human activities is a good measure for recognizing possible acceptance problems, for example, due to too frequent manual input or for describing the complexity of a technical system (too many interactions required for use).

With its standardized notation of processes, BPMN provides a basis for the integration and harmonization of different processes, analysis approaches, and quality metrics in the healthcare sector [48, 49, 50]. To integrate these different concepts, it would certainly be of interest to consider semantic technologies such as ontologies or semantic data repositories [51].

However, if the existing limitations of this study are eliminated, a reference model for generalization of telemonitoring applications based on the DiGA.Pro models could be created as follow-up work. The individual process and architecture models for interaction and communication, data exchange, and data storage are already available in their initial stages.

Acknowledgments

This work was supported by the DiGA.Pro project funded by the German Federal Ministry of Health on the basis of a decision of the German Federal Parliament (Bundestag) under funding ID ZMI5-2521FSB010. We would like to thank the sponsors and our interview partners for their support in making this publication possible.