*Cost of Tender: Rs.

2000/-
(Rs. Two Thousand only)

BID DOCUMENT

for

HMIS-LAN
Hospital Management Information System
&
Local Area Networking
for
Sir Sunderlal Hospital

ON

TURNKEY BASIS

Institute of Medical Sciences

Banaras Hindu University
Varanasi
Important:
*Those who download this documents from the website are required to submit cost of Tender document that is
Rs 2000/( Two Thousand only) alongwith tender document payable in a form of Bank draft in favor of
Registrar Banaras Hindu University.

BID CHECKLIST

Bidder is required to fill-up this checklist and enclose alongwith the envelope containing the Earnest Money.
Sl. Item Description Yes/No Bid Reference
1. Earnest Money Enclosed
2. Bid Submitted in Triplicate
3. Soft Copy of the Bid Submitted
4. Validity of the Bid-180 Days
5. If the SI Vendor is not the Owner of the
Product(s)/Service(s) offered under the scope of this
project, a letter from a duly constituted attorney of
the Owner(s) of such product(s)/service(s) attached,
authorizing the SI Vendor to bid as a Consortium
Leader for the Bid
6. In case of a Consortium Bid, copy of the MOU
between the Consortium members attached
7. Un-priced, detailed, item-wise Bill of Material
provided as an appendix along with the Technical
Bid
8. Duly answered prequalification questionnaire with
documentary proof
9. Duly filled in HMIS functionality requirements
attached with Technical Bid

2
 Prequalification Criteria

Pre qualification criteria for the participating bidders are given below –

1. The bidder (or the consortium partner as defined in Para 4.2 hereinafter to e referred to as SI vendor) should
have implemented Hospital Management Information System including PACS and Medical Education
System software at a hospital including for an attached medical college/Large Corporate Hospitals that has
750 or more bedded and it should be running satisfactorily for more than 2 years as on date of the submission
of bid. A letter of satisfactory performance from the Chief Medical Officer or Administrative Director of the
hospital in which it is running should be enclosed along with the bid.

2. The software should be ICD – 10, HL – 7, DICOM, ASTM, CPT compliant and the bidder or consortium
partner should be able to demonstrate the compliance as described in para 1.,at a location described above
within 15 days after opening of the technical bid.

3. The bidder or the consortium partner should be able to demonstrate the application software for the Hospital
Management System at a location where they have implemented these systems covering most of the
functionalities within 15 days after opening of the technical bid. This will be evaluated along with the
verification of the performance of the system requirement detailed in the PreQualification Questionnaire
(Appendix A).

4. The software offered should be based on platform independent vendor agnostic architecture (like J2EE),
enabling it to be interoperable, modular in design, thin client compatible and be able to integrate seamlessly
with Laboratory Information System, Radiology Information System including PACS and Telemedicine.

5. The software should feature integrated data analysis capabilities that can be used for Decision Support
System.

6. The bidder or the consortium partner should specify the qualifications and experience of the domain
specialists and experts in the implementation team, the software design and R & D team at the software
development center.

7. The bidder or the consortium partner should be in a position to station adequate manpower to complete the
entire implementation in a time period of less than 12 months from the placement of the order.

8. Implementing a HMIS is more of a Change Management challenge than installing and implementing a
technology based product. Hence the project manager who will be working on the project should be PMP
certified. Please enclose CV’s of proposed Project Managers along with bid. The bidder should also give
details of the hardware, software, networking, application software and change management specialists for
the respective areas of installation and implementation of the system.

9. The bidder or the consortium partner should have implemented a multi site, multi campus LAN / WAN
covering at least 500 + nodes (with minimum backplane speed of 1 GBPS) implemented in 750 or more
bedded hospital described above and it should be running satisfactorily for more than 2 years as on date of the
submission of bid.

10. The bidder or the consortium partner should have implemented a server farm with redundant and failover
servers in 750 or more bedded hospital described above and it should be running satisfactorily for more than
2 years as on date of the submission of bid.

3
Index

1.Introduction...................................................................................………………... 6
2 Project Scope…………………… ....................................................................…… 7
2.1 Scope of work..................................................................................…………..….. 7
2.2 Components of Scope of Work…….……………………….............................….. 7
2.3 Supervisory Committee Formation ........................................….............……...…. 8
2.4 Project Execution Approach & Methodology...........................…..........…………. 8
2.5 Documentation .................................…..............………………………..……… 9
2.6 Facility management service……....…............................................…............ . 9
2.7 Guaranteed Uptime …….........................................................................………… 9
2.8 Downtime Penalty…........................................................................………..……. 9
2.9 Services & Service Level Requirements............................................................…. 10
2.10 Project & Technical Risk Management Plan & Procedures ... ..........…….. 11
2.11 Time line…………………..........................………..................... ..........…….. 11
3.Payment Terms...........................................................................................……….. 12
3.1 LAN & Hardware implementation …………………………………….….……… 12
3.2 Facility Management Service……………………………………….……………. 12
3.3 Other Information related to Payment Terms………………….………………... 12
4. General Information for SI………………………………………..…………….. 14
4.1 Bid Submission ………….…………………………………………………….. . 14
4.2 Consortium………………………………………………………..……….……. 15
4.3 The University and SI Memorandum of Understanding (MOU)………..……… 15
4.4 Amendments of Bidding Document ………………………………..……….….. 16
4.5 Tender Bid Clarification………………………………………………………… 16
4.6 Governing Language ………………………………………………….……..… 17
4.7 Bid Validity ……………………………………………………………………. 17
4.8 Force D’Majeure ………………………………………………………………. 17
4.9 Late Bids ……………………………………………………………………….. 17
4.10Modification and withdrawal of Bid Document .…..…………………………… 17
4.11Canvassing………………………………………………………………………. 17
4.12Right to vary quantities at the time of award………………………….………. . 17
4.13Bid Processing Fee ……………………………………………………….….…. 18
4.14Earnest Money Deposit ……………………………………………….………….. 18
4.15 Ownership of Data ……………………………………………….……….…… 18
4.16 Change Management ……………………………………………….……….…. 18
5. Project Requirements…………………………………….………….……….…. 18
5.1 Network ………………………………………………………….………….… 18
5.2 Functionality Requirements…………………………………….…………… 19
5.3 Essential Standards………………………………………………….………... 23
5.4 Application Architecture ………………………………………………..….. 24
5.5 Innovative Solutions ………………………………………….…………….... 25

6 Project Requirements........................................................................................…. 26
6.1 Hospital Management Information System (HMIS) ............................................. 26
6.2 Hardware Requirements for HMIS…………...........................................………….. 29
6.3 Picture archival & Communication System (PACS) ...................................……....…..29

7 Bid Evaluation............................................................................................…..………....31

8 Financial Bid…………………………………………………………………….….. 33

4
 TENDER DOCUMENT FOR: Hospital Management Information System – LAN in
S.S.Hospital

BID REFERENCE HOSPITAL MANAGEMENT

INFORMATION SYSTEM - LAN
DATE OF COMMENCEMENT AND SALE
18.12.2009
OF BIDDING DOCUMENT
LAST DATE & TIME FOR SALE OF
06.01.2010
BIDDING DOCUMENTS
LAST DATE AND TIME FOR RECEIPT
07.01.2010
OF BIDS
ADDRESS FOR COMMUNICATION THE Dy. REGISTRAR & CAO, SSH, BHU,
VARANASI – 221 005

Advertisement to be released in following News Papers :

1. Times of India (Delhi Edition)
2. The Hindu (All Editions)
3. The Details of the Tender Documents will be available on imsbhu.nic.in, bhu.ac.in

5
OBJECTIVE: In order to overcome the management and administrative difficulties, SS H desires to implement a
Hospital Management Information System (HMIS). The above systems would be implemented on a Local Area
Network (LAN) in order to replace the existing manual paper based system on a turnkey basis. The key point of the
new systems would be a graphical user interface in order to make the design user friendly and to enable the existing
staff to utilize the system with minimal training.

1. Introduction

Sir Sunderlal Hospital

Sir Sunderlal Hospital of the Institute of Medical Sciences, BHU established in the year 1926, initially with 96
Beds has grown into a 1000 bed Hospital (750 for Modern Medicine 127 for Ayurveda, Private 42 and 81 others)
with all modern medical, surgical and investigative amenities.

Sir Sunderlal Hospital of the Institute of Medical Sciences, Banaras Hindu University, Varanasi is only tertiary
care Hospital in Eastern Uttar Pradesh which caters to the health care needs of more than 15 crore population in
vast catchment area that includes Eastern UP, Bihar, Jharkhand, Madhya Pradesh, Chattisgarh and even
neighboring country Nepal.

The Hospital is primarily a teaching and training Hospital for the undergraduates (MBBS/BAMS), the
postgraduate (MD/MS/MDS/MD(Ay) /MS (Ay), the super specialty students (DM/Mch Students), Ph.D. ,BDS
research scholars, B.Sc nursing & training of paramedical staff. The Hospital gets nearly 2500-3000 patients
daily in its OPD.

The unique feature of the Hospital is that it renders specialty and super specialty services through Modern
Medicine, Ayurveda and Dental Sciences under one roof.

STATISTICAL INFORMATION
Requirement Remarks
Average number of Out-Patients registered per year 7,50,000 - 8,00,000
Average number of In-Patients registered per year 40,000 - 45,000
Average number of patients attending Casualty per year 55,000 - 60,000
Existing Bed Complements
Modern Medicine 750
Ayurveda 127
Special Ward 42
Others 81
Total 1000
Average number of operations done per year 25,000 - 30,000
Various investigations by different units 5,00,000 – 5,50,000

6
 2 PROJECT SCOPE

2.1 Scope of Work

The scope of work includes for Outsourcing of IT Services for Customization, & Implementation of an integrated
Hospital Management & Information System (HMIS) and Local Area Network (LAN). The University expects to
deal with a single vendor, who shall be a System Integrator (hereinafter referred to as —SI Vendor), who
would provide ALL the elements of the solution. The SI Vendor is expected to propose an integrated IT solution,
which includes off-the-shelf (i.e. readymade, integrated & customizable) items suitably adapted to the
University requirements.

SI shall be responsible for installing and implementing the HMIS, developing the LAN, supply of all the relevant
hardware and software products and operating the system for 5 years as a Facility Management Service. The
Terms of Reference under the scope of this Bid are listed below. The Payment Terms & details of the project
requirement are given in the next sections The contents of this Bid are only indicative in nature. SI may suggest
technically superior alternative, wherever applicable, along with the explanation. The major components of the
solution under the scope of this Bid are listed below:

2.2 Components of Scope of Work

The Components of Scope of Work are as follows:

2.2.1. Customization, Installation & Implementation of --
a) ) Hospital Management Information System (HMIS) which includes LIS , RIS, PACS, Telemedicine
and Medical college management system in an integrated manner. The University will have the option to
implement the various modules/products in a phased manner.
b) System security, including firewall, anti-virus solution, etc. as detailed in (5.4.7)

2.2.2. Installation of Hardware, including --

a) Appropriate Server(s) along with OS, associated database & other related software, for --
• HMIS, LIS, RIS, PACS , Telemedicine ;
• System security, including firewall, anti-virus solution, etc.
b) Desktop PCs or thin clients (as applicable) with OS & other related software;
c) Printers with associated software;
d) Associated hardware for Business Continuity & Backup;

2.2.3. Installation of IMS campus-wide LAN as detailed in 5.1

• This includes supply and installation of networking equipment & associated cabling infrastructure
• LAN installation incorporates laying down of Optical Fiber Cable (OFC), UTP cable and switches in the
campus after finalization of the networking map. A five year warranty and Facility management Service on
these products as proposed elsewhere in this Bid.
• The cable shall be laid at 1 meter depth, in HDPE pipe, with brick and sand bed with brick/concrete structure
covering.
• The SI shall furnish complete details of acceptance tests proposed to be conducted before handing over the
installation to the University.

2.2.4. User Training on --

a) HMIS;
b) System security.
c) PACS (when implemented)

7
2.2.5. Providing post-implementation Maintenance Support for all components listed above.

The SI is expected to provide complete specifications of all the products and services quoted for, together
with the details of the manufacturer. The University reserves the right to make appropriate verifications on
all the products / components.
2.3 Supervisory Committee Formation
• A supervisory committee shall be constituted which will review the progress and provide necessary advice
for mid-course corrections to the service provider. The committee will comprise of representatives of the
University, IMS and the SI .

2.4 Project Execution Approach & Methodology

The SI should propose a comprehensive strategy for project execution, which should clearly bring out the integration
of HMIS elements like HMIS, PACS, LIS and RIS. These will be implemented on a LAN. The SI should take up the
following sequence of activities during the course of project execution:
2.4.1 For Product Customization:
• System Study and Gap Analysis
Study the workflow and functional requirements at SSH/IMS
Estimate the exact customization effort & costs depending upon the requirements.
Present the Gap Analysis report and detailed findings as part of Gap Analysis Document (GAD)
Obtain sign off for GAD and agreement on the customization effort.
Prepare a detailed project plan for executing the project
Finalize the project reporting and project monitoring procedures
Finalize the training schedule and training participants along with the IMS team.

Customization
1. Prepare the Design Document (in case of enhancements)
2. Customization of HMIS modules
3. Prepare Unit Test plans (UTPs) and System Test Plans (STPs)

• System Testing
1. Execute System Tests
2. Review of System Tests results
3. Prepare User Manual

• Acceptance Testing
1. Install the application software in the User Acceptance Test (UAT) environment
2. Execute acceptance tests using the Acceptance Test data provided by the University
3. Document discrepancies and defects encountered in the course of acceptance testing
4. Jointly review with authorized University personnel the discrepancies and defects with a view to diagnosing
the nature of the problems
5. Attend to and fix the deficiencies/defects arising from the software not performing in accordance with the
GAD.
6. Once the discrepancies are resolved, repeat the necessary Acceptance Tests
7. Formal acceptance of the system by IMS

• Implementation
1. Deployment of the HMIS in the Production environment
2. Resolution of problems/bugs reported during support period

• For LAN Installation:

1. Implementation Methodology followed
2. Network Plan
3. Testing and Acceptance Criteria

8
The SI is required to specify the following in details in the Bid:

Implementation Methodology followed

Quality Plan
Project Team Structure
Review and reporting mechanism
Representative profiles of Key personnel
Project Implementation Timelines
Key Deliverables and Milestones

2.5 Documentation

It is the responsibility of SI to provide at least the following documents to IMS:

• Gap Analysis Document (GAD) or System Requirement Specification (SRS)
• Software Design Documentation (SDD)
• User Manuals
• Training Manuals
• Implementation Manuals

2.6 Facility management service

The SI, which will be finally awarded the project, shall be fully responsible for the entire HMIS, PACS, LIS and RIS
project integration, its implementation on the LAN and provide Facility Management Service [FMS] to maintain the
same. The SI shall provide complete onsite warranty and Facility Management Services including upgrade &
maintenance for a period of five years and this will be extendable. The SI shall permanently post its personnel for the
period of contract in the University campus, who shall be responsible for the overall operation of the system –
Network, Hardware and the entire software HMIS. LIS, RIS PACS, Telemedicine. This would also include addressing
and fixing any technical snags reported by the end user. The personnel should have minimum qualification of MCA or
B. Tech/BE with reasonable experience of handling a network of this size. The entire payment of the FMS for the
period may be included in the financial Bid. However the actual payments of FMS shall be made annually. The SI
shall be ready to make further customization / any changes in the code as the need may arise from time to time during
the above said period , without any extra financial cost.
SI shall be responsible for complete maintenance support for all the items supplied, day-to-day operations &
management of complete infrastructure including the desktop PCs.

2.7 Guaranteed Uptime

FMS shall ensure a guaranteed uptime of not less than 98%, which shall be calculated as follows:

On all 24x7 hrs x 365 days a year, the network shall be up and running. It is assumed that IMS will be working, 24 hrs
round the clock for 365 days in a year and hence the total up time works out to 365 x 24= 8760 hour/annum. 2.0%
downtime accordingly shall mean 175 hours in a year. However, the network shall be maintained in such a manner
that on no occasion the network shall be down for more than 4 hours at a stretch and 20 hours in a calendar month.
The same shall be construed as failure of FMS to rectify the system within the stipulated period and the penalty as
indicated below shall be recovered, even though the total down time in the year up to that point of time/month/year
may be less than the permissible downtime.

2.8 Downtime Penalty

For whole network downtime as defined above beyond the permissible period in a day/month/year a penalty at the rate
of Rs. 2000/- per hour will be recovered for every additional hour of failure. However, if only a portion of the network
or sub-network is down beyond the permissible limits, a penalty of Rs. 500/- per hour will be levied. The penalty time
shall be arrived on the basis of 24 hours operation on each working day. Penalty for non-availability of the services of
the network manager will be levied at twice the quoted rate per day derived from the quoted rate for providing the
services of the network manager.

9
2.9 Services & Service Level Requirements
The total outsourcing model expected by the University includes service requirements related to the
solution for hospital and medical college/ institute, within scope of this Bid

The services would include, but will not be limited to - hardware and software installation, maintenance,
administration, network access, user support, training etc.

2.9.1. Definitions & Reference

i. The general working hours for the reference of the services are from 0800 Hrs. to 1800 Hrs.
However, the service availability for certain critical functions is a must as and when requirement arises.
Such critical functions are:
a) OPD: 0800 Hrs to 1400 Hrs - 6 days a week
b) Casualty / Emergency support services : 24 x 7 Hrs
c) ICU/ CCU/ NICU/ NSICU : 24 X 7 Hrs
d) IPD : 24 x 7 Hrs.
e) All other support services of the Hospital : 24 x 7 Hrs
f) Administrative services : 24 x 7 Hrs

ii. Services shall include standard maintenance services, complaint tracking and record keeping. These
would apply for the IT related infrastructure of the University/IMS-BHU but limited to, the
applications, databases, servers etc.

iii. Hardware, Software & Peripherals :Maintenance.

iv. A request for hardware or software maintenance shall be recorded as service request, which include
requests such as installation / re-installation, to change software applications. Turn around for such
service request expected is within 3 days of logging of service request. Suitable alternative arrangements
be provided in such situation.
v. System Administration services shall include, for example, troubleshooting and user support, file /
system / application management, data storage monitoring, and reporting, system error detection and
correction, backup management, etc.

vi. Turn around time expected for all the scheduled services shall be defined at the time of
finalization of SLA with the SI Vendor for non-scheduled services (within working hours) is 1
day and during non-working hours is before the end of next working day. If however complaint is lodged
on the last day of the week it should be rectified before end of the day of the subsequent working day.
The critical functions defined above cannot have any failure, and thus proper redundancies must be built
in to the solution design.

vii. Centralized Help Desk service at each location, covering complaint registration, resolution & tracking
services shall be established by SI Vendor, to support service calls for hardware, application
software as applicable. The help desk service shall also include the generation of trouble tickets
and submitting unresolved problems to the appropriate internal service providers.

viii. Server-class systems Service Level requirements shall provide for services to ensure availability of
appropriate server platform (e.g. type & no. of processors, network card, memory, etc.) coupled
with operating system and middleware, for each specified server type. The services shall also include
installation of application as required. These services shall be available to the University on an ongoing
basis.

ix. Local Area Network availability

x. The University requires 98% network availability. Therefore the networking vendor must ensure this
availability.
xi. Data Storage availability

10
 xii. The University requires the on-line storage capacity to be monitored and upgrade suggested whenever storage
exceeds 70% of disk capacity. the University also expects the solution to include provision for complete
online storage with a view to ensure seamless & automatic retrieval of data from reasonable past
periods.
xiii. Operations Management service

a) The IT Vendor shall be responsible to identify, track, and report all vendor supplied application
software. The Hardware and networking support will be provided by respective vendors, but the
coordination responsibility will still be with the SI vendor.
b) The SI Vendor shall provide quarterly reports to support asset tracking, analysis, and strategic
planning.
c) Asset tracking and inventory data must be provided to the University authorized persons, upon
request.
ix. Security service
The SI Vendor shall be responsible for development, documentation and implementation of IT and IS
security management systems.
x. The performance of the SI Vendor will be monitored and recorded as necessary over the duration of
the contract with respect to satisfactory fulfillment of all contractual obligations. Performance assessments
may comprise of:

a) Delivery of services
b) Condition of delivered equipment
c) Compliance with service levels
d) Availability of services within established timelines

The SI Vendor shall assemble and create regular reports on the performance of application functions, in
order to assist in the effective management of the Service agreement, and enable continuous improvement
of the in-scope services that the University receives.

Routine meetings and reporting processes must be defined to ensure a smooth interface and timely
resolution of issues. The University requires a single interface to coordinate the delivery of all services from the
SI Vendor.

There must be routine and continuous interaction between the SI Vendor's staff and the users at the
University location. They shall contribute significantly to bridge gap between the users, the University and
SI Vendors management.

2.10 Project and Technical Risk Management Plan and Procedures

The SI will be responsible for assisting the University in Identifying and assessing potential technical risks of the
project as well as identifying and managing actions to avoid, mitigate, or manage those risks. The Bidder is
responsible for providing appropriate methods, tools and techniques for active identification and assessment of project
technical risk; development of risk avoidance , mitigation , or management strategies; and monitoring and reporting of
risk status throughout the life of the project , the University shall fully co-operate with the SI in this regard.

2.11 Time line

The entire work in the IMS campus, and all the associated hospital buildings of IMS shall be completed and ‘Go Live’
within 9 months from the 10th day of signing of MOU. Failing this, liquidated damages at a rate of 1/2 % of the
contract amount per week of delay beyond the stipulated period, subject to a maximum of 5% of the total contract
value for the delayed portion of the contract will be levied for delayed supply. The successful SI shall submit a Bar
Chart / Programme for completion of supply, erection & commissioning of the various components & sub assemblies
along with manpower schedule.

11
3 Payment Terms

The University proposes the following payment terms:

3.1 LAN, Hardware and Software implementation

40% on delivery of Hardware and LAN equipment by the SI

40% on Installation of hardware and software
20% on Completion certificate and Final acceptance of work

3.2 Facility Management Service

This will be paid on an annual basis to the SI at the end of each year from the date of completion of the project. The
entire five year cost may be budgeted in this Bid. SI shall declare its rates on a yearly basis in the financial Bid.

3.3 Other Information related to Payment Terms:

• The currency of payments shall be Indian Rupees. The prices quoted by the SI shall be in Indian rupees, firm and
not subject to any escalation if the order is placed within the validity period. (If there is any item, rate of which
has been quoted in foreign currency, the conversion will be done on the rate applicable at the time of negotiation
of Letter of Credit between the SI and their suppliers). No request for enhancement of rates will be
entertained in the interim period of five years on any pretext.

• Further, subsequent to order being placed/ MOU executed, the SI shall pass on to the University all fiscal benefits
arising out of reduction in Government Levies. Also the University may revise the payments to the SI vendor in
case of increase in Govt. levies such as viz., sales tax, excise duty, custom duty etc.

• Arithmetical errors will be rectified on the following basis:

a. If there is a discrepancy between the unit price and total price that is obtained by multiplying unit price and
quantity, the unit price shall prevail. The total price will be corrected accordingly.
b. If there is discrepancy between words and figures, the higher of the two shall be treated as final. If the SI does
not accept this procedure, the Bid will be rejected.
• The prices quoted for all products and services in the proposed solution shall be competitive.
• The SI will submit its quotations after carefully examining the documents / conditions. The SI must obtain for
itself on its own responsibility and at its own expenses all the information necessary to enable it to prepare a
proper quotation, and submission of the same.
• The SI shall not omit items or leave blank against price of an item, instead, the SI shall indicate ‘Nil’ or
“included in item----” explicitly.
• Any other Tax / Levies such as Sales Tax / Octroi / Entry Tax/ Trade Tax/ Service Tax, VAT etc. which may
be payable on actual basis wherever applicable at the place of delivery should be included in the financial
Bid. In case any way-bill or road permit is to be obtained, the SI shall make necessary arrangements for
obtaining/submitting the same and liaison with authorities as required.

• The University may at any time, by written order to the SI, make changes within the Scope and Terms of
Reference of this Bid in any one or more of the following:

a. Configuration/Specifications
b. Place of delivery or installation.
c. Services to be provided by SI.
d. Delivery schedule.

12
Any increase/decrease in the cost on account of above change shall be mutually discussed and equitable adjustment
shall be made in the price.

• For indigenous goods the price should be on F.O.R. S. S. Hospital, IMS, BHU basis inclusive of all levies and
duties wherever applicable which should be indicated clearly as specified in proforma. The rates of sales tax
should be clearly indicated wherever chargeable. S. S. Hospital, IMS is not eligible to issue ‘C’ or ‘D’ Form,
however the concession rate of Central Sales Tax admissible to Research Institutions on purchase of
Scientific Instruments / Equipment etc from certain states like Maharashtra, Delhi, West Bengal etc is
applicable to S. S. Hospital, IMS, BHU.

• For imported goods, prices shall be quoted on F.O.R. S. S. Hospital, IMS, BHU basis. Indian Agency
commission / rebate payable to Indian Agent, if any, shall be shown separately and that will be payable in
equivalent rupees directly to Indian Agent as per declaration furnished by foreign suppliers. The University
reserves the right to get their goods air / sea freighted and air insured / marine insured up to the site.

13
4 General Information for SI

SI shall note the following information:

4.1 Bid Submission

• SI is advised to study the Bid document carefully. Submission of the Bid shall be deemed to have been done after
careful study and examination of the Bid document with full understanding of its implications. Failure to furnish all
information required by this Bid document or submission of a Bid not substantially responsive to the Bid document
in every respect will be at SI’s risk and may result in the rejection of its Bid.

• The University reserves the right to accept/reject any deviation in the Bid by SI.

• The SI must bear all the costs associated with the preparation and submission of its Bid and the University will in
no case be responsible or liable for those costs, regardless of the conduct or the outcome of the Tendering process

• The Bid will not be returned to the SI after the decision is made.

• Submission of Bid in response to this Bid shall not be construed as an obligation on the part of the University to
award a purchase order for any products / services or combination of services proposed

• The University reserves the right to reject any particular Bid or all Bids without assigning any reason whatsoever to
anyone, and failure of the University to select a SI shall not result in any claim whatsoever against the University

• Blank columns and Overwriting is not permitted in filling up the bids and may entail rejection of the Bid.

• The Bid terms and conditions must be clearly typed or legibly written and have the full name and address of the SI.
Each and every page shall have the signature and seal of the authorized representative of SI.

• A copy of Sales Tax registration certificate duly attested by a Gazetted officer shall be enclosed.

• Sales Tax, Income Tax clearance certificate along with an affidavit from the Notary that the firm has never been
black-listed must be attached along with the Bid, failing which the Bid shall be rejected.

• Last date and time for Bid submission is 07.01.2010 upto 3.00 PM.

• All responses that are received after the due date / time will be treated as invalid and would not be accepted or
opened unless called for.

• Technical Bid (Two copies: One original and one duplicate) and Financial Bid (Two copies: One original and one
duplicate) must be submitted in separate sealed envelopes. The envelope cover in each case should be superscribed
with “Technical Bid for BHU Bid” and “Financial Bid for BHU Bid” respectively. SI name and address should also
be superscribed on each envelope. These two envelopes enclosed with the prequalification questionnaire, duly
answered with documentary proof, should be put in another sealed envelope and super scribed with “ Bid for HMIS
& LAN Implementation” along with SI name and address. This sealed envelope should be submitted to ‘The
Medical Superintendent , SSHospital Institute of Medical Sciences, Banaras Hindu University, Varanasi” on or
before the Bid due date/time. The place of submission shall be ‘The Office of Medical Superintendent , SSH, IMS,
BHU, Varanasi’.

• The Technical Bid must contain, Product catalogue, Literature of Product, Copy of Product manual and Network
Diagram, besides a detailed technical Bid encompassing all the attributes of this Bid. SI shall also submit the
completed checklist given in the appendix. Each page of the original document must be sealed and signed by the
authorized person of SI.

• Financial Bid on the letter head of the SI must conform to the proforma provided in the appendix, and bear seal and
signature of SI on every page. The prices shall be quoted excluding taxes. All taxes and other charges shall be
declared in the adjoining column. All rates shall be F.O.R. destination SS H IMS, BHU, Varanasi.

14
4.2 Consortium: - the University expects the Vendor to use the latest state-of-the-art technology, the
appropriate hardware & software product(s), workflow procedures and maintenance & security policies in the
proposed solution. For this purpose, the SI Vendor may form a Consortium for the proposed solution.

However, the University shall deal with a single Vendor (herein after referred to as SI Vendor) who shall
be the Prime Vendor / Consortium Leader and a single point solution provider.

4.2.1. Consortium Bid:

a) The bid would be a Consortium Bid, if:

i. The SI Vendor, as a part of the proposed solution, proposes the use of some product(s) which are not
owned by the SI Vendor; or

ii. The SI Vendor, as a part of the proposed solution, proposes on behalf of another Vendor, the use of some
service(s) which are not provided by the SI Vendor; or

iii. The SI Vendor, as a part of the proposed solution, proposes product(s) on behalf of another Vendor.

b) In the case of a Consortium Bid, the SI Vendor shall submit the proof of authorization to bid for the
product(s) / service(s) not owned by the SI Vendor and authentication from Consortium members.

This proof shall be a letter from a duly constituted attorney of the Owner(s) of such product(s) / service(s),
authorizing the SI Vendor to bid as a Consortium Leader for this Bid and A copy of the Memorandum of
Understanding (MOU) between the Consortium members. This MOU must essentially contain --
• Name of the Lead member of the Consortium;
• Names of all other members of the Consortium other than the Lead member;
• Agreed roles and responsibilities of each of the Consortium member, including the Lead member;
• Power of attorney to the Lead member / its authorized signatory to negotiate and enter into the
Contract for the Project on behalf of the Consortium.

ii. The SI Vendor shall be responsible for all details presented on behalf of the Consortium, in the
response to this Bid. All such details will form a part of the final Contract.
iv. The SI vendor shall be totally responsible for delivery of end-to-end contractual services.
v The SI Vendor shall be responsible for all obligations under the Commercial Bid. the University would deal
with the SI Vendor only, for all commercial and legal matters.

4.3 The University and SI Memorandum of Understanding (MOU)

• By submitting a Bid in response to this Tender, the SI agrees to promptly engage in contract with the
University if it is selected for the assignment

• The University will first issue a Letter of Intent (LOI) to the SI. The SI shall submit its acceptance within a
week of issue of the LOI.

• From the date of issuance of a Letter of Intent to the selected SI, the SI shall sign an agreement in this Bid
document, with the University at the time, place and in the format prescribed by the University, The MOU
agreement shall include all agreed terms, conditions and specifications of this tender document and also the
Bill of material and price, as agreed finally after Bid evaluation. The MOU shall be executed in English
language in 2 (TWO) original, with both University and the SI receiving the duly signed original. The MOU
shall be valid till all contractual obligations are fulfilled
• The effective date of start of the MOU with the selected SI shall be the signing of the MOU by the SI.

15
 • All questions, disputes and differences arising under and out of , or in connection with the MOU shall be
referred to the sole arbitration by an arbitrator appointed under the provisions of the Arbitration and
Conciliation Act, 1996 by the Vice-Chancellor, B.H.U., Varanasi.

• Any notice by one party to the other pursuant to the MOU shall be sent by telegram/telex/cable/fax/e-mail
and confirmed in writing to the address specified for that purpose in the Memorandum of Understanding.

• By entering into a MOU with the University, the SI acknowledges that the SI has the expertise and the
competence in executing all phases of work involved in the provisions of this Bid. The SI also acknowledges
that University relies on this statement, therefore neither accepting responsibility for, nor relieving the SI of
the responsibility for the performance of all provisions and terms and conditions of this Bid.

• All goods or materials shall be supplied by the SI, whose Bid is accepted, strictly in accordance with the
specifications, drawings, data sheets, other attachments and conditions stated. Any alterations of these
conditions shall not be made without the consent of University in writing which must be obtained before any
work against the order is commenced.

• All material furnished by the SI pursuant to the MOU (irrespective of whether engineering, design data or
other information has been furnished, reviewed or approved by the University) will be guaranteed to the best
quality of their respective kind (unless otherwise specifically authorized in writing by the University) of
workmanship and materials, and to be of sufficient size and capacity and of proper materials so as to fulfill in
all respects with all operating conditions.

• In the event that the material supplied is defective or do not meet the specifications and are not in accordance
with the drawings, data sheets or the terms of the order, SI shall replace the material at no extra cost to the
University . Failure on the part of SI may prompt University to immediately replace the material at the cost of
SI.

• The entire responsibility of supply, warranty and the MOU execution lies with the SI, on whom the Purchase-
cum-Work Order is placed and with whom the MOU is signed.

• The SI shall be overall responsible for the entire work, including that done by its consortium partners.
University shall not enter into any dialogue with the consortium partners. University shall only interact with
the SI.

4.4 Amendment of Bidding Documents:

4. 4.1 At any time prior to the deadline for submission of bids, the University may, for any reason, whether at its
own initiative or in response to a clarification requested by a prospective bidder, modify the bidding
documents by amendment.
4.4.2 All prospective bidders who have received the bidding documents will be notified of the amendment in
writing which will be binding on them.
4.4.3 In order to allow prospective bidders reasonable time within which to take the amendment into account in
preparing their bids, the University, at its discretion may extend the deadline for the submission of bids.

4.5 Tender Bid Clarification

• To assist in the examination, evaluation and comparison of Bids, University may, at its discretion, ask the SI
for clarification of the same. The request for clarification and the response shall be in writing and no change
in the price or substance of the Bid offer shall be sought, offered or permitted.

• A prospective SI requiring any clarification of the Bid Document may notify University in writing or by fax,
telex or email at the University mailing address as indicated in the Bid Document. No query from any SI shall
be entertained by University if it is received more than 7 (seven) days after the release of this Bid. The
University will respond in writing to any request for clarification of the Bidding documents which it receives,

16
 not later than 7 (seven) days prior to the deadline for the submission of bids prescribed. Written /email copies
of the University response (including an explanation of the query but without identifying the source of the
query) will be sent to all prospective SI who have received the Bid.

• The preferred mode of communication shall be email.

4.6 Governing Language

• The bids prepared by the SI and all correspondence and documents relating to the bids exchanged between
the SI and the University, shall be written in the English language, provided that any printed literature
furnished by the SI may be in any another language as long as the same is accompanied by an English
translation in which case, for purposes of interpretation of the Bid, the English translation shall govern.

4.7 Bid Validity

• The Bid will remain valid for 180 days from the date of submission of the Bid

4.8 Force D’Majeure

The SI shall not be liable for forfeiture of its performance security, liquidated damage or termination for default, if and
to the extent that it’s delay in performance or other failure to perform its obligations under the MOU is the result of an
event of Force D'Majeure. For the purpose of this clause "Force D'Majeure" means an event beyond the control of the
SI and not involving the SI's fault or negligence and not foreseeable. Such events shall mean and limited to, war or
revolution, riot, earthquake, fires, floods, epidemic, quarantine restrictions, freight embargo and terrorist attack, strike
or lock-out (only those exceeding 10 continuous days). If a "Force d' Majeure" situation arises, the SI shall promptly
notify University in writing of such condition and the clause thereof. SI shall notify University by registered letter duly
certified by Local Chamber of Commerce of Statuary Authorities, the beginning and end of the above causes of delay
within 7(seven) days for occurrence and cessations of such conditions, in the event of delay lasting over one month, if
arising of causes of Force d’ majeure, University reserves the right to cancel the order and the provisions/articles
governing termination of order shall apply. Unless otherwise directed by the University in writing the SI shall
continue to perform their obligations under the MOU as far as reasonably practical, and shall adopt all reasonable
alternative means for performance not prevented by "Force d' Majeure" clause. For delays arising out of Force d’
majeure, the SI shall not claim extension in completion date for a period exceeding the period of delay attributable to
the causes of force d’ majeure and neither University nor the seller shall be liable to pay extra costs provided it is
mutually established that Fore d’ majeure conditions did actually exist.

4.9 Late Bids

Any Bid received after the Bid due date and time prescribed in the Bid Document shall be rejected. Telegraphic/fax/E-
mail offers whether sent directly or submitted by local agent in India will not be considered and shall be rejected.

4.10 Modification and withdrawal of Bid Document

The SI shall not be allowed to modify or withdraw his Bid after the Bid submission even if the deadline for submission
is not reached.

4.11 Canvassing

Any efforts by a SI to influence University on Bid evaluation, Bid comparison or contract award decisions may result
in the rejection of its Bid.
4.12 Right to vary quantities at the time of award

University reserves the right at the time of award of Contract to increase or decrease the quantity of Goods specified in
the scope (in respect of each item of scope), without any change in unit price or other terms & conditions. Any
variation in quantity will be mutually agreed upon by University and the SI.

17
4.13 Bid Processing Fee: -
The Bidder shall submit a separate Bid Processing Fee (non- refundable) of Rs. 50,000/- (Rupees Fifty
Thousand Only) along with the Bid, in the form of a Banker‘s Cheque / Demand Draft drawn on any Nationalized
Bank, in favor of —“The Registrar, BHU“.

4.14 Earnest Money Deposit : -

The Bidder shall submit an Earnest Money Deposit (EMD) of Rs. 10,00,000/- (Rupees Ten Lakhs Only)
along with the Bid, in the form of a Banker‘s Cheque / Demand Draft drawn on any Nationalized Bank, in
favor of —“The Registrar, BHU, Varanasi.”

4.15 Ownership of Data

a) The SI Vendor shall be the custodian of such data , and shall also ensure its security and integrity.
b) The SI Vendor shall ensure the provision of appropriate and adequate security levels, for
protection of such data and other technology resources, which shall come into its custody during the
implementation of the proposed solution.
c) The infrastructure for the proposed solution, at each of the sites, shall be strictly and exclusively used
by the SI Vendor for processing data related to the University only. Under no circumstances shall
the infrastructure be used for any other purpose by the SI Vendor.
d) The University / its authorized representative(s) shall conduct periodic / surprise security reviews
and audits, to ensure the compliance by the SI Vendor to these control / access provisions.
e) The SI Vendor shall develop and implement an —IT Security Policy“ for the proposed IT solution.
This IT Security Policy shall be in line with international guidelines and standards. The SI Vendor shall
also keep itself updated with the latest IT Security Policy of the Government.

4.16 Change Management:

a) A Supervisory Committee shall be constituted by the University at the time of award of the final
Contract / Agreement, which shall have a representative/s from the University as well as the SI.
b) In the event a change is requested (either by the University or the SI) post customization &
implementation of the proposed HMIS solution, the Supervisory Committee shall consider the change in
scope along with the development / change implementation time estimate for the same.
c) The Supervisory Committee shall evaluate the change Bid and if needed, recommend the change to the
University.
d) The approved changes shall be carried out by the SI Vendor as per the —rate per “person-month“ quoted
through this Bid.

5 Project Requirements

University looks for a ‘turnkey project’ from the SI. The SI is required to propose a composite HMIS and LAN
solution for University in line with the following general requirements:

5.1 Network

• The Solution envisages integration of Software and hardware and Connectivity for the following parts of
SSLH campus :
1. Indoor Patient Complex- six floor
2. Medical Superintendent’s Office (three floor)
3. Connectivity with IMS Building Network
4. Pediatrics Building – Pediatric Medicine –Two floors
Pediatric Surgery – Three floors
5. Eye/ENT Building –two floors
6. Radio Therapy Building two floors
7. OPD Complex – three floors
8. Psychiatry Building – two floors
9. Special Ward – Two floors

18
 10. Chest & Trauma Wards – First Floor
11. Laser OT
12. Cardiology
13. Clinical / Research Laboratories in IMS
14. Ayurvedic wing of the hospital
15. Any other parts of the Hospital / IMS Building that may need to be connected.

The LAN envisages to comprise of at least 500 nodes with possibility of expansion in future. The SI is expected to
obtain more details of location and number of nodes in each building after a detailed survey of the Hospital / IMS
Campus.

It is important to note that the proposed HMIS must have the facility of adding new departments as more
departments may be added to those already existing. The bidder should also propose setting up of an intranet site
as a solution for knowledge repository requirements of the university.

• LAN should be at least Gigabit Ethernet on Optical fiber backbone. SI may propose a high performance
system which is capable to handle the needs of University Hospital and support the proposed PACS.

• SI shall supply all equipments/components as per requirement of the application software mentioned in Bid
• The SI shall supply all the installation material/ accessories/ consumables (e.g. screws, clamps, fasteners, ties
anchors, supports, grounding strips, wires, fiber connection kits etc.) necessary for the installation of the
systems.
• The SI shall be responsible for providing proper "Electrical ground" at all the required points as per the
approved IEEE standards for Grounding of Sensitive Electronic Equipment and as per the OEM guidelines.
• The SI shall install, wire the UPS power at required locations and provide proper electrical ground for the
same before installation of the equipment. Civil works if any required for installation of the system will be
the responsibility of the SI.
• All the work shall be done in a conscientious manner as per the OEM guidelines and best industry practices.
The system shall be subjected to inspection at various stages. The SI shall follow all Safety Regulations and
practices.
• The SI shall configure quality of service parameters on network switching devices for end-to-end QoS for
critical traffic over the network.
• SI shall be responsible for integration of security components in the network to ensure a secured network
access for users.
• SI shall configure network management policies for managing all the network and security devices using
network management systems.
• SI shall prepare detailed acceptance testing plan (ATP) for each of the components i.e. Network, Image &
Data and submit the same to the University.
• All the functionality, features and configuration shall be documented for all the equipments/components and
shall be demonstrated with respect to the documentation prepared.
• The SI shall be responsible for obtaining approvals (if any) for any Statutory &Regulatory requirements from
any of the authorities.

5.2 Functionality Requirements

All the features and functions desired for the optimal operation of a tertiary care multi specialty hospital is to be
provided in an integrated platform, which includes but not limited to, Laboratory and Radiology Management
System, PACS and Telemedicine.
A detailed study of existing systems and required functionalities for the HMIS system is to be conducted to be
able to understand the customizations that will possibly be required. Results of these are to be documented by the
vendor.

The SI should also submit information in response to desired features listed below

19
5.2.1. Patient Management System (PMS)

The Patient Management System shall broadly cover

5.2.1.1. Out-patient Registrations, including

• Capturing basic patient demographic information;
• Generation of out-patient ID;
• Consulting details;
• Clinical follow up;
• Lab test reports;
• Diagnosis;
• Insurance details;
• Patient bill status;
• Referral data; etc.
• LCD display for appointment term;
* Specialty & Subspecialty template development

5.2.1.2. In-patient Admission-Transfer-Discharge (ATD) Process, including

• Capturing basic patient demographic information;
• Basic health record;
• Past medical history;
• Current medication;
• Details of ailment including allergy, disability, chronic diseases, addiction, etc.;
• In-patient ID;
• Insurance details;
• Referral data;
• Patient admission from various sources (OPD, accidents & emergency units, referrals, transfers from
other hospitals / clinics, etc.);
• Reservation of beds;
• In-patient care;
• Generation of Transfer Requests (if required);
• Operation details (if any);
• Medical images (if any);
• Lab test reports;
• Patient bill status;
• Discharge details;
• Printing of Admission & Discharge slips / cards; etc.

5.2.1.3. Consulting Appointment Management, including

• Set-up of Hospital Calendar capturing non-working days, day-care timings, etc.;
• Scheduling multiple services
• Availability & Time-slot of Consulting Doctors as per day & time combinations;
• Search for Consulting Doctors as per service;
• Appointment Booking of Consulting Doctors on internet, WAP enabled phones, IVR, walk-in,
etc.
• Booking of multiple slots for patients;
• Booking of multiple appointments per slot;
• Appointment cancellation / re-scheduling;
• Reminders via e-mail, SMS, IVR, etc.

20
5.2.1.4. Casualty & Emergency Registrations & Management, including
• Capturing of whatever basic patient demographic information available at the time of registration
of the casualty & updation of the same when fully available;
• Temporary ATD;
• Consulting details;
• Clinical follow up;
• Lab test reports;
• Diagnosis;
• Services bookings;
• Pharmacy / Surgical details;
• Statutory forms & reports; etc.

5.2.2. Clinical Care System (CCS)

• The Clinical Care System shall broadly cover

5.2.2.1. Clinical follow up, including

• Recording patient visit details like patient complaints, physician findings,
• medical prescriptions, diagnostic tests, follow-up information, etc.;
• Easy access to patient basic health records;
• Viewing of patient medication history & laboratory test results;
• Appointment for tests;
• Recording sample collection details;
• Authorization of laboratory test results (if applicable);
• Interface to medical equipment, billing & inventory; etc.

5.2.2.2 Service Order Processing, including

• Generation of Service Orders by Service Points like Clinics, Wards, OT, etc.;
• Electronic processing;
• Service Order Tracking, including Service Point account for material consumption against
Service Order, detection of material wastage, detection of loss of revenue at service point, etc.;
• Billing patients as per the services rendered, etc.

5.2.2.3. Medical imaging, including

• An integrated imaging & reporting solution designed to ease the operations of various equipments
like ultrasound, colour doplor, endoscopy, microscopic camera, etc.;
• Image editing facility like annotation, zoom, free-hand drawing, cut, copy, paste, crop etc.;
• Viewing stored videos, clippings & images;
• Printing images or sending images by e-mail;
• Creation of images from captured videos & storage in .jpg files;
• Linking of images / videos to patient data;
• DICOM support; etc.

5.2.2.4. PACS Radiology

• Ability for all the image storage to be on-line.
• Ability to automatically display warning when the storage space is above 70% used
• Ability to support the current American College of Radiologists
• Ability to provide for the maintenance of the storage system without loss of data or time.
• Ability to provide purge, archive and move lists by user-defined criteria.
• Ability to track films at the following levels:
•Master Folder
•Subfolders
•Procedure incl. C.T., DSA (Digital Subtraction Angiography)
•Reported status
•Unreported status.

21
 • Picture Archiving Communicating System (PACS) should be implemented and connected to all
Radiology modalities.
• PACS should be integrated with the HMIS where films and reports are easily accessed and previous
images/ reports should be available for any references.
• Ability to view radiographic images at wards, ER, clinics, with or without reports.
• Ability to view primary and final reports for urgent cases at ER and any selected area.
• Ordering Physicians have the ability to refer any unreported images to radiologist requesting urgent
report.
• Ability to view the same image in deferent areas such as wards, clinic Etc.
• Ability to print high quality diagnostic images in hard copy or to be saved on CD.
• Ability to send these images via internet or remote connection such as outside hospital clinic along with
reports.

5.2.2.5. Operation Theatres Management, including

• Maintenance of OT & staff calendar;
• OT Scheduling including scheduling of providers & resources;
• Material requisition;
• Recording operation details like list of staff present, date of operation, start & end time of operation,
details of procedure notes & nurse instructions, pre
• & post operation care procedures, etc.
• Interface to inventory & billing;
5.2.2.6. Nursing & Ward Management

• Ability to access Patient Administration system for user defined data items.
• Ability to link in with the order communications.
• Ability to include notification of patient's pending arrival including any admission tests to be performed, the
treatment proposed and the condition of the patient, including the initial diagnosis. For surgery, the theatre
schedule must be notified, together with any preparation required.
• Ability to record admissions, discharge and transfers at the wards to update the bed census, confirm location
of the patient and to notify ancillary departments such as dietary.

Quality Improvement (Nursing Services)

• Statistic of total hours that the nurse has spent with the patient, with procedures been made containing the
nursing and medical diagnosis of the patient.
• Provide diagnostic control on reducing operational errors and minimize incident (needle stick injury, drug
error etc.)
• Infection Control (Nursing Services)
• Ability to record extra clinical details against a patient record for infection control purpose like (HEP: A, B,
C, HIV and other infectious diseases.
• Ability to access user defined patient data from Patient Administration data items.
• Ability to receive automatic notification of certain specific hospital defined organisms growing from culture.
• Facilities to access patient clinical data (CBC, CRP etc) date of operation, TPN curve. etc.
• Ability to access date of admission and discharge of selective Patients.
• Ability to gather statistics according to international standards for infection control.

Bed Management (Nursing Services)

• Ability to provide on line access to Accommodation usage by room

• Ability to print bed utilization per ward, consultant and specialty
o Daily
o Monthly
Ability to report bed days by
• Ward
• Consultant

22
 • Specialty
• Diagnosis/classification
Ability to analyze ward or room occupants by sex, service, age etc.

5.2.2.7. Blood Bank, including

• Blood collection, storage & supply from voluntary donors;
• Maintenance of Blood Stock Register;
• Maintenance of Donor Database;
• Confirm availability for anticipated use (for operation, accident patients, etc.);
• Capturing detailed information about blood samples;
• Replacement of blood against borrowings;
• Processing of service requests;
• Maintenance of inventory / interface to existing inventory system, billing, etc.
• Condemnation of blood, etc.
5.2.2.8. Electronic Medical Records (EMR), including
• Collated & formatted information on patients, as required;
• Search on patient records by patient name, patient ID, etc.;
• Complete clinical data repository, capturing basic patient demographic
• details, medical history, consultations, diagnosis, laboratory reports, medical
• images, medical treatment records, etc.
• Built-in reports and user-oriented report-writing capabilities, etc.

5.2.2.9 CSSD, including

• OT Equipment Set Register;
• Sterilization Acceptance;
• Generation of Equipment list as per OT Schedule;
• Lead time adjustment for the Equipment;

5.2.2.10 Telemedicine
• Ability to provide unique Patient number Ability to make appointments over telemedicine network from
clients (remote patient location)
• Ability to have voice and video connectivity
• Ability to attach the medical data transmitted to be part of the patient EMR
• Ability for the remote doctor (client) to access patients EMR
• Ability to transfer the EMR data of the patient upon the request from the telemedicine client
• Ability to use the telemedicine network to possibly support tele-education

5.2.3. Other Services Management System (SMS)

The System shall broadly cover
a) Helpdesk
Information repository
Current bed census
Tariff for various services

5.3 Essential Standards

The proposed HMIS shall adhere to, but shall not be limited to, the following international healthcare
standards:

a) American Society for Testing & Materials (ASTM)

- For interfaces to laboratory equipments complying with ASTM

b) Digital Imaging & Communication in Medicine (DICOM)

- For images

23
c) Health Level 7 (HL7)
- For messaging & communicating with HL7 compliant systems

d) International Statistical Classification of Diseases & Related Health Problems œ 10th Revision (ICD-
10)
- Controls for ICD coding of discharge diagnosis details

e) Current Procedural Terminology (CPT)

- Support for coding of services

f) Clinical Physician Order Entry (CPOE)

- support for ease in data entry for physician, which helps in user adoption as well as ergonomics of the solution.
NOTE: The proposed HMIS solution must confirm to the above-mentioned standards currently, and the SI is
expected to demonstrate these standards in existing reference customer.

5.4 Application Architecture

Proposed implementation of HMIS is aimed at deriving benefits for the patient, doctor as well as administrator in
more ways than one. To site a few benefits -

5.4.1. Patient
• Computerized medical record
• Preventive healthcare
• Appointment booking on web, phone and mobile

5.4.2.Physician
• Online access to patient health records
• Computerized prescription
• Online referrals
• Paperless virtual office

5.4.3.Administrator
Optimum resource utilization
Computerized scheduling of staff and services
Online reports

5.4.4.The application architecture should be such that it has capability to deliver the expectations of the
University. Following are some of the salient points that are desired from the architecture design:

5.4.5. Scalability
• New servers can be added dynamically to increase capacity
• Load balancing can be used to ensure that the servers are proportionately utilized

5.4.6. Performance
• Application framework designed to ensure good performance
• Use of caching techniques

5.4.7. Security
SSL
• Data encryption
• Firewall and DMZ provides security from outside attacks
• Application level security in terms of user roles & responsibilities
5.4.7a. Security must be addressed through OS security and application Security. Please give details of the
security architecture for the following
Log in security
Network security

24
 Operating System security
Application related security
Antivirus measures
Intrusion Detection measures
Intrusion prevention measures

5.4.8. Availability
• 24 x 7 availability

5.4.9. The proposed HMIS should be based on fully redundant N -tier architecture which is vendor agnostic
like J2EE technology, which allows for scalability, central management of business rules, reduced
maintenance and single point of deployment. Platform independent, and open source compliant application
with web-based clients is what IMS BHU is looking forward to implement.
The HMIS solution must be based on N-tier Architecture (which makes in completely vendor
neutral/independent/agnostic, like J2EE), and some of the highlights are:

5.4.9a Presentation Layer

• HTML : platform independent
• Browser based client : thin client model
• Compatibility with multiple browsers
• No client installation for application

5.4.9b. Web Tier

• JSP / Servelets
• Open Source Rapid Application Development
• Support for open source servelet container

5.4.9c. Application Layer

• Support for all leading application servelets
• Option for open source, free servers without loss of performance / features
• Reusability i.e. component based
• Standards driven i.e. no vendor locking
• High availability
• Easy to upgrade i.e. server level upgrade only
The application should be platform independent at the server side, and should allow any operating system
from client side to connect to the application over intranet or internet. Data mining and warehousing support,
providing multi-dimensional view of data, MIS and DSS reports is desirable from the application

5.5 Innovative Solutions

University also looks forward to innovative solutions from the SI Vendor. These solutions should be such as to make
the system easy to handle for the user or inclusion of value added solutions to the system. Some of the solutions may
be given for
1. VoIP Telephony on the network,
2. Wireless access points in the hospital wards,
3. use of smart card for students,
4. Biometric authentication
5. Connection to PDA’s. or any other such solution which SI considers important for IMS.
6. LCD Display for OPD patient turn
(These can be separately Quoted)

25
6 Project Requirements

The project requirements given here are a high end view and only indicative in nature. The SI is expected to follow
International Industry standards for project implementation. The SI is expected to perform the system study of the
University Hospital and IMS and propose its own technically superior solution.

6.1 Hospital Management Information System (HMIS)

The proposed HMIS system should be a comprehensive system that integrates all the departments in a hospital and
automates most of its major functions. The University is looking at the following key benefits from the proposed
HMIS system:
• Online availability of information
• Improved administration & control
• Automated information flow across departments avoiding duplication
• Simplified billing & discharge process
• Optimized resource allocation

The proposed HMIS should have the following features that will benefit SSH, IMS:

• Multiple level Security

• Graphical User Interface
• Online Help & User Manual
• Web enabled
• ICD 10 / CPT codes incorporation
• HL7 compliance
• Mobile Device Interface (SMS/WAP)
• Smart Card Interface
• Barcode Compatibility
• Drug Database integration
• Voice Transcription
• LCD Display for OPD Patient turn

Proposed HMIS system may have the following modules:

6.1.1 Patient Care / Hospital Administration

Registration
In-patient management
Duty Roster
Appointment Scheduling
Billing
Drug Database
(It would be an advantage if the software offered can provide seamless integration with Medical Education module.)

6.1.2 Clinical Services Security & Administration

Laboratory
Operation Theatre
Ancillary Services
Blood Bank
CSSD (Central Sterile Supplies Department)
Electronic Medical Records
Equipment Maintenance
Radiology File Management

26
6.1.3. The functionality desired in each module is as given below:

6.1.3. 1. Registration
The Registration desk is the first point of contact when a patient visits a hospital. This module should assign every
patient a unique Medical Registration (MR) number, which should be valid during the lifetime of a patient. Once
registered, patients need not mention their details during subsequent visits. There should be a search facility in the
Registration module, which should enable the registration desk staff to retrieve details of a patient based on various
parameters, such as the name, age, date of birth, and city, even if the patient does not remember the medical
registration number. This module should also serve as a help desk at the hospitals front office.
6.1.3. 2. In-patient management
The In Patient Management module should automate the routine tasks of Wards and thus ensure better patient care.
Tasks, such as transferring a patient from one ward to another, requesting laboratory tests, and requesting drugs
prescribed by a doctor should be done in wards. Additional functions should include diet requests to the kitchen. A
discharge request should be raised for a
patient, once the doctor decides to discharge that patient. The Billing department should generate a bill for all the
services rendered till that date. The patient should be given a discharge summary report and discharged immediately.
This will ensure that there is no waiting time involved in preparing the bill or the discharge summary report. To handle
corporate patients, the details of patients should be captured at the time of admission and their billing should be done
accordingly

6.1.3. 3. Appointment Scheduling

The Appointment Scheduling module should help in maintaining the schedule of various resources in a hospital, such
as doctors, and laboratories. Pre-registration booking for appointments, fixing appointments at flexible time intervals,
variable start time and end time should be available for these resources using the scheduler. This module should be
used to book the next available slot on the approximate date. Public holidays should be considered automatically while
scheduling appointments and a facility for viewing the schedule of multiple
resources should also be available.

6.1.3. 4. Billing
The patient getting admitted in the hospital shall be depositing an advance amount at a central facility. The respective
departments providing the services shall post charges for bed charges, lab requests, pharmacy requests,
accommodation charges, and food. Through this functionality, at the billing department, all services should be
consolidated and the amount shall be deducted from the patients account and a bill should be generated. The bill
should be printed and given to a patient. A patient should check the amount due for payment as on a particular date so
that he/she gets an indication about the final payment at the time of their discharge from the hospital. The ward nurse
should get alerts of near zero balance of the in-patient. The hospital management should be able to define the tariffs
for various services and discounts applicable for corporate entities. Tariff for packaged services and special categories
should also be defined. Special categories are based on the type of the bed/ward occupied by the patient. There should
be facility to waive off the charges by authorized persons. There should be facility to roll back transaction incase of
any mistake in data entry.
6.1.3. 5. Drug Database
This would have details of all drugs and their brand names. It would also hold details of the drug like Indications of
use, mode of action, side effects, contraindications of use etc. This should facilitate the doctor as a ready reckoner for
the drug. There should also be facility for adding/deleting brand names by end users. Each end-user may have own
favorite lists of the most frequently used brands.

6.1.3. 6. Laboratory
The Laboratory module should enable users to maintain information about the status of a patient, and text/numeric
results of various services such as clinical pathology, X-ray, and ultra sound, based on the investigation requests made
for patients. Nurses/Billing people should be able to make a request for laboratory tests for a patient from various

27
locations in a hospital including wards, billing, sample collection point, or at the laboratory. This module should also
take care of
test request reversals, that is, requested tests should be cancelled if it is found that the test requested need not be
performed. The Laboratory module should be integrated with the IP/OP Registration, Wards and Billing modules. For
In Patients, lab test charges should be automatically posted to Billing. In the case of outpatients, payment has to be
made while raising test request. Laboratory equipment should also be integrated with HMIS to facilitate automatic
storage of text/numeric results directly, on completion of tests.

6.1.3. 7. Operation Theatre

The Operation Theatre module should be used for efficient management of the operation theatre. A checklist for each
kind of surgery should aid the staff in gearing up for a surgery. Pre-defining standard notes should aid the staff in
generating pre-operative, operative, and post-operative notes. Surgical items used during the surgery should be
indented through the system from the Central Sterile Supplies Department. The system should also interface with the
Blood Bank module to ensure that requirement for blood and blood products are immediately taken care of. This
module should automate majority of the routine tasks of hospital personnel, who in turn will be to concentrate on
patient care.

6.1.3. 8. Blood Bank

The Blood Bank module should be a comprehensive system that should maintain complete information about donors,
along with the details of blood donation. This module should be linked to the operation theatre & wards, and whenever
there is a surgery, blood requirement should be indicated to the blood bank. Availability of blood, details of cross
matching with patient’s blood, and transfusion reactions should be recorded in the system. The system should also
provide for interactions with external blood banks, both for receipt of blood bags and delivery of blood bags from
external banks. There should be facility for expiry date notifications.

6.1.3. 9. Instrument sterilization

Sterilization of surgical instruments, dressing sets and linen is very important prior to their use. CSSD module should
provide sterile instruments, dressing sets and linen to operation theatres and wards. The system should also facilitate
procurement of items, stitching of dressing sets. The autoclave register should be maintained to record the details of
sterilization. The CSSD module should automate the entire spectrum of activities including details of instruments
going for sterilization, instruments sterilized, instruments supplied, and instruments received from operation theatres/
wards.
6.1.3. 10. Electronic Medical Records
The Electronic Medical Records module should facilitate complete online storage of patients’ Medical records. The
complete history of a patient, along with diagnosis and prescription should be maintained online. There is a provision
for a doctor to prescribe tests from the Lab module and also medication from the Pharmacy module. Users of the Lab
and Pharmacy modules should be able to view these requests from their respective locations and provide service to
patients. The ICU monitoring chart should help the doctor to monitor the hourly/daily update of vitals. Vitals and
frequency of monitoring should be decided for each patient. This helps the doctor to analyze the trend of the vitals for
a patient and aids in decision-making. Nurses, doctors and consultants should be able to enter progress notes of a
patient, which should then be available for ready reference. Patient data should be analyzed on various parameters like
disease, procedure, age, sex, and duration of stay.

6.1.3. 11. Radiology

Registration of patients at Radiology Department At the registration counter of Radiology Department, Patient should
get registered for the test. For out patients the bill amount should be collected and the Order Number should be
generated. For In Patients payments is not necessary during that time. The service amount should be accumulated
against In-Patient Registration number. With the Order number the patient goes to the Radiology Department and to
the particular lab where the test has to be done, where a registration is done for that test which generates a Registration
number. Registration Number should keep track of the patient’s request status. A very few users, who have the
authorization for that, should be able to do the cancellation of the test requisition. After the patient getting registered,
patient will proceed to the respective room (facility) to avail the services.

28
Result Entry

After taking the radiology test, the radiologist will enter the report of the test. A concerned authority would verify the
result before generating the report. However even before the report is generated by the radiologist, the unreported
image should be available for viewing at any terminal by the physician, for a rapid patient service. By default, films
shall not be provided to the patient, until specifically asked for by the treating physician.

Inventory Maintenance and Generation of Test Reports

Sub-store in radiology department keeps inventory of materials required in Radiology department. Sub Store gets all
the items from the Main Store of the hospital. To get the items, the Sub Store has to raise an indent. According to the
availability of the items, stores issue the items either partially or fully. After getting the items, Sub Store sends an
acknowledgement to the Main Store. The inventory with in the Radiology department also follows the same. The dark
rooms and the nursing station raise a request to the Sub Store and the Sub Store issues the items according to the
availability. The consumption of the films and other materials is entered in the various rooms against radiology request
number; accordingly the stock will be depleted.

6.1.3. 12. Security & Administration

The Security module should provide controls to access information available in the application. It deals with user
level security for the other modules and their functions. Each user should have access to a predefined set of actions
(add/modify/delete/query) on various functions in a given module. User-defined error and help messages should also
be maintained and customized in this
module. The General Administration module should deal with the configuration of the HMIS for a hospital. The
physical layout of a hospital, its logical partitioning into departments, specialization details and various hospital
services should be defined in this module.

6.2 Hardware Requirements for HMIS

The vendor should propose appropriate Industry standard high-end configuration for the Application, Database, Mail
Servers and any other type of servers. This should be done keeping in mind the complexity of the SSH, IMS
requirements and also from the perspective of current and future needs of response time, data storage, archival etc. It is
recommended that the Application, Database and Backup servers should atleast be dual processor based with at least 1
GB RAM and appropriate hard disk storage with Redundant Array of Inexpensive Disks (RAID) technology.

6.3 Picture Archival & Communication System (PACS)

The Picture Archiving and Communications System (PACS) is intended to setup a film-less system in IMS for
performing radiology and cardiology services within the institution. Anticipated benefits of implementation of the
system include significant reduction in the costs associated with film and its processing, handling, and storage,
improved operational efficiency, and enhanced patient care within the hospital and to other affiliated healthcare
facilities. The function of the PACS is to acquire, distribute, display and archive imaging data and related information
used by the institution. This data will be incorporated into and stored in the PACS at the full contrast and spatial
resolution originally obtained by the acquisition devices. Access to the data will be limited to those center personnel
who are authorized. The system shall be interfaced to HMIS to support display of HMIS diagnostic reports alongside
medical images on ser-friendly, high performance, applications-oriented workstations, and automated image
management and distribution. The PACS image storage and management subsystem must allow the rules for image
management to be determined by the customer. The Hospital is expected to handle nearly 1.5 lacs procedures per
year, once the HMIS/PACS are in place, hence proposed PACS should be able to handle this load and should be
validated for at least 2 lacs procedure and sufficient scalability to expand this in future.

6.3.1 Current Estimate of Hospital Imaging Throughput

Current No. of Exams per year

Modality Type No.
CT (Computed Tomography) GE Sytec4001 12808
MG (Digital Mammography) 172
MR (Magnetic Resonance) GE.2Tesla 2747

29
 US (Ultrasound - Grayscale) GELogic2000Pro 13454
Siemens Sonoline Adora
Color Doppler Toshiba Nemio 30 1068
GE Logic 400 CL

6.3.2 SI shall provide offering for the following:

Image acquisition Systems

• 2 x Film Digitizer Systems QC Workstation
The Quality Control workstation should have built-in modality work-list management support and through this and
other work-list support we should be able to copy and/or match patient data from HMIS.

Image Review Workstations

• x Diagnostic Reading Workstations (including 1 X DVD Archival workstation)
• 1 x Advanced Clinical processing workstation with Volume rendering, virtual endoscopy, Volume viewer,
CT/MR fusion software
• 2 x Cardiology workstation capable of doing DSA, QCA, QVA

Backup Server:
SI needs to propose backup server for the Image storage solution. The Backup server should be able to take-over if the
Primary Server fails (in case of server crash, disaster/fire, etc). As and when the Primary Server becomes live again, it
should automatically synchronize with the data on Secondary Server. This is to avoid Doctors from being stranded
without access to patient images at any point of time. Backup Server should consist of RAID-5 storage. The backup
Server
should be able to be used as Primary Archive also.

• Central Short-Term and Long-Term Image Storage

• Calculate Primary Storage for the given data. The proposed Archive Server should be compatible to RAID-5
Technology with atleast 3.5 TB effective storage.
• Calculate Long-Term Storage equal to 2 years worth of volume according to the data provided. The proposed
Archive should be proposed on the following technologies:
• Spinning disk based storage for Long term Archive.
• NAS Archive
Please provide complete configurations, with the corresponding Financial information for the configuration. Please
include in your response a PACS logical diagram that depicts the entire PACS configuration including modalities. To
prevent bandwidth clogging, it is proposed that only 25 concurrent users be allowed to access the PACS from any
terminal. There should be provision to upgrade this number in future, if required. Please include in your response
vendor recommendations for monitor types and quantities to support the various modalities and clinical applications.

6.3.3 PACS Structure

Please indicate your compliance with the following points:-

6.3.3.1 HMIS Integration

Please propose a broker-less HMIS integration with image management solution. Few of the top-level tasks to
consider are as follows.

Flow of Patient demographics from the Hospital Management System (HMIS) to the QC workstation as sometimes the
technician at the modality has limited information on the patient or procedure he or she is about to perform.
Facility to save the study instance UID to the information system
EMR accessing the images from the HMIS client directly The HMIS integration solution should be configured to
match the patient demographics from the information system with the incoming exams. If it is not matching
automatically, the solution should be proposed so that it can be done manually. The EMR of the hospital can be

30
 configured to display the images without logging into the image management solution in a single window. In addition
to above integration, the Quality Control feature should also be provided for checking whether all images made it
across the network from the modality, for CR/DR studies to check for proper image order, PA/AP, Lateral and
oblique.

6.3.3.2 Web Server

The Web Server proposed should be a complete DICOM solution. SI shall supply a cache-less web server as an
Intranet or Internet solution to permit access to radiographic image data and their relevant reports from a HMIS to
Clinician Offices. This should be a cache-less system where images and reports from the Primary Storage are readily
available to privileged users. Access to the server shall be accomplished via a normal Financial Web Browser,
(preferably Microsoft Internet Explorer 5.5 or 6.0).

Please keep in mind the following server sizing considerations for the same-

The relation between user roles and server performance is influenced by the ratio of user roles within the concurrent
user group. A radiologist user would open a lot more images and perform more processing than Referring physicians.
Server performance is also determined by the number of requests being processed by the server at a time. Even though
sizing documents are not requested now, the University can later, request server-sizing documents to understand the
sizing calculations of the vendor .To prevent unauthorized access to Patient data the web server must provide data
security with a user Login and Password. Based on user logon, the system shall know what privileges and studies a
user has access to. These access rights and privileges shall be configurable by the administrator.

7. Bid Evaluation

The evaluation of the Bid will be based on Prequalification questionnaire (Stage I), Technical Evaluation (Stage-II),
Bidder Presentations & Client References (Stage-III) and Financial (Commercial) / Price Evaluation (Stage-IV).

a) Once the bidder qualifies on the basis of prequalification questionnaire (Stage I), the Technical Evaluation Score
(Stage-II) shall be computed on the following grounds:

Sl. Strength Max. Score

Part A - For HMIS & other software

1. Quality Certifications 5
2. Product Architecture and Technical 10
• Performance (3 sec) for single transaction except for PACS.
• Scalable.
• Reliable.
• Available.
• Secure.
3. Implemented Customer sites of the Proposed HMIS 5
4. HMIS Functionality Requirements 50*
Total 70
Part B- For Bidder

5. Past Experience in Managing System Integration (SI) Projects 5

6. Manpower Strength-SI Vendor (including PMP certified PM) 10
7. Quality Certifications –SI Vendor 5
8. Network Installation Experience by the Implementing Agency 5

31
 9. Facilities Management & Maintenance Support Methodology 5
Total 30
(* this weightage will be equally distributed in all the functionalities mentioned under Section 5.2)
b) The qualifying criteria for Stage II shall be:

i. Part A Score must be >= 50

ii. Part B Score must be >= 20
iii. Total Score (Part A + Part B) must be >= 70

c) Stage-III evaluation would be limited to an exercise of verification of information provided the Bidder by means
of presentation & client references, which may include site visits. However, Stage-III evaluation may lead to
rejection including forfeiture EMD of any bid found to be inconsistent with claims made by the Bidder in
Stage I & Stage II evaluation

d) After completion of Stage-III evaluation, the Commercial / Price Bids of those Bidders who meet the criteria
mentioned in (b) & (c) above shall be opened. The Price Evaluation Score (Stage-IV) of these Bids shall be
computed on the following grounds:

If commercial bids for Bidder 1, 2, 3, 4………..are taken as L1, L2, L3, L4……..wherein L1 is the lowest bid;

The weightage given to commercial bids would be L1/L1, L1/L2, L1/L3, L1/L4……for Bidder 1, 2, 3,
4………..respectively.

Similarly weightage will be calculated for technical evaluation:

If scores of technical evaluation for Bidder 1, 2, 3, 4………..are taken as T1, T2, T3, T4…………wherein T4 is the
highest score;

The weightage given to technical evaluation would be T1/T4, T2/T4, T3/T4, T4/T4…………. For Bidder 1, 2, 3,
4………..respectively.

SI shall submit their proposals in three parts as prescribed in the Section General Information above.

Each proposal would be evaluated against the 70-30 criteria. This means 70% weightage will be given to Technical
proposal and 30% to financial proposal.

As a last step, the technical and financial scores obtained by all the organizations screened thru stage IV would be
summed and the organization that scores the highest would be AWARDED THE BID.

The final scores for the bidder 1, 2, 3, 4…………. Would be a follows:

Bidder 1:
(T1/T4)*0.7 + (L1/L1)*0.3

Bidder 2:
(T2/T4)*0.7 + (L1/L2)*0.3

Bidder 3:
(T3/T4)*0.7 + (L1/L3)*0.3

Bidder 4:
(T4/T4)*0.7 + (L1/L4)*0.3

32
8 Financial Bid

Kindly use the format given below to provide details of your Commercial Bid. It is mandatory that any change in these
formats, inclusion of any remarks, etc. be mentioned under” Deviation Schedule” to be submitted along with the
Technical Bid.

Item Description Year 0 Year 1 Year 2 Year 3 Year 4 Year 5

System Software-License Fees

Proposed HMIS Software-License

Fees
PACS

Telemedicine

Implementation Costs

Training Costs

Support Costs

Cost of Annual Maintenance Contract

(AMC) for 5 years
Upgrades and Enhancements

Infrastructure (networking)

Hardware (servers & clients)

Duties & Taxes

Other Costs

Grand Total

The SI Vendor is required to provide detailed, item-wise Bill of Material with break-up of costs as an Appendix along
with the Price Bid.

Also, an un-priced, detailed, item-wise Bill of Material shall be provided as an appendix along with the Technical Bid.

SI should also give the cost of the person month along with Price Bid.
SI should also give the 5 year Annual Maintenance Contract (AMC) costs to be included in the Tender/Price Bid

33