Online Doctor Appointment Project Database Project Report Group-04 Report submitted 27 March, 2022 A project submitted to Dr. Rudra Pra Department of Computer Science and Engineering, Chittagong University (CU) in partial fulfillment of the requirements for the Database Systems Lab course. The project is not submitted to any other organization at the same time, ap Deb Nath, Associate Professor‘Table 1: Details of Group-04 Roll | Name Sigature | Date ‘Supervisor Approval TS7OLOSL | Awiaul Karim Agizul | 24-03-2022 18707044 | Tanvoor Ahmed Tanvoor | 24-03-2022 18701047 | Mosharrof Hossain | Naiem | 2-03-2022 18701049 | Nurul Mostafa Rahat | Rahat | 21-03-2022 10701054 | Sahin Salem Sahim | 24-03-2022 10701061 | Shah Tareq Ahmed [Tareq — [24-03-2022Contents 1 Introduetion 1.1 Background and Motivation . 1.2 Problem Statement. 1.3 System Definition . . an 14 System Development Process... 15. Organization 2 Project Management 3 Requirement Gathering and analysis 3.1 Establishing Project Goals and Objectives .. . . tack-holders é 38. System Sindy... “ 34 Eliciting Requirements from Stads-holders . 3.5 System Analysis and Requirements Specifications User Requirement... . : Fiactioual and Non Funetional Requirements. - System Requirement... 4 Conceptual Modelling 5 Logical Modelling 6 Normalization 7 System Architecture 8 Implementation 9 Validation 9.1 User Manual . 9.1.1 Manual for Patient ‘ 9.2 Manual for Doctor “ . 10 Software Deployment 11 Conclusion and Future Work 12 Bibliography soooaa 10 10 10 10 ty u u u 2 14 16 18 23 28 sees 31 32 33List of Figures System Deployment Process 6 Work Updates in ‘Trello 9 Doctor Appointment System I-R Diagran u Department Relation... 00.0 cee cece eee eee ee 19 Doctor Relation . . . Patient Relation Appointment Relation 21 System Architecture 23 Doetor Login 24 Doctor's Scheduling Interface a4 Patient Registration Interface . . Doctor Admin Interface beeen Appointment Update Interface . . csegmngmer: 26 Clinie Admin Interface oe 25 List of Tables 1 Details of Group-04 . 1 Listings 1 Create Patient Table... eee aoe 2 To Project Doctors and their Respective Departments . 28 3 To see All Departments Name . . 4 Insert into Patient Table... . « 5 Insert into appointment Table 6 To soe serial of doctor 1011 in his available day.Abstract With the rapid development of technology, many man have been replaced by computerized systems all over the world as well as in our country-In this case, we will create a quick and stnooth appointment system between doctors and patients, In the conventional appointment system, patients have to stand in line a the hospitals or doctor's chambers to make an appointment, ts waste much time and do not even get an appointment ‘on the desired day. At present most of the people in Bangladesh are connected through Internet. So, through the internet, if people want to get connected to their preferred doctors, a nexus might be needed, We have planned to build a website to get an appointment for that motive. Our system could assist people to got instant help without wasting time and effort ‘oven they will got this serviee from home and overseas. By using this system, people can quickly learn about the timing of the doctor's Jing period aud make their meeting on every occasion they want The properly categorized listing will make people more comfortable browsing their anticipated doctors.1 Introduction In our dai one of the ly life, we are facing numerous problems. mest commonplace troubles in a person’ life. If anybody is ill and wants to visit a doctor for checkup, he needs to go to the hospital and wait till the doctor is available, Suppose the doctor cancels the appointment for some emergeney reason after getting the appointment. In that ease, the patient will not know about the cancellation of the appointment until he gocs to the clinic. So, it is cemncial to have a session with the doctors whenever we are infected with var- ious diseases. As the internet is now available for every person, anyone ean use the online appointment system to overcome such problems and inconve- hience for the patients. The vision of this task is to create a doctor-patient managing system to help patients book doctor appointinents and fulfil their prospeets. In this system, doctors are allowed to eontrol their hooking stots, and patients can make their appointment. to book empty spaces, too. that is the reservation system for counselling with the aid of patients’ names. ‘This system manages different. varieties of doctors simultancously, and patients can choose their anticipated one for booking. ‘This project aims to develop a database application system with the aid of making use of the theories, methodologies, tools, and technologies we learned in CSE 413, 1.1 Background and Motivation As patients, we face many difficulties when we want to get an appointment for a doctor in their chambers or hospitals. ‘The patient needs to visit their chambers or hospital to get an appointment, but it is a prolonged method and wastes patients’ time, Sometimes patients visit a doctor's chamber for a health check, but the doctor is not available for various reasons. It is the only way to know whether the doctor is available or not when the patient visits their places. It harasses patients a lot. Our motivation is that if we want to have an option to get this appointment quickly, that can be more precious. So, we have planned to implement a web-based doctor appointment system, 1.2. Problem Statement he primary aim of the *Online Doctor Appointment System” is to make ‘clean interface for patients who will apply for a doctor appointment. Ad~ ditionally, he or she ean check the doctor's availability and presents their feedhacks on which doctor treats them.1.3. System Definition An online doctor appointment. system is managed by a computerized method that allows patients to book an appointment from their places via the internet-enabled device at any time and give them their doctor's table and save patient’s details digitally 1.4. System Development Process We are using the waterfall model to develop our system. ‘The waterfall model is a classical version utilized in the system improvement life cyele to create a system with a linear and sequential approach. It is called waterfall bocanse the model develops systematically from one phase to another in a downward style, This model is split into different levels, and the output of Figure 1: System Deployment Process has one segment is used as the input of the following section, Each segm to be completed before the following phase starts, and there is no overlapping of the phases. Requirement Gathering and analysis: All possible requirements of thesystem to be developed are captured in this phase and document in a re- quirement, specification doc. Database Modeling: A database model database, including the relationships and co data can be stored and accessed. Individual database models are designed 1ows the logical structure of a traints that determine how based on the rules and concepts of whichever broader data model the design- cers adopt. System Architecture: ‘The requirement specifications from first: phase are sindied in this phase and system design is prepared. System design helps in specifying hardware and system requirements and also helps in defining overall system architecture. Implementation: With inputs from system design, the system is first devel- oped in small programs called units, which are integrated in the next phase, Each unit is developed and tested for its functionality which is referred to as lunit testing. Validation: Validation is the documented process of demonstrating that a system or process meets a defined set. of requirements, ‘There are a common set of validation documents used to provide this evidence. [I] 1.5 Organization We developed a web-based system that’s an online doctor appointment system. We have designed our workflow follows by above: Section 1 offers an overview of the project. Section 2 deseribes how the project and the resourees are managed, Section 3 briefs how to acquire re- sources and its analysis. Section 4 indicates our system E-R diagram where illustrates how to locate the entity types, relationships, and attributes. See- tion 5 offers the logical model of our system where we convert our E-R di- agram to the relational model. Section 6 has the details of our database normalization up to 3NP. Section 7 shows our system architecture how each structure eommuni- cates, and Section 8 indicates the implementation of our database. Section 9 contains the user satisfaction with our product and system user manual. Section 10 describes a way to install and configure our system so that a non- technical person can use our system. In the end, the belief and the hints to the future work are am2 Project Management In brief, the project.” Online Doctor's Appointment” is a web app designed to focus on the problem of patients making appointments quickly and saving their time by getting the proper schedule. ‘To manage and gather the assets of the whole project, we go through a technique referred to as SCRUM, Scrum is a methodology that uses an iterative and incremental approach to develop software. Throughout the project's lifecycle, Serum is designed to provide value to the customer in an adaptive, fast, flexible, and effec manner. [2] Our SCRUM master, Avizul Karim Prithibi, came up with a concept to make the doctor’s appointment system more fluent and less complex. SCRUM master created a SCRUM team consisting of 6 participants, inehud- ing him, SCRUM crew individuals are Azizul Karim, Sahim Salem, Tanvoer Ahmed, Nurul Mostafa Rabat, Shah Tareq Ahmed, and Mosharrof Hossain. Here we took a 2 months sprint to satisfy the project. Furthermore, the SCRUM master arranged an online meeting every two days.We divided into two teams firstly, team frontend and team backend. ‘The frontend group inchides Azizul Karim, Nurul Mostafa, Mosharrof Hossain, ‘This crow accumulated our designing resources from W3 schools, Boot- Strap and designed the frontend with HTML, CSS, js, bootstrap, and so on, the second group, along with Azizul Karim, Tanveer Ahmod, Shaim Salem, Shah Tareq Ahmed of the backend portion has designed sources from MySql, PHPMyAdmin, and many others. ‘Zoom software has been used to arrange the SCRUM meeting as a tool. Besides, ‘Trello has a beautiful use of updating the entirety after the SCRUM, mieotings which we have included below as a screenshot. All of the frontend and backend codes are stored in GitHub.een Ce) eee en ore) 2: Work Updates in Trello3 Requirement Gathering and analysis ‘This chapter describes how we collect requirements, study and analyse system, ‘To be able to accumulate requirements, we have to go through the following processes{i); 3.1 Establishing Project Goals and Objectives tem, we project In order to collect required data of a structured appointment 5 set np project goals and project objectives at first. The goals of o1 are following i, To create a web-based online doctor appointment. ii, ‘To manage doctor's profile related data. ‘To manage patient-related information, iv. ‘To store patient’s records in an organized and secured way for further v. ‘To overcome inconvenience or drawbacks of manual doctor appointment system. 3.2 Identifying Stack-holders ‘The following are the stack-holders of Doctor Appointment system: i. Doctors Patients Users iv. System Administrators vy, Medical record departinent 3.3. System Study ‘This Section describes how we conduct syst system requirements. We carried out the system study on patients, doctors, and many departments of hospital. The main motive of the study was to find out how we carried ont patients’ information recording process. ‘The udy to collect feasible 0rently utilized in patients, doctors, and hospitals is entirely manu ena patient requests all information be recorded manually from the appointment, and the system is very time-consuming and hesitating from the facts; doctor availability, and right time maintenance of the doctor appoint ment 3.4 Eliciting Requirements from Stack-holders ‘Throughout this section, we have to go through numerous cycles of elici- tation, documentation, and evaluations. ‘To obtain a functional specification, we have to undergo numerous confirmations, even though we can not reach to all stack-holders; we have found out difficulties of manual appointment, sy tem from patients, doctors, and, additionally, analyzed the existing online doctor appointment system. 3.5 System Analysis and Requirements Specifications During the system study segment, we have classified the requirements of the online doctor appointment system into user requirements, system require ments and functional and non-functional requirements, After analyzing the collected information, we formulated several requirements, particularly user roquirements and system hardware software attributes. We grouped this formation into user requirement, functional and non-functional requirement, and system requirement. 3.5.1 User Requirement During data collection, we investigated and found out how the eurrent system operates and attempted to find out which problems are faced and how they can be solved. The users deseribe some of the primary requirements of the system, which include the search for patients, updating the record, doctor information file, and viewing all styles of reviews. 3.5.2 Functional and Non Functional Requirements We have planned to add an online payment system to collect doctor's vis- iting fees in the future. For this consequence, we will append the acceptance of submissions in the form of the raw patient which will perform financial analysis to authenticate the system’s user, Furthermore, non-useful require- ments include the following; The system must verify to validate user's input, and the user must be notified in ease of errors detected in the databas. ul3.5.3. System Requirement This Section describes the hardware components and software require- ments necded for effective and efficient running of the system. Hardware Requirements SL Hardware Minimum System Requirement Processor 24 GHz Processor aie 2 Vem [22cm maw 3 Disk Space [00 cB Software Requirements SL Software Minimum System Requirement 1 Operating System Windows Server 2012, Windows10 2 Database — Manage- MySQL. ment System 3 Runtime Environment phpMyAdminDocumenting Requirements Afier going through all of these processes mentioned above, the following requirements wo have found Entity Attributes Relationships ‘Type Doctor doctor id doctor.natne, Has doctor email ete Patient patient.id, patient_name ‘Take patient age ete Appointment | — appointment id, Cheek appointment date etc 134 Conceptual Modelling ‘The primary stage of the database design process is conceptual design. ‘The output. of this process is a conceptual statistical model that describes the principle records entities, attributes, relationships, and constraints of a given problem area. This design is descriptive and narrative in shape. In the case of conceptual modeling, we first need to specify the fundamental components like entity types, relationships types, and attributes related to them which is done in the Requirement Gathering Section. Our conceptual data model involves i, Entity sets re a factors. ul-world objects that are our essential informat ii, Relationship sets among entity types. iii, Attributes related to entity and relationship sets, \ I-<>—4 toon |_ pee Pom Xe KAS System E-R Diagram igure 3: Doctor Appoint 4We list the entity sets and their attributes below, with primary keys underlined by revisiting the requirements gathering, and analysis phase 1. Departiment ( departinent id, departitient_name, department location) 2, Doctor ( doctor id, doctor name, doctor-email id, doctor phone.no) 3. Doctor Availability (available day, available time, maximum_appointment. capacity) 4, Appointment ( appoiniment.id, appointment. date, appointment. status) Patient ( patient. id, patient name, patient age,patient.sex, patient_phone.no)5 Logical Modelling A logical data model (LDM) deseribes data elements in detail and is used to develop visual understandings of data entities, attributes, keys, and relationships[i]. ‘This kind of model is uniquely independent. of a specific database to establish a foundational structure for the components of the se- mantic layer in data management systems. ER Model to Relational Schema: 1. Create a table for each entity 2. Entity’s attributes should become fields of tables with their respective data types. 3. Declare primary key. 4. In the case of a one-to-one relationship, we add the primary key of cither side to another side as a forcign key. In the case of a one-to-many relationship, we add the p the one side to the many sides as a foreign key imary key of 6. Create a table for a relationship if the a many-to-many relationship. 7. Add the primary keys of all participating Entities as fields of the table with their respective data types. 8. Ifa relationship has any attribute, add cach attribute as a table field, 9, Declare a primary key composing all the primary keys of participating centiti 10. Declare all foreign key constraints In our database, th many relationship between Doctor and Department. Hence, adding the primary key of Department (department. id) to Doctor as a foreign key: oO a, Department(department_id, department name, department location) b. Doctor(doctor id, doctor name, doctor.email.id, doctor phone.no) ‘There is a one-to-many relation between Doctor and Doctor_Availability. Adding primary key of Doctor(doctor id) to Doctor_Availability as a foreign key 16a, Doctor_Availability( available day, available time, maximum_appointinent.eapacity) ete is a one-to-many relation between Patient and Appointment. Adding primary key of Patient( patient id) to Appointment as a foreign key: a, Appointment appointment. id, appointment late) b. Patient patient id, patient_name, patient.age, patient.sex, patient. phone.no) ‘There is a one-to-many relation between Doctor and Appointment. In this p primary key of doctor (doctor-id) acts as a forcign key of Ap- relations!6 Normalization Normalization is the process of minimizing redundancy from a relation or set of relations. Redundancy in relation may cause insertion, deletion, and update anomalies. So, it helps to minimize the redundancy in relations. Normal forms are used to eliminate or reduce redundancy in database tables, INF (First Normal Form) Rule: If « relation contains a composite or multivalued attribute, it violates the first normal form or the relation is in first normal form if it does not contain any composite or multi-valued attribute. relation is in first normal form if every attribute in that relation is singled valued attribute 2NF (Second Normal Form) Rule: ‘To be in second normal form, a relation must be in first normal form and relation must not contain any partial dependency and all non-prime attribute in relation is fully functionally dependent on each of the candidate key. A relation is in 2NF if it has No Partial Dependency, i.e., no non-prime attribute (attributes which are not part of any candidate key) is dependent on any proper subset of any candidate key of the table. 3NF (Third normal form) Rule: \ relation is in third normal form if there is no transitive dependency for non-prime attributes as well as it is in second normal form and non-prime attributes must not determine other attributes. [5] A relation is in 3NF if at least one of the following conditions holds in every non-trivial function dependeney X+Y X is a super key. ii, Y isa prime attribute (each clement of Y is part of some candidate key). At first, we have to check each of the relations whether they are on 3NF or not, If anyone of them is not in 3NF, we will decompose it so that it wil in BNF. 1. Department: ( id, departinent_name, department location) Functional Dependencies: department. id —+{department.name, department. location} Finding Candidate key: Closure of {department id} = {department name, departinent location} As, {department.id} can uniquely identify all the attribute ferred as Super Key. And proper subset of this attribute so it is also a Candidate Key. Candidate key: {department.id) it ean be re- not super key 18Department_Name _ Department_Location _Department_ID Medicine Room - 101 101 Gynocology Room - 102 402 Dermatology Room - 103 103 Cardiology Room - 104 404 Paediatrician Room - 105 105 Physical Medicine Room - 106 106 ure 4: Department Relation Prime Attribute: {department id} Non-prime attributes: {department.name, department location} ANF: It satisfies INF as domains of all of the attributes are atomic: 2NF: There is no functional dependency as the proper subset of the eandi- date keys don’t uniquely identify any of the non-prime attributes. 3NF: Since department. id is a super key of the relation, it satisfies 3NF also. Hence, relation Department: is in 3rd Normal Form, 2. Doctor ( doctor id, doctor_name, doctor-email.id, doctor_phone.no ) ottor_id. Doctor Name, Doctor Emall_10. Doctor Phone_No Department 1D 4011 RuhulAmin TESTION@gmai‘com 2147483647 101 4012 Shakawat Hidoy TEST1012@gmaiicom 2147489647 401 4021 Nadir Mahmud TESTIO21@gmailcom 2147489647 102 4022 Sahim Salem TESTIO22@amaiicom 7147483647 402 1032 Sop TEST1032@gmailcom 2147483647 103) 1041 Arita Dey TEST1041@gmailcom 2147489647 104 1042 Act Priibee TEST1042@gmailcom 2147483647 404 1051 Shahnaz Anne [email protected] 217483647 105 41052 Nurul Mostafa Rahat test1052@omailcom 2147483647 105, 41061 Sania Tenir test1061@amalcom 2147489647 106 igure 5: Doctor Relation 19Functional Dependencies: {doctor id} — {doctor name, doctor-email id, doctor_phone.no} {doctor email id} ++ {doctor id} {doctor phone.no} -+ {doctor id} Finding Candidate keys: Closure of {doctor-id} = {doctor-name, doctor-emaiL id, doctor_phone.no} doctor-id is both candidate key and super key, Closure of {doctor-email id} = {doetor-id, doctor_name, doctor_phone.no) doctor email-id is also both candidate key and super key. Closure of {doctor.phone.no} = {doctor-id, doctor nam doctor_phone.no is also both candidate key and super ke Candidate keys:{doctor id}, {doctor-email id}, {doctor phone.no} Prime Attributes: {doctor id, doctor-email id, doctor phone.no} Non-prime-attributes: {doctor-name} LNF: All of them satisfy INF as domains of all of the attributes are atomic 2NF: Since all of the non-prime attributes are fully functionally dependent on each candidate key and there is no partial dependency on any of this functional dependencies, relation Doctor satislies 2NP. BNF: Right side of these FDs are «loctor-id, doctor-email-id, and doctor_phone-no. Each of which are super keys. Hence, ‘These FDs satisfy 3NF. ‘Thus, relation Doctor is in 8rd Normal Form. doctor_email.i 3.Patient (patient id, patient_name, patient_age, patient phone-no, patient sex) Patint.1D__ Patent. Name Patient Phone Patient Age Patient Sex 10008 Glamentine Bauch 01629830010 23. Female 10008 Evin Howell 17162604062 38 Female 10006 PaticiaLebsack 01815774386 23. Female 10009 Leanne Graham 01521410440, 44 Fomale 1000E Chelsey Dietich 017218120248 35 Female 1000 Kurs Weissnat_ 017327290322 25 Malo 10003 Nicholas Runolsdotir 017333892039 55 Male 1000H Glenna Reichert 014805765743 45. Female Figure 6: Patient Relation 20Functional Dependencies: {patient.id} + {patient.name, patient.age, patient. pho {patient.phone.no} + {patient id} Finding Candidate key: Closure of {patient.id} = {paticnt.name, patient age, patie Hence, patient-id is both candidate key and super key. And closure of {patient_phone-no} {patient id, patient_name, patient. patient sex} ‘Thus, phone-no is also both super key and candidate key. Candidate keys: {patient id}, {patient_phone-no} Prime Attributes: {patient.id, patient_phone.no} Non-prime-attributes: {patient_name, patient.age, patient.sex} ANF: All of them satisfy INF as domains of all of the attributes are atomic, 2NF: Since all of the non-prime attributes are fully functionally dependent on each candidate key and there is no partial dependency on any of this functional dependencies, relation Patient satisfies 2NF. BNF: Right side of these FDs are patientid, and patient. phone.no. Each of which are super keys. Hence, These Ds satisfy 3NF ‘Thus, relation Patient is in 3rd Normal Yoru, 4. Appointment, (appointment.id, appointment date) 20, patient. sex} -phone-no, patient sex} Appointment_ID _Appointment_Date Patient_ID_Doctor_id 1001 2022-04-10 100A 1011 4002, 2022-04-40 10008 1011 1003 2022.04.12 1000¢ 1011 1004 2022.04.12 70000 1011 1005 2022.04.15 10006 1011 Figure 7: Appointment Relation a1Functional Dependencies: {appointment id} {appointment date} Finding Candidate keys: Closure of {appointment id} —+ {appointment date} Hence, appointment.id is both a super key and a candidate key Candidate key: {appointment-id} Prime Attribute: {appointment id} Non-prime-attribute: {appointment.date} LNF: It satisfies INF as domains of all of the attributes are atomic 2NF: There is no functional dependency as the proper subset of the candi- date keys don't uniquely identify any of the non-prime attributes. ince appointment. id is a super key of the relation, it satisfies 3NF Hence, relation Appointment is in 3rd Normal Form,7 System Architecture A system architecture diagram is the distribution of the functional cor- respondences. ‘These are formal elements, the embodiment of concepts and information. Architecture defines the relations between elements, amongst features, and the surrounding elements{(} [= =) SS] J] Figure 8: System Architecture In our Advanced Clinie’s Doctors Appointment Management System , there are in total 6 interface, Each of them are described below: 23Doctor’s login: In this interface, doctor ean login using e.mail, doctor id, password and ean go to doctor's admin interface DOOCTOR LOG IN Figure 9: Doetor Login Doctor's Scheduling: Doctor can set schedule for his/her patient for next days. Set Schedule Figure 10: Doctor's Scheduling Interface 24Patient Registration: Patient can register by giving information about patient name, age, gender, mobile-number, choosing doctor and suitable date to take appointment or login(if old patient) by giving patient. ID, choosing doctor and suitable date. After login they can sce their updates of appoint- ment only for that doctor who he/she have chosen as a doctor. REGISTER A NEW PATIENT igure U1: Pati at Registration Interface 25Doctor's Admin: In this interface, doctor ean wateh his recent sched- ule along with details of recent schedule’s patient. Also can go to doct scheduling interface. Doctor Activities Schedule Recent Schedules ‘Appointment List seis sheeted deo dun Figure 12: Doctor Adinin Interlace Appointment updates: Patient can watch their updates by giving patient id for all doctors he/she have appointments with or past schedule of doctors whom he/she have already visited CHEACK YOUR SERIAL Figure 13: Appointment Update Interface 26Clinic Admin: Can delete existing doctor, department or add new doe tor, department. ADD A New Doctor Clinic Admin Interface8 Implementation L CREATE TABLE Patient c Patient_ID VARCHAR(20) NOT NULL, Patient_Name VARCHAR(20) NOT NULL, Patient_Email_ID VARCHAR(20) NOT NULL, Patient_Phone VARCHAR(20) NOT NULL, Patient_Address VARCHAR(20) NOT NULL, Patient_Age INT NOT NULL, Patient_Sex VARCHAR (20) NOT NULL, PRIMARY KEY (Patient_ID) ting 6 shows an SQL query. Listing 1: Create Patient Table SELECT Do.Doctor_Name, DE.Department_Name FROM doctor AS Do JOIN department AS DE WHERE Do.Department_ID = DE.Department_ID; Li ing 2: To Project Doctors and their Respective Departments SELECT Department_Name FROM department ; Listing 3: To see All Departments Name INSERT INTO patient (Patient_ID, Patient_Name, Patient_Phone, Patient_Age, Patient_Sex) VALUES(*$patient_id’, ’Sname’, "$mobile’, ’Sage’, ’ Sgender ); Listing 4: Insert. into Patient Table INSERT INTO appointment (Appointment_ID, Appointment_Date , Patient_ID, Doctor_ID) VALUES(?$appointment_id’, "$date’, ’$patient_id’, ? $doctor_id); Listing 5: Insert into appointment Table 28SELECT t1.Patient_Name, t1.Patient_Phone, t1 Patient_Age , t1.Patient_Sex, t2.Appointment_Date » td. Available Time as Time FROM patient as ti JOIN appointment as t2 OW t1.Patient_ID = t2.Patient_ID JOIN doctor as t3 ON t2.Doctor_id = t3.Doctor_id JOIN doctor_availability as t4 ON t3.Doctor_id = t4.Doctor_id AND t2.Appointment_Date = t4.Available_Day WHERE t2.Doctor_id = 71011’ AND t2.Appointment_Date = ’$day ; Listing 6: ‘To see serial of doctor 1011 in his available day. 29.9 Validation Our system saves mon and time for patients. Our current medical system is a mess up. People come from a different city area, facing colossal traflic jams, anticipate a doctor for hours, and if the medical doctor is absent frequently, they do not get the notification, So it becomes a loss of time, cost in colossal eapacity. Our application provides a better answer of keep times and price. Our application has a better notification system, which gives patients an appointaient time. If the doctor does not come on the scheduled date, it, will notify the in-person pati and the website. 9.1 User Manual Our application system is the simplest one. We said before that. we had got stakeholders, doctors, and patients. So they may use our system simmul- tancously, 9.1.1 Manual for Patient i. They can elect a doctor from the department or doctor list: page. ii, ‘Then they go to their selected doctor page. From this page, they can soe doctors, the latest three scheduled, and set an appointinent with the doctor, iv. If the doctor’s schedule is ocenpied, our application suggests considering, other doctors of the same department. v. If they can set an appointment, they go to the doctor's respective ap- pointment page. Where they can set an appointment, through form fields. ‘They can also show their appointment no. on their respective schedule. 9.1.2 Manual for Doctor hhey can go to their page directly or from their respective department's web page. ii, They can log in to their admin page. While the doctor goes to his respective admin web page, he ean provide a new timetable, see older time tables, see the appointment tables of re- spective schedlules, send notifications if needed, eonneet with the patient through chatot(conceptual) 3010 Software Deployment Our web application can be hasted on a hosting site like Netlify, Heroku. ‘The hosting site will give us an address. We will use the address for our ap- plication, and it will provide doctor’s visiting cards, prescriptions, billboards, diagnostic report. cover, social media page/groups. Patients will discover this web address in this way. They need only type/copy-paste the address to their internet-connected device's browser al11 Conclusion and Future Work At present, the number of patients is increasing tremendously, and it is, becoming tough to get doctors’ services. In the most chambers or hospitals, appointments are manually taken to serve patients. However, pati to wait in line for a long time to have an appointment. Again many times, if for some reason the doctor cancels the appointment, then the patient may not know it immediately. That is why the patients have to suffer from far and away. Not everyone knows exactly how many specialist. doctors there are for a particular type of disease. Finding a specialist doctor is tricky, especially for those who live in rural areas. ‘Through our project, patients can easily make an appointment with a specialist doctor without standing in any line. The patient does not have to come to a specific place at a specific time to make the doctor’s appointment and he can take the schedule of his choice sitting at home, Patients’ phone numbers and emails will he stored in our database at appointanent time. If the doctor cancels the schedule for any reason, the patient will be informed obile S.M.S and email. Even if the patient feels that he cannot come doctor for any reason, he can apply to cancel the appointment, himself Significance of the project: Onr project is a database management system for making doctor's appoint ments online, Our idea is that this project will have a very influential impact ily lives. In the manual appointment system, the patient. has to e receptionist or oflice stall face to face or on the telephone with the required documents. If the office staff is not available directly or by phone, the patient has to spend a long time in line or on the phone to make an ap- pointment, Due to which much valuable time of the patient is wasted. With the online appointment: system, the patient can make an appointment at any place of his choice. It is challenging for ordinary people, especially in rural areas, to come to the city and find a specialist doctor. In this case, he can casily arrange the specialist doctor’s appointment through any device with an internet connection, and then he ean appear in the doctor's chamber at the appointed time. Newly added doctors in the profession will increase the popularity with the people through this project and will be able to serve the patients efficiently. Near future, it’s going to be great easy for a massive umber of patients and doctors,12 Bibliography References [1] Definition of ‘Waterfall Model’ (2021). nttps://economictimes indiatimes.com/def inition/vaterfall-model. [2] Digite, What: Is Serum Methodology and Serum Project Management (2021). https: //www .digite.con/agile/scrun-methodology/. [3] Jama Software, What is requirements gathering? (2022), notps://wuw. jamasoftware. con/requirenents-management-guide/ requirenents-gather ing-and-management-processes/ ‘what-is-requirenents-gathering. ‘Techopedia, Logical Data Model (LDM) (2014). https: //wew. ‘techopedia..com/def inition/30599/logical-data-model-ldm#: UTE: text=A%201ogical /,20datal,20model/,20(LDM) ,20provides’, 20a/20detailedy200verviews200f , from/,20thel,20underlyingy, 20database.20technology... [5] GecksforGeeks, Introduction of Database Normal ization (2021). https: //www. geeksforgeeks.org/ introduction-of-database-normal ization. [6] System Architecture Diagram: A Complete Tutorial EdrawMax (2021). https: //www.edrawsoft .con/article/ system-architecture-diagram. html. a3