Final Project Hms

7/29/2019 Final Project Hms

1/42

Online Hospital Management System

A.I.T.S. Rajkot 1

1. Introduction

Title: Online Hospital Management System

1.1 Purpose

The Software is for the automation of Hospital Management. It maintains two levels of users:-

1. Administrator Level2. User Level

The Software includes:- Maintaining Patient details.

Providing Prescription, Precautions and Diet advice. Providing and maintaining all kinds of tests for a patient. Billing and Report generation.

1.2 Scope

Patient registration Appointments scheduling Billing and payments (cash, CC, insurance)

Security of the whole system Pharmaceutical drugs/equipment Staff management (work roster, availability, scheduling, etc.) Management functions (report generation, accounting, etc.) System administration Resource allocation (booking rooms, operating theatres, etc.) Comprehensive database Web interface (proposed for future)

1.3 Definitions, Acronyms, and Abbreviations.

Problems with conventional system1. Lack of immediate retrievals: -

The information is very difficult to retrieve and to find

particular information like- E.g. - To find out about the

patients history, the user has to go through various

registers. This results in inconvenience and wastage of time.

2. Lack of immediate information storage: -

The information generated by various transactions takes

time and efforts to be stored at right place.


2/42


A.I.T.S. Rajkot 2

3. Lack of prompt updating: -

Various changes to information like patient details or

immunization details of child are difficult to make as paperwork is involved.

4. Error prone manual calculation: -

Manual calculations are error prone and take a lot of

time this may result in incorrect information. For example:

calculation of patients bill based on various treatments.

5. Preparation of accurate and prompt reports: -

This becomes a difficult task as information is difficult

to collect from various registers.

1.4 References

Books

Black Book ASP .NET

Master in ASP .Net

Master in SQL Server 2008

Murachs SQL Server 2008 for developersProfessional ADV.NET 2.0 -Wrox Publication.

Asp.net 4, unleashedPearson Publication

Websites

www.Bazee.com

www.WikiPedia.comwww.Online Auctionworld .com

www.google.com

www.ebay.com

www.onlineauction.com

www.bidjeeto.com

1.5 Overview
http://www.google.com/http://www.ebay.com/http://www.onlineauction.com/http://www.onlineauction.com/http://www.ebay.com/http://www.google.com/


3/42


A.I.T.S. Rajkot 3

Project is related to Hospital Management System. The project maintains two levels of users:-

Administrator Level-Doctor

User Level-Data Entry Operator

Main facilities available in this project are:-1. Maintaining records of indoor/outdoor patients.2. Maintaining patients diagnosis details, advised tests to be done.3. Providing different test facilities to a doctor for diagnosis of patients.

X-RayUrine TestStool TestSonography TestGastroscopy TestColonoscopy TestBlood TestBiochemistry Test

Maintaining patients injection entry records.

5.Maintaining patients prescription, medicine and diet

advice details.

6.Providing billing details for indoor/outdoor patients.

7.Maintaining backup of data as per user requirements.

(betweenmentioned dates).

8.If user forgets his/her password then it can be retrieved by hint

question.

9.In this project collection of data is from different pathology labs.

10.Results of tests, prescription, precautions and diet advice will be

automatically updated in the database.

11.Related test reports, patient details report, prescription and billing

reports can be generated as per user requirements.

12.User or Administrator can search a patients record by his/her name

or their registration date.

13.Patients diet advice can be provided in Hindi.


4/42


A.I.T.S. Rajkot 4

2. The Overall Description

2.1 Product Perspective Theproduct requires a browser .It will support IE 5.0+, NetScape 4+, Mozilla 1+, and

Opera. External interfaces include keyboard and mouse, enabling navigation across

screens and Internet Connection if Possible.

2.1.1 Interfaces

Input from the

user will be via keyboard input and mouse point and click. Theuser will navigate

through the software by clicking on icons and links. The icons will give appropriate

responses to the given input.

2.1.2 Hardware Interfaces

MICROPROCESSOR INTEL PENTIUM IV OR HIGHER

SYSTEM BUS SPEED 533 MHz

PROCESSOR SPEED 2.0 GHz

MAIN MEMORY 256 MB

SECONDARY

MEMORY

40 GB

SECONDARY

MEMORY SPEED

270 MHz

2.1.3 Software Interfaces

OPERATING SYSTEM WINDOWS XP/2000,SERVER,Windows 7

WEB SERVER IIS (Internet Information Server)


5/42


A.I.T.S. Rajkot 5

WEB SERVER

DESIGNING TOOL

ASP.Net,.NetFramework 3.5v

LANGUAGE C#

DATABASE MS-SQL SERVER 2008

Front-end and back-end selection

An important issue for the development of a project is the selection of suitable

front-end and back-end. When we decided to develop the project we went through an

extensive study to determine the most suitable platform that suits the needs of the

organization as well as helps in development of the project.The aspects of our study included the following factors.

Front-end selection:

1. It must have a graphical user interface that assists employees that are not from

ITbackground.

2. Scalability and extensibility.

3. Flexibility.

4. Robustness.

5. According to the organization requirement and the culture.

6. Must provide excellent reporting features with good printing support.7. Platform independent.

8. Easy to debug and maintain.

9. Event driven programming facility.

10.Front end must support some popular back end like Ms Access.

According to the above stated features we selected VS10.0 as the front-end for

developing our project.

Back-end Selection:

1. Multiple user support.2. Efficient data handling.

3. Provide inherent features for security.

4. Efficient data retrieval and maintenance.

5. Stored procedures.

6. Popularity.

7. Operating System compatible.

8. Easy to install.

9. Various drivers must be available.

10.Easy to implant with the Front-end.

According to above stated features we selected Ms-Access as the backend.


6/42


A.I.T.S. Rajkot 6

The technical feasibility is frequently the most difficult area encountered at this stage.

It is essential that the process of analysis and definition be conducted in parallel with

an assessment to technical feasibility. It centers on the existing computer system

(hardware, software etc.) and to what extent it can support the proposed system.

2.1.4Communications Interfaces

Local Area Network, which is internal to LCHP, used

for communication among employees & HRM.

2.1.5 Memory Constraints

Memory size required depends on number of employee

records and Datas.

2.1.6 Operations

It is mainly related to human organizations and political aspects. The points to

be considered are:

What changes will be brought with the system?What organization structures are disturbed?What new skills will be required? Do the existing staff members have these skills?If not, can they be trained in due course of time?

The system is operationally feasible as it very easy for the End users to operate

it. It only needs basic information about Windows platform.

2.2 Product Functions

The system functions can be described as follows:

1. Registration: When a patient is admitted, the front-desk staff checksto see if the patient is already registered with the hospital. If he is,

his/her Personal Health Number (PHN) is entered into the

computer. Otherwise a new Personal Health Number is given to this

patient. The patients information such as date of birth, address and

telephone number is also entered into computer system.

2. Consultation: The patient goes to consultation-desk to explain his/hercondition so that the consulting nurse can determine what kind of ward

and bed should be assigned to him/her. There are two possible

circumstances:


7/42


A.I.T.S. Rajkot 7

a) If there is a bed then the patient will be sent to the bed to

wait for the doctor to come.

b) If there is no bed, the patient is put on a waiting list until a

bed becomes available.

3. Patient check out. If a patient checks out, the administrative staff shalldelete his PHN from the system and the just evacuated bed is included

in available-beds list.

4. Report Generation: The system generates reportson the followinginformation: patients, bed availability and staff schedules after every

six hours. It prints out all the information on who has used which bed,

when and the doctor that is taking care of a given patient as well as

expected medical expenses.

2.3 User Characteristics

The system will be used in the hospital. The administrators, doctors,

nurses and front-desk staff will be the main users. Given the condition

that not all the users are computer-literate. Some users may have to be

trained on using the system. The system is also designed to be user-

friendly. It uses a Graphical User Interface (GUI).

Front-desk staff:

They all have general reception and secretarial duties. Every staff hassome basiccomputer training. They are responsible for patients check-

in or notification of appropriate people (e.g. notify administrator or

nurse when an event occurs).

Administrators:

They all have post-secondary education relating to general business

administration practices. Everyadministrator has basic computer

training. They are responsible for all of the scheduling and updating

day/night employee shifts. Administrators in the wards are responsible

for assigning doctors and nurses to patients.

Nurses:

All nurses have post-secondary education in nursing. Some nurses are

computer literate. Consulting nurses to whom patients give short

descriptions of their conditions are also responsible for assigning

patients to appropriate wards if the beds are available, otherwise

putting patients on the waiting list. Nurses in wards will use the HPMS

to check their patient list.

Doctors:


8/42


A.I.T.S. Rajkot 8

All doctors have a medical degree. Some have further specialized

training and are computer literate. Doctors will use the HPMS to check

their patients list.

2.4 Constraints

The constraint associated in the development of any software system

includes those that are common to all system. The common constraints Some

of the constraints are listed below with which we have developed this system.

It requires Microsoft windows XP or ASP .Net Microsoft SQL server 2000 is required. User mistake can be turned into the improper answer. It is Hospital Management System and there is unique form layout and the report

format.

The common constraints may include lack of managerial participation tighterdevelopment schedule frequently working for management etc.

It has some specification need: to run this software because is developed in theASP.Net

2.5 Assumptions and Dependencies

Patient provides CC/insurance details when registering Appointments can be cancelled 24 hours in advance without penalty Patient medical history can be viewed by concerned doctors at the hospital with

approval of the patient.

Hospital is covered by insurance policy. Staff are assigned roles to interact with the system Staff have basic computer operating skills. It is assumed that one hundred IBM compatible computers will be available

before the system is installed and tested.

It is assumed that the Hospital will have enough trained staff to take care of thesystem

2.6 Apportioning of Requirements.

The Website requires a browser. If any add-on or service like flash player

missing error etc. occurs then website opens in a compatible view which gives error

on the page. The browser requires the flash player to run flash objects if not possible

then it provides a direct link to the flash player download link or any other plug in

missing the it provides the interface to resolve the problem externally.


9/42


A.I.T.S. Rajkot 9

3. Specific Requirements

3.1 External Interfaces

Input from the user will be via keyboard input and mouse point and click. The

user will navigate through the software by clicking on icons and links. The icons will

give appropriate responses to the given input

User interface:

Main interface of HMS is a GUI window linked to different Functions such asto retrieve option that performs search for Staff Or Patient datas in database

and return relevant records.

Software interface :

S/W Name : SQL server.

Version: 8i

Vendor: Microsoft Corp.

External: server system.

Hardware interface:

Workstations: Personal computers used by employees in LCHP.

Memory constraints:

Memory size required depends on number of employee records/Datas.

Communication interface :

Local Area Network, which is internal to LCHP, used for communicationamong employees & HRM.

3.2 Functions

User side

Section 1: Home Page

Hospital startup details.

Section 2: About Us PageDetailed description about Hospital


10/42


A.I.T.S. Rajkot 10

Section 3: Facilities

Detailed description Vision of Hospital

Section 4: Registration form

Registration form for patient, doctor, appointment

Section 5: User Login

Doctor

Creating login sessions for the authorized user

It will provide following sections to access ito Profileo Patient listo Patient profile listo Patient messageo Patient prescription details and charge

Patient

Creating login sessions for the authorized user

It will provide following sections to access ito Profileo Des. listo Solutions listo message

Admin side

Section 1: Dashboard

All latest statistics, total users, total users scheme showed, total user

awaiting verification, total users awaiting activation, complaint status and

complaint verification.

Section 2: Verification

Show all unverified users, show all unverified user, either edit, delete

or activate either edit, delete or activate a user.


11/42


A.I.T.S. Rajkot 11

Section 3: Management

Users

Show all users, search through parameters: name, user id etc..

Appointment listShow all scheme list, search through parameters: upload date, category, etc.

Categories (Doctors, Patients)

Add, edit, delete, activate, and deactivate a category.

CMS

Add, edit, and delete new static content. Like about us, history, T&C, logo etc.

Section 4: Flag Reports

Show all Query and data upload reports, view query reports, edit contents withreports, delete contents report.

Section 5: Configurations & Settings

Setup global parameters like: daily max user access for specific data

for a specific scheme query, daily max scheme reviews, SEO meta tags, daily

download, Limit for a user, manage other rules for comments and ratings, etc.

3.3 Performance Requirements

The performance of our product is at its best if stored locally, as the responsetime will be much faster. If the product accessed via Internet, the performance is

limited by the connection speed. The only foreseen limitation is that of web-server

response.

Response Time

The system shall give responses in 1 second after

checking the patients information.

Capacity

The System must support 1000 people at a time.

User-interface

The user-interface screen shall respond within 5seconds.

Conformity

The systems must conform to the Microsoft

Accessibility guidelines

3.4 Logical Database RequirementsDirectory Structure of HMS

1. ASP.netFORM


12/42


A.I.T.S. Rajkot 12

frmBill

frmDivisionMaster

frmDoctorMaster

frmDoctorQualificationMaster

frmDoctorSpecialistMaster

frmDoctorTypeMasterfrmDoctorVisitChargeMaster

frmDoctorVisitTypeMaster

frmLogin

frmPrimaryChargeGroup

frmPrimarySubChargeGroup

frmRegistration

frmRoomTypeMaster

frmTreatment

frmUserDetail

frmUserPermission

MODULE

ModHMS

CLASS

clsHMS

REPORT

CrpChargeMaster.

CrpDailyCollection

CrpDepositeDetailDateWise

CrpDoctorMasterReport

CrpDoctorWiseCaseReport

CrpPatientVisitReportCrprptDepoitdetailRegIdWise

CrprptReliefReport

CryrptIPDBillDetail

CryrptOPDBillReport

2. SQL 2000

DATA

dbHMS_Data

LOG

dbHMS_Log

SQL

CreateTable

uspSaveDrMaster.uspSaveUserDetail


13/42


A.I.T.S. Rajkot 13

uspSaveTreatmentDetail

uspSaveRoomType

uspSavePrimarySubChargeGroup

uspSavePrimaryChargeGroup

uspsavePatientMaster

uspSaveDrVisitTypeuspSaveDrVisitCharge

uspSaveDrType

uspSaveDrSpecialist

uspSaveDrQualification

uspTotalBill

uspSaveDivisionMaster

uspSaveBillDetail

uspDrMasterNavigation

uspBillDetailNevigation

uspRegistrationNevigation

uspTreatmentNavigationuspRptReliefReport

uspRptPatientWisecaseReport

uspRptOPDBillReport

uspRptOPDBillReport

uspRptDoctorWiseCaseRepot

uspRptDoctorChargeReport.

uspRptDepositDetailReport

uspRptDailyCollectionReport

uspRptChargeMaster

uspOPDBillReport

DATABASE dbHMS

TABLES Login

DivisionMaster

PrimaryChargeGroup

PrimarySubChargeGroup

DrType

DrQualification

DrSpecialist

DrMaster

DrInsentive

DrVisitType

RoomType

DrVisitCharge

PatientMaster

MLCDetail

DepositDetailDetailOfShifting


14/42


A.I.T.S. Rajkot 14

TreatmentDetail

BillDetail

Form

Table No : 1

Name : DivisionMaster

Field

Name

Data

Type

Description Validation

DivId SmallI

nt

Automatically

Genetated

Primary Key

DivDescri

ption

Varch

ar

Division Name If not then null.

Table No : 2

Name : PrimaryChargeGroup

Field Name Data Type Description Validation

DivId SmallInt Division

Name

Foreign Key

From

DivMaster

PriGroupId SmallInt Automatical

ly

Genetated

Primary Key

PriGroupDescr

iption

Varchar Primary

Charge

Group

Description

If not then

null.

Table No : 3

Name : PrimarySubChargeGroupField Name Data Type Description Validation

PriGroupId SmallInt Primary

Group Id

Foreign Key

From

PriGroupMas

ter

PriSubGroupId SmallInt Automatically

Genetated

Primary Key

ChargeDescript

ion

Varchar Primary Sub

Charge

Description

If not then

null.

ChargeAmt Numeric Charge If not then


15/42


A.I.T.S. Rajkot 15

Amount null.

ApplyTo Varchar Charge Apply

To

If not then

null.

Table No : 4

Name : DrType

Field

Name

Data

Type


DrTypeId SmallInt Automatically

Genetated

Primary Key

DrTypeD

escri

Varchar Doctor Type

Description

If not then Null.

Table No : 5

Name : DrQualification

Field

Name

Data

Type


DrQualiId SmallInt Automatically

Genetated

Primary Key

DrQualiD

escri

Varchar Doctor

Qualification

Description

If not then Null.

Table No : 6

Name : DrSpecialist

Field

Name

Data

Type


DrQualiI

d

SmallInt Doctor

Qualification Id

If not then Null.

Specialist

Id

SmallInt Automatically

Genetated

Primary Key

SpecDesc

ri

Varchar Doctor Specialist

Description

If not then Null.

Table No : 7

Name : DrVisitType

Field

Name

Data

Type


DrVisitTyp

eId

SmallIn

t

Automatically

Genetated

Primary Key

DrVisitDescri

Varchar Doctor VisitDescription

If not then Null.


16/42


A.I.T.S. Rajkot 16

Table No : 8

Name : DrVisitCharge

Field Name Data

Type


DrTypeId SmallInt Doctor Type Id Foreign Key from

DrType

DrVisitType

Id

SmallInt Doctor Visit

Type Id

Foreign Key from

DrVisitType

RoomTypeI

d

SmallInt Room Type Id Foreign Key from

RoomType

DrCharge SmallInt Doctor charge If not then Null.

Table No : 9

Name : RoomType

Field

Name

Data

Type


RoomTypeI

d

SmallInt Automatically

Genetated

Primary Key

RoomType

Descri

Varchar Room Type

Description

If not then Null.

PtRoomCh

arge

SmallInt Patient Room

Charge

If not then Null.

AdvanceDe

posite

SmallInt Advanced

Deposite

If not then Null.

Table No : 10

Name : PatientMaster

FieldName

DataType


RegType Varchar Registration

Type

It must be enterd.

RegId SmallInt Automatically

Genetated

Primary Key

RegDate Datetime Registration

Date

It must be enterd.

PName Varchar Patient Name It must be enterd.

PAddr1 Varchar Patient

Address1

It must be enterd.

PAddr2 Varchar Patient If not then Null.


17/42


A.I.T.S. Rajkot 17

Address2

PBirthdate Datetime Patient

BirthDate

If not then Null.

Age SmallInt Patient Age If not then Null.

Sex Varchar Patient Sex It must be enterd.

Phone Varchar Patient PhoneNo

If not then Null.

Mobile Varchar Patient Mobile

No

If not then Null.

ConsDrId SmallInt Consultant

Doctor Id

If not then Null.

RefDrNam

e

Varchar Reference

Doctor Name

If not then Null.

Mediclaim Varchar Patient

Mediclaim

It must be enterd.

Table No : 11

Name : MLCDetail

Field Name Data

Type


RegId SmallInt Ledger Id Foreign Key fromPatientMaster

MLCAdmiD

ate

Datetime MLC

Patient

Admit Date

If not then Null.

CaseNo SmallInt Case No If not then Null.

MLCDate Datetime MLC Date If not then Null.

TimeInforme

d

Datetime Time

Informed to

Police

If not then Null.

PSOName varchar Police sub

Officer

Name

If not then Null.

BucNo SmallInt Buccle No If not then Null.

PoliceSt varchar Name of

Police

Station

If not then Null.

TimeArrived Datetime Time

Arrived

If not then Null.

MLCDischar

geDate

Datetime MLC

Patient

DisChargeDate

If not then Null.


18/42


A.I.T.S. Rajkot 18

Table No : 12

Name : DepositDetail

Field Name Data

Type


RegId SmallInt Registration Id Primary Key.

ReceiptNo SmallInt Automatically

Genetated

Primary Key

ReceiptDate datetime Reciept Date If not then Null.

Amount Integer Deposite Amount If not then Null.UserId SmallInt User Id If not then Null.

Table No : 13

Name : DetailOfShifting

Field

Name

Data

Type


ShiftingId smallint Automatically

Genetated

Primary Key

RegId smallint Automatically

Genetated

Primary Key

RoomTypeI

d

smallint Room Type Id If not then null.

RoomNo smallint Room No If not then null.

Bed No smallint Bed No If not then null.

FromDate Datetime From Date If not then null.

ToDate Datetime To Date If not then null.

Table No : 14

Name : DrMaster

Field

Name

Data

Type


DrId smallInt Automatically

Genetated

Primary Key

DrName Varchar Doctor Name It cannot be Null.

DrNickNa

me

Varchar Doctor Nick

Name

It must be enterd.

Address1 Varchar Doctor Address1

It cannot be Null.


19/42


A.I.T.S. Rajkot 19

Address2 Varchar Doctor Address

2

If not then null.

PhoneNo Varchar Phone Number It cannot be Null.

MobileNo Varchar Mobile

Number

If not then null.

QualiId Varchar Qualifiction Id If not then null.DrTypeId Integer Doctor Type Id If not then null.

SpecialistI

d

smallInt Specialist Id If not then null.

DivId smallInt Division Id If not then null.

ConsultCh

arge

smallInt Consultant

Charge

If not then null.

FollowUp

Charge

smallInt Follow Up

Charge

If not then null.

CaseValid

UpTo

smallInt Case Valid Up

To

If not then null.

Insentive smallInt Insentive If not then null.

BasicSalar

y

Numeric Doctor Basic

Salary

If not then null.

Table No : 15

Name : DrInsentive

Field

Name

Data

Type


DrId smallint Doctor Id If not then null.

PriGroupI

d

Smallint Primary Charge

Group Id

If not then null.

PriSubGr

oupId

Smallint Primary

subCharge

Group Id

If not then null.

Insentive Smallint Percentge Of

Insentive

If not then null.

Type Varchar Type % or / If not then null.

Table No : 16

Name : TreatmentDetail

Field Name Data

Type


RegId Small

Int

Registration Id Primary Key

TreatId Small

Int

Automatically

Genetated

Primary Key


20/42


A.I.T.S. Rajkot 20

TreatDate Dateti

me

Treatment Date If not then null.

DrId Small

Int

Doctor Id Foreign Key From

DrMastrer

PriGroupId Small

Int

Primary

Charge GroupId

Foreign Key From

PriGroupMaster

PriSubGroupId Small

Int

Primary Sub

Charge Group

Id

Foreign Key From

PriSubGroupMaster

ChargeAmt Small

Int

Treatment

Charge

Amount

If not then null.

Qty Small

Int

Quantity If not then null.

TotalAmount SmallInt

Total Amount If not then null.

Table No : 17

Name : Bill Detail

Field Name Data

Type


RegId SmallInt Register Id It must be entered.

Bill No SmallInt Patient Bill No Primary Key

Bill Date Datetime Bill Date It must be entered.

Bill Type Varchar Bill Type If not then Null.

DischargeTyp

e

Varchar DisCharge Type If not then Null.

DischargeDate Datetime DisCharge Date It must be entered.

TotalBillAmt Integer Total Bill

Amount

If not then Null.

NurChargePer Integer Nurshing Charge

Percentage

If not then Null.

NurChargeAm

t

Integer Nurshing Charge

Amount

If not then Null.

OtherCharge Integer Other Charges If not then Null.

ReliefAmt Integer Relief Amount If not then Null.

RemarkOfReli

ef

Varchar Remark Of

Relief

If not then Null.

SerTaxPer Integer Service Tax

Percentage

If not then Null.

SerTaxAmt Integer Service Tax If not then Null.


21/42


A.I.T.S. Rajkot 21

Amount

TotalDepositA

mt

Integer Total Deposite If not then Null.

NetPayable Integer Net Payable

Amount

If not then Null.

PayMode Varchar Payment Mode If not then Null.RemarkOfPay

ment

Varchar Remark Of

Payment

If not then Null.

Table No : 18

Name : UserDetail

Field Name Data

Type


UserId SmallInt Automatical

lyGenetated

Primary Key

UserName Varchar User Name If not then null.

UserAddr Varchar User

Address

If not then null.

ContactNo Varchar User

Contact No

If not then null.

Permission Varchar User

Permission

If not then null.

Table No : 19

Name : Login

Field Name Data

Type

Descriptio

n

Validation

UserId SmallInt User Id Foreign Key From

UserDetail

UserPasswd binary User

Password

If not then null.

LoginDate Datetime User Login

Date

If not then null.

LogoutDate Datetime User

Logout

Date

If not then null.

Table No : 20

Name : Form

Field

Name

Data

Type


FormId SmallInt Form Id If not then null.


22/42


A.I.T.S. Rajkot 22

FormNam

e

Varchar Form Name If not then null.

3.5 Design Constraints

Must use a SQL based database. SQL standard is the most widely useddatabase format.Restricting to SQL allows easy of use and compatibility for Web

Store.

Compatibility is only tested and verified for Microsoft Internet Explorer version 6 and7.

Other versions may not be 100% compatible. Alsoother browsers such as Mozilla or

Firefox may not be 100% compatible.

Database

The system shall use the MySQL Database, which is

open source and free.

Operating System

The Development environment shall be Windows 2000.

Web-Based

The system shall be a Web-based application.

3.5.1 Standards Compliance

Report Format:

IEEE Format

Data Naming:

Some general comments about the structure of entity and attribute names; names must be:

meaningful; self-documenting derived from the business use or purpose; and repeatable (different people from different areas of the ministry reading the name at

different times must have the same understanding of what the name means -- a

corporate-wide use of the name).

Accounting procedures:

The customer needs to enter its credit card information for purchasing any

items or products. They are to be securely maintained so that they can ensure his

privacy.

The account information is sent for the transaction process so that the processcontinues while purchasing.


23/42


A.I.T.S. Rajkot 23

3.6 Software System Attributes

3.6.1 Reliability

The reliability of the proposed system will be high due to

the above stated reasons. The reason for the increased reliability

of the system is that now there would be proper storage of

information.

3.6.2 Availability

The system should be available at all times, meaning the user can

access it using a web browser, only restricted by the down time of

the server on which the system runs. In case of a of a hardware

failure or database corruption, a replacement page will be shown.

Also in case of a hardware failure or database corruption, backups

of the database should be retrieved from the server and saved by

the administrator. Then the service will be restarted.

3.6.3 Security

Each member is required to enter an individual password when accessing the

site. Administrators have the option of increasing the level of password security their

members must use. The data on your site is secured through multiple layers of

protection. One of those security layers involves member passwords. For maximum

security of your site, each member must protect their password.

Patient Identification

The system requires the patient to

identify himself /herself using PHN

Logon IDAny user who uses the system shall have a Logon

ID and Password.

Modification

Any modification (insert, delete, update) for the

Database shall be synchronized and done only by the

administrator in the ward.

Compliance

The system must comply with the Regional Health

Authority Regulations concerning privacy, section

703.2RHA/2000/v78

Front Desk staff Rights

Front Desk staff shall be able to view all information in


24/42


A.I.T.S. Rajkot 24

HPMS, add new patients to HPMS but shall not be able

to modify any information in it.

Administrators ' Rights

Administrators shall be able to view and modify all

information in HPMS

Nurses' RightsNurses shall only be able to view all information in

HPMS.

Doctors Rights

Doctors shall only be able to view all information in

HPMS

3.6.4 Maintainability

Back Up

The system shall provide the capability to back-up the Data

ErrorsThe system shall keep a log of all the errors.

3.6.5 Portability

The application is ASP.Net based and should be compatible with all other systems which

have a ASP implementation. The end-user part is fully portable and any system using any

web browser should be able to use the features of the application, including any hardware

platform that is available or will be available in the future.

3.7 Organizing the Specific Requirements

3.7.1 System Mode


25/42


A.I.T.S. Rajkot 25


26/42


A.I.T.S. Rajkot 26

3.7.2 User Class

Class Diagram 1


27/42


A.I.T.S. Rajkot 27

ClassDiagram 2

3.7.3 Objects

Helpdesk Patient Registration and Appointment Scheduling Module Outpatient Management Module Doctors workbench/ CPOE Inpatient and Ward Management Patient Billing & Insurance Module Pharmacy Module General Stores/ Inventory Laboratory Information System Radiology Management Module Electronic Medical Record (EMR) Dietary Module


28/42


A.I.T.S. Rajkot 28

House Keeping Module Nursing Module Emergency Management Machine Maintenance CSSD Blood Bank Financial Accounting Module Fixed Asset Module Payroll Module MIS Dashboard Services Module User Manager Module (security workflow)3.7.4 Functional Hierarchy

One of the tools of the tructure analysis is the Data flow Diagram. A DFD is a

graphical representation of the system. The data flow Diagram is used by the System

analysis to explain the flow of the data in the system.

A DFD uses Some Elements as its building blocks. The following is a brief

description of these elements.

External EntityThe external entityis a source and/or destination of the data for the system.As

the name suggest,it lies outside the context of the system.It is represented by solid

rectangles.

ProcessA process represent some amount of word beging performed on the data.A

process does transformation of the data from one form to another. A circle represent a

process.The process must be named and numbered appropriately.

Data FlowA data flow designate an interface among different component in the DFD.It

represent the path of data as it flow through the system.

An arrow represent a data flow.The name of the data flow is written along the line.


29/42


A.I.T.S. Rajkot 29

Data SourceA data source is a repository of data. An open ended rectangle or tow horizontal

parallel lines represent it.

A DFD,whichdesribes the system at a very general level,is called the context

diagram.

It contains a single process,but it plays a vary important role in studying the

system.

The following pages displayed the context diagram and the DFDs of the

subsequent level of the Front Desk,Room Service & Restaurant.


30/42


A.I.T.S. Rajkot 30

GIVE SALARY

DETAIL

HOSPITAL

MANAGEMENT

SYSTEM

RECEIVE

FILETREATMENT SERVICE

DETAIL

MANAGEMENT

RECEIVE TREATMENT

DETAIL

REGISTRATION DETAIL

BILL DETAIL

PAYMENT DEATIL

REQUEST FOR

RELIEF

REVEIVE RELIEF

DEPOSIT PAYMENT DETAIL

DEPOSIT RECEIPT DETAIL

REPORT

REQUEST

FOR

RELIEFGIVE

RELIEF

DETAIIL

Context Level Diagram

PATIENTDOCTOR


31/42


A.I.T.S. Rajkot 31

1.0

REGISTRATIO

N

PATIENT

Patient Master

REG.ID,

DETAIL

2.0

TREATMENT

5.0

BILL

3.0

SHIFTING

4.0

DEPOSITE

REG.ID,

DETAIL

PATIENT

DETAIL

REG ID.

DETAIL

REG ID.

DOCTOR

TREATMENT

DETAILTREAT

TREATMENT

DETAIL

TREATMENT

DETAIL

REG ID, TREAT ID

7.0

REPORT

BILL NO

MANAGEMENT

REPORT

BILL DETAIL

PATIENT

DEPOSITE DETAIL

RED ID ,

SHIFTING ID

DEPOSITE DETAIL

IPD REG

ID

PATIENT

DETAIL

SHIFTING DETAIL

SHIFTING

DETA

IL

6.0

RELIEF

PAY

BILL AMOUNT

REG ID ,

RECEIPT NO

IPD REG ID

PATIENT

DETAIL

BILL

NO , DETAILREG ID ,

RECEIPT NO

PAY DEPOSIT RECEIVE RELIEF

REQUEST RELIEF

SEND

RELIEFREQUEST RELIEF

DETAIL

First Level Diagram


32/42


A.I.T.S. Rajkot 32

1.1

PATIENT

DETAIL &

REG TYPEPATIENT

PATIENT

DETAIL

REGID , DETAIL

1.2

CHECK

REG TYPE

REG ID

PATIENT MASTER

REG

ID,DETAIL

OPD

1.3

TAKE MLC

DETAILIPD

DETAIL

REG ID

MLC DETAIL

DETAIL

Fir :- Second Level DFD for Registration

SECOND LEVEL DFD FOR REGISTRATION


33/42


A.I.T.S. Rajkot 33

SECOND LEVEL DFD FOR TREATEMENT


34/42


A.I.T.S. Rajkot 34

3.1

VERIFY

REG TYPE

PATIENTREG ID

3.2

CHECK

ROOMAVAILABLE

IF IPD

3.3

ALLOCATE

ROOMIF EXIST

Second Level DFD for Shifting

DETAIL OF SHIFTING

RED ID

&

DETAIL

SECOND LEVEL DFD FOR SHIFTING


35/42


A.I.T.S. Rajkot 35

4.1

PAY

DEPOSITPATIENT

REG ID

4.2

GENERATE

REPORT

Second Level DFD for Deposit

DEPOSITE

DETAIL

REG ID,DEATIL

MANAGEMENT

SEND REPORT

RECEIPT

SECOND LEVEL DFD FOR DEPOSIT


36/42


A.I.T.S. Rajkot 36

5.1

BILL

GENERATIONPATIENT

REG ID

Second Level DFD for Bill Detail

BILL DEATIL

MANAGEMENT

BILL DETAIL

5.1.2

CALCULATE

SHIFTING

CHARGES

5.1.2

CALCULATE

OTHER

CHARGES

5.1.1

CALCULATE

TREATMENT

CHARGES

5.1.3

CALCULATE

NURSING

CHARGES

5.2

TOTAL

RELIEFDEDUCT RELIEF

AMT

REG ID

TOTAL

CHARGE

REG ID

REG ID

TOTAL

CHARGE

TOTAL

CHARGE

REG ID

TOTALCHARGE

REPORT

SECOND LEVEL DFD FOR BILL


37/42


A.I.T.S. Rajkot 37

6.0

RELIEF

PROCESSPATIENT

SEND INFORMATION

Second Level DFD for Relief

REQUEST

RELIEF

RELEIF AMOUNT

RELIEF

AMOUNT

BILL DETAIL

MANAGEMENT

SECOND LEVEL DFD FOR RELIEF


38/42


A.I.T.S. Rajkot 38

7.1

VARIOUS

REPORT

Second Level DFD for Report

REQUEST

REPORT

REPORT

VARIOUS TRANSACTION

MANAGEMENT

VARIOUS MASTER

TRANSACTION

DETAIL

MASTER

DEATAIL

3.8 Additional Comments

The website contains some extra or additional services like free hosting

advertisements, flash files etc. are handled with the change management process

which may discuss later. This website provides high portability thats why we can

change or edit/remove any components from the site easily from server side.

4. Change Management Process


39/42


A.I.T.S. Rajkot 39

To incorporate ad hoc changes in the requirements and to see if proper

changes to the system meet the requirements, change management

process will be done iteratively with all the activities, the following

strategy will be followed.

The Developer will identify a new requirement or a modification in arequirement and communicate it to the team lead via email/Msg or to

the entire team in a meeting.

The Developer will assess the feasibility of the proposed change consideringthe time constraints and structural constraints of the implemented modules and

develop an implementation strategy and submit it to the mentor for approval.

A change plan will be created for the implementation of the change andfollowing sequences of the changes is determined.

The Developer will then continue implementing the new requirements. Thentesting will be done on the new programmed system.

During the testing phase, the product will be tested for satisfying the requestedchanges. After the changes have been done, update will be made to

documentation also.

The changes will then be verified for the last time, and a new system release ismade.

5. Document Approvals


40/42


A.I.T.S. Rajkot 40

All the document of the Online Hospital Management are

correct,Understandable and verified. All the things done in this document is legal ang

in the guidance of Mr.PinakGosh.(prof. AITS). All the DFDs And Other Diagrams

are as per the IEEE Standards. Hence the document is acceptable and correct.The document in this file is an annotated outline for specifying software

requirements, adapted from the IEEE Guide to Software Requirements Specifications

(Std 830-1993).

Approved by: Mr. Pinaki Gosh

Signature: Date:

------------------------------------------ ----------------------


41/42


A.I.T.S. Rajkot 41

6. Supporting InformationAppendix:

SnapShots

Table of Contents

1. Introduction 1

1.1 Purpose 1

1.2 Scope 1

1.3 Definitions, Acronyms, and Abbreviations. 1

1.4 References 2

1.5 Overview 2

2. The Overall Description 4

2.1 Product Perspective 42.1.1 Interfaces 42.1.2 Hardware Interfaces 42.1.3 Software Interfaces 42.1.4 Communications Interfaces 62.1.5 Memory Constraints 62.1.6 Operations 6

2.2 Product Functions 6

2.3 User Characteristics 7

2.4 Constraints 8

2.5 Assumptions and Dependencies 8

2.6 Apportioning of Requirements. 8

3. Specific Requirements 9

3.1 External Interfaces 9

3.2 Functions 9

3.3 Performance Requirements 11

3.4 Logical Database Requirements 11

3.5 Design Constraints 223.5.1 Standards Compliance 22

3.6 Software System Attributes 233.6.1 Reliability 233.6.2 Availability 233.6.3 Security 23

3.6.4 Maintainability 243.6.5 Portability 24


42/42


3.7 Organizing the Specific Requirements 243.7.1 System Mode 243.7.2 User Class 263.7.3 Objects 273.7.4 Functional Hierarchy 28

3.8 Additional Comments 38

4. Change Management Process 38

5. Document Approvals 39

6. Supporting Information 41

Final Project Hms

Documents