Mobile App Support for Cardiopulmonary Resuscitation: Development and Usability Study
Bibliographic record
Abstract
BACKGROUND: The user requirements for in-hospital cardiopulmonary resuscitation (CPR) support apps are understudied. To study usability, functionality, and design based on user requirements, we applied a mixed methods research design using interviews, observations, and a Kano questionnaire to survey perspectives of both physicians and nurses. OBJECTIVE: This study aims to identify what an in-hospital CPR support app should include to meet the requirements and expectations of health care professionals by evaluating the CprPrototype app. METHODS: We used a mixed methods research design. The qualitative methods consisted of semistructured interviews and observations from an advanced life support (ALS) course; both provided input to the subsequent questionnaire development. The quantitative method is a questionnaire based on the Kano model classifying user requirements as must-be, one-dimensional (attributes causing satisfaction when present and dissatisfaction when absent), attractive, indifferent, and reverse (attributes causing dissatisfaction when present and satisfaction when absent). The questionnaire was supplemented with comment fields. All respondents were physicians and nurses providing ALS at hospitals in the Central Denmark Region. RESULTS: A total of 83 physicians and nurses responded to the questionnaire, 15 physicians and nurses were observed during ALS training, and 5 physicians were interviewed. On the basis of the Kano questionnaire, 53% (9/17) of requirements were classified as indifferent, 29% (5/17) as attractive, and 18% (3/17) as one-dimensional. The comments revealed 7 different categories of user requirements with noticeable differences between those of physicians and nurses: technological challenges, keep track of time, documentation and history, disturbing element, improvement areas: functions, improvement areas: design, and better guidance. CONCLUSIONS: The study provides recommendations to developers on the user requirements that need to be addressed when developing CPR support apps. Three features (one-dimensional attributes) must be incorporated in an in-hospital CPR support app: reminder of rhythm check, reminder of resuscitation drugs, and differentiate between adults and children. In addition, 5 features (attractive attributes) would result in higher user satisfaction: all functions on one side, access to the patient journal in the app, automatic time recording when cardiac arrest is called, sound to guide the chest compression rate (metronome), and send CPR history to the DANARREST(Danish in-hospital cardiac arrest registry) database.
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 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.001 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.000 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| 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 itClassification
machine, unvalidatedMachine predicted; a candidate call from one teacher head, 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".