MétaCan
Menu
← Retour à la cohorte
Enregistrement W4415666166 · doi:10.2196/65504

Obtaining Patient-Reported Outcome Data via a Home Patient Monitoring App: Development, Implementation, and Validation of Novel Interface Terminology

2025· article· en· W4415666166 sur OpenAlexvenueno aff
Lucia Sacchi, Giordano Lanzola, Silvana Quaglini, Nicole Veggiotti, Silvia Panzarasa, Valentina Tibollo, Matteo Terzaghi, Itske Fraterman, Savannah Glaser, Manuel Ottaviano, Vadzim Khadakou, Vitali Hisko, Mor Peleg, Sofie Wilgenhof, Henk Mallo, Alexandra Kogan, David Glasspool, Stephanie Medlock, Laura Del Campo, Matteo Gabetta, Mimma Rizzo, Laura D. Locati, Paola Gabanelli, Sara Demurtas, Andrea Premoli, Szymon Wilk

Notice bibliographique

RevueJMIR mhealth and uhealth · 2025
Typearticle
Langueen
DomaineHealth Professions
ThématiqueElectronic Health Records Systems
Établissements canadiensnon disponible
Organismes subventionnairesHorizon 2020 Framework Programme
Mots-clésTerminologyExploitInterface (matter)Clinical decision support systemDecision support systemUsabilityRemote patient monitoringOutcome (game theory)

Résumé

récupéré en direct d'OpenAlex

BACKGROUND: Adverse events (AEs) related to cancer treatment represent a valuable source of information that can be used to adjust therapy for individual patients. The NIH developed the Common Terminology Criteria for Adverse Events (CTCAE), a comprehensive standardized terminology for healthcare providers to consistently report AEs during patient visits. mHealth technologies, in principle, also allow AEs to be self-reported by patients in-between visits; however, the terminology poses challenges for them, both in selecting the correct symptom to report and in rating its severity. NIH developed the Patient-Reported Outcomes (PRO)-CTACE as the patient-oriented companion of the CTCAE. However, it shows some weaknesses in completeness and precision when used for continuous home patient monitoring and for decision support. OBJECTIVE: The aim of this work is to propose a new terminology for reporting AEs, which is easy for patients to use while also being clinically meaningful for healthcare providers, and easily exploitable by decision support systems. Moreover, we aim to demonstrate its implementation and validation within the CAPABLE EU project. METHODS: The development of the new terminology starts from the CTCAE, which includes a comprehensive list of signs and symptoms along with guidance for accurately grading their severity. Through a multi-step, participatory approach involving both patients and healthcare providers, we reduced and adapted the AE list for patient-oriented applications. During the CAPABLE project, the proposed terminology was integrated in a mobile app and evaluated within a clinical pilot study involving 86 patients who were monitored through the app for at least 6 months, and a control cohort of 133 patients monitored using standard care practices. RESULTS: The final terminology includes 124 AEs, 49 expressed as "present/absent", and 77 associated with four description levels. A mapping between the description levels and the original CTCAE grades enables running the decision support system embedded in the CAPABLE app. The pilot study demonstrated that the majority of the patients used the symptoms reporting functionality, sharing also 24 unique AEs that are not present in the PRO-CTCAE. Symptoms reported using the proposed terminology allowed the enactment of the clinical practice guidelines included in the CAPABLE decision support tool, triggering 11 distinct recommendations. CONCLUSIONS: The results obtained from the clinical study support our claim regarding the need for a novel terminology for the self-reporting of AEs, characterized by ease of use, completeness, and clinical meaningfulness. Finally, by mapping our terminology to the CTCAE, we demonstrated that it is possible to exploit self-reported data to trigger decision support rules consistent with clinical practice guidelines.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction machine sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.

score de la tête « metaresearch » (Codex)0,014
score de la tête « metaresearch » (Gemma)0,042
Version: metacan-v3-hybrid-931329e0061cStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Expérimental (laboratoire) · Signal consensuel: aucune
GenreSignal candidat: Empirique · Signal consensuel: Empirique
Score de désaccord entre enseignants0,014
Score d'incertitude au seuil0,075

Scores du classifieur distillé par catégorie (deux têtes)

CatégorieCodexGemma
Métarecherche0,0140,042
Méta-épidémiologie (sens strict)0,0010,000
Méta-épidémiologie (sens large)0,0010,001
Bibliométrie0,0010,000
Études des sciences et des technologies0,0000,001
Communication savante0,0020,002
Science ouverte0,0020,002
Intégrité de la recherche0,0010,001
Charge utile insuffisante (le modèle a refusé de juger)0,0020,001

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,221
Tête enseignante GPT0,527
Écart entre enseignants0,305 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.

Les modèles n’ont appliqué aucune catégorie : rien dans la taxonomie ne correspondait à ce travail.
Devis d'étudeExpérimental (laboratoire)
Domainenon disponible
GenreEmpirique

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations0
Publié2025
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueJMIR mhealth and uhealth→Même sujetElectronic Health Records Systems→Travaux en français237 207→