hospital information management system - cover page

Hospital Information Management System Leonoid Technologies Pvt. Ltd

Project By:

Chandrima Das (07030241006)

Raveesh Goswami (07030241024)

Sampreeth Agara (07030241029)

Saurabh Soni (07030241032)

Surbhit Bansal (07030241033)

Vijay Chakule (07030241035)

Hospital Information Management System – Leonoid Technologies Pvt. Ltd

Table of Contents

1. Introduction ………………………………………… 1

2. Scope ……………………………………………….. 1

3. Requirements for HIMS ……………………............. 1

4. Functioning ………………………………………… 2

5. Salient Features …………………………………….. 2

6. Features Overview …………………………............. 3

6.1 Patient Registration …………………………….. 3

6.2 Billing ………………………………………….. 3

6.3 Electronic Medical Report (EMR) …………….. 3

6.4 Reports …………………………………............ 4

6.5 Resources ………………………………............ 4

6.6 Scheduling ……………………………………... 5

6.7 Knowledge Repository ………………………... 5

7. Estimation …………………………………………….. 5

7.1 Function Point Model …………………….................. 5

7.2 COCOMO Model …………………………………… 10

8. Probable risks and Solution …………………………… 11

References ……………………………………………….. 12


1. Introduction:

Hospital Information Management (HIMS) System is designed for hospitals, which covers the wide range of hospital administration and management processes. It provides relevant information across the hospital to support effective decision making for patient care, scheduling and billing, in a seamless flow.

2. Scope: 1. The base product is an integrated system for storing, visualizing, querying and

retrieving patient medical records, cost of treatment and hospital inventory. 2. The system caters to various departments in a hospital setup. 3. The system has facility to register patients with a unique ID. 4. The System features a Knowledge Repository that includes Standard Protocols and

Drug Information. 5. Appointment scheduling is an integral part of the system. 6. The system provides facility to generate customized Reports/Discharge summary. 7. The system has facility to export data that can be customized.

3. Requirements for HIMS (Functional and Non-Functional): Functional:

1. Patient information 2. Clinical laboratory, radiology, and patient monitoring 3. Patient census and billing 4. Staffing and scheduling 5. Outcomes assessment and quality control 6. Pharmacy ordering, prescription handling, and pharmacopoeia information 7. Decision support 8. Finance and accounting 9. Supplies, inventory, maintenance, and orders management

Non-Functional:

1. Access to information. 2. Improvement in quality of documentation. 3. Improving quality of patient care. 4. Improvement in communications. 5. Reduction in errors of omission. 6. Reduction in medication errors. 7. Reduction in hospital costs. 8. Development of a common clinical database. 9. Enhancing ability to track patient's record.


10. Improving hospital image.

4. Functioning: The system is a software application that consists of seven modules that would be developed by Leonoid Technologies Pvt. Ltd. These seven modules are basically providing various controls functioning between various functions that concern a hospital management. The system is connected to an EAI that communicates between database of hospital and front end application. The front end application is being developed by us and the cost of integrating it with EAI would be an additional cost that would depend on the number of licenses that the hospital opts for.

5. Salient Features/Functionalities The base product has the following functionalities:

Registration

Billing

Electronic Medical Records (EMR)

Reports

Resources

Scheduling

Knowledge Repository


6. Features Overview 6.1 Patient Registration (Admission) This feature will enable the user to capture information about the Out/ In Patient. Patient Registration includes essential details such as „Name‟, „Surname‟, „Sex‟, „Phone Number‟, „Date of Birth‟, „Age‟ etc. A unique ID is generated by the application for each registered patient. In addition, there is a provision to capture a unique identifier for each patient, which can be his/her „Passport‟, „PAN issued by Income Tax Department of India‟, „Driving License‟, „Voter‟s ID issued by EC of India‟, etc. A combination of the Patient ID and the identifier will be unique and would help in distinguishing patients sharing the same name, surname or date of birth. Patient Registration also includes facility to capture more details such as „Marital Status‟, „Contact Address‟ of the patient and place of registration. Additionally, facility to capture details of person to be contacted in case of emergency, like „Name‟, „Relationship‟, „Contact Number‟, „Address‟ etc, has been provided. If the patient is covered under Medical Insurance, then there is provision to capture information regarding the same including „Policy No.‟, „Sum Insured‟, „Insurer‟, „TPA‟, etc. 6.2 Billing This feature will allow user(s) with appropriate privileges to generate, store and retrieve information of billing and keep track of individual payments for the following categories: 1. Consultation – General, Health Check-up, Specialist, etc. 2. In-Patient – Ward/Bed Charges, Surgical, etc. 3. Laboratory – Diagnostics like Blood Sugar test, Biopsy, ECG etc. 4. Pharmacy – Medicines, Consumables, etc. 5. Miscellaneous – Anesthetist Charges, Dressing, Accommodation, etc. 6.3 Electronic Medical Record (EMR) This feature will help users (usually Doctors, Nurses or any authorized person) to capture information of the patient in an electronic format. Following are few typical categories: 1. Medical Data - Examination, Operation (Surgical) Procedure, Observation,

Diagnosis, Prescription, Diet Instruction, etc.

2. Radiology Data - USG, ECG, X-ray, etc.


3. Wet Lab Data - Information of the analyzed sample obtained from the patient for investigations like Biochemistry, Hematology, etc.

4. Time Series Data - Time-dependent parameters of the patient such as Partogram, Temperature Chart, Nurse‟s Bedside Report, Diabetes management, Blood pressure monitoring (PIH), Drug administration, etc.

6.4 Reports The following types of reports can be generated for In/Out Patients: 1. Investigation Reports 2. Discharge Summary 3. Depending upon the specialization of a department, report formats can be

customized and/or templates can be provided. 6.5 Resources This feature will contain information regarding: 1. Organization structure – Divisions, Departments, Labs, People, etc.

2. People – Affiliation of human resources such as Doctors, Nurses, etc. to various

divisions, departments. 3. Inventory – will have information regarding inventory items in labs and pharmacy. Inventory will be categorized as: 1. Consumable - Any resource that will be used up and not generate immediate

hazardous remnant. Ex: Injectables, Medicines, food supplements, etc.

2. Disposable - Any resource that will be used up and generate disposable remnant. Ex: Syringes, gloves etc.

3. Reusable - Any resource that will be reused over a period of time, but

servicing/refilling will be needed after every cycle of use. Ex: Linen, Oxygen cylinders, etc.

4. Durable - Any resource that will be used over a period of time, but servicing/refilling

may not be required after each cycle of use. Ex: Refrigerators, Beds, ICU equipments, Instruments, Apparatus, Computers, Printers etc

5. Biosample - Any resource that is collected from the patients as a part of medical

examination, Ex: Bio-fluids, Tissues etc.


6.6 Scheduling This feature will facilitate: 1. Doctor Scheduling 2. Appointment Scheduling for Patients 3. Operation Theatre Scheduling 4. Duty Roster 6.7 Knowledge Repository This feature will help to capture information on the following: 1. Drug Information - Description, Clinical Pharmacology, Indications & Dosage, Side

effects & Drug interactions, Warnings & Precautions and Overdose & Contraindications about relevant drugs.

2. Standard Protocols - Medical procedures undertaken at predefined conditions.

7 Estimation through Function points and COCOMO model:

7.1 Function Point Estimation:

Some points considered before calculating the FP‟s for this system: 1. Module 1:- 1 Display, Maximum inputs from the users and contains patient

information. 2. Module 2:- Total 4 displays, each function sub divided into more sub-functions, only

the major functional applications have been shown. Getting 1 Input from module1. 3. Module 3:- 2 Displays, Investigation and discharge, 6 inputs from module 1 and 11

from module 2. 4. Module 4:- 3 Displays and 10 inputs from mod-1, 4 from mod-2, 1 from mod-3, 6

from mod-6 and I from mod-7. 5. Module 5:- 3 Displays and 2 inputs from mod-1, 2 from mod-6 and 1 from mod-7. 6. Module 6:- 1 Display and 2 inputs from mod-1, 2 from mod-2 and 1 from mod-7. 7. Module 7:- 1 Display and 1 input from mod-1, 6 from mod-2 and 1 from mod-4.


All these inputs and connectivity‟s have been used to calculate the internal logic connections in the system. Note: -The details have not been given in complete but on an average each function shown below in the module tables can be further divided into 4-5 sub-functions whose complexities would be low. EIF: - USG, ECG, Data Base (Back end through EAI), BP, Pathology, Temperature, Diabetes. The complexities shown below are based on parameter that each function is going to hold i.e. <=19 is low, <=49 is average and >=50 is high. Modules and their complexity values which have been used for calculating function

points.

Module- 1 Patient Registration

Complexity

Features Low

Name Low

Surname Low

Sex Low Ph. No Low

DOB Low

Age Low

Marital Status Low

Address Average

Bed No. Low

Insurance Policy No. Low Person to contact during emergency Name Low

Relationship Low Contact Number Low

Module -2 EMR (Electronic Medical Reports)

Complexity

Medical data

Examination High

Observation Average

Diagnosis Average

Prescription Average

Diet instruction Low

Radiology Data

USG Average

ECG Average

X-Ray Average

Wet Lab data

Biochemistry Average

Hematology Low

Time Series data

Blood Pressure Low

Diabetes Low

Temp Chart. Low

Partogram Low

Drug Administration Average

Bed Side report Low


Module - 3 Reports Complexity Investigation report Blood Average Urine Average ECG High Chest X-Ray High Sonography High Blood Clotting Time Low Blood grouping Low Blood Sugar Low Discharge Summary Name Low Age Low Sex Low Diagnosis High Date of Admission Low Date of Discharge Low Presenting Complain Average Past History Average Investigation done Average Treatment given High Follow-ups Low Medication Low Name of the Doctor Low

Module - 4 Billing Complexity Consulting General Average Health Check-up Average Specialist Low IPD Ward/Bed Charges Low Surgical Average Laboratory Blood Sugar Low Biopsy Low ECG Average Urine Average Blood Grouping Low

Blood Average Pharmacy Medicine Average Surgical Average Misc Anesthetist Charges Average

Dressing Low

Accommodation Low

Module - 6 Resources

Complexity

Organization Structure

Division Low

Department Low

Lab Average

People Average

Doctor Low

Nurse

Inventory Consumables

Injectable Average

Medicine Average

Food Supplements Low

Disposable

Syringes Low

Gloves Low

Re-Useable

Oxygen Cylinders Low

Linen Low

Durables

Refrigerator Low

Bed Low

ICU Average

Instrument Average

Computer/Printer Low

Apparatus Average

Bio-Sample

Tissues Average Bio-Fluid Average

Module -5 Scheduling Complexity Doctor Scheduling Average Appointment For Patient Low OT Schedule Average Duty Roster High

Module - 7 Knowledge Repository Complexity Drug Info Description Average Indication and Doses Average Side effects and Drug Interactions High Warning & precautions/ Overdose High Contraindications Average Clinical Pharmacology Average


Estimation through Function Points:

ASSUMED VALUES COMPLEXITY FACTORS TOTAL

S.NO LOW AVERAGE HIGH LOW AVERAGE HIGH

EXTERNAL

INPUT

31 28 5 3 4 6 235

EXTERNAL

OUTPUT

8 7 4 4 5 7 95

EXTERNAL

QUERY

15 12 4 3 4 6 117

INTERNAL

LOGIC FILE

38 34 7 7 10 15 711

EXTERNAL

INTERFACE

4 2 1 5 7 10 44

TOTAL 1202

VALUE ADJUSTED FACTORS

General System Char. Value General System Characteristic

Value

Data Communications 3 On-Line Updates of Master File

0

Distributed Processing 2 Complex Processing 2

Performance 4 Reusability 2

Heavily Used Configuration

2 Conversion & Installation Ease

4

Transaction Rates 1 Operational Ease 4

On-Line Data Entry 1 Multiple Sites 3

End-User Efficiency 3 Backup & Recovery 3

Total Degree of Influence (TDI)

34

VAF (Value adjusted factor) = (TDI*.01) +.065= (34*.01) +.65= 0.99

COUNT TOTAL= VAF*FUNCTION POINT= 1202*0.99= 1189.98


The above table here uses an empirical method of calculating effort and cost. (Sources have

been mentioned in References).

Assumptions:-

1. Programming language is Visual C.

2. No. of persons required 6.

3. Cost per person per day 25$ (Used in India).

4. Miscellaneous cost for other expenses like traveling etc.


5. Buffer of 15 days for safety purpose.

6. Quality and testing 15 days set and same persons are going to do.

7. Saturday and Sunday have been considered holidays and so adjusted with extra 24

days.

Computing Function Points

EI EO EQ ILF EIF Functionality

Parameters

Module 1 (Patient Registration) 16 1 4 20 0 20

Module 2 (EMR) 0 4 2 3 4 18

Module 3 (Reports) 9 4 7 9 3 21

Module 4 (Billing) 16 1 4 16 0 16

Module 5 (Scheduling) 3 6 4 6 0 4

Module 6 (Resources) 20 2 7 20 0 20

Module 7 (Knowledge Repository) 0 1 3 1 0 7

7.2 Estimation using COCOMO model:

COCOMO model uses LOC for calculations. COCOMO has been defined for three classes of

software‟s and we are going to use “SEMI-DETACHED” because the project is of rigid as well

as flexible requirements.

Assumptions: -

1. Programming Language is Visual C.

2. Average LOC by a developer in a day is 60 (source in references) according to

estimates made by experts. (Min-40 and max-100).

3. Person working are 6.

4. Project is to be completed in 5

months so approx 120 days of

working.

5. Cost per person per day 25$.

Calculations: -

E = aKLOC b ----(1)

Development Time = cEd ------(2)

Software project a b c D

Organic Project 2.4 1.05 2.5 .38

Semi-Detached 3.0 1.12 2.5 .35

Embedded 3.6 1.20 2.5 .32


The system has in all 75 functionalities (specified in modules shown above) and each

application on an average has 5 sub-functions. The average line of code according to

information available from sources (References) is 95-120 lines per Application functionality

in C/C++ so we are taking 110 lines as average.

Therefore, Total LOC= 5 (sub-Fn) *75(Main Fn)*110 (LOC) = 41250 LOC=41.25 KLOC.

Now applying it in equation (1) we get

E= 3 *(41.25^1.12) = 193.37 person month

Putting in equation (2)

D= 2.5*(193.37^0.38) = 18.48 months/person

Considering 6 developers = 18.48/6 = 3.08 months

Adding one month of buffer and quality and testing= 3.08 + 1= 4.10 months approx adding

24 days of holidays i.e. 24/30= 0.8.

Total time is then 4.8 months.

Cost would be 25$ * 45(Conversion to Rs.) * total 116.3 days= 7, 85,995.3 Rs

Adding 1, 00,000 as miscellaneous for other expenses (Travel etc) we get 8,85,995.3 Rs.

8. Probable Risks and their Solution:

1. The electricity may go while the entries are still being done so the system would be

available with a dedicated battery back up.

2. The communication of front end application with back end may create problem so we

would take services of an oracle certified partner.

3. Any module may show error and hinders the progress of work thus we have designed

modules to work independently.

4. Incomplete data may be entered in the system so some field are made mandatory which

have to be filled before the entry can be made.

5. During emergency, system may show error so the system may be run in safe mode with

minimum functionality.

6. Data stored unsorted at the back end so proper normalization techniques are used while

storing of data.

7. Security risks are one of the major threats so minimum connectivity with the internet is

provided.


8. End user may not be comfortable with system so proper training needs to be provided to

the hospital staff.

9. The interfacing done with various systems may not be proper so a suitable middleware

application needs to be chosen also a certified implementer is required.


REFERENCES

1. http://www.softwaremetrics.com/Function&percnt;20Point&percnt;20Training&percnt;20Book

let&percnt;20New.pdf

2. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1492375

3. http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10923/34372/01640

4. http://www.codeproject.com/gen/design/Estimation.asp

5. http://www.codeproject.com/gen/design/cocomo2.asp

6. http://www.ijcim.th.org/past_editions/v13n1/IJCIM-V131-pp3.pdf

7. http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=39

8. http://msdn2.microsoft.com/en-us/library/bb245774.aspx

9. “Software Engineering” by Roger R. Pressman.

http://www.softwaremetrics.com/Function&percnt;20Point&percnt;20Training&percnt;20Booklet&percnt;20New.pdf

http://www.softwaremetrics.com/Function&percnt;20Point&percnt;20Training&percnt;20Booklet&percnt;20New.pdf

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1492375

http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/10923/34372/01640

http://www.codeproject.com/gen/design/Estimation.asp

http://www.codeproject.com/gen/design/cocomo2.asp

http://www.ijcim.th.org/past_editions/v13n1/IJCIM-V131-pp3.pdf

http://www.softdevtools.com/modules/weblinks/viewcat.php?cid=39

http://msdn2.microsoft.com/en-us/library/bb245774.aspx

hospital information management system - cover page

Documents