Escolar Documentos
Profissional Documentos
Cultura Documentos
Management System
Leonoid Technologies Pvt. Ltd
Project By:
Chandrima Das (07030241006)
1. Introduction ………………………………………… 1
2. Scope ……………………………………………….. 1
4. Functioning ………………………………………… 2
7. Estimation …………………………………………….. 5
References ……………………………………………….. 12
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.
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.
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
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:
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:
6.4 Reports
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
3. Inventory – will have information regarding inventory items in labs and pharmacy.
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.
1. Doctor Scheduling
2. Appointment Scheduling for Patients
3. Operation Theatre Scheduling
4. Duty Roster
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.
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.
Complexity Complexity
Features Low Medical data
Name Low Examination High
Surname Low Observation Average
Sex Low Diagnosis Average
Ph. No Low Prescription Average
DOB Low Diet instruction Low
Age Low Radiology Data
Marital Status Low USG Average
Address Average ECG Average
Bed No. Low X-Ray Average
Insurance Policy No. Low Wet Lab data
Person to contact during Biochemistry Average
emergency Hematology Low
Name Low Time Series data
Relationship Low Blood Pressure Low
Contact Number Low Diabetes Low
Temp Chart. Low
Partogram Low
Drug Administration Average
Bed Side report Low
Module - 6 Resources
Complexity
Organization Structure Module -5 Scheduling
Complexity
Division Low
Department Low
Doctor
Lab Average
Scheduling Average
People Average Appointment For Patient Low
Doctor Low OT Schedule Average
Nurse Duty Roster High
Inventory Consumables
Injectable Average
Medicine Average
Module - 7 Knowledge
Food Supplements Low
Repository
Disposable Complexity
Syringes Low Drug Info
Gloves Low Description Average
Re-Useable Indication and Doses Average
Oxygen Cylinders Low Side effects and Drug Interactions High
Linen Low Warning & precautions/ Overdose High
Durables Contraindications Average
Refrigerator Low Clinical Pharmacology Average
Bed Low
ICU Average
Instrument Average
Computer/Printer Low
Apparatus Average
Bio-Sample Hospital Information Management System – Leonoid Technologies Pvt. Ltd
Tissues Average
Bio-Fluid Average
Estimation through Function Points:
ASSUMED VALUES COMPLEXITY FACTORS TOTAL
EXTERNAL 31 28 5 3 4 6 235
INPUT
EXTERNAL 8 7 4 4 5 7 95
OUTPUT
EXTERNAL 15 12 4 3 4 6 117
QUERY
INTERNAL 38 34 7 7 10 15 711
LOGIC FILE
EXTERNAL 4 2 1 5 7 10 44
INTERFACE
TOTAL 1202
Performance 4 Reusability 2
Heavily Used 2 Conversion & Installation 4
Configuration Ease
Transaction Rates 1 Operational Ease 4
Assumptions:-
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.
Assumptions: -
5. Cost per person per day 25$. Semi-Detached 3.0 1.12 2.5 .35
Calculations: -
Embedded 3.6 1.20 2.5 .32
E = aKLOC b ----(1)
Therefore, Total LOC= 5 (sub-Fn) *75(Main Fn)*110 (LOC) = 41250 LOC=41.25 KLOC.
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.
Adding 1, 00,000 as miscellaneous for other expenses (Travel etc) we get 8,85,995.3 Rs.
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.
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.
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