Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Local health integration networks (LHINs) were created in March 2006 to transform the delivery of healthcare services in Ontario by simplifying the process of healthcare service access when patients move from one service provider to another. The LHINs are mandated to plan, integrate, and fund local health services and are guided by the belief that “a community’s health needs and priorities are best understood by people familiar with the needs of our communities and the people who live there, not from those in offices hundreds of miles awayFootnote 1”. There are 14 LHINs in Ontario and this chapter discusses information systems development initiative in one of the LHINs called Erie St. Clair LHIN (ESC LHIN hereafter) serving the population of over 649,000 people residing in the regions of Chatham-Kent, Sarnia/Lambton, and Windsor/Essex with an annual budget of over $900 million. There are 88 agencies consisting of hospitals, long-term centres, assisted living services, community support services, community care access centres, mental health agencies, addiction agencies, and community health centres, which are funded by the ESC LHIN. The ESC LHIN needs different types of information from these member agencies in a periodic manner in order to implement its healthcare service integration strategy in the region.

An earlier work (Bhandari and Snowdon 2011) suggested service-oriented architecture (SOA) (Fig. 54.1) for managing the seamless flow of data and information between this meta-organisation (i.e. ESC LHIN) and its member agencies, system architects and designers, and clients. Table 54.1 outlines the agencies and their services. In this chapter, we adopt the SOA framework to develop a requirements elicitation model for building a navigation tool for accessing healthcare services available in the region. The remainder of this chapter is organised as follows. Section 2 introduces the current information systems development initiative (ISD). Section 3 summarises various approaches to formulating the process of requirements elicitation based on our literature review. Section 4 discusses our ontology-based model for developing an automated and interactive tool capable of supporting automatic service discovery, automatic service composition, and dynamic composition. Section 5 concludes this chapter.

Fig. 54.1
figure 00541

Service-oriented architecture for the LHIN (Adapted from Bhandari and Snowdon 2011)

Full size image
Table 54.1 LHIN member agencies and their brief service description
Full size table

2 Information Systems Development in ESC LHIN

In order to understand the need for a navigation system for accessing healthcare services available in the region under the mandate of the ESC LHIN, consider the following scenario:

An elderly woman at home becomes ill with a fever. She is unable to eat and only drinks the occasional sip of water. When she gets up in the evening she is very light headed, dizzy and then falls while going to the bathroom. She crawls to the phone and calls her daughter, who dials 911 to get her to the hospital. She arrives in the emergency room and waits several hours to be seen. She has blood tests, a CT scan, a urinalysis and a chest x-ray, and she is found to dehydrated, has a low blood pressure due to poor fluid intake and a mild flu. She did not have any serious injuries as a result of the fall. Social work is consulted for home support for this woman. (Bhandari and Snowdon 2011)

This is a case involving a senior citizen living independently at home and becoming ill who needed primary care services and home support to prevent dehydration, low blood pressure, and subsequent fall. This case illustrates how the inability to access appropriate services (i.e. primary care and supportive services) results in patients ending up at the wrong location (emergency room) for the wrong service. This is a common scenario in Ontario and is one of the primary reasons for overcrowding in emergency rooms. In order to facilitate the access of healthcare services available in the region, the ESC LHIN has embarked on a project called the Integrated Health Service Plan for the period of 2010–2013 with the following five strategic objectives: improved outcomes in alternate level of care, emergency department care, diabetes management, mental health addiction, and rehabilitation care and interventions. This approach is reflective of the trend that organisations are increasingly defining their solutions as services and their interconnections (Sheth et al. 2006). Such an approach is referred to as a service architecture which is considered successful when it closes the information gap among key actors (Jones 2005).

Earlier efforts in making healthcare services accessible include ConnexOntario (http://www.connexontario.ca) and a care coordination programme called Facilitated Access and Coordinated Teamwork (FACT) (Bertoni 2009). However, both of them are limited in the sense that ConnexOntario provides basic information about alcohol and drug, gambling, and mental health services only and the FACT is a noncomputerised, group participation-based review system only. It should be evident from Fig. 54.1 that for a meta-organisation like ESC LHIN, the information system development is a critical undertaking because it involves understanding user requirements for all of its member agencies. In the following section, we provide an overview of prior approaches to requirements elicitation in ISD projects.

3 An Overview of Requirements Elicitation in ISD

Prior studies find that many ISD projects fail because of the poor understanding of user requirements during the requirements elicitation (RE) phase (Mathiassen et al. 2007) resulting in significant costs to organisations (Brown and Rogich 2001). While the importance of RE in ISD is unequivocal among IS scholars, the lack of uniformity in conducting RE is critical. For example, Sommerville (2007) views the RE process as a staged sequence of activities and/or task objectives while others view it as “chaotic and non-linear” (Davidson 2002), non-deterministic (Rolland 1993), and dialectical (Thanasankit 2002). There is also a disagreement between researchers as to whether RE processes should be characterised as normative or nonnormative ones. As normative processes, RE have been described as a multistage process characterised by input-task objective-output (Browne and Ramesh 2002), iterative process typified by evolving knowledge about the system requirements (Hickey and Davis 2004), and knowledge acquisition process (Byrd et al. 1992). While Hickey and Davis (2004) have proposed a unified model of RE by emphasising the role of situational knowledge, the abundance of proposed RE techniques for ISD has created a confusion among systems developers, which Mathiassen et al. (2007) rightly term as a “methodology jungle”.

Given that the ESL LHIN is a meta-organisation mandated to integrate a variety of healthcare services offered by diverse agencies (see Fig. 54.1), the challenge of RE for the navigation project increases exponentially because just one methodology or technique cannot possibly meet all requirements of different organisations (Davis and Hickey 2002; Maiden and Rugg 1996). In order to manage this complexity of RE in the current ISD initiative, we suggest an ontology-based RE model for developing an automated and interactive tool capable of supporting automatic service discovery, automatic service composition, and dynamic composition.

4 Ontology-Based RE Model

Ontology refers to a formal, explicit specification of a shared conceptualisation to represent common knowledge within a domain (Gruber 1993). While the use of ontology in RE can be traced back to the early 1980s (Dobson and Sawyer 2006), it still remains a popular methodology until these days. Kaiya and Saeki (2005) proposed an ontology-based RE model with the objective of identifying incompleteness and inconsistency of requirements artefacts, measuring requirement engineering quality, and forecasting possible future changes.

In the current ISD, we use Semantic Web Service (OWL-S) for automating implementation activities for the SOA framework depicted in Fig. 54.1. OWL-S, as an ontology of services, makes automatic service discovery and composition possible (Martin et al. 2004). Before software with SOA methods can be built, all relevant services must be discovered as the output from the RE process. In OWL-S, an instance of ServiceProfile is used to discover a service with the instantiation of Input, Output, Precondition, and Result, which respectively represent the following: the information required by the service to work, the message returned by the service, the condition required by the service for its proper execution, and the impact of the service execution. Each elicited requirement is associated with an aspect of service discovery along with the functionalities represented with Input, Output, Precondition, and Result.

Our proposed interactive RE process can be divided into two broad stages: (1) machine-directed RE for identifying implicit knowledge (indirect relationships) with reasoning and then performing RE and (2) user-directed RE for customising requirements. The interactive dialogue system is being developed in Java for Windows OS using Eclipse IDE for coding and debugging. Service ontology is being developed with Protégé ontology editor and Pellet for ontology reasoning.

The proposed interactive dialogue system consists of four components: dialogue interface, I/O controller, dialogue manager, and ontology knowledge base. The dialogue interface is a text-based system displaying generated statements such as “Would you like to select the requirement…” to which the user is expected to answer “Yes” or “No”. The user’s response is then passed on to the I/O controller which will attempt to match the input with a set of prespecified information. When no match is found, the user is asked to modify her response. When a match is found, the input is formatted and given to the dialogue manager, thereby knowing the user’s requirement decision currently being elicited. The dialogue manager then consults the ontology knowledge base with the decision and customises the requirements if necessary. Once this process is complete, the dialogue manager generates output which is passed onto the I/O controller. The I/O controller then converts the output in natural language which is displayed in the dialogue interface initiating the next interaction cycle.

In order to understand the proposed ontology-based RE model, let us consider a service ontology for locating a healthcare service (as illustrated in the scenario in Sect. 2). The first task would involve function decomposition. As shown in Fig. 54.2 (adapted from Zhang 2011), Locate a service can be decomposed into two functions: Get reference to a service and Get detailed info of a service. Getting detailed information about a healthcare service may involve either getting information about the service provider (such as hospital or community care access centre) or getting description about the service itself (such as primary care and supportive services for elderly). In order to get the reference to a service, search method is followed resulting in a list of relevant services which the user can select by pointing to it. Sorting of services (in alphabetical order) could also be done to facilitate locating the relevant service from the list. Searching of services can be implemented in two ways: predefined keyword search and advanced search allowing different combinations. For the search involving keyword matching, there are two possibilities: broad match and exact match. Since broad match and exact match exhibit two different levels of search quality constraints, they are considered mutually exclusive (indicated as contradiction in Fig. 54.2).

Fig. 54.2
figure 00542

Instantiation of requirement model for locating a service

Full size image

Requirements elicitation can be performed once the ontology model is instantiated and completed through the interactive dialogue system (as discussed earlier). When the dialogue system encounters a user response that it cannot handle, it asks the user to correct it. When all the functions depicted in Fig. 54.2 are handled by the dialogue manager, the requirements elicitation is considered complete resulting in the generation of output in the OWL-S document format. When services are described in the OWL-S format, they can be discovered by semantic capability matching.

The proposed system, which could be hosted by the ESC LHIN, would be used by both organisations (member agencies) and the general public. The example shown in Fig. 54.2 is intended to illustrate how the public could access and navigate healthcare services available in the region. Descriptions (profiles) of the services in the organisational level can be generated in a similar manner.

5 Conclusion

In this chapter, we discussed ontology-based requirements elicitation model for developing a service navigation system for a meta-organisation such as the ESC LHIN. A major advantage of the proposed model is that it demonstrates the feasibility of conducting automated RE which is critical for a complex ISD initiative such as healthcare service navigation system. Although this chapter discusses a study done in the Canadian health sector, we believe the methodology followed by us is general enough to be of value in other contexts as well. One major limitation of the proposed automated RE model is that it is not applicable to a dynamic environment. Furthermore, the support for customising requirements is inherently limited by the knowledge the machine owns. However, in the future, the proposed model can be extended by improving its expressiveness and domain characteristics. Finally, we conclude by underscoring the significance of eliciting requirements from the public and regional healthcare service providers for developing information systems following software product line engineering approach.