Medical Information System

APPLICATION DEVELOPMENT – II

SOFTWARE DESIGN SPECIFICATION

Submitted in partial fulfilment for the award of the degree

Of

Master of Science
in
Information Technology
By
Neraja Venugopal

VIT ID: 12MIN2821

WIPRO ID: 292052

School of Information Technology and Engineering

AUGUST, 2017

1|Page
 Table of Contents

1. Introduction……………………………………………………………………………………3
1.1 Purpose………………………………………………………………………………………...3
1.2 Scope of Document……………………………………………………………………………3
1.3 Definitions, Acronyms, and Abbreviations…………………………………………………...3
1.5 Overview of document………………………………………………………………………...4
2. Description of Project…………………………………………………………………………4
2.1 Project Overview……………………………………………………………………………...5
2.2 Project Functions……………………………………………………………………………...6
2.3 User Characteristics…………………………………………………………………………...9
2.4 Constraints to Project Development and Implementation…………………………………….9
2.5 Assumptions and Dependencies………………………………………………………………9
3. Physician Office System……………………………………………………………………..11
3.1 Logical Database Requirements……………………………………………………………..11
3.2 Design Constraints…………………………………………………………………………...11
4. Hospital System………………………………………………………………………………12
4.1 Hospital Digital Record System Performance……………………………………………….12
4.2 Logical Database Requirements…………………………………………………………......12
4.3 Design Constraints…………………………………………………………………………...13
5. Real-time Patient Monitoring System……………………………………………………....12
5.1 Functional Requirements of Real-time Patient Monitoring System…………………………12
5.2 Non- Functional Requirements of Real-time Patient Monitoring System…………………...12
5.3 Real-time Patient Monitoring System Performance…………………………………………13
5.4 Design Constraints…………………………………………………………………………...14
6. Ambulatory Medical System………………………………………………………………...14
6.3 Real-time Ambulatory Medical System Performance……………………………………….14
6.4 Design Constraints…………………………………………………………………………...14
7. Design of Architecture……………………………………………………………………….14
7.1 Design Concept………………………………………………………………………………14
7.2 Data Integration……………………………………………………………………………...15
7.3 Function Integration………………………………………………………………………….16
8. Workflow Design……………………………………………………………………………..17
9. Feasibility Study……………………………………………………………………………...20
9.1 Technical Feasibility……………………………………………………………………........21
9.2 Economical Feasibility……………………………………………………………………....22
9.3 Operational Feasibility………………………………………………………………...…….22
9.4 Schedule Feasibility……………………………………………………………...………….23
References……………………………………………………………………………………....25

2|Page
1. Introduction
1.1 Purpose
The software requirement specification document is specifically designed to delineate the
boundaries of the Healthcare Information System design and functionality. Parties interested
in this documentation would include but not be limited to the system owners, the system
users, the project manager and the design team.

1.2 Scope of Document

This document will identify the pertinent software products we will develop including a
Host DBMS, JAVA software supported and web-based Patient, Physician, and Ambulatory
Input/Outputs, and sensor driven inputs for real-time patient monitoring. The SRS will show that
we will be utilizing SQL server and ASP for interfacing with the Input/Outputs as well as Java
applets for the real-time acquisition of health data from remote sources. Finally, utilizing the
security attributes of XML, XSL, and a secure socket layer in the protocol stack we hope to
address the valid security concerns about the networking and transmission of confidential health
care information.

In addition to the specific design components of this software, this document will make
clear the design team’s goals of creating value-added software which not only correctly captures
patient health information, but then efficiently stores it, sorts it, retrieves it, and delivers this
critical care information where it is needed by healthcare professionals. The benefit of having
accurate, complete, and timely health information is that it will inevitably save human lives.

This software is deliberately focused on medical records and the associated diagnostics. It
is important to point out that this system which is life critical will not have cross functionality
regarding appointment management, billing, or insurance functions, however diagnostic codes
sets will be compliant with present Federal law.

1.3 Definitions, Acronyms, and Abbreviations

1.3.1 Electro-cardiogram (EKG). A device that measures the electrical activity in a biological
heart and measures heart rate.

1.3.2 Pulse oximeter. A device that employs monochromatic light to measures percentages of
oxygenated hemoglobin in blood.

1.3.3 Systolic blood pressure. The peak pressure in the arterial circulatory system.

3|Page
1.3.4 Diastolic blood pressure. The pressure at which the heart’s aortic valve closes.

1.3.5 Emergency medical technician (EMT). A trained emergency healthcare specialist.

1.3.6 Oscilloscope monitor. A cathode ray tube capable of representing a beam of light that
simulates a heart rhythm waveform.

1.3.7 (HIPAA) -The Health Insurance Portability and Accountability Act of 1996

1.3.8 (SDLC)-The Systems Development Life Cycle.

1.3.9 Non-Digitized Professionals. Health Care providers who have no access to digital records
through lack of hardware, software, or preference to legacy flat file charting methods.

1.3.10 (AES)-Advanced Encryption Standard

1.3.11 (DSP) -Distributed Services Provider

1.3.12 (ASP) –Application Service Provider

1.3.13 (FAT32) - File Allocation Table 32 Bit

1.3.14 (TIFF) – Tag Image File Format

1.3.15 (JPEG) - Joint Photographic Experts Group

1.3.16 (DOB) – Date of Birth

1.3.17 Vendor. A licensed and authorized agent of the development team or their vested
remaindermen.

1.3.18 ISO 8601. A standard format for representing date and time recommended by the
International Organization for Standardization

1.3.19 Initial patient information. Information normally gathered during a patient’s first arrival in
a healthcare provider’s office or in an emergency room. This includes but not limited to name,
address, Social Security Number and any health insurance numbers.

1.3.20 (fps) – Frames per second

1.3.21 (CISDC) – Computer Information Society Design Competition

1.4 Overview of document

The Software Requirement Specification will define and illustrate the overall project and
its requirements- both functional and non-functional. In addition, the SRS will define the users

4|Page
and their respective characteristics as well as any constraints to development that the team has
identified.

The format of the SRS document will address the overall project first- including
functions and objectives in an overview. This section will also address how this software
interfaces with other legacy systems and/or diagnostic equipment connected to it. Then the
subsequent sections will specifically addresses the components of the larger software system.
These sections delineate specifications for every facet of the components design.

2. Description of Project

2.1 Project Overview

Medical records are the keystone to the healthcare profession; however these
records are not utilized to their fullest potential. Often records are inaccurate, misplaced, and /or
duplicated unnecessarily. In a world which recognizes the improvement of data digitization and
networking as a constructive force which often increases efficiency while lowering costs; it is
our view that medical records networking could only benefit the quality of healthcare offered in
the United States.

An information system which is primarily linked between a physician’s office and his
hospital would be able to capture and store data from either location giving access to diagnostics
from satellite locations. Added functionality could include ability to gather data in real time from
a remote monitor or an inbound Emergency transport vehicle. [2]

This information system is an industry-compliant application, based upon an open

architecture (Microsoft NT/SQL relational database), and is designed to function within a
standard IEEE compliant Ethernet (10 or 100) Local or Wide Area Network environment, and
will also include Wireless capabilities. The communications protocol is TCP/IP, and is supported
under any routing protocol within an infrastructure (routed or bridged).

The software is based upon standard and emerging web technologies, requiring a
workstation to only be capable of running an Internet Browser such as Microsoft’s Internet
Explorer and Netscape Navigator. Within the browser Java applets will parse and display real-
time data in the form of streaming MPEG 4 video, still images in JPEG or Tiff format, and a java
bean real-time graph plotter from diagnostic equipment anywhere within the network.

As a Distributed Systems Provider (DSP) the system offers all the advantages of an
Application Service Provider (ASP), but overcomes security and proximity issues by allowing
hospitals to keep the primary system at their facility.

5|Page
2.2 Project Functions
2.2.1 The software code should be portable between different operating systems such as
Linux and Windows.

2.2.2 The software should be easy to use and should require minimum manual
operation.

2.2.3 The software should have a user-familiar interface so that the system would not pose an
additional workload to the users.

Note. Interface design would follow generally accepted model conventions for placement
of dropdown menus and toolbars.

2.2.4 The software should allow bidirectional synchronous communication between the user and
the data source in real time.

2.2.5 The software should provide security of operation and confidentiality of information
(restricting access to non-privileged users), by FAT32 compression of data and Rijndael (AES)
encryption algorithms.

2.2.6 The software should allow collection of vital signs and still images of the patient for visual
inspection by experts.

2.2.7 The software should have tools for computer assisted diagnosis like an electronic
stethoscope, a blood oxygen sensor, EKG, and a digital sphygmomanometer.

2.2.8 The software should be able to avoid congestion while transmitting high volumes of
data and images in real-time.

2.2.9 The software should sample video images from diagnostic equipment automatically at
30fps or rates compatible with the transmission capacity available.

2.2.10 The software should be able to interface and link all components of system refer to
Figure 2.2.1

6|Page
 Hospital
Database

Physician’s
Office
Record Record
input retrieval

Record retrieval

Streaming Software to
DataFlow Record input/
be developed
Query
Query
Record input/
Query

Record retrieval
Real-time
Patient EMT
Monitor

Figure 2.2.1 Context Diagram

2.2.11 The system will extend the data capabilities of the Physician’s office, the hospital, and
emergency personnel. Refer to Figure 2.2.2

7|Page
 «extends»
Uses Diagnotics Patient

«extends»

«uses»

Physician Database

«extends»
Physician «uses»
Patient Interface
«extends»
Software TBD
«extends»
Stores

«uses» «uses»
«extends»
-Access Data Structure
Updates
Hospital Database
Hospital Healthcare Interface *
«uses»

* *
«uses» Retrieves
«uses» -Recieves Data -Transmits Data

Sorts
Real Time Monitor
«uses»

EMT Transmits

*
Maintains
«uses» -Data Maintenence
«extends»
System Administrator

Administrative Interface

Figure 2.2.2 Use Cases

8|Page
2.3 User Characteristics
2.3.1 The primary user will be a healthcare professional like a physician, a nurse, or an
emergency medical technician.

Note. This is a Medical Information System therefore to limit access and ensure
integrity of the data only licensed medical personnel have access to input, search, and update
functions.

2.3.2 Nurse Administrators, Physician Office Administrators, System Administrators and/or

Therapists will have limited access and information capabilities.

Note: For the reasons clearly stated in 2.3.1 the System Administrator (or Vendor) will
only be able to access data with his Admin access code in combination with the Physician’s code
while in the physician’s presence.

2.4 Constraints to Project Development and Implementation

2.4.1 The Health Insurance Portability and Accountability Act of 1996 (HIPAA) has mandated
various standards on security, privacy, transaction and code sets, and unique healthcare
identifiers to which this system must adhere.

2.4.2 Legacy systems in place must be considered and modified to interface with the new system
design.

2.4.3 The timebox which encapsulates the SDLC may limit some functionality of the system.

2.4.4 Both the hospital and physician database will need large storage capabilities and a process
to archive outdated data.

(Note. Method and size of Database storage TBD)

2.4.5 Paper flat file medical records will need to be produced and stored to ensure ability to
handle non-digitized medical professionals.

2.5 Assumptions and Dependencies

2.5.1 The system relies on a Physician relationship with a hospital system with which he/she is
a staff member.

2.5.2 The SDLC chosen to implement the system will be model driven and based on
subsequent versions to insure data integrity and functionality. Refer to figure 2.5.1

2.5.3 Due to report length constraints imposed by CISDC, HIPAA regulations will be strictly
followed but kept as a stand alone document.

9|Page
Model Driven System Development Life Cycle
MDD

Preliminary
Investigation

MDD

Problem
Analysis

MDD

Requirements
Analysis

MDD

Decision
Analysis
Physician/ Hospital Data Repository Real-time Patient Monitor
Wireless EMT Connection

MDD MDD MDD

Version 1: Design Version 1: Design Version 1: Design

Construction, Coding, Construction and Construction and
and Implementation Implementation Implementation

MDD MDD MDD

Version 2: Design Version 2: Design Version 2: Design

Construction, Coding and Construction and Construction and
Implementation Implementation Implementation

MDD MDD MDD

Version 3: Design Version 3: Design Version 3: Design

Construction, Coding and Construction and Construction and
Implementation Implementation Implementation

MDD

Subproject Integration
and
Full-System Implementation

Figure 2.5.1 Model Driven Hybrid SDLC

10 | P a g e
3. Physician Office System

3.1 Logical Database Requirements

Fully Attributed ERD

Sendsarchive/recieves
tblOfficeAdmin

PK oOfcAdminId
tblTranscriptionist
oOfcAdminPsw
PK trMdRcTranID
oPaymentDue
trMdRcTranName
oNextApp Is cross-checked/receives chart
oBalance

Generates/is assigned

validates file/ receives data tblCharge_i

PK pPatientID_oOfcAdminID

cChrgeAmt tblTreatment
cServiceName
PK rxTreatmentID

tblMedicalRecord rxTreatmentName
rxMedication
PK rMedRecID rxGeneralInstruction

pPatientID
Presented to/ paid by rxDosage
rxFollowupCare
rFamilyHistory
rAllergies
rSurgicalHistory
rMedications tblPatient

Requires/will remedy
rPresentConditions
PK pPatientID
Associated with/ discusses
rApptHistory
pFirstName
pLastName
Generates data/ is validated pMiddleInitial tblDiagnosis
pBirthDate PK dDiagnosisID
pInsName
pInsID dDiagnosisName
pPhone
pEmail
pStreetAddress
pCity
pState
pZip
pPatientPsw
Patient_n tblPatient_d

PK pPatientID_nNurseID PK pPatientID_drDrId
Formulates/ is made by
pTodayBp pTodaySymptom
pTodayTemp
Is checked/is observed by
Is checked/is observed by
tblNurse tblDoctor
PK nNurseID PK drDrID

nNurseName Summarizes info/ is received by drDrName

Figure 3.4.1 Physicians Office Entity Relationship Diagram

3.2 Design Constraints

3.5.1 Hardware, software, and data communication elements must be sourced within
budgetary constraints.

11 | P a g e
4. Hospital System

4.1 Hospital Digital Record System Performance Requirements

4.1.1 The Hospital software should be able to support up to 300 simultaneous users.

4.1.2The Hospital software should support an internet server, diagnostics inputs (see section
.5.1), thirty two terminals and a SQL server database.

4.1.3 95% of the transactions shall be processed in less than one second.

4.1.4 Data should be secured and backed up every quarter hour.

4.1.5 Power supply should have a back up and a disaster recovery plan.

4.1.6 System should be operable 24 hours a day and accessible in real-time.

4.1.7 Secure Socket Layer 3.0 with 128 bit encryption will enable network security

4.2 Logical Database Requirements

TBD

4.3 Design Constraints

4.3.1 Hardware, software, and data communication elements must be sourced within budgetary
constraints.

5. Real-time Patient Monitoring System

5.1 Real-time Patient Monitoring System Performance Requirements

5.1.1 Acquisition of EKG Data will require solid, wet gel, banana socket, snap or tab
disposable electrode sensors.

5.1.2 Electrode (EKG) sensors will attach to electronic monitoring equipment through 36 inch
IEEE compliant universal lead wires. Refer to Requirement 5.3.1

5.1.3 Pulse oximetry data must be collected using Masimo finger sensor.

5.1.4 Masimo finger sensor must connect to Masimo interface cable. Refer to Requirement

12 | P a g e
5.2 Design Constraints
5.2.1 Real-time Sensors and Diagnostics may need to be simulated due to inability to access
authentic healthcare equipment.

5.2.2 Data Integrity and Security are life critical issues with this system.

5.2.3 Redundant power and transmission should be addressed as this system is life critical.

6. Ambulatory Medical System

(Note. Asked source about blood type, allergies, etc. informed that information presently not
relevant to EMT. [1])

6.3.1 The software to be developed shall accept output from existing patient monitoring
equipment.

6.3.2 The software to be developed shall display graphical and numeric data at a remote location
in real time.

6.3.3 The software to be developed shall graphically display output from an EKG oscilloscope
monitor.

6.3.4 The software to be developed shall display numeric output from an EKG monitor.

6.3.5 The software to be developed shall display numeric percentages from a pulse oximeter.

6.3.6 The software to be developed shall display numeric values for systolic blood pressure.

6.3.7 The software to be developed shall display numeric values for diastolic blood pressure.

6.3.8 The software to be developed shall display numeric values for mean blood pressure.

6.3.9 The software to be developed shall display text values for patient identification.

6.2.1 The software to be developed must display correct numeric pulse oximeter values at a
remote location within five seconds. (Note. Correct values within 3% of actual [1])

6.4.2 The software to be developed must display correct numeric EKG values at a remote
location within five seconds.

6.4.3 The software to be developed must display a correct graphical EKG oscilloscope waveform
at a remote location within five seconds.

6.4.4 The software to be developed must display correct numeric blood pressure values at a
remote location within five seconds.

13 | P a g e
6.4.5 The software to be developed must operate twenty-four hours a day.

6.3 Real-time Ambulatory Medical System Performance Requirements

TBD

6.4 Design Constraints

TBD

7. DATA DESIGN

7.1 Design Concept

The complicated digital hospital environment could beconsidered as a digital neural network
system, as depicted inThe outmost ring, analogous to neural end, contains theterminals,
workstations, medical devices and even sensors in the hospital, through which all kinds of end-
users could interface with the system. The end-users do not need to be aware of the internal
structure of system at all. The middle ring, assimilated to peripheral neural system, contains all
kinds of the medical information systems, through which most of the tasks in a hospital are
accomplished. Among them, some are departmental systems such as PACS, RIS and LIS, while
others are enterprise systems such as HIS. Since most of the systems come from different
vendors, they are often heterogeneous and isolated. In order to fulfil the digital workflow among
these systems, a kind of framework or model is necessary to specify how to exchange

Digital neural network system in hospital

14 | P a g e
messages among these systems to achieve the workflow integration. Proceedings of the 2005
IEEE Engineering in Medicine and Biology 27th Annual Conference Shanghai, China,
September 1-4, 2005 0-7803-8740-6/05/$20.00 ©2005 IEEE. 6957 Digital neural network
system in hospital The central ring, assimilated to central neural system, is the core of Enterprise
Hospital Information System, which contains a “virtual” data center and a set of middleware
components interfacing with the systems in the middle ring and the terminals in the outmost ring.
The word “virtual” means that other than archiving all clinical data itself, the data center actually
manages all data through linkage to the real data records distributed in different systems. The
middleware components are based on web service, a middleware architecture using Simple
Object Access Protocol (SOAP). The standard interfaces for each service are defined to provide
common functionalities, and support Enterprise Viewers (See Fig.2).

7.2 Data Integration

With more and more systems being introduced into hospital, a key problem is how to keep an
integrated data set. To keep all clinical data in one storage seems to be a good solution, but due
to the large quantities of clinical data and the complexity to unify all data from heterogeneous
systems, it proves to be effective only in small hospitals or newly-built hospitals. In the
architecture, the concept of “virtual” data center has been introduced. The clinical data are
distributed and archived in corresponding departmental systems or enterprise systems. The data
center stores the linkage information of each data record in different heterogeneous

15 | P a g e
 The architecture of Enterprise Hospital Information System
Systems, thus functioning as a “virtual” data center for all clinical data. The data records stored
in the actual data center are 6W1H (Who, When, Where, toWhom, What, Why, How)
information for the clinical events. To be ideal, any event, as long as it happens in the clinical
environment, it should be recorded, including making clinical report, injecting medicine to a
patient and measuring body temperature for a patient, to name a few. For an example, when a
radiologist makes a report, the information of the radiologist who makes the report (Who), the
time and the department of the report (When & Where), the patient whom the report belongs to
(toWhom), the event type of the report (What), the event of the radiology order of the report
(Why), the report status of creating, editing or confirming (How), and the data link of the report
are recorded.

Compared to the data structure based on patient or visit, 6W1H data structure is more flexible
and could be used for different requirements of data view such as the patient record view (the
events happened on the patient), the doctor task view (the events initiated by the doctor), and
even the process management view (the events linked each other by the “Why” element).
According to the practical situation of each existing system, the event recorded could be either
cursory if the system is difficult to be expanded or in detail if the system could be tailored.

7.3 Function Integration

Hospitals have a strong need for affordable, interoperable information systems. These systems
must operate seamlessly across a wide variety of institutions pharmacies, laboratories, physician
practices of all sizes, outpatient clinics, community hospitals, and tertiary/quaternary care
regional medical centers. They have many operations (methods) in common across the clinical
departments. In the architecture, these common operations are realized as a set of web services
on an enterprise basis to implement the function integration. 1) Data Registry Service: In order to

16 | P a g e
implement the “virtual” data centre, it’s necessary for all medical information systems to register
the data through the Data Registry Service to the actual data server wherever and whenever the
clinical event happens through the Data Registry Service. The systems must at least register the
data linkage information to the data center while the data record is created, deleted and updated.
The schema of storage has the good expansibility since new systems are easier to be merged into
the architecture by complying with the interface of Data Registry Service. 2) Patient
Identification (ID) Service: Throughout an individual’s lifetime they may have episodes of care
provided by healthcare organizations. When a patient comes into a healthcare organization for
care there is a need to find the records for any previous care. Each system may have 6958 used a
different scheme (e.g. numbering system) to identify the patient. It is desirable to combine the
medical records from multiple institutions in order to show a complete picture of a person’s
health record. One of the major impediments to this sharing of patient records between
organizations is a lack in the ability to identify a patient in a consistent manner. Due to this
inability Patient ID Service specifies the common interfaces that allow multiple systems to
interoperate.

8. WORKFLOW DESIGN

Data integration is oriented to create the “virtual” datacenter to manage the entire distributed
clinical data, while function integration is oriented to provide common functionalities for
systems in healthcare institutions. None of them focus on the workflow, which is a technology
that manages and monitors processes and allows the flow of work between individuals and/or
departments to be defined and tracked. It is usually implemented by the data relationship of the
database in the client-server model. But in a distributed environment such as a healthcare
institution, the implementation will be more complicated. Middleware technologies such as Web
Service could be used to implement the digital workflow by tackling with distributed database
environment just like one database in client-server model. But it has no expandability in terms of
adding new system into the architecture especially when the data structures are unknown.
Standard messages such as DICOM and HL7 have already been applied in many systems to
implement the workflow between different systems, but a complete integration is

17 | P a g e
still difficult if there is no framework or model to guide the system to exchange the correct
message in correct time. IHE is an initiative designed to stimulate the integration of information
systems that support modern healthcare institutions. Using a common framework, IHE employs
existing protocols like DICOM and HL7 to connect devices, terminals and information systems
in a hospital so as to fulfill the digital workflow. Up to now, it contains 12 integration profiles for
radiology technical framework each of which specifies the model of one clinical application
environment. Fig.3 depicts the Scheduled workflow integration profile. The Scheduled
Workflow Integration Profile establishes the continuity and integrity of basic departmental
imaging data acquired in an environment where examinations are being ordered. It specifies a
number of transactions that maintain the consistency of patient and ordering information as well
as defining the scheduling and imaging acquisition procedure steps. There are actually four
different systems involved, corresponds to ADT and Order Placer actors, RIS corresponds to
DSS/Order Filler and Performed Procedure Step Management actors, PACS corresponds to
Image Manager, Image Archive, Image Display and Evidence Creator actors, Modality
corresponds to Acquisition Modality actor. By implementing each system with the standard
transactions, we could easily achieve the workflow integration.

18 | P a g e
 Design concept of Enterprise Viewers

19 | P a g e
 Clinical implementation of the first two phases

E. Enterprise Viewer
Now that we could access all clinical data through the schema of the “virtual” data center, the
key is how to organize and present them in an appropriate way so that the data could be fully
utilized. Enterprise Viewer Services achieve this goal by reorganizing the entire clinical data set
and projecting the specialized view for users of each role. Included are Physician’s View,
Clinical Specialist’s View, Patient’s View, Department Manager’s View, Senior Executive’s
View, and IT Manager’s View

9. Feasibility Study

Depending on the results of the initial investigation the survey is now expanded to a more
detailed feasibility study. “FEASIBILITY STUDY” is a test of system proposal according to
its workability, impact of the organization, ability to meet needs and effective use of the
resources. It focuses on these major questions:
1. What are the user’s demonstrable needs and how does a candidate system
meet them?
2. What resources are available for given candidate system?
3. What are the likely impacts of the candidate system on the organization?
4. Whether it is worth to solve the problem?

20 | P a g e
 During feasibility analysis for this project, following primary areas of interest are to be
considered. Investigation and generating ideas about a new system does this.
Steps in feasibility analysis

Eight steps involved in the feasibility analysis are:

✓ Form a project team and appoint a project leader.

✓ Prepare system flowcharts.
✓ Enumerate potential proposed system.
✓ Define and identify characteristics of proposed system.
✓ Determine and evaluate performance and cost effective of each proposed system.
✓ Weight system performance and cost data.
✓ Select the best-proposed system.
✓ Prepare and report final project directive to management.

9.1) Technical feasibility

A study of resource availability that may affect the ability to achieve an acceptable
system. This evaluation determines whether the technology needed for the proposed
system is available or not.
 Can the work for the project be done with current equipment existing software
technology & available personal?

 Can the system be upgraded if developed?

 If new technology is needed, then what can be developed?
This is concerned with specifying equipment and software that will successfully satisfy the
user requirement. The technical needs of the system may include:
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.

21 | P a g e
 Front-end selection:

It must have a graphical user interface that assists employees that are not from IT
background.
1. Scalability and extensibility.
2. Flexibility.
3. Robustness.
4. According to the organization requirement and the culture.
5. Must provide excellent reporting features with good printing support.
6. Platform independent.
7. Easy to debug and maintain.
8. Event driven programming facility.
9. Front end must support some popular back end like Ms Access.
According to the above stated features we selected VB6.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.

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.

22 | P a g e
 9.2) Economical feasibility
Economic justification is generally the “Bottom Line” consideration for most systems.
Economic justification includes a broad range of concerns that includes cost benefit analysis.
In this we weight the cost and the benefits associated with the candidate system and if it suits
the basic purpose of the organization i.e. profit making, the project is making to the analysis
and design phase.
The financial and the economic questions during the preliminary investigation are
verified to estimate the following:
The cost to conduct a full system investigation.
The cost of hardware and software for the class of application being considered.
The benefits in the form of reduced cost.
The proposed system will give the minute information, as a result the performance is
improved which in turn may be expected to provide increased profits.
This feasibility checks whether the system can be developed with the available funds. The
Hospital Management System does not require enormous amount of money to be developed.
This can be done economically if planned judicially, so it is economically feasible. The cost of
project depends upon the number of man- hours required.

9.3) Operational Feasibility

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.

23 | P a g e
 9.4) Schedule feasibility

Time evaluation is the most important consideration in the development of project. The time
schedule required for the developed of this project is very important since more development
time effect machine time, cost and cause delay in the development of other systems.

A reliable Hospital Management System can be developed in the considerable amount of time.

24 | P a g e
References
[1] Mack, Francis E. MD, Personal Interview February 1, 2003

[2]Sundaram, Senthilnathan, Requirements Analysis of Software Requirements for

Telemedicine and the HealthCare Industry, Master Thesis, UCF,

Orlando, Florida, July 19, 2002

25 | P a g e