4.1
Introduction
In this research, we followed a scientific research methodology. The research involved both empirical and constructive studies. The main approach followed an empirical study route. This route investigated the current situation to determine the way forward and then most importantly evaluated the proposed approach to a solution, by interacting with the users, research com- munity, and developers to refine this approach. Part of the research involved a constructive study, which used a software development methodology. This involved designing and building a system using WFMS as a prototype to present the proposed concept for the new approach so that the users could comment on the proposal. Iterative and incremental cycles were followed as we progressed the research. This resulted in continuous revision being conducted as the proposed system evolved.
The nature of this research required an empirical study. This is because the problem was not clearly defined at the start. Moreover, observation was required to fully understand the domain and therefore identify the problems that can be addressed. This meant that research approaches such as conceptual and exploratory were excluded. A conceptual research approach is appropri- ate when some abstract idea or theory is being used to develop a new concept and the objective is to develop a new concept or interpret one and the domain is well understood [69]. While an exploratory research approach is utilised when there is a hypothesis as the basis for the in- vestigation and it is not appropriate when testing and observations are being used [69] and the objective is to explore a little known area [70].
4.2
Research Empirical Study
This research follows a scientific method as it is based on a hypothesis which the research aims to support by evidence [69, 71, 72]. This research is seen as an empirical study because it is mainly based on experience or observations. Observations of the user needs, current system behaviour and usage were made in the initial stage. This was followed by a concentration on the user’s perspective in our approach.
The formal steps of this research were [73]:
• identifying the research problem: to set a defined research problem with aims and object- ives.
• reviewing the literature: to understand the background and research foundations used in the domain.
4.2 Research Empirical Study 27
• specifying the purpose of the research: to set the research hypothesis.
• collecting data: the data needed for the research experiments that will be undertaken needs to be identified and collected.
• analysing and interpreting the data: conducting the experiments and interpreting the find- ings.
• reporting and evaluating the research: to evaluate the outcomes of the experiments and therefore validate the hypothesis and understand its impact.
4.2.1
Identifying the Research Problem
The first stage is identifying the research problem. The problem was at first very broad and needed a lot of focussing by identifying more clearly the objectives. In order to focus the research problem, a literature survey was conducted with interaction with users occurring at appropriate points. This process went into a loop of continuous revision, between the problem, the literature, and user reaction, until a final focused problem emerged.
The initial problem was brought to our attention by the software development team at Velindre NHS Trust. The Velindre CIU team believed that there is lack of communication and coordin- ation support among care team members and that the IT support systems could be altered to give better support for these activities. They then identified the need to support alerts within the current information system. The team also clarified that the inclusion of alerts within Canisc was part of their future plans.
This initial stage was followed by cycles of revisions driven by our increasing understanding of the domain from the literature findings and review of the current status. The key to identifying the research problem in this approach is understanding the causes of the broad problem and the limitations imposed by the domain. Causes of the communication and coordination problem are mainly related to the complexity of the domain and the care process. Limitations on the way forward include the need to keep legacy systems operating to retain an organisation’s current IT systems and these users local autonomy while facilitating access to the medical information in them. It would be unrealistic to assume all the systems could be updated at the same time. This was followed by the identification of the care pathway, as a common base for a care team’s interactions. At this stage, it was decided to use the national clinical guidelines as a mean to understand and identify the different parties involved in the treatment process and their interac- tions. Moreover, it was decided to use the guidelines to identify the stages within the treatment flow requiring team communication and care coordination support, and identifying how these
28 4.2 Research Empirical Study
stages can be supported. The possible requirements identified along the treatment pathway were then linked to the communication and coordination obstacles in the healthcare domain.
4.2.2
Reviewing the Literature
The literature survey was conducted to understand the current status in the healthcare domain. It was an activity aimed at refining the research problem and gaining a greater focus. When the research problem was identified, we did a focused literature survey on the final problem statement to relate our research to other work in the field and justify the decisions made with an awareness of related work.
The literature research approach undertaken started with a general observation of the healthcare system and communication and coordination problems in the healthcare domain (see chapter 5). This was followed by a search with a particular focus on teamwork and the challenges in the delivery of the ICP. This concluded that an ICP reflects a patient-centric flow (see chapter 5). We also looked at legacy systems, their limitations and current approaches being used to tackle these limitations. This confirmed that for some time legacy systems need to be kept while their interfaces evolve to support the requirements of a healthcare team in patient centric treatment. This was consolidated by positioning this research against current national and international health informatics projects (see chapter 6).
As part of gaining a better understanding of the healthcare domain and health informatics, the author had several discussion sessions with the CIU team at Velindre NHS Trust to link the literature with what is actually happening at the hospital and observe practically the way in- formation systems at the hospital are used. This led to the need to investigate the different tools and technologies that can/are used to overcome similar problems. This review was conducted by considering the specifications of the ICP and the need to use existing CISs. This work suggested the use of workflow technology to address the research problem (see chapter 7).
4.2.3
Specifying the Purpose/ Hypothesis
This is the stage resulting from the problem identification (section 4.2.1) and literature review (section 4.2.2). Here after formalising the problem, understanding the domain and the capab- ilities of the suggested tool, we can clearly state the research hypothesis. This is to state the vision of what can be achieved using the suggested tool in the problem domain (as presented in section 3.3).
4.2 Research Empirical Study 29
4.2.4
Collecting the Data
Data collection is also called the research experiment, this is when more thought is put into how the proposed approach can be assessed and evaluated. After stating the hypothesis, an intensive focused literature survey was undertaken to understand the current state of workflow technology, its different engines, and how it operates. This was followed by identifying the specifications of a workflow engine that could support the research problem (see chapter 8). As part of our observation process, of the workflow technology and the different engines imple- menting it, a practical investigation was conducted. This was undertaken by downloading and running several open-source WFMSs to gain practical experience of different types of workflow system. This was an important stage in increasing understanding and helping us to classify the different engines. This resulted in an identification of the specifications of the engines that most suited the problem being addressed (see chapter 8). These engine specifications were identified based on the needs of the users along the ICP. The ICP represents the workflow implemented in the WFMS’s engine.
Another part of the experiment is identifying different sources for the clinical guidelines. It was also found essential to have a specific scenario to be used as an exemplar to drive the research. A breast cancer scenario was selected for use in the demonstration, as the breast cancer scenario represent a good example of interactions in an ICP. This was followed by the identification of the critical stages within the scenario which need support (see section 10.2).
4.2.5
Analysing and Interpreting the Data
This is the stage when a decision is made on how the research can be evaluated to produce evidence to support or reject the hypothesis. Here thought is put into evaluating the proposal approach and what must be done in the evaluation. At this stage a decision was made on implementing a proof of concept prototype to achieve the following:
• Investigate and suggest a practical technique of mapping the ICP to WFMS (see chapters 9 and 10).
• Test the capabilities of the technology, and the support it can give to the scenario being followed as an exemplar (see chapter 11).
• Demonstrate the use of the technology. This will be used in the evaluation to allow users, technology experts, and developers to see what can be achieved (see chapter 12).