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.
Top Related