Abstract
Healthcare Information Systems (HIS) are essential in the healthcare industry since they manipulate vital information. For example, HIS may keep track of the patient’s medical history, avoiding mistakes with medications, dosages, and treatments. However, the traditional methods for identifying HIS requirements focus on specifying functional requirements for the software. Moreover, system scope should be fully understood by stakeholders, such as healthcare workers and hospital managers, something extremely difficult to achieve in practice. As such, many requirements are incomplete, missing, or not needed, leading to expensive and inadequate HIS. The authors identify requirements for Healthcare Information System using Focus Groups. They evaluate this method with experiments, applying a variety of techniques and having encouraging preliminary results. In particular, they verify that stakeholders can reach consensus on high-level requirements by discussing different perspectives about the system scope. The authors conclude that Focus Groups are really effective.
TopIntroduction
Sauerborn and Lippeveld (Bodart, Lippeveld, & Sauerborn, 2000) state that good management is a prerequisite for increasing efficiency and effectiveness of health services. They also argue that the World Health Organization identified HIS as critical for achieving this goal. In fact, HIS should provide useful information, based on good data, to influence decisions. These information-based decisions will lead to a more effective use of scarce resources and health planning. However, HIS is inadequate in most countries and represent a management obstacle rather than a tool.
Many reasons have been pointed for this inadequacy, including irrelevant information gathered, lack of timely reporting and feedback, poor quality of data or poor use of information. These reasons, as we may see, are strongly related to data collected that is incomplete or inadequate, resulting on useless information. In fact, a well-designed information system starts with functional analysis and identification of information needs (Bodart et al., 2000). This is where we get to the Requirements Engineering field in the domain of HIS.
Requirements are the heart of Information Systems development since the earliest days of computing (Avison & Fitzgerald, 2006; Bodart et al., 2000). The Requirements Engineering process handles with these requirements. It is regarded by many authors as the most important and crucial part of the development process because the process determines how the system will operate (Coughlan & Marcredie, 2002; Davey & Cope, 2008; Zowghi & Coulin, 2005). Nevertheless, problems still exist with requirements (Burg, 1997; Group, 2009; Hossenlopp & Hass, 2007; Nuseibeh & Easterbrook, 2000; Preece, Rogers, & Sharp, 2002), and these problems are considered the major causes for the high failure rate of the projects (Group, 2009).
This chapter focuses on the Requirements Elicitation activity for Healthcare Information Systems (HIS), an activity of the Requirements Engineering process. Because Healthcare Information Systems are social systems of human activity designed to operate in the dynamic context of the Health organization (Avison & Fitzgerald, 2006), they demand the involvement of stakeholders and of the dynamic context of the organization in their development (Avison & Fitzgerald, 2006).
Requirements Elicitation aims to identify requirements through intense communication between stakeholders, such as healthcare workers, hospital managers, and analysts. This communication is complex and error-prone because stakeholders are not always clear when describing what they need and analysts have difficulties understanding business concepts (Al-Rawas & Easterbrook, 1996; Burg, 1997; Maté & Silva, 2005; Nuseibeh & Easterbrook, 2000; Preece et al., 2002). The consequences of errors in this activity become expensive and hard to fix (Kitzinger, 1994). Costs of fixing errors at the requirements stage are around 80-100 times less than if discovered at the development stage (Avison & Fitzgerald, 2006). As a result, the Requirements Elicitation activity is usually accepted as a critical one (Apshvalka, Donina, & Kirikova, 2008; Davey & Cope, 2008; Engelbrektsson, Yesil, & Karlsson, 2000; Geisser & Hildenbrand, 2006).
Key Terms in this Chapter
Requirement: Represents a need that an Information System should fulfill. Requirements can be functional (what the software or component should do, a functionality), non-functional (how the system will do, that is, constraints or qualities) and environmental (imposed constraints such as legal restrictions or standards). This classification can be seen from the user point of view (understandable for stakeholders) or from the system point of view (on a technical and more detailed level).
Web Forum: Also known as message board, this term refers to Web sites that handle discussions of specific topics and issues. Participation is in the form of messages posted on the forum. Messages have a time label, can be anonymous and can require a moderator’s approval.
Requirements Engineering: A process of Information Systems Development (ISD) that involves five activities, that is: identification, analysis, specification, verification and validation of requirements.
Action Research: Research method that contributes with practical actions to the organization and generates knowledge about its context simultaneously. The method has five phases: 1) diagnosis where the problematic situation is studied, 2) Action planning during which alternative actions are analyzed, 3) Action taking when the selected plan of action is applied in practice, 4) evaluation where results are analyzed, and 5) learning in which findings and knowledge are generated. These phases are cyclic until the results are satisfactory.
Requirements Elicitation: An activity of the Requirements Engineering process of development projects that aims at identifying requirements through intense communication between stakeholders and analysts.
Focus Groups: This method is a variation of workshops. The method consists of a meeting involving relevant individuals to a discussion topic. This discussion is controlled by a moderator that holds a moderator guide to guide the discussion around key topics.
Computer Supported Collaborative Work (CSCW): This term, also known as groupware, refers to all the technology (hardware, software and processes) that aims to aid group tasks.