Paperless Hospital Management

Software Requirements Specification

Submitted By, K.Gopal (10BCE0196) V.Vidyanath (10BCE0170) Sn.Jai kishan (10BCE0333)

Contents
1. Introduction 1.1 Aim3 1.2 ProblemDescription.......3 1.3 Objective..... .3 1.4 Scope.....3 2. Overall Description 2.1 Process Model3 2.1.1 Description.3 2.1.2 Model Diagram..4 2.1.3 Advantages.4 2.1.4 Disadvantages4 2.1.5 Justification4 2.2 Work Breakdown Structure...5 2.3 Gantt Structure...6 2.4 Pert Chart...7 2.5 Timeline Chart...8 2.6 Stakeholders......9 2.7 Usecase Diagra.......10 2.8 Class Diagram..10 3. Functional Requirements....11 4. Non-Functional Requirements....12 4.1 Usability....12 4.2 Security.12 4.3 Reliability..12 4.4 Performance......12 4.5 Availability...12 4.6 Portability.12 5. Software Interface..13 6. Hardware Interface..13

1. Introduction 1.1 Aim

The project aimed at providing Paperless Service in a Hospital to help patients, doctors not to do any paperwork, store all patient details like problem, prescription, tests required, test results, billing details etc. in the Database and let patients and doctors access it anytime and from anywhere. This project makes hospital service Quick and Easy.

1.2 Problem Description

The present hospital management system is mostly paper based. All the patient details, records are paper based. Patients have to wait long times to avail doctors appointment. To avoid wastage of time and effort, hospitals must be computerised. All the details, patient information and records must be saved permanently in the Database so that they will available forever for future reference. Both patient and doctor must be provided with a facility to access their information whenever and from wherever by creating a Patient Profile for each patient. Past patient records, current availability of doctor must be accessed easily. Doctors can have a discussion board where they can discuss serious case. This system helps doctors to treat better and reduces patients efforts.

1.3Objective
To provide facility to patients, doctors to avoid paperwork by performing writing, form filling operations online. Allow patients to see their patient profile from home through Internet. To make patient profiles available to doctor all time to help them understand case better and treat patients better. To reduce wastage of time and effort for patient and staff. Provide feedback To make hospital services Quick and Easy.

1.4Scope
Patients need not wait in long queue as he knows the availability of doctor beforehand. The patient details are stored permanently in Database and can be used for further reference. Patients can pay their bills online through Credit/Debit cards, Net Banking. An effective ambulance service can be provided as details, locations can be made informed online quickly.

2. Overall Description 2.1 Process Model 2.1.1 Description

V Shaped Model: V Shaped Model is chosen for this project. V Shaped Model allows us to develop modules, test them after completion of each module. Once the module is complete, it is included in the project and the project completed so far will be evaluated. Project is tested after addition of each module. Functionality of each module is evaluated and required changes are made if necessary. Project is tested at each of its phases. Design and Testing of Project are done simultaneously at each phase. So, V Shaped Model is chosen for development of this project.

2.1.3 Advantages
All Requirements are known before hand and chance of error during development is very less. Each Module is tested after completion. Project is evaluated at each phase. So, any errors can be resolved during development process. Unit testing helps to evaluate and increase efficiency in functionality of each module. Work division in a group is easy.

2.1.4 Disadvantages
All the requirements must be gathered before starting the project. Any change in the project in the middle of development may lead to starting of project from the beginning.

2.1.5 Justification
All the requirements are known beforehand. The project is divided into modules and each one of them is going to be developed independently. Unit testing of each module is done after completion. The module is added to project and the project is evaluated all together at each phase. This model provides high loading ability, stress ability and early user interface. This assures that there is no conflict with previous requirements and design.

2.2 Work Breakdown Structure (WBS)

2.3 Gantt Chart

2.4 Pert Chart

2.5 Timeline Chart

2.6 Stake Holders

Patient Doctor Receptionist Test Centre Finance Department.

2.7 Use Case Diagram

2.8 Class Diagram

10

3. Functional Requirements

The patient profile must be updated up to date in the database A patient ID must be generated after submitting the patient registration form Doctor must be provided with an option to take leave and block patient entries into his particular session before hand If doctors are not available and if all slots(sessions) are filled then newly registered patient IDs are kept in a queue and they are informed after allotting the doctor The patient profile must be updated on internet so that patient and doctor can view ,analyse the progress of the treatment Test centre must upload test results only after payment of corresponding bill at the finance office. Only after confirmation in patient profile, test results must be uploaded Doctor can edit only prescriptions , task required fields . He cant edit any other information Test centre will be able to upload test results only. They cant access any other field in the patient profile.

11

4. Non-Functional Requirements 4.1 4.2 Storage

Database must be maintained to store all patient profiles

Security

Passwords must have a minimum length of 10 characters with at least one upper case letter one lower case letter a number (0-9) one special character(&,#,$) Secure access of confidential data (users details). SSL can be used
4.3 Reliability

The MySQL database and system backups mechanism will be considered on implementation.
4.4 Performance

Better component design to get better performance at peak time. The application shall be able to successfully handle 1000 transactions per hour.
4.5 Availability

The system will be available on all days 24*7. 4.6 Response time Response time must not exceed 10sec for each event 4.7 Capability Database must be capable of holding any number of patient profiles and store them for further reference 4.8 Time out System at a particular user must time out if not used for 5 minutes

12

5. Software Interface
Web Server Tomcat or WASCE Database Server DB2 or MYSQL

6. Hardware Interface Server Side Processor

RAD DB2 Intel Pentium III or AMD- 800MHz

RAM
1GB 256MB

Disk Space
3.5GB 500MB

13