Health information systems are becoming ubiquitous throughout healthcare delivery processes. Governments, enticed by the potential for improved patient care and cost reduction, are pushing for more integrated IT systems in healthcare. However, the successful adoption of these systems depends on the value they create as a service for healthcare professionals and how they support their activities. Following a call for more multidisciplinary research in health information systems and increased end-user participation in HIS development, this study presents a service perspective that considers users of health information systems (HIS) as active partners and co-creators of value, instead of passive recipients of the functionalities brought by these IT systems. From a service perspective we frame healthcare professionals as customers of HIS, and analyze how they can better support healthcare provision. We present an in-depth study of primary care professionals experience with the HIS of the Portuguese National Health Service. Experience was systematized using Customer Experience Modeling, a method that takes into account the holistic nature of experience. Results portray and evaluate HIS according to professionals' experience requirements. They also show a fragmented reality where HIS usefulness is being hampered by integration and performance issues. HIS design guidelines are also posited.

The boundaries between virtual reality and physical reality are becoming ever more blurred as activities in cyber worlds bleed into everyday life and sophisticated software now crosses the line from digital interaction to physical destruction. This paper examines what might be learned from the real-world exploits of the sophisticated software worm known as Stuxnet and from the speculations and extrapolations of fictional counterparts.

In this panel, we propose to figure out how requirements engineering and interaction design can be usefully combined. In particular, some people argue that scenarios/ use cases should be concrete, as in story-telling. Others argue for use of "essential" use cases as a methodological approach to interaction and user-interface design. Somewhat in the middle, it is argued that use cases should help acquiring the requirements in the first place. What should the practitioner believe and, in particular, do, in order to develop useful and usable software and systems? Software development and interaction design require different skills and different methods and are typically done by different people. Still, scenario-based design is proposed for several activities relevant for both tasks, such as requirements elicitation, software design, and interaction design. Symbolic modeling in this spirit is actually common to various fields. However, scenario-based approaches vary, especially with regard to their use, e.g., employing abstract use cases or integrating scenarios with functions and goals in a systematic design process. So, the key issue to be raised at the panel is how to combine different approaches, e.g., in scenario-based development, so that the interaction design as well as the development of the user interface and of the software internally result in an overall useful and useable system.

Usage-centered design is a systematic, model-driven approach to visual and interaction design with an established record of effectiveness in a wide variety of settings and areas of application. The tutorial introduces the models and methods of usage-centered design and explores the integration of usage-centered approaches into software engineering practice. Agile approaches to modeling will be emphasized, with the focus on use cases, which are central to usage-centered design and serve as a common thread throughout an integrated usage-centered software engineering process.

The key to making object technology work isn't technology. So what is it? This panel will cover a lot of the "soft" issues about dealing with people and teams. It's partly about managing software development, and mostly about doing it.

Anthropology is the study of civilization, particularly its societies, customs, structure, and evolution. Our premise is that there are cultureal "chasms" to be crossed to ensure the success of the technological beachhead established by innovators and early adopters of the OO paradigm. Our panelists will address the following questions:•What anthropological cultural factors have to be "matured" (and how?) to foster the success of the OO paradigm?•What mechanisms are required to facilitate communications between cultures of differing maturity?•What cultural chasms must be crossed to develop a successful organization/culture within the framework supported by the object-oriented paradigm (or more perrversely, is there anything "special" about the OO paradigm)?This panel will interest pracitioners as a forum to share and debate experiences related to our current-day software culture metamorphosis.

The commenter acknowledges that the practical criteria provided in the above-titled paper (see ibid., vol.16, no.5, p.537-42, 1990), offer substantive guidelines for designing module interfaces. He points out that the results obtained can be further improved and certain remaining conflicts resolved through consideration of established principles of structured design and software engineering. He illustrates his point with an example involving the specification of a stack interface that requires two or three separate references to replace one. He presents two designs and argues that the first is better. The author refutes the commenter's arguments and argues that the second design is better.>