A Federated FHIR-Based Interoperability Framework for Multi-Site Heart Failure Monitoring: The RETENTION Project ^†

Abstract

Heart failure management increasingly relies on heterogeneous clinical and real-world data generated through remote monitoring technologies. However, transforming these multimodal data streams into actionable insights requires robust interoperability infrastructures. This study presents the RETENTION interoperability framework, a federated HL7 Fast Healthcare Interoperability Resources (FHIR)-based architecture designed to support multi-site heart failure monitoring across five independent clinical environments. A semantic reference model comprising 444 clinical and contextual variables was developed and aligned with FHIR R4 resources and internationally recognised terminology systems. The platform adopts a selective profiling strategy, extending only the Patient resource while standardising the remaining variables through example-driven Implementation Guide documentation. Identifiable data are retained locally within Clinical Site Backends, whereas anonymised datasets are periodically aggregated into a Global Insights Cloud to enable centralised analytics and controlled third-party interactions. The framework was deployed across six hospitals (with two Spanish hospitals sharing the same deployment), supporting 390 patients and over 130,000 patient-days of monitoring, with more than 3.6 million remote device data points harmonised without schema conflicts. The results demonstrate that large-scale semantic harmonisation and privacy-preserving aggregation can be achieved using a lightweight profiling approach, providing a scalable and reproducible interoperability model for multi-centre digital health research infrastructures.

1. Introduction

Heart failure (HF) remains one of the leading causes of death, hospitalisation and thus high healthcare expenses worldwide [1,2]. Modern guidelines underline the importance of monitoring physiological and behavioural parameters, medication adherence and patient-reported outcomes to improve disease management and reduce hospitalisations [1]. The increasing utilisation of wearable devices, remote monitoring sensors and digital questionnaires has expanded the volume of valuable clinical and non-clinical data streams available for HF management. Telemonitoring interventions have demonstrated reduction in mortality and unplanned hospitalisations [3], while recent evidence further supports the role of remote patient management as an integral component of HF care pathways [4]. However, converting these heterogeneous data into exploitable clinical insights relies on strong interoperability infrastructures.

Healthcare interoperability remains a significant technical and organisational challenge [5] due to the variety of information systems, data models and terminology systems used. Traditional integration mechanisms based on HL7 v2 and document-centric approaches such as Clinical Document Architecture (CDA) have facilitated syntactic data exchange but often lack the semantic flexibility required for structured interoperability [6]. As digital health ecosystems shift towards service-oriented and cloud-based architectures, scalable and harmonised data exchange models become necessary [7].

The Fast Healthcare Interoperability Resources (FHIR) standard was developed by HL7 to address these limitations by combining structured healthcare data models with RESTful web technologies [8]. FHIR enables modular resource representations, uses standardised APIs and improves integration with modern web applications. Over recent years, it has gained international adoption by being incorporated into national health infrastructures and digital health platforms [7]. Despite its growing popularity, large-scale operational deployment of FHIR introduces challenges such as semantic harmonisation, resource profiling, terminology binding and cross-organisational conformance validation [9]. Moreover, the creation of FHIR Implementation Guides and the management of custom extensions remain tricky parts in complex deployment scenarios [7].

Multi-site research networks and health data-sharing initiatives have demonstrated the importance of harmonised data models and federated system architectures in analytics and collaborative research [10]. However, there is still limited practical evidence on how FHIR can be effectively utilised in multi-centric clinical studies under strict privacy and security considerations [11]. Combining local site autonomy with centralised data aggregation while complying with regulations such as the General Data Protection Regulation (GDPR) [12] introduces both technical and governance challenges.

Federated learning frameworks have emerged as privacy-preserving paradigms in which data remain locally stored and only model parameters are exchanged across institutions [13]. While such approaches decentralise analytics, they generally assume locally harmonised data representations and do not address cross-site semantic interoperability challenges, which still require common standards or Common Data Models (CDMs) [14]. In parallel, document-centric infrastructures such as Integrating the Healthcare Enterprise (IHE) and Cross-Enterprise Document Sharing (XDS) have supported data exchange through CDA-based documents; however, document-level interoperability is primarily designed for episodic clinical documentation and may offer limited granularity for structured, high-frequency monitoring data [15,16]. CDM approaches, including Observational Medical Outcomes Partnership (OMOP), enable retrospective harmonisation of heterogeneous datasets for large-scale observational research and federated benchmarking but typically rely on Extract–Transform–Load (ETL) processes and are primarily oriented toward retrospective data harmonisation rather than real-time, API-based ecosystems [14,17].

The ‘Heart Failure Patient Management and Interventions using Continuous Patient Monitoring outside Hospitals and Real-World Data’ (RETENTION) project addresses these challenges in the context of a multi-centre advanced HF monitoring and management platform [18,19]. The project integrates heterogeneous data sources, including vital signs from remote devices, physiological and behavioural data from wearables, medication adherence, patient symptom reporting and follow-up recorded data, into a unified interoperability framework. The project is currently in the clinical trial phase, which started on May 2024 and will continue until August 2026.

A semantic reference model consisting of 444 clinical and contextual variables, identified through extensive clinical requirement analysis, was developed and aligned with FHIR R4 resources and internationally recognised terminology systems such as SNOMED CT [20], LOINC [21], ICD-10 [22] and ATC [23]. The platform is deployed in a federated manner across five Clinical Site Backends (CSBs), each hosting a dedicated FHIR server instance and maintaining identifiable patient data locally [11,24]. Periodically, the entire dataset is anonymised and transferred to a separate environment, the Global Insights Cloud (GIC), where analytics and controlled third-party interactions are enabled [25]. In parallel, a dedicated FHIR Implementation Guide was developed to standardise resource profiling, terminology system binding and profile extensions. Overall, the RETENTION framework establishes semantic alignment at the FHIR resource level prior to aggregation, enabling operational, multi-site harmonisation of longitudinal monitoring data within a privacy-preserving architecture.

The objective of this paper is to present and evaluate the RETENTION interoperability framework, focusing on its semantic modelling strategy, distributed multi-centre FHIR deployment architecture, security and privacy-by-design mechanisms, Implementation Guide engineering process and the privacy-compliant anonymisation pipeline that enables centralised analytics/model training and controlled third-party data exchange. It also aims to investigate whether a federated architecture combined with a lightweight FHIR profiling strategy and aggregated anonymised model training can sustain large-scale multi-site interoperability.

The remainder of the paper is structured as follows: Section 2 describes the RETENTION architecture, semantic modelling process, FHIR profiling strategy and privacy mechanisms. Section 3 presents operational deployment results and interoperability validation outcomes. Section 4 discusses architectural design decisions, scalability considerations and limitations. Finally, Section 5 summarises the conclusions and future directions.

2. Materials and Methods

2.1. RETENTION Platform Architecture Overview

RETENTION is based on a three-layer architecture composed of: (i) Patient Edge (PE), (ii) Clinical Site Backend (CSB) and (iii) Global Insights Cloud (GIC). Figure 1 provides a high-level overview of the RETENTION architecture, illustrating the interaction between the PE, CSB and GIC layers. Each layer consists of modular components, including data acquisition modules, FHIR repositories, security services and analytics workflows, that communicate via secure REST APIs or containerised services and are designed to fulfil a specific operational purpose [26]. The figure abstracts implementation details while focusing on the data flow and separation of identifiable and anonymised environments, which are crucial to the platform’s interoperability and privacy-by-design principles [11].

At the PE, a mobile application is used as a central tool for data acquisition. Clinical measurements including blood pressure, heart rate, pulmonary oxygen saturation and weight are collected via Bluetooth-connected medical devices (blood pressure meter, oximeter and weight scale). In parallel, activity, sleep and heart rate data are gathered via a smartwatch. Patients may additionally self-report body temperature, medication adherence and symptoms through structured application forms and a symptom reporting questionnaire. A home gateway, based on a Raspberry Pi (RPi), integrates a home sensor enabling the collection of internal temperature and humidity. An open API is used to acquire the outdoor equivalents as well as the pollution index. The data are then transmitted to the corresponding CSB through secure REST APIs.

For the CSB level, five distinct environments are used, one for each clinical site. Each CSB instance operates autonomously and maintains identifiable patient data locally, following a federated data management approach [27]. At this level, data originating from the PE are combined with clinician recorded data collected during baseline assessment, scheduled follow-up visits or unscheduled emergency encounters via a CSB dashboard. Each deployed CSB instance hosts the platform’s data repositories; an FHIR repository, powered by a dedicated HAPI FHIR (R4) server [28], storing all clinical and patient-related resources; and a non-FHIR repository used for storing environmental measurements and non-clinical data streams not represented as FHIR resources. This separation advances interoperability for clinical data while preserving flexibility for contextual variables. Each CSB deployment also includes a service which monitors remote device data and generates rule-based notifications for clinicians, a service monitoring patient adherence which generates notifications for device inactivity after a predefined time interval, a security component which handles data transactions and pseudonymisation of data, and a clinical CSB dashboard.

The GIC acts as the cross-site environment that periodically pulls fully anonymised data from the CSBs. At this level, global analytics and model workflows take place, while trained models are distributed back to CSB instances for local application [9]. The GIC also hosts the functionality of controlled transfer of anonymised data from or to the RETENTION platform by third-party users [29]. A dedicated GIC dashboard acts as a playground for a variety of expert categories, including data analysts, policy makers and stakeholders, offering insights from the clinical study without revealing any identifiable information for patients.

2.2. Semantic Reference Model

To enhance interoperability across heterogeneous clinical and real-world data sources [30], a semantic reference model was developed to represent the data requirements of the RETENTION platform [19]. This model defines the conceptual structure, variable categorisation and terminology bindings governing all data acquisition and exchange processes.

The modelling followed an Entity–Relationship (E-R) procedure, aiming for the identification of data entities, their attributes and how they relate to each other [31]. A patient-centric design was developed, to fully align with the FHIR structure of the data, where the “Patient” resource functions as the primary entity to which every other piece of information is linked [28]. The process was iterative, focusing on the identification of entities, the specifications of attribute relationship modelling and the mapping between attributes and entities. Continuous refinements and validation were performed in collaboration with clinicians, to ensure that the model accurately reflects the clinical protocol requirements. This modelling approach complements our previously reported work, where a detailed data modelling workflow was defined, including entity identification, attribute definition, relationship modelling, mappings and validation [19]. In the present study, this methodology is operationalised within an environment based on FHIR, enabling the implementation of the semantic model across distributed clinical sites.

The resulting reference model comprises 444 variables, organised into 14 domain classes, including demographics, baseline assessment, visits, clinical data, laboratory data, electrocardiography, echocardiography, medications, six-minute walk test, cardiopulmonary exercise test, questionnaires, VAD measurements, real-time device measurements and special events. Each variable is assigned a parent class ensuring semantic clarity and categorisation.

Terminology binding was applied to ensure interoperability. All variables were mapped to internationally recognised coding systems such as SNOMED CT, LOINC, ICD-10 and ATC [25,32]. In some cases, where no suitable terminology mapping was available, custom code systems were defined to preserve completeness of the clinical protocol without compromising homogenous semantic structure.

To facilitate machine-readable interoperability, the conceptual model was formalised as an ontology using semantic web technologies. Classes, data properties and object properties were encoded in standard formats (e.g., RDF/OWL) enabling hierarchical relationships and terminology associations [25]. This ontology representation serves as a bridge between conceptual modelling and FHIR resource profiling, elevating the semantic reference model as the foundational specification of the RETENTION interoperability framework [33].

Figure 2 illustrates how the conceptual semantic reference model is systematically aligned with FHIR resources and terminology systems, providing a visual representation of the mapping between domain variables and interoperable data structures. This alignment is essential to ensuring that heterogenous clinical and real-world data are consistently represented across all clinical sites, enabling data integration and interoperability. Furthermore, it highlights the role of the semantic model as the central linking layer between raw data acquisition and FHIR-based implementation.

2.3. FHIR Profiling and Implementation Guide Engineering

The developed semantic reference model was operationalised using HL7 FHIR Release 4 (R4), which was adopted as the interoperability standard for the project. A dedicated HAPI FHIR server was deployed for each CSB instance, managing storage and exchange of data [34].

The project’s clinical protocol was extensive and comprehensive, leading to a wide reference model, which consists of 444 variables across multiple domains. For this reason, a realistic profiling approach was followed, to avoid excessive complexity [35]. Rather than applying strict “StructureDefinition” and “ValueSet” constraints for every variable of the model, profiles were only created for variables where it was necessary [28].

A custom “Patient” profile was defined to extend the base FHIR resource and incorporate additional sociodemographic attributes required by the clinical protocol (education level, marital and employment status, etc.) [36]. These attributes were added as extensions to the base resource specification, as they were not supported by default. For the remaining variables, base FHIR resources (Observation, Condition, MedicationStatement, QuestionnaireResponse and Encounter) were used. Instead of defining heavy profiles, structured example instances were created to standardise how resources are represented and ensure consistent terminology mapping across all the deployment scenarios. This example-driven approach helped to maintain the engineering of the Implementation Guide simple and concise while preserving homogeneous representation across all deployment scenarios.

For variables which required enumerations by the clinicians (represented by dropdown menus in the CSB dashboard), custom “CodeSystem” resources were defined [32]. These “CodeSystem” resources were built in alignment with the semantic reference model and integrated into the FHIR Implementation Guide examples to ensure a consistent representation of all “CodeableConcepts”. A custom “CodeSystem” was also used for the variables which could not be mapped to any existing code of the terminology systems used.

The FHIR Implementation Guide was developed using Firely Forge for profile and extension definitions. Generated profiles, extensions and resource examples were subsequently expressed in FHIR Shorthand (FSH) format. The set of FSH resources was then delivered to SUSHI to generate a structured Implementation Guide. The Implementation Guide was used as a reference point by all developers dealing with any form of data handling, to ensure a compliant FHIR representation of each specific variable [37].

This selective profiling and example-based standardisation strategy acted as a balancing mechanism between the complexity of the semantic reference model and the operational flexibility. It allowed the platform to support a large and diverse set of variables without compromising interoperability and scalability [28].

2.4. Security and Privacy-by-Design Architecture

Security and privacy were integrated into the RETENTION platform following a privacy-by-design approach, ensuring that data protection mechanisms are applied at all levels of data handling [38,39].

The platform uses a security model designed specifically for its three-layer architecture. Each CSB operates as a distinct environment, maintaining identifiable patient data locally [40]. Communication between the three layers (PE, CSB and GIC) is conducted exclusively via secure REST APIs, while network segmentation is used to completely isolate the containerised databases.

Authentication and authorisation mechanisms are implemented using a role-based access control (RBAC) model [41]. Distinct user roles, such as clinician, technician and administrator, are assigned controlled permissions based on the principle of least privilege (PoLP) [42]. Access to CSB dashboards, FHIR endpoints and data management services is restricted according to predefined policies. Internal communication among platform components is similarly authenticated to prevent unauthorised service interactions.

At the production level, secure APIs regulate all inbound and outbound traffic, enforcing authentication, token validation and the filtering of requests. All FHIR server instances are deployed within controlled environments, preventing direct exposure of the corresponding repositories. Communication with the FHIR server is performed through the security component, which handles the pseudonymisation of the data, during both storage and retrieval [43]. Network segmentation is also applied, ensuring that the FHIR servers can only communicate with the necessary containerised components and services while restricting access to anything else.

Data confidentiality is also enhanced through encryption both in transit and at rest [44]. Sensitive data are stored encrypted in a distinct repository, while HTTPS protocols are used by all the APIs which handle data transfers. Privacy-by-design principles also govern the separation between personal and anonymised data. Identifiable patient information never leaves the corresponding CSB. The complete dataset of each clinical site is anonymised and transferred to the GIC, which serves as a distinct environment operating exclusively on an anonymised dataset [45].

This multi-layered security architecture enables controlled interoperability across distributed environments while preserving the autonomy of each clinical site and ensuring regulatory compliance [46].

2.5. Anonymisation and Cross-Site Aggregation Mechanism

Building upon the security-by-design framework described above, the aggregation of data collected by each clinical site within RETENTION is performed through an anonymisation pipeline executed locally at each CSB [45]. This design ensures that identifiable patient information is restricted to the originating clinical environment [40].

Prior to data transfer, each CSB follows a rule-based anonymisation process, applied on both direct and indirect identifiers. Direct personal identifiers (name, postal code, address, e-mail address, and phone number) are completely removed from the dataset [47]. To further reduce re-identification risk, indirect identifiers are categorised [45]. Demographic variables such as age, weight and height are transformed from raw measurements into predefined value ranges [47]. The mid-range value is actually used to ensure consistency between FHIR representations of the same variables in the CSBs and the GIC. This approach mitigates the possibility of attribute combinations that could lead to indirect identification of a patient. The ranges for each attribute were defined in collaboration with clinicians, aiming to preserve sufficient granularity for the model training process.

Temporal information is handled using a date-shifting mechanism. All dates are shifted relative to a specific reference timestamp before export (Figure 3). This method preserves internal longitudinal relationships within each patient’s record while further reducing the risk of re-identification [47]. As a result, time-series analytics can be successfully performed without revealing real temporal identifiers.

At the GIC level, the anonymised dataset is completely aligned to the semantic reference model and FHIR implementation framework, despite the data processing leading to anonymisation [9]. This enables cross-site analytical workflows and model training processes to be executed centrally. Trained models are subsequently distributed back to the CSBs for local execution on identifiable data [48].

2.6. Controlled Third-Party Data and Model Exchange Framework

To extend the interoperability framework beyond the participating clinical sites, the RETENTION platform incorporates a controlled mechanism enabling external users to interact with anonymised datasets and trained analytical models [46]. These interactions are exclusively performed on anonymised data representations at the GIC level.

Access to third-party users is granted by the project’s Data Management Board after considering an incoming request. External users authenticate via role-based access control mechanisms to ensure that only authorised users may perform data export or import functions.

Authorised external users may download anonymised datasets stored on the GIC. FHIR-compliant resources are retrieved in JSON format and packaged in compressed archives. Users may select specific clinical sites as data sources and generate downloadable links dynamically. Exported data conform to the RETENTION semantic reference model and Implementation Guide ensuring consistency, interoperability and reusability [9,28].

This tool also enables third-party users to upload structured datasets aligned with the RETENTION data model. Dedicated templates are provided to ensure compliance with the predefined variable structures and coding conventions. The uploaded files are parsed and stored separately in the GIC environment.

In addition to data exchange, the system supports the distribution of trained analytical models. External users may retrieve models associated with specific clinical cases. The architecture further allows configuration of models through parameter selection interfaces, allowing external users to experiment.

By allowing third-party user interaction with the anonymised datasets while enforcing alignment with the semantic reference model and Implementation Guide, the platform extends the research ecosystem and interoperability beyond the involved partners, while guaranteeing data protection and regulatory compliance [46].

Summarising the end-to-end data flow throughout the RETENTION platform, data are initially acquired at the PE through connected devices and patient-reported inputs. Subsequently, they are transmitted to the CSBs, where they are pseudonymised and stored, in alignment with the semantic data model. Anonymised datasets are periodically transferred to the GIC, where cross-site analytics and model training are performed. Finally, trained models are redistributed to the CSBs, while access to models and anonymised data can be authorised to third-party users under controlled conditions.

3. Results

3.1. Multi-Site Deployment and Real-World Operation

The RETENTION platform was successfully deployed across five independent CSB environments, supporting six hospitals in four European countries. Each CSB instance is operating autonomously, hosting a dedicated HAPI FHIR R4 server, local data repositories and secure APIs in accordance with the three-layer architecture described in Section 2.1.

At the time of recruitment completion, 390 patients had been enrolled across the participating sites, including 219 heart failure (HF), 64 left ventricular assist device (LVAD) and 107 heart transplant (HT) patients. The platform has supported 4245 patient-months (133,157 patient-days) of monitoring to date, with a median follow-up of 11 months and the first participants reaching up to 22 months of monitoring.

Each CSB instance successfully operates on the semantic reference model which is described in Section 2.2. Clinical assessments, remote device measurements and patient-reported outcomes are stored using a unified patient-centric FHIR representation. The low dropout rate, currently 6.66%, supports system usability, as patients maintain high engagement with the remote monitoring devices and digital reporting mechanisms throughout an extended follow-up period.

3.2. Semantic Harmonisation and FHIR Interoperability Validation

The distributed deployment of five independent FHIR servers, in combination with the existence of multiple data sources for each CSB instance (CSB dashboard, remote devices, and mobile application), introduced a validation scenario for semantic harmonisation under real-world conditions.

The platform is currently supporting the ongoing clinical trial, which started in May 2024 and will continue until August 2026. During the operational phase of the platform, a substantial number of data have already been collected.

Table 1. Data recorded by the RETENTION platform to date.

Category	FHIR Resource	Data Points
Remote devices	Observation	3,644,016
Visits	Encounter	1239
Events	Observation	189
Laboratory Data	Observation	38,127
Clinical Data	Observation	19,171
Echocardiography	Observation	14,576
Electrocardiography	Observation	5633
Six-Minute Walk Test	Observation	2680
Cardiopulmonary Exercise Test	Observation	335
VAD	Observation	40,878
Medications	MedicationStatement	4954
Questionnaires	QuestionnaireResponse	24,303
Demographics	Patient (extended)	1819
Baseline	Observation	12,520
	Condition

summarises the distribution and volume of the collected data across the participating clinical sites, providing an overview of the scale and heterogeneity of the dataset managed by the RETENTION platform. The presented statistics highlight the capability of the proposed infrastructure to support continuous data acquisition, including both clinical and real-world data, and demonstrate the robustness of the platform in handling large-scale datasets while maintaining consistent data representation across all sites.

All the above entries were stored using harmonised FHIR resource structures, aligned with the RETENTION Implementation Guide. The FHIR base resources which were used include “Patient”, “Observation”, “Condition”, “Encounter”, “MedicationStatement” and “QuestionnaireResponse”, supplemented by 42 custom “CodeSystem” resources created for categorical variables and two for mapping variables that could not be represented by the terminology systems used.

Despite the selective profiling strategy adopted as mentioned in Section 2.3, where only the “Patient” resource was extended while most of the variables were standardised through examples, interoperability across the five CSBs and the multiple data sources was preserved. During the aggregation of the anonymised data at the GIC, no schema conflicts nor terminology inconsistencies were observed.

This finding demonstrates that large-scale semantic harmonisation can be achieved with a soft profiling and validation strategy, when the structure guidelines and terminology bindings are appropriately documented even just as examples in a centralised Implementation Guide.

3.3. Large-Scale Remote Data Ingestion and Longitudinal Density

As reported in the previous section, beyond manual data entries from clinicians during sparse scheduled or emergency patient visits, a large number of data are acquired with remote devices through daily monitoring. Over 133,157 patient follow-up days, 3,644,016 data points from remote devices were recorded, corresponding to an average of 27.37 data points per patient per day.

These data streams refer to blood pressure and heart rate measurements from a blood pressure meter, capillary oxygen saturation and heart rate measurements from an oximeter, body weight from a weight scale, body temperature, VAD measurements, medication adherence and symptoms’ questionnaires reported by patients through a mobile application, and finally heart rate, activity and sleep metrics collected by a smartwatch. Environmental data which are acquired via an RPi and stored in the non-FHIR repositories are not included.

Despite variability in patient adherence, connectivity conditions and device behaviour, which constitutes typical real-world problems, the system maintained a continuous and sufficient data flow from the remote devices. Of course, this large-scale remote data ingestion is fully aligned with the semantic reference model and FHIR representations of remote device data following the Implementation Guide rules. Furthermore, the resulting dataset provides high temporal density supporting analytics and model training.

3.4. Privacy-Preserving Aggregation Feasibility

The anonymisation pipeline described in Section 2.5 is periodically executed at each CSB, before the transfer of data to the GIC. Direct identifiers are removed, specific variables are transformed from raw measurements to predefined ranges, and all dates are shifted in relevance with a specific reference timestamp.

Despite the transformation process of the data, alignment with the semantic reference model and FHIR-based schemas is completely preserved. Even for categorised variables, the mid-range point of each interval is selected to ensure that representation of the same information is identical both at identifiable CSB and anonymised GIC levels.

The RETENTION platform is designed to support centralised analytics workflows performed on harmonised anonymised datasets. While predictive model evaluation is currently in progress, the infrastructure for federated to central analytical pipelines is fully operational, with models being iteratively trained and scheduled to be redistributed to the CSB instances for personalised predictions.

3.5. System Performance and Operational Stability

System performance of the RETENTION platform was assessed by indirect indicators. The low dropout rate of 6.66%, alongside an average of 27.37 daily data points per patient, reveals a satisfying level of user engagement and adherence. Furthermore, problem-reporting mechanisms which have been established since the beginning of the clinical trial have led to the successful handling of both platform errors and improvement requests.

Across the five independently deployed CSB instances, no interoperability issues have been recorded during the aggregation of data to the GIC. The federated architecture has demonstrated operational stability by successfully supporting everyday clinical practice and real-time acquisition of data from remote devices. These findings indicate that the RETENTION interoperability framework operates smoothly on a production level, with multi-site deployment capable of sustaining high-volume data exchange under privacy and security constraints.

At the current stage of the RETENTION project, full technical and clinical evaluation of the platform is still in progress, and outcomes will be available after the end of the ongoing clinical trial. Therefore, this study reports operational indicators that reflect real-world deployment status, including patient retention and volume of collected data. In this context, the dropout rate was calculated as the percentage of patients who have formally withdrawn from the clinical trial relative to the total number of enrolled patients.

4. Discussion

The RETENTION interoperability framework proves that large-scale, multi-site clinical infrastructures can be implemented using HL7 FHIR while preserving local sovereignty, privacy compliance and semantic consistency. The deployment across five different clinical sites and the successful aggregation of high-volume diverse datasets provide practical evidence that structured interoperability can be achieved in real-world conditions without relying on excessive profiling strategies [7,9].

4.1. Lightweight Profiling as a Scalability Strategy

One of the key engineering decisions of the project was the adoption of a selective profiling approach. Instead of defining strict “StructureDefinition” and “ValueSet” limitations for each of the 444 variables of the semantic reference model, only the “Patient” resource was extended, while most of the variables were standardised through example-based documentation in the Implementation Guide.

This decision was primarily driven by scalability considerations. The heavy profiling of hundreds of variables can introduce maintenance load, implementation, and documentation complexity, leading to possible interoperability risks [49]. The operational results indicate that example-based standardisation can provide sufficient harmonisation across different deployment scenarios, when combined with strict terminology bindings and disciplined implementation [32].

The absence of schema conflicts during aggregation of data gathered from different CSBs and by various methods suggests that semantic alignment does not necessarily require exhaustive structural constraints and validation [28]. This finding is particularly relevant to research-oriented infrastructures, where flexibility and extensibility are critical [9].

4.2. Federated Identifiable Data—Centralised Anonymised Analytics

The RETENTION architecture follows a federated deployment model with identifiable data only residing in repositories hosted by distinct CSB environments, combined with centralised aggregation of anonymised datasets for model training. This design differs from purely federated approaches [50], where data never leave local environments, and purely centralised architectures [43].

Compared with existing interoperability approaches, the RETENTION framework follows a distinct operational paradigm. CDM approaches such as OMOP primarily support retrospective harmonisation of heterogenous datasets through ETL processes and are not usually designed for real-time ecosystems handled by APIs [14,17]. Similarly, federated learning frameworks focus on decentralised analytics but generally assume pre-harmonised local data representations [13]. RETENTION, on the other hand, establishes semantic alignment of the data prior to aggregation [28]. Finally, document-centric infrastructures such as IHE/XDS support data exchange at the document level but lack the granularity required for high-frequency monitoring data [15,16]. The proposed approach therefore combines semantic harmonisation, federated deployment and centralised anonymised analytics within a unified framework. To further contextualise the proposed framework, a conceptual comparison with representative interoperability approaches is presented in

Table 2. Conceptual comparison of interoperability approaches.

	OMOP CDM	Federated Learning	IHE/XDS	RETENTION
Data model	Relational CDM	Model-based	Document-based (CDA)	FHIR-based
Interoperability level	Retrospective	Analytical	Document level	Resource-level
Data location	Centralised/federated	Local only	Distributed	Hybrid (local + central anonymised)
Real-time support	No	Limited	Limited	Yes
Semantic harmonisation	Post hoc (ETL)	Assumes pre-harmonised data	Low granularity	Built-in semantic model
Privacy mechanism	De-identification	Data locality	Access control	Pseudonymisation + anonymisation

.

By restricting identifiable data to CSBs and transferring only anonymised datasets to the GIC, the platform achieves a compromise between regulatory compliance and analytical scalability [51]. At the CSB level, clinical practice is normally supported, with clinicians being able to monitor patients remotely and perform the scheduled follow-up assessments. In parallel, anonymised datasets are utilised at the GIC level for model training and analytics. Data and model interactions are also available through a dedicated tool, described in Section 2.6. Further anonymised findings from the clinical trial offer insights for a variety of expert categories, including data analysts, policy makers and stakeholders, while the clinical trial is in active conduct.

The operational outcomes have confirmed that anonymisation processes have not inserted any issues regarding structural interoperability and temporal integrity. Overall, this separation of identifiable and anonymised environments preserves privacy and security compliance while expanding the research impact of the study [52,53].

4.3. Interoperability Under High-Density Real-World Data Streams

A distinguishing characteristic of the RETENTION framework is the integration of high-frequency remote monitoring data with structured clinical monitoring under a unified semantic model. The acquisition of millions of data points by remote devices across more than 130,000 patient-days demonstrates that infrastructures based on FHIR can sustain high temporal density in addition to conventional, sparse clinical data [6,36].

In many health information systems, interoperability efforts focus primarily on scheduled hospital encounters and laboratory records. In contrast, RETENTION incorporates a daily real-time physiological and behavioural monitoring into its semantic framework. The successful alignment of remote device data with FHIR “Observation” resources validates the applicability of FHIR to large-scale remote patient monitoring scenarios [7].

4.4. Engineering Lesson from Federated Multi-Centre Deployment

Large-scale FHIR infrastructures and multi-site research networks are increasingly emerging as foundational components of digital health ecosystems [54]. The distributed deployment across five autonomous CSBs provides a realistic validation scenario for the RETENTION platform architecture, development and operation. Each site integrates data from multiple sources, including clinical dashboards, mobile applications and remote devices. Despite the federated deployment and the heterogeneity of data streams, the aggregated anonymised dataset presents harmonised FHIR representations of data.

This practically indicates that early architectural planning and structured design, in supporting large-scale, long clinical studies, reduce risks and burdens from later stages. The definition of a centralised semantic reference model prior to implementation proved to be critical [55]. Clear Implementation Guide documentation prior to component development maintains homogeneity in data representation by ensuring that every data exchange operation complies with the guidelines set by the reference model [28]. Lightweight profiling, relying on examples rather than strict constraints and validations, preserves simplicity and flexibility in model maintenance and updates [9]. Furthermore, this example-based Implementation Guide approach enhances developer-friendliness, by presenting minimum but concise data schemas to users, instead of exhaustive “StructureDefinition” and “ValueSet” resources [30].

The observed operational stability and the handling of a large number of data, as detailed in Section 3.2, suggest that containerised FHIR server deployment combined with REST APIs and security-privacy mechanisms provides a robust foundation for multi-centre research infrastructures.

4.5. Limitations

Despite the demonstrated feasibility, the RETENTION platform and interoperability framework present several limitations.

Initially, the selective profiling strategy, while scalable and easy to maintain, does not enforce strict validation against the FHIR schema for every variable. This proved to be a good strategy in the boundaries of even a large-scale research clinical study, with multiple variables and heterogeneous data streams. Stronger conformance validation mechanisms, based on a broader use of FHIR artefacts such as “StructureDefinition” and “ValueSet” resources, would be necessary to enhance interoperability robustness, particularly in broader deployment scenarios beyond the scope of this study [35]. It should be noted that full terminology binding has already been established within the semantic reference model. The remaining gap concerns the formal definition of profiles and the enforcement of constraints based on the allowed coded values.

Furthermore, predictive model evaluation is currently ongoing within the RETENTION project, which is still in the clinical trial phase, and has not yet reached a mature stage suitable for comprehensive reporting. For this reason, the present study focuses on the interoperability infrastructure and its operational validation, while analytical performance outcomes will be addressed in future work after the completion of the trial. The external user interaction tool is currently operational at the infrastructure level but has not yet been fully exercised under large-scale usage scenarios.

In addition, the complete elimination of re-identification risk cannot be fully guaranteed [43]. Further measures, including the insertion of synthetic data into the anonymised datasets, have been considered but are not yet defined as necessary to implement [56].

Finally, the transfer of a large number of data from five distinct CSB-level FHIR servers to an aggregated GIC-level one, with the intervention of a security component that handles the pseudonymised data and the parallel enforcement of anonymisation processes at each CSB, poses some accountable delays in the completion of the pipeline. No mitigation measures have been required so far, but this is something to be investigated, as the datasets expand in size.

4.6. Future Directions

Future work will extend the current interoperability framework towards systematic evaluation of predictive models trained on harmonised anonymised datasets, following the completion of the ongoing clinical trial and enabling assessment of performance and cross-site reproducibility. Further research will investigate scalable mechanisms for secure third-party data and model exchange under controlled interoperability constraints. Additionally, advanced anonymisation strategies and privacy-enhancing techniques may be explored to further mitigate re-identification risks while preserving the power of the analysis [56]. Alignment with emerging European Health Data Space (EHDS) initiatives [57] may also be examined to evaluate how federated FHIR-based infrastructures can support clinical care at a European scale.

5. Conclusions

This paper presents the RETENTION interoperability framework, a multi-centre FHIR-based infrastructure designed to support heart failure patient monitoring through integration of heterogeneous clinical and real-world data sources. For the operational needs of the platform, a comprehensive semantic reference model consisting of 444 variables was designed. Dedicated HAPI FHIR server instances were deployed to support it across five different CSBs.

This study demonstrates that large-scale semantic harmonisation can be achieved using a selective profiling strategy, accompanied by strict terminology binding and example-based Implementation Guide documentation. Despite the absence of strict constraints for every variable, cross-site aggregation of anonymised datasets was performed without schema conflicts and terminology inconsistencies.

The federated architecture combined with centralised anonymised aggregation enabled model training workflows while preserving privacy compliance. Operational engagement of 390 patients and more than 130,000 patient-days confirm the stability of the infrastructure under real-world conditions, including ingestion of high-frequency remote monitoring data.

The RETENTION platform illustrates that FHIR-based interoperability infrastructures can extend beyond sparse clinical records, to support continuous multimodal data streams in active clinical studies. By balancing semantic governance, architectural scalability and privacy-by-design principles, the proposed approach provides a reproducible model for future digital health platforms oriented to research.

Future research will evaluate predictive model performance, advance secure interoperability mechanisms, reinforce privacy protection strategies, and explore alignment with European Health Data Space (EHDS) initiatives.