EHealth Reception SRS V 2.2

Government of Kerala
Software Requirement Specifications

of
Reception Counter
Version: 2.2
Nov 2014
File Name: HP- JKT_eHealth_Reception_SRS_V_2.2
Effective Date: 26th Nov 2014
Total Pages: 62
Prepared
Hewlett Packard India Sales Pvt. Ltd. and

JK Technosoft Ltd.
Prepared By: Sarvesh Gupta
Reviewed By:
st
1 Level reviewer: Javed Khan and Vidya Lakshmy
2nd Level reviewer: Narayan Gopalan and Milind Gadkari
Revision History
Software Requirement Specification Document (Volume1: Reception Counter) Page 1
Author
Role
Date of Preparation
Business Analyst
19th Nov 2014
Revised By
Role
Date of Review
Name
Sarvesh Gupta
Name
Signature
Sarvesh Gupta
Signature
Reviewer(s)
Name
1st Level Reviewer :
Role
Date of Review
Signature
Javed Khan
Solution Architect
22-11-2014
Javed
Vidya Lakshmy
Project Manager
25-11-2014
Vidya
Solution Delivery Executive
26-11-2014
Narayan
Program Manager
26-11-2014
Milind
2nd Level Reviewer :

Narayan Gopalan
Milind Gadkari
Approver
Name
Role
Date of Approval
Version Number
2.2
Signature
Date of Release
10th Dec 2014
Revision History
Draft
Released
On
th
20 Nov 2014
1.0
22nd Nov 2014
Modified SRS
Changes in screens
2.0
25th Nov 2014
Modified SRS
Incorporated the review comments
2.1
09th Dec2014
Modified SRS
Added the precondition, post condition and

business rules. Incorporated queue management
logic
2.2
10th Dec 2014
Modified SRS
Add Token Print Screen
Ver. No.
Section # Changed Details Of Change

All sections
New Template
List of Participants
Sr. No.
1
Date
10-Nov-2014
Name of Participant
Sarvesh Gupta
Organization / Department
JK Technosoft
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
10-Nov-2014
11-Nov-2014
11-Nov-2014
11-Nov-2014
11-Nov-2014
11-Nov-2014
11-Nov-2014
11-Nov-2014
11-Nov-2014
12-Nov-2014
12-Nov-2014
12-Nov-2014
12-Nov-2014
Javed Khan
Sumit Yadav
Rajalekshmi
Vidya Lakhmy
Millind A. Gadkari
Dileep S
Gopa Kumar S
Suresh K S
Dr. V. Sreedhas
Salim. M
Dr.Nandini C.S
Beena R.S
Dr.Shivakumar M.
Dr.Lekshmy R.
Dr.G Sunil Kumar
Dr. S.V Arun
Dr.C Jayan
Rakesh L
Akhilraj V.J
Dr.C.K Jagadesan
Dr.Ambika A
Anoop Mohan
Rajesh P
Neelima N
S Kannan
Dr. Shano P
Dr. Prathap Kumar
Rajase Kharan Nair
Gopika G. P.
JK Technosoft
JK Technosoft
JK Technosoft
JK Technosoft
Hewlett Packard
Chief Consultant
Demographer and SDO
Technical Manager
C.S-JR AMO,DHS
OP Counter(GH)
M-MoC EHC Venpakal
DRI officer, Asst Director DHS
DHS
MO PHC Veli
Joint Director
KMSCL
Asst DHS (DH
DMO GH Trivandrum
Clerk cum DIO- NPCB
Systems Analyst RCC
Systems Manager RCC
LO
SRS Document Acceptance Certificate

The following Software Requirements Specification has been accepted and approved
by the following:
Signature
Printed Name
Title
Date
Table of Contents
2
Acronyms............................................................................................................. 7
Section 1.............................................................................................................. 8
3.1
Introduction................................................................................................... 8
3.2
Background.................................................................................................... 8
3.2.1
Module Overview..................................................................................... 8
3.2.2
Purpose of Document..............................................................................8
3.2.3
Scope & Boundary................................................................................... 9
3.2.4
Definitions, Acronyms & Abbreviations..................................................11
3.2.5
References............................................................................................. 11
3.2.6
Overview of existing System.................................................................11
Section II............................................................................................................ 12
4.1
Functional Requirements............................................................................. 12
4.2
Process (Context Diagram)..........................................................................12
4.3
Functional Flow Chart...................................................................................13
4.4
Screen (Form) wise analysis of the requirement..........................................14
4.4.1
Creation of Citizen Database.................................................................15
4.4.2
Validation of the citizen database..........................................................15
4.4.3
Merging of the validated database with the citizen database...............15
4.4.4
UHID Registration.................................................................................. 16
4.4.5
Visit Creation......................................................................................... 28
4.4.6
Print Token............................................................................................. 34
4.4.7
Update Patient Registration...................................................................36
4.4.8
Online Appointment...............................................................................44
4.4.9
Queue management..............................................................................47
4.4.10
Enquiry.................................................................................................... 49
4.5
5
Report wise Analysis.................................................................................... 56
Section III........................................................................................................... 57
5.1
Non Functional Requirements......................................................................57
5.2
Performance Requirements..........................................................................58
5.3
Safety Requirements.................................................................................... 58
Section IV........................................................................................................... 59
6.1
User Interfaces............................................................................................. 59
6.2
Standards Interface..................................................................................... 59
6.3
Hardware Interfaces..................................................................................... 60
6.4
Software Interfaces...................................................................................... 60
6.5
Communication Interfaces...........................................................................60
Annexures.......................................................................................................... 60
7.1
Annexure I.................................................................................................... 60
7.2
Annexure II................................................................................................... 60
7.3
Annexure III.................................................................................................. 60
1 Acronyms
PM
Project Manager
PL
Project Lead
RTM
Requirement Traceability Matrix
QAG
Quality Assurance Group
SRS
Software Requirement Specification
UAT
User Acceptance Test
DB
Data Base
SW- CMMI
Software- Capability Maturity Model Integration
ISO
International Organization for Standardization
2 Section 1
2.1 Introduction
This eHealth project is being implemented by the Department of Health &
Family Welfare(DHFW), Government of Kerala with the help of DeitY,
Government of India to capture the patients demographic data automate
hospital processes and bring all information into a centralized State Health
Information system through the network to ensure continuity in health care.
2.2 Background
The existing systems in the Department of Health and Family Welfare are
described in this section. These systems, mostly managed through manual
processes are not expected to be replicated exactly in the eHealth Project. A
great deal of Process Re-engineering will have to be done in order to create
an efficient and dynamic system driven by efficient management processes
and supported by state of the art technology.
The study is for fully understanding the requirement and suggesting the
Process Re-engineering required to be implemented to make the system
modern and vibrant.
The eHealth System created shall have the facility to carry out all the
functionalities described in the RFP document and subsequently validate the
feasibility of incorporating them later during the System Requirement Phase.
2.2.1 Module Overview
eHealth needs to maintain the Patients medical records, Patients history,

Admission records etc. efficiently at their hospital. At any given time the
Reception Module should be able to get the correct information from each of
their location.
2.2.2 Purpose of Document
The purpose of this document is to capture user requirements of reception

counter module in the form of SRS document to construct and customize the
eHealth solution to be implemented in the state of Kerala.
2.2.3 Scope & Boundary
System should be able to authenticate a patient from citizen database

based on any one of the following (the citizen has to show the same
document as the proof also)
o Aadhaar Number
o driving license,
o PAN,
o voters ID,
o ration card,
o mobile no
System should be able to validate and pull in the demographic details

of the patient with the help of Aadhaar card and do the registration
process
System should be able to generate UHID cards based on identity card

provided by the patient
System should be able to capture photo incase patient comes without

an Aadhaar card
System should be able to generate UHID cards and register a patients

in case he/she comes with no identification card. In such cases a
temporary UHID will be generated by the system
The system will be able to create the visit for the patient based on the
following
o Based on specialty that the patient needs to visit
o Patients preference to a doctor, whom he wants to visit
o Past visited doctor by the patient
o Doctors with the shortest queue

o Visit based on units
o Visits for patients referred from other hospitals
System should be able to search the patient details based on the

search criteria set on the screen
System should be able to merge the patient records if he/she registers

with multiple identity card. In such cases the system should have a
utility to merge all the records
System should have a provision to track the following category of

patients separately:
o A normal resident of Kerala
o Non Resident Keralites
o Citizens from other states who have migrated to Kerala
o Travelers and Tourists
The system should allow generating of statistical and analytical

reports.
System should also have provision to export and import required data.
Queue management at various places
Give appointment to patient for further visit
Software Requirement Specification Document (Volume1: Reception Counter)

10
Page
2.2.4 Definitions, Acronyms & Abbreviations
1
2
3
4
CD
CHC
CSC
DeitY
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
DHFW
EHR
RFP
HMIS
IDSP
KMSCL
KSWAN
LEP
LSGD
MCTS
MSDG
NCD
NOFN
PHC
RFP
SCTIMST
21
22
23
24
25
SDC
SRDH
TB
TBC
W&C
Communicable Disease
Community Health Centre
Common Service Centre
Department of Electronics & Information Technology,
Govt. of India.
Department of Health & Family Welfare
Electronic Health Record
Bid
Health Management Information System
Integrated Disease Surveillance Program
Kerala Medical Supplies Corporation Limited
Kerala State Wide Area Network
Leprosy Specialty Hospital
Local Self Government Department
Mother and Child Tracking System
Mobile Service Delivery Gateway
Non Communicable Disease
National Optical Fiber Network
Primary Health Centre
Request for Proposal
Sree Chitra Tirunal Institute for Medical Sciences and
Technology
State Data Centre
State Resident Data Hub
Tuberculosis Specialty Hospital
Tuberculosis Clinics
Women & Child specialty Hospital
2.2.5 References
Annexure 3 Functional Requirements

2.2.6 Overview of existing System
The existing system in the Department of Health and Family Welfare is

described in this section. The existing systems, mostly managed
through manual processes are not expected to be replicated exactly as
it is in the eHealth Project. A great deal of Process Re-engineering will
have to be done in order to create an efficient and dynamic system
driven by efficient management processes and supported by state of
the art technology.

11
Page
The study is for fully understanding the requirement and suggesting

the Process Re-engineering required to be implemented to make the
system modern and vibrant.
The eHealth System created shall have facility to carry out all the
functionalities described in the RFP document and subsequently
validated during the System Requirement Phase.
3 Section II
3.1 Functional Requirements
This section describes functionality to be covered in the Reception
Module. This also gives the details of the input required, source of
input, list of outputs reports and source of output reports
3.2 Process (Context Diagram)

Inputs
Authenticate by
eCitizen database
Patient Registration
details
Visit Creation
Update Registration
Online Appointment
Enquiry
Outputs
P
R
O
C
E
S
S
UHID
Token Number
Confirmation /Issue of
appointment /future
token number
OP Statistics
Appointments

12
Page
3.3 Functional Flow Chart

13
Page
3.4 Screen (Form) wise analysis of the requirement

1. Patient Registration
2. Visit Creation
3. Update Patient Registration
4. Online Appointment
5. Enquiry

14
Page
3.4.1 Creation of Citizen Database
The process for this has been covered in the public health SRS
3.4.2 Validation of the citizen database
3.4.3 Merging of the validated database with the citizen database

15
Page
3.4.4 UHID Registration
Screen Id
: REC - 001
Screen Name
: UHID Registration
Screen Description
: Registration for UHID.
This screen captures the demographic details of the citizen and registers
the citizen to allot the UHID. This screen will be accessible to the
Reception counter staff in the Hospital.
UHID registration will be primarily be done based on Aadhaar card which
will serve as the unique health identification number for the citizens.
The name of the citizen will be captured in the form of Citizen Name
according to the Aadhaar QR Code format.
Age is a vital information of the citizen, Aadhaar has year of birth. 1st
January of the year of birth may be stored in a 'Notional DOB' field.
However if actual DOB is available it will be captured and stored in a
'DOB' field
In the absence of Aadhaar card another temporary UHID can be
generated. Algorithm to create this temporary UHID is Hospital Id
number (5 digit number) + DDMMYY +4 digit serial number.
Age is a vital information of the citizen. If actual DOB is available it may
be captured and stored in a 'DOB' field else, The approximate age of the
patient will be entered. The system then calculates the date of birth by
deducting the year from the current date and store the date in 'Notional
DOB' field. The actual DOB field will be left blank so that it can be
populated when it becomes available. In future the age shall be calculated
based on 'Notional DOB' until actual DOB is populated. Database will
store the Age.

16
Page
Actor
Reception counter user
Description
This screen will used to register a patient into the e-health

system. This is the former most activity to get the
healthcare facility from the hospitals
Pre-Condition
1- Active Internet / Intranet Connectivity for Lean

Server / Central Server.
2- Reception counter User will login with his/her
credentials (username and password).
3- Reception counter User should have rights to create
this information.
4- A citizen should have come for registration
Post Condition
UHID of the citizen is generated
Normal Course
Patient comes for getting enrolled in eHealth database
Alternative
No action
Exceptions
Priority
Frequency
Daily
Business Rules
As mentioned below
Assumptions
Internet / Intranet connectivity with lean server / central

server with sufficient bandwidth is available.
Notes

17
Page
Business Rules for Registration of a patient

Process of UHID Registration:
Registration using Aadhaar Card:
Option 1 Read from the QR code and get values for the following
If the citizen is carrying his Aadhaar card then the QR code will be
scanned to get the relevant information from the Aadhaar card. After
getting the details from the Aadhaar card the system will search the
central DB for its pre-existence and if the card details already exists then
the System will display pop-up message Card is already registered. And
if not found the, the following information will be taken from the QR code
and populated in the registration form:
Aadhaar Number
Name
Address
Age the exact Date Of Birth (DOB) can be confirmed by the citizen
for accuracy
If not already registered proceed with the registration process.
Option 2:- Use eKYC for authentication and pre-populate the fields.
Take the biometric impression of the patient and enter the Aadhaar number and
get the eKYC authentication from Aadhaar this process will validate the citizen,
check the availability from our e-health database and if not found the
registration process can proceed with the following information System will
display pop-up message Card is already registered
Name
Gender
Year of Birth
Name of Parent
E-mail address
Phone number
Address:
o House
o Street

18
Page
o
o
o
o
o
o
Village/Town/City
Post Office
PIN
District (Use NIC Master table data)
Sub District (Use NIC Master table data)
State (Use NIC Master table data)
Permanent Address: Same as Aadhaar Check box

o House
o Street
o Village/Town/City
o Post Office
o PIN
o District (Use NIC Master table data)
o Sub District (Use NIC Master table data)
o State (Use NIC Master table data)
o Landline number with STD Code (Separate field for STD Code)
Present Address
Check boxes: Same as Aadhaar; Same as Permanent Address (If both are
same only one check box)
o House
o Street
o Village/Town/City
o Post Office
o PIN
The system will allow the addition of the following information during the
registration process
1. LSG Name (Panchayath, Municipality, Corporation) (From NIC Master
data)
2. Ward Name / Number (From NIC Master data)
3. House Number (Format ,,,,,/,,,,,,/.... (....) (To be discussed with IKM)

19
Page
Option 3 Registration without Aadhaar card:

Citizen may bring any of the following IDs for Temporary UHID.
Voters ID
Driving License
PAN Card.
None (UHID can also be generated without any standard IDs in case of
emergency using this interface,)
Select the other ID type, ID number the system will validate the same with
the e-health database and if found System will display pop-up message
Card is already registered else it will proceed with the registration process.
Enter the following details.
Note: Some details may be available through a web service from the
respective servers. Provided the custodian of the data is ready to share the
same for the e-health project. This will depend on the subsequent agreement
between the MOHFW and the custodian of the data.
Name
Gender
Year of Birth
Name of Father / Mother
Permanent Address: (Enter data)
o House
o Street
o Village/Town/City
o Post Office
o PIN

20
Page
Present Address
Check box: Same as Permanent Address
o
o
o
o
o
o
o
o
o
House
Street
Village/Town/City
Post Office
PIN
District (Use NIC Master table data)
Sub District (Use NIC Master table data)
State (Use NIC Master table data)
Landline number with STD Code (Separate field for STD Code)
The will also capture the following information:

LSG Name (Panchayat, Municipality, Corporation) (From NIC Master
data)
Ward Name / Number (From NIC Master data)
House Number (Format ,,,,,/,,,,,,/.... (....) (To be discussed with IKM)
The screen and its field mapping is mentioned below.

21
Page
Pl add the ration card number, if electricity poll number is needed then the same can be added
Occupation (LoV - Standard GoI List) this needs to be added

Category (Check boxes) probably needs change of name in the screen
APL / BPL (pre-populated from Ration Card data if available)
Others (Get Complete List)

22
Page
Screen Field Map:

Screen Field
Label
Object
Type
Data Type
Format
Values
UID
Text Box
Integer
X(16)
It will be enterable field. If

Aadhaar card is read using a
QR code reader then the UID
shall be auto populated with
the Aadhaar ID
Search
Button
UID
Text Box
Integer
X(16)

the Aadhaar ID.
Other ID
Combo
Box
Charact
er
X(30)
It will be selectable field.
ID No.
Text box
Charact
er
X(32)
It is an enterable field.
Full Name
Text Box
Charact
er
X(100)
It will be enterable field.
On click this button, search

the entered the UID from the
database.
It cannot have null value.
DOB
Text Box
Date
DD/M
M/YYY
Y
It will be enterable field in the

format of DD/MM/YYYY.
Age
Text Box
Integer
X(3)
This is an enterable field.

The system calculates the
approximate age if date of
birth has been entered.
If DOB is not available, then
the approximate age of the

23
Page
patient will be entered.

In future the age shall be
calculated based on 'DOB'.
Database need not store the
Age.
Gender
Combo
Box
Charact
er
X(15)
Year of Birth
Text Box
Integer
X(4)
It will be display field from

DOB.
Occupation
Combo
Box
Text Box
Charact
er
Charact
er
X(32)
X(32)
Yes/No
Father /
Mothers
Name

Permanent Address
Same as
Aadhaar
Check box
Check
Box
Logical
House
No./Bldg/Apt
Street/Road/L
ane
Text Box
Charact
er
Charact
er
X(32)
X(32)
Landmark
Text Box
Charact
er
X(32)
Area/Locality/
Sector
Text Box
Charact
er
X(32)
Village/Town/
Text Box
Charact
X(32)
Text Box
If user checked the check box

then fetch the Address from
Aadhaar database and will be
display in the Permanent
Address section.

24
Page
City
er
Post Office
Text Box
Charact
er
X(32)
State
Combo
Box
Charact
er
X(32)
District
Combo
Box
Charact
er
X(32)
Combo
Box
Charact
er
X (32)
Pin code
Text Box
Integer
X(6)
It will be enter the 6 digits

value.
LSG Name
Text Box
Charact
er
X(100)
Ward Name
Text Box
Charact
er
X(32)
Ward No.
Text Box
Charact
er
X(16)
Land Line No.
Text Box
Integer
X(12)
It will be enterable field in

format STD Phone No..
Sub District
It will be display based on

State.
District.
For ex 0120 4606200

Electricity
Poll No.
Text Box
Charact
er
X(16)
Logical
Yes/No
Present Address
Same as
Aadhaar
Check Box
Check
Box
If user checked the check

box then fetch the Address

25
Page
from Aadhaar database and

will be display in the
Permanent Address section.
Same as
Permanent
Check
Box
Logical
House
No./Bldg/Apt
Text Box
Charact
er
X(32)
Street/Road/L
ane
Text Box
Charact
er
X(32)
Landmark
Text Box
Charact
er
X(32)
Area/Locality/
Sector
Text Box
Charact
er
X(32)
Village/Town/
City
Text Box
Charact
er
X(32)
Post Office
Text Box
Charact
er
X(32)
State
Combo
Box
Charact
er
X(32)
District
Combo
Box
Charact
er
X(32)
Combo
Box
Charact
er
X (32)
Pin code
Text Box
Integer
X(6)
It will be enter the 6 digits

value.
LSG Name
Text Box
Charact
er
X(100)
Sub District
Yes/No

If user checked the check
box then Present Address will
be display same as
Permanent Address.

State.
District.

26
Page
Ward Name
Text Box
Charact
er
X(32)
Ward No.
Text Box
Charact
er
X(16)
Land Line No.
Text Box
Integer
X(12)
It will be enterable field in

format STD Phone No..
For ex 0120 4606200
Electricity
Poll No.
Text Box
Charact
er
X(16)
Primary
Mobile No.
Text Box
Integer
X(12)
It will be enter the 12 digit

value.
For ex 09812345678
Secondary
Mobile No.
Text Box
Integer
X(12)
It will be enter the 12 digit

value.
For ex 09812345678
Patient
Category
ComboBox
Submit
Button
Charact
er
X(32)

On click this button, citizens
record will be save in the
database.
On submitting with Aadhaar
number system will save it
as an UID number otherwise
system will generate an UHID
Number.
Reset
Button
On click this button, clear the

existing data in all fields.
Print
Registration
Card
Button
On click of this button,

system will have the facility
to print the Registration Card
with Barcode.

27
Page
3.4.5 Visit Creation
Screen Id
Screen Name
Screen Description
: REC - 002
: Visit Creation
: Visits of OP patients
Actor
Description
This screen is used to capture the purpose of the patients

visit to the hospital.
Pre-Condition
Active Internet / Intranet Connectivity for Lean

Reception counter User will login with his/her

Reception counter User should have rights to create

this information.

28
Page
Post Condition
UHID has to be generated
Token slip is generated
Bill is generated
Visit for doctor/department/lab/pharmacy is created.
Normal Course
Patient comes for getting a treatment or getting some

investigation done or coming to the OP nursing station for
follow-up injections/bandage/procedures or coming to
pharmacy for collecting the balance prescription drugs
Alternative
No action
Exceptions
Token numbers can get jumped at OPD based on the

appointment policy of the hospital.
In case of emergency patients, the doctor have the facility
to alter the order of visit
Priority
Frequency
Daily
Business Rules
As mentioned below
Assumptions

server with sufficient bandwidth is available. Patient is
registered successfully in the system
Notes
Process of Visit Creation:

The UHID is the input for creating the Visit.
If UHID is not provided by the patient then the user can search the UHID
using the following data:
Name
LSG Name
Ward
House Number
DOB
Age (Range)
29
Page
Mobile Number
Land line Number
All the matches will be displayed. One name/UHID can be selected for
creating visit
If UHID is known to the patient then the User may key in this and get the
demographic data.
The screen will be pre-populated with the demographic data pertaining to
the UHID.
a) Visit Number: A serial number, called visit number is an Auto
Generated Number and it keeps track of the visits of the patient in that
hospital. Visit No. 1 identifies that the patient is new to the hospital.
Visit number greater than 1 denotes that this is a repeat visit.
b) The age of the patient will be calculated at every visit from the
information given at the time of first registration.
c) The date and time of the visit of the patient will be automatically filled
in with current system date and time.
User need to provide the following data:

1.
2.
3.
4.
5.
6.
Complaint type (LoV - Master Data to be provided)

OP Session (Morning OP / Evening OP)
Department (Display List of Departments which are on session)
Unit (Display List of Units of Departments which are on session)
Doctor (Display List of Units of Departments which are on session)
Doctors in Charge:
Here display the Names of Doctors who are authorized to give
appointments by name. If the Hospital has opted for Consultation by
Unit Name then this will be disabled.
7. Duty Doctors: Display the list of all Doctors who are on Duty in that
Unit for the OP Session. This is just for information and not for
selection.

30
Page
Please the id type also weather it is DL, voter card etc.

31
Page
Screen Field Map:
Screen
Object
/Field Label Type
Person Index Text Box
Data
Type
Integer
Format
Values
X(16)
It will be optional enterable field.
Full Name
Text Box
X(100)
LSG Name
Text Box
X(32)
Ward
Text Box
X(32)
House no.
Text Box
X(32)
DOB
Text Box
Characte
r
Characte
r
Characte
r
Characte
r
Date
Combo
Box
Line Text Box
Characte
r
Integer
DD/MM/Y
YYY
X(16)
X(16)
It will be optional enterable field

in format STD Phone No..
Age
Land
No.
Mobile No.
Text Box
Search
Button
Integer
X(16)
It will be optional selectable field.
For ex 0120 4606200

On click this button, it will search
the records based on the entered
criteria and will
display the
searched record in the below grid.
Patient Details
Person Index
Text Box
Patient
Name
Gender
Text Box
Age
Text Box
Other ID
Text Box
Occupation
Text Box
Mobile No.
Text Box
Text Box
ReadOnly
ReadOnly
ReadOnly
ReadOnly
ReadOnly
ReadOnly
ReadOnly
It will be display the UID.

It will be display the Patient
Name.
It will be display the Gender.
It will be display the Age.
It will be display the Other ID.
It will be display the Occupation.
It will be display the Mobile No.

32
Page
Address
Text Box
Patient
Text Box
Category
Visit Details
ReadOnly
ReadOnly
It will be display the Address.

It will be display the Patient
Category.
Visit No.
Text Box
ReadOnly
It will be display the autogenerated number.
Visit Date
Text Box
ReadOnly
It will be display the current date.
Visit Time
Text Box
ReadOnly
I will be display the current time.
Complaint
Type
Combo
Box
Characte
r
X(32)
OP Session
Combo
Box
Characte
r
X(16)
Department
Combo
Box
Characte
r
X(32)
Unit
Combo
Box
Characte
r
X(32)
Unit Doctor
Combo
Box
Characte
r
X(32)
List of Duty
Doctors
List Box
It will be display the list.
Bill Details
Charge
Combo
Box
Bill No.
Amount
Characte
r
X(32)
Text Box
ReadOnly
It will be display the field.
Text Box
ReadOnly
It will be display the value based

on Charge field.

33
Page
Actual
Collected
Amount
Text Box
Decimal
999.99
Discount
Text Box
Decimal
999.99%
Balance
Text Box
Decimal
999.99%
It will be display the field based

on calculation (Amount, Actual
Collected Amount and Discount
fields).
Submit
Button
On click of this button, It will be

able to create the patient visit.
Reset
Button
Print Token
Button
On click of this button, clear the

On click of this button, The Token
Number will be generated serially.
Printed data following:-Token Number (Numerals and
Bar code)
-Name of Patient
-Age
-Consultation Room No,
Department Name and Unit
Number

34
Page
3.4.6 Print Token

Screen
Id
Screen Name
Screen Description
: REC - 003
: Print Token
: Token will generated for OPD patients
Actor
Description
This screen is used to print token for the doctors visit to the
hospital.
Pre-Condition

3- Reception counter User should have rights to create
this information.
4- Visit has to be created
Post Condition
Token number is printed
Normal Course
Immediately after saving the visit details, the token slip is

printed
Alternative
No action
Exceptions
If printer is not working, token will be issued manually
Priority
Frequency
Daily
Business Rules
As mentioned below
Assumptions

server with sufficient bandwidth is available. Visit is created
successfully in the system
Notes

35
Page

36
Page
3.4.7 Update Patient Registration

Screen
Id
Screen Name
Screen Description
: REC - 004
: Update Patient Registration
: Update Registration for OPD patients.
Actor
Description
This screen is used to update the patients registration

details.
Pre-Condition

3- Reception counter User should have rights to update
this information.
4- Patient should have been registered by a UHID
5- Proper authorization from court of law or
authorization by Higher authorities of the hospital
Post Condition
Visit for doctor/department/lab/pharmacy is created
Normal Course
Patient comes for getting a treatment or getting some

investigation done or coming to the OP nursing station for
follow-up injections/bandage/procedures or coming to
pharmacy for collecting the balance prescription drugs.
Patient needs to update his details either because he has
registered first time with any other valid identification
number, apart from the Aadhaar card
Alternative
No action
Exceptions
Token numbers can get jumped at OPD based on the

appointment policy of the hospital.
In case of emergency patients, the doctor have the facility
to alter the order of visit
Priority
Frequency
Daily

37
Page
Business Rules
As mentioned below
Assumptions

registered successfully in the system
Notes

38
Page

39
Page
Screen Field Map:

Screen Field
Label
Object
Type
Data Type
Format
Values
UID
Text Box
Integer
X(16)

the Aadhaar ID
Search
Button
UID
Text Box
On click this button, search the

entered the UID from the
database.
Integer
X(16)
It will be display the UID.

If Aadhaar card is read using a
the Aadhaar ID.
Other ID
ID No.
Full Name
Combo
Box
Charact
er
X(30)
Text box
Charact
er
X(32)
Charact
er
X(100)
Text Box

It will be modifiable field.
It will be display the ID No.
DOB
Age
Text Box
Text Box
Date
Integer
DD/M
M/YYY
Y
It will be display the DOB.
X(3)
It will be display the Age.

The system calculates the
40
Page
approximate age if date of birth

has been entered.
If DOB is not available, then the
approximate age of the patient
will be entered.
In future the age shall be
calculated based on 'DOB'.
Database need not store the
Age.
Gender
Combo
Box
Charact
er
X(15)
It will be display the Gender.

Year of Birth
Text Box
Integer
X(4)
It will be display field based on

DOB.
Occupation
Combo
Box
Charact
er
X(32)
It will be display the

Occupation.
Father /
Mothers
Name
Text Box
Charact
er
X(32)

It will be display the Father /
Mothers Name.
Permanent Address
Same as
Aadhaar
Check box
Check
Box
Logical
Yes/No
House
No./Bldg/Apt
Text Box
Charact
er
X(32)
Street/Road/L
ane
Text Box
Charact
er
X(32)


41
Page
Landmark
Text Box
Charact
er
X(32)
Charact
er
X(32)
Charact
er
X(32)
Charact
er
X(32)

Combo
Box
Charact
er
X(32)
Combo
Box
Charact
er
X(32)
Combo
Box
Charact
er
X (32)
Text Box
Integer
X(6)
Area/Locality/
Sector
Text Box
Village/Town/
City
Text Box
Post Office
Text Box
State
District
Sub District
Pin code


LSG Name
Ward Name
Ward No.
Land Line No.
Text Box
Text Box
Text Box
Text Box
Charact
er
X(100)
Charact
er
X(32)
Charact
er
X(16)
Integer
X(12)

Electricity
Text Box
Charact
X(16)

42
Page
Poll No.
er
Present Address
Same as
Aadhaar
Check Box
Check
Box
Logical
Yes/No
Same as
Permanent
Check
Box
Logical
House
No./Bldg/Apt
Text Box
Charact
er
X(32)
Street/Road/L
ane
Text Box
Charact
er
X(32)
Landmark
Text Box
Charact
er
X(32)
Charact
er
X(32)

Yes/No

Area/Locality/
Sector
Text Box
Village/Town/
City
Text Box
Charact
er
X(32)
Post Office
Text Box
Charact
er
X(32)

Combo
Box
Charact
er
X(32)
Combo
Box
Charact
er
X(32)
Combo
Box
Charact
er
X (32)
Text Box
Integer
X(6)
State
District
Sub District
Pin code



43
Page

LSG Name
Ward Name
Ward No.
Land Line No.
Text Box
Text Box
Text Box
Text Box
Charact
er
X(100)
Charact
er
X(32)
Charact
er
X(16)
Integer
X(12)

Electricity
Poll No.
Text Box
Charact
er
X(16)
Primary
Mobile No.
Text Box
Integer
X(12)
Secondary
Mobile No.
Text Box
Patient
Category
ComboBox
Update
Button
On click this button, patients

record will be update in the
database and display the
generated UID number.
Reset
Button
On click this button, clear the


Integer
X(12)

Charact
er
X(32)


44
Page
3.4.8 Online Appointment
Screen Id
Screen Name
Screen Description
: REC - 005
: Online Appointment
: Online Appointment for OP Patient
Actor
Patient logs into the system online
Description
This screen is used to capture the appointment information.

Patient is able to book an appointment online
Pre-Condition

2- Patient should have been registered by a UHID
3- Patient should be given a proper username and
password for logging into the system online
Post Condition
Online appointment for a doctor based on the

unit/department/specialty is created
Normal Course
Patient logs into the system and finds out the available
doctors for a particular day. System will provide him an
information of how many tokens are distributed so far for
that doctor and the possible time he needs to be present in
the hospital when a particular token is selected. He
chooses a token based on his convenience and submits.
Alternative
If the appointment in not available for a particular day, the

patient needs to choose an alternative date or visit the
hospital as a walk-in patient
Exceptions
Priority
Frequency
Daily
Business Rules
The token is generated based on the configurable

parameters identified for each hospital and based on the
queue management followed in the hospital
Assumptions

registered successfully in the system and is allocated
necessary access with user credentials for logging the

45
Page
system online
Notes
Note:
The online appointment can be configured based on the below 3 parameters

Interval parameter -Interval between each token.
Stop parameter -Max limit when the online token has to be stopped,
Consecutive parameter interval parameter + < configurable no depending
on the hospital>

46
Page
Screen Field Map:
Screen
Field
Label
Object Data
Type
Type
Forma Values
t
UID
Text
Box
X(16)
Appointme Text
nt Date
Box
Integer

Date
DD/M
M/YYY
Y
It will be display the by default

current date.
It will be modifiable field in the
Session
Combo
Box
Characte
r
X(5)
Departme
nt
Combo
Box
Characte
r
X(32)
Unit
Combo
Box
Characte
r
X(32)
Unit
Doctor
Combo
Box
Characte
r
X(32)
List of
Duty
Doctors
List
Box
Characte
r
X(32)
It will be display the doctors list.
Mobile No.
Text
Box
Integer
X(12)
Text
Box
Characte
r
Token No.
At the time of online appointment

if mobile no. entered here is
different from the one which is
given in registration then system
should ask the person for and alert
that it you want to update this
mobile no. with existing mobile no.
in registration.
X(32)
On click token no., that token no.

book for the patient.

47
Page
And save the appointment.

48
Page
3.4.9 Queue management

3.4.9.1 The normal flow:
In case of patient who doesnt have a preferred doctor, system works with 3
possibilities, First preference will be given to the doctor who has attended his
encounter maximum no of times. If that particular doctor has the longest
queue then he is moved to the available doctor who has the shortest queue.
But if the patient is coming for the first time and have no past history he will
be allocated to the doctor with the shortest queue.
3.4.9.2 If the patient is not available in the token display
First time If any patient is not available at the time of token display, the
token number will move down 3 position (will be called after three token
numbers from queue).
Second time If any patient is not available at the time of token display, the
token number will move down 5 position (will be called after five token
Third time If any patient is not available at the time of token display, the
token number will move down 10 position (will be called after 10 token
After three times the doctor can remove the token from the list - Need
confirmation on this point by e-health
3.4.9.3 Parked patients
When a patient is being called and doctor decides to see him some time later
( after doing some investigations), that patient data will be saved and his
info will come in the list of parked patients .In the token display the parked
patient will be highlighted in a different colour.
3.4.9.4 In Laboratories and In pharmacy
In case patient need to come to lab multiple number of times as in case of

Fasting and PP BSL the system will understand how many times patient will
come for giving samples. Accordingly the system will keep the token number
in pending list even after first sample collection. System will have facility to
capture blood collection time after patient arrives in phlebotomy. Patient will
be called based on the time captured.
The token number will be displayed based on the time stamp. Hence patient
whose visit is generated first, will be on top of the list, based on which
patient will be called for sample collection.
49
Page
In case patient is not available for sample collection, his token will be shifted
down based on the logic defined for queue management for out patients
The queue management logic applies when the patient wants to come back
and re-verify the medicines given to him in pharmacy.
3.4.9.5 For patients falling in a specific category
System should be given preference in the Queue system to set the priority
-Geadrics and deferentially abled persons. These patients will be given high priority
above all the category
3.4.9.6 Patients who visit doctors related to a specific department for follow-ups
or revisits
All patients coming for follow-ups (revisits) do not need to go to OPD ticket counter,
he/she comes directly to specialty clinic. Hence queue management need to take
care of prioritizing follow-ups as against new patients.

50
Page
3.4.10 Enquiry
Screen Id
Screen Name
Screen Description
: REC - 006
: Enquiry
: Enquiry
Actor
Patient/Reception counter User
Description
This screen facilitates the following services like

details/availability/consultation time of a doctor based on
the specialty/department given, list of pay wards available,
contact details of a particular hospital/doctor, list of higher
level referral hospital for a selected hospital
Pre-Condition

2- Reception counter User should have access to
eHealth system
3- A citizen should have come for an enquiry
Post Condition
Details of the doctor, Name of the hospital, Time of

appointment is generated based on the search criteria.
System also provides the details of the paywards available
in a particular hospital, services available in different
hospitals and list of higher level referral hospitals for a
selected hospital
Normal Course
Patient obtains information about a particular

doctor/hospital
Alternative
No action
Exceptions
Priority
Frequency
Daily
Business Rules
Assumptions

server with sufficient bandwidth is available.
Notes
51
Page
Doctor availability - Add Department for selection

52
Page
Screen Field Map:
Screen
Field
Label
Object Data
Type
Type
Form
at
Doctor
Image
Availability Link
and Duty
Time
Values
On click this image, open the

Enquiry screen.
District
Name
Text
Box
Character
X(32)
Hospital
Name
Text
Box
Character
X(32)
Date
Text
Box
Date
DD/M
M/YYY
Y
It will be display the by default

current date.
X(32)
Character
It will be modifiable field in the

Doctor
Name
Text
Box
Search
Button
On click this button, it will be

display the searched record in the
below grid.
Telephone
Directory
Image
Link
On click this image, it will be open

the directory where user will
search the list of number of
hospitals, Doctors and other
required information.
Available
Pay Ward
Image
Link

the pop up where user can see the
status of pay ward booking by
searching through Hospital.
Various
Services
Image
Link

services available in the various

53
Page
hospital. User can search on the

basis of Hospital, Date and
Services.
Higher
Level
Referral
Hospital
Image
Link

the pop up where user can see
information on all services
available in the higher level
referral Hospitals nearby.
Note: If the telephone no is given as a search criteria, then the doctor name,
hospital and district will be provided in the resultant data

54
Page
Screen Field Map:
Screen
Field
Label
Object Data
Type
Type
Form
at
Values
Telephone
Directory
Image
Link
District
Name
Text
Box
Characte
r
X(32)
Hospital
Name
Text
Box
Characte
r
X(32)
Doctor
Name
Text
Box
Characte
r
X(32)
Telephone
No.
Text
Box
Integer
X(12)
Search
Button

the directory where user will search
the list of number of hospitals,
Doctors and other required
information.

display the searched record.
Note: the result will be the availability of payward in a particular hospital in a

district

55
Page
Screen Field Map:
Screen
Field
Label
Object Data
Type
Type
Form
at
Values
Available
Pay Ward
Image
Link
District
Name
Text
Box
Character
X(32)
Hospital
Name
Text
Box
Character
X(32)
Pay Ward
Combo
Box
Character
X(32)
Search
Button

status of pay ward booking by
searching through Hospital.

Note: result will the services available with timing on a particular day for a
hospital in a district

56
Page
Screen Field Map:
Screen
Field
Label
Object Data
Type
Type
Various
Services
Image
Link
District
Name
Text
Box
Character
X(32)
Hospital
Name
Text
Box
Character
X(32)
Services
Text
Box
Character
X(32)
Date
Text
Box
Date
DD/M
M/YYY
Y
It will be display by default current

date.
Search
Button
Form
at
Values

services available in the various
hospital. User can search on the
basis of Hospital, Date and
Services.
It will be modifiable also.

Note: Click on this will open the pop up where by district and hospital name search
user can see the list of all higher level referral hospitals for that hospital.

57
Page
Screen Field Map:
Screen
Field
Label
Object Data
Type
Type
Form
at
Values
Higher
Level
Referral
Hospital
Image
Link
District
Name
Text
Box
Character
X(32)
Hospital
Name
Text
Box
Character
X(32)
Search
Button

the pop up where user can see
information on all services
available in the higher level
referral Hospitals nearby.

3.5 Report wise Analysis

<Report formats will be attach after getting from eHealth PMU>

58
Page
4 Section III
4.1 Non Functional Requirements
System should be able to adhere to the SLA defined for each of individual
module
Functional Module
Total Permitted Down

Time in a quarter In
Hours
Permitted Down Time at

single instance of
failure
Centralized
Hospital
Management System
30 minutes
Offline
Hospital
Management
Module
at MCH and Large
Institutions
30 minutes
PH Module
10
IAM Module
1 Hour
30 minutes
Offline
Hospital
Management
Module
at Small Institutions
24
1 Hour
Centralized PH Module
24
1 Hour

59
Page
4.2 Performance Requirements

The e-health solution will meet the following performance standards. The
response time shall be measured based on the response from the servers
locally and shall not take into account the network latency. These queries are
common queries that will be used in most outpatient and in-patient
scenarios.
Query
Definition
Response time
Simple
Simple query is defined as query of a single 3 Seconds

document or a level 1 clinical information
( Single result, single medication) without any
associated level 2 ( Associated hospital, lab
where
test
is
performed,
prescriber)
information
Medium
Medium
complex
query
is
multiple 5 Seconds
documents of a single patient over last 6
months of outpatient encounters or single inpatient episode
Complex
Single episode all details with multiple levels 8 Seconds

or Multiple encounters with level 2
information
When violation of Service Levels with respect to Web page Response Time is
reported, it needs to be rectified within 48 hours
4.3 Safety Requirements

Information transmission should be securely transmitted to server without
any changes in information.

60
Page
5 Section IV
External Interface Requirements
Biometric devise
Aadhaar
Token display system
Barcode Printer
5.1 User Interfaces

The system shall be designed in such a way to make the task easy. The user
interfaces shall be designed in close interaction with the users and shall be
efficient, User-friendly, simple and easy to learn. The individual screens shall
not be crowded.
The screen designs shall be department/specialty specific. The menus,
contents, list boxes, labels etc shall be based on the Specialty. As far as
possible provide lists for the user to choose from. Some of the data items
which can be provided as lists are given below.
Patient signs, complaints and symptoms

observations, diagnosis with status
outcome of treatment
drugs, quantity and dosage
laboratory investigations
Radiological investigations
The lists may be based on standards such as SNOWMED-CT, Drug Codes etc.
5.2 Standards Interface

Specify only the relevant standards
Sl
Stand
Description
Used For

61
Page
No.
ard
MDDS
HL7
v2.x
Meta Data and Data Standards

For exchange of data as
per MDDS
5.3 Hardware Interfaces

1.
2.
3.
4.
5.
6.
7.
Biometric Reader
Bar Code Reader & Writer
Web Camera
Scanner
Printer
Server
Client
5.4 Software Interfaces

1. Apache Tomcat 8.0
2. Java SDK 7
3. MySQL 5.6
4. I.E 8.0
5. Mozilla Firefox 5.0 and Above
6. iReport 2.0.2
7. Framework is Spring Version 3.0
8. Hibernate Version 3.0
9. Eclipse Release 1
10.
Birt 4.3
5.5 Communication Interfaces

TCP/IP
6 Annexures
6.1 Annexure I
Test Cases for User Acceptance Testing
Test
Case
Id
Bug
Type
Use
Case /
Req
Reference
Priority
Test Case
Name
Test
Steps
Expected
Result
Actual
Result
Passed
/ Failed
Passed
/ Failed
Test
Prepare
d By
Test
Reviewed
By

62
Page
Test
Execute
d By
6.2 Annexure II
List of Specimen documents collected during SRS Study
6.3 Annexure III

Minutes of Meetings during SRS Document phase.

63
Page

EHealth Reception SRS V 2.2

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

EHealth Reception SRS V 2.2

Hochgeladen von

Copyright:

Verfügbare Formate

Government of Kerala

Software Requirement Specifications

Hewlett Packard India Sales Pvt. Ltd. and

Solution Delivery Executive

2nd Level Reviewer :

22nd Nov 2014

25th Nov 2014

Incorporated the review comments

Added the precondition, post condition and

10th Dec 2014

Add Token Print Screen

Section # Changed Details Of Change

Software Requirement Specification Document (Volume1: Reception Counter) Page 2

Software Requirement Specification Document (Volume1: Reception Counter) Page 3

SRS Document Acceptance Certificate

Software Requirement Specification Document (Volume1: Reception Counter) Page 4

Scope & Boundary................................................................................... 9

Definitions, Acronyms & Abbreviations..................................................11

Overview of existing System.................................................................11

Process (Context Diagram)..........................................................................12

Functional Flow Chart...................................................................................13

Screen (Form) wise analysis of the requirement..........................................14

Creation of Citizen Database.................................................................15

Validation of the citizen database..........................................................15

Merging of the validated database with the citizen database...............15

Update Patient Registration...................................................................36

Report wise Analysis.................................................................................... 56

Non Functional Requirements......................................................................57

Software Requirement Specification Document (Volume1: Reception Counter) Page 5

Software Requirement Specification Document (Volume1: Reception Counter) Page 6

Requirement Traceability Matrix

Quality Assurance Group

Software Requirement Specification

User Acceptance Test

Software- Capability Maturity Model Integration

International Organization for Standardization

Software Requirement Specification Document (Volume1: Reception Counter) Page 7

eHealth needs to maintain the Patients medical records, Patients history,

The purpose of this document is to capture user requirements of reception

Software Requirement Specification Document (Volume1: Reception Counter) Page 8

2.2.3 Scope & Boundary

System should be able to authenticate a patient from citizen database

System should be able to validate and pull in the demographic details

System should be able to generate UHID cards based on identity card

System should be able to capture photo incase patient comes without

System should be able to generate UHID cards and register a patients

Software Requirement Specification Document (Volume1: Reception Counter) Page 9

o Doctors with the shortest queue

System should be able to search the patient details based on the

System should be able to merge the patient records if he/she registers

System should have a provision to track the following category of

The system should allow generating of statistical and analytical

Queue management at various places

Give appointment to patient for further visit

Software Requirement Specification Document (Volume1: Reception Counter)

2.2.4 Definitions, Acronyms & Abbreviations

Annexure 3 Functional Requirements

The existing system in the Department of Health and Family Welfare is

Software Requirement Specification Document (Volume1: Reception Counter)

The study is for fully understanding the requirement and suggesting

3.2 Process (Context Diagram)

Software Requirement Specification Document (Volume1: Reception Counter)

3.3 Functional Flow Chart