ABSTRACT Our project Hospital Management system includes registration of patients, storing their details into the system, and also booking their appointments with doctors. Our software has the facility to give a unique id for every patient and stores the details of every patient and the staff automatically. User can search availability of a doctor and the details of a patient using the id. The Hospital Management System can be entered using a username and password. It is accessible either by an administrator or receptionist. Only they can add data into the database. The data can be retrieved easily. The interface is very user-friendly. The data are well protected for personal use and makes the data processing very fast. It is having mainly two modules. One is at Administration Level and other one is of user Le. of patients and doctors. The Application maintains authentication in order to access the application. Administrator task includes managing doctors information, patient’s information. To achieve this aim a database was designed one for the patient and other for the doctors which the admin can access. The complaints which are given by user will be referred by authorities. The Patient modules include checking appointments, prescription. User can also pay doctor's Fee online. a|PaTable of Contents SNO TOPIC Page No 1. PROBLEM STATEMENT 9 2. PROCESS MODEL 1 3. SOFTWARE REQUIREMENTS 15 SPECIFICATION 4. CONTEXT LEVEL DIAGRAM 18 5. DFD LEVEL 1 19 6. DFD LEVEL 2 20 7. USE CASE DIAGRAM 24 8. USE CASE DESCRIPTION 25 9. DATA DICTIONARY 35 10. ER DIAGRAM 36 11. DATA DESIGN 37 12 COMPONENT LEVEL DIAGRAM 40 13. PROJECT SCHEDULING 44 14. TIMELINE CHART 45 1s. FUNCTION POINT METRICS 46 16. COCOMO MODEL 52 17. SAMPLE SCREENSHOTS 56 18. RISK ANALYSIS 68 19. TESTING 69 20. CONCLUSION 74 5]LIST OF FIGURES USED IN THE PROJECT FIGURE_NO NAME PAGE No 24 CONTEXT LEVEL DED 18 22 LEVEL-1DFD 19 23 LEVEL —2 REGISTRATION 20 2.4 LEVEL-2 LOGIN 20 25 LEVEL - 2 MAKE APPOINTMENT 2a 2.6 LEVEL -2 ADD DESCRIPTION 2a 27 LEVEL - 2 DOCTOR MODULE 22 28 LEVEL -2 PAYMENT 22 29 LEVEL - 2 CANCEL APPOINTMENT 23 2.10 LEVEL - 2 PAITENT MODULE 23 61 HOME PAGE 57 62 SELECT LOGIN 37 63 PATIENT LOGIN PAGE 58 6.4 REGISTRATION 58 65 PATIENT PROFILE 59 66 PATIENT UPDATE DETAILS 59 67 PATIENT BOOK APPOINTMENT 60 68 PATIENT APPOINTMENT STATUS 60 69 PATIENT CANCEL APPOINTMENT 61 6.10 PAYMENT. 61 6.11 PATIENT PAYMENT RECIPET 62 616.12 PATIENT VIEW PAYMENT HISTORY 62 6.13 PATIENT VIEW DOCTORS 63 6.14 DOCTOR LOGIN PAGE 63 6.15, DOCTOR PROFILE 64 6.16 DOCTOR VIEW APPOINTMENT 64 6.17 DOCTOR ADD DESCRIPTION 65 6.18 ADMIN LOGIN PAGE 65 6.19 ADMIN ADD DOCTOR 66 6.20 ADMIN UPDATE DOCTOR DETAILS 66 6.21 ADMIN PAYMENT REQUEST 67 6.22 ADMIN VIEW RECORDS 67 7\LIST OF TABLES USED IN THE PROJECT TABLE NO NAME PAGE NO 44 DATA DICTIONARY 38 42 PATIENT 40 43 ‘APPOINTMENT 40 44 DOCTOR 41 45 PRESCRIPTION 41 46 ‘ADMIN 42 47 BILL 42 5.1 PROJECT SCHEDULING 44 5.2 TIMELINE CHART 45 53 FUNCTION POINT COMPLEXITY 49 WEIGHTS 54 COCOMO II COMPLEXITY 52 WEIGHTS PRODUCTIVITY RATE FOR 53 55 OBJECT POINT COUNTS 74 RISK ANALYSIS 68 8]PROBLEM STATEMENT In this busy world we don’t have the time to wait in infamously long hospital queues. The problem is, queuing at hospital is often managed manually by administrative staff, then take a token there and then wait for our turn then ask for the doctor and the most frustrating thing - we went there by traveling a long distance and then we come to know the doctor is on leave or the doctor can’t take appointments. HMS will help us overcome all these problems because now patients can book their appointments at home, they can check whether the doctor they want to meet is available or not. Doctors can also confirm or decline appointments, this help both patient and the doctor because if the doctor declines’ appointment then patient will know this in advance and patient will visit hospital only when the doctor confirms’ the appointment this will save time and money of the patient. Patients can also pay the doctor’s consultant fee online to save their time. HMS is essential for all healthcare establishments, be it hospitals, nursing homes, health clinics, rehabilitation centers, dispensaries, or clinics. The main goal is to computerize all the details regarding the patient and the hospital. The installation of this healthcare software results in improvement in administrative functions and hence better patient care, which is the prime focus of any healthcare unit. Benefits of implementing a hospital management system: + Appointment booking > Helps patients cut the long queue and saves their time o Is equipped with features like automated email and text message reminders + Role-Based Access Control © Allows employees to access only the necessary information to effectively perform their job duties > Increases data security and integrity g|PaOverall cost reduction o Cuts down paper costs as all the data are computerized No separate costs for setting up physical servers Data accuracy 2 Removes human errors 2 Alerts when there's a shortage of stock Data security 2 Helps to keep patients records private o Restricts access through role-based access control Revenue management > Makes daily auditing simple © Helps with statistics and other financial aspects 10|PROCESS MODEL Hospital Management System follows INCREMENTAL MODEL because initially software requirements are reasonably well defined but the overall scope of development effort is a purely linear process. There may be other requirements of the user which will be known later. So, those requirements can the implemented and delivered in the following next increments. Our project is a short term project of 3 months and 3 weeks only and staffing available is also low (3 persons).CHAPTER 1 INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS 1.4 REFERENCES 1.5 OVERVIEW1.1 PURPOSE This software will help the company to be more efficient in registration of their patients and manage appointments, records of patients. It enables doctors and admin to view and modify appointments schedules if required. The purpose of this project is to computerize all details regarding patient details and hospital details. 1.2 SCOPE The system will be used as the application that serves hospitals, clinic, dispensaries or other health institutions. The intention of the system is to increase the number of patients that can be treated and managed properly. If the hospital management system is file based, management of the hospital has to put much effort on securing the files. They can be easily damaged by fire, insects and natural disasters. Also could be misplaced by losing data and information. 1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS 1. Cardiologist - treats heart disease. Pediatrician - treats infants, toddlers, children and teenagers. 3. Plastic Surgeon - restores, reconstructs, corrects or improves in the shape and appearance of damaged body structures, especially the face. 4, Psychiatrist - treats patients with mental and emotional disorders. Ophthalmologist - treats eye defects, injuries, and diseases 6. ENT- Ear, Nose and Throat Specialist. N s SRS: Software Requirement Specification. DFD: Data Flow Diagram ENT- Ear, Nose and Throat Specialist. BG - Blood group ee ee Y Appt — Appointment. Y Sign up - Creating New User. Y Log in - Logging in Existing User. ¥ PhNo - Mobile number. v Addr — Address. v Expr — Experience. BI1.4 REFERENCES > https://www.officetimeline.com/make-gantt-chart/excel > https://medium.com/@datamateuaecrescent/hospital-management-system- features-objectives-62eeb13f4fc4 > R.S Pressman, Software Engineering: A Practitioner’s Approach, Mc-Graw-Hill, Edition-7 (2010) > P. Jalote, an Integrated Approach to Software Engineering, Narosa publication house, Edition -3 (2011). 1.5 OVERVIEW Our application contains two modules — the admin module and the user module. Our application will not only help the admin to preview the monthly and/or yearly data but it will also allow them to edit, add or update records. The software will also help the admin to monitor the transactions made by the patients and generate confirmations for the same. The admin will be able to manage and update information about doctors. The user module can be accessed by both the doctors and the patients. The doctor can confirm and/or cancel appointments. The doctors can even add prescriptions for their patients using our application. The patients will be able to apply for the appointment and make transaction for the same, and can even cancel appointments with the doctors. They can track details about the previous transactions made by them. Advantages + The system automates the manual procedure of managing hospital activities. + Doctors can view their patients’ treatment records and details easily. + Iteven generates an instant bill. + The system is convenient and flexible to be used. + Itsaves their time, efforts, money and resources. Disadvantages + Requires large database. + The admin has to manually keep updating the information by entering the details in the system. + Need Internet connection. 14)CHAPTER 2 SOFTWARE REQUIREMENT SPECIFICATION 2.1 Product Perspective 2.1.1 System Interfaces 2.1.2 System Specifications 2.1.2.1 H/W Requirement 2.1.2.2 S/W Requirement 2.1.3 Communication Interfaces 2.2 Product functions 2.3 Data Flow Diagram (DFD) 2.3.1 Context Level Diagram 2.3.2 DFD Level — 1 2.3.3 DFD Level — 2 2.4 Use Case Diagram 2.5 Use Case Description 2.6 User characteristics 2.7 Constraints 2.8 Assumptions and dependencies2.1 Product Perspective This Hospital Patient Info Management System is a self-contained system that manages activities of the hospital. Due to improperly managed details medical center faces quite a lot of difficulties in accessing past data as well as managing present data. The fully functional automated hospital management system which will be developed through this project will eliminate the disadvantages caused by the manual system by improving the reliability, efficiency and performance. The usage of a database to store patient, employee, stock details etc. will accommodate easy access, retrieval, and search and manipulation of data. The access limitations provided through access privilege levels will enhance the security of the system. The system will facilitate concurrent access and convenient management of activities of the medical center. 2.1.1 System Interfaces * User interfaces = This section provides a detailed description of all inputs into and outputs from the system. It also gives a description of the hardware, software and communication interfaces and provides basic prototypes of the user interface. = The protocol used shall be HTTP. + The Port number used will be 80. = There shall be logical address of the system in IPv4 format. + Hardware Interfaces = Laptop/Desktop PC-Purpose of this is to give information when Patients ask information about doctors, medicine available lab tests etc. To perform such Action it need very efficient computer otherwise due to that reason patients have to wait for a long time to get what they ask for. = Laser Printer (B/W) - This device is for printing patients’ info etc. "Wi-Fi router - Wi-Fi router is used to for internetwork operations inside of a hospital and simply data transmission from pc’s to sever. + Software Interfaces = JDK 1.8 - Java is fast, secure, and reliable. From laptops to data centers, game consoles to scientific supercomputers, cell phones to the Internet, = Mysql server - Database connectivity and management = OS Windows 7/8/8.1- Very user friendly and common OS = JRE 1.8 - JAVA Runtime Environment for run Java Application and System 16|Pa2.1.2 System Specifications 2.1.2.1 H/W Requirement = Core iS processor = 2GB Ram, = 20GB of hard disk space in terminal machines = 1TB hard disk space in Server Machine 2.1.2.2 S/W Requirement & Windows 7 or above operating system & JRELB = Mysql server ion Interfaces 2.1.3 Commu 4 NIC (Network Interface Card) — It is a computer hardware component that allows a computer to connect to a network. NICs may be used for both wired and wireless connections. CAT 5 network cable- for high signal integrity 4 TCP/IP protocol- Internet service provider to access and share information over the Internet A Ethernet Communications Interface- Ethernet is a frame-based computer network technology for local area networks (LANs) 4 Ubiquitous, easy to set up and easy to use. Low cost and high data transmission rate. » 2.2 Product functions Provide access to registered users only Registration of new patients. Enable patient to view their record. Enable patient to update their record. Generate appointment date and timing. Confirmation by doctor. Patients can do Payment. Modification in schedule by patient. Admin access to patients record. Admin Verify Payment and Generate Bill/Receipt. ‘Admin can view monthly/yearly records. oo00000 o0000 wv2.3 DATA FLOW DIAGRAM (DFD) CONTEXT LEVEL DIAGRAM DFD LEVEL -0 1D, Password Tolalfee caliecton Bationt Details tert! ee ContirmyCancel Appointment PatientiD, Medicine Advice, Remark confirmation Profile Bil/Receipt DOCTOR Management System PATIENT Name,Age Addr BG Phi ID Password DostarName, Time, Date Payment FIGURE 2.1 CONTEXT LEVEL DFD 18)DFD LEVEL -1 Doctor Na Time Date PaventiD\ Vedcire, arice, \ Remark DFD Level 1 riame, Bae, ‘specie 0 FIGURE 2.2 LEVEL - 1 DFD 19P_1D(PatientiD} Name,age, address, Blood Group, PATIENT ‘Mobile No.-mall Enter patient details 10 Dummy profile Set Password 1.2 FIGURE 2.3 LEVEL - 2 Registration SN DFD LEVEL-2 REGISTRATION toi ie i PATIENT | 2 a DOCTOR folie FIGURE 2.4 LEVEL - 2 Login 20)DFD LEVEL -2 Make Appointment ‘Appointment Schedule aa PATIENT Cancel Appointment Vertypoctar and Schedule 32 Appointment iii Contimation 33 couuantter_, Payment ims. da FIGURE 2.5 LEVEL — 2 Make Appointment wii Search Potions DOCTOR = Profile — 4a ‘aaatveatcine, Remark aavce evel ares, #2 rico] Ramer aw | vedere TaeNecicne, DFD LEVEL - 2 Remark aavce ADD PRESCRIPTION 43 FIGURE 2.6 LEVEL — 2 Add Description 21)ame Enter doctor Details 54 Search Update DFD LEVEL - 2 DOCTOR MODULE FIGURE 2.7 LEVEL — 2 Doctor Module 4 PATIENT rathoenn cna Nebel siL/seceot ‘ADMIN DFD LEVEL -2 Payment FIGURE 2.8 LEVEL — 2 PaymentPATIENT Tewschedae Fora smathods DFD LEVEL -2 Cancel appointment FIGURE 2.9 LEVEL - 2 Cancel Appointment DFD LEVEL -2 PATIENT MODULE ‘Search Doctor BA PATIENT Search For Receipt 83 FIGURE 2.10 LEVEL — 2 Patient Module 23)2.4 USE CASE DIAGRAM 24|Page2.5 USE CASE DESCRIPTION (1) PATIENT * REGISTRATION DESCRIPTION - The new patient can register themselves and add their details like name, age , gender, blood group etc. The patient entry will be made in the hms database. PRE -CONDITION — The patient must be a new patient, If necessary fields left by user then prompt user to fill the necessary fields. MAIN FLOW OF EVENTS 1. Patient selects sign up in login module. 2. A registration form get displayed 3. Patient fills the required details. POST CONDITIONS - Patient record is added to hms database. * UPDATION DESCRIPTION-The patient should be enabled to update his/her details and the changes should reflect in hms database. PRE-CONDITION — The patient must be a registered patient, The patient cannot update details after treatment starts. MAIN FLOW OF EVENTS 1, Patient logs in to the system. 2. Patient view his record 3. Patient selects update details. 4, Now patient may change the necessary fields. 5. Pop of update details. POST CONDITION - The record of patient is updated in hms database. 251*APPOINTMENT DESCRIPTION - It shows users a list of available doctors, timings, dates and enables patients to select the most suitable appointment date and doctor. The patient may also the cancel the appointment. PRE-CONDITION - The patient must be a registered patient, Patient can fix only one appointment for a particular department. MAIN FLOW OF EVENT 1, Patient first logs in to system. 2. View his/her record. 3. Create a new appointment or cancel the appointment... POST CONDITIONS - patient details are displayed and a new appointment is fix or a existing appointment is cancelled. The hms database is updated. *PAYMENT DESCRIPTION — It enables user to pay the consultant fee of Doctor online. PRE-CONDITION - The patient must be a registered patient, If Patient don’t wants to pay online he/she can pay by cash also. MAIN FLOW OF EVENT 1. Patient first logs in to system 2. View his/her record. 3. Appointment confirmed by the Doctor then go for Payment. POST CONDITIONS ~ A Reciept will be displayed. The hms database is updated 26 |(2) DOCTOR DESCRIPTION- The doctor view patient record/ update his details and add description of the treatment given to patient. PRE-CONDITION — The doctor must be a registered doctor, System does not allow the doctor to modify the qualification, hospital managed details MAIN FLOW OF EVENTS 1.Doctor logs in to the system. 2. Doctor may select view patient. 2.1 Patient record is displayed with treatment history. 3. Doctor add description of patient treatment. 4. Doctor may select appointment details 4.1 Appointment Requests is displayed with schedule. 5. Doctor confirm or cancel appointment. POST CONDITION ~ The patient and doctor ‘s database are updated. (3) ADMIN DESCRIPTION - The admin add doctor, update docotr details and verify payment and generate Bill/Reciept for the same. MAIN FLOW OF EVENTS 1. Admin logs in the system 2. Admin may add doctor new doctor. 2.1 admin fills the doctor’s details 3. Admin view Doctor record. 3.1 Admin enters the doctor id in the system. 3.2 Doctor details are displayed, Admin can update details. 4. Admin Verify the payment submited by the Patient. 4.1 Generate Bill/Reciept and confirmation message for the same. CONDITION - Admin must first log in with his/her credentials. POST CONDITION - The hms database is updated. 27)2.6 User characteristi ADMIN ‘Admin has the full access to the system which means he is able to manage any activity with regard to the system. He is the highest privileged user who can access to the system. Key functions: ‘*Access patient record, doctor Record. ‘*Add new doctor entry in system database. © Confirm Payment and Generate Bill. * View Records.(Total no of patients treated, doctor added/remove, consultant fee). PATIENT Patients can choose the best preferred appointments from the options provided and can also change the appointment schedule or cancel it. After appt. is confirmed by the respective doctor they can pay their consultant fee online. Patients have access to only their records. Key functions: * Make appointment. * Cancel appointment. * Update Details. Payment. © View Payment History. DOCTOR Doctors can view the patient appointment list and provide the confirmation or make changes in the appointment list if required. Doctors have access to only records of those patients whom they are treating. Key functions: Confirmation of appointment. Cancellation of appointment. Modification of appointment list. Add Prescription. 28|2.7 Constraints System is wirelessly networked with an encryption. system is only accessible within the hospital's website only. Database is password protected. Should use less RAM and processing power. Each user should have individual ID and password. Only administrator can access the whole system. 2.8 Assumptions and dependencies = Each user must have a valid user id and password = Server must be running for the system to function = Users must log in to the system to access any record. = Only the Administrator can delete records. 29)CHAPTER 3 SPECIFIC REQUIREMENTS 3.1 Performance requirements 3.2 Safety requirements 3.3 Security constraints 3.4 Software system attributes 3.4.1 Usability 3.4.2 Availability 3.4.3 Correctness 3.4.4 Maintainability 3.4.5 Accessibility 3.5 Functional Requirements3.1 PERFORMANCE REQUIREMENTS. © Response time- The system will give responses within 1 second after checking the patient information and other information. © Capacity-The system must support 1000 people at a time ©. User interface- User interface screen will response within 5 seconds 3.2 SAFETY REQUIREMENTS If there is extensive damage to a wide portion of the database due to catastrophic failure, such as a disk crash, the recovery method restores a past copy of the database that was backed up to archival storage and reconstructs a more current state by reapplying or redoing the operations of committed transactions from the backed up log, up to the time of failure. All the administrative and data entry operators have unique logins so system can understand who is login in to system right now no intruders allowed except system administrative nobody cannot change record and valuable data: 3.3 SECURITY REQUIREMENTS 1. Want take the responsibility of failures due to hardware malfunctioning. 2. Warranty period of maintaining the software would be one year. 3. Additional payments will be analyzed and charged for further maintenance. 4, If any error occur due to a user's improper use. Warranty will not be allocated to it. 5. No money back returns for the software. 3.4 SOFTWARE SYSTEM ATTRIBUTES 3.4.1 Usability: Software can be used again and again without distortion. 3.4.2 Availability: The system shall be available all the time. 3.4.3 Correctness: Bug free software which fulfills the correct need/requirements of the client. 3.4.4 Maintainability: The ability to maintain, modify information and update fix problems of the system. 3.4.5 Accessibility: Administrator and many other users can access the system but the access level is controlled for each user according to their work scope. a1| Pa3.5 FUNCTIONAL REQUIREMENTS S.No. MODULE NAME APPLICABLE ROLES DESCRIPTION LOGIN PATIENT DOCTOR ADMIN PATIENT: Can login using unique Id and Password after this system shall show his/her profile. DOCTOR: Can login using unique Id and Password after this system shall show his/her profile. ADMIN: Can login using unique Id and Password after this system shall show a profile with links to maintain the website. REGISTRATION PATIENT PATIENT: Can Register by filling all the required details, after this the system will verify the details and check if already registered or not. MAKE APPT. PATIENT PATIENT: Can Select doctor, date time and make an appointment request after this system shall show a confirmation for appointment request. CANCL APPT. PATIENT DOCTOR PATIENT : Can Cancel appointment if want to by just one click after this system shall ask for re-schedule or refund of payment. DOCTOR : Can Cancel appointment if want to by just one click after this system shall send a message to the patient. PAYMENT PATIENT PATIENT : Enter payment details and make payment after this system shall show the generated bill by the hospital DOCTOR MODULE ADMIN ‘ADMIN : Can add a new doctor by filling all the details after this system shall show a confirmation message. Can Remove a doctor by just one click after this system shall show confirmation message 32PATIENT MODULE PATIENT PATIENT : Can view payment history or can search for a particular bill also after this system shall show a bill or history. Can also See or search for a doctor by entering dept. name or doctor id if known after this system will check for the doctor if found shall show doctor’s profile. Can also update details after this system shall ask for re-enter password and after verifying password shall update details. ADD PRESCRIPTION DOCTOR DOCTOR : Enter Patient Id and after this all the treatment details and medicine, remark and advice for the patient after this system shall show a message for update. 33CHAPTER 4 DESIGN 4.1 Data Dictionary 4.2 ER Diagram 4.3 Data Design 4.4 Component Level Diagram4.1 DATA DICTIONARY 1. legal_character | [a-z| A-Z] 2. Digit [0-9] 3. special_ch (@|$|#l+I-] 4. Blood [A|B]AB|O] 1. Name first_name + (middle_name) + last_name 2. first_name {legal_character}* 3. middle_name {legal_character}* 4. last_name {legal_character}* 5. P_ID {legal_character + digit}* 6. D_ID {legal_character + digit}* 7. AID {legal_character + digit}* 8. Password {legal_character + digit + special_ch}* 9. Address House_no + (Street) + City 10. House_no {legal_character + digit}* 11, Street {legal_character}* 12. City {legal_character}* 13. Mobile No. { digit }* 14. Blood_Group {Blood + special_ch}* 15. Specialization {legal_character}* 16. Consultant Fee | { digit }* 17. Medicine {legal_character + digit}* 18. Advice {legal_character + digit}* 19. Remark {legal_character + digit}* Table 4.1 Data Dictionary4.3 DATA DESIGN SNO. | COLUMN DATA CONSTRAINTS | DESCRIPTION NAME TYPE 1. | PID Varchar(50) | Primary Key _| Contains Unique Id 2._| Name Varchar(50) - Contains Name 3. | DOB Varchar(50) - Contains Date Of Birth 4. | Gender Varchar(50) = Contains Gender 5. | Blood Group __| Varchar(50) - Contains Blood Group 6. Email ID Varchar(50) : Contains Email Id 7.__| Address Varchar(50) - Contains Address 8.__| Mobile No. Integer : Contains Mobile No. 9. | CGHS/Private | Varchar(50) - Contains Category Table 4.2 Patient SNO. COLUMN DATA | CONSTRAINTS | DESCRIPTION NAME TYPE 1 [PID Varchar(50)| Primary Key _ | Contains Unique Id Patient 2. | Specialization | Varchar(50) - Contains Name of the Department in which Patient wants to visit 3. Doctor’s Name | Varchar(50) - Contains Doctor Name Patient Wants To Visit 4. Consultant Fee Integer - Contains Consultant Fee Of Doctor 5. | Date Date - Contains Date For The Appointment 6. |Time Time - Contains Time For The Appointment Table 4.3 AppointmentSNO. COLUMN DATA CONSTRAINTS DESCRIPTION NAME TYPE 1. [DID Varchar(50)| Primary Key _| Contains unique ID 2. | Age Integer - Contains age 3.__| Gender Varchar(50) - Contains gender 4. | Specialization _| Varchar(50) - Contains specialization 5. _ | Experience Varchar(50) - Contains experience of the doctor (In months) 6. | Language Varchar(50) - Contains in how many languages doctor can speak. 7. | Mobile No. Integer - Contains mobile number 8. Email ID Varchar(50) - Contains Email Id 9. Schedule Varchar(50) - Contains day and time for which the doctor is available Table 4.4 Doctor SNO. COLUMN DATA | CONSTRAINTS | DESCRIPTION NAME TYPE 1. | DID Varchar(50) - Contains unique ID 2. | PID Varchar(50) | Primary Key _| Contains unique ID 3. | Medicine Varchar(50) Contains name of the medicine. 4. | Remark Varchar(50) Contains Remark given by the doctor for the patient. 5. | Advice Varchar(50) Contains any advice for the patient. Table 4.5 Prescription 38 |SNO. COLUMN DATA | CONSTRAINTS | DESCRIPTION NAME TYPE 1. [AID Varchar(50)| Primary Key _ | Contains unique ID. 2. | Name Varchar(50) - Contains Name 3. | DOB Varchar(50) - Contains Date Of Birth 4. | Gender Varchar(50) - Contains Gender 5. | Email ID Varchar(50) - Contains Email Id 6. __| Mobile No. Integer : Contains Mobile No. 7. [Address Varchar(50) : Contains Address Table 4.6 Admin SNO. COLUMN DATA | CONSTRAINTS | DESCRIPTION NAME TYPE 1. | PID Varchar(50) - Contains unique ID. 2. Bill No. Varchar(S0 | Primary Key | Contains number of the bill. 3. | Date Varchar(50 - Contains Date of The bill. 4. | Time Varchar(SO - Contains Time of the bill generated. 5. [Amount Int - Contains amount of the bill Table 4.7 Bill 394.4 COMPONENT LEVEL DIAGRAM Book Appointment Module enum Status { confirm , cancel} ; int Department, Date , Time, mode, ch; char Dr_Name(50); cout<< Enter The Information cin>> Department; cin>>Dr_Name; cin>> Date; cin>> Time; bool Appointment = cancel; cout<>mode; if(mode==1) { Generate a Receipt and send confirmation message; } else if(mode == 2) { Enter Card Details Make Payment Send confirmation message } else { Enter Account Details 40 |Make Payment Send confirmation message }//end if Send appointment Request to the doctor Doctor will check the Appointment Requests; cout<>ch; if(cl { 1) Appointment = Confirm; Send a Confirm Message to the patient. else Send a Cancel Message to the patient. V/end if 41)NO Are all the Details correct? ‘YES NO ‘Is Related Doctor available? <> YES Is Transaction completed? ——— YES ‘1s Appointment Confirmed No By the Doctor? YES 42|PageCHAPTER 5 ESTIMATION AND SCHEDULING 5.1 Project Scheduling 5.2 Timeline chart 5.3 Size Estimation (FUNCTION BASED METRICS) 5.4 Cost Estimation (COCOMO II MODEL)5.1 Project Scheduling Planned| Actual | Planned | Actual | Assigned person TASK ~> Start Start | complete | complete PROBLEM JanW1 | JanwW1 | Janw1 | Jan W1 Esha, Akansha, STATEMENT Monica SOFTWARE MODEL | JanW2 | JanW2 | JanW2 | JanW3 | Akansha, Monica PROJECT Esha, Akansh SCHEDULING JanW2 | JanW2 | JanW3 | Jan W3 ‘sha, Akansha SRS JanW3 | JanW3 | FebW1 | FebW1 Esha, Monica CONTEXT LEVEL DIAGRAM FebW1 | FebW1 | FebW1 Feb W2 Esha, Monica DFD LEVEL -1 FebW2 | FebW2) FebW2 | FebW3 Akansha, Monica DFD LEVEL - 2 Feb W3 | FebW3 | FebW3 | Feb W4 Esha, Akansha, lonica DATA DICTIONARY | MarW1 | MarW1 | MarW1 | MarW1 Esha, Akansha ER DIAGRAM MarW1 | MarW1 | MarW2 | MarW2 Esha DATA DESIGN MarW2 | MarW2|) MarW2 | MarW2 Akansha USE CASE DIAGRAM | MarW3 | MarW3) MarW3 | MarW3 Akansha USE CASE ‘Akansha, Esh: DISCRIPTION Mar W4 | MarW4 | MarW4 | Mar W4 ansha, Esha FUNCTION POINT Esha, Akansha, MATRIX Mar W3 | MarW3 | MarW3 | Mar W4 si ‘ions. a, COCOMO MODEL | AprW1 | AprW1 | AprW1 | AprW1 Esha, Akansha, lonica RISK ANALYSIS ‘AprW2 | Aprw2 | Aprw2 | AprWw2 Esha, Akansha TESTING AprW2 | AprW2 | Aprw2 | Aprw2 Esha, Akansha Jan-January Feb - February Table 5.1 Project Scheduling Mar ~ March Apr ~ April W- Week 44|Page5.2 Timeline chart Month ~> January | February March April Week ~> 2/3/4/1/2)3 41 2.3/4 PROBLEM STATEMENT SOFTWARE MODEL PROJECT SCHEDULING SRS CONTEXT LEVEL DIAGRAM DFD LEVEL -1 DFD LEVEL - 2 DATA DICTIONARY ER DIAGRAM DATA DESIGN USE CASE DIAGRAM USE CASE DISCRIPTION FUNCTION POINT MATRIX COCOMO MODEL RISK ANALYSIS TESTING au Table 5.2 Timeline Chart 45|Pege5.3 Size Estimation (FUNCTION BASED METRICS) Information domain values are defined in the following manner: * Number of external inputs (Els) - Each external input originates from a user or is transmitted from another application and provides distinct application-oriented data or control information. Inputs are often used to update internal logical files (ILFs). Inputs should be distinguished from inquiries, which are counted separately. * Number of external outputs (EOs) - Each external output is derived data within the application that provides information to the user. In this context external output refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately. * Number of external inquiries (EQs) - An external inquiry is defined as an online input that results in the generation of some immediate software response in the form of an online output (often retrieved from an ILF). * Number of internal logical files (ILFs) - Each internal logical file is a logical grouping of data that resides within the application's boundary and is maintained via external inputs © Number of external interface files (EIFs). - Each external interface file is a logical grouping of data that resides external to the application but provides information that may be of use to the application. 46 |SIZE ESTIMATION FOR THIS PROJECT Screen Els EOs EQs ILFs EIFs No 1. 1.Select - 1.Doctor’s On Hospital - Language leave File 2Nisitors on Website 2. : - : : - 3. | 1.Username - - Hospital - 2. Password File 4. 1.Name - - Hospital - 2.Dob File 3. Gender 4 Email 5. Blood Group 6 .Mobile No 7 Address 8 .CGHS / Private 9.Card Picture 5. : 1.Profile : HF - 6. 1. Department - - Hospital - 2.Date File 3.Time 4 Doctor Name 7. 1.Appointment | Hospital - Status File 8. |1.Card Holder : : Hospital ~ Name File 2. Card number 3. Expire Date 4. CVC Number 9. | 1.Registered - = Hospital - Mobile No. File 2.Edit Appt. Schedule 10. - - 1.Payment Hospital - History File 11. - 1.Profile - HF - 4712. | 1.Doctor ID 1.Doctor Hospital Details File 2B. - 1.Bill - Hospital File 14, | 1.Username - - Hospital 2. Password File 15. - 1. Profile Hospital File 16. - - Lappt. | Hospital Details File 17. | 1. Treatment 1,Patient - Hospital Name Profile File 2..Medicine 3 Advice 4 Remark 5.Patient ID 18. | 1.Username - - Hospital 2. Password File 19. | 1.Payment - - Hospital Verify File 20. | 1Name - - Hospital 2 Age File 3 Gender 4 Specialization 5 Experience 6 Language 7 Mobile No 8 Email Id 9 Schedule 21. | 1.Doctor Id 1.Doctor - Hospital Profile File 22. | 1.Select - Records Hospital Monthly/Yearly File 2.Select Year 3.Select Month 48TABLE 5.3 Function Point Complexity Weights Measurement parameter Weighting factor Simple|Average|Complex umber of user inputs 3 4 6 umber of user outputs ja 5 7 umber of user inquiries 3 a 6 umber of files 7 10 15 umber of external interfaces|5 7 10 TOTAL EXTERNAL INUPUTS = 41 TOTAL EXTERNAL OUTPUTS = 7 TOTAL LOGICAL INTERNAL FILES = 1 TOTAL EXTERNAL INQUIRIES = 6 TOTAL EXTERNAL INTERFACE FILES = 0 Function point = FP = UFP x CAF = Count Total * (0.65 + (0.01 *> fi) UFP (Count Total) = Sum of all the complexities i.e. the 5 parameters provided in the question, CAF = Complexity Adjustment Factor i.e. 0.65 + (0.01 * Sf),CALCULATING ( © fi) Total Degree of Influence of the 14 General System Characteristics 1, How many communication facilities are there to aid in the transfer or exchange of information with the application or system? 2. How are distributed data and processing functions handled? 3. Did the user require response time or throughput? 4. How heavily used is the current hardware platform where the application will be executed? 5. How frequently are transactions executed daily, weekly, monthly, etc.? 6. What percentage of the information is entered online? 7. Was the application designed for end-user efficiency? 8. How many ILFs are updated by online transaction? 9. Does the application have extensive logical or mathematical processing? 10. Was the application developed to meet one or many user’s needs? 11. How difficult is conversion and installation? 12. How effective and/or automated are start-up, back-up, and recovery procedures? 13. Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? 14. Was the application specifically designed, developed, and supported to facilitate change? Considering all adjustment factors of average influence > fi = 14 * 3 = 42 50| PageTOTAL EXTERNAL INUPUTS = 41 TOTAL EXTERNAL OUTPUTS = 7 TOTAL LOGICAL INTERNAL FILES = 1 TOTAL EXTERNAL INQUIRIES = 6 TOTAL EXTERNAL INTERFACE FILES = 0 Assuming all the parameters are of SIMPLE COMPLEXITY. UFP (Count Total) = {41 * 3} + {7 * 4} + {1 * 3} + {6 * 7} + {0 * 5} = 196 Considering all adjustment factors of average influence > fi = 14 * 3 = 42 Function point = FP = Count Total + (0.65 + (0.01 *Y, fi) = 196 * (0.65 + (0.01 * 42) = 196 * (0.65 + (0.42) = 196 * (1.07) = 209.72 FUNCTION POINT = 209.725.4 Cost Estimation (COCOMO II MODEL) The original COCOMO model became one of the most widely used and discussed software cost estimation models in the industry. It has evolved into a more comprehensive estimation model, called COCOMO II. COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarch © Object Points © Function Points © Lines Of Source Code The COCOMO II application composition model uses object points. Like function point, the object point is an indirect software measure that is computed using counts of the number of (1) screens (at the user interface), (2) reports, (3) components likely to be required to build the application. Each object instance (e.g., a screen or report) is classified into one of three complexity levels (i.e. simple medium, or difficult). Once complexity is determined, the number of screens, reports, and components are weighted according to the table illustrated in Table 5.4 TABLE 5.4 COCOMO II Complexity Weights OBJECT TYPE COMPLEXITIY WEIGHT SIMPLE MEDIUM DIFFICULT SCREEN 1 2 3 REPORT. 2 5 8 3GL COMPONENT 10 52]The object point count is then determined by multiplying the original number of object instances by the weighting factor in the figure and summing to obtain a total object point count. When component-based development or general software reuse is to be applied, the percent of reuse (%reuse) is estimated and the object point count is adjusted: NOP = (Object Point) * [ (100 - %reuse) / 100 ] where NOP = defined as new object points. To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be derived. NOP PROD = ————___ Person-Month Table 5.5 presents the productivity rate for different levels of developer experience and development environment maturity. Once the productivity rate has been determined, an estimate of project effort is computed using NOP ESTIMATED EFFORT = PROD TABLE 5.5 Productivity Rate For Object Point Counts Developer's experience/capability Verytow| low | Normal | High | Very high Environment maturity/capability Verytow| Low | Normal | High Very high PROD 4 7 13 25 sO 53COST ESTIMATION FOR THIS PROJECT (1) SCREENS 1. Home Page. 12. Login Page For Doctor. 2. Select Login. 13. Doctor Profile. 3. Login Page For Patient . 14. Appointment Details. 4. Registration For Patient. 15. View Patient by Doctor. 5. Patient Profile. 16. Add Prescription. 6. Patient Update Details. 17. Login Page For Admin. 7. Book Appointment . 18. Generate Bill. 8. View Appointment Status . 19. Update Doctor Details. 9. Cancel Appointment. 20. Add Doctor. 10. Payment By Patient. 21. View doctor By Admin. 11. Receipt Of Payment . 22. View Records. (2) REPORTS . Total Visitors on Website. . Total Patients Treated. . Total Appointments Taken. . Total Appointments Cancelled. . Total Doctors on Leave. . Total Doctors Added. . Total Doctors Removed. ON ANEWNHE . Total Consultant Fee Collected .TOTAL SCREENS = 22 TOTAL 3GL MODULES = 0 TOTAL REPORTS = 8 CONSIDERING ALL OF THE ABOVE HAVE MEIDEM COMPEXITY, 0% OF COMPONENTS ARE REUSED AND TAKING THE DEVELOPER EXPERIENCE AND ENVIRONMENT MATURITY AS LOW. 74+7 PRODUCTIVITY RATE = TF OBJECT POINT = {22 * 2} + {8 * 5} = 84. NO! ESTIMATED EFFORT = ———~ =—- = 12 Person-Months.CHAPTER 6 SAMPLE SCREENSHOTSFIGURE 6.1 HOME PAGE eo panees) Sot heh As. ‘ MOEKA HOSPITAL poctor’s on [= a* ‘ x m ‘LEAVE ~ ~ oF ~ S Date:292.2018 se, LOGIN 1 Akansta Rah —_ 2.Muskan Kumari fal ‘Best Roctors: 5 Kavita Pandey — Bisciyia 52016 FIGURE 6.2 SELECT LOGIN MOEKA HOSPITAL eesti La Molo) Skolt i 57|PageFIGURE 6.3 PATIEN LOGIN PAGE NEW USER? REGI: FIGURE 6.4 REGISTRATION 58| Pageee Patient Name ge/Gender Blood Group Email Address Mobile no. + Esha Bit + eshadi3@gmalicom vine NOOO EAT FIGURE 6.5 PATIENT PROFILE CGHS Patient ID : Esha0o PATIENT. ‘CGHSCARD PHOTO eee SE 28 years 5 months/t Ae Recent Treatment Details ‘Treatment Name : Nose Problem Doctor Name: De akansha Rath, ENT Speciale Prescription: Fhiticasone / Mometasone Nose Spray Remark: Useat Bedtime, ‘Advice:You don't get the full fectfersaveraldays or evena week, Buti you use t dai, #1 be incredibly effective. > Profle Bookappaintment Appointment status Update Beta: vViewDoctor Receintof Payment Logout NAME GENDER ‘81000 GROUP ea MORE NO ADDRESS, PRIvare/cGHs FIGURE 6.6 PATIENT UPDATE DETAILS. Patient ID : Esha09 ha Behe CGHSCARD PHOTO ine ee Pern corner] fi Sa cee —| WONNUINNIN ee | GH _ SUBMIT Profile Book Appointment Appointment status Updote Detal View Doctor Receiptof payment Logout 59|PageFIGURE 6.7 PATIENT BOOK APPOINTMENT Select Department Select Doctor Name* Consultant Fee Date” Time" |_ Book Appointment Edit Appointment FIGURE 6.8 PATIENT APPOINTMENT STATUS Patient | Doctor Name ] Dept | Consultant | statue | cancel | Payment io Fee ‘hapa | alaneha ath | ENT | 45000 | Confirmed ad 4 Aupotntment lb confirmed bythe doctor Profle Fock Appointment Appointment Status Update Detats Fecelptot Payment Profile Book Appointment >Appointinentstatus Update Detais ‘view Doctor Aeceiptot Payment 60 | agFIGURE 6.9 PATIENT CANCEL APPOINTMENT Profile Book Appointment CANCEL APPOINTMENT >appointmentstatus Update Betaie Do You Want To Edit Schedule? Yes No. TTT SELECT METHOD —[PhonePe _< PayTM CASH ENTER REGISTERED MOBILE NO. suBMIT Pen. FIGURE 6.10 PAYMENT Lay ransicrt visa C2 CD EE Card Holder's Name card Number l Expire Date we Cancel conmnue 61/ PaFIGURE 6.11 PATIENT PAYMENT RECIPET BILL OF SUPPLY Mobi ne, + ssa7es4aau ees Patent Esha ashe ose geison Iayeats Smonthe/# —PalentIO shad fess: M0, NewDebi sino * cass “se Hog Mew et poate: 23/07/18 ose raterady cavsfenvare + cons 1 AtarshaRath(@¥T) 2 Gon 150.0 ssa.c0 (Consutaton) Total: 000 s5n00 035000 150.00 fo. G2 Signature Print Bownloae FIGURE 6.12 PATIENT VIEW PAYMENT HISTORY “Pe rofile posit Book Appointment PAYMENT HISTORY AppointmentStatus Update Detats DATE | BILLNO. | DOCTOR'S | AMOUNT | STATUS ‘View Doctor NAME > Recelptof Payment wppoia | CaS | Atamhesat | 15000 Pa ‘Open Logout vinnie | ose | Ashsinh | so000 | netnd | Open 62|PageFIGURE 6.13 PATIENT VIEW DOCTORS “¥ OT rit sa |BookAppamtment -Aopodnment status LIST OF DOCTORS AND THEIR DEPARTMENT Update Details > view Doctor Receiptof payment Logout Name of Doctor | Department Consultant Fee ‘Akansha Rathi ENT 600.00 Shikha Bisht Plastic Surgeon 1200.00 Reha Karmakar Padiatrician 500.00 Muskan Ophthalmologist 700.00 Kavita Pandey Psychiatrist 900.00 L__Ashi Singh Cardiologist 1500.00, FIGURE 6.14 DOCTOR LOGIN PAGE p | PASSWORD: ¢ 63|PageFIGURE 6.15 DOCTOR PROFILE Sania rae ‘Specialization : Nasal Language Spoke : English, Hindi, Urdu R Contact Details Mobile No. : +91-8945639342 Email: Akansha12@gmail.com Schedule :- Monday Wednesday Friday 9:00AM-12:00PM, 2:00PM-4:00PM ——-12:00PM-3:00PM. FIGURE 6.16 DOCTOR VIEW APPOINTMENT V3 25/02/18, Wednesday PID Name Schedule status Cancel fsha09 Esha Bisht Wednesday(2:30PM) Confirmed @& 23/02/18, Monday PLID Name ‘Schedule Status Cancel Fsha09 Esha Bisht Monday(10:30AM) Cancelled © >Profile My Appointments ‘Add Prescription Logout Profte My Appointments [Add Prescription Logout 64 |FIGURE 6.17 DOCTOR ADD DESCRIPTION “He Profle ost ImyAppointments >addpreceiption Enter Patient 1D. [Se rc Logout PLID:Eshaoo Patient Name : Esha Bisht ‘Treatment Name : Nose Problem Prescription: Fluticasone / Mometasone Nose Spray Remark : Use at Bedtime. Advice: You don't get the full effect for several days or even a week, But if you use it daily it'll be incredibly effective. FIGURE 6.18 ADMIN LOGIN PAGE PASSWORD: NEW USER? REGISTER... 65|PageFIGURE 6.19 ADMIN ADD DOCTOR “te Profile nin PaymentRequest >addDoctor ADD NEW DOCTOR Update Detail of Doctor Records NAME : AGE : “ GENDER SPECIALIZATION z >| EXPERIENCE : LANGUAGE SPOKEN 4 MOBILE NO. : EMAIL : SCHEDULE : FIGURE 6.20 ADMIN UPDATE DOCTOR DETAILS oc Profle tonne Payment Request Enter Dactor 1D. Ads Doctor > Update Detals of Doctor Name: Akansha Rathi Recoxts Logout — ye Mobile No, : +91-8945839342 Email: Akanshat 2@gmail com Schedule - Monday Wednesday Friday S:00AM-12:009M — 2:00PIM-8:00PM —_12:00PM-3:00PM Edit Details Remove Doctor 66 |P age= FIGURE 6.21 ADMIN PAYMENT REQUEST PAYMENT REQUESTS S.No | Patient | DoctorName | Consultant | Status | Generate Receipt 0 Fee and Upload i | Esha09 | AkanshaRathi | 600.00 Done FIGURE 6.22 ADMIN VIEW RECORDS: Profile > Payment Request ‘Ada Doctor Update Devas of br Records Logout Pre Baymantionver RECORD : [Monthly + ddbader pit beta of Boston Records select YEAR = [2018 5 Tas SELECT MONTH : [January ‘Total Patient Treated + | 10,123 Total Doctor Added = [io Total Doctor's Removed = [5 ‘Total Appointments Taken =: | 10,123, Total Appointments Cancelled : | 455 Total Fee Collected | Rs 1010,700 67|PageCHAPTER 7 RISK ANALYSIS S.No RISK CATEGORY | PROBABLITY | IMPACT RMMM (P) ()) PLAN 1, | SOME TEAM TECHNICAL 20% 2 OTHER TEAM MEMBER RISK MEMBERS BECOME SICK IN DISTRIBUTE THE BETWEEN WORK IN BETWEEN THEM 2. | DELIVERY PROJECT RISK 30% 1 TEAM MAY USE DEADLINE EXTRA MEMBERS TIGHTENED TO DO JOB ON SCHEDULED TIME 3, | LOSING OF ALL PROJECT RISK 20% 2 BACK UP THE PROJECT DATA PROJECT ONLINE THIS MAY OR IN EVERY HAPPEN DUE TO SYSTEM OF EVERY HARD DISK MEMBER FAILURE 4, | TEAM PROJECT RISK 10% 3 WE MAKE SOME DISTENTION / RULES HOW WE LACK OF CONSULT EACH COHESION OTHER TABLE 7.1 68CHAPTER 8 TESTING 8.1 WHITE BOX TESTING 8.1.1 Basic Path ( Pseudo code ) 8.1.2 Flow Graph 8.1.3 Cyclomatic Complexity 8.1.4 Independent PathsBASIS PATH TESTING FOR BOOK APPOINTMENT MODULE enum Status { confirm , cancel} ; int Department, Date , Time, mode, ch; char Dr_Name(50}; cout<< Enter The Information cin>> Department; cin>>Dr_Name; cin>> Date; cin>> Time; bool Appointment = cancel; 1 cout<>mode; if(mode==1), ———————_—————- 2 { Generate a Receipt and send confirmation message; 3 } else if(mode == 27 4 { Enter Card Details Make Payment 5 Send confirmation message } else { Enter Account Details 6 Make Payment Send confirmation message 70 |}/fendif Send appointment Request to the doctor Doctor will check the Appointment Requests; cout<>ch; if(ch==1) { Appointment = Confirm; Send a Confirm Message to the patient. } else _j Send a Cancel Message to the patient. V/end if B 10 11 12 711FLOW GRAPH NOTATION 72|Page2) CYCLOMATIC COMPLEXITY V(G) 1. Cyclomatic complexity V(G) = Total number of Regions. v(G) =4. 2. Cyclomatic complexity V(G) = (E—N) +2 where E = the number of flow graph edges. i.e. 15 N= the number of flow graph nodes. i.e. 13 V(G) = (15-13) +2=4. 3. Cyclomatic complexity V(G) =P +1. where P = the number of predicate nodes contained in the flow graph 6. WG)=3+1=4. There will be 4 independent Paths. 3) INDEPENDENT PATHS Path A: 1-2-3-7-8-9-10-11-13 Path B: 1-2-4-5-7-8-9- 10-12-13 PathC:1-2-4-6 -7-8-9-10-11-13 Path D:1-2-3-7-8-9-10-12-13 73)CHAPTER - 9 CONCLUSION Working on the project was an excellent experience. It helped us to understand the importance of planning, designing and implementation so far we have learnt in our theory books. It helped us unleashing our creativity while working in a team. It also realized the importance of team working, communication as a part of this project. The project was successfully completed after a lot of efforts and work hours. This project underwent number of compiling, debugging, removing errors, making it bug free, adding more facilities in Hospital Management System and interactivity making it more reliable and useful This project focused that scheduling a project and adhering to that schedule creates a hard sense of time- management. It has also let us known that co-operative teamwork always produce effective results. The entire project has been developed and deployed as per the requirements stated by the user. It is found to be bug free as per the testing standards that are implemented. The estimated cost of the project is (efforts) 12 and the estimated size of the project is (FP) 209.72. There are also few features which can be integrated with this system to make it more flexible. Below list shows the future points to be consider : * Getting the current status of patient. * Including a different module for pharmacy, LAB, Bed Allotment and many more. * Including a Frequently Asked Questions Section. Finally, we like to conclude that we put all our efforts throughout the development of our project and tried to fulfill most of the requirements of the user. 74)