Drug Control System tender.pdf · • Developer 6i • Power Designer • Power Builder • Office...
24
Drug Control System -- Converted from Word to PDF for free by Fast PDF -- www.fastpdf.com --
Transcript of Drug Control System tender.pdf · • Developer 6i • Power Designer • Power Builder • Office...
Drug Control System
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
1
- - - - - - - -
PROPOSED PROJECT DESCRIPTION AND FUNCTIONALITIES - TECHNICAL SPECIFICATIONS - TRAINING REQUIREMENTS -
- -
- -- -- -- -- -- INSTRUCTIONS TO OFFERORS
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
2
1- 1-1-
•
• •
1-2-
• • • • • • • • • • • –– •
1-3-
-
1-4-
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
3
1-5-
-
• • LAN • •
- • • • • • • • •
-
• Oracle 9i • Developer 6i • Power Designer • Power Builder • Office 2000 • Windows XP • AIX operating system for risk machines
• UNIX FOR NCR
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
4
- --
–
Data warehouse, OLAP Data mining
-- • • • • • • • • • Smart CardBar-code
-- • • • paperless organization • • • • •
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
5
-
3.1 PROPOSED PROJECT DESCRIPTION AND FUNCTIONALITIES
The proposed system should include 9 modules to fulfill the HIO requirements the enclosed modules are:
1. Drug Formulary Book Module
2. Drug Acquisition Module
3. Drug Dispense Module
4. Stock Control and Management Module
5. Customer Care Module
6. Vendor Accounting Module
7. System Control Module
8. Online Help Module
9. Decision Support Module
1. DRUG FORMULARY BOOK MODULE This Module is concerned with building and maintaining the drug list and all related lists such as:
• Drug groups
• Drug Interaction
• Drug Generic name
• Drug form
• Drug substitution
Enable users to make on-line query about:
• Generic-trade names
• Drug -drug interaction
• Drug-Diagnosis
• Drug substitution
• Drug-Vendors
• Drug-Groups effects.
2. Drug Acquisition Module Drug Acquisition Module is concerned with all system functions related to the following process:
• Drug and medical supplies requirements prediction.
• Acquisition procedures of drug and medical supplies
• Supplying drug and medical supplies to drug stores
The drug acquisition module is concerned with reviewing the previous dispensing rates and forecast needs in
future for each pharmacy; the pharmacies needs will be aggregated in total annual plan. The tender process will
take place until the needs delivery, the system typical functions are:
• Prepare pharmacy requirement
• Collect pharmacy requirement
• Review pharmacy requirement
• Prepare HIO requirement
• Prepare terms of references Award
• Create purchase order
• Prepare payment sheet
3. Drug Dispense Module
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
6
Drug Dispense Module is concerned with dispensing the drug in all levels until the drug reaches to the end
point of cycle .It consists of three components:
• Dispensing drug from drug store to pharmacy
• Dispensing drug from pharmacy to patient
• Dispensing drug from pharmacy to medical section in hospital
Dispensing drug from drug store to pharmacy
• An electronic requirements sheet should be available to collect the pharmacies requirements.
• The sheet will be forwarded to the store which will tack the necessary procedures for preparing
the approved quantities and shipping it to the pharmacy.
Dispensing drug from drug pharmacy to patient
• Clinic physician enter prescription from data to the system.
• Pharmacist query prescription to dispense it.
• Pharmacist issues the external prescription if needed.
• Pharmacist run End-of-day, End-of-month and End-of-year job periodically
Dispensing drug from drug pharmacy to medical section
• Nurse enter the section requirement from prescribed drugs to the system
• Pharmacist receives the requests electronically
• Pharmacist keeper prepares the drugs of each request upon receiving.
• System alerts the different sections upon shipment preparation
• System re adjust the drug balance.
4. Stock Control and Management Module Stock Control and Management Module should handle but not limited to the following functions:
• Entering transaction order
• Keep track of current balance
• Handling re-order level
• Handling stagnate balances
• Preparing stocktaking lists
• Entering the actual balance
• Handling end-of-year procedures
• The stock control module should comply with FIFO principle and zero stock methodology.
Enter ing transaction order
• Storekeeper or pharmacist enters transaction order.
• System updates the stock balance automatically.
• Update and Delete should be restricted to certain users with approval procedures, all these
transactions should be frozen before End-of-year work.
Keep track of current balance
• System updates each item balance references to each transaction.
• Storekeeper or pharmacist queries about drug balance.
• System alerts the operator for reorder level.
Handling re-orders level
• System issues statistics about the stagnate balances.
• System handles re-order level and update it continuously
• System notify user when item is reached to Re-order-level
Prepar ing stocktaking lists
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
7
• System prepare stocktaking sheets automatically including book balances
• User query stocktaking sheets and enter actual balances.
• System computes for over balance and lower balance items.
• User prints final stocktaking sheets including book and actual balances.
5. Customer Care Module
Customer care module is concerned with customer satisfaction, the module encloses a set of e-functions to
support the HIO beneficiaries, the module functions will include but not limited to:
• Home delivery
• Electronic payment
• Claims handling
• Useful links and notification
Home delivery Service
Health Insurance Organization (HIO) is looking forward to provide drug at home in regard with service
improvement for some categories of customer unless it will affect dispensing rules
Electronic payment
It handles the electronic payments through internet, card machines at pharmacy, using Visa or other credit cards to
facilitate customer payments.
Claims handling
Hio with its developed services has a special interest with the customer claims, the system should provide its users
with mechanisms for gathering, studying and solving the customer clains.
Useful links and notif ication
System provide also sum links to invoke to useful sites and redirect customer to take a health culture
6. Vendor Accounting Module
Vendor Accounting Module is a very necessary module to
• Keep track of vendors and manufactures information.
• Review payable sheets.
• Prepare payment sheets
• Maintains vendors black list.
7. SYSTEM CONTROL MODULE
This application is concerned with security rules handling the user account (user authentication, User available
Options, security policies, privileges-responsibility, for each user and usage rules), in addition the module
monitors the DB access and the different data transactions, the system should generate a set of log files to track the
important transactions, these will be defined through the analysis phase of the project
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
8
8. Online Help Module We believe that such type of system (web based system) should support its users with full training facilities to get
familiar with the system functions, and should support the technical staff to be capable to deal with the system
perfectly, the on line help module will provide:
• Intelligent search wizard full search (simple and compound) facilities.
• Online troubleshooting wizard
• Computer based training (CBT) on drug control system
Notifications about useful video conference to discuss the new features or holding online training. 9. Decision Support Module
DSS Module should provide management staff with a specialized problem solving expertise stored as facts,
rules, procedures, or in similar structure, the DSS module should include but not limited to the following
functions:
• Support for decision makers in semi structured and unstructured problems.
• Support managers at all levels.
• Support individuals and groups.
• Support for interdependent or sequential decisions.
• Support variety of decision processes and styles.
• DSS should be adaptable and flexible.
• DSS should be interactive and provide ease of use.
• Effectiveness balanced with efficiency (benefit must exceed cost).
• Complete control by decision-makers.
• Ease of development by (modification to suit needs and changing environment) end users.
• Support modeling and analysis.
• Data access.
• Standalone, integration and Web-based.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
9
3-2. TECHNICAL SPECIFICATIONS
3-2-1. REQUIRED HOSTING SITE TECHNICAL SPECIFICATIONS
The required infrastructure items are essential for the development and hosting. It is required to ensure that the
infrastructure is housed in a well-protected and continuously operational environment. This hardware will be
housed in a data center of Internet Service Provider (ISP).
The ISP is required to have a data center with the following specifications:
• Environment:
• HVAC (heating, ventilation, air-conditioning) compliant
• Electric power 220-240 v with full UPS support and redundant power supplies
• Temperature control
• Fire alarm and fighting
• 24x7 Building Security and Monitor Services
• Access Doors Security
• Communications and Connectivity
• Minimum Internet communication line speed 1 Mbps dedicated to drug control system it is strongly
recommended to have dual 512 Kbps from two different ISPs
• Data transfer rate (for 1 Mbps leased line) not less than 30 Kbps for ADSL 512 Kbps client in case of
downloads
• Total Internet bandwidth capacity for the ISP is 40 Mbps
• IT System Security and Protection
• Firewalls or security appliances
• Intrusion detection and prevention system
• Web application protection
• Virus protection
• Data protection and security
• Disaster recovery site availability
• Administration and Management
• Full infrastructure (e.g., network, security, servers, etc.) management and monitoring
• Daily backup procedures
• Off-site backup procedures
• Software applications fixes, upgrades, and updates
• Technical support
• Help desk for operation management by 24x7x365
HIO technical staff will handle the data management and updates, and drug control applications support (in
coordination with the system integrator staff).
The Offeror is required to provide the data center technical specifications that will be proposed for hosting drug
control System.
3-3. TRAINING REQUIREMENTS
The Offeror shall send a proposal for a training plan that includes programs in the following areas.
• RDBMS Engine Administration
• Email Server Administration
• Software to be developed including content management for the web server
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
10
These training programs are for forty three (34) persons two (2) from each HIO branch, two (2) from HIO head
quarter and four (4) from CDIS.
The Offeror should include the following training programs/materials within the proposal.
• Online training materials for Internet users. Prepare online guides and FAQ section for
Internet users to assist them in using the online facilities of drug control system.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
11
-
-- :00
–
-
-- ---
- --- - CD
MS WORD
--- - --- - CD
MS WORD
---
--
• •
--- • infrastructure
–––
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
12
--
ISP
---
---
1-
• • •
. ISP
ISP 2-
.
.
3-
•
4-
---
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
13
. Source CodeSource Code
.
. Gab Analysis and Design
Document Deployment Plan Project Status Reports User's Manual Executive User's Manual Operation and Administration Manual
.
.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
14
--
4-3-5-1. TECHNICAL PROPOSAL SKELETON
It is mandatory for the Offeror to prepare their proposal in accordance with the outline mentioned in
this section. Each Offeror is required to submit the technical proposal in a sealed package. Proposals
shall be prepared as simply as possible and provide a straightforward, concise description of the
Offeror’s capabilities to satisfy the requirements of this RFP. Utmost attention shall be given to
accuracy, completeness, and clarity of content. All sections, pages, figures, and tables should be
numbered and clearly labeled. The proposal should be organized into the following major sections.
Proposal Section
Title Page
Letter of Transmittal
Table of Contents
1. Executive Summary
2. Company Background
3. Scope of Services
4. Proposed ISP Data Center Specifications
5. Proposed Infrastructure and Computing Environment
6. Proposed Software Applications
7. Proposed Third-Party Products/Optional Software
8. Project Implementation Plan
9. Training Plan
10. Change Management
11. Warranty, Maintenance and Support
12. Acceptance Testing
13. Required Attachments
Executive Summary (Technical Proposal Section 1.0)
This section of the response to the RFP should be limited to a brief narrative summarizing the Offeror’s
proposal. The summary should include a technical overview (at a summary level only) for
infrastructure, software development, and IT services. Please note that the Executive Summary should
identify the primary engagement contact for the software vendor, the contact for the implementation
services firm, if different, and the contact for any third-party software being proposed. Contact
information should include a valid e-mail address and a telephone number.
Company Background (Technical Proposal Section 2.0)
Each proposal must provide the following information about the submitting Offeror’ s company, the
implementation partner’s company, and any third-party vendor being proposed to provide a business
function so that the evaluation of the Offeror’s stability and ability to support the commitments set
forth in response to the RFP can be properly assessed. The Offeror Background information should
include:
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
15
• How long the company has been in business.
• A brief description of the company’s size and organizational structure.
• How long the company has been developing software applications similar to that in health care
projects.
• Listing of installations at entities similar to the HIO by name and locations.
• Any material (including letters of support or endorsement from clients) indicative of the
Offeror’s capabilities.
• If partnering, how long the system integrator has worked with the software development
vendor and the ISP, and how many implementations these parties have completed together.
• Copies of Egyptian Commercial Register Authority (CRA) certificates, any business licenses,
professional certifications, or other credentials.
Scope of Services (Technical Proposal Section 3.0)
This section of the Offeror’ s proposal should include a general discussion of the understanding of the
“overall” project and the scope of work proposed. The response must clearly describe the
infrastructure, software products, and IT services that are necessary to meet the requirements
mentioned before. The response also must confirm that the proposal includes all of the software
development work effort necessary to implement the software products or modules included in the
proposal.
Proposed Internet Service Provider Data Center Specifications (Technical Proposal Section 4.0)
The Offeror shall provide the technical specifications for the ISP data center which will host the drug
control project systems. These specifications shall include, but not limited to:
• HVAC
• Electricity
• Fire alarm and Fire-fighting
• Building security
• Software maintenance and warranty
• Networks
• Communications and Internet connectivity
• IT security
• Failover and disaster recovery
• Backup
• Customer support
Proposed Infrastructure and Computing Environment (Technical Proposal Section 5.0)
The Offeror shall provide the technical specifications of the following items associated with a clear
network and servers’ schematic diagram.
A. Hardware Environment: Describe the optimal hardware configuration required to utilize the
proposed software. In the event there is more than one suitable hardware platform, list all options
indicating the relative strengths and drawbacks, if any, of each. Identify the optimal server and desktop
requirements including the required number of servers and how they are distributed.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
16
B. Network Environment: Describe the ideal network environment required to utilize the proposed
software. In the event that there is more than one suitable network configuration, and list all options,
including the relative strengths and weaknesses, if any, of each.
C. Software Development Platform: Describe the primary software development technology and the
tools that will be used in developing the drug control applications. Also, indicate whether underlying
code is generic or platform-specific. What application toolsets are included with the software? What
programming languages and skills are required to maintain the software? What tools are available to
customize the software (e.g., add fields, create new tables, change menus, etc.)?
D. Database Platform: Provide the ideal database platform choices for the proposed software. In the
event that there is more than one suitable database platform, please list all options, including the
relative strengths and drawbacks, if any, of each. What is the required experience utilizing both the
database and other technical areas?
E. Email Platform: Describe the Electronic Mail Platform that will be used within the E-BT software
applications.
F. Web Based Architecture: The proposed drug control software applications will be a “web-based.”
application. Discuss the limitations on the functionality available to the end-user.
G. Administration/Monitor ing: What administration and monitoring tools and tasks are routinely
required for optimal system performance (e.g., monitoring of audit files)?
I . Secur ity: What security tools are included within the software? How are the following restrictions
accomplished: administrative tool access; application access; menu access; record access; field access;
and querying/reporting access? How is the security profile defined? What is included in the user
security profile?
Proposed Software Applications (Technical Proposal Section 6.0)
The Offeror must present, in detail, features and capabilities of the proposed software applications.
This presentation must include software architectures and integration with e-payment mechanisms. In
addition to the description, the Offeror must consider the following factors:
• Technology and System-Wide Features
• Multilingual and Arabic-language Support
• Document/Record Management and Workflow, if necessary, or integration with ECM if exist.
• Automatic Upgrade Capability
• Reporting and Analysis Tools (i.e., Business Intelligence)
• E-Payment Mechanisms Integration
• Modular Integration with any other software modules
• The software development methodology including the quality assurance
• The requested deliverables mentioned before
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
17
Proposed Third-Par ty Products/Optional Services (Technical Proposal Section 7.0)
The Offeror shall explicitly state the name of any third-party products or services that are part of the
proposed solution. Proposals must describe any products, features, or other value-added components
and services recommended for use with the proposed administrative system that have not been
specifically requested in this RFP.
The Offeror should also provide proof that it has access to the third-party support and services and that
the Offeror has the ability to provide long-term support for the third-party software components of its
system. Consideration of these products, features, or other value-added components will be given
where they may be of value to the drug control Project. Offerors must include the cost of any third-
party products, including the software license cost, maintenance, implementation, training cost, and any
other related costs in the total cost of this proposal.
Project Plan (Technical Proposal Section 8.0)
The Offeror must provide an initial plan for implementing the proposed system. This information must
include:
• Detailed methodology for implementing enterprise software. Methodology shall include estimated
timeframe, overview of phases and milestones, assumptions, and assumed responsibilities.
• Detailed methodology for implementing third-party software, if applicable. Methodology shall
include estimated timeframe, overview of phases and milestones, assumptions, and assumed
responsibilities. Time plans (Work Breakdown Structure) may be submitted in Excel Format or
preferable in Microsoft Project Format.
• Explain how each of the following types of testing has been addressed in your implementation plan:
a) module testing;
b) integration testing;
c) parallel testing; and
d) stress/load testing.
• Names, titles, and resumes of project team likely to be assigned to this project.
• Deliverables and milestones.
Training Plan (Technical Proposal Section 9.0)
The drug control system has requested training for both software administrations for HIO technical
staff and software applications for HIO users. The Offeror must provide a detailed plan for training.
This information must include:
• An overview of proposed training plan/strategy, including options for on-site or off-site training
services, for the core project team, end-users, and technology personnel.
• The role and responsibility of the software and/or the system integrator in the design and
implementation of the training plan (e.g., development of customized training materials, delivering
training to HIO users).
• The knowledge transfer strategy proposed by the software and/or implementation vendor to
prepare HIO staff to maintain the system after it is placed into production.
• Descriptions of classes/courses and training materials proposed in the training plan. The Offeror
should specify the unit of measure for its training (e.g., units, classes, days, etc.) and define the hours
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
18
associated with these units of measure. The Offeror must be very clear about exactly what training
courses are included in the cost of the proposal and whether the training is certified by the software
vendor or other parties.
Change Management (Technical Proposal Section 10.0)
The Offeror should describe their overall change management plan. Offerors should describe what
aspects of change management are included in the proposal.
Warranty, Maintenance, and Suppor t (Technical Proposal Section 11.0)
The proposal must specify the nature of any post-implementation and ongoing support provided by the
vendor, including:
• Post-implementation support.
• Telephone support (e.g., include toll-free support hotline, hours of operation, availability of
24/7 hotline, etc.).
• Special plans defining “ levels” of customer support (e.g., gold, silver, etc.). Define what level of
support is being proposed.
• Delivery method of future related technology upgrades and product enhancements, including
historical frequency of upgrades by module.
• Availability of user groups, in general, and public sector user groups, in particular, and their
geographic areas.
• Problem-reporting, resolution, and escalation procedures.
• Bug fixes and patches.
• Support provided for third-party solutions.
• Other support (e.g., on-site, remote dial-in, website access to patches, fixes, and knowledge
base).
• If there is to be a separate maintenance contract, the vendor should attach the form of such
contract.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
19
Acceptance Testing Cr iter ia (Technical Proposal Section 12.0)
Specific mutually agreeable criteria for successful system operation will be established during the
contract negotiation process, taking into account the drug control’s functional specifications and the
system integrator’ s own software documentation. The selected offeror will be required to participate
with appropriate domain expert personnel in testing the functionality of the proposed system to
ascertain conformance with the acceptance criteria before the HIO will accept the system. Offerors
should detail their approach to acceptance testing and what criteria were generally used to signify
acceptance at previous engagements.
Explain how each of the following types of testing has been addressed in your implementation plan:
a) module testing;
b) integration testing; and
c) stress/load testing.
Also, explain any anticipated parallel testing that will be part of the overall implementation
process.
Required Attachments (Proposal Section 13.0)
To establish a complete and competitive proposal, Offerors must include the following attachments in a
hard-copy and electronic formats.
• Proposed Team Structure
• Team Members Resumes
• Functional Requirements List
• Exceptions to the Specifications
• Project Plan
• Software Development Methodology
Offerors should include sample copies of the following documents.
• Sample software licensing agreement
• Sample implementation service level agreement
• Sample selected standard reports (Arabic and English)
• Sample documentations (analysis document, design document, user requirements and user guides,
training materials, etc.)
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
20
4-3-5-2. FINANCIAL PROPOSAL SKELETON
Offerors shall prepare their financial proposals in accordance to the outline mentioned in this section.
Each Offeror is required to submit the financial proposal in a sealed package. Proposals should be
prepared as simply as possible and provide a straightforward, concise description of the Offeror’s
capabilities to satisfy the requirements of the RFP. Utmost attention should be given to accuracy,
completeness, and clarity of content. All sections, pages, figures, and tables should be numbered and
clearly labeled. The proposal should be organized into the following major sections.
Proposal Section
Title Page
Letter of Transmittal
Table of Contents
1. Executive Summary
2. Scope of Services
3. Cost Proposal
4. Required Attachments
Instructions relative to each part of the response to this RFP are defined in the remainder of this
section.
Executive Summary (Financial Proposal Section 1.0)
This part of the response to the RFP should be limited to a brief narrative summarizing the Offeror’s
proposal. The summary should contain as little technical jargon as possible and should be oriented
toward non-technical personnel. This section should include cost quotations, at a summary level only,
for software and services totals at most. Please note that the Executive Summary should identify the
primary engagement contact for the software vendor, the contact for the implementation services firm,
if different, and the contact for any third-party software being proposed. Contact information should
include a valid e-mail address and telephone number for the person responsible for the financial and
technical proposals.
Scope of Services (Financial Proposal Section 2.0)
This section of the vendor’s proposal should include the list of the scope of services where the financial
proposals will cover.
Cost Proposal (Financial Proposal Section 3.0)
Offerors should submit an estimate of project costs. Offerors estimate costs for all categories with the
understanding that they may have to make assumptions. Such assumptions should be stated. Failure to
fully provide cost and work effort estimates may lead to elimination prior to the presentations.
Required Attachments (Financial Proposal Section 4.0)
To establish a complete and competitive proposal, Offerors must include Cost Proposal Spreadsheet
(Attachment-B) as an attachment in a hard-copy and electronic formats.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
21
5. INSTRUCTIONS TO OFFERORS
1. OFFEROR DEADLINES
The following timetable is provided to assist bidders. The dates for each phases’ deliverables indicate
expectations only. The final acceptance date is highly recommended, while any other dates will be
under discussion and close review.
RFP Advertised
Available and send to the bidder
Submission of questions (electronic submissions only)
Hosts bidders’ conference
Final RFP responses due
Estimated award date
Sign the contract
SUBMITTAL OF QUESTIONS
All Questions regarding this RFP must be submitted by / / . Questions shall only
be accepted via e-mail.
E-Mail Questions to:
E. Khalil Radwan,
Mrs. Sohila A. Hamid
Mr. Mamdouh A. Kader
Subject: Drug control RFP Question
SUBMITTAL OF RESPONSE TO RFP DUE DATE AND TIME
All submittals must be received by close of business 12:00 Cairo, Egypt time, on / /
.Deliver one (1) Or iginal Response to RFP and two (2) copies to:
HIO-MIS center, 20, El-Ahram St. 2nd floor
Helioplis, Cairo
E. Khalil Radwan,
Mrs. Sohila A. Hamid
Mr. Mamdouh A. Kader
Please mark:
RESPONSE to Drug control Technical Proposal and, in a separate envelope,
RESPONSE to Drug control Financial Proposal
IMPORTANT: All pricing information must be quoted in Egyptian Pounds
E-mail electronic copy of the Technical Proposal only to:
E. Khalil Radwan,
Mrs. Sohila A. Hamid
Mr. Mamdouh A. Kader
Subject: Drug control RFP Response- Technical Proposal
Faxed Submittals Will Not Be Accepted.
Late Submittals Will Not Be Accepted.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
22
If you have any problems receiving or opening the electronic documents, please contact:
E. Khalil Radwan,
Mrs. Sohila A. Hamid
Mr. Mamdouh A. Kader
Cairo, Egypt
Telephone: +20 2 4525038
All days 8:30am – 5:00pm
2. REPLY TO
All correspondence regarding this RFP offer must addressed as follows:
E. Khalil Radwan,
Mrs. Sohila A. Hamid
Mr. Mamdouh A. Kader
Drug Control System
HIO-CDIS center, 20, El-Ahram St. 2nd floor
Helioplis, Cairo
Correspondence must be marked: “Drug control RFP”
Electronic submissions for QUESTIONS ONLY should be submitted to:
And must contain: Questions re: Drug control RFP
A complete offer must include all of the above. Offerors are required to complete and submit one (1)
or iginal and two (2) copies of their offer. A person duly authorized to do so must sign each copy of
the offer in blue ink. Offers submitted by corporations must bear the seal of the corporation. The person
signing the offer must initial any changes to the offer
.
3. DESCRIPTIVE LITERATURE
Descriptive literature for offered equipment is recommended. Descriptive literature means information
(e.g., cuts, illustrations, drawings, and brochures) that is submitted as part of an offer.
4. OFFEROR’S ORGANIZATION, EXPERIENCE, AND ABILITY
The Offeror must present a description of the Offeror’s company and organization, with appropriate
reference to parent and subsidiaries, and a demonstration of the Offeror’ s experience and ability in
selling and servicing the goods and services listed in the commodity schedules. Include also the name
of the firm that will carry out the installation and servicing of the systems in Egypt, as well as a
description of the firm’s experience and ability. This information should be included in a separate
section of the proposal entitled “Offerors Organization, Experience, and Ability.”
5. VALIDITY PERIOD
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
23
Offers must remain valid for not less than ninety (90) calendar days after the offer deadline. All
required HIO approvals relevant to this procurement are anticipated to occur as scheduled. Should there
be any delay, an extension of the offer validity may be requested.
6. PERFORMANCE BOND
Within fifteen (15) days of the receipt of notification of award from HIO, the successful Offeror shall
furnish a Letter of Credit for 5% of the total contract value ensuring full completion of the contract.
Failure to submit a Letter of Credit may void the contract
7. SOFTWARE/MANUALS
For any off-the-shelf software packages supplied under this RFP (including the operating systems),
Offerors must supply the latest version available on the market, unless otherwise indicated. All
software is to be accompanied with appropriate media and manuals. Software and manual language
must be English, unless otherwise specified.
8. BASIS FOR AWARD (EVALUATION CRITERIA)
Awards will be made to a responsible offeror whose offer follows the RFP instructions, meets the
technical specifications, meets the origin requirements, and is judged to be most advantageous to HIO
in terms of cost, quality, experience, and delivery. In judging the offers, the award criteria will be
weighted as follows:
Company Profile 10%
Technical staff experience, responsiveness and quality 15 %
Previous similar projects experience for the company 15%
Selected ISP experience 10%
Technical Solution 40%
Delivery Time 10%
Total 100%
The bidder must pass 80% for each of “Company Profile” and “Selected ISP Experience” criteria.
Also, the bidder must pass 75% for the total technical evaluation to be qualified for the financial
evaluation. Each successful bidder who passes the technical evaluation will be asked for a presentation
about the proposed technical solution before the financial evaluation starts. The disqualified bidders
who do not pass the technical evaluation will not be asked for this presentation.
-- C
onve
rted
from
Wor
d to
PD
F fo
r fr
ee b
y F
ast P
DF
--
ww
w.fa
stpd
f.com
--
