MétaCan
Menu
Back to cohort
Record W4321360147 · doi:10.2196/43781

Implementation and User Evaluation of an eHealth Technology Platform Supporting Patients With Cardiovascular Disease in Managing Their Health After a Cardiac Event: Mixed Methods Study

2023· article· en· W4321360147 on OpenAlex

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.

venuePublished in a venue whose home country is Canada.
no affNo Canadian affiliation: this work is invisible to an affiliation-only frame.
No Canadian affiliation. An affiliation-only frame, the usual design, would never have seen this work. It is one of the works that make the case for inverting the frame.

Bibliographic record

VenueJMIR Cardio · 2023
Typearticle
Languageen
FieldMedicine
TopicCardiac Health and Mental Health
Canadian institutionsnot available
FundersMedical DeltaNederlandse Organisatie voor Wetenschappelijk OnderzoekZonMw
KeywordseHealthUsabilityCoachingRehabilitationIncentiveMedicineSet (abstract data type)Disease managementHealth management systemComputer scienceKnowledge managementMedical educationHealth carePsychologyPhysical therapyHuman–computer interactionAlternative medicine

Abstract

fetched live from OpenAlex

BACKGROUND: eHealth technology can help patients with cardiovascular disease adopt and maintain a healthy lifestyle by supporting self-management and offering guidance, coaching, and tailored information. However, to support patients over time, eHealth needs to blend in with their needs, treatment, and daily lives. Just as needs can differ between patients, needs can change within patients over time. To better adapt technology features to patients' needs, it is necessary to account for these changes in needs and contexts of use. OBJECTIVE: This study aimed to identify and monitor patients' needs for support from a web-based health management platform and how these needs change over time. It aimed to answer the following research questions: "How do novice and more advanced users experience an online health management platform?" "What user expectations support or hinder the adoption of an online health management platform, from a user perspective?" and "How does actual usage relate to user experiences and adoption?" METHODS: A mixed methods design was adopted. The first method involved 2 rounds of usability testing, followed by interviews, with 10 patients at 0 months (round 1) and 12 patients at 6 months (round 2). In the second method, log data were collected to describe the actual platform use. RESULTS: After starting cardiac rehabilitation, the platform was used frequently. The patients mentioned that they need to have an incentive, set goals, self-monitor their health data, and feel empowered by the platform. However, soon after the rehabilitation program stopped, use of the platform declined or patients even quit because of the lack of continued tailored or personalized advice. The reward system motivated them to log data, but most participants indicated that being healthy should be the main focus, not receiving gifts. A web-based platform is flexible, accessible, and does not have any obligations; however, it should be implemented as an addition to regular care. CONCLUSIONS: Although use of the platform declined in the longer term, patients quitting the technology did not directly indicate that the technology was not functioning well or that patients no longer focused on achieving their values. The key to success should not be user adherence to a platform but adherence to healthy lifestyle habits. Therefore, the implementation of eHealth should include the transition to a stage where patients might no longer need support from a technology platform to be independently and sustainably adherent to their healthy lifestyle habits. This emphasizes the importance of conducting multi-iterative evaluations to continuously monitor whether and how patients' needs and contexts of use change over time. Future research should focus on how this transition can be identified and monitored and how these insights can inform the design and implementation of the technology.

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 imitation

Not 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.

metaresearch head score (Codex)0.009
metaresearch head score (Gemma)0.000
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesnone
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Observational · Consensus signal: Observational
GenreCandidate signal: Empirical · Consensus signal: Empirical
Teacher disagreement score0.388
Threshold uncertainty score0.807

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0090.000
Meta-epidemiology (narrow)0.0000.000
Meta-epidemiology (broad)0.0010.000
Bibliometrics0.0010.001
Science and technology studies0.0000.000
Scholarly communication0.0000.000
Open science0.0000.000
Research integrity0.0000.000
Insufficient payload (model declined to judge)0.0000.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.

Opus teacher head0.031
GPT teacher head0.438
Teacher spread0.407 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it