Diagrams

I.
Company Background
SCC Clinic was founded last June 18 in the year of 2011. Its former name was Dentista clinic and had been changed last
May of 2015. SCC Clinic is owned by Dr. Sheila C. Cruz and she is also the primary dentist of the clinic. SCC Clinic is consist of
six (6) employees. Two (2) of them are dental associates and four (4) staff members consists of three (3) clinic assistants and one
helper. SCC Clinic has been serving over 3,000 patients since the year it started. An approximate of eight (8) appointments are
booked and an average of 10 patients are being catered per day. The SCC Clinic offers minor and major dental procedures to
their patients and entertain patients who are walk-ins.
Patients places their appointments through phone calls or through personal visit to the clinic. The clinic assistant takes the
appointment requested by the patient by providing the schedule desired and the service that the patient needed. Patients are
required to fill in the patient appointment form that serves as the clinic initial record of the patient. The placed appointments can
be modified by the patient or clinic assistant if needed and can be done through phone call or text messages. A day before the
patients appointment, the clinic assistant notify the patient through text message and require for the patient to give confirmation.
If the patient fails to provide confirmation, his/her appointment will be cancelled. Patients can as well cancel their appointments.
SCC clinic is still practicing manual record keeping of their patients records. Patient Information form, treatment remarks,
list of services, and appointment records are all written manually and kept in file cabinets. There is an available software that the
SCCClinicOnlinePatientAppointmentSystem
owner is using to archive previous patient's records. However, doing so is taking her and her clinic assistant too much time and
effort. Thus, they see that keeping the records in a file cabinet is the better option. With the manual process that the clinic is still
practicing, it is hard for the employees to retrieve, organize, and update such records when needed.
II.
System Overview
In the current setup of SCC clinic in attending their patient appointments and tracking of records, it takes the employees
great effort and time. To lessen the manual process that the clinic is practicing, automating these processes is a good solution.
Furthermore, taking advantage of the applications that are available in the network will give the patients, staff, and dentists an
easier access to monitor and update these processes.
The
Online Patient Appointment System is an online-based patient appointment system for the benefit of the patients,
doctors and staff. This is to help them manage appointments, organize, retrieve and monitor information. In
Figure 2.1 below, the
Hierarchical Input Process Output diagram shows the high-level framework of Online Patient Appointment System.
The diagram entails what are the expected inputs of the system, the different processes that will work with the inputs and
the expected output. In the Input node, the system requires the subscription of appointment information which includes date,
time, and service needed, patient information that contains the patient demographic information such as name, contact number,
age, birthday, etc. The system also requires the inputs of patient treatment record and the list of services that the clinic offers.
These information is then performed in the Process node. The system consist of 2 major process, Manage Patient Information and
Manage Schedule Appointment. These processes will handle the information being inputted. As the processing of information is
done, the system is expected to generate relevant and necessary reports, serving as the Output of the system. These reports are
the summary of patient information and treatment record, summary of patient appointment, and the clinic workload based on the
appointments.
Figure 2.1. Hierarchical Input Process

Output Online Patient Appointment
System
To further discuss the functionalities of

Online Patient Appointment System, the
Figure 2.2
shows the use case diagram.
The use case diagram consist of three
main actors of the system; the patient, the dentist, and the clinic assistant. These actors are involved and responsible with
different use cases in the system. The patient can be categorized as new patients and old patients.
Figure 2.2. Use Case diagram of Online Patient Appointment System

III.
Business Process Flow of the System
Understanding the business process flow of Online Patient Appointment System is done in various ways. This is to see the
entities that are involved in the system and what data and its attributes are being processed and generated.
Data flow diagram (DFD) is an important technique in modeling a systems high-level detail by showing how input data is
transformed to output results through a sequence of functional transformations. In
Figure 3.1
, the diagram shows the data flow
diagram context level of Online Patient Appointment System. The entities of the system are the patients, dentists, and the clinic
assistants. These entities are where the raw data are coming from as well as receiving an output from the system.
Figure 3.2
shows the level 0 diagram of context level. It shows the more specific processes that perform every data that in the system that
may result in generation of reports and keeping in data storage. These data storage keep the information related to each other
Figure 317 Online Patient Appointment System Context Diagram
Figure 3.2 Online Patient Appointment System Context Diagram
Table 4.1. Use Case Narrative: Make New Patient Appointment

Online Patient Appointment System
Author(s): Karla Tebia
Use-Case
Name:
Make New Patient

Appointment
Use Case ID:
Priority:
Low
Date: Aug 1, 2015

Version: 1
Use Case Type:
Detail, Essential
Source:
Primary
New Patient
Business Actor:
Other
Participating
Actor:
Assistant - Receives the patient appointment schedule
Other Interested Assistant - ensures that the schedule is met by the patient.
Stakeholder:
Dentist - ensures that the patient's needs are met in a timely manner.
New Patient - wants to make changes or cancel the scheduled appointment.
Description
This use case describe the event of a new patient making an appointment to the clinic. The New Patient
must fill up the patient information form to create a new account for him/her. Once the patient is
successfully registered, s/he may procceed in creating his/her appointment.
Precondition:
The patient must be registered first before creating an appointment.
Trigger:
This use case is triggered when a new patient creates an appointment.
Typical Course
of Events:
Actor Action
System Response
Step 1: The new patient

register to the system,
providing his/her basic
demographic information
and dental history
Step 2: The system responds by validating all the required demographic

information that has been provided.
Step 3: The system verifies the patient's demographic information against
what has been previously recorded
Step 4: The system automatically logged in the new patient account after
verifying and validating the information. This will allow the patient to continue
in creating an appointment.
10
Step 5: The system responds by displaying the available schedules to choose

from.
Step 6: The patient makes
an appointment, providing
the date, time and the
service/s he/she wants to
achieve.
Step 7: The system verifies if the selected date and time is available for
scheduling an appointment
Step 8: Once verified, the system saves the scheduled appointment created
by the new patient.
Step 9: Once the appointment is scheduled, the system will generate a
summary of the scheduled appointment to serve as patient's copy.
Alternate
Courses:
Alt Step 2: The patient has not provided all the required information to process the registration. The patient
is notified of the fields that has errors and prompted to re-submit.
Alt Step 3: If the patient information is the same as what has previously recorded, it will notify the patient
that it already exist.
Alt Step 7. If the patient entered an invalid date and time, the patient is notified and required to enter
another schedule.
Conclusion
This use case concludes when the patient receives the summary of his/her appointment.
Postcondition
The appointment has been recorded and the schedule selected is changed to unavailable. If the patient
canceled the appointment, the schedule will be available again.
Business Rules
* If the patient did not confirm to his/her appointment within 24 hours, the assistant will change his
appointment status as Cancelled and will be open for patients to have their appointment.
11
Implementation, * Web screen to be provided for the patient displaying the available schedules of the clinic.
Constraints, and * Graphical User Interface for patient portals that can be accessed by new and old patients
Specification:
* Web Screen for patient application form
Assumptions:
Assistant will be notified of the new appointment created.
Open Issues:
In the current business rule, the patient has to inform the assistant for changes in the created appointment
before. Once changed, the patient has to make another confirmation of the modified appointment.
Table 4.2. Use Case Narrative: Make New Patient Appointment
12

Use-Case
Name:
Make Old Patient

Appointment
Use Case ID:
Priority:
Low
Date: Sept. 13, 2015

Version: 1
Use Case Type:
Detail, Essential
Source:
Primary
Business Actor:
Old Patient
Other
Participating
Actor:
Assistant - Receives the patient appointment schedule
Other Interested Assistant - ensures that the schedule is met by the patient.
Stakeholder:
Dentist - ensures that the patient's needs are met in a timely manner.
Old Patient - wants to make changes or cancel the scheduled appointment.
Description
This use case describe the event of an old patient making an appointment to the clinic. Since he is an old
patient, he may proceed with scheduling an appointment.
Precondition:
The old patient should login to his/her account before proceeding in making an appointment.
13
Trigger:
This use case is triggered when an old patient creates an appointment.
Typical Course
of Events:
Actor Action
System Response
Step 1:The patient wants to

view the available schedule
in the calendar.
Step 2: The system responds by displaying the available schedules to choose

from.

an appointment, providing
the date, time and the
service/s he/she wants to
achieve.
Step 4: The system verifies if the selected date and time is available for
scheduling an appointment
Step 5: Once verified, the system saves the scheduled appointment created
by the new patient.
Step 6: After the appointment is scheduled, the system will generate a
summary of the scheduled appointment to serve as patient's copy.
Alternate
Courses:
Alt Step 4. The patient will be notified that the time and date he/she selected is unavailable. The system will
require him to select another schedule or cancel the process.
Conclusion
This use case concludes when the patient receives the summary of his/her appointment.
Postcondition
The appointment has been recorded and the schedule selected is changed to unavailable. If the patient
canceled the appointment, the schedule will be available again.
Business Rules
If the patient did not confirm to his/her appointment within 24 hours, the assistant will change his
appointment status as Cancelled and will be open for patients to have their appointment.
Implementation,
* Web screen to be provided for the patient displaying the available schedules of the clinic.
14
Constraints, and * Graphical User Interface for patient portals that can be accessed by new and old patients
Specification:
* Web Screen for old patient login
Assumptions:
Assistant will be notified of the new appointment created.
Open Issues:
* In the current business rule, the patient has to inform the assistant for changes in the created appointment
before. Once changed, the patient has to make another confirmation of the modified appointment.
Table 4.3. Use Case Narrative: Manage Appointment

Use-Case
Name:
Manage Appointment
Use Case ID:
Priority:
Medium

Version: 1
Use Case Type:

Detail, Essential
Source:
Primary
Patient s/he manages his/her appointment with the schedule he/she prefers.
15
Business Actor:
Other
Participating
Actor:
Assistant Manages the patient appointment by changing schedule status and appointment information
when there are cancellations or adjustments that are being requested by the patients over the phone/
personal.
Other
Interested
Stakeholder:
Assistant - ensures that the information that is modified in the patient appointment are correct.
Dentist - ensures that the patient appointment is accommodated in his/her preferred time.
Description
This use case describes the event of a patient managing his/her appointment to the clinic.
Precondition:
The patients must identify/ enter first his account credentials before proceeding to modifying their
appointment.
Trigger:
This use case is triggered when the patient wants to modify his/her appointment information. This use case
includes editing the date and time and extends to cancellation of appointment.
Typical Course
of Events:
Actor Action
System Response
Step 1: The patient view the

list of appointments he/she
created.
Step 2: The system responds by displaying all the appointments created by

the patient.
Step 3: The patient selects

the appointment he/she
wished to modify.
Step 4: The system will display the details of the appointment selected.
Step 6: The system responds by displaying the available schedules to
16
modify his/her appointment

choose from.
by providing the appointment
date and time he/she desired. Step 7: The system verifies if the selected date and/or time is available.
Step 8: Once verified, the system saves the updated appointment
information.
Step 9: Once the appointment is updated, the system will notify the
assistant with the changes made. This will also be reflected to the workload
of the dentist.
Alternate
Courses:
Alt Step 4: The patient can select another appointment he/she likes to modify by canceling or closing the
one that is selected first.
Alt Step 7. If the patient entered an invalid date and time, the patient is notified and required to enter another
schedule.
Conclusion
This use case concludes when the patient updated information reflects to the patient calendar and when the
assistant is notified with the changes at the same time.
Postcondition
The updated appointment has been recorded. The previous schedule of the patient will be available again. If
the patient canceled the appointment, the schedule will be available again.
Business Rules
The updated appointment shall notify the dentist and the clinic assistant. The patient shall confirm with
his/her new appointment when s/he is recheached out. Otherwise, his/her updated appointment will be
cancelled and available.
Implementation, * User interface to display the patient appointments

Constraints,
* Web screen that allows the patient to update his/her appointment information
17
and
Specification:
* User interface for the assistant to see the notification that the patient did.
Assumptions:
Assistant will be notified of the updated appointment
Open Issues:
Patients don't immediately confirm to his/her appointment. Yet, on the day of their scheduled appointment,
they will show up, thus, making them wait or the dentist will have to adjust.
Table 4.4. Use Case Narrative: Cancel Appointment

Use-Case
Name:
Cancel Appointment
Use Case ID:
Priority:
Medium
Source:
Use Case ID 3
Primary
Business Actor:
Patient

Version: 1
Use Case Type:

Detail, Essential
18
Other
Participating
Actor:
Assistant The assistant can cancel an appointment of patient if the patient did not confirm or if the patient
calls to have his/her appointment to be cancelled.
Other
Interested
Stakeholder:
Assistant ensures that the request of the patient is met.

Dentist - ensures that the patient request is being accommodated.
Description
This use case describes the event of a patient cancelling his/her appointment
Precondition:
The patient must be logged in and must select an appointment he/she wants to cancel
Trigger:
This use case is triggered when the patient wants cancel his/her appointment
Typical Course
of Events:
Actor Action
System Response
Step 1: The patient cancels

the appointment he/she
selected
Step 2: The system prompts a confirmation message if the patient wishes to

cancel the appointment.
Step 3: Once the patient confirmed, the cancelled appointment will be
removed to the patient's list of scheduled appointment.
Alternate
Courses:
Alt Step 3. If the patient did not confirm, cancellation of appointment will not be processed.
Conclusion
This use case concludes when the patient confirm in deleting the appointment and it is removed in his/her
list.
Postcondition
Once the patient canceled his/ her appointment, the assistant will be notified of the action.
19
Business Rules
Cancellation of appointment can be performed with the following scenarios:

* If the patient cancelled his/her appointment personally,
* If the assistant cancelled the appointment as requested by the patient
* If the patient did not confirm to his/her appointment.
Implementation,
* User interface to display the patient appointments
Constraints,
* Web screen that shows the selected appointment with an option to cancel the appointment.
and
* Web screen that shows confirmation message for the patient before proceeding to cancellation
Specification:
Assumptions:
Assistant will be notified of cancellation that is made by the patient. If the assistant is the one who canceled
the appointment, the patient will be notified of the action.
Open Issues:
Patients who are not confirming with their appointments that leads to cancellation, yet still shows up to the
clinic, resulting to overlapping of schedule.
Table 4.5. Use Case Narrative: Register New Patient

Use-Case
Name:

Version: 1
Use Case Type:
Register New Patient
Detail, Essential
20
Use Case ID:
Priority:
Low
Source:
Use Case ID 1
Primary
Business Actor:
New Patient
Other
Participating
Actor:
Other Interested
Stakeholder:
Assistant views the information that the newly registered patient provided.
Dentist views the treatment history of the newly registered patient (if provided)
Description
This use case describes the event of a new patient registering an account to the system before proceeding
to creating appointment
Precondition:
The new patient should first visit the clinic web page and choose to create an account or create an
appointment.
Trigger:
This use case is triggered when a new patient wants to create an appointment and as a requirement, the
new patient should register an account.It can also be triggered if the new patient register first before
creating an appointment
Typical Course
of Events:
Actor Action
System Response
Step 1: The new patient
Step 2: The system responds by validating entered information; checking the
21
provides his/her
demographic
information such as
name, address, contact
number, etc.
format, and required fields.
Step 5: The patient

proceeds in submitting
his/her information.
Step 6: The system stores the information provided and will return a success
message for completing the registration.
Step3:Thesystemverifiesthepatient'sdemographicinformationagainstwhat
hasbeenpreviouslyrecorded
Step 4: The system prompts a summary of the entered patient information in
order for the patient to review his/her information.
Step 7: The system sends an email to the patient containing the temporary
password of the patient
Alt Step 2: The patient has not provided all the required information to process the registration. The patient
is notified of the fields that has errors and prompted to re-submit.
Alternate
Courses:
Alt Step 3: If the patient information is the same as what has previously recorded, it will notify the patient
that it already exist.
Alt Step 4. The new patient has an option to bo back in patient application form to make changes before
proceeding in the next part of registering his/her account.
Conclusion
This use case concludes when the new patient successfully logged in his/her newly created account and
able to proceed in creating an appointment.
Postcondition
The patient will have now an access to the system using his username and password. The temporary
password that is sent to his email is advised to be changed.
22
Business Rules
The new patient will first register an account by filling up patient information form before he/she can create
an appointment.
Implementation,
Constraints, and
Specification:
User interface with patient information form that will allow the new patient to enter his/her information.
Assumptions:
Assistant will be notified of the new appointment created and a newly registered patient.
The dentist's workload will be updated because of the newly added appointment.
Open Issues:
People who are just registering an account to the system yet not creating any appointment.
Table 4.6. Use Case Narrative: Manage Schedule

Use-Case
Name:
Manage Schedule
Use Case ID:
Priority:
High
Date: Oct. 04, 2015

Version: 1
Use Case Type:

Detail, Essential
Source:
23
Primary
Business Actor:
Assistant
Other
Participating
Actor:
Other
Interested
Stakeholder:
Dentist views the status in the calendar of schedules and might ask the assistant to make updates.
Patient asks the assistant to have his/her appointment updated
Description
This use case describes the event of an assistant managing the calendar of schedule that will be presented
to the patients who are inquiring for available schedules to make an appointment
Precondition:
The assistant should login first in her account before managing the schedule.
The dentist and/or the patient asked the assistant to do changes with the schedules of patients or a
particular appointment.
Trigger:
This use case is triggered when the assistant should do updates with the schedule or when the dentist
required the assistant to manage the schedule due to some conditions.
Typical Course
of Events:
Actor Action
System Response
Step 1: The assistant

proceeds in managing the
schedules by adding
patient appointments,
updating appointment
Step 2: The system responds with the action chosen by the assistant by
showing appropriate screens for adding, updating, and deleting appointments
and notes.
24
status and details, or

deleting/ canceling
appointments, disabling
dates due to some
conditions. The assistant
can also add notes that are
given by the dentists, like
the clinic is closed in a
specific day.
Step 3. The assistant can
save the changes she
made with the schedule.
Step 4: Once the assistant is about to save the changes, the system will show
a confirmation box before proceeding.
Step 5. The assistant has

an option to proceed or to
cancel the process.
Step 6: The system then saves the changes made and will show a message
that the action is successful.
Alt Step 2. The assistant has an option to cancel the action she chose and be directed back to the primary
page of calendar schedule.
Alternate
Courses:
Alt Step 4. The assistant has an option to cancel the changes she made and get directed back to the current
screen.
Alt Step 6. If there is an error in processing the changes made by the assistant, the system provide
notification and will ask to try again, otherwise check if the correct values are provided.
Conclusion
This use case concludes when the changes that the assistant had created is successfully saved.
25
Postcondition
The changes will then reflect to the calendar of schedule that the patients as well as the dentist is checking.
Business Rules
The changes that the assistant will do should have a consent from the dentist or the patient, verbally or
written. She should not do such actions without their consent, especially in updating and canceling
appointments.
Implementation,
Constraints,
and
Specification:
* User interface to display the calendar of schedule

* Web screen that will shows the list of schedule in tabular or grid form, and will give the assistant an option
to do actions like add, edit, update, and delete appointments.
* Web screen that shows confirmation messages in every actions before the assistant proceeds or cancel
the process.
Assumptions:
The dentist will be notified in every changes that the assistant made in the calendar of schedule.
The patient that is affected of the update should also be notified.
Open Issues:
If the assistant is not around, the dentist takes responsibility in taking notes for what changes should be
done.
Table 4.7. Use Case Narrative: Manage Patient Record

Use-Case
Manage Patient Record
Date: Oct. 04, 2015

Version: 1
Use Case Type:
26
Name:
Use Case ID:
Priority:
High
Detail, Essential
Source:
Primary
Business
Actor:
Assistant
Other
Participating
Actor:
Other
Interested
Stakeholder:
Patient requesting for changes with his/her information like contact information, address, etc.
Dentist Reviewing the patient basic information.
Description
This use case describes the event of a assistant managing the patients registered basic information.
Precondition:
The assistant should login first in her account before managing the patient record.
The dentist and/or the patient asked the assistant to do changes with the patient record
Trigger:
This use case is triggered when the assistant should do updates with the schedule or when the dentist
required the assistant to manage the schedule due to some conditions.
Typical Course
Actor Action
System Response
27
of Events:
Step 1: The assistant has

now an access in updating
the patient's' information.
She will choose the
information that will be
updated from the list of
patients.
Step 3. The assistant does
the changes in the patient's
information
Step 2: The system responds by redirecting the assistant in the screen

showing the initial information of the patient and giving her an option to
update.
Step3: The system checks if the information entered is in correct format and if
all the required fields are given.
Step 4: The system proceeds in saving the changes. It prompts an alert
message to the assistant that it is successfully saved.
Alt Step 2. The assistant has an option to cancel the action she chose and be directed back to the primary
page of calendar schedule.
Alternate
Courses:
Alt Step 3. If the entered values are incorrect, the system prompts an alert message of the error and will allow
the assistant to review and correct the wrong inputs.
Alt Step 4. If there is an error in processing the changes made by the assistant, the system provides
notification and asks to try again, otherwise checks if the correct values are provided.
Conclusion
This use case concludes when the changes that the assistant had created is successfully saved.
Postcondition
The changes will be reflected by the patients on their own account.
Business Rules
* The assistant cannot delete patient information. However, the patient information that is no longer active or
no more engagements can be moved to archive. These patient information cannot be shared except with the
28
dentist.
* The patient is not allowed to do the changes in his/her own to avoid putting incorrect information.
Implementatio
n, Constraints,
and
Specification:
* User interface to display the patient information:

* Web screen that shows the list of the patients and gives the assistant an option to select and/or modify the
information.
* Web screen that shows confirmation messages in every actions before the assistant proceeds or cancel the
process.
Assumptions:
The patient will be notified of such changes in his/ her information in his or her account.
Open Issues:
Table 4.8. Use Case Narrative: Manage Patient Treatment Record
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
A. Data Modeling
60
Entity Relationship Diagram (ERD) is used for data modeling to present the design specification of Online Patient
Appointment System. Also, the ERD of this system projects the logical structure of the database to be designed and used.
Figure 5.A.11
shows the ERD of the system. In the diagram, it entails the relevant attributes that describes the entity as
well as to show what entities are related to each other. The ERD presents of what kind of relationship does the an entity,
patient entity for instance, has with other entities in in the system.
61
62
B. Tables and Structure
63
Tables and structures of the database based on the ERD diagram in

Figure 5.A.11 projects the specification of the
columns in every table. These discuss the detailed requirements and constraints of data to be stored.
Table 5.B.1 to Table
5.B.10
shows the specific tables in the database of Online Patient Appointment System
Table Name:
tbl_dentist
Table Description
: This table consists of information of the dentists.
Purpose
: To store the information of the dentist that be then use for retrieval of information.
Fieldname
Description
Data Type
Length
isNull
dentistID
Unique identifier of the

dentist record
INT
No
lastname
Dentists last name
Text
25
No
firstname
Dentists first name
Text
25
No
gender
Dentists gender, values

are either male or female
Text
No
title
Dentist title or position
Text
50
No
emailAdd
Dentists email address
Text
50
No
userID
Reference key for the

users of the portal
INT
10
No
64
Table 5.B.1 Dentist information table
Table Name:
tbl_assistant
Table Description
: This table consists of information of the clinic assistants.
Purpose
: To store the information of the clinic assistants that be then use for retrieval of information.
Fieldname
Description
Data Type
Length
isNull
asstID

assistants record
INT
No
lastname
Assistants last name
Text
25
No
firstname
Assistants first name
Text
25
No
gender
Assistants gender, values

Text
No
emailAdd
Assistants email address
Text
50
No
userID

users of the portal
INT
10
No
65
Table 5.B.2 Clinic Assistant information table
Table Name:
tbl_patient
Table Description
: This table consists of information of the patients.
Purpose
: To store the information of the patients that be then use for retrieval of information.
Fieldname
Description
Data Type
Length
isNull
patientID

patients record
INT
10
No
lastname
Patients last name
Text
25
No
firstname
Patients first name
Text
25
No
gender
Patients gender, values

Text
No
birthday
Patients birthdate
Date
10
No
age
Patients age. It is
computed based on the
birth date
INT
No
address
Patients present address
Text
50
No
contactNo
Patients contact number
Text
11
No
66
emailAdd
Patients email address
Text
50
No
occupation
Patient's occupation. Null

if the patient is
unemployed or minor.
Text
50
Yes
parentName
Minor patients parent

name. Null if the patient is
in legal age.
Text
50
Yes
parentOccup
Minor patients parents

occupation. Null if the
patient is in legal age.
TEXT
50
Yes
userID

users of the portal
INT
10
No
Data Type
Length
isNull
Table 5.B.3 Patient information table
Table Name:
tbl_service
Table Description
: This table consists of information of the services offered.
Purpose
: To store the information of the patients that be then use for retrieval of information.
Fieldname
Description
67
serviceID

services record
INT
No
name
Name of the service
Text
50
No
description
Brief description of the

service
Text
100
Yes
estTime
Estimated time that the

service is done
INT
No
initialPrice
The initial price that the

service cost
INT
No
Table 5.B.4 Service information table
Table Name:
tbl_patient_treatment
Table Description
: This table consists of treatment record of the patient.
Purpose
: To store the treatment record of the patient and the associated appointment that the treatment is performed.
Fieldname
Description
Data Type
Length
isNull
recordID

treatment record
INT
No
apptID
Reference key of the
INT
10
No
68
appointment from the

appointment records
dentistID

dentist who created the
treatment record
INT
No
patientID

patient that the treatment
belongs to
INT
10
No
treatment
Detail
Descriptive information of
the treatment done to the
patient
TEXT
Remarks
Any additional note of the

dentist for the treatment
TEXT
500
Yes
dateTime
Date and time that the

record is added
DATE
10
No
No
Table 5.B.5 Patient Treatment Record table

Table Name:
tbl_patient_appointment
Table Description
: This table consists the information of the appointment.
Purpose
: To store the appointments of the patient and the associated to check what dates are still available and to track the
appointments of the patient.
Fieldname
Description
Data Type
Length
isNull
69
apptID

appointment record
INT
10
No
serviceID

service or list of services
selected for the
appointment
TEXT
dentistID

dentist who is assigned to
the appointment
INT
Yes
patientID

patient who created the
appointment
INT
No
date
Selected appointment
date
DATE
10
No
time
Selected appointment
time
TIME
15
No
status
Status of the appointment:

Pending, cancelled, done
TEXT
10
No
No
Table 5.B.6 Patient Appointment Table
70
Table Name:
tbl_patient_information_logs
Table Description
: This table consists the log information that the clinic assistant modify the patient information.
Purpose
: To store monitor the time of update being done by the clinic assistant to the patient information.
Fieldname
Description
Data Type
Length
isNull
patientLogID

patient log record
INT
10
No
asstID

assistant who updated the
patient information
INT
No
patientID

patient that the record is
updated
INT
10
No
dateUpdated
Date that the information

is updated
DATE
10
No
Table 5.B.7 Patient Information Logs
71
Table Name:
tbl_users
Table Description
: This table consists the log information that the clinic assistant modify the patient information.
Purpose
: To store monitor the time of update being done by the clinic assistant to the patient information.
Fieldname
Description
Data Type
Length
isNull
userID

user
INT
10
No
password
Password of the user. This

is encrypted as saved
TEXT
emailAddress
Users email address
INT
10
No
type
If the user is a patient, a

dentist, or assistant
TEXT
10
No
No
C. Interface Design
Interface design of the Online Patient Appointment System is also based in the use case narratives that are
discussed. The major functionalities in the interface are gathered from the course of action in the use case and the
business rule for the constraints. The figures below shows the different interface designs that the system has.
72
Interface Name: Website Home Page

Description: This is homepage of the public website of the clinic
Figure 5.C.1 Website Home Page

Interface Name: Patient Login
73
Description: This interface displays the login page of the patient
Figure 5.C.2 Patient Login Page
74
Interface Name: New Patient Registration

Description: This screen displays the registration form that the new patient should fill in.
75
Figure 5.C.3 New Patient Registration
76
Interface Name: Create New Patient Appointment

Description: This screen is for creating new patient appointment. This also shows the calendar of schedule.
77
Figure 5.C.4 Create New Patient Appointment
78
Interface Name: New Appointment Summary

Description: This screen is for summary of the newly created appointment
79
Figure 5.C.5 New Appointment Summary
80
Interface Name: Patient Information

Description: This is a read-only screen that shows the patient information. However, the patient can modify his/her password.
81
Figure 5.C.6 Patient Information
82
Interface Name: Patient Treatment Record

Description: This is a read-only screen that shows the patient treatment record.
83
Figure 5.C.7 Patient Treatment Record
84
Interface Name: Patient Treatment Record (View Detail)

Description: This screen shows the detailed view of the treatment record selected.
85
Figure 5.C.8 Patient Treatment Record (View Detail)
86
Interface Name: Patient Appointment View

Description: This screen shows the list of all appointments of the patient.
87
Figure 5.C.9 Patient Appointment View

Interface Name: Patient Appointment View (Details)
Description: This screen shows the details of the selected patient appointment.
88
Figure 5.C.10 Patient Appointment View (Details)

Interface Name: Cancelation of Patient Appointment
Description: This screen shows the dialog box when a patient is about to cancel the appointment.
89
Figure 5.C.11 Cancellation of Patient Appointment
Interface Name: Modify Patient Appointment

Description: This interface is for updating patient appointment information.
90
Figure 5.C.12 Modify Patient Appointment

Interface Name: Summary of Modify Patient Appointment
Description: This screen shows the summary of modified patient appointment
91
Figure 5.C.13 Summary of Modified Patient Appointment
Interface Name: Admin Login

Description: This is login page for dentists and assistants
92
Figure 5.C.14 Admin Login

Interface Name: Dentist Manage Patient Record List
Description: This screen shows the list of the patients to mange the treatment record
93
Figure 5.C.15 Dentist Manage Patient Record List
94
Interface Name: Dentist Selected Patient Record

Description: This screen shows the information of the selcted patient and the list of appointments.
95
Figure 5.C.16 Dentist Selected Patient Record
96
Interface Name: Dentist Selected Patient Treatment Record

Description: This screen shows the detailed information of the treatment selected.
97
Figure 5.C.17 Dentist Selected PatientTreatment Record
98
Interface Name: Dentist Create New treatment Record

Description: This screen allows the dentist to create new patent record.
99
Figure 5.C.18 Dentist Create New Patient Record
100
Interface Name: Dentist Manage Services List

Description: This screen shows the list of services.
101
Figure 5.C.19 Dentist Manage List of Services
Interface Name: Dentist View Selected Service

Description: This screen shows detailed view of selected service.
102
Figure 5.C.20 Dentist View selected Service

Interface Name: Dentist Modify Selected Service
Description: This screen allows the dentis to modify the selected service.
103
Figure 5.C.21 Dentist Modify selected Service
Interface Name: Dentist Inactivate Selected Service

Description: This screen allows the dentist to set the selected service as inactive.
104
Figure 5.C.22 Dentist Inactivate selected Service

Interface Name: Dentist View Workload List
Description: This screen allows the dentist to view her workload and to filter the list by date.
105
Figure 5.C.23 Dentist View Workload List
106
Interface Name: Dentist View Workload Details

Description: This screen allows the dentist to view her selected workload information.
Figure 5.C.24 Dentist View Workload Details
107
Interface Name: Dentist Manage Profile

Description: This screen allows the dentist to modify her infromation and password.
Figure 5.C.25 Dentist Manage Profile
Interface Name: Assistant Manage Profile

Description: This screen allows the assistant to modify her infromation and password.
108
Figure 5.C.26 Assistant Manage Profile
109
Interface Name: Assistant View Patient List

Description: This screen shows to the assistant the list of all patients and their status.
110
Figure 5.C.27 Assistant View Patient List
111
Interface Name: Assistant View Selected Patient Detail

Description: This screen shows to the assistant the details of the selected patient
112
Figure 5.C.28 Assistant View Selected Patient Detail
113
Interface Name: Assistant Modify Selected Patient

Description: This screen allows the assistant to modify selected patient information
114
Figure 5.C.29 Assistant Modify Selected Patient
Interface Name: Assistant Inactivate Selected Patient

Description: This screen allows the assistant to set the selected patients status as inactive
115
Figure 5.C.30 Assistant Inactivate Selected Patient

Interface Name: Assistant Calendar of Schedule
Description: This screen shows the assistant the list of Patient appointment in a selected date from the calendar of schedules
116
Figure 5.C.31 Assistant Calendar of Schedule
117
Interface Name: Assistant Calendar of Schedule - No appointment placed

Description: This screen allows the assistant to create an appointment if needed.
118
Figure 5.C.32 Assistant Calendar of Schedule - No appointment placed
119
Interface Name: Assistant Calendar of Schedule - Create New Appointment
120
Description:
This
screen
allows
the
assistant
to
create
new
appointment
121
Figure 5.C.33 Assistant Calendar of Schedule - Edit Selected Appointment
Interface Name: Assistant Calendar of Schedule - Edit Selected Appointment

Description: This screen allows the assistant to edit the selected appointment
122
Figure 5.C.34 Assistant Calendar of Schedule - Edit Selected Appointment
123
Interface Name: Reports - List of Services

Description: This screen shows the list of services report in a PDF format.
124
Figure 5.C.35 Reports - List of Services
Interface Name: Reports - List of Patients

Description: This screen shows the list of patients report in a PDF format.
125
Figure 5.C.36 Reports - List of Patient

Interface Name: Reports - Summary of Dentist Workload
Description: This screen shows the masters list of appointments assigned to the dentist. This report is in PDF format.
126
Figure 5.C.37 Reports - Summary of Dentist Workload
Interface Name: Reports - Summary of Appointment

Description: This screen shows information of the patient individual appointment details in PDF format
127
Figure 5.C.38 Reports - Summary of Appointment
Interface Name: Reports - Summary of Patient Information and Treatment Record

Description: This screen shows information of the patient as well as all of his/her treatment records in PDF format
128
129
Figure 5.C.39 Reports - Summary of Patient Information and Treatment Record

D. Architecture Design
Online Patient Appointment System use a 3-Tier Client - Server Architecture design to implement for its network.
The architecture consist of database server that caters the data access logic and data storage processes of the system.
Web application server does the application logic process of the system. Since the system is online based, sending and
requesting for data are done in web. Client server does the presentation of the system, particularly the website. The client
server can be a computer or mobile devices.
Figure 5.D.1
shows the architecture design of the system.
Figure 5.D.1 3-Tier Client - Server Architecture
130
E. Security Controls Consideration

There are security controls that are considered to ensure the safety of the information and to increase the
confidence of the end users to use the system specially for sensitive data. Developers must considered implementing
integrity and security controls. Integrity controls of the web application must include form validation, confirmation boxes,
login sessions, escaping characters and identifying limits. The system database should also contains integrity controls such
as access controls, data encryption, management controls and should have a backup and recovery to prevent the sudden
loss of data. For ensuring the network security of the system, implementing Hypertext Transport Protocol Security (HTTPS)
must be considered. This is to ensure that all transactions that are processed in every pages of the website over the
internet are secured. These securities must be considered to avoid hacking of end users information.
131
IV.
Appendices
A. Glossary of Terms
1. Class Diagram -
are the mainstay of object-oriented analysis and design. It shows the classes of the system,
their interrelationships (including inheritance, aggregation, and association), and the operations and attributes
of the classes.
132
2. Client - Server Architecture -

is a network architecture in which each computer or process on the network is
either a client or a server. Servers are powerful computers or processes dedicated to managing disk drives
(file servers), printers (print servers), or network traffic (network servers ).
3. Data Flow Diagram -
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an
information system, modelling its process aspects. A DFD is often used as a preliminary step to create an
overview of the system, which can later be elaborated.
4. Entity Relationship Diagram -
An entity-relationship diagram, or ERD, is a chart that visually represents the
relationship between database entities. ERDs model an organization's data storage requirements with three
main components:entities, attributes, and relationships.
5. Hierarchical Input Process Output (HIPO) - HIPO diagram is a combination of two organized method to
analyze the system and provide the means of documentation. HIPO model was developed by IBM in year
1970.
6. Hypertext Transport Protocol Secure (HTTPS) - It means all communications between your browser and the
website are encrypted. HTTPS is often used to protect highly confidential online transactions like online
banking and online shopping order forms.
133
7. Integrity Control - are controls integrated into the application

8. Security Control - are controls integrated in the operating and network system.
9. Use Case Diagram -
A use case diagram is a graphic depiction of the interactions among the elements of a
system. A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements.
10. Use Case Narrative - Use case narration is a textual representation of the course of events encountered when
an actor is interacting with the system. There can be several use cases associated with a system, each of
which describes the system in a functional or behavioral point of view.
B. Project Proposal
V.
References
134
rd
1. Ambler S., The Object Primer 3
Edition Agile Model Driven Development with UML 2,
http://www.ambysoft.com/books/theObjectPrimer.html, Chapter 8, 2004

2. What is Client-Server Architecture? Webopedia, www.webopedia.com/TERM/C/client_server_architecture.html
3. Data flow diagram, Wikipedia, https://en.wikipedia.org/wiki/Data_flow_diagram
4. What is ERD (Entity Relationship Diagram)?, Lucidchart, https://www.lucidchart.com/pages/what-is-ERD
5. HIPO Diagram, Tutorial Point, http://www.tutorialspoint.com/software_engineering/ software_analysis_design_tools.htm
6. What is HTTPS?, Instant SSL by Comodo, https://www.instantssl.com/ssl-certificate-products/https.html
7. Integrity & Security Controls, Designing Security Controls - Introduction a New Product
8. Integrity & Security Controls, Designing Security Controls - Introduction a New Product
9. What is use case diagram (UML use case diagram)?, whatis.techtarget.com/definition/use-case-diagram
10. Md. Popel T., Use Case Narration,
Pg 2, http://www.geocities.ws/hellopopel/use_case_narration.pdf, 2003
135

Diagrams

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diagrams

Uploaded by

Copyright:

Available Formats

I.

Figure 2.1. Hierarchical Input Process

To further discuss the functionalities of

Figure 2.2. Use Case diagram of Online Patient Appointment System

Business Process Flow of the System

Figure 317 Online Patient Appointment System Context Diagram

Figure 3.2 Online Patient Appointment System Context Diagram

Table 4.1. Use Case Narrative: Make New Patient Appointment

Make New Patient

Use Case ID:

Date: Aug 1, 2015

Assistant - Receives the patient appointment schedule

The patient must be registered first before creating an appointment.

This use case is triggered when a new patient creates an appointment.

Step 1: The new patient

Step 2: The system responds by validating all the required demographic

Step 5: The system responds by displaying the available schedules to choose

Assistant will be notified of the new appointment created.

Table 4.2. Use Case Narrative: Make New Patient Appointment

Online Patient Appointment System

Make Old Patient

Use Case ID:

Date: Sept. 13, 2015

Assistant - Receives the patient appointment schedule

This use case is triggered when an old patient creates an appointment.

Step 1:The patient wants to

Step 2: The system responds by displaying the available schedules to choose

Step 3: The patient makes

Assistant will be notified of the new appointment created.

Table 4.3. Use Case Narrative: Manage Appointment

Use Case ID:

Date: Sept. 13, 2015

Use Case Type:

Step 1: The patient view the

Step 2: The system responds by displaying all the appointments created by

Step 3: The patient selects

Step 5: The patient makes

Step 6: The system responds by displaying the available schedules to

modify his/her appointment

Implementation, * User interface to display the patient appointments

Assistant will be notified of the updated appointment

Table 4.4. Use Case Narrative: Cancel Appointment

Use Case ID:

Date: Sept. 13, 2015

Use Case Type:

Assistant ensures that the request of the patient is met.

Step 1: The patient cancels

Step 2: The system prompts a confirmation message if the patient wishes to

Cancellation of appointment can be performed with the following scenarios:

Table 4.5. Use Case Narrative: Register New Patient

Online Patient Appointment System

Date: Sept. 13, 2015

Register New Patient

Use Case ID:

Step 1: The new patient

Step 2: The system responds by validating entered information; checking the

format, and required fields.

Step 5: The patient

Table 4.6. Use Case Narrative: Manage Schedule

Online Patient Appointment System

Use Case ID:

Date: Oct. 04, 2015

Use Case Type:

Step 1: The assistant