Scribd
Upload
40 views30 pages

E-Healthcare Final

Uploaded by

honeytpatel
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
40 views30 pages

E-Healthcare Final

Uploaded by

honeytpatel
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

E-Healthcare Management System

1st Semester

Department of MCA

Prepared By:
Patel Astha Vipulkumar
Patel Dhruv Kiritkumar
Patel Arth Bhaveshkumar
Introduction
 The project E-healthcare Management system includes registration of patients, storing
their details into the system. The software has the facility to give a unique id for every
patient and stores the details of every patient .
 The E-healthcare Management System can be entered using a username and password. It is
accessible either by an administrator .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.
 E-healthcare Management System is powerful, flexible, and easy to use and is designed
and developed to deliver real conceivable benefits to hospitals.
 E-healthcare Management System is designed for multispecialty hospitals, to cover a wide
range of hospital administration and management processes. It is an integrated end-to-end
E-healthcare Management System that provides relevant information across the hospital to
support effective decision making for patient care, hospital administration and critical
financial accounting, in a seamless flow.
Objective
 Define E-Healthcare
 Recording information about the Patients that come.
 Generating bills.
 Recording information related to diagnosis given to Patients.
 Keeping record of the Immunization provided to children/patients.
 Keeping information about various diseases and medicines available to cure them.
 These are the various jobs that need to be done in a Hospital by the operational staff and
Doctors. All these works are done on papers.
Scope of the Project
 Information about Patients is done by just writing the Patients name, age and gender.
Whenever the Patient comes up his information is stored freshly.
 Bills are generated by recording price for each facility provided to Patient on a separate
sheet and at last they all are summed up.
 Diagnosis information to patients is generally recorded on the document, which contains
Patient information. It is destroyed after some time period to decrease the paper load in the
office.
 Immunization records of children are maintained in pre-formatted sheets, which are kept in
a file.
 Information about various diseases is not kept as any document. Doctors themselves do
this job by remembering various medicines.
 All this work is done manually by the receptionist and other operational staff and lot of
papers are needed to be handled and taken care of. Doctors have to remember various
medicines available for diagnosis and sometimes miss better alternatives as they can’t
remember them at that time.
MODULES
 E-Healthcare Management System is web application for hospital which manages doctors
and patients. In this project, we use PHP and MySQL database.
 The entire project mainly consists of 3 modules, which are
 Admin module
 User module (patient)
 Doctor module
Admin Module
 Dashboard: In this section, admin can view the Patients, Doctors, Appointments and New
queries.
 Doctors: In this section, admin can add doctor’s specialization and mange doctors
(Add/Update).
 Users: In this section, admin can view users detail(who take online appointment) and also
have right to delete irrelevant user.
 Patients: In this section, admin can view patient’s details.
 Appointment History: In this section, admin can view appointment history.
 Contact us Queries: In this section, admin can view queries which are send by users.
 Doctor Session Logs: In this section, admin can see login and logout time of doctor.
 User Session Logs: In this section, admin can see login and logout time of user.
 Reports: In this section, admin can view reports of patients in particular periods.
 Patient Search: In this section, admin can search patient with the help of patient name and
mobile number.
 Admin can also change his/her own password.
User module (patient)
 Dashboard: In this section, patients can view the his/her profile, Appointments and Book
Appointment.
 Book Appointment: In this section, Patient can book his/her appointment.
 Appointment History: In this section, Patients can see his/her own appointment history.
 Medical History: In this section, Patients can see his/her own appointment history.User
can update his/her profile, change the password and recover the password.
Doctor module
 Dashboard: In this section, doctor can view his/her own profile and online appointments.
 Appointment History: In this section, Doctor can see patient’s appointment history.
 Patients: In this section, doctor can manage patients (Add/Update).
 Search: In this section, doctor can search patient with the help of patient name and mobile
number.Doctor can also update his profile, change the password and recover the password.
Requirement Specification
 Hardware Configuration:

Client Side

Server Side

RAM 1 GB
Hard Disk 20GB

Processor 2.0GHz
Continue.....
 Software Requirement:
Client Side

Server Side
Use Case Diagram
Continue.......
Continue.......
Class / Schema Diagram
ER Diagram
Implementation and
System Testing
 After all phase have been perfectly done, the system will be implemented to the server and the
system can be used.

System Testing

 The goal of the system testing process was to determine all faults in our project .The program was
subjected to a set of test inputs and many explanations were made and based on these explanations
it will be decided whether the program behaves as expected or not. Our Project went through two
levels of testing

 Unit testing
 Integration testing
Doctor Login
Admin Login
Patient Login
Admin Page
Admin Code

 CREATE TABLE `admin` (


 `id` int(11) NOT NULL,
 `username` varchar(255) NOT NULL,
 `password` varchar(255) NOT NULL,
 `updationDate` varchar(255) NOT NULL
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1
COLLATE=latin1_swedish_ci;
Appointment Code
 CREATE TABLE `appointment` (
 `id` int(11) NOT NULL,
 `doctorSpecialization` varchar(255) DEFAULT NULL,
 `doctorId` int(11) DEFAULT NULL,
 `userId` int(11) DEFAULT NULL,
 `consultancyFees` int(11) DEFAULT NULL,
 `appointmentDate` varchar(255) DEFAULT NULL,
 `appointmentTime` varchar(255) DEFAULT NULL,
 `postingDate` timestamp NULL DEFAULT current_timestamp(),
 `userStatus` int(11) DEFAULT NULL,
 `doctorStatus` int(11) DEFAULT NULL,
 `updationDate` timestamp NULL DEFAULT NULL ON UPDATE
current_timestamp()
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;
Doctors Info Code
 CREATE TABLE `doctors` (
 `id` int(11) NOT NULL,
 `specilization` varchar(255) DEFAULT NULL,
 `doctorName` varchar(255) DEFAULT NULL,
 `address` longtext DEFAULT NULL,
 `docFees` varchar(255) DEFAULT NULL,
 `contactno` bigint(11) DEFAULT NULL,
 `docEmail` varchar(255) DEFAULT NULL,
 `password` varchar(255) DEFAULT NULL,
 `creationDate` timestamp NULL DEFAULT current_timestamp(),
 `updationDate` timestamp NULL DEFAULT NULL ON UPDATE
current_timestamp()
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci;
Table Structure for doctorslog

 CREATE TABLE `doctorslog` (


 `id` int(11) NOT NULL,
 `uid` int(11) DEFAULT NULL,
 `username` varchar(255) DEFAULT NULL,
 `userip` binary(16) DEFAULT NULL,
 `loginTime` timestamp NULL DEFAULT current_timestamp(),
 `logout` varchar(255) DEFAULT NULL,
 `status` int(11) DEFAULT NULL
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1
COLLATE=latin1_swedish_ci;
Table Structure For Medicalhistory

 CREATE TABLE `tblmedicalhistory` (


 `ID` int(10) NOT NULL,
 `PatientID` int(10) DEFAULT NULL,
 `BloodPressure` varchar(200) DEFAULT NULL,
 `BloodSugar` varchar(200) NOT NULL,
 `Weight` varchar(100) DEFAULT NULL,
 `Temperature` varchar(200) DEFAULT NULL,
 `MedicalPres` mediumtext DEFAULT NULL,
 `CreationDate` timestamp NOT NULL DEFAULT
current_timestamp() ON UPDATE current_timestamp()
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1
COLLATE=latin1_swedish_ci;
Doctor specialization

 INSERT INTO `doctorspecilization` (`id`, `specilization`,


`creationDate`, `updationDate`) VALUES
 (18, 'Radiology', '2023-08-07 10:43:56', NULL),
 (19, 'Pediatrics', '2023-08-07 10:44:17', NULL),
 (20, 'General Surgery', '2023-08-07 10:44:30', '2023-08-07
10:44:38'),
 (21, 'ENT', '2023-08-07 10:44:54', NULL),
 (22, 'Dental Care', '2023-08-07 10:45:02', NULL),
 (23, 'Neurologists', '2023-08-07 10:45:23', NULL),
 (24, 'Gynecology', '2023-08-07 10:45:40', NULL),
 (25, 'Orthopedics', '2023-08-07 10:45:53', NULL),
 (26, 'Pathology', '2023-08-07 10:46:10', NULL),
 (27, 'Endocrinologists', '2023-08-07 10:47:12', NULL);
Conclusion
 Since we are entering details of the patients electronically in the” E-healthcare
Management System”, data will be secured. Using this application we can retrieve
patient’s history with a single click. Thus processing information will be faster. It
guarantees accurate maintenance of Patient details. It easily reduces the book keeping task
and thus reduces the human effort and increases accuracy speed.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy