Felix Fennell 11MRP

26/04/2008

Page | 1
Felix Fennell 11MRP
26/04/2008

CONTENTS

itroduction to problem.......................................................................... ..........................4

Indentifying the problem............................................................................................. ....4

Background information............................................................... ...............................5

Problems with the current system................................................................................. ..6

User requirements................................................................................... ....................6

Intended system............................................................................................ ..............6

Aims & Objectives.................................................................................................... .......7

Aims............................................................................................. ...............................7

MY Objectives........................................................................................... ...................7

Data Collection................................................................................... ............................8

Process of collecting information.......................................................... .......................8

Contacting users................................................................................................... .......8

Methods of data collection................................................................................ .........12

Proposed Questionnaires.................................................................. .........................14

Completed Questionnaires..................................................................................... ....18

Summary of findings............................................................................................ ......27

Objectives........................................................................................................... .......29

Inputs/processes/Outputs................................................................ .............................30

Example 1 – Doctor................................................................................................ ....30

Example 2 – Doctor................................................................................................ ....30

Example 3 – Patient............................................................................. ......................30

Example 4 –Patient.............................................................................. ......................31

Previous methods............................................................................ .............................31

Example 1 – Doctor................................................................................................ ....31

Example 2 - doctor..................................................................... ...............................31

Example 3 – patient.................................................................................... ...............32

Example 4 –Patient.............................................................................. ......................32

System Specification.................................................................................................. ...32

Alternatives.................................................................................. .............................34

Page | 2
Felix Fennell 11MRP
26/04/2008

justification................................................................................................ ................37

Design.......................................................................................................................... ....38

Data Structure..................................................................................... .........................38

IDENT..................................................................................................................... ....38

MEDIC (table)......................................................................................................... ....38

Patient_Info...................................................................................................... ..........39

Alternatives.................................................................................. .............................39

Justification.................................................................................................. ..............41

User Interface......................................................................................... ......................42

Input........................................................................................................ ..................42

Output............................................................................................. ..........................46

Hard Copy......................................................................................................... .........47

Hardware & software requirements............................................... ...............................51

Hardware Requirements................................................................ ............................51

Software requirements................................................................. .............................52

Alternatives.................................................................................. .............................53

Justification.................................................................................................. ..............54

Other considerations.................................................................. ...............................55

Testing................................................................................................. ......................60

Implimentation............................................................................................................ .....61

Page | 3
Felix Fennell 11MRP
26/04/2008

Analysis

ITRODUCTION TO PROBLEM

Project 2 of my ICT coursework states that I need to identify and solve an IT problem.
This involves designing and using a database, a manual, testing, and an analysis and
design of the problem.

These are some of the examples of the type of problem that I could have chosen.

• A charity database

○ This would involve a large amount of work to set up and would not be
beneficial to that many potential people to justify the workload, I am also
unsure if it is possible in the time given.

• A database on a particular animal,

○ There may not be enough scope to this system and my database would not
contain enough information to justify making it, this lack of information
may also mean that the number of users would be limited to almost
nothing.

After considering all the options available to me, I decided help a doctor with patient
information.

INDENTIFYING THE PROBLEM

The De Parys Medical centre is run by the NHS (National Health Service) and the doctors
collect information on their patients at regular intervals, they also help to provide
information about minor or common illness that are easily treatable to their patients.

However with an increasing number of patients and health targets the time needed to
collect and sort this information is needed to spend on other problems or concerns,
therefore it is a problem they understand needs to be improved. The resources spent on
giving medical information to patients is also needed in other areas of the centre as the
doctor needs to do other things.

The system needs to do the following:

• Collect information on patients (basic medical information)

• Collect information on the locations of the patients

• To provide information to patients on medical diseases or conditions.

This information is currently located in individual patient files contained within the
medical centre; information relating to diseases is given to the patients by the doctor or
through leaflets within the centre.

This based on evidence from: http://www.deparysmedical.co.uk/

Page | 4
Felix Fennell 11MRP
26/04/2008

As you can see there is no information for patients about medical information, at the
moment this information has to obtained either from leaflets in the medical centre or by
asking the doctor.

BACKGROUND INFORMATION
The De Parys Medical Centre is located in the town of Bedford and provides medical care
for the town and the surrounding area. It is spread over two sites, one in the town itself
and the other, in Bromham, is a local branch. The main site has been providing medical
care from the early 1990’s the local branch is much newer, both operate under the
Bedfordshire primary trust

The medical centre provides many of the most common services and provides easy
access to patients GPs.

For more information please visit: http://www.deparysmedical.co.uk/ or

http://www.nhs.uk/ServiceDirectories/Pages/Trust.aspx?id=5P2

Page | 5
Felix Fennell 11MRP
26/04/2008

PROBLEMS WITH THE CURRENT SYSTEM

The current problems with the system are:

• When a new patient is added to the centre a new file has to be created and
medical information re-collected, this process takes time, and are needed for
house visits, etc.

• To review a patient’s information the doctor has to have the records brought into
the room, as this happens a lot records may not be put back in the correct places
and can be lost in some cases.

• When a patient needs information on a local condition or a minor complaint they

need to go to the centre to either collect the information by ringing before hand or
seeing a doctor, this reduces the time the doctor has with other patients and puts
more pressure on the medical staff that help them.

• The patient details are not always kept up to date, for example mobile phone
number or address.

• The information is not easy to transport between one sites to another, a fax has to
be sent for example.

• The doctor has no easy way to review or analyse the patient information for
health drives for example or to know where his patients are located, if this was to
done at the moment a large amount of time is needed to collect and sort the data
before any calculations can be done on it.

USER REQUIREMENTS
The user requirements for this system are:

• Staff need an easily way to collect medical information about a patient or to

update the existing information.

• Doctors need an easy way to communicate between sites, and need access to the
patient records without having to wait for them to be faxed through.

• The patient needs to have easy access to basic medical information without
having to arrange for the information to be prepared for them or to have to drive
in to collect it.

• The doctors need to be able to easy analyse the information given by patients.

INTENDED SYSTEM

• Requires a record of patient information that can be accessed or easily transferred

between each site (database software) for the doctor

• A record of basic medical information about common complaints or diseases for

use by the patients. (database software)

• An easy way for the patient to update their information held by the doctor, either
at home or in the centre. (Some form of data based application or service)

Page | 6
Felix Fennell 11MRP
26/04/2008

• An easy way for the doctor to analyse the patient information for their uses.
(Database or spreadsheet package).

AIMS & OBJECTIVES

AIMS
My overall aim is to provide a system that can be used by the doctor & medical staff in
both sites to access patient information. To allow the patients easy access to the
information they require about basic medical diseases. The database needs to be able to
be used with a range of users with varying technical abilities.

MY OBJECTIVES
These are for the designer of the system NOT the system itself, these are discussed
later.

• I need to discuss with a doctor the needs for the system and what sort of content
needs to be displayed to who, for the both the patient information for the doctor
and the medical information needed by the patient.

• I need to analyse the problem discussed, to help chose a suitable design with the
required features.

• I need to design a number of different methods to solve the problem that meet
my users’ requirements.

• I need to build and setup the decided solution.

• I need to test the system and to remove any errors that may be found.

• I need to provide information to the users on how to use the system.

• I need to provide information to a technical user on how the system was designed
and how to improve or add to it.

Page | 7
Felix Fennell 11MRP
26/04/2008

DATA COLLECTION

PROCESS OF COLLECTING INFORMATION

To begin with the user initial needs are assessed.

After this the information is sorted to create a list of objectives based on these user
requirements. These surveys also asses if there is a need for the use of ICT to help to
improve the existing system.

CONTACTING USERS
In order to gather information from my users I needed to arrange a suitable time with the
user to access their needs for a potential new system and possible application of ICT.

These screen shots below show the e-mail being written to the doctor and response
received by the doctor.

Page | 8
Felix Fennell 11MRP
26/04/2008

USER 1
This is the e-mail sent to the doctor:

This is the response:

Page | 9
Felix Fennell 11MRP
26/04/2008

USER 2
This is the e-mail sent to the doctor:

This is the response:

Page | 10
Felix Fennell 11MRP
26/04/2008

Page | 11
Felix Fennell 11MRP
26/04/2008

USER 3
This is a transcript of a telephone call with a potential patient:

<Start of phone call>

Felix: Hello are you busy?

User: No, how can I help you?

F: I was wondering if I could talk to you some point this week to discuss the project I
mentioned last week?

U: Yeah, sure is Friday afternoon all right?

F: Perfect, thanks a lot

U: Ok, see you Friday, bye.

F: Bye.

<End of phone call>

USER 4
This request was made verbally and as the user was able to complete the questionnaire
at the time no meeting needed to be arranged.

In order to establish the needs of my users for the system I need to decide on a suitable
method of data collection. The following gives information on each method, the method I
chose, alternatives & why I chose the method I did. These some key terms:

Page | 12
Felix Fennell 11MRP
26/04/2008

METHODS OF DATA COLLECTION

KEY TERMS
Data collection: This is the method by information is collected from the target audience
or users of the system. Each different method has its own individual strengths or
weaknesses and a method suitable for one problem may not work for another.

Qualitative data: Written text or other data that is not number based, this information
can only show the subject of data and not the quantity of it.

Quantitive Data: This is data containing a quantity; the title of the information shows
the subject of the information and is in a numerical format.

INTERVIEWS

An interview provides more background information for the interviewee and if they have
a question or don’t understand the question and answer can be given immediately, if the
wrong sort of information is given back, the interviewer can adapt the question so the
correct sort of information can be given back. Using these methods means that the
interviewee is often more relaxed and will communicate more easily. However if there is a
large number of people to be interviewed, it can be a long process, requiring a
substantial amount of time.

Note: This does not mean that the data is censored but means that the answer is
relevant and makes sense.

QUESTIONNAIRES

These involve pre-written questions which the subject fills in, these can be either
sentence type questions where the answer is a full written answer or multiple choices
where a list of possible answers is given and the patient chooses one. This type of data
collection and obviously only be used for literate people, however as this is being
conducted in a medical centre this is not a concern. The other problems with this method
are that if on multiple sheets some or all of the questions or answer could be lost. Using
multiple choice style questions may not provide subjects actual opinion, rather an
approximation or generalization meaning that no focused answers can be drawn out as a
result. The advantages are that this is a good way to ask a large audience of people their
views and for information that can or needs to be broad.

SURVEYS

A survey is similar to a questioner, but the questions are asked orally, this methods does
often gives little or no extra information but means that it is easier for a subject to ask
questions about what they are doing. This method is quicker than interview as less
information is collected and using more than one person can reduce the time needed for
collecting information. However this may be intimidating for some people and as a result
won’t express their true feelings.

OBSERVATION

This method typically needs no interaction from the subject as they are being watched,
by watching the area that can be improved can be indentified and from these a design
can be proposed. This is good for when the subject does not have time to complete or
answer any of the other methods. However the problem is seen through the eyes of

Page | 13
Felix Fennell 11MRP
26/04/2008

someone else, which normally would not use the system, the person observing may not
spot the main area the subject needs addressing or may point out irreverent information.

FORMS/DOCUMENTS

This means that the forms used, to collect, store and otherwise use or manage
information within an existing system. These may not need to be physical documents but
electronic forms for example. This method requires little input for the subject and means
that data collection is very quick. However this information may not give an accurate
overview of the problems faced, leading to wasted time.

MY CHOSEN METHOD

The method I decided to use for my system were questionnaires, these would be given
out to the doctors and patients in the doctors area to collect the user’s needs.

ALTERNATIVES

There were other alternatives to the one used above to collect my data as the list above
shows but two I could have used were:

SURVEYS

These are basically the same as a questionnaire and would give the same amount of
information and in the same level of detail as before. However I choose not to use this
method because it is quite time consuming, some people may feel uncomfortable about
the nature of the questions and there was no real benefit over the questionnaire. Any
information based system is going to involve reading & writing so the advantage of being
able to ask illiterate people their views was not needed as they would not be the end
user.

FORMS/DOCUMENTS

I could have asked the doctor to give me a copy of the forms they use at the monument,
and from this decide myself where the system needs to be improved and how. However
this does not get the full opinion of the end users, especially as the only information
given is the existing system with no information relating to the new one. Therefore I
decided against using this method, as it wasn’t detailed enough and I could not gauge
the full opinions of the ends users.

JUSTIFICATION

I have decided to use the questionnaire other my other methods because it gives me a
greater audience to sample in the same amount of time, and requires no extra time or
effort from me. The use of an oral method of data collection would in my view, not have
any benefits and in the case of the interview a negative impact. This is because the
interview would have different questions to each people meaning the responses are not
balanced between two doctors.

The method of observation would clearly not be acceptable in a doctor’s medical centre
due to patient-doctor confidentiality agreements.

Page | 14
Felix Fennell 11MRP
26/04/2008

PROPOSED QUESTIONNAIRES

DOCTOR
Section 1

1. Do you or any of your staff currently collect any information about your patients?

2. What form does this information take?

3. What do you currently do with this information?

4. If a new system was introduced what would you like to do with this information?

5. What would this new system need to do?

6. To achieve this what information would be required from your patients?

7. What would need to be done to this data to make it more useful?

8. How would this information need to be shown?

9. Where would you need to access this information?

10. Would the storage of this data need any requirements?

Page | 15
Felix Fennell 11MRP
26/04/2008

11. Would the access to this data need to be controlled?

12. Are there any other requirements in this section?

Section 2

1. Do you currently recommend a personal medical diagnosis service or other similar

product?

2. What are the limitations of this product or service?

3. How would you like to improve this system?

4. What would such a system need to be able to do?

5. Would this service need to show any other information that is non-medical related
(but is related to the practice or community)

6. Where would you want this information to be accessed?

7. How would such a service help you as a doctor?

8. Would you want to the patient to be involved in the site in any way?

Page | 16
Felix Fennell 11MRP
26/04/2008

9. Are there any other requirements for this section?

Name: Date:

Thank you for your time

PATIENT
1. Do you currently use any kind of self diagnosis system?

2. If yes what or where? (please tick)

CheckBox1

CheckBox2

CheckBox3

Computer in the medical centre

3. How could this system be improved?

4. Do you use the internet?

5. Do you use the computer at the local surgery?

6. Have you used in-line medical information using internet access?

7. Would you be interested in using a service provided by your local doctor’s surgery
to help you understand the symptoms of any medical problem?

8. If such a system was created what are your main requirements as a user?

Page | 17
Felix Fennell 11MRP
26/04/2008

9. For each medical disease listed which of the following would be want to know
about a disease?

10. Would this information help to speed up an average appointment with your
doctor?

11. If your doctor requested basic medical information from you in order to help with
their service offered to you, would you feel comfortable giving this information
away?

12. What restrictions if any would you expect to be placed on your collected data?

13. At what location would you want to use this service?

14. Would you want any other information about your doctor & their practice?

15. Would you require being able to contact your doctor about any improvements to
the system?

Name: Date:

Page | 18
Felix Fennell 11MRP
26/04/2008

COMPLETED QUESTIONNAIRES
My completed surveys are shown below:

Note that these are scanned images of the original documents; the actual documents are
attached to the end of this report.

(1) DOCTOR 1

Page | 19
Felix Fennell 11MRP
26/04/2008

Page | 20
Felix Fennell 11MRP
26/04/2008

Page | 21
Felix Fennell 11MRP
26/04/2008

(2) DOCTOR 2

Page | 22
Felix Fennell 11MRP
26/04/2008

Page | 23
Felix Fennell 11MRP
26/04/2008

(3) PATIENT 1

Page | 24
Felix Fennell 11MRP
26/04/2008

Page | 25
Felix Fennell 11MRP
26/04/2008

(4) PATIENT 2

Page | 26
Felix Fennell 11MRP
26/04/2008

Page | 27
Felix Fennell 11MRP
26/04/2008

SUMMARY OF FINDINGS
These are the observations I have found after reviewing the information given by my
users, I can also conclude that in order to create the required system then ICT must be
applied to help solve the problem.

DOCTOR

The requirements of the doctor are:

• A localised system

• Easy to add information regarding the practice (staff changes)

• Easy to collect information on their patients such as:

○ Basic medical information (weight, height, etc.)

○ Allergies

○ Location

• The doctor wants this information in the form of a report rather than simply
numbers.

• The doctor wants to automatically calculate the average number of visitors & their
age profile

Page | 28
Felix Fennell 11MRP
26/04/2008

• Easy to display this information, either on screen or as a print out.

• Easy to filter information on date or by specific values (people over a certain

weight)

• Easy to receive feedback /questions on the website.

PATIENT

The requirements of the patient are:

• A system requiring limited technical skills

• To help speed up an average appointment with a doctor

• A system that informs patient’s on practice information, (staff lists, news, opening
hours)

• Able to quickly contact their doctor with suggestions/comments

Page | 29
Felix Fennell 11MRP
26/04/2008

• Able to use the system from home

OBJECTIVES
From this information I could determine the following objectives for the doctor;

• The doctor wants to easily add & edit disease information and update the
information instantly.

• The doctor wants to be able to communicate news and other information easily to
his patients.

• The doctor wants to be able to collect information from his patients in an accurate
way.

• The doctor wants to perform fast calculations on this information.

• The doctor wants to have a simple & robust system which is requires limited new
knowledge.

• The doctor wants to be able to backup the system and make it secure.

For the patient the objectives are:

• Easy to use, navigable

• Easy to find important information quickly

Page | 30
Felix Fennell 11MRP
26/04/2008

INPUTS/PROCESSES/OUTPUTS

From these objectives I was able to determine the following list of inputs, processes &
outputs for both the doctor and patient. The examples below are examples of the tasks
most likely to be performed by the users. Each example lists, the Inputs to the system,
the processing performed on that data and the output in which it is shown to the user.

EXAMPLE 1 – DOCTOR
In this example the doctor wants to calculate when the most frequent times the users
access the system and how this differs between men & women, per week

INPUTS + PROCESSING
Query to count the number of new records created in the last week, another query would
split this answer into hour groups (every 3 hours, e.g. 1200 -1500, 1500-1800, etc.) For
these answers split by gender to give the count of new records created at certain times
per gender in one week.

OUTPUT
This will create a table listing the hours of the day, (1200-1500) and the number of new
male records in one column, & the number of new female records in the other.

EXAMPLE 2 – DOCTOR
In this example the doctor wants to calculate the average weight of his patients over 35
per post code, per week

INPUTS + PROCESSING
Query to show only records in date range then, split records in patient info per post code,
another query to remove any records under 35 in age and not female. This result is then
averaged to give answers per post code.

OUTPUTS
Map of postcodes with result of each overlaid to create a visual representation, and a
graph showing the results in a bar graph with post code against weight.

EXAMPLE 3 – PATIENT
In this example a patient is searching for a disease with its name that they think begins
with the letter ‘r’ (for example if they know the name ‘rubella’ but are unable to either
spell or remember the name other than its first letter).

INPUTS + PROCESSING
Query to database with ‘r’ as criteria for disease name, only disease names with ‘r’ will
be found.

OUTPUT

Page | 31
Felix Fennell 11MRP
26/04/2008

Results of query are shown to user as a list of clickable links (hyperlinks) which will take
them to the relevant disease information page.

A hard copy of this information will also be created, using mail merge.

EXAMPLE 4 –PATIENT
In this example a patient wants information on flu whilst having already contracted the
disease themselves.

INPUTS + PROCESSEING
User searches for ‘flu ‘and chooses link for the disease, this then takes them to the
disease information page.

OUTPUT
A report style format where field information can be rearranged is used to position each
detail of the disease in the correct location for the patient to understand.

A hard copy of this information will also be created, using mail merge.

PREVIOUS METHODS

EXAMPLE 1 – DOCTOR
In this example the doctor wants to calculate when the most frequent times the users
access the system and how this differs between men & women, per week

The information on when the user has visited is not currently recorded, and as such the
most frequent times cannot be shown, also as the information is paper based counting
the number of male/female patients will be very time consuming.

My Proposed system will be able to, through a query, count and divide the number of
males/females and the website will log the times that users visit the site automatically.
These can be filtered to a certain time if needed. The results are then shown in a report
or as raw data.

EXAMPLE 2 - DOCTOR
In this example the doctor wants to calculate the average weight of his patients over 35
per post code, per week

At the moment this information would have to be captured manually, first checking all
the files to see who are over 35 years old, and of these results to tally their postcodes,
this would obviously be a very long and difficult process, especially over a large area.

My new system will automatically perform all the steps above, however it calculates
them more quickly and with a greater accuracy, for example with post codes. The system
can also output to a graph or map to allow easy interpretation.

EXAMPLE 3 – PATIENT

Page | 32
Felix Fennell 11MRP
26/04/2008

In this example a patient is searching for a disease with its name that they think begins
with the letter ‘r’ (for example if they know the name ‘rubella’ but are unable to either
spell or remember the name other than its first letter).

At the moment the user would have to ask for any information with the letter ‘r’ and
possible to describe its symptoms, the centre would then give a lot of possible diseases.

My system would ask for any part of the name to search the database, this query would
return the results and then allow the user to choose the correct name from the generated
list. Minimising the time needed.

EXAMPLE 4 –PATIENT
In this example a patient wants information on flu whilst having already contracted the
disease themselves.

At the moment this could only be possible by using the NHS website at home, which for
inexperienced users may be difficult. The user could not do to the medical centre
because they advice that persons with a contagious disease do not visit the centre for
risk of spreading the disease to venerable groups (children, babies, elderly).

With my system the user can access the doctors system from home without adversely
affecting anyone else, whilst still acquiring the information they need.

SYSTEM SPECIFICATION

From the objectives above and the inputs/processes & outputs required this would be a
basic outline for the system.

I could use a database package to store information on the disease information, and a
web package to output this information on the internet or the doctor’s local network.

In the database would be details of each disease in one table, this information would
then be uploaded to a computer to allow patients to access it. The paitent would access
this information through a webpage, this would allow them to select in some way the
disease they wanted information about. There chossen disease would be looked up in the
databse and the record shown to the user on screen. To collect information on a patient a
second table would be made to store this information. The data would be captured using
an online form; this form would hold one piece of information per field. When submitted
this information would be automatically added to the database.

This is an example:

To communicate with his patients easily the doctor could use a blog (a form of online
journal or news site) to easily contact his patients, this could also include an RSS (really
simple syndication) feed and a subscription via e-mail.

Page | 33
Felix Fennell 11MRP
26/04/2008

To make sure the data on patients was collected in the correct way the computer would
check the data for common errors and apply rules stating what information can be
accepted for a particular field, in this way only correctly entered information would be
entered.

The patient information can easily be used in calculations; this would be performed using
a form of query. These are independent from the data entered into the main table so
could update automatically each time run.

This system only needs two components, the database and the online section; these
could easily be changed without affecting any other part of the system. The skills
required to operate the system are limited to basic database knowledge. (for example
creating a report or changing a query). The online section would be maintained through a
point and click interface so again only knowledge of how to update the content would be
needed.

For security the database can be encrypted with different user groups who can only
change certain sections of the database and with a user name and password, the same
approach can be applied to any online component.

This chart below shows the typical request process for disease information:

This process diagram shows how patient information can be made into useful information
for the doctor:

Page | 34
Felix Fennell 11MRP
26/04/2008

This system would require the following hardware & software

• Doctors PC – capable of running the following software & Database program,

web browser

• Website PC – capable of running the following software & database, HTTP server

• Patient – capable of running the following software & web browser

Note: These are basic requirements, for a full specification; please see hardware &
software requirements in design.

ALTERNATIVES
As an alternative to this, I could have used a spreadsheet package to store the
information on different diseases; an information request form would then be created.
This would list the names of the diseases and the patient would write down or e-mail the
diseases they wanted more information on. This form would also have a questionnaire to
collect information on the patient. A member of the doctor’s staff would then use mail
merge with a word processer package to create a document with the details requested
by the patient. The patient information would be copied to another spreadsheet.

This diagram shows an overview of the system:

Page | 35
Felix Fennell 11MRP
26/04/2008

To send information to patients easily the doctor will create a newsletter, this will written
by the doctor and the finished letter use mail merge to be sent to either the patients
home or e-mail address. (This information is collected in the information request form
explained above).

The information on the patients will be collected when the patient requests information
on a disease. The information will be requested one fact at a time to make sure the
correct fact is collected in the correct order. For example to there would be two separate
boxes for first name & last name.

See the below example:

This collected information will add to a spreadsheet, in the form a large verity of
calculations could be performed, for example information on the number of visitors to the
site per age or weight category.

This process can be seen below:

Page | 36
Felix Fennell 11MRP
26/04/2008

These can be saved so when new information is added the calculations are performed
again to give new answers automatically.

The system would only consist of a newsletter template, a disease request sheet (with
patient info form) a spreadsheet for disease information & a spreadsheet for patient
information. The tasks of copying this information from the patient form to the
spreadsheet would ideally be carried with whoever current updates patient records.
There would only be two programs needed, one for the spreadsheet & one for the
document templates, the doctor and information updater (the user who copies the
information from form to spreadsheet) would only need to know how to use mail merge.

The system can be backed up by simply copying the files to another computer or using
an external data drive. To secure the system a password can be added to the
spreadsheets, this can prevent unauthorised people editing or viewing the file.

This system would require the following hardware & software

• Doctors PC – capable of running the following software & spreadsheet, word

processing package

• Secretaries PC – capable of running the following software & spreadsheet, word

processing package, e-mail client

• Patient PC – capable of running the following software & e-mail client, word
processor.

Page | 37
Felix Fennell 11MRP
26/04/2008

JUSTIFICATION
I have decided on my first design because it is better suited to my user requirements.

Using a database creates a more structured system where data is stored in the same way
and organised automatically by fields. This can useful to make sure the correct
information is entered and if editing that no other information is edited by accident or as
a consequence.

Using an online system allows the information to be readily available at all times and
important information is available more quickly. This system doesn’t require staff to
maintain the list of people to inform & using such a system may not be as efficient. The
required setup for an on-line form of new updating is less time consuming to set up and
can be performed in very little time.

Using an electronic form allow information to entered into the system a lot quicker than if
performed manually. The information can’t be misread or be influenced by human error
as it is transmitted from computer to computer. The information can be easily entered
into the correct places whereas in a spreadsheet changes to the layout could corrupt the
input process. Using form validation where data is checked reduces the time needed for
data checking and ensures GIGO (garbage in, garbage out) does not occur; the
information is also corrected at point of entry.

Using a query means the calculations are separate from any data where they are applied
to, this means they are a lot more versatile and are easier to use as only the actually
calculations are shown. Using a spreadsheet package is not suitable for text data and so
if calculations were to be performed using text they would not work.

The first system is more modular and so if a problem occurs to one part of the system
the other can still operate, this aids in troubleshooting and to limit any damage done to
one system from impacting another. For example if the database was corrupted or
infected with dangerous code, the user would be affected as the database not directly
accessible. Most operations in the database can be performed with a limited and basic
knowledge. This knowledge can easily be acquired. For the only section most of the
system will be pre-configured requiring limited action form the doctor. For updating the
news site they will only need to type the information they will only need to type the
information they need to convey to their patients.

To data security the database & website are separate, so the doctor is the only person
who has access, whereas the patient is simply shown the output of that database. The
information on the patient would be transmitted very quickly from computer to computer
so while interception is possible it is no harder than intercepting an e-mail. The database
can also be encrypted to allow only certain members different levels of access, whereas
with a spreadsheet, any user is able to change everything within that file.

For backup the first system the database is stored in two locations automatically and the
other information only needs to backup once. Therefore the database is the only part that
requires regular backup. The second system however will use a lot more files and on
different computers meaning that not the files may be backed up at the correct time and
if forgotten then the spreadsheets have to be recreated manually whereas the first
second uses a database in two locations so if one is affected it can be replaced with the
other, and vice-versa.

For these reasons I believe that the first system is the best for my users, and is one that
be used my design.

Page | 38
Felix Fennell 11MRP
26/04/2008

DESIGN

Using the above objectives a design can now be created to solve the problems
highlighted.

DATA STRUCTURE

These data dictionaries below show the structure of the tables contained within my
database. For reference purposes the database name is MEDIC.

The tables below are contained within this database.

IDENT
This table is used to make sure only authorised users (defined as a record within this
table) is allowed access to the doctor area of the website.

This table is used to store the login details of the doctors and other staff added by the
doctor.

Field Field Lengt Validation Description

Name Type h
Username text 10 None Primary Key
password text 10 Must contain a Shown as ‘*’ within form
number

MEDIC (TABLE)
This is the main table in the database and contains the information on each disease
which will be displayed the patients and edited by the doctor.

Field Name Field Type Leng Validation Description

th
Disease Name Text 10 None Primary Key
Affected Area Look up NA NA Links to lookup table
field
Symptoms Text 300 None The symptoms of the
disease.
Causes Text 300 None The causes of the
disease.
Treatment Text 300 None Treatments available
Severity Text 10 Must match: In form this be offered as
‘Low’ Or a drop down box with
‘Medium’ Or static values.
‘High’ Or
‘Critical’
Contagious? Yes/No N/A N/A Is the disease easily
transferable?
Self Treatable Yes/No N/A N/A Can the illness be
treated without a
prescription or medical

Page | 39
Felix Fennell 11MRP
26/04/2008

examination?
Needs check-up? Yes/No N/A N/A Does the patient need to
see their doctor soon?
Requires emergency Yes/No N/A N/A Does the disease require
services? immediate help?
Age groups affected Yes/No N/A N/A Are particular age
groups affected?
(children, Elderly)
Ethnic groups affected? Text 20 N/A Are any particular
ehtnoc groups affected?
(Asian, European, Etc.)
Particular gender Yes/No N/A N/A Is the disease sex
affected? dependant? (only affects
women)

PATIENT_INFO
This table contains the information from the patients for the doctor’s reports.

Field Field Length Validation Description

Name Type
Title Text 5 Can only be: ‘Mr.’, ‘Miss’, ‘Mrs’, Patients title
‘Dr’, ‘Prof’
First Text 10 None Primary Key
Name
Last Text 10 None
Name
Age Numbe 3 Must be between 1 and 100 Measured in years
r
Height Numbe 3 Must be between 50 and 999 Measured in CM
r
Weight Numbe 3 Must be between 1 and 600 Measured in KG
r
Gender Numbe 6 Special (see right) his is controlled by a
r drop down box with pre-
defined values, the user
chooses from one of
these fields.
Ethnic Text 20 Special (see right) This is controlled by a
Group drop down box with pre-
defined values, the user
chooses from one of
these fields.
Post Text
Code
E-Mail Text Must be formatted to: Uses spry validation at
Address <someone>.@<somewhere>.<so form level.
meplace>

There is also a hidden field Timestamp this is a hidden field is not visible to the patient
who is filling in the form, the timestamp is in the form of the time and date at which the
record is created.

This field is controlled by the database so there is no validation, length or field type for
this field.

ALTERNATIVES

Page | 40
Felix Fennell 11MRP
26/04/2008

I could have used other data structures, these are shown below:

Medic:

Field Field Length Validation Description

Name Type
Name Text None
Medical Text None
Name
Affected Text Lookup This field will lookup it’s
Area’s values from another
column
Symptom Text None
s
Causes Text None
Treatmen Text None
t
Alternativ Text None
e
treatmen
t
Contagio Yes/No None
us
999 Yes/No N/A
needed
Severity Text Lookup This field will lookup it’s
values from another
column
Life Yes/No N/A See below
threateni
ng

The addition of the medical name field will allow patients to research more information
on a particular disease more accurately.

Alternative treatment would allow a patient to view all the options available to them,
from both contemporary & alternative medicine.

Some people may already have a doctor’s appointment planned so information on if they
need one is not needed.

Whether or not a disease is life threatening can make sure people realise the full impact
of an illness and to request professional support if available.

Ethnicity is not required for a disease.

Patient Information:

I could use this table structure for the patient information:

Field Name Field Type Lengt Validation Description

h
Full Name Text 25 None The patients First & Last
Name
Date of Birth Date Must be When the patient was
NN/NN/NNNN born
Where n= number
between 0-9
Sex Text 6 Lookup This field will lookup it’s

Page | 41
Felix Fennell 11MRP
26/04/2008

values from another

column
Weight Number Must be between In KG
4 & 10000
Height Number Must be between In CM
1 & 10000
Number of children Number Between 1,10 and The number of children
must be an the patient currently has
integer
Occupation Text 25 None What the patient does
Family/genetic Text None If there are any family
conditions problems such as being
prone to heart attacks.
Frequency of visits Number Must be between How many times each
1 & 1000 week does the patient
use the system?
Post code Text 8 Must begin & end The patients post code.
with a letter, be in
two parts and both
must be 4
characters long
Address Text 40 None The patients home
address
Telephone Number Number 11 Must have area The patients phone
code followed by 6 number
digit number
Complaint Text 20 Lookup This field will lookup it’s
values from another
column
Existing doctor name Text 20 None The patients’ current
doctor (useful in a multi-
doctor practice)
Patient Notes Text 200 None This is other information
that the doctor should
know about, but that
don’t fit in any other
section.

The addition of phone, number & home address allows the doctor to update his accounts
at the same time and to see who is in which family with the number of children question.
The doctor is also able to see if a particular line of work is responsible for a particular
illness or complaint.

JUSTIFICATION
I have decided to use the first of my two designs, this is because;

The second design requested too much information from the patient. A patient will not
expect to have to reveal that amount of personal information over the internet each time
they wish to use the system.

The second design groups the patients first & last name together, this can cause a
problem when trying to use a mail merge letter and only want to show the last name.

The system was designed to only give a brief introduction to the diseases listed on the
site, therefore the medical name as suggested in design 2 is not needed since the
average user does not know what the medical name means.

Page | 42
Felix Fennell 11MRP
26/04/2008

The first design gave a more varied and balanced set of information that would be shown
to patients, where as the second listed more focused questions that could be found out
by using common sense.

For example the second design shows both severity and if the disease has a critical
severity rating then it stands to reason that there will be a significant threat to life as
well.

Other reasons include ease of use, for example the age field in the first design gives the
age in the number of years, whereas design 2 gives the age in terms of a date of birth.
Although the age can be derived from this date it is not immediately apparent to doctor,
who wants ease of use.

In terms of meeting the doctor’s objectives using a database with the suggested tables
will allow the doctor to easily enter new information and view & check the existing
information on each disease as each is stored in a different record, and each attribute in
a different field.

To collect the patient information in an accurate way is achieved using a validation both
at form level and sorting the information in an organised and structured table helps to
make sure information isn’t lost or entered into the wrong section.

Another reason that I have chosen design 1 over design 2 is that design 1 for patent info
will automatically timestamp the field, this allows greater flexibility that simply the total
time a particular patient spends on the site, which is all that is offered by design 2.

Page | 43
Felix Fennell 11MRP
26/04/2008

USER INTERFACE

INPUT
These designs are for the doctor’s user interface to enter information into the system; it
also shows the patient input form to add patient data to the database.

DOCTOR
This is where the data is entered for the MEDIC database, and the IDENT table.

DESIGN 1

This design allow information to be entered for both tables in one go, this reduces the
required button clicking for the doctor making it easier to use.

The header for the input screen is designed to show common commands that may be
needed for all inputs. The buttons in the top left section allow the doctor to view & edit
the other tables in the database so the doctor can access all the information they need
without having to use another form.

This interface s quite easy to follow as the doctor moves through each tab, new
information is entered, this is then saved at the end.

Page | 44
Felix Fennell 11MRP
26/04/2008

DESIGN 2

This design uses a more structured approach to adding the information to the database.
To begin it is clear to the doctor what information he is currently adding as the message
bar under the header shows, the use of only one table per screen also helps.

The main screen is split into three parts, these are; the sidebar, the main information
pane and the command pane.

The sidebar gives the doctor an overview of the entire database, not only allowing new
information to be added but other functions as well.

The main information pane naturally takes up the most room on the screen as it is the
most important part of the form. Another useful feature is the scroll bar, this is used
when too much information is shown on screen, and this bar allows the screen to be
moved down revelling more information.

The command bar is the final aspect of adding information to the form as it offers the
save and print commands as well as any other custom commands designed by the
doctor.

This bar will change depending on the requirements of the user.

JUSTIFICATION
I have decided to use my second design for data entry as it allows the doctor to access
all parts of the system quickly and easily. The use of the message bar tells the doctor
exactly what they are entering, and the large content area is not cluttered with other
buttons to distract or confuse the user. One advantage this design has other the other is
the simplicity. The information required to be entered is entered one after another and
moved using a simple slider whereas the other design uses a tab based system, this is
easy for the doctor to misunderstand and forget to enter the required information. For
this reason I have chosen design 2 as it is easier for the doctor to use, as per by user
requirements & objectives.

Page | 45
Felix Fennell 11MRP
26/04/2008

PATIENT

DESIGN 1

Note: Only the form is shown here, the site menu & navigation are the same
for all aspects of the site.

This design uses a new web technology called spry effects, these allow more
sophisticated layouts to used which can later the layout of the page without having to
reload any content.

This design uses one of these new effects to create a form that allows one section to
filled and when the patient moves onto the text the previous will move up to make room
for the new section, which expands to fill the form area.

This allows patients to enter information in sections without being faced with a large form
demanding lots of information.

Another feature of this design not shown in the diagram above is the use of text resizing
buttons; these allow the patient to automatically resize all the information to allow less
able patients to see the information more easily.

Page | 46
Felix Fennell 11MRP
26/04/2008

DESIGN 2

This design is very simplistic in its structure, using a simple table, this will split the input
fields form their labels, and allow them to easily aligned and create a flowing form that is
easy for patients to understand and.

JUSTIFICATION
In terms of user requirements which include ease of use and navigation I think the
second design is more suitable, this is because unlike the first design this design does
not require the user to instinctively know how to use the element, this confusion may
cause the patient to either miss out information or give up and use another more simple
system.

A reason for not choosing design 1 is that using text enlargers on webpage’s actually
reduces accessibility for a disabled user. For example the JavaScript used to control the
text changes mean that some screen readers (programs that read aloud the text on a
computer screen for a blind or partially sighted person) may be confused and so not
convey the correct information. This would be a major problem especially with medical
recommendations.

For these reasons I have decided to use design 2.

Page | 47
Felix Fennell 11MRP
26/04/2008

OUTPUT
These are the output designs for my system, both the doctor’s and the patients.

DOCTOR

DESIGN 1

This design shows the information the doctor wants to see clearly with the text under the
form heading. This is followed by a large content area in which the results of the
particular query are shown.

The small sidebar shows the other sections of the site to the user with the other reports
in the database shown first.

Page | 48
Felix Fennell 11MRP
26/04/2008

DESIGN 2

This design is similar to the previous design in terms of overall layout, however it does
make the information on which query is being viewed more obvious to the user, it also
changes the order in which the different commands & other sections of the site are
arranged on the slightly wider sidebar. This means that it is a lot easier to create a new
query & report and the language is simpler and tells the doctor exactly where they are
and what a particular option will do.

HARD COPY
As well as the electronic version the doctor may ask their staff to produce a report based
on their request. This information would be outputted using mail merge, and then printed
or sent to the doctor. This means that the doctor doesn’t have to actually make the
report.

JUSTIFICATION
In terms of ease of use both designs are roughly the same, however in terms of being
able to quickly understand the system the second design is more useful, and allows the
doctor to quickly understand what each section does, it also allows greater flexibility with
the option to create a new query more prominent.

Page | 49
Felix Fennell 11MRP
26/04/2008

PATIENT

DESIGN 1

Note: Only the form is shown here, the site menu & navigation are the same
for all aspects of the site.

This design lists the most important information first, this is the information that a
patient would most want to know and allows them to ascertain a brief overview of the
illness, the other sections list who and where the disease can be treated by. It then shows
the treatments available. The final sections shows the causes and any notes as well as
the ages & ethnic groups affected (not seen in image)

Each section is coloured differently allowing easy identification of each group of

information.

Page | 50
Felix Fennell 11MRP
26/04/2008

DESIGN 2

This design is not as highly structured as the first and is comprised of two columns of
information moving down the page, the order of the information is determined by the
structure of the table from which the information is collected from.

HARD COPY

Along this these designs a hard copy will be created, when the user has found the
reverent information. This information will be created using mail merge and a standard
template for displaying this information in the correct layout.

This is because the patient may not always have internet access or wants to refer to the
information later where no computer is available.

MAIL MERGE

A mail merge is a link between a database and a document template; the database
would typically contain the user’s first and last name for example to address the patient.
This information would be stored in a table the field names of which would be called ‘first
name’ & ‘last name’.

The document template would be written without the names for example and saved. The
user would then use a mail merge feature in the program used to create the document,
in this case a word processor. The user would select the database and table to collect the
information from; this information would then be added to the database depending on
where the user positions each field name. When completed multiple copies of the same
document would be created with a different record on each for all the records in the
database, replacing the field names.

This drawing shows the basic template for the doctor, the data in will be retrieved from
the ‘patient information page in the database:

Page | 51
Felix Fennell 11MRP
26/04/2008

JUSTIFICATION
I choose to do this instead of using a normal print button because different software and
different printers will print the same content differently. However using a mail merge
method where the layout is fixed will help to prevent this from happening.

JUSTIFICATION

The first design uses coloured sections to make differentiation of each group of fields
easier where as the second design simply lists the information with little consideration for
layout control.

Page | 52
Felix Fennell 11MRP
26/04/2008

For this reason I have decided to use design 1, as it allows easier navigation and it is far
easier to access the key information using the top section on the first design, in these
ways the first design is more suitable for my users and so was therefore chosen.

Please see attachment 2 for the actual designs

HARDWARE & SOFTWARE REQUIREMENTS

HARDWARE REQUIREMENTS
The hardware required for this system will consist of a minimum of three computers
these are listed below along with their hardware requirements:

• Doctors PC, this is the personal computer used by the doctor to add, manage &
view the system.

○ 50Mz CPU (central processing unit)

○ 256MB RAM (Random Access Memory)

○ Screen resolution of 1024 x 768

○ Network support (for internet access, access to the doctors network &
product updates)

○ CD Drive (for installation of software)

○ Keyboard & mouse (mouse is optional)

• System Server, this will run the databases used by the doctor & website, and will
also store and run the website section of the system; this is the most important
component.

○ 700Mz CPU

○ 512MB RAM

○ Network Support (for internet access, access to doctors network & product
updates)

○ CD Drive (for installation of software)

• Patients PC, this is the personal computer used by any of the doctor’s patients,
this means there is no one fixed computer and so the hardware requirements are
harder to specify, however for the purposes of this report this will viewed as a
single computer, the patient PC.

○ (depends on operating system) however a minimum is:

 300Mz CPU

 128MB RAM

 Screen resolution of 800 x 600

 Network support (internet only)

 Keyboard

Page | 53
Felix Fennell 11MRP
26/04/2008

 Mouse (optional)

Note: Only the doctors PC will be located at the doctor’s practice, as the server would be
managed remotely and housed in a purpose built environment, the patients PC will be
located in multiple places.

SOFTWARE REQUIREMENTS
The software for each of three computers is listed below; these are the minimum
requirements to be able to run the system.

• Doctors PC –

○ Microsoft® Windows®1 XP™ operating system or Microsoft® Windows

Vista™ is required to run the software applications

○ Microsoft Office® Access™ 2007 or 2003 (note: for the database to open in
Access 2003 an update has to be installed, this update will not allow all the
features of the database to be used.) This is used to administer the
database.

○ Microsoft Office® word™ 2007 or2003 (note: for the database to open in
Access 2003 an update has to be installed, this update will not allow all the
features of the database to be used.) This is used to create the template
letter for distributing the mail merged letter for the disease information.

○ HTML compatible web browser, this is used to access the website section
of the system

○ E-mail Client, used to receive the feedback from patients (it is assumed the
doctor already has an e-mail address)

○ Automattic Wordpress (hosted edition) personal blog, used to convey

important information to patients using a web interface.

• System Server

○ RED HAT™2 Linux version 7.3 or higher is required as a base operating

system

○ Apache™3 version 1.3 or above, for the correct processing of HTML

(hypertext mark-up language) pages

○ PHP version 4.1 or above, (hypertext pre-processing) as a scripting

language to display dynamic content with HTML code.

1
Windows is a registered trademark of Microsoft Corporation in the United States and
other countries
2
RED HAT is a registered trademark of Red Hat, Inc.
3
Apache is a trademark of the Apache Software Foundation

Page | 54
Felix Fennell 11MRP
26/04/2008

○ MySQL™4 version 3.23 or above, used to store the website version of the
database and process queries from the website, in this case it is a
database management system

○ phpMyAdmin version 1 or above, allows online administration of MySQL

databases (optional)

• patient PC

○ Suitable operating system, this includes any of the following Windows

operating system; Windows 95, Windows 98, Windows ME, Windows 2000,
Windows XP, Windows Vista, Windows Server 2000,2003,2008 or Windows
Vienna (blackcomb), any version of Apple Mac OS operating system
version 8 or higher, or any distribution of Linux operating system with
support for TCP/IP protocol 4.

○ HTML compatible web browser (by HTML compatible it must be able to

render XHTML pages)

○ Microsoft Office® word™ 2007 or2003 (note: for the database to open in
Access 2003 an update has to be installed, this update will not allow all the
features of the database to be used.) This allows the user to open or print
the mail merge version of the disease information.

ALTERNATIVES
I could also use the following set up as an alternative to the one above:

HARDWARE

• Doctor PC: This will run both the website section for the site and will function as
the doctors personal computer as well. The system requirements are:

○ 1Gz CPU

○ 512MB RAM

○ Screen resolution of 1024 x 768

○ Network support (for internet access, access to the doctors network &
product updates)

○ CD Drive (for installation of software)

○ Keyboard & mouse (mouse is optional)

• Patient PC: this is the personal computer used by any of the doctor’s patients,
this means there is no one fixed computer and so the hardware requirements are

4
MySQL is a trademark of Sun Microsystems Inc.

Page | 55
Felix Fennell 11MRP
26/04/2008

harder to specify, however for the purposes of this report this will viewed as a
single computer, the patient PC

○ (depends on operating system) however a minimum is:

 300Mz CPU

 128MB RAM

 Screen resolution of 800 x 600

 Network support (internet only)

 Keyboard

 Mouse (optional)

This speciation is NOT form factor specific, meaning that desktop or conventional
computer or a laptop, notebook or tablet computer can be used instead, for my
system it makes no difference.

SOFTWARE

The software listed below is the minimum required to run the system:

• Doctor PC:

○ Microsoft Windows XP or Microsoft Windows Vista with ISS support. this will
be PC’s operating system & the web sever

○ Open Office Kexi, for editing and updating the system, & to administer the
database.

○ Apple Pages, for creating the mail merged letter for the patient
information.

○ Wordpress (webware edition) this is a self hosted version of the Wordpress

blogging platform.

• Patients PC:

○ Suitable operating system, this includes any Windows operating system by

Microsoft, any version of Apple Mac OS operating system version 8 or
higher, or any distribution of Linux operating system with support for
TCP/IP protocol 4.

○ HTML compatible web browser (by HTML compatible it must be able to

render XHTML pages)

The main advantage of this system of using this system is that the system server and the
doctor’s computer is combined to reduce the overall complexability of the system, the
system is further simplified by the fact that with ISS active scripting support is built in by
default, therefore no other scripting language needs to be installed.

It also makes the system easier to trouble shoot as the number of potential problems is
reduced, it also reduces the overall cost of the system.

JUSTIFICATION

Page | 56
Felix Fennell 11MRP
26/04/2008

I decided to use the first system for several reasons, the first is reliability, the first system
is modual and while if the system server may go offline only the website will be affected
& not the doctors main computer. Having the server in a data centre is far more cost
effective than using a dedicated one, as any problems are fixed automatically, this
makes sure the doctor doesn’t have to worry about that aspect making it easy to use.

This logic is also used for Wordpress for example, although both alternatives use the
same product the implementation is different, for the first design it is hosted for free by
Wordpress and offers automatic updates to the software running the site and to the
doctor’s blog. The alternative to this is a self hosted solution which has to be installed,
set up, maintained and regularly updated to make sure it is operable, this must be design
wither by the doctor or another person. This required more money and hassle for the
doctor and as such the hosted solution is better for my user requirements.

Using PHP & MySQL is better in terms of reliability as it is more widely used & as such
more widely tested meaning that nay potential problems will have been removed making
the system more robust, IIS is also less sure than Apache

Using Microsoft Access instead of Open Office Kexi is easier for the doctor as it is a widely
used program that integrates well with other products, this means there is less likely to
be any significant training required as the basic commands are the same and no extra
software needs to bought to make the software work with the doctor’s system*

Using Microsoft Work as opposed to Apple Pages is that the doctor would probably have a
limited if not experienced knowledge of how to use Office Word, however this is not the
only reason for choosing this software, the other is that in order to run Pages proprietary
software and hardware is needed, this would make the doctor locked into a specific
hardware manufacturer, this would prevent the doctor from using any other type of
computer that is not made by Apple.

*Using the first system does require a MySQL driver in order to connect to the website
server.

Overall for the doctor I think that the first specification is better for by users needs.

For the doctor there is very little difference between the two designs and the patient
even less as the website would function exactly the same.

OTHER CONSIDERATIONS
There are some other considerations that need to be discussed now, the main
consideration is the production environment and how both the database & the website
will be created and then maintained.

CREATING THE DATABASE

The database will be created using Microsoft Office Access 2007 as this is the same
product the doctor will use to use the database be it to view reports or to enter new
information. Using the same product rather than a different database manger would be
less effective as the doctor may not be able to use the different database without
extensively modifying it first.

Note: This only applies for the initial set up of the database, after which the doctor takes
control and/or there staff.

CREATING THE WEBSITE

Page | 57
Felix Fennell 11MRP
26/04/2008

The website however has not be discussed yet and will be explained next, however the
software that will be used to create the individual pages that create a site will be coded
and created using Adobe® Dreamweaver™5CS3. This is due to several reasons; the first
is that Dreamweaver has built in support for web standards; this means that with any
compatible web browser the content will show as intended with no side effects, this
means that the doctor can more easily ensure all they’re patients can view the content,
making it easier for the doctor. Another reason is it is the leading web design program
on the market and is internationally recognised, this helps make sure that if a new web
designer takes control of the site to add new sections or edit existing ones they should
have a basic understanding of how the site was created.

Note: Dreamweaver is used to create any new content on the site with the exception of
the news section.

HUMAN COMPUTER INTERFACE (WEBSITE)

The website is used by the patient to access and view the information provided from the
doctor, this is accessed through a HTML compatible web browser (see system
requirements)

The site will consist of two main sections, these are:

• The patient Area

• The doctor Area

The patient area is around 70% of the website and contains all the medical information,
links to other resources, news, patient information data entry form & feedback form.

The doctor area is protected and allows access to the online databases and site statistics
as well as other information.

This diagram shows the full layout tree of the website:

5
Adobe & Adobe Dreamweaver are registered trademarks of Adobe systems Inc.

Page | 58
Felix Fennell 11MRP
26/04/2008

I will now explain what each part of the above diagram is:

HOMEPAGE (FILE)
This is where anybody accessing the site will be taken to; it will contain links to both
sections of the site.

PATIENT AREA (FOLDER)

This provides links to other local websites, (local hospital, care trust, etc.) as well as news
and disease information (MEDIC)

MEDIC

This contains the patient information input from which adds information to the MySQL
table patient Info.

This takes the form of a single webpage with a form containing the fields form the patient
info table, the patient enters this information and then clicks the submit button. This
invokes a server action (an action such as save or delete is performed on the web server
at the behest of a remote user, the patient in this case), which adds this information to
the table. Each field in the table is linked with a field in the table to make sure the correct
information is entered into the correct places.

This process is shown below:

Page | 59
Felix Fennell 11MRP
26/04/2008

To make sure only correct information can be entered into the table spry validation is
used, this is a type of active code that when the form is submitted checks to see if the
data is correct. These checks are defined by the designer as rules. If some data is not
correct then the form does not submit and the user has to correct it and try again. This is
to help make sure the doctor only has correct information. An example of a rule is that a
person cannot be under the age of 0.

Once the information is submitted the user is transferred to either the search page or the
body key page, (depending on user preference)

SEARCH

This page allows the user to search the entire MEDIC database from a single form.

The page holds a form with a search field and a submit button. When text is entered into
the search box and submits button is clicked the users text is converted into a query and
run on the disease name field of the MEDIC table. If any results are found they are shown
as a list of clickable links for the patient to click on. These links will take them to the
disease information page for the particular disease they clicked on.

BODY KEY

This uses a page with a picture of the human body split into different areas, (the body is
made of a number of images arranged in a table) the key works in the following way. A
patient clicks on the area of the body the disease is associated with, when clicked the
value of image is run as a query on the affected area field of the medic table. The results
are shown as a series of clickable hyperlinks which the patient uses to go to the disease
they wish to know more about. Each image has a hidden value, for example the upper
left arm has the hidden value, upper left arm.

DISEASE INFORMATION

This page displays the same layout and field names as shown in output designs above,
however in this case the values are seen for each field.

NEWS

This section displays any news submitted by the doctor. However as the doctor would
have to edit the page each time he wanted to add new information which would require
new software to be learnt and paid for, the news is not directly shown on the site.

Instead a simple blog hosted on the internet is set up. Any information entered by the
doctor is added to this blog. The blog also has a RSS feed which displays the most recent
news when subscribed to. Using a free web service called Feedburner
(http://www.feedburner.com/fb/a/home) this ‘feed’ can translated to an automatically
updating piece of code. This code when added to a web page will display the latest news
to patients on the doctor’s site, without the doctor needing to update anything other than
the blog (through a WYSIWYG [What You See Is What You Get] type interface on a
website) This makes it far easier for the doctor to use.

Page | 60
Felix Fennell 11MRP
26/04/2008

FEEDBACK

This page allows patients to express their views & opinions of the website be they good
or bad.

The page contains another form with spaces for their name, e-mail address (if they want
a response) and a large textbox for their message. When the included submit button is
clicked the form contents are converted to an e-mail message with a pre-set subject &
address. This is done by the web server and is not dependent on the user in anyway.

HELP (FOLDER)
Provides information for the doctor and patient on how to use the site providing ease of
use.

DOCTOR AREA (FOLDER)

After logging in the doctor is taken to the doctor area where the databases can be
viewed, edited, and created as well as adding news to the news section.

LOGIN

This is a set of pages shown below that make sure only authorised users can gain access
to the system, (as per user requirements & objectives)

This is achieved using a number of pages, (shown below), the most important page is the
actual login page as it contains the form used to submit the username & password, used
to allow access to the system.

The page operates in a simple way, on the login page there is a simple form, this
contains two fields and a submit button. The first field is the username and the second is
the password, when the submit button is clicked the information is sent to a MySQL table
called IDENT, which the doctor manages, the information is sent as a query to the
database. If the username and password entered match exactly any record within the
database (case sensitive) then the user is forwarded to the doctor’s area properly. If no
record is found the user is sent to a page informing them that there login has failed &
they have to login again.

This shows the structure of the login process

This shows the process of a successfully login to the system:

Page | 61
Felix Fennell 11MRP
26/04/2008

This shows the process when a login fails:

DATABASE

The database section allows the doctor to perform basic tasks, such as viewing table
information and creating new records. This is available for all the MySQL tables (see
note). This can be especially useful if the doctor needs to add a new doctor to the doctor
area when out of the practice.

NEWS

This section displays any news submitted by the doctor. However as the doctor would
have to edit the page each time he wanted to add new information which would require
new software to be learnt and paid for, the news is not directly shown on the site.

Instead a simple blog hosted on the internet is set up. Any information entered by the
doctor is added to this blog. The blog also has a RSS feed which displays the most recent
news when subscribed to. Using a free web service called Feedburner
(http://www.feedburner.com/fb/a/home) this ‘feed’ can translated to an automatically
updating piece of code. This code when added to a web page will display the latest news
to patients on the doctor’s site, without the doctor needing to update anything other than
the blog (through a WYSIWYG [What You See Is What You Get] type interface on a
website) This makes it far easier for the doctor to use.

The process is shown below:

Page | 62
Felix Fennell 11MRP
26/04/2008

MYSQL & ACCESS DATABASES

It should be noted that for each table, MEDIC, IDENT, & Patient Info there are always 2
versions. In fact there are two completely separate databases, however the information
stored within them is the same.

This is because the website can only use a MySQL table to create on the fly queries for
the doctor login, or searching for diseases. However the doctor would find it too difficult
to use the MySQL interface without extensive training. Instead the access version of the
database is linked using a driver installed on the doctor’s computer which means that
when any data is changed by the doctor in access the MySQL tables are updated as well,
meaning both databases are both the same in terms of content.

Likewise when a patient adds information to the patient info table in MySQL the new
information is downloaded to the access version as well.

Also having two databases means that if one is corrupted or damaged the other can be
easily used to rebuild it if required.

TESTING
In order to make sure that my design works with the examples used earlier in my report
and is suitable for my users I need to test my design, this will consist of inputting:

• normal data, that the system is designed to accept and process,

• Erroneous data, data that is not in the correct format, shouldn’t be accepted by
the system.

• Extreme data, outside of the limits for my system and should cause error message
to be shown to the user and shouldn’t be accepted by the system.

Test Name Objectives Input Expected Actual Result

Output

Note: Because my system has not be built yet I cannot have an actual result, for this
information please see the section titled, Testing.

Copy this table for testing

Page | 63
Felix Fennell 11MRP
26/04/2008

IMPLIMENTATION

In this section I will document how my system is actually setup and implement by
system.

Page | 64