ANWAR Mohammed Jamal

The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) _______________________________

An Integrated Framework for Hospital Appointment Management

Mohammed Jamal Anwar Computer Science with Operational

Research (Industry)

2008/2009

i

Summary

The aim of this project was to design and develop a software prototype which integrates with an

external scheduling component to manage hospital appointments for patients on fixed treatment

pathways and is extendible in the future to include additional functionality. The application has been

designed to be used by hospital receptionists to assist them with scheduling patients.

A software development methodology was determined and followed to ensure the successful

completion of the project. A number of different tools were researched to develop the solution. The

requirements of the system were established which were then used in the development phase.

Following the successful implementation of the system, the application was tested and evaluated for

usability and functionality to see overall how successful the project had been. The final solution

developed met all the minimum requirements and also included some additional features.

The report covers the whole project from start to finish, including the requirements analysis,

background reading, design, implementation, testing and evaluation stages.

ii

Acknowledgements

I would like to thank my project supervisor Dr. Natasha Shakhlevich for her time and support

throughout the project and Alessandra Condotta for taking time to attend project meetings at the

initial stages. Secondly I would like to thank my project assessor Professor Martin Dyer for his

feedback on my mid-project report and progress meeting.

I would like to thank my personal tutor Dr. Sarah Fores for her advice in the final year not only for

the project but also for other modules when things were not going according to plan.

I would like to thank my friends and family who have supported me throughout university and

particularly those who took part in the evaluation of this project.

iii

Table of Contents

Summary .................................................................................................................................................. i

Acknowledgments ................................................................................................................................... ii

Table of Contents ................................................................................................................................... iii

1 Introduction .........................................................................................................................................1

1.1 Problem Definition .........................................................................................................................1

1.2 Aim.................................................................................................................................................2

1.3 Objectives .......................................................................................................................................3

1.3.1 Minimum Requirements ...........................................................................................................3

1.3.1 Enhancements...........................................................................................................................4

1.4 Requirements Analysis...................................................................................................................4

1.4.1 Functional Requirements..........................................................................................................5

1.4.2 Non Functional Requirements..................................................................................................5

1.5 Project Schedule .............................................................................................................................6

2 Background Research .........................................................................................................................7

2.1 Software Engineering Methodologies ............................................................................................7

2.2 Chosen Methodology......................................................................................................................8

2.3 Tools and Applications...................................................................................................................8

2.3.1 Database Management Systems ...............................................................................................8

2.3.2 Programming Environments...................................................................................................10

2.4 Reusable Coding ..........................................................................................................................13

2.5 Usability ......................................................................................................................................14

3 Design ................................................................................................................................................15

3.1 Framework System Architecture ..................................................................................................15

3.2 Graphical User Interface...............................................................................................................18

3.3 Database Design ..........................................................................................................................18

3.3.1 Entity Relationship Diagram ..................................................................................................18

3.3.2 Normalisation .........................................................................................................................19

iv

3.3.3 Data Definition Tables of Normalised Database ....................................................................21

3.4 Summary .....................................................................................................................................24

4 System Implementation ...................................................................................................................25

4.1 Technology Setup ........................................................................................................................25

4.2 Database Implementation ............................................................................................................25

4.2.1 Tables .....................................................................................................................................25

4.2.2 Queries ....................................................................................................................................26

4.3 Data Source Connection ..............................................................................................................26

4.4 Application Implementation .......................................................................................................27

4.4.1 Intraday/Multiday Input...........................................................................................................27

4.4.2 Patient/Nurse Input .................................................................................................................28

4.4.3 Patient Appointment Output ...................................................................................................30

4.4.4 Nurse Schedule Output ...........................................................................................................32

4.4.5 Appointment Archive .............................................................................................................33

4.4.6 CSV Parsing ...........................................................................................................................35

4.4.7 Other Development ................................................................................................................36

5 Testing ................................................................................................................................................39

5.1 Unit Testing .................................................................................................................................39

5.2 Integration Testing .......................................................................................................................40

5.3 Summary ......................................................................................................................................40

6 Evaluation ..........................................................................................................................................41

6.1 Evaluation Criteria .......................................................................................................................41

6.2 Aim and Objectives .....................................................................................................................41

6.3 Usability ......................................................................................................................................43

6.4 CSV Parser ..................................................................................................................................45

6.5 Methodology and Schedule .........................................................................................................46

6.6 Technologies ................................................................................................................................47

6.7 Future Enhancements ...................................................................................................................48

6.5 Evaluation Summary ....................................................................................................................49

References ............................................................................................................................................50

v

Appendix A: Personal Reflection .......................................................................................................53

Appendix B: Project Schedule ............................................................................................................55

Appendix C: MS Access ER Diagram ...............................................................................................57

Appendix D: UML Class for Table Adapter .....................................................................................58

Appendix E: Patient Report Generated ............................................................................................59

Appendix F: Test Plan ........................................................................................................................60

1

1. Introduction

1.1 Problem Definition

There are many medical specialties within the NHS which have a standard pathway for patients to

follow whilst requiring hospital treatment. This could mean a treatment continues for several days or

even several weeks with regular appointments required for patients at fixed intervals. Also the

specific treatment carried out on one of the days may be a standard treatment which requires a

specific duration. For example initially a patient may be given an injection by a nurse and then after

fifteen minutes a nurse may give the patient an examination.

It is a very complex problem scheduling the patients such that they follow their required pathway

(multiday pattern) accurately whilst utilising hospital resources to full potential such as nurses and

doctors. It is imperative to schedule patients in a way in which nurses and doctors can be allocated

systematically to each patient within their normal working hours and also not to have any clashes. It

is also important for the patients to have their treatments in accordance to the prescribed medical

procedures. Figure 1.1 shows an example of a twenty-one day multiday pattern, where a patient is

required to visit hospital on days 1, 10, 15 and 21; on day 10, visit 2 the appointment duration

(intraday pattern) is 3 hours and 45 minutes with 4 actions performed on them which are shown by

the shaded slots.

21 days

Multiday Pattern

Intraday Pattern

Figure 1.1: Multiday and Intraday pattern

15 minute

intervals

Total duration 225

minutes (3h 45m)

2

Currently staff schedule patients using a manual diary with pen and paper [1], however due to the

large number of patients treated there may be clashes where a single nurse is allocated two patients at

the same time and required to perform treatment on multiple patients at the same time, which in

practice is not possible. Also a problem which arises is that patients end up not following their

required medical procedure so for example a treatment which should be completed in twenty-one

days can take twenty-eight days. Also the treatment pattern on a specific day is not always followed

accurately due to limitations of the current booking and resource allocation system. This makes it

very difficult for both staff and patients to follow the timetables whilst conforming to the medical

requirements.

This can be frustrating for the patients as sometimes they have to stay longer at the hospital than they

had anticipated and also for staff as they often have high workloads which they cannot always cope

with. This is a major problem for the receptionists who are responsible for booking patient

appointments, as they have to consider the patients preferences for appointments whilst ensuring there

are sufficient staff on the rota to perform the treatments. Also there are government set targets for the

NHS, which need to be achieved.

An algorithm has been developed by researchers at the University of Leeds to schedule the patients

and allocate nurses to each action slot within an intraday pattern, with the aim of eliminating clashes

and also to fulfil patient requests.

Advancements in information technology have provided methods for capturing and storing

information more effectively and efficiently, whilst allowing for backups to be created in the case of

data corruption. Such information systems can be used to improve time management within

organisations.

1.2 Aim

The aim of the project is to develop a framework which allows management of appointments using

the external scheduling component. The system will have a data model which stores patient, nurse

staff, multiday pattern and intraday pattern data. A prototype system will be developed which inputs,

queries and outputs from the data model. It is the aim of this project to display the results of the

generated schedules and not to actually generate schedules for patients and nurses. The system needs

to integrate with a scheduling component which has been developed by researchers at the University

of Leeds to schedule the appointments. The system should be able to manually modify schedules

generated by the external scheduling program. The setup of the system can be seen in Figure 1.2 on

the following page:

3

The system will be operated by hospital receptionists and other staff to assist them in scheduling

appointments for patients in the near future with respect to staffing resources.

Also an aim of the project is to develop the framework so that it is easy to extend in the future.

1.3 Objectives

In order to satisfy the aim the following objectives need to be achieved:

• Identify an appropriate software engineering methodology

• Research RDBMS’ and develop a data model

• Design and develop an integrated system that queries the data model

• Test and evaluate the system against the requirements

1.3.1 Minimum Requirements

• A prototype of an integrated framework for hospital appointments which can call an

external scheduling component and produce schedules

• A prototype to input and store patient data

• A prototype to input and store nurse data

• A prototype to input and store multiday and intraday patterns

Input

External

Scheduling

Program

Output

Figure 1.2: System setup

Appointment

Management

Framework

4

1.3.2 Enhancements

• A login system to provide security for the application

• View of/Report of nurse roster for any date

• Administrator prototype to add new users

• Administrator prototype to archive appointments and nurse roster

• Drag and drop feature to change times of intraday appointments

Input

Multiday Pattern – This defines the number of days a treatment lasts and on which days a patient is

required to come into the hospital for treatment

Intraday Pattern – This defines the actions within each 15 minute interval on a specific day when a

patient is required to visit the hospital linked to their prescribed multiday pattern

Patient Data

(Primary Input) - Patient ID, Patient Multiday Pattern ID, Appointment Preference, Earliest Start

Date, Latest Start Date

(Additional Input) – Title, Forename, Surname, Address Line 1, Address Line 2, City/Town, Phone

Number, Other Details

Nurse Data

Nurse ID, Experience Level

Working Days – This states the dates on which a nurse is at work

Working Hours – This states the hours a nurse is working on the days they are in work

Output

For each patient date and start time of each multiday appointment and stating which multiday

pathway they are on and which intraday patterns are assigned to their multiday pattern

Schedule for each day for a nurse for six weeks showing which patients they will be attending to and

at what times.

5

1.4 Requirements Analysis

Meetings were held with the researchers who had developed the scheduling program to establish their

requirements for this system. The purpose of this project is not to develop a scheduling system but to

integrate with the external scheduling component to manage hospital appointments; therefore it was

important to gather accurate requirements for this system. There are several techniques available to

capture requirements however in this project only meetings were held as the requirements for the

system were fixed and would not change.

The requirements are split into two sections; functional requirements and non functional

requirements. The following sections state these requirements:

1.4.1 Functional Requirements

• Add and edit patients

• Add and edit nurses

• Add and edit multiday and intraday patterns

• Call the external scheduling program

• Display and print appointments for patients

• Display and print schedules for nurses

• Manually amend appointments

1.4.2 Non Functional Requirements

• System must be easy to use and navigate

• System should have a consistent interface

6

1.5 Project Schedule

Milestone Date

Submit Aim and Minimum

Requirement 24/10/08

Background Reading

Software Development Methodologies

Database Technologies

Programming Languages

Reusable coding practices

19/10/08 – 25/01/09

Methodologies and Project Planning

Analyse and select methodology

Develop a project plan

19/10/08 – 12/12/08

Submit Mid Project Report 12/12/08

January Exam Revision 20/12/08 – 15/01/09

January Exams 08/01/09 – 15/01/09

Collect Marked Mid Project Report 06/01/09

Design and Development of Data

Model

15/01/09 – 31/01/09

Development of Solution

Patient Input

Nurse Input

Patient Appointment Output

Nurse Schedule Output

Data Parser

Administrator Prototype

01/02/09 – 24/03/09

Submit Table of Contents and draft

chapter 13/03/09

Progress Meeting 18/03/09

Testing and Evaluation of Solution 25/03/09 – 10/04/09

Write Report 25/01/09 – 28/04/09

Submit Project Report (Hard Copy) 29/04/09

Submit Report (Electronic Copy) 1/05/09

Table 1.5: Project Schedule

This table highlights the outline of the project with the deadlines highlighted in bold. A detailed

breakdown of the schedule in Gantt charts in Appendix B. Two Gantt charts are included showing the

original schedule and the amended schedule which was actually followed. An amended schedule was

required as some changes were required during the course of the project. The Gantt charts show the

tasks involved and their durations.

7

2. Background Research

2.1 Software Engineering Methodologies

A methodology provides a structured approach to development and thus decreases the chances of

aspects of the project failing, it provides a recommendation of a series of steps to be followed [2].

There are many different types of software development methodologies some of which have been

studied and deployed by the developer in university modules and in external software projects. Some

of these include the waterfall model described as the ‘classical’ model [3], the spiral model, the unified

process and extreme programming. Many of these were designed to replace the waterfall methodology

and introduced an iterative approach. For example the spiral model does this [4], as this was one of the

biggest weaknesses of the now obsolete waterfall methodology. Also a lot of these methodologies are

very generic and are not suitable for every software engineering project; the spiral model is one that is

criticised for its ability to follow strictly. The Rapid Application Development (RAD) methodology

became popular in the early 1990’s ‘due to the perceived deficiencies of the traditional waterfall

approach’ [5]. RAD is designed for projects where the requirements are likely to change however with

this system all the requirements are known so it will not be necessary to refine requirements. An

advantage of RAD is its speed which may be advantageous in this project as time is limited.

Prototyping is a common methodology where the developer quickly builds an initial system from the

requirements. There are two ways of using prototyping; evolutionary prototyping and throw-away

prototyping and it is important to decide in advance which approach to take if using prototyping [6].

After analysing several methodologies in detail it has been decided no single methodology is suitable

for this project. The chosen methodology is explained in the following section.

2.2 Chosen Methodology

It has been decided after reviewing the methodologies that the most appropriate methodology in this

project is the prototyping methodology using an evolutionary prototype, however RAD will be used

within prototyping so that features of the solution can be quickly developed. It has been decided to not

solely use RAD as has been discussed it can lead to errors and prototyping will allow for any errors to

be corrected, by modifying a prototype.

Prototyping works in four main stages; identification of requirements, development of a prototype

system, review of the prototype and revisions and enhancements of the prototype.

8

Prototyping will allow for certain aspects of the solution to be developed, so that even if due to time

constraints the whole system is not fully functional certain aspects of it can be; this will allow for a

valid ‘proof of concept’ before moving on. For example the patient appointments aspect may be

implemented before the nurse schedule module is developed. As all the requirements have been

defined at the beginning user evaluation throughout the project would not be necessary instead the

developer could add additional features until the solution is complete, which is also why ‘throw away’

prototyping has been discarded.

RAD will be used within each phase of development, so the ‘Patient/Nurse Input’ task will be

developed rapidly. Similarly the other aspects will be developed like this and will together form the

overall framework, which will develop as an evolutionary prototype. Each aspect of the system will be

developed using a RAD approach and then modified, this will include the database development, the

input component and the output component. The evolutionary prototype will allow for any bugs to be

corrected during development instead of detecting and correcting them during the testing phase.

2.3 Tools and Applications

2.3.1 Database Management Systems

The system will involve the use of a lot of information, some which will be needed several times and

the most appropriate form of storage of this data is in a database. This will allow data to be saved

from input to the system and retrieved to be used by the system. It is possible to store data in ASCII

text files however this would be an inefficient storage method, as it would require for there to be

many files whereas a database would hold the data centrally and it would be easier to make backups.

As an important aspect of this project is to use an external scheduling module a database would be

ideal to store the schedules generated and to provide input for the scheduling module. In this section

several databases are reviewed for their suitability to this project.

Microsoft Access

Microsoft Access is a very widely used database system, as it is part of the Microsoft Office Suite.

Although it is not free most computers have it installed, which have MS Windows based operating

systems. Therefore it is platform dependent of Windows and would not be appropriate for use on

Linux or Macintosh systems however this would not be an issue as the hospitals have windows based

systems.

One of the reasons Access is so popular is that it has the ability to develop databases, queries and

forms using a GUI, so users are not required to learn VBA or SQL, however it does allow advanced

9

users to modify the SQL. The GUI makes it relatively easy to generate tables and assign primary and

foreign keys. As MS Access is one of the best selling databases it has a lot of support available and

this is likely to remain so in the future [7].

Disadvantages of Access include that it has a data limit of 2GB and also it is not ideal for use on a

network as it can only cope with a limited number of users at one time [7]. However these

disadvantages would not be an issue for this project as the system is likely to be accessed by a single

user at a time and is very unlikely to exceed 2GB in size. There is a possible security risk of an MS

Access database due to it being stored as a single file if un-trusted sources gain access to the folder it

is contained in [8] but with this project only requiring a local database this will not be an issue.

MS SQL Server

SQL Server has also been developed by Microsoft and it is their more expensive but more robust

alternative to MS Access. MS SQL Server is more commonly used by businesses for small to

medium sized databases. MS SQL Server is a powerful database with a lot of functionality and it also

has built in security features. There are free ‘express versions’ of MS SQL Server that can be

downloaded for free, however these versions offer less in functionality [9]. MS SQL Server utilises

Transact-SQL as its primary query language.

MS SQL Server allows procedures to be stored within the database similar to MS Access queries.

This reduces network traffic as only variables are sent to the database along with the corresponding

procedure to be used and not entire queries. This is particularly useful for queries which will be used

regularly. This is also a benefit for the security of the system as it does not allow SQL injection

attacks [10], however due to the database in this project being stored locally SQL injection attacks

will not be an issue.

Similar to MS Access, MS SQL Server only works on Windows based systems which may be

restrictive for users. A major disadvantage of MS SQL Server is that it is very expensive and hospital

departments may not be willing to pay such amounts for a licence.

MySQL

MySQL is free open source relational database management system. MySQL is the most popular

open source database due to its high performance [11]. It is compatible with many operating systems

including Windows, Linux and Mac allowing users to customise it to their needs. It can also handle

large amounts of data and provides security through user authorisation and access privileges [12].

MySQL was initially designed for use on the Internet and is highly popular, however it is also gaining

popularity for non web based applications due to its high performance and functionality. Database

10

design is also relatively simple in MySQL, which may be an advantage in this project as more time

could be spent on designing and developing the actual application.

A downside of MySQL is that it is not ideal if you require foreign key references [13], which for this

project will be required, for example when storing nurses working days and hours.

PostgreSQL

PostgreSQL is also an open source RDBMS, it is a platform independent database management

system similar to MySQL however it provides more features such as triggers. However if all the

features were implemented PostgreSQL performance is effected and MySQL would run faster.

PostgreSQL has been used in many high profile applications such as Skype and Hi5.com. Database

design is said to be more complex in PostgreSQL than in MySQL [13].

Performance of PostgreSQL is relatively slow [13], which could be a disadvantage in this project if

performance is seriously affected, as it would slow down appointment allocations and entering

working patterns.

Chosen Database Management System

It has been decided to discard MS SQL Server due to its high purchase cost which would be

unsuitable for a hospital. PostgreSQL includes many features which are not required for this project

so would not be suitable. MySQL is very similar to PostgreSQL and has also been discarded. It has

been decided to use MS Access as the platform for the database as it offers many advantages in this

project. As Microsoft Access is part of Microsoft Office hospital receptionists will have experience of

using it, which would be a major advantage and it also has a lot of support available, which is not

always the case with other database packages. The developer has experience of using Microsoft

Access from the recent placement year. The hospital may also already have some data stored and MS

Access has the facility to append current data into a database.

In the unlikely event of the size of the database exceeding 2GB additional databases can be created

with linked tables to the main database enabling the data to be accessed from a single database only.

Queries can also be created from a GUI which includes creation of queries with JOINS. This could be

a benefit for hospital staff if they wished to extend the system, they would not be required to know or

learn SQL. Also graphical interfaces can be created using Access, this may be useful if an

‘Administrator’ was required to manage the data. As MS Access databases are saved as a single file,

this will allow for an administrator to create backups easily, which is very important for a hospital

11

database in the event of data corruption. Extending an Access database in the future would also be

relatively easy.

2.3.2 Programming Environments

A suitable programming environment needs to be selected for system development. The chosen

language should be capable of developing a graphical user interface to display suitable output to an

end user who in this project would be a hospital receptionist. It has been decided that MS Access will

be used to store the data so the language must be able to retrieve and write data to a Microsoft Access

database.

The chosen language should include support for object-oriented implementations. Booch (1998)

stated ‘Each object can be viewed as an independent little machine with a distinct role or

responsibility’ [14]. As the system will comprise of several components implementing via an object

oriented language would allow for more efficient data parsing through each component. Developing

using a high level object-oriented language enables more flexibility making more complex

programming simpler than coding in low level languages. This would fulfil the extensibility

requirement of the framework making it easier to adapt and modify in the future.

There are many programming languages available which meet these criteria. Some of these are

analysed in more detail.

Java

Java is an object oriented programming language that has been developed by Sun Microsystems [15]

and is a popular high-level language. It has been studied by the developer during the first two years of

university. As Java is a very popular language it can run on many platforms including Windows and

Linux. Java has many additional libraries available for it, which may be advantageous in this project.

Integrated Development Environments are available for Java which include Eclipse and Netbeans,

which make compiling of code easier. A JDBC for Microsoft Access is available so integrating a Java

program with Access would be possible.

However a disadvantage of Java is that it is slower and more memory consuming compared to its

fellow languages. Java can require a lot of code to be written and more complex code compared with

other languages such as Python, which could mean this project falls behind schedule as it has strict

time constraints.

12

Python

Python is also an object oriented language which has been studied by the developer during the course;

however experience of this language is more limited than Java. Python is described as a ‘portable,

interpreted, object-oriented programming language’ [16]. Python is developed in the C

programming language; it is classed as an interpretive language meaning no compilation is required

to take place. An advantage of Python is that less code has to be written than Java to achieve the same

functionality and it also utilises simpler syntax than Java hence systems development is generally

quicker which would be an advantage in this project.

In this project GUIs will be required for the application however with the basic Python package there

is no default GUI framework so an external framework would have to be integrated into the system

such as PyGtk or WxPython.

VB 9.0

VB is also an object oriented programming language developed by Microsoft. Application can be

developed in VB using Microsoft Visual Studio. The latest version of Visual Studio is Microsoft

Visual Studio 2008 used by many developers. Visual Basic 2008 (VB 9.0) is described as ‘the most

mature version yet of the most popular programming language for building Windows and web

applications’ [17], which would be a major advantage to fulfil the extendibility requirement of the

project as it is likely to maintain its strong support network in the future. Another advantage of using

VB with Visual Studio is that it incorporates a visual editor which allows for graphical user interfaces

to be created using a ‘drag and drop’ feature. This would allow for the interfaces to be created

relatively quickly, which would fit in well with the RAD aspect of the methodology chosen for the

project. Microsoft Visual Studio also includes an advanced ‘debugger’ which would make bug

detection and correction simple. VB would also be able to query the Microsoft Access database that

will be used to store data. A very wide range of libraries are available for VB, which could be useful

not only in this project but also for any future extensions to it. A disadvantage of using VB is that the

developer has no experience of using Microsoft Visual Studio however has limited experience of

using VBA with Microsoft Excel and Microsoft Access.

Chosen Programming Environment

Java and Python both offer the advantage that they have been studied by the developer previously in

University modules however experience with Python is much more limited so it has been discarded.

Java can require a lot of code to be written which could seriously affect progress, so it has also been

discarded. Microsoft VB has been chosen as the programming language for this project as it fits in

well with the RAD and prototyping methodology chosen in creation of the GUIs, as the code for the

GUIs is automatically generated reducing the amount of code that will have to be manually written.

13

VB offers support for integration with MS Access via the Microsoft Access Object Library and the

Interop.Access assembly. As VB is integrated into Microsoft Visual Studio it means that any

extensibility to this project in the future would not limit the developer to VB, as it also includes

support for C# and Visual C++. As a key aspect of this project is extendibility in the future the

creation of new graphical user interfaces is very simple and can be done relatively quickly. A web

based application in the future for patients could also be developed based on the existing framework

using Microsoft’s ASP.net technology. Support is also very strong for MS Visual Studio and VB

based projects both in the form of published literature and also online communities such as the

Microsoft Developer Network [18], which may be very assistive in this project.

2.4 Reusable Coding

Reusable code is described as code that can be used again without modification [19]. This technique

is commonly used by programmers as it can reduce time by eliminating redundant work. One of the

objectives of this project is to develop a software framework which is easy to extend in the future thus

the code written for it should be easily reusable.

Microsoft Corporations .NET framework will be used to support development, as this will help to

reduce the expenses associated with software development such as database access and code structure

as functions are pre-coded. Use of such a framework promotes the re-use of code in accordance with

the Don’t Repeat Yourself (DRY) process [20].

Software libraries are collections of classes used to develop software and are an example of code

reuse. Modern object-oriented programming languages including VB have large libraries. VB 9.0 has

a very widely used GUI library which will be used in this project and can also be used in future

extensions and adaptations to the system. VB 9.0 programs can also utilise the Windows API using

external functions. There are also many libraries available for VB 9.0 which allow applications

written in VB to interact with other external software packages; one that will be used in this project is

the Interop.Access library to interact with the MS Access database, however in the future additional

libraries may be used or developed for other software packages.

‘Separation of concerns’ (SoC) is a technique used to make software more easily reusable. It is the

process of separating a computer program into different features (concerns) that have minimal

overlap. ‘Separation of concerns’ is described in an academic research paper as ‘a general problem-

solving idiom that enables us to break the complexity of a problem into loosely-coupled, easier to

solve, subproblems’ [21]. A good technique for creating separation of concerns is to use distinct

logical layers in the code [22], where each layer is concerned with a single aspect of the application.

14

A layered design will be used for the application following the principles of ‘separation of concerns’.

There will be a distinct layer for the user interfaces which will be developed using the .NET

frameworks GUI designer, which will separate the graphical interfaces (presentation) from the classes

(content). Also the database will be separate from the main application allowing for it to be extended

in the future, whilst the main application can also be extended. This follows the principle of the

Model-View-Controller (MVC) architecture, which separates content from presentation. This will

enable appointments and other data stored in the database to be viewed from multiple views in the

future. By using a layered design any future enhancements to the application could be done more

efficiently by only modifying the necessary layers.

2.5 Usability

As this system will be used by hospital receptionists usability is very important. The users should be

able to operate the application easily. If the system is difficult to use the users may become reluctant

to use it, which would result in a waste of resources. GOMS is an acronym which stands for Goals,

Operators, Methods and Selection. This model composes of the Goals, which is what the user wants

to achieve, Operators, which is the actions a user needs to take to achieve the goal, Methods are the

different ways to achieve the goal and Selection is the chosen method [23]. GOMS is effective at

deciding how users perform specific tasks, allowing the developer to create an application which does

not require the user to alter the way they use a computer, therefore creating a simple to use and adjust

to application.

15

3. Design

The proposed solution has two main components which need to be designed and combined together to

form the end solution. The first part of this section is about the design of the main application

architecture and the second part is the design of the data model which will store the data.

3.1 Framework System Architecture

In this section the overall architecture of the proposed system is designed. It shows the different

components of the system and the links between them. The application is split into four components;

the main application that users interact with, the database storing the data, the CSV parser and the

external scheduling component responsible for generating schedules. As explained in Section 1 the

scheduling component has already been developed and is only included in the design to show how it

links to the application in this project.

A data transfer method is required to send and receive schedules from the external scheduling

component. There are a number of ways in which this can be achieved including allowing the

scheduling component direct read and write access to the database. Other methods for storing and

transferring tabular data include the CSV and XML file data structures.

A CSV (Comma-Separated Values) parser will act as a barrier between the database and the external

scheduling component to stop the schedule generator from directly accessing the database. This will

aim to reduce the likelihood of data corruption. The CSV parser will be controlled from the main

application.

It has been decided to use CSV files which have a flat-file structure unlike XML, as transferring and

processing flat-file structures is relatively quick compared to XML [24] due to there being no

metadata which there is with XML. CSV parsing is also supported by VB, the development language

in this project. As CSV files have a flat-file structure it will be possible to extract them directly from

the database tables and append them in without any data manipulation required which will ensure

performance of the system is not affected.

16

Request

Receive Response

An overview of the system is presented in Figure 3.1 above. Server components have not been shown

due to it being possible to store the Database, Main Application and Schedule Generator on separate

servers if required, demonstrating the extensibility of the framework. To access the data from the

database users make requests from the main application via the user interfaces and then the database

is queried and the results are displayed on a GUI on the main application.

A user will be able to trigger the CSV parser and the schedule generator from the main application. A

user will be able to select which data they want to extract from the database in a CSV file to send to

the schedule generator. This may be updated multiday patterns or if they require a schedule to be

generated for new patient(s) then they would extract the patient data and future schedule data and

send it to the schedule generator. The future schedule will also be sent so that the schedule generator

does not generate a schedule for a patient that clashes with the existing schedule.

Once the CSV files have been sent the user will trigger the schedule generator from the main

application. The schedule generator will then read the data in the CSV files which have been sent to

it, generate schedules for the required patients and write them in two CSV files in the same format as

the structures of the appointment tables (Section 3.3.3). The user will then trigger the CSV parser to

append the data from the CSV files to the appointment tables defined in Section 3.3.3.

The application (excluding the scheduling component) will be developed using a three tiered layered

design based on the ‘Separation of Concerns’ process, described in Section 2.4. The underlying layer

of the system will be the data layer above which will be the application access layer which will then

have above it the presentation layer. The database will be developed initially and then the data access

sub layer will be developed. The presentation layer and the application layers will be developed in

parallel to create the functionalities required. Figure 3.1.1 on the following page shows an

architecture diagram of the application layered into three tiers; the data layer, the application layer

and the presentation layer.

Figure 3.1 Proposed System Architecture

Main

Application

Write

Read

Database

Trigger

Send Extract

Append

Trigger

Users

17

The presentation layer will contain the graphical user interfaces and user controls and the code behind

them. This will enable a developer to make changes to the interfaces without manually needing to

modify the code as it will be automatically changed to correspond to the new interfaces. This

separates the interfaces from the .vb class files, which control the functionality of the controls placed

on the interfaces.

The application layer will contain all the code behind the interfaces required for the functionality of

the framework. This will include the code to extract CSV files from the database and append

schedules in and also the code to trigger the scheduling component. The data access layer will be a

sub layer of the application layer which is responsible for accessing data stored in the database.

The data layer will manage the physical storage of the data and its retrieval. It will contain the tables

which define the physical storage of the data in the database. This layer will also include queries,

which are recognised as stored procedures and views to retrieve data. These will allow a user to

manipulate the data as it is entered into the database and extracted from the database, so that if in

future the structure of the database tables is changed, the stored procedures can remain in the same

format hence not requiring a developer to make changes in the application layer.

Using this layered design will reduce the impact of changes to the framework in the future, as a

developer would only have to make changes to the necessary layers.

Figure 3.1.1 Three tier architecture diagram

18

3.2 Graphical User Interface

The visual editor in Microsoft Visual Studio 2008 will be used to develop the interfaces (presentation

layer) for the application. This will offer a swift and easy solution as the .NET framework API for

producing GUIs called System.Windows.Forms features a rich library of components. A consistent

layout will be used for the application to achieve good usability, as functionality and usability are the

most important issues in designing the system. The interfaces will be self explanatory and easy to use.

The standard colour scheme of WinForms will be used for all the interfaces, as it will ensure

consistency is maintained throughout the application.

3.3 Database Design

As it has been discussed before the data for this application, such as patient data, will be stored in an

MS Access database. MS Access (database layer) is easily integrated with VB and Visual Studio

(data access layer). MS Access allows for the creation of entities in a graphical user interface and also

for relationships between the entities to be defined using a graphical relationship tool. An entity

relationship diagram consists of three key elements: entities, attributes and relationships.

3.3.1 Entity Relationship Diagram

An entity is defined as something ‘in the real world with an independent existence’ [25], which can

be something physical or conceptual. An attribute however has ‘properties that describe the entities

characteristics’ [25], for example the properties for the entity Patient could be Forename, Surname,

House Number and Postcode. Finally, entities can be associated with each other via certain types of

relationships. These relationships are split into three types; one-to-one, one-to-many and many-to-

many.

A one-to-one relationship is where a single entity is related only to one other entity, for example no

patient has more than one NHS patient number and no NHS patient number is used by more than one

person. A one-to-many relationship is where a single entity is related to many instances of another

entity, for example a multiday pattern may be prescribed to many patients. Lastly a many-to-many

relationship is where many instances of an entity are related to many instances of another entity, for

example a multiday pattern can be prescribed to more than one person and those people could have

more than one multiday pattern.

19

3.3.2 Normalisation

‘A process of changing a database design to produce table schemes in normal form is called

normalisation’ [26]. By using normalisation to design the database it will ensure data is not

duplicated in the database. This will keep the amount of space the database consumes to a minimum.

The process of normalisation allows databases to be more easily maintained [27], which is very

important in this project. The database for this project will be normalised to third normal form.

Definitions of the first three normal forms are stated below taken from [26]:

First normal form (1NF) sets the very basic rules for an organised database:

• Eliminate duplicative columns from the same table.

• Create separate tables for each group of related data and identify each row with a unique

column or set of columns (the primary key).

Second normal form (2NF) further addresses the concept of removing duplicative data:

• Meet all the requirements of the first normal form.

• Remove subsets of data that apply to multiple rows of a table and place them in separate

tables.

• Create relationships between these new tables and their predecessors through the use of

foreign keys.

Third normal form (3NF) goes one large step further:

• Meet all the requirements of the second normal form.

• Remove columns that are not dependent upon the primary key.

The normalisation process for this project can be seen below.

Original Data Structure

Primary keys are underlined and foreign keys are tagged with an asterisk*.

tblMultiday (PatternName, TotalNumberOfDays, NumberOfVisits, MultidayDay,

IntradayPatternID*, Valid)

tblIntraday (IntradayPatternID, PatternName, TotalNumberOfSlots, NumberOfActions,

SlotNumber, TreatmentName)

tblPatient (PatientID, MultidayPatternID, AppointmentPreference, EarliestStartDate,

LatestStartDate, Title, Forename, Surname, AddressLine1, AddressLine2, Town/City, Postcode,

PhoneNumber, OtherDetails, ScheduleGenerated)

tblNurse (NurseID, Forename, Surname, Experience, TelephoneNumber)

20

tblNurseRoster (Date, NurseID*, StartTime, EndTime)

tblAppointment (Date, PatientID*, StartTime, MultidayPatternID, MultidayDay, IntradayPatternID,

SlotNumber, TreatmentName, NurseID*)

Step1 – Eliminate repeating groups

Repeating groups can be seen in the data structure above. For example the field PatternName is

duplicated several times in the table tblMultiday for every visit in the multiday pattern. Also this table

does not have a primary key. To resolve these issues the following changes were made:

tblMultiday (MultidayPatternID, PatternName, TotalNumberOfDays, NumberOfVisits, Valid)

tblMultidayVisit (MultidayPatternID*, MultidayDay, IntradayPatternID*)

tblIntraday (IntradayPatternID, PatternName, TotalNumberOfSlots, NumberOfActions)

tblIntradayAction (IntradayPatternID*, SlotNumber, TreatmentName)

tblPatient (PatientID, MultidayPatternID, AppointmentPreference, EarliestStartDate,

LatestStartDate, Title, Forename, Surname, AddressLine1, AddressLine2, Town/City, Postcode,

PhoneNumber, OtherDetails, ScheduleGenerated)

tblNurse (NurseID, Forename, Surname, Experience, TelephoneNumber)

tblNurseRoster (Date, NurseID*, StartTime, EndTime)

tblAppointmentMultiday (AppointmentID, Date, PatientID*, MultidayPatternID, MultidayDay,

IntradayPatternID)

tblAppointmentIntraday (AppointmentID*, StartTime, SlotNumber, TreatmentName, NurseID*)

The above data structure is now in First Normal Form (1NF)

Step 2 – Remove partial dependencies

This step ensures all attributes depend on the primary key and are linked through the use of foreign

keys. Following the changes made in step 1, this data structure does not have any partial

dependencies and is therefore in Second Normal Form (2NF).

Step 3 – Remove non primary key dependent fields

This step removes attributes that are non key dependent on other attributes that are also non key.

Following the changes made in step 1 this data structure does not have any non primary key

dependent fields and is therefore in Third Normal Form (3NF).

21

De-normalisation

De-normalisation is a technique used to improve database performance. In this database the fields

‘Treatment Name’ and ‘NurseID’ have been included in the table tblAppointmentIntraday, which is

redundant data as ‘Treatment Name’ is in the table tblIntradayAction, however they have been

included to speed up access when viewing appointments avoiding queries with JOINS. Currently only

one nurse performs the treatment for each slot to a patient in an intraday appointment meaning it

would be better to place NurseID in the table tblAppointmentMultiday however in the future different

nurses may perform different action slots in an intraday pattern so it has been included in the table

tblAppointmentIntraday. The fields have also been included as the receptionist may wish to modify

intraday appointments by actually changing the intraday pattern for a specific appointment, so the

final action slot could be delayed, where it is not essential that an intraday pattern is followed totally

accurately.

Below is the final database schema along with the entity attributes.

3.3.3 Data Definition Tables of Normalised Database

tblPatient

Attribute Name Data Type Description

PatientID Text Primary Key

MultidayPatternID Text Foreign Key

AppointmentPreference Text Appointment time preference

EarliestStartDate Date/Time Patients earliest available date

LatestStartDate Date/Time Patients latest available date

Title Text Title of patient

Forename Text Patients forename

Surname Text Patients surname

AddressLine1 Text Patients address

AddressLine2 Text Patients address

Town/City Text Patients town/city

PostCode Text Patients postcode

PhoneNumber Number Patients phone number

OtherDetails Text Patients other detail

ScheduleGenerated Boolean (Yes/No) Patient has a schedule

22

tblMultiday


MultidayPatternID Text Primary Key

PatternName Text Name of multiday pattern

TotalNumberOfDays Number Total length of pattern in days

NumberOfVisits Number Number of visits required

Valid Boolean (Yes/No) Pattern valid or not

tblMultidayVisit


MultidayPatternID Text Foreign Key

MultidayDay Number Visit number

IntradayPatternID Text Foreign Key

tblIntraday


IntradayPatternID Text Primary Key

PatternName Text Name of intraday pattern

TotalNumberOfSlots Number Number of slots in pattern

NumberOfActions Number Number of actions required

Valid Boolean (Yes/No) Pattern valid or not

NB The duration of each slot is not defined in the database. It is controlled from the main application

allowing for it to be modified in the future without requiring amendment to the data model

tblIntradayAction


IntradayPatternID Text Foreign Key

SlotNumber Number Slot number

TreatmentName Text Name of treatment

tblNurse


NurseID Text Primary Key

Forename Text Nurse forename

Surname Text Nurse surname

23

Experience Number Experience level of nurse

TelephoneNumber Text Nurse telephone number

NB The experience level of each nurse is set as a number field so that it can be easily extended in the

future where 0 is the lowest level possible and n is the highest level possible

tblNurseRoster


Date Date/Time Date on roster

NurseID Text Foreign Key

StartTime Date/Time Shift start time

EndTime Date/Time Shift end time

tblAppointmentMultiday


AppointmentID Text Primary Key

Date Date/Time Date of appointment

PatientID Text Foreign Key

MultidayPatternID Text Patients multiday pattern

MultidayDay Number Patients visit day

IntradayPatternID Text Patients intraday pattern

tblAppointmentIntraday


AppointmentID Text Foreign Key

StartTime Date/Time Start Time of action

SlotNumber Number Intraday slot number

Treatment Name Text Name of treatment

NurseID Text Foreign Key

tblUser (Additional Table)


Username Text Primary Key

Password Text Users password

Forename Text Users forename

Surname Text Users surname

24

Figure 3.3 below is an E-R diagram showing the relationships between the key tables.

Figure 3.3 An entity relationship diagram showing the key tables for the proposed database

3.4 Summary

In this chapter the overall framework has been designed and this design will be implemented in the

next stage of the project. The design stage included designing the application architecture and the data

model. These plans will be followed in the implementation, however if changes are required these can

be made as the methodology is flexible and allows stages to be re visited.

M

1 1 M tblPatient

1

M

M

1

1

M

M

1

1

M

M

tblIntradayAction

tblAppointmentIntraday

day

tblNurseRoster

tblNurse

tblIntraday

tblMultidayVisit

tblMultiday

1

tblAppointmentMultiday

25

4. System Implementation

This chapter will look at the implementation of the system including the database and the main

application. The database was created first followed by the main application which was integrated

with the database. This section highlights the main features of the system and how they were

implemented. Some screenshots and snippets of code have been used to document the development.

4.1 Technology Setup

Before the implementation could begin the machine had to be setup with the necessary software. As

development was done using MS Access and MS Visual Studio all development was done on the

developer’s laptop using Microsoft Windows Vista because no Windows machines are available in

the school of computing. Microsoft Access was already installed on the machine which required only

Microsoft Visual Studio 2008 to be installed. MS Visual Studio was configured as having VB 9.0 as

the default development setting; this was done by following a tutorial in [28]. The visual editor in

Visual Studio provider a WYSIWYG (what you see is what you get) feature to develop the GUIs,

which can be modified in the future and additional GUIs added in extensions to the system using the

editor without any coding required. This feature was used by inheriting the System.Windows.Forms

class library. It was discussed in the requirements section usability is important in this system as it

will be used mainly by hospital receptionists therefore several HCI techniques were used. These

included developing simple and consistent interfaces and using dropdown menus where appropriate

to simplify use. For selecting fields and buttons a tab index was used so a user was not limited to

using the mouse to make a selection and could use the keyboard if they prefer.

4.2 Database Implementation

4.2.1 Tables

The database tables were implemented in the Microsoft Access database following the schema in the

design chapter, Section 3.3.3. Initially only the required tables to meet the minimum requirements

were implemented however tblUser was also added as it was necessary for the login function of the

main application. In total ten tables were created. All the tables were created using the ‘design’

feature of MS Access from which the properties of each field were also set. The ‘Text’ data type was

used for most of the fields, however character limits were set appropriately. For example a maximum

length of 20 was set for forename as single names are unlikely to go over 20 characters, however for

patient ‘Other Details’ a memo type was used. Primary keys such as Patient ID and Nurse ID were set

26

as text field as a patients NHS number may be used for this which comprises of text characters and

numeric characters. A Boolean yes/no field was used to mark patterns as valid or not and also for

whether or not a schedule has been generated for a patient, this provided an efficient way for marking

patterns as valid or not as it only requires 1 bit of storage capacity. Finally the relationship links

between the tables were created using foreign keys as specified in Section 3.3.3. The entity

relationship diagram can be seen in Appendix D.

4.2.2 Queries

Once the tables had been created queries were created in the MS Access database. It was decided to

store the queries at the database end, as they would be recognised by the main application as ‘Stored

Procedures’ and ‘Stored Functions’ which could be remotely called and passed parameters. This

would increase the performance of the system as entire queries would not have to be sent to the

database and then the results sent back, instead only parameters could be sent and then the result

would be sent back. A common parameter used in this application was to filter results based on the

date, so a placeholder [Enter date dd/mm/yyyy] would be used as the criteria box in the field; this

would prompt the user to enter this parameter whenever the query is called. Using this approach

allows further queries to be created in the future which can be called by reusing the current VB code

and simply passing in a new query name. A range of queries had to be created which included queries

to display the staff rota for any day and also the actual schedules for the patients.

4.3 Data Source Connection

It was realised that the database would have to be used several times in various screens and methods

and this would require a connection to the database. In order to increase efficiency and avoid having

to rewrite the same database connection string in several places the database connection string was

included in the app.config file. This file is a configuration management file that holds the global

configuration settings [29] so that they can be used anywhere in the application. If any changes to this

string are required in the future during any extensions to the system instead of changing the code

everywhere in the application where it is used it would only have to be changed here. This snippet of

code from the app.config file can be seen in Figure 4.3 on the following page:

27

The System.Configuration reference was imported to the project settings, which enabled the

connection to be referenced from anywhere in the code using MySettings.ConnectionString

The input and output to and from the system was done using .NET ‘Table Adapters’ which provide

communication between an application and a database. They allow for data to be retrieved from a

database and also for it to be written to a database. The UML class diagram for TableAdapterManager

can be seen in Appendix E. The .vb class files can then access the data via the ‘Table Adapters’. This

covers the ‘data access layer’ and can be modified and extended easily in future development.

4.4 Application Implementation

4.4.1 Intraday/Multiday Pattern Input

The development of the patterns was done in two stages. In the first stage a user enters the basic

information for the pattern. For example in a new multiday pattern they would enter its ID, Pattern

Name, Total Number of Days and the Number of Visits it requires, the pattern then gets saved into

the database and then in the second stage the user enters data for each visit day of the multiday

pathway. It is essential that the pattern is saved before the visit days are added as Multiday Pattern ID

is a foreign key in tblMultidayVisit. If records are added to tblMultidayVisit when no corresponding

MultidayPatternID exists in tblMultiday it will cause referential integrity to be violated in the

database resulting in a System.Input error.

To ensure the multiday pattern is saved first additional code was added to the ‘Add Visit Days’ button

preceding the code to open the interface where the visit days are actually added. On the next page in

Figure 4.4.1 the button can be seen with the additional code to save the pattern in tblMultiday before

records can be added to tblMultidayVisit.

<connectionStrings>

<add name="NHSApp.My.MySettings.NHSDatabaseConnectionString"

connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data

Source=|DataDirectory|\NHSDatabase.mdb"

providerName="System.Data.OleDb" />

</connectionStrings>

Figure 4.3 Connection String in app.config File

28

The same approach was used when editing patterns and adding Intraday patterns and their actions for

the slots in a treatment as this data was also separated into two tables linked via a foreign key, as

shown in Figure 3.3 in the design section of the report. A data grid view was used for editing the

patterns so that when entering visit days and action slots the user can view all the visit days and action

slots that have already been entered to avoid entering a duplicate record.

For editing patterns two parameter queries were created to filter the results only to the pattern the user

wants to edit. The first query was based on using the pattern ID in the WHERE clause. The ID query

for multiday patterns can be seen below:

SELECT MultidayPatternID, PatternName, TotalNumberOfDays, NumberOfVisits, Valid

FROM tblMultiday

WHERE (MultidayPatternID LIKE ?)

The second query for both multiday and intraday patterns was based on their names. This query was a

wildcard query as the user may not spell the pattern name accurately or know its ID and only knows

how it starts. For example a user may enter ‘In’ and all patterns with names starting with ‘In’ would

appear and the user can select the one they wish to edit. The pattern name query for intraday patterns

can be seen below:

SELECT IntradayPatternID, PatternName, TotalNumberOfSlots, NumberOfActions, Valid

FROM tblIntraday

WHERE (PatternName LIKE ? + '%')

4.4.2 Patient/Nurse Input

The patient and nurse input was implemented using INSERT queries to add new patients or nurses to

the database. The input screen to add a new patient can be seen below in Figure 4.4.2 on the

following page:

Me.Validate()

Me.TblMultidayBindingSource.EndEdit()

Me.TableAdapterManager.UpdateAll(Me.NHSDatabaseDataSet)

MsgBox("Multiday Pattern Saved")

Figure 4.4.1 Screenshot and code for saving a multiday pattern

29

Figure 4.4.2 Screenshot for adding a new patient

A calendar was used to select a patient’s earliest start date and latest start date; this was done to

ensure dates are entered in the correct format (dd/mm/yyyy) into the database. Several features of the

visual editor were used in regard to HCI issues such as automatic alignment of fields and equal

spacing between fields. A dropdown list was used to select the multiday pattern a patient has been

prescribed. To populate the dropdown a query was used to only select valid multiday pattern IDs

sorted alphabetically. The query bounded to the dropdown list can be seen below:

SELECT tblMultiday.MultidayPatternID

FROM tblMultiday

WHERE (((tblMultiday.Valid)=True))

ORDER BY tblMultiday.MultidayPatternID

Following the input function the editing function for patients and nurses was created, as in Section

4.4.1 two parameter queries were developed based on the Patient ID/Nurse ID and the surnames of

the patient or nurse using a wildcard parameter for the names. A screenshot of the two ‘toolstrips’

used to enter the parameters for the queries to search for a nurse can be seen below.

Figure 4.4.22 Screenshot of nurse filter toolstrips

30

As part of the nurse input, the staff rota has to be entered into the system to populate the table

tblNurseRoster. This was implemented using a data grid view so that the rota for an entire day could

be seen on one screen, with the information of which nurse will be working and also their shift times

on specific days.

The start time and end time of each shift were stored in the database and these fields were formatted

as ‘Date/Time’ fields in the data model. When this data was retrieved by the application it introduced

an artificial date to precede each time. For example a time of ‘16:30’ would appear as ‘12/12/1899

16:30’. Although actual date fields appeared correctly and did not introduce an artificial time, time

fields had this artificial date before each time.

This problem was solved by changing the query in the getter method to include a formatted time

instead of retrieving the entire field. This query can be seen below:

SELECT [Date], NurseID, Format(StartTime, ‘hh:mm’) AS StartTime, Format(EndTime, ‘hh:mm’) AS EndTime

FROM tblNurseRoster

The same approach was used in patient appointments where time fields were used. This technique can

be re-used in future extensions to the application where any time data is stored in the database.

4.4.3 Patient Appointment Output

A query was written in the MS Access database using the method stated in Section 4.2.2. As this will

be a very commonly called query it was stored in the actual database to speed the performance of the

system by only sending the parameter and then receiving the result. As discussed in Section 4.2.2 the

.NET framework recognises these queries as ‘Functions’ which can be remotely called and passed

parameters. The query used for generating the output for a patient showing their appointments in their

prescribed multiday pattern can be seen on the following page:

31

SELECT tblAppointmentMultiday.AppointmentID, tblAppointmentMultiday.Date,

tblAppointmentIntraday.StartTime, tblAppointmentMultiday.PatientID, tblPatient.Title, [Forename] & " " &

[Surname] AS Name, [TotalNumberOfSlots]*15 AS Duration, tblMultiday.PatternName AS [Multiday

Treatment], tblIntraday.PatternName AS IntradayPatternName

FROM ((tblMultiday INNER JOIN (tblIntraday INNER JOIN tblAppointmentMultiday ON

tblIntraday.IntradayPatternID = tblAppointmentMultiday.IntradayPatternID) ON

tblMultiday.MultidayPatternID = tblAppointmentMultiday.MultidayPatternID) INNER JOIN

tblAppointmentIntraday ON tblAppointmentMultiday.AppointmentID =

tblAppointmentIntraday.AppointmentID) INNER JOIN tblPatient ON (tblPatient.PatientID =

tblAppointmentMultiday.PatientID) AND (tblMultiday.MultidayPatternID = tblPatient.MultidayPatternID)

WHERE (((tblAppointmentMultiday.PatientID)=[Enter Patient ID]) AND

((tblAppointmentIntraday.SlotNumber)=1));

Several iterations of this query were made to get the output as required. The field AppointmentID was

included so that the receptionist can run a query later using the application if required; this may be a

patient wanting to change an appointment later over the phone enabling the receptionist to search for

that specific appointment. The results of this query were then passed to a report using a visual

designer within MS Access. A report to display the results of the query has been used as it can be

neatly formatted and printed out to give to the patients or exported to MS Word. In order to remotely

call reports from the main application the Interop.Access library had to be imported to the project

which is part of the .NET framework. In future extensions to the project reports can be generated

easily by using the same method where no programming is required to design the layout of the report.

An example of a report generated for a patient can be seen in appendix E. The code used to display

the report from the main application has been written so that it can be reused for different reports in

the future by passing a new parameter for the report name. This code can be seen in Figure 4.4.3

below:

Dim ac As New Microsoft.Office.Interop.Access.Application

ac.OpenCurrentDatabase(MySettings.ConnectionString)

ac.Visible = True

ac.RunCommand(Microsoft.Office.Interop.Access.AcCommand.acCmdAppMaximize)

ac.DoCmd.RunCommand(Microsoft.Office.Interop.Access.AcCommand.acCmdWindowHide)

Try

ac.DoCmd.OpenReport("rptPatientAppointment",

Microsoft.Office.Interop.Access.AcFormView.acPreview)

ac.DoCmd.Maximize()

Catch ex As System.Runtime.InteropServices.COMException

ac.DoCmd.Quit()

MsgBox("Unable to display report")

End Try

Figure 4.4.3 Report display code

32

4.4.4 Nurse Schedule Output

Two functions were created to show the output for nurses. A report based function was created to

show which nurses are in work on any date specified by the user, which can be printed. The report is

generated for a specific date showing the names of the nurses in work on that day, their nurse ID, start

time and end time of their shift. The query used to form the report is shown below:

SELECT tblNurseRoster.Date, tblNurseRoster.NurseID, [Forename] & " " & [Surname] AS Name,

tblNurseRoster.StartTime, tblNurseRoster.EndTime

FROM tblNurse INNER JOIN tblNurseRoster ON tblNurse.NurseID = tblNurseRoster.NurseID

WHERE (((tblNurseRoster.Date)=[Enter date (dd/mm/yyyy)]));

The second function was to develop schedules showing the nurses assigned to patients for intraday

appointments which can be also be printed to give to the nurses. This function was required to show

the full intraday schedule for a nurse for any date, stating at what times a nurse needs to perform a

treatment to which patient and the name of the action that needs to be performed. Two parameters are

passed to this query which are the date and nurse ID for which an intraday schedule needs to be

displayed. This query can be seen below:

SELECT tblAppointmentMultiday.Date, tblAppointmentIntraday.NurseID, [tblNurse.Forename] & " " &

[tblNurse.Surname] AS NurseName, tblAppointmentIntraday.StartTime, tblPatient.PatientID,

[tblPatient.Forename] & " " & [tblPatient.Surname] AS PatientName, tblIntraday.PatternName,

tblPatient.AppointmentPreference, tblAppointmentIntraday.TreatmentName

FROM tblPatient INNER JOIN (tblNurse INNER JOIN ((tblAppointmentMultiday INNER JOIN tblIntraday ON

tblAppointmentMultiday.IntradayPatternID = tblIntraday.IntradayPatternID) INNER JOIN

tblAppointmentIntraday ON tblAppointmentMultiday.AppointmentID =

tblAppointmentIntraday.AppointmentID) ON tblNurse.NurseID = tblAppointmentIntraday.NurseID) ON

tblPatient.PatientID = tblAppointmentMultiday.PatientID

WHERE (((tblAppointmentMultiday.Date)=[Enter date (dd/mm/yyyy)]) AND

((tblAppointmentIntraday.NurseID)=[Enter Nurse ID]));

The schedules generated can be manually changed by the user via a DataGridView, this can be to

change a nurse assigned to a patient or change the time of an intraday appointment of a patient by

filtering by patient ID or nurse ID. The start times of individual slots within an intraday appointment

can also be changed if required; this may be due to clashes in the schedule generated by the external

scheduling component. Figure 4.4.4 on the next page shows how an intraday schedule for a patient

may be altered where the final action is delayed.

33

Image a) in Figure 4.4.4 shows a schedule generated by the external scheduler which is manually

modified to postpone the final action by one slot, with image b) showing the final (modified) schedule

for a patient.

4.4.5 Appointment Archive

As part of the enhancements for the system an archiving functionality was created. As this would

mean data is deleted from the main database it was decided to develop an administrative function, so

it was developed actually using MS Access from the database which only an administrator has direct

access to.

Initially a new archive Access database was setup which had three tables;

tblAppointmentIntradayArchive, tblAppointmentMultidayArchive and tblNurseRosterArchive which

had mapped structures to the original tables, tblAppointmentIntraday, tblAppointmentMultiday and

tblNurseRoster respectively. It was decided to use another Access database for the archive as it could

easily be extended in the future if new tables are added and it does not take up any memory in the

main database. The archive tables can be linked directly to the main database, which would not be

possible if using text files or CSV files for example.

To archive the appointments four queries had to be written, two insert queries followed by two delete

queries. These had to be carefully designed to ensure no data is permanently deleted. As there are two

tables storing appointment records they both have to be archived but the intraday appointments have

to be archived first as they contain a foreign key linked to the multiday appointments. After creating

the four queries a macro was written to ensure the queries are run in the correct order. The four

queries to archive year old patient appointments can be seen on the following page:

Figure 4.4.4

34

Append Intraday Appointments – Query 1

INSERT INTO tblAppointmentIntradayArchive ( AppointmentID, StartTime, SlotNumber, TreatmentName,

NurseID )

SELECT tblAppointmentIntraday.AppointmentID, tblAppointmentIntraday.StartTime,

tblAppointmentIntraday.SlotNumber, tblAppointmentIntraday.TreatmentName,

tblAppointmentIntraday.NurseID

FROM tblAppointmentMultiday INNER JOIN tblAppointmentIntraday ON

tblAppointmentMultiday.AppointmentID = tblAppointmentIntraday.AppointmentID

WHERE (((tblAppointmentMultiday.Date)<=(Date()-365)));

Append Multiday Appointments – Query 2

INSERT INTO tblAppointmentMultidayArchive ( AppointmentID, [Date], PatientID, MultidayPatternID,

MultidayDay, IntradayPatternID )

SELECT tblAppointmentMultiday.AppointmentID, tblAppointmentMultiday.Date,

tblAppointmentMultiday.PatientID, tblAppointmentMultiday.MultidayPatternID,

tblAppointmentMultiday.MultidayDay, tblAppointmentMultiday.IntradayPatternID

FROM tblAppointmentMultiday


Delete Intraday Appointments – Query 3

DELETE tblAppointmentIntraday.*, tblAppointmentMultiday.Date

FROM tblAppointmentMultiday INNER JOIN tblAppointmentIntraday ON

tblAppointmentMultiday.AppointmentID = tblAppointmentIntraday.AppointmentID


Delete Multiday Appointments – Query 4

DELETE tblAppointmentMultiday.AppointmentID, tblAppointmentMultiday.Date,

tblAppointmentMultiday.PatientID, tblAppointmentMultiday.MultidayPatternID,

tblAppointmentMultiday.MultidayDay, tblAppointmentMultiday.IntradayPatternID

FROM tblAppointmentMultiday


35

The same approach was used to archive the nurse roster however as this data is only stored in a single

table only two queries had to be written; the first to append data to the archive and then to delete data

from the main database.

4.4.6 CSV Parsing

To send and receive data to and from the external scheduling component CSV files are used as

discussed in the design section. Two directories were created; one for input to the scheduling

component and the second for output from the scheduling component.

For the input to the scheduling component directory seven blank CSV files were created, each

corresponding to a different table in the database. The format of the CSV files is identical to their

corresponding data structure in the tables, which can be seen in Section 3.3.3.

For the output from the scheduling component directory two blank CSV files were created which had

the same format as the structures of tblAppointmentMultiday and tblAppointmentIntraday. The

schedules would be returned from the scheduling component in these formats so that they can be

directly appended into the database.

To ensure unnecessary data is not exported from the tables some select queries were run to filter out

data to export. For example to export multiday and intraday patterns when they are added or updated

only valid patterns are exported. For example to export tblMultidayVisit the following query was

used:

SELECT tblMultidayVisit.MultidayPatternID, tblMultidayVisit.MultidayDay, tblMultidayVisit.IntradayPatternID

FROM tblMultiday INNER JOIN tblMultidayVisit ON tblMultiday.MultidayPatternID =

tblMultidayVisit.MultidayPatternID

WHERE (((tblMultiday.Valid)=True));

The following code was then used to export the data to the required CSV file in its specified

directory. It can be seen that two parameters are passed to this command which are the name of the

query to export and the directory of the file which to append the data to:

ac.DoCmd.TransferText(Microsoft.Office.Interop.Access.AcTextTransferType.a

cExportDelim, , "qryExportMultidayVisit", "C:\Scheduler

Input\tblMultidayVisit.csv")

36

The same code was used for exporting all the tables each time specifying a new query or table and the

CSV filename is changed to correspond to the correct table. The same code can be used in the future

if additional tables are added to the data model. This technique can also be used if external data sets

exist already which the user may want to import into the database.

Once the scheduling component has received the files and stored the information in its own database

it then deletes the data from within the CSV files but not delete the file itself so that it can be used in

future updates. Each time the schedule component is triggered it checks the CSV files for updated

information before it generates the schedules, so that it can generate schedules with the correct

patterns and also to avoid clashes with existing appointments.

To import generated schedules into the database acImportDelim was used and the arguments

specified were the name of the CSV file and table into which to append the data. For importing data it

was imperative that the data in the CSV files is in the same format as it is in the tables, for example

dates are formatted dd/mm/yyyy. To ensure any data that is imported is in the correct format ‘import

specifications’ were created for the two appointment tables which state for each field what data type it

should contain and its format. One of the parameters in the import code is the import specification

name; if an attempt is made to import incompatible data an error message is displayed. Once

schedules are received for patients and appended into the database the patient record in the table

‘tblPatient’ gets updated to include ‘True’ in the ‘ScheduleGenerated’ field using an UPDATE query

and also the data in those CSV files is deleted to eliminate the risk of data duplication when schedules

are appended in the future.

A major advantage of using a MS Access database was that VBA code can be used from VB 9.0 code

thus acImportDelim and acExportDelim were used to export and import data instead of looping

through each row in the CSV file and selecting the required records.

To remotely trigger the scheduling component a Shell command was used which executes the

program by specifying the directory where it is stored as a parameter to the method. The code to do

this was placed in a Try and Catch block statement where a message is displayed to the user if it is

not possible to run the external program.

4.4.7 Other Development

As an enhancement of the project a login screen was created. Although security is not a major

concern in this project as the system will be stored locally it was decided that a login screen would

37

provide sufficient security. The login was linked to the table tblUser in the database to query the

entered username and password to check they match a record. The login screen can be seen below in

Figure 4.4.7 along with the message displayed if an invalid username or password is entered, the main

menu of the application can be seen in Figure 4.4.72 which the user is directed to if valid details are

entered.

Figure 4.4.7 Login page and unsuccessful login message

Figure 4.4.72 Main menu of the application

38

a) File Menu b) Tools Menu

Figure 4.4.73 a) File Menu and b) Tools Menu of the application

Figure 4.4.73 shows the options available on two of the menus of the toolbar. The menus of the

toolbar can be easily extended or modified in future extensions to the project to include additional

features by modifying the toolstrip used from the visual editor in MS Visual Studio.

A further administrative feature was also included, which was to add new users for the application

and to amend existing users’ information, which includes resetting their passwords. This was done

using MS Access. During further extensions to the project the administrator function can also be

extended, as it has been created using Access forms, no coding would be required. The main menu of

the administrator application can be seen below in Figure 4.4.74.

Figure 4.4.74 Administrator main menu

39

5. Testing

This chapter will look at the testing of the system developed to ensure it has met its requirements. As

a fairly flexible methodology was adopted for the development the testing of the application started

during its development with bugs being fixed as they were discovered. One of the advantages of using

a prototyping methodology was that it allowed for several iterations for improvement where bugs

were fixed. After each section of the application was completed or some code was written it was

tested so that errors could be corrected. Following the completion of the system further testing was

done to test the final system.

5.1 Unit Testing

Unit testing was undertaken during the actual implementation of the system. Each time some code

was written it was run and monitored using the ‘debug’ feature in MS Visual Studio which proved to

be extremely useful throughout the development phase. As bugs were discovered they were corrected

by adding additional code or modifying the existing code. Several bugs were corrected using ‘try and

catch’ block statements using VB.NETs exception class, for example the try and catch statement in

figure 4.4.3 was written after the actual executable code had been written, as it was discovered during

testing that if a user clicked on cancel when prompted for a patient ID the application would terminate

and go into debug mode. Similarly many other minor errors were discovered and corrected. This

method of testing proved to be very effective in discovering trivial errors relatively quickly, which

were fixed before they created more complicated problems further down the line during development.

After development of the system had been completed testing was also performed. A test plan was

developed which specified ‘what is to be tested, how it is to be tested, the criteria by which it is

possible decided whether a particular test has been passed or failed’ [5]. Functionality testing and

interface testing were combined to ensure the system was functioning as required. The full test plan

and its results can be seen in appendix G.

It was found during the testing phase some of the ‘Back’ buttons were not functioning properly and

failing to go back to the previous screen. To keep interfaces consistent and following good usability

practise the buttons on the forms were reused wherever appropriate however when controls were

copied from one form to another their function code was not copied, so it had to be added manually.

Similarly further ‘try and catch’ block statements were added to the code.

40

5.2 Integration Testing

Integration testing involves testing the interfaces between programs. Integration testing was applied to

this project by testing the integration between the database and the main application. Integration

testing between the main application, scheduling component and database was also performed

however due to the developer not having the scheduling component available only the CSV parsing

was tested.

Information needs to be read from the database and also inserted into the database by the main

application for the system to work successfully as intended. To perform these tasks INSERT and

SELECT queries are executed by the main application. Using dummy data several tests were carried

out to ensure data is being correctly entered into the appropriate fields and tables in the database and

also retrieved from the database. Some problems were discovered using this method, for example

there are several fields which are required for a patient, for example their multiday pattern ID is

required however the system was still allowing records to be added without this data. This was solved

by adding validation code to the ‘Save’ button to ensure all required fields had been filled in. Reading

data from the data was successful and required no further coding or modification.

The CSV parser was also tested to check that the correct data is being exported into the correct CSV

files from the database. This was done for each possible export and also for the imports and the CSV

files and data tables were manually checked to see if the data had been appended successfully. The

CSV files were also checked to ensure once they had been processed the data they contain has been

deleted. The trigger for the external scheduler was tested with other external programs however due

to the developer not having the scheduling program it was not possible to test it directly.

5.3 Summary

As testing was performed during implementation of the system it meant that the majority of errors

were corrected before entering the testing phase. There were some errors which were discovered

during the testing phase and these were corrected. Integration testing was required to check if data is

being correctly entered into the database and retrieved from the database otherwise the system would

not function at all. An issue that was highlighted from the final testing was a performance issue. Upon

detailed investigation it was found that several times the application uses the database directly for

example when generating reports and each time the application was doing this it was not closing the

connection it had opened. This resulted in the application slowing down after time, as a result of this

DoCmd.Quit and DoCmd.Close statements were added to ensure the connections were closed.

41

6. Evaluation

This chapter will evaluate the solution to determine if it has been a success. This chapter will also

evaluate the effectiveness of the methodology employed throughout the project and the tools used. In

addition to evaluating the solution and methodology future enhancements to the project will be

discussed.

6.1 Evaluation Criteria

The criteria for evaluating the system will focus on the objectives and requirements of the system;

Section 1.3 highlights these with Section 1.4 stating the functional and non functional requirements of

the system. In addition to these requirements the CSV parsing will be evaluated including the

performance of the extraction of CSV files from the database and the appending of schedules to the

database. Usability of the system will also be evaluated. The evaluation will then look at the

effectiveness of the adopted methodology and the schedule, chosen technologies, possible future

enhancements and the effectiveness of the testing,

6.2 Aim and Objectives

The objectives of the project stated in Section 1 were completed successfully thus the project aim has

been achieved.

• The problem was analysed in detail and all the requirements were sought at the initial stages

which made development of the solution easier as no new requirements were introduced

during development

• A software engineering was chosen which was then successfully followed during the project

which can be seen from the Gantt chart in appendix B with the actual schedule

• A data model has been developed using MS Access which accurately stores all the data

required from which data can be retrieved and inserted appropriately

• An application has been developed which integrates with the data model and can query it

successfully

• The system has been tested and several bugs have been corrected

• The framework developed can be easily extended in the future using the same or additional

technologies. Using the software engineering principle of ‘Separation of Concerns’ with a

layered design has achieved the required adaptability, reusability and extensibility

42

All the minimum requirements which are stated in Section 1.3.1 have been achieved

Manage patient and staff details

Graphical user interfaces were developed to input and store patient and nurse details including which

treatments have been prescribed to patients and the nurse timetables for nurse shifts. Additionally

advanced search functions were added to the system to allow for patients and nurses to be searched

for using wildcard queries and then edit existing details of patients and nurses.

Manage multiday and intraday patterns

This requirement was also completed by developing graphical interfaces linked to the database to

enter new multiday patterns and then link each visit day of a multiday pattern to an intraday pattern.

The intraday patterns are linked to each treatment slot within the intraday pattern. Similar to staff and

patients multiday and intraday patterns can also be searched by a wildcard query on their name or by

their ID.

Generate schedules for patients and nurses

CSV files can be extracted from the database for patients requiring schedules to be generated and sent

to the scheduling component. An external program can then be remotely triggered using a Shell

command. Using the main application CSV files received from the scheduling component containing

the schedules data can be successfully appended to the database.

Display schedules for patients and nurses

Schedules for both nurses and patients can be generated and printed. This is done by using queries to

extract the appropriate data from the database. To allow a user to manually change the schedules

generated by the external scheduling component data grid views were used which the user can filter

and amend details. The minimum requirement was to show a schedule for any nurse for the next six

weeks, this requirement has been exceeded and the system shows the schedule for any dates where

the scheduling component has generated schedules including the past as well as the future. Also a

nurse shift timetable can be generated for any date showing the nurses on the rota that day and their

shift times.

Enhancements

Some of the enhancements specified in Section 1.3.2 were also implemented. A login screen was

implemented so that only authorised users can access the system. An administrator prototype was

developed, which can add new users and edit existing user profiles, also an administrator can archive

appointments and the nurse roster. One enhancement that was not possible to implement due to time

43

constraints was to have a drag and drop feature enabling a user to alter the times of an intraday

appointment.

6.3 Usability

As the main application has been designed to be used by hospital receptionists’ usability is very

important. Two evaluation techniques identified by Preece et al [30] are usability testing and field

studies. In usability testing a user is given a series of prepared tasks and they are observed whilst

performing those tasks, field studies differ as they are performed in a user’s natural environment; a

common approach is for the developer to observe the users and note any comments or suggestions

they may have for improvement.

In order to evaluate the usability of the system a questionnaire was designed and given to people to

use the system and record their responses. The evaluators used the system on the developer’s laptop

with the developer observing them and answering any questions they may have. Only one

questionnaire was designed which covered both the main application and the administrator prototype.

A range of people including different computer literacy people were given the questionnaire as this

would achieve more accurate results in comparison to hospital receptionists, the potential users.

The first stage of the questionnaire used closed questions with several possible answers to obtain

quantitative data and the second stage asked open questions to establish general feedback and

possible recommendations for improvement.

The results of the questionnaire are shown on the next page, followed by further analysis. The

numbers indicate the number of users who ticked that box.

44

Question Excellent

(5)

Good

(4)

Average

(3)

Below

Average (2)

Poor

(1)

1. Your general computer

experience

1

5

2

0

0

2. How easy was it to navigate

around the application?

5

3

0

0

0

3. What did you think of the

layout of the forms and their

consistency?

4

4

0

0

0

4. Were the fonts, sizes and

colours used appropriate?

1

4

3

0

0


application performance?

7

1

0

0

0

6. What do you think the

terminology used?

0

4

4

0

0

7. Do you think the system is

easy to learn?

4

3

1

0

0

8. Do you think the system is

reliable?

0

4

4

0

0

9. Were the error messages

informative and clear?

0

5

2

1

0



layout of the interface?

2

5

1

0

0

11. Do you think the application

buttons are appropriate?

1

7

0

0

0

12. What do you think of the

colour scheme?

3

4

1

0

0

Most positive aspect of the

application

A range of answers were received to this. The main ones were

performance, system speed and layout used

Most negative aspect of the

application

The most common answer was a help facility with a search

Suggestions for improvement A calendar to allow dragging and dropping of appointments. A

web based system for patients to view/change appointments

The raw results of the questionnaire can be seen above. Only 8 people participated in the evaluation

however it is stated in [23] that between three and five evaluators may be sufficient in identifying

around 75% of usability issues and that subsequent evaluators generally repeat issues already

45

User Questionnaire Response

1

2

3

4

5

1 2 3 4 5 6 7 8 9 10 11 12

Question

Ra

tin

g Average

Minimum

identified by previous evaluators which was found to be the case in this evaluation hence only

increasing the quantity of responses and not necessarily the value.

The minimum value of each response has been used in the analysis as well as the mean of each

response. This technique is known as the ‘least misery strategy’ [31]. This shows that the group of

evaluators is only as satisfied as the least satisfied evaluator. However there is a possibility that some

evaluators rate the system more negatively than others so the mean has also been included.

The responses from the questionnaire are presented below in Figure 6.3. The bars show the average

response for each question with the red line showing the minimum value for each question. As all the

results were above 2, the y-scale has been modified to start from 1 and not 0.

Figure 6.3 Chart showing responses from user questionnaire response

It was noticed that none of the evaluators used the Tab key to navigate around the application and

they all used use the mouse, however when told of this function being available it received positive

feedback as it meant the user was not limited to using the mouse and could use the keyboard if they

preferred.

6.4 CSV Parser

To evaluate the performance of the CSV parsing additional code was written using a .NET framework

Timer component to time how long exporting and importing takes. The code was wrapped around the

export functions so they began with InitializeTimer() , Timer1.Enabled = True and ended

with Timer1.Stop(). The timer interval was set to 0.1 seconds.

46

With some runs of using the timer it failed to display any reading and remained at 0.0 seconds as the

export took under 0.1 seconds. Therefore the test was run on the table tblAppointmentIntraday which

is the most populated table in the database. There were 10,000 records in the table and the export

function took 0.3 seconds.

Similarly it was found that the importing of schedules was quick, however due to the developer not

having the scheduling program on the system it was not possible to test generation of schedules and

the importing of the resulting CSVs combined.

A limitation of exporting CSV files is that each time a change is made the relevant CSV file needs to

be generated and exported, in practice it may be better to give the external scheduling component

shared read access to the database and only allow it to enter data to the database by sending CSV

files. This approach could be easily be implemented with the current framework, as the importing of

schedules from CSV files works and it would only require the user to send a CSV with patient and

future appointment records for generation of schedules

6.5 Methodology and Schedule

As discussed in Section 2.2 an evolutionary prototyping methodology using RAD for each phase was

chosen for this project. The RAD was used for each phase and the schedule for the development was

split into these phases which can be seen from the Gantt charts in appendix B. This methodology

made time management and the schedule more efficient as smaller phases for development made

tracking of progress easier.

The RAD aspect of the methodology was successful in the project as its focus is on adding

functionality and the development of the GUIs was also done in this way and any limitations were

then solved by iterating over the same stage. However development of the system was not always as

‘rapid’ as would have been preferred which did hinder progress at times.

A slight change was made to the methodology which was to use throw away prototypes. This was

done when a bug was discovered and the solution was not immediately obvious to ensure any changes

to the code did not result in the entire system ‘breaking’. For example the solution to the problem

stated in Section 4.4.2 regarding time fields not displaying correctly was discovered using a throw

away prototype. As this involved directly changing the query in the getter method the problem could

have escalated by making incorrect alterations to the code, so it was decided to use a throw away

prototype and apply the solution to the main evolutionary prototype.

47

Some of the changes made to the main evolutionary prototype include: changes to the layout of the

interfaces, changes to the ER diagram and database, additional validations to avoid data corruption,

additional help comments, try and catch block statements and adding the login screen for security.

Throughout development reusable coding has been used; some of which has been reused internally in

the project and also designed to be reused in future extensions and enhancements to the project. The

‘Separation of Concerns’ (SOC) process was used successfully in this project to split the system into

separate features with minimal overlap. A layered design was used based on SOC; a database layer,

application layer and a presentation layer. This approach has made the system extendable in the future

and enables further functionality to be added.

The schedule was roughly followed, however some alterations were made to the initial schedule

which can be seen from the Gantt charts in appendix B. Alterations were required due to development

not being as quick as initially planned in some phases and quicker than planned in other phases. The

initial schedule also underestimated the time that would be required for the background reading and it

can be seen some of this actually took place in semester 2 in parallel to the development.

6.6 Technologies

Two technologies were chosen for this project; a MS Access database and VB9.0 using Microsoft

Visual Studio 2008 as the development environment which is part of the .NET framework. MS

Access was appropriate to this project as it is a very popular database and is easy to extend in the

future which was one of the aims of the project. Also MS Access provided the ability to develop an

administrator interface for the framework without any coding required, similarly this can also be

modified and extended in future development to the framework. MS Access also provides the ability

to link to tables in another MS Access database which was used in this project to link to the archive

database.

The Visual Studio development environment was appropriate to this project as it was relatively

simple to use enabling the developer to start development quickly and make significant progress.

There were many useful features to aid development with VB9.0 and Visual Studio which included

central project configuration files and ‘drag and drop’ facilities for adding controls to GUIs. This

feature fitted in well with the RAD method that was used for each phase of development keeping

development roughly on track. Visual Studio provides a good way of organising the project so each

interface (.vb Designer file) has its own .vb code file with the same name, this fitted well with the

‘separation of concerns’ process separating the presentation layer from the data access layer, as

48

shown in Figure 3.1.1. This allows for developers extending the project in the future to easily

establish which files require alterations. There are many libraries available for VB9.0 and some of

these were used to good effect and further use can be made of them in future extensions. Overall the

technologies worked very well together and any technical difficulties that were encountered were

solved quite quickly.

6.7 Future Enhancements

From the results of the evaluation and during development further enhancements were found which

could be incorporated in future extensions to the project enhancing system functionality. As the

framework has been designed and developed to be extended there are many extensions possible to the

system. Some of these are stated below:

• Include a help feature. This could be done by including more help messages in the application

and could be done by creating an interactive screen which demonstrates use of the software

and explain features more clearly. This was identified by evaluators of the system.

• Include nurse break times when entering the rota for each day. This could be done by

modifying the database to include break times for nurses.

• A calendar feature could be incorporated within the application or by linking the application

to an external calendar. This was another feature identified by evaluators of the system who

said a ‘clever calendar’ could be used with various views enabling users to zoom in and out

of several timeframes; for example an entire month could be shown or a user could zoom into

a specific day. This feature could also allow for ‘drag and drop’ of appointments.

• A web based application could be added to allow patients to view their appointments. This

major addition could allow patients to change their intraday appointments. More focus on the

actual scheduling could be placed on such a project to re-allocate nurses to patients if they

wish to change their appointments. Also nurses could login to view their rotas; security would

have to be a consideration with such a project. This application could be created using the

current database and Microsoft’s ASP.NET technology using Visual Studio.

• The system could be extended to deal with the preparation of medicines prior to a patients

appointment, so that any required medications are ready for a patient and this process does

not have to be done manually.

49

6.8 Evaluation Summary

The evaluation showed that the final system created met its objectives and has achieved all the

minimum requirements hence it has been successful. A system has been developed on time and with

the required functionality and security. Also an administrator prototype with data archiving

functionality has been developed which can also be extended in the future. The application created is

easily extendible in the future and many principles of reusable coding have been used.

The usability evaluation has shown that the system meets key usability principles and is user friendly.

Although the number of evaluators was quite low it still provided sufficient feedback for conclusive

results. The responses from the questionnaire were positive and helped in identifying some problems

users experienced and further enhancements they would like such as a calendar allowing dragging

and dropping of multiday pathways and intraday appointments.

The CSV parsing evaluation showed that performance was not an issue both when extracting data and

when entering schedules into the system, however in practise it may be better for the scheduling

component to have direct read access to the database, so that it can view multiday and intraday

patterns and when a user wants to generate schedules they can export the future schedule and records

for the patients who they want schedules generated for.

Finally some future enhancements to the project have been presented based on the findings of the

evaluation and also some aspects which were outside the scope of this project due to time constraints.

In conclusion it can be seen that the delivered solution provides an appropriate solution to the

problem where it eliminates the need for paper based scheduling and record keeping. The evaluation

has highlighted some areas for improvement that could be made which if implemented would

enhance the system further in terms of its capabilities and functionality.

Further personal reflections of the developer are presented in Appendix A for reference by future

students undertaking similar projects.

50

References

[1] Condotta, A & Shakhlevich, N, Private communication (2008)

[2] Avison, D & Fitzgerald, G, (2002), Information Systems Development: Methodologies,

Techniques and Tools, Third Edition, McGraw Hill

[3] Hughes, B & Cotterell, M, (2006), Software Project Management, Fourth Edition, McGraw

Hill

[4] Cadle, J & Yeates, D, (2004), Project Management for Information Systems, Fourth Edition,

Prentice Hall

[5] Bennet, S, McRobb, S & Farmer, R, (2006), Object-Oriented Systems Analysis And Design

Using UML, Third Edition, McGraw Hill

[6] Yeates, D & Wakefield, T, (2003), Systems Analysis and Design, Second Edition, Financial

Times / Prentice Hall

[7] Gallery Image Business Data Solutions, (2008), Benefits and Constraints of using Microsoft

Access Database & Office, http://www.galleryimage.com.au/Why-Access-Database.htm

[Accessed 09/11/2008]

[8] Carter, J, (2003), Database Design and Programming with Access, SQL, Visual Basic and

ASP, Second Edition, McGraw Hill

[9] Whitehorn, M, (2008), Review: Microsoft SQL Server 2008 database server, Personal

Computer World, http://www.pcw.co.uk/personal-computer-world/software/2226091/sql-

server-2008-4149553 [Accessed 09/11/2008]

[10] Microsoft Develop Network, (2008), Stored Procedure Basics, SQL Server 2008 Books

Online (October 2008), http://msdn.microsoft.com/en-us/library/ms191436.aspx [Accessed

11/11/08]

[11] MySQL, (2008), Why MySQL, http://www.mysql.com/why-mysql/ [Accessed 11/11/08]

51

[12] Valade, J, (2006), PHP and MySQL for Dummies 3rd

Edition, John Wiley & Sons, 2006

[13] Hunter, S R, TechRepublic, (2008), MySQL vs PostgreSQL,

http://articles.techrepublic.com.com/5100-10878_11-1050671.html [Accessed 11/11/08]

[14] Booch, G, (1998), Object-Oriented Analysis and Design with Applications, Second Edition ,

Addison- Wesley

[15] Savitch, W, (2005), Java: An Introduction to Problem Solving & Programming, Fourth

Edition, Prentice Hall

[16] Python Documentation, (2008), An Introduction to Python,

http://www.python.org/doc/intros/introduction/ [Accessed 12/11/08]

[17] Petroutsos, E, (2008), Mastering Microsoft Visual Basic 2008, First Edition, John Wiley &

Sons

[18] MSDN, (2008), Microsoft Developer Network, http://msdn.microsoft.com/en-gb/default.aspx

[Accessed 13/12/08]

[19] MSDN, (2008), What Is Reusable Code?, http://msdn.microsoft.com/en-

us/library/aa189112(office.10).aspx [Accessed 23/12/08]

[20] Hunt, A & Thomas, D, (1999), The Pragmatic Programmer: From Journeyman to Master,

First Edition, Addison Wesley

[21] Mili, H, Elkharraz, A & Mcheik, H, (2004), Understanding separation of concerns, In

Proceedings of the 3rd

Workshop on Early Aspects, Aspect-Oriented Software Development,

Lancaster

[22] Clements, P.C, (1996), From Subroutines to Subsystems: Component-Based Systems, In

Brown, A.W: Component Based Software Engineering, IEEE Computer Society Press

[23] Dix, A, Finlay, J, Abowd, D & Beale, R, (2003), Human Computer Interaction, Third

Edition, Prentice Hall

52

[24] Etzold, T & Argos, P, (1993), SRS -- An Indexing and Retrieval Tool for Flat File Data

Libraries. Computer Applications In The Biosciences, 9(1):49-57

[25] Elmasri, R & Nevathe, S, (2006), Fundamentals of Database Systems, Fifth Edition, Pearson

Education

[26] Chapple, M, (2008), Database Normalization Basics,

http://databases.about.com/od/specificproducts/a/normalization.htm [Accessed 20/01/09]

[27] Kendall, K & Kendall, J, (2007), Systems Analysis and Design, Seventh Edition, Pearson

Education

[28] Powers, L & Snell, M, (2008), Microsoft Visual Studio 2008 Unleashed, First Edition, Sams

[29] Petroutsos, E, (2006), Mastering Microsoft Visual Basic 2005, First Edition, John Wiley &

Sons

[30] Preece, J, Rogers, S & Sharp, H, (2002), Interaction Design: Beyond Human-Computer

Interaction, First Edition, John Wiley & Sons

[31] Masthoff, J, (2004), Group modelling: Selecting a sequence of television items to suit a group

of viewers, User Modelling and User-Adapted Interaction, 14 (1): 37-85

53

Appendix A – Personal Reflection

This project has been the most challenging work I have done in my academic career. It has been very

challenging both mentally and physically. I would advise future students to take a step back from the

project when interest levels plummet and come back to it with a fresh mind as you are more likely to

solve the problem. Now that the project is complete I look back on it as a very positive experience

from which I have learnt numerous lessons. I have highlighted some of these in the points below.

When choosing a project make sure it is a project you will be interested in for the long haul and not

just the next few weeks. There will be many times when enthusiasm towards the project drops

however if you have chosen a project you enjoy you are more likely to come back to it with a fresh

mind and be successful. I would recommend before starting any project to read the assessment criteria

and plan your time according to the awarding of marks for each section. Similarly try to plan your

report structure early in the project.

Choose your methodology carefully; I looked into several software development methodologies

however I found no single methodology that would work for my project. I was inclined to follow a

single well known methodology with the idea that as it is well known it would result in a successful

project, however a lot of methodologies are very generic and need to be considered for each

individual project to evaluate their suitability. Split your development into sub tasks as it can seem

that you have a long time for development and are reluctant to start. I would recommend planning for

contingencies as they are inevitable in almost any project. It can be seen that my initial project plan is

not the same as my followed project plan, which is for these reasons exactly.

A lot of background reading is required for the project which should not be underestimated. This is

one aspect of the project which I was not up to scratch with. Some of my reading actually took place

during the development and in semester 2, whilst it should really have been done in advance of

beginning the coding. You will come across many references, some of which you will not end up

using in the final report, I used MS Excel to store all the references and use only the appropriate ones

in the final report.

Throughout your project work with your supervisor as they have a wealth of experience and can offer

a lot of constructive criticism which improves the quality of your project. Attend all your scheduled

meetings and seek their advice on anything you are unsure about as they can instantly answer

54

questions which it would take you a long time to figure out. Similarly I would highly recommend you

never miss a deadline including the mid-project report, as this will keep you on track.

I found using MS Visual Studio daunting at first as it meant I would need to learn not only a new

programming language but also a new integrated development environment, however I would advise

students not to be afraid of trying something new. There were times during development when doing

the simplest of things turned into a test, which I could have done quickly with Java or Python but I

am now more confident in programming using new languages and development environments.

For students considering using MS Visual Studio for their project I would highly recommend it and to

use the Microsoft Developer Network website as a help resource. I used this before starting the

coding and throughout development and it made life much easier in particular watching the ‘How Do

I’ series videos at the beginning of development. A lot of the support available for Visual Studio

projects using databases is targeted at MS SQL Server databases whereas I was using a MS Access

database. Although MS Access worked fine some things from the support material would not work.

For example when using parameter queries with MS SQL Sever you have to use ‘@parameter’

however with MS Access you enter ‘?’. If you are doing a project using a database with Visual Studio

this may be something to bear in mind.

A lesson I learnt after the mid-project report was to write your report as you go along, this can be seen

from my followed plan. This will make report writing much easier towards the end of your project.

During development I kept a log of everything I did including the problems I came across and how

these were solved, this made it much easier to write up the development section of the report, as I had

small fragments of code and screenshots prepared which I thought would be suitable to include in the

report. Also whenever you have written any section of your report be prepared to refine it again and

again, this will help you immensely.

It is recommended by all previous final year project students and I will reiterate it ‘start your work as

early as possible’. Managing your time effectively is one of the most important aspects in delivering a

successful project. Looking back I wish I had started development in semester 1, which would have

meant I had much more time for the evaluation which is worth as many marks as the actual delivery

of solution. I had a 50-30 credit split across semesters 1 and 2 respectively, which I would

recommend however significant work on the project should still commence in semester 1. It is very

difficult balancing the workload of the modules and the project, which is something to consider when

planning the project.

55

Appendix B – Project Schedule

Initial Schedule

56

Actual Schedule

57

Appendix C – Tables & Relationships

58

Appendix D – UML Class for Table Adapter Manager

59

Appendix E – Patient Appointment Report

60

Appendix F – Test Plan

Login Page

Test Test Data Expected Result Success?

Incorrect Username asc5mja Error YES

Incorrect Password abc Error YES

Correct Username, Incorrect Password scs5mja

abc

Error YES

Incorrect Username, Correct Password asc5mja

scs5mja

Error YES

Correct Username, Correct Password scs5mja

scs5mja

Login Successful–

MainMenu form open

YES

No information entered -Blank- Error YES

Main Menu


Patients button Click Button Patients form open YES

Nurses button Click Button Nurse form open YES

Staff Rota button Click Button Staff Rota form open YES

Multiday Patterns button Click Button Multiday Patterns

form open

YES

Intraday Patterns button Click Button Intraday Patterns

form open

YES

External Scheduler button Click Button External Scheduler

form open

YES

View Schedules button Click Button View Schedules form

open

YES

View Reports button Click Button View Reports form

open

YES

Exit button Click Button Exits Application YES

Patients Form


Add Patient button Click Button Add Patient form

open

YES

Edit Patient button Click Button Edit Patient form

open

YES

Back button Click Button Close Patients form YES

61

Add Patients Form


Complete New Patient form Patient ID, Title,

Name, Address,

Multiday Pattern

ID, Appointment

Preference,

Earliest/Latest Start

date

Add Patient to

tblPatient + Display

record saved message

YES

Add new patient without required fields

filled in

Title, Address,

Other Details

Error message YES

Back button Click Button Close Add Patient

form

NO

Edit Patients Form


Search for patient on patient ID P1 Record displayed for

patient P1

YES

Search for patient on partial surname sm All patient with

surname beginning

‘sm’ displayed

YES

Edit a patients multiday pattern ID M3 Record updated

message

YES

Edit a patients appointment preference Morning Record updated

message

YES

Delete a patients ID -blank- Error message YES

Back button Click button Close Edit Patient

form

YES

Nurses Form


Add Nurse button Click Button Add Nurse form open YES

Edit Nurse button Click Button Edit Nurse form open YES

Back button Click Button Close Nurse form YES

Add Nurse Form


Complete New Nurse form Nurse ID,

Forename,

Surname,

Experience,

Telephone Number

Add nurse to

tblNurse + Display

record saved message

YES

Add new nurse without required fields

filled in

Forename,

Surname,

Error message YES

62

Back button Click Button Close Add Patient

form

NO

Edit Nurse Form


Search for nurse on nurse ID N1 Record displayed for

nurse N1

YES

Search for nurse on partial surname My All nurses with

surname beginning

‘my’ displayed

YES

Edit a nurses experience 1 Record updated

message

YES

Edit a nurses telephone number 0113764631 Record updated

message

YES

Delete a nurses Nurse ID -blank- Error message NO

Back button Click button Close Edit Nurse

form

YES

Staff Rota Form


Add Nurse Shift Date, Nurse, Start

Time, End Time +

Click Save button

Add Nurse shift

record

YES

Edit Nurse Shift Date, Nurse, Start

Time, End Time +

Click Save button

Edit Nurse shift

record

YES

Delete Nurse Shift Select shift +

Delete button

Delete Nurse shift

record

YES

Back button Click Button Close Nurse Roster

form

YES

Multiday Patterns Form


Add Multiday Pattern button Click Button Add Multiday Pattern

form open

YES

Edit Multiday Pattern button Click Button Edit Multiday Pattern

form open

YES

Back button Click Button Close Multiday

Patterns form

NO

Add Multiday Pattern Form


Complete New Multiday Pattern form Multiday Pattern

ID, Pattern Name,

Total Number of

Days, Number of

Visits, Pattern

Add multiday pattern

to tblMultiday +

Display record saved

message

YES

63

Valid

Add visit days button Click button Add visit days form

open + multiday

pattern saved

message

YES

Add new multiday pattern without

required fields filled in

Pattern Name Error message YES

Back button Click Button Close Add Multiday

Pattern form

YES

Visit Days Form


Add visit days and their intraday pattern

IDs

Multiday pattern

ID, Multiday visit

days, Intraday

Pattern IDs

Display records saved

message

YES

Add visit days without intraday pattern

IDs

Multiday pattern

ID, Multiday Visit

Error Message YES

Search for visit days of a multiday

pattern

Multiday Pattern

ID

Display visit days

records

YES

Back button Click button Close Visit Days

Form

YES

Edit Multiday Pattern Form


Search for multiday pattern on multiday

pattern ID

M1 Record displayed for

multiday pattern M1

YES

Search for multiday pattern on partial

pattern name

Multi All multiday patterns

with name beginning

‘multi’ displayed

YES

Edit a multiday patterns name Multiday Rename Record updated

message

YES

Invalidate a multiday pattern Click button Record updated

message

YES

Delete a patterns Multiday pattern ID -blank- Error message YES

Edit a patterns visit days Click button Visit Days form open YES

Back button Click button Close Multiday

Pattern form

YES

Intraday Patterns Form


Add Intraday Pattern button Click Button Add Intraday Pattern

form open

YES

64

Edit Intraday Pattern button Click Button Edit Intraday Pattern

form open

YES

Back button Click Button Close Intraday

Pattern form

YES

Add Intraday Pattern Form


Complete New Intraday Pattern form Intraday Pattern ID,

Pattern Name,

Total Number of

Slots, Number of

Actionss, Pattern

Valid

Add intraday pattern

to tblIntraday +

Display record saved

message

YES

Add action slots button Click button Add action slots form

open + intraday

pattern saved

message

YES

Add new intraday pattern without

required fields filled in

Pattern Name Error message YES

Back button Click Button Close Add Intraday

Pattern form

YES

Intraday Action Slots Form


Add action slots and their treatment

names

Intraday pattern ID,

Slot Number,

Treatment Names

Display records saved

message

YES

Add action slots without an intraday

pattern ID

Slot Number,

Treatment Name

Error Message YES

Search for action slots of an intraday

pattern

Intraday Pattern ID Display action slot

records

YES

Back button Click button Close Intraday Action

Slots Form

YES

Edit Intraday Pattern Form


Search for intraday pattern on intraday

pattern ID

I1 Record displayed for

multiday pattern I1

YES

Search for intraday pattern on partial

pattern name

Intra All multiday patterns

with name beginning

‘intra’ displayed

YES

Edit an intraday patterns name Intraday Rename Record updated

message

YES

Invalidate an intraday pattern Click button Record updated

message

YES

65

Delete a patterns Intraday pattern ID -blank- Error message YES

Edit action slots button Click button Intraday Action Slots

form open

YES

Back button Click button Close Edit Intraday

Pattern form

YES

External Scheduler Form


Export Multiday Patterns button Click button Exports multiday

pattern table into a

CSV

YES

Export Multiday Visits button Click button Exports multiday

visits table into a

CSV

YES

Export Intraday Patterns button Click button Exports intraday


CSV

YES

Export Intraday Actions button Click button Exports intraday


CSV

YES

Export Patients button Click button Exports patients

requiring schedules

into a CSV

YES

Export Nurses button Click button Exports nurses table

into a CSV

YES

Export Nurses Roster button Click button Exports future nurse

roster into a CSV

YES

Export Multiday Appointments Click button Exports future

multiday

appointments into a

CSV

YES

Export Intraday Appointments Click button Exports future

intraday

appointments into a

CSV

YES

Import Multiday Appointments button Click button Append the multiday

schedule generated

from the CSV to the

multiday

appointments table

YES

Import Intraday Appointments button Click button Append the intraday

schedule generated to

the intraday

appointments table

YES

Generate Schedules button Click button Trigger an external

program to run

YES

Back button Click button Close external

scheduler form

YES

66

Schedules Form


Multiday Appointments button Click Button Multiday

Appointments form

open

YES

Intraday Appointments button Click Button Intraday

Appointments form

open

YES

Back button Click Button Close Schedules form YES

Multiday Appointments Form


Search for an appointment on

Appointment ID

A1 Display record for

appointment with ID

‘A1’

YES

Search for appointments by date 30/03/2009 Display all

appointments on

30/03/2009

YES

Search for appointments by patient ID P2 Display all

appointments for

patient ‘P2’

YES

Edit an appointments date 31/03/2009 Update record +

message record

updated

YES

Back button Click button Close Multiday

Appointments form

YES

Intraday Appointments Form


Search for an appointment on

Appointment ID

A1 Display record for

appointment with ID

‘A1’

YES

Search for appointments by date 30/03/2009 Display all intraday

appointments on

30/03/2009

YES

Edit an intraday appointments times

including altering slot times

Times (hh:mm) Update record +

display message

‘record updated’

YES

Edit nurse assigned to a patient on an

intraday appointment

N43 Update record +

display message

‘record updated’

YES

Back button Click button Close Intraday

Appointments form

YES

67

Reports Form


View Patient Appointment button Click button Prompt for patient ID

and display patients

appointments

YES

View Nurse Roster button Click button Prompt for date and

display nurses in

work that day and

their shift times

YES

View Nurse Schedules button Click button Prompt for date and

nurse ID and display

their patient

assignments that day

YES

Back button Click button Close Reports form YES



Add/Edit User Add a user, Edit

existing user

Database updated YES

Delete User Delete existing user Database updated YES

Archive Year Old Appointments Click Button Data archived YES

Archive Nurse Roster Click Button Data archived YES

From the testing several issues were discovered which had not been detected during development.

One of the common issues found was that the ‘Back’ buttons did not do anything; this was due to the

graphical objects being copied from form to another however the code for the buttons had to be

written.

ANWAR Mohammed Jamal

Documents

Transcript of ANWAR Mohammed Jamal