Professional Documents
Culture Documents
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,
SCCClinicOnlinePatientAppointmentSystem
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.
SCCClinicOnlinePatientAppointmentSystem
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.
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
SCCClinicOnlinePatientAppointmentSystem
SCCClinicOnlinePatientAppointmentSystem
SCCClinicOnlinePatientAppointmentSystem
SCCClinicOnlinePatientAppointmentSystem
SCCClinicOnlinePatientAppointmentSystem
Priority:
Low
Source:
Primary
New Patient
SCCClinicOnlinePatientAppointmentSystem
Business Actor:
Other
Participating
Actor:
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:
Trigger:
Typical Course
of Events:
Actor Action
System Response
SCCClinicOnlinePatientAppointmentSystem
10
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.
SCCClinicOnlinePatientAppointmentSystem
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:
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.
SCCClinicOnlinePatientAppointmentSystem
12
Priority:
Low
Source:
Primary
Business Actor:
Old Patient
Other
Participating
Actor:
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.
SCCClinicOnlinePatientAppointmentSystem
13
Trigger:
Typical Course
of Events:
Actor Action
System Response
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.
SCCClinicOnlinePatientAppointmentSystem
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:
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.
Manage Appointment
Priority:
Medium
Source:
Primary
Patient s/he manages his/her appointment with the schedule he/she prefers.
SCCClinicOnlinePatientAppointmentSystem
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 4: The system will display the details of the appointment selected.
SCCClinicOnlinePatientAppointmentSystem
16
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.
SCCClinicOnlinePatientAppointmentSystem
17
and
Specification:
* User interface for the assistant to see the notification that the patient did.
Assumptions:
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.
Cancel Appointment
Priority:
Medium
Source:
Use Case ID 3
Primary
Business Actor:
Patient
SCCClinicOnlinePatientAppointmentSystem
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:
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
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.
SCCClinicOnlinePatientAppointmentSystem
19
Business Rules
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.
Use-Case
Name:
SCCClinicOnlinePatientAppointmentSystem
Detail, Essential
20
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
SCCClinicOnlinePatientAppointmentSystem
21
provides his/her
demographic
information such as
name, address, contact
number, etc.
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.
SCCClinicOnlinePatientAppointmentSystem
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.
Manage Schedule
Priority:
High
Source:
SCCClinicOnlinePatientAppointmentSystem
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 2: The system responds with the action chosen by the assistant by
showing appropriate screens for adding, updating, and deleting appointments
and notes.
SCCClinicOnlinePatientAppointmentSystem
24
Step 4: Once the assistant is about to save the changes, the system will show
a confirmation box before proceeding.
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.
SCCClinicOnlinePatientAppointmentSystem
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:
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.
SCCClinicOnlinePatientAppointmentSystem
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
SCCClinicOnlinePatientAppointmentSystem
System Response
27
of Events:
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
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
SCCClinicOnlinePatientAppointmentSystem
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:
Assumptions:
The patient will be notified of such changes in his/ her information in his or her account.
Open Issues:
SCCClinicOnlinePatientAppointmentSystem
29
SCCClinicOnlinePatientAppointmentSystem
30
SCCClinicOnlinePatientAppointmentSystem
31
SCCClinicOnlinePatientAppointmentSystem
32
SCCClinicOnlinePatientAppointmentSystem
33
SCCClinicOnlinePatientAppointmentSystem
34
SCCClinicOnlinePatientAppointmentSystem
35
SCCClinicOnlinePatientAppointmentSystem
36
SCCClinicOnlinePatientAppointmentSystem
37
SCCClinicOnlinePatientAppointmentSystem
38
SCCClinicOnlinePatientAppointmentSystem
39
SCCClinicOnlinePatientAppointmentSystem
40
SCCClinicOnlinePatientAppointmentSystem
41
SCCClinicOnlinePatientAppointmentSystem
42
SCCClinicOnlinePatientAppointmentSystem
43
SCCClinicOnlinePatientAppointmentSystem
44
SCCClinicOnlinePatientAppointmentSystem
45
SCCClinicOnlinePatientAppointmentSystem
46
SCCClinicOnlinePatientAppointmentSystem
47
SCCClinicOnlinePatientAppointmentSystem
48
SCCClinicOnlinePatientAppointmentSystem
49
SCCClinicOnlinePatientAppointmentSystem
50
SCCClinicOnlinePatientAppointmentSystem
51
SCCClinicOnlinePatientAppointmentSystem
52
SCCClinicOnlinePatientAppointmentSystem
53
SCCClinicOnlinePatientAppointmentSystem
54
SCCClinicOnlinePatientAppointmentSystem
55
SCCClinicOnlinePatientAppointmentSystem
56
SCCClinicOnlinePatientAppointmentSystem
57
SCCClinicOnlinePatientAppointmentSystem
58
SCCClinicOnlinePatientAppointmentSystem
59
A. Data Modeling
SCCClinicOnlinePatientAppointmentSystem
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.
SCCClinicOnlinePatientAppointmentSystem
61
SCCClinicOnlinePatientAppointmentSystem
62
SCCClinicOnlinePatientAppointmentSystem
63
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
INT
No
lastname
Text
25
No
firstname
Text
25
No
gender
Text
No
title
Text
50
No
emailAdd
Text
50
No
userID
INT
10
No
SCCClinicOnlinePatientAppointmentSystem
64
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
INT
No
lastname
Text
25
No
firstname
Text
25
No
gender
Text
No
emailAdd
Text
50
No
userID
INT
10
No
SCCClinicOnlinePatientAppointmentSystem
65
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
INT
10
No
lastname
Text
25
No
firstname
Text
25
No
gender
Text
No
birthday
Patients birthdate
Date
10
No
age
Patients age. It is
computed based on the
birth date
INT
No
address
Text
50
No
contactNo
Text
11
No
SCCClinicOnlinePatientAppointmentSystem
66
emailAdd
Text
50
No
occupation
Text
50
Yes
parentName
Text
50
Yes
parentOccup
TEXT
50
Yes
userID
INT
10
No
Data Type
Length
isNull
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
SCCClinicOnlinePatientAppointmentSystem
Description
67
serviceID
INT
No
name
Text
50
No
description
Text
100
Yes
estTime
INT
No
initialPrice
INT
No
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
INT
No
apptID
INT
10
No
SCCClinicOnlinePatientAppointmentSystem
68
INT
No
patientID
INT
10
No
treatment
Detail
Descriptive information of
the treatment done to the
patient
TEXT
Remarks
TEXT
500
Yes
dateTime
DATE
10
No
No
Description
Data Type
Length
isNull
69
apptID
INT
10
No
serviceID
TEXT
dentistID
INT
Yes
patientID
INT
No
date
Selected appointment
date
DATE
10
No
time
Selected appointment
time
TIME
15
No
status
TEXT
10
No
No
SCCClinicOnlinePatientAppointmentSystem
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
INT
10
No
asstID
INT
No
patientID
INT
10
No
dateUpdated
DATE
10
No
SCCClinicOnlinePatientAppointmentSystem
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
INT
10
No
password
TEXT
emailAddress
INT
10
No
type
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.
SCCClinicOnlinePatientAppointmentSystem
72
SCCClinicOnlinePatientAppointmentSystem
73
SCCClinicOnlinePatientAppointmentSystem
74
SCCClinicOnlinePatientAppointmentSystem
75
SCCClinicOnlinePatientAppointmentSystem
76
SCCClinicOnlinePatientAppointmentSystem
77
SCCClinicOnlinePatientAppointmentSystem
78
SCCClinicOnlinePatientAppointmentSystem
79
SCCClinicOnlinePatientAppointmentSystem
80
SCCClinicOnlinePatientAppointmentSystem
81
SCCClinicOnlinePatientAppointmentSystem
82
SCCClinicOnlinePatientAppointmentSystem
83
SCCClinicOnlinePatientAppointmentSystem
84
SCCClinicOnlinePatientAppointmentSystem
85
SCCClinicOnlinePatientAppointmentSystem
86
SCCClinicOnlinePatientAppointmentSystem
87
SCCClinicOnlinePatientAppointmentSystem
88
SCCClinicOnlinePatientAppointmentSystem
89
SCCClinicOnlinePatientAppointmentSystem
90
SCCClinicOnlinePatientAppointmentSystem
91
SCCClinicOnlinePatientAppointmentSystem
92
SCCClinicOnlinePatientAppointmentSystem
93
SCCClinicOnlinePatientAppointmentSystem
94
SCCClinicOnlinePatientAppointmentSystem
95
SCCClinicOnlinePatientAppointmentSystem
96
SCCClinicOnlinePatientAppointmentSystem
97
SCCClinicOnlinePatientAppointmentSystem
98
SCCClinicOnlinePatientAppointmentSystem
99
SCCClinicOnlinePatientAppointmentSystem
100
SCCClinicOnlinePatientAppointmentSystem
101
SCCClinicOnlinePatientAppointmentSystem
102
SCCClinicOnlinePatientAppointmentSystem
103
SCCClinicOnlinePatientAppointmentSystem
104
SCCClinicOnlinePatientAppointmentSystem
105
SCCClinicOnlinePatientAppointmentSystem
106
SCCClinicOnlinePatientAppointmentSystem
107
SCCClinicOnlinePatientAppointmentSystem
108
SCCClinicOnlinePatientAppointmentSystem
109
SCCClinicOnlinePatientAppointmentSystem
110
SCCClinicOnlinePatientAppointmentSystem
111
SCCClinicOnlinePatientAppointmentSystem
112
SCCClinicOnlinePatientAppointmentSystem
113
SCCClinicOnlinePatientAppointmentSystem
114
SCCClinicOnlinePatientAppointmentSystem
115
SCCClinicOnlinePatientAppointmentSystem
116
SCCClinicOnlinePatientAppointmentSystem
117
SCCClinicOnlinePatientAppointmentSystem
118
SCCClinicOnlinePatientAppointmentSystem
119
SCCClinicOnlinePatientAppointmentSystem
120
Description:
This
screen
SCCClinicOnlinePatientAppointmentSystem
allows
the
assistant
to
create
new
appointment
121
SCCClinicOnlinePatientAppointmentSystem
122
SCCClinicOnlinePatientAppointmentSystem
123
SCCClinicOnlinePatientAppointmentSystem
124
SCCClinicOnlinePatientAppointmentSystem
125
SCCClinicOnlinePatientAppointmentSystem
126
SCCClinicOnlinePatientAppointmentSystem
127
SCCClinicOnlinePatientAppointmentSystem
128
SCCClinicOnlinePatientAppointmentSystem
129
SCCClinicOnlinePatientAppointmentSystem
130
SCCClinicOnlinePatientAppointmentSystem
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.
SCCClinicOnlinePatientAppointmentSystem
132
SCCClinicOnlinePatientAppointmentSystem
133
V.
References
SCCClinicOnlinePatientAppointmentSystem
134
rd
1. Ambler S., The Object Primer 3
Edition Agile Model Driven Development with UML 2,
Pg 2, http://www.geocities.ws/hellopopel/use_case_narration.pdf, 2003
SCCClinicOnlinePatientAppointmentSystem
135