This study seeks to elicit user requirements for an app for in-hospital CPR support by evaluating the CprPrototype app, developed by physicians from Aarhus University Hospital, researchers from Aarhus University, and developers from Aarhus Business Academy. The app is based on the European Resuscitation Council guideline for ALS (adapted from Soar et al [10]; Figure 1).

When performing CPR, the user of the CprPrototype app can choose the algorithm for shockable rhythms or nonshockable rhythms (screenshot 1 in Figure 2). The app then starts a 2-min cycle with a countdown for the next rhythm check. Depending on the rhythm, the app instructs the user when to prepare specific resuscitation drugs, including the dose (screenshot 2 in Figure 2). An available feature is the ability to see a list of possible reversible causes of cardiac arrest (screenshot 3 in Figure 2). The app continuously keeps track of time, and every action performed by the user in the app is tracked and stored in the app’s log (History) feature (screenshot 4 in Figure 2).

As the app serves to support in-hospital CPR, it is important from a development perspective to understand the needs of nurses and physicians during resuscitation. Therefore, we applied a mixed methods research design to study user requirements.

First, we observed an ALS course to understand the unspoken needs of nurses and physicians in providing ALS. The ALS course included simulations of cardiac arrests, and the participants practiced each step of ALS. During the simulations, the nurses and physicians were divided into teams. We followed each team through participant observation in an effort to uncover the needs that were not verbally articulated by the course participants. We took extensive field notes that were subsequently coded and analyzed to identify common themes [16]. The themes (resuscitation challenges, smooth collaboration, information overload, efficient communication, and need for structure and overview) provided insight into the work processes and communication of resuscitation team members, their unspoken needs for support and guidance, and helped prepare the subsequent interviews.

Second, we conducted interviews with physicians who served as resuscitation team leaders. The interviews were semistructured, based on insights from our observations. An interview guide was used to ensure the structure and comparable answers. The interviews were transcribed and analyzed through systematic text condensation to uncover their meaning [17]. The analysis facilitated our understanding of how they practice ALS, medical terminology and technology used during resuscitation, and use case scenarios for the app.

Third, we used the interview results together with the observations to develop questions for the Kano-type questionnaire. The questionnaire was sent to the respondents with an attached video of how the app functions. Furthermore, the questionnaire data were collected and managed using the REDCap (REDCap consortium; research electronic data capture) software platform [18,19].

The study complies with the ethical principles for medical research involving human subjects. According to the Danish National Committee on Biomedical Research Ethics, the study does not require approval from an ethical review committee. The study took place from February to May 2019.

To elicit user requirements and improve user satisfaction in developing health care products and services, the Kano model has previously been used [13,20,21]. The model provides insight into user requirements and whether different features (quality attributes) of a service or product contribute to greater or lower customer satisfaction [21]. Thus, it guides in prioritizing between user requirements and identifying opportunities when designing or improving products and services based on customer needs [13].

Kano et al [22] proposed a 2-dimensional quality model to classify and categorize an element of a service or product. The model is based on the motivator-hygiene theory by Herzberg et al [23], positing that the factors causing satisfaction are different from those causing dissatisfaction. The model helps visualize the relationship between the product’s functionality and customer satisfaction (Figure 3—adapted from Witell and Löfgren [24]). The model serves to explain the role of various quality attributes in determining customer satisfaction as a basis for developing a product or service.

As illustrated, the model classifies the quality attributes into 5 categories: must-be, one-dimensional, attractive, indifferent, and reverse quality (listed based on importance). The must-be attributes are expected by the customer and do not result in increased customer satisfaction, but if these attributes are not present, customers are dissatisfied. The one-dimensional attributes cause satisfaction when present and cause dissatisfaction when absent. The attractive attributes are unexpected and delight the customer, which increases customer satisfaction, but they do not cause dissatisfaction when absent, because they are not expected. Therefore, these attributes often reflect unspoken needs. Finally, the indifferent attributes neither cause satisfaction nor dissatisfaction, and reverse attributes result in dissatisfaction when present and cause satisfaction when absent [24].

We used the Kano 5-level questionnaire to classify the features into 5 categories. The features are first evaluated according to a functional question (how respondents feel if a particular feature is present) and subsequently a dysfunctional question (how respondents feel if the feature is not present). The respondents had to choose between 5 possible responses (Textbox 1).

When the survey was completed, all answers were evaluated and placed in an evaluation table [21] (Table 1) and categorized into M (must-be), O (one-dimensional), A (attractive), I (indifferent), R (reverse), and Q (questionable) quality attributes. If an answer is categorized as questionable, it indicates a conflicting answer because the respondent has answered like to both the functional and dysfunctional question, making the response invalid [21]. All questions from the survey are listed in the evaluation table, where an attribute is assigned according to the most frequently used response category (Tables 1, 2, and 3).

The coefficient of customer satisfaction shows how strongly a feature influences satisfaction or dissatisfaction, which helps developers prioritize user requirements. The coefficient consists of positive (satisfaction) and negative (dissatisfaction) values, and the coefficient shows the satisfaction or dissatisfaction with the presence or absence of a feature. The positive value in the formula below shows the satisfaction when a requirement is met, and the negative value shows dissatisfaction when a requirement is not met. The coefficient is calculated as follows (adapted from the study by Berger et al [25]):

A, O, M, and I indicate the frequency of each category shown in the evaluation table. The negative sign in front of the dissatisfaction formula emphasizes the negative influence on customer satisfaction when the requirement is not met or if the feature is not part of the product [20]. Features of the evaluated product or service that yield high positive and negative values should be prioritized and addressed [21].

Before distributing the Kano questionnaire to respondents, a pilot test was performed with 5 physicians to evaluate their understanding of the questions. Their feedback helped us modify questions to facilitate understanding and ensure reliability and validity by adapting the wording to the terminology used by both nurses and doctors. The final questionnaire design consists of 3 main categories of questions and 5 subcategories (Figure 4).

The Kano model is used to elicit user requirements and provides insight into the needs and priorities of users, but it does not provide a more detailed explanation of those requirements. To this end, supplementary methods are needed. Therefore, we added additional questions with comment fields that allow respondents to elaborate on answers. As the study participants had not used the CprPrototype app beforehand, we created a video in Danish that explains the app and its purpose [26].

An analysis of the comments was performed to identify themes and interpret the answers to the functional and dysfunctional questions.

Physicians and nurses are considered the users in this study, as they respond to in-hospital resuscitations [27].

We observed 15 physicians and nurses at an ALS course at a university hospital. In the semistructured interviews, a total of 5 physicians from different hospitals in the Central Denmark Region were interviewed. All 5 interviewees acted as team leaders during in-hospital resuscitation and provided feedback on the CprPrototype app. Finally, the questionnaire was sent to a total of 469 physicians and nurses from different hospitals in the Central Denmark Region who had previously participated in an ALS course. Questionnaires were distributed by course coordinators via email to safeguard their anonymity and ensure compliance with the General Data Protection Regulation (GDPR) [28]. The exact number of nurses compared with the number of physicians is unknown. Respondents were given the option of participating in a draw to win movie tickets.

The 3 attributes classified as one-dimensional are app features that the user explicitly wants. The 3 features are reminder of rhythm check, reminder of resuscitation drugs, and differentiate between adults and children. App developers should focus on these but may also benefit from implementing the attractive features. According to Witell and Löfgren [24], attractive attributes are essential when striving for quality in products and services because of the likelihood of generating user satisfaction. This is supported by the coefficient values in Table 6, which display a user satisfaction of above 0.70 for all attractive features. Besides, implementing attractive features is a low-risk strategy, as low performance with regard to such features will not increase user dissatisfaction because they are unexpected. For example, one feature that could be added to a CPR support app to increase user satisfaction is automatic time recording when cardiac arrest is called (0.71). Thus, app developers may use the coefficients (Table 6) to prioritize the features to be implemented when developing an in-hospital CPR support app.

An analysis of the questionnaire comments by the respondents revealed 7 central themes. Most of the comments supported the results of the Kano questionnaire. When asked if they would use the app during resuscitation, the nurses saw it as an attractive feature, whereas the responses of the physicians were classified as indifferent. More than one theme supported these categorizations. The themes technological challenges and disturbing element were commented on frequently among physicians compared with nurses, which helped explain why the physicians were indifferent to using an app during resuscitation. In contrast, nurses frequently mentioned the value of receiving better guidance provided by the app.

Furthermore, physicians frequently made suggestions regarding functionality, whereas nurses made design suggestions. A possible explanation for the differences in user requirements between physicians and nurses is the difference in experience with ALS and the different roles they have during CPR, with physicians most frequently being team leaders. Some physicians have more experience with the ALS algorithm, which could account for their suggestions regarding functionality, whereas it is difficult for nurses to comment on functionality as they are less experienced with the algorithm. The study suggests that it might be beneficial in the future to ensure configurability of the CPR support app, depending on who the user is, given the different requirements of physicians and nurses. However, further research is necessary to investigate the differences between physicians and nurses and how to accommodate their different needs.

Several studies that have applied the Kano model in a health care context have recently been published [13,21,29-34]. None of these studies use the Kano model to elicit user requirements in the development of an in-hospital CPR support app. Using the Kano model, we are able to support the claims of both Sulisworo and Maniquiz [32] and Gustavsson et al [13] that the Kano model is a practical tool to elicit different user requirements in a health care context and help prioritize between them. However, we recommend combining the Kano model with qualitative methods. We used observations and interviews to develop the Kano questionnaire, and we supplemented the Kano questionnaire with more open questions and comment fields, encouraging respondents to elaborate on their answers. This is a contribution to the existing Kano model methodology that allowed us to gain an in-depth understanding of user requirements and their priorities based on different roles (ie, physicians and nurses). The study by Gustavsson et al [13] shows the importance of incorporating the perspectives of individuals in multiple roles, which should be taken into consideration when using the Kano model. In doing so, practitioners and researchers can capture a wide range of different user needs. Our study corroborates the findings of Gustavsson et al [13] in the sense that our results show different user requirements based on the different roles of nurses and physicians.

Kalz et al [6] reported about an evaluation study of usability and quality criteria in developing an app for basic life support. In comparison, our study elicits user requirements for an ALS support app. Not only does our study offer recommendations for app developers to create value through implementation of specific attractive and one-dimensional features, but it also shows the importance of eliciting user requirements. Our results compare with those of Liao et al [34], who focus on exercise apps. Their study also recommends that app developers focus on value creation and invoke positive emotions through attractive features. Although there are similarities between the studies, our study extends the findings of Liao et al [34] by recommending that developers also focus on one-dimensional features and not only attractive features. They focus on attractive features because it enhances the strategic advantage in a competitive market with thousands of other apps similar to the one they are developing.

One study suggests that CPR support apps help improve the performance of ALS [12], although the literature on the subject is scarce. Low et al [12] found that test groups using an app during a simulation test improved the quality of ALS compared with the control group not using the app. Our study is the first to focus on app support for in-hospital CPR. Although our study elicits user requirements for such an app, we cannot provide additional support to the existing evidence that CPR support apps help improve CPR performance [12]. However, our study documents the user requirements for apps that are intended to precisely accomplish that goal.

A limitation of this study is the low response rate. In total, 469 potential respondents were contacted of which 83 responded, which translates into a response rate of 18%. Compliance with the European GDPR regulation necessitated that the questionnaires were distributed by health care coordinators who were in possession of the names and email addresses of the respondents. However, indirect contact with respondents limited our ability to encourage participation through personal contact and reminders. Furthermore, the study only included physicians and nurses from the Central Denmark Region. However, the Danish health care system is homogeneous. Therefore, the results are, in all probability, comparable across Danish regions.

Furthermore, this study shows challenges in eliciting user requirements for a CPR support app, as most of the features are classified as indifferent. One reason for the classification can be attributed to the respondents not having used the CprPrototype app in real life but only having seen it presented in a video. Consequently, they may have difficulty articulating their requirements. In the comment fields, most respondents mentioned that they would like to try the app. If the respondents try the app in a simulation, they may have more specific comments regarding the features they need. Thus, a limitation is that this study does not include a simulated or a clinical resuscitation attempt. Future research should address this limitation. Thus, clinical investigations need to be done once the user requirements have been incorporated.

When developing a product or service such as an app for clinical use, focusing on user requirements is essential. Therefore, we address a knowledge gap by using the Kano model to elicit the user requirements for an in-hospital CPR support app. In total, 3 requirements classified as one-dimensional should be prioritized and incorporated in the app: reminder of rhythm check, reminder of resuscitation drugs, and differentiate between adults and children. This study also revealed 5 attractive requirements that should be prioritized in developing CPR apps to increase 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 database.

Although this study shows an increasing use of mobile apps during CPR and highlights the importance of eliciting user requirements, our study is uniquely able to provide recommendations to developers on the specific user requirements that should be addressed when developing CPR support apps.

Looking toward the future, it will be important to ensure that the CprPrototype app complies with the European Union Medical Device Regulation of 2017 [35] and relevant national legislation before it can be used in clinical medical practice without fear of personal liability [36]. The next step is to integrate the app with widely used defibrillators into a coherent CPR decision support system for monitoring physiological processes and guiding CPR based on dynamic algorithms. This integration will pave the way for systems interoperability, so the information can be used in, for example, digital hospital command centers [37].