Request For Proposal Primary System Integrator for e-Health Project [PDF]

Request For Proposal for selecting

Primary System Integrator for e-Health Project Volume 3 - Functional Requirements eHealth Project Management Unit Directorate of Health Services, General Hospital Junction, Thiruvananthapuram – 695 035

February 2014

CONTENTS 1. Hospital Management System 2. Web Portal 3. Public Health Monitoring System 4. Procurement and Asset Management 5. Maintenance Management 6. General Administration Module 7. Document Management Solution: 8. Management Information System

1

Hospital Management System

1.1 General Architecture The proposed architecture is based on a centralized hosted environment consisting of a standards based clinical data repository that contains a longitudinal record of patients. The central repository is a collection of documents for patients created at different points in time across clinical encounters and episodes. To enable interoperability of clinical information across points of care for patients the central repository shall be compliant with HL7 CDA and CCD document structures. There will be a Lean Local Server in the Institutions. The main purpose of this local server is to hold data to ensure business continuity in case of a connectivity failure. The solution proposed should be in line with this requirement. The detailed General Architectural Requirements of the Hospital Management System are described below:

1.2 Central System The central system shall have the following capabilities Requirement Feature Description ID HMS-GR.1 Unique identifier 1. The centralized master person Index shall provide a single (Centralized point of reference to a patient, clinician, payer, or other Master Person healthcare entity within the state environment. This shall Index) be the central single source of data for patient demographic information 2. Centralized master person index should be capable of handling multiple identifiers (Hospital registration numbers, govt issued identities, UHID/Aadhaar. 3. The system should be able to de-duplicate person information for multiple registrations using a heuristic algorithm and establish a unique identifier for the patient 4. The master person index shall be able to interact with external systems through open standards web services based architecture 5. The Centralized master person Index shall be capable of integrating ( Data exchange and de-duplication with other govt citizen databases) HMS-GR.2 Longitudinal 1. The centralized Clinical Data Repository (CDR) shall be Clinical the common longitudinal repository of clinical episodes, repository clinical encounters, medication, lab and diagnostics results 2. The repository should support HL7 CDA and CCD document structures

HMS-GR.3

3. The repository should be able to normalize these CDA documents in the database so that a sub section of CDA can be queried independently and also used for analytics. 4. The key function of the CDR is to capture and store healthcare transactions from any relevant healthcare domain (Diagnosis, Lab, Medication etc). To enable interoperability, central eHealth requires an open HL7 V3 standards based repository conforming to the EMR/EHR standards prescribed by Government of India to ensure data can be reused for secondary purposes, such as continuity of care. 5. Interfaces: The CDR must be exposed through open standards based (Eg:Java/J2EE) application-programming interfaces. Local (hospital, CHC/PHC) applications (described later) should be able to interact with the central repository to submit and extract required information leveraging the document index. 6. Terminology Services: A collection of services allowing the CDR to utilize the prevailing clinical terminologies for coding data including LOINC, CPT4, ICD 10, SNOMED, drug databases and other coding systems prescribed by Government of India. Terminology services should also provide a provision to load custom terminologies and custom terminology maps. In addition the Terminology Services should provide mapping functionalities between the loaded terminologies – current and future terminologies – in effect ensuring consistency of data in the CDR over the years, allowing for the creation of a true longitudinal patient health record. The Terminology services should allow for the uploading of custom, implementation specific concepts and terminologies. 7. Inbound and Outbound Messaging Services: A collection of services that will allow the CDR to exchange inbound and outbound HL7 CDA and CCD documents. Document Index The Clinical Document Index (CDI) operates as an adjunct to the Clinical Document Repository. It provides a central location which document consumers (Hospital/PHC/CHC systems) can query for information about, availability and location of shared clinical documents in one or multiple repositories.

1.3 Hospital System HMS- Outpatient GR.4 Management

1. The outpatient setup in PHCs and CHCs shall request the centralized patient record for clinical history documents of the patient once the patient is checked into the hospital/PHC/CHC. Once the patient is in the queue in the backend the system shall get the relevant documents and cache these documents in the local point of care application for doctor to view the patient history. The following table defines the data set that should be available to the doctor Title Content Demographics Name, Age ( Calculated) , DoB, Father/Spouse name, Phone Number, Address Vitals Height (Multiple readings for under 20 yrs) Weight ( last 3-5 Encounters) Pediatrics Patients  Pediatric Parameters like Head Circumference Conditions Current Active conditions (ICD 10 Codes) Past Notable Conditions (ICD 10 Codes) Family History Relevant family history Chronic conditions Relevant Acute Conditions ( Cancer) Social History Relevant Lifestyle related information Diet and exercise Smoking and Alcohol Living Conditions Immunizations Record of Immunizations Medications Active Medications ( Currently active prescriptions) In-active Medications ( 6 Months) Significant Medications ( Past Chemotherapy) Alerts/Intolera Allergies nces ( Medication/Food/Substances/Medications) Procedure Past Procedures and amputations if any History Past Past 6 Months Encounter History Encounters Chief complaints, Diagnosis, Outcome, Investigations Medications Care Plan Active Care Plan Results Past One year investigation orders Past One year investigations results Notes Clinical notes 2. The screening process by a nurse shall also be able to identify the relevant documents required for the clinical encounter with the

3.

4.

5.

6.

HMSGR.5

In-patient Management

HMSGR.6

Specialty providers

specialist. However the nursing staff shall be able to request for the documents but not view these documents for patient privacy purposes. In this case the patient once checked in and queued for a specific doctor shall be deemed to have provided consent to the doctor to view his clinical history. The consent shall be implied once the appointment is fixed. Based on the need the doctor can ask the central patient record system to provide more detailed history or search for specific document and view a broader range history of the patient. In case of larger hospitals once the appointment is fixed the system should be able to schedule a caching of relevant documents from central patient record between the check in to appointment waiting time of the patient. The new data generated as part of the encounter shall be captured in relevant templates; these templates can be designed as per the needs of the facility/clinical practice or chronic /acute disease, based on the CDA architecture. The encounter information (Observations, results, medications, notes) shall be captured in these documents and uploaded to the central patient record as a part of its continuum of care. The data captured shall be stored in a temporary local storage system for the day in case of OP. This is a back up to take care of the business continuity in case of a loss of connection with the central server.

In patient scenario is higher in transactions and shall follow similar process to the outpatient scenario, where the patient history (Longer duration than outpatient) shall be cached in local system once admission is done. In this case the consent shall be implied to the care provider organization as in many scenarios multiple physicians maybe coordinating care for one patient. The local history shall be kept in the facility till the completion of the episode of care and data generated in multiple clinical encounters in the episode shall be captured in clinical documents and regularly (daily) synchronized with the central patient record. At the end of the episode the discharge summary shall be prepared and stored in the central patient record for continuum of care. In case of specialty providers using local specialty systems like Oncology system, Cardiology application, the point of care specialty system can be used as a source system to the central patient record. The local specialty system should be capable of exchanging CDA documents with the patient record

1.4 Offline Mode HMS-GR.8

Ability to capture encounter data

HMS-GR.9

Temporary local storage

HMSGR.10

Synchronisation with Central Server

The point of care shall have a lean application designed to meet the particular needs of the point of care in case of a connectivity failure. The lean application will leverage the centralized patient health record to view and later update the patient history. The lean application shall also enable the clinical activities in the institution to go on without a linkage with the central sever which may be unavailable due to loss of connectivity and later update the patient history when connectivity is restored. The requirements of this local Hospital system are discussed here. In case of loss of connectivity, the local Point of care solution should be able to provide ability to capture encounter data for the patient. The data capture can be based on most frequently used templates. For example, General template to capture patient encounters. Pediatric template for children, Woman care/pregnancy templates for pregnancy cases. These templates shall be defined with clinician inputs. These templates can be based on HL7 CDA standards. The local solution should provide a temporary local storage of clinical data CDA/CCD based templates. a. The temporary storage should store the encounter data locally until its synchronized with the central patient repository b. The temporary storage should provide ability to store data received from central patient repository for the duration of patient visit c. The temporary storage should be capable of providing persistence for long term care plans for Inpatients d. The temporary storage should be secure and encrypted and should provide access control based on confidentiality and privacy requirements e. Temporary store should be temper proof and should not allow any unauthorized access including system administrators access to patient clinical data The system shall initiate a synchronisation process with central server a soon as connectivity is restored.

1.5 Other General Requirements are described below: HMS-GR.11 Alerts, eHealth shall have a Decision Support System (DSS) built over Warnings and the existing protocols prevalent in the Department. The Exceptions: Decision Support System of the Application shall throw appropriate alerts and warnings which are rule based and relevant for the stake holders. At various points there can be situations which the system cannot handle due to various reasons. The system shall have foolproof methods to handle such exceptions. This means that if the system fails to generate an output or complete the process as described in the FRS at that point there shall be alternate methods to continue the process. The system shall also generate meaningful messages to help the user solve the problem. The methods to continue the process shall be clearly defined in the SRS in consultation with the Users. HMS-GR.12 User Interfaces The number of persons approaching Public Healthcare (UI): Institutions for medical care is huge. The average OP and IP in each institution is given in Section……… It is very obvious that every individual healthcare provider in the system starting from the Nursing Assistant at the OP Ticket counter to the Specialist Doctor in the OP Clinic or IPD are hard pressed for time and resources to service such an enormous crowd in front of them. The system shall be designed in such a way to make the task easy. The user interfaces shall be designed in close interaction with the users and shall be efficient, User-friendly, simple and easy to learn. The individual screens shall not be crowded. The screen designs shall be department/specialty specific. The menus, contents, list boxes, labels etc shall be based on the Specialty. As far as possible provide lists for the user to choose from. Some of the data items which can be provided as lists are given below. This is not exhaustive and given only as in indication only.  Patient signs, complaints and symptoms  observations, diagnosis with status  outcome of treatment  drugs, quantity and dosage  laboratory investigations  Radiological investigations The lists may be based on standards such as SNOWMED-CT, Drug Codes etc

HMS-GR.13 Audit Trail

The system shall keep a log of all transactions with User, Date and time. HMS-GR.14 Integration The system shall be capable of interfacing with digital medical with Medical equipments providing standard digital output. equipments: HMS-GR.15 Performance eHealth Application shall be able to evaluate and provide all Indicators: required Performance indicators pertaining to each Institution. The detailed list of Performance Indicators in different domains are given in this document.

1.6 Reception Counter Module Introduction: This module will handle the following functions: 1. OP Registration 2. Token issue 3. Issue of UHID Cards 4. Print outs of different documents required by the patients such as Reference Document 5. Enquiry 6. Online Registration 7. Report Generation The detailed requirements of the Reception Counter Module is as follows HMS-RC.1

OP Registration:

OP registration has the following tasks: 1. Identify and locate the patient from the eHealth Database. 2. If UHID is already allotted retrieve the UHID 3. Retrieve the Clinical Data (See Section 'General Requirements') 4. Generate UHID if no UHID is already generated 5. Register the Patient if not already registered in the database and allot a UHID 6. Allocate to the doctor based on specialty, patient preference or current work load 7. Print Token

HMS-RC.2

Identifying and Implementation of the eHealth Project begins with the creation locating the of a demographic database of citizens in the state. This Patient: database has nearly all important personally identifying data pertaining to all citizens who are normal residents of the state. This database has the Aadhar Number, ration Card number, Mobile phone number etc. This means that, when the system is implemented in a hospital there will be a full-fledged citizen database at the back end. It is very likely that the Patient reporting at the OP counter now is also in the database. So the first task is to locate this patient and get her credentials and Medical data from the data repository. Different scenarios are described below:

HMS-RC.3

Case 1: Aadhaar is the primary identity used by the system to identify a Aadhaar based person. So there are four options for a person with Aadhaar ID: Identification: 1. Produce the original Aadhaar card at the counter 2. Provide a photocopy of the Aadhaar card at the counter 3. Give the Aadhaar number in writing at the counter 4. Do a biometric authentication through eKYC facility of UIDAI if options 1,2 & 3 are not feasible. In case of options 2 & 3 also where the person do not produce the original Aadhaar card a biometric authentication may be necessary.

HMS.RC.4

Case 2: Ration card based Identification:

There are three options for a person who has a ration card 1. Produce the original Ration card at the counter 2. Provide a photocopy of the Ration card at the counter 3. Give the Ration card number in writing at the counter For option 1 &2, where the patient produces the original Ration card or the photocopy, the user at the counter scans the bar code on the ration card and retrieves the ration card data. For option 3 the user enters the number and retrieves the ration card data. Based on this data the patient can be identified.

HMS-RC.5

Case 3: Driving License, PAN, Voters ID, Mobile Number based Identification:

In the demographic survey there shall be provision to capture the Driving License, PAN, Voters ID and Mobile phone number. So there is a possibility that a person’s stored data can be retrieved based on any of these numbers. Then with proper validations her identity can be established

HMS-RC.6

HMS-RC.7

HMS-RC.8

HMS-RC.9

Case 4: Any of the above Identification numbers of a next of Kin residing in the same House: Case 4: Identification based on Local Body, Ward Number, House Name etc: Authenticating with Aadhaar:

Capturing Biometrics in the absence of Aadhaar: HMS-RC.10 Retrieving UHID:

The data pertaining to all the members in a house hold along with their relationship is captured in the demographic survey. Hence if the above unique id numbers of any of the next of kin can be given then the person can be located. Then with proper validations her identity can be established.

The User can use any parameter like Local Body Name, Ward Number, House Number, House Name etc to retrieve the details of the person from the database. In this case also there shall be proper validations before her identity can be established. In all cases where the identity retrieval was based on IDs other than Aadhaar ID then the system shall do a verification to retrieve the Aadhaar Number. If Aadhaar Number cannot be retrieved then the system shall capture the biometrics and store it so that next time the data can be retrieved with biometric scanning. Every citizen shall have a UHID. UHID is created first time when the citizen approaches a public healthcare institution for service. This is done at the time of the first OP registration of the person in eHealth. All the clinical data captured subsequently will be appended to the database against the UHID. This UHID is only for the sake of the system and the citizen need not be aware of this provided he/she has an Aadhaar Card. In the absence of Aadhaar, the UHID can be used till an Aadhaar number is granted to the citizen.

The system will do a database search to locate a citizen as described above when she approaches any of the public healthcare institutions for service and get her UHID. HMS-RC.11 Retrieve the The relevant Clinical Data of the Patient has to be extracted Clinical Data if from the Central server and cached in the local server for the the Patient has a doctor to view later in the OPD. different ‘Registered Hospital’: HMS-RC.12 Generate UHID The patient may be visiting the Public Healthcare institution if if the Patient for the first time after the eHealth is implemented. Her name is not in the may be in the demographic database but no UHID is generated Database: yet. Then the system shall generate a UHID now.

HMS-RC.13 Register the Patient if not already registered in the database and allot a UHID

If the patient is not registered in the eHealth database at all, then the earlier search will return a NULL. Then the system shall do the registration first and then create the UHID. This is a very delicate process and has to be handled with care. Case 1: A normal resident of Kerala: If the patient is a normal resident of Kerala then the requirement is that all data items required in the Family Health Register is to be captured. This is time consuming and cannot be done at the Reception when there are others waiting in the queue. So the following procedures are suggested: 1. Check if she has an Aadhaar. Do a Biometric verification. If Aadhaar is authenticated then use it to do the registration 2. If she does not have an Aadhaar and if she has any other identity such as Driving License, PAN, Voters ID, Mobile number etc use it for registration 3. If she has no identification proof then capture name, DoB/Age, Address with District and generate a temporary ID. In this case the District Official shall be given an SMS/System alert to locate this person later and add in the database. Non Resident Keralites can be registered provided they have a local address. Case 2: Citizens from other states who have migrated to Kerala: Citizens from other states who have migrated to Kerala shall also be registered as described above. However the system shall use a flag to distinguish them in order to help the Government plan welfare measures. If there is any registry for migrant workers, the eHealth system shall have linkage with that to exchange data as required. Case 3: Travelers and Tourists: System need not keep a trail of Medical Records of each tourist/traveler. The records can be stored with separate IDs and stored only in the Central Server. Any of the above mentioned numbers viz. Aadhaar, Mobile, Voters ID, License Number etc can be used for registration along with the name and address. In case of a Foreigner capture the name of Country and Passport Number and do the registration. There is a system of registration for every foreigner arriving in the country and staying in Hotels and Home stays. This is a computerized system and eHealth may have to have link with the system.

HMS-RC.14 Multiple In all cases the system shall carry out exhaustive validations to registrations to ensure that a person is not registered multiple times and given be avoided: more than one Health ID. However in the rare case of one person being registered multiple times inadvertently, the system shall ahve facility to link these records and create a single entity. HMS-RC.15 Native Hospital: Every citizen is conceptually linked to a PHC/CHC for statistical and Healthcare monitoring purpose. The database shall have facility to flag a hospital as a 'Native Hospital' for each citizen and generate statistical reports A Native Hospital is normally the PHC/CHC in the area where they reside HMS-RC.16 Photo The system may have a facility to capture the Photograph of those who do not have an Aadhaar Card. The OP counter may have a web cam with good resolution to capture the photo and add to the database. HMS-RC.17 Token Issue: The system shall display the OP wise list of doctors on duty on the day, extracted from the Duty scheduling module. There shall be facility for the Patient to choose a doctor if she desires so. If the policy of the Hospital does not allow this, then this option can be disabled in that hospital. The Medical Officer in charge of the Hospital shall have the privilege to disable this. The system shall print a Token with the following information.  Name of Patient  Gender  Age  Address  Name of the Native Hospital in case it is a different Hospital. (Not mandatory)  Name of the OP clinic the patient wants to visit  Name of Doctor (Not mandatory)  Bar code HMS-RC.18 Issue of Health Patients can be issued a Health card on request. The system Cards: shall keep a track of this and manage the issue of Health cards There may be two different types of Health cards. Health ID Cards: This may be free of cost for the first time and subsequent issues may be charged. The Health ID card may be standard Plastic cards and need contain only basic information such as Name, Date of Birth/Age at the time of issue, Aadhaar Number / UHID Number, Photograph etc. Bar code with required basic data for identifying the patient shall also be printed on the Health ID Card.

HMS-RC.19 Print outs of different documents:

HMS-RC.20 Enquiry:

HMS-RC.21 Online Registration:

HMS-RC.22 Report Generation:

Health Smart cards: This can be issued to patients with chronic illness, Pregnant women who need special attention etc. The clinical data can be updated in the card at the end of each encounter. Reception counters shall b e equipped with smart card readers to update this data. There are only few centers where print out are given to patients. At OP clinics no print out is given to them. Hence the required prints are to be issued from reception. Some of the print outs are listed below:  Prescription for Drugs if patient wants to buy from other Drug stores  Prescription for tests if patient wants to do it outside  Reference Document This module shall be capable of providing various general information to the Patients. Some are listed below:  Availability and Duty time schedules of doctors  Timings of various services  Information on all services available in the Hospital  Important telephone numbers  Information on all services available in the higher level referral Hospitals nearby  Status of Pay ward Bookings There shall be facility to do online registration for OP consultation. The Medical Officer in charge of the Hospital shall have the privilege to determine the number of days allowed for advance booking and the percentage allowed for advance booking. There shall be facility for patients registration for online services. Patients can log in view the doctors on duty and register online for consultation. The system will allot a token number based on a logic to sandwich the online and walk-in patients based on the percentage allotted for online booking. The system shall send SMS and email confirmations of the token number with necessary disclaimers. This module need to generate several reports. An indicative list is given below. These reports will have to be generated daily or for a specified period.  OP Register  Review OP Register  Foreigners OP Register  Accident Register  Department/Unit wise OP Statistics  Income wise OP Statistics  District region wise OP Statistics  Incident Register

1.7 OP Clinical Module This module will handle the following functions: 1. Queue Management 2. Intermediary Nursing station 3. Past Clinical History 4. Symptom Capturing 5. Diagnosis Capturing 6. Protocols and Guidelines 7. Prescription of Drugs 8. Prescription of Tests 9. Prescription of Clinical Procedure 10. Admission to IP 11. Coding of Diseases: 12. Issue of Medical Certificates: HMS-OPD.1

Queue Management:

HMS-OPD.2

Past Clinical History:

HMS-OPD.3

Capturing additional History

HMS-OPD.4

Symptom Capturing:

Patients will report at the OP clinic after registration at the OP counter. They will have tokens issued to them from the OP registration counter. The tokens are issued Specialty / Unit / Doctor-wise. Each Doctor shall get the list of patients waiting to see her. Patients who have not indicated any preference for any doctor shall be included in the list of all doctors on OP duty in the Specialty. The topmost token shall be highlighted and the Doctor shall have the option to move the highlight to any token in the queue. The system shall push the highlighted token number to the token display. In case the patient with the displayed token number is not available at the moment for consultation the token may be pushed a few steps down the list so that it will reappear at top after a few turns. Also there may be facility to remove the token from the list if required. The system shall display the past clinical history of the selected patient in a standard format as available in the system. This may begin with the most recent history with facility to drill down and view all the past history. This interface shall display all the clinically relevant information such as allergy to drugs etc. The doctor shall have an interface to capture the history and additional information if necessary. The interface shall be User friendly, interactive, menu driven, ICD 10/SNOMEDCT based and designed specifically for each specialty to avoid keyboard entry to the extent possible. The system shall have interface to capture the symptoms as the patient narrates them. Here the emphasize is to make the screen as user friendly as possible minimizing key board entry and designed to suit each specialty. The system shall use standard coding system for recording the symptoms.

HMS-OPD.5

HMS-OPD.6

HMS-OPD.7

HMS-OPD.8

Vitals: Physical examination and Findings

a. The system shall have interface to capture the Physical examination Findings. The UI shall provide user friendly screens to enter all the parameters related to physical examination. There shall be validation and alerts for unusual entries. b. The system shall provide facility for an intermediary nursing station where the vitals of the patient are captured by a Nurse and entered. However in smaller hospitals where such a facility is not available this will be done by the doctor. The system shall have flexibility to configure an intermediary nursing station Diagnosis The system shall capture provisional & final Diagnosis. The Capturing: interface shall be User friendly, interactive, menu driven, ICD 10 based and designed specifically for each specialty to avoid keyboard entry to the extent possible. Protocols and The system need to have embedded Protocols and Guidelines Guidelines: to assist the Physician to carry out the clinical activities as per the accepted norms and best practices. Protocols, Norms, Best Practices and Guidelines as used in the clinical practice in the state shall be incorporated in the system. In the absence of documentation of such standard practices in the state the solution provider shall suggest guidelines based on National or International practices based on their previous experience in the field. This will be reviewed by an expert panel. The approved Protocols, Norms, Best Practices and Guidelines shall be incorporated in the system. Advise: The system shall have facility to for the Doctor to record the advice. Some of the advice will comprise of the following, though this is not an exhaustive list. 1. Investigations orders: Some of the typical orders are a) Lab Test b) X Ray c) ECG d) EEG e) TMT f) Scan There shall be user friendly menu driven screens for Doctors to prescribe Tests. All the standards Tests shall be available as drop down lists for the Doctor to choose from. National and International coding systems such as LOINC shall be used for tests and clinical procedures. All the Tests prescriptions shall be queued at the Laboratory. The Clinical Procedures shall be queued at Nursing Stations or mini Operation Theatre or other

locations depending on the nature of the procedure. The services shall be delivered as per the queue. 2. Prescription of drugs. There shall be user friendly menu driven screens for Doctors to prescribe Drugs, Tests and Clinical Procedures. All the standards Drugs, Tests and Clinical Procedures shall be available as drop down lists for the Doctor to choose from. There shall also be facility to enter the names of Drugs, Tests and Clinical Procedures with auto-complete facility. The Doctors web page shall display the drugs available in the Hospital Pharmacy. It shall also have an exhaustive list of drugs which can be prescribed and purchased from outside also. For this the system may be linked to any standard drug specification publications such as WHO Drug Dictionary ATC – anatomic therapeutic classification, CIMS, MIMS etc. with regular updating arrangement. The cost for such subscription shall be borne by the Solution Provider throughout the contract period. All the drug prescriptions shall be queued at the pharmacy. The pharmacist will deliver drugs to each patient based on this queue. KMSCL has evolved a drug code for its use. The solution provider is free to use this or another standard drug code if it suits the eHealth Application. If a drug code different from that of KMSCL is chosen then the chosen drug code shall be mapped with that of KMSCL so that both systems interact seamlessly. 3. Clinical Procedures , Injection, Dressing wounds (Cleaning &Dressing, Incision & Dressing), Administering Intravenous Fluid: There shall be user friendly menu driven screens for Doctors to prescribe Clinical Procedures. All the standard Clinical Procedures shall be available as drop down lists for the Doctor to choose from. National and International coding systems such as WHO – PCS , SNOMED-CT, CCI etc shall be used for clinical procedures. All the Clinical Procedures prescribed shall be queued at

Nursing Stations or mini Operation Theatre or other locations depending on the nature of the procedure. The services shall be delivered as per the queue.

HMS-OPD.9

Observation Ward:

HMS-OPD.10

References within same Hospital:

HMS-OPD.11

Reference to other Hospital

There may be an observation room attached to Casualty and other OPs. Nurses at these wards shall have facility to record the all the incidents happening at these wards similar to the other in-patient wards. The system shall have facility to refer patients to other OPs or Other Doctors within the same Hospital. This will require a reasonable logic to be evolved for managing the queue without hassles. A patient may be referred to one or multiple Doctors for consultation from the OP where she reported. This could be either because she reported at the wrong OP or because she needs further consultations. The patient already has a token number. How this token is to be queued at the subsequent OPs where the patient is redirected is to be decided and the system developed accordingly. These are cases when the patient is referred to another hospital for treatment. This process shall mark the patient as a referred patient in the database in the Central Server. The system will have facility to create and transmit the relevant clinical data in a standard format to the other hospital where the patient is referred so that when the patient visits the referred hospital within a specified period, the clinical data can be easily retrieved in the hospital. In case the system fails to retrieve the relevant clinical data of the referred patient to the referred hospital due to connectivity failure, then a reference document shall be generated at the referring Hospital by the Doctor who is referring the patient. This document will have necessary clinical data in a standard format. This is printed and handed over to the patient with necessary directions. This printed reference document will also have a bar code. A printed reference document may also be required in the following occasions as well. 1. When the patient is not referred to any specific hospital (Eg: Consult a Cardiologist of your

Choice) 2. Patient wants to consult somebody in the private sector. At the OP ticket counter of the referred hospital the system will recognize the patient as a referred patient and a token printed with information such as the name of the Referring Hospital and reference status. The Doctor at the OP will have necessary clinical data at his terminal when the Patient walks in for consultation in his cabin. If necessary the Doctor can also access the central server and get additional information directly. If there is no connectivity then the OP module will not be able to get the digital data and the doctor will have to go by data in the printed reference document. The data input by the referred hospital will be cached in the local server initially and later the Central Server database will get updated by this data.

HMS-OPD. 12

Tentative Appointment

HMS-OPD. 13 Admission to IP

HMS-OPD. 14

Casualty:

If the patient has a Smart Health Card then the card will be updated at referring hospital and the referred Hospital can use the data in the Smart card if connectivity is not available. The system shall provide the referring Doctor facility to view the availability of the Doctor to whom he is referring the patient and if necessary take a tentative appointment. The referred Doctor will then get the details of the patients in advance. The system shall have a messaging system so that doctors and paramedical staff can communicate with each other on clinical matters online and take decisions.. The system shall have facility for the Doctor to order Admission. Doctor’s direction will contain Ward Number, Unit and other orders. These details shall be queued at the IP registration counter (Admission Counter). Processes in Casualty are similar to that of other OPs except that they have to deal with Medico Legal Cases. The system shall have facility to for the following:  Generate Police intimation form.  Generate Accident Register cum wound Certificate.  Certificate of Examination of a person under police or judicial custody  Drunkenness certificate Register  Examination of potency  Scheme of examination of rape  Update Death Register

HMS-OPD.15

Key Board entry with auto completion

HMS-OPD.16

Coding of Diseases:

HMS-OPD.17

Issue of Medical Certificates:

HMS-OPD.18

Reports:

 Update Brought Dead Register In all cases described above where standard menu driven interfaces are provided there shall be an alternative facility to enter data through key board, in case the doctor is more comfortable in using key boards. This facility shall be augmented with auto completion facility. In all cases there shall be a list of favorites for each doctor so that the selection becomes easier. The Government of Kerala has adopted ICD 10 for Coding of Diseases. The system shall suggest codes based on the diagnosis. There shall be an interface for the Medical Record Librarian to verify the Code and confirm it or enter a new code. Doctors may be required to issue various certificates to patients. A list of Certificates to be issued by Doctors is given in Annexure: ……. The system shall have interface to issue all such certificates which can be issued from the OP Clinic. These certificates will be digitally generated by the Doctor and printed at the OP Nursing Station. The printed certificates are then signed by the Doctor. Some Certificates are free and some are paid. The system admin shall have facility to mark certificates as free or paid and update the fee to be paid for each type of certificate. For paid certificates the system shall capture details such as amount to be paid to the hospital and that to be paid to the doctor. The certificate may only be generated after the requisite fee has been paid. The amount collected on behalf of the Doctor is to be credited to the account of the Doctor directly. The system shall have facility to generate all statistical Reports and MIS reports.

1.8 In-Patient Management This module has the following requirements: HMS-IPD.1

Admission

HMS-IPD.2

IP registration The patient is then queued at the IP registration counter Counter (Admission Counter). The Nursing Assistant at the Admission will verify the data, confirm the identity of the patient and complete the process by making necessary entries in the system. These details entered shall be stored as the Main IP Register. Only the admission part is entered by the Nursing Assistant. No clinical data is filled up by the Nursing Assistant. Rest of the data are entered subsequently at the ward and then later completed by the Medical Records Department. A new IP Record is generated and a unique IP number is allotted to the Patient. The Patient is flagged as an In-Patient. The IP record shall be linked to the demographic data of the Patient. Sociological Essential sociological data of an identifying nature is a Data required in the Case record. Incase this is not available in the database at the time of admission of the patient then this data is to be gathered either from the patient or from the nearest relative present at the time of admission and then entered in the Main I.P Register and in the Case Record. Ward Then the patient is directed to the Ward. The IP record now created shall be available at Nursing Station attached to the Ward where the Patient is admitted. The Duty Nurse shall have facility to enter any hand written directions by the Doctor. The previous case records of the same patient shall be automatically retrieved by the system and made available to view. The viewing privileges shall be decided at the time design and implemented Allotment of The system shall have facility for allotment of Bed and Bed and allotment of Linen. There shall be interfaces for recording all allotment of the Nurses activities. Linen Clinical data Duty MO/MO in charge of the Ward shall have privilege and

HMS-IPD.3

HMS-IPD.4

HMS-IPD.5

HMS-IPD.6

The Doctors at OP Clinics may order a patient for admission to a specific ward under his department. The doctor's directions are expected to contain the following mandatory items: Name of Doctor,  Provisional Diagnosis,  Ward Number and Unit Number ( Normally there is a linkage for Ward/Bed to Unit.)

entry by Doctors

HMS-IPD.7 HMS-IPD.8

HMS-IPD.9

HMS-IPD.10

HMS-IPD.11

HMS-IPD.12

Accident cases User Interfaces for the Nurses

User Interfaces to record references Temporarily shifting for tests etc Registers

Ambulance Service Requests:

UI to view all new admissions daily and give further clinical directions from anywhere in the Hospital. Duty MO may order further investigations, medications and other directions. User friendly Interface shall be made available to record subsequent directions by the concerned MOs during routine rounds. The Medical Officer attending the case shall have facility to record all details the patients regarding the onset and cause of the present illness, personal and family history and also that of physical examination conducted. All investigation reports concerning Laboratory, X-ray, E.C.G. etc are to be captured. It shall also be possible for the Medical Officer to record daily the progress of the patient along with his directions regarding the treatment to be carried out until the discharge of the case. In accident cases there shall be facility to record external cause of the accident and the nature of injury. There shall be User Interfaces for the Nurses to record the observations of the Nurses and also details of treatment and services rendered by them to the patient. The system shall have facility for the preparation of Graphic Chart and Nurses records. There shall be User Interfaces to record references to other Hospitals or to other Specialties within the same Hospital.

Patients may have to be shifted out temporarily for tests and other procedures that may not be available in the hospital. There shall be User Interfaces to record this. The system shall have facility to generate the following Registers:  Report book  Costly Medicine Book:  Diet Register  Complaint Book (Office Information Book):  RMO Stock Register:  Referral Book:  Daily Discharge register:  Discharge Card to be issued to the Patient  Daily Admission / Discharge / Census Report The system shall have facility to request for Ambulance services by Duty MO. This interface shall have a link to the 108 Services so that a request is generated automatically. The system shall have linkages with other Ambulance services as well. It should be possible for requesting Ambulance from other sections such as OP etc.

HMS-IPD.13

Delivery

HMS-IPD.14

Operation Theatre:

The system shall have facility to record the following:  To record shifting of Patient to the Labour Room  To record Delivery and update the Birth Register.  To report the Birth to Local Body through Medical Record Department.  To update the Report Book in Labour room  To update the Case Record Book with the type of labour and the details of the new born baby by the attending Medical Officer.  To update the following registers  MTP Register  Sterilization registers  Abortion Register  Laparoscopic Sterilization Register The system shall have facility to record the following:  Pre - operative diagnosis before the operation is performed  Pre-anesthesia check up details  Anesthesia procedure  The Surgery procedure and findings immediately after the operation  Findings in the Surgery and post-operative diagnosis.  Anesthesia recovery details  Provisional/Final diagnosis The system should update the following registers:  Minor surgery register  Major surgery register  Anesthesia register

HMS-IPD.15

Discharge:

The system shall have the following facilities:  Manage Operation Theatre consumables  Operation Theatre scheduling  Pre- Operation Theatre Checklist  Surgeons Notes  Keep track of Operation Theatre Equipment Usage  Generate Operation theatre reports  Generate Operation Theatre & Operation Resources Usage Report The system shall have facility to record the following:  The final diagnosis  The date and time of discharge from the hospital  The condition of the patient at the time of discharge  Cause of death in cases of Death  Other Discharge Data etc

HMS-IPD.16 HMS-IPD.17

Discharge Register Final diagnosis

HMS-IPD.18

Discharge summary

HMS-IPD.19

HMS-IPD.20

Discharge process in emergency situation Reports

HMS-IPD.21

Death:

The system should update the Discharge Register. The final diagnosis recorded should be complete in all respects and should be accurate and in conformity with the accepted terminology of the standard nomenclature of diseases and operations. The Discharge condition may have the following options: a. Cured b. Relieved (Condition Improved) c. Referred d. Death e. Left Against Medical Advice (LAMA) f. Discharged Against Medical Advice(DAMA) g. Absconding The system shall have facility to give the Discharge summary to the patient as a Discharge Card and a Reference Card to the referred patients in a standard format. The reference may be of two types: i. To a higher Level Hospital for further investigation and treatment ii. To a lower level Hospital for continuance of care The system should have facility to allow the Duty MO to initiate discharge process in emergency situation if necessary.

The system shall generate necessary reports for the privileged users. The report shall contain the following data:  the ward and the date to which it relates  I.P.No. Name, age, unit, diagnosis and date of admission of the cases discharged from the hospital for that particular day.  Details of outstanding cases, admissions, transfer in discharges, deaths, transfer out, balance remaining, (classified into male, female and children). The system shall have facility to update all the related registers and forms such as:  Death Register  Death Report (Form No 2)  Medical Certificate of Cause of Death (MCCD Form No.4). Part 1 of Death Report and MCCD is sent to the Local Body (LSG) for registration of death. When body is handed over the duty nurse shall get acknowledgement of the relation who is taking over the body in a printed form (Death register)

The system shall have facility for the following  To authorize autopsy if required.  To record that the body is ‘Transferred to Mortuary' in the death register.  To generate and Print the Police intimation form  To update the Mortuary Register by the Nursing Assistant. The system shall have a UI to enter autospy report by the authorized Doctor. It shall be feasible to send information to the Police Computer system through web service at a later stage.

HMS-IPD.22

Patients Search & Select

The system shall have facility for giving permission to store the body in the mortuary if necessary for prolonged periods. The module shall have facility to search patients based on various search criteria and display details based on the access rights.

1.9 Store and Pharmacy Module The Pharmacy Module shall carry out the following functions: 1. Stock Updating 2. Issue of Drugs to Patients 3. Billing 4. Drug Requisitioning HMS-PM.1 Stock Updating:

Pharmacy gets the stock of drugs from the Hospital Store. The store is part of the KMSCL network. Hence the eHealth system should be linked to the KMSCL system to get stock data realtime. The Pharmacy module shall have interface to receive the stock issued from the store to the Pharmacy and also to return stock when necessary. The system shall up date stock position to the central server at a given interval. HMS-PM.1 Issue of Drugs The Drugs prescribed by the Doctors are queued at the Pharmacy. to Patients: Pharmacists issue drugs to patients based on this list. The system shall print out the details including dosage. The system may also need to print out the list of drugs which are not available at the pharmacy for allowing the patient to buy it from outside. HMS-PM.2 Billing: Normally the supply of drugs to patients is free of cost. However the system shall have facility to calculate the cost of Drugs and also to print them on the document handed over to the patient. The cost of the drug may be shown and the entire amount deducted as subsidy so that the patient need not pay anything.

HMS-PM.4 Requisitioning of Drugs and other Store items:

Pharmacy module shall have interface to do the requisitioning of drugs and other items from store regularly. Such requisitions can come from Pharmacy, IP wards, Doctors who want a specific drug or item and even other employees. This data shall be compiled for the Hospital and transmitted to KMSCL regularly. Head of the Institution shall have a privilege to overrule the periodicity of the central server updating and update data instantaneously in case of urgency requirements. HMS-PM.5 Drug The system shall have facility to intend drugs online. Every such Requisitioning request originated in an Hospital shall be compiled by the system and transmitted to KMSCL for arranging purchase. The Head of Institution may also arrange to purchase some drugs locally using the HMC fund or Government fund. The system shall be able to arrange the procurement through the ‘eQuotation’ described in this document HMS-PM.6 Reports The system shall generate various reports. Few examples are given below:  Drugs Available  Drugs Details Listing  Drug Sales Daily  Drug Sale Patient Wise  Drug Stock  Indents and Issues to Other Depts. / General Store / SubStores  Batch details of drugs  Sale Report  Store-wise medical consumable stock  Prescriptions versus Issues / Sale  Pending Prescriptions (IP/OP)

1.10 Blood Bank Most of the Large Hospitals have Blood banks where as some of the smaller hospitals have Blood Storage facility. eHealth system shall have module to manage the Blood bank functionalities. HMS-BB.1

Donors Database

The system shall have an interface for Donor registration and shall maintain a database of Donors. There shall be linkage to the web portal so that Donors can register online through eHealth portal

HMS-BB.2

HMS-BB.3

Results of each tests and quality of blood collected Blood Inventory Management

HMS-BB.4

Online requests

HMS-BB.5

Blood Bank registers

There shall be facility for Donor search The system shall capture and store the results of each tests and quality of blood collected The system shall have facility for Blood Inventory Management including stock register and issue register Doctors shall be able to register their requests for Blood online. The Blood bank managers shall be able to view the requests and respond. The system shall have facility to update all Registers maintained in the Blood Bank

1.11 Laboratories Public Health Laboratories There are six Public Health Laboratories in the State. 1. State Public Health Laboratory Trivandrum 2. Regional Public Health Laboratory Ernakulam 3. District Public Health Laboratory Kollam 4. District Public Health Laboratory Alleppey 5. Regional Public Health Laboratory Kannur 6. Regional Public Health Laboratory Kozhikode Patients can walk in to any of these PH Laboratories for clinical tests. Patients may carry prescriptions for tests from Govt. hospitals, Private hospitals or even Private doctor referrals. There can also be direct request from Patients for normal routine clinical tests such as Blood Sugar, Lipid profile etc without a formal prescription from a Doctor.

Out of the six Public Health Laboratories in the State only the State Public Health Laboratory in Trivandrum has a computerised system. This is an archaic system and will be replaced by the proposed PH Lab Module in the eHealth. The system shall have the following facilities: HMS-LM.1 Reception: 1. Provide Token numbers for Queue management 2. Capture the id of the patient from the citizen database available in eHealth 3. Retrieve the prescriptions from Government Hospitals generated through eHealth and available in the eHealth database 4. Enter test prescriptions from the following sources: a. Govt. hospitals not yet covered under eHealth b. Private hospitals c. Private doctor referrals d. Direct request from Patients for routine clinical tests without a formal prescription from a Doctor. 5. Store rates of different tests 6. Generate bills for the three categories viz. a) Free category b) Concessional Rate c) Full payment category. 7. Receive payments and issue standard Treasury receipt viz. TR5. 8. Account the collected money HMS-LM.2 Sample 1. Queue management at Sample collection counters collection 2. Flag the two categories sample collection viz. a. sample collected and brought from outside b. patient coming for sample collection 3. Master table for different sample types – Blood, Urine, Sputum, Pus, needle aspirates etc. 4. Uniquely identify the multiple samples for a each patient and multiple tests for each sample. 5. Print labels for each sample 6. Generate separate requests for separate sections. HMS-LM.3 Sections: 1. The data from Reception and Sample collection counters shall be available at the sections. 2. Standardised UIs to enter Test results 3. Alerts for abnormal values 4. Facility to verify and approve by superiors 5. All results once approved will not be editable by the staff. 6. Editing privilege is only to section head. HMS-LM.4 Result issuing 1. Queue management at Result issuing counters 2. Alerts when the results of a patient are available 3. Print the results 4. Print the names/designation of concerned authorities in the

HMS-LM.5 Supporting sections

print out. 5. SMS and email alerts to the patients when result is ready. 6. Web portal shall have facility for the registered Users to download their test results. 7. Facility for the Doctors at Hospitals covered under eHealth to view the result. Reagents are prepared in these sections for supply to outside institutions like CHCs and Hospitals. There shall be facility for accounting stock (manufacture and issue) of reagents prepared in the sections.

1.12 Clinical Laboratories in Hospitals: There are clinical laboratories in all major Hospitals. Medical College Hospitals have specialized Laboratories such as Pathology, Bio-Chemistry and Micro-biology labs. The requirement in these laboratories are as follows. HMS-LM.6 Clinical Clinical Laboratories in Hospitals have similar requirements Laboratories except that patients approaching them for service are those from in Hospitals: the OP or IP of the same hospitals. So the queue management system need to consider only such cases. The tests are prescribed by the doctors and hence the data entry by staff at laboratories is practically limited to result entry.

1.13 Picture Archiving and Communication System Major Hospitals shall have a Picture Archiving and Communication System (PACS) which provides economical storage of, and convenient access to, images from multiple modalities (source machine types). User Licenses shall be unlimited HMS -PACS.1

The Architecture should be centralised one in which the long term storage is done centrally for all hospitals. Images pertaining to the current episode / encounter alone are proposed to be stored in the local server. Medical Images which have clinical or academic importance are proposed to be uploaded to the Central server for the time being. The enterprise work list for every Radiologist may be driven from the central server.

HMS -PACS.2

The Local PACS at the hospitals System should be able to connect to any DICOM 3.0 modality including the various modalities in the radiology/cardiology department.

HMS -PACS.3

For future connectivity with any modality, no additional license shall be required. Vendor shall provide the required support during the entire period of Contract.

HMS -PACS.4

HMS -PACS.5

The system shall have two components 1. VNA (Vendor Neutral Archive) 2. RIS-PACS. The storage shall be managed by VNA independently of RIS-PACS. Vendor needs to ensure that no data migration is required if department decides to replace the RIS-PACS to some other system in the future.

HMS -PACS.6

All the modalities shall transfer data images to the PACS application server. Diagnostic workstations shall be connected to PACS for reporting

HMS -PACS.7

All digital imaging modalities listed below will be interfaced with PACS  MRI  PET-CT  CT  Mammography  Ultrasound & Doppler  Digital X ray 

Nuclear medicine

  

Single-photon emission computed tomography (SPECT) Endoscopy Slide Microscopy

  

HMS -PACS.8

HMS -PACS.9

Radio Therapy Image, Segmentation External Camera Photography DSA Images (Cardiology, Neurology, Radiology etc)

The system shall support unlimited DICOM modality connectivity. No additional license shall be required from vendor to connect the supported DICOM modalities to PACS. The system interface shall be browser based and users (esp. Physicians) should be able to access the images without requiring any application installation at the viewing PC. The user interface shall be very intuitive and easy to use

HMS -PACS.10

Application should conform to the standards DICOM/HL7. DICOM Conformance and HL7 Protocol guide needs to be shared

HMS -PACS.11

Application should follow the guidelines for data security and confidentiality reasons

HMS -PACS.12

The system shall support unlimited examinations/studies. There should not be any license dependency to store high number of records.

HMS -PACS.13

The proposed system architecture shall be scalable. It should not only meet the current load requirements (in terms of incoming scans and users), but shall also meet the future requirements (assuming increase of 10% load year on year).

HMS -PACS.14

The system should be Web based and allow access of images in any PC.

HMS -PACS.15

The application shall work on multiple operating system environments. Users shall be able to connect from any operating system and view images (ex. Windows, MAC, Linux etc.)

HMS -PACS.16

The system shall be designed and appropriate hardware needs to be proposed to handle nearly 1500 users concurrent load.

HMS -PACS.17

The system shall support TeleRadiology and doctors shall be able to view images and report cases from anywhere.

HMS -PACS.18

The system shall allow to define the purge rules for slices

HMS -PACS.19

Proposed system should be hardware agnostic and should be able to run on any standards hardware etc. The storage architecture should be VNA (Vendor Neutral Archive) based. All the image shall be independently managed by the VNA server and PACS should keep only short term data. The architecture shall ensure that there should not be any data migration, if hospital decides to change the PACS system. The new PACS system shall be able to work seamlessly with VNA.

HMS -PACS.20

Performance HMS -PACS.21

HMS -PACS.22 HMS -PACS.23 HMS -PACS.24 HMS -PACS.25 Security HMS -PACS.26 HMS -PACS.27

HMS -PACS.28

System should have been tested for performance with 1Million scan studies in the database. Documentary evidence should be produced at the time of Technical Evaluation. The study list page and any query on that should display results in less than 2 secs X-ray image should be loaded in less than 2 seconds Loading CT scan with 2500 images should not take more than 2 mins from server There should not be any limit of loading high image volume scans on 32 bit machines. Normal desktops shall be able to open big CT studies All access should be encrypted and system should support SSL All user access (ex. login, study access, report access) should be saved into database as AUDIT TRAIL and this should be accessible/searchable by Administrator Integration with Identity and Access Management

Radiologist Worklist HMS -PACS.29 Browser based worklist HMS -PACS.30 User should be able to search and filter the records. Search should be supported on various parameters ex. Patient Name, Patient ID, Accession No, Modality, Scan Date/Time, IP No HMS -PACS.31 Study List should display the reporting status (DRAFT/Reviewed/Sign-Off) for the scan HMS -PACS.32 User should be able to see the series breakup for the scan and has the option to load limited/all series in the viewer HMS -PACS.33 User should be able to add interesting cases to Academic folders HMS -PACS.34 The shortcuts should be displayed as links HMS -PACS.35 If exam has prior studies, it should be displayed on the study list page with some link HMS -PACS.36 User should be able to view the complete Patient History without separate logging into any other Module. It should be one-click access HMS -PACS.37 If study is currently being accessed by other radiologists, it should be displayed on study-list with the name of doctor who is currently accessing it Image DICOM Viewer Features HMS -PACS.38 Ability to load and display various types of Images ex. CT, MRI, X-Ray, US, Cath-Lab, 2D Echo etc. HMS -PACS.39 Series Thumbnail panel and one click option to load series on viewing area HMS -PACS.40 Ability to display multiple series at same time HMS -PACS.41 Series Synchronization : Auto and Manual HMS -PACS.42 Scout/Reference line display HMS -PACS.43 Ability to load priors and view both current and old study at the same time HMS -PACS.44 Series Synchronization between current and old scan HMS -PACS.45 CT Window level presets. Ability to define new presets HMS -PACS.46 Image Filter support HMS -PACS.47 Zoom-in and Zoom-out support HMS -PACS.48 Image rotate and flip support HMS -PACS.49 Image colour invert support HMS -PACS.50 Measurements support : Pixel(Hounsfield), Linear, Area, Angular HMS -PACS.51 Ability to retain the study layout while interchanging between studies. HMS -PACS.52 Ability to pop-up a series in a small window and scroll it without disturbing the existing view layout HMS -PACS.53 Hanging Protocol support HMS -PACS.54 Ability to save hanging protocols on the server HMS -PACS.55 MRI Spine Labelling Support

HMS -PACS.56 HMS -PACS.57

Magnifinder support Inbuilt PACS viewer should support MPR & MIP for CT and MR images. Hospital need to procure addtiional workstation softwares to achieve this HMS -PACS.58 Ability to view images on Mobile devices (ex. iPhone, iPAD, Android) as DICOM images. User should be able to do require image manipulations and measurements on these devices as well HMS -PACS.59 User shall be able to do post processing (ie. MPR & Volume Rendering) on these devices. The standard orthogonal MPR shall be supported. User shall be able to perform measurements, adjust brightness/contrast on these post processed images. For VR, the color presets shall be supported. HMS -PACS.60 Direct export of images to Microsoft Power Point for presentation HMS -PACS.61 The PACS inbuilt viewer should work on both windows and MAC platform HMS -PACS.62 Ability to identify Key Images and save them as a new series HMS -PACS.63 Ability to export single image/series/study as standard image format ex. JPEG/GIF/PNG etc HMS -PACS.64 Ability to export the moving images (ex. Cath-Lab, Ultrasound) as AVI file HMS -PACS.65 Ability to burn images into a CD HMS -PACS.66 Ability to do Film Printing from the viewer. Viewer should support configurable print layouts Reporting module Features: HMS -PACS.67 Report Template Support HMS -PACS.68 MACROs support HMS -PACS.69 Various image format support (ex. TXT, HTML, RTF etc) HMS -PACS.70 Integration with MS-WORD to use microsoft word as reporting editor HMS -PACS.71 Digital Signature Support HMS -PACS.72 Ability to paste images in the reports HMS -PACS.73 Reports should be saved as PDF HMS -PACS.74 The Patient demographics should appear in all pages of the reports HMS -PACS.75 Reports should display the page numbers HMS -PACS.76 Ability to save reports as DICOM Images and it should be attached with the scan HMS -PACS.77 Ability to assign reporting privileges to Radiologists HMS -PACS.78 Typist workflow support HMS -PACS.79 Voice Recognition Support HMS -PACS.80 Ability to email Reports to Physicians or Patients HMS -PACS.81 Report Search Engine : Ability to search the reports on Keywords. The search should not take more than 5 secs on 1M studies

Radiology Information System(RIS) Features General Requirements HMS -PACS.82 RIS shall support all the standard Modules ie. Patient Registration, Appointment/Scheduling, Modality Worklist, Radiologist Worklist and Reporting

HMS -PACS.83

The system shall support scanning of hardcopy request forms and other documents and attach with a patient

HMS -PACS.84

The system shall be integrated with HMS. It shall be bi-directional integration.

HMS -PACS.85

System shall support workflow for radiology orders which do not require scheduling (ex. X-Rays)

HMS -PACS.86

The patient consent forms should be able to be scanned and attached into the system

HMS -PACS.87

The system shall have an ability to insert a flag for attention for an examination. The flag shall be visible in all various worklists. The user typed comments shall also be visible

HMS -PACS.88

The system shall support sticky notes function. The sticky notes shall open as popup when a scan is opened.

HMS -PACS.89

The system shall provide instant messaging functionality for users to communicate via system.

HMS -PACS.90

It should be possible to view the details of personnel involved with the Order ie. who created the order, who scheduled/rescheduled it, scanning technician, draft radiologists and final report signoff radiologist

HMS -PACS.91

RIS shall be integrated with EMR so that with a click radiologists can see other details of the patient

HMS -PACS.92

System shall support the check for duplicate order and patient IDs

HMS -PACS.93

The system shall provide the section where all standard documents related to operations, policies, standard forms can be uploaded and kept for users to access it

HMS -PACS.94

System shall support multiple department workflow where multiple department users can work without being able to access other department data. For ex. Front Office of one department shall not be able to schedule cases of other departments. Cross department access shall be limited and shall be available only to limited users

HMS -PACS.95

System shall support setting up Master data from the Admin interface ex. Procedures List, Reporting Templates

HMS -PACS.96

System shall support transfer of orders from one department to another

HMS -PACS.97

System shall support multiple user profiles which includes the following but not limited to o Junior Resident o Senior Resident o Radiologist o Transcriptionist o Radiographer o Patient Service clerk & supervisor o Radiology Nurse o Administrator The system shall allow to create user groups and assign users to groups. It should allow to manage access rights both at group and individual user level.

HMS -PACS.98 HMS -PACS.99

The system shall allow to provision and manage Radiology Roster. The HOD/Authorize User, should be able to define the roster and automatic case assignment rules.

HMS -PACS.100 The system shall support Rostering for other users as well ie. Radiographers, Transcriptionist etc.

HMS -PACS.101 Patient Registration HMS -PACS.102 System shall be able to use the Hospital generated Registration Number (OP/IP) HMS -PACS.103 System shall allow to mark Patient Arrival status in RIS HMS -PACS.104 The system shall support Patient Merge workflow HMS -PACS.105 System shall capture and display health alerts HMS -PACS.106 Able to scan various consent forms ex. Request Form, Consent Forms, Pregnancy Declaration forms etc

HMS -PACS.107 The document scanner shall be integrated with RIS Handling of Imaging Service Requests (ISR) HMS -PACS.108 Protocolling module: Allow the creation of a protocolling worklist for radiographers or radiologists with options to select standard performing protocols and free text field to document additional performing instructions to radiographers or communications with clinicians that will be visible to the radiographer when performing the study.

HMS -PACS.109 System should be able to audit and track protocolling workload per user.

HMS -PACS.110 Able to distribute tasklist to radiologist for vetting protocol and be able to update as a completed status.

HMS -PACS.111 Support more than 1 level of vetting e.g. Radiographer or trainee performs vetting and with option to send to Radiologist to verify.

HMS -PACS.112 Support more than 1 level of vetting e.g. Radiographer or trainee performs vetting and with option to send to Radiologist to verify.

HMS -PACS.113 Support seamless paperless communication between clerk, radiologist and radiographer during the vetting process.

HMS -PACS.114 Have a means to support rejection of requests sent for vetting. HMS -PACS.115 Requested procedures or Imaging Requests that need clarification can be flagged for follow-up from Request creation.

HMS -PACS.116 Urgent ISRs to trigger notifications eg SMS to appropriate personel as defined by users.

HMS -PACS.117 List of Requested Procedures or ISRs o

HMS -PACS.118

HMS -PACS.119

Able to filter by Date/Time, Modality, Priority, Patient Type, Medical Service, Referal Location, Patient Class o Option to search for list of Requested Procedures or ISRs by Patient ID, Patient Name, exam order ID o Print out Porter Slip with information like Patient ID, Patient Location o Ability to sort list by different fields and select specific fields for display o Able to import and retain performing or reporting priority fields from CPOE and recognise them as separate fields o Able to print by location/time o Able Export list. Choice of giving an appointment or starting the procedure from the request list. For example: o For general x-rays, select ISR, generate bill and start procedure. No need to book an appointment slot before starting the procedure. o For specialised x-rays like CT or MRI, book appointment, indicate arrival of the patient on appointment day, generate bill and continue workflow. Able to restrict cancellation of confirmed/performed orders to defined,configurable users/group.

HMS -PACS.120 The system should support printing of Radiology Request orders created in RIS or electronic radiology orders from EMR with relevant clinical and health information.

Appointment / Scheduling HMS -PACS.121 Graphical representation of booking slots with comments and/or colour code showing reservation of slots for different types of procedures, e.g., NeuroRadiology, Musculo-Radiology.

HMS -PACS.122 Able to define slots in a resource (room) based on certain contraints eg urgent cases only, inpatient or outpatient. System should be able to use these constraints and rules to faciliate giving an appointment.

HMS -PACS.123 Appointment diary to display available slots according to the procedure time. This improves utility of resource and eliminates waste gaps in appt time slots. Visually the schedulers can identify appt time slots readily.

HMS -PACS.124 Able to customise the number of booking slots available per day as duration of the procedures varies for different types of examinations. The system should allow reservation of appointment slots for specific procedures, by patient type (eg. inpatient, outpatient), patient class, etc. This should be easily visible to assist users in scheduling.

HMS -PACS.125 Able to "suggest" an appropriate appointment date/time for patient based on certain rules and constraints, bypassing slots that do not meet the constraints for the patient.

HMS -PACS.126 System able to load balance the procedures booked in a particular modality over a defined period eg. 1 week, respecting existing constraints or have a dashboard which gives a quick view of the booking in each of the rooms or in the modality over 1 week.

HMS -PACS.127 Ability to separate appointment resources by department and yet enable crosschecking and alert if patients have the same exam/other already performed in own/other department recently or already has an appointment made in different department within a specified number of days.

HMS -PACS.128 Ability to auto-fax or auto-email appointment details to source of referral. HMS -PACS.129 Able to check for duplicated procedures and/or procedure conflict and alert user when an appointment is given.

HMS -PACS.130 Duplicate checking: The procedures to check against and the number of days should be customizable at procedure level or modality level rather than be a system wide setting that is the same for all procedures.

HMS -PACS.131 Alert for contra-indication such as “Cardiac pacemaker for MRI procedures” HMS -PACS.132 Able to alert and prompt alternative appointments for multi-exam procedures requiring more than one procedure rooms.

HMS -PACS.133 Able to define specific appointment slots for viewing and scheduling for certain category of users. Able to restrict booking into certain appointment slots in the scheduling book.

HMS -PACS.134 Able to easily reschedule an ISR without having to unscheduled. HMS -PACS.135 Able to block and reserve slots with a patient identifier but without having to create ISR by designated users or user groups. That identifier could be used as searchable criteria in the scheduling system.

HMS -PACS.136 Able to control rights for overbooking to authorised users. Configurable in terms of resource allowed to overbook, number of overbooking & types of procedures, etc.

HMS -PACS.137 Able to perform group transfer of appointments. HMS -PACS.138 Able to easily close a few rooms for a certain defined periods or a particular date. This could be done by user, without intervention by a system administrator.

HMS -PACS.139 Able to generate list of appointments affected (with patient details) when there are ad-hoc closure of appointment rooms.

HMS -PACS.140 Able to generate a daily list of appointments by appointment room 1 working day prior to procedure date. Able to export this list to Excel or other standard software to be used in case of RIS downtime to arrive patients.

HMS -PACS.141 Able to input of comments (via a drop-down list) related to appointment making, e.g. appointment date is requested by patient, etc with option to display the comments online or extracted in report.

HMS -PACS.142 The system should allow for appointment labels and preparation instruction to be printed for specific procedures.

HMS -PACS.143 Upon an appointment being scheduled for an inpatient, the system has an option to automate sending of instruction to inpatient locations regarding procedure preparation/appointment details/consent.

HMS -PACS.144 The systems should capture fees of procedures based on different patient paying status so as to enable appropriate fees to be printed on labels or instruction sheet for conselling of procedure cost to patient.

HMS -PACS.145 For inpatients’ appointment, the appointment module shall provide a portering service schedule for porters to bring inpatients from the wards for examinations and to send them back to the wards after the examinations.

HMS -PACS.146 Able to auto change appointment status into "No Show" on the the next day if patients do not turn up for appointment.

HMS -PACS.147 Able to email or SMS reminder to the patient of an impending appointment in a predefined timeframe.

HMS -PACS.148 Web-enabled appointment schedule book for external clients. This shall be integrated with institute website if required in future

Patient Check-in And Order Creation HMS -PACS.149 Able to setup new procedures in advance with effective dates. HMS -PACS.150 Able to setup procedures which require different equipment resources e.g. CT Arthrography (require both CT and fluoroscopy resources).

HMS -PACS.151 Support mapping of a specific procedure to different service code base on patient type, referring location, facility, performing department, procedure code etc. Example:

HMS -PACS.152 Able to assign unique numbers (accession and order numbers) to identify the procedures and provide the link of results/ to images in PACS.

HMS -PACS.153 Orders created within RIS to be differentiated from orders originating from CPOE. HMS -PACS.154 Able to capture and/or bill procedures such as surcharges, consultation, follow-up, consumables, etc.

HMS -PACS.155 Able to trigger charge or credit transaction to billing system(s) upon order entry or cancel or replace procedure respectively using HL7 protocol for communication

HMS -PACS.156 Able to apply price discount by referral location. HMS -PACS.157 Able to capture the reasons for cancellation of procedures or no charge procedures or waiver of professional fees for audit purpose.

HMS -PACS.158 Produce sticky labels with patient, visit, billing code and order related information

HMS -PACS.159

upon check-in or order entry: o to show waiting/procedure room o to display accession/order number for identifying procedures for modality worklists and reporting o to paste on film envelope for film tracking and despatching of films to GP referrals, non-resident patients, clinics, etc. System should have an easy way to do adhoc re-reprint of additional patient labels.

Examination Room HMS -PACS.160 Filterable Worklist for scheduled/ordered procedures based on room, modality or location eg waiting area. Able to configure fields and filters based on user preference. The system has an option to save the user-defined worklist. Ability to print and export list.

HMS -PACS.161 Be able to select multiple procedures from the worklist, and perform the same operation in one instance eg start or complete procedure or assign reporting radiologist.

HMS -PACS.162 Track procedure duration based on procedure start and complete times HMS -PACS.163 Track radiographer(s) who performed the procedure. Able to easily add additional operators.

HMS -PACS.164 Track radiologist(s) who performed the procedure. HMS -PACS.165 Track other personnel involved in the procedure eg nurses, patient's care-giver. HMS -PACS.166 Allow radiographers to enter technical comments for procedures performed to capture examination information eg. Contrast usage, sequences performed, sonographic findings.

HMS -PACS.167 Able to order/cancel/remove procedures. There should be a security object that controls cancellation of procedures that have been started or have images or reports.

HMS -PACS.168 Exam status should include suspend and confirmed statuses or equivalent. HMS -PACS.169 Able to trigger messages to EMR/HIS for order/cancel/remove of procedures when applicable using HL7 protocol for communication

HMS -PACS.170 Able to route examinations for reporting based on user defined rules. Criteria include: institution, equipment/group of equipment, imaging centre, individual radiologist or group of radiologists, modality, types of procedures, patient payment class, referring medical service.

HMS -PACS.171 System should be able to define and capture different work units for the same procedure done in different rooms or for different patient type eg inpatient vs outpatient.

HMS -PACS.172 MPPS from modality to RIS/PACS (including sequences) to plan examinations based on protocol.

HMS -PACS.173 Reuse protocols from previous examinations when planning follow-up examinations at the same modality and for the same organ.

HMS -PACS.174 To trigger a message to EMR/HIS upon examination started/completion. HMS -PACS.175 To alert referring clinicians through email or SMS upon examination completion if applicable.

HMS -PACS.176 To allow radiographer to group/link 2 or more procedures to be reported together. Splitting of grouped procedures should also be possible prior to reporting.

HMS -PACS.177 Allow radiographers to update reporting priority. HMS -PACS.178 The PACS to be able to support segmentation of studies. This is to enable the radiologist to view the study in parts before completion especially for MRI and CT.

Reporting HMS -PACS.179 Able to import patient history into the Radiology report. HMS -PACS.180 An efficient way to assign a list of pending reporting tasks to a particular radiologist to report.

HMS -PACS.181 Able to view at a glance outstanding reporting tasks based on each worklist eg. MRI (2) ie. 2 MRIs not reported.

HMS -PACS.182 Reporting templates and canned text should have both public and private options. Report templates and canned text should be keyboard and voice activated.

HMS -PACS.183 Standard word processing capabilities with spell checking function, formatting e.g bold underline, italic and medical dictionary

HMS -PACS.184 Voice recognition should function together with all combinations of template and canned text reporting using keyboard activation +/- voice activation.

HMS -PACS.185 Supports disease coding system if required by regulation (ICD-10) HMS -PACS.186 Able to correct reports (alter original report text) after final/verified i.e remove original content but with history of original versions kept (versioning).

HMS -PACS.187 Able to amend reports after finalised/verified as addendum i.e additional text on top HMS -PACS.188 HMS -PACS.189

or bottom of original report but leaving the original report text untouched. Allow specification and flagging of levels of abnormal reports Allow radiologist to alert referring clinicians for abnormal and amended report i.e., either through email, SMS

HMS -PACS.190 Abnormal alert levels should be a "field" that can be filtered/sorted and used to create report printing worklists.

HMS -PACS.191 Flexibility to control printing of preliminary and final reports. HMS -PACS.192 Able to easily diifferentiate amended reports from original version in printouts. HMS -PACS.193 The printed radiology report should have the time stamp of when the report was printed.

HMS -PACS.194 Option to automatically utilise pre-defined fields of data captured in the acquisition notes or technical comments (input by radiographer) to pre-populate to the radiology report.

HMS -PACS.195 System should make it easy to assign and reassign cases for reporting within specific user rules. System should have ability to set up proxy rights to enable Radiologist A to finalise reports on behalf of Radiologist B (if the proxy rights are given).

HMS -PACS.196 Cases reported by the resident should route to the radiologist's work-list for verification regardless of mode of report creation.

HMS -PACS.197 Cases awaiting verification by the resident will auto-route to the radiologist's worklist for verification after user specified time frame.

HMS -PACS.198 Radiologist's sign-out list should be able to view configurable fields incl. patient name, examination, priority of examination,priority of reporting, report status, reporting resident, patient type (ie. I, E, W), referring department etc.

HMS -PACS.199 Allow more than one radiologist to verify a report (co-read). HMS -PACS.200 Alert/highlight unreported or unverified reports to respective radiologist as a pop-up reminder on log in. After a user defined time, email or sms reminder to be sent.

HMS -PACS.201 Able to track both the reporting and verification radiologist and easily determine the person that needs to verfiy the report or perform an action that will allow the report to be finalized.

HMS-PACS.202

Able to print a verified radiology report with name(s) of reporting and verifying radiologists, date/time of verification in a format acceptable to the institution. If preliminary reports can be printed, specify if there are distinguishing factors that differentiate it from a verified report eg a watermark.

HMS -PACS.203 Allow to print a verified report on an adhoc basis. HMS -PACS.204 To allow option of auto-printing upon verification.

HMS -PACS.205 Able to distribute verified reports by automated faxing, sending of reports by email. HMS -PACS.206 Reporting module should have a lock feature that prevents radiologist from starting a report on an examination that has already been opened for reporting by another radiologist regardless of screen refresh.

HMS -PACS.207 If reporting module supports viewing of more than 1 patient's images at a time, then the module should have a warning feature that alerts the radiologist if starting to report or saving / verifying a report for a procedure when another patient's images are opened for viewing. eg. Patient 1 images and report editor are open for reporting. Patient 2 images are opened for a quick review with clinician without closing Patient 1 report editor and or images. Subseq. with patient 2 images still open, radiologist wishes to Save or Verify patient 1 images, warning message should appear.

HMS -PACS.208 Tightly integrated voice-recognition system: o

HMS -PACS.209

Proposed reporting solution should include Voice Recognition and Digital Dictation Applications which should preferably be tightly integrated as part of the GUI of the RIS solution. o State if the VR has option to forward report and voice file to transcription to allow correction of VR text by transcriptionists. Ability to save personal voice profile into a transportable file after voice recognition training and apply it to another institution using the same system. (Saving and export of voice file).

HMS -PACS.210 Allow radiologist to indicate priority of dictated report to the transcriptionist. HMS -PACS.211 Able to support structured and tabulated reporting and data mining. HMS -PACS.212 Able to support addition of diagrams and images into the radiology report. HMS -PACS.213 Able to support different ways of reporting e.g. manual dictation, digital dictation, voice recognition & template reporting.

Recording Media Tracking HMS -PACS.214 System should provide a way to track at the procedure level whether films or CDs have been given to the patient or ward.

HMS -PACS.215 System should provide a way to charge for the films or CDs given to patient.

Inventory HMS -PACS.216 To track the stock level of the procedure related items (e.g. contrast media, needles, medication etc.) at the main store and sub-stores (certain procedure rooms). Basic features of an inventory system must be present.

HMS -PACS.217 Module is integrated with the Examination Room Input module so that stock level can be automatically adjusted according to the usage in the procedure rooms.

HMS -PACS.218 Track and calculate statistics of consumable used. HMS -PACS.219 Able to set up procedures with default consumables (which may or may not be billable) with default quantities. Both the default consumable and the default quantity should be modifiable.

HMS -PACS.220 Able to charge for consumables used in radiology (during exam completion). HMS -PACS.221 If the procedure is cancelled, must be able to credit the charges for the consumables. HMS -PACS.222 Triggering a charge and usage of consumables should be independent of each other. That is to say, we could waive charge for a consumable yet update inventory quantity for used items.

HMS -PACS.223 Allow flexible entry of consumables at user-defined points in the workflow. HMS -PACS.224 Able to change the quantity of a consummable (ad hoc) Data-Analytics HMS -PACS.225 The system shall support advanced data analytics tools based on Machine Learning and Artificial Intelligence algorithms. Following are the few analysis features that the system must support HMS -PACS.226 When Radiologists finishes one Report, the system shall automatically finds the cases where similar findings have been reported HMS -PACS.227 The system (once trained) shall be able to identify the best matching node in the Academics Folder directory HMS -PACS.228 Big Data Support ie ability to export data to HADOOP cluster and analyze it. Vendor Neutral Archive(VNA) Features HMS -PACS.229 Scalable. The performance should not degrade as data size grows HMS -PACS.230 The vendor shall provide user friendly access to usage statistics which includes-- but is not limited to--storage and retrieval rate based on institution, department, modality, and study description HMS -PACS.231 System administrator tools must allow for patient and study merge

HMS -PACS.232 Tools should allow for changing any DICOM Attribute in the image header and database HMS -PACS.234 Query tools (SQL is acceptable) shall be provided to access the database for any searches that are needed to locate “lost exams” and perform any analysis (based on images stored) that an institution sees fit. HMS -PACS.235 Changes in image headers should be able to propagate to all images in the respective Exam, Series, Study, and Patient level HMS -PACS.236 Storage and retrieval of Enhanced DICOM objects such as--but not limited to-- the new multiframe MRI, CT, XA, and RF shall be supported HMS -PACS.237 A complete list of all supported Image Storage SOP Classes shall be provided HMS -PACS.238 Changes in window width/level, zoom, and pan shall be stored and retrieved as DICOM Presentation States HMS -PACS.239 Overlays, such as those that contain measurements and notes, as well as markers and shutters, shall be stored and retrieved as DICOM Presentation States HMS -PACS.240 Key images shall be stored and retrieved as DICOM Structured Reports HMS -PACS.241 Structured reports--such as to store CAD and measurements--shall be able to be stored and retrieved HMS -PACS.242 A complete list of supported Non-Image DICOM SOP Classes shall be provided HMS -PACS.243 Query, storage, and retrieval of multimedia formats such as--but not limited to--MPEG, JPEG, TIFF, .DOC, .TXT, .PDF, and .XML shall be supported HMS -PACS.244 A complete list of supported file formats shall be provided HMS -PACS.245 All DICOM Unique and Required Query Attributes shall be supported HMS -PACS.246 A list of all optional DICOM Query keys for both Patient and Study Level Query shall be provided HMS -PACS.247 A SQL interface shall be provided that shall allow administrator access to the institution's PACS to perform queries HMS -PACS.248 The number of responses to a “wide-open query” shall be configurable HMS -PACS.249 The device shall support WADO for retrieving images and related information over a Web interface HMS -PACS.250 Autorouting rules shall be configurable to include Institution, AE Title, Station Name, Modality, Date and Time as well as referring Physician HMS -PACS.251 Routing shall take place simultaneously to multiple destinations HMS -PACS.252 Prefetching rules shall be based on HL7 transactions and be configurable to include--as a minimum--Body Part, Modality, Institution, Study Date HMS -PACS.253 The device shall support DICOM Storage Commitment as a SCU and SCP

HMS -PACS.254 The device shall support DICOM MPPS as a SCU and SCP HMS -PACS.255 Vendor shall specify its tag morphing capability--whether it is static, dynamic, bidirectional-- and a list of attributes and their values that can be configured HMS -PACS.256 Supported IHE Profiles: The device shall support the following profiles: SWF: Scheduled Workflow for radiology PIR: Patient Information Reconciliation for radiology XDS-B: Cross-Enterprise Document Sharing XDS-I: Cross-Enterprise Image Sharing PIX/PDQ: Patient Identifier Exchange and Query ATNA: Audit Trails Node Authentication EUA: Authentication HMS -PACS.257 VNA Should be Level IV HMS -PACS.258 VNA      Vessel analysis HMS-PACS.259

Should support Radiology images Cardiology images Pathology images XDS documents Other Dicom objects such as structured reports, Presentation States, Key image notes and visible light images

Oncology workflow Automated registration Bone removal OB measurements Advanced PET/CT PET / CT fusion Optional third party integrate for orthopedic templating stream line work flows with a standards based connectivity option to external application .This includes the ability to launch products such as Orthopedic templating and external RIS applications from PACS

Web reporting HMS-PACS.260 Global reporting work list HMS-PACS.261 Web deployed voice recognition HMS-PACS.262 Multi-Site pass integration HMS-PACS.263 Multi- Site report approval Data Management:HMS-PACS.264 Information cycle Management HMS-PACS.265 Quarantine Features HMS-PACS.266 Rules workflow engine for creation, approval and audit of rules

1.14 Billing: The Public healthcare services are provided free of cost to citizens. However there are certain services which are billed also. For example OP tickets are given for a very nominal fee. Pay wards have rental charges. The eHealth system shall have a billing module to manage the billing and collection. The system shall have the following facilities: HMS-B&C.1 Patients The module shall have facility to search patients based on various Search & search criteria and display details based on the access rights. Select HMS-B&C.2 Adding and The system shall have facility to add new charges as well as modifying modify existing charges Charges HMS-B&C.3 Bill The system shall generate bills Generation HMS-B&C.4 Payment The system shall have a collection interface to collect payments at collection the cash counters through Cash / Credit Card / Debit Card / Cheque HMS-B&C.5 Online The system shall have linkage with the State Governments payment payment gateway to collect online payments. HMS-B&C.6 Advance and The system shall have facility to receive Advance and Part Part Payments payments. HMS-B&C.7 Refund The system shall have facility to refund excess amount collected HMS-B&C.8 Patient Dues The system shall generate Patient Dues Report Report

1.15 Queue Management System: eHealth shall have a well defined Queue Management system. This consists of a Queue Management Application and a Token Display system. The logic for queue management is already described in previous sections while listing the requirements of various modules such as OP Management, Lab management etc. The Application shall implement this logic and shall interface with a standard Token Display system. This will be an integrated solution of Token Display and Digital Signage. Digital Signage is a system for disseminating information to intended audience. Any kind of contents viz, full motion video, photo-realistic graphics, text, presentations, animated flash images and much more. This is a dynamic scenario comparing to that of old conventional static boards, banners etc. The proposed system will take care of displaying the token numbers being allotted to specific counters along with Digital signage for displaying various schemes and other information such as Videos, Slides, Tickers etc. The token numbers along with counter numbers will be displayed in a portion of LCD display. Video relating to various healthcare schemes and other information will be displayed in the LCD screen along with the token numbers with the help of a digital signage software. In this way, the public / patients waiting for their turn can

watch other useful information along with token numbers. This way the healthcare authorities can convey any information relevant to public effectively using this media. The HMS shall interface with a standard third party Digital Signage system and provide the above functionalities. The requirement of the Token Display system with Digital Signage Solution are described below. Supply and maintenance of Token Display systems and LCD Displays are not within the scope of this RfP HMS-QMS.1

Queue The queue management and token display will be handled management by the central eHealth Hospital Management System and the token numbers generated will be displayed in the respective portion of the LCD display unit. The system will fetch the queue token data sent from the server at the data centre and display it along with the media content at the designated area of the TV screen. The screen layout of the LCD display shall be configured as per requirement with reference to the QMS and Signage application.

HMS-QMS.2

Digital signage solution

The digital signage solution also shall be centrally managed and monitored. The server part of the Digital signage Application will schedule the display and transfer the digital contents along with the schedule for display to the respective media players installed at the hospitals. Using the Server module, media content for specific department (Reception, General Medicine, Gynecology, Pediatrics etc) shall be formatted and scheduled at the data centre. The content created at data centre shall be downloaded to each player having specific IP address using the back bone data network. The download process shall be automated during off-peak time to reduce the network load. The downloaded content shall have a play list and media files which will be displayed on the TVs accordingly. The displays installed will have connectivity to individual

HMS-QMS.3

LED Token Displays

HMS-QMS.4

Ethernet LAN connectivity and specific IP addresses Solution Components

HMS-QMS.5

media players. Each media player will have a client version software. The client version of the Digital signage Application installed in the local media players will manage the display of the video and other digital contents as per the pre-defined schedule in the LCD screen. As per schedule, the contents will be fetched from the player and will be displayed. In addition to the above facility, dedicated LED counter token display units also shall also be provided in each Hospital. These counter display units are to be installed in the counters which are located away from the normal patient waiting area. Departments like Labs, Pharmacy, Radiology etc which may be in separate buildings can be provided with these LED displays for showing the token numbers. Transmitting token numbers to these counter display units will be through the central Queue Management System.

Both the above displays shall have Ethernet LAN connectivity and specific IP addresses. The token data received from data centre specific to an IP address will be displayed with an audio alert. The total solution consisting of the following:  Hardware (Not within the scope of the present RfP) o LED TV Display system. o Media player with storage facility. o 4 digit Counter Display Unit (LED)  Software (To be integrated with the HMS)

HMS-QMS.6

Digital Signage Software

o Media player Software (Client version at the Hospitals) o Server Signage Software. The Digital Signage Software shall have the following features:  Provision for content management at data centre and distribution of the same over network to various players with TVs.  Provision for display of Queue Token Numbers along with media files.  Provision for display of Token numbers in dedicated LED displays.  Windows/Android based Software.  Screens can be divided into multiple zones and multiple files can be played simultaneously.  Supports all media files (Video, Photos, PPS, PDF, JPG, AVI, BMP etc).  Scheduling facility: Contents can be created in advance and be scheduled for a later date & time. It will be triggered at the pre-defined date & time automatically.  Connectivity to live TV channels available.  Content previewing facility available.  Supports different display sizes.  Support Landscape & Portrait modes of displays.  Different layouts can be created and can be saved as templates for future design/use.  Built-in International Clocks in both analog and digital format.  Text & tickers features. Supports regional languages and RSS feeds.  Grid option to align files properly.  Audio can be enabled or disabled.  Each player can have discrete content, if required.  Screens interfaced with same Player will play uniform content.  User privilege facility: Password protection and Userright restrictions.  Log Report at any point of time  Administrator can know the status of each client at any point of time.  Players can be monitored & controlled remotely.

1.16 Interoperability with Legacy Systems: The system will be required to communicate with existing Legacy systems and interchange data. This interoperability shall be implemented through SOA described above. The Legacy systems which shall be linked with eHealth are listed below. HMS-LS.1

Total Automation Solution for KMSCL (TASK)

HMS-LS.2

SPARK

HMS-LS.3

eTender

HMS-LS.4

Treasury system

HMS-LS.5

Drug Controller Application

HMS-LS.6

Professional statutory Bodies:

HMS-LS.7

Regional Cancer Centre (RCC) Insurance

HMS-LS.8

The system shall exchange data with TASK seamlessly. TASK has provision to transfer medicines and equipments to the level of stores on the Hospitals. The stock received in the Store shall get automatically updated in the eHealth Database and further distribution to Pharmacies and Wards shall be through eHealth System. Additional requirements of integration is described in sections Asset Management and Maintenance Management’ eHealth System may have a Unique ID for each employee. This Unique ID for employee shall be mapped with the PEN number given in SPARK. Similarly all the Institutions shall also be mapped with that of SPARK. There shall be a facility to do this mapping in future also when new employees join or when new Institutions are added. Kerala Government has adopted the eTendering system of NIC for procurement. The Purchase Orders released through this eTendering system will have to be entered in the eHealth system for further processing. eHealth system shall be designed to have this compatibility and a future integration through web services or by digital data interchange through standard file formats such as XML or CSV. The treasury system in Kerala is fully computerized. Many of the cash collection in Health Department is through standard treasury receipts. This will require printing of standard Treasury Receipts and remitting of money at Treasury. All required forms and reports for this cash transaction as per treasury rules will have to be generated by the system. eHealth system shall be capable of accepting data pertaining to withdrawn/banned drugs directly or through manual entry from the Drug Controllers portal. The information shall initiate a process to stop distribution of all such drugs with immediate effect. Statutory bodies such as TC Medical Council, Nursing Council, Pharmacy Council etc has a digital database of professionals who are registered and are allowed to function in their respective fields in Healthcare sector. eHealth system envisages a future enrollment of Private sector in the framework. Hence there shall be a linkage to the information on professional registrations so that professional practice by unqualified persons are totally eliminated. RCC has an independent computerized system. eHealth Database shall be updated with the EMR from RCC. RCC Servers will upload this EMR regularly to eHealth through web service. eHealth shall have facility to carry out this uploading regularly.. eHealth Application shall be able to provide data to various

Schemes: HMS-LS.9

Other Health Care Schemes

Insurance Schemes approved by the Government. Details of Insurance Schemes is given in Section …… eHealth shall provide data required by all Healthcare schemes being implemented by State and Central Governments. An indicative list of major schemes currently under implementation is given below.  IDSP  MCTS  NCD Control  School Health  Blindness Control  RNTCP  Leprosy Control Programme  National Vector Borne Disease Control Programme (NVBDCP) There are several other schemes currently being implemented in the Healthcare sector. The list of the schemes are provided in Section ...... 'As-is Scenario'

2

Web Portal

Objective : The goal is to provide the citizen in general and Patients in particular a user friendly portal that will make it easy for them to communicate with the Health Department through the web. This portal will also act as a source of information for the citizen regarding policies and procedures. This in turn will improve customer satisfaction and reduce work load on the employees. The portal shall also provide a platform for forming a social network of Healthcare Professionals such as Doctors, Nurses, Lab Technicians, Pharmacists etc.

Requirement Functionality Description ID WP.1 Design of the Portal Web Pages shall be designed to render a logical and professional layout for the Website enhancing the overall user experience. Uniform look and feel is to be maintained across all pages of the website. Site shall be well organized, information being available with minimal number of clicks and navigation clear and consistent

WP.2

Content Management System

CMS for the Portal shall be configured with appropriate business flow required to authenticate of publication of content in the site. CMS must be easily manageable and authorised staff must be able to add, change and delete Portal contents without manipulating any HTML or scripting code as and when required

WP.3

Content organisation

Contents shall be organised meaningfully in manageable units with appropriate meta-tag/ labelling scheme. Visual elements are to be appropriate and well organised

WP.4

Delivering different types of contents Plug-ins

Capable of hosting and delivering different types of contents including HTML documents, word documents, PDF documents, Images, Photographs and Multimedia files.

WP.6

Floatable and collapsible menus

Floatable and collapsible menus and icons shall be effectively used to enhance the content presentation.

WP.7

dynamic generations of links

The design should support the dynamic generations of links on the page.

WP.8

No broken links

There shall be no broken links (causing 404 Error) in the site, at any given point of time.

WP.5

Plug-ins shall be embedded for opening and viewing various contents including audios and videos.

WP.9

Search Facility

The Portal shall be search enabled.

WP.10

Search Engine Optimization

Search Engine Optimisation shall be provided for the Portal with respect to all major search engines such as Google, Bing, Yahoo, Alta Vista etc

WP.11

CSS

CSS based design approach and W3C compatible coding style shall be used for developing the site.

WP.12

Browser Compatibility

The site must be compatible with the current versions of Browsers Firefox, Internet Explorer, Safari, and Chrome.

WP.13

Mobile Compatibility

The portal shall be mobile compatible rendering well on mobile and tablet devices.

WP.14

GIGW Compliance

The portal shall be compliant with the Guidelines for Indian Government Websites (GIGW) as applicable.

WP.15

Visitor Counter

The Portal shall have Visitor Counter.

WP.16

Event countdown Clock

The Portal shall have Event count-down Clock for specific events such as Pulse Polio vaccination etc.

WP.17

Online contests, quizzes and polls ‘Home page’ for each Healthcare institution

Portal shall have facility to host Online contests, quizzes and polls related to the Healthcare to generate awareness and interest among the public.

publicity and bulk outreach programs RSS feed

eHealth Portal shall also provide a platform for publicity and bulk outreach programs. Communication tools such as bulk e-mails, newsletters and SMS are to be integrated in the Portal. Dynamic RSS feed facility shall be incorporated in the Portal.

WP.21

live feeds to social networking sites

Portal shall render live feeds to Twitter, Facebook, other social networking sites.

WP.22

Virtual media rooms

The Portal shall provide virtual media rooms from where media can pull live updates, audio, video etc for publishing and broadcasting.

WP.23

Hosting

The Portal shall be hosted in Web Servers co-located in the State Data Center.

WP.18

WP.19

WP.20

The portal shall have a ‘home page’ for each Healthcare institution with institution specific details such as List of Specialties and Doctors, photo galleries, location map, Venue Maps, Contact numbers etc.

WP.24

Service Level

WP.25

WP.26

Integration with other components Security

WP.27

Audit trail

Audit trail of content updation of the site shall be maintained.

WP.28

Home

This page provides a brief description about the site, the various functionalities it provides and promotional features or any kind of advertisement for special programs can be placed in this page. Login Component is provided and registered users may login using their username and password. New Users can also register by clicking on the First Time Users Register link. The Forgot Password link helps the user to retrieve their password.

WP.29

Log In

WP.30

Registration

The Log In page asks the registered users for their username and password while the new members can also register through this page. Aadhaar Number may be made mandatory for registration

WP.31

Forgot Password

WP.32

Security Question Answer Change Password

WP.33

Average Response Time for all Web Pages shall be less than 4 seconds. The Agency shall be responsible for maintaining of service levels and necessary hardware, software and connectivity so as to achieve the service levels stipulated for the Web Portal. The Portal must be integrated with other components of the eHealth Solution as applicable. Portal shall have security solutions for protection from hackers, malware, Virus, Trojans, un-authorized access/intrusions and other threats. STQC Security Audit of the Portal shall be completed before hosting. Portal shall be accessible through HTTPS protocol over SSL layer.

The user is asked for his first name, last name, zip code, birthday and his primary email address before being provided with the security question. The new password is sent to the user by email (his primary email address as in his profile) on answering the question correctly. Once the user has logged in, he can change his credentials i.e. Username and Password by clicking on the Change Credentials link This is the landing page for the citizen. The screen contains a description of the account Any status messages pertaining to the account involving immediate user action is also presented here.

WP.34

My Page

WP.35

Encounter/Ep isode History

The page provides a line history of the encounters or episodes of during a selected period. A more detailed view of each encounter /episode may be provided on clicking each encounter/episode.

WP.36

Images

User shall be able to open and view the stored X Rays etc, if any

WP.37

Lab Results

User shall be able to open and view the stored Lab results etc

WP.38

Online Appointments

The system shall have options for Booking Appointments online. The queuing logic for those booking appointments online will decided in the system study.

WP.39

Book Pay ward online

Facility to book Pay ward online

WP.40

Online payment

The user shall have multiple modes of online payment such as Credit Card, Debit card, net banking etc. The online payment shall be processed through secured payment gateways. e Health system

shall he integrated with payment systems like the IMPS (Immediate Payment Service) of National Payment Corporation of India. Reference on IMPS and National Payment Corporation shall be done at http://www.npci.org.in/aboutimps.aspx WP.41

Pay for Services

Facility to make Payments online for all the available services such as Medical Certificates, Lab payment, Pharmacy, Pay ward etc

WP.45

Service Requests

This page allows user to post request for services such as house visit by Health worker, enrollment in service schemes etc.

WP.46

Service Request Status

This is a read only screen which the user can view. Status of various pending requests for the user are listed here.

WP.47

Complain

Under this page user can log his complaint using a drop down menu and also through key board entry.

WP.48

Complaint Status Report Outbreaks etc

This is a read only screen in which user can view the complaint status. This screen contains contact information to report Outbreaks etc to authorities.

WP.50

Online Reporting of Outbreaks etc

This screen allows the user to report any incident which has significance such as Outbreaks etc. The user has to fill up the specific information provided in the screen in order to locate the region/house etc.

WP.51

SMS facility

‘Push’ and ‘Pull’ SMS facility shall be integrated into the Web Portal. Portal shall have the capability for forwarding SMS alerts both on demand (pull) and on prescribed schedules (push) to both Healthcare providers and Public. Interested parties shall be able to pull pertinent information using simple and easy-to-use query formats. Portal shall also support bulk information dissemination (Immunisation Schedules, Disease prevention tips etc.) through SMS (push mechanism) to registered numbers. Government of Kerala has a Mobile Service

WP.49

Delivery Gateway (MSDG) which may be integrated to eHealth for SMS Delivery.

WP.52

Update Profile

This screen enables the user to update his/her profile information. The user can make changes to his email id, Mobile phone number etc. changes.

Wp.53

Report relocation

User can report relocation and change of address etc. The Health worker will make on site verification and update the demographic database.

WP.54

Healthcare Information Associated Sites Contact Us

This screen displays the relevant Healthcare information for Public view. This screen provides the link to all Essential the associated sites

Wp.57

Business Associates

This screen enables business Essential associates (contractors) to register online, view tenders, purchase tenders, etc

WP.59

Medical Reimburseme nt

Administrative user shall have privilege to update database on Drugs, Lab Test and Clinical Procedure eligible for reimbursement

WP.60

Medical Reimburseme nt Medical Reimburseme nt

There shall be an interface to check whether a Medicine/Lab Test/Clinical Procedure is reimbursable by Public sector employers

Wp.55 Wp.56

WP.61

3

This screen displays the information Vital of the contact persons, who should be contacted for any information or for providing any feedback

Government Departments and PSUs shall have accounts to post the claims of employees and get recommendation from DHS regarding admissibility of claims

Public Health Monitoring System

3.1 Introduction: The Public Health Monitoring System has six distinct functionalities. 1. Create and Maintain a Digital Family Health Register 2. Reproductive and Child Health (RCH) Monitoring 3. Integrated Disease Surveillance Programme (IDSP). 4. Non Communicable diseases program 5. Provide Data to all the centrally sponsored Public Health Schemes 6. Intersectoral Coordination with other agencies Family Health Register:- The State Health Department is maintaining a Family Health Register which provides comprehensive information about the households in the state. This register contains Village level details, House Details and Demographic Details. The first task is to

digitize this Family Health Register and then keep it updated. Once created, the eHealth system should keep the register constantly updated. RCH Monitoring:- The functionalities covered under the RCH head include Ante natal Care, Post partum Care, Mother and Child tracking, Immunisation Monitoring etc. IDSP:- Non Communicable and Communicable Disease Control is the main objective of IDSP. The Multipurpose Health Workers go out to the community for early detection of potential highrisk individuals and offer secondary preventive options. Detection of malaria cases by blood smear examination, pulmonary tuberculosis by sputum AFB examination, diabetes and high blood pressure screening, immunizations, etc are examples of this category of services. Intersectoral coordination with other agencies In the above measures, individuals or families are the targets. But certain aspects need concerted action from the community, as these interventions are beyond the scope of individuals or family. Air pollution, provision of safe drinking water, vector control, etc are examples of this kind of activities. The Multipurpose Health Workers need to keep track of such public health interventions also in the eHealth platform. Public Healthcare Schemes:- Central and State Governments have initiated several schemes with the aim of improving Public Health. Some of these Central schemes are monitored using a centrallised digital frame work. State Governments shall provide data to these digital frameworks at defined intervals. eHealth system shall provide data to these Central systems. eHealth shall also generate reports on these schemes for both State and Central governments. The Health Department has a well structured network of field workers and supervisory staff and Officers to handle the Public Health Functionalities. Providing the technical infrastructure, training and necessary hand holding for efficiently carrying out these tasks will be the responsibility of the Agency. The IT infrastructure for the Public Health Monitoring Functionality include the following: 1. Central Database and Central Application to manage the Public Health related functionalities 2. A Hand Held Device (HHD) with a user friendly Application to carry out the field activities.

As described earlier the basic reporting for Public Health Monitoring is primarily done by the Multi Purpose Health workers and their supervisory staff. This functionality is to be carried out using a Hand held devise which should have the required database and Software Application installed in it. The database in each device will pertain to the population each Multi Purpose Health worker is responsible for. The Application shall facilitate data collection and generation of reports offline. The Multi Purpose Health workers shall also be able to access the Central eHealth Database and Application, view and print the reports according to their access rights.

The details of training and hand holding support to be provided by the Agency is described elsewhere. The following descriptions relate to the requirements of the Public Health Monitoring Functionality with respect to the Hand Held Device (HHD) and the Central Application. All the functionalities described below shall be available in all types gadgets used such as Hand Held Devices, Tablets, Netbooks, Laptops and PCs. Some requirements are specific to the central Application and hence need not be available in the Hand Held Device Application. These requirements separately described.

3.2 General Requirements of the Hand Held Device Application HHD.GR.1

HHD.GR.2

HHD.GR.3

Online There shall be facility for real-time online synchronization of data synchronization of between HHD and central server. If this is not happening due to lack data of connectivity there shall be facility for this data to be uploaded to the central server when connectivity becomes available. This shall help in the prompt reporting of possible outbreaks of infectious diseases (the S form of IDSP project) and in the follow-up of Non-Communicable Diseases. This also avoids risk for data loss as hand held devices may be lost, stolen or infected with viruses or worms. This also keeps health data in centralized health information repository up-to-date. Thus the data entered into the handheld device from survey fields by health workers becomes part of a centralized health information database, which can be accessed from anywhere. Updating the The central system shall update the Database and Application residing Hand Held Device in the HHD periodically or on request. This will ensure that the HHD (HHD) is updated as follows: 1. Any data directly entered into Central database through Web based HMIS application 2. Data entered into Central database through other HHDs 3. Changes to master Data such as Ward Changes, New Taluks etc 4. Changes to the HHD Application (Version Control) HHD as a portable Thus the HHD will act as a portable office for the field level workers. office HHD will have updated socio-demographic data of around 5000 population (within the area of the workers jurisdiction). If any of these individuals avails hospital, or laboratory services, then the relevant details of discharge/results summary with clear instructions for follow up shall get updated in the HHD.

3.3 Mobile Device Management - Requirements The Solution should provide Secure corporate data at rest and in-transit across all supported devices the Solution should support Application and Corporate/Organization Policy Provisioning. The Solution should be able to easily promote, deploy, configure, distribute & update apps over the air (OTA) via a custom/enterprise apps store. The proposed Solution should be able to provide visibility and control of telecom costs using real-time telecom expense management analytics, reports and dashboards

HHD-MDM.1 HHD-MDM.2 HHD-MDM.3

HHD-MDM.4 HHD-MDM.5 HHD-MDM.6

HHD-MDM.7 HHD-MDM.8 HHD-MDM.9 HHD-MDM.10

HHD-MDM.11

Wipe and lock

The solution should support Wipe and lock corporate/work data remotely Removal of The solution should be able to remove corporate apps only leaving corporate apps personal data / apps alone Control device The proposed solution must be able to control device lock/unlock lock/unlock states states Manage SIM The proposed solution must be able to manage SIM Lock status Lock status Automatically The proposed solution must be able to automatically lock the device SIM Lock if SIM is changed Configurable The proposed solution must have an easily configurable password password policy that can be set on the managed devices policy Remote device The proposed solution must be able to carry out remote device wipe wipe Selective wipe The proposed solution must be also be able to carry out a selective wipe of the device data remotely Camera Lock The proposed solution must be able to lock/unlock the camera using GUI based policies Configurable The proposed solution must be able to define intuitive and user wizard-driven configurable wizard-driven policies to achieve the following policies functionalities: 1. Internet Browser lock for Open standard devices 2. Lock/Unlock USBs for Open standard devices 3. Block SMS for Open standard devices 4. Push Applications onto the device as per policy 5. Push Documents onto the device as per policy 6. Block documents leak from SD card 7. Block GPRS based on OS configuration capabilities 8. Block and Blacklist Applications 9. Block App Store Access / Downloads Remote control The proposed solution must be able to take remote control of the mobile devices for support activities from a central management location.

HHD-MDM.12

Security Requirements

HHD-MDM.13

Device Notifications

1. The proposed solution must support Application Containerization for application pay load 2. The proposed solution must support create enterprise data partition based on OS vendor 3. The proposed solution must support enterprise-based App stores The proposed solution must be able at least provide the following notifications from devices controlled by a wizard-based and GUIdriven policy editor: - Data usage - Voice and SMS

HHD-MDM.14

HHD-MDM.15

HHD-MDM.15

Mobile Operating Systems Integration with mailing solutions Data Security

The proposed mobility management solution must be compatible with the Open Standard Mobile Operating Systems The proposed solution must be compatible and integrate with Open Standard mailing solutions.

The offline healthcare data being stored in the mobile devices are sensitive and shall be as safe and secure as that in the central server. Hence security standards same as those in the centralized Database system shall be adopted for mobile devices as well.

3.4 Centralised Digital Family Health Register (FHR) Health Department is maintaining a Family Health Register in all Sub Centres. It has all relevant data about all citizens in the area. The register also has information about all public places in that region. This data is used for planning and monitoring public health activities in that region. A major task in eHealth project is the creation of a Digital Family Health Register. The Digital Family Health Register shall uniquely identify each citizen residing in the State. Such a Unique identity for each citizen is the primary requirement of implementation of eHealth Project. This will ensure that all healthcare Data pertaining to a citizen will be linked together based on this Unique Identity. Aadhaar registrations in the State are substantial. By the time the project is ready for implementation a large majority of the citizens in the state would have registered with UIDAI. So it is proposed to use Aadhaar as the Unique ID where ever it is available. In cases Aadhaar is not available the system will generate a Unique ID which can be used to link the Medical records of citizens. Several databases with citizen data already exist in the state. These are created by individual departments with the limited purpose of providing services related to that department. These are disparate systems existing in the servers of the respective departments. Each of these databases has a unique ID to distinguish the citizen within their realm of activities. A few examples are given below: Database

Department

Unique ID

PDS Database

Department Civil Supplies

Ration Card Number

LSG Database

IKM

House ID

Driving License Database

MVD

Driving License No

Remarks The Ration Card Number concatenated with the serial number can uniquely identify a Person who is included in the PDS database IKM is providing a unique House ID to each House so the frequent change of house numbers do not affect data integrity

Consumer Database

KSEB

Consumer Number

Nearly 100% houses are electrified and the consumer number can link to the House number

Health Department carries out a Family Health Survey and a Village Survey every year. Next Survey will be carried out with the help of Hand Held Devices and will have a unique objective of creating a centraslised Digital Family Health Register to be used by eHealth System subsequently. This massive survey undertaken by Health Department may be done with close coordination with several other departments which have databases of citizen data. The objectives of the survey are: 1. Link this data to the Aadhaar ID 2. Create a new ID to be used in the eHealth database in case Aadhaar is not available. 3. Insert the Unique IDs relating to Citizens in the existing databases of different departments in the Digital Family Health Register so that citizens can refer any of these IDs to identify them. Only this Unique ID from these database will be inserted in to the Digital Family Health Register. No other data from these databases of other departments are required in this Digital Family Health Register except the BPL status in case of PDS database. Some of such Unique IDs relating to citizens are:  Ration Card Number and BPL status from PDS database  House number from LSG database  Driving License Number from MVD database  Consumer Number from KSEB database 4. Import the relevant fields from Socio-economic census Data to complete the missing data in the Digital Family Health Register 5. Complete the database by entering the missing Data such as Mobile Number, relationship among the members of a house hold etc. PH.FHR.1

PH.FHR.2

Data Refining The eHealth system shall have facility to carry out the following as a prior to prelude to the Family Survey: Survey 1. Carry out a de-duplication of data in the respective individual (Central databases mentioned above Application 2. Do a data refining by eliminating junk data alone) 3. Suggest logical linkages of unique IDs of the same person in different databases 4. The Data as available from the existing databases may also be hosted in a web site with access rights for citizen to view their personal data. They may also be given rights to add additional information to their personal data. This data can then be further verified by the field staff during their field visits. Download to All the available data pertaining to the region being surveyed on a Hand Held given day shall be downloaded to Hand Held Device along with the Device probable linkages of unique IDs of the same person in different databases.

PH.FHR.3

Survey Process

All the available data pertaining to the region being surveyed on a given day will be downloaded to Hand Held Device along with the probable linkages of unique IDs of the same person in different databases. The Application shall have facility to pick any one base data depending on the situation and then link with other available data to create a linked database where all the above parameters of citizen is linked with each other. The missing data is to be collected. After locating the person in any one of the existing database the surveyor shall carry out the following data refining process: 1. Link the person's Unique ID in a database with corresponding IDs in other databases if existing. For example if a person has Aadhaar, then pick his id from the following: a. Socio-economic census Database b. Ration Card No from the database of PDS c. Driving License No from the Database of MVD d. House number of the residence from the LSG Database e. Consumer Number of the residence from KSEB Database 2. Then the surveyor has to collect and the remaining data that is not available in the selected databases.

PH.FHR.4

Basic information identification Data

The Application shall have facility to capture and edit the following basic data pertaining to each individual: 1. Name 2. Date of Birth, option for age 3. Gender 4. Aadhaar number 5. Father’s Name 6. Mother’s Name 7. Spouse name 8. Place of Birth 9. House Address of the present residence if different 10. Domicile Type 11. Blood group 12. Religion 13. Caste 14. Marital Status 15. Differently-abled /Disabilities 16. Ration Card No 17. Driving License Number 18. Land Line Number 19. Mobile Number 20. RSBY and other insurance schemes

PH.FHR.5

Factors affecting demographic indexes

The module also include provisions to identify and record factors affecting demographic indexes such as individuals’ educational, economic, and health status. 1. Physical Condition like disability 2. Major health issues –h/o diabetes, hypertension, CAD, epilepsy, mental ailments, COPD etc 3. Education 4. Occupation 5. Habits  Vegetarian  Smoking  Pan chewing/other substances  Consumes more than specified quantity of alcohol

PH.FHR.6

Family Database

The system shall have facility to group members of the Family together and denote the Head of Family and relationship of each member to the Head of the Family. The following data are collected: 

Family o o o o o

Head of family UID House Number House ownership Annual Income – APL/BPL



PH.FHR.7

Family Members o Name o Relationship o UID House Data A portion of the data required for this survey may already available in the Collection database created through triangulation explained earlier. The data collected or updated through this interface include:

House Details: • House No, Name • Place and PIN code • Unique House No. • House Type : thatched, terrace, apartments, etc • Electrified or Not • Latrine Type • Drinking water Source & Storage • Waste disposal details- pipe compost, biogas plant, soakage pits etc • Geo-cordinates-longitude, latitude, elevation, etc • Type of houses : own/rented etc • Nearest landmark

PH.FHR.8

Ward Reconstitution

When Local Bodies do a re-configuration of wards the house number changes. This change shall be updated in the eHealth Database also. There shall be a module to handle changes arising from ward reconstitution by Local Bodies.  New Ward Number  New House Number allotted after a ward change

PH.FHR.9

Changes to The core components of demographic change – birth, death and migrations Demographic in and out – are handled in this module. This module comprises of four sub Data modules:  Birth Registration  Death Registration  Migration Registration Data pertaining to Births and Deaths taking place in Hospitals covered under eHealth are available in the Central database. During the regular synchronization process this data shall get updated in the HHD. Births and Deaths occurring outside the Hospitals covered under eHealth are to be captured. The regular synchronization process shall update the Central database with data captured on Birth, Death and Migration.

PH.FHR.10

Birth Registration:

PH.FHR.11

Death Registration

The Application shall have a Birth Registration module to capture and store data on births occurring in each family. The data accumulated through this interface include  Name of Mother  UID  Date and Place of Birth  Type of Delivery  Any other relevant details The data from this module is used to get a sub-centre level month wise reports on Birth The Application shall have a Death Registration module to capture and store data on deaths occurring in each family. The data accumulated through this interface include  Name of deceased person  UID  Date and Place of Death  Cause of death as reported by medical officer  Duration and Status of diseases at the time of death  Death Report details The data from this module is used to get a sub-centre level month wise reports on Death including Maternal Death

PH.FHR.12

Migration Registration

The persons who are living in a province other than that of birth for more than 6 months due to employment, marriage or any other socio-economic factors is considered as migrated. Data on migrations within wards and outside wards are handled through the Migration Registration module. The data collected through this module interface include  Name of person migrated  Date and Cause of migration  Data on ward and house to which person migrated When a family moves out of the Village this can be marked as ‘Moved Out’ and when the Field worker in the destination Village can attach them to a house in the new Village.

PH.FHR.13

Village Survey

The purpose of Village Survey Module is to collect relevant economic, social, cultural and educational data about villages. It records data about the availability of various civic facilities including the supply of water, schools, health care, shops, offices, temples, Geo-cordinates-longitude, latitude, elevation of each building/spot of interest etc in a village. The data collected during village survey include details such as  Educational Institutions  Organizations such as MSS units, Kudumbasree  Public Places such as Libraries, Theatres, Community Halls, Markets …  Government / Non Government Offices  Worship places  Hospitals (clinics also)  Water Sources  Business Centres  Cattle sheds The data available in the Socio-economic census Database can be

imported, verified and refined.

3.5 RCH Monitoring: The requirements of the RCH Monitoring Application described below: PH.RCH.1

Reproductive The module focuses on the family planning services provided to Health and couples and has three sub modules: Family Planning  Eligible Couple Registration  Family Planning Registration  Family Planning Follow-up This module shall generate reports such as:  Eligible Couple Register  Target Couple register  Family Welfare Acceptance Register

PH.RCH.2

Eligible Couple The Eligible Couple (EC) Registration module identifies and Registration records some basic data pertaining to eligible couples in each family. The term Eligible Couples targets couples who are eligible for receiving any type of family planning services. The basic data collected include name of couples and their marriage date. With this interface, one can enter data on new registration, edit data on existing registration or view registration details. The registration shall normally be based on UID or a Unique Health Id (UHID). The UHID is a unique identifier created in eHealth Database to take care of situations where the citizen do not have UID (Aadhaar) Inputs  Name of Wife (Select name of the person)  Age of Wife  Name of Husband (Select name of the person)  Age of Husband  Survey Date  Marriage Date  Remarks PH.RCH.3 Family Planning Family Planning Registration module is used to enter the details Registration - of the couples who have accepted any kind of family planning Target Couple methods. The family planning methods are categorized as two details types Permanent and Temporary methods. The system itself maintains a list of family planning methods and the health worker is required to only select the required method. The interface also facilitates entry of data on institution, if the person visited an institution for accepting the method. In addition to the above, the system will also seek data on any complications suffered by the method acceptor. Inputs  Name  Survey Date  FW Acceptance Date  FW Acceptance Method a. Spacing method Condom IUDs (Copper T) Epills Oral pills Hormonal Implants b.Terminal Methods PPS Laparoscopic Sterilization Minilap Sterilization NSV

c.Others Hystrectomy  Institution Category a. Government b. Private  Remarks PH.RCH.4 Family Planning Once a family planning method is accepted by a couple, it has to Follow-up be followed up by the health workers on a routine basis. The data on each follow up visit is entered through the module Family Welfare Follow-up. The data collected for follow-up include whether there were any complications since method was accepted and whether the method was discontinued. Family Planning Family Planning Registration & Follow-up module facilitates PH.RCH.5 Follow-up - Data entry of data on entry  Family Planning Method Accepted  The Institution visited for method acceptance  Date of accepatance  Complications, if any suffered by the method acceptor PH.RCH.6 Family Planning Follow-up Inputs

Name Visit No Visit Date Previous Visit Date Complication  Failure  Recanalization  Sepsis  Death  Bleeding  Pain  Expulsion  Infection  Migraine  Vomiting  Allergy Complication Date Discontinue Date Discontinue Reason  Recovered  Continuing with Treatment  Dead  Transferred out Remarks

PH.RCH.7

Maternity Module

Maternal care includes care during pregnancy, delivery and immediately following delivery, along with the care of the new born. Women can get maternal care services either by visiting a health center where such services are available or from health workers during their domiciliary visits. One of the most important components of antenatal care is to offer information and advice to women about pregnancy-related complications and possible curative measures for the early detection and management of complications The health workers collect details of the services given to pregnant women and new born child using HHD. The maternity module involves the Antenatal Care module coupled with Postnatal Care module.

PH.RCH.8

Antenatal Care Ultimate goal of Ante Natal Care module is to reduce Maternal & Module Infant Mortality. This module comprises of the following components  Antenatal care Registration  Antenatal care Follow-up  Antenatal care Termination

PH.RCH.9

Antenatal care Name Registration - Survey Date Inputs Name of Husband Order of Pregnancy (Gravida) No. of Living Children No.of Abortions Type of previous delivery- Normal/LSCS Date of Last Menstrual Period (LMP) Expected Date of Delivery (EDC) Trimester (The system to automatically calculate the Trimester) Remarks Antenatal care  Name Follow-up Survey Date Inputs  Name of Husband (System to display the name)  Height  Weight  Blood Pressure  Blood group  Blood HB  Height of Uterus  Result of Urine Test o Albumin o Sugar o Deposits-Pus Cells

PH.RCH.10



       



PH.RCH.11

Antenatal care Termination Inputs:

o Deposits-RBC o Deposits-Others Danger Signal o Bleeding o Oedema face/legs o Viral Infection o Others Quantity of folic acid given Quantity of IFA given in 1st TM(Quantity of IFA tablets recommended for the pregnant woman) Quantity of IFA given in 2nd TM Quantity of IFA given in 3rd TM Quantity of calcium tablets given Inj.TT 1st dose- date Inj.TT 2nd dose- date Complications “Abnormal movement of baby” o Anemia o APH o BP above 140 o Epilepsy o Heart disease o Diabetesmelitus o Hypertension o Pregnancy 30y o Previous Caesarean o Weight increase more than 3 Kg/month o Short stature o Grantmultiparity o Others Referred Institution Category o PHC o CHC o THQH etc Referred Institution Name Remarks

  Name Survey Date Name of Husband

Delivery: Delivery Date Delivery outcome  Baby- Alive  Still Birth

Delivery Type  Normal  Forceps  Vacuum  LSCS Attended by  Specialist doctor  Doctor  ANM/LHV  Trained/skilled birth Attendant  Untrained birth Attendant Complication  Rupture  PPH  Sepsis  Post partum psychosis  Etc Termination type  Abortion: induced/spontaneous; If Termination type is legal/illegal If Termination type is MTP Type Abortion- 1st Trimester/2nd TM Date of Abortion/MTPPlace/institution where abortion doneReason  Medical  Eugenic  Humanitarian  Socio-economic  Others Person done- Specialist/MBBS Doctor/Health worker Patient Status  Alive  Dead Complication  Rupture/Tear in Uterus  Bleeding  Sepsis Remarks

PH.RCH.12

Postnatal Care The postnatal period (or called postpartum, if in reference to the Module mother only) is defined by the period beginning one hour after the delivery of the placenta and continuing until six weeks (42 days) after the birth of an infant. Care during this period is critical for the health and survival of both the mother and the newborn. This module records Post Partum Care details such as PPC methods and PPC given Date etc. Inputs Name Survey Date Postpartum Care Date Name of Husband Type of Termination Date of Termination Mother Complication  Fever  Abnormal Bleeding  Lochia-Foul Smelling  Abdominal Pain  Abnormal Behavior  Painful and Swollen legs  Painful Breast Child Complication  Refusal of Feeds  Increased Drowsiness  Cold to Touch  Difficulty in breathing  Rapid Breathing  Abdominal Distension  Convulsion or Stiffness  Incessant cry  Persistent Vomiting  Deep Jaundice Remarks

PH.RCH.13

Child Care Module

The Child Care Module is for recording data about individual children, for scheduling appointments for their immunization and for producing aggregated statistical information. This module comprises of the following components:  Child Registration. This is done through Birth Registration process in the

Demographic Module. The module will collect following data about an infant:  Child birth information (Birth Date, weight, Condition up to 28 days etc).  Risk factors, Abscesses, Complications.  Immunization  Scheduled and optional Immunization details (immunization name and Date).  Immunization Alerts The software shall generate Immunization reports such as  Lists the names of the Infants due for immunization services for the next 30 days.  Immunization services due against each Infant. PH.RCH.14

Child Care Name Module - Inputs Date of birth Survey Date Immunization Name Scheduled:  “BCG”  “OPV-0”  “Hepatitis-B1”  “OPV-1”  “DPT-1”/penta  “Hepatitis-B2”  “OPV-2”  “DPT-2”/penta  “Hepatitis-B3”  “OPV-3”  “DPT-3”/penta  “Measles”-1  “Vitamin-A1”  “OPV-Booster-1”  “DPT-Booster-1”  Measles”- Booster(1.5 Yrs)  “Vitamin-A2”  “Vitamin-A3”  “Vitamin-A4”  “Vitamin-A5”  “Vitamin-A6”  “Vitamin-A7”  “Vitamin-A8”  “OPV-Booster-2”  “DT/DPT-Booster”  “Vitamin-A9”  “TT Dose (10 year)”

 “TT Dose (16 year)” Immunization Name - Optional:  “HIB-1”  “HIB-2”  “HIB-3”  “HIB-Booster”  “Vericella”  “MMR”  “Hepatitis-A (Dose 1)”  “Hepatitis-A (Dose 2)”  “Rubella” Immunization Date Immunization taken from Outside (Yes/No) AEFI  Abscesses  Respiratory Tract  Skin  Urinary Tract Other Complications  Fever  Inflammation  Others  Redness  Swelling Remarks PH.RCH.15

Child Module Reports

care -

1. 2. 3. 4. 5.

Immunization due date list Unimmunized/drop out list Reasons for not getting immunized Universal Immunization Programme (UIP) CARD Complication Reporting - Adverse Events Following Immunization (AEFI) format to be used 6. IMNCI Components

3.6 Disease Monitoring Module A cadre of trained field workers equipped with HHD Application, Standardized practices and procedures, timely alerts, quick response coupled with service on a 24*7 basis will ensure a very effective Disease Surveillance mechanism in the State. eHealth shall leverage the existing framework into an effective Disease Surveillance Network in the state. The requirements are described below:

This Application Module in the hand held device is to be used for recording of any kind of communicable /non communicable diseases. The data will be collected by the Multi Purpose Health Workers and regularly uploaded to the Central eHealth server. The Central eHealth server also receives data from various sources viz. Hospital OPD, IPD and Laboratories. The central IDSP Module shall keep track of incidence of diseases based these several sources of data and give alerts in case the number of incidences of diseases cross the predefined limits and qualify to be notified as alarming stage. The purpose is tracking incidence of diseases, the detection and control of diseases through regular and timely reporting, ensuring prompt treatment, planning & monitoring preventive and remedial measures. Following are the purposes of Disease monitoring module:  Tracking incidence of diseases through surveillance  Early detection and control of diseases through regular and timely reporting  Ensuring prompt and complete treatment  Planning & Monitoring preventive and control measures  Help to conduct awareness programmes(IEC/BCC) and to give prevention advices The following is the description of requirements of the Application Module for Disease tracking to be to be used by the Multi Purpose Health Workers. PH-IDSP.1 Real-time Real-time data on reporting of Communicable diseases from Data Sub Centres, OP Clinics, IP Wards and Clinical Laboratories collection: shall be transmitted to the central server at very frequent intervals. Data from Sub Centres captured using the HHD Application shall be transmitted at a pre-defined interval. Data from OP Clinics across the State will also be transmitted frequently. The central system will aggregate this data and will constantly evaluate the situation based on an intelligent algorithm to detect any abnormal increase of incidence of diseases. PH-IDSP.2 Disease The Disease monitoring module in the HHD Mobile Monitoring Application collects communicable and non communicable using HHD disease details. This module shall keep record of the people affected with any kind of communicable /non communicable disease. PH-IDSP.3 Private In the present scenario reporting of diseases from Private Institutions Institutions is very low. In the new system there will be a web interface for each private institution to report the data on diseases regularly. This will make the system complete and accurate. PH-IDSP.4 Central The system shall send aggregate reports in the prescribed Government formats weekly to the Central Government IDSP framework. IDSP framework

PH-IDSP.5

Healthcare notification messaging service

The eHealth System shall have facility to automatically send out alerts in the form of SMSs, emails etc to all the concerned authorities. In addition there will be general Healthcare messages such as precautions during an outbreak etc. There is also facility to send out SMS to the concerned person regarding clinical test results and sensitive reports on communicable diseases.

PH-IDSP.6

Receiving Messages

PH-IDSP.7

Sub Modules

PH-IDSP.8

Disease Registration - Suspected Case Registration - Inputs

The system shall be able to accept SOS SMSs from individuals and make it available to the concerned authorities. There shall be facility for public users to text a particular keyword to receive information on a range of topics such as H1N1 fever symptoms. This module has been divided into following sections:  Disease Registration (Suspected Case and Confirmed Case).  Disease Follow-up. Name UID Age Sex Survey Date Symptoms  Acute Flaccid paralysis