Design and Usability of a Heart Failure mHealth System: A Pilot Study
Bibliographic record
Abstract
BACKGROUND: Despite the advances in mobile health (mHealth) systems, little is known about patients' and providers' experiences using a new mHealth system design. OBJECTIVE: This study aimed to understand challenges and provide design considerations for a personalized mHealth system that could effectively support heart failure (HF) patients after they transition into the home environment. METHODS: Following exploratory interviews with nurses and preventive care physicians, an mHealth system was developed. Patients were asked to measure their weight, blood pressure, and blood glucose (if they had diabetes). They were also instructed to enter symptoms, view notifications, and read messages on a mobile app that we developed. A Bluetooth-enabled weight scale, blood pressure monitor, glucometer, and mobile phone was provided after an introductory orientation and training session. HF nurses used a dashboard to view daily measurements for each patient and received text and email alerts when risk was indicated. Observations of usage, cases of deterioration, readmissions, and metrics related to system usability and quality of life outcomes were used to determine overall effectiveness of the system, whereas focus group sessions with patients were conducted to elicit participants' feedback on the system's design. RESULTS: A total of 8 patients with HF participated over a 6-month period. Overall, the mean users' satisfaction with the system ranked 73%, which was above average. Quality of life improvement was 3.6. Patients and nurses used the system on a regular basis and were able to successfully identify and manage 8 health deteriorations, of which 5 were completely managed remotely. Focus groups revealed that, on one hand, the system was beneficial and helped patients with: recording and tracking readings; receiving encouragement and reassurance from nurses; spotting and solving problems; learning from past experiences; and communication. On the other hand, findings also highlighted design issues and recommendations for future systems such as the need to communicate via other media, personalize symptom questions and messages, integrate other health tracking technologies, and provide additional methods to analyze and visualize their data. CONCLUSIONS: Understanding users' experiences provides important design considerations that could complement existing design recommendations from the literature, and, when combined with physician and nurse requirements, have the potential to yield a feasible telehealth system that is effective in supporting HF self-care. Future studies will include these guidelines and use a larger sample size to validate the outcomes.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.011 | 0.017 |
| Meta-epidemiology (narrow) | 0.001 | 0.000 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.001 | 0.000 |
| Science and technology studies | 0.001 | 0.001 |
| Scholarly communication | 0.001 | 0.001 |
| Open science | 0.001 | 0.001 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.002 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".