The Complexity of eHealth Architecture: Lessons Learned from Application Use Cases

Abstract

The rapid evolution of eHealth technologies has revolutionized healthcare, enabling data-driven decision-making and personalized care. Central to this transformation is interoperability, which ensures seamless communication among heterogeneous systems. This paper explores the critical role of interoperability, data management processes, and the use of international standards in enabling integrated healthcare solutions. We present an overview of interoperability dimensions—technical, semantic, and organizational—and align them with data management phases in a concise eHealth architecture. Furthermore, we examine two practical European use cases to demonstrate the extend of the proposed eHealth architecture, involving patients, environments, third parties, and healthcare providers.

1. Introduction

The European demographic landscape is undergoing profound changes characterized by an ageing population, declining fertility rates, and increasing migration flows [1]. Over recent decades, the growth rates of the four largest European economies, i.e., France, Germany, Italy, and the United Kingdom, have slowed [2]. Longer life expectancy and declining fertility [1] have led to gradually ageing populations [2]. Life expectancy among these countries increased from an average of $72.5$ to $77.3$ and $77.3$ to $81.8$ between 1975–1995 and 1995–2015. This means that every year, life expectancy has increased by almost a quarter of a year. The U.N. projections suggest that this trend will continue with a predicted rise from $82.7$ to $85.5$ between 2020 and 2040 [2].

Population ageing poses significant challenges for the healthcare systems across Europe. Chronic conditions like heart failure and fall-related injuries are, among others, major contributors to mortality and disability. This increases demand for healthcare services and places a substantial strain on existing resources [3]. To mitigate this pressure, telemedicine has attracted increasing attention as a promising solution in facing challenges such as heart failure monitoring and fall detection. These technologies have the potential to enhance care delivery, improve patient outcomes, and reduce hospital readmissions. However, the widespread adoption of telemedicine solutions faces several barriers. Telemonitoring generates a huge amount of data [4], which is usually hard to manage, often fragmented, and rarely integrated into the hospital Electronic Health Record (EHR). The lack of interoperability hinders data availability, accessibility, and affordability [5], limiting its potential for personalized care planning and reducing re-hospitalization. Addressing these challenges requires a comprehensive telemedicine architecture that ensures secure data exchange, supports interoperability, and complies with European regulations on data privacy and security.

Critical aspects such as the management, the storage, and the use of data constitute an important starting basis. The adoption of cloud-based solutions, the integration of Artificial Intelligence (AI) and machine learning (ML), the rise of interoperability, and the increased awareness of data security and privacy have produced a growing role for patient-centred data management.

This approach requires accounting for all relevant entities, stakeholders, rules, and regulations to ensure the secure and private exchange of healthcare data between all parties involved. Consequently, this study addresses the following research question: “What architectural components and regulatory considerations are essential for implementing effective telemedicine services, such as fall detection and chronic care monitoring, in Europe?”.

To answer this question, we employ a methodological approach that first outlines a general architectural framework for eHealth applications and subsequently undertakes a case-based analysis involving two research projects: one conducted in Italy on heart failure management and another in Germany on fall monitoring.

These case studies are analysed alongside existing literature to identify key requirements, challenges, regulations, and best practices for telemedicine implementation in Europe. Based on this analysis, we propose recommendations for the design of comprehensive telemedicine architectures and outline directions for future research. It is worth noting that the proposed framework is optimized for the European regulatory context; consequently, further evaluations are necessary to ensure its applicability in non-European contexts.

The remainder of this paper is organized as follows: Section 2 reviews the current state of eHealth architectures. Section 3 introduces the Italian and German use cases, detailing the stakeholders, system architectures, and associated challenges. Section 4 discusses the findings, and Section 5 presents the conclusions and future research directions.

2. System Architecture and Data Management Challenges in eHealth

This section provides a high-level state-of-the-art analysis of eHealth architectures, covering various use cases (e.g., telemedicine and ambient assisted living). We aim to outline a broader landscape of challenges and design considerations that should be addressed when developing eHealth solutions, as illustrated in Figure 1. Furthermore, we map the Data Management NECESSARY phases to specific Use Case perspectives.

For data management, we consider the entire process: from data collection to provisioning to the end user. The main phases include

• Data Gathering: Collection of data through devices such as wearable sensors, environmental sensors, and actuators;
• IoT-Fog Networking: The connectivity layer responsible for aggregating data from patients or their environments via IoT devices (e.g., the Patient or Patient Environment);
• Fog Processing: Processing and data exchange with central systems;
• Fog-Central Networking: Communication mechanisms for transferring patient or environmental data to centralized platforms or cloud-based services.
• Central Processing: Devices or systems that manage all the health data.

We consider the use case aspects:

• Patient: The individual receiving care and generating health-related data;
• Patient Environment: The physical spaces where the patient can interact (direct physical contacts, rooms, and environments);
• Third Parties: The external entities that interact, collaborate, or provide eHealth systems;
• Healthcare Provider: The clinical organizations and professionals leveraging technologies to enhance and optimize the operational efficiency and care quality.

All these aspects are embedded in the legal frameworks and regulations of the specific local, national, or international use cases. While this paper primarily emphasizes the European (EU) context, due to its significant influence on the complexity of eHealth architectures, it is important to recognize that practical implementation begins with the national legal context. Thus, national frameworks and sector-specific regulations should be considered first, followed by an evaluation of their compliance with and alignment to EU-level directives and regulations. This layered approach—from national to EU-level—provides a more realistic and implementable foundation for analyzing and deploying eHealth solutions in practice.

For eHealth scenarios, the following aspects of legal frameworks and regulations in particular should be considered:

• Privacy: Compliance with the General Data Protection Regulation $679/2016$, GDPR [6], at the EU level, as well as its national-level supplements and interpretations;
• IT-Security: Adherence to the Network and Information Security Directive 2 (NIS-2) [7], alongside its national transpositions into domestic legislation;
• Healthcare specific: Frameworks such as the European Health Insurance Card (EHIC) and the European Health Data Space (EHDS), complemented by corresponding national healthcare regulations;
• Emerging Regulations: The forthcoming EU Artificial Intelligence Act (AI Act) [8], which introduces risk-based obligations for AI systems, including those applied in healthcare, and the Digital Services Act (DSA), which establishes broader digital governance principles. Both require careful monitoring to ensure that national implementations remain interoperable and legally compliant across the EU.

This is not considered an exhaustive overview of legal and regulatory aspects; additional regulations and laws have to be considered depending on the use case, e.g., specialist regulations for electronic installations or components. Given the growing adoption of AI technologies in healthcare, it is imperative to systematically address the legal and regulatory frameworks that govern their deployment, in parallel with their technological development. Careful alignment with established governance structures and ethical standards is essential to ensure that AI-enabled healthcare solutions are not only technically robust but also sustainable, socially responsible, and compliant with socio-economic and policy requirements affecting both providers and patients.

With the legal frameworks and regulations addressed, we will first detail for each data management phase the physical and logical properties to be considered, before aligning these phases with the use case views.

2.1. Data Management

2.1.1. IoT Data Gathering

In eHealth, processing data about or from the patient is fundamental. Among traditional means of data collection, i.e., manual input or electronic forms, we consider in this data management phase, especially the collection of data by things, i.e, small sensors. The Internet of Things (IoT) includes various sensors that vary in physical properties (e.g., size, waterproofing), and measurement properties (e.g., reliability, frequency, or accuracy). For simplicity, the term sensors is used throughout this paper to collectively describe both data-collecting devices and actuators, which may perform actions based on data.

These sensors can, in general, be classified into the following groups:

• IoT Physical Sensors and MIoT Physical Sensors: These measure properties of the patient’s body at a given time. We differentiate between the terminology of IoT and Medical IoT (MIoT) sensors. We refer to IoT sensors as things that are not designed or certified as medical-grade, e.g., wearables like smart watches measuring/estimating the blood oxygen values. Meanwhile, with MIoT, we refer to devices that are medical-grade and certified for the specialized use, e.g., electrocardiogram (ECG) [9].
• IoT Ambient Sensors: The differentiation between physical and ambient sensors depends on the observed subject. While physical or wearable sensors focus on the patient itself, ambient sensors focus on the environment (of the patient). Thus, IoT ambient sensors are placed in the environment of the patient, e.g., at home for Ambient Assistant Living (AAL) or within a healthcare provider domain (ambulance, hospital room, or nursing homes [10]).

In the data management phase, various key challenges have to be considered and overcome for a successful eHealth framework. ‘Data is key’; thus, in the IoT Data Gathering phase, the baseline is created for all upcoming processing steps. Alongside the data quality itself, the nature of the data, i.e., the sensitivity the health, medical or personal data, and the device class ((M)IoT) are of importance and must be accounted for accordingly. Thus, we consider the following properties of importance for this phase:

• Data Availability: Continuous access to data both in real-time and offline, minimizing losses and downtime;
• Data Quality: Data collected should be accurate, complete, and timely to avoid artifacts such as errors, noise, or missing values, which can lead to incorrect or wrong solutions that can compromise patient care;
• Informativeness/Purposefulness: Data have to be relevant and useful for the clinical and analytical purposes, minimizing redundancy and non-informativeness for storage and processing optimization, thus ensuring appropriate clinical decision-making support;
• Reliability: Data must be consistent and reproducible across different systems and conditions over time, accounting for network stability and error correction;
• Calibration: Regular calibration and maintenance of sensors prevent data drift and maintain accuracy.

With the data initially collected in the IoT Data Gathering phase, it is generally a singular data point of insignificant use and must be made useful. This is generally achieved within the decentralized fog processing and/or subsequently by central processing, requiring data to be transferred and collected. Thus, IoT-Fog networking is the next phase within the data management to be discussed.

2.1.2. IoT-Fog Networking

The IoT-Fog networking phase is crucial for processing data in any scenario collecting data from the Patient or Patient Environment with IoT devices. The used sensors collect data in a decentralized manner, which has to be processed in combination (over time and/or various dimensions) to gain insights. Common networking solutions and protocols are available, each with specific properties, e.g., wired or wireless networking solutions. Within the scope of this paper, we will not survey the various possibilities but want to give an exemplary overview.

• Zigbee: This is a low-power, low-data-rate wireless communication protocol commonly used in personal area networks and ideal for battery-operated health monitor devices [11];
• BLTE: Bluetooth Low Energy provides short-range, energy-efficient wireless communication, particularly suited for wearable patient monitoring systems [12];
• WLAN: Wireless local area networks, such as wi-fi, offer high data rates and broader coverage, often used in hospital settings for more data-intensive transmissions [13];
• ETHERNET: Ethernet is a wired solution and provides high-speed, reliable communication; it is often preferred in clinical environments where stability and bandwidth are crucial, such as in teleoperation and telerobotic systems [14].

In this data management phase, various key challenges have to be considered to adequately transfer the data. Key properties and challenges for this phase include

• Compression: This reduces the transmitted data size. Compression techniques are necessary, especially in bandwidth-limited environments, offering reduced storage costs, increased data transmission efficiency, improved scalability, fast data access and retrieval, and sustainability [15];
• Low-Energy: Efficient operation (e.g., minimal power consumption) is critical for mobile devices and wearable applications [16];
• Encryption: This ensures data privacy and security, during transmission and storage [17];
• Authorization: Robust access control to sensitive data is granted through robust authentication and authorization mechanisms (e.g., Blockchain-based, multi-factor authentication, zero-trust, and machine learning-based security models, etc.) [18];
• Fail-Safety: systems design to handle network failures, and ensure data integrity and continuity of service [19].

With these properties to be addressed, data can be transferred adequately to the next data management phase Fog Processing.

2.1.3. Fog Processing

In the Fog, various device types can be used to collect data from IoT sensors. These Fog devices have generally two purposes: processing and exchanging data with central systems. These devices include

• Bridges/Hubs: These act as network intermediaries that gather data from IoT endpoints, forwarding to central or cloud-based processing systems via standardized protocols (e.g., CoAP, MQTT, XMPP, AMQP, DDS, LoWPAN, BLE, and Zigbee) [20];
• Local Servers: These provide localized processing, such as real-time notifications, integration with other systems, e.g., smart home assistants, and conditional forwarding to central platforms [20];
• Smart Devices: Smartphones, tablets, SoCs, and smart watches are used both for data collection and processing, offering data transfer capabilities while also enabling edge analytics or temporary data storage [21].

In this data management phase, data is collected from one or many IoT devices and can be processed for various use cases. The Fog devices are, depending on their capabilities, used to collect, (pre)process, and transfer the data and derived insights. Therefore, this phase is crucial for data management, whereas the following properties have to be addressed:

• Data Structure: Efficient organization and categorization of data are essential to support easy access, storage, and processing. The data structure should be designed to handle diverse data types, ranging from structured data such as patient records to unstructured data like medical images and time-series sensor data. Specific attention should be paid to data normalization and the use of consistent identifiers to enhance data integration and sharing between different IoT devices and platforms;
• Distributed Storage and Computing: These enable synchronization across Fog nodes, addressing latency, consistency, and load balancing;
• Data Pre-Processing: This involves integration, transformation, reduction, and generalization of data (e.g., filtering, aggregation, trimming, anonymization/pseudonymization, and relevance-based selection) before central transfer to save bandwidth and protect privacy [21,22].
• Tiny ML: This involves execution of lightweight ML models on low-resource edge devices for preliminary data classification or pattern detection. These models have recently attracted increasing attention for their potential and scalability (e.g., enabling distributed computing and reducing the computational load on centralized systems). Nevertheless, their development and application in healthcare practice face significant challenges. In particular, effective training requires balanced and high-quality datasets, the availability of which is often constrained or restricted by privacy regulations.
• Connectivity: Reliable and standard (e.g., DIN/ISO) compliant network connectivity to ensure interoperability and safety.
• Notifications and Alerts: Immediate, local alerts (e.g, threshold-based anomalies) offering a fast and less complex decision-making [21].

When the data has been collected in the decentralized Fog, it can be transferred via the Fog-Centralized Networking to the last data management phase, centralized processing.

2.1.4. Fog-Central Networking

Based on the Fog processing device and the environment it is situated in, various networking options are available to transfer the collected data of the patient or patient environment. The networking options can be differentiated within the following classes, whereas combinations of them may be used.

• Wired Networking: Data is transferred via a physical wired connection, e.g., such as LAN (local area network), WAN (wide area network), or the Internet.
• Wireless Networking: Data is transferred via a physical wireless connection, e.g., radio waves. Common examples include Wi-Fi (IEEE 802.11 [23]), Zigbee, Bluetooth, and proprietary RF protocols [24].
• Cellular Networking: Data is transferred via physical wireless connection of the cellular mobile band, e.g., 2G, 3G, 4G, LTE, 5G. This is typically used by smart devices, e.g., smartphones, tablets, or wearables [25].

In this data management phase, data is transferred from the Fog to centralised processing systems. Due to the collection of a medium amount of data from various IoT devices, a relatively higher bandwidth is required to transfer the data compared to IoT-Fog networking. Furthermore, depending on the scenario, it is essential to ensure uninterrupted connectivity for critical applications; or, at least, strategies such as local storage and deferred transmission (i.e., store-and-forward) should be implemented to address temporary network disconnections and avoid data loss. Therefore, the following properties have to be addressed.

• Compression: Data should be compressed efficiently to minimize the transmission time and bandwidth usage, especially when transmitting over networks with constrained throughput or when handling burst data streams [26];
• Fail-Safety: Redundancy mechanisms (e.g., fallback connections, buffering, retransmission strategies) prevent data loss during temporary network outages or degraded performance [27].

In contrast to IoT-Fog networking, we do not consider security-related challenges, e.g., encryption for this data management phase, because it is commonly solved or addressed with standard technologies and well-know protocols, thus not inducing additional challenges for an eHealth framework. In the last part of this section, we will address this topic specifically as a general challenge for all data management phases.

Next, we will address the last data management phase, central processing.

2.1.5. Central Processing

Central processing refers in this context to devices or systems—often composed of multiple subsystems—that are intended to manage all the health data for various purposes, including long-term storage, large-scale analytics, cross-patient modeling, decision support, and compliance tracking. The central processing devices can hereby be differentiated within the following classes.

• Local Servers: These refer to servers that are managed in-house and typically situated in the data center of the healthcare provider. They offer full control over hardware, software, and data governance and are often selected when compliance or latency-sensitive applications are critical [28];
• Cloud: This refers to servers and platforms offered by third-party providers and used with healthcare institutions in a service as-a-Service (aaS) model. This category can be further differentiated by service type, e.g., Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS). These models can be available for users through different delivery models; a public cloud provides a scalable, cost-efficient infrastructure shared across organizations. In contrast, a private cloud offers dedicated infrastructure for one organization. Hybrid clouds combine both to allow workload portability and compliance flexibility [28].

Within the centralized processing system, various technical challenges arise, depending on the type of processing. Although each of these challenges can be further addressed and differentiated within their respective research fields, for the scope of the paper, we provide a general overview. In the following, we outline typical challenges and use cases that have to be considered.

• (Big) Data Storage: The system must reliably and efficiently store vast amounts of structured and unstructured health data (e.g., time series, images, and EHRs) [29];
• (Big) Data Mining: Extracting useful patterns or correlations from large datasets requires robust data mining frameworks capable of handling noisy, heterogeneous, and incomplete data [30];
• Analytics and Learning: Descriptive, predictive, and prescriptive analytics are central for generating insights. Machine learning techniques are applied for anomaly detection, patient stratification, and outcome prediction.
• AI: Artificial Intelligence (AI) can support clinical decision-making through diagnostics, recommendation systems, and workflow automation. However, explainability, reliability, and bias mitigation remain significant challenges in the eHealth sector [31]. From a technical perspective, AI systems in healthcare can be deployed through various architectures—ranging from on-premise solutions and federated learning frameworks to cloud-based services—each with distinct implications for data protection, privacy, and compliance. The choice of deployment strategy is therefore closely tied to regulatory constraints and organizational requirements. Moreover, different classes of AI technologies are increasingly applied in the eHealth domain: large language models (LLMs) and conversational agents enable interactive support for patients and healthcare professionals; recommender systems provide personalized treatment options and resource allocation; and workflow automation tools improve operational efficiency by streamlining administrative and clinical processes. Building accurate AI models requires extensive training data, the acquisition of which is frequently constrained by privacy regulations and by quality issues, including imbalance and incompleteness of available datasets. Despite their potential, these technologies pose critical challenges related to transparency, interpretability, fairness, and secure data handling, which must be systematically addressed to ensure trustworthy adoption in healthcare practice.
• Blockchain: Distributed ledger technologies can enhance data integrity, auditability, and patient-centric control over health records [32]. Challenges include scalability, interoperability with legacy systems, and compliance with regulations such as GDPR. The appropriate usage of Blockchain technology within an eHealth architecture to address specific challenges requires careful consideration.

Using the data management phases, their respective device classes and networking resources, and their respective challenges, we will detail the additional challenges that have to be addressed throughout the eHealth framework and thus within all data management phases.

2.1.6. General Data Management Challenges

Time

Time-critical considerations in data management are essential for eHealth frameworks, e.g., how data is transferred. These considerations are motivated by healthcare requirements and limited by technological properties.

• Real-Time: In an ideal scenario, an eHealth system would operate in real time. For example, detecting a potential cardiac anomaly could trigger immediate emergency response procedures, including dispatching medical transport while simultaneously transmitting real-time and historical patient data to hospital staff. Achieving real-time capabilities requires ultra-low latency communication, reliable high-bandwidth networking, edge or fog-based pre-processing, and deterministic system behaviour. Additionally, system redundancy and QoS (Quality of Service) policies must be enforced to ensure consistent real-time performance.
• Synchronous: Synchronous systems rely on near real-time request–response interaction but are not necessarily designed for critical alerts. For example, a clinician can request the patient’s latest glucose readings during a teleconsultation. Synchronous systems have to balance responsiveness with stability, employing timeout management, load balancing, and consistent state across devices and services.
• Asynchronous: Asynchronous communication models are used when immediate response is not critical. Data is collected, stored, and transmitted when resources are available or network load is optimal. This is typical for non-urgent health metrics, such as daily step counts [33]. In addition, this type of communication may act as a fallback strategy for data transfer when synchronous channels are not available.

IT-Security Technical and Organizational Measures

Ensuring Confidentiality, Integrity, and Availability (CIA) [34] is essential for information systems, especially within an eHealth framework and each of its phases and use cases.

• Confidentiality: This involves maintaining the secrecy of information during data exchange within networks, organizations, or institutions. This ensures that only individuals with proper authorization can access or view the information.
• Integrity: This focuses on maintaining data in its true state, safeguarding its consistency, precision, and dependability, which contributes to the general trustworthiness of the entity. Essentially, it encompasses preserving information in its unaltered form.
• Availability: This ensures rightful access to systems, operating environments, data, or information. It also includes redundancy and decentralization, supporting the project’s completion on schedule.

Implementing IT security principles requires appropriate technical solutions and organizational measures, finding a trade-off between function (security) and user acceptance. The use of standardized and tested solutions should be encouraged alongside National and international standards (e.g., NIS-2 [35]). Depending on the previously chosen technologies, in each phase, specific solutions are applicable.

For example, in an IoT environment, authenticating wearable devices and other network components in a distributed setting is complex due to various factors [36]. Existing methods often rely on centralized authorities for fixed networks. This can lead to network congestion, scalability issues, and resource misuse, particularly for resource-limited edge devices that perform unnecessary computations and communications. Effectively authenticating healthcare IoT devices in distributed networks is and remains a challenge. Similar challenges arise in other phases and technologies.

Privacy Technical and Organizational Measures

In the era of digital transformation, the rise of Big Data, AI, and IoT has significantly impacted the healthcare sector. These technologies serve as the foundation for various applications as well as the proposed eHealth framework and enable, e.g., predicting patient needs to optimize staffing and monitoring the health of elderly individuals to provide support in emergencies [37,38]. Effective collection and processing of personal data are vital for harnessing valuable insights for these healthcare applications, including scientific research. However, ensuring individual privacy is essential.

The European Union’s General Data Protection Regulation (GDPR) [6], effective since May 2018, establishes a comprehensive legal framework for data collection and processing. It mandates explicit, informed consent for processing sensitive data (e.g., health information). Consent must be given freely, with a clear understanding of how personal data is handled, ensuring transparency, accountability, and comprehensibility to specific purposes (e.g., for research and not for marketing).

Data must be used strictly for the agreed purposes, even when shared with third parties. Research institutions and hospitals are responsible for safeguarding privacy throughout the whole data lifecycle, anonymization, and pseudonymization. GDPR grants individuals with data subject rights, enabling control over personal information. Non-compliance may lead to significant penalties.

Implementing these legal requirements demands considerable expertise and effort. Privacy enhancing technologies (PETs) can mitigate this complexity by simplifying the management and enforcement of privacy policies. Establishing standard policies and processing rules helps in the efficient administration of consent decisions and other privacy measures, ensuring compliance and protecting user privacy [39].

It is important to remark that the GDPR represents the principal regulatory framework for the processing and protection of personal data in Europe, while Member States may complement it with additional national provisions. Consequently, from an implementation perspective, any relevant national-level regulations should also be taken into account. On the other hand, other regions and countries have their own legal frameworks covering privacy concerns for eHealth, e.g., Health Insurance Portability and Accountability Act (HIPAA) [40], Health Information Technology for Economic and Clinical Health Act (HITECH) [41], Personal Information Protection and Electronic Document Act (PIPEDA) [42], or Saudi Health Information Exchange Policies (SHIEP) [43].

Interoperability

Interoperability is a foundational feature for continuous development and deployment of eHealth frameworks. It enables seamless communication and data exchange across diverse systems and phases, ensuring efficient sharing of patient data, generating added value both for the patient and healthcare provider.

Interoperability is facilitated through the use of Application Programming Interfaces (APIs) and standardized protocols, which enable efficient and effective data exchanges between various applications and systems. APIs serve as a bridge that enables different software applications to communicate with each other, allowing them to exchange information seamlessly. By leveraging APIs, healthcare providers can overcome many challenges related to data lakes, enabling more integrated and responsive care delivery.

The adoption of interoperability standards, such as HL7 FHIR (Fast Healthcare Interoperability Resources) [44], SNOMED CT (Systematized Nomenclature of Medicine—Clinical Terms) [45], and LOINC (Logical Observation Identifiers Names and Codes) [46], is critical to ensure exchanged data is consistent, meaningful, and actionable across different systems. These standards provide a common language, dictionary, and framework that enhance semantic interoperability, making it possible to exchange and interpret heterogeneous data accurately across different healthcare settings.

Interoperability in eHealth can be separated into the following categories.

• Technical Interoperability: This addresses the physical and technical infrastructure enabling data exchange via standardized communication protocols and data formats, such as HL7 FHIR, ensuring connectivity and data sharing, avoiding inconsistencies or loss of information.
• Semantic Interoperability: This ensures data exchanged is meaningful and interpretable by the receiving systems using standardized medical terminologies and ontologies, such as SNOMED CT or LOINC for shared understanding.
• Organizational Interoperability: This includes policies, regulations, and procedures that enable collaboration and data sharing among different healthcare organizations. It ensures the alignment of goals, responsibilities, and governance structures necessary to support data exchange and integration efforts [47,48].

Achieving effective interoperability requires adopting international standards, implementing APIs in technological infrastructures, and fostering collaboration and trust among governments, healthcare providers, and technology vendors. This represents an essential step toward the creation of shared frameworks and guidelines that support the deployment of interoperable systems. By addressing technical, semantic, and organizational challenges and promoting collaboration across the healthcare ecosystem, the full potential of digital health can be realized, streamlining healthcare delivery and enabling innovations that improve patient outcomes and system efficiencies.

2.2. Use Case

With the data management phases addressed, we align these with the corresponding use case perspectives. The following views are considered in relation to the data management phases:

2.2.1. Patient

The patient may act as a passive or active subject to the eHealth framework. In a passive role, the patient can be observed by various devices and actors that gather health-related data (i.e., within the (data management phase Data Gathering)). In an active role, the patient interacts with the eHealth framework directly (e.g., manual input of data via surveys or self-monitoring of health-related information).

Applications providing added value to the patient include

• Health and Lifestyle Monitoring: Continuous health and lifestyle monitoring through eHealth systems enables patients to track their vital signs and daily activities, promoting proactive health management and facilitating early detection of potential health issues;
• Convenient Healthcare: Remote access to medical advice and consultations via eHealth systems reduces the need for frequent in-person visits;
• Cost Reduction: This streamlines care delivery, reduces travel, and lowers healthcare costs for patients (e.g., savings on transportation, time, and medical expenses);
• Expert Availability: eHealth solutions provide access to a wider range of healthcare specialists and experts regardless of geographic barriers;
• Patient Empowerment: This enables patients to actively participate in their health management and medical decisions, leading to more personalized and effective treatment outcomes;
• High Standards of Care: Integration of advanced technologies ensures consistent, evidence-based, and up-to-date medical services with the latest research and practices.

These benefits demonstrate the transformative potential of eHealth throughout the patient journey. To realize these benefits, it is essential to collect and transmit data from the patient environment for further processing.

2.2.2. Patient Environment

The patient environment encompasses the physical spaces and devices in direct contact with or surrounding the patient, including the environments where the patient interacts and is treated. We propose but do not limit the patient environment to the following categories.

• Connected Patient: This utilizes wearable devices (IoT physical sensors and MIoT physical sensors) and mobile health applications to monitor health status and vital signs in real time. For example, a smartwatch tracking heart rate and alerting to irregular patterns can help in proactively managing cardiovascular health;
• Smart Home: This integrates health monitoring devices (IoT ambient sensors) within the living environment to enhance patient care and safety. For example, a smart home system equipped with motion sensors can detect falls or inactivity, automatically alerting caregivers or emergency services to assist elderly residents;
• Smart Ambulance: This is equipped with advanced telemedicine tools and real-time data transmission to improve pre-hospital care. For instance, transmitting vital signs and ECG data to the receiving hospital allows pre-arrival preparation.
• Smart Hospital: This leverages IoT devices, Electronic Health Records, and automation to enhance patient care and operational efficiency. Examples include Radio Frequency IDentification (RFID) tags to track patient locations and automate workflow coordination, ensuring timely delivery of services and reducing waiting time for patients.

These different types of patient environment correspond to the data management phases of data gathering, IoT-Fog networking, and Fog processing, where data and information are gathered, transmitted, and received by central eHealth systems. These systems can be operated and provided by different third parties, including healthcare providers.

2.2.3. Third Parties

Various third parties may interact with or provide eHealth systems, typically through the following media.

• Web Application Services: These are online platforms facilitating various healthcare services, such as appointment scheduling to telemedicine consultations. For example, patients can book appointments and attend virtual consultations.
• Apps: These are mobile applications offering personalized health management tools to monitor conditions and communicate with healthcare professionals, for example, nutrition and exercise tracking apps.
• Data Platforms: These are cloud or local platforms that collect, store, and organize large healthcare datasets from multiple sources to support research and decision-making.
• Analytics Platforms: These are services that process and analyse healthcare data to generate valuable insights, improving decision-making and operational efficiency, for example, a platform that uses advanced analytics to help hospitals identify trends and improve patient care quality.

These services may be cloud-based or locally deployed, supporting both patients and healthcare providers.

2.2.4. Healthcare Provider

Healthcare providers benefit from eHealth through improved operational efficiency and care quality. Shared health resources allow centralized patient data access by multiple healthcare professionals, enhancing decision-making, communication, and treatment planning.

The integration of eHealth services streamlines communication and collaboration among diverse healthcare teams, reducing redundancy and errors. Real-time data monitoring enables timely interventions, increased accuracy, and treatment plan adjustments, resulting in enhanced care quality.

Additionally, shared health resources improve workflow efficiency by automating routine tasks, minimizing paperwork, and prioritizing critical cases. This allows providers to allocate more time and resources to patient care, training, and research initiatives. Data collected also contributes to population health management and epidemiological research, identifying trends and patterns and informing public health strategies and policies.

Furthermore, eHealth facilitates improved diagnostic and therapeutic processes through advanced data analytics, enabling personalized and predictive models that identify potential health issues before they become acute. This leads to faster access to relevant patient data that supports timely interventions, improving outcomes, and reducing costs by minimizing invasive procedures and hospital stays.

Finally, eHealth supports clinical research and innovation, leveraging big data and machine learning to uncover novel insights and strategies for disease management.

The synergy between technology-driven insights and traditional medical expertise fosters continuous improvement toward clinical and operational excellence. The integration of eHealth technology promotes a more connected, informed, and responsive healthcare ecosystem, benefiting both patients and providers.

3. Application Use Cases

To demonstrate the applicability and scalability of the proposed eHealth architecture, we select and analyse two heterogeneous and distinct European use cases: the Italian Proximity telemedicine system (see Section 3.1) and the German residential fall monitoring system (see Section 3.2). Both systems operate within the European eHealth ecosystem, ensuring consistency in terms of overarching regulatory compliance (e.g., GDPR), while still accounting for structural differences in healthcare systems, digital infrastructure maturity, and organizational models. In fact, Italy emphasizes territorial and proximity care through regionalized services, addressing urban–rural disparities [49]. Conversely, Germany operates a more federated system with strong primary care integration and significant investment in digital health innovations under the Digital Healthcare Act (DHA) [50]. These differences enable us to explore how the proposed eHealth architecture can accommodate diverse implementation contexts.

In terms of technology maturity, both systems can be classified at a Technology Readiness Level (TRL) of approximately 7. They have been validated in relevant environments, and the reported challenges (e.g., user acceptance, connectivity gaps, interoperability issues) originate from these pilot demonstrations. The systems have not yet undergone large-scale operational deployment nor achieved full medical-device certification, although some components are classified as medical devices, which currently limits their classification beyond TRL 7.

3.1. Telemedicine Case Study

The Proximity project, particularly through the Chronic Care Telemedicine research line, aims [49] to establish a distributed health network that links hospitals and local services and general practitioners (i.e., GP) to ensure continuity of care for chronic patients [49]. A key goal is to promote interoperability and integration of different healthcare systems. Access to up-to-date and easily accessible information for healthcare professionals is crucial for managing chronic diseases such as heart disease, chronic obstructive pulmonary disease (COPD), and diabetes. This case study introduces patient-oriented interfaces and technological tools to enhance collaboration and information sharing among doctors, nurses, and patients [49]. A core component of this architecture is the territorial Electronic Health Record (EHR), integrated with the outpatient and hospital EHR systems. The data feeding the EHR originate from both healthcare professionals and remote patient monitoring sensors.

Based on the care plan intensity level, different monitoring strategies can be implemented, e.g., continuous monitoring for chronic, unstable, or post-discharge patients by wearable sensors and periodic outpatient monitoring of vital parameters for low-risk patients by family (e.g., caregivers) and community nurses. Patients, doctors, and nurses use sensors to transmit information, and mobile phone/tablet applications are designed to ensure constant doctor–patient communication, assessing the improvements these technologies bring to the care pathway. These solutions enable clinicians, nurses, and patients to share data, use communication tools, and evaluate the benefits of telemedicine interventions. Figure 2 illustrates the overall system architecture, emphasizing the two main integrated subsystems: a telemonitoring platform (blue) and an Electronic Health Record (green). Data exchange between the two platforms is enabled through web service channels, leveraging the HL7 FHIR standard to encode information transmitted via HTTPS messages. Specifically, relevant data are mapped onto Observation, Procedure, Condition, and Medication Statement resources, using identification codes from LOINC, SNOMED CT, and ICD-9.

The design follows a Unified Modeling Language (UML) analysis, defining both areas (see

Table 1. Areas in heart failure cases.

Area	Description
DOM	Patient’s home
TERR	Territorial coordination
AMB	Hospital or territorial clinic/outpatient
GP-AMB	General Practitioner clinic
OSP	Hospital ward

) and actors (i.e., human-level actors in 

Table 2. Human-level actors in heart failure cases.

Human-Level Actor	Description
PAT	Patient
CGIV	Caregiver, family assistant
GP	General Practitioner
MED-OSP	Hospital doctor in the ward/specialist
MED-AMB	Hospital doctor outpatient/specialist
INF-TERR	Central Territorial Nurse (CTN) i.e., Regional Coordinator, Regional Central Nurse
INF-DOM	Home nurse for patient’s home
INF-OSP	Hospital nurse in the ward/specialist
INF-AMB	Hospital outpatient nurse/specialist

and machine/system-level actors in

Table 3. Machine/system level actors in heart failure cases.

Machine/System-Level Actor	Description
PTM-DOM	Patient’s home client
PTM-INF	Nurse’s home toolbox
PTM-WEB	Web client for MED-INF
PTM-REP	PTM repository (includes PTM middleware/PTM Bus)
C8	Advanced Medical Software (ISA)
Administrative Software	GP’s medical record
C7-REP	C7 repository (includes C7 Middleware/Bus)

).

This integrated system enables shared monitoring and aligned clinical information, fostering synergy among multidisciplinary teams (i.e., General Practitioners, hospital doctors, hospital nurses, Central Territorial Nurses, home nurses, and caregivers). Advanced analytics, including risk stratification and AI-driven decision support, enhance care quality through continuous learning and automatic interpretation of clinical data.

3.1.1. IT Architecture

The IT architecture is structured into three levels.

• First level: This is the basic structure of the telemedicine system, implementing the territorial Electronic Health Record (developed on the platform already in use at Azienda Usl Toscana Nord Ovest) and integrated with outpatient (clinic) and hospital.
• Second level: This involves integration of established technology systems, including virtual outpatient televisits using specialized sensors; telemonitoring for continuous home monitoring of unstable or post-discharge patients; regular monitoring of vital parameters by community nurses; patient interface webAPP; and decision support systems to determine eligibility for telemonitoring.
• The third level concerns the development and testing of innovative technologies, such as remote ultrasound diagnostic technology using robotic systems, as well as wearable sensors with Fiber Bragg Grating (FBG) technology for biomechanical cardio-respiratory monitoring and related wearable optoelectronic interrogation systems (clinical tests conducted at healthcare facilities and home-based clinical trials).

Due to the project’s wide scope, our analysis focuses on the second level, particularly addressing post-discharge care for heart failure patients [51]. This stage integrates personalized care pathways with timely interventions, leveraging digital tools to reduce hospitalization risks and provide support for personalized treatments [52,53].

3.1.2. Use Case: Heart Failure (HF) in the Italian Context

Continuous monitoring for chronic, unstable, or post-discharge patients, which require a care plan with a high level of monitoring, is performed by the integrated platform shown in Figure 3. In detail, it presents different building blocks, described as follows.

• EHR: The patient Electronic Health Record (i.e., ISA) is the central node for data storage, presentation, and sharing, developed at “Fondazione Toscana Gabriele Monasterio” (FTGM) [54]. It allows all actors involved in patient care to simultaneously access multimodal up-to-date data from hospitals, clinics, and home settings.
• Telemedicine and Home Monitoring Module: The Telemonitoring Platform (i.e., EasyTeleMed) includes monitoring kits for the autonomous acquisition of vital signs—heart rate, blood pressure, weight, height, oximetry, etc.—executed directly by the patient at home [55], and a remote web-based application for data collection, visualization, and synchronization with external repositories. In particular, the monitoring system is composed of a tablet and wireless medical sensors [56]. It guides the patient through autonomous measurements according to the personalized care plans, designed for a user unfamiliar with technologies, minimizing interactions via audio-visual alerts and graphic animations.
• Clinical Decision Support System: This combines a rule-based Expert System and AI Tools for monitoring suggestions [57] and risk prediction [58]. In particular, the Expert System supports patients’ enrollment and follow-up planning (monitoring intensity and exams), integrating all available data from the EHR [59]. It continuously adapts the follow-up strategies based on the data collected by the monitoring devices and generates alerts for General Practitioners (GPs) or specialists to intervene promptly, aiming to prevent HF decompensation.

In terms of data flows, the hospital and clinic’s care episodes (i.e., inpatients and outpatients) are sent from ISA to the EasyTeleMed platform (i.e., diagnosis, vital parameters acquired during medical visits, visit reports and procedure outcomes, clinical evaluations, and medical therapy). Conversely, patient-generated data collected at home are transmitted from the telemonitoring platform to ISA. This provides medical staff with a comprehensive and updated view of the patient’s health status. The acquisition from the medical sensors and the transmission of the collected data to the selected cloud-based EHR are completely automatic and transparent to the end-user. In contrast, the CDSS is invoked on demand by the clinician, who submits the patient’s clinical characterization data to receive recommendations on the most appropriate monitoring strategy based on the patient’s condition. The data collected in the EHR are navigated and presented through intuitive web interfaces provided by the integrated platform.

According to the schema illustrated in Figure 3, the process begins once the patient has been discharged from the hospital and enrolled in the telemedicine programme, receiving the home monitoring kit. The data self-collected by the patient, managed through the telemedicine module, are subsequently integrated into the health record alongside the data gathered during hospitalization and follow-up visits. Thus, ISA (i.e., the EHR) records all patients’ clinical data and allows healthcare providers to access, retrieve, and share data in real time. It acts as a centralized hub for an individual’s medical information, facilitating healthcare providers’ collaboration and incorporating communication tools, alerts, and clinical functionalities to improve care quality and health outcomes.

This advanced ecosystem provides EHR services for physicians and nurses, both inpatient and outpatient. By integrating clinical, technological, and administrative hospital processes with remote monitoring, it supports the processing of clinical information collected from different sources and remote systems, thereby facilitating efficient clinical information management and ensuring a smooth integration into care workflows.

3.1.3. Data Management

Effective data management is pivotal in this case study to ensure that health data is effectively collected, processed, analysed, and applied to enhance clinical decision-making and patient outcomes. In the following, we describe key functions that include

• Interoperability: This ensures seamless integration and data exchange between all system components;
• Data Security: This protects sensitive patient information during collection, storage, and transmission;
• Compliance: It adheres to legal and ethical standards for healthcare data management (e.g., General Data Protection Regulation, GDPR);
• Data Quality: It maintains data accuracy, consistency, and reliability throughout the system.

The data life cycle involves availability, collection, storage, analysis, integration, and utilization (see Figure 3), for instance

• Data Availability: Information scattered across different sources (e.g., user-based);
• Data Collection: Health-related data gathered from medical devices (e.g., heart rate, blood pressure, etc.);
• Data Storage: Episodes from remote monitoring and hospital visits are stored in EHR. Centralized databases in the eHealthcare centre allow for the management of historical and aggregated data;
• Data Analysis: Application of algorithms for clinical insights and organizational optimization, for example, by means of clinical Decision Support System (DSS) data processing;
• Data Integration: Integration across home monitoring, hospital episodes, and central eHealth systems data, see Figure 3;
• Data Security and Privacy: Protocol implementation to safeguard sensitive data during the phases of collection, transmission, and storage and compliance with relevant healthcare data regulations (i.e., GDPR);
• Data Utilization: Actionable insights delivered to clinicians and healthcare providers for personalized care plans and operational outcomes.

3.1.4. IoT-Fog and Fog-Centralized Networking

The proposed case study consists of several monitoring kits tailored to patient risk stratification and a centralized server application with storage capabilities, usually deployed in the service provider’s facility [55] (see Figure 4).

Each monitoring kit enables the acquisition and transmission of lifestyle parameters, vital signs, physiological signals, and questionnaire data, following personalized care plans. The kit operates as an IoT sensor network including the following:

• Non-invasive wireless (i.e., BT/BLE) sensors for physiological monitoring, as depicted in Figure 4 and devices (i.e., tablets, smartphones, etc.), which manage phases such as the acquisition, local storage, and transmission of patients’ data [55];
• A mobile device (gateway), typically an Android tablet or smartphone, for local processing and communication.

Sensors communicate with the gateway via Bluetooth/BLE, using proprietary drivers from the manufacturer or standard Bluetooth profiles, while the gateway manages the bidirectional communication with the server application (i.e., networking resources: e.g., 3G, 4G, WiFi), uploading health data via HL7 FHIR and downloading monitoring care plans via a custom XML format.

3.1.5. Fog and Centralized Processing

The gateway application runs on an Android device and includes a core module for scheduling patient care plan activities and coordinating tasks such as data acquisition, processing, local storage, and transmission, as shown in Figure 5. Specifically, the gateway manages drivers to collect data from sensors and performs initial processing to verify data validity and accuracy. Valid data are then stored locally in an SQLite database and subsequently transmitted to the server application using a store-and-forward strategy. This approach mitigates temporary connectivity interruptions, ensuring no data loss. The gateway’s graphical interface is designed to guide patients through each step of the process, offering audio-visual prompts and immediate feedback on the outcomes of their actions. This helps to improve usability and patient acceptance.

The server application is the central node of the telemedicine system, offering a web-based user interface, web services, and repository capabilities. A cloud-oriented software manages bi-directional communication and provides a web-based graphical user interface, elaboration (i.e., data processing and analysis), data synchronization, graphical representation, and data management resources [55].

The server application provides a Representational State Transfer (REST) web service for bidirectional communication, supporting data upload and remote configuration updates (e.g., a patient’s personalized care plan). Furthermore, it runs data processing algorithms, including alarm situation detection [55]. Server and gateways use XML tags, and external third-party software and information systems (e.g., clinical records, etc.) are integrated through the HL7 FHIR Clinical Document Architecture (CDA). Following a Software-as-a-Service (SaaS) cloud paradigm (e.g., HTML5, CSS, and JavaScript), a multi-access, multi-profile web application is provided for the users. This allows clinicians and staff to visualize and manage patients’ data. The HTTPS protocol and user authentication are used both in the Security and Access Control module (i.e., web services and the web application). Finally, a relational database (i.e., MySQL DBMS) implements the repository, which provides long-term storage of the monitoring kits’ acquired data, data generated by the platform algorithms, and the medical staff’s manually inserted data [55].

Connectivity-specific infrastructural characteristics are analysed and matched with the localization of healthcare and third sector facilities. Availability and access to care, both in response to complex and primary needs, are still an issue that generates disparities between urban and rural residents. Connectivity issues are not well considered when working in rural areas, which are often characterized by underdeveloped infrastructures.

3.1.6. Challenges

The implementation of this system faces and overcomes several technological and operational challenges.

• Connectivity gaps: limited network coverage in rural or inner areas creates disparities in access to digital healthcare services and delayed data transmissions.
• User acceptance: the level of digital literacy plays a crucial role for both clinicians and patients, influencing the adoption and effective use of eHealth solutions.
• Usability: elderly patients may struggle with even simplified interfaces, requiring dedicated training or on-site support.
• Data completeness and interoperability: integration with different clinical databases, although well supported by standards, remains incomplete, as outpatient data are often paper-based or stored in non-interoperable systems, resulting in fragmented or incomplete patient medical records.
• Organizational support: identification of local third sector associations and volunteers to assist patients.

3.2. Ambient Assisted Living Case Study

This use case complements the Italian cardiovascular monitoring scenario by addressing a different risk: residential falls among older adults. While both use cases target the vulnerable population, the German approach focuses on using passive smart home infrastructure, differing in sensing methods, data granularity, and clinical integration. Similar to the Italian case, user acceptance and interoperability remain as challenges.

3.2.1. Residential Fall Monitoring

Falls—especially ‘long lie’ events, in which a person remains on the floor for at least one hour—rank among the most dangerous domestic emergencies for older adults [60,61]. In Germany, more than 30% of adults aged 65+ and over 50% of those aged 80+ experience at least one fall per year [61,62,63,64]; in 37–55% of incidents, the person is unable to rise without assistance [62,65]. For individuals living alone, this means a high risk of remaining undetected on the floor; the literature labels an unnoticed recumbency of one hour or more as a long lie, a condition linked to markedly increased mortality [62,66].

The German scenario introduces a sensor-agnostic Ambient Assisted Living (AAL) system that re-uses existing smart home infrastructure—smart water- and power meters together with indoor CO₂ sensors—to derive activity traces and identify potential emergencies [67,68,69,70]. The raw streams are first cleaned and pre-processed; the resulting activity signals feed an inactivity score model that flags prolonged inactivity. When the score exceeds a specific threshold, an alert and (if necessary) a full emergency chain are started [71].

Figure 6 illustrates the system architecture.

Table 4. Areas in the fall monitoring case.

Area	Description
DOM	Patient’s home
IoT-SP	Backend of the Internet of Things (IoT) device vendor; optional hop before data reach the care domain
EDGE	Edge-cloud operated by the AAL service provider; aggregates activity signals and performs emergency analytics
OPS	Telemonitoring operations centre of the AAL provider (dashboards, caregiver coordination)
EMS	External medical and emergency services

,

Table 5. Human-level actors in the fall monitoring case.

Human-Level Actor	Description
PAT	older adult/patient
CGIV	informal caregiver (family, neighbours)
AAL-OP	telemonitoring staff of the AAL provider
EMS-DISP	emergency service dispatcher
HCP-MD	treating physician

and

Table 6. Machine/system-level actors in the fall monitoring case.

Machine/System-Level Actor	Description
SMT	Smart meters and environmental sensors (water, power, CO2)
GW	In-home edge gateway (feature extraction, anomaly detection)
IoT-SP-Cloud	Vendor backend receiving raw IoT data
DISAGG	Micro-service that disaggregates vendor data streams into semantic activity signals
EDGE-Cloud	Secure edge--cloud instance for signal fusion, model updates, and alarm logic
NOTIF	Secure alarm broker (push/SMS/voice)

define the areas and actors involved in the system, used in the UML analysis.

Upon a detected anomaly, a local alert (HOME-ALERT) is triggered in DOM. If the event is not canceled, NOTIF escalates to CGIV and the AAL-OP. Only after the operator confirms the emergency is the EMS dispatched. This two-stage approach minimizes false positives while ensuring rapid professional response.

3.2.2. IT Architecture

The system is organised in four logical tiers that extend the classic edge–fog stack by an optional IoT-service-provider hop (see Figure 6):

• Device/home tier (DOM): smart meters and ambient sensors (SMT) collect raw data. Readings are forwarded either (i) directly to a DISAGG micro-service, (ii) via the in-home gateway (GW) to the edge cloud, or  (iii) to a vendor-specific IoT service provider cloud (IoT-SP).
• IoT service provider tier (IoT-SP, optional): when a vendor cloud is involved, local access to raw data is unavailable. The IoT-SP forwards the payload to a dedicated DISAGG micro-service that extracts activity information and applies the relevant models before handing the resulting activity signal to the edge cloud (EDGE).
• Edge–cloud/service tier (EDGE): the EDGE-Cloud, operated by the AAL provider, aggregates encrypted activity streams from all sources. It may reside on dedicated hardware within DOM or as a centralized cloud service. The edge layer maintains patient-specific baselines, detects deviations, and triggers the alarm workflow. Critical events are exposed via REST APIs to the operations tier (OPS) and, when necessary, to EMS.
• Operations and application tier (OPS): the NOTIF broker and caregiver dashboards reside here. The alarm chain starts with an in-home alert, escalates to informal caregivers via push/SMS, involves telemonitoring staff (AAL-OP), and, after confirmation, dispatches the professional emergency service (EMS) together with a structured observation package.

3.2.3. Use Case: Falls in the German Context

A fall alarm is generated and processed in four phases that correspond to the architectural tiers.

Phase 1—Data acquisition (DOM). Smart-meter and ambient-sensor packets are streamed continuously from the dwelling to the next tier without any local analytics. The in-home gateway acts solely as a secure forwarder [72].

Phase 2—Activity disaggregation (IoT-SP or EDGE). The DISAGG micro-service ingests the raw sensor streams, verifies message integrity and derives a semantic activity label. Only this compact activity record is forwarded to the edge cloud for further analysis.

Phase 3—Event validation (EDGE). The EDGE-Cloud decrypts the activity messages and enriches them with contextual data such as the patient’s calendar (e.g., planned absences). A rules engine updates a rolling inactivity score buffer and compares the current score with its historical distribution to detect unusual behavior.

If the score exceeds the adaptive threshold, the event is classified as a confirmed anomaly and the operations phase is triggered; otherwise, the record is archived for model re-training [71].

Phase 4—Alarm escalation (OPS). For a confirmed anomaly, the NOTIF broker activates the staged alarm chain [67]:

• it issues an in-home alert, allowing the patient to cancel a false alarm;
• it sends push/SMS notifications to all informal caregivers (CGIV) and aborts the chain if one acknowledges within the configured time window;
• if unanswered, it forwards the alert to the telemonitoring operator (AAL-OP) for a voice check or live data inspection;
• after operator confirmation, it dispatches the emergency medical service (EMS) via the national 112 interface.

This staged workflow reduces unnecessary EMS deployments while maintaining a short alarm-to-door time.

3.2.4. Data Management

• Interoperability: Below the disaggregation tier, the landscape is heterogeneous: every sensor type exposes its proprietary frame format and therefore requires a dedicated DISAGG micro-service. True interoperability is achieved only after disaggregation, when each micro-service emits a uniform activity stream consisting of event ID, timestamp and a model-derived certainty score. These streams are mapped to a minimal Observation profile in the edge layer. This mapping follows HL, where each activity signal is represented as an Observation resource. To preserve semantic meaning, a reduced SNOMED CT code set is used for labelling inactive and anomaly events. The effectiveness of this approach is twofold: it allows integration with existing clinical systems in principle, but at the same time highlights the limitations when sensor data originates from domains without standardised health semantics. Thus, interoperability is partially achieved; it is sufficient for alarm escalation and documentation but not yet for comprehensive clinical record integration.
• Security: Because most sensors originate from non-health domains, cryptographic protection of raw packets cannot be guaranteed once they leave the dwelling. From the disaggregation point onwards, all traffic is secured with end-to-end TLS 1.3 (AES-GCM). Whenever possible, the edge cloud is deployed on-premises, so that critical information never traverses the public Internet.
• Compliance: Vendor transport paths remain outside our control. GDPR measures, therefore, start at the edge layer. Only event metadata (event ID, certainty score) is processed, satisfying data-minimization requirements.
• Audit logging: Every activity record is linked to a Provenance resource; logs are retained for 70 days, striking a balance between traceability and storage economy.
• Quality assurance: The self-learning edge analytics continuously recalculates the certainty score of each sensor channel. Streams with low confidence are flagged for maintenance, and model parameters are adjusted nightly to suppress emerging false positives.

3.2.5. Fog Processing

Edge analytics rely on lightweight statistical models. For every activity stream, a rolling feature set is maintained.

• Inactivity score: A moving-average z-score quantifies the deviation of the current gap length from the median gap length observed over the past ten weeks.
• Adaptive thresholds: Thresholds are updated constantly on the edge node by exponential smoothing, enabling slow adaptation to seasonality without transferring raw data.
• Certainty estimation: Each sensor channel contributes a confidence weight based on its recent data quality; the final certainty score is a weighted sum over all channels.
• Model maintenance: Feature statistics and confidence weights are persisted locally and backed up to the cloud; no central retraining is required.

An alarm is raised when the inactivity score exceeds its adaptive threshold.

3.2.6. Fog-Central Networking

Each confirmed event generates a compact JSON payload of about $100B$ that contains the event ID, timestamp, and certainty score. Transport is handled exclusively via HTTPS secured with TLS $1.3$; when a vendor cloud sits in the path, the identical encrypted message is simply tunneled through the IoT-SP to the edge cloud, without further transformation.

3.2.7. Challenges

As with the Italian use case, user acceptance and data interoperability remain persistent issues. However, unlike Italy’s hospital-integrated workflow, the German system operates largely independently of formal healthcare channels, which eases integration but limits clinical validation.

Key open issues closely resemble those encountered in the Italian pilot:

• Connectivity gaps—sporadic LTE coverage in rural regions still delays alerts despite buffering.
• Data heterogeneity—every new smart meter vendor adds a custom payload that must be onboarded through a bespoke DISAGG micro-service.
• User acceptance—some older adults remain skeptical of continuous monitoring and may struggle with mobile notifications.
• Regulatory uncertainty—the precise classification of the system under German medical device law (MPDG) is not yet settled, which could prolong certification and raise costs.
• Limited audit retention—GDPR data minimization leads to a 70-day log window, restricting long-term forensic analysis.

4. Discussion

The presented use cases both address critical healthcare needs for vulnerable populations, specifically older adults at risk of cardiovascular events and residential falls, respectively. While they share the overarching goal of improving safety and health outcomes through technology, their approaches diverge significantly in terms of system design, clinical integration, sensing methods, and operational workflows.

The HF-oriented system, employed in the Italian study, uses dedicated wearable sensors that collect high-resolution physiological data (e.g., ECG, heart rate, oxygen saturation), enabling detailed clinical assessment and decision-making. This granularity supports sophisticated diagnostics but requires user compliance in wearing and maintaining devices. Conversely, the AAL-oriented system, deployed in the German study, employs a sensor-agnostic approach, reusing ambient data from smart meters (water, power) and environmental sensors, which provide indirect activity-related signals. The data granularity is lower and less medically specific, focusing instead on detecting inactivity patterns suggesting falls or emergencies. This passive sensing reduces user burden but limits direct clinical insight.

Both systems use multi-tier architectures incorporating edge and cloud components; however, their integration differs. The telemonitoring system is tightly coupled with hospital IT infrastructure, supporting direct clinical workflows, data validation, and immediate intervention. In contrast, the AAL system operates largely independently of healthcare institutions, emphasizing privacy, minimal data transfer, and gradual alarm escalation through informal caregivers and telemonitoring operators before involving emergency services. The AAL use case introduces an optional IoT service provider tier, reflecting reliance on commercial smart home vendors, which adds complexity to data interoperability and security management. The Italian scenario typically manages medical device data under controlled clinical environments.

Both cases highlight user acceptance as a significant challenge. Italian patients must adapt to wearable devices and hospital interactions, while German users may be skeptical about ambient monitoring and managing mobile notifications. To address user acceptance in practice, the pilots included support from the research team, who assisted participants during onboarding and initial use. While the passive sensing approach used in the German study reduces the need for direct interaction and thereby lowers the burden on elderly users, long-term adaptation challenges persist. In particular, trust in the monitoring system was repeatedly raised as a concern. We therefore emphasize that although passive monitoring can increase acceptance compared to wearable solutions, additional long-term studies are required to evaluate how stable adoption develops over time. The Italian case also revealed resistance to the adoption of telemedicine among medical staff, largely driven by the perceived increase in workload and reluctance to alter established working practices. In some cases, a sense of mistrust towards technology emerged, particularly with regard to AI-based solutions. Long-term demonstrations designed to assess practical benefits and improve digital literacy are essential for overcoming barriers to the acceptance of such systems in clinical practice.

Interoperability is an important concern in both systems. Different standards for data exchange are available to support effective system integration. The Italian system deals with integrating heterogeneous clinical data sources using well-known standards. In practice, these standards efficiently handle structured clinical data, such as vital signs and diagnostic images, but present challenges when applied to natively unstructured data or information originally recorded in an unstructured format. At the same time, the German use case faces challenges onboarding diverse smart meter vendor protocols requiring customized disaggregation services before normalizing data streams. In practice, the German case study illustrates the potential and the limitations of such standards in AAL applications. Because fall monitoring relies on heterogeneous non-medical IoT devices (e.g., smart meters, CO₂ sensors), standard-compliant data exchange is not possible at the raw sensor level. Instead, each vendor stream must be normalized via a disaggregation service into a uniform activity stream and then mapped to a minimal FHIR Observation profile to ensure syntactic interoperability. In addition, semantic coding via SNOMED CT is limited to a small set of high-level activity concepts (e.g., inactivity episodes and confirmed anomalies). This demonstrates that while FHIR/SNOMED provide a useful target framework, their effectiveness in heterogeneous home environments remains restricted, and further harmonization work is required.

Network disparities and connectivity gaps pose significant challenges for telemedicine and AAL systems, directly affecting the reliability and timeliness of services. Interrupted or inconsistent connectivity can disrupt real-time monitoring, leading to delays in decision-making and potential data loss. Moreover, unreliable connectivity can hinder user trust and acceptance. To mitigate these issues, strategies such as local data buffering (store-and-forward), the use of redundant communication channels, adaptive data compression, and edge computing are employed to maintain care continuity despite unreliable connectivity.

Clinical validation is more advanced in the Italian telemonitoring case due to its direct hospital integration and medical device classification. Regulatory pathways are clearer but require compliance with medical standards. The German AAL system, operating outside formal healthcare channels, faces regulatory uncertainty, especially concerning medical device law classification, which may delay certification despite simpler clinical validation needs. The system’s focus on event metadata and data minimization helps GDPR compliance but restricts long-term forensic data retention.

The Italian telemonitoring system supports rapid clinical response via direct hospital staff intervention, leveraging continuous vital sign monitoring to detect acute events in advance. The German AAL system adopts a multi-stage alarm escalation to balance false positive reduction with timely response. Initial local alerts allow patients to cancel false alarms, followed by notifications to informal caregivers, telemonitoring operators, and finally emergency medical services if needed. This process respects user autonomy and resource optimization but may introduce slight delays in emergencies.

This paper showcases how the proposed eHealth architecture is suitable for use in the structured comparison and classification of eHealth systems in Europe. Although not all details of eHealth systems are specified by our proposed architecture, it still enables a holistic approach to covering and generalizing the architectural concepts that need to be addressed within an eHealth system. By demonstrating the coverage on two data points, i.e., eHealth systems, we can state that the proposed eHealth architecture should be completed.Furthermore, the examples are limited to only the European health space.

Thus, we see further need for extensive validation of the proposed eHealth architecture by applying it to more eHealth systems (in higher quantities) and with a broader scope (various countries and continents). The detail level of the proposed metrics may be discussed further to consider developments and changes to standards, the state of the art, and the state of research.

5. Conclusions

The rapid evolution of eHealth technologies has revolutionized healthcare and requires a structured approach to address and compare the technological and organizational changes and challenges in emerging eHealth systems.

In this paper, we present two complementary use cases addressing critical health risks faced by older adults: cardiovascular telemonitoring in Italy and residential fall detection in Germany.

To answer the research question—What architectural components and regulatory considerations are essential for implementing effective telemedicine services, such as fall detection and chronic care monitoring, in Europe?—we propose an eHealth architecture in Section 2 and validate it based on two use cases. We therefore demonstrate its applicability to various use cases, architectures, and legal and regulatory frameworks, specifically in addressing two critical health risks faced by older adults. Both scenarios leverage advanced sensing and data analytics to enhance safety and enable timely interventions. They differ in sensing modalities, system architectures, clinical integration, and operational workflows.

The Italian telemonitoring use case demonstrates the benefits of integrating wearable sensors within established hospital workflows to deliver continuous, high-resolution physiological monitoring. This approach supports precise clinical decision-making and early detection of cardiovascular events but depends on user compliance and IT interoperability. In contrast, the German ambient assisted living system emphasizes passive, sensor-agnostic monitoring using existing smart home infrastructure. By focusing on activity patterns rather than direct physiological measurements, it offers a less intrusive solution that facilitates independent living while maintaining a staged emergency escalation process. This design enhances privacy and usability but faces challenges related to data heterogeneity, clinical validation, and regulatory clarity.

Both use cases reveal challenges in user acceptance, data interoperability, and regulatory compliance, underscoring the need for harmonized standards and user-centered design principles. Additionally, connectivity limitations and audit data retention constraints must be addressed to ensure reliability and long-term system accountability.

Advances in edge computing, machine learning, and interoperable standards will be critical to achieving scalable deployments that can adapt to diverse user needs and healthcare frameworks.

Expanding clinical validation and engaging end-users early in the design process can foster trust and acceptance, while clarifying regulatory pathways fosters safe and effective technology adoption. Finally, the integration of multifaceted monitoring paradigms into a cohesive eHealth architecture could significantly improve quality of life and health outcomes for aging populations worldwide.

In general, it can be concluded that the proposed eHealth architecture can be applied to the limited selection of eHealth systems. Nonetheless, this also shows the limitation of this work, which only focuses on two eHealth systems to validate our approach.

In future work, we intend to cover these limitations by comparing eHealth systems from the state of the art and various national backgrounds with our proposed eHealth framework. Furthermore, we aim to extensively validate the acceptance level of the proposed framework, considering professionals’ feedback from technical, health, and regulatory domains, e.g., through validating the detail level of the proposed metrics.

An additional evolutionary direction for the proposed architecture is the development of a toolkit of ready-to-use components, which are aligned with regulatory requirements and supported by existing technologies.

With this work, we intend to ease not only the application of eHealth systems but also standardization processes, because clinical data sharing among healthcare providers is fundamental for an efficient telemedicine service.

The final goal of telemedicine should be the enhancement of the well-being of all patients, which requires a delicate balance of fairness and equity.

To advance this intent, different platforms need to be interconnected to an EHR systems in order to exchange data and maintain the consistency of data available on different platforms. Interoperability is a key element of the implementation and provision of efficient and effective services.

Looking ahead, future work should explore the transformative role of AI in shaping the next generation of eHealth systems. Beyond addressing current challenges of transparency, fairness, and data protection, research must anticipate how emerging paradigms—such as foundation models, multimodal learning, and privacy-preserving federated ecosystems—can fundamentally reconfigure healthcare delivery. A key direction will be the investigation of how AI can act as an enabler of personalized, context-aware, and equitable care, while ensuring that deployment models remain trustworthy, interoperable, and globally compliant. Moreover, cross-disciplinary collaboration between computer science, medicine, ethics, and policy will be essential in developing frameworks that not only safeguard patient rights but also unlock the full socio-economic and clinical potential of AI. Ultimately, the vision is to move beyond incremental improvements toward AI-driven healthcare ecosystems that are adaptive, resilient, and designed to enhance human well-being on a systemic scale.