記住我
With constant advancements in digitalization, wearable devices such as smartwatches, fitness trackers, or chest straps are becoming an integral part of everyday life. These devices facilitate continuous recording and monitoring of patient-generated data, such as sensor-based health data (SHD) and electronic patient-reported outcome measures (PROMs). If these data were efficiently shared with physicians, they could gain a more comprehensive view of a patient’s lifestyle and longitudinal insights into a patient’s health trajectory []. Although most wearables are designed for the consumer market and are not primarily intended as medical devices, initial clinical trials have shown that the quality of patient-generated data from wearable consumer devices is sufficiently high to answer medical questions [-]. In addition, selected wearable consumer devices have been approved for various diagnostic purposes by authorities such as the US Food and Drug Administration. Especially for physical activity and cardiovascular monitoring, the development of wearables with accurate sensors is well advanced (eg, for step count as well as heart rate and electrocardiogram [ECG] measurements).
Patients show willingness to share their self-generated data with physicians, anticipating that the integration of wearables into their health care journey positively enhances their health []. Consequently, this holds potential for both patients and physicians to engage in collaborative health management. This can include monitoring the patient’s health status; managing risk factors; and facilitating asynchronous feedback to support effective self-management, especially in the case of chronic conditions []. In addition, it has the potential of reducing the frequency of needed physician consultations; improving quality of life; and, ultimately, reducing long-term treatment costs [-].
To exploit this potential, suitable IT systems following a patient-centric design must be available. In the literature, these systems are often referred to as telehealth, telemedicine, eHealth, mHealth, or remote patient monitoring (RPM) systems; the terminology is used interchangeably and inconsistently [,]. RPM systems must be able to process and transfer large amounts of data in an automated manner and should facilitate the integration of wearable devices into a patient’s everyday life as well as into standardized primary care and clinical research workflows. Methods for realizing such integrations are still immature due to numerous challenges in areas including patient digital literacy, data overload, interoperability, data privacy, data protection, and information security [-]. Overall, high usability and, consequently, high acceptance of RPM systems among patients during their treatment process is needed a priori. In addition, wearables are mostly used by healthy individuals as lifestyle devices [] or for early disease detection in younger adults, such as in the Apple Heart Study [] or the Fitbit Heart Study [].
ObjectivesIn its position papers on wearable-based detection of arrhythmias [] and eCardiology [], the German Cardiac Society and other international organizations emphasize the benefits of wearables and RPM systems for primary care and clinical research, including the treatment of heart failure. This chronic disease has a high worldwide prevalence, with an estimate of up to 64 million individuals affected. In high-income countries, it is assumed that 1% to 2% of the adult population has heart failure []. These patients usually have multiple contact with health care providers each year; the rehospitalization rates can approach 30% within 90 days of discharge []. RPM systems have been shown to detect early health deterioration of patients with chronic heart failure, triggering therapeutic interventions that could reduce rehospitalizations. Overall, approximately 30% to 40% of patients with heart failure have nonischemic cardiomyopathy, such as dilated cardiomyopathy (DCM) []. Patients with DCM face physical and quality of life limitations and are often young. In the past, they have been discouraged from physical activity []. However, exercise has, in principle, been shown to positively impact morbidity, quality of life, and patients’ psychological state, which in turn enhances their physical well-being [-]. Sports-related complications, such as ventricular arrhythmias, can counteract the positive effects. Therefore, the activeDCM study [] investigated the impact of an individualized exercise program in patients with DCM. In this paper, we introduce the RPM system used in activeDCM, detailing its conceptualization, implementation, and evaluation. The objective of this study was to create a user-friendly, reusable, interoperable, and secure RPM system incorporating asynchronous feedback mechanisms using a broadly available consumer wearable device for primary patient input. In addition, this study sought to evaluate factors influencing patient acceptance of the developed RPM system.
activeDCM was designed as a prospective, randomized, interventional case-control study and is described by Sedaghat-Hamedani et al []. The primary outcome measure of activeDCM was defined as the change in maximum oxygen uptake, whereas the secondary outcome measures focused on changes in quality of life and behavioral lifestyle. The inclusion criteria for patients were age between 18 and 75 years and diagnosis of nonischemic DCM (left ventricular ejection fraction of ≤50% and New York Heart Association Classification of I-III). The exclusion criteria were acute myocarditis or Takotsubo syndrome; known or suspected ischemic heart disease; known syndromic DCM; history of syncope, cardiac arrest, sustained ventricular tachycardia, or cardiac decompensation within the previous 3 months; contraindications for exercise testing or training; and pregnancy or breastfeeding in women. Patients were identified during initial presentations or routine examinations at the outpatient center for cardiomyopathies at Heidelberg University Hospital and were screened against the inclusion and exclusion criteria by a physician familiar with the study. Participation in the study lasted at least 12 months for each patient. On the day of enrollment, patients were randomly assigned to one of three study arms: (1) intervention group with an individualized exercise program and feedback messages (IG+), (2) intervention group with an individualized exercise program but without feedback messages (IG–), and (3) control group (CG).
RequirementsUsing the focus group methodology [], the following requirements for a patient-centric RPM system were systematically delineated through collaborative sessions involving cardiologists (n=3), mobile health experts (n=2), and potential users (n=2) affiliated with Heidelberg University Hospital, Germany.
The functional requirements were as follows:
Patients should use a wearable as primary input device. They should be equipped with a wearable by the study team and not use their own device.Patients should be able to record and transmit patient-generated data (ie, the SHD steps, active burned energy, heart rate, and ECG as well as the PROMs of a study-specific, weekly 7-part questionnaire and an optional exercise diary) in near real time to the study center.Physicians should be able to send personalized feedback messages to patients with motivational content about the individualized exercise program.Physicians should be able to review the substantial volume of transmitted patient-generated data in a streamlined format.The nonfunctional requirements were as follows:
The RPM system should prioritize usability, thereby minimizing barriers to integrating the wearable into patients’ daily routines as many patients are older and a prestudy showed little penetration of wearable devices in this cohort (data not shown).The RPM system should be based on medical IT standards for interoperability.The RPM system should meet the regulatory requirements for data privacy and data protection as well as provide state-of-the-art information security.The RPM system should be usable beyond the activeDCM study.Concept and ImplementationOn the basis of the identified requirements, a concept of an RPM system with asynchronous feedback mechanisms was designed and subsequently implemented using an iterative approach. In each iteration, a new module of patient-generated data or for feedback messages was added to the system. Throughout the implementation process, a test environment was available, allowing for the immediate testing of each newly added module. This facilitated short feedback cycles with test participants and physicians from the activeDCM study and ensured the technical feasibility of a patient-centric RPM system.
The final concept, as well as the implementation, consisted of 4 main components: patient devices, data server, data viewer, and notification service (see the Results section). The patient devices used in this study included an iPhone (SE generation 1 or newer) and an Apple Watch (Series 4 or newer, generously provided by Apple Inc). A study-specific wearable and smartphone app was implemented using the Swift programming language (version 5.1; Apple Inc) [] for the operating systems of both devices (ie, iOS version 14 and watchOS version 7). The extraction of the SHD (steps, active burned energy, heart rate, and ECG) was based on the Core Motion [] and HealthKit [] frameworks for iOS and watchOS development. The PROMs (study-specific, weekly questionnaire and optional exercise diary) were recorded by means of a self-designed user interface using Apple’s UIKit [] framework. The transfer of data from the Apple Watch to the iPhone and vice versa was based on the iOS and watchOS Watch Connectivity protocol []. The data storage on the iPhone was based on the Realm database (version 5.5; MongoDB Inc) [].
The implementation of the data server as well as the transmission of the patient-generated data was based on the standardized application programming interface (API) and the standardized data model of Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) version R4 [], as well as the Logical Observation Identifiers Names and Codes (LOINC) [] and the Unified Medical Language System (UMLS) [] (see the Data Model section) in the Java programming language (version 11; Oracle Corporation) [] using the HAPI library (version 5.2) []. The database technology used was PostgreSQL (version 12; PostgreSQL Global Development Group) [].
The physician data viewer component was implemented as a mobile-first TypeScript (version 4.1; Microsoft Corp) [] web application using the vue.js framework (version 2) [] and the chart.js library (version 2) []. The notification service was provided by the device manufacturer (ie, Apple Inc). Local on-device and remote push notifications for the patient devices were implemented using the User Notifications [] framework for iOS and watchOS development.
The aforementioned version numbers correspond to the ones at the beginning of the implementation process and were regularly updated during the use of the RPM system if new applicable versions were released or APIs changed. These updates did not change any functionality or user interfaces of any component.
ProcedureTo ensure both technical and clinical feasibility, the RPM system was used in the activeDCM study following a procedure that was developed in addition to the requirements as part of the focus group sessions. The procedure is illustrated in . On the day of enrollment, patients were randomized to 1 of the 3 study arms and provided with a configured device bundle consisting of a consumer wearable (Apple Watch Series 4 or newer) and a smartphone (iPhone SE generation 1 or newer) on which the corresponding app of the RPM system was preinstalled. Patients were not provided with a mobile data volume contract for the devices; instead, they were required to set up a Wi-Fi connection at their home. After a thorough patient educational session regarding the study and the RPM system covering instructions on use of the wearable and smartphone, including the RPM-specific app and how to launch a workout session with resultant increased frequency of activity measures, patients signed the written informed consent form. After that, they were onboarded to the app by scanning a patient-specific QR code using the smartphone’s camera. From this point forward, the required SHD were continuously recorded by the wearable. The synchronization of the recorded data with the study center was confirmed by patients through a short daily interaction with the wearable. In addition, patients were asked to answer 1 randomly selected question daily from the study-specific, weekly 7-part PROM questionnaire [], requiring a second daily interaction. To remind patients of these 2 mandatory interactions with the wearable, they were alerted daily at 11 AM and 5 PM with local on-device push notifications sent directly by the wearable app. An interaction with the smartphone was not mandatory but could take place to keep an optional PROM exercise diary, which was synchronized with the study center as well. Each patient was part of the activeDCM study over a period of at least 12 months. Patients were allowed to withdraw at any time from the study. During participation in the study, patient-generated data were collected and transmitted from the wearable via the smartphone to the study center, which in turn provided feedback messages to the patients in the corresponding intervention group (IG+). Feedback messages containing motivational content about the individualized exercise program were sent by a physician using the study center’s data viewer approximately every 7 to 10 days using remote push notifications.
Figure 1. Use of the remote patient monitoring (RPM) system in the activeDCM study. After onboarding, patients are equipped with devices whose RPM system app is activated by scanning a patient-specific QR code. Patient-generated data are then continuously recorded and transmitted to the study center until the end of follow-up. Physicians analyze the data and send feedback messages to the patients’ devices if appropriate. IG+: intervention group with feedback messages. EvaluationThe evaluation of the RPM system was conducted in 2 parts. First, to assess patients’ subjective perspectives on the RPM system, a 2-part evaluation questionnaire was used to address the following two end points: (1) the first part of the evaluation questionnaire asked about experience (no: without previous device experience [Exp–], yes: with previous device experience [Exp+]) using Apple devices (iPhone or Apple Watch) before participating in the activeDCM study and used a German version [] of the standardized System Usability Scale (SUS) [] to assess user-friendliness, and (2) the second part contained 5 self-designed questions to assess patients’ attitudes toward the use of an RPM system for disease management.
Both parts of the evaluation questionnaire—the SUS and self-designed questions—used a 5-point ordinal Likert scale with each item ranging from strongly disagree to strongly agree. An SUS value of >68 was considered user-friendly []. The evaluation questionnaire was administered to each patient at completion of the activeDCM study protocol after at least 12 months and can be found in .
Second, to assess patients’ objective use of the wearable and the interaction with the study-specific wearable and smartphone app, three additional end points were evaluated: (3) to assess wearable interaction frequency, the number of days with at least one wearable interaction (either SHD transmission or answering a PROM questionnaire item) was compared with the total number of days that a patient was enrolled in the study; (4) SHD completeness was assessed by comparing the days with available SHD on the data server with the total number of days that a patient was enrolled in the study; and (5) finally, to assess PROM completeness, the number of completed and available PROM questionnaires on the data server was compared to the total number of PROM questionnaires expected to be completed during the study period (1 per week).
The statistical analysis of all 5 end points was conducted using descriptive statistics incorporating box plots. Continuous variables were described using mean and SD, and categorial variables were described using absolute and relative frequencies. Assessment of differences in the patient demographics of the evaluation groups was performed using the Kruskal-Wallis test [] for continuous variables. For categorical variables, the Pearson chi-square test [] was used.
As the number of days for which each patient participated in the activeDCM study varied, we calculated relative values for end points 3, 4, and 5 for each patient. We then described these relative values using mean and SD and used them for further statistical analysis. For comprehensiveness, we reported the ratio of mean absolute values in days and weeks across all patients for end points 3, 4, and 5 as well. However, the mean of the relative values offers a more detailed understanding of the differences between patients and produces more accurate results than the ratio of mean absolute values. It is important to note that these 2 measures are not mathematically equivalent.
Furthermore, bias-corrected and accelerated bootstrapped multiple linear regression [] was performed to investigate evaluation group differences in the SUS, patient wearable interaction frequency, and SHD or PROM completeness. Thus, the outcome (dependent) variables were the SUS score, patient wearable interaction frequency, and SHD or PROM completeness after activeDCM study protocol completion. As independent variables, age in years at activeDCM study protocol completion, sex, device experience (no: Exp–, yes: Exp+), and study arm membership (CG, IG–, IG+) were chosen before the analysis. The analysis involved 10,000 bootstrap resampling distributions applying a CI of 95%. CIs not including 0 were considered as significant (P<.05). The analysis was conducted using Python (version 3.10; Python Software Foundation) [] using the packages scipy.stats.kruskal (version 1.11.1) [], scipy.stats.chi2_contingency (version 1.11.1) [], scipy.stats.bootstrap (version 1.11.1) [], and statsmodels.regression.linear_model.OLS (version 0.14.0) [].
Due to the exploratory characteristics of this study, the analysis is intended for hypothesis generation only; thus, P values were not adjusted for multiplicity, and P<.05 was regarded as significant.
Ethical ConsiderationsThe activeDCM study, as well as its RPM system concept, its implementation, and its evaluation method, received ethics approval from Heidelberg University’s research ethics committee (reference numbers S-740/2018 and S-740/2021). The study is registered on ClinicalTrials.gov (NCT04359238). It adheres to the principles of the Declaration of Helsinki and good clinical practice guidelines. Participation in the activeDCM study was voluntary and patients received no compensation. An Apple Watch (Series 4 or newer) and an iPhone (SE generation 1 or newer) were provided during participation in the activeDCM study. After study completion these devices had to be returned to the study team. A written informed consent form was signed by each patient participating in the study. In addition, the RPM system’s data protection concept and its security mechanisms were audited by the data protection officer of Heidelberg University Hospital. No deficiencies were identified regarding data privacy, data protection, and information security.
On the basis of the identified requirements, a concept of a patient-centric RPM system with asynchronous feedback mechanisms was designed. It consisted of 4 interoperable components: patient devices (ie, a smartphone and a connected consumer wearable device, both having a corresponding RPM system app installed), a data server, a data viewer, and a notification service. A graphical representation of the concept and its implementation can be found in summarizing the key features and functionalities of the individual components. In this concept, the smartphone was used for patient onboarding and as a data relay with local storage for data transmission to the data server, which was located at the study center. The wearable was intended to be the patient’s primary input device. It was used to record SHD as well as collect PROMs to transmit these patient-generated data to the data server, relayed via the smartphone. In addition, the wearable was supposed to remind patients about necessary interactions and display personalized feedback messages, which were received from the notification service and forwarded by the smartphone. The data server was responsible for global storage of patient-generated data and feedback messages in a standard-compliant, interoperable manner. In addition, it made patient-generated data available to the data viewer. The data viewer, operated at the study center, allowed physicians to analyze patient-generated data and send personalized feedback messages to the data server. These feedback messages were stored on the data server and transmitted to the notification service. The notification service was responsible for identifying the smartphone that would receive the forwarded feedback messages. For the notification service to uniquely identify a smartphone, the latter must undergo an initial registration process during patient onboarding. At the end of this process, administrative data were generated and forwarded from the smartphone to the data server. The data server used the administrative data to identify the smartphone when forwarding feedback messages to the notification service.
Figure 2. Architecture of the remote patient monitoring system with asynchronous feedback mechanisms describing the 4 main components and their interaction. Black writing shows the initial concept, and colored writing shows concepts realized subsequently as part of the implementation. The services, frameworks, and protocols of the Apple ecosystem are shown in green; the standardized data model based on Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) are shown in orange; and the authentication mechanisms are shown in blue. PROM: patient-reported outcome measure; SHD: sensor-based health data. ImplementationOverviewThe described concept was subsequently implemented for the activeDCM study. For patient devices, an iPhone (SE generation 1 or newer) was used as the smartphone, and an Apple Watch (Series 4 or newer) was used as the wearable for which a study-specific app was implemented. Selected screenshots of the Apple Watch app can be found in . The onboarding of a patient to the RPM system was based on scanning a patient-specific QR code on the iPhone’s app. After that, SHD recording started immediately on the Apple Watch. Security mechanisms permitting data access and extraction from HealthKit exclusively if the device was unlocked forced the extraction of SHD on the Apple Watch app, which must be unlocked during interaction. Each type of SHD and PROM was implemented in its own module so that each module could be activated and deactivated independently of one another. To remind patients to answer the daily question of the PROM questionnaire and transfer patient-generated data to the study center, local on-device notifications were implemented directly as part of the Apple Watch app.
Figure 3. Screenshots of the Apple Watch app. (A) and (B) show the daily notification to remind patients about answering 1 question of the 7-part weekly patient-reported outcome measure (PROM) questionnaire. (C) and (D) show the user interface to enter 1 of 2 different answer types for the PROM questionnaire—(C) allows for entering a star rating between 1 and 4, and (D) allows for entering a Boolean answer using yes or no. (E) shows the user interface during the transmission of the patient-generated data to the study center. Transmission of patient-generated data from the Apple Watch to the iPhone was executed using background processes triggered by interactions with the Apple Watch on-device notifications. Transmission errors between Apple Watch and iPhone were displayed to the patient in the user interface, cached, and retried on the next transmission. Once the patient-generated data had been transmitted to the iPhone, they were forwarded again through background processes to the data server without any user interaction. This meant that no patient interaction with the iPhone was necessary. It could remain plugged into a power supply socket for the duration of the study and did not have to be carried around. Data transmissions used the standardized HL7 FHIR API provided by the data server. Each data transmission from the iPhone to the data server was recorded with an audit message, which could be viewed by a patient on the user interface of the iPhone app. If a transmission error occurred, the patient-generated data were temporarily stored in an encrypted local database, and the transmission was retried during the next scheduled data transfer to the data server.
The data server provided global storage of patient-generated data and feedback messages using standardized HL7 FHIR R4 resources as a data model. In addition, it executed algorithms periodically to check the date and time of the last data transmission of each patient. If >5 days had passed since a patient’s last data transmission, an automated feedback message was sent to the patient’s devices with a request to synchronize data.
The data viewer retrieved patient-generated data via the HL7 FHIR API and displayed them through a self-designed user interface. Data transmitted by a patient could be viewed at several levels of granularity (ie, data for a single day, data for 2 weeks, data for 1 month, or all recorded and transmitted data since study enrollment). Depending on the data type, they were presented using different visualization formats: (1) bar plots illustrated various granularities of active burned energy and step data, (2) scatter plots were used for daily heart rate views, and (3) box plots were used for 2 weekly and all-data heart rate views.
If all the data of a patient since study enrollment were displayed, the visualization was zoomable so that a closer look at areas of interest was possible. Selected screenshots of the data viewer user interface can be found in . A screencast showing the functionality of the data viewer (with a German user interface) can be found in .
Figure 4. Screenshots of the data viewer application for 1 patient; (A) shows the recorded and transmitted heart rate data of a single day as a scatter plot; (B) shows the recorded and transmitted heart rate data over 2 weeks as daily box plots; (C) shows the recorded and transmitted step counts for all days included in the study as a zoomable bar plot, where asterisks indicate days without any recordings or transmissions, for example, because the wearable was not worn. To receive remote push notifications from the study center, the patient’s iPhone registered itself with Apple Push Notification service (APNs) directly after onboarding. APNs provided a device-specific identifier, which was forwarded by the iPhone app to the data server of the study center as administrative data. On the basis of the device identifier, the data server could forward a feedback message received from the data viewer to the APNs server after the message was transformed from the standardized HL7 FHIR format to the APNs-required proprietary format. The device identifier then enabled the APNs server to forward the feedback message as a remote push notification to the patient’s devices. Each feedback message was recorded, in addition to an audit message on the iPhone, and could be viewed by a patient in the app’s user interface.
Data ModelThe data model was based on standardized HL7 FHIR R4 resources to establish syntactic interoperability. A patient was identified by a Patient resource containing the patient’s study pseudonym. The Device resource stored the device-specific identifier provided by APNs, which was needed to send and retrieve feedback messages via remote push notifications and linked to the Patient resource. Feedback messages were modeled using the Task resource, which contained information such as title, message, category, and recipient, which was a reference to the Patient resource. The SHD steps, active burned energy, and heart rate were modeled using the Observation resource. For steps and active burned energy, the recorded data were summarized in 1-hour intervals. For heart rate, 25 consecutive measurements were listed and transferred in 1 Observation resource to reduce network calls. The DocumentReference resource was used to store metadata related to ECG data, such as recording date, classification, and average heart rate. In addition, it referenced a Binary resource to transport the actual ECG recording (512 Hz; 30 seconds) as millivolt values in a CSV file. The PROM questionnaire was based on the Questionnaire resource, which contained the questions to be answered weekly, and the QuestionnaireResponse resource, which stored a patient’s completed questionnaire. The exercise diary was based on the Composition resource, which stored the date of a completed workout and was linked to several Task resources containing information about the executed strength and endurance exercises during the workout.
To establish semantic interoperability with other clinical information systems (eg, from primary care), the SHD were annotated using LOINC codes, and the PROM questionnaire was annotated using postcoordinated UMLS codes. For semantic annotation of the PROM exercise diary, we used a self-defined code system based on the exercise program. HL7 FHIR profiles, concrete resource examples, and validation information for the data model can be found in .
Security, Authentication, and AuthorizationFor general security, all messages exchanged between the components of the RPM system were encrypted using Transport Layer Security [] using a minimum version of 1.2. The Realm database used to cache patient-generated data on the iPhone was encrypted using the Advanced Encryption Standard-256+Secure Hash Algorithm 2 algorithm and could not be analyzed if the device was lost. The encryption key of the database was stored in the secure Keychain [] of the iPhone and could only be accessed through the iPhone app.
Authentication and authorization to the RPM system distinguished between the roles of patient and study center staff using distinct technical approaches for each. For the patient role, the QR code scanned during onboarding contained a signed JSON Web Token (JWT) [] valid for study enrollment, storing authentication information and the patient’s pseudonym in the iPhone’s secure Keychain. This JWT was used when transmitting patient-generated data, ensuring authentication and data provenance. The role of study center staff, authenticated using X.509 client certificates [], could retrieve patient-generated data and stored push notifications on the data server. Revoking compromised certificates or JWTs was managed via configuration options on the data server. The server’s authentication to APNs used a JWT as well that was signed and encrypted by the study center data server using a private key from Apple that was revocable on the Apple developer website if compromised.
EvaluationThe evaluation of the RPM system was carried out with patients who completed the activeDCM study protocol between October 2021 and February 2024 (N=110). A total of 13.6% (15/110) of the patients were excluded from the evaluation because of missing answers in the evaluation questionnaire on experience or SUS answers. The evaluated cohort consisted of 95 patients (n=28, 29% female) with a mean age of 50 (SD 12) years at the end of study participation. Of these 95 patients, 39 (41%) had previous experience using Apple devices (Exp+, n=30, 77% using iPhone only and n=9, 23% using iPhone and Apple Watch), and 56 (59%) had no experience (Exp–) at the time of enrollment in the study. A total of 26% (25/95) of the patients were randomized into the intervention group with an individualized exercise program and feedback messages (IG+), 36% (34/95) were randomized into the intervention group with an individualized exercise program but without feedback messages (IG–), and 38% (36/95) were randomized into the CG study arm. The mean enrollment time of these patients in the activeDCM study was 396 (SD 39) days, which corresponds to 56 (SD 5) weeks. The baseline characteristics of the evaluated patient cohort are summarized in .
Table 1. Baseline characteristics of patients by device experience and study arm membership in the activeDCM study (N=95).VariableTotal sampleExp–a (n=56)Exp+b (n=39)CGc (n=36)IG–d (n=34)IG+e (n=25)Sex, n (%)faExp–: without previous device experience.
bExp+: with previous device experience.
cCG: control group.
dIG–: intervention group without feedback messages.
eIG+: intervention group with feedback messages.
fDevice experience: Pearson χ21P>.99; study arm: Pearson χ22P=.65.
gDevice experience: Kruskal-Wallis test P=.58; study arm: Kruskal-Wallis test P=.29.
hDevice experience: Kruskal-Wallis test P=.95; study arm: Kruskal-Wallis test P=.53.
The results of the patients’ subjective perspective on the RPM system based on the evaluation questionnaire were divided into 2 end points. The results of the first end point, analyzing the usability of the wearable and smartphone app based on the SUS, are summarized using box plots in . The app achieved a mean SUS score of 78 (SD 17). A total of 25% (24/95) of the patients reported an SUS score of <68 (insufficient usability), of whom 75% (18/24) were aged >50 years and 75% (18/24) had no previous experience using Apple devices (Exp–). Patients with previous experience using Apple (Exp+) devices rated usability more highly, with a mean SUS score of 82 (SD 15), compared with patients without any experience (Exp–), who reported a mean SUS score of 75 (SD 18). There were no major differences among patients in the study arms. Patients in the intervention group with feedback messages (IG+) reported a mean SUS score of 78 (SD 15), patients in the intervention group without feedback messages (IG–) reported a mean score of 78 (SD 15), and patients in the CG reported a mean score of 77 (SD 20).
Figure 5. Results of the wearable and smartphone app usability analysis using the System Usability Scale (SUS) displayed as box plots. All data combined are shown in blue, experience using Apple devices is shown in green, and study arm membership is shown in orange. Triangles show mean values. CG: control group; Exp–: without previous device experience; Exp+: with previous device experience; IG–: intervention group without feedback messages; IG+: intervention group with feedback messages. As shown in , the bias-corrected and accelerated bootstrapped multiple linear regression analysis of the SUS scores resulted in a significant effect for those with previous experience (Exp+) with a 95% CI of 0.25-13.47 and an estimate of 6.75. This means that patients with Apple device experience were estimated to rate the usability of the wearable and smartphone app 6.75 points higher on the SUS than patients without Apple device experience. This is similar to the measured differences in SUS scores between those without and with previous experience (7-point difference). Age approached significance with a 95% CI of −0.46 to 0.14. The estimate of −0.19 showed that a 40-year age difference between 2 patients was estimated to result in a 7.60-point worse SUS score for the wearable and smartphone app from the older patient.
Table 2. Bias-corrected and accelerated bootstrapped multiple linear regression analysis of the System Usability Scale (SUS) scores, the wearable interaction frequency (percentage of days enrolled in the study), the sensor-based health data (SHD; percentage of days enrolled in the study), and patient-reported outcome measure (PROM) completeness (percentage of weeks enrolled in the study).VariableEstimate, mean (95% CI)SUS scoreaExp+: with previous device experience.
bCIs not including 0 were considered as significant (P<.05).
cIG+: intervention group with feedback messages.
dIG–: intervention group without feedback messages.
The results of the second evaluation questionnaire end point, regarding the 5 self-designed questions about the patients’ attitudes toward using the RPM system as well as their participation in the study, are shown in . A total of 87% (83/95) of the patients (strongly) agreed that the use of the app was easy to integrate into their daily routine. Similarly, 88% (84/95) and 93% (88/95) of the patients considered answering the PROM questionnaire and transmitting their SHD to the study center via Apple Watch as convenient, respectively. In total, 64% (61/95) of the patients would like to submit their health data to the study center and receive feedback from a physician (even after the activeDCM study), and the app with feedback from their physician was or would be useful for 71% (67/95) of the patients regarding their health and well-being.
Figure 6. Results of the 5 self-designed questions regarding the patients’ attitudes toward using the remote patient monitoring system as well as their participation in the activeDCM study. Responses to the statements were provided by patients using a 5-point ordinal Likert scale ranging from strongly disagree in orange to strongly agree in blue. In , the results of patients’ objective use of the wearable device are summarized using box plots, showing wearable interaction frequency and SHD as well as PROM completeness for end points 3, 4, and 5. On average, patients interacted with the wearable app on 61% (SD 26%) of the days that they were enrolled in the study, which corresponds to 239 (SD 99) of 396 (SD 39) days. On average, SHD were available for 78% (SD 23%) of the days that patients were enrolled in the study, which corresponds to 307 (SD 87) of 396 (SD 39) days. In terms of PROM questionnaires answered, data were available on average for 64% (SD 27%) of the weeks that the patients were enrolled in the study, which corresponds to 35 (SD 15) of 56 (SD 5) weeks. There were no major differences between those without and with previous experience (wearable interaction frequency: mean 62%, SD 27% of days [240, SD 103 of 398, SD 44 days] vs mean 60%, SD 23% of days [238, SD 91 of 394, SD 30 days], respectively; SHD completeness: mean 76%, SD 25% of days [299, SD 97 of 398, SD 44 days] vs mean 81%, SD 17% of days [319, SD 69 of 394, SD 30 days], respectively; PROM completeness: mean 65%, SD 28% of weeks [36, SD 15 of 56, SD 6 weeks] vs mean 63%, SD 24% of weeks [35, SD 14 of 56, SD 4 weeks], respectively). Only the dispersion of the data was slightly narrower for those with previous experience (Exp+). Regarding the 3 different study arms, the interaction with the wearable was more frequent and patient-generated data completeness was higher in both the IG– (wearable interaction frequency: mean 67%, SD 20% of days [266, SD 84 of 395, SD 28 days]; SHD completeness: mean 82%, SD 20% of days [322, SD 80 of 395, SD 28 days]; PROM completeness: mean 69%, SD 21% of weeks [39, SD 12 of 56, SD 4 weeks]) and IG+ (wearable interaction frequency: mean 62%, SD 20% of days [242, SD 78 of 389, SD 31 days]; SHD completeness: mean 85%, SD 16% of days [330, SD 63 of 389, SD 31 days]; PROM completeness: mean 67%, SD 23% of weeks [36, SD 12 of 55, SD 4 weeks]) than in the CG (wearable interaction frequency: mean 54%, SD 31% of days [212, SD 115 of 402, SD 50 days]; SHD completeness: mean 70%, SD 26% of days [277, SD 99 of 402, SD 50 days]; PROM completeness: mean 58%, SD 32% of weeks [32, SD 17 of 57, SD 7 weeks]). In both the IG+ and IG–, the dispersion of the data was smaller than in the CG.
Figure 7. Results of patients’ wearable interaction frequency as well as completeness of recorded and transmitted patient-generated data classified into sensor-based health data (SHD) and electronic patient-reported outcome measures (PROMs) of the wearable and smartphone app as box plots. All data combined are shown in blue, experience using Apple devices is shown in green, and study arm membership is shown in orange. Triangles show mean values. CG: control group; Exp–: without previous device experience; Exp+: with previous device experience; IG–: intervention group without feedback messages; IG+: intervention group with feedback messages. The data volume recorded and transferred per patient to the data server varied based on health status, physical activity levels, and workout duration, which influenced both recorded data point density and the number of ECG recordings. On average, the data volume amounted to approximately 300 MB per patient and year in the HL7 FHIR database on the data server.
The bias-corrected and accelerated bootstrapped multiple linear regression analysis () resulted in a significant influence of IG– membership on the wearable interaction frequency and SHD completeness end points and approached significance for the PROM completeness end point (wearable interaction frequency estimate: 13.53%, 95% CI 1.02%-25.4%; SHD completeness estimate: 11.73%, 95% CI 1.17%-21.86%; PROM completeness estimate: 12.22%, 95% CI –0.37% to 24.29%). This means that, on average, a patient in the IG– was expected to interact with the wearable app on 13.35% more days enrolled in study than a patient in the CG and that both SHD and PROM data were expected to be available on 11.73% more days and 12.22% more weeks that a patient was enrolled in the study, respectively.
In this paper, we presented a concept, implementation, and evaluation of a reusable RPM system following a patient-centric approach for RPM without direct physician-patient contact using asynchronous feedback mechanisms. The system was based on patient-generated data such as SHD and PROMs. It leveraged a consumer wearable device (smartwatch) instead of a smartphone as the primary input device. The implementation of the concept and its subsequent use as part of the activeDCM randomized controlled clinical trial demonstrated that the identified challenges and requirements of a sophisticated precision digital health trial could be addressed. The implementation relied on wearable devices and smartphones from Apple Inc and their notification service, but the concept should be versatile enough to be used with devices based on other operating systems, such as the Android-based Wear OS for the Samsung Galaxy Watch or the Google Pixel Watch.
Decisions during RPM system conceptualization and implementation aimed to minimize barriers to use, enhancing usability and ensuring high patient acceptance as well as compliance. The study team established a device preparation and distribution scheme providing patients with ready-to-use devices, thereby reducing the configuration efforts to scanning an onboarding QR code. Patient education sessions focused not only on the medical aspects of the study but also on digital literacy and provided written and video-based material about the wearable and smartphone app, requiring additional effort from patient educational sessions. Opting for a wearable as the primary input device likely played a pivotal role in seamlessly integrating the RPM system into the patients’ daily routines. Its proximity to the patient and its intuitive interaction, aligned with the chosen device, operating system, and study-specific app, contributed to a successful integration and reduced the interaction time to a few seconds per day. To enhance the wearable and smartphone app usability, we implemented only the essential functionalities in a straightforward, simplistic manner, trying to reduce the interactions for these functionalities to a minimum. This was significantly shaped by the official human interface guidelines provided by Apple [,]. Storing authentication information during onboarding further streamlined data transmissions, eliminating the need for patients to remember usernames and passwords.
The Apple Watch sensors capture heart rate measurements in an interval of seconds during an activity session [], and active burned energy and step data can be extracted in hourly intervals. Given this vast amount of data points, the physician-centered data viewer prioritized simplicity, presenting summarized information. In total, 3 visualization granularity levels allowed physicians to analyze patient-generated data, identifying short-, medium-, and long-term trends, and compare data from multiple patients effortlessly. Direct remote push notifications from the data viewer interface streamlined physician support, eliminating the need to switch between various communication channels, as observed in other wearable-based studies [,].
The HL7 FHIR standard enhanced medical data exchange by addressing health care challenges beyond the capabilities of previous standards, such as HL7 version 2, HL7 version 3, and Clinical Document Architecture []. Therefore, HL7 FHIR’s standardized API and data models used in combination with the LOINC and UMLS medical terminologies ensured syntactic and semantic interoperability with other clinical information systems. However, complete integration with other clinical information systems requires these systems to provide standardized interfaces as well. Without these interfaces, integration becomes more complex, necessitating adaptations and mappings. In Germany, legislative efforts are promoting the adoption of HL7 FHIR interfaces for clinical information systems [].
The wearable and smartphone app, data server, and data viewer implementation were not bound to a specific medical domain and could be used independently beyond the activeDCM study as long as the counterpart supported the HL7 FHIR standard as well. The components of the wearable and smartphone app and the data viewer were built iteratively in a modular system and, thus, can be adapted for further studies and other diseases such as diabetes or chronic obstructive pulmonary disease without major effort. If required, new modules could be implemented, integrating additional sensors and data types. Similarly, not required data types could be removed easily.
By equipping patients with dedicated devices, it was possible to ensure that data transmissions only took place in a pseudonymized form. During the educational session, patients were briefed on the RPM system’s privacy and security mechanisms, emphasizing the storage of only the pseudonym on devices after handover. This ensured that no data were stored in a cloud solution provided by the manufacturer of the devices. As such, the smartphone and wearable were setup using Apple Configurator 2, and the app was deployed using the over-the-air method without the need to sign in using an Apple ID. Furthermore, by separating patient identification from device identification, feedback messages could be sent via the manufacturer’s notification service without having to know the patient’s identity or pseudonym. The connection of the pseudonym to the device could only be established on the data server.
The SUS evaluation, resulting in a mean score of 78 (SD 17), indicated that the wearable and smartphone app was considered user-friendly by patients []. The significant difference between patients with and without experience using Apple devices (estimate: 6.75, 95% CI 0.25-13.47) suggests that patients are generally more comfortable using devices they are familiar with. However, to allow use of wearables from different manufacturers in the RPM system, achieving comparable sensor accuracies for the same SHD recordings would be essential, but the literature shows that there are measurable differences [,], posing challenges for physicians in comparing patient data and providing feedback. Despite the additional effort to explain the devices and study-specific app, patient age had an influence on the SUS score approaching significance (estimate: −0.19, 95% CI –0.46 to 0.14). Insufficient usability (SUS score of <68; 24/95, 25% of the patients) was mainly reported by patients aged >50 years (18/24, 75%) and with no previous Apple device experience (18/24, 75%). This suggests that the challenges faced by these individuals may not have been due to problems with the usability of the wearable and smartphone app but rather with the general use of the devices. These findings are consistent with results reported by Sonderegger
留言 (0)