Design of a Consumer Mobile Health App for Heart Failure: Findings From the Nurse-Led Co-Design of Care4myHeart
Why this work is in the frame
A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.
Bibliographic record
Abstract
BACKGROUND: Consumer health care technology shows potential to improve outcomes for community-dwelling persons with chronic conditions, yet health app quality varies considerably. In partnership with patients and family caregivers, hospital clinicians developed Care4myHeart, a mobile health (mHealth) app for heart failure (HF) self-management. OBJECTIVE: The aim of this paper was to report the outcomes of the nurse-led design process in the form of the features and functions of the developed app, Care4myHeart. METHODS: Seven patients, four family caregivers, and seven multidisciplinary hospital clinicians collaborated in a design thinking process of innovation. The co-design process, involving interviews, design workshops, and prototype feedback sessions, incorporated the lived experience of stakeholders and evidence-based literature in a design that would be relevant and developed with rigor. RESULTS: The home screen displays the priority HF self-management components with a reminder summary, general information on the condition, and a settings tab. The health management section allows patients to list health care team member's contact details, schedule medical appointments, and store documents. The My Plan section contains nine important self-management components with a combination of information and advice pages, graphical representation of patient data, feedback, and more. The greatest strength of the co-design process to achieve the design outcomes was the involvement of local patients, family caregivers, and clinicians. Moreover, incorporating the literature, guidelines, and current practices into the design strengthened the relevance of the app to the health care context. However, the strength of context specificity is also a limitation to portability, and the final design is limited to the stakeholders involved in its development. CONCLUSIONS: We recommend health app development teams strategically incorporate relevant stakeholders and literature to design mHealth solutions that are rigorously designed from a solid evidence base and are relevant to those who will use or recommend their use.
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.
Full frame distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.001 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.001 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.001 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
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 it