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 Description Alias Occurrence

Department A specialty field to which a physician belongs to.

Specialty Each department has one or more doctor.

Doctor Any physician who has a clinic Physician Each doctor belongs to one department.

Each doctor has exactly 35 time-slots per day.

Booking 15 – Minute time slot in which the physician examine and treat a patient.

Appointment Each appointment is for one patient only.

Patient A pre-registered patient in the hospital information system who want to book an appointment with a physician through the Internet.

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

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

Attribute Description Data Type and length Nulls Multi-value

Department Dep_Code (PK)Dep_Name

Department code that uniquely identifies each department.Department name (specialty).

3-digit Integer number 25 variable characters

NONO

NONO

Doctor Doctor_ID (PK)

Doctor_fNameDoctor_lNameDep_Code (FK)

Doctor’s ID number that uniquely identifies each doctor (assigned by Human resources).

Doctor’s first nameDoctor’s last nameA 3-digit department code.

Integer

15 variable characters15 variable characters3-digit Integer number

NO

NONONO

NO

NONONO

Booking Booking_No (PK)App_DateApp_timeDoctor_ID (FK)MR_Number (FK)

Booking Number that uniquely identifies each appointmentAppointment dateAppointment timeDoctor’s ID numberPatient’s Medical Record

15-digit integer numberDateTimeInteger Integer

NONONONONO

NONONONONO

Patient MR_number (PK)Patient_fNamePatient_lName DOBSexAddressContact No.Email

Patient’s Medical Record number that uniquely identifies each patient.

Patient’s first namePatient’s last nameDate of birth Gender of the patientCity where the patient livesMobile or landline telephone numberEmail address of the patient

Integer25 variable characters25 variable charactersDate1 character (“M”/”F”)10 variable characters15-digit integer number25 variable characters

NONONONONONONOYES

NONONONONONONONO

Conceptual Database Design – Keys

Entity type Attribute Primary key Candidate key Alternate key

Department Dep_Code (PK)Dep_Name

X X

Doctor Doctor_ID (PK)Doctor_fNameDoctor_lNameDep_Code

X X

Booking Booking_No (PK)App_DateApp_timeDoctor_IDMR_Number

X X “App_DateApp_timeDoctor_ID” is a

composite alternate key

Patient MR_number (PK)Patient_fNamePatient_lName DOBSexAddressContact No.Email

X X

X

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

Integrity constraint Status Location

1. Required dataRequired data are defined (Null and not

Null)Data dictionary

2. Attribute domain Length and data types are defined Data dictionary

3. Entity integrity All primary keys are not null Data dictionary

4. Referential integrity Foreign keysFinal logical ER

Model

5. Multiplicity Checked as per user requirementsFinal logical ER

Model

6. General constraints 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.2 choosing file organization

• DBMS dependent

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