his checklist for midsize indian hospitals

Hospital Information System Checklist

for Small & Medium Hospitals

of 29



of 29

DISCLAIMER

HIMSS Asia Pacific India Chapter has exercised professional care and diligence in collection and processing of the information

in this report.

This report is intended to be of general interest only and does not constitute professional advice.

HIMSS Asia Pacific India Chapter makes no representations or warranties about the accuracy of the data in this report. HIMSS

Asia Pacific India Chapter is not be liable to any user of this report or to any other person or entity for any inaccuracy of

information contained in this report or for any errors or omissions in its content, regardless of the cause of such inaccuracy, error

or omission.

Furthermore, to the extent permitted by law, HIMSS Asia Pacific India Chapter, its members, employees and agents accept no

liability and disclaim all responsibility for the consequences of you or anyone else acting, or refraining from acting, in relying

upon the information contained in this report or for any decision based on it, or for any consequential, special, incidental or

punitive damages to any person or entity for any matter relating to this report even if advised of the possibility of such

damages.

This document is NOT aligned with the HIMSS Analytics EMRAM (EMR Adoption Model). The checklist will be aligned to EMR

Adoption Model in the next phase of work.



of 29



of 29

CHAIRMAN’S MESSAGE

I am happy that HIMSS Asia Pacific India Chapter has come out with the much needed HIT Checklist for

small and medium size hospitals.

Having served on the board of medium and large size hospitals, I have seen the pain of failure of HIT/HIS (Hospital Information

Technology/ Hospital Information Systems), the transition to a new system and the financial loss to the organizations for the

failure of the HIS. In three organizations, I have at the board level, written off about Rs. 10 Cr (approximately USD 2 million) due

to an ill-conceived HIT/ HIS system.

The problem starts at the ordering stage itself, as a wrong RFP for a HIT/ HIS solution would lead to a wrong solution being

developed, and the vendor may not be responsible for the failure. To make the job easier for the hospital administrators, experts

at HIMSS have come out with a checklist which has been reviewed by a leading panel of experts. We hope that using this HIT

checklist as a reference, the hospitals can design the right HIT /HIS solution .This is the first HIT checklist and we will await your

feedback and improvise on the next version.

Pankaj Vaish, Vice President, Board Member - HIMSS Asia Pacific India, deserves credit for taking out time from his busy

schedule and making this happen with the help of other board members, and our deep heart-felt thanks to the eminent expert

panel for their review and feedback.

HIMSS is committed to the transformation of healthcare using IT, and we look forward to your feedback on this initiative

Rajendra Pratap Gupta

Chairman,

Board of Directors

HIMSSS Asia Pacific India Chapter



of 29

HIMSS ASIA PACIFIC INDIA CHAPTER

Rajendra Pratap Gupta Chairman , Board of Directors

Vishal Gupta President, Board of Directors

Pankaj Vaish Vice President, Board of Directors

Manick Rajendran Vice President, Board of Directors

Madhubala Radhakrishnan Treasurer

Dr Pankaj Gupta Joint Secretary

Vamsi Chandra Kasivajjala Member, Board of Directors

Amit Mishra Secretary, Board of Directors

Shailendra Ravi VP, Senior Director, Business Strategy EMC

Email: [email protected]

mailto:[email protected]



of 29

ACKNOWLEDGEMENT

HIMSS Asia Pacific India Chapter is pleased to publish this document that is intended to serve as a checklist for Small & Medium

Hospitals in India while they embark on their journey to choosing the right Healthcare IT Solution in the form of a Hospital

Information System (HIS). This document can be used by most small and medium hospitals across public and private sector

settings in India and to a certain extent can also be extended to hospitals outside of India in neighbouring regions with similar

level of maturity of adopting Health IT and a comparable socio economic status as that of India. This checklist covers key

functional areas for IT automation in hospitals and addresses both functional and technical requirements.

The initial draft was prepared by members of the board of HIMSS Asia Pacific India Chapter. This report also bears the efforts of

significant contributions through review and revision of the document and hence it is important to place on record

appreciation to the following members whose contribution has resulted in finalizing and publishing this checklist.

Expert Review Panel

1. Mr. Praneet Kumar CEO, BL Kapoor Hospital, New Delhi, India

2. Dr. Mahesh Inder VS CEO, Saket City Hospital, New Delhi, India

3. Dr. Dharminder Nagar Managing Director, Paras Healthcare Pvt. Ltd., India

4. Dr. Karanvir Singh Chief Medical Information Officer, Apollo Healthcare, India

5. Dr. Gayatri Mahindroo Director, NABH, New Delhi, India

6. Dr. Kiran Venugopal Vice President – Product Management, HealthFore Technologies, Bangalore, India

7. Mrs. Neena Pahuja Independent HIT Consultant, NCR Region, India

8. Mr. Rajesh Batra Kokilaben Dhirubhai Ambani Hospital, Mumbai, India

9. Mr. Aditya Mani Pushpanjali Crosslay Hospital, NCR Region, India

10. Mr. J P Dwivedi CIO, Rajiv Gandhi Cancer Institute & Research Centre, Delhi, India

11. Mr. R S Bapat Adtiya Birla Memorial Hospital, Pune, India



of 29

DEFINITIONS

1. EMPI Enterprise Master Person Index

2. MRN Medical Record Number

3. EMR Electronic Medical Record

4. CPOE Computerized Physician Order Entry

5. IV Intra Venous

6. OPD Out Patient Department

7. OT Operation Theatre

8. OR Operating Room

9. ICU Intensive Care Unit

10. SaaS Software as a Service

11. TAT Turn Around Time



of 29

FUNCTIONAL REQUIREMENTS

Legend

G: Indicates the proposal fully comply the

requirement/ clause

A: Indicates the proposal partially meet

the requirement / clause; supported

with remarks

R: Indicates the proposal does not meet

the requirement / clause; supported

with remarks

S. No. Module Sub Module/

Function Requirement Importance Weightage

Vendor

Remarks

HIS/1 Patient Registration & EMPI

HIS/1.1 General The system shall auto generate a unique Patient ID (aka

MRN or UHID) which shall use alpha numeric characters.

The logic used to generate the Patient ID should be

definable by the Hospital.

Critical

HIS/1.2 General Types of Registration - General, VIP, Emergency and

External. General registration is used in all normal cases.

VIP is registration that is used for VIP patients or can be a

part of general registration with a separate Flag/Indicator.

Emergency registration should take only approximate age

and gender as an input. External registration can be used

for patients visiting for Diagnostic services and/or

Pharmacy services only.

Critical

HIS/1.3 General Flexible fields to capture unique Patient Identifier like PAN

card, Aadhar Card, Passport, Referral Source etc.

Important



of 29



Vendor

Remarks

HIS/1.4 Patient

Search

Patient Search shall have multiple search capabilities. It

shall be able to qualify searches by name, date of birth,

sex, national individual identifiers (such as Aadhar, PAN

Card, Passport etc.). The index shall support a variety of

possible internal identifiers such as Patient ID (MRN/UHID),

case number, multiple account numbers, etc., for each

patient and be able to maintain cross reference to other

existing identifiers in each of the facilities used by the

patient in the same site or in other locations.

Critical

HIS/1.5 Patient

Search

The HIS shall support a EMPI at multi-site, multi-institutional,

district, or national levels that links existing patient indices

together.

Critical

HIS/1.6 Patient

Search

The EMPI shall support multiple names so that patients who

change their names can still be located with a EMPI

search.

Critical

HIS/1.7 Patient

Search

Ability to search patient name using soundex as well as

multi-part names.

Desirable

HIS/1.8 Patient

Search

Name alert search. Patients with same last name and

same first name and initial shall be flagged to alert users of

possible conflict.

Critical

HIS/1.9 Patient

merge

The system should have the capability to merge 2 records

under a single record and allow searching for either

record resulting in one final search result of merged

identity.

Desirable

HIS/1.10 Patient

merge

The system should have the capability to let the end user

choose the visits and records which need to be merged.

Desirable

HIS/1.11 Patient

merge

During the merge process, across the system except for

super users, the normal users should be able to see only

one record.

Desirable

HIS/1.12 Patient

Unmerge

The system should have the capability to unmerge the

merged records

Desirable



of 29



Vendor

Remarks

HIS/1.13 The system should have the capability to control if end

user is allowed to choose the visits and records which

need to be unmerged and also the association of all the

transactions to the right Patient Unique ID and the visits

and if access is not granted, system should automatically

decide unmerge rule.

Desirable

HIS/1.14 Demographi

c Profile

The system should have capability to capture dependant

information against a patient profile and also maintain a

family tree association where applicable to enable

reviewing family records where necessary. Linking of

mother and child record or donor and recipient record

should also be supported.

Desirable

HIS/1.15 Pre-

Registration

The system must have support for bulk registration in case

of mass patient enrolment from medical camps as well as

have a provision to perform pre-registration which can

later be converted to a permanent registration

Desirable

HIS/1.16 Eligibility The system must have support for capture of patient

eligibility along with registration process which can include

payor plans, authorizations, effective dates for eligibility

etc. that will impact encounter wise invoicing

Important

HIS/1.17 Tagging The system must support tagging of patients as either VIP,

Free patient, staff etc.

Desirable

HIS/2 Appointment Scheduling

HIS/2.1 General The System shall support integrated scheduling of

appointments and resources across the organisation.

Critical

HIS/2.2 General System shall be able to retrieve the patient’s demographic

data captured with capability to update/make changes.

Critical

HIS/2.3 General System should allow different kinds of appointments

namely Appointments with Doctors, Multi Appointment

(Appointments across multiple dates with a single doctor,

or appointments with multiple doctors on a single day or a

Critical



of 29



Vendor

Remarks

combination), Diagnostic appointments, Check-up

appointments, follow up visits.

HIS/2.4 General The Appointment Scheduling module will be used:

• To minimise patient’s waiting time.

• To flag No-Show patients.

• To optimize resource utilization

Critical

HIS/2.5 General System shall allow online booking of appointments. Desirable

HIS/2.6 General Upon confirmation of an appointment, notification must

be sent to the patient via SMS and email/Fax. Also

reminders via SMS should be sent x no of hours before the

appointment. This is applicable only to those cases which

are not walk ins.

Important

HIS/2.7 General The System will allow for multi-step appointments to be

created. For ex: if the patient first has to get a lab test

completed and only after the report is available, the

patient’s appointment with the doctor needs to get

confirmed.

Desirable

HIS/2.8 General The above multi-steps cancellation and/or re-scheduling

rules needs to be taken into consideration.

Desirable

HIS/2.9 General System shall alert in the event of any appointment clashes

or future appointments including during admission.

Important

HIS/2.10 General System shall generate appointment slips with details

including Date, Time, Room No, Doctor Name, Token

number, etc. These details should be configurable by the

end user.

Critical

HIS/2.11 General It is preferable that the scheduling screen depicts a

calendar view similar to outlook or mac calendar

Important

HIS/2.12 General Alert or prompt rules should be configurable and by

default should consist of conflict rules, duplicates, etc.

Important



of 29



Vendor

Remarks

HIS/2.13 General The system should handle resource planning and this

should include resource definition, resource time slot

planning, appointment transfers, appointment slot

swapping features, etc.

Critical

HIS/2.14 General Types of appointments include one-to-one, one-to-many,

many-to-one and many-to-many combinations and all of

them needs to be handled by the system

Critical

HIS/2.15 General The system should accommodate overbooking and

forced booking functionalities based on configurable

rules.

Critical

HIS/2.16 Reports System should have inbuilt reports for Daily appointment

lists, no show lists, cancellation lists, etc.

Critical

HIS/2.17 Communica

tion

System should have support to generate reminder

messages to be sent to patients/attendants based on

context of schedule or appointment – e.g. Reminders on

confirmed consultation appointments, reminders based

on vaccination schedule

Desirable

HIS/2.18 Booking System must allow for bulk management of appointments

including bulk booking of multiple patients into a slab /

timeframe or allow for bulk re-scheduling or cancellations

based on resource constraints that are unplanned – e.g.

Doctor on emergency leave or delayed due to other

critical cases outside of the OPD setting

Important

HIS/3 Outpatient Management

HIS/3.1 Billing System should cater to both Pre-Billing and Post-Billing

scenarios.

Critical

HIS/3.2 Billing System should auto alert cashier desks/stations for a

patient's bill collection.

Important

HIS/3.3 Registration System should have the ability of Pre-Registration (Online),

Self-Registration (Kiosk and/or Web), and interfacing with

payment gateway.

Desirable



of 29



Vendor

Remarks

HIS/3.4 Triage The system should have the ability to capture basic clinical

information from a nursing desk or by a junior doctor.

Critical

HIS/3.5 EMR The ability to view the patient's EMR by the consulting

doctor at any point of time is a must. Also, the EMR should

be accessible by multiple doctors at the same time but

only the first doctor would have read/write rights and rest

all would have read only rights. Provision to have intuitive

user interface to see the continuity of care in case sheet

style and book flip style.

Critical

HIS/3.6 CPOE The consulting doctor should have access to the order

entry module.

Critical

HIS/3.7 Information Through the system, users must be able to pass information

securely similar to a messenger or a chat application. The

same should be stored and audited.

Desirable

HIS/3.8 Quality It is desirable that the system can track turnaround times

for various activities and escalates when the TAT are

missed.

Desirable

HIS/3.9 Worklist Doctors OPD patient worklist should be configurable

based on various criteria

Desirable

HIS/4 Admission, Discharge & Transfer

HIS/4.1 Admission System should be able to handle different kinds of

admission namely Pre-Admission(online), Direct Admission,

Emergent Admission, Walk-in Admission, Referral Admission

and Planned admission

Critical

HIS/4.2 Admission System should have the ability to provide with a bill

estimation at the time of admission. Further system must

also have capability of admitting under joint

management such that billing and apportioning of

expenses is possible to respective medical

conditions/disciplines.

Important



of 29



Vendor

Remarks

HIS/4.3 Admission The system should show a graphical representation of

available and occupied beds in the hospital. The system

should be able to

search for beds based on multiple criteria, e.g. vacant

bed, vacant beds user a particular speciality, beds of a

particular class (e.g. deluxe) that are under housekeeping

– about to become vacant, etc.

Important

HIS/4.4 Admission The system should capture details of the guarantor and/or

Insurance/TPA/Corporate/CGHS/ESIC details.

Critical

HIS/4.5 Transfer The system should have the ability to transfer a patient

from one ward to another based on configurable business

rules.

Critical

HIS/4.6 Transfer The system should have the ability to transfer the patient

from one admitting consultant to another.

Critical

HIS/4.7 Transfer The system should have the ability to transfer based on

configurable billing rules like retrospective billing, etc.

Desirable

HIS/4.8 Discharge The system should have configurable workflow based

discharge. From Clinical discharge to Physical discharge,

there could be multiple steps involved based on each

individual hospital's workflow and they should be

configurable in the system. Ex: Pharmacy Discharge,

Diagnostic discharge, Financial discharge, etc.

Critical

HIS/4.9 Discharge The system should send alerts about the discharge status in

real time to the relevant actors.

Critical

HIS/4.10 Discharge The discharge summary/detail report should be

configurable and should have the ability for the hospital to

decide which transactions during the patient's journey

should become a part of the discharge.

Critical

HIS/4.11 Transfer The system should support transfer of care from ER/EM

(emergency care) to Inpatient care without having to

close and re-open a new encounter – this should also

Desirable



of 29



Vendor

Remarks

support combining of charges into a single IP Invoice

HIS/5 Bed & Ward Management

HIS/5.1 Bed Mgmt. The system should have the ability to create different kinds

of bed and associate it with multiple attributes. Ex: Normal

bed which is billed on a daily (24 hour) basis and has a

bassinet and ventilator attached to it which will be

charged at a certain value.

Critical

HIS/5.2 Beds should be billed either on a hourly basis or daily basis Critical

HIS/5.3 Bed Census report is required Critical

HIS/5.4 The available, occupied and under maintenance beds

should also be shown in a graphical representation

Desirable

HIS/5.5 Ward Mgmt. The system should provide the ability to certain users to

order, track and return consumables, medications, etc.

from the ward management screen

Important

HIS/5.6 Ward Mgmt. The system should track diet/food orders and returns. Important

HIS/5.7 Ward Mgmt. The system should provide the overall status of a ward at

any given instance in terms of pending orders, bed status,

housekeeping requests, etc.

Critical

HIS/5.8 Bed Mgmt. Scheduling of housekeeping and maintenance activities Critical

HIS/5.9 Bed Mgmt. Should facilitate the estimation of appropriate waiting

times for patients

Important

HIS/5.10 Bed Mgmt. Forecasting of bed availability based on all vacant beds

and all potential beds that can be made available based

on planned discharges and planned maintenance tasks

on blocked beds

Desirable

HIS/6 CPOE

HIS/6.1 General The system should gave the ability to handle different kind Critical



of 29



Vendor

Remarks

of orders namely medications, IV, Radiology, Laboratory,

Blood, Procedures, Nursing, Diet, etc.

HIS/6.2 General The system should track the orders - ordering, status,

administration (where applicable) and results without

losing information and in real time.

Critical

HIS/6.3 General Orders should be processed by the relevant actors by

providing them the information through worklists/

dashboards or similar functionalities.

Critical

HIS/6.4 General Orders progress needs to be recorded through relevant

screens and the same should be visible in real time to the

relevant actors. For ex: Lab order when processed and the

report is available, the same should be visible to the

ordering doctor in the EMR.

Critical

HIS/6.5 Results The system should have the ability to enter multiple levels

of results. Ex: Unverified results, Verified results and

authorized results.

Critical

HIS/6.6 Results Based on configurable rules, the results should appear in

the EMR at the right stage (Unverified/Verified/Authorized)

Critical

HIS/6.7 Order Sets The ability to create order sets based on problem,

diagnosis, doctor or pathway is desirable.

Desirable

HIS/6.8 Medication

Orders

The ability to order for medications based on types of

medications is critical. Ex: Variable dosing, Sliding Scale,

Tapering dose, etc.

Important

HIS/6.9 Medication

Orders

The system should interface with drug database to

provide both default dosage details while prescribing

medications as well as provide decision support alerts for

contraindications or interactions

Important

HIS/6.10 IV Orders The system should have the ability to order for the right

kind of IV and with built in rules depending on the drip

rate, type of IV, and the mode of delivery - Bags, Infusion

pumps, etc.

Important



of 29



Vendor

Remarks

HIS/6.11 Radiology The system should mandatorily send basic clinical

information along with the radiology order as per HL7

guidelines.

Critical

HIS/6.12 Laboratory The system should be able to handle different kind of lab

orders and the results, such as Pathology, Histopathology,

Microbiology, Cyto-Genetics, Immunology, etc.

Important

HIS/6.13 Results The results should have the ability contain text, images,

audio and video and should be stored in the EMR.

Desirable

HIS/6.14 Results The results should be sent to EMR in real time. Critical

HIS/6.15 Results The system should have the ability to create reports based

on the due date of results.

Important

HIS/6.16 Surgical

Procedures

System should support workflow to order/initiate surgical

procedures and schedule such procedures within a

surgical theatre complex

Important

HIS/6.17 Diet Module Recording of Dietics Visit (Prescription) & Billing Critical

HIS/6.18 Diet Module View of Treating Doctor's recommendations Important

HIS/6.19 Diet Module Diet/Meal Plan Critical

HIS/6.20 Diet Module Interface with F&B Module for Diet preparation Important

HIS/6.21 Diet Module Alerts of new Admissions, Transfers and Diet

recommendations

Important

HIS/6.22 Discharge

Summary

Multi-Level Templates (Unit, Department, User Group, User) Critical

HIS/6.23 Speech to Text Support Important

HIS/6.24 Macro based Reporting Feature Important

HIS/6.25 Import EPR entries (Investigation Results, Illness History,

Treatment Record etc.)

Important

HIS/6.26 Capture Pictures and Annotations Important

HIS/6.27 Diet Module Preparation of meal tickets that can be used to affix on

meals for delivery that contain patient and location

details for smoother management of logistics of meal

delivery

Important



of 29



Vendor

Remarks

HIS/7 Pharmacy

HIS/7.1 General The worklist show the Inpatient, Outpatient, Emergency

orders against the patient/ward

Critical

HIS/7.2 General The system should show the return requests against a

patient/ward in a worklist.

Critical

HIS/7.3 General The dispensing should be based on closed loop of

medication principles.

Critical

HIS/7.4 General It is desirable to have the drug details including

monograph, interactions, etc. shown to the pharmacist on

the relevant screens.

Desirable

HIS/7.5 General Drug and Patient search capabilities to be available Critical

HIS/7.6 General The system should be able to show the available drugs

based on batch details and should be dispenses on First

Expiry First Out principle. (FEFO Model)

Important

HIS/7.7 General Controlled substances and narcotics should be stored

separately and should be accounted for based on

governmental regulations. Reports for the same to be

available.

Critical

HIS/7.8 Stock Stock movement should be tracked Critical

HIS/7.9 Stock Stock requests, indentation, receipt functionalities to be

available

Important

HIS/7.10 Label The ability to print labels in multiple languages and the

data that needs to be printed on a label should be

configurable.

Critical

HIS/7.11 Label Labels should be printed automatically on pre-defined

network printers in real time or in batch mode.

Critical

HIS/7.12 Label Directions for usage of medications should also be

available and should be configurable.

Important

HIS/7.13 OTC It is desirable to have Over the Counter sale functionality Desirable

HIS/7.14 Inpatients It is desirable to have medication list functionality at a

ward level

Desirable



of 29



Vendor

Remarks

HIS/7.15 Reports Reports are extremely important and at the minimum

should print patient (OP) bills, stock lists, regulatory reports,

etc.

Critical

HIS/7.16 General Bar Code Enabled Important

HIS/7.17 Medication Maintenance of Generic and Brand Mapping Important

HIS/7.18 Medication Drug Substitution based on common attributes across

trade names/brand names of drugs / medications

Critical

HIS/7.19 Medication Interface with Third Party Drug Database Critical

HIS/7.20 Medication Batch, Expiry Management Critical

HIS/7.21 Pharmacy Dispensing & Inventory management - Should support all

the standard processes of In-Patient and Out-Patient

Pharmacy within a Hospital. This module should also

support processes of sub-stores like Operation theatre,

Procedure rooms etc. A robust inventory control with audit

trail should form the backbone of the system. The standard

processes to be supported include Material Receipts,

Issues, Transfers, Dispensing, Stock Tracking, Stock Taking,

Automatic Indenting

Critical

HIS/8 Nursing Management

HIS/8.1 General The nursing personnel should have access to their worklists

based on their activity within OPD, Inpatient wards,

OT/Surgical wards and/or ICU.

Critical

HIS/8.2 General The nursing personnel based on access control should

have access to EMR

Critical

HIS/8.3 Orders The nursing personnel should be able to place orders on

behalf of a doctor or due to verbal orders after

documenting the same.

Critical

HIS/8.4 Orders The nursing personnel should be able to start the

discharge process on behalf of a doctor based on verbal

orders, and after documenting the same.

Critical



of 29



Vendor

Remarks

HIS/8.5 Documentat

ion

Clinical documentation features in terms of Triage notes,

Progress notes, visit notes should be available.

Critical

HIS/8.6 Care Plans It is desirable to have Nursing Care Plans functionality. Desirable

HIS/9 Laboratory

HIS/9.1 Worklist All lab orders should be reflected in the respective

user/sub-department worklist

Critical

HIS/9.2 Worklist The status of all the lab orders should be reflected in real-

time within the worklist

Critical

HIS/9.3 Workflow As the workflow of the lab process within each sub

department typically differs from hospital to hospital, it is

important to have configurable workflows or desirable to

have an inbuilt workflow engine.

Important

HIS/9.4 Rules The rules for TAT, result validation, result entry, etc. differ

and hence it is important to have configurable rules or

desirable to have an inbuilt rules engine.

Important

HIS/9.5 Results Results must be in real time updated in the EMR and also

the configurable alerts need to be sent to the respective

users.

Critical

HIS/9.6 Laboratory Customizable workflows Critical

HIS/9.7 Laboratory Customizable alerts for critical values Critical

HIS/9.8 Laboratory Laboratory KIT Management Critical

HIS/9.9 Laboratory Support for Digital Signatures Important

HIS/9.10 Laboratory Standards based Uni Direction / Bi Directional interface to

Various Analyzers

Critical

HIS/9.11 Reports List of reports need to be available and at the minimum

Individual Test reports, consolidated detail/summary

patient report, stock report, worklist reports, etc.

Critical

HIS/9.12 Reports Ability to compare previous results and perform a delta

check

Important

HIS/10 Billing & Insurance



of 29



Vendor

Remarks

HIS/10.1 Integration Billing module needs integration with almost all the

modules within the system starting from Registration and till

Finance, Procurement and Inventory. So the interfaces

need to be robust and well tested.

Critical

HIS/10.2 Integration Integration to orders, registration, appointment, admission

is a must

Critical

HIS/10.3 Integration Integration with AR, AP and GL is important Important

HIS/10.4 General The main worklist should have the ability to filter the list

based on type of patient (IP, OP, A&E, Day-care, External,

etc.), type of Payer (Insurance, Cash, TPA, Corporate,

CGHS, etc.)

Critical

HIS/10.5 General Cash Counter tracking and auditing functionalities

including reports

Critical

HIS/10.6 General The system should able to generate Trial, Instant and Final

invoices in real time.

Critical

HIS/10.7 General The system should have the full-fledged functionalities of

Invoice, Deposits, Refunds, Settlements, and interfaces to

credit and debit notes

Critical

HIS/10.8 General It is desirable to have a patient ledger functionality, where

the billing details of a patient across all his/her visits are

stored

Desirable

HIS/10.9 Reports Reports are critical and at the minimum should consist of

Patient Invoice, Patient Settlement, Deposit, Refund,

Counter wise - Shift wise collection report, Day wise

summary/detail report, etc.

Critical

HIS/10.10 Reports Dashboards are a desired functionality Desirable

HIS/10.11 Insurance The ability to define different types of payers is critical Critical

HIS/10.12 Insurance The system should handle pre-authorizations, claim

preparation, claim submission and reconciliation

functionalities.

Critical



of 29



Vendor

Remarks

HIS/10.13 Insurance The system should be able to handle different charges for

the same order (test/service/consumable/etc.) different

payers through configuration and also manage printing of

payer specific terminology(Codes and descriptions)

Critical

HIS/10.14 Packages The ability to define fixed and variable packages based

on configurable billing rules is critical

Critical

HIS/10.15 Rules It is important that the billing rules are configurable and

desirable that system has an inbuilt rules engine.

Important

HIS/10.16 General System should support collection of advance

payments/deposits either at a patient level which can be

later utilized across visits or at a specific visit level for

adjustment during closure of visit

Important

HIS/10.17 General System should support definition of alternative

Nomenclature of services and products based on payer

guidelines in order to generate payer invoice based on

such specific nomenclature or grouping.

Important

HIS/10.18 General System should be able to allow customization of invoice

formats based on payer preferences

Desirable

HIS/10.19 General System should be flexible to define various levels of

taxation and other applicable surcharges based on

regulatory guidelines in the region

Important

HIS/10.21 General System must support charging for one or more surgical

procedures performed within the surgical care setting with

flexible rules to determine charge dynamics based on

primary procedure, surgeon preferences and packages

assigned

Important

HIS/10.22 Billing (RCM) Multi-Dimensional Tariff structure Desirable

HIS/10.23 Billing Support for Multiple versions of tariff Desirable

HIS/10.24 Billing Facility to create multiple Tariffs Desirable

HIS/10.25 Billing Support for Hospital / Company (CGHS, Arogyashree, ESI)

nomenclatures for services

Critical



of 29



Vendor

Remarks

HIS/10.26 Billing Flexible settlement options (Credit, Cash, Cards, and

Coupons etc.)

Critical

HIS/10.27 Billing Interface / Integration with Swipe card machines Critical

HIS/10.28 Billing Facility to accept deposits against Patient ID (MR No) and

subsequently apply the same to all types of bills

Critical

HIS/10.29 Billing Support Tariff conversions for OP, IP, Day Care and

Emergency Billing

Critical

HIS/10.30 Billing Support for Bills in Process (BIP) for inter-unit Transfers Critical

HIS/10.31 Billing Alerts for Pending bills Critical

HIS/10.32 Billing Alerts / reminders for deposit collection Critical

HIS/10.33 Billing Support for comprehensive discount/Concessions process

with ability to authorize partial or full write off in case of

non-payments

Critical

HIS/10.34 Billing &

Collection

Advance Collection (Patient Specific or Multi-patient)with

ability to allocate advances to a specific visit or utilize the

advance across multiple visits.

Important

HIS/10.35 Settlement of Deposits Critical

HIS/10.36 Billing based on Corporate or PSU (Price and Naming) Important

HIS/10.37 Bill Submission and Receivable Tracking Important

HIS/10.38 Aging of Receivables Important

HIS/10.39 Localization of Tax's (VAT, Services etc.) Critical

HIS/10.40 Refunds from Advances Critical

HIS/10.41 Refunds against Billed Items (with Approval workflows) Critical

HIS/10.42 Visitor Pass (Interfaced with Billing) Important

HIS/10.43 Clearance for Surgery/Procedure, Discharge Important

HIS/10.44 TPA/Insurance Workflow Important

HIS/10.45 Insurance Authorization Amount Interface with Billing Important

HIS/10.46 Date wise Billing to Patient Important

HIS/10.47 Contracts Inclusion and Exclusion of Service Items based on Payer

(Quantity and Amount Based)

Critical



of 29



Vendor

Remarks

HIS/10.48 Contracts Price Master Important

HIS/10.49 Contracts Billing override tracking Important

HIS/10.50 Contracts Billing of combined and dependent Items (Surgery, Re-Do,

OT, Anaesthesia charges)

Important

HIS/10.51 Doctors

Payout

Service based definition of Fee Structure Important

HIS/10.52 Doctors

Payout

Recording of Services rendered from

Billing/Ordering/Payment Realization

Important

HIS/10.53 General Automated and Manual Discounting based on Business

Rules with feature to define discounts for a period,

discounts with user based limits etc.

Essential

HIS/10.54 OT Billing Billing Enquiry for OT Cases (Surgery Clearance) Important

HIS/10.55 Patient

Billing

Package subscription with support for managing a single

package across multiple visits/encounters

Critical

HIS/10.56 Patient

Billing

Billing Estimates and Counselling Forms Important

HIS/10.57 Payor Billing Credit Billing for PSU and Insurance customers Important

HIS/10.58 Payor Billing Receivables Management (Aging and Collection) Important

HIS/10.59 Payor Billing EDI Gateway Desirable

HIS/10.60 Payor Billing Eligibility Inquiry and Response Important

HIS/10.61 Payor Billing Claim Status Inquiry and Response Important

HIS/10.62 Payor Billing Request from Provider and Response from Health Plan or

Administrator

Important

HIS/10.63 Payor Billing Claims Management / Adjudication Important

HIS/10.64 Package

Billing

Flexibility to define mode of revenue recognition on

package invoices and also support for managing consults

within package where doctor is assigned dynamically at a

later stage once all results are available for consultation in

case of OPD packages

Important

HIS/10.65 Package

Services

Ability to track incomplete package services and prompt

for such services to be completed in a forthcoming visit

Desirable



of 29



Vendor

Remarks

HIS/10.66 Ad-hoc

Billing

Ability to allow miscellaneous billing (in case some masters

are yet to be configured and billing needs to be done

immediately) with restriction in terms of access rights

Desirable

HIS/11 Reporting Services

HIS/11.1 General System must have capability to generate various statistical

and analytical reports based on key performance

indicators of the organization

Critical

HIS/11.2 General System must allow representation of report related

information in multiple formats including a combination of

tabular and graphical outputs with ability to drill down

from summary based reports

Important

HIS/11.3 General System should allow personalization of dashboards that

consolidate specific set of reports based on user

preference

Desirable

HIS/11.4 General Multi-format reports like tabular, graphical etc. from

RDBMS, XML Based Data Source

Critical

HIS/11.5 General Use for Scheduling Report Processing or accessing Reports

on Demand

Critical

HIS/11.6 General Use for publishing various Reports Important

HIS/11.7 General Reports can be exported to various formats HTML,PDF,XML,

E-Mail etc.

Important

HIS/11.8 General Add interactive features by providing links to sub reports

and drill through reports

Important

HIS/11.9 General Ability to customise and personalize individual user

dashboards and configure alerts/reminders upon

dashboards being populated with relevant information

that requires immediate attention

Desirable



of 29

TECHNICAL REQUIREMENTS



Vendor

Remarks

HIS/Tech

/1

User Interface

HIS/Tech/

1.1

Client The system should be web based and should be browser

agnostic i.e. it must be able to run on most popular

browsers such as Microsoft Internet Explorer, Apple Safari,

Mozilla Firefox and Google Chrome browsers

Critical

HIS/Tech/

1.2

Client Must support multi lingual interfaces Important

HIS/Tech/

1.3

Client Should be able to run in multi windows Desirable

HIS/Tech/

1.4

Client The system should have the capability where the end users

can define keyboard shortcuts in real-time.

Important

HIS/Tech/

1.5

Client able to suspend use after a present period of inactivity Critical

HIS/Tech/

1.6

Client Usage of icons is strongly recommended Critical

HIS/Tech/

1.7

General Ability to reach the desired functionality in less than 4 clicks

is strongly recommended from login completion step.

Important

HIS/Tech/

1.8

General Ability to achieve single sign on in case of multi-solution

environment

Desirable

HIS/Tech/

1.9

General Password management to prompt users to manage their

password changes on periodical basis based on password

policy

Desirable

HIS/Tech

/2

Architecture

HIS/Tech/

2.1

General The system should have the ability to be hosted on a

private/public cloud infrastructure

Critical

HIS/Tech/ General The system should have been designed to be modular and Critical



of 29

2.2 scalable

HIS/Tech/

2.3

General It is preferable that the system was designed to handle

multi tenancy and multi-location requirements.

Important

HIS/Tech/

2.4

General It is desirable that the system has inbuilt workflow and rules

engines

Important

HIS/Tech/

2.5

General Ability to run on clustered environments to provide high

availability

Important

HIS/Tech

/3

Database

HIS/Tech/

3.1

General It is preferable that the system uses industry standards like

ANSI SQL

Important

HIS/Tech/

3.2

General It is preferable that system provides a full-fledged data

dictionary.

Important

HIS/Tech/

3.3

General Referential integrity must be enforced Critical

HIS/Tech/

3.4

General Central master tables should be used by multiple modules Critical

HIS/Tech/

3.5

General Please mention the database backup features and how

they are used by the system natively.

Critical

HIS/Tech/

3.6

General All activity in the system, be it related to patient

registration, EMR, CPOE, stock management, etc. should

be auditable.

Critical

HIS/Tech/

3.7

General System must allow configuration to control which activities

must log audit data so at to optimise the overhead and

disk storage space used. This should be feasible using end

user interface without having to programmatically extract

such data each time.

Important

HIS/Tech

/4

Integration & Interfaces

HIS/Tech/

4.1

Integration It is desirable that the system has an inbuilt integration

engine

Desirable

HIS/Tech/

4.2

Integration It is critical that the system has the ability to communicate

with other Healthcare Informatics systems via HL7 V2.x

Critical



of 29

messages

HIS/Tech/

4.3

Integration It is Desirable that the system has the ability to

communicate with other Healthcare Informatics systems

via HL7 V3 messages

Critical

HIS/Tech/

4.4

Integration It is desirable that the system has pre-built interfaces with

SAP, Oracle and/or Tally

Desirable

HIS/Tech/

4.5

Integration It is important that the system has the ability to

communicate with lab equipment (Uni/Bi Directional

interfaces)

Important

HIS/Tech/

4.6

Integration It is desirable that the system has the ability to

communicate with Patient Monitoring devices, Infusion

pumps and/or other medical devices

Desirable

HIS/Tech/

4.7

Integration System must have capability to adhere to national

guidelines and standards that are in use to contribute

towards interoperability of EMR/EHR data as well as

standard related to patient safety and quality (e.g. NABH,

NABL)

Important

HIS/Tech/

4.8

Integration System must have capability to integrate with third party

systems to enable adoption of digital signatures, speech to

text conversion, drug database decision support,

electronic claim management etc. and facilitate

compliance to standards that warrant error free

transactions.

Desirable

HIS/Tech

/5

Deployment

HIS/Tech/

5.1

General It is critical that the system can be deployed on a

private/public cloud environment

Critical

HIS/Tech/

5.2

General It is desirable that the system can work as a SaaS model Desirable

HIS/Tech/

5.3

General It is critical that the system has at least 99.9% uptime. Critical



of 29

COMPLEMENTING SERVICES

S. No. Functional

Service

Sub Module/

Function Remarks Importance

HIS/Comp/1

HIS/Comp/1.1 Training HIS Modules Vendor should extend effective training sessions on all the HIS

modules supplied. Training personals must be from healthcare

domain background with relevant implementation

experience

Critical – For a

complete /

successful

implementation

HIS/Comp/1.2 Post

Implementation

Support/

Maintenance

Constant Client

Interfacing

24/7, well defined / structured service levels to be extended

by the vendor for post implementation maintenance. The

levels of support should be determined keeping 99.99% of

uptime of the application without disturbing hospital

operations. Extensive / elaborated support models to be

offered with defined team members coming from healthcare

implementation / support experience

Critical

HIS/Comp/1.3 Data Migration

Services

Masters/

Demographics

Vendor should extend the minimum master / demographic

data migration required to use the new application.

Important

HIS/Comp/1.4 Mater Data

Mgmt.

Starter Data Sets Vendor should extend support in providing pre-populated

master data / starter data sets based on a combination of

industry standard code sets as well as best practices of other

institutes where information on master data structures can be

exposed to other clients. This will result in reducing turnaround

time on system configuration

Desirable

-- END OF DOCUMENT --