In this phase, we selected Garmin Vívoactive 4 smartwatches for their ability to track key PGHD, including heart rate, step count, sleep patterns, activity intensity, stress level, etc.

Once the Garmin Vívoactive 4 devices were enrolled, they were set up to continuously track and record health metrics which are vital for monitoring an individual's physical activity, sleep quality, burning calories, body composition, and overall health. This setup involved adjusting the data sampling rates and ensuring the devices could automatically sync with the central system through the Garmin Connect tool, which ensured a smooth and nonstop flow of data.

On the other hand, real-time monitoring was essential for tracking important health measures. Therefore, the Garmin Connect tool was used to configure the devices, making sure they were correctly set up to gather data while also ensuring that the data synced accurately with the central system for reliable and constant data transfer.

Aligned to better management of data collection, the Fitrockr hub was employed. The Fitrockr hub served as the central platform for data acquisition, where it securely gathered and organized the data from the Garmin devices. This platform has been shown to enhance data integration by supporting various wearable technologies and ensuring secure data administration (24).

The collected data was then prepared for integration with the FHIR server. A critical component of this process was using the Fitrockr data dictionary, which provided a list of standardized data elements for the PGHD from wearable tools (25). In other words, it provides a clear point of view on wearable health data, and then defining details of interoperability between different systems will be easier.

The Fitrockr data dictionary provides structured naming and codification of PGHD variables derived from Garmin and other wearable devices. The codification primarily relies on vendor-specific identifiers, using parameter names and structures defined in the Garmin Health API (25), which are then systematically organized within Fitrockr's internal data dictionary (26). This enables structured extraction of key health metrics such as heart rate, step count, and sleep stages. However, the data dictionary does not currently use clinical coding systems such as LOINC or SNOMED CT, limiting direct clinical interoperability.

The data dictionary is maintained and validated internally by the Fitrockr team, who test its accuracy and reliability through various production-level integrations. While not externally certified, the data schema is stable and widely used in Fitrockr's deployments for research and wellness analytics.

Although it is not officially integrated with the HealthData@EU framework, the Fitrockr dictionary, due to its structured formatting and FHIR mapping offers a model that could be adapted to align with the interoperability goals defined by the TEHDAS recommendations (22), especially in the context of secondary data use and PGHD harmonization within EHDS.

By utilizing the Fitrockr hub and its data dictionary, we ensured that all PGHD was accurately formatted, stored, and prepared for smooth integration into the healthcare ecosystem.

The hub also played a vital role in maintaining the integrity and quality of the data throughout the intake process, ensuring that it met the necessary standards for further analysis. If any errors occurred in the data, such as inconsistencies in format or unusual values, the hub would identify and correct these issues by using preprocessing and correction methods, such as fixing incorrect values or aligning the data with the correct formats.

This process ensured that the data remained accurate and ready for subsequent analysis, which in the next step involved mapping to FHIR standard resources. Additionally, users could monitor and view their data through the Fitrockr dashboard, which demonstrated the integrated data on the hub. Figure 3 illustrates a snapshot of the Fitrockr hub.

The Kodjin FHIR server was selected to ensure standardized data storage and retrieval. It was configured to support seamless processing of FHIR resources and enable secure management of our prototyping on PGHD. The Kodjin solution uses a low-code declarative approach, allowing for efficient integration with minimal coding. We used a cloud version of the Kodjin FHIR server in this study.

To make the data ready for integration with the FHIR server, we used the secure Public Fitrockr API to access the collected PGHD from the Fitrockr hub and then mapped each data element individually and created an FHIR bundle, ensuring it was practical with the FHIR standard.

Moreover, the Public Fitrockr API was used for its secure, standardized access to Garmin data. Participants voluntarily initiated data sharing via the study portal. Token-based authentication and encrypted communication ensured GDPR-compliant, ethical use of PGHD in the research.

In this step, we mapped the processed and collected data to FHIR profiles using the Edenlab transformation tool to ensure seamless integration. In this process, key FHIR resource types were used, including Patient for personal information like name, gender, birth date, and contact details, and Observation for capturing health-related data such as Heart Rate, stress data, respiration, steps, VO2 max, Pulse Ox, BBI data, etc.

These resources were structured and linked appropriately, allowing consistent and standardized data exchange, aligning with the FHIR framework for smooth interoperability and integration into healthcare ecosystems.

We utilized the Kodjin mapping tool to convert the Garmin Vívoactive 4 PGHD collected on the Fitrockr hub into appropriate FHIR resources as a Liquid.

In fact, Liquid is a template language designed to work with FHIR resources data mapping. It enables complex mappings and offers flexibility for data processing tools. This facilitated unified mapping and ensured compatibility with the FHIR standard for further integration into healthcare systems (27).

Some of the data we retrieved from the Fitrockr hub and mapped to FHIR resources is illustrated in Figure 4. In addition, to further demonstrate the data transformation process, we have included a raw JSON sample from the MORE research platform and its mapped version in FHIR format in the Supplementary Material.

In this prototype, we developed a portal to allow users to control their data-sharing preferences. This web-based portal provides an option for them to exclude sensitive data, such as demographic details or stress analysis, and send only selected data to the server of their choice.

In this research-focused project, formal consent forms were not applied, as the study did not involve clinical intervention or treatment. Instead, we developed a participant-controlled portal that allowed individuals to fully access and review their wearable data collected through Fitrockr.

Data sharing only occurred when participants actively clicked a “Send to FHIR Server” button, indicating voluntary and informed participation in the research. This design supports the principle of active informed consent through action, ensuring transparency and autonomy.

To ensure privacy and compliance with the GDPR, pseudonymization was implemented during data transmission to the FHIR server, each participant was assigned a unique, non-identifiable code that replaced direct identifiers in the server. In the second part of the study, where we analyzed data exported from the MORE platform, no direct transmission occurred. These datasets were already anonymized due to their research nature, and no identifying information was included. As such, GDPR compliance was ensured through anonymization at source.

While this solution is specific to the research study, adopting GDPR-compliant practices is critical for larger-scale projects to protect user privacy and ensure data security by consulting with GDPR experts to ensure that the solutions meet the European regulation standards for data sharing, such as using short message (SMS) on participants mobile phones to give their confirmation before using related data.

At the same time, for verification and confirmation on the successful transfer of data to the FHIR server, we developed a quick dashboard that allows for retrieving and fetching PGHD based on FHIR identifiers such as Patient ID and Participant ID or Patient name, etc. Therefore, it serves as a tool and proof for verification of the entire process in our work.

We worked with a subset of JSON-formatted PGHD instead of utilizing an API. The extracted data was reviewed to determine the necessary transformations for mapping to FHIR resources.

In our analysis of the MORE research platform, we identified that the research data is categorized into four key elements: •

Heart Rate: Physiological data obtained from wearable devices.

To align the data with FHIR standards, we mapped each data type to the corresponding FHIR resources: •

Heart rate, GPS data, and acceleration → FHIR Observation

The integration of real-time data processing frameworks for PGHD, especially in the context of PREMs and PROMs, should be prioritized for future efforts. This involves leveraging machine learning (ML) and artificial intelligence (AI) for live analysis of PGHD, enabling actionable insights and supporting Clinical Decision Support Systems (CDSS) (29–31). These advancements would enhance personalized care and precision medicine by utilizing live data from wearable devices to optimize care decisions. Expanding AI-driven predictive analytics for clinical outcomes will improve decision-making and treatment pathways, offering more targeted and effective healthcare interventions (32).

Ensuring the security and privacy of sensitive health data is crucial in the integration of PGHD into the healthcare system. Since wearable devices are not classified as medical devices, the legal status and standards of PGHD are still under development, requiring further research on their quality, authentication, and authorization processes. The EHDS aims to establish a harmonized framework for health data sharing while ensuring strong data protection measures, particularly in compliance with the GDPR and other European laws (33).

Additionally, future work should emphasize developing robust encryption and privacy-preserving technologies, such as federated learning and especially homomorphic encryption, to protect PGHD during transmission and storage. Furthermore, systems for managing dynamic consent in compliance with EHDS and GDPR should be designed to ensure data security without compromising clinical utility (34). In this context, emerging technologies such as blockchain offer promising models for secure and transparent data sharing while maintaining patient consent and traceability. Recent researchs are exploring the disruptive potential of blockchain in managing health data compliance, particularly under GDPR (35).