Part III | Page 1 of 29
RFP for Implementation of HIS-Hospital
Management System in CHC/PHC OF
Gorakhpur District of Uttar Pradesh
Part – III – Schedules of Draft Contract
Date: _________________
Tender Number: ____________
NHM –UP (Uttar Pradesh), INDIA
E-Mail_id:
Phone Numbers: (91 - 0522) 2237497, 2237498, 2237540
Fax Numbers: (91 - 0522) 2237
Part III | Page 2 of 29
Table of Content
1. SCHEDULE 1 - TERMS OF REFERENCE AND SCOPE OF WORK……..........04
1.1 Background……………………………………………………………..…04
1.2 Goals and Objectives……………………………………………………...04
1.3 Coverage of the Project…………………………………………………...05
1.4 Duration of the Project……………………………………………………05
1.5 Scope of Work…………………………………………………………….05
1.6 Modules of Hospital Information System………………………………...07
1.7 Software Requirement…………………………………………………….07
1.8 Suggestive Diagrammatic Representation of the Technical Architecture...08
1.9 Details of Manpower and Infrastructure………………………………..…09
1.9.1 Qualification and Experience of Staff Employed……………………………...…09
1.9.2 Hierarchical Structure of Technical Help Desk……………………………..12
1.9.3 Manpower at Health Facility level..................................................13
1.10 Software Application Development, Testing and Rollout………………..13
1.11.1 Sizing, Provisioning, Deployment and Commissioning of Hosting
infrastructure for the HIS Application……………………....................….14
1.11.2 Training and Handholding of Facility Staff………………………………14
1.11.3 Following are the Minimum Standards Required for Training…………..14
1.11.4 Schedule of Trainings………………………………………………….…15
Part III | Page 3 of 29
1.12 Integration with HMIS and MCTS data………………………………….15
1.13 Design Standards…………………………………………………………16
1.13.1 Data Privacy Standards – Protected Health Information………………………..16
1.14 Key Deliverables and Timelines………………………………………………...17
2. SCHEDULE – 2: DETAILED FUNCTIONAL AND TECHNICAL REQUIREMENT
SPECIFICATIONS…………………………………………………….…….19
2.1 System Security Requirements……………………………………….……….…19
2.2 MIS Reports……………………………………………………………………..22
2.3 Exit Management………………………………………………………………..22
3. SCHEDULE – 3: SERVICE LEVEL AGREEMENTS & PENALTIES……….…24
3.1 Payment Schedule……………………………………………………………….25
3.2 SLAs Applicable……………………………………………………………..…26
Part III | Page 4 of 29
Schedule 1 - Terms of Reference and Scope of Work
1.1 Background
Health care systems are highly complex, fragmented and use multiple information technology
system, incorporating different standards for similar or same systems. In order to be meaningful,
the health record of an individual need to be from conception (better) or birth (at the very least).
As one progresses through one’s life, every record of every clinical encounter represents an
event in one’s life. Each of these records may be insignificant or significant depending on the current problems that the person suffers from. Thus, it becomes imperative that these records be
arranged chronologically to provide a summary of the various clinical events in the lifetime of a
person.
The customized software will register each patient with the help with a unique ID. This ID will
contain the personnel and demographic data. During the subsequent visits patients medical
records and personnel details will be automatically fetched from the cloud based server. This
software must be capable of generating various reports required by the user. The detailed
configuration and reporting formats will be decided during the system analysis and design phase.
1.2 Goals and Objectives
The main objectives for establishing the HIS are as followed:
Capture Health records from Birth to death
Provide an effective communication to create awareness for better disease control
Strengthen PHC by providing a electronic referral feature to specialized doctors
As Healthcare systems are highly complex, fragmented and use multiple information
technology system, forms that can be dynamically customized is imperative.
Internet connectivity in rural Uttar Pradesh is a challenge and thus the system needs to
work on an online – offline mode i.e., data entry should be possible even without
internet connectivity
Generation of standard and customizable reports in tabular or graphical form can
produce useful data for monitoring the performance of the health facility to achieve
better care.
Part III | Page 5 of 29
Maternal Mortality Rate (MMR) is a key indicator of Health performance of a state, so
special emphasis has to be placed on this aspect, thus the application should capture
relevant records and should provide a dashboard on various parameters connected to
MMR for all applicable stake holders.
SMS reminders can be set to warn about upcoming scheduled tasks like vaccinations
(mother and child), therapies, etc.
Disease prevention can be initiated by sending SMS alerts when communicable diseases
are identified in real time.
A quick and fast on-ground roll-out to deliver early results.
Capture doctor attendance via biometric device implementation.
Should complement the existing NRHM application with portability to data handshake
and integration as applicable (HL7 communication compatible).
Should adhere to EHR standards finalized by MoHFW
Dynamically configurable forms for customized data capture.
1.3 Coverage of the Project
In the current scenario, the application installation is envisaged in about 60 PHCs and 29
CHCs/Block PHCs (03 under construction) across Gorakhpur, Uttar Pradesh.
1.4 Duration of the Project
The duration of pilot project is a period of one calendar years (12 months) from the date of
signing of the contract.
1.5 Scope of Work
Health records monitor the occurrence and severity of disease, the effectiveness and cost of
treatment & vaccination programs, and tracking other performance indicators like Maternal
Mortality Rate, Infant mortality rate, PHC / CHC performance, Doctor Performance. Records
can be kept manually on registers or in binders. However, to increase the likelihood that the
information is used to its fullest, the records should be computerized. Information recorded
should include:
Demographics:
Demographics should include Name, Age (calculated) , DoB, Father/Spouse name, Phone
Number, System Number, Address, Any Govt ID (not mandatory), other identifiers like
HMIS, MCTS etc (not mandatory).
Vitals Patient vitals like Height (Multiple readings for under 20 yrs), Weight (last 3-5
Encounters), BP, Pulse, Blood group and more as applicable.
Part III | Page 6 of 29
Family History Relevant family history that have a bearing on treatment plan
Social History Relevant Lifestyle related information, Smoking and Alcohol
Immunizations Record of Immunizations
Medications
Active Medications (Currently active prescriptions), In-active Medications ( 6 Months) &
Significant Medications ( Past Chemotherapy)
Alerts/Intolerances Allergies towards Medication/Food/Substances.
Visit History Past visits history, and vitals during such visits, an option to provide a graphical output of
past visit parameters
Chief complaints An area to capture the chief complaint by the patient
Investigations/ Lab Results Standard Lab results should be captured
Diagnosis The diagnosis should be captured, with an option to have drop downs with ICD 10 codes
Maternal Records For maternity Patients, additional records like LMPs, immunizations, Ambulance service
should also be captured.
Infant records
Infant records should capture head circumference, weight & height at each visit,
Vaccinations with pre-defined vaccination reminders.
Care Plan / Notes Notes by the doctor, which can assist in future visits
Birth Record
Part III | Page 7 of 29
An option to record birth date & time, along with height and weight, mother’s name, father’s name, Gender. The Application should also have an option to provide a birth record documents that can assist in birth certificates.
Death Record The date and time of death should also be captured, cause of death, explanatory
comments, and outcome of any further laboratory analyses. These records should be
available for further reporting and analysis
1.6 Modules of Hospital Information System:
1. Patient Registration
2. OPD Module
3. Investigation Module
4. Pharmacy Module
5. Referral Module
6. IPD Module
7. Maternal Health Module
8. Child Health Module
9. Personnel Management Module
1.6.1 Process Flow:
1. On arrival on health facility patient will fill the available patient’s form. 2. Then patient give the form to data operator and operator will register the patient with
UID number and will mention the UID on the form.
3. Patient will produce the form (containing UID) to doctor for further prescription.
A). Doctor may refer patient.
B). Doctor may write the prescription
C). Doctor may advice for medical tests(Lab/X-ray/etc).
4. Patient will collect the report from lab/x-ray/etc. (or/and) collect the medicines from
pharmacy.
5. All the above information (From step 3 to 4) will be mentioned in to patient form or
into additional Report.
6. Patient will display the form to the data operator and then data operator will enter the
details in to different modules of HIS
Part III | Page 8 of 29
1.7 Software Requirement:
A web based application with offline capability built on EHR standards (ICD -10,
SNOWMED etc) ensuring high data security and error free encapsulation of data
Use of open source software in development of HIS will be preferred .
Cloud based server will be preferred .
Internet connectivity should be minimum 512 kbps. for data transmission.
Interoperability within existing Information Systems and its up scalability.
Risk analysis and Mitigation.
Provisioning for security of data and network. It should conform to Electronic Health
Record Standards for India (Appendix 1), Approved by Ministry of Health & Family
Welfare, Government of India. Software application should be certified by STQC and should
follow GIGW guidelines .
Connectivity and synchronization of proposed system with existing systems HMIS/MCTS/
other state level portal.
Use of SMS Gateway platform.
With data expected to grow periodically better reporting tools and performance need to be
key consideration.
1.8 Suggestive Diagrammatic representation of the Technical Architecture:-
Server Hosting Environment
A centrally hosted web server in an electronically robust data center
Part III | Page 9 of 29
Load balancing is achieved through performance tuning across multiple servers present
within the datacenter setup for optimum effectiveness
The below provided table provides requisite information pertaining to the hosting server
environment required.
User (client) environment for online access
Computers with any of the operating system with one of the available browser installed
such as Google chrome, Internet explorer, Mozilla Firefox, Safari etc.,
All the mentioned browser software are free distributable. With connectivity, user based
access of features and information will be enabled on the platform.
User (client) Environment for Offline access
Installation of client for offline access will be required.
1.9 Details of Manpower and Infrastructure
The following sections provide details on the specific Manpower and Infrastructure expected to
be provide for successful implementation of Hospital Management System:-
209 data operators will operate from in about 60 PHCs and 29 CHCs/Block PHCs (2
Data Operators for each PHC and 3 Data Operators for each CHC), 2 Operators in
reserve for 1 Year
10 HIS Supervisor cum trainer on ground team with personal visits for training and
infrastructure maintenance.
Team of 3 Call center executives support (via phone and mail).
Team of 2 Technical support team (backend technical team)
Team of 2 data analysts for data analysis
1 Project Manager to manage the entire program.
Average 1 L SMS per month to patients/doctors
120 biometric devices for Staff of Health facility on rental basis.
209 desktop computers to capture health data on rental basis.
Internet connection to assist in maintaining central data repository.
1.9.1 Qualification and Experience of Staff Employed:
Post 1: Call center executive (03 Posts)
Part III | Page 10 of 29
Qualification
Bachelor’s degree preferably in computer science
Experience
1. 2+ years of user experience in Web applications.
2. Should have worked in at least two projects for web applications
3. Strong conceptualization ability, strong visual communication ability,
4. Exceptional design skills, production value and attention to detail
Post 2: Technical support team Member (02 Posts)
Qualification
1. BE/B,Tech/Master’s degree in computer science/IT/ITES
Experience
1. 3+ years of experience in software, Web applications.which leverage emerging
technologies, consumer electronics and System devices
2. Should have executed at least Four projects for web applications
3. Strong conceptualization ability, strong visual communication ability.
4. Experience in Data Analysis, Data Interpretation and Data sharing.
5. Exceptional design skills, production value and attention to detail
6. Experience with user interface design patterns and standard User-Centered Design
(“UCD”) methodologies
Post 3: Data analysts for data analysis (02 Posts)
Qualification
BE/B.Tech/Master’s degree in computer science
Experience
1. 5+ years of Social Sector preferably in Health Sector.
2. Should have executed at least Four projects for web applications and Data Handling
Part III | Page 11 of 29
3. Strong conceptualization ability, strong visual communication ability, .
4. On hand experience in Data Analysis, Data Interpretation and Data sharing.
5. Good command over MS-Office and any Data Analytical Tool.
Post 4: Project Manager(01 Posts)
Qualification
1. Must possess Master/Post-Graduate degree in Management or Technology
2. Certification in Program/Project Management is preferred (PMP ® or PRINCE2
Experience
1. Must have at least 7 years of experience in IT industry
2. Should have successfully delivered in the capacity of Project/Program Manager at least
two system integration and managed services projects of similar scope and nature
3. Must have managed in the capacity of Project/Program Manager a project costing more
than INR 2 Crores
4. Experience in project management in Government sector is mandatory
Role and Responsibilities
1. Shall be deployed on-site full time for the duration of the project
2. Responsible for organizing, planning, directing and coordinating overall program effort
3. Should have extensive experience and proven expertise in managing similar contracts
with Government
4. Establish overall HIS project management strategy
5. Implement the proposed implementation plan
6. Monitor overall project progress and provide direction
7. Responsible for periodically assessing the project resourcing and ensuring it is in line
with proposed deployment and adequate for project requirements
8. Assess project risks and ensure timely resolution
9. Ensure compliance to the terms and conditions of contract and SLAs
10. Manage project scope
Part III | Page 12 of 29
1.9.2 Hierarchical Structure of Technical Help Desk:
Part III | Page 13 of 29
1.9.3 Manpower at Health Facility level:
Post 1: Data Operator (209 Posts)
Bachelor’s degree preferably in computer science
Experience
1. 3+ years of user experience in Web applications which leverage emerging
technologies and interaction with end user to sort out the related issues.
2. Should have executed at least two projects for web applications
3. Strong conceptualization ability, strong visual communication ability, Exceptional
design skills, production value and attention to detail
Post 2: HIS Supervisor cum trainer (10 Posts):
Qualification
1. BCA/MCA or Master’s Degree in Social Sciences with PG Diploma in Computer
Application
Experience
1. At least 3 years’ experience in capacity building and training programs of Government of
India or any state government in India
2. Should have expertise in capacity building and development of training modules,
curriculum and materials with specific focus on bringing about Behavioral Change
1.10 Software Application Development, Testing and Rollout
The System Integrator shall be expected to perform the following activities as part of this
project:
Deliverable Description
Inception Report Inception report (detailing schedule of work, key staff deployment,
methodology, etc.) and Inception Workshop to discuss with Client.
Systems
Requirement Study
All key aspects of design (MIS structure, indicators, report formats,
information flow, internal and external software structure and hosting
arrangements, additional hardware/software/ data/ connectivity
requirements, institutional arrangements, etc.) in close consultation with
SMPU- MIS section and user.
Part III | Page 14 of 29
Hospital Information
System Design and
Development
Design Stage: Indicators, information flow, institutional arrangements,
software, hardware, and process design in close consultation with SMPU-
MIS section and user.
Testing including
UAT
Demo with Beta version and before go live of HIS
Project Management
and Monitoring
System
Testing Phase : software testing, full data entry and roll-out for selected
modules in implementation areas.
Full Roll-out Phase: deployment of system in all project areas for full
functionality
Post Roll-out: handholding support, proactive use, bug fixes & updates
till end of assignment
Documentation and
Training
MIS documentation (design, use, and training manuals, organizational
roles, etc.), on-the-job training
Final Report Final overview of activities, review of MIS use, user perspectives, issues,
suggestions for improvement and sustainability.
1.11.1 Sizing, Provisioning, Deployment and Commissioning of Hosting infrastructure for
the HIS application
1. The OPERATOR shall be responsible for sizing of the infrastructure required for hosting
the HIS application in line with the service levels expected.
2. The OPERATOR shall be responsible for provisioning and deployment of the
infrastructure as required.
3. The OPERATOR can host the solution on cloud based server.
1.11.2 Training and Handholding of Facility Staff:
1. Training and handholding of Facility staff is an important responsibility of the
OPERATOR in this project.
2. The OPERATOR is responsible for adopting the appropriate training and handholding
approach to ensure that the HIS objectives are achieved.
3. The OPERATOR shall be responsible for developing the training and capacity building
strategy best suited for the conditions prevailing in the state of UP.
1.11.3 Following are the Minimum Standards Required for Training
1. A total of 2 days of training per Facility is required to be provided during the course of
training.
Part III | Page 15 of 29
2. Training has to cover the entire staff of facility engaged in the manual transaction going to
be supported by Hospital Management System
3. A minimum capacity of Master Trainers should be deployed as followed by OPERATOR
i. 3 per CHC,2 per block PHC and 1 for New PHC.
ii. The training can be conducted in a larger batch size but the Trainer:
Trainee ratio shall not increase beyond 1:5
iii. Training content shall be developed and delivered in Hindi
4. During each training, the OPERATOR shall be responsible for providing hard bound,
printed, Training Material, Handouts to each staff.
5. Co-ordination with OEM of System Devices: Where issues reported pertain to the devices,
the OPERATOR shall be responsible for invoking the required warranty and support from
OEM OPERATOR.
1.11.4 Schedule of Training:
The OPERATOR shall be fully responsible for tracking and reporting training status as
per following schedule.
At the time Go Live: 2 day training to orient the staff in usage of System computer
System which includes
Comfort with the application, usage of the application including its several features and
functionalities
1.12 Integration with HMIS and MCTS data: The purpose of integration with the third
party is to have a seamless communication channel for data exchange without loss of
data integrity
1. The solution shall have the capability of exchanging information with the third party
interface with the ones mentioned in the diagram below. The list of system is indicative
and there may be more systems. The data exchange shall be using open standards and not
with the proprietary protocols
2. The OPERATOR shall be responsible for necessary data encoding, encryption and
compression methods to ensure secure and efficient data transfer between the systems
3. The solution shall have the capability to provide data and access to notifications to other
solutions that will be part of the integration
4. The Solution shall have the capability to request and update information from the third
party.
5. The integration with the HMIS and MCTS will be subject to the policies and conditions
of GOI.
Part III | Page 16 of 29
Figure 1: Integration with third party
1.13 Design Standards
1.13.1 Data Privacy Standards – Protected Health Information
1. The data being collected as part of the HISHIS application about the end beneficiaries,
viz., women, children and adolescent girls falls under the category of Protected Health
Information.
2. Protected health information (PHI) is any information about health status, provision of
health care, or payment for health care that can be linked to a specific individual.
3. The OPERATOR shall be responsible for managing and ensuring the privacy of this
information.
4. Specific data protection modalities would need to be worked out by the OPERATOR in
consultation with NHM-UP or DGMH.
5. For all reporting purposes to third parties, data shall be anonymized as per the United
States HIPAA norms.
6. The data must not leave the geographical boundary of India.
7. All personally identifiable information must be encrypted on transmission, storage,
backup and retrieval
8. Any data privacy breach (data leakage) must be notified immediately to the concerned
authorities
9. Access to personally identifiable information shall be secure and must be accessible only
to Authorized personnel. The list of authorized personnel with access to personally
identifiable information is always known
Part III | Page 17 of 29
10. Detailed audit logs will be available to track and trace access to personally identifiable
information
11. All personally identifiable data must be erased completely upon completion of its life
cycle
12. No personally identifiable data should be allowed to be downloadable without
appropriate protection mechanism built-in (password locked files etc.)
13. No biometric, audio, video, photographic personal data shall be downloadable from the
application for offline use or into a storage system or server or backup device.
14. In addition to the above, the OPERATOR shall be required to comply with any laws or
guidelines pertaining to Information Security, Data Protection, Cloud usage regulation
and Data Privacy as may be promulgated or issued by the Authority or by any competent
authority under the Government of India or the Government of Uttar Pradesh which may
be applicable to this project including but not limited to those issued under the
Information Technology Act, 2005.
1.14 Key Deliverables and Timelines
1. The following table provides the expected timelines for design, development and roll out
of the HISHIS application across district Gorakhpur covering the entire user group.
Deliverable Description Timeline for
completion
Signing of
Contract
T
Inception Report Inception report (detailing schedule of work, key staff
deployment, methodology, etc.) and Inception Workshop
to discuss with Client.
T+2 Week
Systems
Requirement
Study
All key aspects of design (MIS structure, indicators,
report formats, information flow, internal and external
software structure and hosting arrangements, additional
hardware/software/ data/ connectivity requirements,
institutional arrangements, etc.) in close consultation
with SMPU- MIS section and user.
T+4 Week
Hospital
Information
System Design
and Development
Design Stage: Indicators, information flow, institutional
arrangements, software, hardware, and process design in
close consultation with SMPU- MIS section and user.
T+6 weeks
Part III | Page 18 of 29
Testing including
UAT
Demo with Beta version and before go live of HIS T+6 Weeks
Project
Management and
Monitoring
System
Testing Phase : software testing, full data entry and roll-
out for selected modules in implementation areas.
Full Roll-out Phase: deployment of system in all project
areas for full functionality
Post Roll-out: handholding support, proactive use, bug
fixes & updates till end of assignment
T+8 weeks
Documentation
and Training
MIS documentation (design, use, and training manuals,
organizational roles, etc.), on-the-job training
T+9 weeks
Final Report Final overview of activities, review of MIS use, user
perspectives, issues, suggestions for improvement and
sustainability.
T+12 weeks
Part III | Page 19 of 29
Schedule 2: Detailed Functional and Technical Requirement Specifications:
2.1 System Security Requirements
1. The solution shall be configurable to prevent corruption or loss of data already accepted
into the solution in the event of a solution failure
2. The solution shall support protection of confidentiality of all Protected Health
Information (PHI) delivered over the Internet or other known open networks via
encryption using triple-DES (3DES) or the Advanced Encryption Standard (AES) and an
open protocol such as Transport Layer Security (TLS), Secure Sockets Layer (SSL),
Internet Protocol Security (IPsec), XML encryptions, or Secure/Multipurpose Internet
Mail Extensions(S/MIME) or their successors.
3. The solution, when storing PHI on any device shall support use of standards based
encrypted format. The solution, prior to access to any PHI, shall display a configurable
warning or login banner (e.g. "The solution should only be accessed by authorized
users").
4. In the event that a solution does not support pre-login capabilities, the solution shall
display the banner immediately following authorization.
5. The solution shall ensure that the inbound and outbound data stream on third party data
from external data sources shall be secured
6. The solution shall record any change to the registration record in a log with details like
name of the user making the changes, timestamp of transaction, etc.
7. The solution shall maintain a log of all user activities related to access - view and printing
of the validation of the registration validation list. The log, among other details, shall
include the user id, access date and time, and type of accesses made. The log shall be
linked to the registration record and available for access for the authorized users
8. The solution shall ensure that registration data is accepted only when submitted by a
human and not by an automated program
9. The solution shall provide secure and automatic access to external web services
10. The solution shall provide local data persistence and security on System devices.. The
HIS application is expected to work in a wide geography which may not necessarily have
good network connectivity at all times. While detailed technical requirements have been
provided in the RFP for device requirements, the requirement for 'local data persistence'
also requires that the solution should be capable of storing data captured in an offline
mode and replicate with the central HISHIS server whenever network connectivity is
available. In light of this requirement, the HIS application and it's modules should be
capable of operating in an 'online-offline' mode and should be capable of securely storing
the data locally until it's replication with central server. OPERATOR System
11. The solution shall provide applications to rely on location information for location
awareness
12. Shall have no legal implications of using 3rd party / Open Source software
Part III | Page 20 of 29
13. All images used in the web application must not have any legal / copyright issues
14. Shall have the ability to detect and defeat Flooding / DoS (Denial of Service) attacks on
the portal. Shall be tested with appropriate tools and report submitted for verification as
part of User Acceptance Testing
15. Shall prevent partial sync of System device data. Data is either fully present OR not
present
16. Shall have appropriate Authentication, Authorization and User management features
17. Shall have ability to backup and restore all data with daily incremental backups
supporting data recovery up until past 24 hours at least
18. Shall be certified via appropriate VAPT (Vulnerability and Penetration Test) suite and
report submitted
19. No screen shall take more than 10 seconds to load at stipulated loads. Shall be tested via
appropriate tools and report submitted
20. Shall support English and Hindi for data entry and display
21. Shall be able to store, search and retrieve data for of past 1 years and archive data for past
10years
22. The application shall have log rotation enabled for all log files
23. System Web application must support IE9 and after, Safari, Chrome and Firefox
browsers
24. Web application must support IE, Chrome and Firefox browsers
25. Web application should be responsive and support form factor for desktop, tablets and
System phones.
26. Web application shall not download any Active X / Applet controls for its functioning.
27. Web application shall not need Java Run Time or .NET run time to perform its
functionality
28. No password / sensitive information shall be transmitted / stored in clear text anywhere in
the communication pathway OR in database
29. The application shall not allow downloading photographs uploaded to the application to
protect privacy of pictures taken.
30. Application shall have context based help menu available
31. User interface must have a defined style guide which shall be adhered to during the
implementation
32. User interface must follow a uniform pattern with a common style sheet across pages
33. Shall be built using tools and libraries and protocols that are de facto standards in
industry
34. Shall be secure at all layers – UI, Application and data
35. Choice of technologies should allow quick development, build and deploy cycles
36. Shall support quick and easy integration into existing MCTS and other systems as
deemed necessary using HTTP based Restful APIs
Part III | Page 21 of 29
37. Shall not require any special plug-ins and privileges on the browser to access the
application
38. System Device Management requirements
39. General Requirements
40. The solution shall be capable of application scanning to detect and resolve issues and
vulnerabilities prior to deployment.
41. The solution shall enable compression of local data store and encryption and
synchronization of local data store in each of the devices with the central HIS server.
42. The solution shall enable User Authentication in offline and online modes in the devices.
43. The Solution shall track and maintain detailed records on all changes via interfaces and
authoring to support audit requirements.
44. The Solution's data model must be expressed using commonly accepted logical data
model conventions with associated metadata.
45. Authoring and Workflow Functionality
46. The Solution shall provide flexible and comprehensive workflow capabilities to enable
users to collaborate effectively in the authoring and management of data.
Security requirements
47. The Solution shall have the ability to integrate the data within the MDM with
management and security tools.
48. The Solution shall manage the policies and rules associated with privacy access rights.
49. The Solution shall allow configuration and management of differing visibility rules,
providing different views for different roles.
50. The Solution shall be able to support user authentication.
Application management
51. The solution shall restrict which applications may be installed through white listing or
blacklisting
52. The solution shall support install, update, and remove applications
53. The solution shall be capable of restricting the use of synchronization services (e.g., local
device synchronization, remote synchronization services and websites)
54. The solution shall digitally sign applications to ensure that only applications from trusted
entities are installed on the device and that code has not been modified.
55. Monitor/report
56. The solution shall provide insight on the users’ activities, data usage, bandwidth usage, device availability and other such statistics to enable optimization of the overall HIS
solution.
57. The solution shall determine if a user is complying with security policy and what actions
are permissible by the end user.
Part III | Page 22 of 29
2.2 MIS Reports
The solution shall be able to prepare pre-defined reports and dashboards as per the
requirements of NHM-UP.. The solution should be flexible to support reporting of
additional indicators as and when they are required to be added to the reports/dashboards.
Following is the minimum set of Key Reports required:
Department Reports (including Lab &
X Ray)
Department wise Service Availed
Service Wise Report.
Summary Reports
Department wise Doctor OPD
Service Summary
Doctor wise OPD Service
Summary
Department wise detailed report
Consent Form
Hospital Out Pass
Pharmacy Report
Stock Position
Expense Summary
Dangerous and life saving Drug list
List of Medical Equipment
Critical shortage Report
OPD Reports
Department wise OPD Report
OPD Register
Missing Registration No.
Report.
Missed OPD List
OPD Slips
OPD Card Printing
OPD Card List Report
IPD Reports
Discharge Register
Admission Register
Discharge\Admission Register
ICD Register
Chemist Report
Admission\Consent form
Exception Reports
Patient Search
Patient Stay & Diet Summary
Patient Satisfaction Report
Any Other User Desired Reports
User Log-in Report
2.3 Exit Management
The key guiding principles which the OPERATOR shall follow during the exit and
transition are as follows:
1. Early planning for exit (at least 3 months before the end date of contract).
Part III | Page 23 of 29
2. All key approvals to be sought well in time from the Authority.
3. Transition of all IT and non-IT assets against a checklist prepared in collaboration with
the Authority.
4. Testing of application readiness in the new environment provided by UP-NHM
5. Training and knowledge transition to personnel identified by UP-NHM
6. Ensuring Disaster Recovery readiness
Accordingly, the OPERATOR’ exit is divided into three phases, i.e.
Exit needs identification: X-3 months to X–2months, where X is end date of the contract
1. Identify and create a detailed checklist of exit needs across hardware, software,
people, process, documentation, training and other support functions and take a sign-
off from the authority.
2. Identify and communicate the IT and data center environment requirements for
porting/hosting the solution and facilitation initiation by the authority
3. IPR (Intelactual Property Rights) of software will belong to authority.
Exit preparation: X-2 months to X - 1 month
1. Assess infrastructure requirements and site readiness for hosting the solution
2. Transfer all the code and non-code artifacts to authority
3. Transfer all training related material including IEC material, training curriculum,
audio-visual aids etc.
4. Hand-over all agreed assets including tablets, smart phones and other peripheral
assets
Exit execution and closure: X- 1 month to X
1. Porting the solution to data center specified by the authority
2. Support NHM -UPUP-NHM in acceptance testing activities on site
3. Support authority in on-boarding of the new support unit
The following deliverables are required to be submitted to UP-NHM at the time of project
completion. The contract shall be deemed to be complete upon submission of the following
deliverables to UP-NHM.
a. User manuals of the entire system
b. Complete documentation of the project
c. Source code of the entire application
d. Transfer of all data, reports, dashboards, analytics solutions and knowledge
objects created during the course of the contract
e. Training to a team 15-20 people for 5 days
f. Training material
g. Audio/Visual content developed for the project
h. Summary of best practices and key learnings
Part III | Page 24 of 29
On its part, the Authority shall assist the OPERATOR in the following:
1. Identification of agency/team to whom the OPERATOR is required to transition the
operations as part of its exit.
2. Nomination of a Nodal officer to coordinate the transition project between the
OPERATOR and the Authority.
3. Provisioning of required facilities/infrastructure as per the OPERATOR’s request to successfully complete the transition and exit.
3. Schedule – 3: Service Level Agreements & Penalties
1. This schedule details the expected service levels for various services to be provided by
the OPERATOR. OPERATOR services shall be measured against the service level
metrics as explained in this schedule.
2. The service level targets define the levels of service to be provided by OPERATOR for
the duration of this contract or until the stated SLA targets are amended.
3. Each SLA has been assigned a Severity Level and Penalties shall be applied against the
corresponding payment specified in this section for not meeting the SLA.
4. The payment milestones referred to in this section are drawn from Article 7 of the
Contract.
5. The severity levels and the corresponding penalty percentage have been defined in the
table below.
Severity
Level Penalties as a percentage of payment linked to the SLA
5
Breach of any SLA with this severity level shall be treated as an event
of default and the corresponding consequences as outlined in the
Contract shall follow
4 10.00%
3 5.00%
2 2.00%
1 1.00%
6. Cumulative Penalties for each month, where the Penalty is linked to the monthly
payment, shall under no circumstance exceed 25% of the fee payable for that month.
7. Calculation of Time Period for which a penalty is levied: The penalties applicable will be
assessed for failure to meet the agreed service levels, in any Calendar month. The
Calendar month shall be calculated commencing from 00.00 hours of the first day to
24.00 hours of the last day of the relevant Calendar month.
8. Imposition of Penalty Provisions: Imposition of penalties pursuant to this Schedule
will be effective only from the Effective Date.
9. Disputes: The OPERATOR may appeal to the Authority, in writing within ten (10)
working days of receipt of notification, for the imposition of any penalty or regarding the
Authority’s penalty calculations.
Part III | Page 25 of 29
10. Recovery of penalties: Any penalty payable under this Contract shall be recovered
through deductions from the payments specified against each SLA payable by the
Authority. In the event the penalty exceeds the corresponding payments, the same shall
be recovered by the Authority from the encashment/ invocation of the Performance
Security.
3.1 Payment Schedule
A. Up to go live stage- 20% of bid amount will be payable as per following table-
Deliverable Description Timeline for
completion
% Payment
from 20% of
Bid amount
Signing of
Contract
T
Inception Report Inception report (detailing schedule of work, key staff
deployment, methodology, etc.) and Inception
Workshop to discuss with Client.
T+2 Week
Systems
Requirement
Study
All key aspects of design (MIS structure, indicators,
report formats, information flow, internal and external
software structure and hosting arrangements,
additional hardware/software/ data/ connectivity
requirements, institutional arrangements, etc.) in close
consultation with SMPU- MIS section and user.
T+4 Week 10%
Hospital
Information
System Design
and Development
The Information System developed with at least
known Project included in Draft stage.
Design Stage: Indicators, information flow,
institutional arrangements, software, hardware, and
process design in close consultation with SMPU- MIS
section and user.
T+6 weeks
Testing including
UAT
Demo with Beta version and before go live of HIS T+6 Weeks 20%
Project
Management and
Monitoring
System
Testing Phase : software testing, full data entry and
roll-out for selected modules in implementation areas.
Full Roll-out Phase: deployment of system in all
project areas for full functionality
Post Roll-out: handholding support, proactive use,
bug fixes & updates till end of assignment
T+8 weeks 20%
Part III | Page 26 of 29
Documentation
and Training
MIS documentation (design, use, and training
manuals, organizational roles, etc.), on-the-job
training
T+9 weeks
Final Report Final overview of activities, review of MIS use, user
perspectives, issues, suggestions for improvement and
sustainability.
T+12 weeks 50%
“Go-Live” is defined as the achievement of all of the following conditions by the operator to
capture at least 50% of the average of the OPD attendance
of the particular facility for the preceding 03 months in the HIS system within 45 days of
signing of the contract in district. Installation and commissioning of requisite software and
hardware and 2 day training of all staff connected with the use of HIS at facility level
regarding functioning and actual use (on the job training) The training module should also
include basic computer training as and where required. 75 % of OPD attendance of the
average stipulated above should be captured within 60 days of signing of the contract. 90%
of the OPD attendance should be captured in the new system within 90 days of signing of
the contract.
All the modules of the system should be fully functional and populated with patient data within
90 days of signing of the contacts.
B. Rest of 80% of bid amount will be payable through 9 monthly equal amount.
3.2 Following are the SLAs applicable for this Project.
A. Upto Go Live stage
Following penalties/deductions will be applicable
Deliverable Description Timeline for
completion
Severity Guideline for
computation
Signing of
Contract
T
Inception
Report
Inception report (detailing
schedule of work, key staff
deployment, methodology,
etc.) and Inception
Workshop to discuss with
Client.
T+2Week 4 Penalty
corresponding to
the severity level
shall be levied for
each week of
delay beyond the
target
Systems
Requirement
Study
All key aspects of design
(MIS structure, indicators,
report formats, information
flow, internal and external
T+4 Week 4 Penalty
corresponding to
the severity level
shall be levied for
Part III | Page 27 of 29
software structure and
hosting arrangements,
additional
hardware/software/ data/
connectivity requirements,
institutional arrangements,
etc.) in close consultation
with SMPU- MIS section
and user.
each week of
delay beyond the
target
Hospital
Information
System Design
and
Development
The Information System
developed with at least
known Project included in
Draft stage.
Design Stage: Indicators,
information flow,
institutional arrangements,
software, hardware, and
process design in close
consultation with SMPU-
MIS section and user.
T+6 weeks 4 Penalty
corresponding to
the severity level
shall be levied for
each week of
delay beyond the
target
Testing
including UAT
Demo with Beta version
and before go live of HIS
T+6 Weeks 4 Penalty
corresponding to
the severity level
shall be levied for
each week of
delay beyond the
target
Project
Management
and
Monitoring
System
Testing Phase : software
testing, full data entry and
roll-out for selected
modules in implementation
areas.
Full Roll-out Phase:
deployment of system in all
project areas for full
functionality
Post Roll-out: handholding
support, proactive use, bug
fixes & updates till end of
assignment
T+8 weeks 4 Penalty
corresponding to
the severity level
shall be levied for
each week of
delay beyond the
target
Documentation MIS documentation T+9 weeks 4 Penalty
Part III | Page 28 of 29
and Training (design, use, and training
manuals, organizational
roles, etc.), on-the-job
training
corresponding to
the severity level
shall be levied for
each week of
delay beyond the
target
Final Report Final overview of
activities, review of MIS
use, user perspectives,
issues, suggestions for
improvement and
sustainability.
T+12 weeks 4 Penalty
corresponding to
the severity level
shall be levied for
each week of
delay beyond the
target
Part III | Page 29 of 29
B: After Go Live:
Deductions from monthly payment will be calculated as per the below table:
Sl. No. Deliverable Severity Guideline for
computation
1 HIS operational with all the conditions
mentioned in the agreement in each
facilities
Proportional Deduction Proportional deduction
on the basis of number
of Health facilities with
Non operationalization
of HIS.
2 OPD Registration and prescriptions
captured
Proportional Deduction Proportional deduction
on the basis of number
of Health facilities with
incomplete/No data
captured.
3 IPD Registration and prescriptions
captured
Proportional Deduction Proportional deduction
on the basis of number
of Health facilities with
incomplete/No data
captured.
4 Pharmacy data captured Proportional Deduction Proportional deduction
on the basis of number
of Health facilities with
incomplete/No data
captured.
5 Lab data captured Proportional Deduction Proportional deduction
on the basis of number
of Health facilities with
incomplete/No data
captured.