FSD 3340703

PRACTICAL: 3

AIM: Prepare SRS Document for Software :

 SOFTWARE REQUIREMENT SPECIFICATION FOR E-HEALTH

APPLICATION

Table of Contents

1. Introduction ...................................................................................................2
1) Purpose .......................................................................................................... 2
2) Scope ............................................................................................................. 2
3) Overview ....................................................................................................... 2
2. General Description .......................................................................................3
3. Functional requirement ............................................................................... 3
4. Interface requirement.................................................................................... 4
1) User Interface ................................................................................................ 4
2) Hardware Interface....................................................................................... 5
3) Software Interface ........................................................................................ 5
4) Communication Interface ............................................................................ 5
5. Performance requirement............................................................................. 5
6. Design constaints............................................................................................ 6
7. Non-functional Attribute............................................................................... 6
8. Operational scenario ..................................................................................... 7
9. Preliminary schedule..................................................................................... 8
10. Preliminary budget.......................................................................................8
11. References .................................................................................................... 8

186170307059 Page no: 1 Arin Modi

FSD 3340703

1. Introduction
1) Purpose :
The software requirement is specifically designed to delineate the
boundaries of the Healthcare Information System design and functionality.
Users interested in this documentation would include but not be limited to the
system owners, the system users, the project manager and the design team.
2) Scope:
This software system capabilities support clinical and enable redesign
and improvement of healthcare workflow and processes, a disciplined referred
towards health informatics, The automated support of daily activities carried
out in health care organization-and use of this software by the professions of
medicine, nursing and public health to develop new, streamlined and more
effective workflows in the care of patients with the intention of improving
healthcare-is the unique discipline of informatics.

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.

3) Overview:
The benefit of having accurate, complete, and timely health
information is that it will inevitably save human lives
While we are always aware of our health, we still haven't
created a system that tracks our health. Tracking health does not always mean
that how many steps we have walked or how much calories we have burned,
but also our past is necessary. This system provides an easier way to get
medical history of a patient regardless of availibility of documents with
patients.

186170307059 Page no: 2 Arin Modi

FSD 3340703

2. General Description:

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

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.

3. Functional Requirements:

 The software must allow input of patient data from patient (initial) home, secured
access at Physician and Nurse Workstations, and from the data streaming real-time
monitoring equipment.
 The software must request username, password and OTP for access to data, only after
authentication will allow access to the system.
 The software must require high levels of error correction and input validation.
Message box prompts would require a second entry of key data fields including
name, DOB, Social Security Number, medications and allergies. Doctor’s inputs will
similarly prompt proper code sets for diagnosis.
 The software must allow browsing by the physician of historical medical information
of his/her patients only.
 The software must identify the patient on the basis of patient’s mobile no.

186170307059 Page no: 3 Arin Modi

FSD 3340703

 The software must retrieve, update, and store data from multiple input locations
including but not limited to hospital workstations, physician workstations, inbound
emergency vehicles, and electronic monitoring equipment.
 The software must allow patient to view their own medical record online a only by
entering phone number and there after they will get OTP to sign in securely ..
 The software to be developed must display the correct patient name.
 The software to be developed shall display the correct sign-in time of day.
 The software to be developed must operate without interruption twenty-four hours a
day.
 The software must allow full and complete record search queries by physicians; also
allow access to limited blood-work, medication, and allergen information by EMT
personnel and display results in order specified by operator.
 The software must allow input of diagnostic imagery and FAT32 compression for
storage and transmission of data.
 The software must enable to keep medical history of minimum 10 years.
 The software must retrieve and sort medical record information and allow for screen
and print output of said information. Print output will include name, DOB, and
requested diagnostic information only.
 The software must encrypt the data from the database for transmission from point to
point.
 The software must be able create access for doctor to update and the history of patient
by requesting permission of user
4. Interface Requirements:
1. User Interface:
 The major interfaces of the system are:
 Dashboard():
 The dashboard will be accessible by all types of users. Here they will perform
respective tasks according to their permission level.
 Almost all the interfaces like Upload-History(),View-History (),login/sign-up,
System-Admin() will be accessed from the dashboard.
 It is the system administrator who assigns the access to each type of users. From the
dashboard all types of users will access the software.

186170307059 Page no: 4 Arin Modi

FSD 3340703

 System Administrator will upload a project, data engineers will export the data and
prepare report and the high level officials will view them. And all activities will be
done through the Dashboard shown above.
2. Hardware Interface:
 Database interfacing will use standard TCP/IP protocols, but using FOSS libraries,
for computers connected to the internet via LAN Ethernet cables. Due to security
concerns and the ease of hackers cracking Wi-Fi hotspots, Wi-Fi internet support
with the software is prohibited by the software. The software detects whether a LAN
or Wi-Fi connection is used, and will terminate the program if Wi-Fi is detected to be
in unauthorized use for the internet connection.
3. software Interface:
 Our software contains mainly three functions on interface of the software.
 Upload-History()
 This interface is accessible to doctors who can upload the history of the patients
 View-History()
 This interface is accessible by doctors and patients to view the history
 Generate-Report()
 This interface will be used mainly by Data Engineer to analyze data and produce
report. Also it will accessible by the doctors and patients to generate the report of the
history.
 Share information()
 This interface will be used by only doctors to share the current or previous history of
patients to other doctor or hospital or clinic
4. Communications Interface:

 Communication interfaces will use TCP/IP for data transmission and SMTP/HTTP for
generating e-mails of reports from the software. FTP can also be used in pushing
generated document reports to a hospitals FTP server.
5. Performance requirements :

 The software should have high performance and low failure rates. The hardware and
software should be able to transmit/receive data from databases with high speed
rates, ranging from Mbps to Gbps.

186170307059 Page no: 5 Arin Modi

FSD 3340703

 Machines should have all recent Windows updates installed, and have their security
not compromised by viruses.
 Machines must have firewalls installed and active virus scanning software in usage.
Machines should solely be used for operation of the software, in order to maximize
performance and security
 All database queries and data receiving/transmitting should be done using TLS or
higher security transmission.
6. Design constraints:
 The site is targeted to run all over the country. So being a huge system it needs to
face several constraints and limitations which may lag the performance of
architecture.
 As Nepal has a unique geography of hills and terrains, deployment of architecture
will be a constraint. As the architecture will be set up with government support, after
the system is set up, skilled manpower will also play key role in delivering the
quality service to the users.
 As E-Health architecture is about providing services online, we should make sure the
power supply, internet, internet bandwidth and communication with central server is
always up and functioning.
 The architecture will receive huge no. of data so the classification of applications,
targeted user groups and classification of data are some essential constraints to be
considered throughout the development and use of system
7. Non-Functional Attributes:
 The software interface must follow design conventions which allow for familiar
location of drop down menus, help etc.
 Input errors will be returned in red with appropriate message box.
 More than three attempts at login and failure will produce a red flag to system
administrator.
 In The Home page of the software, there is a must option of Doctor's login and
Patient's login.
 The software should be able to support at least three simultaneous users.
 The software should support diagnostics inputs.
 Data should be secured and backed up every day.

186170307059 Page no: 6 Arin Modi

FSD 3340703

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

 System should be operable 24 hours a day and accessible in real-time.
 Secure Socket Layer 3.0 with 128 bit encryption will enable network security.
8. Operational scenarios:
1. Patient Care Scenario A:
 The emergent transfer of health information between two healthcare providers
when the status of the patient is unsure.
 Patient X presents to emergency room of General Hospital in State A. She has been
in a serious car accident. The patient is an 89 year old woman who appears very
confused. Her adult daughter informed the ER staff that her mother has recently
undergone treatment at a hospital in a neighboring state and has a prescription for an
antipsychotic drug. The emergency room physician determines there is a need to
obtain information about Patient X’s prior diagnosis and treatment during the
inpatient stay.

2. Patient Care Scenario B :

 The non-emergent transfer of records from a specialty substance treatment

provider to a primary care facility for a referral.
 A specialty substance abuse treatment facility wants to refer client X to a primary
care facility for a suspected medical problem. The client has a long history of using
various drugs and alcohol relevant for medical diagnosis. The information is being
sent to the primary care provider without the patient's authorization. The primary care
provider refers the patient to a specialist and sends all of their information (without
patient authorization) including the information received from the substance abuse
treatment facility to the specialist.
3. RHIO Scenario:

 The RHIO In your region wants to access data from all participating organizations
(and their patients) to monitor the incidence and management of diabetic patients.
The RHIO also intends to monitor participating providers to rank them for the
provision of preventive services to their diabetic patients.

186170307059 Page no: 7 Arin Modi

FSD 3340703

9. Preliminary Schedule:
 We aim to complete this project within 6 months

10. Preliminary Budget:

 Minimum Budget for this project : 1.5k$
 Maximum Budget for this project : 2k $

11. References:
 Computer Information Systems Program College of Business Florida Gulf
Coast University:
 Team Eagle : [email protected]

186170307059 Page no: 8 Arin Modi