functional requirements - national rural health mission
TRANSCRIPT
Request For Proposal for selecting
Primary System Integrator for
e-Health Project
Volume 3 - Functional Requirements
eHealth Project Management Unit
Directorate of Health Services,
General Hospital Junction,
Thiruvananthapuram – 695 035
February 2014
CONTENTS
1. Hospital Management System
2. Web Portal
3. Public Health Monitoring System
4. Procurement and Asset Management
5. Maintenance Management
6. General Administration Module
7. Document Management Solution:
8. Management Information System
1 Hospital Management System
1.1 General Architecture The proposed architecture is based on a centralized hosted environment consisting of a
standards based clinical data repository that contains a longitudinal record of patients. The
central repository is a collection of documents for patients created at different points in time
across clinical encounters and episodes. To enable interoperability of clinical information across
points of care for patients the central repository shall be compliant with HL7 CDA and CCD
document structures. There will be a Lean Local Server in the Institutions. The main purpose of
this local server is to hold data to ensure business continuity in case of a connectivity failure. The
solution proposed should be in line with this requirement.
The detailed General Architectural Requirements of the Hospital Management System are
described below:
1.2 Central System
The central system shall have the following capabilities
Requirement
ID
Feature Description
HMS-GR.1 Unique identifier
(Centralized
Master Person
Index)
1. The centralized master person Index shall provide a single
point of reference to a patient, clinician, payer, or other
healthcare entity within the state environment. This shall
be the central single source of data for patient
demographic information
2. Centralized master person index should be capable of
handling multiple identifiers (Hospital registration
numbers, govt issued identities, UHID/Aadhaar.
3. The system should be able to de-duplicate person
information for multiple registrations using a heuristic
algorithm and establish a unique identifier for the patient
4. The master person index shall be able to interact with
external systems through open standards web services
based architecture
5. The Centralized master person Index shall be capable of
integrating ( Data exchange and de-duplication with other
govt citizen databases)
HMS-GR.2 Longitudinal
Clinical
repository
1. The centralized Clinical Data Repository (CDR) shall be
the common longitudinal repository of clinical episodes,
clinical encounters, medication, lab and diagnostics results
2. The repository should support HL7 CDA and CCD
document structures
3. The repository should be able to normalize these CDA
documents in the database so that a sub section of CDA
can be queried independently and also used for analytics.
4. The key function of the CDR is to capture and store
healthcare transactions from any relevant healthcare
domain (Diagnosis, Lab, Medication etc). To enable
interoperability, central eHealth requires an open HL7 V3
standards based repository conforming to the EMR/EHR
standards prescribed by Government of India to ensure
data can be reused for secondary purposes, such as
continuity of care.
5. Interfaces: The CDR must be exposed through open
standards based (Eg:Java/J2EE) application-programming
interfaces. Local (hospital, CHC/PHC) applications
(described later) should be able to interact with the central
repository to submit and extract required information
leveraging the document index.
6. Terminology Services: A collection of services allowing
the CDR to utilize the prevailing clinical terminologies for
coding data including LOINC, CPT4, ICD 10, SNOMED,
drug databases and other coding systems prescribed by
Government of India. Terminology services should also
provide a provision to load custom terminologies and
custom terminology maps. In addition the Terminology
Services should provide mapping functionalities between
the loaded terminologies – current and future
terminologies – in effect ensuring consistency of data in
the CDR over the years, allowing for the creation of a true
longitudinal patient health record. The Terminology
services should allow for the uploading of custom,
implementation specific concepts and terminologies.
7. Inbound and Outbound Messaging Services: A collection
of services that will allow the CDR to exchange inbound
and outbound HL7 CDA and CCD documents.
HMS-GR.3 Document Index The Clinical Document Index (CDI) operates as an adjunct
to the Clinical Document Repository. It provides a central
location which document consumers (Hospital/PHC/CHC
systems) can query for information about, availability and
location of shared clinical documents in one or multiple
repositories.
1.3 Hospital System
HMS-
GR.4
Outpatient
Management
1. The outpatient setup in PHCs and CHCs shall request the
centralized patient record for clinical history documents of the
patient once the patient is checked into the hospital/PHC/CHC.
Once the patient is in the queue in the backend the system shall get
the relevant documents and cache these documents in the local
point of care application for doctor to view the patient history.
The following table defines the data set that should be available to
the doctor
Title Content
Demographics Name, Age ( Calculated) , DoB, Father/Spouse
name, Phone Number, Address
Vitals Height (Multiple readings for under 20 yrs)
Weight ( last 3-5 Encounters)
Pediatrics Patients
Pediatric Parameters like Head
Circumference
Conditions Current Active conditions (ICD 10 Codes)
Past Notable Conditions (ICD 10 Codes)
Family History Relevant family history
Chronic conditions
Relevant Acute Conditions ( Cancer)
Social History Relevant Lifestyle related information
Diet and exercise
Smoking and Alcohol
Living Conditions
Immunizations Record of Immunizations
Medications Active Medications ( Currently active
prescriptions)
In-active Medications ( 6 Months)
Significant Medications ( Past Chemotherapy)
Alerts/Intolera
nces
Allergies
( Medication/Food/Substances/Medications)
Procedure
History
Past Procedures and amputations if any
Past
Encounters
Past 6 Months Encounter History
Chief complaints, Diagnosis, Outcome,
Investigations Medications
Care Plan Active Care Plan
Results Past One year investigation orders
Past One year investigations results
Notes Clinical notes
2. The screening process by a nurse shall also be able to identify the
relevant documents required for the clinical encounter with the
specialist. However the nursing staff shall be able to request for the
documents but not view these documents for patient privacy
purposes.
3. In this case the patient once checked in and queued for a specific
doctor shall be deemed to have provided consent to the doctor to
view his clinical history. The consent shall be implied once the
appointment is fixed. Based on the need the doctor can ask the
central patient record system to provide more detailed history or
search for specific document and view a broader range history of
the patient.
4. In case of larger hospitals once the appointment is fixed the system
should be able to schedule a caching of relevant documents from
central patient record between the check in to appointment waiting
time of the patient.
5. The new data generated as part of the encounter shall be captured in
relevant templates; these templates can be designed as per the needs
of the facility/clinical practice or chronic /acute disease, based on
the CDA architecture. The encounter information (Observations,
results, medications, notes) shall be captured in these documents
and uploaded to the central patient record as a part of its continuum
of care.
6. The data captured shall be stored in a temporary local storage
system for the day in case of OP. This is a back up to take care of
the business continuity in case of a loss of connection with the
central server.
HMS-
GR.5
In-patient
Management
In patient scenario is higher in transactions and shall follow similar
process to the outpatient scenario, where the patient history (Longer
duration than outpatient) shall be cached in local system once
admission is done. In this case the consent shall be implied to the care
provider organization as in many scenarios multiple physicians maybe
coordinating care for one patient. The local history shall be kept in the
facility till the completion of the episode of care and data generated in
multiple clinical encounters in the episode shall be captured in clinical
documents and regularly (daily) synchronized with the central patient
record. At the end of the episode the discharge summary shall be
prepared and stored in the central patient record for continuum of care.
HMS-
GR.6
Specialty
providers
In case of specialty providers using local specialty systems like
Oncology system, Cardiology application, the point of care specialty
system can be used as a source system to the central patient record. The
local specialty system should be capable of exchanging CDA
documents with the patient record
1.4 Offline Mode
HMS-GR.8 Ability to
capture
encounter data
The point of care shall have a lean application designed to
meet the particular needs of the point of care in case of a
connectivity failure. The lean application will leverage the
centralized patient health record to view and later update the
patient history. The lean application shall also enable the
clinical activities in the institution to go on without a linkage
with the central sever which may be unavailable due to loss
of connectivity and later update the patient history when
connectivity is restored. The requirements of this local
Hospital system are discussed here. In case of loss of
connectivity, the local Point of care solution should be able
to provide ability to capture encounter data for the patient.
The data capture can be based on most frequently used
templates. For example, General template to capture patient
encounters. Pediatric template for children, Woman
care/pregnancy templates for pregnancy cases. These
templates shall be defined with clinician inputs. These
templates can be based on HL7 CDA standards.
HMS-GR.9 Temporary local
storage
The local solution should provide a temporary local storage
of clinical data CDA/CCD based templates.
a. The temporary storage should store the encounter data
locally until its synchronized with the central patient
repository
b. The temporary storage should provide ability to store
data received from central patient repository for the
duration of patient visit
c. The temporary storage should be capable of providing
persistence for long term care plans for Inpatients
d. The temporary storage should be secure and encrypted
and should provide access control based on
confidentiality and privacy requirements
e. Temporary store should be temper proof and should not
allow any unauthorized access including system
administrators access to patient clinical data
HMS-
GR.10
Synchronisation
with Central
Server
The system shall initiate a synchronisation process with
central server a soon as connectivity is restored.
1.5 Other General Requirements are described below:
HMS-GR.11 Alerts,
Warnings and
Exceptions:
eHealth shall have a Decision Support System (DSS) built over
the existing protocols prevalent in the Department. The
Decision Support System of the Application shall throw
appropriate alerts and warnings which are rule based and
relevant for the stake holders.
At various points there can be situations which the system
cannot handle due to various reasons. The system shall have
foolproof methods to handle such exceptions. This means that if
the system fails to generate an output or complete the process as
described in the FRS at that point there shall be alternate
methods to continue the process. The system shall also generate
meaningful messages to help the user solve the problem. The
methods to continue the process shall be clearly defined in the
SRS in consultation with the Users.
HMS-GR.12 User Interfaces
(UI):
The number of persons approaching Public Healthcare
Institutions for medical care is huge. The average OP and IP in
each institution is given in Section……… It is very obvious that
every individual healthcare provider in the system starting from
the Nursing Assistant at the OP Ticket counter to the Specialist
Doctor in the OP Clinic or IPD are hard pressed for time and
resources to service such an enormous crowd in front of them.
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. This is not exhaustive and given only as in
indication only.
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
HMS-GR.13 Audit Trail The system shall keep a log of all transactions with User, Date
and time.
HMS-GR.14 Integration
with Medical
equipments:
The system shall be capable of interfacing with digital medical
equipments providing standard digital output.
HMS-GR.15 Performance
Indicators:
eHealth Application shall be able to evaluate and provide all
required Performance indicators pertaining to each Institution.
The detailed list of Performance Indicators in different domains
are given in this document.
1.6 Reception Counter Module
Introduction:
This module will handle the following functions:
1. OP Registration
2. Token issue
3. Issue of UHID Cards
4. Print outs of different documents required by the patients such as Reference Document
5. Enquiry
6. Online Registration
7. Report Generation
The detailed requirements of the Reception Counter Module is as follows
HMS-RC.1 OP
Registration:
OP registration has the following tasks:
1. Identify and locate the patient from the eHealth
Database.
2. If UHID is already allotted retrieve the UHID
3. Retrieve the Clinical Data (See Section 'General
Requirements')
4. Generate UHID if no UHID is already generated
5. Register the Patient if not already registered in the
database and allot a UHID
6. Allocate to the doctor based on specialty, patient
preference or current work load
7. Print Token
HMS-RC.2 Identifying and
locating the
Patient:
Implementation of the eHealth Project begins with the creation
of a demographic database of citizens in the state. This
database has nearly all important personally identifying data
pertaining to all citizens who are normal residents of the state.
This database has the Aadhar Number, ration Card number,
Mobile phone number etc.
This means that, when the system is implemented in a hospital
there will be a full-fledged citizen database at the back end. It
is very likely that the Patient reporting at the OP counter now
is also in the database. So the first task is to locate this patient
and get her credentials and Medical data from the data
repository.
Different scenarios are described below:
HMS-RC.3 Case 1:
Aadhaar based
Identification:
Aadhaar is the primary identity used by the system to identify a
person. So there are four options for a person with Aadhaar ID:
1. Produce the original Aadhaar card at the counter
2. Provide a photocopy of the Aadhaar card at the counter
3. Give the Aadhaar number in writing at the counter
4. Do a biometric authentication through eKYC facility of
UIDAI if options 1,2 & 3 are not feasible.
In case of options 2 & 3 also where the person do not
produce the original Aadhaar card a biometric
authentication may be necessary.
HMS.RC.4 Case 2: Ration
card based
Identification:
There are three options for a person who has a ration card
1. Produce the original Ration card at the counter
2. Provide a photocopy of the Ration card at the counter
3. Give the Ration card number in writing at the counter
For option 1 &2, where the patient produces the original
Ration card or the photocopy, the user at the counter scans the
bar code on the ration card and retrieves the ration card data.
For option 3 the user enters the number and retrieves the ration
card data. Based on this data the patient can be identified.
HMS-RC.5 Case 3: Driving
License, PAN,
Voters ID,
Mobile Number
based
Identification:
In the demographic survey there shall be provision to capture
the Driving License, PAN, Voters ID and Mobile phone
number. So there is a possibility that a person’s stored data
can be retrieved based on any of these numbers. Then with
proper validations her identity can be established
HMS-RC.6 Case 4: Any of
the above
Identification
numbers of a
next of Kin
residing in the
same House:
The data pertaining to all the members in a house hold along
with their relationship is captured in the demographic survey.
Hence if the above unique id numbers of any of the next of kin
can be given then the person can be located. Then with proper
validations her identity can be established.
HMS-RC.7 Case 4:
Identification
based on Local
Body, Ward
Number, House
Name etc:
The User can use any parameter like Local Body Name, Ward
Number, House Number, House Name etc to retrieve the
details of the person from the database. In this case also there
shall be proper validations before her identity can be
established.
HMS-RC.8 Authenticating
with Aadhaar:
In all cases where the identity retrieval was based on IDs other
than Aadhaar ID then the system shall do a verification to
retrieve the Aadhaar Number.
HMS-RC.9 Capturing
Biometrics in
the absence of
Aadhaar:
If Aadhaar Number cannot be retrieved then the system shall
capture the biometrics and store it so that next time the data
can be retrieved with biometric scanning.
HMS-RC.10 Retrieving
UHID:
Every citizen shall have a UHID. UHID is created first time
when the citizen approaches a public healthcare institution for
service. This is done at the time of the first OP registration of
the person in eHealth. All the clinical data captured
subsequently will be appended to the database against the
UHID. This UHID is only for the sake of the system and the
citizen need not be aware of this provided he/she has an
Aadhaar Card. In the absence of Aadhaar, the UHID can be
used till an Aadhaar number is granted to the citizen.
The system will do a database search to locate a citizen as
described above when she approaches any of the public
healthcare institutions for service and get her UHID.
HMS-RC.11 Retrieve the
Clinical Data if
the Patient has a
different
‘Registered
Hospital’:
The relevant Clinical Data of the Patient has to be extracted
from the Central server and cached in the local server for the
doctor to view later in the OPD.
HMS-RC.12 Generate UHID
if if the Patient
is not in the
Database:
The patient may be visiting the Public Healthcare institution
for the first time after the eHealth is implemented. Her name
may be in the demographic database but no UHID is generated
yet. Then the system shall generate a UHID now.
HMS-RC.13 Register the
Patient if not
already
registered in the
database and
allot a UHID
If the patient is not registered in the eHealth database at all,
then the earlier search will return a NULL. Then the system
shall do the registration first and then create the UHID. This is
a very delicate process and has to be handled with care.
Case 1: A normal resident of Kerala:
If the patient is a normal resident of Kerala then the
requirement is that all data items required in the Family Health
Register is to be captured. This is time consuming and cannot
be done at the Reception when there are others waiting in the
queue. So the following procedures are suggested:
1. Check if she has an Aadhaar. Do a Biometric
verification. If Aadhaar is authenticated then use it to
do the registration
2. If she does not have an Aadhaar and if she has any
other identity such as Driving License, PAN, Voters
ID, Mobile number etc use it for registration
3. If she has no identification proof then capture name,
DoB/Age, Address with District and generate a
temporary ID.
In this case the District Official shall be given an SMS/System
alert to locate this person later and add in the database.
Non Resident Keralites can be registered provided they have a
local address.
Case 2: Citizens from other states who have migrated to
Kerala:
Citizens from other states who have migrated to Kerala shall
also be registered as described above. However the system
shall use a flag to distinguish them in order to help the
Government plan welfare measures.
If there is any registry for migrant workers, the eHealth system
shall have linkage with that to exchange data as required.
Case 3: Travelers and Tourists:
System need not keep a trail of Medical Records of each
tourist/traveler. The records can be stored with separate IDs
and stored only in the Central Server. Any of the above
mentioned numbers viz. Aadhaar, Mobile, Voters ID, License
Number etc can be used for registration along with the name
and address. In case of a Foreigner capture the name of
Country and Passport Number and do the registration. There is
a system of registration for every foreigner arriving in the
country and staying in Hotels and Home stays. This is a
computerized system and eHealth may have to have link with
the system.
HMS-RC.14 Multiple
registrations to
be avoided:
In all cases the system shall carry out exhaustive validations to
ensure that a person is not registered multiple times and given
more than one Health ID.
However in the rare case of one person being registered
multiple times inadvertently, the system shall ahve facility to
link these records and create a single entity.
HMS-RC.15 Native Hospital: Every citizen is conceptually linked to a PHC/CHC for
statistical and Healthcare monitoring purpose. The database
shall have facility to flag a hospital as a 'Native Hospital' for
each citizen and generate statistical reports A Native Hospital
is normally the PHC/CHC in the area where they reside
HMS-RC.16 Photo The system may have a facility to capture the Photograph of
those who do not have an Aadhaar Card. The OP counter may
have a web cam with good resolution to capture the photo and
add to the database.
HMS-RC.17 Token Issue: The system shall display the OP wise list of doctors on duty on
the day, extracted from the Duty scheduling module. There
shall be facility for the Patient to choose a doctor if she desires
so. If the policy of the Hospital does not allow this, then this
option can be disabled in that hospital. The Medical Officer in
charge of the Hospital shall have the privilege to disable this.
The system shall print a Token with the following information.
Name of Patient
Gender
Age
Address
Name of the Native Hospital in case it is a different
Hospital. (Not mandatory)
Name of the OP clinic the patient wants to visit
Name of Doctor (Not mandatory)
Bar code
HMS-RC.18 Issue of Health
Cards:
Patients can be issued a Health card on request. The system
shall keep a track of this and manage the issue of Health cards
There may be two different types of Health cards.
Health ID Cards:
This may be free of cost for the first time and subsequent
issues may be charged. The Health ID card may be standard
Plastic cards and need contain only basic information such as
Name, Date of Birth/Age at the time of issue, Aadhaar Number
/ UHID Number, Photograph etc. Bar code with required basic
data for identifying the patient shall also be printed on the
Health ID Card.
Health Smart cards:
This can be issued to patients with chronic illness, Pregnant
women who need special attention etc. The clinical data can be
updated in the card at the end of each encounter. Reception
counters shall b e equipped with smart card readers to update
this data.
HMS-RC.19 Print outs of
different
documents:
There are only few centers where print out are given to
patients. At OP clinics no print out is given to them. Hence the
required prints are to be issued from reception. Some of the
print outs are listed below:
Prescription for Drugs if patient wants to buy from other
Drug stores
Prescription for tests if patient wants to do it outside
Reference Document
HMS-RC.20 Enquiry: This module shall be capable of providing various general
information to the Patients. Some are listed below:
Availability and Duty time schedules of doctors
Timings of various services
Information on all services available in the Hospital
Important telephone numbers
Information on all services available in the higher level
referral Hospitals nearby
Status of Pay ward Bookings
HMS-RC.21 Online
Registration:
There shall be facility to do online registration for OP
consultation. The Medical Officer in charge of the Hospital
shall have the privilege to determine the number of days
allowed for advance booking and the percentage allowed for
advance booking. There shall be facility for patients
registration for online services. Patients can log in view the
doctors on duty and register online for consultation. The
system will allot a token number based on a logic to sandwich
the online and walk-in patients based on the percentage allotted
for online booking. The system shall send SMS and email
confirmations of the token number with necessary disclaimers.
HMS-RC.22 Report
Generation:
This module need to generate several reports. An indicative list
is given below. These reports will have to be generated daily or
for a specified period.
OP Register
Review OP Register
Foreigners OP Register
Accident Register
Department/Unit wise OP Statistics
Income wise OP Statistics
District region wise OP Statistics
Incident Register
1.7 OP Clinical Module
This module will handle the following functions:
1. Queue Management
2. Intermediary Nursing station
3. Past Clinical History
4. Symptom Capturing
5. Diagnosis Capturing
6. Protocols and Guidelines
7. Prescription of Drugs
8. Prescription of Tests
9. Prescription of Clinical Procedure
10. Admission to IP
11. Coding of Diseases:
12. Issue of Medical Certificates:
HMS-OPD.1 Queue
Management:
Patients will report at the OP clinic after registration at the OP
counter. They will have tokens issued to them from the OP
registration counter. The tokens are issued Specialty / Unit /
Doctor-wise. Each Doctor shall get the list of patients waiting
to see her. Patients who have not indicated any preference for
any doctor shall be included in the list of all doctors on OP
duty in the Specialty. The topmost token shall be highlighted
and the Doctor shall have the option to move the highlight to
any token in the queue. The system shall push the highlighted
token number to the token display. In case the patient with the
displayed token number is not available at the moment for
consultation the token may be pushed a few steps down the
list so that it will reappear at top after a few turns. Also there
may be facility to remove the token from the list if required.
HMS-OPD.2 Past Clinical
History:
The system shall display the past clinical history of the
selected patient in a standard format as available in the
system. This may begin with the most recent history with
facility to drill down and view all the past history. This
interface shall display all the clinically relevant information
such as allergy to drugs etc.
HMS-OPD.3 Capturing
additional
History
The doctor shall have an interface to capture the history and
additional information if necessary. The interface shall be
User friendly, interactive, menu driven, ICD 10/SNOMED-
CT based and designed specifically for each specialty to avoid
keyboard entry to the extent possible.
HMS-OPD.4 Symptom
Capturing:
The system shall have interface to capture the symptoms as
the patient narrates them. Here the emphasize is to make the
screen as user friendly as possible minimizing key board entry
and designed to suit each specialty. The system shall use
standard coding system for recording the symptoms.
HMS-OPD.5 Vitals:
Physical
examination
and Findings
a. The system shall have interface to capture the Physical
examination Findings. The UI shall provide user friendly
screens to enter all the parameters related to physical
examination. There shall be validation and alerts for
unusual entries.
b. The system shall provide facility for an intermediary
nursing station where the vitals of the patient are captured
by a Nurse and entered. However in smaller hospitals
where such a facility is not available this will be done by
the doctor. The system shall have flexibility to configure an
intermediary nursing station
HMS-OPD.6 Diagnosis
Capturing:
The system shall capture provisional & final Diagnosis. The
interface shall be User friendly, interactive, menu driven, ICD
10 based and designed specifically for each specialty to avoid
keyboard entry to the extent possible.
HMS-OPD.7 Protocols and
Guidelines:
The system need to have embedded Protocols and Guidelines
to assist the Physician to carry out the clinical activities as per
the accepted norms and best practices. Protocols, Norms, Best
Practices and Guidelines as used in the clinical practice in the
state shall be incorporated in the system. In the absence of
documentation of such standard practices in the state the
solution provider shall suggest guidelines based on National
or International practices based on their previous experience
in the field. This will be reviewed by an expert panel. The
approved Protocols, Norms, Best Practices and Guidelines
shall be incorporated in the system.
HMS-OPD.8 Advise: The system shall have facility to for the Doctor to record the
advice. Some of the advice will comprise of the following,
though this is not an exhaustive list.
1. Investigations orders: Some of the typical orders are
a) Lab Test
b) X Ray
c) ECG
d) EEG
e) TMT
f) Scan
There shall be user friendly menu driven screens for
Doctors to prescribe Tests. All the standards Tests shall
be available as drop down lists for the Doctor to choose
from. National and International coding systems such as
LOINC shall be used for tests and clinical procedures.
All the Tests prescriptions shall be queued at the
Laboratory. The Clinical Procedures shall be queued at
Nursing Stations or mini Operation Theatre or other
locations depending on the nature of the procedure. The
services shall be delivered as per the queue.
2. Prescription of drugs.
There shall be user friendly menu driven screens for
Doctors to prescribe Drugs, Tests and Clinical
Procedures. All the standards Drugs, Tests and Clinical
Procedures shall be available as drop down lists for the
Doctor to choose from. There shall also be facility to
enter the names of Drugs, Tests and Clinical Procedures
with auto-complete facility.
The Doctors web page shall display the drugs available in
the Hospital Pharmacy. It shall also have an exhaustive
list of drugs which can be prescribed and purchased from
outside also. For this the system may be linked to any
standard drug specification publications such as WHO
Drug Dictionary ATC – anatomic therapeutic
classification, CIMS, MIMS etc. with regular updating
arrangement. The cost for such subscription shall be
borne by the Solution Provider throughout the contract
period.
All the drug prescriptions shall be queued at the
pharmacy. The pharmacist will deliver drugs to each
patient based on this queue.
KMSCL has evolved a drug code for its use. The solution
provider is free to use this or another standard drug code
if it suits the eHealth Application. If a drug code different
from that of KMSCL is chosen then the chosen drug code
shall be mapped with that of KMSCL so that both
systems interact seamlessly.
3. Clinical Procedures , Injection, Dressing wounds
(Cleaning &Dressing, Incision & Dressing),
Administering Intravenous Fluid:
There shall be user friendly menu driven screens for
Doctors to prescribe Clinical Procedures. All the standard
Clinical Procedures shall be available as drop down lists
for the Doctor to choose from. National and International
coding systems such as WHO – PCS , SNOMED-CT,
CCI etc shall be used for clinical procedures.
All the Clinical Procedures prescribed shall be queued at
Nursing Stations or mini Operation Theatre or other
locations depending on the nature of the procedure. The
services shall be delivered as per the queue.
HMS-OPD.9 Observation
Ward:
There may be an observation room attached to Casualty and
other OPs. Nurses at these wards shall have facility to record
the all the incidents happening at these wards similar to the
other in-patient wards.
HMS-OPD.10 References
within same
Hospital:
The system shall have facility to refer patients to other OPs or
Other Doctors within the same Hospital. This will require a
reasonable logic to be evolved for managing the queue
without hassles. A patient may be referred to one or multiple
Doctors for consultation from the OP where she reported. This
could be either because she reported at the wrong OP or
because she needs further consultations. The patient already
has a token number. How this token is to be queued at the
subsequent OPs where the patient is redirected is to be
decided and the system developed accordingly.
HMS-OPD.11 Reference to
other Hospital
These are cases when the patient is referred to another
hospital for treatment.
This process shall mark the patient as a referred patient in the
database in the Central Server. The system will have facility
to create and transmit the relevant clinical data in a standard
format to the other hospital where the patient is referred so
that when the patient visits the referred hospital within a
specified period, the clinical data can be easily retrieved in the
hospital.
In case the system fails to retrieve the relevant clinical data of
the referred patient to the referred hospital due to connectivity
failure, then a reference document shall be generated at the
referring Hospital by the Doctor who is referring the patient.
This document will have necessary clinical data in a standard
format. This is printed and handed over to the patient with
necessary directions. This printed reference document will
also have a bar code.
A printed reference document may also be required in the
following occasions as well.
1. When the patient is not referred to any specific
hospital (Eg: Consult a Cardiologist of your
Choice)
2. Patient wants to consult somebody in the
private sector.
At the OP ticket counter of the referred hospital the system
will recognize the patient as a referred patient and a token
printed with information such as the name of the Referring
Hospital and reference status. The Doctor at the OP will have
necessary clinical data at his terminal when the Patient walks
in for consultation in his cabin. If necessary the Doctor can
also access the central server and get additional information
directly.
If there is no connectivity then the OP module will not be able
to get the digital data and the doctor will have to go by data in
the printed reference document. The data input by the
referred hospital will be cached in the local server initially and
later the Central Server database will get updated by this data.
If the patient has a Smart Health Card then the card will be
updated at referring hospital and the referred Hospital can use
the data in the Smart card if connectivity is not available.
HMS-OPD. 12 Tentative
Appointment
The system shall provide the referring Doctor facility to view
the availability of the Doctor to whom he is referring the
patient and if necessary take a tentative appointment. The
referred Doctor will then get the details of the patients in
advance.
The system shall have a messaging system so that doctors and
paramedical staff can communicate with each other on clinical
matters online and take decisions..
HMS-OPD. 13 Admission to
IP
The system shall have facility for the Doctor to order
Admission. Doctor’s direction will contain Ward Number,
Unit and other orders. These details shall be queued at the IP
registration counter (Admission Counter).
HMS-OPD. 14 Casualty: Processes in Casualty are similar to that of other OPs except
that they have to deal with Medico Legal Cases. The system
shall have facility to for the following:
Generate Police intimation form.
Generate Accident Register cum wound Certificate.
Certificate of Examination of a person under police or
judicial custody
Drunkenness certificate Register
Examination of potency
Scheme of examination of rape
Update Death Register
Update Brought Dead Register
HMS-OPD.15 Key Board
entry with
auto
completion
In all cases described above where standard menu driven
interfaces are provided there shall be an alternative facility to
enter data through key board, in case the doctor is more
comfortable in using key boards. This facility shall be
augmented with auto completion facility. In all cases there
shall be a list of favorites for each doctor so that the selection
becomes easier.
HMS-OPD.16 Coding of
Diseases:
The Government of Kerala has adopted ICD 10 for Coding of
Diseases. The system shall suggest codes based on the
diagnosis. There shall be an interface for the Medical Record
Librarian to verify the Code and confirm it or enter a new
code.
HMS-OPD.17 Issue of
Medical
Certificates:
Doctors may be required to issue various certificates to
patients. A list of Certificates to be issued by Doctors is given
in Annexure: ……. The system shall have interface to issue
all such certificates which can be issued from the OP Clinic.
These certificates will be digitally generated by the Doctor
and printed at the OP Nursing Station. The printed certificates
are then signed by the Doctor.
Some Certificates are free and some are paid. The system
admin shall have facility to mark certificates as free or paid
and update the fee to be paid for each type of certificate. For
paid certificates the system shall capture details such as
amount to be paid to the hospital and that to be paid to the
doctor. The certificate may only be generated after the
requisite fee has been paid. The amount collected on behalf of
the Doctor is to be credited to the account of the Doctor
directly.
HMS-OPD.18 Reports: The system shall have facility to generate all statistical
Reports and MIS reports.
1.8 In-Patient Management
This module has the following requirements:
HMS-IPD.1 Admission The Doctors at OP Clinics may order a patient for admission
to a specific ward under his department. The doctor's
directions are expected to contain the following mandatory
items:-
Name of Doctor,
Provisional Diagnosis,
Ward Number and Unit Number ( Normally there is a
linkage for Ward/Bed to Unit.)
HMS-IPD.2 IP registration
Counter
The patient is then queued at the IP registration counter
(Admission Counter). The Nursing Assistant at the
Admission will verify the data, confirm the identity of the
patient and complete the process by making necessary entries
in the system. These details entered shall be stored as the
Main IP Register. Only the admission part is entered by the
Nursing Assistant. No clinical data is filled up by the Nursing
Assistant. Rest of the data are entered subsequently at the
ward and then later completed by the Medical Records
Department. A new IP Record is generated and a unique IP
number is allotted to the Patient. The Patient is flagged as an
In-Patient. The IP record shall be linked to the demographic
data of the Patient.
HMS-IPD.3 Sociological
Data
Essential sociological data of an identifying nature is a
required in the Case record. Incase this is not available in the
database at the time of admission of the patient then this data
is to be gathered either from the patient or from the nearest
relative present at the time of admission and then entered in
the Main I.P Register and in the Case Record.
HMS-IPD.4 Ward Then the patient is directed to the Ward. The IP record now
created shall be available at Nursing Station attached to the
Ward where the Patient is admitted. The Duty Nurse shall
have facility to enter any hand written directions by the
Doctor. The previous case records of the same patient shall
be automatically retrieved by the system and made available
to view. The viewing privileges shall be decided at the time
design and implemented
HMS-IPD.5 Allotment of
Bed and
allotment of
Linen
The system shall have facility for allotment of Bed and
allotment of Linen. There shall be interfaces for recording all
the Nurses activities.
HMS-IPD.6 Clinical data Duty MO/MO in charge of the Ward shall have privilege and
entry by
Doctors
UI to view all new admissions daily and give further clinical
directions from anywhere in the Hospital. Duty MO may
order further investigations, medications and other directions.
User friendly Interface shall be made available to record
subsequent directions by the concerned MOs during routine
rounds.
The Medical Officer attending the case shall have facility to
record all details the patients regarding the onset and cause of
the present illness, personal and family history and also that
of physical examination conducted. All investigation reports
concerning Laboratory, X-ray, E.C.G. etc are to be captured.
It shall also be possible for the Medical Officer to record
daily the progress of the patient along with his directions
regarding the treatment to be carried out until the discharge of
the case.
HMS-IPD.7 Accident
cases
In accident cases there shall be facility to record external
cause of the accident and the nature of injury.
HMS-IPD.8 User
Interfaces for
the Nurses
There shall be User Interfaces for the Nurses to record the
observations of the Nurses and also details of treatment and
services rendered by them to the patient. The system shall
have facility for the preparation of Graphic Chart and Nurses
records.
HMS-IPD.9 User
Interfaces to
record
references
There shall be User Interfaces to record references to other
Hospitals or to other Specialties within the same Hospital.
HMS-IPD.10 Temporarily
shifting for
tests etc
Patients may have to be shifted out temporarily for tests and
other procedures that may not be available in the hospital.
There shall be User Interfaces to record this.
HMS-IPD.11 Registers The system shall have facility to generate the following
Registers:
Report book
Costly Medicine Book:
Diet Register
Complaint Book (Office Information Book):
RMO Stock Register:
Referral Book:
Daily Discharge register:
Discharge Card to be issued to the Patient
Daily Admission / Discharge / Census Report
HMS-IPD.12 Ambulance
Service
Requests:
The system shall have facility to request for Ambulance
services by Duty MO. This interface shall have a link to the
108 Services so that a request is generated automatically. The
system shall have linkages with other Ambulance services as
well. It should be possible for requesting Ambulance from
other sections such as OP etc.
HMS-IPD.13 Delivery The system shall have facility to record the following:
To record shifting of Patient to the Labour Room
To record Delivery and update the Birth Register.
To report the Birth to Local Body through Medical
Record Department.
To update the Report Book in Labour room
To update the Case Record Book with the type of labour
and the details of the new born baby by the attending
Medical Officer.
To update the following registers
MTP Register
Sterilization registers
Abortion Register
Laparoscopic Sterilization Register
HMS-IPD.14 Operation
Theatre:
The system shall have facility to record the following:
Pre - operative diagnosis before the operation is
performed
Pre-anesthesia check up details
Anesthesia procedure
The Surgery procedure and findings immediately after
the operation
Findings in the Surgery and post-operative diagnosis.
Anesthesia recovery details
Provisional/Final diagnosis
The system should update the following registers:
Minor surgery register
Major surgery register
Anesthesia register
The system shall have the following facilities:
Manage Operation Theatre consumables
Operation Theatre scheduling
Pre- Operation Theatre Checklist
Surgeons Notes
Keep track of Operation Theatre Equipment Usage
Generate Operation theatre reports
Generate Operation Theatre & Operation Resources
Usage Report
HMS-IPD.15 Discharge: The system shall have facility to record the following:
The final diagnosis
The date and time of discharge from the hospital
The condition of the patient at the time of discharge
Cause of death in cases of Death
Other Discharge Data etc
HMS-IPD.16 Discharge
Register
The system should update the Discharge Register.
HMS-IPD.17 Final
diagnosis
The final diagnosis recorded should be complete in all
respects and should be accurate and in conformity with the
accepted terminology of the standard nomenclature of
diseases and operations. The Discharge condition may have
the following options:
a. Cured
b. Relieved (Condition Improved)
c. Referred
d. Death
e. Left Against Medical Advice (LAMA)
f. Discharged Against Medical Advice(DAMA)
g. Absconding
HMS-IPD.18 Discharge
summary
The system shall have facility to give the Discharge summary
to the patient as a Discharge Card and a Reference Card to
the referred patients in a standard format. The reference may
be of two types:
i. To a higher Level Hospital for further investigation and
treatment
ii. To a lower level Hospital for continuance of care
HMS-IPD.19 Discharge
process in
emergency
situation
The system should have facility to allow the Duty MO to
initiate discharge process in emergency situation if necessary.
HMS-IPD.20 Reports The system shall generate necessary reports for the privileged
users. The report shall contain the following data:
the ward and the date to which it relates
I.P.No. Name, age, unit, diagnosis and date of
admission of the cases discharged from the hospital
for that particular day.
Details of outstanding cases, admissions, transfer in
discharges, deaths, transfer out, balance remaining,
(classified into male, female and children).
HMS-IPD.21 Death: The system shall have facility to update all the related
registers and forms such as:
Death Register
Death Report (Form No 2)
Medical Certificate of Cause of Death (MCCD -
Form No.4).
Part 1 of Death Report and MCCD is sent to the Local
Body (LSG) for registration of death.
When body is handed over the duty nurse shall get
acknowledgement of the relation who is taking over the body
in a printed form (Death register)
The system shall have facility for the following
To authorize autopsy if required.
To record that the body is ‘Transferred to Mortuary'
in the death register.
To generate and Print the Police intimation form
To update the Mortuary Register by the Nursing
Assistant.
The system shall have a UI to enter autospy report by the
authorized Doctor. It shall be feasible to send information to
the Police Computer system through web service at a later
stage.
The system shall have facility for giving permission to store
the body in the mortuary if necessary for prolonged periods.
HMS-IPD.22 Patients
Search &
Select
The module shall have facility to search patients based on
various search criteria and display details based on the access
rights.
1.9 Store and Pharmacy Module
The Pharmacy Module shall carry out the following functions:
1. Stock Updating
2. Issue of Drugs to Patients
3. Billing
4. Drug Requisitioning
HMS-PM.1 Stock
Updating:
Pharmacy gets the stock of drugs from the Hospital Store. The
store is part of the KMSCL network. Hence the eHealth system
should be linked to the KMSCL system to get stock data real-
time. The Pharmacy module shall have interface to receive the
stock issued from the store to the Pharmacy and also to return
stock when necessary. The system shall up date stock position to
the central server at a given interval.
HMS-PM.1 Issue of Drugs
to Patients:
The Drugs prescribed by the Doctors are queued at the Pharmacy.
Pharmacists issue drugs to patients based on this list. The system
shall print out the details including dosage. The system may also
need to print out the list of drugs which are not available at the
pharmacy for allowing the patient to buy it from outside.
HMS-PM.2 Billing: Normally the supply of drugs to patients is free of cost. However
the system shall have facility to calculate the cost of Drugs and
also to print them on the document handed over to the patient.
The cost of the drug may be shown and the entire amount
deducted as subsidy so that the patient need not pay anything.
HMS-PM.4 Requisitioning
of Drugs and
other Store
items:
Pharmacy module shall have interface to do the requisitioning of
drugs and other items from store regularly. Such requisitions can
come from Pharmacy, IP wards, Doctors who want a specific
drug or item and even other employees. This data shall be
compiled for the Hospital and transmitted to KMSCL regularly.
Head of the Institution shall have a privilege to overrule the
periodicity of the central server updating and update data
instantaneously in case of urgency requirements.
HMS-PM.5 Drug
Requisitioning
The system shall have facility to intend drugs online. Every such
request originated in an Hospital shall be compiled by the system
and transmitted to KMSCL for arranging purchase. The Head of
Institution may also arrange to purchase some drugs locally using
the HMC fund or Government fund. The system shall be able to
arrange the procurement through the ‘eQuotation’ described in
this document
HMS-PM.6 Reports The system shall generate various reports. Few examples are
given below:
Drugs Available
Drugs Details Listing
Drug Sales Daily
Drug Sale Patient Wise
Drug Stock
Indents and Issues to Other Depts. / General Store / Sub-
Stores
Batch details of drugs
Sale Report
Store-wise medical consumable stock
Prescriptions versus Issues / Sale
Pending Prescriptions (IP/OP)
1.10 Blood Bank
Most of the Large Hospitals have Blood banks where as some of the smaller hospitals
have Blood Storage facility. eHealth system shall have module to manage the Blood bank
functionalities.
HMS-BB.1 Donors Database The system shall have an interface for Donor
registration and shall maintain a database of
Donors.
There shall be linkage to the web portal so
that Donors can register online through
eHealth portal
There shall be facility for Donor search
HMS-BB.2 Results of each tests and
quality of blood
collected
The system shall capture and store the results
of each tests and quality of blood collected
HMS-BB.3 Blood Inventory
Management
The system shall have facility for Blood
Inventory Management including stock
register and issue register
HMS-BB.4 Online requests Doctors shall be able to register their
requests for Blood online. The Blood bank
managers shall be able to view the requests
and respond.
HMS-BB.5 Blood Bank registers The system shall have facility to update all
Registers maintained in the Blood Bank
1.11 Laboratories
Public Health Laboratories
There are six Public Health Laboratories in the State.
1. State Public Health Laboratory - Trivandrum
2. Regional Public Health Laboratory - Ernakulam
3. District Public Health Laboratory - Kollam
4. District Public Health Laboratory - Alleppey
5. Regional Public Health Laboratory - Kannur
6. Regional Public Health Laboratory - Kozhikode
Patients can walk in to any of these PH Laboratories for clinical tests. Patients may carry
prescriptions for tests from Govt. hospitals, Private hospitals or even Private doctor referrals.
There can also be direct request from Patients for normal routine clinical tests such as Blood
Sugar, Lipid profile etc without a formal prescription from a Doctor.
Out of the six Public Health Laboratories in the State only the State Public Health Laboratory in
Trivandrum has a computerised system. This is an archaic system and will be replaced by the
proposed PH Lab Module in the eHealth.
The system shall have the following facilities:
HMS-LM.1 Reception: 1. Provide Token numbers for Queue management
2. Capture the id of the patient from the citizen database
available in eHealth
3. Retrieve the prescriptions from Government Hospitals
generated through eHealth and available in the eHealth
database
4. Enter test prescriptions from the following sources:
a. Govt. hospitals not yet covered under eHealth
b. Private hospitals
c. Private doctor referrals
d. Direct request from Patients for routine clinical
tests without a formal prescription from a Doctor.
5. Store rates of different tests
6. Generate bills for the three categories viz.
a) Free category
b) Concessional Rate
c) Full payment category.
7. Receive payments and issue standard Treasury receipt viz.
TR5.
8. Account the collected money
HMS-LM.2 Sample
collection
1. Queue management at Sample collection counters
2. Flag the two categories sample collection viz.
a. sample collected and brought from outside
b. patient coming for sample collection
3. Master table for different sample types – Blood, Urine,
Sputum, Pus, needle aspirates etc.
4. Uniquely identify the multiple samples for a each patient
and multiple tests for each sample.
5. Print labels for each sample
6. Generate separate requests for separate sections.
HMS-LM.3 Sections:
1. The data from Reception and Sample collection counters
shall be available at the sections.
2. Standardised UIs to enter Test results
3. Alerts for abnormal values
4. Facility to verify and approve by superiors
5. All results once approved will not be editable by the staff.
6. Editing privilege is only to section head.
HMS-LM.4 Result issuing
1. Queue management at Result issuing counters
2. Alerts when the results of a patient are available
3. Print the results
4. Print the names/designation of concerned authorities in the
print out.
5. SMS and email alerts to the patients when result is ready.
6. Web portal shall have facility for the registered Users to
download their test results.
7. Facility for the Doctors at Hospitals covered under
eHealth to view the result.
HMS-LM.5 Supporting
sections
Reagents are prepared in these sections for supply to outside
institutions like CHCs and Hospitals. There shall be facility for
accounting stock (manufacture and issue) of reagents prepared in
the sections.
1.12 Clinical Laboratories in Hospitals:
There are clinical laboratories in all major Hospitals. Medical College Hospitals have specialized
Laboratories such as Pathology, Bio-Chemistry and Micro-biology labs. The requirement in
these laboratories are as follows.
HMS-LM.6 Clinical
Laboratories
in Hospitals:
Clinical Laboratories in Hospitals have similar requirements
except that patients approaching them for service are those from
the OP or IP of the same hospitals. So the queue management
system need to consider only such cases. The tests are prescribed
by the doctors and hence the data entry by staff at laboratories is
practically limited to result entry.
1.13 Picture Archiving and Communication System
Major Hospitals shall have a Picture Archiving and Communication System (PACS) which
provides economical storage of, and convenient access to, images from multiple modalities
(source machine types). User Licenses shall be unlimited
HMS -PACS.1 The Architecture should be centralised one in which the long term storage is
done centrally for all hospitals. Images pertaining to the current episode /
encounter alone are proposed to be stored in the local server. Medical Images
which have clinical or academic importance are proposed to be uploaded to
the Central server for the time being. The enterprise work list for every
Radiologist may be driven from the central server.
HMS -PACS.2 The Local PACS at the hospitals System should be able to connect to any
DICOM 3.0 modality including the various modalities in the
radiology/cardiology department.
HMS -PACS.3 For future connectivity with any modality, no additional license shall be
required. Vendor shall provide the required support during the entire period
of Contract.
HMS -PACS.4 The system shall have two components
1. VNA (Vendor Neutral Archive)
2. RIS-PACS.
HMS -PACS.5 The storage shall be managed by VNA independently of RIS-PACS. Vendor
needs to ensure that no data migration is required if department decides to
replace the RIS-PACS to some other system in the future.
HMS -PACS.6 All the modalities shall transfer data images to the PACS application server.
Diagnostic workstations shall be connected to PACS for reporting
HMS -PACS.7 All digital imaging modalities listed below will be interfaced with PACS
MRI
PET-CT
CT
Mammography
Ultrasound & Doppler
Digital X ray Nuclear medicine Single-photon emission computed tomography (SPECT)
Endoscopy
Slide Microscopy
Radio Therapy Image, Segmentation
External Camera Photography
DSA Images (Cardiology, Neurology, Radiology etc)
HMS -PACS.8 The system shall support unlimited DICOM modality connectivity. No
additional license shall be required from vendor to connect the supported
DICOM modalities to PACS.
HMS -PACS.9 The system interface shall be browser based and users (esp. Physicians)
should be able to access the images without requiring any application
installation at the viewing PC. The user interface shall be very intuitive and
easy to use
HMS -PACS.10 Application should conform to the standards DICOM/HL7. DICOM Conformance
and HL7 Protocol guide needs to be shared
HMS -PACS.11 Application should follow the guidelines for data security and confidentiality
reasons
HMS -PACS.12 The system shall support unlimited examinations/studies. There should not be any
license dependency to store high number of records.
HMS -PACS.13 The proposed system architecture shall be scalable. It should not only meet the
current load requirements (in terms of incoming scans and users), but shall also
meet the future requirements (assuming increase of 10% load year on year).
HMS -PACS.14 The system should be Web based and allow access of images in any PC.
HMS -PACS.15 The application shall work on multiple operating system environments. Users shall
be able to connect from any operating system and view images (ex. Windows,
MAC, Linux etc.)
HMS -PACS.16 The system shall be designed and appropriate hardware needs to be proposed to
handle nearly 1500 users concurrent load.
HMS -PACS.17 The system shall support TeleRadiology and doctors shall be able to view images
and report cases from anywhere.
HMS -PACS.18 The system shall allow to define the purge rules for slices
HMS -PACS.19 Proposed system should be hardware agnostic and should be able to run on
any standards hardware etc.
HMS -PACS.20 The storage architecture should be VNA (Vendor Neutral Archive) based.
All the image shall be independently managed by the VNA server and PACS
should keep only short term data. The architecture shall ensure that there
should not be any data migration, if hospital decides to change the PACS
system. The new PACS system shall be able to work seamlessly with VNA.
Performance
HMS -PACS.21 System should have been tested for performance with 1Million scan studies
in the database. Documentary evidence should be produced at the time of
Technical Evaluation.
HMS -PACS.22 The study list page and any query on that should display results in less than 2
secs
HMS -PACS.23 X-ray image should be loaded in less than 2 seconds
HMS -PACS.24 Loading CT scan with 2500 images should not take more than 2 mins from
server
HMS -PACS.25 There should not be any limit of loading high image volume scans on 32 bit
machines. Normal desktops shall be able to open big CT studies
Security
HMS -PACS.26 All access should be encrypted and system should support SSL
HMS -PACS.27 All user access (ex. login, study access, report access) should be saved into
database as AUDIT TRAIL and this should be accessible/searchable by
Administrator
HMS -PACS.28 Integration with Identity and Access Management
Radiologist Worklist
HMS -PACS.29 Browser based worklist
HMS -PACS.30 User should be able to search and filter the records. Search should be
supported on various parameters ex. Patient Name, Patient ID, Accession
No, Modality, Scan Date/Time, IP No
HMS -PACS.31 Study List should display the reporting status (DRAFT/Reviewed/Sign-Off)
for the scan
HMS -PACS.32 User should be able to see the series breakup for the scan and has the option
to load limited/all series in the viewer
HMS -PACS.33 User should be able to add interesting cases to Academic folders
HMS -PACS.34 The shortcuts should be displayed as links
HMS -PACS.35 If exam has prior studies, it should be displayed on the study list page with
some link
HMS -PACS.36 User should be able to view the complete Patient History without separate
logging into any other Module. It should be one-click access
HMS -PACS.37 If study is currently being accessed by other radiologists, it should be
displayed on study-list with the name of doctor who is currently accessing it
Image DICOM Viewer Features
HMS -PACS.38 Ability to load and display various types of Images ex. CT, MRI, X-Ray,
US, Cath-Lab, 2D Echo etc.
HMS -PACS.39 Series Thumbnail panel and one click option to load series on viewing area
HMS -PACS.40 Ability to display multiple series at same time
HMS -PACS.41 Series Synchronization : Auto and Manual
HMS -PACS.42 Scout/Reference line display
HMS -PACS.43 Ability to load priors and view both current and old study at the same time
HMS -PACS.44 Series Synchronization between current and old scan
HMS -PACS.45 CT Window level presets. Ability to define new presets
HMS -PACS.46 Image Filter support
HMS -PACS.47 Zoom-in and Zoom-out support
HMS -PACS.48 Image rotate and flip support
HMS -PACS.49 Image colour invert support
HMS -PACS.50 Measurements support : Pixel(Hounsfield), Linear, Area, Angular
HMS -PACS.51 Ability to retain the study layout while interchanging between studies.
HMS -PACS.52 Ability to pop-up a series in a small window and scroll it without disturbing
the existing view layout
HMS -PACS.53 Hanging Protocol support
HMS -PACS.54 Ability to save hanging protocols on the server
HMS -PACS.55 MRI Spine Labelling Support
HMS -PACS.56 Magnifinder support
HMS -PACS.57 Inbuilt PACS viewer should support MPR & MIP for CT and MR images.
Hospital need to procure addtiional workstation softwares to achieve this
HMS -PACS.58 Ability to view images on Mobile devices (ex. iPhone, iPAD, Android) as
DICOM images. User should be able to do require image manipulations and
measurements on these devices as well
HMS -PACS.59 User shall be able to do post processing (ie. MPR & Volume Rendering) on
these devices. The standard orthogonal MPR shall be supported. User shall
be able to perform measurements, adjust brightness/contrast on these post
processed images. For VR, the color presets shall be supported.
HMS -PACS.60 Direct export of images to Microsoft Power Point for presentation
HMS -PACS.61 The PACS inbuilt viewer should work on both windows and MAC platform
HMS -PACS.62 Ability to identify Key Images and save them as a new series
HMS -PACS.63 Ability to export single image/series/study as standard image format ex.
JPEG/GIF/PNG etc
HMS -PACS.64 Ability to export the moving images (ex. Cath-Lab, Ultrasound) as AVI file
HMS -PACS.65 Ability to burn images into a CD
HMS -PACS.66 Ability to do Film Printing from the viewer. Viewer should support
configurable print layouts
Reporting module Features:
HMS -PACS.67 Report Template Support
HMS -PACS.68 MACROs support
HMS -PACS.69 Various image format support (ex. TXT, HTML, RTF etc)
HMS -PACS.70 Integration with MS-WORD to use microsoft word as reporting editor
HMS -PACS.71 Digital Signature Support
HMS -PACS.72 Ability to paste images in the reports
HMS -PACS.73 Reports should be saved as PDF
HMS -PACS.74 The Patient demographics should appear in all pages of the reports
HMS -PACS.75 Reports should display the page numbers
HMS -PACS.76 Ability to save reports as DICOM Images and it should be attached with the
scan
HMS -PACS.77 Ability to assign reporting privileges to Radiologists
HMS -PACS.78 Typist workflow support
HMS -PACS.79 Voice Recognition Support
HMS -PACS.80 Ability to email Reports to Physicians or Patients
HMS -PACS.81 Report Search Engine : Ability to search the reports on Keywords. The
search should not take more than 5 secs on 1M studies
Radiology Information System(RIS) Features
General Requirements
HMS -PACS.82 RIS shall support all the standard Modules ie. Patient Registration,
Appointment/Scheduling, Modality Worklist, Radiologist Worklist and Reporting
HMS -PACS.83 The system shall support scanning of hardcopy request forms and other documents
and attach with a patient
HMS -PACS.84 The system shall be integrated with HMS. It shall be bi-directional integration.
HMS -PACS.85 System shall support workflow for radiology orders which do not require
scheduling (ex. X-Rays)
HMS -PACS.86 The patient consent forms should be able to be scanned and attached into the system
HMS -PACS.87 The system shall have an ability to insert a flag for attention for an examination.
The flag shall be visible in all various worklists. The user typed comments shall
also be visible
HMS -PACS.88 The system shall support sticky notes function. The sticky notes shall open as popup
when a scan is opened.
HMS -PACS.89 The system shall provide instant messaging functionality for users to communicate
via system.
HMS -PACS.90 It should be possible to view the details of personnel involved with the Order ie.
who created the order, who scheduled/rescheduled it, scanning technician, draft
radiologists and final report signoff radiologist
HMS -PACS.91 RIS shall be integrated with EMR so that with a click radiologists can see other
details of the patient
HMS -PACS.92 System shall support the check for duplicate order and patient IDs
HMS -PACS.93 The system shall provide the section where all standard documents related to
operations, policies, standard forms can be uploaded and kept for users to access it
HMS -PACS.94 System shall support multiple department workflow where multiple department
users can work without being able to access other department data. For ex. Front
Office of one department shall not be able to schedule cases of other departments.
Cross department access shall be limited and shall be available only to limited users
HMS -PACS.95 System shall support setting up Master data from the Admin interface ex.
Procedures List, Reporting Templates
HMS -PACS.96 System shall support transfer of orders from one department to another
HMS -PACS.97 System shall support multiple user profiles which includes the following but not
limited to
o Junior Resident
o Senior Resident
o Radiologist
o Transcriptionist
o Radiographer
o Patient Service clerk & supervisor
o Radiology Nurse
o Administrator
HMS -PACS.98 The system shall allow to create user groups and assign users to groups. It should
allow to manage access rights both at group and individual user level.
HMS -PACS.99 The system shall allow to provision and manage Radiology Roster. The
HOD/Authorize User, should be able to define the roster and automatic case
assignment rules.
HMS -PACS.100 The system shall support Rostering for other users as well ie. Radiographers,
Transcriptionist etc.
HMS -PACS.101 Patient Registration
HMS -PACS.102 System shall be able to use the Hospital generated Registration Number (OP/IP)
HMS -PACS.103 System shall allow to mark Patient Arrival status in RIS
HMS -PACS.104 The system shall support Patient Merge workflow
HMS -PACS.105 System shall capture and display health alerts
HMS -PACS.106 Able to scan various consent forms ex. Request Form, Consent Forms, Pregnancy
Declaration forms etc
HMS -PACS.107 The document scanner shall be integrated with RIS
Handling of Imaging Service Requests (ISR)
HMS -PACS.108 Protocolling module: Allow the creation of a protocolling worklist for radiographers
or radiologists with options to select standard performing protocols and free text
field to document additional performing instructions to radiographers or
communications with clinicians that will be visible to the radiographer when
performing the study.
HMS -PACS.109 System should be able to audit and track protocolling workload per user.
HMS -PACS.110 Able to distribute tasklist to radiologist for vetting protocol and be able to update as
a completed status.
HMS -PACS.111 Support more than 1 level of vetting e.g. Radiographer or trainee performs vetting
and with option to send to Radiologist to verify.
HMS -PACS.112 Support more than 1 level of vetting e.g. Radiographer or trainee performs vetting
and with option to send to Radiologist to verify.
HMS -PACS.113 Support seamless paperless communication between clerk, radiologist and
radiographer during the vetting process.
HMS -PACS.114 Have a means to support rejection of requests sent for vetting.
HMS -PACS.115 Requested procedures or Imaging Requests that need clarification can be flagged
for follow-up from Request creation.
HMS -PACS.116 Urgent ISRs to trigger notifications eg SMS to appropriate personel as defined by
users.
HMS -PACS.117 List of Requested Procedures or ISRs
o Able to filter by Date/Time, Modality, Priority, Patient Type,
Medical Service, Referal Location, Patient Class
o Option to search for list of Requested Procedures or ISRs by Patient
ID, Patient Name, exam order ID
o Print out Porter Slip with information like Patient ID, Patient
Location
o Ability to sort list by different fields and select specific fields for
display
o Able to import and retain performing or reporting priority fields
from CPOE and recognise them as separate fields
o Able to print by location/time
o Able Export list.
HMS -PACS.118 Choice of giving an appointment or starting the procedure from the request list. For
example:
o For general x-rays, select ISR, generate bill and start procedure. No
need to book an appointment slot before starting the procedure.
o For specialised x-rays like CT or MRI, book appointment, indicate
arrival of the patient on appointment day, generate bill and continue
workflow.
HMS -PACS.119 Able to restrict cancellation of confirmed/performed orders to defined,configurable
users/group.
HMS -PACS.120 The system should support printing of Radiology Request orders created in RIS or
electronic radiology orders from EMR with relevant clinical and health information.
Appointment / Scheduling
HMS -PACS.121 Graphical representation of booking slots with comments and/or colour code
showing reservation of slots for different types of procedures, e.g., Neuro-
Radiology, Musculo-Radiology.
HMS -PACS.122 Able to define slots in a resource (room) based on certain contraints eg urgent cases
only, inpatient or outpatient. System should be able to use these constraints and
rules to faciliate giving an appointment.
HMS -PACS.123 Appointment diary to display available slots according to the procedure time. This
improves utility of resource and eliminates waste gaps in appt time slots. Visually
the schedulers can identify appt time slots readily.
HMS -PACS.124 Able to customise the number of booking slots available per day as duration of the
procedures varies for different types of examinations. The system should allow
reservation of appointment slots for specific procedures, by patient type (eg.
inpatient, outpatient), patient class, etc. This should be easily visible to assist users
in scheduling.
HMS -PACS.125 Able to "suggest" an appropriate appointment date/time for patient based on certain
rules and constraints, bypassing slots that do not meet the constraints for the patient.
HMS -PACS.126 System able to load balance the procedures booked in a particular modality over a
defined period eg. 1 week, respecting existing constraints or have a dashboard
which gives a quick view of the booking in each of the rooms or in the modality
over 1 week.
HMS -PACS.127 Ability to separate appointment resources by department and yet enable cross-
checking and alert if patients have the same exam/other already performed in
own/other department recently or already has an appointment made in different
department within a specified number of days.
HMS -PACS.128 Ability to auto-fax or auto-email appointment details to source of referral.
HMS -PACS.129 Able to check for duplicated procedures and/or procedure conflict and alert user
when an appointment is given.
HMS -PACS.130 Duplicate checking: The procedures to check against and the number of days
should be customizable at procedure level or modality level rather than be a system
wide setting that is the same for all procedures.
HMS -PACS.131 Alert for contra-indication such as “Cardiac pacemaker for MRI procedures”
HMS -PACS.132 Able to alert and prompt alternative appointments for multi-exam procedures
requiring more than one procedure rooms.
HMS -PACS.133 Able to define specific appointment slots for viewing and scheduling for certain
category of users. Able to restrict booking into certain appointment slots in the
scheduling book.
HMS -PACS.134 Able to easily reschedule an ISR without having to unscheduled.
HMS -PACS.135 Able to block and reserve slots with a patient identifier but without having to create
ISR by designated users or user groups. That identifier could be used as searchable
criteria in the scheduling system.
HMS -PACS.136 Able to control rights for overbooking to authorised users. Configurable in terms of
resource allowed to overbook, number of overbooking & types of procedures, etc.
HMS -PACS.137 Able to perform group transfer of appointments.
HMS -PACS.138 Able to easily close a few rooms for a certain defined periods or a particular date.
This could be done by user, without intervention by a system administrator.
HMS -PACS.139 Able to generate list of appointments affected (with patient details) when there are
ad-hoc closure of appointment rooms.
HMS -PACS.140 Able to generate a daily list of appointments by appointment room 1 working day
prior to procedure date. Able to export this list to Excel or other standard software
to be used in case of RIS downtime to arrive patients.
HMS -PACS.141 Able to input of comments (via a drop-down list) related to appointment making,
e.g. appointment date is requested by patient, etc with option to display the
comments online or extracted in report.
HMS -PACS.142 The system should allow for appointment labels and preparation instruction to be
printed for specific procedures.
HMS -PACS.143 Upon an appointment being scheduled for an inpatient, the system has an option to
automate sending of instruction to inpatient locations regarding procedure
preparation/appointment details/consent.
HMS -PACS.144 The systems should capture fees of procedures based on different patient paying
status so as to enable appropriate fees to be printed on labels or instruction sheet for
conselling of procedure cost to patient.
HMS -PACS.145 For inpatients’ appointment, the appointment module shall provide a portering
service schedule for porters to bring inpatients from the wards for examinations and
to send them back to the wards after the examinations.
HMS -PACS.146 Able to auto change appointment status into "No Show" on the the next day if
patients do not turn up for appointment.
HMS -PACS.147 Able to email or SMS reminder to the patient of an impending appointment in a pre-
defined timeframe.
HMS -PACS.148 Web-enabled appointment schedule book for external clients. This shall be
integrated with institute website if required in future
Patient Check-in And Order Creation
HMS -PACS.149 Able to setup new procedures in advance with effective dates.
HMS -PACS.150 Able to setup procedures which require different equipment resources e.g. CT
Arthrography (require both CT and fluoroscopy resources).
HMS -PACS.151 Support mapping of a specific procedure to different service code base on patient
type, referring location, facility, performing department, procedure code etc.
Example:
HMS -PACS.152 Able to assign unique numbers (accession and order numbers) to identify the
procedures and provide the link of results/ to images in PACS.
HMS -PACS.153 Orders created within RIS to be differentiated from orders originating from CPOE.
HMS -PACS.154 Able to capture and/or bill procedures such as surcharges, consultation, follow-up,
consumables, etc.
HMS -PACS.155 Able to trigger charge or credit transaction to billing system(s) upon order entry or
cancel or replace procedure respectively using HL7 protocol for communication
HMS -PACS.156 Able to apply price discount by referral location.
HMS -PACS.157 Able to capture the reasons for cancellation of procedures or no charge procedures
or waiver of professional fees for audit purpose.
HMS -PACS.158 Produce sticky labels with patient, visit, billing code and order related information
upon check-in or order entry:
o to show waiting/procedure room
o to display accession/order number for identifying procedures for
modality worklists and reporting
o to paste on film envelope for film tracking and despatching of films
to GP referrals, non-resident patients, clinics, etc.
HMS -PACS.159 System should have an easy way to do adhoc re-reprint of additional patient labels.
Examination Room
HMS -PACS.160 Filterable Worklist for scheduled/ordered procedures based on room, modality or
location eg waiting area. Able to configure fields and filters based on user
preference. The system has an option to save the user-defined worklist. Ability to
print and export list.
HMS -PACS.161 Be able to select multiple procedures from the worklist, and perform the same
operation in one instance eg start or complete procedure or assign reporting
radiologist.
HMS -PACS.162 Track procedure duration based on procedure start and complete times
HMS -PACS.163 Track radiographer(s) who performed the procedure. Able to easily add additional
operators.
HMS -PACS.164 Track radiologist(s) who performed the procedure.
HMS -PACS.165 Track other personnel involved in the procedure eg nurses, patient's care-giver.
HMS -PACS.166 Allow radiographers to enter technical comments for procedures performed to
capture examination information eg. Contrast usage, sequences performed,
sonographic findings.
HMS -PACS.167 Able to order/cancel/remove procedures. There should be a security object that
controls cancellation of procedures that have been started or have images or reports.
HMS -PACS.168 Exam status should include suspend and confirmed statuses or equivalent.
HMS -PACS.169 Able to trigger messages to EMR/HIS for order/cancel/remove of procedures when
applicable using HL7 protocol for communication
HMS -PACS.170 Able to route examinations for reporting based on user defined rules. Criteria
include: institution, equipment/group of equipment, imaging centre, individual
radiologist or group of radiologists, modality, types of procedures, patient payment
class, referring medical service.
HMS -PACS.171 System should be able to define and capture different work units for the same
procedure done in different rooms or for different patient type eg inpatient vs
outpatient.
HMS -PACS.172 MPPS from modality to RIS/PACS (including sequences) to plan examinations
based on protocol.
HMS -PACS.173 Reuse protocols from previous examinations when planning follow-up
examinations at the same modality and for the same organ.
HMS -PACS.174 To trigger a message to EMR/HIS upon examination started/completion.
HMS -PACS.175 To alert referring clinicians through email or SMS upon examination completion if
applicable.
HMS -PACS.176 To allow radiographer to group/link 2 or more procedures to be reported together.
Splitting of grouped procedures should also be possible prior to reporting.
HMS -PACS.177 Allow radiographers to update reporting priority.
HMS -PACS.178 The PACS to be able to support segmentation of studies. This is to enable the
radiologist to view the study in parts before completion especially for MRI and CT.
Reporting
HMS -PACS.179 Able to import patient history into the Radiology report.
HMS -PACS.180 An efficient way to assign a list of pending reporting tasks to a particular radiologist
to report.
HMS -PACS.181 Able to view at a glance outstanding reporting tasks based on each worklist eg. MRI
(2) ie. 2 MRIs not reported.
HMS -PACS.182 Reporting templates and canned text should have both public and private options.
Report templates and canned text should be keyboard and voice activated.
HMS -PACS.183 Standard word processing capabilities with spell checking function, formatting e.g
bold underline, italic and medical dictionary
HMS -PACS.184 Voice recognition should function together with all combinations of template and
canned text reporting using keyboard activation +/- voice activation.
HMS -PACS.185 Supports disease coding system if required by regulation (ICD-10)
HMS -PACS.186 Able to correct reports (alter original report text) after final/verified i.e remove
original content but with history of original versions kept (versioning).
HMS -PACS.187 Able to amend reports after finalised/verified as addendum i.e additional text on top
or bottom of original report but leaving the original report text untouched.
HMS -PACS.188 Allow specification and flagging of levels of abnormal reports
HMS -PACS.189 Allow radiologist to alert referring clinicians for abnormal and amended report i.e.,
either through email, SMS
HMS -PACS.190 Abnormal alert levels should be a "field" that can be filtered/sorted and used to
create report printing worklists.
HMS -PACS.191 Flexibility to control printing of preliminary and final reports.
HMS -PACS.192 Able to easily diifferentiate amended reports from original version in printouts.
HMS -PACS.193 The printed radiology report should have the time stamp of when the report was
printed.
HMS -PACS.194 Option to automatically utilise pre-defined fields of data captured in the acquisition
notes or technical comments (input by radiographer) to pre-populate to the
radiology report.
HMS -PACS.195 System should make it easy to assign and reassign cases for reporting within
specific user rules. System should have ability to set up proxy rights to enable
Radiologist A to finalise reports on behalf of Radiologist B (if the proxy rights are
given).
HMS -PACS.196 Cases reported by the resident should route to the radiologist's work-list for
verification regardless of mode of report creation.
HMS -PACS.197 Cases awaiting verification by the resident will auto-route to the radiologist's work-
list for verification after user specified time frame.
HMS -PACS.198 Radiologist's sign-out list should be able to view configurable fields incl. patient
name, examination, priority of examination,priority of reporting, report status,
reporting resident, patient type (ie. I, E, W), referring department etc.
HMS -PACS.199 Allow more than one radiologist to verify a report (co-read).
HMS -PACS.200 Alert/highlight unreported or unverified reports to respective radiologist as a pop-up
reminder on log in. After a user defined time, email or sms reminder to be sent.
HMS -PACS.201 Able to track both the reporting and verification radiologist and easily determine the
person that needs to verfiy the report or perform an action that will allow the report
to be finalized.
HMS-PACS.202 Able to print a verified radiology report with name(s) of reporting and verifying
radiologists, date/time of verification in a format acceptable to the institution. If
preliminary reports can be printed, specify if there are distinguishing factors that
differentiate it from a verified report eg a watermark.
HMS -PACS.203 Allow to print a verified report on an adhoc basis.
HMS -PACS.204 To allow option of auto-printing upon verification.
HMS -PACS.205 Able to distribute verified reports by automated faxing, sending of reports by email.
HMS -PACS.206 Reporting module should have a lock feature that prevents radiologist from starting
a report on an examination that has already been opened for reporting by another
radiologist regardless of screen refresh.
HMS -PACS.207 If reporting module supports viewing of more than 1 patient's images at a time, then
the module should have a warning feature that alerts the radiologist if starting to
report or saving / verifying a report for a procedure when another patient's images
are opened for viewing. eg. Patient 1 images and report editor are open for
reporting. Patient 2 images are opened for a quick review with clinician without
closing Patient 1 report editor and or images. Subseq. with patient 2 images still
open, radiologist wishes to Save or Verify patient 1 images, warning message
should appear.
HMS -PACS.208 Tightly integrated voice-recognition system:
o Proposed reporting solution should include Voice Recognition and
Digital Dictation Applications which should preferably be tightly
integrated as part of the GUI of the RIS solution.
o State if the VR has option to forward report and voice file to
transcription to allow correction of VR text by transcriptionists.
HMS -PACS.209 Ability to save personal voice profile into a transportable file after voice recognition
training and apply it to another institution using the same system. (Saving and
export of voice file).
HMS -PACS.210 Allow radiologist to indicate priority of dictated report to the transcriptionist.
HMS -PACS.211 Able to support structured and tabulated reporting and data mining.
HMS -PACS.212 Able to support addition of diagrams and images into the radiology report.
HMS -PACS.213 Able to support different ways of reporting e.g. manual dictation, digital dictation,
voice recognition & template reporting.
Recording Media Tracking
HMS -PACS.214 System should provide a way to track at the procedure level whether films or CDs
have been given to the patient or ward.
HMS -PACS.215 System should provide a way to charge for the films or CDs given to patient.
Inventory
HMS -PACS.216 To track the stock level of the procedure related items (e.g. contrast media, needles,
medication etc.) at the main store and sub-stores (certain procedure rooms). Basic
features of an inventory system must be present.
HMS -PACS.217 Module is integrated with the Examination Room Input module so that stock level
can be automatically adjusted according to the usage in the procedure rooms.
HMS -PACS.218 Track and calculate statistics of consumable used.
HMS -PACS.219 Able to set up procedures with default consumables (which may or may not be
billable) with default quantities. Both the default consumable and the default
quantity should be modifiable.
HMS -PACS.220 Able to charge for consumables used in radiology (during exam completion).
HMS -PACS.221 If the procedure is cancelled, must be able to credit the charges for the consumables.
HMS -PACS.222 Triggering a charge and usage of consumables should be independent of each other.
That is to say, we could waive charge for a consumable yet update inventory
quantity for used items.
HMS -PACS.223 Allow flexible entry of consumables at user-defined points in the workflow.
HMS -PACS.224 Able to change the quantity of a consummable (ad hoc)
Data-Analytics
HMS -PACS.225 The system shall support advanced data analytics tools based on Machine
Learning and Artificial Intelligence algorithms. Following are the few
analysis features that the system must support
HMS -PACS.226 When Radiologists finishes one Report, the system shall automatically finds
the cases where similar findings have been reported
HMS -PACS.227 The system (once trained) shall be able to identify the best matching node in
the Academics Folder directory
HMS -PACS.228 Big Data Support ie ability to export data to HADOOP cluster and analyze it.
Vendor Neutral Archive(VNA) Features
HMS -PACS.229 Scalable. The performance should not degrade as data size grows
HMS -PACS.230 The vendor shall provide user friendly access to usage statistics which
includes-- but is not limited to--storage and retrieval rate based on
institution, department, modality, and study description
HMS -PACS.231 System administrator tools must allow for patient and study merge
HMS -PACS.232 Tools should allow for changing any DICOM Attribute in the image header
and database
HMS -PACS.234 Query tools (SQL is acceptable) shall be provided to access the database for
any searches that are needed to locate “lost exams” and perform any analysis
(based on images stored) that an institution sees fit.
HMS -PACS.235 Changes in image headers should be able to propagate to all images in the
respective Exam, Series, Study, and Patient level
HMS -PACS.236 Storage and retrieval of Enhanced DICOM objects such as--but not limited
to-- the new multiframe MRI, CT, XA, and RF shall be supported
HMS -PACS.237 A complete list of all supported Image Storage SOP Classes shall be
provided
HMS -PACS.238 Changes in window width/level, zoom, and pan shall be stored and retrieved
as DICOM Presentation States
HMS -PACS.239 Overlays, such as those that contain measurements and notes, as well as
markers and shutters, shall be stored and retrieved as DICOM Presentation
States
HMS -PACS.240 Key images shall be stored and retrieved as DICOM Structured Reports
HMS -PACS.241 Structured reports--such as to store CAD and measurements--shall be able to
be stored and retrieved
HMS -PACS.242 A complete list of supported Non-Image DICOM SOP Classes shall be
provided
HMS -PACS.243 Query, storage, and retrieval of multimedia formats such as--but not limited
to--MPEG, JPEG, TIFF, .DOC, .TXT, .PDF, and .XML shall be supported
HMS -PACS.244 A complete list of supported file formats shall be provided
HMS -PACS.245 All DICOM Unique and Required Query Attributes shall be supported
HMS -PACS.246 A list of all optional DICOM Query keys for both Patient and Study Level
Query shall be provided
HMS -PACS.247 A SQL interface shall be provided that shall allow administrator access to
the institution's PACS to perform queries
HMS -PACS.248 The number of responses to a “wide-open query” shall be configurable
HMS -PACS.249 The device shall support WADO for retrieving images and related
information over a Web interface
HMS -PACS.250 Autorouting rules shall be configurable to include Institution, AE Title,
Station Name, Modality, Date and Time as well as referring Physician
HMS -PACS.251 Routing shall take place simultaneously to multiple destinations
HMS -PACS.252 Prefetching rules shall be based on HL7 transactions and be configurable to
include--as a minimum--Body Part, Modality, Institution, Study Date
HMS -PACS.253 The device shall support DICOM Storage Commitment as a SCU and SCP
HMS -PACS.254 The device shall support DICOM MPPS as a SCU and SCP
HMS -PACS.255 Vendor shall specify its tag morphing capability--whether it is static,
dynamic, bidirectional-- and a list of attributes and their values that can be
configured
HMS -PACS.256 Supported IHE Profiles: The device shall support the following profiles:
SWF: Scheduled Workflow for radiology
PIR: Patient Information Reconciliation for radiology
XDS-B: Cross-Enterprise Document Sharing
XDS-I: Cross-Enterprise Image Sharing
PIX/PDQ: Patient Identifier Exchange and Query
ATNA: Audit Trails Node Authentication
EUA: Authentication
HMS -PACS.257 VNA Should be Level IV
HMS -PACS.258 VNA Should support
Radiology images
Cardiology images
Pathology images
XDS documents
Other Dicom objects such as structured reports, Presentation States,
Key image notes and visible light images
Vessel analysis
HMS-PACS.259 Oncology workflow
Automated registration
Bone removal
OB measurements
Advanced PET/CT
PET / CT fusion
Optional third party integrate for orthopedic templating
stream line work flows with a standards based connectivity option to
external application .This includes the ability to launch products such as
Orthopedic templating and external RIS applications from PACS
Web reporting
HMS-PACS.260 Global reporting work list
HMS-PACS.261 Web deployed voice recognition
HMS-PACS.262 Multi-Site pass integration
HMS-PACS.263 Multi- Site report approval
Data Management:-
HMS-PACS.264 Information cycle Management
HMS-PACS.265 Quarantine Features
HMS-PACS.266 Rules workflow engine for creation, approval and audit of rules
1.14 Billing:
The Public healthcare services are provided free of cost to citizens. However there are
certain services which are billed also. For example OP tickets are given for a very nominal fee.
Pay wards have rental charges. The eHealth system shall have a billing module to manage the
billing and collection.
The system shall have the following facilities:
HMS-B&C.1 Patients
Search &
Select
The module shall have facility to search patients based on various
search criteria and display details based on the access rights.
HMS-B&C.2 Adding and
modifying
Charges
The system shall have facility to add new charges as well as
modify existing charges
HMS-B&C.3 Bill
Generation
The system shall generate bills
HMS-B&C.4 Payment
collection
The system shall have a collection interface to collect payments at
the cash counters through Cash / Credit Card / Debit Card / Cheque
HMS-B&C.5 Online
payment
The system shall have linkage with the State Governments
payment gateway to collect online payments.
HMS-B&C.6 Advance and
Part Payments
The system shall have facility to receive Advance and Part
payments.
HMS-B&C.7 Refund The system shall have facility to refund excess amount collected
HMS-B&C.8 Patient Dues
Report
The system shall generate Patient Dues Report
1.15 Queue Management System:
eHealth shall have a well defined Queue Management system. This consists of a Queue
Management Application and a Token Display system. The logic for queue management is
already described in previous sections while listing the requirements of various modules such as
OP Management, Lab management etc. The Application shall implement this logic and shall
interface with a standard Token Display system.
This will be an integrated solution of Token Display and Digital Signage. Digital Signage is a
system for disseminating information to intended audience. Any kind of contents viz, full
motion video, photo-realistic graphics, text, presentations, animated flash images and much
more. This is a dynamic scenario comparing to that of old conventional static boards, banners
etc.
The proposed system will take care of displaying the token numbers being allotted to
specific counters along with Digital signage for displaying various schemes and other
information such as Videos, Slides, Tickers etc. The token numbers along with counter numbers
will be displayed in a portion of LCD display. Video relating to various healthcare schemes and
other information will be displayed in the LCD screen along with the token numbers with the
help of a digital signage software. In this way, the public / patients waiting for their turn can
watch other useful information along with token numbers. This way the healthcare authorities
can convey any information relevant to public effectively using this media.
The HMS shall interface with a standard third party Digital Signage system and provide
the above functionalities.
The requirement of the Token Display system with Digital Signage Solution are
described below. Supply and maintenance of Token Display systems and LCD Displays are not
within the scope of this RfP
HMS-QMS.1 Queue
management
The queue management and token display will be handled
by the central eHealth Hospital Management System and
the token numbers generated will be displayed in the
respective portion of the LCD display unit. The system
will fetch the queue token data sent from the server at the
data centre and display it along with the media content at
the designated area of the TV screen. The screen layout of
the LCD display shall be configured as per requirement
with reference to the QMS and Signage application.
HMS-QMS.2 Digital
signage
solution
The digital signage solution also shall be centrally
managed and monitored. The server part of the Digital
signage Application will schedule the display and transfer
the digital contents along with the schedule for display to
the respective media players installed at the hospitals.
Using the Server module, media content for specific
department (Reception, General Medicine, Gynecology,
Pediatrics etc) shall be formatted and scheduled at the data
centre.
The content created at data centre shall be downloaded to
each player having specific IP address using the back bone
data network. The download process shall be automated
during off-peak time to reduce the network load. The
downloaded content shall have a play list and media files
which will be displayed on the TVs accordingly.
The displays installed will have connectivity to individual
media players. Each media player will have a client
version software. The client version of the Digital signage
Application installed in the local media players will
manage the display of the video and other digital contents
as per the pre-defined schedule in the LCD screen. As per
schedule, the contents will be fetched from the player and
will be displayed.
HMS-QMS.3 LED Token
Displays
In addition to the above facility, dedicated LED counter
token display units also shall also be provided in each
Hospital. These counter display units are to be installed in
the counters which are located away from the normal
patient waiting area. Departments like Labs, Pharmacy,
Radiology etc which may be in separate buildings can be
provided with these LED displays for showing the token
numbers. Transmitting token numbers to these counter
display units will be through the central Queue
Management System.
HMS-QMS.4 Ethernet
LAN
connectivity
and specific
IP addresses
Both the above displays shall have Ethernet LAN
connectivity and specific IP addresses. The token data
received from data centre specific to an IP address will be
displayed with an audio alert.
HMS-QMS.5 Solution
Components
The total solution consisting of the following:
Hardware (Not within the scope of the present RfP)
o LED TV Display system.
o Media player with storage facility.
o 4 digit Counter Display Unit (LED)
Software (To be integrated with the HMS)
o Media player Software (Client version at
the Hospitals)
o Server Signage Software.
HMS-QMS.6 Digital
Signage
Software
The Digital Signage Software shall have the following
features:
Provision for content management at data centre and
distribution of the same over network to various
players with TVs.
Provision for display of Queue Token Numbers along
with media files.
Provision for display of Token numbers in dedicated
LED displays.
Windows/Android based Software.
Screens can be divided into multiple zones and
multiple files can be played simultaneously.
Supports all media files (Video, Photos, PPS, PDF,
JPG, AVI, BMP etc).
Scheduling facility: Contents can be created in advance
and be scheduled for a later date & time. It will be
triggered at the pre-defined date & time automatically.
Connectivity to live TV channels available.
Content previewing facility available.
Supports different display sizes.
Support Landscape & Portrait modes of displays.
Different layouts can be created and can be saved as
templates for future design/use.
Built-in International Clocks in both analog and digital
format.
Text & tickers features. Supports regional languages
and RSS feeds.
Grid option to align files properly.
Audio can be enabled or disabled.
Each player can have discrete content, if required.
Screens interfaced with same Player will play uniform
content.
User privilege facility: Password protection and User-
right restrictions.
Log Report at any point of time
Administrator can know the status of each client at
any point of time.
Players can be monitored & controlled remotely.
1.16 Interoperability with Legacy Systems:
The system will be required to communicate with existing Legacy systems and
interchange data. This interoperability shall be implemented through SOA described above. The
Legacy systems which shall be linked with eHealth are listed below.
HMS-LS.1 Total
Automation
Solution for
KMSCL
(TASK)
The system shall exchange data with TASK seamlessly. TASK has
provision to transfer medicines and equipments to the level of stores
on the Hospitals. The stock received in the Store shall get
automatically updated in the eHealth Database and further
distribution to Pharmacies and Wards shall be through eHealth
System. Additional requirements of integration is described in
sections Asset Management and Maintenance Management’
HMS-LS.2 SPARK eHealth System may have a Unique ID for each employee. This
Unique ID for employee shall be mapped with the PEN number given
in SPARK. Similarly all the Institutions shall also be mapped with
that of SPARK. There shall be a facility to do this mapping in future
also when new employees join or when new Institutions are added.
HMS-LS.3 eTender Kerala Government has adopted the eTendering system of NIC for
procurement. The Purchase Orders released through this eTendering
system will have to be entered in the eHealth system for further
processing. eHealth system shall be designed to have this
compatibility and a future integration through web services or by
digital data interchange through standard file formats such as XML
or CSV.
HMS-LS.4 Treasury
system
The treasury system in Kerala is fully computerized. Many of the
cash collection in Health Department is through standard treasury
receipts. This will require printing of standard Treasury Receipts and
remitting of money at Treasury. All required forms and reports for
this cash transaction as per treasury rules will have to be generated by
the system.
HMS-LS.5 Drug
Controller
Application
eHealth system shall be capable of accepting data pertaining to
withdrawn/banned drugs directly or through manual entry from the
Drug Controllers portal. The information shall initiate a process to
stop distribution of all such drugs with immediate effect.
HMS-LS.6 Professional
statutory
Bodies:
Statutory bodies such as TC Medical Council, Nursing Council,
Pharmacy Council etc has a digital database of professionals who are
registered and are allowed to function in their respective fields in
Healthcare sector. eHealth system envisages a future enrollment of
Private sector in the framework. Hence there shall be a linkage to the
information on professional registrations so that professional practice
by unqualified persons are totally eliminated.
HMS-LS.7 Regional
Cancer
Centre
(RCC)
RCC has an independent computerized system. eHealth Database
shall be updated with the EMR from RCC. RCC Servers will upload
this EMR regularly to eHealth through web service. eHealth shall
have facility to carry out this uploading regularly..
HMS-LS.8 Insurance eHealth Application shall be able to provide data to various
Schemes: Insurance Schemes approved by the Government. Details of
Insurance Schemes is given in Section ……
HMS-LS.9 Other Health
Care
Schemes
eHealth shall provide data required by all Healthcare schemes
being implemented by State and Central Governments. An
indicative list of major schemes currently under implementation is
given below.
IDSP
MCTS
NCD Control
School Health
Blindness Control
RNTCP
Leprosy Control Programme
National Vector Borne Disease Control Programme
(NVBDCP)
There are several other schemes currently being implemented in the
Healthcare sector. The list of the schemes are provided in Section
...... 'As-is Scenario'
2 Web Portal
Objective :
The goal is to provide the citizen in general and Patients in particular a user friendly portal that
will make it easy for them to communicate with the Health Department through the web. This portal will
also act as a source of information for the citizen regarding policies and procedures. This in turn will
improve customer satisfaction and reduce work load on the employees. The portal shall also provide a
platform for forming a social network of Healthcare Professionals such as Doctors, Nurses, Lab
Technicians, Pharmacists etc.
Requirement
ID
Functionality Description
WP.1 Design of the
Portal
Web Pages shall be designed to render a logical and professional
layout for the Website enhancing the overall user experience. Uniform
look and feel is to be maintained across all pages of the website. Site
shall be well organized, information being available with minimal
number of clicks and navigation clear and consistent
WP.2 Content
Management
System
CMS for the Portal shall be configured with appropriate business flow
required to authenticate of publication of content in the site. CMS
must be easily manageable and authorised staff must be able to add,
change and delete Portal contents without manipulating any HTML or
scripting code as and when required
WP.3 Content
organisation
Contents shall be organised meaningfully in manageable units with
appropriate meta-tag/ labelling scheme. Visual elements are to be
appropriate and well organised
WP.4 Delivering
different
types of
contents
Capable of hosting and delivering different types of contents including
HTML documents, word documents, PDF documents, Images,
Photographs and Multimedia files.
WP.5 Plug-ins Plug-ins shall be embedded for opening and viewing various contents
including audios and videos.
WP.6 Floatable and
collapsible
menus
Floatable and collapsible menus and icons shall be effectively used to
enhance the content presentation.
WP.7 dynamic
generations
of links
The design should support the dynamic generations of links on the
page.
WP.8 No broken
links
There shall be no broken links (causing 404 Error) in the site, at any
given point of time.
WP.9 Search
Facility
The Portal shall be search enabled.
WP.10 Search
Engine
Optimization
Search Engine Optimisation shall be provided for the Portal with
respect to all major search engines such as Google, Bing, Yahoo, Alta
Vista etc
WP.11 CSS CSS based design approach and W3C compatible coding style shall be
used for developing the site.
WP.12 Browser
Compatibility
The site must be compatible with the current versions of Browsers -
Firefox, Internet Explorer, Safari, and Chrome.
WP.13 Mobile
Compatibility
The portal shall be mobile compatible rendering well on mobile and
tablet devices.
WP.14 GIGW
Compliance
The portal shall be compliant with the Guidelines for Indian
Government Websites (GIGW) as applicable.
WP.15 Visitor
Counter
The Portal shall have Visitor Counter.
WP.16 Event count-
down Clock
The Portal shall have Event count-down Clock for specific events such
as Pulse Polio vaccination etc.
WP.17 Online
contests,
quizzes and
polls
Portal shall have facility to host Online contests, quizzes and polls
related to the Healthcare to generate awareness and interest among the
public.
WP.18 ‘Home page’
for each
Healthcare
institution
The portal shall have a ‘home page’ for each Healthcare institution
with institution specific details such as List of Specialties and Doctors,
photo galleries, location map, Venue Maps, Contact numbers etc.
WP.19 publicity and
bulk outreach
programs
eHealth Portal shall also provide a platform for publicity and bulk
outreach programs. Communication tools such as bulk e-mails,
newsletters and SMS are to be integrated in the Portal.
WP.20 RSS feed Dynamic RSS feed facility shall be incorporated in the Portal.
WP.21 live feeds to
social
networking
sites
Portal shall render live feeds to Twitter, Facebook, other social
networking sites.
WP.22 Virtual
media
rooms
The Portal shall provide virtual media rooms from where media
can pull live updates, audio, video etc for publishing and
broadcasting.
WP.23 Hosting The Portal shall be hosted in Web Servers co-located in the
State Data Center.
WP.24 Service
Level
Average Response Time for all Web Pages shall be less than 4
seconds. The Agency shall be responsible for maintaining of
service levels and necessary hardware, software and
connectivity so as to achieve the service levels stipulated for the
Web Portal.
WP.25 Integration
with other
components
The Portal must be integrated with other components of the
eHealth Solution as applicable.
WP.26 Security Portal shall have security solutions for protection from hackers,
malware, Virus, Trojans, un-authorized access/intrusions and
other threats. STQC Security Audit of the Portal shall be
completed before hosting. Portal shall be accessible through
HTTPS protocol over SSL layer.
WP.27 Audit trail Audit trail of content updation of the site shall be maintained.
WP.28 Home This page provides a brief description about the site, the various
functionalities it provides and promotional features or any kind of
advertisement for special programs can be placed in this page. Login
Component is provided and registered users may login using their
username and password. New Users can also register by clicking
on the First Time Users Register link. The Forgot Password link
helps the user to retrieve their password.
WP.29 Log In The Log In page asks the registered users for their username and
password while the new members can also register through this
page.
WP.30 Registration Aadhaar Number may be made mandatory for registration
WP.31 Forgot
Password The user is asked for his first name, last name, zip code, birthday
and his primary email address before being provided with the
security question.
WP.32 Security
Question
Answer
The new password is sent to the user by email (his primary email
address as in his profile) on answering the question correctly.
WP.33 Change
Password Once the user has logged in, he can change his credentials i.e.
Username and Password by clicking on the Change Credentials
link
WP.34 My Page This is the landing page for the citizen. The screen contains a
description of the account Any status messages pertaining to the
account involving immediate user action is also presented here.
WP.35 Encounter/Ep
isode History
The page provides a line history of the encounters or episodes of
during a selected period. A more detailed view of each encounter
/episode may be provided on clicking each encounter/episode.
WP.36 Images User shall be able to open and view the stored X Rays etc, if any
WP.37 Lab Results User shall be able to open and view the stored Lab results etc
WP.38 Online
Appointments The system shall have options for Booking Appointments online. The
queuing logic for those booking appointments online will decided in
the system study.
WP.39 Book Pay
ward online Facility to book Pay ward online
WP.40 Online
payment
The user shall have multiple modes of online payment such as
Credit Card, Debit card, net banking etc. The online payment shall
be processed through secured payment gateways. e Health system
shall he integrated with payment systems like the IMPS
(Immediate Payment Service) of National Payment Corporation
of India. Reference on IMPS and National Payment Corporation
shall be done at http://www.npci.org.in/aboutimps.aspx
WP.41 Pay for
Services Facility to make Payments online for all the available services such as
Medical Certificates, Lab payment, Pharmacy, Pay ward etc
WP.45 Service
Requests This page allows user to post request for services such as house visit
by Health worker, enrollment in service schemes etc.
WP.46 Service
Request
Status
This is a read only screen which the user can view. Status of
various pending requests for the user are listed here.
WP.47 Complain Under this page user can log his complaint using a drop down
menu and also through key board entry.
WP.48 Complaint
Status This is a read only screen in which user can view the complaint
status.
WP.49 Report
Outbreaks etc This screen contains contact information to report Outbreaks etc
to authorities.
WP.50 Online
Reporting of
Outbreaks etc
This screen allows the user to report any incident which has
significance such as Outbreaks etc. The user has to fill up the
specific information provided in the screen in order to locate the
region/house etc.
WP.51 SMS facility ‘Push’ and ‘Pull’ SMS facility shall be integrated into the Web Portal.
Portal shall have the capability for forwarding SMS alerts both on
demand (pull) and on prescribed schedules (push) to both Healthcare
providers and Public. Interested parties shall be able to pull pertinent
information using simple and easy-to-use query formats. Portal shall
also support bulk information dissemination (Immunisation Schedules,
Disease prevention tips etc.) through SMS (push mechanism) to
registered numbers. Government of Kerala has a Mobile Service
Delivery Gateway (MSDG) which may be integrated to eHealth
for SMS Delivery.
WP.52 Update
Profile This screen enables the user to update his/her profile
information. The user can make changes to his email id, Mobile phone
number etc. changes.
Wp.53 Report
relocation
User can report relocation and change of address etc. The Health
worker will make on site verification and update the demographic
database.
WP.54 Healthcare
Information This screen displays the relevant Healthcare information for Public
view.
Wp.55 Associated
Sites
This screen provides the link to all Essential the associated sites
Wp.56 Contact Us This screen displays the information Vital of the contact persons,
who should be contacted for any information or for providing any
feedback
Wp.57 Business
Associates
This screen enables business Essential associates (contractors) to
register online, view tenders, purchase tenders, etc
WP.59 Medical
Reimburseme
nt
Administrative user shall have privilege to update database on Drugs,
Lab Test and Clinical Procedure eligible for reimbursement
WP.60 Medical
Reimburseme
nt
There shall be an interface to check whether a Medicine/Lab
Test/Clinical Procedure is reimbursable by Public sector employers
WP.61 Medical
Reimburseme
nt
Government Departments and PSUs shall have accounts to post the
claims of employees and get recommendation from DHS regarding
admissibility of claims
3 Public Health Monitoring System
3.1 Introduction:
The Public Health Monitoring System has six distinct functionalities.
1. Create and Maintain a Digital Family Health Register
2. Reproductive and Child Health (RCH) Monitoring
3. Integrated Disease Surveillance Programme (IDSP).
4. Non Communicable diseases program
5. Provide Data to all the centrally sponsored Public Health Schemes
6. Intersectoral Coordination with other agencies
Family Health Register:- The State Health Department is maintaining a Family Health Register
which provides comprehensive information about the households in the state. This register
contains Village level details, House Details and Demographic Details. The first task is to
digitize this Family Health Register and then keep it updated. Once created, the eHealth system
should keep the register constantly updated.
RCH Monitoring:- The functionalities covered under the RCH head include Ante natal Care,
Post partum Care, Mother and Child tracking, Immunisation Monitoring etc.
IDSP:- Non Communicable and Communicable Disease Control is the main objective of IDSP.
The Multipurpose Health Workers go out to the community for early detection of potential high-
risk individuals and offer secondary preventive options. Detection of malaria cases by blood
smear examination, pulmonary tuberculosis by sputum AFB examination, diabetes and high
blood pressure screening, immunizations, etc are examples of this category of services.
Intersectoral coordination with other agencies
In the above measures, individuals or families are the targets. But certain aspects need concerted
action from the community, as these interventions are beyond the scope of individuals or family.
Air pollution, provision of safe drinking water, vector control, etc are examples of this kind of
activities. The Multipurpose Health Workers need to keep track of such public health
interventions also in the eHealth platform.
Public Healthcare Schemes:- Central and State Governments have initiated several schemes with
the aim of improving Public Health. Some of these Central schemes are monitored using a
centrallised digital frame work. State Governments shall provide data to these digital frameworks
at defined intervals. eHealth system shall provide data to these Central systems. eHealth shall
also generate reports on these schemes for both State and Central governments.
The Health Department has a well structured network of field workers and supervisory staff and
Officers to handle the Public Health Functionalities. Providing the technical infrastructure,
training and necessary hand holding for efficiently carrying out these tasks will be the
responsibility of the Agency.
The IT infrastructure for the Public Health Monitoring Functionality include the following:
1. Central Database and Central Application to manage the Public Health related functionalities
2. A Hand Held Device (HHD) with a user friendly Application to carry out the field activities.
As described earlier the basic reporting for Public Health Monitoring is primarily done by the
Multi Purpose Health workers and their supervisory staff. This functionality is to be carried out
using a Hand held devise which should have the required database and Software Application
installed in it. The database in each device will pertain to the population each Multi Purpose
Health worker is responsible for. The Application shall facilitate data collection and generation
of reports offline. The Multi Purpose Health workers shall also be able to access the Central
eHealth Database and Application, view and print the reports according to their access rights.
The details of training and hand holding support to be provided by the Agency is described
elsewhere. The following descriptions relate to the requirements of the Public Health Monitoring
Functionality with respect to the Hand Held Device (HHD) and the Central Application.
All the functionalities described below shall be available in all types gadgets used such as Hand
Held Devices, Tablets, Netbooks, Laptops and PCs. Some requirements are specific to the
central Application and hence need not be available in the Hand Held Device Application. These
requirements separately described.
3.2 General Requirements of the Hand Held Device Application
HHD.GR.1 Online
synchronization of
data
There shall be facility for real-time online synchronization of data
between HHD and central server. If this is not happening due to lack
of connectivity there shall be facility for this data to be uploaded to the
central server when connectivity becomes available. This shall help in
the prompt reporting of possible outbreaks of infectious diseases (the S
form of IDSP project) and in the follow-up of Non-Communicable
Diseases. This also avoids risk for data loss as hand held devices may
be lost, stolen or infected with viruses or worms. This also keeps
health data in centralized health information repository up-to-date.
Thus the data entered into the handheld device from survey fields by
health workers becomes part of a centralized health information
database, which can be accessed from anywhere.
HHD.GR.2 Updating the
Hand Held Device
(HHD)
The central system shall update the Database and Application residing
in the HHD periodically or on request. This will ensure that the HHD
is updated as follows:
1. Any data directly entered into Central database through Web
based HMIS application
2. Data entered into Central database through other HHDs
3. Changes to master Data such as Ward Changes, New Taluks etc
4. Changes to the HHD Application (Version Control)
HHD.GR.3 HHD as a portable
office
Thus the HHD will act as a portable office for the field level workers.
HHD will have updated socio-demographic data of around 5000
population (within the area of the workers jurisdiction). If any of these
individuals avails hospital, or laboratory services, then the relevant
details of discharge/results summary with clear instructions for follow
up shall get updated in the HHD.
3.3 Mobile Device Management - Requirements
The Solution should provide Secure corporate data at rest and in-transit across all supported devices the
Solution should support Application and Corporate/Organization Policy Provisioning. The Solution
should be able to easily promote, deploy, configure, distribute & update apps over the air (OTA) via a
custom/enterprise apps store. The proposed Solution should be able to provide visibility and control of
telecom costs using real-time telecom expense management analytics, reports and dashboards
HHD-MDM.1 Wipe and lock The solution should support Wipe and lock corporate/work data
remotely
HHD-MDM.2 Removal of
corporate apps
The solution should be able to remove corporate apps only leaving
personal data / apps alone
HHD-MDM.3 Control device
lock/unlock
states
The proposed solution must be able to control device lock/unlock
states
HHD-MDM.4 Manage SIM
Lock status
The proposed solution must be able to manage SIM Lock status
HHD-MDM.5 Automatically
SIM Lock
The proposed solution must be able to automatically lock the device
if SIM is changed
HHD-MDM.6 Configurable
password
policy
The proposed solution must have an easily configurable password
policy that can be set on the managed devices
HHD-MDM.7 Remote device
wipe
The proposed solution must be able to carry out remote device wipe
HHD-MDM.8 Selective wipe The proposed solution must be also be able to carry out a selective
wipe of the device data remotely
HHD-MDM.9 Camera Lock The proposed solution must be able to lock/unlock the camera using
GUI based policies
HHD-MDM.10 Configurable
wizard-driven
policies
The proposed solution must be able to define intuitive and user
configurable wizard-driven policies to achieve the following
functionalities:
1. Internet Browser lock for Open standard devices
2. Lock/Unlock USBs for Open standard devices
3. Block SMS for Open standard devices
4. Push Applications onto the device as per policy
5. Push Documents onto the device as per policy
6. Block documents leak from SD card
7. Block GPRS based on OS configuration capabilities
8. Block and Blacklist Applications
9. Block App Store Access / Downloads
HHD-MDM.11 Remote control The proposed solution must be able to take remote control of the
mobile devices for support activities from a central management
location.
HHD-MDM.12 Security
Requirements
1. The proposed solution must support Application
Containerization for application pay load
2. The proposed solution must support create enterprise data
partition based on OS vendor
3. The proposed solution must support enterprise-based App
stores
HHD-MDM.13 Device
Notifications
The proposed solution must be able at least provide the following
notifications from devices controlled by a wizard-based and GUI-
driven policy editor:
- Data usage
- Voice and SMS
HHD-MDM.14 Mobile
Operating
Systems
The proposed mobility management solution must be compatible
with the Open Standard Mobile Operating Systems
HHD-MDM.15 Integration
with mailing
solutions
The proposed solution must be compatible and integrate with Open
Standard mailing solutions.
HHD-MDM.15 Data Security The offline healthcare data being stored in the mobile devices
are sensitive and shall be as safe and secure as that in the
central server. Hence security standards same as those in the
centralized Database system shall be adopted for mobile
devices as well.
3.4 Centralised Digital Family Health Register (FHR)
Health Department is maintaining a Family Health Register in all Sub Centres. It has all relevant
data about all citizens in the area. The register also has information about all public places in that
region. This data is used for planning and monitoring public health activities in that region. A
major task in eHealth project is the creation of a Digital Family Health Register.
The Digital Family Health Register shall uniquely identify each citizen residing in the State.
Such a Unique identity for each citizen is the primary requirement of implementation of eHealth
Project. This will ensure that all healthcare Data pertaining to a citizen will be linked together
based on this Unique Identity.
Aadhaar registrations in the State are substantial. By the time the project is ready for
implementation a large majority of the citizens in the state would have registered with UIDAI.
So it is proposed to use Aadhaar as the Unique ID where ever it is available. In cases Aadhaar is
not available the system will generate a Unique ID which can be used to link the Medical records
of citizens.
Several databases with citizen data already exist in the state. These are created by individual
departments with the limited purpose of providing services related to that department. These are
disparate systems existing in the servers of the respective departments. Each of these databases
has a unique ID to distinguish the citizen within their realm of activities. A few examples are
given below:
Database Department Unique ID Remarks
PDS Database Department
Civil Supplies
Ration Card
Number
The Ration Card Number
concatenated with the serial number
can uniquely identify a Person who is
included in the PDS database
LSG Database IKM House ID
IKM is providing a unique House ID
to each House so the frequent change
of house numbers do not affect data
integrity
Driving License
Database MVD
Driving License
No
Consumer
Database KSEB
Consumer
Number
Nearly 100% houses are electrified
and the consumer number can link to
the House number
Health Department carries out a Family Health Survey and a Village Survey every year. Next
Survey will be carried out with the help of Hand Held Devices and will have a unique objective
of creating a centraslised Digital Family Health Register to be used by eHealth System
subsequently. This massive survey undertaken by Health Department may be done with close co-
ordination with several other departments which have databases of citizen data. The objectives of
the survey are:
1. Link this data to the Aadhaar ID
2. Create a new ID to be used in the eHealth database in case Aadhaar is not available.
3. Insert the Unique IDs relating to Citizens in the existing databases of different departments in
the Digital Family Health Register so that citizens can refer any of these IDs to identify them.
Only this Unique ID from these database will be inserted in to the Digital Family Health
Register. No other data from these databases of other departments are required in this Digital
Family Health Register except the BPL status in case of PDS database. Some of such
Unique IDs relating to citizens are:
Ration Card Number and BPL status from PDS database
House number from LSG database
Driving License Number from MVD database
Consumer Number from KSEB database
4. Import the relevant fields from Socio-economic census Data to complete the missing data in
the Digital Family Health Register
5. Complete the database by entering the missing Data such as Mobile Number, relationship
among the members of a house hold etc.
PH.FHR.1 Data Refining
prior to
Survey
(Central
Application
alone)
The eHealth system shall have facility to carry out the following as a
prelude to the Family Survey:
1. Carry out a de-duplication of data in the respective individual
databases mentioned above
2. Do a data refining by eliminating junk data
3. Suggest logical linkages of unique IDs of the same person in
different databases
4. The Data as available from the existing databases may also be
hosted in a web site with access rights for citizen to view their
personal data. They may also be given rights to add additional
information to their personal data. This data can then be further
verified by the field staff during their field visits.
PH.FHR.2 Download to
Hand Held
Device
All the available data pertaining to the region being surveyed on a
given day shall be downloaded to Hand Held Device along with the
probable linkages of unique IDs of the same person in different
databases.
PH.FHR.3 Survey
Process
All the available data pertaining to the region being surveyed on a
given day will be downloaded to Hand Held Device along with the
probable linkages of unique IDs of the same person in different
databases. The Application shall have facility to pick any one base
data depending on the situation and then link with other available
data to create a linked database where all the above parameters of
citizen is linked with each other. The missing data is to be collected.
After locating the person in any one of the existing database the
surveyor shall carry out the following data refining process:
1. Link the person's Unique ID in a database with corresponding
IDs in other databases if existing. For example if a person has
Aadhaar, then pick his id from the following:
a. Socio-economic census Database
b. Ration Card No from the database of PDS
c. Driving License No from the Database of MVD
d. House number of the residence from the LSG
Database
e. Consumer Number of the residence from KSEB
Database
2. Then the surveyor has to collect and the remaining data that is
not available in the selected databases.
PH.FHR.4 Basic
information
identification
Data
The Application shall have facility to capture and edit the following
basic data pertaining to each individual:
1. Name
2. Date of Birth, option for age
3. Gender
4. Aadhaar number
5. Father’s Name
6. Mother’s Name
7. Spouse name
8. Place of Birth
9. House Address of the present residence if different
10. Domicile Type
11. Blood group
12. Religion
13. Caste
14. Marital Status
15. Differently-abled /Disabilities
16. Ration Card No
17. Driving License Number
18. Land Line Number
19. Mobile Number
20. RSBY and other insurance schemes
PH.FHR.5 Factors
affecting
demographic
indexes
The module also include provisions to identify and record factors
affecting demographic indexes such as individuals’ educational,
economic, and health status.
1. Physical Condition like disability
2. Major health issues –h/o diabetes, hypertension, CAD,
epilepsy, mental ailments, COPD etc
3. Education
4. Occupation
5. Habits
Vegetarian
Smoking
Pan chewing/other substances
Consumes more than specified quantity of alcohol
PH.FHR.6 Family
Database
The system shall have facility to group members of the Family
together and denote the Head of Family and relationship of each
member to the Head of the Family. The following data are collected:
Family
o Head of family
o UID
o House Number
o House ownership
o Annual Income – APL/BPL
Family Members
o Name
o Relationship
o UID
PH.FHR.7 House Data
Collection
A portion of the data required for this survey may already available in the
database created through triangulation explained earlier. The data collected
or updated through this interface include:
House Details:
• House No, Name
• Place and PIN code
• Unique House No.
• House Type : thatched, terrace, apartments, etc
• Electrified or Not
• Latrine Type
• Drinking water Source & Storage
• Waste disposal details- pipe compost, biogas plant, soakage
pits etc
• Geo-cordinates-longitude, latitude, elevation, etc
• Type of houses : own/rented etc
• Nearest landmark
PH.FHR.8 Ward
Reconstitution
When Local Bodies do a re-configuration of wards the house number
changes. This change shall be updated in the eHealth Database also. There
shall be a module to handle changes arising from ward reconstitution by
Local Bodies.
New Ward Number
New House Number allotted after a ward change
PH.FHR.9 Changes to
Demographic
Data
The core components of demographic change – birth, death and migrations
in and out – are handled in this module. This module comprises of four sub
modules:
Birth Registration
Death Registration
Migration Registration
Data pertaining to Births and Deaths taking place in Hospitals covered
under eHealth are available in the Central database. During the regular
synchronization process this data shall get updated in the HHD. Births and
Deaths occurring outside the Hospitals covered under eHealth are to be
captured.
The regular synchronization process shall update the Central database with
data captured on Birth, Death and Migration.
PH.FHR.10 Birth
Registration:
The Application shall have a Birth Registration module to capture and store
data on births occurring in each family. The data accumulated through this
interface include
Name of Mother
UID
Date and Place of Birth
Type of Delivery
Any other relevant details
The data from this module is used to get a sub-centre level month wise
reports on Birth
PH.FHR.11 Death
Registration
The Application shall have a Death Registration module to capture and
store data on deaths occurring in each family. The data accumulated
through this interface include
Name of deceased person
UID
Date and Place of Death
Cause of death as reported by medical officer
Duration and Status of diseases at the time of death
Death Report details
The data from this module is used to get a sub-centre level month wise
reports on Death including Maternal Death
PH.FHR.12 Migration
Registration
The persons who are living in a province other than that of birth for more
than 6 months due to employment, marriage or any other socio-economic
factors is considered as migrated. Data on migrations within wards and
outside wards are handled through the Migration Registration module. The
data collected through this module interface include
Name of person migrated
Date and Cause of migration
Data on ward and house to which person migrated
When a family moves out of the Village this can be marked as ‘Moved Out’
and when the Field worker in the destination Village can attach them to a
house in the new Village.
PH.FHR.13 Village Survey The purpose of Village Survey Module is to collect relevant economic,
social, cultural and educational data about villages. It records data about the
availability of various civic facilities including the supply of water, schools,
health care, shops, offices, temples, Geo-cordinates-longitude, latitude,
elevation of each building/spot of interest etc in a village. The data
collected during village survey include details such as
Educational Institutions
Organizations such as MSS units, Kudumbasree
Public Places such as Libraries, Theatres, Community Halls,
Markets …
Government / Non Government Offices
Worship places
Hospitals (clinics also)
Water Sources
Business Centres
Cattle sheds
The data available in the Socio-economic census Database can be
imported, verified and refined.
3.5 RCH Monitoring:
The requirements of the RCH Monitoring Application described below:
PH.RCH.1 Reproductive
Health and
Family Planning
The module focuses on the family planning services provided to
couples and has three sub modules:
Eligible Couple Registration
Family Planning Registration
Family Planning Follow-up
This module shall generate reports such as:
Eligible Couple Register
Target Couple register
Family Welfare Acceptance Register
PH.RCH.2 Eligible Couple
Registration
The Eligible Couple (EC) Registration module identifies and
records some basic data pertaining to eligible couples in each
family. The term Eligible Couples targets couples who are
eligible for receiving any type of family planning services. The
basic data collected include name of couples and their marriage
date. With this interface, one can enter data on new registration,
edit data on existing registration or view registration details. The
registration shall normally be based on UID or a Unique Health Id
(UHID). The UHID is a unique identifier created in eHealth
Database to take care of situations where the citizen do not have
UID (Aadhaar)
Inputs
Name of Wife (Select name of the person)
Age of Wife
Name of Husband (Select name of the person)
Age of Husband
Survey Date
Marriage Date
Remarks
PH.RCH.3 Family Planning
Registration -
Target Couple
details
Family Planning Registration module is used to enter the details
of the couples who have accepted any kind of family planning
methods. The family planning methods are categorized as two
types Permanent and Temporary methods. The system itself
maintains a list of family planning methods and the health worker
is required to only select the required method. The interface also
facilitates entry of data on institution, if the person visited an
institution for accepting the method. In addition to the above, the
system will also seek data on any complications suffered by the
method acceptor.
Inputs
Name
Survey Date
FW Acceptance Date
FW Acceptance Method
a. Spacing method
Condom
IUDs (Copper T)
Epills
Oral pills
Hormonal Implants
b.Terminal Methods
PPS
Laparoscopic Sterilization
Minilap Sterilization
NSV
c.Others
Hystrectomy
Institution Category
a. Government
b. Private
Remarks
PH.RCH.4 Family Planning
Follow-up
Once a family planning method is accepted by a couple, it has to
be followed up by the health workers on a routine basis. The data
on each follow up visit is entered through the module Family
Welfare Follow-up. The data collected for follow-up include
whether there were any complications since method was accepted
and whether the method was discontinued.
PH.RCH.5
Family Planning
Follow-up - Data
entry
Family Planning Registration & Follow-up module facilitates
entry of data on
Family Planning Method Accepted
The Institution visited for method acceptance
Date of accepatance
Complications, if any suffered by the method acceptor
PH.RCH.6 Family Planning
Follow-up -
Inputs
Name
Visit No
Visit Date
Previous Visit Date
Complication
Failure
Recanalization
Sepsis
Death
Bleeding
Pain
Expulsion
Infection
Migraine
Vomiting
Allergy
Complication Date
Discontinue Date
Discontinue Reason
Recovered
Continuing with Treatment
Dead
Transferred out
Remarks
PH.RCH.7 Maternity
Module
Maternal care includes care during pregnancy, delivery and
immediately following delivery, along with the care of the new
born. Women can get maternal care services either by visiting a
health center where such services are available or from health
workers during their domiciliary visits. One of the most important
components of antenatal care is to offer information and advice to
women about pregnancy-related complications and possible
curative measures for the early detection and management of
complications
The health workers collect details of the services given to
pregnant women and new born child using HHD. The maternity
module involves the Antenatal Care module coupled with
Postnatal Care module.
PH.RCH.8 Antenatal Care
Module
Ultimate goal of Ante Natal Care module is to reduce Maternal &
Infant Mortality. This module comprises of the following
components
Antenatal care Registration
Antenatal care Follow-up
Antenatal care Termination
PH.RCH.9 Antenatal care
Registration -
Inputs
Name
Survey Date
Name of Husband
Order of Pregnancy (Gravida)
No. of Living Children
No.of Abortions
Type of previous delivery- Normal/LSCS
Date of Last Menstrual Period (LMP)
Expected Date of Delivery (EDC)
Trimester (The system to automatically calculate the Trimester)
Remarks
PH.RCH.10 Antenatal care
Follow-up-
Inputs
Name
Survey Date
Name of Husband (System to display the name)
Height
Weight
Blood Pressure
Blood group
Blood HB
Height of Uterus
Result of Urine Test
o Albumin
o Sugar
o Deposits-Pus Cells
o Deposits-RBC
o Deposits-Others
Danger Signal
o Bleeding
o Oedema face/legs
o Viral Infection
o Others
Quantity of folic acid given
Quantity of IFA given in 1st TM(Quantity of IFA tablets
recommended for the pregnant woman)
Quantity of IFA given in 2nd
TM
Quantity of IFA given in 3rd
TM
Quantity of calcium tablets given
Inj.TT 1st dose- date
Inj.TT 2nd
dose- date
Complications “Abnormal movement of baby”
o Anemia
o APH
o BP above 140
o Epilepsy
o Heart disease
o Diabetesmelitus
o Hypertension
o Pregnancy <20y or >30y
o Previous Caesarean
o Weight increase more than 3 Kg/month
o Short stature
o Grantmultiparity
o Others
Referred Institution Category
o PHC
o CHC
o THQH etc
Referred Institution Name
Remarks
PH.RCH.11
Antenatal care
Termination -
Inputs:
Name
Survey Date
Name of Husband
Delivery:
Delivery Date
Delivery outcome
Baby- Alive
Still Birth
Delivery Type
Normal
Forceps
Vacuum
LSCS
Attended by
Specialist doctor
Doctor
ANM/LHV
Trained/skilled birth Attendant
Untrained birth Attendant
Complication
Rupture
PPH
Sepsis
Post partum psychosis
Etc
Termination type
Abortion: induced/spontaneous;
If Termination type is legal/illegal
If Termination type is MTP
Type
Abortion- 1st Trimester/2
nd TM
Date of Abortion/MTP-
Place/institution where abortion done-
Reason
Medical
Eugenic
Humanitarian
Socio-economic
Others
Person done- Specialist/MBBS Doctor/Health worker
Patient Status
Alive
Dead
Complication
Rupture/Tear in Uterus
Bleeding
Sepsis
Remarks
PH.RCH.12 Postnatal Care
Module
The postnatal period (or called postpartum, if in reference to the
mother only) is defined by the period beginning one hour after
the delivery of the placenta and continuing until six weeks (42
days) after the birth of an infant. Care during this period is critical
for the health and survival of both the mother and the newborn.
This module records Post Partum Care details such as PPC
methods and PPC given Date etc.
Inputs
Name
Survey Date
Postpartum Care Date
Name of Husband
Type of Termination
Date of Termination
Mother Complication
Fever
Abnormal Bleeding
Lochia-Foul Smelling
Abdominal Pain
Abnormal Behavior
Painful and Swollen legs
Painful Breast
Child Complication
Refusal of Feeds
Increased Drowsiness
Cold to Touch
Difficulty in breathing
Rapid Breathing
Abdominal Distension
Convulsion or Stiffness
Incessant cry
Persistent Vomiting
Deep Jaundice
Remarks
PH.RCH.13 Child Care
Module
The Child Care Module is for recording data about individual
children, for scheduling appointments for their immunization and
for producing aggregated statistical information.
This module comprises of the following components:
Child Registration.
This is done through Birth Registration process in the
Demographic Module. The module will collect following
data about an infant:
Child birth information (Birth Date, weight, Condition
up to 28 days etc).
Risk factors, Abscesses, Complications.
Immunization
Scheduled and optional Immunization details
(immunization name and Date).
Immunization Alerts
The software shall generate Immunization reports such as
Lists the names of the Infants due for
immunization services for the next 30 days.
Immunization services due against each Infant.
PH.RCH.14 Child Care
Module - Inputs
Name
Date of birth
Survey Date
Immunization Name Scheduled:
“BCG”
“OPV-0”
“Hepatitis-B1”
“OPV-1”
“DPT-1”/penta
“Hepatitis-B2”
“OPV-2”
“DPT-2”/penta
“Hepatitis-B3”
“OPV-3”
“DPT-3”/penta
“Measles”-1
“Vitamin-A1”
“OPV-Booster-1”
“DPT-Booster-1”
Measles”- Booster(1.5 Yrs)
“Vitamin-A2”
“Vitamin-A3”
“Vitamin-A4”
“Vitamin-A5”
“Vitamin-A6”
“Vitamin-A7”
“Vitamin-A8”
“OPV-Booster-2”
“DT/DPT-Booster”
“Vitamin-A9”
“TT Dose (10 year)”
“TT Dose (16 year)”
Immunization Name - Optional:
“HIB-1”
“HIB-2”
“HIB-3”
“HIB-Booster”
“Vericella”
“MMR”
“Hepatitis-A (Dose 1)”
“Hepatitis-A (Dose 2)”
“Rubella”
Immunization Date
Immunization taken from Outside (Yes/No)
AEFI
Abscesses
Respiratory Tract
Skin
Urinary Tract
Other Complications
Fever
Inflammation
Others
Redness
Swelling
Remarks
PH.RCH.15 Child care
Module -
Reports
1. Immunization due date list
2. Unimmunized/drop out list
3. Reasons for not getting immunized
4. Universal Immunization Programme (UIP) CARD
5. Complication Reporting - Adverse Events Following
Immunization (AEFI) format to be used
6. IMNCI Components
3.6 Disease Monitoring Module
A cadre of trained field workers equipped with HHD Application, Standardized practices and
procedures, timely alerts, quick response coupled with service on a 24*7 basis will ensure a
very effective Disease Surveillance mechanism in the State. eHealth shall leverage the existing
framework into an effective Disease Surveillance Network in the state. The requirements are
described below:
This Application Module in the hand held device is to be used for recording of any kind of
communicable /non communicable diseases. The data will be collected by the Multi Purpose
Health Workers and regularly uploaded to the Central eHealth server.
The Central eHealth server also receives data from various sources viz. Hospital OPD, IPD and
Laboratories. The central IDSP Module shall keep track of incidence of diseases based these
several sources of data and give alerts in case the number of incidences of diseases cross the pre-
defined limits and qualify to be notified as alarming stage. The purpose is tracking incidence of
diseases, the detection and control of diseases through regular and timely reporting, ensuring
prompt treatment, planning & monitoring preventive and remedial measures.
Following are the purposes of Disease monitoring module:
Tracking incidence of diseases through surveillance
Early detection and control of diseases through regular and timely reporting
Ensuring prompt and complete treatment
Planning & Monitoring preventive and control measures
Help to conduct awareness programmes(IEC/BCC) and to give prevention
advices
The following is the description of requirements of the Application Module for Disease tracking
to be to be used by the Multi Purpose Health Workers.
PH-IDSP.1 Real-time
Data
collection:
Real-time data on reporting of Communicable diseases from
Sub Centres, OP Clinics, IP Wards and Clinical Laboratories
shall be transmitted to the central server at very frequent
intervals. Data from Sub Centres captured using the HHD
Application shall be transmitted at a pre-defined interval. Data
from OP Clinics across the State will also be transmitted
frequently. The central system will aggregate this data and will
constantly evaluate the situation based on an intelligent
algorithm to detect any abnormal increase of incidence of
diseases.
PH-IDSP.2 Disease
Monitoring
using HHD
The Disease monitoring module in the HHD Mobile
Application collects communicable and non communicable
disease details. This module shall keep record of the people
affected with any kind of communicable /non communicable
disease.
PH-IDSP.3 Private
Institutions
In the present scenario reporting of diseases from Private
Institutions is very low. In the new system there will be a web
interface for each private institution to report the data on
diseases regularly. This will make the system complete and
accurate.
PH-IDSP.4 Central
Government
IDSP
framework
The system shall send aggregate reports in the prescribed
formats weekly to the Central Government IDSP framework.
PH-IDSP.5 Healthcare
notification
messaging
service
The eHealth System shall have facility to automatically send
out alerts in the form of SMSs, emails etc to all the concerned
authorities. In addition there will be general Healthcare
messages such as precautions during an outbreak etc.
There is also facility to send out SMS to the concerned person
regarding clinical test results and sensitive reports on
communicable diseases.
PH-IDSP.6 Receiving
Messages
The system shall be able to accept SOS SMSs from individuals
and make it available to the concerned authorities. There shall
be facility for public users to text a particular keyword to
receive information on a range of topics such as H1N1 fever
symptoms.
PH-IDSP.7 Sub Modules This module has been divided into following sections:
Disease Registration (Suspected Case and Confirmed
Case).
Disease Follow-up.
PH-IDSP.8 Disease
Registration
- Suspected
Case
Registration
- Inputs
Name
UID
Age
Sex
Survey Date
Symptoms
Acute Flaccid paralysis<15 years of age
Cough with or without fever <2weeks
Cough with or without fever >2 weeks
Fever<7 days
1. Only Fever
2. With Rash
3.With vesicles
4. With Arthralgia
5. With Bleeding
6. With Daze/Semiconsciousness/
Unconsciousness
Fever>7 days
Jaundice cases<4 weeks
Acute Jaundice
Loose watery stools<2 week
With Some/Much Dehydration
With no Dehydration
With Blood in Stool
Hypopigmented Patches
Itching
Other Symptoms
Onset Date
Other members affected/contacts
H/O travel to endemic areas
Visited Doctor? (No/Yes)
Admitted Hospital? (No/Yes)
Diagnosis
Probable Cases
Acute Diarrheal (including acute gastroenteritis)
Bacillary Dysentery
Viral Hepatitis
Enteric Fever
Malaria
Dengue / DHF / DSS
Chikungunya
Acute Encephalitis Syndrome
Filariasis
Hand foot mouth disease
Scrub typhus
Leishmaniasis
Leprosy
Scabies
Meningitis
Measles
Rubella
Diphtheria
Pertussis
Chicken Pox
Fever of Unknown Origin (PUO)
Acute Respiratory Infection (ARI) / Influenza Like
Illness (ILI)
Pneumonia
Leptospirosis
Acute Flaccid Paralysis
< 15 Years of Age
Dog bite
Snake bite
Unusual Syndromes NOT Captured Above (Specify
clinical diagnosis)
Action taken in brief if unusual increase noticed in
cases/deaths for any of the above diseases
Other Probable Cases - Retro Viral Infections and Opportunistic infection
Remarks
PH-IDSP.9 Confirmed
Case
Registration
-Inputs
Name
UID
Survey Date
Confirmed As
Dengue / DHF / DSS
Chikungunya
JE
Meningococcal Meningitis
Typhoid Fever
Diphtheria
Cholera
Shigella Dysentery
Viral Hepatitis A
Viral Hepatitis.B
Viral Hepatitis.C
Viral Hepatitis.E
Leptospirosis
Malaria
-PV:
-PF:
Mixed
H1N1
Filariasis
Scrub typhus
Leishmaniasis
Leprosy
Scabies
Cancer
Diabetes
Hyper Tension
Stroke
Other (Specify)
Disability requiring medical care
Confirmed Date
Visited Doctor? (Yes/No)
Admitted Hospital? (Yes/No)
Medicine Taken
Lab Result Details
Patient Status
Continuing Treatment
Recovered
Relapsed
Transferred Out
Referred
Dead
Other
Remarks
PH-IDSP.10 Vector Study
Data from periodic surveys (weekly) carried out at houses for
the presence of larvae of mosquito vectors in natural and
artificial habitats like used tyres, terrace/sunshades, overhead
tanks and other water-holding containers in and around the
houses shall be captured through the application.
Inputs:
Survey Date
Previous Date
Container Examined- Number
No: of containers examined having larvae
Type of containers positive-
Containers Reduced (No: of containers with larvae reduced)
House Index(HI)
Container Index(CI)
Brateu Index (BI)
Hotspots identified- Number& names
Name of High risk area become low risk by follow up surveys-
Remarks
Malaria and filarial vectors also be surveyed by the DVC Unit
staff
PH-IDSP.11 Health
Advice
Health worker will give health tips and conduct awareness
programmes in public for their better day to day life.
Inputs
Survey Date
Select House No
Previous Visit Date
Health Advice given
Public Health- NCD, CDs, Source reduction activities
Mother and Child Health
Family Planning
More Details
PH-IDSP.10 Non Communicable
Disease Monitoring
- Inputs
Name
UID
Type of NCD
1. Diabetes
2. Hypertension
3. Cholesterol disorders
4. Coronary Artery disease
5. Stroke
6. Cancers
7. Mental health issues
8. Others, Accidents including RTA, trauma,
Occupational disease, oral health, endocrine
disorders, burns, deafness, blindness etc
Age of Patient
Have you checked your BP (Yes/No)
If yes, record the last data
Have you checked your Sugar Level (Yes/No)
If yes, record the last data
Any one in your family Have NCD
DM- (Yes/No)
HTN- (Yes/No)
CAD-- (Yes/No)
If yes Relationship
How many years since diagnosis of the disease Have you under drug treatment- Yes/No
If yes, regular/irregular
System of medicine- Allopathy/Ayurvedic/Homeo/other
Present treatment
1. LSM
2. Oral drugs
3. Insulin
Exercise-
Regular/Irregular/Occational/No exercise
Type of Work
Sedentary
Moderate
Heavy
Type of Food: Veg/Non Veg
Habits (since)
Smoking
Alcohol
Tobacco Chewing
IV Drug user
Death in family due to NCD & Type of NCD
Age of death due to NCD
Basic measurements
Height
Weight
BMI (Calculate and display)
Waist Hip ratio
Health education given on
1.Hypglycemia and Management
2.Foot care
3.Physical activity
4.Ophthalmic care
5.Meal plan
HTN
Duration
BP Level
Status of cholesterol
Details of Doctor Consultation
Type of cancer
Duration
Treatment received
Type of Stroke
Since when
Type of morbidity
Type of treatment
Palliative care beneficiary
Duration
Type of disease
Treatment received
Procedures performed
3.7 Reports:
PH-R.1 Report
Generation
Several reports need to be provided by the HHD Application A
few indicative reports are given below:
List of immunizations due for an infant
Ante Natal Care registration and Follow-ups made by a
person
Family welfare registrations and Follow-ups made by a
person
Consolidated report showing total number of fully
immunized children under a specific institution
Consolidated report showing the total number of houses
visited, number of persons offered with ANC services
etc. on a particular survey date
The data collected through various data collection modules are
used to generate institution level survey reports, consolidated
reports and various graphical reports.
PH-R.2 Central
Application -
Reports
Some reports to be generated through the central Web based
Application are summarized in the table shown below. This is
not an exhaustive list.
Family Health Survey Register
Institution level survey report showing household data
and data on demographics
Eligible Couple Register
Institution level or month wise institution level report
showing eligible couple registrations made at an
institution
Family Welfare Acceptance Register
Institution level or month wise Institution level report
summarizing data on persons who have registered for
any family planning methods at an institution
Mother and child Register
Institution level or month wise Institution level or
financial year wise Institution level report containing
details of persons who have registered for Ante Natal
Care and birth and immunization details of children
coming under an institution
Child Register
Institution level or month wise Institution level or
financial year wise Institution level report showing
birth and immunization details of children coming
under an institution
Birth Register
Institution level or month wise Institution level or
financial year wise Institution level report showing
birth details of infants born under an institution
Death Register
Month wise report on death cases registered at
Institution level
Immunization Report
Institution level or month wise institution level report
showing details of children who are given different
immunizations
AEFI Reports
AFP Surveillance Report
Maternal Death Report
Month wise report on maternal death cases registered at
Institution level
Infant death report
Month wise report on infant death cases registered at
Institution level
Graphical report on Fully Immunized Children Rate
A chart report showing variations in the number of
fully immunized children under an institution in
different financial years.
Graphical report on Child Birth Rate
A chart report showing child birth rates under an
institution in different financial years.
Graphical report on Annual Disease Rate
A chart report showing number of persons registered
with various communicable and non communicable
diseases in a given financial year
Graphical report on Disease Wise Patient Rate
Given a disease, the report shows a chart representing
the number of persons registered with that disease in
different financial years
Graphical report on Ante Natal Termination Rate
A chart report showing number of registered cases of
delivery, abortion and MTP under an institution in
various financial years
Graphical report on ANC Danger Conditions Rate
A chart report showing the number of ANC cases
registered with different Danger conditions or
complications for a given financial year
Graphical report on Family Welfare Method Acceptance Rate
A chart report presenting data on the number of persons
who have adopted permanent or temporary family
planning methods in various financial years within an
institution
Immunization Alerts
Institution level monthly report showing list of children
whose immunization(s) are due as on a date in a
particular month. The report helps in forecasting
immunization doses needed by an institution in a
specific month.
Yearly Statistical Report
Institution level Financial year wise consolidated report
showing data on the number of birth cases, death cases,
deliveries etc. reported from a specific institution
Monthly work schedule
Institution level monthly report which prepares a work
schedule for health workers for a given month and year.
The data shown include a list of families along with
various health services to be offered to the family
members in that particular month (40day blocks)
Form 6
A consolidated report of the data collected from the
field by health workers from lowest level sub-centres
Demographic Health History
A person name search facility that outputs
comprehensive HTML web page report presenting
biographical data, general health, present health or
history of present illness, serious or chronic illnesses,
course of pregnancy, if any, immunizations, if any,
current medications, last examination date and
hospitalizations, if any. The standardized health history
report make it easy to understand demographics'
personal health history
Drill Down Health Report
A consolidated report presented by drilling down
through the health information database accessing
summary public health information for higher level
BPHC and moving through hierarchy to detailed
demographic health information view in sub centres
(SC)
3.8 Public Healthcare Schemes:
PH-PHS.1 HMIS eHealth System shall provide data to HMIS directly. At present
the the data transfer mode is through Excel file. If the HMIS
portal is ready to accept data through XML or Web service
then the eHealth system shall be capable of providing required
data and linkage
PH-PHS.2 MCTS eHealth System shall provide data required for MCTS directly.
This will require providing a web service which will be
invoked by the MCTS periodically to derive required data from
eHealth. Alternately the data may be provided in any standard
format such as csv, XML or even Excel format. The exact
modality for providing data will be decided based on
discussions with MOHFW, GoI.
PH-PHS.3 School
Health
The eHealth system shall allow seamless flow of information
to and from the School Health database
PH-PHS.4 Revised
National
Tuberculosis
Programme
(RNTCP) -
Registration-
Inputs
Name
UID
Survey Date
Confirmed Date
Weight
Sputum Taken on
Name of Lab
Result of sputum test
3 Plus
2 Plus
1 Plus
Negative
Non Productive
Scanty
Other tests
X-Ray
Mantoux
Blood Test
FNAC
Type of Patient
Default
New
Relapse
Transfer in
Patient Status
Recovered
Continuing Treatment
Transferred out
Relapse
Defaulted
Dead
Other
Disease Classification
Dormant
Miliary
Pulmonary
Treatment Starting date
DOTS or Non DOTS
DOTS
Category-I
Category-II
Any side effects of drugs
DOTS PLUS
Any side effects of drugs
Remarks
PH-PHS.5 RNTCP
Follow up -
Inputs
Name
UID
Survey Date
Weight
Sputum Taken on
Name of Lab
sputum result
Patient Status
Outcome – cured/completed/defaulted
Date of completion of treatment
Chemoprophylaxis of < 6yrs
Remarks
PH-PHS.6 National
Vector Borne
Disease
Control
Programme
(NVBDCP)
NVBDCP is an umbrella programme coming six major vector
borne disease namely Malaria, Lymphatic Filariasis, Dengue,
Chikungunya, Japanese Encephalitis and Kala -Azar. eHealth
system shall provide data monitoring of diseases covered under
the programme.
PH-PHS.7 NPCDCS In order to address one of the greatest public health
challenges, the Kerala state Health Department and NRHM
has designed and implemented a non communicable diseases
prevention and control programme in the state. eHealth shall
provide necessary data for this scheme.
PH-PHS.8 National
Programmes/
State specific
programs/
LSGI
specific
programs
In additiona there are few more National Health Programmes
aiming to improve the health standards of the people which are
listed below. eHealth shall provide necessary data for
monitoring and reporting. 1. National Leprosy Eradication Programme
2. National Programme of Control of Blindness
3. National Iodine Deficiency Disorders Programme
4. Palliative care
5. Ashraya program
6. Practical Approach to Lung Health (PAL)
7. List of 53 schemes/programs of other departments
3.9 Sample screen shots of Reports
1. Family Health Survey Register
2. Eligible Couple Register
3. Family Welfare Acceptance Register
4. Mother’s Register
5. Child Register
6. Immunisation Alerts
Pentavalent vaccine also may be included
7. Work Schedule Report
3.10 Intersectoral Coordination with other agencies:
Meetings held with schools, agriculture, animal husbandry, rural development
departments, PWD, Electricity, Town planning, Water Authority, Social Justice
department, NGOs, private Hospitals, Law and order department, LSG,Environment
Industry and commerce, Tourism, Legislation and Judiciary, Suchithwa Mission,
Kudumbasree, Residence Association representatives etc.
Number and details of health related projects implemented through LSG
Action related to functions assigned by public health act – inspection of hotels, melas,
dwelling places, work places, institutions etc.
Implementation of Building rules
Numbers of people who attended the meetings
Numbers of anganwadis visited
Numbers of animals vaccinated against rabies
Results of water testing undertaken in the viscinity,
List of differentially abled persons (physical mental)
List of people requiring palliative care
Public complaints received
Resolved
Not resolved- reason
Medical camps
Major disasters
4 Procurement and Asset Management
Procurement of equipments are arranged by KMSCL/DHS//DME. Procurement of
equipments is to be arranged by the competent authority by observing rules and regulations
contained in Store Purchase manual (SPM).
PAM.1 Integration with eTendering Government of Kerala has already implemented
eTendering through the NIC framework. eHealth shall
have facility to import data from this framework
regarding Purchase Orders issued.
PAM.2 Management of Quotations
There may also be a simplified framework created in
eHealth viz. eQuotation for local purchases not
covered through eTendering. This is a facility by
which authorized Users of the system can create new
quotations in eHealth. The eQuotation module shall
have the following facilities:
1. Create Purchase requests by Users
2. Approvals at various levels including
Technical and Administrative Sanction
3. Create new quotations/tenders for local
purchase
4. Create a Registered vendor list for each
category with email IDs, Mobile numbers and
Postal addresses.
5. Registered vendors shall be given SMS and
emails regarding the new quotation/tender
6. The mode of submission of quotation/tender
may be Offline. That is the tenders/quotation
will be submitted in sealed Covers as usual.
7. However the system shall have a payment
gateway for allowing vendors to make
payments of Cost of Tender Forms, EMD and
Security Deposit online.
8. The system may have Interface to generate
Purchase Orders and mail it to the respective
Vendor.
PAM.3 Recording of purchase and
all other historical
information about asset
from TASK
Data pertaining to all new equipments purchased by
KMSCL shall be imported regularly to eHealth. The
system shall be able to capture and record information
such as the supplier, purchase dates, serial number
against each individual piece of equipment from the
KMSCL Supply Chain management System 'TASK' -
Equipment / Asset identification number, Description
Serial number - Manufacturer - Model number Year
of manufacturing Maintenance history for the
equipment Cost centre Bill of Materials Status (e.g.
installed, repaired, in store) Supplier, Warrant period
Location etc
PAM.4 Importing existing Data
from TASK
The relevant data of all equipments already purchased
through KMSCL is available in TASK. This data is to
be imported to eHealth and stored for reporting
purposes.
PAM.5 Data pertaining to all new
equipments purchased by
DHS, DME etc.
eHealth system shall also store data pertaining to all
new equipments purchased by DHS, DME or other
Heads of Offices/Institutions other than KMSCL. The
system shall differentiate these equipments from that
purchased through KMSCL.
PAM.6 Data to be stored in eHealth The data pertaining to equipments stored in the
eHealth database shall include all the contact details of
the manufacturers/Suppliers of the equipments. This
include mail ids, URLs for reporting breakdowns,
Land line and Mobile numbers Postal address etc. This
information will mainly used for reporting
breakdowns and arranging repairs.
PAM.7 Facility to select consignees The system shall have the facility to select consignees
for each procurement
PAM.8 Facility for each consignee The system shall have facility for each consignee to
to acknowledge receipt acknowledge receipt
PAM.9 Account the received
equipments
The system shall account the received equipments in
the respective account of stores.
PAM.10 Capability to scan bar code
tags and upload the
inventory
The system shall provide the capability to scan the bar
code tags and automatically upload the physical
inventory for review, reconciliation, and approval.
PAM.11 Facility to issue equipments Stores shall have facility to issue equipments to users
PAM.12 Receive back equipments Stores shall have facility to receive back equipments
PAM.13 Provision for asset transfer
transaction
The system shall provide an asset transfer transaction
for collaborative data entry. This shall include the
capability to enter and save partially completed asset
transfers. This could include allowing the transferring
agency to complete their portion of a transfer and to
allow the document to be saved. At a later date, the
receiving agency could access the transaction for
completion and posting of the final transfer.
PAM.14 Creation of asset master
records
The system shall have the ability to initiate the
creation of asset master records from the process of
creating and processing store issue documents. The
system shall have the ability to identify potential fixed
assets through Store transaction details.
PAM.15 Creation of population table
for identifying ownership
and maintenance
responsibility
The system shall contain a population table for the
purpose of identifying ownership and maintenance
responsibility for equipments.
PAM.16 Provision of multiple
responsibility codes.
The system shall provide multiple responsibility
codes. These codes would identify who is responsible
for the asset, including but not limited to : Department
assignment Organization assignment Group
assignment Individual assigned responsibility
Program responsible District responsible Supervisor
responsible
PAM.17 Location of an Asset and
Asset tracking
The system shall have the ability to link an asset to a
Healthcare institution where it is located and track it
with following features:
• Real time location tracking GUI to find assets
• GUI to visually identify asset location
PAM.18 Review the list of assets
attached to an Institution
The system shall allow the Institution head to review
the list of assets attached to his Institution. The
system shall support this function with reports of
assets.
PAM.19 Integration with web- based
GIS information
The system shall allow integration of web-based GIS
(geographic information system) with provision to
zoom in and display the list of assets in an Institution
and the details of each asset.
PAM.20 Custodian of the equipments System shall have facility to mark the custodian of the
equipments.
PAM.21 Classification of assets The system shall allow for major asset class (e.g.,
Medical equipments, vehicles, Ambulance, buildings,
land, infrastructure, leasehold) for tracking and
reporting.
PAM.22 Creation of multiple asset
grouping
The system should able to create and define multiple
asset grouping for each class of asset. The user should
able to classify the asset as per the defined asset
groups.
PAM.23 Electronic certification of
physical inventory
The system shall allow electronic certification of
physical inventory for each Healthcare Institution.
PAM.24 Furnishing of condition of
the asset on the date of
physical inventory
The system shall allow the User to provide a 'condition
of the asset' at the date of physical inventory.
Examples include: New Good Poor Broken
PAM.25 Recording of a date of
physical inventory
The system shall allow utilities to record a 'date of
physical inventory' when inventory counts of physical
assets take place.
PAM.26 Provision for mass updates
to a physical inventory date
field
The system shall allow utilities to provide mass
updates to a physical inventory date field. This would
be required for agencies that complete their inventory
at one time and wish to update all of their assets with
one transaction.
PAM.27 Capability to identify
missed or non updated
assets
The system shall allow utilities to provide the
capability to identify all assets that have been missed
and not updated by the physical inventory process, or
to identify all assets in the following categories :
Missing or lost Stolen Destroyed Under disposal
review
PAM.28 Maintaining the list of
spares with their part no.
The system should be able to maintain the list of
spares along with their part no for each equipment.
The system should also be able to group equipments of
same make and rating for the purpose of assessment of
spares requirement. To avoid stock out situations and
ensure minimum inventory carrying costs, the system
should be able to prompt for replenishing of spares,
optimal re-order levels for major assets and also for re-
ordering of daily consumables.
PAM.29 Capability to identify
vehicles
The system shall provide the capability to identify
vehicles that have been purchased or leased via
various methods.
PAM.30 Insurance claims related
asset tracking
The system shall allow asset tracking and reporting
related to insurance claims and insurance recoveries.
PAM.31 Provision to deactivate an
asset
The system shall provide the ability to deactivate an
asset when removed for maintenance and allow
reactivation based on proper authorization.
PAM.32 Mark for Auction Stores shall have facility to mark equipments for
auction
PAM.33 Auction and Disposal System shall have facility to arrange auction and
dispose of equipments
5 Maintenance Management
5.1 Introduction:
Repairs of all equipments purchased through KMSCL are arranged by KMSCL during
the period of their Warranty and AMC. Repairs of all equipments after the warranty and AMC
period as well as repairs of equipments purchased by DHS and DME are to be arranged by the
respective officers who are the custodians of the equipments directly.
The eHealth system shall have a centralized framework for reporting, arranging and
monitoring repairs of equipments used in various Healthcare Institutions covered under this
project. What is envisaged is very user friendly efficient and Maintenance Management system
to keep the equipments in good working condition so that Doctors and Para-medical staff will be
able to carry out their functionalities without hassles. This is a problem area and the eHealth
system shall bring about visible and measurable changes in the existing system.
5.2 Equipments Purchased through KMSCL and are Under Warranty/AMC
If the equipments are procured through KMSCL and are still under Warranty or AMC
arranged by KMSCL, then the information shall be transmitted to TASK. The concerned officer
at KMSCL managing the Warranty/AMC through TASK will arrange the repairs through
authorized service centers. eHealth System shall have facility to monitor the progress of the
repair and send required alerts to the concerned authorities in this regard.
5.3 Equipments procured directly by DHS/DME
If the equipments were procured directly by DHS/DME then the whole process will be
confined within the eHealth System. This process is described below.
Within the Warranty/AMC period
If the equipments are within the Warranty/AMC period then the OEM/Supplier is to be
informed about the incident. The system shall have facility to send email/SMS with details of
the equipment and request for immediate action. The system shall monitor the progress and
escalate the matter in case of no action as per the hierarchy. The Central User shall have UIs
to manage this.
When the repair is completed then the authorized User(s) shall have facility to update the
system
5.4 Equipments not covered under Warranty/AMC
In case of equipments which are not covered under Warranty/AMC the repairs are to be
arranged by DHS/DME. There are well defined organization in DHS and DME to carry out
the repairs. The system shall capture this hierarchy and use it to automatically allot the
requests to the concerned employee in the hierarchical chain. The system shall alert the
employee regarding the repair requests.
The employee responsible for arranging the repair shall have a user friendly UI to view
the repair requests and plan their visits to institutions to attend the repairs. The superior
officers in the hierarchy shall also have privilege to view these plans and programs charted by
the sub-ordinate employees, revise it and monitor the progress.
The System shall have the following facilities in the eHealth System:
1. Plan both Minor repairs and major Repairs by employees of the repair unit
2. Report the requirement of spares for the repair.
3. To create and submit all forms and reports linked to the repair so that the process can
be completed paperless completely.
4. To issue necessary sanction for the repair of the equipment by the concerned authority
5. To arrange the repair as per the sanction obtained
The Maintenance Management system shall have following facilities:
MM.1 Integration with Asset
database
Maintenance Management system shall be integrated to
Asset Database to use Asset Database functionalities and
information.
MM.2 Reporting
Breakdowns
Authorized users of the system shall have the facility to
report breakdown of equipments. Some equipments have
built in alert mechanism which will send messages to the
immediate user, supervisor, controlling officer & the
technician who is responsible for that particular equipment.
If feasible, eHealth system should be configured to route the
alerts through this system.
MM.3 Reporting Preventive
Maintenance
requirement
Users shall also have facility to report the need of a
preventive maintenance for equipments.
MM.4 Creation of Work
requests
Ability to raise maintenance Work Requests after receiving
notification from operations about a breakdown. The system
shall have facility for graphical, Colloquial searches for
equipment IDs, drop down menus for selectable fields and
sizeable descriptive fields for recording job/fault
information.
MM.5
Notification to
Supervisor
The Work Request should then be capable of triggering
electronic notification to the maintenance supervisor.
MM.6 Search capability for
all work requests
Ability to easily review / search for equipment related Work
Request and/or any other Work Request problem
MM.7 Classification of work
requests
Ability to classify Work Request/Work Order by user
defined variables. For example safety, modification, new
work, rework, breakdown, preventive etc.. It should be
possible to report by each of these classifications.
MM.8 Prioritization of work
requests
Ability to assign a priority to a Work Request.
MM.9 Ability to view any
work request
Ability to view details of any outstanding Work Requests on
a specific job or related piece of equipment in order to avoid
duplicating work requests. Also, ability to link / reference a
Work Request against a customer reference or location.
MM.10 Status of a work
request
Ability to record the status of a Work Request via user
defined variables eg. Awaiting approval etc.
MM.11 Feedback to requestor Ability to inform requestor via e-mail or otherwise upon
approval / action /rejection of Work Request.
MM.12 Automatic creation/
linking of WO to a
work request
Ability to automatically and manually create / link Work
Orders to a Work request.
MM.13 Transfer of
information from work
request to work order
Ability to transfer (manually or automatically) information
captured within a Work Request directly into a Work Order
fields e.g. Job Type. Once entered in the Work Order, it
should be possible to alter this information e.g. fault
description.
MM.14 Establishment of time
level targets
Ability to establish time level targets against a Work
Request. The ability to report on these targets should also
exist.
MM.15 Defining of work Ability to clearly define work, in terms of attributes (nature,
type, driver etc), by populating fields and allowing user to
enter a suitable long/short text description.
MM.16 Defining of critical
dates
Ability to define critical dates against a Work Request. E.g.
Required By dates.
MM.17 Approval to closure of
request online
Ability to approve, maintains, complete and close Work
Request online.
MM.18 Creation, review and
deletion of WO
Ability to create, maintain and delete Work Orders.
MM.19 Creation of Work
orders
Ability to create a work order for all types of work by
estimating the job duration, resource requirements, material
requirements, contractor requirements and allocate a work
priority to the request. The work order shall also identify the
labor type and/or crew (s) allocated to the work, description
of the work and the duration of the work. It is likely that for
Emergency work, the Work Order details could be provided
in via an electronic interface.
MM.20 Generation of WO
number
The Work Order reference number should accommodate
existing numbering and naming conventions used by the
utility.
MM.21 Linkage of WO with
account code
Ability to link a Work Order to a financial account code.
MM.22 Defining of critical
dates for a WO
Ability to define critical dates against a Work Order e.g.
Required By date, planned start date, planned end date, job
duration etc.
MM.23 Format of a WO The Work Order details should include but not be limited to:
Work Order type (e.g. corrective, preventive, breakdown
etc.) Sub categories within a Work Order type Detailed
description Work Order tasks Planned start/end date and
duration for work Asset object requiring attention (e.g.
equipment, function, location) Work instructions/tasks Any
safety procedures Material (spare parts, stock and non stock
items) required Estimation of manpower (internal and
external labor) requirement Labor skill level; Planned cost,
Cost centre/project code etc.
MM.24 Linking of WO Ability to link/reference a Work Order against a piece or
group of equipment, customer reference or location.
MM.25 Creation of multi WO
tasks
Ability to create multiple Work Order tasks against a Work
Order.
MM.26 Defining of work
requirements
Ability to define work requirements (plan/ labour/
equipment/ other) against the Work Order.
MM.27 Review of WO
priorities
Ability to assign and review Work Order priorities.
MM.28 Postponement of WO Ability to postpone Work Orders to a certain date
MM.29 Ability to change a
WO
Ability to make changes to a Work Order (e.g. change
maintenance steps, change material requirements, change
labour requirements).
MM.30 Ability to view details
of a WO
Ability to view details of any outstanding Work Orders on
specific or related pieces of equipment.
MM.31 Recording the status
of a WO
Ability to record the status of a Work Order via user defined
variables e.g. on stand-by awaiting materials, partially
closed, closed etc.
MM.32 Online approval of
WO
The ability to approve work orders on-line via workflow is
required. This could be performed by different incumbents
within the organization, depending on work order size/cost,
priority, mode and Delegated Financial Authority levels etc.
If a work order is not approved within a specified time it
should be forwarded to the next appropriate person.
MM.33 Closure of WO online Ability to maintain, complete and close Work Orders online.
MM.34 Adjustment in WO Ability to adjust all elements of the Work Order including :
Materials, Resources, Tools, Timings
MM.35 Creation of an
emergency WO
Ability to create and issue an emergency Work Order that
does not require approval. An audit trail will record the user
who authorized the Work Order.
MM.36 Review of
maintenance history
Ability to review maintenance history for a specific item of
equipment and/or on a particular manufacturer based on
Work Order history.
MM.37 Attachment of
documents to a WO
Ability to attach documents to a Work Order including
detailed work instructions, safety requirements and
checklists, drawings etc. Upon issue of a Work Order, it
should be optional as to whether attachments are printed
automatically or at the discretion of the user.
MM.38 Review and printing
of tech information
Ability to review and print any technical information
associated with the work parcel.
MM.39 Status on warranty Ability to check whether there are any current warranties on
the equipment, or 'related' equipment. This will require a link
to the equipment database where all warranty information
will be kept.
MM.40 Bulk creation of WO Ability to create Work Orders in bulk using a pre-selected set
of fields.
MM.41 Bulk updation of WO Ability to bulk updates information for a number of Work
Orders.
MM.42 Search criteria on
group of WO
Ability to specifically target a group of Work Orders during a
search - based on Work Order fields populated by the user.
MM.43 Viewing of bulk WO
information
Ability to view bulk Work Order information and manipulate
this information based on user requirements. These
modifications should include filed/code updates and/or
generic description/ information input into the Work Orders
description / extended description.
MM.44 Issue of warning /
alarm in case of non
completion
Ability to notify relevant personnel or issue a warning/alarm,
if a Work Order has not been completed after certain period
of time.
MM.45 Automatic dispatch of
work to crews
Ability to dispatch work to crews automatically (Manually
function should be able to overwrite the automatic function.)
based on user defined criteria.
MM.46 Integration with
mobile messaging and
CC system
Ability to integrate with Mobile messaging and/or Internet
systems for electronic dispatch of work to work groups or
crews.
MM.47 Modification in work
crew / teams
Ability to create, review and modify the structure and make-
up of the work teams / crews including skills and
competency requirements.
MM.48 Standard Jobs Ability to create, retain and use standard jobs including
specification of tasks, materials requirements, labour, hours
and skills and contractor hours and skills, in-house and
outsourced tools / plant requirements, outage requirements,
priorities, accounting information etc.
MM.49 Creation of standard
jobs for specific
equipments
Ability to create standard maintenance jobs for activities
involving specific equipment, specific 'classes' or 'groups' of
equipment or some 'general' jobs.
MM.50 Linkage of documents
to a standard job
Ability to link to a standard job(s) any required documents
including technical information, safety instructions, method
sheets, checklists etc.
MM.51 Tasks during a
standard job
Ability to specify the type of tasks that will be performed
during a standard job.
MM.52 Linkage of safety
documents to a
standard job
Ability to link to a standard job any required safety
instructions. Linkage is also required to be maintained to
Safety procedures within externally maintained
documentation.
MM.53 Linkage of inspection
checklists to a
standard job
Ability to link a standard job to any inspection checklists.
MM.54 Viewing of backlogs Ability to view all work, review the backlog, and availability
of resources to see which of the jobs can be absorbed into the
current or next schedulable period(s). All work, including
backlog, should be able to be reviewed by user-defined codes
MM.55 Actioning on backlog
work
Ability to bulk re-schedule, cancel, close or postpones
backlog work.
MM.56 Ability to support
electronic signature
Ability to support electronic signature for document approval
MM.57 Capturing of all
information for a
completed work
Ability to capture all information relating to completed
maintenance work against a work order as part of the
maintenance history database. Retain the information as part
of the maintenance history unless it is physically removed
from the system (e.g. through archiving exercise).
MM.58 Bulk closure of WO Ability to bulk close Work Orders meeting a user defined
time, cost, resource, status or other criteria.
MM.59 Authorization to enter
comments against WO
Ability to allow authorized employees to enter text in a free
format against the Work Order. These comments should be
able to be forwarded to maintainer's supervisor.
MM.60 Flagging WO for cost
escalation
Ability to flag/warning work orders where the work order
cost exceeds the work estimate / budget for the month/year or
user defined approval limit.
MM.61 Automatic flagging of
outstanding orders
Ability to automatically flag outstanding orders/costs when
attempting to close a Work Order.
MM.62 Complete closure of
WO
Ability to completely close off work order. System should
inform user that all outstanding commitments and invoices
have been met. After this step, no more costs can be charged
to the order.
MM.63 Archiving of WO Ability to archive Work Orders after a defined period of
time. It should be possible to easily retrieve archived Work
Orders within few hours.
MM.64 Maintain Bill of
Materials
Ability to maintain the parts list contained in the equipment.
The list should also include the quantities of parts involved.
Ideally a graphical parts book Referenced to the catalogue
would support this.
MM.65 Maintaining history of
changes in parts list
Ability to maintain history of changes to Part List. From time
to time equipment is reconfigured with alternative parts.
History of such changes is required to be kept.
MM.66 Maintaining reference
to catalogue
Ability to maintain reference to catalogue. For each part in
the equipment parts list, there is a requirement to include a
cross- reference to the catalogue, to enable material
identification and reservations.
MM.67 Maintaining document
identification and
contents
Ability to maintain the document identification and
document contents in the document register. Ability to
maintain any links between documents and any Equipment/
Component items.
MM.68 Creation of asset When an equipment item / component is created, it is
required to reference the item / component to an asset in the
fixed assets register. Where a relevant asset hasn't been set
up, it is expected that the system would require the creation
of an appropriate asset.
MM.69 Maintaining the
warranty details
Ability to record the warranty duration, the warranty period
end date, the warranty number and any warranty notes. If a
WO is raised on an asset under warranty, the system should
flag that the vendor is responsible for repairs and that
maintenance is required to be performed in accordance with
warranty supply and contract conditions.
MM.70 Recording of vendor
recommendation
maint. freq, type,
procedure etc.
Ability to record the maintenance frequency, type and
procedure recommended by the vendor.
MM.71 Maintaining history of
changes to above
recommendations
Ability to hold history of changes to the recommended
maintenance frequency, type and procedure.
MM.72 Listing of outstanding
& incomplete WO
Ability to list the outstanding Work Orders that have not
been completed by their estimated due date.
MM.73 Ability to record status
of a WO
Ability to record status of a Work Order such as approved,
not-approved, wait on materials, wait on contractors, wait on
labour, held etc.
MM.74 Capturing of Work
progress of a WO
Ability to capture work progress including completion of
tasks and closure of Work Orders - Manually derived %
completion for each task or Work Order
MM.75 Review of any notes
on equipment
Ability to review any notes about the particular equipment/
component, which have been entered by maintenance
experts. The notes should be accessed from the particular
equipment/ component record.
MM.76 Ability to manually
key in WO expenses
Ability to allow for manual keying in of Work Order
expenses.
MM.77 Progress of repairs There shall be facility for the end users to enter progress of
repairs and finally close the call.
MM.78 Monitoring by Central
User
There will be a UI for a Central User who will monitor the
maintenance of equipments using the eHealth framework.
MM.79 Escalation of pending
issues
There shall be a system of escalation of pending cases of
maintenance.
MM.80 SMS and email alerts The system shall also send SMS and email alerts to the
concerned officials in the hierarchy about pending requests
for maintenance.
MM.81
Linkages with
eQuotation
The system should facilitate the authorized User to arrange
the repair work or Purchase of Spares for the repair work
through eQuotation described in Procurement and Asset
Management Module
MM.82 DEEP FREEZER
temperature
monitoring
Provision to enter ILR & DEEP FREEZER temperature and,
at the time of entering SMS message should be sent to the
Medical Officer in charge
6 General Administration Module
6.1 Introduction:
eHealth shall have a General Administrative Module to handle the Office Administrative
Functionalities. This will be mainly used by the Administrative cadre officers. This module is
expected to provide a framework for the employees to manage their routine administrative and
personnel matters with ease so that they can focus on their areas of core competency viz.
providing healthcare. This module will take out the drudgeries of office work to some extent and
will make the administrative hierarchy function more efficiently. The General Administrative
Module consists of the following sub modules:
1. Institutional Database
2. Human Resources
3. Accounts
4. Medical Reimbursement
The requirements of each sub module is described below
6.2 Institutional Database:
GAM.1 Data capturing The eHealth system shall have interfaces to capture static data
pertaining to each institution. An authorized user will
Enter/update/Edit these data.
GAM.2 Home Page for
Institutions
Each Institution shall have a page in the eHealth Web portal and the
data shall be displayed in the web page of the Institution. There
shall be facility to enter/edit names of LSGD Members, HMC
Members. There shall be facility to upload Jurisdiction area Map of
the Institution.
GAM.3 Annual
Administration
report
The data shall be used to provide various reports including those
required for the Annual Administration Report.
GAM.4 Data items The data items to be captured is listed below. 1. Name of Hospital/ Institution
2. Location
3. Post Office
4. Pin code
5. Land mark
6. Panchayath/ Municipality/ Corporation
7. Ward/ Division
8. Village
9. Revenue Block
10. Taluk
11. District
12. Nearest Railway station& Distance
13. Nearest Bus station& Distance
14. Nearest Bus Stop
15. Main Bus root in which the Institutions located
16. Phone No. with STD Code
a. Office
b. Causality
c. Enquiry
d. Others
17. Govt. order pertaining to the sanction of the institution
18. Orders relating to subsequent development
19. Total land available
20. Re survey No.
21. Registry
22. Building availability
23. No. of buildings available, Movable & immovable asset register ; in a PHC this
facility should be down to the Sub Centre level
24. House No. of each building
25. Area of each building
26. Plinth area
27. No. of Electric connection
28. Consumer No.:
29. Water connection consumer No
30. Whether OPD & IPD functioning
31. No. of days OPD functioning in a week
32. Whether OPD functioning 24 hour
33. No. of sanctioned beds
34. Nature of specialties available
a. General Specialty
b. Major Specialty
c. Supporting Specialty
d. Super Specialty
35. Special clinics available& weeks of operation
36. Diagnostic facilities available(Yes/No)
a. X-Ray
b. Laboratories
c. Pathological
d. USG
e. Biochemistry
f. CT scan
g. Microbiology
h. MRI Scan
37. Any Special Diagnostic facility available (Yes/No)
a. H1N1 Screening
b. Filarial test
38. Other Supporting Section/ Dept. available (Yes/No)
a. Blood Bank
b. MRD
39. Whether FW centre available
40. Whether Enquiry/ Information Centre available(Yes/No)
41. Details of Vehicles (Nature of Vehicle, Register No., Condition of vehicle)
a. Owned by Department
b. On rent
42. Name of Institution
43. Public Information Officer
a. Name
b. Designation
c. Address
44. Asst.Public Information Officer
a. Name
b. Designation
c. Address
45. Details of Sanctioned Bed strength
a. Male
b. Female
c. Children
d. Medical
e. 2.Surgical
f. 3 Obstetric & Gynecology
g. 4 Pediatric
h. 5.Orthopaedics
i. 6. Ophthalmology (Eye)
j. 7.ENT
k. 8.Psychiatry
l. 9.Dermatology (Skin)
m. 10.PMR
n. 11.Chest Diseases
o. 12.Cancer
p. 13.T B
q. 14. Dental
r. 15. Family Planning
s. 16. Geriatrics
t. 17. Isolation
u. 18. Observation
v. 19. Casualty
w. 20. Reserved for emergency
x. 21. Pay wards
i. KHRWS
ii. Govt. Pay wards
iii. (Donated by organizations/ persons-specify)
6.3 Human Resources Module:
The Pay Roll Processing of all Government employees is carried out through SPARK. A brief
description about SPARK is given in Section ……….
eHealth shall have a HR Module with limited functionalities. The requirements of this module
are described below.
GAM.5 Data Import
from SPARK
Nearly all employees are enrolled in SPARK. The unique ID for
employee in SPARK is known as Permanent Employee Number
(PEN). The basic data about employees shall be imported from
SPARK. All master data such as Institutions, Designations, Cadre
etc shall also be imported to eHealth from SPARK. These master
data and IDs shall be used in eHealth for the HR module.
GAM.6 Organizational
Hierarchy
There shall be facility to capture the Organization Hierarchy and
then display it in a dynamically generated tree structure. The system
shall allow editing the Hierarchy as and when changes occur. The
user interface shall facilitate display of the following pertaining to
each Institution in the hierarchy:
1. The basic details about the Institution
2. List of employees in each Institution
3. Drilldown facility to view the details of each employee
GAM.7 ID Cards: The system shall have facility to print and issue ID Cards with
Photograph. The Cards for Medical Education wing will be issued
for DME and that of Health Service will be issued from DHS.
GAM.8 Service
History of
Employees
prior to
eHealth:
SPARK has Service History of many employees. The service
history in SPARK shall be imported to eHealth. Employees shall be
able to view this and report errors. There shall be facility to make
corrections to this data and add new data by an Admin User. The
basic purpose is to create an error-free service data of all employees
in the Health Department pertaining to the period prior to the date
of implementation of eHealth. Service History after the
implementation of eHealth will automatically get updated in the
system from the attendance module.
GAM.9 Attendance
Module:
There shall be a simple attendance module to capture the daily
attendance of every employee. The UI for this module shall allow
the Users to mark their own and their subordinates' attendance. The
UI shall allow capturing different service status for each employee
as below:
Leave
Unauthorized Absence
Promotion
Transfer
Deputation
Suspension
Retirement
Termination
Death
Joining
Each one of the above events will close the current record in the
‘Service Data Table’. Except in the following cases a new record
shall be created.
1. Retirement
2. Termination
3. Death
GAM.10 Duty
Scheduling:
There shall be facility for scheduling duty for the employees
including Doctors and other Clinical staff. The attendance module
shall confirm that the employee has reported for duty as per the
schedule. Thus the service history of each employee will get
updated automatically after the implementation of eHealth.
GAM.11 Sanctioned
Strength:
Department of Health has a specific number of sanctioned posts in
each cadre in each Institution. Regular Employees can only be
posted against this sanctioned number of posts. System shall have
facility capture the sanctioned cadre strength for each Institution.
There shall be facility to make changes to the cadre strength as and
when Government orders issued altering the cadre strength.
GAM.12 Shifting of
Posts Due to
exigencies of
services
Due to exigencies of service posts will be shifted temporarily or
permanently to other institutions. The system shall have facility to
capture such changes and reflect that in the cadre strength.
GAM.13 Working
Arrangement
Employees may have to be posted in excess of the sanctioned
number in an institution. This is often done by posting the
employee on ‘Working Arrangement’ in an Institution where there
is no vacancy. eHealth system shall capture all this types of
postings and the working strength in each Institution shall be
updated dynamically.
GAM.14 Vacancy
Position
The system shall also have facility to derive the vacancies in each
institution by deducting the actual number of employees in a cadre
from the sanctioned number. The system shall be required to
generate various reports based on sanctioned strength, working
strength and vacancies.
GAM.15 Contract
Employees:
Employees including Doctors are posted on contract basis for a
specific Period. The system shall keep a track of this and shall have
the details such as the scheme under which they are posted etc. The
system shall be required to generate reports based on these data.
GAM.16
Leave
Management.
System shall have facility for employees to apply leave online. The
sanctioning by the superior officer shall also be done online. There
shall be facility to refuse leave by the superior officer and the
system shall inform the employee through SMS, email etc about
such refusal or sanction. In case of Officers the system shall
generate the sanction letter for Accountant General
GAM.17
Online
Application for
transfer
The system shall have facility for employees to apply for transfer
online.
GAM.18 Transfer Lists There is a precisely defined norms for transferring employees. The
system shall generate a ranking of employees eligible for transfer
based on the guidelines.
GAM.19 Transfer
Orders
The system shall have an interface to generate the transfer orders
online.
GAM.20 Relieving and
Joining of
Employees
The system shall capture the relieving and joining of employees
based on the transfer orders. The system shall have the facility to
generate the Charge Transfer Certificate (CTC) in case of Gazetted
Officers.
GAM.21 Gradation The employees are ranked in each cadre based on a Gradation List.
This ranking is used for their promotions to next higher cadre. The
system shall capture the gradation of employees.
GAM.22 Cadre
Hierarchy
The designations of employees shall also be linked different cadres
and the system shall create a Cadre Hierarchy.
GAM.23
Confidential
Reports (CR)
The system shall have an interface to capture the Confidential
Report (CR) of employees provided by their superiors. The CR has
a defined format. The system shall prompt the respective Officer to
submit the CR in time. Similarly the system shall have facility to
enter Non Liability Certificates by superior Officers. The CRs and
NLCs shall be documented and stored with confidentiality with a
well defined retrieval system. The system shall also have facility to
enter details of Disciplinary actions taken against each employees
in the employees page
GAM.24 Promotions The system shall provide a list of employees due for promotion to
the next cadre based on anticipated vacancies in any cadre. The
system shall alert missing CRs or any other documents required for
effecting promotion.
GAM.25 Training: There shall be a master data of trainings. The mandatory trainings
for each position in the Health Service shall be mapped to the
position. The system shall keep a track of trainings being imparted
to employees. The system shall be able to verify whether the
employees have undergone all the mandatory trainings prescribed
for the position they are holding.
GAM.26 Video
Conferencing:
The system shall have a facility for Video Conferencing. The
system shall be able to handle at least three conferences with 50
seats at a time. There shall be facility to provide links for these
conferences by the organizer and the allowed participants will join
the conference by clicking the link and logging in with their user
name and password.
GAM.27 Webcasting The system shall have facility for webcasting for authorized users.
This facility will be mainly used for conducting Continuing
Medical Education (CME) Programmes.
GAM.28 Staff Tracking The system shall have facility to track employees.
GAM 29 Hospital
Management
Committee
The system shall have facility to enter details about HMC
GAM 30
Organogram
The system shall have facility to display and Edit the organization
chart
GAM 31
Automatic
duty roster
The system shall have facility to enter the basic constraints
regarding duty allocation and parameters for an algorithm to
generate the duty schedule. Based on the constraints and the
algorithm, the system shall generate a tentative duty schedule for
the given month. The MO in charge shall then be able to edit this
schedule to generate a final duty schedule.
GAM.32
Daily census
Facility to Display Daily census of hospitals like total bed strength,
admission, vacant bed, excess patient number etc
GAM.33 The system shall display the names of Duty Doctors & other staff in
Digital displays at two or three locations in the Hospital.
6.4 Accounts:
Money is collected at various points in hospitals. Some collections in the Hospital are to
be remitted in the Treasury and some are to be remitted in the Bank account of agencies such as
Hospital Management Committee etc.
GAM.29 Scheme-wise
accounting
Hospitals receive money from various sources such as NRHM,
RSBY etc. eHealth shall have a standard Accounting module to
keep track of the receipts and expenditure pertaining to different
Accounts including the financial transactions of HMCs. The
system shall be able to keep accounts of receipts and payments
with a standard classification of expenditure and income. The
system shall generate Account Head-wise reports relating the
income and expenditure. The module shall have standards features
such as Accounts Payable/Receivable, General Ledger (GL), Cash
Management, Internal Auditing, Budgeting & Planning
GAM.30 Collection
reports
eHealth shall have facility to generate reports giving details of
collections at various cash counters in each institution.
GAM.31 Expenditure
base
Performance
Indicators
The accounting module shall also generate report on various
performance indicators relating to the income and expenditure
pertaining to each fund. The Performance Indicators based on
Income and Expenditure is given Section……..
6.4.1 Medical Re-imbursement:
GAM.32 Medical
Reimbursement
The system shall have a database of all medicines and Clinical
Procedures and Lab Tests which are reimbursable to the
Government employees. The Web portal should facilitate
verification of admissibility of all Medical reimbursement claims of
Government and PSU employees.
7 Document Management Solution:
Document management solution is a computer system used to track and store electronic
documents and/or images of paper documents; provide storage, versioning, metadata,
security, as well as indexing and retrieval capabilities. It's also termed as document
management software or document management tool. The information in the form of
documents is required to be shared across the stakeholders for smooth functioning and
maintaining high service levels.
Requirement of Document management solution -
DMS.1 Users: The users of the DMS are primarily the Administrative Cadre
Officers and staff who need to create, store and retrieve
documents.
DMS.2 Documents Typical documents are Governemnt Orders, Proceedings,
Documents submitted by staff and Officers, Confidential reports
etc.
DMS.3 Storage Every user should have approx 1 GB of storage space so
that user can add documents as per their requirement.
DMS.4 Easy Additions Adding a new Document should be easy and trouble free so
that user can upload the document file at ease.
DMS.5 Managed Filing Document filing system can be maintained hierarchy like normal
disk based file systems and also associate multiple taxonomies
with the same document or set of documents.
DMS.6 Fast Retrieval User should be able to search for any document that has been
uploaded by name with Full Text Search of inside any kind of
document. Automated Retrieval should also available by popular
XML formats like RSS for every Tag.
DMS.7 Security Each document must be protected by a granular security
system, All Documents must be protected against theft, loss
and tampering.
DMS.8 Distribution The documents must be available in eHealth internal and
external portal depending upon policy to any user who has
access right to it. It should also be possible easily click-to-
distribute documents to select users, user group or even the
whole Web Space.
DMS.9 Archival Automatic Revision control system must be in place that
maintains versions automatically, every time a document is
updated. All prior revisions should also be always available.
DMS.10 Retention The facility of purging prior revisions and permanently
deleting stored documents should also be available to user to
protect security of sensitive documents.
DMS.11 File
Collaboration
It should be possible to collaborate on any kind of document
that is stored within using Ad-Hoc Workflows of Collaboration.
7.1 Features of document Management:
DMS.12 Scanning Scanning documents and other back office files to save office
space and retrieval time.
DMS.13 Documents
submitted
through website.
Enabling auto storage of documents submitted through website.
DMS.14 Information
sharing
Enabling information sharing between different offices,
departments and customers
DMS.15 Document filing Automating document filing
DMS.16 Enterprise wide
solutions
Implementation of enterprise wide Electronic Data Management
(EDM) solutions
8 Management Information System
One the key objectives of eHealth are to enable better insights into the health system to
enable multiple stakeholders to make evidence based decision based on reliable and relevant
data. The scope of MIS is covering cross domain healthcare analytics for the entire healthcare
system in the state.
The solution shall integrate clinical, operational and financial data and create one single data
source to drive cross domain analytics in a data warehouse with the following capabilities
Easy data acquisition from central patient record as well as from other clinical and
administrative applications providing a reliable source of data for analytics applications
Data cleaning with healthcare specific logic like terminology management , units of
measure etc
Maintain data lineage and handle healthcare environment data warehousing concepts like
late arrival of data
Rules based data quality and data cleansing
Cross Domain data model which can integrate clinical, financial, operational and
administrative domains
Proven data model which shall require minimum changes in the data model when a new
data source is added to the warehouse
The warehouse should be agnostic to the analytics tools and should support fit for
purpose tool for end user analytics
Rapid deployment of analytics applications
8.1 Analytics:
State eHealth shall enable analytics in multiple analytics areas as illustrated below.
8.2 Example Analytics
• Diabetic hospital admissions Top 5 reasons
• Average length of Stay by condition
• Reported communicable diseases by Geo area
• HIV Status
• By Gender
• By age group
• Cervical cancer by %age of population
• Exposed to a specific lifestyle
• Exposed to an ethnicity
• Diabetics as %age of population
• By Age group
• By Lifestyle
• Obesity trends
• Mother age distribution
• Average age for onset of Diabetes ( trends)
• Depression cases by
• Socio Economic Status
• Age Group
• Trend of substance abuse by
• Age group
• Male vs. female
• Vaccine coverage
• Smoking Status and trends
• By Age
• By Gender
• COPD registrations
• Bed Utilization by region
• trends in physician /population coverage
• %age of OPD resulting in admissions
• Waiting time for surgeries
• Nurse/Patient ratio
8.3 The requirements of MIS module is as follows:
MIS.1 General
Requirements
The system shall generate various management information reports
required for top management, middle level management and
respective Institutions. These are generally based on the data
generated under different other modules covered in this section.
The MIS Module should include
Information capturing
Information processing
Information management
Information based decision- making & reporting
MIS.2 Pre-
implementation
study
Before finalization of MIS requirements and formats, a through
study of the existing business process shall be carried out along
with the eHealth PMU. Based on the organization structure and
requirement of decision support system at organization level, a
comprehensive MIS requirement document shall be prepared.
The actual MIS requirement shall be finalized at implementation
Stage.
MIS.3 Format of reports. The system should be able to generate reports on regular
basis. eHealth PMU will finalize the periodicity and the format of
report.
MIS.4 The granularity
and format of
report
The granularity and format of report on same subject will vary for
different levels. For example format and content of a report
relating to disease surveillance for DHS will vary substantially
from that of Institution.
MIS.5 Data to be
collected from
source
Data acquisition for MIS should preferably be without human
intervention as far as possible. The data should be collected
only at the lowest level and from the same source and in the
standard formats.
MIS.6 MIS reports for
external agencies
MIS reports are also to be generated for external
agencies such as Planning Board, Finance Department etc. The
formats and the periodicity of the same will be finalized with
the eHealth PMU.
MIS.7 Performance
Indicators
This module should provide performance monitoring system
based on the Performance Indicators given Section:……... Some
of the Indicators are of general nature and it may not be feasible
to create the indicators from the data captured and stored by
eHealth. In such cases there shall be UIs to input data manually
and generate the required Performance Indicators.
MIS.8 Business
Intelligence Tools
This module should provide Business Intelligence Tools
for data mining, analysis, trending, simulation, manage reporting,
On-Line Analytical Processing (OLAP) analysis, Ad-Hoc
querying, dash boarding, score carding, business activity
monitoring, MS Office, Open Office Integration. etc.
Essentially, a BI solution is normally implemented with following
components
An Extraction, transformation and loading (ETL)
component which extracts data from OLTP systems,
transforms it and load it to the data warehouse
A data warehouse component which will host the data.
A reporting component which will allow on-the-fly
reporting on the data from data warehouse.
MIS.10 Graphical User
Interface
The system shall generate reports for all the modules in user-
defined formats. The system will have a graphical user interface
with a capability for generating customized reports, apart from
the regular ones mentioned above, as per the requirement of
management and operations staff. Display of statistical data shall
be presented additionally in graphical formats such as bar-
graph/pie diagram etc. for convenience of analysis.
MIS.11 General Facilities The MIS module shall have the following general facilities
Centralized Health Dashboard and Score-card for all
program specific KPI's
Overall Status : State/District Healthcare level Health
managers shall get to see the change in different Healthcare
parameters
Drill down to see individual KPIs specific to context of
relevant health events
Identify the resources around the incident location, nearest
health facilities
Real Time Reports on Different layers of map based on
facilities like PHC, District Health Center, Laboratory,
Radiology etc
Staff Tracking
Patient Tracking
MIS.12 Alerts State/District Healthcare Executive gets alerts over series of events
which have relevance in Public healthcare
MIS.13 Identify the
resources around
the incident
location
Facility to identify the resources around the incident location,
nearest hospital with Burn unit, Cardiac unit, Spine unit etc
MIS.14 Real time reports
on healthcare
schemes
Real time reports related to different healthcare schemes
MIS.15 Point to epicenter Point to epicenter of Disease, Events, Incidents view over the GIS
Map
MIS.16 Facility
Locations
Different layers of map based on facilities like PHC, District
Health Center, Laboratory, Radiology etc..
MIS.17 Dashboard view Dashboard view for District HQs/State Healthcare officials for
review, reporting, planning and decision making regarding
Disease surveillance
Resource Management and Procurement
Human Resource Management
8.4 Performance Indicators:
8.4.1 MCH/Nutrition
No. Measurement Indicators
1 Registration of ANC, under nutrition, maternal anaemia:-
Share of 3rd
Trimester ANC with Maternal Hb>11 g%
2 PHC own record and outreach data form and private facilities:-
> 4 ANCs all registered
3 Early referral of complicated cases:-
% of ANC records with BP and weight entries alb./HB
4 % of TT as per scheduled
5 % of FBS done in first trim. of ANC
6 % of ANC with USG Screening for congenital anomalies at 19 week
7 % LBW at birth <2.5Kg
8 No. of deaths in children under 5 years
9 % of (0-2) year children with growth monitoring at every immunization
(drop-down):- on exclusive breast feeding until 6 months)
10 % children breast fed within 1/2 hrs.
11 % children started weaning after six months
12 Age at Pregnancy
13 Share of 3rd
Trim ANC fully immunized for TT
14 Share of children fully immunized against six vaccine preventable diseases
and against eight diseases (+HiB and HBV) at 18 months
8.4.2 Adolescent Health
No. Measurement Indicators
1 Screening referral counselling:-
Share of school health JPHN available or not for every 2500 children
2 No. of Adolescent counselled/screed for health education
3 Number of adolescents screened for Anemia and Obesity
4 Number of adolescents attending ARSH camps??
8.4.3 Family Welfare Services
No. Measurement Indicators
1 Family Planning acceptance Temp./Permanent Method:-
% of NSV out of total permanent sterilization, Couple protection rate
2 Male female sterilization:-
Number of NSV surgeries done per month
3 Services to infertile couple:-
Number of infertility cases referred to higher centers
8.4.4 NCD Management
No. Measurement Indicators
1 % of total population screened for NCD
2 No. of deaths due to NCD below < 60
3 Regular supply of medicine:-
% of cases who received consultation/total detected
No. of New cases identified DM/HT
4 Share of patients above 30 years where BP measurement is available in OPD
record
5 No. of demonstration/awareness campaign done by PHC
6 No. of Tobacco/Alcohol counselling session
7 No. of Diet modification, life style management session organised
8 Share of patients above 30 years where blood glucose measurement is
available in OPD record
9 Share of known diabetics maintaining RBS <130mg ???(FBS,RBS,HbA1c)
10 Share of known hypertensive maintaining systolic BP < 140 mm Hg
11 Number of Pap smears collected in the month and screened for Ca Cervix
12 Share of known hypertensive with DM maintaining systolic BP < 130 mm Hg
13 Number of cataract patients identified and referred
14 Number of cases booked under Tobacco Products act in the month
15 Share of known hypertensive and/or DMrecorded for urine examination
(urine protein, sr.creatinine, lipids)??
8.4.5 Gender Sensitivity
No. Measurement Indicators
1 No. of New staff train on gender based violence (GBV)
2 No. of GBV cases detected by PHC
3 No. of cases detected to Bhuomika
4 Number of sessions on gender sensitization conducted in schools, colleges,
community etc.
8.4.6 Patient satisfaction
No. Measurement Indicators
1 % patient satisfied over the period
Exit poling
Rating scale
2 Validation by the random survey
3 Relative performance/ change in level determined by Patient Exit Survey
8.4.7 Linkage to community/LSGI/Other sector
No. Measurement Indicators
1 No. of WHSC meeting conducted
2 HMC meetings
3 No. LSGI project implemented
4 Classes conducted for AWW in sector meetings
5 No. of AWs visited by MO
6 No. of school visited by MO/paramedical
7 No. of Panchayat level meetings participated by MO
8 No. of health related trainings given to LSGI
9 Share of Panchayat Funding
8.4.8 Implementation of Public health related acts
No. Measurement Indicators
1 % of staff trained in PH related acts (COTPA, PH Act)
2 No. of institution (Under the PH act.) inspected in the previous month
3 % of institution under PH act. Issued notice v/s the institution that have
violated PH act.
4 No. of institution in the area violated PH act.
5 No. of awareness campaign conducted on PH related act.
6 No. of cases registered under COTPA or PHA
7 Health certificates issued by MOs
8 % of public health complaints investigated
8.4.9 School Health, Occupational Health
No. Measurement Indicators
1 % of staff trained in SHP
2 % of schools and Students covered under the PHC area
3 No. of student screened by JPHN/JHI in previous month
4 No. of MO visits to school/ total no. of schools in PHC area
5 No. cases referred or detected/ schools
6 OH – No. of workplace visits done by MO/paramedical under the PHC area
7 Number of counselling sessions conducted
8 Number of health education classes conducted
9 Immunisation activities
8.4.10 Access and Equity
No. Measurement Indicators
1 Proportion of BPL patient visiting the PHC
2 OPD attendance
3 Population based survey:-
Proportion of children, females, elderly, tribals , disabled, BPL attending
OPD
4 Coverage of social security measures (asraya projects, community nutrition
programmes, MGNREGS) in terms of number of people for each
8.4.11 Referral and Gate keeping
No. Measurement Indicators
1 Forward: No. of patient referred out
2 Backward: No. of Patient Referred In
3 Indicator for not doing over referral:
Patient’s that could be managed effectively at the PHC- number??? (indicator
to be refined)
?? Or audit of referred cases showing that cases could have been managed at
that level itself.
How well follow up was done for patients referred back- indicator??
8.4.12 Laboratory Services
No. Measurement Indicators
1 Total No. of types of investigation with SOP/Total no. of types of
investigation
2 No. of trained lab. Staff/ Total no. of lab staff
3 No. of equipment calibrated at any time/ Total no. of equipment in the lab at
that time
4 Adequacy of universal precaution (0-5, based on the available universal
precaution)
5 Biomedical waste management system in place (Yes/No)
6 Whether there is availability of
Functioning lab.
Collection and transportation facility
Both of the above
None of the above
7 No. of episodes in the previous month due to supply chain disruption
8 Do you have deep burial pit?
Facility to burn
Affiliated to any other
9 % of routine lab investigation done in the PHC delivered in on the same day?
10 No. of TB suspect done for sputum AFB in previous month/total no. of TB
suspect in the PHC in a month:- No. of new cases of PTB identified
11 No. of blood smear tested in a month/ total no. of suspected malaria cases in
month:-
No. of new cases of malaria identified in previous month
8.4.13 Mental health
No. Measurement Indicators
1 No. of patient screened or followed up for mental health illnesses/ total no. of
OP patients
2 No. of episodes in the previous month where medicines were not available to
the patient due to supply chain disruption
3 % of patient referred to higher centre out of the identified patients
4 % of identified patient followed up in the previous month by the field staff in
the PHC area
8.4.14 Health Education, IEC/BCC, Advocacy
Objective- Produce Knowledge dissemination practices
No. Measurement Indicators
1 % of staff trained in health communication
2 Availability of Audio Visual Aids
3 No. of IEC/BCC material displayed in the key sites / the total no. of IEC/
BCC supposed to be displayed in the institution
4 % of IEC material disbursed to the periphery from the total IEC material
received in the PHC
5
% of IEC, BCC funds utilised in a stipulated time period (and situation
demand)
6 % of activities conducted against the planned activities for IEC/BCC for that
institution and at sub centre level
8.4.15 Data Compilation, Surveillance and data reporting
No. Measurement Indicators
1 % of S,P,L form reporting
2 % of private institution reporting/ total no. of institution in this area
3 % of public health important specific diseases cases reported within 24 hours
among the total number of cases of that particular diseases in the previous
month
4 Completeness of each of the registers like basic population data register,
MCH register, Pw register etc.
5 Completeness of HMIS, MCTS
8.4.16 Legal Services, Medico Legal Services
No. Measurement Indicators
1 No. of cases registered and reported
2 No. of wound certificates issued
3 No. of GBVM cases referred to ISCC
8.4.17 Other outreach activity
No. Measurement Indicators
1 No. of Anganwadi visits
2 No. of outbreak investigation by the MO/PHC team / no. of outbreak in the
area during the period
3 No. of death audit conducted by PHC team/Total no. of deaths due to
communicable diseases during the period
4 No. of outreach medical camps conducted during the previous month
8.4.18 Facility level indicators OP/IP
No. Measurement Indicators
1 Total No. of New OP in facility in the previous month
2 Total No. of OLD OP in facility in the previous month
3 No. of OP days conducted/monthly by MO
4 Average bed occupancy in the previous month
5 NO. of IP admission in the previous month
6 Average length of stay of IP patients
7 Readmission Rate (definition?)
8 % of OP cases referred
9 % of IP cases referred
8.4.19 Financial management
No. Measurement Indicators
1 % of specific funds (HMC, Plan, AMG, Untied, RSBY, LSGD etc.) spent in
the previous FY
2 Average time to submit the SOE after complete the activity
3 Proper maintenance of Books of account
4 % of staff trained for financial management
5 Physical achievement/financial expenditure
6 Unspent funds in HMC
7 Delegation and uniformity
8 Externally mobilized funds
9 No. of audit queries dropped
8.4.20 Quality and Infection control
No. Measurement Indicators
1 No. of trainings conducted
2 No. of infection control committee meeting held
3 % of staff practicing waste segregation
4 No. of reported events of needle stick injuries
- of which, number in which HIV prophylaxis given
5 Institutional mechanism for biomedical waste management in place or not
6 ??Hand wash policy and practice: Nursing trolleys with sanitizers?
Consumption of hand sanitizers?
8.4.21 Palliative Care
No. Measurement Indicators
1 Proportion of patient given at least one home care services during month
2 No. of patient visited P.C.Clinic during month
3 share of patients who are satisfied with the palliative care they receive
8.4.22 Communicable Diseases
No. Measurement Indicators
1 Vector Indices
2 Indices based on the national programme
RNTCP – Cure Rate
Case Detection Rate
NACP - % children born to HIV positive mothers, who have not received
Nevirapine
NVBDCP- Annual Blood Examination Rate
No of notifiable diseases reported
8.4.23 HR and Capacity Building
No. Measurement Indicators
1 No. of training conducted and attendance by participant/resource person
2 Type of training conducted and attended
% of staff compiled with the training department
Compliance with new training requirement
Redeployment and retraining
SOP’s for defining Role/Resp.
Staff satisfaction
8.4.24 OPD
No. Measurement Indicators
1 Average OPD attendance – OP register
2 Avg. Waiting time for registration–Patient Surveys
3 Avg. waiting time for consultation–Patient Surveys, IT (future) – need
timestamp upon registration and timestamp upon visiting doctor, token
system
4 Department wise distribution of patient – OP register for each physician,
would require additional data entry since this is not currently electronically
compiled
5 Patient satisfaction index – Exit poll and Survey
6 No. of days doctors were not available – superintendent register on attendance
of physician (daily only, no late arrivals)
7 Total no. of complaints received - suggestion box, complaint box - Box
8 Avg. consultation time– Survey/ time motion/IT, questionable (survey may
not be accurate, IT would only capture time if fully electronic – each patient
scanned as they first present to doctor, may be able to calculate approximate
average with total OPD times and total patient loads)
9 Consultation time for a standardized patient
10 Types of patient referred - OPD register, difficult to pick up referrals with
current documentation
11 Adverse event reporting – difficult to pick up with current or future
documentation
8.4.25 Casualty
No Measurement Indicators
1 Presence/absence of triage systemfor emergency patients – time motion study,
observation
2 Round the clock availability of staff and supplies at the casualty –inventory,
spot checks, absenteeism/availability study
3 Training status of emergency care team – Survey
4 Presence of management protocol –spot check for guidelines/SOPs
5 Display of management protocol - observation
6 % of patient who’s required investigation done within set time frame based on
SOP - Unclear, maybe a function of lab efficiency and not casualty
management
7 Availability of emergency lab facility– Unclear, may not be an emergency lab
facility, change to indicator reflecting presence of a system for requesting
urgent lab/radiology results
8 Avg. time for specialist to respond after call – call register, documentation
may not be available
9 Presence of patient handover protocol–observation, spot checks of case
reports, staff interviews
8.4.26 Operation Theatre
No Measurement Indicators
1 Surgical Site Infection (SSI) rate– calculate from number of infections
reported, may be difficult to assess if infection is due to OT or to ward care.
2 OT utilization rate - OT register
3 Death in OT rate - mortality register, Hosp. admission register
4 Re-exploration rate – OT register (may need to extract information and match
patient IDs)
5 Display of protocol – Identification, infection control, - observation
6 Zoning/patient separation with proper protocol for activity and guidelines
each zone - observation
7 Avg. time between sterilization of OT - Sterilization register, OT register
8 Frequency of swab tests for microbiology– Register, may not exist currently
9 Availability of functional minimum standard equipment – equip. register,
observation
10 Training status of OT staff - surveys
11 Iatrogenic injuries and nosocomial infection rate – case report spot checks,
difficult to assess
12 % Use of checklists - observation
8.4.27 LABs and Other Diagnostic Investigations
No Measurement Indicators
1 No. of types of available investigations– Register?
2 Portion of patients who seek external laboratory facilities for tests available in
public hospital – surveys of sample of case reports
3 Avg. time from sample collection and results (Turn Around Time)–
Register/IT using timestamps
4 Reliability of test results using external control - survey
5 Frequency of internal/external quality assurance/ monitoring – observation,
survey
6 Equipment utilization rate (for CT, X-Ray, MRI etc.)– register
7 % Calibrated equipment- equipment log book?
8 % downtime – equipment log book?
8.4.28 Pharmacy
No Measurement Indicators
1 Percentage of drugs procured by local purchase – procurement register?
2 Percentage of stock-outs including emergency drugs–stock out register
(denominator is EDL and Rational Drug List)?
3 Portion of patients who seek purchase externally for drugs that should exist in
the pharmacy – spot checks, surveys
4 Avg. waiting time– need some timestamp mechanism through IT,
observation, time motion studies
5 % of slow moving drugs - drug register?
6 % of medicines lost by pilferage, spillage etc. – Stock register?
7 Maintenance of adequate storage conditions–observation
8 % drugs reaching expiration date – register? May not exist, observation, spot
checks
9 Presence of mechanism to inform OP/IP/Casualty doctors if drugs are not
available – observation, spot checks
8.4.29 Labour Room
No Measurement Indicators
1 Maternal mortality - register
2 Complications – case reports
3 Caesarean delivery rate (especially emergency CS) - register
4 Mothers leaving after 48 hrs – case reports
5 No. of new-borns examined by paediatrician within specified time frame –
case reports
6 Baby breastfed within 30 minutes?
7 Share of mothers given oxytocin in 3rd
stage – case reports?, possibly drug
registers
8 Share of delivery records complete withpartogram – case reports?
8.4.30 Wards
No Measurement Indicators
1 Average Length of stay (ALOS) – hospital already documents through
institutional activities report
2 Space per bed or bed-to-bed distance - observation
3 Bed occupancy rate – registers, hospital documents already
4 Bed strength – hospital records document
5 Hospital acquired infections – difficult to assess, case reports, surveys of
patients
6 Readmission rate – need patient UID,
7 Patient-staff (IP only) ratio – hospital records using IP load and staff count
with staff attendance (need to ensure that staff is fully assigned to IP)
8 Nurse: bed ratio – hospital staffing and bed strength records
9 Number of admissions - register
10 Adverse events (falls from bed, bed soresetc)- from incidence reporting
forms?, case report surveys
8.4.31 ICU
No Measurement Indicators
1 Occupancy – observation, records of admissions/bed strength
2 Avg. length of stay – records?
3 Number of patients in ward >30 days – case reports? May not be
electronically recorded now
4 Admissions total - register
5 Mortality rate – mortality register
6 Bed:nurse ratio – staffing totals and bed strength
7 Ventilator:Bed ratio – equipment register or observation and bed strength
8 Ventilator associated pneumonia/catheter related infection rate – case
reports? May be difficult to assess
8.4.32 Housekeeping
No Measurement Indicators
1 Frequency of cleaning facilities – checklists, records of housekeeping
2 Responsiveness time – test, spot check, observation
3 Compliance with Service Level Agreements – discussion with contractor?
Observation, surveys
4 Timeliness of responses to complaints – observation, survey, may be
difficult to assess
5 Hospital acquired infections – difficult to assess
8.4.33 Medical records
No Measurement Indicators
1 Share of complete/incomplete files – surveys
2 Percent without ICD codes - surveys
3 Missing medical records – comparison of IP registers (counts) and totals of
records available
4 Compliance to SLAs
8.4.34 Procurement and Maintenance
No Measurement Indicators
1 Issue- Most of the PROC outsourced to other agencies
2 Local procurement time from indent to supply
3 % of stock outs
4 Downtime
5 Utilization rate
6 % of Equipment Calibrated
7 Clear SLA’s for restoring the equipment
8 Procedures for Timely reporting of breakdown of equipment in theatres,
wards, and back room operations
9 Procedures for timely mending/sourcing of equipment
.