Characterizing Context for Mobile User Interfaces in Healthcare ...

Procedia Computer Science

Procedia Computer Science 00 (2011) 000–000

www.elsevier.com/locate/procedia

The 9th International Conference on Mobile Web Information Systems

Characterizing Context for Mobile User Interfaces in Healthcare Applications R. Alnanih, T. Radhakrishnan, O. Ormandjieva Department of Computer Science & Software Engineering, Concordia University,1455 De Maisonneuve Blvd. W., Montreal, QC H3G 1M8, Canada

Abstract Mobile technology has been piloted in a variety of domains. We investigate the role of smart mobile phones regarding its use in the hospital environment, as they can play significant role in the recording and exchange of information. This paper examines how context can be characterized for developing context sensitive user interfaces for smart phone application in a hospital environment. We reintroduce a new characterization of the notion of context, based on separation of concern principles that are relevant to the domain of application. Our characterization of context is defined at two unique levels that are named: basic context and domain-based context. We coin the term context descriptor which captures the notion of context at the end users’ level and the characterization of the context incorporates the user model via the user stereotype. We use a sub-domain of health care that is nursing services, and their tasks as a running example to drive home the ideas presented.

© 2011 Published by Elsevier Ltd. Selection and/or peer-review under responsibility of [name organizer] Keywords: Context; Mobile; User Interface; User Stereotype, Context Descriptor; Health Services.

1. Introduction Understanding and defining the notion of ‘context’ has been a focus for researchers with interests in different domains of applications. For example, Winograd has studied context in the linguistic sense as used in human dialogs [1], Pascoe has studied context with respect to wearable computers [2], and Dey and Abowd have examined context in a generic sense [3]. People have used context for the development of adaptive or intelligent systems that are capable of sensing specific context, and based on this, adapting the system’s behaviour at run time in an appropriate manner is their important consideration. With the increasing popularity of mobile devices like smart phones and tablets, these devices’ applications in the Healthcare domain are becoming more and more relevant. This is one of the application domains of people’s and Nation’s current needs but has not yet been widely researched and brought into practice. The user interfaces (UI) and user experiences in healthcare applications are extremely important to promote

2

Author name / Procedia Computer Science 00 (2012) 000–000

the translation of research into practice in hospitals and clinics. We have termed the UI developed for mobile devices as Mobile User Interface or MUI. The designer of an MUI can incorporate context based adaptations in the interface appearance or in the behaviour, either at the design time or at the run time. Mobile technology has been piloted in a range of health-related areas, including improving the dissemination of public health information (e.g. disease outbreak and prevention messages). It has also facilitated remote consultation, diagnosis and treatment, the dissemination of health information to doctors and nurses, patient management, public health monitoring and increased efficiency of administrative systems. Research suggests that mobile phones can play a significant role in all of these areas [4]; however, the role of mobile phones, as with other information and communication technologies (ICT), is subject to increasing scrutiny in the health care area, precisely because the stakes are so high and the potential gains from technology development in this area are so significant [4]. This paper first deals with the idea of characterizing the context for MUI development; and then provides a brief exposure, through an example, to an approach for developing a MUI based on that notion of context. The paper is organized as follows: In section 2, for the sake of brevity, we present a brief overview of a ‘sub domain’ example within healthcare applications. We do not address the important issues of security, privacy, and reliability with regard to healthcare applications in this section. Section 3 provides a summary of the literature with respect to characterizing the context. At the end of this section we present how our views are similar and different from other views. Section 4 is a brief introduction to MUI development. In section 5 we present our clear understanding of context in this domain of application and in Section 6 we summarize and point out our on-going research. 2. A ‘sub domain’ example from a Hospital ward A hospital is a sub unit within a larger healthcare system. In a large metropolitan hospital usually there will be an emergency unit, several hospital wards, specialized diagnostic or service divisions; and possibly a number of out-patient clinics. Functioning of a Hospital can be viewed as a coordinated set of services. Some examples include doctor consulting and examination services, imaging services, pharmacy, food, transport within the hospital, testing (blood, pulmonary, etc.) services, and nursing services. For our discussions, we focus on the particular area of the hospital ward that involves nursing services. Relevant actors are: nurses, patients, doctors, pharmacists, orderlies, nutritionists and PCAs (personal care assistants). An actor plays many different roles. The relationship between roles and actors is many-to-many. All role playing in hospitals involve both information based actions (record keeping) and skill oriented physical actions (e.g. checking blood pressure). Let us consider one of the many roles played by a nurse, namely taking and recording the vital signs such as temperature, blood sugar, blood pressure, pulse, oxygen saturation, pain level, fluid in and fluid out, weight, and the healing status of a wound. The frequency of such recording in a single day depends on the particular case of a patient. In a traditional system, the nurse notes down all the vital sign values on a piece of paper, that she always keeps in her coat pocket, and later on enters them on a nursing chart. This chart serves as a medium of communication with other actors who need to share that recorded information about patients. Typically, a nurse on duty in a hospital ward looks after two, three, and four or up to six patients in a shift. Noting down the data of multiple patients on the paper and copying them in paper form have been found to be a possible source of error; as well, sharing the paper document is not as versatile as an electronic document. In a modern hospital ward there will usually be a nursing station and a desktop computer that is provided for all of the nurses to share and enter the vital signs into shareable electronic records. An improved method would be to use a mobile device for each nurse on duty which would allow them to enter the vital signs immediately, preferably at the point of care. This is one of the well matched mobile applications in a hospital. A mobile device of that kind can be used for additional purposes by a nurse such as instant

Author name / Procedia Computer Science 00 (2012) 000–000

communication with other actors and for checking specific medicine details and for verifying the medical care protocols in complex situations. In a large organization like a hospital one cannot assume that all nurses are alike. We will find a number of user models into which the different nurses will fit. For example, a young nurse recently graduated with a modern curriculum might be very computer savvy and will be quick to learn a new application on a mobile device. An experienced nurse who has familiarity with computers might be willing to be trained and willingly adapt to new methods of doing her mundane paper work. A senior nurse who has years of experience might be reluctant to change and might even be ‘afraid’ of using mobile phones based applications. Thus, when developing MUI or context aware applications in a hospital domain, the developer will have to take into consideration the user models. When this is not done, we have found in practice that user experiences are very mixed and one can not succeed in the real world in technology acceptance [5]. 3. View of Context by other Researchers The commonly used English word ‘context’ is intuitively understood by people but its formal or technical definition when used in Context aware computing or in the design of Adaptive software systems is quite elusive. There is no ‘universally accepted’ definition and our belief is that there will be none possible that can satisfy everyone under all circumstances. Some people use the terms ‘context’ and ‘situation’ synonymously [3], whereas others differentiate them. However, a clear and unambiguous understanding of the term ‘context’ will help the software engineers to accomplish the development goals relatively more efficiently and effectively. People have viewed ‘context’ in various domains and have created several models for the notion of context. Context models and a clear understanding of the term ‘context’ in a technical sense is becoming important as the popularity of mobile computing increases, and used anywhere, anytime, and to communicate with remotely located people. A comprehensive review of the extensive literature in this area is quite challenging. In this section we consider some critical issues but we do not claim this review to be all-inclusive. An interesting question posed by a software engineer might be, ‘What comes after clearly defining the notion of context?” The context aware or the adaptive system under operation should be able to do the following: (a) Based on the instrumentation in hardware and/or software, sense or gather the parameters needed to recognize the context; (b) Recognize the context from such parameters; (c) Act as per the recognized context following the adaptiveness built into system implementation. The adaptive system actions could fall into different categories such as, information access and display, information referrals or recommendations, services of some kind, transactions, browsing, social networking, business communications, multimedia based leisure activities, and finally, monitoring and alerting the end user environment. Meeting these requirements would require additional algorithms, processes (and sub processes), or enhancements to the software architecture. The familiar and abstract notion of ‘state’ in Computer Science, and its concrete representation by means of a ‘state vector’ (a vector of computer manipulated parameters) are useful when we try to understand the otherwise intuitive notion of context. Let us restrict our focus to a given domain at one time, otherwise additional encompassing definitions can become intractable. At the same time, we leave the intuition of understanding the boundaries of a ‘domain’ to the software engineer. This assumption is mainly due to our main goal in our research which is to explore the applications of mobile computing in the broad domain of Healthcare, particularly in Hospital settings. While developing a model or a clear interpretation for the intuitive notion of context, the basic question to ask is: “The state of What?” The answer to this question is not simple. It involves a complex combination of multiple entities and these entities can be physical (room), logical (software artifacts or co-location or collaboration requirement of other entities), actors or human users in our research (who perform the task), and what task is performed. We believe that consideration of this question by various researchers is one that has resulted in a

3

4

Author name / Procedia Computer Science 00 (2012) 000–000

multitude of context models, definitions or interpretations in the literature for the term ‘context.’ Different researchers publishing on this topic within literature have viewed ‘What’ differently. Some researchers defined context as the user's physical, social, emotional or informational state or as the subset of physical and conceptual states of interest to a particular entity [3]. For them, an entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and the applications themselves. The authors in [3] have presented the definition or interpretation of the term ‘context’ by different researchers. For example, they have enumerated how context is viewed by Schilit and Theimer [6], Brown et al. [7], Ryan et al. [8], Dey [9], Franklin & Flaschbart [10], Ward et al.[11], Rodden et al. [12], Hull et al. [13], Pascoe [2], Schilit et al. [14]. In Dey and Abowd [3] the authors are interested in the context aware system and hence they focused on characterizing the term ‘context.’ In a Tabular format they compare 14 different context aware systems reported as of the year 2000. For the sake of comparison they have introduced two terms: Context Type and Context Aware System’s functionality. Their context type includes Activity (A), Identity (I), Location (L) and Time (T). The functionalities are classified into Presentation, Execution and Tagging. In Pascoe [2], the author interest in the notion of ‘context’ is in wearable computers. His view of ‘context’ is based on the sensed parameters of the environment. He also studies the difficulties in building context aware systems and introduces the notion of CIS or Context Information Service. Then, any context aware system can retrieve the context information from CIS. Subsequently in Pascoe et al. [15], the authors introduce the notion of a universal context model that can enable applications to sense their surrounding environment in order for them to react or adapt. Objects and relationships are used by them. Two parameterized relationships are developed: the “is-in relationship,” linking the relationship between objects which suggests a location; and the “is-near relationship,” which they re-label “as with” and which characterizes the difference between a location inference and the problem of ownership. In Gwizdka [16], the author introduces what is in a ‘context’ as internal (to the user) and external in dealing with context information. Internal context describes the state of the user. It can be composed of work context (e.g. current projects and their status, status of to-dos, project team), personal events (i.e. events experienced by the user; these events are internalized external events), communication context (i.e. state of interpersonal email communication), and the emotional state of the user. External context describes the state of the environment. It can be composed of location, proximity to other objects (both people and devices), and temporal context. In Winograd [1], the author introduces the term ‘context’ from a linguistic point of view and explains how context plays a role in communication or dialog between people. In our opinion, he also points out three important issues: universal definition is unlikely, lack of conceptual models, and lack of tools or tool boxes. . He presents three models in his paper; two of them, namely ‘widget model’ and ‘infrastructure model’ are proposed by other researchers, [17] and [18] respectively. The third context management model, called ‘Blackboard model,’ is described by him in his paper. In Flanagan et.al [19], the authors are interested in the recognition of context based on the features of multi dimensional sensed data from different sensors. The authors use a running example. An example of context at the higher order level is “the user is walking in the evening on a busy street and talking to a friend” (on his cell phone). The authors in that paper show how this higher order concept is generated from multiple sensor measurements based on an unsupervised clustering algorithm. The sensors used are an accelerometer, light sensor, temperature sensor; humidity sensor, thermometer, and a microphone (see their Table-1 on page 175). In Korpipää and Mantyjarvi [20], the authors view the term context in a totally different and bottom up perspective. Their research goal is to investigate ontology for sensor based context aware systems. The example quoted in their paper is that the mobile display adjusts the illumination level, font size or the display format based on the context in performing as simple task of displaying the next bus arrival time. The authors also bring out another important issue in studying context, namely the confidence level in the sensing of the context. This is very important when mobile applications automatically adjust their behavior to suit the user needs under the assumption that the ‘sensed context’ is correct. We believe that

Author name / Procedia Computer Science 00 (2012) 000–000

building deployed mobile applications as opposed to lab prototypes should pay more attention to this aspect. In Savio and Braiterman [21], the authors are interested in the notion of context from the stand point of designing mobile user-interactions with mobile devices. In their short paper of three pages, they talk about: Interface (device, connection, and carrier), Task, and User’s Attention category, Goal, Activity, Environment and Culture. They have not gone into characterizing this ‘spheres’ of interactions. From the above brief review of the literature, we summarize the following and in summarizing these points, we have kept in mind, our research goal of ‘Designing Mobile User Interfaces for applications in a Hospital setting”.     

Mobile user interfaces (MUI) design should benefit from the idea of adaptation of the UI with respect to the context. Therefore, we need to develop a formal representation of what context means in our ‘domain’ There will be two categories of adaptations: (a) by the designer adapting the design to the mobile device and (b) the device recognizing the context at run time and adapting certain interface widgets as per the pre-programming. We will employ a two level characterization of the term ‘context’ (Basic level and Domain level) It is known that in the real world hospital settings we have different categories of users and hence some form of user modelling is essential. Both usability and user experience are highly important for a successful transfer of technology (MUI and the mobile application) to the real world

4. A Proposed approach for MUI Development First, briefly let us consider the research related to MUI. Tools like Damask [22] are proposed to simplify the process of designing user interfaces for several platforms but it does not take into account the user categories. Supple system [23] took a different approach treating the interface generation as an optimization problem. It optimized the rendition of the UI widgets under the device’s constraints and minimized the estimated cost of the user activity. SBCA [20] proposes context ontology for mobile devices, and its interface is able to adapt to the user’s current activity. However, SBCA focuses on modeling the sensor level contextual elements such as sound intensity, light intensity, and frequency of users’ movements. MIContext [21] is a context model for mobile interactions. Many contextual elements for mobile interactions are proposed by them to highlight potentially new ways to assist users through mobile devices. Some of the main categories of contextual elements that are taken into consideration include device, communication channel, interface, user tasks, activities, environment and culture. CAMob [24] is a mobile handheld system that is designed for the communication and collaboration between healthcare professionals in the hospital environment and it uses user roles to facilitate the communication and collaboration process. However, contextual elements such as user category and MUI elements not considered. We propose a top down approach in the beginning stages of analysis and development of a context model. In this section we motivate our proposed approach through a running example. Step-1: Establish the goal or sub goal ‘Gij’ of MUI in a suitably bounded domain Di. The simple but non trivial example we have chosen is in the domain of nursing services in a hospital ward. Keeping the hospital domain, we include the user characteristics (through traditional user models - stereotypes) as part of the MUI. The design goal is to develop a MUI for the nursing application (gathering the vital signs) that is adaptable to the user category and to the context of work. Step-2: Conduct a task analysis and develop the set of tasks {Ti} that each role playing will require in the selected domain of application. For example, {Ti} could be: {enter the vital signs one at a time; upload the data; correct any mistakes happened; send a twitter message related to work}.

5

6

Author name / Procedia Computer Science 00 (2012) 000–000

Step-3: The next step is to perform a thorough requirement analysis and gather a set of ‘context descriptors’ denoted as Si that are described in the form of sentences or sentence fragments that will form the basis for MUI adaptations: For example Si could be: {I am in an isolation room; on the way to pick up something; my hands are not free; ambient light is too low; etc}. In general context descriptors can arise from a variety of sources, namely constraints to be satisfied, physical state of an entity being in etc. The user model will also add certain ‘context descriptors’ to the set Si. For example the stereotype Uj may add {I need large sized letters; I do not like to be disturbed when my hands are not free; etc.} Step-4: Based on a clear understanding of the UI architecture, the analyst determines a set of adaptable features, Fi. By the term UI architecture we include such artifacts as, the user interface objects or widgets, the way individual screens are laid out, and the navigation sequence required to accomplish each of the Tasks {Ti}. Step-5: Then, the knowledge required for the MUI to adapt itself at run time or the knowledge required for implementing the adaptations at the design time need to be captured and represented formally. Any suitable knowledge representation method known in the literature can be used for this purpose. Rule based representation is one possibility. Step-6: A user interface is a link between the software system and the human user; and the software is only a tool that is helping a nurse to perform her nursing tasks. Once the nurse gets used to a particular form and behavior of the UI it becomes a routine for her to use the software tool. Any change by way of adaptation in the form or behavior of the MUI is a transitional inconsistency. The MUI designer has to establish the trade off between the benefits and pains that may accrue due to MUI adaptations and enhance the user experience 5. Characterization of the term ‘Context’ Intuitively, context can be defined as any information that describes the relevant entity of a given situation [25]. For the purpose of this section, we characterize the term ‘context’ from the MUI designer’s perspective to implement an adaptable MUI. Let us view a scenario in the nursing application in a hospital ward, that a task is performed by an actor using different objects. Our characterization is based on the concept of separation of concerns. Basic Context (BC) is independent of the actor and the other is a dependent termed Domain Based Context (DBC). The following parameters in (a) are independent from (b): (a) Where it happened (location, L); when it happened (time, M); and the physical environment (environment, E). We define the vector as the basic context. Zero or more of the basic context parameters might be relevant to the set of tasks performed in the domain of application considered. Each of these parameters in the basic context can be characterized by one or more features to a varying level of granularity. For example: the location can be a patient’s room; the patient’s bed; emergency room; a transplant ward, etc. (b) Who is the user (actor, A); what he performs (task performed, T); and with what (object information, O). We define the vector as the domain based context. Each of these parameters in the DBC can be characterized by one or more features. For example: The actor belonging to the user’s stereotype (such as a young nurse, a senior nurse), are characterized because we are interested in adapting the MUI to user stereotypes. The actor is playing a role, for instance, a nurse is playing the role of nursing, but that nursing role may involve several tasks. The task T is obtained from the task model where different methods could exist to perform the same task in different context descriptions. The informational-objectset is the set of data objects, e.g. patient recorded data. In this paper we take one task for one actor and consider that as a domain for discussion. Separating out the basic context from the rest of the context-defining parameters creates the possibility of creating a CIS (see Pascoe [2]) to facilitate sharing the context recognition among multiple applications.

Author name / Procedia Computer Science 00 (2012) 000–000

Let Context be the set of all BC DBC where BC = L M E  Let L be the set of all locations such as a patient’s room; the patient’s bed; emergency room; transplant ward, etc.  Let M be the set of all times such as the time of day, etc.  Let E be the set of environments such as low light, noise, etc. DBC= A T O BC  Let A be the set of all user stereotypes for certain domain  Let T be the set of all tasks performed  Let O be the set of domain objects So Context is defined as a vector of: Our context definition serves to create three service layers (Figure 1) which are: Layer-1: Basic context (In-dependent) Layer-2: What is performed (task performs), and with what (object). Represent the role that the actor plays, the Task, and the Object (dependent) Layer-3: Actor dependent. We separate this into two parts :< > : < inherent to user stereotype, derived from relevant context descriptors> Actor dependent Role & Task & Object Basic Context < L, M, E>

Figure 1 Characterization of Context

Context descriptor Si is an instance of context that allows the MUI to adapt directly based on the run time context recognition. The context descriptors are obtained from requirements analysis stage. Each task {Ti} in the context is defined as tuple (Trigger, Result), where trigger is a request for task completion and result is the expected outcome. Each task can be performed by several methods based on the specific context descriptor. Example: Consider the task of a nurse taking vital signs of a patient and let the nurse belong to stereotype1. The patient is in a room with multiple beds. There are three patients and the other patients are sleeping. The time is 10:00 pm and the light is off. The nurse is taking the vital signs and entering them directly into the patient record through the MUI. Here, the task= “entering the vital sign” can be achieved by several methods: Method 1: If (Actor= nurse belonging to stereotype1& Location= Patient in a single bedroom & Time=10:00am & Light =on) then adapt the MUI by keeping the behaviour of the keyboard click to an ‘on’ state. Method 2: If (Actor= nurse belonging to stereotype1& Location= Patient in a multi- bedroom & Time=10:00 pm & Light =off) then adapt the MUI by changing the behaviour of the keyboard clicks from ‘on’ to ‘off’ state Method 3: If (Actor= nurse belonging to stereotype1& Location= Patient in a single bed & Time=10:00am & Light =on & “the nurse’s hand is busy with the patient”) then adapt the MUI by transforming the text entry mode to a voice entry mode According to the above described context, the condition of Method 2 will be evaluated as True and Method 2 will be chosen corresponding to the performed task of the nurse.

7

8

Author name / Procedia Computer Science 00 (2012) 000–000

Summary A universal definition for the term context will not be viable. Hence, each software engineer has a need to clearly understand and characterize the context and the goal of its development. We introduced a new characterization of ‘context’ for MUI in the health care domain based on separation of concern principles that are relevant to the designer of MUI. The built in adaptations in an MUI can enhance the acceptability of technology in the healthcare domain where diversity is inherent. Architectures and field testable prototypes are currently under development as parts of the on-going doctoral work of the first author.

References 1. 2. 3. 4.

5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

16. 17. 18. 19. 20. 21. 22.

23. 24. 25.

Winograd T. Architectures for context. Human-Computer Interaction. 2001; 16(2):401- 419. Pascoe J. Adding Generic Contextual Capabilities to Wearable Computers. 2nd International Symposium on Wearable Computers 1998; 92-99. Dey AK, Abowd GD. Towards a better understanding of context and context awareness. Proc. CHI 2000 Workshop on the What, Who, where, when and How of Context-Awareness, New York: ACM Press; 2000. Kinkade S, VerclasK. Wireless Technology for Social Change. Washington, DC and Berkshire, UK: UN Foundation– Vodafone Group Foundation Partnership, 2008. Retrieved from http://mobileactive.org/files/MobilizingSocialChange_full.pdf, last accessed on 27/01/2012 Rim Project, Available from < http://132.205.221.4/twiki/bin/view/RIM/WebHome>, last accessed on 5, Feb, 2012. Schilit B, Theimer M. Disseminating Active Map Information to Mobile Hosts. IEEE Network 1994; 8(5): 22-32. Brown P J, Bovey J D, Chen X. Context-Aware Applications: From the Laboratory to the Marketplace. IEEE Personal Communications 1997; 4(5): 58-64. Ryan N, Pascoe J, Morse D. Enhanced Reality Fieldwork: the Context-Aware Archaeological Assistant. Gaffney V, van Leusen M, Exxon S, editors. Computer Applications in Archaeology; 1997. Dey AK. Context-Aware Computing: The CyberDesk Project. AAAI 1998 Spring Symposium on Intelligent Environments, Technical Report SS-98-02 1998; 51-54. Franklin D, Flaschbart J. All Gadget and No Representation Makes Jack a Dull Environment. AAAI 1998 Spring Symposium on Intelligent Environments, Technical Report SS-98-02; 1998: 155-160. Ward A, Jones A, Hopper A. A New Location Technique for the Active Office. IEEE Personal Communications 1997; 4(5):42-47. Rodden T, Cheverst K, Davies K, Dix A. Exploiting Context in HCI Design for Mobile Systems. Workshop on Human Computer Interaction with Mobile Devices 1998. Hull R, Neaves P, Bedford-Roberts J. Towards Situated Computing. 1st International Symposium on Wearable Computers 1997; 146-153. Schilit B, Adams N, Want R. Context-Aware Computing Applications. 1st International Workshop on Mobile Computing Systems and Applications 1994; 85-90. Pascoe J, Rodrigues H, Ariza C. An investigation into a universal context model to support context-aware applications, in On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, Lecture Notes in Computer Science, Springer; 2006; 4278: 1884-1893. Gwizdka J. What's in the context?. Workshop on the What, Who, Where, When, and How of Context-Awareness 2000. Dey AK, Abowd G, Salber D. A conceptual framework and a toolkit for supporting the rapid prototyping of contextaware applications. Human-Computer Interaction 2001;16: 97–166. Hong J I, Landay J A. An infrastructure approach to context-aware computing. Human-Computer Interaction 2000; 16: 287–303. [This special issue]. Flanagan J A, Mintyjarvi J, Himberg J. Unsupervised Clustering of Symbol Strings and Context Recognition, IEEE Conference on Data Mining 2002; 171–178. Korpipää P, Mantyjarvi J. An ontology for mobile device sensor-based context awareness. in Proceedings of the 4th International and Interdisciplinary Conference on Modeling and using Context, Stanford, CA, USA, 2003; p. 451-458. Savio N, Braiterman J. Design sketch: The context of mobile interaction, in Proceedings of International Journal of Mobile Marketing, Singapore: 2007, p. 5-7. Lin J, Landay J. Damask: A tool for early-stage design and prototyping of multi-device user interfaces. In Proceedings of The 8th International Conference on Distributed Multimedia Systems (2002 International Workshop on Visual Computing); 2002, p. 573- 580. Gajos K, Weld D S. Supple: automatically generating user interfaces. In Proceedings of the 9th international conference on Intelligent user interface, Funchal, Madeira, Portugal: ACM Press; 2004, p. 93–100. Muñoz M A, Rodríguez M, Favela J, Martinez-Garcia A I , González V M. Context aware mobile communication in hospitals. Computer 2003; 36: 38-46. Dey AK. Understanding and Using Context. Personal and Ubiquitous Computing. 2001; 5, number 1:4-7.