ccbrt request for information - global tenders · pharmacy departments use sap b1. we plan for the...

Request for Information on Integrated

Hospital Management Systems

By

Comprehensive Community Based Rehabilitation in Tanzania

Confidentiality

This RFI document contains confidential and proprietary information and has been prepared to give vendors a high-level understanding of Comprehensive Community Based Rehabilitation in Tanzania’s (CCBRT) requirements for an Integrated Hospital Management System.

The contents of this document are provided solely for use by recipients and in considering their interest in providing services related to this RFI. Its reproduction by photographic, electronic, or other means is permitted only for the purpose of preparing a corresponding RFI response and in any other subsequent activities that may be related to the provision of the requested services.

Interested vendors are required not to disclose to anyone, other than their employees and officers directly connected to responding to this RFI and requested services, any information concerning this RFI. No news release, public announcement, or any other reference to this RFI or any program there under shall be made without expressed written consent from CCBRT.

Contents 1 Executive Summary ..................................................................................................................... 4

2 Project Overview .......................................................................................................................... 5

2.1 Problem Statement .............................................................................................................. 5

2.2 Project objective ................................................................................................................... 5

2.3 Project Scope ........................................................................................................................ 5

2.4 Other Information ................................................................................................................. 6

2.4.1 Current Systems ........................................................................................................... 6

2.4.2 Current Technical Environment .................................................................................. 6

2.4.3 Average volumes of transactions per day ................................................................ 6

3 CRITERIA FOR EVALUATION .................................................................................................... 8

3.1 RFI schedule ......................................................................................................................... 8

3.2 RFI RELATED questions / clarifications / submission ..................................................... 8

3.3 RFI terms & conditions ........................................................................................................ 9

4 RFI Requirements ...................................................................................................................... 10

4.1 General requirements ........................................................................................................ 10

4.2 High level business requirments ...................................................................................... 13

4.3 Overview of information Security Requirements and privacy protection .................. 27

4.4 Overview of Technical ARCHITECTURE ......................................................................... 29

5 Response Format ....................................................................................................................... 30

5.1 company profile format ..................................................................................................... 30

5.2 Project references .............................................................................................................. 31

1 EXECUTIVE SUMMARY Comprehensive Community Based Rehabilitation in Tanzania (CCBRT) is a non-

governmental organisation established in 1994 in response to the needs of people with

disabilities in and around Dar es Salaam and the lack of accessible services to them. It

comprises two community-based rehabilitation (CBR) programmes in Dar es Salaam and

Moshi, a disability hospital, and an active international training programme. CCBRT will also

be opening a high-risk, 200 bed maternity hospital in 2015 to prevent birth-related disabilities

before they occur. CCBRT is the largest indigenous provider of disability and rehabilitation

services in the country, providing quality rehabilitative services to 120,000 people with

disabilities and their caregivers each year. CCBRT on a daily basis delivers its services to an

average of 480 outpatients and perform surgery to around 50 people. Comprehensive

Community Based Rehabilitation in Tanzania website is http://www.ccbrt.or.tz/home.

Comprehensive Community Based Rehabilitation in Tanzania referred to herein as

“CCBRT”, is requesting for information from vendors rendering professional services

related to Integrated Hospital Management Systems (IHMS). The intent is to invite

interested vendors to highlight system capabilities that will best meet CCBRT’s IHMS

needs. CCBRT will subsequently shortlist respondents’ best placed to meet CCBRT

requirements and subsequently invite them to respond to a detailed Request for Proposal

(RFP). The RFP will contain detailed technical requirement specifications upon which

vendors will submit a technical and financial proposal for the supply and implementation of

their proposed solution. However, the general nature of the scope of work including high-

level technical specifications for the IHMS is outlined in this Request for Information (RFI).

All questions and inquiries regarding this RFI should be addressed to the project office at

the below email address:

[email protected]

2 PROJECT OVERVIEW This RFI addresses the system, technical requirements as well as implementation

requirements and concerns of ICT in the delivery of an IHMS for CCBRT. This chapter

seeks to provide a brief description of the project.

2.1 PROBLEM STATEMENT

With the systems currently in use, CCBRT faces system functionality gaps that are either

not currently addressed, or are addressed through manual workarounds, creating additional

work and control risks. Challenges faced include:

Poor patient flow;

Numerous physical patient files to retrieve, create and re-file;

Lack of integration between current integrated hospital management system and

finance system, leading to opportunities for fraud;

Poor insurance process management (from verification to collections);

Inadequate reporting;

No current capacity to incorporate the maternity Hospital’s needs into system

without re-design and development; and

Poor inventory and procurement tracking and controls.

2.2 PROJECT OBJECTIVE

To implement an integrated hospital management system to manage and track all of

CCBRT’s patient information, including registration, payment, treatment, medical records,

as well as manage support services such as procurement, warehouses, and finance for all

of CCBRT, including the Disability Hospital, Community Programs in Dar es Salaam and

Moshi, and the Maternity Hospital to be operational in 2015.

To better track patient medical data, improve patient flow, identify real costs relating to

patient services, ensure integration between medical services and billing, create controls to

lessen fraud, and satisfy reporting requirements

2.3 PROJECT SCOPE

In order to obtain a new IHMS, CCBRT will identify its requirements, select a vendor to

implement software that addresses our needs, and work with all levels of staff to ensure

system is tested and staff trained, for a successful go-live.

A new integrated hospital management system should be operational at the Disability

Hospital by October 2014 and should be ready for implementation at the new Maternity

Hospital upon its opening.

2.4 OTHER INFORMATION

2.4.1 Current Systems

CCBRT currently uses an in-house Access database to manage patient demographics and patient payments. Our Finance, Procurement, Warehouse and Pharmacy departments use SAP B1. We plan for the new IHMS to replace the Access DB completely. We will consider IHMS solutions that use our already purchased SAP B1 for the financial module, or an IHMS that contains its own financial module.

2.4.2 Current Technical Environment

Below is a table showing the current technical architecture at CCBRT. Since this

will be a long-term project, the current technical architecture may change in the

coming year.

Technology Current technical environment

Server DELL POWEREDGE R520 32GB RAM,2T HHD, DUAL Xeon® E5‐2640 2.50GHz Processor.

Server operating system Windows Server 2008 R

Client Operating system Windows 7, Windows XP

Databases SQL, MS ACCESS, MYSQL

Workstation DELL, HP PC

Communication email, Intranet, telephone

Internet Browser Mozilla Firefox, Internet Explorer

2.4.3 Average volumes of transactions per day

Functional Area Average Volumes Outpatients Eye Standard 300 Eye Private 60 Ortho Standard 100 Ortho Private 10

VVF 10 Surgeries Eye 35 Ortho/reconstructive 10 VVF 4

3 CRITERIA FOR EVALUATION CCBRT will evaluate the responses to this RFI based on the vendor:

1. Understanding and responsiveness to CCBRT requirements: This refers to the

Consultant’s understanding of CCBRT IHMS high-level business, functional and

technical requirements as detailed in this RFI, and the nature and scope of the work

involved.

2. Organizational expertise: This refers to respondents’ ability to demonstrate expertise

and functionality as evident by client references the firm may hold.

3. Implementation consultant’s experience: the experience of the vendor should be

demonstrated through the references and explanation of similar projects, to that of

the one being implemented by CCBRT.

4. Training and support: provide a high level of customer service and technical support,

both pre-installation and post-installation to clients as evidenced by references.

3.1 RFI SCHEDULE

RFI key dates are as follows:

15 Aug 2013 RFI made available to interested vendors

13 Sep 2013, 23:59 GMT + 3 Deadline for receiving responses to the RFI.

14 Sep 2013 – 01 Oct 2013 The evaluation of the RFI responses takes place.

11 Oct 2013 The project office will communicate to vendors as to whether their RFI responses are successful.

3.2 RFI RELATED QUESTIONS / CLARIFICATIONS / SUBMISSION

The Project Office shall be accepting requests for clarification from vendors. All questions received and responses will be through the following channel.

[email protected]

Solution vendors are expected to submit their responses as an electronic document ideally in Adobe PDF format (but not scanned images of the document) at the following email address before the RFI closing date, September 13th in accordance with all terms and submission guidelines contained herein.

[email protected]

All RFI submissions must be received by September 13th (by 23:59 GMT). Receipt of all submissions and files will be confirmed via email. Please note that the project office will

not be liable for any technical issues that may hinder the vendor’s submission of the RFI responses.

If the documents are larger than 8MB, please submit split zip files with a maximum of 8 MB for each file.

3.3 RFI TERMS & CONDITIONS

Information submitted to Project Management Office as part of this Request for Information will not be publicly disclosed and will be used by CCBRT and its designees during the RFI evaluation period.

This RFI is only a request for information about potential products / services and no contractual obligation on behalf of CCBRT whatsoever shall arise from the RFI process.

This RFI does not commit CCBRT to pay any cost incurred in the preparation or submission of any response to the RFI.

4 RFI REQUIREMENTS

4.1 GENERAL REQUIREMENTS

1.0 GENERAL REQUIREMENTS MATRIX Vendor Response Codes:

S = Standard Functionality ("Out-of-the-Box")

M = Modification Required

C = Custom Report/Inquiry N = Cannot Meet Requirement T = Third-Party component

Ref No: General Requirements

Vendor response Comments

1.1 Organisational 1.1.1 Describe organisation's sites where the supply,

installation and commissioning of the IHMS has been done (name at least three). Refer to section 5.2

Confirm and reference the Document Section and Page Section ______________________ Page ______________________

1.1.2

Describe at least three sites where annual support and maintenance of the IHMS has been done in the last 5 years


1.1.3 Specify what the current version of your software is and list of sites where that version is currently in use

1.1.4 How many employees in your company specialize in the specific IHMS solution proposed?

1.1.5 Summarize your implementation methodology and delivery strategy for IHMS solutions.(Please limit response to 1 page )


1.1.6 Summarize your approach to data conversion. Confirm and reference the Document Section and Page Section ______________________ Page ______________________

1.1.7 Tax compliance certificate (or its equivalent) that is valid in accordance with any legally recognized jurisdiction


1.1.8 Certificate of registration (or its equivalent) that is valid in accordance with any legally recognized jurisdiction


1.2 Training Services 1.2.1 Describe training methods and venues available for

the IHMS product. Confirm and reference the

Document Section and Page Section ______________________ Page ______________________

1.2.2 Describe the IHMS training offerings for the IHMS end users.


1.2.3 Describe the IHMS training offerings for the technical support employees.


1.2.4 Describe your knowledge transfer methodology. (Please limit to one page)


1.3 Support and Enhancements Response 1.3.1 Provide an overview of your IHMS software support

capabilities Confirm and reference the


1.3.2 Summarize how you choose to implement enhancements and release builds


1.3.3 Summarize your processes and tools used for handling implementation, as well as production issues.

Confirm and reference the Document Section and Page

Section ______________________ Page ______________________

1.4 After sale support service 1.4.1 Describe the annual maintenance and after sales

support service for the proposed IHMS Confirm and reference the


1.4.2 Describe the turnaround time to be given for the various nature of problems ranging from critical, to urgent, to non-critical


1.5 Costing 1.5.1 Please provide an estimate of the total costs of your

product with regard to the requirement of this RFI. Confirm and reference the


1.5.2 Please provide the estimated licensing costs of the solution per module


1.5.3 Are new releases chargeable separately? Confirm and reference the Document Section and Page Section ______________________ Page ______________________

1.5.4 Provide the estimated consultancy rates to for implementation staff


1.5.5 What rates do you charge for customization? Confirm and reference the Document Section and Page Section ______________________ Page ______________________

1.5.6 Provide the estimated training cost of about 400 employees, 40 of which are super users.


1.5.7 What are the estimated maintenance and support costs? Please give a breakdown.


4.2 HIGH LEVEL BUSINESS REQUIRMENTS

2.0 FUNCTIONAL REQUIREMENTS MATRIX Vendor Response Codes:

S = Standard Function ("Out-of-the-Box") M = Modification Required

C = Custom Report/Inquiry N = Cannot Meet Requirement T = Third-Party

Ref No:

Business Requirements Application Functions (Capabilities)

Vendor Response Comments

2.0 Patient Profile

2.1.1 Ability to manage patient’s service request based

on queuing theory and issue visiting patient with a ticket.

2.1.2 Ability to search individual and determine if individual is a new/returning patient using e.g. but not limited to, unique reference number, names, NHIF number, insurance number etc.

2.1.3 Ability to create a new patient profile with a medical record number assigned to it.

2.1.4 Ability to apply different rules when registering a new patient, when viewing the patient information, during selection of appropriate insurance coverage for the patient account / encounter, identification and collection of any patient missing account level information and when selecting services offered by CCBRT.

2.1.5 Ability to integrate with record management system and be able to support the creation, editing and viewing of patient records while still ensuring patient confidentiality (e.g. but not limited to, restrictions on view based on security and privacy level, ability to update)

2.1.6 Ability to capture and process patients insurance/NHIF eligibility and response transaction

2.1.7 Ability to generate unique identification cards for patients.

2.1.8 Ability to attach/convert multiple patients to a single account (e.g. merge, un-merge, delete)

2.1.9 Ability to check for duplicate patients based on user-defined criteria (e.g., social security number, alphabetic similarity, phone number, etc.).

Ref No:



2.1.10 Ability to integrate to patient appointment schedule to capture the patient type (inpatient/outpatient), date, time, consulting doctor and the service.

2.1.11 Ability to integrate to service order processing, billing and collection to manage the presales, sales and patient after sales activities.

2.2

Service Order Processing, Billing and Collection 2.2.1 Ability to define and maintain a service catalogue,

and assign auto generated services codes to services provided within CCBRT.

2.2.2 Ability to support the generation of Service Orders by patient registration and service points workflows such as, but not limited to, Clinics, Wards, OT, Production, etc.

2.2.3 Ability to bill services as per billing counters depending upon the category of the patient, (i.e. general, insured, patient referral, staff, etc.). This is while applying rule based logic of services e.g. determine if certain services or patients will have outstanding balances, or can have their balances written off/debited automatically or collection of payments before processing of order the concerned department.

2.2.4 Ability to integrate to the payment system and payer systems for validation of data related to insurance, bank and patient demographics.

2.2.5 Ability of the system to support rules processing to ensure patient billing validation based on, but not limited to, patient demographics and ensure that all charges are generated

2.2.6 Ability to integrate the billing and collection workflows to the general ledger and cash deposit processes.

2.2.7 Ability to support multiple modes of payment e.g. but not limited to, cash, debit/ credit card, cheques etc.

2.2.8 Ability to integrate with mobile money service providers e.g. ( MPESA) and banking industry

2.2.9 Ability to support an automated charge capture from the different services administered and resources consumed against a service order e.g. clinical documents(X-Ray, lab reports ), surgery, pharmacy, rehabilitation

2.2.10 Ability to support cost estimations to allow point of service billing and patient cash collection (e.g. hospital, physician, or other services related to the patients care plan)

2.2.11 Ability to generate and issue profoma invoices, receipts based on the CCBRT rules since some services are free of charge depending on certain criteria e.g. demographic data of the patient

2.2.12 Ability to support different modes of capturing insurance details.

2.2.13 Provision for follow up with Insurance companies and mobile payment service providers against a patient claim.

2.2.14 Status enquiry of the submitted claims

Ref No:



2.2.15 Ability to integrate with other modules for discharge summary and other details

2.2.16 Provision to bill the patient separately for the services provided by the hospital that are not covered by the Insurance companies.

2.3 Scheduling

2.3.1 Ability to allow affected departments within CCBRT to pull scheduled list of patient cases they are to attend to.

2.3.2 Ability to integrate to records management system 2.3.3 Ability to handle unscheduled patients and/or same-

day patients 2.3.4 Ability to generate patient calendar appointments of

the past, present and future. 2.3.5 Ability to automatically track, alert, and cancel

expired appointment dates. 2.3.6 Ability to support the definition, executions and

interoperability to of rules processing to insure the required tests are scheduled, performed, and resulted.

2.3.7 Ability to support different service workflows and approvals

2.3.8 Ability to print booking confirmation, issue pre-requisite medical requirements and send alerts to patient.

2.3.9 Ability to integrate to service order processing, billing and collection for advance booking of services e.g. surgery.

2.3.10 Ability to provide a seamless integration to patient profile

2.3.11 Ability to send patients and CCBRT staff notifications and reminders using various communication channels (e.g. PDA, e-mail, cell phone, etc.)

2.3.12 Ability to support validation and verification of patient consent before booking of certain services e.g. surgery

2.3.13 Ability to book a patient and dynamically schedule the required resources on need base as per case specific user input e.g. authorized persons can select the name of doctor, day, estimated time for consultation etc

2.3.14 Ability to maintain a schedule for the patient's Physiotherapy sessions

2.3.15 Ability to match patient appointments dates and CCBRT medical staff personal calendars

2.4 Records management

2.4.1 Ability to add, index, retrieve attach clinical related documents to the appropriate patient account

2.4.2 Ability to store, index, retrieve photo images

2.4.3 Ability to support electronic signatures

2.4.4 Ability to convert paper documents to electronic records.

2.4.5 Ability to support electronic record creation of all documents and case information through scanning

Ref No:



and linkage to case and/or individual.

2.4.6 Ability to track and assess that the users have taken action and the type of action taken on submitted information has been addressed.

2.5 Referral management process

2.5.1 Ability to support clinical system interoperability for automatic transfer of clinical documentation to the specialist

2.5.2 Ability to generate and print an E-referral form

2.5.3 Ability to support order entry system interoperability

2.5.4 Ability to support automatic notification to the referred specialist via multiple modes

2.5.5 Ability to integrate to service order processing workflows for the different services offered by CCBRT

2.5.6 Ability to integrate to patient profile and records management to be able to identify and evaluate patient

2.5.7 Ability to centrally make a service order from a list of ambulance services and advise on the patient situation and what equipments are required

2.5.8 Ability to alert referral hospital of an incoming patient.

2.6 Check-out

2.6.1 Ability to provide interoperability with a

standardized charge master

2.6.2 Ability to provide a detailed cost statement for the completed services rendered to patient

2.6.3 Ability to view prior patient accounts / encounters with outstanding balances

2.6.4 Ability to provide printed documents and forms at check-out

2.6.5 Ability to provide real time access to scheduling

2.6.6 Ability to provide payer interoperability in the financial system to determine deductible amount met

2.7 Discharge planning

2.7.1 Ability to support discharge planning and case management

2.7.2 Ability to create work list based upon pre-defined workflows

2.7.3 Ability to consolidate request from different wards according to different categories

2.7.4 Ability to perform a status change of the account from inpatient to outpatient automatically based on the cancelled procedure so it can be billed for appropriate services provided

2.7.5 Ability to request for funds from finance to cater for CCBRT post treatment services e.g. transport

2.7.6 Ability to integrate to financial accounting and management accounting for the posting of finance related data

Ref No:



2.7.7 Ability to support different service discharge workflows and approvals

2.8 Bed management

2.8.1 Ability to queue patients for most appropriate bed based on patient status and prioritization of patients waiting for a bed

2.8.2 Utilize the bed management function across all locations to identify the appropriate bed based upon patient and physician preference, and acuity

2.8.3 Interoperability with nursing acuity systems

2.9 Finance

2.9.1 Financial applications meet Generally Accepted Accounting Principles (GAAP) and International Finance Standards. Financial internal controls comply with Accounting and Financial Reporting best practice standards

2.9.2 Provides all procedural functions of a donor fund accounting system on a modified accrual basis of accounting, including proprietary (enterprise and internal), and fiduciary fund types and account groups (general long-term debt and fixed assets).

2.9.3 Ability to provide for the maintenance of separate funds, each of which is a self-balancing set of accounts by fund and resource, with all fund/resource records processed simultaneously by the common system.

2.9.4 All transactions, whether posted manually or automatically, update both the general and subsidiary ledgers immediately and reflect a real time cash position.

2.9.5 Ability to support cash entries and must automatically map the appropriate cash entry to balance the transaction

2.9.6 Ability to verify that each transaction type posted has a posting date that is correct for the current fiscal month and year. The system allows for the correction of entry dates when needed with the proper authority.

2.9.7 Ability to support control of month and year cut-offs and provide means for altering transaction dates for new and still unprocessed entries at both the national and district level with proper authority

2.9.8 Ability to verify/add valid account codes during transaction entry without having to leave the journal, budget transfer or cash deposit currently in progress.

2.9.9 Ability to support an audit trail maintained on all activities on all accounts including time and user identification.

2.9.10 Automatically posts revenue entries and offsetting cash entries to the general ledger when deposit is approved.

2.9.11 Ability to support the creation of budgets and enforce budget controls

2.9.12 Ability to integrated business process for financial accounting, purchasing, receiving, and vendor maintenance. This is to insure integrity of payment

Ref No:



records.

2.9.13 Ability to integrate the vendor master files with, but not limited to purchasing/requisition, receiving, accounts payable, material management.

2.9.14 Ability to do automatic reconciliation between cash book, bank statements, and insurance statements via statements being provided in a standard file format

2.9.15 Ability to generate accounts payable cheques when required or specific period.

2.9.16 Ability to support claw backs, refunds and reversals

2.9.17 System provides for billing statement and invoice generation with the ability to produce multiple statements

2.10.1 Procurement

2.10.1 Ability to create, process and turn departmental and case based requisitions to purchase orders within the system.

2.10.2 Ability to interface completely with the general ledger, accounts payable, receiving and stores modules.

2.10.3 Ability to supports a complete workflow process from the requisition state to the final purchase order. Must contain date and time stamp for change/approval capability.

2.10.4 Ability to provide a simple messaging system within the module for internal requests regarding requisition/purchasing items.

2.10.5 Ability to provide tables and menus that contain standard information that can be tailored to each line of business unique need such as a unit of measure table, receiving location table and requester table. The lines of business include, but not limited to, physiotherapy, eye clinic, rehab centre, maternity etc

2.10.6 Allows for the attachment of scanned or electronic backup to either requisitions or purchase orders

2.10.7 Ability to support the processing of stock, non-stock, multi-delivery, direct ship and blanket requisitions from a local or remote site within the system.

2.10.8 Ability to track, date, and time stamp (received, accepted, returned, re-received) requisitions with notes and comments.

2.10.9 Provides real time account and budget verification and an option to override when necessary and approved.

2.10.10 Ability of the system to provide full lifecycle support for all contract management functionality from the online Request for quotation/proposal stage, vendor responses and evaluation online, awarding of Tenders through predefined templates, drafting of contracts online and publishing for reviews, on line approvals, provide repository for all contracts, accessibility for references in purchase orders, alerts for expiries and provision extensions.

Ref No:



2.10.11 Ability to match vendor invoice, purchase order and purchase order receipt for both partial and final receipts automatically.

2.11 Inventory Management

2.11.1 Must support process and approval workflows

2.11.2 Provides the capability to track, receive, and disburse and backorder inventory supplies from multiple warehouse types and integrate all transactions with the purchasing, budgeting, production and financial systems.

2.11.3 Ability to track inventory by item description, stock location, unit of measure, unit cost, calculated average price, vendor number, quantity on hand, quantity received on orders, ordered/received year to date and issued to date.

2.11.4 Ability to establish, maintain, adjust and delete inventory stock item records in real time.

2.11.5 Provide picking slip report to serve as picking slip, receiving document, and accounting log to reduce paperwork and errors.

2.11.6 Ability to calculate inventory by actual cost, moving average, LIFO, FIFO and replacement values

2.11.7 Ability to integrate to other modules to be able to receive requisitions for patient related materials e.g. medicine

2.11.8 Ability to track expired inventory items and handle the disposal

2.11.9 Allows multiple receiving documents for a single purchase order.

2.11.10 Allows receiving by line item or by entire purchase order.

2.11.11 Allows receipt to multiple warehouses.

2.11.12 Ability of to create and manage unlimited number of CCBRT stores.

2.11.13 Ability of the system to allow be able match a goods receipt against the LPO the goods were procured with

2.12 Manufacturing/Production of Goods

2.12.1 Ability to support order related in-house production of, but not limited to, artificial limbs, orthopaedic braces, eye glasses, etc.

2.12.2 Ability to seamlessly integrate to procurement, stores, sales and distribution, and finance.

2.12.3 Ability to generate a production order linked to a

sales order by selecting the different CCBRT elements that make up a production order e.g. but not limited to, payment rules, production schedule, material components, production cost etc

Ref No:



2.12.4 Ability to support CCBRT production order processing which includes identification of pending production orders, material withdrawal, production, closing of production order, goods receipt by stores, settlement and good issued to patient.

2.12.5 Ability of the system to track order status during the manufacturing lifecycle.

2.12.6 Ability to track the status and notes during production order processing in the manufacturing lifecycle.

2.12.7 Ability of the system to integrate with patient scheduling plan for follow up pre/revisits

2.12.8 Ability to centrally create and manage CCBRT production related data e.g. material requirements, the bill of material, operations related information carried out etc

2.12.9 Ability to report broken items referencing an order in the manufacturing cycle.

2.12.10 Ability to integrate with or contains an optical module, which captures lens specific measurements and refraction prescriptions

2.13 Dietary (Food & Beverage) Management

2.13.1 Ability to seamlessly integrate to finance and post food cost as per ward/ cost centre.

2.13.2 Ability to integrate to patient registration and nurses’ workbench.

2.13.3 Ability to generate and issue index coupons sequentially

2.13.4 Ability to integrate to patient registration to link coupon to patient number, and verify that coupon usage while still admitted. This prevents patients from giving food coupons to other patient's caregivers.

2.13.5 Ability to create, update and support a food catalogue

2.13.6 Ability to generate an order for the kitchen providing a list of items to be prepared for each day, based on the requirements of the patient.

2.14.7 Creation of a meal plan for the kitchen by the dietician in the system for breakfast, lunch and dinner for any given period as per the requirements of patients.

2.14 Housekeeping /Laundry Management

2.14.1 Ability to scheduling the cleaning and collection of items sent to laundry from various areas of a hospital.

2.14.2 Ability to assign nurses in charge for specific housekeeping activities

2.14.3 Ability to schedule maintenance activities of cleaning equipments.

2.14.4 Ability to integrated with the finance and stores department to maintain the required stock and bill external laundry company based in the number of pieces received and monitor linen that was sent out and still pending.

Ref No:



2.14.5 Ability to define and monitor the change schedule of linen used by the In-patient department.

2.14.6 Ability to maintaining the count of incoming and outgoing laundry items by raising and monitoring laundry issue and receipt

2.14.7 Quality indicators provided for cleanliness.

2.14.8 Real time updates of cleaning orders from various departments.

2.14.9 Ability to create report on Laundry pending (what was submitted from the ward but not yet returned post cleaning)

2.15 Ward management

2.15.1 Bed state report should be standard report showing patients (per patient and with summary numbers per ward) per ward, including name, diagnosis, bed number, gender, age, etc. Should be based on date when patient leaves, not just medical discharge date.

2.15.2 System should allow for 2 patients per bed after authorization by in-charge.

2.15.3 Ability to transfer patients between wards (different beds in eye and ortho ward for example)

2.15.4 Ability to integrate to doctors and nurses workbench to monitor, track and flag patient related procedures carried out by nurses.

2.15.5 Ability to integrate to laundry management to maintain a schedule of cleaning activities carried out in the ward.

2.15.6 Ability to integrate to record management to facilitate the view/access, and update patient observation chart.

2.16 Operation Theatres Management

2.16.1 Ability to track, in each surgical case, when/if pre-anesthesia procedure was complicated, since this is a KPI.

2.16.2 Ability to track turnaround timeframes/theatre usage in the system as a KPI. This includes, time of start of anesthesia, end of anesthesia, duration of patient prep time for surgery, patient ready for surgery time, first surgical incision time, end of surgery tie and patient out time.

2.16.3 Ability to track complications related to anesthesia in a reportable way (dropdown of major causes and an "Other" reason with free-text?)

2.16.4 Ability to alert staff for example, but not limited to, patient with previous complication during surgery.

2.16.5 Ability to integrate to the record management

system, patient registration, service order management, finance, patient schedule to view and validate patient based on the different set of rules for a planned surgery.

2.16.6 Ability to define and maintain a comprehensive WHO checklists for monitoring pre/post surgical procedures e.g. anesthesia checklist, items used during surgery, surgery findings, procedures performed, post operation treatment

Ref No:



2.16.7 Ability to integrate with service order processing, billing and collection rules processing to ensure that all charges are generated and collection of payments before performing surgery

2.16.8 Ability to postpone or cancel surgical procedure processes to insure appropriate billing still occurs based on security rights.

2.16.9 Ability to perform a status change of the account from inpatient to outpatient automatically based on the cancelled procedure so it can be billed for appropriate services provided

2.16.10 Ability to ensure that appropriate billing occurs for cancelled surgical procedures

2.16.11 Ability to integrate to blood management to request for blood

2.16.12 Ability to integrate to service order processing, billing and collection to retrieve patient payment records and to automatically capture surgery consumables

2.16.13 Ability to track patient status and transfer patient status automatically from outpatient to inpatient after surgery

2.16.14 Ability to integrate to the nurses and doctors work bench for pre-operation prep and operational workflow procedures and approvals

2.16.15 Ability to integrate to patient profile and service order processing, billing and collection for the booking of surgery and other related resources e.g. equipment.

2.16.16 Ability to track the pattern of improvement of the patients

2.16.17 Ability to integrate to inventory to track usage of stock and bill the patient/ cost centre

2.17 Pharmacy Management

2.17.1 Ability of the system to automatically trigger transfer request based on maximum stocks at point of use at predefined intervals(weekly, monthly)

2.17.2 Ability of the system to integrate with inventory management to support stock transfer and transfer posting as per the requisitions

2.17.3 Ability or the system to maintain a comprehensive list of available drugs updated whenever there is change.

2.17.4 Ability of support online requisition and approvals by doctors and nurses for drug orders from the main store.

2.17.5 Ability to provide a list of alternative drugs to a prescribed drug that is not in stock.

2.17.6 Deducting the stock depending on their batch nos., mfg. dates, exp. Dates

2.17.7 Ability to integrate to procurement module to support the purchase of drugs not in stock.

2.17.8 Ability to integrate with service order workflows, billing and collection rules processing to ensure that all charges are generated and collection of payments before dispensing drug

2.17.9 Ability to view, monitor and track the issuing of drugs to patient with reference to an electronic prescription.

Ref No:



2.17.10 Ability to report on drugs prescribed to patients against the dispensed drugs in order to reserve for patients or allow patients to source the drugs elsewhere

2.17.11 Ability to integrate and update patient profile as per drugs consumed

2.18 Nurses work bench

2.18.1 Ability to integrated to patient scheduling management in order to call patient from the queue system and be able to

2.18.2 Ability to integrate to record management to attach patient document results

2.18.3 Ability to add notes and be able to flag case criteria based on risk statistics

2.18.4 Ability to integrate to record management to attach patient document results

2.19 Doctors work bench

2.19.1 Ability to access record management for patient VA results and history and be able to add doctors notes

2.19.2 Ability to integrate to the referral management system to be able to refer patient to other doctors and CCBRT services for further evaluation e.g. lab diagnostic tests, surgery

2.19.3 Ability to integrate to pharmacy management to be able to create and post E-prescription

2.20.0 Lab/ X-ray management

2.20.1 Ability to capture test result values, differentiated on screen & on printouts and assign to patient profile

2.20.2 Ability to integrate to service order processing, billing and collection module to ensure patient has paid.

2.21 Physiotherapy and Rehabilitation

2.21.1 Ability to integrate to manufacturing module to post the detailed requirements of the type of appliance patient needs, measurements etc.

2.21.2 Ability of the system to integrate to scheduling module to maintain a schedule for the patient's Physiotherapy sessions

2.21.3 Ability to integrate to record management module to provide patient related documents

2.21.4 Ability to maintain a schedule of activities to be performed by patient at home

2.21.5 Ability to manage the referrals by a surgeon for post operative rehabilitation

2.21.6 Ability to track the pattern of improvement of the patients

2.21.7 Ability to integrate to service order processing, billing and collection to validate patient has paid

2.21.8 Ability to integrate with inventory management and manufacturing to capture electronic signatures for goods issued and delivered to patient

Ref No:



2.21.9 Ability to integrate to discharge planning and check out to manage standard and private patients

2.21.10 Provides a schedule of exercises to be performed a home

2.21.11 Manages the referrals by a surgeon for post operative rehabilitation

2.21.12 Ability to support CCBRT physiotherapy and rehabilitation workflows and approvals

2.22 Community Programs

2.22.1 Ability to integrate with the patient master db

2.22.2 Ability to track attendance at weekly meetings, progress of patients, and to measure the percentage of patients referred to CP who actually attend

2.22.3 Ability to integrate with SMS capability to alert patients as to milestones and appointments

2.22.4 Ability to enter manual unique identifiers, along with system generated ones

2.22.5 Ability to remotely log into CP module from handheld device (iPad, external computer, etc.) or through a web portal

2.23 Maternity

2.23.1 Ability to provide seamless integration with other hospital systems e.g. but not limited to pharmacy, pathology, ultrasound, pediatrics, theatres and anesthetics

2.23.1 Ability to provide antenatal and neonatal screening functionality with data reporting on whether the screening was offered, accepted, declined and outcome

2.23.2 Ability to generate antenatal and intrapartum alerts on the baby which should be flagged up during labor and on neonatal entry with prompts for follow ups

2.23.3 Ability to support recording of multiple births in different situations e.g. two separate birth events.

2.23.4 Ability to support Pre-eclampsia/eclampsia assessment and treatment

2.23.5 Ability to support elective induction and caesarean procedures

2.23.6 Ability to integrate with the IHMS for antenatal admissions

2.23.7 Ability to integrate to discharge planning for electronic discharge summaries.

2.23.8 Ability to maintain a central birth register

2.23.9 Ability to define and assign patients to personalized maternity care plan depending on the medical history

Ref No:



2.23.10 Ability to record and report on details relative to the provision of breast feeding support services, including: Lactation consultants, Attendance at clinics

2.23.11 Ability to record and report on location of care details relative to the model of care for postnatal care for the newborn.

2.23.12 Ability to record and report on planned and actual key care providers for postnatal services that includes referral to medical and paramedical staff.

2.23.13

Ability to integrate with discharge planning to record and report on planned and actual discharge date and discharge location for the newborn.

2.23.14 Ability to integrate to discharge planning to record and report on planned and actual discharge date and discharge location for the mother.

2.23.15 Ability to integrate to patient profile to capture new born/neonatal information.

2.23.16 Ability to capture and report on: Postnatal (pre-discharge information) Maternal complications Maternal mortality rate Maternal interventions Maternal infant feeding Lactation / breastfeeding issues term

2.23.17 Ability to capture and report on: Neonatal mortality rate Neonatal morbidity Congenital abnormalities Neonatal interventions

2.23.18 Ability to record and report on the labour & birth, decisions made, and interventions, specifically: History of previous pregnancy History medical/surgical Gestation at delivery Onset of labour Complications in first stage labour Interventions in first stage labour Complications in second stage labour Interventions in second stage labour Complications in third stage labour Interventions in third stage labour Mode of birth (normal, assisted, caesarean

section) Post partum – morbidity

2.23.20 Ability to record and report on appropriate counselling & support requirements for: HIV/Hep C Antenatal Screening\Diagnostic tests Miscarriage Discharge Planning

Ref No:



Smoking Breastfeeding Substance Abuse

2.23.21 Displays patient alerts for risk management relevant to a pregnancy (e.g. previous caesarean sections, diabetes mellitus)

2.24 Reporting

2.24.1 Ability to report at summary levels as well as detailed down to a specific patient, visit or consumable

2.24.2 Ability for manager and advanced staff to run their own reports, or modify parameters of a pre-set report

4.3 OVERVIEW OF INFORMATION SECURITY REQUIREMENTS AND PRIVACY PROTECTION

3. 0

Information Security Requirements and Privacy Protection Requirement Matrix

Vendor Response Codes:

S = Standard Function ("Out-of-the-Box")

M = Modification Required

C = Custom Report/Inquiry N = Cannot Meet Requirement T = Third-Party

Ref No: Business Requirements


3.1 Data Protection

3.1.1 Ability of the systems to secure sensitive

data in transit (including, but not limited to e-mail, financial data etc.) that requires confidentiality protection when traversing entity boundaries.

3.1.2 Ability to protect individually identifiable health information with reasonable administrative, technical, and physical safeguards. This is to ensure its confidentiality, integrity, and availability and to prevent unauthorized or inappropriate access, use, or disclosure.

3.1.3 Ability to follow and protect data throughout the data security lifecycle i.e. in all 6 phases of data lifecycle, create, store, use, share, and archive and destroy.

3.1.4 Ability to provide data protection and other security devices for smart phones, tablet computers and other emerging non-tradition platforms.

3.1.5 Provides the appropriate controls to ensure data (e.g., structured database, unstructured files) is adequately secured and protected.

3.2 Application Security,

3.2.1 Ability to support audit trails to ensure accountability and non-repudiation, ensuring that the organization can trace actions on the system back to the responsible individuals.

3.2.2 Ability to provide the appropriate controls to ensure applications (e.g., web, thin client, mobile) used to access data and other resources is adequately secured and protected.

3.2.3 Ability to enforces a boundary around the application code, configuration, and data to prevent tampering, unauthorized access, or data leakage

Ref No: Business Requirements


3.3 Platform Security

3.3.1 Ability to secures and protects the runtime components necessary for a subject to interact with resources and/or data.

3.3.2 Ability to provide the appropriate controls to ensure client devices (e.g., laptop, virtual workstation, and mobile platforms) used to access data is adequately secured and protected.

3.3.3 Ability to ensure applications, operating systems, processes and software components adhere to security principles and practices throughout the development lifecycle.

3.4 Access Control,

3.4.1 Ability to define and manage the data required to track, authenticate, and authorize a subject's (e.g., person, application, device) access to one or more resources (e.g., client, host, network, application).

3.4.2 Ability of the system to support identity proofing by provide a minimum set of administrative controls and requirements for identity proofing (validating that users are who they say they are) and for the periodic management of authenticators.

3.4.3 Ability to define and assign user roles, to ensure that users only have access to data that is needed to get the job done and nothing more (least privilege).

3.4.4 Ability of the system to increase complexity of authentication as the sensitivity of the system and data increases as per CCBRT Privacy Rule’s requirements for verification of identity and authority in an electronic health information exchange environment.

4.4 OVERVIEW OF TECHNICAL ARCHITECTURE

The solution vendors should provide an overview of the recommended technical architecture and infrastructure required to run their systems

Technology Current technical environment

Server

Server operating system

Client Operating system

Databases

Workstation

Communication

Internet Browser

5 RESPONSE FORMAT

5.1 COMPANY PROFILE FORMAT

COMPANY PROFILE DETAILS

Name of company Registered

Trading Name

Year the company was founded

No of technical employees

Areas of expertise 1.

2,

3.

4.

Area of expertise relevant to this RFI and number of years of experience No of yrs

1.

2.

3.

4.

5.

5.2 PROJECT REFERENCES

Assignment name:

Approx. value of the contract (in current US$ or Euro):

Country:

Location within country:

Duration of assignment (months):

Name of Client:

Total No of staff-months of the assignment:

Address:

Approx. value of the services provided by your firm under the contract (in current US$ or Euro):

Start date (month/year):

Completion date (month/year):

No of professional staff-months provided by associated Consultants:

Name of associated Consultants, if any:

Name of senior professional staff of your firm involved and functions performed (indicate most significant profiles such as Project Director/Coordinator, Team Leader):

Narrative description of Project:

Description of actual services provided by your staff within the assignment:

ccbrt request for information - global tenders · pharmacy departments use sap b1. we plan for the...

Documents