anwar mohammed jamal
TRANSCRIPT
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
Attribute Name Data Type Description
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
Attribute Name Data Type Description
MultidayPatternID Text Foreign Key
MultidayDay Number Visit number
IntradayPatternID Text Foreign Key
tblIntraday
Attribute Name Data Type Description
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
Attribute Name Data Type Description
IntradayPatternID Text Foreign Key
SlotNumber Number Slot number
TreatmentName Text Name of treatment
tblNurse
Attribute Name Data Type Description
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
Attribute Name Data Type Description
Date Date/Time Date on roster
NurseID Text Foreign Key
StartTime Date/Time Shift start time
EndTime Date/Time Shift end time
tblAppointmentMultiday
Attribute Name Data Type Description
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
Attribute Name Data Type Description
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)
Attribute Name Data Type Description
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
WHERE (((tblAppointmentMultiday.Date)<=(Date()-365)));
Delete Intraday Appointments – Query 3
DELETE tblAppointmentIntraday.*, tblAppointmentMultiday.Date
FROM tblAppointmentMultiday INNER JOIN tblAppointmentIntraday ON
tblAppointmentMultiday.AppointmentID = tblAppointmentIntraday.AppointmentID
WHERE (((tblAppointmentMultiday.Date)<=(Date()-365)));
Delete Multiday Appointments – Query 4
DELETE tblAppointmentMultiday.AppointmentID, tblAppointmentMultiday.Date,
tblAppointmentMultiday.PatientID, tblAppointmentMultiday.MultidayPatternID,
tblAppointmentMultiday.MultidayDay, tblAppointmentMultiday.IntradayPatternID
FROM tblAppointmentMultiday
WHERE (((tblAppointmentMultiday.Date)<=(Date()-365)));
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
5. What did you think of the
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
Administrator Prototype
10. What did you think of the
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
pattern table into a
CSV
YES
Export Intraday Actions button Click button Exports intraday
pattern table into a
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Test Test Data Expected Result Success?
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
Administrator Prototype
Test Test Data Expected Result Success?
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.