Online Clinic Booking System

Database Design
Data Management (MIS 512)

Odai Saleem (201003500)

Introduction
Outpatient Clinic Department (OPD) is considered one of the busiest departments in the hospital.
To have an appointment with a doctor: Patients come to the OPD Book through phone. Problems in the current system: Patient may come to OPD, but doctors are fully booked. Receptionists are unable to answer the phone calls Solution Online booking system Convenient for the patients Efficient for the hospital

Outline
Database Planning Requirements Collection and Analysis System Definition Conceptual Database Design Logical Database Design Physical Database Design Conclusion

Database Planning
Mission statement

To create a database system that allows the patients to manage their appointments with their doctors in a convenient way through the internet.
Objectives

Allow the patients to book, organize and cancel their bookings through the internet. Create reports on demand.

Requirements Collection and Analysis

Five short interviews were conducted with patients to understand their needs and preferences.
Most important issues for patients:
Simple interface, doctors names and specialties are provided Dates and times are defined exactly.

Receptionists interface and doctors interface were also examined.

System Definition

System Definition
Note: patients should have:
Medical record number. Activated online booking service.

Conceptual Database Design

Conceptual Database Design - Entities

Entity Name Department Description A specialty field to which a physician belongs to. Any physician who has a clinic Alias Specialty Occurrence Each department has one or more doctor. Each doctor belongs to one department. Each doctor has exactly 35 time-slots per day.

Doctor

Physician

Booking

15 Minute time slot in which the physician examine and treat a patient.
A pre-registered patient in the hospital information system who want to book an appointment with a physician through the Internet.

Appointment

Each appointment is for one patient only.

Each patient can book many appointments with many doctors provided that appointment date, appointment time and doctor altogether are different.

Patient

Outpatients

Conceptual Database Design - Relationships

Entity name

Multiplicity

Relationship

Multiplicity

Entity name

Department

1..1

Has

1..*

Doctor

Doctor

1..1

Has

0..35

Booking

Patient

1..1

Has

1..*

Booking

Connection Traps
No fan trap or chasm trap were found.

Conceptual Database Design Attributes

Entity type
Department

Attribute Dep_Code (PK) Dep_Name Doctor_ID (PK) Doctor_fName Doctor_lName Dep_Code (FK)

Description Department code that uniquely identifies each department. Department name (specialty). Doctors ID number that uniquely identifies each doctor (assigned by Human resources). Doctors first name Doctors last name A 3-digit department code. Booking Number that uniquely identifies each appointment Appointment date Appointment time Doctors ID number Patients Medical Record Patients Medical Record number that uniquely identifies each patient. Patients first name Patients last name Date of birth Gender of the patient City where the patient lives Mobile or landline telephone number Email address of the patient

Data Type and length 3-digit Integer number 25 variable characters Integer 15 variable characters 15 variable characters 3-digit Integer number 15-digit integer number Date Time Integer Integer

Nulls NO NO NO NO NO NO NO NO NO NO NO

Multi-value NO NO NO NO NO NO NO NO NO NO NO

Doctor

Booking

Booking_No (PK) App_Date App_time Doctor_ID (FK) MR_Number (FK)

Patient

MR_number (PK) Patient_fName Patient_lName DOB Sex Address Contact No. Email

Integer 25 variable characters 25 variable characters Date 1 character (M/F) 10 variable characters 15-digit integer number 25 variable characters

NO NO NO NO NO NO NO YES

NO NO NO NO NO NO NO NO

Conceptual Database Design Keys

Entity type Department Attribute Dep_Code (PK) Dep_Name Primary key X Candidate key X Alternate key

Doctor

Doctor_ID (PK) Doctor_fName Doctor_lName Dep_Code

Booking_No (PK) App_Date App_time Doctor_ID MR_Number MR_number (PK) Patient_fName Patient_lName DOB Sex Address Contact No. Email

Booking

App_Date App_time Doctor_ID is a composite alternate key

Patient

 Enhanced Entity Relation models were not used.

Model checked no redundancy. Validation of the conceptual model against the users transactions:
List all appointments for a named doctor. List all appointments for a named patient.

 Conceptual data model reviewed with users

Logical Database Design

Logical Database Design

1. Deriving relations for the logical model The relations in this database are the followings:
Department (Dep_Code, Dep_Name) Doctor (Doctor_ID, Doctor_fName, Doctor_lName) Booking (Booking_No, App_Date, App_time) Patient (MR_number, Patient_fName, Patient_lName, DOB, Sex, Address, Contact_No, Email)

Managing one to many (1..*) relationship types

Department (Dep_Code, Dep_Name)

Primary key: Dep_Code Doctors (Doctor_ID, Doctor_fName, Doctor_lName, Dep_Code) Primary key: Doctor_ID Foreign key: Dep_Code referencing to Department relation.

 Patient (MR_number, Patient_fName, Patient_lName, DOB, Sex, Address, Contact_No, Email)

Primary key: MR_number

Booking (Booking_No, App_Date, App_time, MR_Number)

Primary key: Booking_No Foreign key: MR_Number referencing to Patient relation.

 Doctors (Doctor_ID, Doctor_fName, Doctor_lName, Dep_Code) Primary key: Doctor_ID Booking (Booking_No, App_Date, App_time, Doctor_ID, MR_Number) Primary key: Booking_No Foreign key: Doctor_ID referencing to Doctors relation. Foreign key: MR_Number referencing to Patient relation.

Validation Of Relations By Normalization

 FD: Contact_No Patient_fName, Patient_lName, DOB, Sex, Address and Email

These attributes are not unique for a single patient except for the email.

Final ER Model

Validation of relations against users transaction

The transactions still valid as in the conceptual design phase

Integrity constraints
No . 1. 2. 3. 4. Integrity constraint Status Required data are defined (Null and not Null) Length and data types are defined All primary keys are not null Location

Required data Attribute domain Entity integrity

Data dictionary Data dictionary Data dictionary Final logical ER Model Final logical ER Model ---

Referential integrity Foreign keys

5. 6.

Multiplicity General constraints

Checked as per user requirements Non exist

 The logical model reviewed with the users.

One logical model merging skipped.

Future growth
The use of this database is optional.

Expected growth rate is 100 user /month.

Physical Database Design

Base relations

 No derived data in the database design.

No other constraints are needed

File organizations and indexes

The type of file organization are dependent on the target DBMS.
4.1 Analyzing transactions: the most frequent transactions will be: Booking appointments by patients Listing the booked appointments by doctors It is also expected that patients will use the system during the day time (mainly) during all the weekdays.

 4.3 Choosing indexes

Primary index: CREATE UNIQUE INDEX bookingind ON BOOKING (booking_ID)

Secondary index: not needed.

4.4 Estimating disk space requirements Disk space is not an issue. The hospital can provide the required hardware as needed. Initially, 5 GB were allocated.

User views
Two users view are required for this database:
Patient view Doctor and admin view

Security mechanisms
System security: username and password to access the database system. Data security: Patients are allowed to access certain attributes (Department, doctor name and appointment date and time). Access to Department and Doctor tables are just read. Patient can update and delete data in the attributes appointment date and time.

Conclusion
Outpatient clinic appointment system is very useful for any hospital.

In our case, the database system we designed were simple and straightforward.

Based on Database System Development Life Cycle methodology.