An Integrated Framework for Hospital Appointment Management Mohammed Jamal Anwar Computer Science with Operational Research (Industry) 2008/2009

Transcription

1 An Integrated Framework for Hospital Appointment Management Mohammed Jamal Anwar Computer Science with Operational Research (Industry) 2008/2009 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)

2 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. i

3 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. ii

4 Table of Contents Summary... i Acknowledgments... ii Table of Contents... iii 1 Introduction Problem Definition Aim Objectives Minimum Requirements Enhancements Requirements Analysis Functional Requirements Non Functional Requirements Project Schedule Background Research Software Engineering Methodologies Chosen Methodology Tools and Applications Database Management Systems Programming Environments Reusable Coding Usability Design Framework System Architecture Graphical User Interface Database Design Entity Relationship Diagram Normalisation...19 iii

5 3.3.3 Data Definition Tables of Normalised Database Summary System Implementation Technology Setup Database Implementation Tables Queries Data Source Connection Application Implementation Intraday/Multiday Input Patient/Nurse Input Patient Appointment Output Nurse Schedule Output Appointment Archive CSV Parsing Other Development Testing Unit Testing Integration Testing Summary Evaluation Evaluation Criteria Aim and Objectives Usability CSV Parser Methodology and Schedule Technologies Future Enhancements Evaluation Summary...49 References...50 iv

6 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 v

7 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. Multiday Pattern 21 days 15 minute intervals Total duration 225 minutes (3h 45m) Intraday Pattern Figure 1.1: Multiday and Intraday pattern 1

8 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: 2

9 External Scheduling Program Input Appointment Management Framework Output Figure 1.2: System setup 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 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 3

10 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. 4

11 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: 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 Non Functional Requirements System must be easy to use and navigate System should have a consistent interface 5

12 1.5 Project Schedule Milestone Date Submit Aim and Minimum 24/10/08 Requirement Background Reading 19/10/08 25/01/09 Software Development Methodologies Database Technologies Programming Languages Reusable coding practices Methodologies and Project Planning 19/10/08 12/12/08 Analyse and select methodology Develop a project plan 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 15/01/09 31/01/09 Model Development of Solution 01/02/09 24/03/09 Patient Input Nurse Input Patient Appointment Output Nurse Schedule Output Data Parser Administrator Prototype Submit Table of Contents and draft 13/03/09 chapter 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. 6

13 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. 7

14 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 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 8

15 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 9

16 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 10

17 database in the event of data corruption. Extending an Access database in the future would also be relatively easy 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. 11

18 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. 12

19 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 problemsolving 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. 13

20 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. 14

21 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. 15

22 Send Receive Extract Append Database Trigger Write Read Main Application Request Response Users Trigger Figure 3.1 Proposed System Architecture 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 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 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. 16

23 Figure Three tier architecture diagram 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. 17

24 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 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-tomany. 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. 18

25 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) 19

26 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). 20

27 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 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 21

28 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 22

29 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 23

30 Figure 3.3 below is an E-R diagram showing the relationships between the key tables. M tblappointmentmultiday tblappointmentintraday day M 1 M 1 tblnurse 1 1 M 1 tblpatient tblmultiday 1 M tblmultidayvisit M 1 tblintraday 1 M tblintradayaction M tblnurseroster 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. 24

31 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 Tables The database tables were implemented in the Microsoft Access database following the schema in the design chapter, Section 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 25

32 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 The entity relationship diagram can be seen in Appendix D 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: 26

33 <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 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 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 the button can be seen with the additional code to save the pattern in tblmultiday before records can be added to tblmultidayvisit. 27

34 Me.Validate() Me.TblMultidayBindingSource.EndEdit() Me.TableAdapterManager.UpdateAll(Me.NHSDatabaseDataSet) MsgBox("Multiday Pattern Saved") Figure Screenshot and code for saving a multiday pattern 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 FROM WHERE IntradayPatternID, PatternName, TotalNumberOfSlots, NumberOfActions, Valid tblintraday (PatternName LIKE? + '%') 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 on the following page: 28

35 Figure 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 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 Screenshot of nurse filter toolstrips 29

36 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/ :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 FROM [Date], NurseID, Format(StartTime, hh:mm ) AS StartTime, Format(EndTime, hh:mm ) AS EndTime 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 Patient Appointment Output A query was written in the MS Access database using the method stated in Section 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 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: 30

37 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 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 Report display code 31

38 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 on the next page shows how an intraday schedule for a patient may be altered where the final action is delayed. 32

39 Figure Image a) in Figure 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 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: 33

40 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))); 34

41 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 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 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") 35

42 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 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 36

43 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 along with the message displayed if an invalid username or password is entered, the main menu of the application can be seen in Figure which the user is directed to if valid details are entered. Figure Login page and unsuccessful login message Figure Main menu of the application 37

44 a) File Menu b) Tools Menu Figure a) File Menu and b) Tools Menu of the application Figure 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 Figure Administrator main menu 38

45 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 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. 39

46 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. 40

47 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 41

48 All the minimum requirements which are stated in Section 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 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 42

49 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. 43

50 Question 1. Your general computer experience 2. How easy was it to navigate around the application? 3. What did you think of the layout of the forms and their consistency? 4. Were the fonts, sizes and colours used appropriate? 5. What did you think of the application performance? 6. What do you think the terminology used? 7. Do you think the system is easy to learn? 8. Do you think the system is reliable? 9. Were the error messages informative and clear? Excellent (5) Good (4) Average (3) Below Average (2) Poor (1) Administrator Prototype 10. What did you think of the layout of the interface? Do you think the application buttons are appropriate? What do you think of the colour scheme? Most positive aspect of the application Most negative aspect of the application Suggestions for improvement A range of answers were received to this. The main ones were performance, system speed and layout used The most common answer was a help facility with a search 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 44

51 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. 5 User Questionnaire Response 4 Rating 3 2 Average Minimum Question 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. 45

52 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 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. 46

53 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 47

54 shown in Figure 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. 48

55 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. 49

56 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, [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, [Accessed 09/11/2008] [10] Microsoft Develop Network, (2008), Stored Procedure Basics, SQL Server 2008 Books Online (October 2008), [Accessed 11/11/08] [11] MySQL, (2008), Why MySQL, [Accessed 11/11/08] 50

57 [12] Valade, J, (2006), PHP and MySQL for Dummies 3 rd Edition, John Wiley & Sons, 2006 [13] Hunter, S R, TechRepublic, (2008), MySQL vs PostgreSQL, [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, [Accessed 12/11/08] [17] Petroutsos, E, (2008), Mastering Microsoft Visual Basic 2008, First Edition, John Wiley & Sons [18] MSDN, (2008), Microsoft Developer Network, [Accessed 13/12/08] [19] MSDN, (2008), What Is Reusable Code?, [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 3 rd 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 51

58 [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, [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):

59 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 53

60 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 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 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. 54

61 Appendix B Project Schedule Initial Schedule 55

62 Actual Schedule 56

63 Appendix C Tables & Relationships 57

64 Appendix D UML Class for Table Adapter Manager 58

65 Appendix E Patient Appointment Report 59

66 Appendix F Test Plan Login Page Test Test Data Expected Result Success? Incorrect Username asc5mja Error Incorrect Password abc Error Correct Username, Incorrect Password scs5mja Error abc Incorrect Username, Correct Password asc5mja Error scs5mja Correct Username, Correct Password scs5mja Login Successful scs5mja MainMenu form open No information entered -Blank- Error Main Menu Test Test Data Expected Result Success? Patients button Click Button Patients form open Nurses button Click Button Nurse form open Staff Rota button Click Button Staff Rota form open Multiday Patterns button Click Button Multiday Patterns form open Intraday Patterns button Click Button Intraday Patterns form open External Scheduler button Click Button External Scheduler form open View Schedules button Click Button View Schedules form open View Reports button Click Button View Reports form open Exit button Click Button Exits Application Patients Form Test Test Data Expected Result Success? Add Patient button Click Button Add Patient form open Edit Patient button Click Button Edit Patient form open Back button Click Button Close Patients form 60

67 Add Patients Form Complete New Patient form Test Test Data Expected Result Success? Add new patient without required fields filled in Patient ID, Title, Name, Address, Multiday Pattern ID, Appointment Preference, Earliest/Latest Start date Title, Address, Other Details Add Patient to tblpatient + Display record saved message Error message 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 Search for patient on partial surname sm All patient with surname beginning sm displayed Edit a patients multiday pattern ID M3 Record updated message Edit a patients appointment preference Morning Record updated message Delete a patients ID -blank- Error message Back button Click button Close Edit Patient form Nurses Form Test Test Data Expected Result Success? Add Nurse button Click Button Add Nurse form open Edit Nurse button Click Button Edit Nurse form open Back button Click Button Close Nurse form Add Nurse Form Complete New Nurse form Test Test Data Expected Result Success? Add new nurse without required fields filled in Nurse ID, Forename, Surname, Experience, Telephone Number Forename, Surname, Add nurse to tblnurse + Display record saved message Error message 61

68 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 Search for nurse on partial surname My All nurses with surname beginning my displayed Edit a nurses experience 1 Record updated message Edit a nurses telephone number Record updated message Delete a nurses Nurse ID -blank- Error message NO Back button Click button Close Edit Nurse form Staff Rota Form Test Test Data Expected Result Success? Add Nurse Shift Date, Nurse, Start Time, End Time + Click Save button Edit Nurse Shift Date, Nurse, Start Time, End Time + Click Save button Delete Nurse Shift Select shift + Add Nurse shift record Edit Nurse shift record Delete Nurse shift Delete button record Back button Click Button Close Nurse Roster form Multiday Patterns Form Test Test Data Expected Result Success? Add Multiday Pattern button Click Button Add Multiday Pattern form open Edit Multiday Pattern button Click Button Edit Multiday Pattern form open 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 62

69 Valid Add visit days button Click button Add visit days form open + multiday pattern saved message Add new multiday pattern without Pattern Name Error message required fields filled in Back button Click Button Close Add Multiday Pattern form Visit Days Form Test Test Data Expected Result Success? Add visit days and their intraday pattern IDs Add visit days without intraday pattern IDs Search for visit days of a multiday pattern Multiday pattern ID, Multiday visit days, Intraday Pattern IDs Multiday pattern ID, Multiday Visit Multiday Pattern ID Display records saved message Error Message Display visit days records Back button Click button Close Visit Days Form 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 Search for multiday pattern on partial Multi All multiday patterns pattern name with name beginning multi displayed Edit a multiday patterns name Multiday Rename Record updated message Invalidate a multiday pattern Click button Record updated message Delete a patterns Multiday pattern ID -blank- Error message Edit a patterns visit days Click button Visit Days form open Back button Click button Close Multiday Pattern form Intraday Patterns Form Test Test Data Expected Result Success? Add Intraday Pattern button Click Button Add Intraday Pattern form open 63

70 Edit Intraday Pattern button Click Button Edit Intraday Pattern form open Back button Click Button Close Intraday Pattern form 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 Add action slots button Click button Add action slots form open + intraday pattern saved message Add new intraday pattern without required fields filled in Pattern Name Error message Back button Click Button Close Add Intraday Pattern form Intraday Action Slots Form Add action slots and their treatment names Test Test Data Expected Result Success? Add action slots without an intraday pattern ID Search for action slots of an intraday pattern Intraday pattern ID, Slot Number, Treatment Names Slot Number, Treatment Name Intraday Pattern ID Display records saved message Error Message Display action slot records Back button Click button Close Intraday Action Slots Form 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 Search for intraday pattern on partial pattern name Intra All multiday patterns with name beginning intra displayed Edit an intraday patterns name Intraday Rename Record updated message Invalidate an intraday pattern Click button Record updated message 64

71 Delete a patterns Intraday pattern ID -blank- Error message Edit action slots button Click button Intraday Action Slots form open Back button Click button Close Edit Intraday Pattern form External Scheduler Form Test Test Data Expected Result Success? Export Multiday Patterns button Click button Exports multiday pattern table into a CSV Export Multiday Visits button Click button Exports multiday visits table into a CSV Export Intraday Patterns button Click button Exports intraday pattern table into a CSV Export Intraday Actions button Click button Exports intraday pattern table into a CSV Export Patients button Click button Exports patients requiring schedules into a CSV Export Nurses button Click button Exports nurses table into a CSV Export Nurses Roster button Click button Exports future nurse roster into a CSV Export Multiday Appointments Click button Exports future multiday appointments into a CSV Export Intraday Appointments Click button Exports future intraday appointments into a CSV Import Multiday Appointments button Click button Append the multiday schedule generated from the CSV to the multiday appointments table Import Intraday Appointments button Click button Append the intraday schedule generated to the intraday appointments table Generate Schedules button Click button Trigger an external program to run Back button Click button Close external scheduler form 65

72 Schedules Form Test Test Data Expected Result Success? Multiday Appointments button Click Button Multiday Appointments form open Intraday Appointments button Click Button Intraday Appointments form open Back button Click Button Close Schedules form Multiday Appointments Form Test Test Data Expected Result Success? Search for an appointment on Appointment ID A1 Display record for appointment with ID A1 Search for appointments by date 30/03/2009 Display all appointments on 30/03/2009 Search for appointments by patient ID P2 Display all appointments for patient P2 Edit an appointments date 31/03/2009 Update record + message record updated Back button Click button Close Multiday Appointments form Intraday Appointments Form Test Test Data Expected Result Success? Search for an appointment on Appointment ID A1 Display record for appointment with ID A1 Search for appointments by date 30/03/2009 Display all intraday appointments on 30/03/2009 Edit an intraday appointments times Times (hh:mm) Update record + including altering slot times display message record updated Edit nurse assigned to a patient on an N43 Update record + intraday appointment display message record updated Back button Click button Close Intraday Appointments form 66

73 Reports Form Test Test Data Expected Result Success? View Patient Appointment button Click button Prompt for patient ID and display patients appointments View Nurse Roster button Click button Prompt for date and display nurses in work that day and their shift times View Nurse Schedules button Click button Prompt for date and nurse ID and display their patient assignments that day Back button Click button Close Reports form Administrator Prototype Test Test Data Expected Result Success? Add/Edit User Add a user, Edit Database updated existing user Delete User Delete existing user Database updated Archive Year Old Appointments Click Button Data archived Archive Nurse Roster Click Button Data archived 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. 67