Kind mobile notifications for healthcare professionals

Abstract

The inclusion of the Internet of Things in healthcare is producing numerous automatic notifications for health professionals. These notifications must be delivered in the right moment and in the right way to be appropriately attended, and at the same time, ensuring no important task is interrupted. In this work, we have applied a human-centred design method to deal with this issue. By collaborating with health professionals in Belgium, we have designed and validated DELICATE, a conceptual framework that categorizes the different attention needs for each notification, and links them with the delivery mechanisms that are more appropriate for each particular context. As an aid for designers, we also define methodological guidelines to clearly determine how DELICATE can be used to develop a notification system. Finally, as a proof-of-concept validation of the framework, we have implemented it in an Android application and tested it using real scenarios. This validation has shown that DELICATE can be used to design a notification system that delivers kind healthcare notifications.

Introduction

With the raise of the Internet of Things (IoT), a constantly growing number of IoT devices that send notifications to users are appearing. Currently, there is more and more data automatically collected and more and more events and alarms that are automatically generated and require attention. This is the case for healthcare environments. The inclusion of IoT technology to support healthcare processes is producing the automation of alarms and other specific tasks that health professionals need to be notified of. In most cases, health professionals have information systems with certain support for desktop notifications, for example, ORBIS (https://global.agfahealthcare.com/main/hospital-it/orbis/) shows notifications in various degrees of severity, from life threatening to serious, warning, and informative, and distinguishes them using different colours. However, people are not sitting behind their computers all the time: in those cases, mobile notifications are necessary.

Although mobile notifications are a core mechanism for communication, they can be disruptive and distract from other tasks that may be more important than the notification itself, that is, they can cause undesired interruptions. Interruptions are defined in healthcare as:

externally or internally generated unexpected events that may cause a break in the primary task, diverting attention to a related or unrelated secondary task, which can have both negative and positive effects on the interrupter’s or the interruptee’s main task. (p. 3) ¹

A balance between the negative and positive effect of notifications needs to be reached to interrupt only when needed without disturbing critical tasks. This balance often depends on the current working situation of health professionals, a situation that may change many times in a single day. For instance, a doctor may be at the operating room in the early morning, attending to a patient at midday, and in a meeting with colleagues in the afternoon.

Health professionals therefore need to be supported by mobile applications that can deliver the notifications in the most appropriate way depending on the particular situation of the professional. This is what we call kind notifications. Although they are extremely important and would considerably improve the way healthcare notifications are handled today, there is a lack of supporting mobile applications that can deliver kind notifications. To improve this problem, we present DELICATE, a Kind Healthcare Notifications Framework. DELICATE is a conceptual framework that categorizes the different attention needs for different notifications, and links these with the delivery mechanisms that are more appropriate for each particular context.

DELICATE follows the Interruption value evaluation paradigm, which is based on the view that not all interruptions are negative, and hence each interruption should be evaluated not just on how it impacts one’s context but also the utility it may bring along. ² Grounded in this paradigm, the focus of DELICATE is to deliver notifications in a kind and effective manner. The former (kind) refers to taking into account the possible interruption for the receiver (notification impact), and the latter (effective) refers to making sure the receiver sees and attends the notification when/if needed (notification utility). Thus, DELICATE takes into account: the availability of the receiver, the relevance of the notification, and the environment constraints for receiving the notification.

DELICATE has been developed in the context of the GPS4IntegratedCare (https://www.imec-int.com/nl/imec-icon/research-portfolio/gps4integratedcare) project and has been co-designed with health professionals in Belgium. In this co-design process, we have analysed real healthcare environments and scenarios to both detect professional needs and validate our results. As an aid for designers, we also define methodological guidelines to clearly determine how DELICATE can be used to define kind notifications. In addition, as a proof of concept, we have developed an Android application that tests DELICATE based on the real scenarios gathered from different hospitals participating in the GPS4IntegratedCare project. The mobile application enables personalized control over how the notifications are delivered to the users. Thus, the contribution of this article is threefold:

1. DELICATE, a conceptual framework for realizing kind notifications in healthcare;

2. A methodological guide for using the framework;

3. A proof-of-concept prototype that has been developed using the methodological guide and the framework to provide kind notifications in an Android mobile phone.

The rest of this article is organized as follows. The ‘Related work’ section describes the prior research related to notification frameworks and non-intrusive human–computer interaction. Afterwards, we describe the research methodology used to develop DELICATE. The ‘DELICATE: Kind Healthcare Notifications Framework’ section describes the framework itself in detail. Afterwards, we show how DELICATE’s theoretical model can be used in a notification flow using realistic examples. Moving to the implementation of the framework in a specific setting, the next sections offer methodological guidelines for using DELICATE and describe an android-based proof of concept. Finally, the ‘Discussion and further work’ and ‘Conclusion’ sections conclude this article.

Related work

Notification frameworks

Since user attention is a valuable but limited resource, notifications should be delivered considering the interruption they may cause. Some studies analyse different issues surrounding interruptions. For instance, McFarlane, ³ and McFarlane and Latorella, ⁴ developed a taxonomy of human interruption as a tool for answering research questions about interruptions. Different factors that may affect the interruption, for example, cognitive, social and environmental factors, have been studied in previous works.^2,5–7 Specifically, Grandhy and Jones ² executed a field study where it was shown that who is calling, as well as the social and cognitive contexts of the call had an influence on interruption management practices in everyday cell phone calls. Ho and Intille ⁵ discuss 11 factors that influence a person’s interruption at a given moment, among others: the activity and social engagement of the user, and the utility of the message. Fischer et al. ⁶ showed that the receptivity to the interruption of SMSs is influenced by its content rather than by its time of delivery. Finally, Calvary et al. ⁷ proposed to take into account the following three facets for adaptive interactions: the end-users of the interactive system, the hardware and software computing platform with which the users have to carry out their interactive tasks and the physical environment where they are working.

Also, some authors have proposed automation frameworks and taxonomies to handle interruptions. For instance, Sheridan and Verplanck ⁸ developed a taxonomy to classify the level of automation that incorporated issues of feedback (what the human should be told by the system), as well as relative sharing of functions determining, selecting, and implementing options. The framework presented by Ju and Leifer ⁹ determines the obtrusiveness level for each interaction in the system. This framework helps designers to create interactions that are socially appropriate, focusing on the manner in which the devices interact with the user. Two dimensions characterize the interactions: attentional demand and initiative. Attentional demand is the degree of cognitive and perceptual loads imposed on users by the interactive system. According to this factor, foreground interactions require a greater degree of focus, concentration and consciousness (the user is fully conscious of the interaction), while background interactions are peripheral and elude the user’s attention (the user is unaware of the interaction with the system). Interactions that are initiated and driven by the user explicitly are called reactive interactions, while interactions initiated by the system based on inferred desire or demand are proactive interactions.

Gil et al. ¹⁰ and Serral et al. ¹¹ extended this framework into the AdaptIO (Adaptive Interaction Obtrusiveness) framework (see Figure 1). AdaptIO was proposed to build ubiquitous and mobile systems capable of adapting its services’ interaction obtrusiveness according to the user’s situational context. The framework has the same two dimensions as the one proposed by Ju and Leifer: ⁹ initiative (reactive vs proactive), and attention, which the authors divide in three segments: invisible, slightly appreciable, and completely aware. Although these frameworks have made significant progress to avoid interruption by automatic services, their focus is not healthcare notifications. The requirements they consider are therefore different than the ones DELICATE addresses.

Figure 1.

Advisory board details.

Calm computing and peripheral interaction

Since the 1990s, researchers have been working on technology in which the interaction between user and system is not in the centre of the user’s attention. ¹² Instead, interaction can be located in the periphery of attention. Since Weiser and Brown’s seminal paper on the topic, numerous researchers have expanded on the idea of calm technology.^13–16 Weiser and Brown’s ¹² work has inspired a variety of ‘visual and auditory displays which subtly present information such that people can perceive it in the periphery of attention’ (p. 4). ¹⁷ As such, most developments in calm technology have focused on peripheral perception.

Bakker ¹⁷ has expanded upon this work by researching the concept of ‘peripheral interaction’: ‘interaction with computing technology which can take place in the periphery of attention and shift to the center of attention when relevant for or desired by the user’ (p. 5). The ultimate goal of technology using peripheral interaction is ‘to fluently embed meaningful interactive systems into people’s everyday lives’ (p. 5). ¹⁷

This work is relevant for the purpose of designing a framework for kind mobile notifications, as it points to the fact that notifications can be designed in different ways. If relevant, notifications should grab the users’ attention – however, if less relevant, notifications can be delivered in a less intrusive way, using different interaction modalities and communication resources.

Research methodology

In this section, we present the research methodology that we followed to develop DELICATE. After the study of the relevant literature (see the ‘Related work’ section), several meetings were held with an advisory board of health professionals to understand the healthcare domain and the current role of notifications. Figure 1 shows the distribution of the advisory board participants in Belgium, indicating the specific organization where they work, their professions and the gender.

Based on the information gathered during these meetings and the findings from the literature, a preliminary version of DELICATE was created. After the advisory board meetings, we conducted a series of workshops with other health professionals to refine, nuance, and validate the preliminary framework. Next, we provide details about these workshops.

Workshop setting

Three workshops were held between October 2017 and March 2018. All workshops were hosted at hospitals in Flanders, Belgium. Two of these hospitals are general hospitals (AZ Maria Middelares in Ghent and ZOL in Genk), while one is a university hospital (UZA affiliated with the University of Antwerp).

Participants

Apart from the GPS4IntegratedCare project researchers, participants with different profiles attended the workshops. Figure 2 provides an overview of the location of the workshops and their participants. This mix of different profiles enabled us to get input for DELICATE from different perspectives.

Figure 2.

Workshop participants’ details.

Procedure and data collection

The workshops were held based on the preliminary version of DELICATE. At the start of the workshops, the framework was presented, and some specific, realistic example scenarios were sketched to make it as tangible as possible for the workshop participants. After this introduction, workshop participants were invited to discuss this future vision on notifications in healthcare, compare this vision with the present situation and discuss opportunities and potential pitfalls that need to be avoided to make the move from the present situation to the future vision. ¹⁸

During the workshops, notes were taken that were used to refine, nuance, and further iterate on the theoretical framework. Workshop participants described relevant examples of personal situations and contexts where notifications were possible and reflected on how automatic notifications would change their work. Furthermore, they offered insights into how they expected to personalize an automated notification system to suit their personal needs and preferences. As such, the workshop data allowed us to improve and validate the first version of the framework. This combination of theory-based and practice-based input resulted in the development of the DELICATE framework.

DELICATE

This section presents DELICATE, a novel three-dimensional framework to determine notification requirements for specific user attention levels. The ‘Requirements for kind healthcare notifications’ section lists high-level requirements that guided the design of DELICATE. These requirements were gathered during early meetings and discussions on the DELICATE framework. The ‘Framework dimensions’ section presents DELICATE’s three dimensions and how they are linked with the identified requirements. The ‘Notification relevance’ section describes the framework support for personalizing notifications.

Requirements for kind healthcare notifications

The workshops resulted in the following high-level requirements for a healthcare notifications framework, which served as guidelines for the development of DELICATE:

• Requirements that characterize notifications and their handling in a healthcare context are as follows:

• - RE2. Take into account the users’ availability. The appropriateness of a notification depends on the user availability, which in most cases depends mainly on the location and current activity of the user.

• - RE3. Find a balance between intrusiveness and effectiveness. A notification should not be intrusive (taking into account the receivers’ preferences) but all the important notifications (taking into account the senders’ needs) must be attended.

• - RE4. Do not create additional workload. Avoid delivering notifications that are not relevant. Health professionals do not want an extra burden added to their current practice.

• - RE5. Design a clear response flow. It must be clear whether the receiver attends the notification, as legal and procedural aspects may be relevant: the receiver becomes responsible of attending the notification. Therefore, participants suggested a button should be used to either accept or reject an incoming notification. If the notification is rejected, and it is urgent, it should be forwarded, if it is not urgent, it can be delayed.

Requirements regarding personalization of the notification process are as follows:

- RE6. Allow for personalization. Each user has its own preferences regarding how to receive notifications. Therefore, they need to be highly customizable.

- RE7. Allow for customization on the organizational level. The importance of a notification should be determined by the healthcare organization where the notification is generated. This may vary from one organization to another.

Framework dimensions

DELICATE is structured as a relation among the following three dimensions, which are extracted from the requirements presented above (see Figure 3):

1. The notification relevance (RE1);

2. The receiver availability (RE2);

3. The notification handling (RE3, RE4, and RE5).

RE1 and RE2 indicate that health professionals need a notification framework that classifies notifications in terms of both their relevance and the users’ availability. Thus, these features constitute the first two dimensions of the framework represented on the X- and Y-axes, respectively (see Figure 3).

Figure 3.

The three dimensions of DELICATE.

The creation of the third framework dimension is driven by RE3, RE4, and RE5. RE3 specifies that notifications should not be intrusive but effective. This means that health professionals should be notified considering also (in addition to the notification’s relevance and the users’ availability) the attention level (i.e. the degree of cognitive and perceptual loads) they prefer to dedicate in the perception of notifications. For instance, there could be situations in which users want to be immediately aware of every notification in the precise moment it arrives; in others, users may prefer to be aware of notifications only if they take a look at the mobile device. Finally, RE4 and RE5 suggest that mechanisms to facilitate a quick response to specific types of notifications, including their rejection, must be provided. To satisfy these requirements, we considered the possibility of defining automatic actions in response to specific notifications. Thus, by considering RE3, RE4, and RE5, we have added a third dimension to DELICATE that characterizes the notification handling in terms of (1) the attention level that users can dedicate to perceive notifications and (2) the automatic actions that may be performed in response.

The following sections explain each dimension in detail.

Notification relevance

The feedback from the advisory board and the workshops has shown that the relevance of a notification is determined by how crucial it is that the receiver receives the message, which depends on the importance of the message as well as on the reaction time, that is, how fast the receiver must react on the notification. According to RE1, the relevance in this case must be categorized by the healthcare organization that sends the notification. For some other projects, however, the relevance could be different for the receiver considering different factors. To cover the different possibilities, we have defined the following relevance levels for caregivers, which can be determined considering any kind of factor:

• Very high. The notification is important and needs immediate reaction. Considering the Common Terminology Criteria for Adverse Events (CTCAE), which is a commonly used classification of events in healthcare, this level would correspond to the CTCAE Grade 4, which refers to life-threatening consequences and urgent interventions.

• High. The notification should be seen (it is important for the doctor to see the message), but it does not need immediate attention. This level would match with CTCAE Grade 3, which corresponds to severe, medically significant events that are not immediately life-threatening, notifications of hospitalization or prolongation of hospitalization; or notifications of events of disabling or limiting self-care Activities of Daily Living (ADL, for example, feeding self, taking medications). Workshop participants pointed out that at this relevance level, notifications should be linked to specific goals. For instance, as keeping treatment plans up to date is an important goal, the arrival of lab results with implications for the treatment plan of a patient warrants a notification to the relevant health professional.

• Low. The notification does not necessarily require that the receiver checks the message. Rather, it is an informative notification. This level would match with CTCAE Grades 1 (asymptomatic or mild symptoms; clinical or diagnostic observations; intervention not indicated) and 2 (minimal, local or non-invasive intervention indicated; limiting age-appropriate instrumental ADL, for example, preparing meals, shopping for groceries or clothes).

Receiver availability

The receiver availability depends on how feasible it is for him or her to attend notifications. To cover an appropriately wide spectrum of possibilities, taking into account the practitioners’ feedback from the workshops, the following availability levels have been defined in DELICATE:

• High. The user is available, for example, the health professional is working alone in the office.

• Low. The user is very busy, for example, attending a patient but not doing any physical action, like questioning and listening to the patient, or performing a physical action that is not critical, such as measuring the blood pressure of a patient.

• None. The user is considered not available, for example, when the doctor is not working or is in surgery.

Workshop results have shown that a distinction between moderate and high availability is not useful, as participants could not determine clear criteria to distinguish between both.

Notification handling

The handling of a notification is defined in terms of (1) the attention that the user can dedicate to notifications (attention level) and (2) the automatic actions that may be performed as a response. In this way, DELICATE is structured as an attention space where each quadrant can be complemented with the following information:

Attention level

The attention level indicates how much attention resources the user wants to dedicate to perceive notifications. The attention levels we use in DELICATE are inspired by the ones proposed by AdaptIO (see the ‘Related work’ section), which are as follows:

• Completely aware (CA). The user wants to be aware of notifications even if he or she is performing other tasks.

• Slightly appreciable (SA). The user does not want to perceive notifications unless he or she makes some effort.

• Invisible (I). The user does not want to perceive notifications.

Automatic actions

We have defined the following automatic actions, which can be used as reaction to a notification:

• Reject. Notifications will be rejected in case they have a very high relevance, but the receiver is not available at that moment. In this case, the notification must be rejected so it can be immediately forwarded to another person that can take care of it as soon as possible.

• Delay. Notifications will be delayed in case they have a high relevance, but the user is not available at that moment. In this case, the notification can be delayed until the receiver can see the notification.

Framework instantiation example

Figure 4 shows the specific preferences of one of the oncologists participating in the workshops (here after referred to as Jane Smith). According to this instantiation of the framework, Jane wants a notification strategy as follows:

• Jane does not want to perceive any notifications if their relevance is low – whether she is available or not. For notifications with low relevance, she wants the interaction to be invisible.

• When the relevance of a notification is high, she wants to be aware of notifications even when she is performing other tasks (completely aware interaction). For this reason, if she has none or low availability, the notification will be delayed until she has high availability.

• When the relevance of a notification is very high, she wants to be completely aware when she can react to it (has low or high availability). If she has no availability, the notification will be handled in an invisible way (added as handled in the list of notifications) and will automatically be rejected so it is immediately redirected to another colleague.

Figure 4.

DELICATE details.

Personalization of the sending and reception of notifications

DELICATE allows us to indicate the handling for notifications that each health professional may need in terms of the attention level and automatic actions, depending on their availability and the relevance of the notification. This is a personalization capability that DELICATE provides: health professionals (or professional category) can have their own framework instantiation to personalize how they want to interact with notifications.

However, RE6 and RE7 indicate that more sophisticated mechanisms must be provided to personalize the reception and sending of notifications, respectively.

First, to satisfy RE6, we complemented DELICATE with mechanisms to define the communication resources (i.e. sounds, vibration, lights) that, depending on environment conditions (i.e. level of environmental sound, location of the user, current time), must be used to fit the attention demand preferred by the user.

Different communication resources (namely, a resource configuration (RC)) can be used to deliver a notification. These resources can be described using feature modelling, which is commonly used to describe a system configuration and its variants by means of features (coarse-grained interaction functionality). ¹⁹ As an example, Figure 5 shows the feature model that represents the possible communication resources used in this work, which are the available ones in a smartphone.

Figure 5.

Feature model that represents possible communication resources available in a smartphone.

A specific RC (i.e. a selection of features of the model) can then be associated with different attention levels (see the ‘Notification handling’ section) within different context conditions. For instance, a possible RC for the CA level in a quiet environment can conceptually be expressed as follows:

$$R{C}_{CA}\left(noise<threshold\right)=\mathrm{Visual},\mathrm{PopUp};\mathrm{Visual},\mathrm{Text};\mathrm{Auditory},\mathrm{Sound};\mathrm{Constant}.$$

If the environment is too noisy to hear the phone sound, the following configuration can be activated (using lights and vibration instead of sound):

$$\begin{array}{l}R{C}_{CA}\left(noise\ge threshold\right)=\mathrm{Visual},\mathrm{PopUp};\mathrm{Visual},\mathrm{Text};\mathrm{Visual},\mathrm{Lights};\\ \mathrm{Haptic},\mathrm{Vibration};\mathrm{Constant}\end{array}$$

Some attention levels may not depend on environment conditions. For instance, the Invisible mode, which implies that users do not want to perceive notifications, may not depend on environment conditions since it does not require to demand user attention. Thus, we can define it without any condition: $R{C}_I$  = Visual, Text.

The feature selection should be based on guidelines for user interface design and modality combinations such as the ones that are further presented in the ‘Definition of communication resources’ section, but most importantly, on the user preferences and constraints. Note that the RCs can be reused for different users with similar preferences.

Second, RE7 suggests that senders should be able to personalize the relevance of each notification in an agile way. Health professionals receive notifications of different types: cardiac disorders, infections, investigations, and so on. Typically, healthcare organizations have predefined classifications of notification relevance, for example, CTCAE. ²⁰ However, these classifications may vary between different healthcare organizations, or even between different departments. For this reason, in this work, we assume that the notification relevance will be assigned by the sender of the notification at the time the notification is sent. This can be done in a manual way if there is a person that creates the notification, and it can also be done automatically if the healthcare organization has a relevance classification: this classification could be automatically interpreted to assign the corresponding notification relevance. This aspect, however, is out of the scope of this article.

Notification flow

The following sequential steps are performed when delivering a notification following DELICATE (see Figure 6):

1. Sending of notifications with a relevance level. A sender organization sends a notification with a specific relevance to the health professional’s mobile app that implements DELICATE.

2. Selection of a framework quadrant. The mobile app receives the notification with its associated relevance and:

3. Identifies the user’s availability according to the situation.

4. Selects the framework quadrant corresponding to the notification relevance and the user’s availability, and retrieves the automatic action, if any, and the attention level assigned for that quadrant.

Treatment of automatic actions.

If the automatic action is ‘delay’, the app adds the notification to a notification queue. When the user is available, the app executes step 4.

If the automatic action is ‘reject’, the app rejects the notification and sends the corresponding message to the sender. Afterwards, the app executes step 4.

Selection of communication resources.

If the attention level is dependent on conditions, the app determines which condition is satisfied.

The app retrieves the communication resources according to the attention level (and environment conditions).

The app delivers the notification using those resources.

Figure 6.

Notification flow with DELICATE.

The ‘Scenario 1: very high relevance and high availability’ and ‘Scenario 2: very high relevance and no availability’ sections present two scenarios to illustrate the notification flow. In both scenarios, there are two participants:

• The hospital emergency room, which is the sender of the notifications. This participant needs to have a software tool that allows sending notifications with a specific relevance.

• Jane Smith, who is a neurosurgeon of the hospital. She has a mobile device with an app that implements DELICATE. This app uses the following resources:

• - The RCs assigned to each attention level. We use the one presented in the section ‘Personalization of the sending and reception of notifications’.

• - A list of Jane’s working situations and her availability.

Note that these scenarios do not consider the design process and implementation issues, which will be introduced in the next two sections.

Scenario 1: very high relevance and high availability

In the first scenario (see Figure 7), Jane Smith is in her office talking with a colleague. Suddenly, she receives a notification from the hospital emergency service indicating that a traffic accident has happened and her assistance is needed (step 1). The hospital service has indicated a very high relevance when sending the notification. Jane has a high availability because she is at her office (step 2a, b). Thus, the top right quadrant is selected (step 2b), which indicates a CA attention level and no automatic action.

Figure 7.

Notification with very high relevance and user with high availability.

A CA attention level means that Jane wants to be aware of the notification in such a way that she perceives the notification even if she is performing other tasks at that moment. The CA attention level has several conditions (step 4a): if Jane is working in a quiet environment, the notification should be received as PopUp, a Text Message and Sound that are Constant (i.e. they will be shown until the user attends the notification). On the contrary, if there is a noisy environment in her office (e.g. she is listening to music, there are building maintenance activities close to her office, colleagues are shouting in adjacent offices), the notification should be received by using a Constant PopUp, Text Message, with Lights and Vibration. Since Jane is in a quiet environment, the first condition is satisfied and therefore the appropriate communication resources are selected (step 4b) and used to deliver the notification (step 4c).

Scenario 2: very high relevance and no availability

In the second scenario (see Figure 8), Jane receives the same notification. However, this time, she is in the operating room and this situation has been associated with none availability according to the DELICATE’s instantiation designed for her. Thus, we have a notification with a very high relevance that is sent to a user that is not available. In this case, the framework quadrant (top left) has a ‘reject’ automatic action and an ‘Invisible’ attention level, therefore, the notification is rejected and a rejection message is sent to the sender (step 3b). The communication resources for this quadrant are Visual, Text; therefore, the text of the rejected notification is just added in the background to the list of notifications (step 3c).

Figure 8.

Notification with a very high relevance and the user not available.

Designing kind healthcare notifications: methodological guide for using DELICATE

DELICATE characterizes notifications by means of three dimensions: notification relevance, user availability, and notification handling (attention level and automatic actions). In addition, context-dependent configurations of communication resources are also considered. Together with the health professionals, the designer should capture this information at design time. To facilitate this activity, we present a methodological guide that includes the following two main tasks (see Figure 8):

• Capturing the user’s preferences in terms of availability, attention levels and automatic actions. We need to identify in which situations the user should be considered not available, or with low or high availability. We also need to determine the attention level that users consider most adequate for each quadrant as well as whether or not some automatic action should be taken. We propose two strategies for this task: (1) one based on techniques targeted at designers for capturing user’s needs and (2) another based on end-user development techniques targeted at the health professionals.

• Definition of communication RCs. Once the situations that determine the user’s availability and the attention levels have been characterized, designers must specify which communication resources should be used for attention level, taking into account the relevant context conditions (e.g. environment noise).

Availability, attention levels, and automatic actions

Our main goal is to specify working situations that determine user’s availability as well as the attention level and automatic actions that each user prefers for each DELICATE quadrant. To do so, several techniques can be used. Some examples are natural language, ²¹ structured templates ²² or graphical notations such as use cases. ²³ In this work, we propose the use of personas ²⁴ that are widely used in user-centred design. ²⁵ Each persona is a fictional character that represents a specific user type, capturing relevant information that impacts the design process: user goals, scenarios, tasks, and so on. Although these user profiles are depicted as specific individuals because they function as archetypes, they represent a type of user. They are helpful when you want to understand users’ needs, experiences, expectations, behaviours and goals. The main idea is to create a target user which designers can empathize with to improve design activities. However, note that personas are based on real data obtained from previous requirements elicitation activities, such as user research, stakeholder interviews, and/or brainstorming sessions.

Thus, we create personas to specify the availability and attention level of health professionals, and also as a technique that can be used to improve later design activities. There is no standard format for representing personas. They may range from a very simple to a very detailed description, and usually include a name and an image of a person, together with the fundamental data to create an archetype of real users which designers can empathize with. In this work, we include in the persona depicted in Figure 9 the background and the goals of a health professional; the activities she performs at work and her availability and attention level in different situations. In this example, we have mainly focused on work data to illustrate how DELICATE is used within a healthcare environment. However, additional personal data may be included to create more empathy.

Figure 9.

Example of a persona with availability data.

During our research, we collaborated with professionals who suggested it would be useful to have mechanisms to define their working situations and availability themselves, without depending on interviews with designers. Previous works^26–28 show that a more active participation of users in requirements gathering can improve problems of understanding that appear in interviews. This active participation is often achieved through end-user tools. ²⁹ In this work, we propose the use of an application like the one developed in Van Woensel et al. ³⁰ In this case, we have developed an easy-to-use designer tool that allows health professionals to define their availability on their own. The user interfaces have been designed taking into account the study presented in Galitz, ³¹ which recommend data selection instead of typing it to avoid end-users’ errors. Thus, this tool provides a set of default situations that health professionals just need to select (Figure 10(a)) to indicate their availability (Figure 10(b)). In particular, workshop participants suggested that their availability would mainly depend on their location and their current activity. Therefore, we developed same examples along these lines. In any case, users can define new situations if required (Figure 10(c)). A screen to define the attention level and automatic actions has been also designed (Figure 10(d)).

Figure 10.

Availability and attention level designer for end-users.

After performing this task, we obtained a list of situations with an associated availability, and the attention level that users prefer for each quadrant of the framework. It is important to note that the framework can be implemented in various ways. First, detailing how notifications should be composed and delivered can be defined on an institutional level, for specific groups of users (nurses, doctors, etc.), or it can be tailored to the needs of each individual user. In this case, health professionals can use the dedicated end-user tool. Second, concerning the granularity of attention needs, the framework allows for implementations that range from very nuanced (detailing different notification mechanisms for each quadrant and different situations) to very coarse (e.g. with a simpler, binary distinction between must-see high-priority notifications and an undifferentiated category of less-important notifications).

Definition of communication resources

The division of the attention space (the framework’s quadrants) drives the selection of the communication resources that are best suited for each situation. Depending on the degree of attention required, different communication resources must be activated to deliver the notifications in a kind manner. As introduced above, the configuration of communication resources should be based on some guidelines for user interface design and modality combinations. Reeves et al. ³² defined several guidelines for multimodal user interface design. From these guidelines, the following are especially relevant to healthcare notifications:

• Avoid redundancy. The use of unnecessarily additional modalities should be avoided as such redundancy can increase cognitive load at the cost of learning the material being presented.

• Maximize the advantages of each modality to reduce the user’s memory load in certain tasks and situations.

• Multimodal interfaces should adapt to the needs and abilities of different users, as well as different contexts of use. Individual differences, such as age, preferences, skill, sensory or motor impairment, can be captured in a user profile and used to determine interface settings.

• Multimodal systems should be designed for the broadest range of users and contexts of use. Designers should use the best modality or combination of modalities anticipated in changing environments (e.g. private office vs driving a car).

• Designers should take care to address privacy and security issues, for example, non-speech alternatives should be available in a public context to prevent others from overhearing private information or conversations.

• Provide good error prevention and error handling and make functionality clear and easily discoverable.

According to Cao et al., ³³ presentation and perception are also important aspects to be considered. Cao et al. studied the effects on the cognitive load of the different modalities and combinations of modalities. Different modality usages can impose different levels of cognitive load to the user even if they are used to convey the same information. For example, the results of the study by Cao et al. support the avoid redundancy guideline defined by Reeves et al., which indicates that a modality combination is not necessarily better than the use of a single modality:

• Sometimes image is a more suitable modality than text + image, as users may experience less mental workload.

• Text + speech is a better modality than text only.

• Visual–auditory combinations (text + speech, text + sound) impose less cognitive load and enable better performance than a visual–visual combination (text + image), which creates overload and causes distraction. Between the two visual–auditory combinations, text + speech has been shown to be better than the text + sound condition. It imposed less cognitive load and allowed faster reaction as speech can be directly rehearsed and maintained in the short-term memory, while the direction of sound needs to be translated from a nonverbal code into a verbal code.

The study also shows that the cognitive effects of modalities might not be crucial to the quality of interaction when the cognitive load demand is low. However, the quality considerably improves when the information load is high, the user task is time critical, and the full capacity of human cognition is being challenged. ³³

Proof of concept: Android-based implementation

In this section, we present an Android application that implements a proof of concept of DELICATE. This application, installed in the smartphone of a health professional, takes into account her preferences and situation to deliver each notification using the most appropriate communication resources. As such, each notification fits the user’s preferred attention level for the specific situation. To develop this application, we have taken the following technological decisions (all graphically illustrated in Figure 11):

Figure 11.

Architecture implemented for the proof of concept.

First, notifications with a specific relevance need to be sent. To do this, we have used the free Google Cloud Messaging service that allows us to push messages to the Android application that delivers the notification. Note that the implementation of the application that sends these messages is out of the scope of this proof of concept. Any application implemented with Java technology can use the Application Programming Interface (API) provided by Google to send messages.

These messages are structured in JSON format and include an id, a short text description, a timestamp and the relevance of the notification. The following is a representative example:

{

 "to": "e1w6hEbZn-8:APA91bEUIb2JewYCIiApsMu5JfI5Ak. . .",

 "data": {

       "message ID": "182012",

       "message text": "Go to operation room 1.34",

       "event date": "24-04-2018",

 "relevance": "very high"

   }

}

When the Android app (identified by the value specified in the ‘to’ property) receives a message, it interprets the corresponding JSON property to determine the relevance of the notification. Next, the app needs to know the availability and attention level of the health professional to properly inform her.

Second, the user’s availability and attention levels need to be specified in the Android app. At design time, we have obtained a list of working situations with a specific availability. We have also specified a list of attention levels, with different communication resources associated with them, depending on context conditions. We need to include all this information into the Android app to decide how to interact with users when a notification arrives.

There are several technological solutions to face this challenge. For instance, we can create a JSON file with this information that can be latter processed with a parser; we can describe all the information in an OWL ontology and query it with SPARQL; we can use a local relational database such as SQLite that allow to execute SQL queries and so on. In this work, we have used the last solution because of its ease of implementation and potential of using SQL queries.

Third, the technology needs to determine the current situation and availability of the user. For the proof of concept, we have simply used the Google calendar/agenda of the receiver, which we access using the Google Calendar API. This implies that health professionals must have their agenda available and up to date. This preliminary solution facilitates to easily test different scenarios by changing the user agenda. Ideally, for a final application, an analysis of the current user activity and user location should be performed to automatically determine and update the current user situation. ³⁴

Fourth, the environment context needs to be captured. Time, location, noise, light and many other context parameters can be currently sensed by standard mobile devices. Thus, we have used the own capabilities of Android mobile phones to know current context conditions. For instance, we used the microphone of an Android device to sense the noise level in decibels (dB), or the light sensor to know the light intensity in luxes. However, considering a precision of decibels or luxes is not appropriate for specifying realistic environmental conditions, that is, humans do not think on these metrics to describe their situation. Thus, we created some predefined levels and assigned an alias to them. For instance, to define conditions based on noise, we defined three noise levels: silence, quiet, and noisy. Since a conversational speech is usually around 60 dB, we established the noise levels as follows: a measurement higher or equal than 80 dB was considered a noisy environment; any value between 30 and 80 dB was considered as a quiet environment and a measurement lower or equal than 30 dB was considered a silence environment (the dBs of a whisper). To work with these noise levels at runtime, we used an SQLite database, in this way, SQL queries can be quickly executed to know the noise level that corresponds to a value in dB. Other conditions such as light intensity are supported in an analogous way.

The technical decisions outlined above have resulted in the proof of concept architecture described in Figure 11 that shows how the developed Android app receives healthcare notifications with a specific relevance by using the Google Cloud Messaging service. According to the instantiation of DELICATE that the app has, the environment information, and the user’s Google Calendar, the app determines how the notification needs to be delivered. A video demo of the developed Android application is available at: https://media.upv.es/player/?id=9dc23fd0-cfdf-11e8-85bc-5bc83fa995d1 .

Discussion and further work

DELICATE is a first step towards kind healthcare mobile notifications. The design and validation of the framework presented in this article meets the established requirements, but the following aspects need further research:

• For very highly relevant notifications, phone calls are currently used to allow questions to be answered and solved on the spot. Although the physicians acknowledged the usefulness of DELICATE, they argued that phone calls might still be the best way to go for notifications that require a discussion between the sender and the receiver. In specific situations, phone calls will remain necessary to communicate and discuss all necessary details: in this sense, DELICATE can be considered as a complement to current telephone practices. However, further research should be performed to analyse to what extent notifications can systematically include all necessary information to avoid discussions and ambiguity, to substitute the phone calls. As such, DELICATE could significantly diminish manual and routine work and make it more efficient.

• In our approach, the user information can be stored locally in the user’s own device. This approach allows keeping all personal information private. However, this issue, as well as the legal consequences of accepting or rejecting a notification, should be studied further to be compliant to current regulations.

• The notification relevance is currently indicated manually when the message is sent. To introduce more automation, the message categories that are used for different healthcare stakeholders, also internationally, can be studied, aligned, and represented in a machine-understandable format. These categories could be used to automatically classify the notifications according to their relevance. Furthermore, we plan to investigate an automatic dispatching service that can find out to which user the notification should be addressed as well as a cascading system that determines the next user to contact if the previous contacted one cannot attend a specific notification.

• The current implementation of DELICATE only takes into account environment constraints when delivering the notification. However, other constraints can be considered as well in the future. Specifically, Obrenovic et al. ³⁵ identify four kinds of output communication constraints: device constraints (e.g. in the case of mobile phones, the size of the display is limited, in the case of a tablet, haptic feedback is not supported), user constraints (e.g. disabilities like hearing impairments), environmental constraints (e.g. noise level, visual conditions, weather conditions), and social context (e.g. people around the user).

• DELICATE focuses on delivering notifications addressed to health professionals. We have also started studying the notification needs of patients. As a next step, it should be investigated how the framework can be applied to satisfy patient needs as well, for example, by organizing focus groups to study their specific needs.

• Finally, the main goal of the current work was to define and to assess the feasibility of the proposed notification framework. To do so, we focused on how notifications need to be characterized at design time and how they can be managed at runtime. The current proof-of-concept Android app was helpful to communicate and evaluate the function of the notification framework based on real-life scenarios, using a functional application prototype. In future work, an elaborate, in-hospital trial of the notification framework will be planned to validate the final application in real life.

Conclusion

In this article, we have presented DELICATE, a conceptual framework to deliver mobile healthcare notifications to health professionals. DELICATE has been designed to deliver such notifications in a kind manner, without interrupting the tasks the professionals are performing unless it is actually needed. To do this, DELICATE considers the notification relevance, and the users’ availability and attention levels they can offer at the moment the notification arrives. Based on this information, DELICATE can select the proper communication resources to deliver notifications in a kind and effective manner. DELICATE has been co-designed with health professionals in Belgium and has been created to be highly customized to fit personal and specific needs.