i
BIDDING DOCUMENT
(SINGLE-STAGE)
Issued on: September 3, 2015
Delivery
of Health Information Systems for
health facilities of the RK
IFB №: KHSTTIRP-D/SW-03- rebidding
Project: Kazakhstan Health Sector Technology Transfer
and Institutional Reform Project
Purchaser: Ministry of Healthcare and Social
Development of the Republic of Kazakhstan
ASTANA 2015
CONTENTS
Invitation for Bids (IFB) ..........................................................................................................1
Section I. Instructions to Bidders (ITB)................................................................................6
Table of Clauses ...................................................................................................................6
Section II. Bid Data Sheet (BDS) .........................................................................................37
Section III. Eligible Countries for the Provision of Goods, Works, and Services in
Bank-Financed Procurement ..................................................................................................5
Section IV. General Conditions of Contract.........................................................................6
Section V. Special Conditions of Contract (SCC) ..............................................................79
Section VI. Technical requirements ..................................................................................102
Section VII. Sample Forms ................................................................................................483
Notes to Bidders on working with the Sample Forms .....................................................483
Table of Sample Forms ....................................................................................................486
INVITATION FOR BIDS (IFB)
Republic of Kazakhstan
Kazakhstan Health Sector Technology Transfer and
Institutional Reform Project
Unified Health Information Management System
Loan 4883 –KZ
Delivery of Health Information Systems for health facilities of the RK
IFB No. KHSTTIRP-D/SW-03 – rebidding
1.
This Invitation for Bids (IFB) follows the General Procurement Notice (GPN) for this
Project that appeared in UN Development Business online № 2633470 as of June 02,
2008.
2.
The Republic of Kazakhstan has received a loan from the International Bank for
Reconstruction and Development toward the cost of Kazakhstan Health Sector
Technology Transfer and Institutional Reform Project, and it intends to apply part of
the proceeds of this loan to payments under the contract resulting from this IFB:
Delivery of Health Information Systems for health facilities of the RK, Contract No.
KHSTTIRP-D/SW-03-rebidding, includes the following lots:
Lot № 1 «Delivery and implementation of Comprehensive Health Information System
for Municipal hospital №1 Ust-Kamenogorsk city»;
Lot № 2 «Delivery and implementation of Comprehensive Health Information System
for Municipal Clinic Hospital №4 Almaty city»;
Lot № 3 «Delivery and implementation of Comprehensive Health Information System
for Mother and Child Center Ust-Kamenogorsk city»;
Lot № 4 «Delivery and implementation of Comprehensive Health Information System
for Municipal Policlinic №11 Almaty city»;
Lot № 5 «Delivery and implementation of Comprehensive Health Information System
for Regional Diagnostic Center Almaty city»;
Lot № 6 «Delivery and implementation of Comprehensive Health Information System
for Policlinic №1 Kostanay»;
Lot № 7 «Delivery and implementation of Comprehensive Health Information System
for Central rayon hospital, Zhualynsky rayon, Zhambul oblast»;
Lot № 8 «Delivery and implementation of Comprehensive Health Information System
for Municipal policlinic №7 Astana city»;
Lot № 9 «Delivery and implementation of Comprehensive Health Information System
for Municipal Hospital No. 1 of Astana city»;
Lot № 10 «Health Information System for accounting donors and recipients».
Bidders have the option to bid for any one or more lots. Bids will be evaluated lotwise, taking into account discounts offered for each lot separately or combination of
lots, if any. The contract(s) will be awarded to the Bidder or Bidders offering the
lowest evaluated cost to the Purchaser for combined lots, subject to the selected
Bidder(s) meeting the required qualification criteria for lot or combination of lots as
the case may be. The Purchaser shall award not more than three lots to one bidder
even if the bidder is lowest and qualified.
If the Bid of one or several Bidders receives the lowest evaluated cost for more than
three lots then the criteria for selection of lots for the Purchaser shall be the best from
the Purchaser’s point of view combination of total cost of all awarded lots.
3.
The Ministry of Healthcare and Social Development of the Republic of Kazakhstan
serves as the implementing agency for the Kazakhstan Health Sector Technology
Transfer and Institutional Reform Project and now invites sealed bids from eligible
Bidders for the supply, installation and commissioning of Health Information Systems
for health facilities of the RK. Supply, installation and commissioning period for
abovementioned is 54 weeks.
4.
Bidding will be conducted using International Competitive Bidding (ICB) procedures
specified in the World Bank’s Guidelines: Procurement under IBRD Loans and IDA
Credits, edition of May 2004, Revised Oct 2006 and May 2010, and is open to all
Bidders eligible as defined in these Guidelines, that meet the following minimum key
qualification criteria:
(a)
The Bidder shall furnish documentary evidence that it meets the following financial
requirement(s):
-
The average annual turnover in USD or equivalent the most recent three (3)
(2012, 2013 and 2014) years:
-
at least US$1,500,000.00 (one million five hundred thousand) for Lot № 1
«Delivery and implementation of Comprehensive Health Information System
for Municipal hospital №1 Ust-Kamenogorsk city»;
-
at least US$1,000,000.00 (one million ) for Lot № 2 «Delivery and
implementation of Comprehensive Health Information System for Municipal
Clinic Hospital №4 Almaty city»;
-
at least US$2,000,000.00 (two million) for Lot № 3 «Delivery and
implementation of Comprehensive Health Information System for Mother and
Child Center Ust-Kamenogorsk city»;
-
at least US$1,000,000.00 (one million) for Lot № 4 «Delivery and
implementation of Comprehensive Health Information System for Municipal
Policlinic №11 Almaty city»;
-
at least US$1,000,000.00 (one million) for Lot № 5 «Delivery and
implementation of Comprehensive Health Information System for Regional
Diagnostic Center Almaty city»;
-
at least US$1,000,000.00 (one million) for Lot № 6 «Delivery and
implementation of Comprehensive Health Information System for Policlinic
№1 Kostanay»;
-
at least US$1,000,000.00 (one million) for Lot № 7 «Delivery and
implementation of Comprehensive Health Information System for Central
rayon hospital, Zhualynsky rayon, Zhambul oblast»;
-
at least US$1,000,000.00 (one million) for Lot № 8 «Delivery and
implementation of Comprehensive Health Information System for Municipal
policlinic №7 Astana city»;
-
at least US$1,000,000.00 (one million) for Lot № 9 «Delivery and
implementation of Comprehensive Health Information System for Municipal
Hospital No. 1 of Astana city»;
-
at least US$1,500,000.00 (one million five hundred thousand) for Lot № 10
«Medical information system for registration of donors, recipients and
individuals waiting for transplantation»
Average Annual Turnover requirements should be consistently applied for all
lots.
Where the Bidder is a Joint Venture the sum of all Partners' average turnover
amounts may be used. Also, where the Bidder is a Joint Venture the Partner in
charge must have had an average annual turnover equivalent to at least half of
the amount required for the most recent three (3) years, while every other
partners – at least 10 % out of total required amount.
The Bidder should provide audited financial statements and balance sheets (or
some other documents according to legislation of Bidder’s country) for the last
three (3) completed fiscal years demonstrating the soundness of the Bidder’s
financial position and available resources necessary to handle the requirements of
the proposed Contract.
If the bidder wishes to qualify for award of contract for more than one lot then the
bidder must demonstrate having required annual average turnover to meet the
aggregate of the qualifying criteria for the individual lots.
(b) Experience and Technical Capacity
The Bidder shall furnish documentary evidence (including information about the
completed contracts and contact information of clients from whom the references
could be taken or whom the Purchaser may, when necessary, visit to learn the systems
put into operation by the Bidder) to demonstrate that it meets the following
requirements to experience:
i. the Bidder should have been operating at minimum for 5 years with the basic
activity being delivery and implementation of Information Systems for health
facilities.
ii. the Manufacturer(s) of Software shall have at least one certificate out of the
following list: Capability Maturity Model Integration (CMMI) Maturity Level 3,
ISO 9000 or ST RK ISO 9001:2009, or similar for quality management process.
(The Bidder shall provide copy of certificate for compliance issued by authorized
agency).
iii. the Bidder shall have experience in training end-users and IT specialists.
iv. the Bidder shall have proven experience in design of similar projects: at least 5
health facilities currently use systems designed and implemented by the Bidder
(the scale of these health facilities shall be preferably correspondent to that of
health facilities – beneficiaries under this Bidding or exceed it). “Proven” means
Page 3
presentation of contracts, addresses, letters and other documents capable to
confirm the use (and outcomes) of the System required under the Contract.
v. The Bidder shall have own team of experts with the experience of
implementation of similar projects. the Bidder shall present the Table containing
the List of Staff with their CV to prove their experience and expertise. Detailed
requirements to the team are set in Section VI «Technical Requirements» in item
R10.4 for lots 1-9 and R11.4 for lot 10. The Bidder should provide two sets of
CVs to win two lots and three sets of CVs to win three lots.
vi. the Bidder shall forward all documents confirming the origin of all components
and products including Manufacturer’s Authorization to use these products within
this Contract or confirmation on ownership of the rights for the products (patent or
any other documents) including Intellectual Property rights and other relevant
rights.
vii.
the Bidders (or JV members) shall have proven experience of work
with one or several standards used herein: HL7 v2, v3, FHIR, CDA (R2). IHE.
5.
Interested eligible Bidders may obtain further information from the Ministry of Health
and Social Development of the Republic of Kazakhstan - Department for Investment
Projects and PPP Development, Project Implementation Support Team and inspect the
bidding documents at the address given below: Astana, Imanova 19, floor 5, office
504 during office hours from 09:00-12:30 and 13:30-18:00., from Monday to Friday,
except public holidays.
6.
The Bidders will receive a complete set of bidding documents in English upon
submission of the written application to the Project Implementation Support Team by
the address: Astana, Imanova 19, office 504 during office hours from 09:00-12:30 and
13:30-18:00, from Monday to Friday, except public holidays. As an alternative, the set
of bidding document in PDF and WORD format may be sent to interested Bidders upon
submission of a written application to the Project Implementation Support Team by
email: kazhealth.procurement@gmail.com.
Complete set of Bidding Document could be downloaded in English (Word and PDF
file) from Project web-site: healthproject.kz upon registration.
The clarifications and amendments shall also be published in this website and also sent to
the bidders by EM.
If there is discrepancy between Word and PDF file, the PDF file will prevail.
Besides interested Bidders can get complete set of Bidding Document in Russian in
Word. In case of discrepancies between the English and Russian versions of the
documents, the English version shall prevail.
7.
Bids must be delivered to the address below at or before 15:30, on October 15, 2015.
The amount of Bid Security required is:
- 20 000 USD for Lot № 1 «Delivery and implementation of Comprehensive Health
Information System for Municipal hospital №1 Ust-Kamenogorsk city»;
- 10 000 USD for Lot № 2 «Delivery and implementation of Comprehensive Health
Information System for Municipal Clinic Hospital №4 Almaty city»;
- 30 000 USD for Lot № 3 «Delivery and implementation of Comprehensive Health
Information System for Mother and Child Center of Ust-Kamenogorsk city»;
- 10 000 USD for Lot № 4 «Delivery and implementation of Comprehensive Health
Information System for Municipal Policlinic №11 Almaty city»;
- 10 000 USD for Lot № 5 «Delivery and implementation of Comprehensive Health
Information System for Regional Diagnostic Center Almaty city»;
- 10 000 USD for Lot № 6 «Delivery and implementation of Comprehensive Health
Information System for Policlinic №1 Kostanay»;
-15000 USD for Lot № 7 «Delivery and implementation of Comprehensive Health
Information System for Central rayon hospital, Zhualynsky rayon, Zhambul oblast»;
- 10 000 USD for Lot № 8 «Delivery and implementation of Comprehensive Health
Information System for Municipal policlinic №7 Astana city»;
- 10 000 USD for Lot № 9 «Delivery and implementation of Comprehensive Health
Information System for Municipal Hospital No. 1 of Astana city»;
- 20 000 USD for Lot № 10 « Medical information system for registration of donors,
recipients and individuals waiting for transplantation ».
Late bids will be rejected. Bids will be opened in the presence of Bidders’
representatives who choose to attend the procedure by the address set below at 15:30,
on October 15, 2015.
8.
The attention of prospective Bidders is drawn to (i) the fact that they will be required
to certify in their bids that all software is either covered by a valid license or was
produced by the Bidder, and (ii) violation of this condition is considered as fraud,
which can result in ineligibility to be awarded by World Bank-financed contracts.
Ministry of Healthcare and Social Development of the Republic of Kazakhstan
Department for Investment Projects and PPP Development,
Project Implementation Support Team
B. Tokezhanov – National Project Coordinator
010000, Kazakhstan, Astana city, Imanov Str. 19, floor 5, office 504,
tel. + 7 7172 787235, fax. + 7172 787247
e-mail: kazhealth.procurement@gmail.com
Page 5
SECTION I. INSTRUCTIONS TO BIDDERS (ITB)
(Single-Stage Bidding)
Table of Clauses
A. General ............................................................................................................................... 8
1.
2.
3.
4.
5.
6.
7.
8.
Scope of Bid and Bidding Process ............................................................................. 8
Source of Funds ......................................................................................................... 8
Fraud and Corruption ................................................................................................. 8
Eligible Bidders........................................................................................................ 10
Eligible Goods and Services .................................................................................... 12
Qualifications of the Bidder ..................................................................................... 12
Cost of Bidding ........................................................................................................ 15
Site Visit................................................................................................................... 15
B. The Bidding Documents .................................................................................................. 15
9. Content of Bidding Documents................................................................................ 15
10. Clarification of Bidding Documents and Pre-bid Meeting ...................................... 16
11. Amendment of Bidding Documents ........................................................................ 16
C. Preparation of Bids ......................................................................................................... 17
12.
13.
14.
15.
16.
Language of Bid ....................................................................................................... 17
Documents Comprising the Bid ............................................................................... 17
Bid Prices ................................................................................................................. 18
Bid Currencies.......................................................................................................... 21
Documents Establishing the Conformity of the Information System to the Bidding
Documents ............................................................................................................... 21
17. Securing the Bid ....................................................................................................... 22
18. Period of Validity of Bids ........................................................................................ 24
19. Format and Signing of Bid ....................................................................................... 25
D. Submission of Bids .......................................................................................................... 25
20.
21.
22.
23.
Sealing and Marking of Bids ................................................................................... 25
Deadline for Submission of Bids ............................................................................. 26
Late Bids .................................................................................................................. 26
Withdrawal, Substitution, and Modification of Bids ............................................... 26
E. Bid Opening and Evaluation .......................................................................................... 27
24.
25.
26.
27.
28.
29.
30.
Opening of Bids by Purchaser ................................................................................. 27
Clarification of Bids ................................................................................................. 28
Preliminary Examination of Bids ............................................................................. 28
Conversion to Single Currency ................................................................................ 29
Evaluation and Comparison of Bids ........................................................................ 29
Domestic Preference ................................................................................................ 34
Contacting the Purchaser ......................................................................................... 34
F. Postqualification and Award of Contract ..................................................................... 34
31.
32.
33.
34.
Postqualification....................................................................................................... 34
Award Criteria.......................................................................................................... 34
Purchaser’s Right to Vary Quantities at Time of Award ......................................... 35
Purchaser’s Right to Accept Any Bid and to Reject Any or All Bids ..................... 35
35.
36.
37.
38.
Notification of Award ............................................................................................... 35
Signing of Contract ................................................................................................... 36
Performance Security ............................................................................................... 36
Adjudicator ............................................................................................................... 36
Page 7
Instructions to Bidders
A. GENERAL
1. Scope of Bid
and Bidding
Process
2. Source of
Funds
3. Fraud and
Corruption
1.1
The Purchaser named in the BDS and the SCC for GCC Clause
1.1 (b) (i), or its duly authorized Purchasing Agent if so
specified in the BDS (interchangeably referred to as “the
Purchaser” in these Bidding Documents), invites bids for the
supply and installation of the Information System (IS), as briefly
described in the BDS and specified in greater detail in these
Bidding Documents.
1.2
The title and identification number of the Invitation for Bids
(IFB) and resulting Contract(s) are provided in the BDS.
1.3
Throughout the Bidding Documents, the term "in writing" means
communicated in written form (e.g. by mail, e-mail, fax, telex)
with proof of receipt, and the term "days" means calendar days
unless a different meaning is evident from the context.
1.4
If the BDS so provides, alternative procedures forming part or
all of what is commonly known as e-Tendering are available to
the extent specified in, or referred to by, the BDS.
2.1
The Borrower named in the BDS has applied for or received a
loan or credit (as identified in the BDS, and called a “loan” in
these Bidding Documents) from the International Bank for
Reconstruction and Development or the International
Development Association (called “the Bank” in these Bidding
Documents) equivalent to the amount indicated in the BDS
toward the cost of the Project specified in the BDS. The
Borrower intends to apply a portion of the proceeds of this loan
to eligible payments under the Contract for which these Bidding
Documents are issued.
2.2
Payment by the Bank will be made only at the request of the
Borrower, or the Borrower’s executing agency, and upon
approval by the Bank in accordance with the terms and
conditions of the Loan Agreement, and will be subject in all
respects to the terms and conditions of that agreement. The
Loan Agreement prohibits a withdrawal from the loan account
for the purpose of any payment to persons or entities, or for any
import of goods, if such payment or import, to the knowledge of
the Bank, is prohibited by a decision of the United Nations
Security Council taken under Chapter VII of the Charter of the
United Nations. No party other than the Borrower shall derive
any rights from the Loan Agreement or have any claim to the
loan proceeds.
3.1
It is the Bank’s policy to require that Borrowers (including
beneficiaries of Bank loans), as well as bidders, suppliers, and
contractors and their subcontractors under Bank-financed
contracts, observe the highest standard of ethics during the
procurement and execution of such contracts.1 In pursuance of
this policy, the Bank:
(a)
defines, for the purposes of this provision, the terms set
forth below as follows:
(i)
“corrupt practice”2 is the offering, giving, receiving
or soliciting, directly or indirectly, of anything of
value to influence improperly the actions of another
party;
(ii)
“fraudulent practice”3 is any act or omission,
including a misrepresentation, that knowingly or
recklessly misleads, or attempts to mislead, a party
to obtain a financial or other benefit or to avoid an
obligation;
(iii) “collusive practice”4 is an arrangement between two
or more parties designed to achieve an improper
purpose, including to influence improperly the
actions of another party;
(iv) “coercive practice”5 is impairing or harming, or
threatening to impair or harm, directly or indirectly,
any party or the property of the party to influence
improperly the actions of a party;
(v)
“obstructive practice” is
(aa) deliberately destroying, falsifying, altering or
concealing of evidence material to the
investigation or making false statements to
investigators in order to materially impede a
Bank investigation into allegations of a
corrupt, fraudulent, coercive or collusive
practice; and/or threatening, harassing or
intimidating any party to prevent it from
disclosing its knowledge of matters relevant to
the investigation or from pursuing the
investigation; or
(bb) acts intended to materially impede the exercise
of the Bank’s inspection and audit rights
1
In this context, any action taken by a bidder, supplier, contractor, or a sub-contractor to influence the
procurement process or contract execution for undue advantage is improper.
2
“Another party” refers to a public official acting in relation to the procurement process or contract
execution]. In this context, “public official” includes World Bank staff and employees of other
organizations taking or reviewing procurement decisions.
3
A “party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement process
or contract execution; and the “act or omission” is intended to influence the procurement process or contract
execution.
4
“Parties” refers to participants in the procurement process (including public officials) attempting to establish
bid prices at artificial, non competitive levels.
5
A “party” refers to a participant in the procurement process or contract execution.
Page 9
provided for under sub-clause 3.1 (e) below.
4. Eligible
Bidders
(b)
will reject a proposal for award if it determines that the
bidder recommended for award has, directly or through an
agent, engaged in corrupt, fraudulent, collusive, coercive
or obstructive practices in competing for the contract in
question;
(c)
will cancel the portion of the loan allocated to a contract if
it determines at any time that representatives of the
Borrower or of a beneficiary of the loan engaged in
corrupt, fraudulent, collusive, or coercive practices during
the procurement or the execution of that contract, without
the Borrower having taken timely and appropriate action
satisfactory to the Bank to address such practices when
they occur;
(d)
will sanction a firm or individual, including declaring
ineligible, either indefinitely or for a stated period of time,
to be awarded a Bank-financed contract if it at any time
determines that the firm has, directly or through an agent,
engaged in corrupt, fraudulent, collusive, coercive or
obstructive practices in competing for, or in executing, a
Bank-financed contract; and
(e)
will have the right to require that a provision be included
in bidding documents and in contracts financed by a Bank
loan, requiring bidders, suppliers, and contractors and
their sub-contractors to permit the Bank to inspect their
accounts and records and other documents relating to the
bid submission and contract performance and to have
them audited by auditors appointed by the Bank.
3.2
Furthermore, Bidders shall be aware of the provision stated in
Clause 9.8 and Clause 41.2 of the General Conditions of Contract.
3.3
Any communications between the Bidder and the Purchaser
related to matters of alleged fraud or corruption must be made in
writing.
3.4
By signing the Bid Submission Form, the Bidder represents that
it either is the owner of the Intellectual Property Rights in the
hardware, software or materials offered, or that it has proper
authorization and/or license to offer them from the owner of
such rights. For the purpose of this Clause, Intellectual Property
Rights shall be as defined in GCC Clause 1.1 (c) (xvii). Willful
misrepresentation of these facts shall be considered a fraudulent
practice subject to the provisions of Clauses 3.1 through 3.4
above, without prejudice of other remedies that the Purchaser
may take.
4.1
A Bidder, and all parties constituting the Bidder, may have the
nationality of any country, subject to the restrictions specified in
Section III, Eligible Countries. A Bidder shall be deemed to
have the nationality of a country if the Bidder is a citizen or is
constituted, incorporated, or registered and operates in
conformity with the provisions of the laws of that country.
4.2
If a prequalification process has been undertaken for the
Contract(s) for which these Bidding Documents have been
issued, only those Bidders may participate that had been
prequalified and continue to meet the eligibility criteria of this
Clause. A prequalified Joint Venture may not change partners
or its structure when submitting a bid.
4.3
A firm may be excluded from bidding if:
(a)
it was engaged by the Purchaser to provide consulting
services for the preparation of the design, specifications, or
other documents to be used for the procurement of the
Information System described in these Bidding
Documents; or
(b)
it is a government-owned enterprise in the Borrower’s
country, unless it can establish that it (i) is legally and
financially autonomous and (ii) operates under commercial
law. No dependent agency of the Borrower or SubBorrower shall be permitted to bid.
4.4
A firm that has been determined to be ineligible by the Bank in
relation to the Bank Guidelines On Preventing and Combating
Fraud and Corruption in Projects Financed by IBRD Loans and
IDA Credits and Grants shall be not be eligible to be awarded a
contract.
4.5
A firm or individual is or will be disqualified from participation
in this bidding if, at any time from advertisement of the bidding
until and including contract award, the firm or individual is
under:
(a)
a suspension by the Purchaser agreed by the Bank as a
result of execution of a Bid-Securing Declaration pursuant
to ITB Clause 17.6 in another Bank-financed procurement,
or under a suspension by the Purchaser for other reasons
that have been agreed by the Bank; or
(b)
a declaration of ineligibility by the Bank in accordance
with ITB Clause 3.1 (d). The list of individuals and firms
debarred from participating in World Bank projects is
available at http://www.worldbank.org/debarr/, or
(c)
a sanction imposed by the United Nations Security
Council, as mentioned in ITB Clause 2.2.
4.6
A firm or other entity that is ineligible according to any of the
above provisions of this Clause, may also not participate as a
Joint Venture partner, or as Subcontractor for or supplier of
goods, works or services.
If a bid becomes materially
incomplete after removing ineligible entities, the bid may be
disqualified.
4.7
Bidders shall provide such evidence of their continued eligibility
satisfactory to the Purchaser, as the Purchaser shall reasonably
request.
Page 11
5. Eligible Goods
and Services
6. Qualifications
of the Bidder
5.1
For the purposes of these Bidding Documents, the Information
System means all:
(a)
the required information technologies, including all
information processing and communications-related
hardware, software, supplies, and consumable items that
the Supplier is required to supply and install under the
Contract, plus all associated documentation, and all other
materials and goods to be supplied, installed, integrated,
and made operational (collectively called “the Goods” in
some clauses of the ITB); and
(b)
the related software development, transportation,
insurance,
installation,
customization,
integration,
commissioning, training, technical support, maintenance,
repair, and other services necessary for proper operation of
the Information System to be provided by the selected
Bidder and as specified in the Contract.
5.2
Funds from Bank loans are disbursed only for expenditures for
an Information System made up of goods and services provided
by nationals of, and produced in or supplied from, eligible
source countries as defined in Section III, Eligible Countries.
An Information System is deemed to be produced in a certain
country when, in the territory of that country, through software
development, manufacturing, or substantial and major assembly
or integration of components, a commercially recognized
product results that is substantially different in basic
characteristics or in purpose or utility from its components.
5.3
For purposes of this clause, the nationality of the Bidder is
distinct from the country in which the Information System and
its goods components are produced or from which the related
services are supplied.
6.1
By submission of documentary evidence in its bid, the Bidder
must establish to the Purchaser’s satisfaction:
(a)
that it has the financial, technical, and production
capability necessary to perform the Contract, meets the
qualification criteria specified in the BDS, and has a
successful performance history. If a prequalification
process has been undertaken for the Contract(s) for which
these Bidding Documents have been issued, the Bidder
shall, as part of its bid, update any information submitted
with its application for prequalification;
(For the purposes of establishing a Bidder’s qualifications,
and unless stated to the contrary in the BDS, the
experience and / or resources of any Subcontractor will
not contribute to the Bidder’s qualifications; only those of
a Joint Venture partner will be considered.)
(b)
that, in the case of a Bidder offering to supply key goods
components of the Information System, as identified in
the BDS, that the Bidder does not itself produce, the
Bidder is duly authorized by the producer to supply those
components in the Purchaser’s country under the
Contract(s) that may result from this bidding; (This will be
accomplished by including Manufacturer’s Authorizations
in the bid, based on the sample found in Section VII.)
6.2
6.3
(c)
that, if a Bidder proposes Subcontractors for key services
if and as identified in the BDS, these Subcontractors
have agreed in writing to serve for the Bidder under the
Contract(s) that may result from this bidding; and
(d)
that, in the case of a Bidder not doing business within the
Purchaser’s country, the Bidder is or will be (if awarded
the Contract) represented by an Agent in that country who
is equipped and able to carry out the Bidder’s
maintenance, technical support, training, and repair
obligations prescribed in the General and Special
Conditions of Contract, and/or Technical Requirements.
Bids submitted by a Joint Venture of two or more firms as
partners shall also comply with the following requirements:
(a)
the bid shall be signed so as to be legally binding on all
partners;
(b)
one of the partners shall be nominated as being in charge,
and this nomination shall be evidenced by submitting a
power of attorney signed by legally authorized signatories
of all the partners;
(c)
the partner in charge shall be authorized to incur liabilities
and receive instructions for and on behalf of any and all
partners of the Joint Venture, and the entire execution of
the Contract, including payment, shall be done exclusively
with the partner in charge;
(d)
the partner or combination of partners that is responsible
for a specific component of the Information System must
meet the relevant minimum qualification criteria for that
component;
(e)
a firm may submit bids either as a single Bidder on its
own, or as partner in one, and only one, Joint Venture. If,
as a result of the bid opening pursuant to ITB Clause 24,
this requirement is not met, all bids involving the firm as a
single Bidder or Joint Venture partner will be disqualified;
(f)
all partners of the Joint Venture shall be liable jointly and
severally for the execution of the Contract in accordance
with the Contract terms, and a statement to this effect shall
be included in the authorization mentioned under ITB
Clause 6.2 (b) above, in the bid as well as in the Contract
(in case of a successful bid).
If a Bidder intends to subcontract major items of supply or
services, it shall include in the bid details of the name and
nationality of the proposed Subcontractor for each of those items
Page 13
and shall be responsible for ensuring that any Subcontractor
proposed complies with the requirements of ITB Clause 4, and
that any Goods or Services components of the Information
System to be provided by the Subcontractor comply with the
requirements of ITB Clause 5 and the related evidence required
by ITB Clause 13.1 (e) (iii) is submitted. Bidders are free to list
more than one Subcontractor against each item. Quoted rates
and prices will be deemed to apply, whichever Subcontractor is
appointed, and no adjustment of the rates or prices will be
permitted. The Purchaser reserves the right to delete any
proposed Subcontractor from the list. This shall be done prior to
Contract signature, by deleting such unacceptable
Subcontractors from Appendix 3 to the Contract Agreement,
which shall list the approved Subcontractors for each item prior
to Contract signature. Subsequent additions and deletions from
the list of approved Subcontractors shall be performed in
accordance with GCC Clause 20 (as revised in the SCC, if
applicable) and Appendix 3 to the Contract Agreement.
For the purposes of these Bidding Documents, a Subcontractor is
any vendor or service provider with whom the Bidder contracts
for the supply or execution of any part of the Information
System to be provided by the Bidder under the Contract (such as
the supply of major hardware, software, or other components of
the required Information Technologies specified, or the
performance of related Services, e.g., software development,
transportation,
installation,
customization,
integration,
commissioning, training, technical support, maintenance, repair,
etc.).
6.4
A firm which is a Bidder, whether as a single Bidder or as a
partner in a Joint Venture, cannot be a Subcontractor in other
bids, except for the supply of commercially available hardware
or software by the firm, as well as purely incidental services
such as installation/configuration, routine training, and ongoing
maintenance/support. If the BDS for ITB Clause 6.1 (a) allows
the qualification of Subcontractors nominated for certain
components to be taken into account in assessing the Bidder’s
overall qualifications, any Subcontractor so nominated by any
Bidder is automatically disqualified from being a Bidder itself or
a partner in a Joint Venture. The same will normally apply to
firms that have provided Subcontractor agreements for certain
services pursuant to ITB Clause 6.1 (c). Non-compliance may
result in the rejection of all bids in which the affected firm
participates as Bidder or as partner in a Joint Venture. As long
as in compliance with these provisions, or as long as unaffected
by them due to not participating as Bidder or as partner in a Joint
Venture, a firm may be proposed as a Subcontractor in any
number of bids. If the BDS for ITB 28.1 permits the submission
of bids for Subsystems, lots, or slices, then the provisions of this
Clause 6.4 apply only to bids for the same Subsystem(s), lot(s),
or slice(s);
7. Cost of
Bidding
7.1
The Bidder shall bear all costs associated with the preparation
and submission of its bid, and the Purchaser will in no case be
responsible or liable for those costs.
8. Site Visit
8.1
The Bidder may wish to visit and examine the site or sites of the
Information System and obtain for itself, at its own
responsibility and risk, all information that may be necessary for
preparing the bid and entering into the Contract. The costs of
visiting the site or sites shall be at the Bidder’s own expense.
8.2
The Purchaser will arrange for the Bidder and any of its
personnel or agents to gain access to the relevant site or sites,
provided that the Bidder gives the Purchaser adequate notice of a
proposed visit of at least fourteen (14) days. Alternatively, the
Purchaser may organize a site visit or visits concurrently with
the pre-bid meeting, as specified in the BDS for ITB Clause
10.2. Failure of a Bidder to make a site visit will not be a cause
for its disqualification.
8.3
No site visits shall be arranged or scheduled after the deadline
for the submission of the Bids and prior to the award of
Contract.
B. THE BIDDING DOCUMENTS
9. Content of
Bidding
Documents
9.1
The contents of the Bidding Documents are listed below and
should be read in conjunction with any addenda issued in
accordance with ITB Clause 11:
Section I
Instructions to Bidders (ITB)
Section II
Bid Data Sheet (BDS)
Section III
Eligible Countries for the Provision of Goods,
Works, and Services in Bank-Financed
Procurement
Section IV
General Conditions of Contract (GCC)
Section V
Special Conditions of Contract (SCC)
Section VI
Technical Requirements (including
Implementation Schedule)
Section VII
Sample Forms
9.2
Bidders are expected to examine all instructions, forms, terms,
specifications, and other information in the Bidding Documents.
Failure to furnish all information required by the Bidding
Documents or to submit a bid not substantially responsive to the
Bidding Documents in every respect will be at the Bidder’s risk
and may result in the rejection of its bid.
9.3
The Invitation for Bids is not formally part of the Bidding
Documents and is included for reference only. In case of
inconsistencies, the actual Bidding Documents shall prevail.
Page 15
10. Clarification of 10.1 A prospective Bidder requiring any clarification of the Bidding
Documents may notify the Purchaser in writing at the
Bidding
Purchaser’s address and by one of the means indicated in the
Documents
BDS. Similarly, if a Bidder feels that any important provision in
and Pre-bid
the documents will be unacceptable, such an issue should be
Meeting
raised as soon as possible. The Purchaser will respond in
writing to any request for clarification or modification of the
Bidding Documents that it receives no later than twenty-one (21)
days prior to the deadline for submission of bids prescribed by
the Purchaser. Copies of the Purchaser’s response (including an
explanation of the query but not identifying its source) will be
sent to all prospective Bidders that received the Bidding
Documents from the Purchaser.
10.2 When specified in the BDS, the Purchaser will organize and
Bidders are welcome to attend a pre-bid meeting at the time and
place indicated in the BDS. The purpose of the meeting will be
to clarify issues and answer questions on any matter that may be
raised at this stage, with particular attention to issues related to
the Technical Requirements. Bidders are requested to submit
any questions in writing to reach the Purchaser not later than one
week before the meeting. Questions and answers will be
transmitted in accordance with ITB Clause 10.1. Minutes of the
meeting, including the questions raised and responses given,
together with any responses prepared after the meeting, will be
transmitted without delay to all those that received the Bidding
Documents from the Purchaser. Any modification to the
Bidding Documents listed in ITB Clause 9.1, which may
become necessary as a result of the pre-bid meeting, shall be
made by the Purchaser exclusively by issuing an Addendum
pursuant to ITB Clause 11 and not through the minutes of the
pre-bid meeting.
11. Amendment of
Bidding
Documents
11.1 At any time prior to the deadline for submission of bids, the
Purchaser may, for any reason, whether at its own initiative or in
response to a clarification requested by a prospective Bidder,
amend the Bidding Documents. Later amendments on the same
subject modify or replace earlier ones.
11.2 Amendments will be provided in the form of Addenda to the
Bidding Documents, which will be sent in writing to all
prospective Bidders that received the Bidding Documents from
the Purchaser. Addenda will be binding on Bidders. Bidders are
required to immediately acknowledge receipt of any such
Addenda. It will be assumed that the amendments contained in
such Addenda will have been taken into account by the Bidder
in its bid.
11.3 In order to afford prospective Bidders reasonable time in which
to take the amendment into account in preparing their bids, the
Purchaser may, at its discretion, extend the deadline for the
submission of bids, in which case, the Purchaser will notify all
Bidders in writing of the extended deadline.
C. PREPARATION OF BIDS
12. Language of
Bid
12.1 The bid prepared by the Bidder and all correspondence and
documents related to the bid exchanged by the Bidder and the
Purchaser shall be written in the language specified in the BDS,
or, if the BDS so provides, in either one of two languages
specified there. Any printed literature furnished by the Bidder
as part of its bid may be in a language not specified in the BDS,
as long as such literature is accompanied by a translation of its
pertinent passages into the language of the bid, in which case,
for purposes of interpretation of the bid, the translation shall
govern.
13. Documents
Comprising
the Bid
13.1 The bid submitted by the Bidder shall comprise:
(a)
Bid Submission Form completed and signed by a person or
persons duly authorized to bind the Bidder to the Contract;
(b)
all Price Schedules duly completed in accordance with ITB
Clauses 14, 15, and 18 and signed by a person or persons
duly authorized to bind the Bidder to the Contract;
(c)
if required, Bid-securing Declaration or Bid Security
furnished in accordance with ITB Clause 17;
(d)
written confirmation authorizing the signatory of the bid to
commit the Bidder, in accordance with ITB Clause 19.2;
(e)
Attachments:
(i)
Attachment 1: Bidder’s Eligibility
In the absence of prequalification, documents
establishing to the Purchaser’s satisfaction the
Bidder’s eligibility to bid, including but not limited
to documentary evidence that the Bidder is legally
incorporated in a territory of an eligible source
country as defined under ITB Clause 4;
(ii)
Attachment 2: Bidder’s Qualifications
Documentary evidence establishing to the
Purchaser’s satisfaction, and in accordance with ITB
Clause 6, that the Bidder is qualified to perform the
Contract if its bid is accepted. In the case where
prequalification of Bidders has been undertaken, and
pursuant to ITB Clause 6.1 (a), the Bidder must
provide evidence on any changes in the information
submitted as the basis for prequalification or, if there
has been no change at all in said information, a
statement to this effect;
Any Manufacturer’s Authorizations and Subcontractor
agreements specified as required in the BDS for ITB
Clauses 6.1 (b) and 6.1 (c);
Page 17
(iii) Attachment 3: Eligibility of Goods and Services
Documents establishing, to the Purchaser’s
satisfaction, that the Goods and Services components
of the Information System to be supplied, installed,
and/or performed by the Bidder are eligible Goods
and Services as defined under ITB Clause 5. If
awarded the Contract, the Bidder shall submit for
such components of the Information System evidence
of eligibility, which shall be confirmed by a
certificate of origin issued at the time of shipment;
(iv) Attachment 4: Conformity of the Information System
to the Bidding Documents
Documentary evidence establishing to the
Purchaser’s satisfaction, and in accordance with ITB
Clause 16, that the Goods and Services components
of the Information System to be supplied, installed,
and/or performed by the Bidder conform to the
Bidding Documents;
(v)
Attachment 5: Proposed Subcontractors
A list of all major items of Goods or Services that the
Bidder proposes to purchase or subcontract from
others, and the name and nationality of the proposed
Subcontractor, including vendors, for each of those
items;
(vi) Attachment 6: Intellectual Property
A list of:
(1)
all Software included in the Bidder’s bid,
assigning each item to one of the software
categories defined in GCC Clause 1.1 (c):
(A) System, General Purpose, and Application
Software; and
(B) Standard and Custom Software.
(2)
all Custom Materials, as defined in GCC Clause
1.1 (c), included in the Bidder’s bid.
All Materials not identified as Custom Materials shall
be deemed Standard Materials, as defined in GCC
Clause 1.1 (c).
Re-assignments among the Software and Materials
categories, if necessary, will be made during the
implementation of the Contract according to GCC
Clause 39 (Changes to the System).
14. Bid Prices
14.1 All Goods and Services identified in the Supply and Installation
Cost Sub-Table and the Recurrent Cost Sub-Table in Section VII
(Forms 2.5 and 2.6), and all other Goods and Services proposed
by the Bidder to fulfill the requirements of the Information
System, must be priced separately in the format of the same
tables and summarized in the corresponding Cost Summary
Tables in the same Section. Prices must be quoted in accordance
with the instructions provided in Section VII for the various cost
tables, in the manner specified below.
14.2 The price of items that the Bidder has left blank in the cost
tables provided in Section VII shall be assumed to be included
in the price of other items. Items omitted altogether from the
cost tables shall be assumed to be omitted from the bid and,
provided that the bid is substantially responsive, an adjustment
to the bid price will be made during evaluation in accordance
with ITB Clause 28.6 (c) (iii).
14.3 Unit prices must be quoted at a level of detail appropriate for
calculation of any partial deliveries or partial payments under
the contract, in accordance with the Implementation Schedule in
Section VI, and with GCC and SCC Clause 12 – Terms of
Payment. Bidders may be required to provide a breakdown of
any composite or lump-sum items included in the Cost Tables.
14.4 The prices for Goods components of the System are to be
expressed and shall be defined and governed in accordance with
the rules prescribed in the edition of Incoterms specified in the
BDS, and quoted in the appropriate columns of the cost tables of
Section VII as follows:
(a)
Goods supplied from outside the Purchaser’s country:
Unless otherwise specified in the BDS, the prices shall be
quoted on a CIP (named place of destination) basis,
exclusive of all taxes, stamps, duties, levies, and fees
imposed in the Purchaser’s country. The named place of
destination and special instructions for the contract of
carriage are as specified in the BDS. In quoting the price,
the Bidder shall be free to use transportation through
carriers registered in any eligible countries. Similarly, the
Bidder may obtain insurance services from any eligible
source country.
(b)
Locally supplied Goods:
Unit prices of Goods offered from within the Purchaser’s
Country, shall be quoted on an EXW (ex factory, ex works,
ex warehouse or off-the-shelf, as applicable) basis,
including all customs duties, levies, fees, sales and other
taxes incurred until delivery of the Goods, but excluding
all VAT or sales and other taxes and duties/fees incurred
for the Goods at the time of invoicing or sales transaction,
if the Contract is awarded.
(c)
Inland transportation:
Unless otherwise stated in the BDS, inland transportation,
insurance and related local costs incidental to the delivery
of the Goods to the designated Project Sites must be quoted
separately as a Service item in accordance with ITB Clause
Page 19
14.5, whether the Goods are to be supplied locally or from
outside the Purchaser’s country, except when these costs
are already included in the price of the Goods, as is, e.g.,
the case, when ITB Clause 14.4 (a) specifies CIP, and the
named places of destination are the Project Sites.
14.5 The price of Services shall be quoted in total for each service
(where appropriate, broken down into unit prices), separated into
their local and foreign currency components. Prices must
include all taxes, duties, levies and fees whatsoever, except only
VAT or other indirect taxes, or stamp duties, that may be
assessed and/or apply in the Purchaser’s country on/to the price
of the Services invoiced to the Purchaser, if the Contract is
awarded. Unless otherwise specified in the BDS, the prices
must include all costs incidental to the performance of the
Services, as incurred by the Supplier, such as travel, subsistence,
office support, communications, translation, printing of
materials, etc. Costs incidental to the delivery of the Services
but incurred by the Purchaser or its staff, or by third parties,
must be included in the price only to the extent such obligations
are made explicit in these Bidding Documents (as, e.g., a
requirement for the Bidder to include the travel and subsistence
costs of trainees).
14.6 Prices for Recurrent Costs beyond the scope of warranty
services to be incurred during the Warranty Period, defined in
SCC Clause 29.4 and prices for Recurrent Costs to be incurred
during the Post-Warranty Period, defined in SCC Clause 1.1. (e)
(xii), shall be quoted as Service prices in accordance with ITB
Clause 14.5 on the Recurrent Cost Sub-Table in detail, and on
the Recurrent Cost Summary Table in currency totals. Recurrent
costs are all-inclusive of the costs of necessary Goods such as
spare parts, software license renewals, labor, etc., needed for the
continued and proper operation of the System and, if
appropriate, of the Bidder’s own allowance for price increases.
14.7 Unless otherwise specified in the BDS, prices quoted by the
Bidder shall be fixed during the Bidder’s performance of the
Contract and not subject to increases on any account. Bids
submitted that are subject to price adjustment will be rejected.
15. Bid Currencies
15.1 Prices shall be quoted in the following currencies:
(a)
The Bidder may quote its prices for all Information
Technologies, associated Goods, and Services to be
supplied from outside the Purchaser’s Country in the
currencies of countries eligible according to Section III. If
the Bidder wishes to be paid in a combination of different
currencies, it must quote unit prices accordingly, but no
more than three foreign currencies may be used.
(b)
Unless otherwise specified in the BDS, the Bidder shall
express its prices for such Information Technologies,
associated Goods, and Services to be supplied locally (i.e.,
from within the Purchaser’s Country) in the currency of
the Purchaser’s Country.
16.1 Pursuant to ITB Clause 13.1 (e) (iv), the Bidder shall furnish, as
16. Documents
part of its bid, documents establishing the conformity to the
Establishing
Bidding Documents of the Information System that the Bidder
the Conformity
proposes to supply and install under the Contract.
of the
Information
16.2 The documentary evidence of conformity of the Information
System to the
System to the Bidding Documents shall be in the form of written
Bidding
descriptions, literature, diagrams, certifications, and client
Documents
references, including:
(a)
the Bidder’s technical bid, i.e., a detailed description of the
Bidder’s proposed technical solution conforming in all
material aspects with the Technical Requirements (Section
VI) and other parts of these Bidding Documents, overall as
well as in regard to the essential technical and performance
characteristics of each component making up the proposed
Information System;
(b)
an item-by-item commentary on the Purchaser’s Technical
Requirements,
demonstrating
the
substantial
responsiveness of the Information System offered to those
requirements. In demonstrating responsiveness, the
commentary shall include explicit cross references to the
relevant pages in the supporting materials included in the
bid. Whenever a discrepancy arises between the item-byitem commentary and any catalogs, technical
specifications, or other preprinted materials submitted with
the bid, the item-by-item commentary shall prevail;
(c)
a Preliminary Project Plan describing, among other things,
the methods by which the Bidder will carry out its overall
management and coordination responsibilities if awarded
the Contract, and the human and other resources the Bidder
proposes to use. The Plan should include a detailed
Contract Implementation Schedule in bar chart form,
showing the estimated duration, sequence, and
interrelationship of all key activities needed to complete
the Contract. The Preliminary Project Plan must also
address any other topics specified in the BDS. In addition,
Page 21
the Preliminary Project Plan should state the Bidder’s
assessment of what it expects the Purchaser and any other
party involved in the implementation of the Information
System to provide during implementation and how the
Bidder proposes to coordinate the activities of all involved
parties;
(d)
a written confirmation that the Bidder accepts
responsibility for the successful integration and interoperability of all components of the Information System as
required by the Bidding Documents.
16.3 For purposes of the commentary to be furnished pursuant to ITB
Clause 16.2 (b), the Bidder shall note that references to brand
names or model numbers or national or proprietary standards
designated by the Purchaser in its Technical Requirements are
intended to be descriptive and not restrictive. Except where
explicitly prohibited in the BDS for specific items or standards,
the Bidder may substitute alternative brand/model names or
standards in its bid, provided that it demonstrates to the
Purchaser’s satisfaction that the use of the substitute(s) will
result in the Information System being able to perform
substantially equivalent to or better than that specified in the
Technical Requirements.
17. Securing the
Bid
17.1 The BDS for this Clause specifies whether bids must be secured,
and if so, whether by a Bid-Securing Declaration or by a Bid
Security. If a Bid Security is required or optional, the BDS also
specifies the amount.
17.2 Securing the bids shall be substantially in accordance with the
related sample forms included in Section VII or other forms
approved by the Purchaser prior to bid submission. Bids must
remain secured for a period of 28 days beyond the validity
period of the bids, as extended, if applicable, in accordance with
ITB Clause 18.2. In case of a Bid Security, it shall also:
(a)
at the Bidder’s option, be in the form of either a certified
check, letter of credit, or a bank guarantee from a banking
institution, or a bond issued by a surety;
(b)
be issued by a reputable institution selected by the Bidder
and located in any eligible country; if the institution
issuing the security is located outside the Purchaser’s
Country, it shall have a correspondent financial institution
located in the Purchaser’s Country to make the security
enforceable;
(c)
be payable promptly upon written demand by the
Purchaser in case any of the conditions listed in ITB
Clause 17.6 is/are invoked;
(d)
be submitted in its original form; copies will not be
accepted.
17.3 The Bid-Securing Declaration or the Bid Security of a Joint
Venture shall be issued in the name of the Joint Venture
submitting the bid provided the Joint Venture has legally been
constituted, or else it shall be issued in the name of all partners
proposed for the Joint Venture in the bid. Sanctions due to a
breach of the terms of a Bid-Securing Declaration pursuant to
ITB Clause 17.6 will apply to all partners to the Joint Venture.
17.4 If a Bid-Securing Declaration or Bid Security is required in
accordance with ITB Clause 17.1, any bid not accompanied by a
substantially acceptable Bid-Securing Declaration or Bid
Security in accordance with ITB Clauses 17.2 and 17.3, shall be
rejected by the Purchaser as non-responsive.
17.5 Unless executed or forfeited pursuant to ITB Clause 17.6, BidSecuring Declarations, if any, will expire for, or Bid Securities,
if any, will be returned as promptly as possible to,
(a)
all Bidders upon annulment of the bidding pursuant to ITB
Clause 34;
(b)
Bidders refusing a request to extend the period of validity
of their bids pursuant to ITB Clause 18.2;
(c)
the successful Bidder once it has signed the Contract
Agreement and furnished a valid Performance Security as
required;
(d)
the unsuccessful Bidders at the same time as in (c), that is,
when they are informed about the successful establishment
of the contract with the successful Bidder.
Page 23
17.6 The Bid-Securing Declaration, if any, may be executed, or the
Bid Security, if any, may be forfeited:
(a)
if a Bidder withdraws its bid during the period of bid
validity specified by the Bidder on the Bid Submission
Form or any extension of validity the Bidder has agreed to
pursuant to ITB Clause 18.2; or
(b)
in the case of the successful Bidder, if the Bidder fails to:
(i)
(ii)
sign the Contract Agreement in accordance with ITB
Clause 36; or
furnish the Performance Security in accordance with ITB Clause
37.
17.7 If a bid security is not required in the BDS, and
(a)
if a Bidder withdraws its bid during the period of bid
validity specified by the Bidder on the Letter of Bid Form,
except as provided in ITB 18.2, or
(b)
if the successful Bidder fails to: sign the Contract in
accordance with ITB 36; or furnish a performance security
in accordance with ITB 37;
the Borrower may, if provided for in the BDS, declare the
Bidder disqualified to be awarded a contract by the Employer
for a period of time as stated in the BDS.
18. Period of
Validity of
Bids
18.1 Bids shall remain valid, at a minimum, for the period specified
in the BDS after the deadline date for bid submission prescribed
by the Purchaser, pursuant to ITB Clause 21. A bid valid for a
shorter period shall be rejected by the Purchaser as nonresponsive. For the convenience of Bidders, the BDS spells out
the minimal original expiration dates for the validity of the bid
and, if applicable pursuant to ITB Clause 17.1, for securing the
bid. However, Bidders are responsible for adjusting the dates in
the BDS in accordance with any extensions to the deadline date
of bid submission pursuant to ITB Clause 21.2.
18.2 In exceptional circumstances, prior to expiry of the bid validity
period, the Purchaser may request that the Bidders extend the
period of validity for a specified additional period. The request
and the responses to the request shall be made in writing. A
Bidder may refuse the request without risking execution of the
Bid-Securing Declaration or forfeiting the Bid Security, but in
this case the bid will be out of the competition for the award.
Except as provided in ITB Clause 18.3, a Bidder agreeing to the
request will not be required or permitted to modify its bid, but
will be required to ensure that the bid remains secured for a
correspondingly longer period, pursuant to ITB Clause 17.2.
18.3 In the case of fixed price contracts, if the award is delayed by a
period exceeding fifty-six (56) days beyond the expiry of the
initial bid validity, the contract price will be adjusted as
specified in the request for extension. Bid evaluation will be
based on the bid prices without taking into consideration the
above correction.
19. Format and
Signing of Bid
19.1 The Bidder shall prepare an original and the number of
copies/sets of the bid specified in the BDS, clearly marking
each one as “ORIGINAL BID,” “COPY NO. 1,” “COPY
NO. 2,” etc., as appropriate. In the event of any discrepancy
between them, the original shall govern.
19.2 The original and all copies of the bid, each consisting of the
documents listed in ITB Clause 13.1, shall be typed or written in
indelible ink and shall be signed by a person or persons duly
authorized to sign on behalf of the Bidder. The authorization
must be in writing and included in the bid pursuant to ITB
Clause 13.1 (d). The name and position held by each person
signing the authorization must be typed or printed below the
signature. All pages of the bid, except for unamended printed
literature, shall be initialed by the person or persons signing the
bid.
19.3 The bid shall contain no interlineations, erasures, or overwriting,
except to correct errors made by the Bidder, in which case such
corrections shall be initialed by the person or persons signing the
bid.
19.4 The Bidder shall furnish in the Bid Submission Form (a sample
of which is provided in the Sample Forms Section of the
Bidding Documents) information regarding commissions or
gratuities, if any, paid or to be paid to agents relating to this
procurement and to the execution of the Contract should the
Bidder be successful.
D. SUBMISSION OF BIDS
20. Sealing and
Marking of
Bids
20.1 The Bidder shall seal the original and each copy of the bid in
separate envelopes, duly marking the envelopes as “ORIGINAL
BID” and “COPY NO. [number].” The envelopes shall then be
sealed in an outer envelope.
20.2 The inner and outer envelopes shall
(a)
be addressed to the Purchaser at the address given in the
BDS, and
(b)
bear the loan/Project name indicated in the BDS for ITB
Clause 2.1, the Invitation for Bids title and number, and
the Contract name(s), as indicated in the BDS for ITB
Clause 1.2, and the statement “DO NOT OPEN BEFORE
[ time and date],” to be completed with the time and date
specified in the BDS for ITB Clause 24.1.
20.3 The inner envelopes shall also indicate the name and address of
the Bidder so that the bid can be returned unopened in case it is
declared “late.”
Page 25
20.4 If the outer envelope is not sealed and marked as required by
ITB Clause 20.2 above, the Purchaser will assume no
responsibility for the bid’s misplacement or premature opening.
If the outer envelope discloses the Bidder’s identity, the
Purchaser will not guarantee the anonymity of the bid
submission, but this disclosure will not constitute grounds for
bid rejection.
21. Deadline for
Submission of
Bids
21.1 Bids must be received by the Purchaser at the address specified
in the BDS for ITB Clause 20.2 no later than the time and date
stated in the BDS.
21.2 The Purchaser may, at its discretion, extend this deadline for
submission of bids by amending the Bidding Documents in
accordance with ITB Clause 11.3, in which case all rights and
obligations of the Purchaser and Bidders will thereafter be
subject to the deadline as extended.
22. Late Bids
22.1 Any bid received by the Purchaser after the bid submission
deadline prescribed by the Purchaser in the BDS for ITB Clause
21, will be rejected and returned unopened to the Bidder.
23.1 The Bidder may withdraw, substitute, or modify its bid after
23. Withdrawal,
submission, provided that written notice of the withdrawal,
Substitution,
substitution, or modification is received by the Purchaser prior to
and
the deadline prescribed for bid submission. All notices must be
Modification of
duly signed by an authorized representative and shall include a
Bids
copy of the authorization (the power of attorney) in accordance
with ITB Sub-Clause 19.2.
23.2 All notices of withdrawal, substitution, or modification shall
(a)
be addressed to the Purchaser at the address named in the
BDS for ITB Clause 20.2 (a), and
(b)
bear the Contract name, the IFB Title and IFB Number,
and the words “BID WITHDRAWAL NOTICE”, BID
SUBSTITUTION NOTICE”, or “BID MODIFICATION NOTICE”.
23.3 A notice may also be sent by electronic means such as fax or email, but in this case must include a scan of the mailing receipt
showing both the sender's and receiver's addresses for the signed
hardcopy of the notice, and a scan of the power of attorney.
23.4 Bids requested to be withdrawn in accordance with ITB 23.1
shall be returned unopened to the Bidders. Bid withdrawal
notices received after the bid submission deadline will be
ignored, and the submitted bid will be deemed to be a validly
submitted bid.
23.5 The substitution or modification of the bid shall be prepared,
sealed, marked, and dispatched as follows:
(a)
The Bidders shall provide an original and the number of
copies specified in the BDS for ITB Clause 19.1 of any
substitution or modification to its bid, clearly identified as
such, in two inner envelopes duly marked “BID
SUBSTITUTION -- ORIGINAL” or “BID MODIFICATION --
ORIGINAL” and “BID SUBSTITUTION -- COPIES” or “BID
MODIFICATION -- COPIES.” The inner envelopes shall be
sealed in an outer envelope, which shall be duly marked
“BID SUBSTITUTION” or “BID MODIFICATION”.
(b)
Other provisions concerning the marking and dispatch of a
bid substitution or modification shall be in accordance with
ITB Clauses 20.2, 20.3, and 20.4.
23.6 No bid may be withdrawn, substituted, or modified in the
interval between the bid submission deadline and the expiration
of the bid validity period specified by the Bidder in the Bid
Submission Form, or any extension thereof agreed to by the
Bidder. Withdrawal of a bid during this interval may result in
the execution of the Bid-Securing Declaration, if any, or
forfeiture of the Bid Security, if any, pursuant to ITB Clause
17.6.
E. BID OPENING AND EVALUATION
24. Opening of
Bids by
Purchaser
24.1 The Purchaser will open all bids, including withdrawals,
substitutions, and modifications, in public, in the presence of
Bidders’ representatives who choose to attend, at the time, on
the date and at the place specified in the BDS. Bidders’
representatives shall sign a register as proof of their attendance.
24.2 First, envelopes marked “BID WITHDRAWAL NOTICE” shall be
opened and read out and the envelope with the corresponding
bid shall not be opened, but returned to the Bidder. No bid
withdrawal shall be permitted unless the corresponding
withdrawal notice contains a valid authorization to request the
withdrawal and is read out at bid opening. Next, envelopes
marked “BID SUBSTITUTION NOTICE” shall be opened and read
out and exchanged with the corresponding bid being substituted,
and the substituted bid shall not be opened, but returned to the
Bidder. No bid substitution shall be permitted unless the
corresponding substitution notice contains a valid authorization
to request the substitution and is read out at bid opening.
Envelopes marked “BID MODIFICATION NOTICE” shall be opened
and read out with the corresponding bid. No bid modification
shall be permitted unless the corresponding modification notice
contains a valid authorization to request the modification and is
read out at bid opening. Only bids that are opened and read out
at bid opening shall be considered further.
24.3 Bids shall be opened one at a time, reading out: the name of the
Bidder and whether there is a modification; the total bid price
including any unconditional discounts, and, if applicable, the
prices and unconditional discounts for Subsystems, lots, or
slices; the presence or absence of a Bid-Securing Declaration or
a Bid Security if one was required; any conditional discounts
offered for the award of more than one Subsystem, lot, or slice,
if the BDS for ITB Clause 28.1 permits such discounts to be
Page 27
considered in the bid evaluation; and any other such details as
the Purchaser may consider appropriate.
24.4 Bids and modifications that are not opened and read out at bid
opening shall not be considered for further evaluation,
irrespective of the circumstances. These bids, including any
bids validly withdrawn in accordance with ITB Clause 24.2, will
promptly be returned, unopened, to their Bidders.
24.5 The Purchaser will prepare minutes of the bid opening,
including the information disclosed to those present in
accordance with ITB Clause 24.3. The minutes will promptly be
distributed to all Bidders that met the deadline for submitting
bids.
25. Clarification of 25.1 During the bid evaluation, the Purchaser may, at its discretion,
ask the Bidder for a clarification of its bid. The request for
Bids
clarification and the response shall be in writing, and no change
in the price or substance of the bid shall be sought, offered, or
permitted.
26. Preliminary
Examination
of Bids
26.1 The Purchaser will examine the bids to determine whether they
are complete, whether any computational errors have been
made, whether required sureties have been furnished, whether
the documents have been properly signed, and whether the bids
are generally in order. In the case where a prequalification
process has been undertaken for the Contract(s) for which these
Bidding Documents have been issued, the Purchaser will ensure
that each bid is from a prequalified Bidder, and in the case of a
Joint Venture, that partners and structure of the Joint Venture
are unchanged from those in the prequalification.
26.2 Arithmetical errors will be rectified on the following basis. If
there is a discrepancy between the unit price and the total price,
which is obtained by multiplying the unit price and quantity, or
between added or subtracted subtotals and totals, the unit or
subtotal price shall prevail and the total price shall be corrected,
unless in the opinion of the Purchaser there is an obvious
misplacement of the decimal point in the unit or subtotal prices,
in which case the line item total as quoted shall govern and the
unit price or sub-total shall be corrected. If there is a
discrepancy between words and figures, the amount in words
will prevail, unless the discrepancy is the result of a typo/error
for which the correction is self-evident to the Purchaser. If the
Bidder with the Lowest Evaluated Bid does not accept the
correction of errors, the bid shall be rejected.
26.3 The Purchaser may waive any minor informality,
nonconformity, or irregularity in a bid that does not constitute a
material deviation, provided such waiver does not prejudice or
affect the relative ranking of any Bidder.
26.4 Prior to the detailed evaluation, the Purchaser will determine
whether each bid is of acceptable quality, is complete, and is
substantially responsive to the Bidding Documents. For
purposes of this determination, a substantially responsive bid is
one that conforms to all the terms, conditions, and specifications
of the Bidding Documents without material deviations,
exceptions, objections, conditionalities, or reservations. A
material deviation, exception, objection, conditionality, or
reservation is one: (i) that limits in any substantial way the
scope, quality, or performance of the Information System; or
(ii) that limits, in any substantial way that is inconsistent with
the Bidding Documents, the Purchaser’s rights or the successful
Bidder’s obligations under the Contract; or (iii) the acceptance
of which would unfairly affect the competitive position of other
Bidders who have submitted substantially responsive bids.
26.5 If a bid is not substantially responsive, it will be rejected by the
Purchaser and may not subsequently be made responsive by the
Bidder by correction of the nonconformity. The Purchaser’s
determination of bid responsiveness will be based on the
contents of the bid itself.
27. Conversion to
Single
Currency
27.1 For evaluation and comparison purposes, the Purchaser shall
convert all bid prices expressed in various currencies and
amounts into a single currency specified in the BDS, using the
selling exchange rate established by the source and on the date
also specified in the BDS.
28. Evaluation and 28.1 The Purchaser will evaluate and compare the bids that have been
determined to be substantially responsive, pursuant to ITB
Comparison of
Clause 26. The evaluation will be performed assuming either
Bids
that:
(a)
the Contract will be awarded to the lowest evaluated
Bidder for the entire Information System; or
(b)
if specified in the BDS, Contracts will be awarded to the
Bidders for each individual Subsystem, lot, or slice defined
in the Technical Requirements whose bids result in the
lowest combined evaluated price for the entire System.
In the latter case, discounts that are conditional on the award of
more than one Subsystem, lot, or slice may be offered in bids.
However, such discounts will only be considered in the price
evaluation if so confirmed in the BDS.
28.2 To be considered for Contract award, Bidders must have
submitted bids
(a)
for which detailed bid evaluation using the same standards
for compliance determination as listed in ITB Clauses 26.3
and 26.4 confirms that the bids are commercially and
technically responsive, and include the hardware,
Software, related equipment, products, Materials, and
other Goods and Services components of the Information
System in, substantially, the full required quantities for the
entire Information System or, if allowed in the BDS for
ITB Clause 28.1, the individual Subsystem, lot or slice bid
on; and
(b)
that offer Information Technologies that are proven to
Page 29
perform up to the standards promised in the bid by having
successfully passed the performance, benchmark, and/or
functionality tests the Purchaser may require, pursuant to
ITB Clause 31.2.
28.3 The Purchaser’s evaluation of a bid will be made on the basis of
prices quoted in accordance with ITB Clause 14 (Bid Prices).
28.4 If indicated by the BDS, the Purchaser’s evaluation of
responsive bids will take into account technical factors, in
addition to cost factors. An Evaluated Bid Score (B) will be
calculated for each responsive bid using the following formula,
which permits a comprehensive assessment of the bid price and
the technical merits of each bid:
B
Clow
T
1  X 
X 
C
Thigh
where
C
= Evaluated Bid Price
C low = the lowest of all Evaluated Bid Prices among
responsive bids
T
= the total Technical Score awarded to the bid
Thigh = the Technical Score achieved by the bid that was
scored highest among all responsive bids
X
= weight for the Price as specified in the BDS
The bid with the highest Evaluated Bid Score (B) among
responsive bids shall be termed the Lowest Evaluated Bid and is
eligible for Contract award, provided the Bidder was
prequalified and/or it was found to be qualified to perform the
Contract in accordance with ITB Clause 31 (Postqualification).
28.5 If, in addition to the cost factors, the Purchaser has chosen to
give weight to important technical factors (i.e., the price weight,
X, is less than 1 in the evaluation), that cannot be reduced to
life-cycle costs or pass/fail criteria, the Total Technical Points
assigned to each bid in the Evaluated Bid Formula will be
determined by adding and weighting the scores assigned by an
evaluation committee to technical features of the bid in
accordance with the criteria set forth below.
(a)
The technical features to be evaluated are generally
defined below and specifically identified in the BDS:
(i)
Performance, capacity, or functionality features that
either exceed levels specified as mandatory in the
Technical Requirements; and/or influence the lifecycle cost and effectiveness of the Information
System.
(ii)
Usability features, such as ease of use, ease of
administration, or ease of expansion, which
influence the life-cycle cost and effectiveness of the
Information System.
(iii) The quality of the Bidder’s Preliminary Project Plan
as evidenced by the thoroughness, reasonableness,
and responsiveness of: (a) the task and resource
schedules, both general and specific, and (b) the
proposed arrangements for management and
coordination, training, quality assurance, technical
support, logistics, problem resolution, and transfer of
knowledge, and other such activities as specified by
the Purchaser in Section VI (Technical
Requirements) or proposed by the Bidder based on
the Bidder’s experience.
(b)
Feature scores will be grouped into a small number of
evaluation categories, generally defined below and
specifically identified in the BDS, namely:
(i)
The technical features that reflect how well the
Information System meets the Purchaser’s Business
Requirements (including quality assurance and riskcontainment measures associated with the
implementation of the Information System).
(ii)
The technical features that reflect how well the
Information System meets the System’s Functional
Performance Standards.
(iii) The technical features that reflect how well the
Information System meets the General Technical
Requirements
for
hardware,
network
and
communications, Software, and Services.
(c)
As specified in the BDS, each category will be given a
weight and within each category each feature may also be
given a weight.
(d)
During the evaluation process, the evaluation committee
will assign each desirable/preferred feature a whole
number score from 0 to 4, where 0 means that the feature
is absent, and 1 to 4 either represent predefined values for
desirable features amenable to an objective way of rating
(as is the case for, e.g., extra memory, or extra mass
storage capacity, etc., if these extras would be conducive
for the utility of the system), or if the feature represents a
desirable functionality (e.g., of a software package) or a
quality improving the prospects for a successful
implementation (such as the strengths of the proposed
project staff, the methodology, the elaboration of the
project plan, etc., in the bid), the scoring will be 1 for the
feature being present but showing deficiencies; 2 for
meeting the requirements; 3 for marginally exceeding the
requirements; and 4 for significantly exceeding the
requirements.
Page 31
(e)
The score for each feature (i) within a category (j) will be
combined with the scores of features in the same category
as a weighted sum to form the Category Technical Score
using the following formula:
k
S j   t ji  w ji
i 1
where:
tji
= the technical score for feature “i” in category “j”
wji
= the weight of feature “i” in category “j”
k
= the number of scored features in category “j”
k
w
and
i 1
(f)
ji
1
The Category Technical Scores will be combined in a
weighted sum to form the total Technical Bid Score using
the following formula:
n
T   S j Wj
j 1
where:
Sj
= the Category Technical Score of category “j”
Wj
= the weight of category “j” as specified in the BDS
n
= the number of categories
n
and
W
j 1
j
1
28.6 The Evaluated Bid Price (C) for each responsive bid will be
determined as the sum of the Adjusted Supply and Installation
Costs (P) plus the Recurrent Costs (R);
where the Adjusted Supply and Installation Costs (P) are
determined as:
(a)
The price of the hardware, Software, related equipment,
products, Materials and other Goods offered from within
or from outside the Purchaser’s Country, in accordance
with ITB 14.4; plus
(b)
The total price for all software development,
transportation, insurance, installation, customization,
integration, Commissioning, testing, training, technical
support, repair, and other Services, in accordance with ITB
14.5;
(c)
with adjustments for:
(i)
Deviations proposed to the Implementation Schedule
in the Technical Requirements resulting in delayed
completion of the entire Information System, if
permitted in the BDS and provided they do not
exceed the maximum permissible delay period
specified in the BDS. For evaluation purposes, a pro
rata increase of the total Supply and Installation
Costs will be added using the percentage(s) specified
in the BDS for each week of delay. Bids offering
deliveries beyond the maximum permissible delay
specified may be rejected.
(ii)
Deviations taken to the Contract payment schedule
specified in the SCC. If deviations are permitted in
the BDS, for evaluation purposes the total Supply
and Installation Costs will be increased pro rata by
the amount of interest that could otherwise be earned
on the amount of any payments that would fall due
under the proposed schedule earlier than the schedule
stipulated in the SCC, at the interest rate specified in
the BDS.
(iii) Goods and Services that are required for the
Information System but have been left out or are
necessary to correct minor deviations of the bid will
be added to the total Supply and Installation Costs
using costs taken from the highest prices from other
responsive bids for the same Goods and Services, or
in the absence of such information, the cost will be
estimated at prevailing list prices. If the missing
Goods and Services are a scored technical feature,
the relevant score will be set at zero.
(iv) Corrections to errors in arithmetic, in accordance
with ITB Clause 26.2.
(v)
(d)
Any discounts offered for the award of more than
one Subsystem, lot, or slice, if the BDS for ITB
Clause 28.1 permits the consideration of discounts in
the price evaluation.
The Recurrent Costs (R) are reduced to net present value
and determined using the following formula:
R
NM R
x

x
x  1 1  I 
where
N = number of years of the Warranty Period, defined in
SCC Clause 29.4
M = number of years of the Post-Warranty Services
Period, as defined in SCC Clause 1.1.(e) (xii)
x
= an index number 1, 2, 3, ... N + M representing
each year of the combined Warranty Service and
Post-Warranty Service Periods.
Rx = total Recurrent Costs for year “x,” as recorded in
Page 33
the Recurrent Cost Sub-Table.
I
= discount rate to be used for the Net Present Value
calculation, as specified in the BDS.
29. Domestic
Preference
29.1 No margin of domestic preference will apply.
30. Contacting the
Purchaser
30.1 From the time of bid opening to the time of Contract award, if
any Bidder wishes to contact the Purchaser on any matter related
to the bid, it should do so in writing.
30.2 If a Bidder tries to directly influence the Purchaser or otherwise
interfere in the bid evaluation process and the Contract award
decision, its bid may be rejected.
F. POSTQUALIFICATION AND AWARD OF CONTRACT
31. Postqualification
31.1 The Purchaser will determine at its own cost and to its
satisfaction whether the Bidder (including Joint Venture
Partners, and any Subcontractors for which the BDS for ITB
Clause 6.1 (a) permits that their qualifications count towards the
required Bidder qualifications) that is selected as having
submitted the Lowest Evaluated Bid is qualified to perform the
Contract satisfactorily, in accordance with ITB Clause 6. If a
prequalification process was undertaken for the Contract(s) for
which these Bidding Documents were issued, the Purchaser will
determine in the manner described above that no material
changes have occurred after the prequalification that negatively
affect the ability of the Bidder that has submitted the Lowest
Evaluated Bid to perform the Contract.
31.2 Pursuant to ITB Clauses 6 and 16, and as additionally may be
specified in the BDS, the determination will evaluate the
Bidder’s financial, technical, design, integration, customization,
production, management, and support capabilities and will be
based on an examination of the documentary evidence of the
Bidder’s qualifications, as well as other information the
Purchaser deems necessary and appropriate. This determination
may include visits or interviews with the Bidder’s clients
referenced in its bid, site inspections, and any other measures. If
so specified in the BDS, at the time of postqualification the
Purchaser may also carry out tests to determine that the
performance or functionality of the Information System offered
meets those stated in the Technical Requirements.
31.3 An affirmative postqualification determination will be a
prerequisite for award of the Contract to the Lowest Evaluated
Bidder. A negative determination will result in rejection of the
Bidder’s bid, in which event the Purchaser will proceed to the
next lowest evaluated Bidder to make a similar determination of
that Bidder’s capabilities to perform satisfactorily.
32. Award
Criteria
32.1 Subject to ITB Clause 34, the Purchaser will award the Contract
to the Bidder whose bid has been determined to be substantially
responsive and the Lowest Evaluated Bid, provided further that
the Bidder has been determined to be qualified to perform the
Contract satisfactorily, pursuant to ITB Clause 31.
33. Purchaser’s
Right to Vary
Quantities at
Time of Award
33.1 The Purchaser reserves the right at the time of Contract award to
increase or decrease, by the percentage(s) indicated in the BDS,
any of the following:
(a)
the quantity of substantially identical Subsystems; or
(b)
the quantity of individual hardware, Software, related
equipment, Materials, products, and other Goods
components of the Information System; or
(c)
the quantity of Installation or other Services to be
performed,
from that originally specified in the Technical Requirements (as
amended by any Addenda issued pursuant to ITB Clause 11),
without any change in unit prices or other terms and conditions.
34. Purchaser’s
Right to
Accept Any
Bid and to
Reject Any or
All Bids
34.1 The Purchaser reserves the right to accept or reject any bid or to
annul the bidding process and reject all bids at any time prior to
Contract award, without thereby incurring any liability to the
Bidders.
35. Notification of
Award
35.1 Prior to the expiration of the period of bid validity, the Purchaser
shall notify the successful Bidder, in writing, that its bid has
been accepted.
35.2 Until a formal Contract is prepared and executed, the
notification of award shall constitute a binding Contract.
35.3 The Purchaser shall promptly publish in UNDB online and in
dgMarket the results, identifying the bid and lot numbers and the
following information: (i) name of each Bidder who submitted a
bid; (ii) bid prices as read out at bid opening; (iii) name,
evaluated price and, if the bidding conditions included scoring
for technical quality, the technical score of each bid that was
evaluated; (iv) name of Bidders whose bids were rejected and
the reasons for their rejection; and (v) name of the winning
Bidder, the price it offered, as well as the duration and summary
scope of the contract awarded. After publication of the award,
unsuccessful Bidders may make a request in writing to the
Purchaser for a debriefing seeking explanations on the grounds
on which their bids were not selected. The Purchaser shall
promptly respond in writing to any unsuccessful Bidder who,
after publication of contract award, requests a debriefing.
35.4 Upon the successful Bidder furnishing the signed Contract
Agreement and the Performance Security pursuant to ITB
Clause 37, the Purchaser will promptly notify each unsuccessful
Bidder, and will discharge all remaining Bid Securities, if any,
Page 35
as provided in ITB Clause 17.5 (c) and (d).
36. Signing of
Contract
36.1 At the same time as the Purchaser notifies the successful Bidder
that its bid has been accepted, the Purchaser will send the Bidder
the Contract Agreement provided in the Bidding Documents,
incorporating all agreements between the parties.
36.2 As soon as practically possible, but no more than twenty-eight
(28) days following receipt of the Contract Agreement, the
successful Bidder shall sign and date it, and return it to the
Purchaser.
37. Performance
Security
37.1 As soon as practically possible, but no more than twenty-eight
(28) days following receipt of notification of award from the
Purchaser, the successful Bidder shall furnish the Performance
Security in accordance with the GCC, using the Performance
Security form provided in the Bidding Documents or another
form acceptable to the Purchaser.
37.2 Failure of the successful Bidder to comply with the requirements
of ITB Clause 36 or ITB Clause 37.1 shall constitute sufficient
grounds for the annulment of the award and, if and as
applicable, execution of the Bid-Securing Declaration or
forfeiture of the Bid Security, in which event the Purchaser may
make the award to the next lowest evaluated bid submitted by a
qualified Bidder or call for new bids.
38. Adjudicator
38.1 Unless otherwise stated in the BDS, the Purchaser proposes that
the person named in the BDS be appointed as Adjudicator under
the Contract to assume the role of informal Contract dispute
mediator, as described in GCC Clause 6. In this case, a résumé
of the named person is attached to the BDS. The proposed
hourly fee for the Adjudicator is specified in the BDS. The
expenses that would be considered reimbursable to the
Adjudicator are also specified in the BDS. If a Bidder does not
accept the Adjudicator proposed by the Purchaser, it should state
its non-acceptance in its Bid Submission Form and make a
counterproposal of an Adjudicator and an hourly fee, attaching a
résumé of the alternative. If the successful Bidder and the
Adjudicator nominated in the BDS happen to be from the same
country, and this is not the country of the Purchaser too, the
Purchaser reserves the right to cancel the Adjudicator nominated
in the BDS and propose a new one. If by the day the Contract is
signed, the Purchaser and the successful Bidder have not agreed
on the appointment of the Adjudicator, the Adjudicator shall be
appointed, at the request of either party, by the Appointing
Authority specified in the SCC clause relating to GCC Clause
6.1.4, or if no Appointing Authority is specified there, the
Contract will be implemented without an Adjudicator.
SECTION II. BID DATA SHEET (BDS)
Bid Data Sheet
The Section contains specific information relating to the Systems to be procured and the
procurement procedures. Whenever there is a conflict, the provisions in the Bid Data Sheet
(BDS) shall prevail over those in Bidding documentation.
A. GENERAL
ITB 1.1
Name of Purchaser: Ministry of Healthcare and Social
Development of the Republic of Kazakhstan
Description of the System for which bids are invited:
Delivery of Health Information Systems for health facilities of
the RK which consists of the following lots:
Lot № 1 «Delivery and implementation of Comprehensive Health
Information System for Municipal hospital №1 Ust-Kamenogorsk
city»;
Lot № 2 «Delivery and implementation of Comprehensive Health
Information System for Municipal Clinic Hospital №4 Almaty
city»;
Lot № 3 «Delivery and implementation of Comprehensive Health
Information System for Mother and Child Center Ust-Kamenogorsk
city»;
Lot № 4 «Delivery and implementation of Comprehensive Health
Information System for Municipal Policlinic №11 Almaty city»;
Lot № 5 «Delivery and implementation of Comprehensive Health
Information System for Regional Diagnostic Center Almaty city»;
Lot № 6 «Delivery and implementation of Comprehensive Health
Information System for Policlinic №1 Kostanay»;
Lot № 7 «Delivery and implementation of Comprehensive Health
Information System for Central rayon hospital, Zhualynsky rayon,
Zhambul oblast»;
Lot № 8 «Delivery and implementation of Comprehensive Health
Information System for Municipal policlinic №7 Astana city»;
Lot № 9 «Delivery and implementation of Comprehensive Health
Information System for Municipal Hospital No. 1 of Astana city»;
Lot № 10 «Health Information System for accounting donors and
recipients».
ITB 1.2
Title of IFB: Delivery of Health Information Systems for health
facilities of the RK
Number of IFB: № KHSTTIRP-D/SW-03-rebidding
Name of resulting Contract: KHSTTIRP-D/SW-03-rebidding
“Delivery of Health Information Systems for health facilities of
Page 37
the RK”
ITB 1.4
Alternative e-Tendering procedures are not available in this
procurement.
ITB 2.1
Name of the Borrower: Republic of Kazakhstan
Loan or credit number: Loan № 4883-KZ
Loan or credit amount: US$ 117 700 000
Name of Project: Kazakhstan Health Sector Technology Transfer
and Institutional Reform Project
ITB 6.1 (a)
Qualification requirements for Bidders are:
(a)
The Bidder shall furnish documentary evidence that it meets
the following financial requirement(s):
-
The average annual turnover in USD or equivalent the most
recent three (3) (2012, 2013 and 2014) years:
-
at least US$1,500,000.00 (one million five hundred
thousand) for Lot № 1 «Delivery and implementation of
Comprehensive Health Information System for Municipal
hospital №1 Ust-Kamenogorsk city»;
-
at least US$1,000,000.00 (one million ) for Lot № 2
«Delivery and implementation of Comprehensive Health
Information System for Municipal Clinic Hospital №4
Almaty city»;
-
at least US$2,000,000.00 (two million) for Lot № 3
«Delivery and implementation of Comprehensive Health
Information System for Mother and Child Center UstKamenogorsk city»;
-
at least US$1,000,000.00 (one million) for Lot № 4
«Delivery and implementation of Comprehensive Health
Information System for Municipal Policlinic №11 Almaty
city»;
-
at least US$1,000,000.00 (one million) for Lot № 5
«Delivery and implementation of Comprehensive Health
Information System for Regional Diagnostic Center Almaty
city»;
-
at least US$1,000,000.00 (one million) for Lot № 6
«Delivery and implementation of Comprehensive Health
Information System for Policlinic №1 Kostanay»;
-
at least US$1,000,000.00 (one million) for Lot № 7
«Delivery and implementation of Comprehensive Health
Information System for Central rayon hospital, Zhualynsky
rayon, Zhambul oblast»;
-
at least US$1,000,000.00 (one million) for Lot № 8
«Delivery and implementation of Comprehensive Health
Information System for Municipal policlinic №7 Astana
city»;
-
at least US$1,000,000.00 (one million) for Lot № 9
«Delivery and implementation of Comprehensive Health
Information System for Municipal Hospital No. 1 of Astana
city»;
-
at least US$1,500,000.00 (one million five hundred
thousand) for Lot № 10 « Medical information system for
registration of donors, recipients and individuals waiting for
transplantation».
Where the Bidder is a Joint Venture the sum of all Partners'
average turnover amounts may be used. Also, where the
Bidder is a Joint Venture the Partner in charge must have had
an average annual turnover equivalent to at least half of the
amount required for the most recent three (3) years, while
every other partners – at least 10 % out of total required
amount.
The Bidder should provide audited financial statements and
balance sheets (or some other documents according to
legislation of Bidder’s country) for the last three (3)
completed fiscal years demonstrating the soundness of the
Bidder’s financial position and available resources necessary
to handle the requirements of the proposed Contract.
If the bidder wishes to qualify for award of contract for more
than one lot then the bidder must demonstrate having
required annual average turnover to meet the aggregate of the
qualifying criteria for the individual lots.
(b) Experience and Technical Capacity
The Bidder shall furnish documentary evidence (including
information about the completed contracts and contact
information of clients from whom the references could be
taken or whom the Purchaser may, when necessary, visit to
learn the systems put into operation by the Bidder) to
demonstrate that it meets the following requirements to
experience:
i.
the Bidder should have been operating at minimum for 5
years with the basic activity being delivery and
implementation of Information Systems for health facilities.
ii.
the Manufacturer(s) of Software shall have at least one
certificate out of the following list: Capability Maturity
Model Integration (CMMI) Maturity Level 3, ISO 9000 or
ST RK ISO 9001:2009, or similar for quality management
process. (The Bidder shall provide copy of certificate for
compliance issued by authorized agency).
iii.
the Bidder shall have experience in training end-users and IT
Page 39
specialists.
iv.
the Bidder shall have proven experience in design of similar
projects: at least 5 health facilities currently use systems
designed and implemented by the Bidder (the scale of these
health facilities shall be preferably correspondent to that of
health facilities – beneficiaries under this Bidding or exceed
it). “Proven” means presentation of contracts, addresses,
letters and other documents capable to confirm the use (and
outcomes) of the System required under the Contract.
v.
The Bidder shall have own team of experts with the
experience of implementation of similar projects. the Bidder
shall present the Table containing the List of Staff with their
CV to prove their experience and expertise. Detailed
requirements to the team are set in Section VI «Technical
Requirements» in item R10.4 for lots 1-9 and R11.4 for lot
10. The Bidder should provide two sets of CVs to win two
lots and three sets of CVs to win three lots.
vi.
the Bidder shall forward all documents confirming the origin
of all components and products including Manufacturer’s
Authorization to use these products within this Contract or
confirmation on ownership of the rights for the products
(patent or any other documents) including Intellectual
Property rights and other relevant rights.
vii.
the Bidders (or JV members) shall have proven experience of
work with one or several standards used herein: HL7 v2, v3,
FHIR, CDA (R2). IHE.
ITB 6.1 (b)
Manufacturer's Authorizations for Information Technologies except for those technologies which the Bidder itself manufactures are required for the following types/categories: for operation
systems, proprietary software
ITB 6.1 (c)
If the Bidder proposes to use Subcontractors for the provision of
certain key services, written agreements by the proposed firms to
provide these services in case of contract resulting from this bidding
are required for the following types/categories of services: software
customization, training, and, in particular, warranty and postwarranty service of equipment.
B. THE BIDDING DOCUMENTS
ITB 10.1
Address:
Project Implementation Support Team (PIST),
010000, Kazakhstan, Astana city, Imanov Str.19 office 504,
tel. + 7172 787 235,
fax. + 7172 787 247
e-mail: kazhealth.procurement@gmail.com
Contact person:
Bolat Tokezhanov – National Project Coordinator
Complete set of Bidding Document could be downloaded in English
(Word and PDF file) from Project web-site: www.healthproject.kz
upon registration.
If there is discrepancy between Word and PDF file, the PDF file will
prevail.
In addition interested Bidders can get complete set of Bidding
Document in Russian in Word. In case of discrepancies between the
English and Russian versions of the documents, the English version
shall prevail
Clarifications shall
www.healthproject.kz
also
be
published
in
this
website
ITB 10.2
Dates, times, and places for the pre-bid meeting: not applicable
ITB 11.2
At the end of the para, add “In addition the amendments to bid
documents shall also be published in www.healthproject.kz “
C. PREPARATION OF BIDS
ITB 12.1
The language of the bid and of all correspondence and documents
related to it is: English.
To facilitate evaluation of bids, the Purchaser requests Bidders to
also submit translations of their bids into Russian language.
However, the lack of translation shall not be reason for rejection of
bids or effect evaluation of the Bid. In case of discrepancies between
English version and translation, the English version will prevail.
ITB 14.1
Recurrent cost items are not required.
ITB 14.4
The Incoterms edition is “Incoterms 2010
For the current version of Incoterms consult the ICC web site at
http://www.iccwbo.org/index_incoterms.asp.
ITB 14.4 (a)
For foreign goods prices are quoted on delivery conditions based as
follows:
CIP-Astana for Lots №8, №9 and №10.
CIP – Ust Kamenogorsk for Lots №1 and №3.
CIP _ Almaty for Lots №2, №4 and №5.
CIP – Kostanay for Lot №6.
CIP – Taraz for Lot №7.
(i) The contract of carriage shall include the cost of unloading the
goods at destination, as well as payment by the Supplier of the cost
of custom formalities, duties, taxes or other charges payable on the
foreign Goods for their transit through any country other than the
Purchaser's country.
(ii) The named place of destination shall be the “Project Sites”
Page 41
pointed out in the table named as List (lists) of the System sites
ITB 14.4 (c)
Not applicable
ITB 14.7
Prices quoted by the Bidder shall be: fixed
ITB 15.1 (b)
The currency to be used for quoting prices of the Goods and
Services components of the System offered locally (i.e., from within
the Purchaser’s Country), as well as local currency expenditures for
local technical support, training, maintenance, transportation,
insurance, and other local services incidental to delivery, installation
and operation of the System, is: Kazakhstan Tenge.
ITB 16.2 (c)
In addition to the stated in ITB 16.2 (c), in the Preliminary Project
Plan the following issues should be addressed:
(а) Plan of the Project management organization containing
described roles and responsibilities of personnel of the Supplier, the
names and the number of working hours (person-months), and what
actions of management unit and staff of a health facility are
necessary for successful implementation of the Project;
(b) System (s) implementation Plan in a health facility that would
prove that all Purchaser’s requirements for delivered Systems are
met, and this is confirmed by facility - beneficiary, and that the
systems are certified in accordance with the Purchaser’s
requirements
(c) Methodology and Plan for development / configuration, testing,
installation, trial operation and certification of Systems supplied
(d) Methodology and User training Plan specifying the methods and
programs of study, the number of hours, training venue and transfer
of technology for both users and managers of the enterprise.
(e) Data migration Plan (if such data is available)
(f) Response plans for warranty service, and provision of
professional services for piloting: what is the response time to
eliminate errors and queries, to indicate where the staff of the
supplier will be, how many people will be involved, and on what
schedule.
(g) Methodology and support plan for all included software and
component both during implementation and during the trial
operation
ITB 16.3
In the interest of effective integration, cost-effective technical
support, and reduced re-training and staffing costs, Bidders are
required to offer specific brand names and models for the following
limited number of specific items: not applicable
ITB 17.1
A bid security will be required in a form of bank guaranty.
The amount of the Bid Security shall be:
- 20 000 USD for Lot № 1 «Delivery and implementation of
Comprehensive Health Information System for Municipal hospital
№1 Ust-Kamenogorsk city»;
- 10 000 USD for Lot № 2 «Delivery and implementation of
Comprehensive Health Information System for Municipal Clinic
Hospital №4 Almaty city»;
- 30 000 USD for Lot № 3 «Delivery and implementation of
Comprehensive Health Information System for Mother and Child
Center of Ust-Kamenogorsk city»;
- 10 000 USD for Lot № 4 «Delivery and implementation of
Comprehensive Health Information System for Municipal Policlinic
№11 Almaty city»;
- 10 000 USD for Lot № 5 «Delivery and implementation of
Comprehensive Health Information System for Regional Diagnostic
Center Almaty city»;
- 10 000 USD for Lot № 6 «Delivery and implementation of
Comprehensive Health Information System for Policlinic №1
Kostanay»;
- 15000 USD for Lot № 7 «Delivery and implementation of
Comprehensive Health Information System for Central rayon
hospital, Zhualynsky rayon, Zhambul oblast»;
- 10 000 USD for Lot № 8 «Delivery and implementation of
Comprehensive Health Information System for Municipal policlinic
№7 Astana city»;
- 10 000 USD for Lot № 9 «Delivery and implementation of
Comprehensive Health Information System for Municipal Hospital
No. 1 of Astana city»;
- 20 000 USD for Lot № 10 «Medical information system for
registration of donors, recipients and individuals waiting for
transplantation».
ITB 18.1
The bid validity period shall be one hundred twenty (120) days after
the deadline for bid submission, as specified below in reference to
ITB Clause 21. Accordingly, each bid shall be valid through
February 10, 2016.
The actual date of Bid Security expiration is March 9, 2016.
ITB 19.1
Required number of bid copies, besides the original: 5 bid copies
D. SUBMISSION OF BIDS
ITB 20.2 (a)
The address for bid submission is:
010000, Kazakhstan, Astana, Imanov Str. 19, office 504,
Attn: Bolat Tokezhanov – National Project Coordinator
ITB 21.1
Deadline for bid submission is: 15:30 hours, on October 15, 2015.
E. BID OPENING AND EVALUATION
ITB 24.1
Time, date, and place for bid opening are: 15:30 hours, on October
15, 2015
Page 43
010000 Kazakhstan, Astana, Imanov str. 19, office 504
ITB 27.1
The currency chosen for the purpose of converting to a common
currency is: local currency, KZT
The source of exchange rate is: National Bank of the Republic of
Kazakhstan
The date of exchange rate determination is: Bid opening date
ITB 28.1
Bids for Subsystems, lots, or slices of the overall Information
System will be accepted. The Bids will be evaluated on lot by lot
basis.
The bidders are not permitted to provide their technical solutions to
other bidders who are participating in the same bidding
If a Bidder wishes to offer an unconditional discount for any
combination of two or three lots, such Bidder may do so by offering
one, and only one, such discount, which shall be expressed as a
percentage to be applied to the total value of any combination of two
or three lots. Such offered discount will be taken into account for the
purpose of determining the lowest evaluated price of the lot
(contract) combinations.
ITB 28.4
A Bidder may also offer individual unconditional discount(s) to the
quoted price(s) for any one or more individual lot(s), in which case
the respective discount so offered for each lot shall be considered
for the purpose of evaluation. If such bidder also offered a single
unconditional discount for a combination of two or three lots as
described above, it shall be applied to the net bid price derived after
subtracting the value of the offered individual unconditional
discounts.
The bid evaluation will not take into account technical factors in
addition to cost factors. Price weight comprises 100%.
ITB 28.6 (c) (i)
The Purchaser will not accept deviations in the schedule of
installation and commissioning specified in the Implementation
Schedule.
ITB 28.6 (c) (ii)
The Purchaser will not accept deviations in the payment schedule in
the SCC.
F. POSTQUALIFICATION AND AWARD OF CONTRACT
ITB 31.2
not applicable
ITB 32.1
The contract(s) will be awarded to the Bidder or Bidders offering the
lowest evaluated cost to the Purchaser for combined lots, subject to
the selected Bidder(s) meeting the required qualification criteria for
a lot or combination of lots as the case may be. The Purchaser shall
award not more than three lots to one bidder even if the bidder is
lowest and qualified.
If the Bid of one or several Bidders receives the lowest evaluated
cost for more than three lots then the criteria for selection of lots for
the Purchaser shall be the best from the Purchaser’s point of view
combination of total cost of all awarded lots.
ITB 33.1
Percentage for quantity increase or decrease: 15%
ITB 38.1
The proposed Adjudicator is: WEINHARA Michael, Master on
Sicence in Health Informatics. CV is attached to this Bid Data Sheet.
The proposed hourly fee is US$ 350 (three hundred fifty US
dollars).
The expenses that would be considered reimbursable to the
Adjudicator are: all dispute-related telephone, fax, and other
communications costs, as well as all costs associated with trips to
the site(s), if any.
Page 45
Annex to Section II. Bid Data Sheet (BDS)
Clause ITB 3: The provisions in ITB 3.1 to 3.3 are replaced with the following, including
relevant footnotes:
3.
3.1
It is the Bank’s policy to require that Borrowers (including
beneficiaries of Bank loans), as well as bidders, suppliers, and contractors
and their agents (whether declared or not), personnel, subcontractors, subconsultants, service providers and suppliers under Bank-financed contracts,
observe the highest standard of ethics during the procurement and
execution of such contracts.6 In pursuance of this policy, the Bank:
Fraud and
Corruption
(a)
defines, for the purposes of this provision, the terms set forth below as
follows:
(i)
“corrupt practice” is the offering, giving, receiving or soliciting, directly
or indirectly, of anything of value to influence improperly the actions of
another party7;
(ii)
“fraudulent practice” is any act or omission, including a
misrepresentation, that knowingly or recklessly misleads, or attempts to
mislead, a party to obtain a financial or other benefit or to avoid an
obligation8;
(iii) “collusive practice” is an arrangement between two or more parties9
designed to achieve an improper purpose, including to influence
improperly the actions of another party;
(iv)
“coercive practice” is impairing or harming, or threatening to impair or
harm, directly or indirectly, any party or the property of the party to
influence improperly the actions of a party10;
(v)
“obstructive practice” is
(aa) deliberately destroying, falsifying, altering or concealing of
evidence material to the investigation or making false statements
to investigators in order to materially impede a Bank investigation
into allegations of a corrupt, fraudulent, coercive or collusive
practice; and/or threatening, harassing or intimidating any party to
prevent it from disclosing its knowledge of matters relevant to the
investigation or from pursuing the investigation; or
(bb) acts intended to materially impede the exercise of the Bank’s
inspection and audit rights provided for under sub-clause 3.2
below.
(b)
will reject a proposal for award if it determines that the bidder recommended
for award has, directly or through an agent, engaged in corrupt, fraudulent,
6
In this context, any action taken by a bidder, supplier, contractor, or any of its personnel, agents,
subcontractors, sub-consultants, service providers, suppliers and/or their employees to influence
the procurement process or contract execution for undue advantage is improper.
“Another party” refers to a public official acting in relation to the procurement process or contract
execution. In this context, “public official” includes World Bank staff and employees of other
organizations taking or reviewing procurement decisions.
7
“Party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement process
or contract execution; and the “act or omission” is intended to influence the procurement process
or contract execution.
8
“Parties” refers to participants in the procurement process (including public officials) attempting to
establish bid prices at artificial, non- competitive levels.
9
“Party” refers to a participant in the procurement process or contract execution.
10
collusive, coercive or obstructive practices in competing for the contract in
question;
(c)
will cancel the portion of the loan allocated to a contract if it determines at
any time that representatives of the Borrower or of a beneficiary of the loan
engaged in corrupt, fraudulent, collusive, or coercive practices during the
procurement or the execution of that contract, without the Borrower having
taken timely and appropriate action satisfactory to the Bank to address such
practices when they occur; and
(d)
will sanction a firm or an individual, at any time, in accordance with
prevailing Bank’s sanctions proceduresa, including by publicly declaring such
firm or individual ineligible, either indefinitely or for a stated period of
time:(i) to be awarded a Bank-financed contract; and (ii) to be a nominatedb
subcontractor, consultant, manufacturer or supplier, or service provider of an
otherwise eligible firm being awarded a Bank-financed contract.
3.2
In further pursuance of this policy, Bidders shall permit the Bank to inspect any
accounts and records and other documents relating to the Bid submission and contract
performance, and to have them audited by auditors appointed by the Bank.
3.3
Furthermore, Bidders shall be aware of the provision stated in Clause 9.8 and
Clause 41.2 in the General Conditions of Contract.
Clause ITB 4 (Eligible bidders):
The provision in ITB 4.3
is replaced with the following, including relevant footnotes:
4.3
Afirm that has been sanctioned by the Bank in accordance with the
above ITB Clause 3.1 (d), or in accordance with the Bank’s Guidelines on
Preventing and Combating Fraud and Corruption in Projects Financed by
IBRD Loans and IDA Credits and Grants, shall be ineligible to be awarded
a Bank-financed contract, or benefit from a Bank-financed contract,
financially or otherwise, during such period of time as the Bank shall
determine. The list of debarred firms is available at the electronic address
specified
in
the
BDS
(http://web.worldbank.org/external/default/main?theSitePK=8426
6&contentMDK=64069844&menuPK=116730&pagePK=641489
89&piPK=64148984).
CV Michael Weinhara
a
A firm or an individual may be declared ineligible to be awarded a Bank-financed contract upon
completion of the Bank’s sanctions proceedings as per its sanctions procedures, including inter
alia: (i) temporary suspension in connection with an ongoing sanctions proceeding; (ii) crossdebarment as agreed with other International Financial Institutions, including Multilateral
Development Banks; and (iii) the World Bank Group corporate administrative procurement
sanctions procedures for fraud and corruption.
b
A nominated sub-contractor, consultant, manufacturer or supplier, or service provider (different
names are used depending on the particular bidding document) is one whicheither has been:(i)
included by the bidder in its pre-qualification application or bid because it brings specific and
critical experience and know-how that are accounted for in the evaluation of the bidder’s prequalification application or the bid; or (ii) appointed by the Borrower.
Page 47
1.
2.
3.
4.
5.
6.
Family name:
WEINHARA
First names:
Michael
Date of birth:
23/07/1962
Nationality:
German
Civil Status:
Married, one daughter
Education:
Institution [ Date from - Date to ]
Degree(s) or Diploma(s) obtained:
Walden University, Baltimore,
M.Sc. Health Informatics
02.2012 – 03.2014
TÜV- Rheinland-Group Academy, Cologne, Auditor for Health Institutions
04.2005
Steinbeis Vocational University, European
EFQM Assessor
Federation for Quality Management, Berlin,
10.2004
Moody International IRCA Cert, Pforzheim, QMS Auditor/Lead Auditor, ISO 9001
04.2003
Management and Economy Academy,
B.A. Hospital Management
Kempten,
08.1996 – 07.1998
Centre of Advanced Vocational Education,
Staff-Management for Hospital Services
Munich,
10.1990 – 09.1992
School of Nursing, Kaufbeuren ,
Registered Nurse
09.1979 – 08.1982
7.
Language skills: Indicate competence on a scale of 1 to 5 (1 - excellent; 5 - basic)
Language
Reading
Speaking
Writing
German
native
native
native
English
1
1
1
Albanian
5
5
5
Bahasa Indonesia
5
5
5
8.
Membership of professional bodies: European Organisation for Quality EOQ, European
Institute for Health Records (EuroRec), German Association for Medical Informatics (gmds),
HL7,
9. Other skills: EHR architecture and functionality, Team leader for HIS implementing teams,
Hospital Planning experience, Hospital Budget Calculation, Lecturing experience, Training
Curriculum Development, Hospital Work Flow Analyses, FMEA experience, knowledge of
labour union work, Quality Management System implementation experience, MS Office
(expert knowledge), FTP, relational databases, Web-design, Adjudicator for Tonga Health
Hospital Information System Module purchases, Adjudicator for Supply and installation of
Equipment and Software for Moldova M-Cloud project.
10.
Present position: Team Leader for Hospital Construction and Capacity Building project
consultants
11.
Years within the firm: 5+ years
12.
Key qualifications:
 Senior consultant with 20 years of professional experience in hospital - and
hospital qualit y management, health information system development, of which
12 years of experience as technical adviser in development projects all over
the world
 Mayor focuses in consultancy, on:, ISO 9001 and EFQM compliant TOTAL
QUALITY MANAGEMENT S ystems, Technical Maintenance of Hospitals,
Workplace, Dut y-R oster and Job Description design, Hospital Information
Management, Human Resource Planning, Budget Calculation,
 Highl y knowledgably in WHO and other international qualit y standards











13.
Gaps and needs assessments as well as qualit y assessments as well as change
management and its’ pro cesses
Experience with Functional Hospital -layout planning, and user training in
hospital facilit y management
Experience in anal yse and updating of Nursing Education curricula, structured
nursing care planning and documentation.
Extensive experience in de velopment and implementation HMIS for all levels,
including applied Telemedicine.
Experience in analyse and upgrading of all processes related to hospital
management
Extensive experience in international medical coding system for primary,
secondary, terti ary level
Anal ysis of
management
structures, using performance indicators,
improvement of existing data collection structures, reduction of redundant data
collection structures
Extensive and practical working experience in capacit y building including
development and implementation of vocational trainings in comprehensive
qualit y management, nursing care, information management, resource planning,
of health facilities
Strong working experience in development of standard operational procedures,
job descriptions, and work flow planning.
Experience in enforcement of work place discipline.
Effective networking and negotiation, skills.
Specific experience in the region:
Country
Date
Country
Date
Uganda
1986 – 1987
Kosovo
2000 – 2006
Albania
2002
Vietnam
2003 – 2004 + 2010 – 2011
Indonesia
2005 – 2007
Syria
2006
Zambia
2007 – 2008
Serbia
2007 - 2008
Tajikistan
2010
Georgia
2009
Afghanistan
2008 – continuedPakistan
Page 49
2013 - 2014
14.
Date
08.2008
on-going
08.2013
03.2014
Professional experience:
Location
Afghanistan
Mazar-eSharif
Kunduz
Pakistan
Peshawar
Company and
Position
Team Leader
KfW German Development Bank
two projects
with overlap of
13 months.
EPOS,
Thomas Herzberg KfW North
Afghanistan
Thomas.Herzberg@kfw.de
AGEG Consultants / KfW German
Development
Bank
Clemens
Lässing c.laessing@ageg.de
Description
Management and coordination of a € 13 Mio intervention Reconstruction of a Province Hospital in Mazar-e Sharif. 16.000m² new construction surface,
with 360 beds. Overall project coordination between all involved parties, capacity building for the hospital management in all aspects of TQM, Budget
and HR planning for sustainable service quality. Completed and opened December 2011. In addition since Nov. 2010 Team Leader of a € 32 Mio, 3
Hospital reconstruction project in North Afghanistan, plus one remote basic health station. Quality control, development of maintenance structures,
introduction of applied Telemedicine and Tele-histopathology
Short term
consultant /
Team leader
Management of the support implementation for the national TB control programme, Supply of mobile health units, mother and child care, emergency care
supply, consulting service on logistics and project coordination with the Federal Administration of Tribal Areas (FATA) in North Waziristan, South
Waziristan and Khyber Pakhtunkhwa. € 5.3 Mio.
Short term
consultant /
Team leader
Short Term
Consultant
HMIS status assessment, inventory of work processes in data management at facility district, province hospitals and ministerial level:
Development of a strategic plan of action on HMIS with technical solutions at different levels in coop. with MoH, in application of the WHO/HMN
structures; Draft of ToR to tender a HMIS implementation program and required hardware.
Technical Assistance in the Development and Introduction of a Health Management Information System in Primary Health Care Centres,
Hospital Facilities and Oblast Health Departments. Focus on management indicators for primary and secondary facility managers and regional health
department managers. Review of Structural requirements for Data quality improvement.
Development of Policy Recommendations to support Development of Nursing Education; Assessment of the capacity of educational institutions
delivering nursing education; formulating recommendations for competencies, professional standards in nursing education; Formulating
recommendations for standards for institutions offering nursing education and required institutional change in the light of these new standards. Gap
analyses on Quality Management structures in nursing education institutions.
Technical Assistance to the Diagnostic Facilities and Blood Bank Directorate of the Ministry of Public Health of Afghanistan.
FATA
11.2010
–04.2011
02.2010
–
11.2010
04.2009
–
11.2009
Vietnam
Hanoi
Tajikistan
DushanbeKh
ujand
Georgia
Tbilisi
GFA Consulting Group
EC Delegation Director Medical
joachim.gromotka@gfa-group.de
Euro Health Group /World Bank
Marina Budeyeva Team Leader
m_budeyeva@yahoo.com
Sofreko, Conseil Santè , World
Bank Maia Gogashvili
University of Georgia Tbilisi
gogashvilim@yahoo.com
EPOS Health Management /
01.2010
–
12.2010
Afghanistan
Kabul
AFD French Development Bank
Roger Fergusson Team Leader ,
Roger.Ferguson@epos.de
12.2007
-02.08
Germany
Brandenburg
05.2007
07.2008
Serbia
05.2007
–
07.2008
Zambia
05.2005
to
10.2007
Indonesia
2005
2006
Germany
10.2006
11.2006
Syria
AWO Königswuster-hausen
Grit Marko head of TQM
Telephone: +4933755144 90
Euro Health Group
EAR Dr Matthias Reinicke Task
Manager Health, European Agency
for Reconstruction
mwreinicke@googlemail.com
CESO CI EUROPEAID/119860/
C/SV/multi Dr. Christopher
Simoonga Ministry of Health,
simoongachris@yahoo.com
Saniplan EU
IDN/AIDCO/2002/0409
Mr Philip Constable, Team Leader
p.740@btinternet.com
5 Lakeside, Darlington, Co
Durham, DL3 5TH, UK
TÜV Rheinland Group / LGA
InterCert Lead Auditor
Barbara-Wagemann@t-online.de
+491601490549
Options/GTZ/EPOS
funded by EU
(HSMP)SYR/AIDCO/2001/0215
Belgrade
Lusaka
Jakarta
Sumatra
Papua
Multiple
Damascus
Short Term
Consultant
Short Term
Consultant
Coordination between architect and relevant Departments of the Ministry of Urban development and the MoPH to receive approval for the construction
and functional design plans; Cooperation with Afghanistan Reconstruction and Development Services (ARDS) in tender preparation for construction
and supplies.
Consultant
Support and coaching of the management in the establishment and implementation of ISO 9001:2000 and EFQM compliant structures in a pensioner’s
home with 400 places at 4 locations in the region of Brandenburg.
Team Leader
Implementation of an Electronic Health Record (EHR) in Serbia: Overall responsibility for project management; technical assistance in the procurement
of services, equipment and works to be contracted separately from the TA contract; Development and quality assurance testing of system architecture,
software modules and databases; Deployment and integration of software modules and third party software components connectivity; Performance and
monitoring of the operating environment;
STE-Team
Leader
In-service and pre-service training needs assessment of HMIS, program staff at national provincial and district level;
Review of existing HMIS training programs at all levels; Development of pre- and in-service training programs for all levels of the health sector;
Support and monitoring of activities of HMIS pre- and in-service programs, at all levels;
HIS Expert
(short-term
200 days)
Health Information Systems for the project “Support to Community Health Services in South Sumatra, Jambi and Papua, Indonesia”: Series of 15 field
assignments to support the MoH Indonesia and District Health Directorates in 8 districts of Indonesia: Analysis of health information management
structures from primary care to the Ministry level under decentralisation; Development of life-long health record systems for hospitals and health
centres and pilot health record databases for 8 districts and 3 provinces; preparation of nation-wide roll-out; Definition of requirements for
hardware and software, based on international standards. Development of an ICD10 mapping table and reporting formats. Organisation of HIM, change
management, quality control, health record systems and statistics workshops.
External Auditor for Quality Systems (approx. 5 times per year) in private and public health institutions, and homes for the elderly; assessment for
TÜV Quality Certification meeting requirements of ISO 9001:2000 and EFQM. Stopped by time constraints in 2006.
First Quality Audit and follow up-visitations for Quality Management Certificate renewal at in-patient, ambulatory and homecare Health Facilities in
Germany.
Short-term consultant to the Ministry of Health Syria for the preparation of tender documents for hospital information systems for three hospitals
(Damascus, Daraa, and Latakkia: 500, 350, 200 beds) in Syria: Analysis of business processes (clinical, administrative), information structure, and
reporting process; Definition of functional requirements for a hospital management information system; Development of a training programme
Auditor
Short Term
Consultant
Hospital
02.2002
to
03.2006
Kosovo
02.2006
to
10.2006
Kosovo
11.2004
Vietnam
05.2003
to
11.2004
Pristina
Prizren
Vinh
Vietnam
HoChiMin
02.2002
-07.02
Albania
Bayram Curri
10.2001
01.2002
Kosovo
09.2000
09.2001
Kosovo
Prizren
10.1992
–
09.2000
Germany
Kempten
04.1990
-04.91
01.1988
- 03.90
08.1986
-09.87
Germany
Kaufbeuren
Germany
Kaufbeuren
Uganda
Yumbe
04.1985
07.1986
Germany
Füssen
02.198403.85
Germany
Munich
09.1982
- 09.85
Germany
Kaufbeuren
09.1982
-02.84
Germany
Pristina
Prof. Ulrich Laaser
University of Bielefeld
ulrich.laaser@uni-bielefeld.de
Bernard Brunhes International,
IRIS Conseil Santé, HLSP
Dr Matthias Reinicke Task
Manager Health, European Agency
for Reconstruction
mwreinicke@googlemail.com
SOFRECO / Grand Duchy of
Luxembourg YUG/00503229 A
Mike Lamb Team Leader Mobile
+44 (0) 7777685237
mikelamb230@hotmail.com
Child Health Dev. Project
Government of Finland
Team Leader, hvouri@hotmail.com
Saniplan
EU ALA/97/012
Ronald M. Bauer
Managing Director
Ronald M. Bauer
r.m.bauer@saniplan.de
HCC, (NGO) ECHO, FPA number
CCP N° 2000/0204 Dr Hristos
Dagres hdagres@gmail.com
Bernard Brunhes International
Dr Matthias Reinicke European
Agency for Reconstruction Task
Manager Health
mwreinicke@googlemail.com
Kinderberg International
Dr Uke Paloke Prizren Contact data
in search
University Teaching Hospital (650
beds)Renate Barn-steiner
renate.barnsteiner@klinikumkempten.de
District Hospital Nursing director
Harald.keller@bkh-kaufbeuren.de
District Hospital Nursing director
Harald.keller@bkh-kaufbeuren.de
Committee Cap Anamur NGO
Edith Fischnaller Espenweg 19,
53127Bonn +492282433785
Regional Hospital (180 beds)
Stadtbleiche 1 Füssen 08362 500-0
Mr Werner Huber
University Hospital
Marchioninistraße 15 Tel.
089/7095-0
Red Cross Emergency Service
Managing director
thomas.hofmann@kvostallgaeu.brk
.de
Marktoberdorf Regional Hospital
Elke.Rieger@kliniken-oal-kf.de
Information
Systems
200 trainees (9 months programme); Development of cost estimates for initial investment, training needs, follow-up and maintenance for hardware and
software
HIS Consultant
MoH,
Team
Leader
Support to the Ministry of Health for re-organisation and updating of the country’s health information system, including:
Health information system architecture; Information management; Procurement; and Training at health facility, Institute of Public Health and MoH
level, funded by EAR: SCRE/111164/D/S/KOS and 01/KOS01/10/002
Hospital
management
Series of short-term missions to support management of a hospital for the implementation of a quality management system, with emphasis on outpatient
management, patient and work flow, infrastructure management, and medical waste management
Training in internal process audits, risk analysis, and change management; implementation of a waste and hazard inventory and early risk warning
system (based on Waste Catalogue Ordinance 91/689/EEC, EU Directive on Hazardous Waste)
Expert
HIS/Audit
Consultant
Quality
Management
Consultant
HIS
Consultant
Training
Consultant
Assessment of clinical, management and IT services for a regional paediatric 350-beds hospital (Vinh Nghe An Province), in the context of a quality
audit. Analysis of management processes; Analyse of emergency preparedness and training requirements; Series of seminars to introduce international
quality management standards ISO 9001/2000 and the processes for ISO certification
Series of short-term missions to An Giang Province, Ba Rja Veng Tan Province, and Ho Chi Minh City, Vietnam
Development of a 5 year action plan for the MoH to implement comprehensive hospital patient care systems; Analysis of training needs for hospital staff
related to the management skills, HRM and total patient care ; Implementation of management training for middle level managers; Introduction of the
international standard ISO 9001:2000 as an instrument towards quality management in the health sector; Training for hospital managers in methods of
staff calculation based on performance indictors; Introduction of a comprehensive patient care and documentation system (bedside documentation)
Implementation of a hospital management information and documentation system. Definition of database requirements; support to, and supervision of
local database developers; Reorganization of hospital archives and introduction of comprehensive filing systems; Assessment of service quality in the
provincial hospital.
Management training for hospital and health facility managers (300 course participants, from 70 facilities) for all health facilities of Kosovo;
Development of job and workplace descriptions, methods for work flow observation in health facilities; Quality control and quality management;
Funded by EAR: EuropeAid/117556/D/SV/KOS
Medical
Coordinator
660 Bed Regional Hospital, implementation of an integrated in-patient documentation system, needs assessment and organisation of training for
emergency preparedness, improvement of facility management, services for the paediatric department. Preparation of technical specifications for
equipment purchase, refurbishment of wards, floor, sanitary units; supervision of refurbishment works
Deputy
Director of
Nursing
Services
Assistant
Lecturer
Dep. Head
Nurse
Registered
Nurse
Coordination of merging two local hospitals under full operational condition; Permanent, administrative responsibility for 160, as deputy for 600 medical
and nursing staff: Staff planning and budgeting based on performance indicators according to the legal framework with the health insurances.
Chairman of IT evaluation and planning committees for the implementation of new working schedules. Introduction of quality assurance systems for
clinical care standards; Coordination of emergency drills, GAP analyses.
Kaufbeuren School of Nursing: Lecturer in general nursing. Research of medical information. On-the-job training for nursing students.
Theatre / ICU
Nurse
Five operating theatres: day-to-day routine in use of surgical and gynaecological equipment, anaesthesia and emergency equipment. In charge of
maintenance of anaesthesia machines and all emergency equipment
ICU / Nurse
Munich University Hospital (1200 beds): Cardio-Surgical ICU 10 beds. Member of the heart transplant team.
Emergency
medical
technician
Team leader on fully equipped mobile Emergency and mobile ICU vehicles. Trainer for emergency and resuscitation procedures; Special driving licence
for emergency vehicles; Voluntarily work on free days, at weekends at night.
General Nurse
Marktoberdorf Regional Hospital (250 beds): ICU 5 beds, general care of all surgical and internal medicine patients
Kaufbeuren District Hospital (700 beds): Staff planning. Refurbishment and investment planning. Management of day-to-day business for a 35-bed male
ward for acute psychiatric diseases
Emergency support to a 100-beds hospital of 100 beds under civil war conditions. Medical service to UNHCR refugee camps under emergency
circumstances. Training of paramedical staff in hygiene. Development of treatment protocols
3
2009
WHO network access to HINARI online medical library for Regional Hospital
Mazar-e-Sharif.
2009
Co-moderator supporting the Afghan participants of the telepathology
network server at Basel University for a tele-histopathology cooperation
2003
Lecturer at the Economic Faculty Pristina, MBA Seminar Management in
Public Health on Health Information Systems
2004
Lecturer at the Medical Faculty HoChiMinh City on hospital information
management
1997/1999
Lecturer at the CTT-Academia Trier / Weiskirchen on: staff calculation;
planning and management of staff in hospitals and nursing homes; preparation
and execution of change management processes
1997/1998
Country tutor for Uganda at the ASA Program, an exchange programme for
young professionals and students founded by the German Ministry of foreign
affairs.
1994/1998
Member of the hospital workers committee
1993/1998
Lecturer at the Munich Centre for Advanced Vocational Education on hospital
administration and managerial economics for nursing home managers and
managers of ambulatory nursing-care organizations and on staff calculation by
use of different indicators.
1979/2004
Member of the German Labour Union for the public sector
Publications/Speeches (Author/Co-author):
2012
NATO Advanced Research Workshop Kabul “Creating Awareness for the Use of
Open Source Systems in the Public Sector in Afghanistan”
2009 “Early Stage Testing of Users’ Satisfaction. After Implementation of a Central
Electronic Health Record
(EHR) System in Serbia” The Journal on Information Technology in Healthcare
2009; 7(2)
2009 “Interoperability, Integration and Risk Management in Creating Electronic Health
Records: Serbia’s Approach”
The Journal on Information Technology in Healthcare Volume 7 Issue 2 2009
2009 “Planning a new hospital in Afghanistan, the balancing act between Stone Age and
21st century high tech”
4
Section II. Bid Data Sheet
NATO Regional Command North - International Security and Assistance Force
(ISAF) – Camp Marmal Afghanistan
2008 “Electronic Health Records in Serbia, EU-Funded Project Delivers Results of Wider
Interest”, Hospital Post
Europe 5/2008
2008 “Approach and risks of EHR’s interoperability and integration with legacy healthcare
ICT systems” 6th ICICTH
Conference Samos Island - Greece
2008 “Design and implementation of a central electronic health record in Serbia: Early
stage testing of Users’
satisfaction” 6th ICICTH Conference Samos Island - Greece
2008 “Electronic Health Record – Opportunities for the future in the Serbian Health
System”, National Conference on
Electronic Health Records, Belgrade - Serbia
2008 “Electronic health records – What can be done with it for a capitation system?”
National conference for the
capitation system, European Agency for Reconstruction, Belgrade- Serbia
2007 “Health Information System development in rural areas in Indonesia” National
Conference for Health Information
Systems SCHS Project Jakarta - Indonesia
2006 “Outsourcing Health Information Systems, an Option for Developing Countries”. 4th
ICICTH Conference Samos
Island - Greece
2001 “How telemedicine could contribute to the stabilisation of South-East-Europe”.
American Telemedicine
Association - Fort Lauderdale - USA
1998 “Legal consequences of the implementation of protocols for patient care in hospitals”.
“Klinik Info” Bavaria,
Landkreis Oberallgäu, Germany
Michael Weinhara
5
SECTION III. ELIGIBLE COUNTRIES FOR THE PROVISION OF
GOODS, WORKS, AND SERVICES IN BANK-FINANCED
PROCUREMENT
Eligible Countries for the Provision of Goods, Works and Services in Bank-Financed
Procurement
As of September 2007
1. Eligible for this procurement are the firms of, and goods manufactured in, all countries
except countries, if any, listed in the following restrictions.
2.
In accordance with Para 1.8 (a) of the Guidelines: Procurement under IBRD Loans
and IDA Credits, dated May 2004, the Bank permits firms and individuals from all countries
to offer goods, works and services for Bank-financed projects. As an exception, firms of a
Country or goods manufactured in a Country may be excluded if:
(i): as a matter of law or official regulation, the Borrower’s Country prohibits
commercial relations with that Country, provided that the Bank is satisfied
that such exclusion does not preclude effective competition for the supply of
the Goods or Works required, or
(ii): by an Act of Compliance with a Decision of the United Nations Security Council
taken under Chapter VII of the Charter of the United Nations, the Borrower’s
Country prohibits any import of goods from that Country or any payments to
persons or entities in that Country.
3.
For the information of borrowers and bidders, at the present time firms, goods and
services from the following countries are excluded from this bidding:
(a)
With reference to paragraph 1.8 (a) (i) of the Guidelines:
None
(b)
None
With reference to paragraph 1.8 (a) (ii) of the Guidelines:
6
Section IV. General Conditions of Contract
SECTION IV. GENERAL CONDITIONS OF CONTRACT
Table of Clauses
A. Contract and Interpretation .............................................................................................8
1.
2.
3.
4.
5.
6.
Definitions...................................................................................................................8
Contract Documents..................................................................................................16
Interpretation .............................................................................................................16
Notices ......................................................................................................................18
Governing Law .........................................................................................................19
Settlement of Disputes ..............................................................................................20
B. Subject Matter of Contract .............................................................................................22
7.
8.
9.
10.
Scope of the System ..................................................................................................22
Time for Commencement and Operational Acceptance ...........................................22
Supplier’s Responsibilities........................................................................................23
Purchaser’s Responsibilities .....................................................................................25
C. Payment.............................................................................................................................27
11.
12.
13.
14.
Contract Price............................................................................................................27
Terms of Payment .....................................................................................................27
Securities ...................................................................................................................28
Taxes and Duties .......................................................................................................29
D. Intellectual Property ........................................................................................................30
15. Copyright ..................................................................................................................30
16. Software License Agreements ..................................................................................31
17. Confidential Information ..........................................................................................33
E. Supply, Installation, Testing, Commissioning, and Acceptance of the System ..........34
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
Representatives .........................................................................................................34
Project Plan ...............................................................................................................36
Subcontracting ..........................................................................................................37
Design and Engineering ............................................................................................38
Procurement, Delivery, and Transport ......................................................................41
Product Upgrades ......................................................................................................43
Implementation, Installation, and Other Services .....................................................44
Inspections and Tests ................................................................................................44
Installation of the System..........................................................................................45
Commissioning and Operational Acceptance ...........................................................46
F. Guarantees and Liabilities ...............................................................................................50
28. Operational Acceptance Time Guarantee .................................................................50
29. Defect Liability .........................................................................................................51
Section IV. General Conditions of Contract
30.
31.
32.
33.
7
Functional Guarantees ..............................................................................................54
Intellectual Property Rights Warranty ......................................................................54
Intellectual Property Rights Indemnity .....................................................................55
Limitation of Liability...............................................................................................58
G. Risk Distribution ..............................................................................................................58
34.
35.
36.
37.
38.
Transfer of Ownership ..............................................................................................58
Care of the System ....................................................................................................58
Loss of or Damage to Property; Accident or Injury to Workers; Indemnification ...59
Insurances .................................................................................................................61
Force Majeure ...........................................................................................................63
H. Change in Contract Elements .........................................................................................65
39.
40.
41.
42.
Changes to the System ..............................................................................................65
Extension of Time for Achieving Operational Acceptance ......................................69
Termination ...............................................................................................................70
Assignment ...............................................................................................................78
8
Section IV. General Conditions of Contract
General Conditions of Contract
A. CONTRACT AND INTERPRETATION
1. Definitions
1.1
In this Contract, the following terms shall be interpreted as
indicated below.
(a)
contract elements
(i)
“Contract” means the Contract Agreement
entered into between the Purchaser and the
Supplier, together with the Contract Documents
referred to therein. The Contract Agreement and
the Contract Documents shall constitute the
Contract, and the term “the Contract” shall in all
such documents be construed accordingly.
(ii)
“Contract Documents” means the documents
specified in Article 1.1 (Contract Documents) of
the Contract Agreement (including any
amendments to these Documents).
(iii) “Contract Agreement” means the agreement
entered into between the Purchaser and the
Supplier using the form of Contract Agreement
contained in the Sample Forms Section of the
Bidding Documents and any modifications to
this form agreed to by the Purchaser and the
Supplier. The date of the Contract Agreement
shall be recorded in the signed form.
(iv) “GCC” means the General Conditions of
Contract.
(v)
“SCC” means the Special Conditions of
Contract.
(vi) “Technical Requirements” means the Technical
Requirements Section of the Bidding
Documents.
(vii) “Implementation
Schedule”
means
the
Implementation Schedule Sub-section of the
Technical Requirements.
viii) “Contract Price” means the price or prices
defined in Article 2 (Contract Price and Terms
of Payment) of the Contract Agreement.
Section IV. General Conditions of Contract
9
(ix) “Procurement Guidelines” refers to the edition
specified in the SCC of the World Bank
Guidelines: Procurement under IBRD Loans and
IDA Credits.
(x)
(b)
“Bidding Documents” refers to the collection of
documents issued by the Purchaser to instruct
and inform potential suppliers of the processes
for bidding, selection of the winning bid, and
Contract formation, as well as the contractual
conditions governing the relationship between
the Purchaser and the Supplier. The General and
Special Conditions of Contract, the Technical
Requirements, and all other documents included
in the Bidding Documents reflect the
Procurement Guidelines that the Purchaser is
obligated to follow during procurement and
administration of this Contract.
entities
(i)
“Purchaser” means the entity purchasing the
Information System, as specified in the SCC.
(ii)
“Project Manager” means the person named as
such in the SCC or otherwise appointed by the
Purchaser in the manner provided in GCC
Clause 18.1 (Project Manager) to perform the
duties delegated by the Purchaser.
(iii) “Supplier” means the firm or Joint Venture
whose bid to perform the Contract has been
accepted by the Purchaser and is named as such
in the Contract Agreement.
(iv) “Supplier’s Representative” means any person
nominated by the Supplier and named as such in
the Contract Agreement or otherwise approved
by the Purchaser in the manner provided in GCC
Clause 18.2 (Supplier’s Representative) to
perform the duties delegated by the Supplier.
(v)
“Subcontractor” means any firm to whom any of
the obligations of the Supplier, including
preparation of any design or supply of any
Information Technologies or other Goods or
Services, is subcontracted directly or indirectly
10
Section IV. General Conditions of Contract
by the Supplier.
(vi) “Adjudicator” means the person named in
Appendix 2 of the Contract Agreement,
appointed by agreement between the Purchaser
and the Supplier to make a decision on or to
settle any dispute between the Purchaser and the
Supplier referred to him or her by the parties,
pursuant to GCC Clause 6.1 (Adjudication).
(vii) “The World Bank” (also called “The Bank”)
means the International Bank for Reconstruction
and Development (IBRD) or the International
Development Association (IDA).
(c)
scope
(i)
“Information System,” also called “the System,”
means all the Information Technologies,
Materials, and other Goods to be supplied,
installed, integrated, and made operational
(exclusive of the Supplier’s Equipment),
together with the Services to be carried out by
the Supplier under the Contract.
(ii)
“Subsystem” means any subset of the System
identified as such in the Contract that may be
supplied, installed, tested, and commissioned
individually before Commissioning of the
entire System.
(iii)
“Information
Technologies”
means
all
information processing and communicationsrelated hardware, Software, supplies, and
consumable items that the Supplier is required
to supply and install under the Contract.
(iv)
“Goods” means all equipment, machinery,
furnishings, Materials, and other tangible items
that the Supplier is required to supply or supply
and install under the Contract, including,
without
limitation,
the
Information
Technologies and Materials, but excluding the
Supplier’s Equipment.
(v)
“Services” means all technical, logistical,
management, and any other Services to be
provided by the Supplier under the Contract to
Section IV. General Conditions of Contract
11
supply, install, customize, integrate, and make
operational the System. Such Services may
include, but are not restricted to, activity
management and quality assurance, design,
development, customization, documentation,
transportation,
insurance,
inspection,
expediting, site preparation, installation,
integration, training, data migration, Precommissioning, Commissioning, maintenance,
and technical support.
(vi)
“The Project Plan” means the document to be
developed by the Supplier and approved by the
Purchaser, pursuant to GCC Clause 19, based
on the requirements of the Contract and the
Preliminary Project Plan included in the
Supplier’s bid. The “Agreed and Finalized
Project Plan” is the version of the Project Plan
approved by the Purchaser, in accordance with
GCC Clause 19.2. Should the Project Plan
conflict with the Contract in any way, the
relevant provisions of the Contract, including
any amendments, shall prevail.
(vii) “Software” means that part of the System
which are instructions that cause information
processing Subsystems to perform in a specific
manner or execute specific operations.
(viii) “System Software” means Software that provides
the operating and management instructions for the
underlying hardware and other components, and
is identified as such in Appendix 4 of the Contract
Agreement and such other Software as the parties
may agree in writing to be Systems Software.
Such System Software includes, but is not
restricted to, micro-code embedded in hardware
(i.e.,
“firmware”),
operating
systems,
communications,
system
and
network
management, and utility software.
(ix)
“General-Purpose Software” means Software
that supports general-purpose office and
software development activities and is
identified as such in Appendix 4 of the Contract
Agreement and such other Software as the
parties may agree in writing to be General-
12
Section IV. General Conditions of Contract
Purpose Software.
Such General-Purpose
Software may include, but is not restricted to,
word processing, spreadsheet, generic database
management, and application development
software.
(x)
“Application Software” means Software
formulated to perform specific business or
technical functions and interface with the
business or technical users of the System and is
identified as such in Appendix 4 of the Contract
Agreement and such other Software as the
parties may agree in writing to be Application
Software.
(xi)
“Standard Software” means Software identified
as such in Appendix 4 of the Contract
Agreement and such other Software as the
parties may agree in writing to be Standard
Software.
(xii) “Custom Software” means Software identified as
such in Appendix 4 of the Contract Agreement
and such other Software as the parties may agree
in writing to be Custom Software.
(xiii) “Source Code” means the database structures,
dictionaries, definitions, program source files,
and any other symbolic representations
necessary for the compilation, execution, and
subsequent maintenance of the Software
(typically, but not exclusively, required for
Custom Software).
(xiv) “Materials” means all documentation in printed
or printable form and all instructional and
informational aides in any form (including
audio, video, and text) and on any medium,
provided to the Purchaser under the Contract.
(xv) “Standard Materials” means all Materials not
specified as Custom Materials.
(xvi) “Custom Materials” means Materials developed
by the Supplier at the Purchaser’s expense under
the Contract and identified as such in Appendix 5
of the Contract Agreement and such other
Materials as the parties may agree in writing to be
Section IV. General Conditions of Contract
13
Custom Materials. Custom Materials includes
Materials created from Standard Materials.
(xvii) “Intellectual Property Rights” means any and
all copyright, moral rights, trademark, patent,
and other intellectual and proprietary rights,
title and interests worldwide, whether vested,
contingent, or future, including without
limitation all economic rights and all exclusive
rights to reproduce, fix, adapt, modify,
translate, create derivative works from, extract
or re-utilize data from, manufacture, introduce
into circulation, publish, distribute, sell, license,
sublicense, transfer, rent, lease, transmit or
provide access electronically, broadcast,
display, enter into computer memory, or
otherwise use any portion or copy, in whole or
in part, in any form, directly or indirectly, or to
authorize or assign others to do so.
(xviii) “Supplier’s Equipment” means all equipment,
tools, apparatus, or things of every kind
required in or for installation, completion and
maintenance of the System that are to be
provided by the Supplier, but excluding the
Information Technologies, or other items
forming part of the System.
(d)
activities
(i)
“Delivery” means the transfer of the Goods from
the Supplier to the Purchaser in accordance with
the current edition Incoterms specified in the
Contract.
(ii)
“Installation” means that the System or a
Subsystem as specified in the Contract is ready
for Commissioning as provided in GCC Clause
26 (Installation).
(iii) “Pre-commissioning” means the testing, checking,
and any other required activity that may be
specified in the Technical Requirements that are to
be carried out by the Supplier in preparation for
Commissioning of the System as provided in GCC
Clause 26 (Installation).
(iv) “Commissioning”
means
operation
of
the
14
Section IV. General Conditions of Contract
System or any Subsystem by the Supplier
following Installation, which operation is to be
carried out by the Supplier as provided in GCC
Clause 27.1 (Commissioning), for the purpose of
carrying out Operational Acceptance Test(s).
(v)
“Operational Acceptance Tests” means the tests
specified in the Technical Requirements and
Agreed and Finalized Project Plan to be carried
out to ascertain whether the System, or a
specified Subsystem, is able to attain the
functional and performance requirements
specified in the Technical Requirements and
Agreed and Finalized Project Plan, in
accordance with the provisions of GCC Clause
27.2 (Operational Acceptance Test).
(vi) “Operational Acceptance” means the acceptance
by the Purchaser of the System (or any
Subsystem(s) where the Contract provides for
acceptance of the System in parts), in
accordance with GCC Clause 27.3 (Operational
Acceptance).
(e)
place and time
(i)
“Purchaser’s Country” is the country named in
the SCC.
(ii)
“Supplier’s Country” is the country in which the
Supplier is legally organized, as named in the
Contract Agreement.
(iii)
“Project Site(s)” means the place(s) specified in
the SCC for the supply and installation of the
System.
(iv) “Eligible Country” means the countries and
territories eligible for participation in
procurements financed by the World Bank as
defined in the Procurement Guidelines. (Note:
The World Bank maintains a list of countries
from which Bidders, Goods, and Services are
not eligible to participate in procurement
financed by the Bank. The list is regularly
updated and can be obtained from the Public
Information Center of the Bank or its web site
on procurement. A copy of the list is contained
Section IV. General Conditions of Contract
15
in the Section of the Bidding Documents entitled
“Eligible Countries for the Provision of Goods,
Works, and Services in Bank-Financed
Procurement”).
(v)
“Day” means calendar day of the Gregorian
Calendar.
(vi) “Week” means seven (7) consecutive Days,
beginning the day of the week as is customary in
the Purchaser’s Country.
(vii) “Month” means calendar month of the Gregorian
Calendar.
(viii) “Year” means twelve (12) consecutive Months.
(ix) “Effective Date” means the date of fulfillment of
all conditions specified in Article 3 (Effective
Date for Determining Time for Achieving
Operational Acceptance) of the Contract
Agreement, for the purpose of determining the
Delivery,
Installation,
and
Operational
Acceptance dates for the System or
Subsystem(s).
(x)
“Contract Period” is the time period during
which this Contract governs the relations and
obligations of the Purchaser and Supplier in
relation to the System, as specified in the SCC.
(xi) “Defect Liability Period” (also referred to as the
“Warranty Period”) means the period of validity
of the warranties given by the Supplier
commencing at date of the Operational
Acceptance Certificate of the System or
Subsystem(s), during which the Supplier is
responsible for defects with respect to the
System (or the relevant Subsystem[s]) as
provided in GCC Clause 29 (Defect Liability).
(xii) “The Post-Warranty Services Period” means the
number of years defined in the SCC (if any),
following the expiration of the Warranty Period
during which the Supplier may be obligated to
provide Software licenses, maintenance, and/or
technical support services for the System, either
under this Contract or under separate contract(s).
16
Section IV. General Conditions of Contract
(xiii) “The Coverage Period” means the Days of the
Week and the hours of those Days during which
maintenance, operational, and/or technical
support services (if any) must be available.
2. Contract
Documents
2.1
Subject to Article 1.2 (Order of Precedence) of the Contract
Agreement, all documents forming part of the Contract (and
all parts of these documents) are intended to be correlative,
complementary, and mutually explanatory. The Contract
shall be read as a whole.
3. Interpretation
3.1
Governing Language
3.1.1 All Contract Documents and related correspondence
exchanged between Purchaser and Supplier shall be
written in the language specified in the SCC, and the
Contract shall be construed and interpreted in
accordance with that language.
3.1.2 If any of the Contract Documents or related
correspondence are prepared in a language other than
the governing language under GCC Clause 3.1.1
above, the translation of such documents into the
governing language shall prevail in matters of
interpretation. The originating party, with respect to
such documents shall bear the costs and risks of such
translation.
3.2
Singular and Plural
The singular shall include the plural and the plural the
singular, except where the context otherwise requires.
3.3
Headings
The headings and marginal notes in the GCC are included
for ease of reference and shall neither constitute a part of
the Contract nor affect its interpretation.
3.4
Persons
Words importing persons or parties shall include firms,
corporations, and government entities.
3.5
Incoterms
Unless inconsistent with any provision of the Contract, the
meaning of any trade term and the rights and obligations of
parties thereunder shall be as prescribed by the current
Incoterms (“Incoterms 2000” or a more recent version if
Section IV. General Conditions of Contract
17
and as published). Incoterms are the international rules for
interpreting trade terms published by the International
Chamber of Commerce, 38 Cours Albert 1er, 75008 Paris,
France.
3.6
Entire Agreement
The Contract constitutes the entire agreement between the
Purchaser and Supplier with respect to the subject matter of
Contract and supersedes all communications, negotiations,
and agreements (whether written or oral) of parties with
respect to the subject matter of the Contract made prior to
the date of Contract.
3.7
Amendment
No amendment or other variation of the Contract shall be
effective unless it is in writing, is dated, expressly refers to
the Contract, and is signed by a duly authorized
representative of each party to the Contract.
3.8
Independent Supplier
The Supplier shall be an independent contractor performing
the Contract. The Contract does not create any agency,
partnership, joint venture, or other joint relationship
between the parties to the Contract.
Subject to the provisions of the Contract, the Supplier shall
be solely responsible for the manner in which the Contract
is performed.
All employees, representatives, or
Subcontractors engaged by the Supplier in connection with
the performance of the Contract shall be under the complete
control of the Supplier and shall not be deemed to be
employees of the Purchaser, and nothing contained in the
Contract or in any subcontract awarded by the Supplier
shall be construed to create any contractual relationship
between any such employees, representatives, or
Subcontractors and the Purchaser.
3.9
Joint Venture
If the Supplier is a Joint Venture of two or more firms, all
such firms shall be jointly and severally bound to the
Purchaser for the fulfillment of the provisions of the
Contract and shall designate one of such firms to act as a
leader with authority to bind the Joint Venture. The
composition or constitution of the Joint Venture shall not be
18
Section IV. General Conditions of Contract
altered without the prior consent of the Purchaser.
3.10 Nonwaiver
3.10.1 Subject to GCC Clause 3.10.2 below, no relaxation,
forbearance, delay, or indulgence by either party in
enforcing any of the terms and conditions of the
Contract or the granting of time by either party to
the other shall prejudice, affect, or restrict the rights
of that party under the Contract, nor shall any
waiver by either party of any breach of Contract
operate as waiver of any subsequent or continuing
breach of Contract.
3.10.2 Any waiver of a party’s rights, powers, or remedies
under the Contract must be in writing, must be dated
and signed by an authorized representative of the
party granting such waiver, and must specify the
right and the extent to which it is being waived.
3.11 Severability
If any provision or condition of the Contract is prohibited or
rendered invalid or unenforceable, such prohibition,
invalidity, or unenforceability shall not affect the validity or
enforceability of any other provisions and conditions of the
Contract.
3.12 Country of Origin
“Origin” means the place where the Information
Technologies, Materials, and other Goods for the System
were produced or from which the Services are supplied.
Goods are produced when, through manufacturing,
processing, Software development, or substantial and major
assembly or integration of components, a commercially
recognized product results that is substantially different in
basic characteristics or in purpose or utility from its
components. The Origin of Goods and Services is distinct
from the nationality of the Supplier and may be different.
4. Notices
4.1
Unless otherwise stated in the Contract, all notices to be
given under the Contract shall be in writing and shall be
sent, pursuant to GCC Clause 4.3 below, by personal
delivery, airmail post, special courier, cable, telegraph,
telex, facsimile, electronic mail, or Electronic Data
Interchange (EDI), with the following provisions.
4.1.1 Any notice sent by cable, telegraph, telex, facsimile,
Section IV. General Conditions of Contract
19
electronic mail, or EDI shall be confirmed within two
(2) days after dispatch by notice sent by airmail post
or special courier, except as otherwise specified in the
Contract.
4.1.2 Any notice sent by airmail post or special courier shall
be deemed (in the absence of evidence of earlier
receipt) to have been delivered ten (10) days after
dispatch. In proving the fact of dispatch, it shall be
sufficient to show that the envelope containing such
notice was properly addressed, stamped, and
conveyed to the postal authorities or courier service
for transmission by airmail or special courier.
4.1.3 Any notice delivered personally or sent by cable,
telegraph, telex, facsimile, electronic mail, or EDI
shall be deemed to have been delivered on the date of
its dispatch.
4.1.4 Either party may change its postal, cable, telex,
facsimile, electronic mail, or EDI addresses for receipt
of such notices by ten (10) days’ notice to the other
party in writing.
5. Governing Law
4.2
Notices shall be deemed to include any approvals, consents,
instructions, orders, certificates, information and other
communication to be given under the Contract.
4.3
Pursuant to GCC Clause 18, notices from/to the Purchaser
are normally given by, or addressed to, the Project
Manager, while notices from/to the Supplier are normally
given by, or addressed to, the Supplier's Representative, or
in its absence its deputy if any. If there is no appointed
Project Manager or Supplier's Representative (or deputy),
or if their related authority is limited by the SCC for GCC
Clauses 18.1 or 18.2.2, or for any other reason, the
Purchaser or Supplier may give and receive notices at their
fallback addresses. The address of the Project Manager and
the fallback address of the Purchaser are as specified in the
SCC or as subsequently established/amended. The address
of the Supplier's Representative and the fallback address of
the Supplier are as specified in Appendix 1 of the Contract
Agreement or as subsequently established/amended.
5.1
The Contract shall be governed by and interpreted in
accordance with the laws of the country specified in the
SCC.
20
6. Settlement of
Disputes
Section IV. General Conditions of Contract
6.1
Adjudication
6.1.1 If any dispute of any kind whatsoever shall arise
between the Purchaser and the Supplier in connection
with or arising out of the Contract, including without
prejudice to the generality of the foregoing, any
question regarding its existence, validity, or
termination, or the operation of the System (whether
during the progress of implementation or after its
achieving Operational Acceptance and whether before
or after the termination, abandonment, or breach of
the Contract), the parties shall seek to resolve any
such dispute by mutual consultation. If the parties fail
to resolve such a dispute by mutual consultation
within fourteen (14) days after one party has notified
the other in writing of the dispute, then, if the
Contract Agreement in Appendix 2 includes and
names an Adjudicator, the dispute shall, within
another fourteen (14) days, be referred in writing by
either party to the Adjudicator, with a copy to the
other party. If there is no Adjudicator specified in the
Contract Agreement, the mutual consultation period
stated above shall last twenty-eight (28) days (instead
of fourteen), upon expiry of which either party may
move to the notification of arbitration pursuant to
GCC Clause 6.2.1.
6.1.2 The Adjudicator shall give his or her decision in
writing to both parties within twenty-eight (28) days
of the dispute being referred to the Adjudicator. If the
Adjudicator has done so, and no notice of intention to
commence arbitration has been given by either the
Purchaser or the Supplier within fifty-six (56) days of
such reference, the decision shall become final and
binding upon the Purchaser and the Supplier. Any
decision that has become final and binding shall be
implemented by the parties forthwith.
6.1.3 The Adjudicator shall be paid an hourly fee at the rate
specified in the Contract Agreement plus reasonable
expenditures incurred in the execution of duties as
Adjudicator, and these costs shall be divided equally
between the Purchaser and the Supplier.
6.1.4 Should the Adjudicator resign or die, or should the
Purchaser and the Supplier agree that the Adjudicator
is not fulfilling his or her functions in accordance with
Section IV. General Conditions of Contract
21
the provisions of the Contract, a new Adjudicator
shall be jointly appointed by the Purchaser and the
Supplier. Failing agreement between the two within
twenty-eight (28) days, the new Adjudicator shall be
appointed at the request of either party by the
Appointing Authority specified in the SCC, or, if no
Appointing Authority is specified in SCC, the
Contract shall, from this point onward and until the
parties may otherwise agree on an Adjudicator or an
Appointing Authority, be implemented as if there is
no Adjudicator.
6.2
Arbitration
6.2.1 If
(a) the Purchaser or the Supplier is dissatisfied with
the Adjudicator’s decision and acts before this
decision has become final and binding pursuant
to GCC Clause 6.1.2, or
(b) the Adjudicator fails to give a decision within the
allotted time from referral of the dispute pursuant
to GCC Clause 6.1.2, and the Purchaser or the
Supplier acts within the following fourteen (14)
days, or
(c) in the absence of an Adjudicator from the
Contract Agreement, the mutual consultation
pursuant to GCC Clause 6.1.1 expires without
resolution of the dispute and the Purchaser or the
Supplier acts within the following fourteen (14)
days,
then either the Purchaser or the Supplier may act to
give notice to the other party, with a copy for
information to the Adjudicator in case an Adjudicator
had been involved, of its intention to commence
arbitration, as provided below, as to the matter in
dispute, and no arbitration in respect of this matter
may be commenced unless such notice is given.
6.2.2 Any dispute in respect of which a notice of intention
to commence arbitration has been given, in
accordance with GCC Clause 6.2.1, shall be finally
settled by arbitration. Arbitration may be commenced
prior to or after Installation of the Information System.
22
Section IV. General Conditions of Contract
6.2.3 Arbitration proceedings shall be conducted in
accordance with the rules of procedure specified in
the SCC.
6.3
Notwithstanding any reference to the Adjudicator or
arbitration in this clause,
(a)
the parties shall continue to perform their respective
obligations under the Contract unless they otherwise
agree;
(b)
the Purchaser shall pay the Supplier any monies due
the Supplier.
B. SUBJECT MATTER OF CONTRACT
7. Scope of the
System
8. Time for
Commencement
and Operational
Acceptance
7.1
Unless otherwise expressly limited in the SCC or Technical
Requirements, the Supplier’s obligations cover the provision
of all Information Technologies, Materials and other Goods
as well as the performance of all Services required for the
design, development, and implementation (including
procurement, quality assurance, assembly, associated site
preparation, Delivery, Pre-commissioning, Installation,
Testing, and Commissioning) of the System, in accordance
with the plans, procedures, specifications, drawings, codes,
and any other documents specified in the Contract and the
Agreed and Finalized Project Plan.
7.2
The Supplier shall, unless specifically excluded in the
Contract, perform all such work and / or supply all such
items and Materials not specifically mentioned in the
Contract but that can be reasonably inferred from the
Contract as being required for attaining Operational
Acceptance of the System as if such work and / or items and
Materials were expressly mentioned in the Contract.
7.3
The Supplier’s obligations (if any) to provide Goods and
Services as implied by the Recurrent Cost tables of the
Supplier’s bid, such as consumables, spare parts, and
technical services (e.g., maintenance, technical assistance,
and operational support), are as specified in the SCC,
including the relevant terms, characteristics, and timings.
8.1
The Supplier shall commence work on the System within the
period specified in the SCC, and without prejudice to GCC
Clause 28.2, the Supplier shall thereafter proceed with the
System in accordance with the time schedule specified in the
Section IV. General Conditions of Contract
23
Implementation Schedule in the Technical Requirements
Section and any refinements made in the Agreed and
Finalized Project Plan.
9. Supplier’s
Responsibilities
8.2
The Supplier shall achieve Operational Acceptance of the
System (or Subsystem(s) where a separate time for
Operational Acceptance of such Subsystem(s) is specified in
the Contract) within the time specified in the SCC and in
accordance with the time schedule specified in the
Implementation Schedule in the Technical Requirements
Section and any refinements made in the Agreed and
Finalized Project Plan, or within such extended time to
which the Supplier shall be entitled under GCC Clause 40
(Extension of Time for Achieving Operational Acceptance).
9.1
The Supplier shall conduct all activities with due care and
diligence, in accordance with the Contract and with the skill
and care expected of a competent provider of information
technologies, information systems, support, maintenance,
training, and other related services, or in accordance with
best industry practices. In particular, the Supplier shall
provide and employ only technical personnel who are skilled
and experienced in their respective callings and supervisory
staff who are competent to adequately supervise the work at
hand.
9.2
The Supplier confirms that it has entered into this Contract
on the basis of a proper examination of the data relating to
the System provided by the Purchaser and on the basis of
information that the Supplier could have obtained from a
visual inspection of the site (if access to the site was
available) and of other data readily available to the Supplier
relating to the System as at the date twenty-eight (28) days
prior to bid submission. The Supplier acknowledges that any
failure to acquaint itself with all such data and information
shall not relieve its responsibility for properly estimating the
difficulty or cost of successfully performing the Contract.
9.3
The Supplier shall be responsible for timely provision of all
resources, information, and decision making under its
control that are necessary to reach a mutually Agreed and
Finalized Project Plan (pursuant to GCC Clause 19.2) within
the time schedule specified in the Implementation Schedule
in the Technical Requirements Section. Failure to provide
such resources, information, and decision making may
constitute grounds for termination pursuant to GCC
Clause 41.2.
24
Section IV. General Conditions of Contract
9.4
The Supplier shall acquire in its name all permits, approvals,
and/or licenses from all local, state, or national government
authorities or public service undertakings in the Purchaser’s
Country that are necessary for the performance of the
Contract, including, without limitation, visas for the
Supplier’s and Subcontractor’s personnel and entry permits
for all imported Supplier’s Equipment. The Supplier shall
acquire all other permits, approvals, and/or licenses that are
not the responsibility of the Purchaser under GCC
Clause 10.4 and that are necessary for the performance of the
Contract.
9.5
The Supplier shall comply with all laws in force in the
Purchaser’s Country. The laws will include all national,
provincial, municipal, or other laws that affect the
performance of the Contract and are binding upon the
Supplier. The Supplier shall indemnify and hold harmless
the Purchaser from and against any and all liabilities,
damages, claims, fines, penalties, and expenses of whatever
nature arising or resulting from the violation of such laws by
the Supplier or its personnel, including the Subcontractors
and their personnel, but without prejudice to GCC
Clause 10.1. The Supplier shall not indemnify the Purchaser
to the extent that such liability, damage, claims, fines,
penalties, and expenses were caused or contributed to by a
fault of the Purchaser.
9.6
The Supplier shall, in all dealings with its labor and the labor
of its Subcontractors currently employed on or connected
with the Contract, pay due regard to all recognized festivals,
official holidays, religious or other customs, and all local
laws and regulations pertaining to the employment of labor.
9.7
Any Information Technologies or other Goods and Services
that will be incorporated in or be required for the System and
other supplies shall have their Origin, as defined in GCC
Clause 3.12, in a country that shall be an Eligible Country, as
defined in GCC Clause 1.1 (e) (iv).
9.8
The Supplier shall permit the Bank and/or persons appointed
by the Bank to inspect the Supplier’s offices and/or the
accounts and records of the Supplier and its sub-contractors
relating to the performance of the Contract, and to have such
accounts and records audited by auditors appointed by the
Bank if required by the Bank. The Supplier’s attention is
drawn to Sub-Clause 41.2.1(c), which provides, inter alia,
that acts intended to materially impede the exercise of the
Section IV. General Conditions of Contract
25
Bank’s inspection and audit rights provided for under SubClause 9.8 constitute a prohibited practice subject to contract
termination (as well as to a determination of ineligibility
under the Procurement Guidelines)
9.9
10. Purchaser’s
Responsibilities
Other Supplier responsibilities, if any, are as stated in the
SCC.
10.1 The Purchaser shall ensure the accuracy of all information
and/or data to be supplied by the Purchaser to the Supplier,
except when otherwise expressly stated in the Contract.
10.2 The Purchaser shall be responsible for timely provision of all
resources, information, and decision making under its control
that are necessary to reach an Agreed and Finalized Project
Plan (pursuant to GCC Clause 19.2) within the time schedule
specified in the Implementation Schedule in the Technical
Requirements Section. Failure to provide such resources,
information, and decision making may constitute grounds for
Termination pursuant to GCC Clause 41.3.1 (b).
10.3 The Purchaser shall be responsible for acquiring and providing
legal and physical possession of the site and access to it, and for
providing possession of and access to all other areas reasonably
required for the proper execution of the Contract.
10.4 If requested by the Supplier, the Purchaser shall use its best
endeavors to assist the Supplier in obtaining in a timely and
expeditious manner all permits, approvals, and/or licenses
necessary for the execution of the Contract from all local,
state, or national government authorities or public service
undertakings that such authorities or undertakings require the
Supplier or Subcontractors or the personnel of the Supplier
or Subcontractors, as the case may be, to obtain.
10.5 In such cases where the responsibilities of specifying and
acquiring or upgrading telecommunications and/or electric
power services falls to the Supplier, as specified in the
Technical Requirements, SCC, Agreed and Finalized Project
Plan, or other parts of the Contract, the Purchaser shall use
its best endeavors to assist the Supplier in obtaining such
services in a timely and expeditious manner.
10.6 The Purchaser shall be responsible for timely provision of all
resources, access, and information necessary for the
Installation and Operational Acceptance of the System
(including,
but
not
limited
to,
any required
telecommunications or electric power services), as identified
26
Section IV. General Conditions of Contract
in the Agreed and Finalized Project Plan, except where
provision of such items is explicitly identified in the Contract
as being the responsibility of the Supplier. Delay by the
Purchaser may result in an appropriate extension of the Time
for Operational Acceptance, at the Supplier’s discretion.
10.7 Unless otherwise specified in the Contract or agreed upon by
the Purchaser and the Supplier, the Purchaser shall provide
sufficient, properly qualified operating and technical
personnel, as required by the Supplier to properly carry out
Delivery, Pre-commissioning, Installation, Commissioning,
and Operational Acceptance, at or before the time specified
in the Technical Requirements Section’s Implementation
Schedule and the Agreed and Finalized Project Plan.
10.8 The Purchaser will designate appropriate staff for the
training courses to be given by the Supplier and shall make
all appropriate logistical arrangements for such training as
specified in the Technical Requirements, SCC, the Agreed
and Finalized Project Plan, or other parts of the Contract.
10.9 The Purchaser assumes primary responsibility for the
Operational Acceptance Test(s) for the System, in
accordance with GCC Clause 27.2, and shall be responsible
for the continued operation of the System after Operational
Acceptance. However, this shall not limit in any way the
Supplier’s responsibilities after the date of Operational
Acceptance otherwise specified in the Contract.
10.10 The Purchaser is responsible for performing and safely
storing timely and regular backups of its data and Software
in accordance with accepted data management principles,
except where such responsibility is clearly assigned to the
Supplier elsewhere in the Contract.
10.11 All costs and expenses involved in the performance of the
obligations under this GCC Clause 10 shall be the
responsibility of the Purchaser, save those to be incurred by
the Supplier with respect to the performance of the
Operational Acceptance Test(s), in accordance with GCC
Clause 27.2.
10.12 Other Purchaser responsibilities, if any, are as stated in
the SCC.
Section IV. General Conditions of Contract
27
C. PAYMENT
11. Contract Price
11.1 The Contract Price shall be as specified in Article 2
(Contract Price and Terms of Payment) of the Contract
Agreement.
11.2 The Contract Price shall be a firm lump sum not subject to
any alteration, except:
(a)
in the event of a Change in the System pursuant to
GCC Clause 39 or to other clauses in the Contract;
(b)
in accordance with the price adjustment formula (if
any) specified in the SCC.
11.3 The Supplier shall be deemed to have satisfied itself as to the
correctness and sufficiency of the Contract Price, which
shall, except as otherwise provided for in the Contract, cover
all its obligations under the Contract.
12. Terms of
Payment
12.1 The Supplier’s request for payment shall be made to the
Purchaser in writing, accompanied by an invoice describing,
as appropriate, the System or Subsystem(s), Delivered, Precommissioned, Installed, and Operationally Accepted, and
by documents submitted pursuant to GCC Clause 22.5 and
upon fulfillment of other obligations stipulated in the
Contract.
The Contract Price shall be paid as specified in the SCC.
12.2 No payment made by the Purchaser herein shall be deemed
to constitute acceptance by the Purchaser of the System or
any Subsystem(s).
12.3 Payments shall be made promptly by the Purchaser, but in no
case later than forty five (45) days after submission of a valid
invoice by the Supplier. In the event that the Purchaser fails
to make any payment by its respective due date or within the
period set forth in the Contract, the Purchaser shall pay to the
Supplier interest on the amount of such delayed payment at
the rate(s) specified in the SCC for the period of delay until
payment has been made in full, whether before or after
judgment or arbitration award.
12.4 All payments shall be made in the currency(ies) specified in
the Contract Agreement, pursuant to GCC Clause 11. For
Goods and Services supplied locally, payments shall be
made in the currency of the Purchaser’s Country, unless
28
Section IV. General Conditions of Contract
otherwise specified in the SCC.
12.5 Unless otherwise specified in the SCC, payment of the
foreign currency portion of the Contract Price for Goods
supplied from outside the Purchaser’s Country shall be made
to the Supplier through an irrevocable letter of credit opened
by an authorized bank in the Supplier’s Country and will be
payable on presentation of the appropriate documents. It is
agre”ed that the letter of credit will be subject to Article 10
of the latest revision of Uniform Customs and Practice for
Documentary Credits, published by the International
Chamber of Commerce, Paris.
13. Securities
13.1 Issuance of Securities
The Supplier shall provide the securities specified below in
favor of the Purchaser at the times and in the amount,
manner, and form specified below.
13.2 Advance Payment Security
13.2.1 As specified in the SCC, the Supplier shall provide a
security equal in amount and currency to the advance
payment, and valid until the System is Operationally
Accepted.
13.2.2 The security shall be in the form provided in the
Bidding Documents or in another form acceptable to
the Purchaser. The amount of the security shall be
reduced in proportion to the value of the System
executed by and paid to the Supplier from time to time
and shall automatically become null and void when
the full amount of the advance payment has been
recovered by the Purchaser. The way the value of the
security is deemed to become reduced and, eventually,
voided is as specified in the SCC. The security shall
be returned to the Supplier immediately after its
expiration.
13.3 Performance Security
13.3.1 The Supplier shall, within twenty-eight (28) days of
the notification of Contract award, provide a security
for the due performance of the Contract in the amount
and currency specified in the SCC.
13.3.2 The security shall be a bank guarantee in the form
provided in the Sample Forms Section of the Bidding
Documents, or it shall be in another form acceptable
Section IV. General Conditions of Contract
29
to the Purchaser.
13.3.3 The security shall automatically become null and void
once all the obligations of the Supplier under the
Contract have been fulfilled, including, but not limited
to, any obligations during the Warranty Period and
any extensions to the period. The security shall be
returned to the Supplier no later than twenty-eight (28)
days after its expiration.
13.3.4 Upon Operational Acceptance of the entire System,
the security shall be reduced to the amount specified
in the SCC, on the date of such Operational
Acceptance, so that the reduced security would only
cover the remaining warranty obligations of the
Supplier.
14. Taxes and Duties
14.1 For Goods or Services supplied from outside the Purchaser’s
country, the Supplier shall be entirely responsible for all
taxes, stamp duties, license fees, and other such levies
imposed outside the Purchaser’s country. Any duties, such
as importation or customs duties, and taxes and other levies,
payable in the Purchaser’s country for the supply of Goods
and Services from outside the Purchaser’s country are the
responsibility of the Purchaser unless these duties or taxes
have been made part of the Contract Price in Article 2 of the
Contract Agreement and the Price Schedule it refers to, in
which case the duties and taxes will be the Supplier’s
responsibility.
14.2 For Goods or Services supplied locally, the Supplier shall be
entirely responsible for all taxes, duties, license fees, etc.,
incurred until delivery of the contracted Goods or Services to
the Purchaser. The only exception are taxes or duties, such
as value-added or sales tax or stamp duty as apply to, or are
clearly identifiable, on the invoices and provided they apply
in the Purchaser’s country, and only if these taxes, levies
and/or duties are also excluded from the Contract Price in
Article 2 of the Contract Agreement and the Price Schedule
it refers to.
14.3 If any tax exemptions, reductions, allowances, or privileges
may be available to the Supplier in the Purchaser’s Country,
the Purchaser shall use its best efforts to enable the Supplier
to benefit from any such tax savings to the maximum
allowable extent.
14.4 For the purpose of the Contract, it is agreed that the Contract
30
Section IV. General Conditions of Contract
Price specified in Article 2 (Contract Price and Terms of
Payment) of the Contract Agreement is based on the taxes,
duties, levies, and charges prevailing at the date twenty-eight
(28) days prior to the date of bid submission in the
Purchaser’s Country (also called “Tax” in this GCC Clause
14.4). If any Tax rates are increased or decreased, a new Tax
is introduced, an existing Tax is abolished, or any change in
interpretation or application of any Tax occurs in the course
of the performance of the Contract, which was or will be
assessed on the Supplier, its Subcontractors, or their
employees in connection with performance of the Contract,
an equitable adjustment to the Contract Price shall be made
to fully take into account any such change by addition to or
reduction from the Contract Price, as the case may be.
D. INTELLECTUAL PROPERTY
15. Copyright
15.1 The Intellectual Property Rights in all Standard Software and
Standard Materials shall remain vested in the owner of such
rights.
15.2 The Purchaser agrees to restrict use, copying, or duplication
of the Standard Software and Standard Materials in
accordance with GCC Clause 16, except that additional
copies of Standard Materials may be made by the Purchaser
for use within the scope of the project of which the System is
a part, in the event that the Supplier does not deliver copies
within thirty (30) days from receipt of a request for such
Standard Materials.
15.3 The Purchaser’s contractual rights to use the Standard
Software or elements of the Standard Software may not be
assigned, licensed, or otherwise transferred voluntarily
except in accordance with the relevant license agreement or
as may be otherwise specified in the SCC.
15.4 As applicable, the Purchaser’s and Supplier’s rights and
obligations with respect to Custom Software or elements of
the Custom Software, including any license agreements, and
with respect to Custom Materials or elements of the Custom
Materials, are specified in the SCC. Subject to the SCC,
the Intellectual Property Rights in all Custom Software and
Custom Materials specified in Appendices 4 and 5 of the
Contract Agreement (if any) shall, at the date of this
Contract or on creation of the rights (if later than the date of
this Contract), vest in the Purchaser. The Supplier shall do
Section IV. General Conditions of Contract
31
and execute or arrange for the doing and executing of each
necessary act, document, and thing that the Purchaser may
consider necessary or desirable to perfect the right, title, and
interest of the Purchaser in and to those rights. In respect of
such Custom Software and Custom Materials, the Supplier
shall ensure that the holder of a moral right in such an item
does not assert it, and the Supplier shall, if requested to do so
by the Purchaser and where permitted by applicable law,
ensure that the holder of such a moral right waives it.
15.5 The parties shall enter into such (if any) escrow
arrangements in relation to the Source Code to some or all of
the Software as are specified in the SCC and in accordance
with the SCC.
16. Software License
Agreements
16.1 Except to the extent that the Intellectual Property Rights in
the Software vest in the Purchaser, the Supplier hereby
grants to the Purchaser license to access and use the
Software, including all inventions, designs, and marks
embodied in the Software.
Such license to access and use the Software shall:
(a)
be:
(i)
nonexclusive;
(ii)
fully paid up and irrevocable (except that it shall
terminate if the Contract terminates under GCC
Clauses 41.1 or 41.3);
(iii) valid throughout the territory of the Purchaser’s
Country (or such other territory as specified in
the SCC); and
(iv) subject to additional restrictions (if any) as
specified in the SCC.
(b)
permit the Software to be:
(i)
used or copied for use on or with the computer(s)
for which it was acquired (if specified in the
Technical Requirements and/or the Supplier’s
bid), plus a backup computer(s) of the same or
similar capacity, if the primary is(are)
inoperative, and during a reasonable transitional
period when use is being transferred between
primary and backup;
32
Section IV. General Conditions of Contract
(ii)
as specified in the SCC, used or copied for use
on or transferred to a replacement computer(s),
(and use on the original and replacement
computer(s) may be simultaneous during a
reasonable transitional period) provided that, if
the Technical Requirements and/or the Supplier’s
bid specifies a class of computer to which the
license is restricted and unless the Supplier agrees
otherwise in writing, the replacement computer(s)
is(are) within that class;
(iii) if the nature of the System is such as to permit
such access, accessed from other computers
connected to the primary and/or backup
computer(s) by means of a local or wide-area
network or similar arrangement, and used on or
copied for use on those other computers to the
extent necessary to that access;
(iv) reproduced for safekeeping or backup purposes;
(v)
customized, adapted, or combined with other
computer software for use by the Purchaser,
provided that derivative software incorporating
any substantial part of the delivered, restricted
Software shall be subject to same restrictions as
are set forth in this Contract;
(vi) as specified in the SCC, disclosed to, and
reproduced for use by, support service suppliers
and their subcontractors, (and the Purchaser may
sublicense such persons to use and copy for use
the Software) to the extent reasonably necessary
to the performance of their support service
contracts, subject to the same restrictions as are
set forth in this Contract; and
(vii) disclosed to, and reproduced for use by, the
Purchaser and by such other persons as are
specified in the SCC (and the Purchaser may
sublicense such persons to use and copy for use
the Software), subject to the same restrictions as
are set forth in this Contract.
16.2 The Standard Software may be subject to audit by the
Supplier, in accordance with the terms specified in the SCC,
to verify compliance with the above license agreements.
Section IV. General Conditions of Contract
17. Confidential
Information
33
17.1 Except if otherwise specified in the SCC, the "Receiving
Party" (either the Purchaser or the Supplier) shall keep
confidential and shall not, without the written consent of the
other party to this Contract (“the Disclosing Party”), divulge
to any third party any documents, data, or other information
of a confidential nature (“Confidential Information”)
connected with this Contract, and furnished directly or
indirectly by the Disclosing Party prior to or during
performance, or following termination, of this Contract.
17.2 For the purposes of GCC Clause 17.1, the Supplier is also
deemed to be the Receiving Party of Confidential
Information generated by the Supplier itself in the course of
the performance of its obligations under the Contract and
relating to the businesses, finances, suppliers, employees, or
other contacts of the Purchaser or the Purchaser’s use of the
System.
17.3 Notwithstanding GCC Clauses 17.1 and 17.2:
(a)
the Supplier may furnish to its Subcontractor
Confidential Information of the Purchaser to the extent
reasonably required for the Subcontractor to perform
its work under the Contract; and
(b)
the Purchaser may furnish Confidential Information of
the Supplier: (i) to its support service suppliers and
their subcontractors to the extent reasonably required
for them to perform their work under their support
service contracts; and (ii) to its affiliates and
subsidiaries,
in which event the Receiving Party shall ensure that the
person to whom it furnishes Confidential Information of the
Disclosing Party is aware of and abides by the Receiving
Party’s obligations under this GCC Clause 17 as if that
person were party to the Contract in place of the Receiving
Party.
17.4 The Purchaser shall not, without the Supplier’s prior written
consent, use any Confidential Information received from the
Supplier for any purpose other than the operation,
maintenance and further development of the System.
Similarly, the Supplier shall not, without the Purchaser’s
prior written consent, use any Confidential Information
received from the Purchaser for any purpose other than those
that are required for the performance of the Contract.
34
Section IV. General Conditions of Contract
17.5 The obligation of a party under GCC Clauses 17.1 through
17.4 above, however, shall not apply to that information
which:
(a)
now or hereafter enters the public domain through no
fault of the Receiving Party;
(b)
can be proven to have been possessed by the Receiving
Party at the time of disclosure and that was not
previously obtained, directly or indirectly, from the
Disclosing Party;
(c)
otherwise lawfully becomes available to the Receiving
Party from a third party that has no obligation of
confidentiality.
17.6 The above provisions of this GCC Clause 17 shall not in any
way modify any undertaking of confidentiality given by
either of the parties to this Contract prior to the date of the
Contract in respect of the System or any part thereof.
17.7 The provisions of this GCC Clause 17 shall survive the
termination, for whatever reason, of the Contract for three
(3) years or such longer period as may be specified in the
SCC.
E. SUPPLY, INSTALLATION, TESTING,COMMISSIONING, AND
ACCEPTANCE OF THE SYSTEM
18.
Representatives
18.1 Project Manager
If the Project Manager is not named in the Contract, then
within fourteen (14) days of the Effective Date, the
Purchaser shall appoint and notify the Supplier in writing of
the name of the Project Manager. The Purchaser may from
time to time appoint some other person as the Project
Manager in place of the person previously so appointed and
shall give a notice of the name of such other person to the
Supplier without delay. No such appointment shall be made
at such a time or in such a manner as to impede the progress
of work on the System. Such appointment shall take effect
only upon receipt of such notice by the Supplier. Subject to
the extensions and/or limitations specified in the SCC (if
any), the Project Manager shall have the authority to
represent the Purchaser on all day-to-day matters relating to
the System or arising from the Contract, and shall normally
be the person giving or receiving notices on behalf of the
Section IV. General Conditions of Contract
35
Purchaser pursuant to GCC Clause 4.
18.2 Supplier’s Representative
18.2.1 If the Supplier’s Representative is not named in the
Contract, then within fourteen (14) days of the
Effective Date, the Supplier shall appoint the
Supplier’s Representative and shall request the
Purchaser in writing to approve the person so
appointed. The request must be accompanied by a
detailed curriculum vitae for the nominee, as well as a
description of any other System or non-System
responsibilities the nominee would retain while
performing the duties of the Supplier’s Representative.
If the Purchaser does not object to the appointment
within fourteen (14) days, the Supplier’s
Representative shall be deemed to have been
approved. If the Purchaser objects to the appointment
within fourteen (14) days giving the reason therefor,
then the Supplier shall appoint a replacement within
fourteen (14) days of such objection in accordance
with this GCC Clause 18.2.1.
18.2.2 Subject to the extensions and/or limitations specified
in the SCC (if any), the Supplier’s Representative
shall have the authority to represent the Supplier on all
day-to-day matters relating to the System or arising
from the Contract, and shall normally be the person
giving or receiving notices on behalf of the Supplier
pursuant to GCC Clause 4.
18.2.3 The Supplier shall not revoke the appointment of the
Supplier’s Representative without the Purchaser’s
prior written consent, which shall not be unreasonably
withheld. If the Purchaser consents to such an action,
the Supplier shall appoint another person of equal or
superior
qualifications
as
the
Supplier’s
Representative, pursuant to the procedure set out in
GCC Clause 18.2.1.
18.2.4 The Supplier’s Representative and staff are obliged to
work closely with the Purchaser’s Project Manager
and staff, act within their own authority, and abide by
directives issued by the Purchaser that are consistent
with the terms of the Contract. The Supplier’s
Representative is responsible for managing the
activities of its personnel and any subcontracted
36
Section IV. General Conditions of Contract
personnel.
18.2.5 The Supplier’s Representative may, subject to the
approval of the Purchaser (which shall not be
unreasonably withheld), at any time delegate to any
person any of the powers, functions, and authorities
vested in him or her. Any such delegation may be
revoked at any time.
Any such delegation or
revocation shall be subject to a prior notice signed by
the Supplier’s Representative and shall specify the
powers, functions, and authorities thereby delegated or
revoked. No such delegation or revocation shall take
effect unless and until the notice of it has been
delivered.
18.2.6 Any act or exercise by any person of powers,
functions and authorities so delegated to him or her in
accordance with GCC Clause 18.2.5 shall be deemed
to be an act or exercise by the Supplier’s
Representative.
18.3 Objections and Removals
18.3.1 The Purchaser may by notice to the Supplier object to
any representative or person employed by the Supplier
in the execution of the Contract who, in the reasonable
opinion of the Purchaser, may have behaved
inappropriately, be incompetent, or be negligent. The
Purchaser shall provide evidence of the same,
whereupon the Supplier shall remove such person
from work on the System.
18.3.2 If any representative or person employed by the
Supplier is removed in accordance with GCC Clause
18.3.1, the Supplier shall, where required, promptly
appoint a replacement.
19. Project Plan
19.1 In close cooperation with the Purchaser and based on the
Preliminary Project Plan included in the Supplier’s bid, the
Supplier shall develop a Project Plan encompassing the
activities specified in the Contract. The contents of the
Project Plan shall be as specified in the SCC and/or
Technical Requirements.
19.2 The Supplier shall formally present to the Purchaser the
Project Plan in accordance with the procedure specified in
the SCC.
Section IV. General Conditions of Contract
37
19.3 If required, the impact on the Implementation Schedule of
modifications agreed during finalization of the Agreed and
Finalized Project Plan shall be incorporated in the Contract
by amendment, in accordance with GCC Clauses 39 and 40.
19.4 The Supplier shall undertake to supply, install, test, and
commission the System in accordance with the Agreed and
Finalized Project Plan and the Contract.
19.5 The Progress and other reports specified in the SCC shall be
prepared by the Supplier and submitted to the Purchaser in
the format and frequency specified in the Technical
Requirements.
20. Subcontracting
20.1 Appendix 3 (List of Approved Subcontractors) to the
Contract Agreement specifies critical items of supply or
services and a list of Subcontractors for each item that are
considered acceptable by the Purchaser.
If no
Subcontractors are listed for an item, the Supplier shall
prepare a list of Subcontractors it considers qualified and
wishes to be added to the list for such items. The Supplier
may from time to time propose additions to or deletions from
any such list. The Supplier shall submit any such list or any
modification to the list to the Purchaser for its approval in
sufficient time so as not to impede the progress of work on
the System. The Purchaser shall not withhold such approval
unreasonably.
Such approval by the Purchaser of a
Subcontractor(s) shall not relieve the Supplier from any of
its obligations, duties, or responsibilities under the Contract.
20.2 The Supplier may, at its discretion, select and employ
Subcontractors for such critical items from those
Subcontractors listed pursuant to GCC Clause 20.1. If the
Supplier wishes to employ a Subcontractor not so listed, or
subcontract an item not so listed, it must seek the
Purchaser’s prior approval under GCC Clause 20.3.
20.3 For items for which pre-approved Subcontractor lists have
not been specified in Appendix 3 to the Contract Agreement,
the Supplier may employ such Subcontractors as it may
select, provided: (i) the Supplier notifies the Purchaser in
writing at least twenty-eight (28) days prior to the proposed
mobilization date for such Subcontractor; and (ii) by the end
of this period either the Purchaser has granted its approval in
writing or fails to respond. The Supplier shall not engage
any Subcontractor to which the Purchaser has objected in
writing prior to the end of the notice period. The absence of
a written objection by the Purchaser during the above
38
Section IV. General Conditions of Contract
specified period shall constitute formal acceptance of the
proposed Subcontractor. Except to the extent that it permits
the deemed approval of the Purchaser of Subcontractors not
listed in the Contract Agreement, nothing in this Clause,
however, shall limit the rights and obligations of either the
Purchaser or Supplier as they are specified in GCC
Clauses 20.1 and 20.2, in the SCC, or in Appendix 3 of the
Contract Agreement.
21. Design and
Engineering
21.1 Technical Specifications and Drawings
21.1.1 The Supplier shall execute the basic and detailed
design and the implementation activities necessary for
successful installation of the System in compliance
with the provisions of the Contract or, where not so
specified, in accordance with good industry practice.
The Supplier shall be responsible for any
discrepancies, errors or omissions in the
specifications, drawings, and other technical
documents that it has prepared, whether such
specifications, drawings, and other documents have
been approved by the Project Manager or not,
provided that such discrepancies, errors, or omissions
are not because of inaccurate information furnished in
writing to the Supplier by or on behalf of the
Purchaser.
21.1.2 The Supplier shall be entitled to disclaim
responsibility for any design, data, drawing,
specification, or other document, or any modification
of such design, drawings, specification, or other
documents provided or designated by or on behalf of
the Purchaser, by giving a notice of such disclaimer to
the Project Manager.
21.2 Codes and Standards
Wherever references are made in the Contract to codes and
standards in accordance with which the Contract shall be
executed, the edition or the revised version of such codes and
standards current at the date twenty-eight (28) days prior to
date of bid submission shall apply unless otherwise specified
in the SCC. During Contract execution, any changes in
such codes and standards shall be applied after approval by
the Purchaser and shall be treated in accordance with GCC
Clause 39.3.
Section IV. General Conditions of Contract
39
21.3 Approval/Review of Technical Documents by the Project
Manager
21.3.1 The Supplier shall prepare and furnish to the Project
Manager the documents as specified in the SCC for
the Project Manager’s approval or review.
Any part of the System covered by or related to the
documents to be approved by the Project Manager
shall be executed only after the Project Manager’s
approval of these documents.
GCC Clauses 21.3.2 through 21.3.7 shall apply to
those documents requiring the Project Manager’s
approval, but not to those furnished to the Project
Manager for its review only.
21.3.2 Within fourteen (14) days after receipt by the Project
Manager of any document requiring the Project
Manager’s approval in accordance with GCC Clause
21.3.1, the Project Manager shall either return one
copy of the document to the Supplier with its approval
endorsed on the document or shall notify the Supplier
in writing of its disapproval of the document and the
reasons for disapproval and the modifications that the
Project Manager proposes. If the Project Manager fails
to take such action within the fourteen (14) days, then
the document shall be deemed to have been approved
by the Project Manager.
21.3.3 The Project Manager shall not disapprove any
document except on the grounds that the document
does not comply with some specified provision of the
Contract or that it is contrary to good industry
practice.
21.3.4 If the Project Manager disapproves the document, the
Supplier shall modify the document and resubmit it
for the Project Manager’s approval in accordance with
GCC Clause 21.3.2. If the Project Manager approves
the document subject to modification(s), the Supplier
shall make the required modification(s), and the
document shall then be deemed to have been
approved, subject to GCC Clause 21.3.5.
The
procedure set out in GCC Clauses 21.3.2 through
21.3.4 shall be repeated, as appropriate, until the
Project Manager approves such documents.
40
Section IV. General Conditions of Contract
21.3.5 If any dispute occurs between the Purchaser and the
Supplier in connection with or arising out of the
disapproval by the Project Manager of any document
and/or any modification(s) to a document that cannot
be settled between the parties within a reasonable
period, then, in case the Contract Agreement includes
and names an Adjudicator, such dispute may be
referred to the Adjudicator for determination in
accordance with GCC Clause 6.1 (Adjudicator). If
such dispute is referred to an Adjudicator, the Project
Manager shall give instructions as to whether and if
so, how, performance of the Contract is to proceed.
The Supplier shall proceed with the Contract in
accordance with the Project Manager’s instructions,
provided that if the Adjudicator upholds the Supplier’s
view on the dispute and if the Purchaser has not given
notice under GCC Clause 6.1.2, then the Supplier
shall be reimbursed by the Purchaser for any
additional costs incurred by reason of such
instructions and shall be relieved of such
responsibility or liability in connection with the
dispute and the execution of the instructions as the
Adjudicator shall decide, and the Time for Achieving
Operational
Acceptance
shall
be
extended
accordingly.
21.3.6 The Project Manager’s approval, with or without
modification of the document furnished by the
Supplier, shall not relieve the Supplier of any
responsibility or liability imposed upon it by any
provisions of the Contract except to the extent that any
subsequent failure results from modifications required
by the Project Manager or inaccurate information
furnished in writing to the Supplier by or on behalf of
the Purchaser.
21.3.7 The Supplier shall not depart from any approved
document unless the Supplier has first submitted to
the Project Manager an amended document and
obtained the Project Manager’s approval of the
document, pursuant to the provisions of this GCC
Clause 21.3. If the Project Manager requests any
change in any already approved document and/or in
any document based on such an approved document,
the provisions of GCC Clause 39 (Changes to the
System) shall apply to such request.
Section IV. General Conditions of Contract
22. Procurement,
Delivery, and
Transport
41
22.1 Subject to related Purchaser's responsibilities pursuant to
GCC Clauses 10 and 14, the Supplier shall manufacture or
procure and transport all the Information Technologies,
Materials, and other Goods in an expeditious and orderly
manner to the Project Site.
22.2 Delivery of the Information Technologies, Materials, and
other Goods shall be made by the Supplier in accordance
with the Technical Requirements.
22.3 Early or partial deliveries require the explicit written consent
of the Purchaser, which consent shall not be unreasonably
withheld.
22.4 Transportation
22.4.1 The Supplier shall provide such packing of the Goods
as is required to prevent their damage or deterioration
during shipment.
The packing, marking, and
documentation within and outside the packages shall
comply strictly with the Purchaser’s instructions to
the Supplier.
22.4.2 The Supplier will bear responsibility for and cost of
transport to the Project Sites in accordance with the
terms and conditions used in the specification of
prices in the Price Schedules, including the terms and
conditions of the associated Incoterms.
22.4.3 Unless otherwise specified in the SCC, the Supplier
shall be free to use transportation through carriers
registered in any eligible country and to obtain
insurance from any eligible source country.
22.5 Unless otherwise specified in the SCC, the Supplier will
provide the Purchaser with shipping and other documents, as
specified below:
22.5.1 For Goods supplied from outside the Purchaser’s
Country:
Upon shipment, the Supplier shall notify the Purchaser
and the insurance company contracted by the Supplier
to provide cargo insurance by telex, cable, facsimile,
electronic mail, or EDI with the full details of the
shipment. The Supplier shall promptly send the
following documents to the Purchaser by mail or
courier, as appropriate, with a copy to the cargo
42
Section IV. General Conditions of Contract
insurance company:
(a)
two copies of the Supplier’s invoice showing the
description of the Goods, quantity, unit price, and
total amount;
(b)
usual transportation documents;
(c)
insurance certificate;
(d)
certificate(s) of origin; and
(e)
estimated time and point of arrival in the
Purchaser’s Country and at the site.
22.5.2 For Goods supplied locally (i.e., from within the
Purchaser’s country):
Upon shipment, the Supplier shall notify the Purchaser
by telex, cable, facsimile, electronic mail, or EDI with
the full details of the shipment. The Supplier shall
promptly send the following documents to the
Purchaser by mail or courier, as appropriate:
(a)
two copies of the Supplier’s invoice showing the
Goods’ description, quantity, unit price, and total
amount;
(b)
delivery note, railway receipt, or truck receipt;
(c)
certificate of insurance;
(d)
certificate(s) of origin; and
(e)
estimated time of arrival at the site.
22.6 Customs Clearance
(a)
The Purchaser will bear responsibility for, and cost of,
customs clearance into the Purchaser's country in
accordance the particular Incoterm(s) used for Goods
supplied from outside the Purchaser’s country in the
Price Schedules referred to by Article 2 of the Contract
Agreement.
(b)
At the request of the Purchaser, the Supplier will make
available a representative or agent during the process of
customs clearance in the Purchaser's country for goods
supplied from outside the Purchaser's country. In the
event of delays in customs clearance that are not the
Section IV. General Conditions of Contract
43
fault of the Supplier:
23. Product
Upgrades
(i)
the Supplier shall be entitled to an extension in
the Time for Achieving Operational Acceptance,
pursuant to GCC Clause 40;
(ii)
the Contract Price shall be adjusted to
compensate the Supplier for any additional
storage charges that the Supplier may incur as a
result of the delay.
23.1 At any point during performance of the Contract, should
technological advances be introduced by the Supplier for
Information Technologies originally offered by the Supplier
in its bid and still to be delivered, the Supplier shall be
obligated to offer to the Purchaser the latest versions of the
available Information Technologies having equal or better
performance or functionality at the same or lesser unit prices,
pursuant to GCC Clause 39 (Changes to the System).
23.2 At any point during performance of the Contract, for
Information Technologies still to be delivered, the Supplier
will also pass on to the Purchaser any cost reductions and
additional and/or improved support and facilities that it
offers to other clients of the Supplier in the Purchaser’s
Country, pursuant to GCC Clause 39 (Changes to the
System).
23.3 During performance of the Contract, the Supplier shall offer
to the Purchaser all new versions, releases, and updates of
Standard Software, as well as related documentation and
technical support services, within thirty (30) days of their
availability from the Supplier to other clients of the Supplier
in the Purchaser’s Country, and no later than twelve (12)
months after they are released in the country of origin. In no
case will the prices for these Software exceed those quoted
by the Supplier in the Recurrent Costs tables in its bid.
23.4 During the Warranty Period, unless otherwise specified in
the SCC, the Supplier will provide at no additional cost to
the Purchaser all new versions, releases, and updates for all
Standard Software that are used in the System, within thirty
(30) days of their availability from the Supplier to other
clients of the Supplier in the Purchaser’s country, and no
later than twelve (12) months after they are released in the
country of origin of the Software.
23.5 The Purchaser shall introduce all new versions, releases or
44
Section IV. General Conditions of Contract
updates of the Software within eighteen (18) months of
receipt of a production-ready copy of the new version,
release, or update, provided that the new version, release, or
update does not adversely affect System operation or
performance or require extensive reworking of the System.
In cases where the new version, release, or update adversely
affects System operation or performance, or requires
extensive reworking of the System, the Supplier shall
continue to support and maintain the version or release
previously in operation for as long as necessary to allow
introduction of the new version, release, or update. In no
case shall the Supplier stop supporting or maintaining a
version or release of the Software less than twenty four (24)
months after the Purchaser receives a production-ready copy
of a subsequent version, release, or update. The Purchaser
shall use all reasonable endeavors to implement any new
version, release, or update as soon as practicable, subject to
the twenty-four-month-long stop date.
24. Implementation,
Installation, and
Other Services
24.1 The Supplier shall provide all Services specified in the
Contract and Agreed and Finalized Project Plan in
accordance with the highest standards of professional
competence and integrity.
24.2 Prices charged by the Supplier for Services, if not included
in the Contract, shall be agreed upon in advance by the
parties (including, but not restricted to, any prices submitted
by the Supplier in the Recurrent Cost Schedules of its Bid)
and shall not exceed the prevailing rates charged by the
Supplier to other purchasers in the Purchaser’s Country for
similar services.
25. Inspections and
Tests
25.1 The Purchaser or its representative shall have the right to
inspect and/or test any components of the System, as
specified in the Technical Requirements, to confirm their
good working order and/or conformity to the Contract at the
point of delivery and/or at the Project Site.
25.2 The Purchaser or its representative shall be entitled to attend
any such inspections and/or tests of the components,
provided that the Purchaser shall bear all costs and expenses
incurred in connection with such attendance, including but
not limited to all inspection agent fees, travel, and related
expenses.
25.3 Should the inspected or tested components fail to conform to
the Contract, the Purchaser may reject the component(s), and
the Supplier shall either replace the rejected component(s),
Section IV. General Conditions of Contract
45
or make alterations as necessary so that it meets the Contract
requirements free of cost to the Purchaser.
25.4 The Project Manager may require the Supplier to carry out
any inspection and/or test not specified in the Contract,
provided that the Supplier’s reasonable costs and expenses
incurred in the carrying out of such inspection and/or test
shall be added to the Contract Price. Further, if such
inspection and/or test impedes the progress of work on the
System and/or the Supplier’s performance of its other
obligations under the Contract, due allowance will be made
in respect of the Time for Achieving Operational Acceptance
and the other obligations so affected.
25.5 If any dispute shall arise between the parties in connection
with or caused by an inspection and/or with regard to any
component to be incorporated in the System that cannot be
settled amicably between the parties within a reasonable
period of time, either party may invoke the process pursuant
to GCC Clause 6 (Settlement of Disputes), starting with
referral of the matter to the Adjudicator in case an
Adjudicator is included and named in the Contract
Agreement.
26. Installation of the 26.1 As soon as the System, or any Subsystem, has, in the opinion
of the Supplier, been delivered, Pre-commissioned, and
System
made ready for Commissioning and Operational Acceptance
Testing in accordance with the Technical Requirements, the
SCC and the Agreed and Finalized Project Plan, the Supplier
shall so notify the Purchaser in writing.
26.2 The Project Manager shall, within fourteen (14) days after
receipt of the Supplier’s notice under GCC Clause 26.1,
either issue an Installation Certificate in the form specified in
the Sample Forms Section in the Bidding Documents, stating
that the System, or major component or Subsystem (if
Acceptance by major component or Subsystem is specified
pursuant to the SCC for GCC Clause 27.2.1), has achieved
Installation by the date of the Supplier’s notice under GCC
Clause 26.1, or notify the Supplier in writing of any defects
and/or deficiencies, including, but not limited to, defects or
deficiencies in the interoperability or integration of the
various components and/or Subsystems making up the
System. The Supplier shall use all reasonable endeavors to
promptly remedy any defect and/or deficiencies that the
Project Manager has notified the Supplier of. The Supplier
shall then promptly carry out retesting of the System or
46
Section IV. General Conditions of Contract
Subsystem and, when in the Supplier’s opinion the System
or Subsystem is ready for Commissioning and Operational
Acceptance Testing, notify the Purchaser in writing, in
accordance with GCC Clause 26.1. The procedure set out in
this GCC Clause 26.2 shall be repeated, as necessary, until
an Installation Certificate is issued.
26.3 If the Project Manager fails to issue the Installation
Certificate and fails to inform the Supplier of any defects
and/or deficiencies within fourteen (14) days after receipt of
the Supplier’s notice under GCC Clause 26.1, or if the
Purchaser puts the System or a Subsystem into production
operation, then the System (or Subsystem) shall be deemed
to have achieved successful Installation as of the date of the
Supplier’s notice or repeated notice, or when the Purchaser
put the System into production operation, as the case may be.
27. Commissioning
and Operational
Acceptance
27.1 Commissioning
27.1.1 Commissioning of the System (or Subsystem if
specified pursuant to the SCC for GCC Clause 27.2.1)
shall be commenced by the Supplier:
(a)
immediately after the Installation Certificate is
issued by the Project Manager, pursuant to
GCC Clause 26.2; or
(b)
as otherwise specified in the Technical
Requirement or the Agreed and Finalized
Project Plan; or
(c)
immediately after Installation is deemed to have
occurred, under GCC Clause 26.3.
27.1.2 The Purchaser shall supply the operating and technical
personnel and all materials and information
reasonably required to enable the Supplier to carry out
its obligations with respect to Commissioning.
Production use of the System or Subsystem(s) shall
not commence prior to the start of formal Operational
Acceptance Testing.
27.2 Operational Acceptance Tests
27.2.1 The Operational Acceptance Tests (and repeats of
such tests) shall be the primary responsibility of the
Purchaser (in accordance with GCC Clause 10.9), but
shall be conducted with the full cooperation of the
Section IV. General Conditions of Contract
47
Supplier during Commissioning of the System (or
major components or Subsystem[s] if specified in the
SCC and supported by the Technical Requirements),
to ascertain whether the System (or major component
or Subsystem[s]) conforms to the Technical
Requirements and meets the standard of performance
quoted in the Supplier’s bid, including, but not
restricted to, the functional and technical performance
requirements. The Operational Acceptance Tests
during Commissioning will be conducted as specified
in the SCC, the Technical Requirements and/or the
Agreed and Finalized Project Plan.
At the Purchaser’s discretion, Operational Acceptance
Tests may also be performed on replacement Goods,
upgrades and new version releases, and Goods that are
added or field-modified after Operational Acceptance
of the System.
27.2.2 If for reasons attributable to the Purchaser, the
Operational Acceptance Test of the System (or
Subsystem[s] or major components, pursuant to the
SCC for GCC Clause 27.2.1) cannot be successfully
completed within the period specified in the SCC,
from the date of Installation or any other period agreed
upon in writing by the Purchaser and the Supplier, the
Supplier shall be deemed to have fulfilled its
obligations with respect to the technical and functional
aspects of the Technical Specifications, SCC and/or
the Agreed and Finalized Project Plan, and GCC
Clause 28.2 and 28.3 shall not apply.
27.3 Operational Acceptance
27.3.1 Subject to GCC Clause 27.4 (Partial Acceptance)
below, Operational Acceptance shall occur in respect
of the System, when
(a) the Operational Acceptance Tests, as specified in
the Technical Requirements, and/or SCC and/or
the Agreed and Finalized Project Plan have been
successfully completed; or
(b) the Operational Acceptance Tests have not been
successfully completed or have not been carried
out for reasons that are attributable to the
Purchaser within the period from the date of
Installation or any other agreed-upon period as
48
Section IV. General Conditions of Contract
specified in GCC Clause 27.2.2 above; or
(c) the Purchaser has put the System into production
or use for sixty (60) consecutive days. If the
System is put into production or use in this
manner, the Supplier shall notify the Purchaser
and document such use.
27.3.2 At any time after any of the events set out in GCC
Clause 27.3.1 have occurred, the Supplier may give a
notice to the Project Manager requesting the issue of
an Operational Acceptance Certificate.
27.3.3 After consultation with the Purchaser, and within
fourteen (14) days after receipt of the Supplier’s
notice, the Project Manager shall:
(a)
issue an Operational Acceptance Certificate; or
(b)
notify the Supplier in writing of any defect or
deficiencies or other reason for the failure of the
Operational Acceptance Tests; or
(c)
issue the Operational Acceptance Certificate, if
the situation covered by GCC Clause 27.3.1 (b)
arises.
27.3.4 The Supplier shall use all reasonable endeavors to
promptly remedy any defect and/or deficiencies and/or
other reasons for the failure of the Operational
Acceptance Test that the Project Manager has notified
the Supplier of. Once such remedies have been made
by the Supplier, the Supplier shall notify the
Purchaser, and the Purchaser, with the full cooperation
of the Supplier, shall use all reasonable endeavors to
promptly carry out retesting of the System or
Subsystem. Upon the successful conclusion of the
Operational Acceptance Tests, the Supplier shall
notify the Purchaser of its request for Operational
Acceptance Certification, in accordance with GCC
Clause 27.3.3. The Purchaser shall then issue to the
Supplier the Operational Acceptance Certification in
accordance with GCC Clause 27.3.3 (a), or shall
notify the Supplier of further defects, deficiencies, or
other reasons for the failure of the Operational
Acceptance Test. The procedure set out in this GCC
Clause 27.3.4 shall be repeated, as necessary, until an
Section IV. General Conditions of Contract
49
Operational Acceptance Certificate is issued.
27.3.5 If the System or Subsystem fails to pass the
Operational Acceptance Test(s) in accordance with
GCC Clause 27.2, then either:
(a)
the Purchaser may consider terminating the
Contract, pursuant to GCC Clause 41.2.2;
or
(b)
if the failure to achieve Operational Acceptance
within the specified time period is a result of
the failure of the Purchaser to fulfill its
obligations under the Contract, then the
Supplier shall be deemed to have fulfilled its
obligations with respect to the relevant
technical and functional aspects of the Contract,
and GCC Clauses 30.3 not apply.
27.3.6 If within fourteen (14) days after receipt of the
Supplier’s notice the Project Manager fails to issue the
Operational Acceptance Certificate or fails to inform
the Supplier in writing of the justifiable reasons why
the Project Manager has not issued the Operational
Acceptance Certificate, the System or Subsystem shall
be deemed to have been accepted as of the date of the
Supplier’s said notice.
27.4 Partial Acceptance
27.4.1 If so specified in the SCC for GCC Clause 27.2.1,
Installation and Commissioning shall be carried out
individually for each identified major component or
Subsystem(s) of the System.
In this event, the
provisions in the Contract relating to Installation and
Commissioning, including the Operational Acceptance
Test, shall apply to each such major component or
Subsystem individually, and Operational Acceptance
Certificate(s) shall be issued accordingly for each such
major component or Subsystem of the System, subject to
the limitations contained in GCC Clause 27.4.2.
27.4.2 The issuance of Operational Acceptance Certificates for
individual major components or Subsystems pursuant to
GCC Clause 27.4.1 shall not relieve the Supplier of its
obligation to obtain an Operational Acceptance
Certificate for the System as an integrated whole (if so
specified in the SCC for GCC Clauses 12.1 and 27.2.1)
50
Section IV. General Conditions of Contract
once all major components and Subsystems have been
supplied, installed, tested, and commissioned.
27.4.3 In the case of minor components for the System that
by their nature do not require Commissioning or an
Operational Acceptance Test (e.g., minor fittings,
furnishings or site works, etc.), the Project Manager
shall issue an Operational Acceptance Certificate
within fourteen (14) days after the fittings and/or
furnishings have been delivered and/or installed or the
site works have been completed. The Supplier shall,
however, use all reasonable endeavors to promptly
remedy any defects or deficiencies in such minor
components detected by the Purchaser or Supplier.
F. GUARANTEES AND LIABILITIES
28. Operational
Acceptance Time
Guarantee
28.1 The Supplier guarantees that it shall complete the supply,
Installation, Commissioning, and achieve Operational
Acceptance of the System (or Subsystems, pursuant to the
SCC for GCC Clause 27.2.1) within the time periods
specified in the Implementation Schedule in the Technical
Requirements Section and/or the Agreed and Finalized
Project Plan pursuant to GCC Clause 8.2, or within such
extended time to which the Supplier shall be entitled under
GCC Clause 40 (Extension of Time for Achieving
Operational Acceptance).
28.2 If the Supplier fails to supply, install, commission, and achieve
Operational Acceptance of the System (or Subsystems pursuant
to the SCC for GCC Clause 27.2.1) within the time for
achieving Operational Acceptance specified in the
Implementation Schedule in the Technical Requirement or the
Agreed and Finalized Project Plan, or any extension of the time
for achieving Operational Acceptance previously granted under
GCC Clause 40 (Extension of Time for Achieving Operational
Acceptance), the Supplier shall pay to the Purchaser liquidated
damages at the rate specified in the SCC as a percentage of the
Contract Price, or the relevant part of the Contract Price if a
Subsystem has not achieved Operational Acceptance. The
aggregate amount of such liquidated damages shall in no event
exceed the amount specified in the SCC (“the Maximum”).
Once the Maximum is reached, the Purchaser may consider
termination of the Contract, pursuant to GCC Clause 41.2.2.
28.3 Unless otherwise specified in the SCC, liquidated damages
Section IV. General Conditions of Contract
51
payable under GCC Clause 28.2 shall apply only to the
failure to achieve Operational Acceptance of the System
(and Subsystems) as specified in the Implementation
Schedule in the Technical Requirements and/or Agreed and
Finalized Project Plan. This Clause 28.3 shall not limit,
however, any other rights or remedies the Purchaser may
have under the Contract for other delays.
28.4 If liquidated damages are claimed by the Purchaser for the
System (or Subsystem), the Supplier shall have no further
liability whatsoever to the Purchaser in respect to the
Operational Acceptance time guarantee for the System (or
Subsystem). However, the payment of liquidated damages
shall not in any way relieve the Supplier from any of its
obligations to complete the System or from any other of its
obligations and liabilities under the Contract.
29. Defect Liability
29.1 The Supplier warrants that the System, including all
Information Technologies, Materials, and other Goods
supplied and Services provided, shall be free from defects in
the design, engineering, Materials, and workmanship that
prevent the System and/or any of its components from
fulfilling the Technical Requirements or that limit in a
material fashion the performance, reliability, or extensibility
of the System and/or Subsystems. Exceptions and/or
limitations, if any, to this warranty with respect to Software
(or categories of Software), shall be as specified in the SCC.
Commercial warranty provisions of products supplied under
the Contract shall apply to the extent that they do not conflict
with the provisions of this Contract.
29.2 The Supplier also warrants that the Information
Technologies, Materials, and other Goods supplied under the
Contract are new, unused, and incorporate all recent
improvements in design that materially affect the System’s
or Subsystem’s ability to fulfill the Technical Requirements.
29.3 In addition, the Supplier warrants that: (i) all Goods
components to be incorporated into the System form part of
the Supplier’s and/or Subcontractor’s current product lines,
(ii) they have been previously released to the market, and
(iii) those specific items identified in the SCC (if any) have
been in the market for at least the minimum periods
specified in the SCC.
29.4 The Warranty Period shall commence from the date of
Operational Acceptance of the System (or of any major
component or Subsystem for which separate Operational
52
Section IV. General Conditions of Contract
Acceptance is provided for in the Contract) and shall extend
for the length of time specified in the SCC.
29.5 If during the Warranty Period any defect as described in
GCC Clause 29.1 should be found in the design, engineering,
Materials, and workmanship of the Information
Technologies and other Goods supplied or of the Services
provided by the Supplier, the Supplier shall promptly, in
consultation and agreement with the Purchaser regarding
appropriate remedying of the defects, and at its sole cost,
repair, replace, or otherwise make good (as the Supplier
shall, at its discretion, determine) such defect as well as any
damage to the System caused by such defect. Any defective
Information Technologies or other Goods that have been
replaced by the Supplier shall remain the property of the
Supplier.
29.6 The Supplier shall not be responsible for the repair,
replacement, or making good of any defect or of any damage
to the System arising out of or resulting from any of the
following causes:
(a) improper operation or maintenance of the System by the
Purchaser;
(b) normal wear and tear;
(c) use of the System with items not supplied by the
Supplier, unless otherwise identified in the Technical
Requirements, or approved by the Supplier; or
(d) modifications made to the System by the Purchaser, or a
third party, not approved by the Supplier.
29.7 The Supplier’s obligations under this GCC Clause 29 shall
not apply to:
(a) any materials that are normally consumed in operation or
have a normal life shorter than the Warranty Period; or
(b) any designs, specifications, or other data designed,
supplied, or specified by or on behalf of the Purchaser or
any matters for which the Supplier has disclaimed
responsibility, in accordance with GCC Clause 21.1.2.
29.8 The Purchaser shall give the Supplier a notice promptly
following the discovery of such defect, stating the nature of
any such defect together with all available evidence. The
Purchaser shall afford all reasonable opportunity for the
Section IV. General Conditions of Contract
53
Supplier to inspect any such defect. The Purchaser shall
afford the Supplier all necessary access to the System and
the site to enable the Supplier to perform its obligations
under this GCC Clause 29.
29.9 The Supplier may, with the consent of the Purchaser, remove
from the site any Information Technologies and other Goods
that are defective, if the nature of the defect, and/or any
damage to the System caused by the defect, is such that
repairs cannot be expeditiously carried out at the site. If the
repair, replacement, or making good is of such a character
that it may affect the efficiency of the System, the Purchaser
may give the Supplier notice requiring that tests of the
defective part be made by the Supplier immediately upon
completion of such remedial work, whereupon the Supplier
shall carry out such tests.
If such part fails the tests, the Supplier shall carry out further
repair, replacement, or making good (as the case may be)
until that part of the System passes such tests. The tests shall
be agreed upon by the Purchaser and the Supplier.
29.10
If the Supplier fails to commence the work necessary to
remedy such defect or any damage to the System caused by
such defect within the time period specified in the SCC, the
Purchaser may, following notice to the Supplier, proceed to
do such work or contract a third party (or parties) to do such
work, and the reasonable costs incurred by the Purchaser in
connection with such work shall be paid to the Purchaser by
the Supplier or may be deducted by the Purchaser from any
monies due the Supplier or claimed under the Performance
Security.
29.11 If the System or Subsystem cannot be used by reason of
such defect and/or making good of such defect, the Warranty
Period for the System shall be extended by a period equal to
the period during which the System or Subsystem could not
be used by the Purchaser because of such defect and/or
making good of such defect.
29.12 Items substituted for defective parts of the System during
the Warranty Period shall be covered by the Defect Liability
Warranty for the remainder of the Warranty Period
applicable for the part replaced or three (3) months,
whichever is greater.
29.13 At the request of the Purchaser and without prejudice to any
other rights and remedies that the Purchaser may have
54
Section IV. General Conditions of Contract
against the Supplier under the Contract, the Supplier will
offer all possible assistance to the Purchaser to seek warranty
services or remedial action from any subcontracted thirdparty producers or licensor of Goods included in the System,
including without limitation assignment or transfer in favor
of the Purchaser of the benefit of any warranties given by
such producers or licensors to the Supplier.
30. Functional
Guarantees
30.1 The Supplier guarantees that, once the Operational
Acceptance Certificate(s) has been issued, the System
represents a complete, integrated solution to the Purchaser’s
requirements set forth in the Technical Requirements and it
conforms to all other aspects of the Contract. The Supplier
acknowledges
that
GCC
Clause 27
regarding
Commissioning and Operational Acceptance governs how
technical conformance of the System to the Contract
requirements will be determined.
30.2 If, for reasons attributable to the Supplier, the System does
not conform to the Technical Requirements or does not
conform to all other aspects of the Contract, the Supplier
shall at its cost and expense make such changes,
modifications, and/or additions to the System as may be
necessary to conform to the Technical Requirements and
meet all functional and performance standards. The Supplier
shall notify the Purchaser upon completion of the necessary
changes, modifications, and/or additions and shall request
the Purchaser to repeat the Operational Acceptance Tests
until the System achieves Operational Acceptance.
30.3 If the System (or Subsystem[s]) fails to achieve Operational
Acceptance, the Purchaser may consider termination of the
Contract, pursuant to GCC Clause 41.2.2, and forfeiture of
the Supplier’s Performance Security in accordance with
GCC Clause 13.3 in compensation for the extra costs and
delays likely to result from this failure.
31. Intellectual
Property Rights
Warranty
31.1 The Supplier hereby represents and warrants that:
(a)
the System as supplied, installed, tested, and accepted;
(b)
use of the System in accordance with the Contract; and
(c)
copying of the Software and Materials provided to the
Purchaser in accordance with the Contract
do not and will not infringe any Intellectual Property Rights
held by any third party and that it has all necessary rights or
Section IV. General Conditions of Contract
55
at its sole expense shall have secured in writing all transfers
of rights and other consents necessary to make the
assignments, licenses, and other transfers of Intellectual
Property Rights and the warranties set forth in the Contract,
and for the Purchaser to own or exercise all Intellectual
Property Rights as provided in the Contract. Without
limitation, the Supplier shall secure all necessary written
agreements, consents, and transfers of rights from its
employees and other persons or entities whose services are
used for development of the System.
32. Intellectual
Property Rights
Indemnity
32.1 The Supplier shall indemnify and hold harmless the
Purchaser and its employees and officers from and against
any and all losses, liabilities, and costs (including losses,
liabilities, and costs incurred in defending a claim alleging
such a liability), that the Purchaser or its employees or
officers may suffer as a result of any infringement or alleged
infringement of any Intellectual Property Rights by reason
of:
(a)
installation of the System by the Supplier or the use of
the System, including the Materials, in the country
where the site is located;
(b)
copying of the Software and Materials provided the
Supplier in accordance with the Agreement; and
(c)
sale of the products produced by the System in any
country, except to the extent that such losses, liabilities,
and costs arise as a result of the Purchaser’s breach of
GCC Clause 32.2.
32.2 Such indemnity shall not cover any use of the System,
including the Materials, other than for the purpose indicated
by or to be reasonably inferred from the Contract, any
infringement resulting from the use of the System, or any
products of the System produced thereby in association or
combination with any other goods or services not supplied
by the Supplier, where the infringement arises because of
such association or combination and not because of use of
the System in its own right.
32.3 Such indemnities shall also not apply if any claim of
infringement:
(a)
is asserted by a parent, subsidiary, or affiliate of the
Purchaser’s organization;
56
Section IV. General Conditions of Contract
(b)
is a direct result of a design mandated by the
Purchaser’s Technical Requirements and the possibility
of such infringement was duly noted in the Supplier’s
Bid; or
(c)
results from the alteration of the System, including the
Materials, by the Purchaser or any persons other than
the Supplier or a person authorized by the Supplier.
32.4 If any proceedings are brought or any claim is made against
the Purchaser arising out of the matters referred to in GCC
Clause 32.1, the Purchaser shall promptly give the Supplier
notice of such proceedings or claims, and the Supplier may
at its own expense and in the Purchaser’s name conduct such
proceedings or claim and any negotiations for the settlement
of any such proceedings or claim.
If the Supplier fails to notify the Purchaser within twentyeight (28) days after receipt of such notice that it intends to
conduct any such proceedings or claim, then the Purchaser
shall be free to conduct the same on its own behalf. Unless
the Supplier has so failed to notify the Purchaser within the
twenty-eight (28) days, the Purchaser shall make no
admission that may be prejudicial to the defense of any such
proceedings or claim. The Purchaser shall, at the Supplier’s
request, afford all available assistance to the Supplier in
conducting such proceedings or claim and shall be
reimbursed by the Supplier for all reasonable expenses
incurred in so doing.
32.5 The Purchaser shall indemnify and hold harmless the
Supplier and its employees, officers, and Subcontractors
from and against any and all losses, liabilities, and costs
(including losses, liabilities, and costs incurred in defending
a claim alleging such a liability) that the Supplier or its
employees, officers, or Subcontractors may suffer as a result
of any infringement or alleged infringement of any
Intellectual Property Rights arising out of or in connection
with any design, data, drawing, specification, or other
documents or materials provided to the Supplier in
connection with this Contract by the Purchaser or any
persons (other than the Supplier) contracted by the
Purchaser, except to the extent that such losses, liabilities,
and costs arise as a result of the Supplier’s breach of GCC
Clause 32.8.
32.6 Such indemnity shall not cover
Section IV. General Conditions of Contract
57
(a)
any use of the design, data, drawing, specification, or
other documents or materials, other than for the
purpose indicated by or to be reasonably inferred from
the Contract;
(b)
any infringement resulting from the use of the design,
data, drawing, specification, or other documents or
materials, or any products produced thereby, in
association or combination with any other Goods or
Services not provided by the Purchaser or any other
person contracted by the Purchaser, where the
infringement arises because of such association or
combination and not because of the use of the design,
data, drawing, specification, or other documents or
materials in its own right.
32.7 Such indemnities shall also not apply:
(a)
if any claim of infringement is asserted by a parent,
subsidiary, or affiliate of the Supplier’s organization;
(b)
to the extent that any claim of infringement is caused
by the alteration, by the Supplier, or any persons
contracted by the Supplier, of the design, data,
drawing, specification, or other documents or materials
provided to the Supplier by the Purchaser or any
persons contracted by the Purchaser.
32.8 If any proceedings are brought or any claim is made against
the Supplier arising out of the matters referred to in GCC
Clause 32.5, the Supplier shall promptly give the Purchaser
notice of such proceedings or claims, and the Purchaser may
at its own expense and in the Supplier’s name conduct such
proceedings or claim and any negotiations for the settlement
of any such proceedings or claim. If the Purchaser fails to
notify the Supplier within twenty-eight (28) days after
receipt of such notice that it intends to conduct any such
proceedings or claim, then the Supplier shall be free to
conduct the same on its own behalf. Unless the Purchaser
has so failed to notify the Supplier within the twenty-eight
(28) days, the Supplier shall make no admission that may be
prejudicial to the defense of any such proceedings or claim.
The Supplier shall, at the Purchaser’s request, afford all
available assistance to the Purchaser in conducting such
proceedings or claim and shall be reimbursed by the
Purchaser for all reasonable expenses incurred in so doing.
58
33. Limitation of
Liability
Section IV. General Conditions of Contract
33.1 Provided the following does not exclude or limit any
liabilities of either party in ways not permitted by applicable
law:
(a)
the Supplier shall not be liable to the Purchaser,
whether in contract, tort, or otherwise, for any indirect
or consequential loss or damage, loss of use, loss of
production, or loss of profits or interest costs, provided
that this exclusion shall not apply to any obligation of
the Supplier to pay liquidated damages to the
Purchaser; and
(b)
the aggregate liability of the Supplier to the Purchaser,
whether under the Contract, in tort or otherwise, shall
not exceed the total Contract Price, provided that this
limitation shall not apply to any obligation of the
Supplier to indemnify the Purchaser with respect to
intellectual property rights infringement.
G. RISK DISTRIBUTION
34. Transfer of
Ownership
34.1 With the exception of Software and Materials, the ownership
of the Information Technologies and other Goods shall be
transferred to the Purchaser at the time of Delivery or
otherwise under terms that may be agreed upon and specified
in the Contract Agreement.
34.2 Ownership and the terms of usage of the Software and
Materials supplied under the Contract shall be governed by
GCC Clause 15 (Copyright) and any elaboration in the
Technical Requirements.
34.3 Ownership of the Supplier’s Equipment used by the Supplier
and its Subcontractors in connection with the Contract shall
remain with the Supplier or its Subcontractors.
35. Care of the
System
35.1 The Purchaser shall become responsible for the care and
custody of the System or Subsystems upon their Delivery.
The Purchaser shall make good at its own cost any loss or
damage that may occur to the System or Subsystems from
any cause from the date of Delivery until the date of
Operational Acceptance of the System or Subsystems,
pursuant to GCC Clause 27 (Commissioning and Operational
Acceptance), excepting such loss or damage arising from
acts or omissions of the Supplier, its employees, or
subcontractors.
Section IV. General Conditions of Contract
59
35.2 If any loss or damage occurs to the System or any part of the
System by reason of:
(a)
(insofar as they relate to the country where the Project
Site is located) nuclear reaction, nuclear radiation,
radioactive contamination, a pressure wave caused by
aircraft or other aerial objects, or any other occurrences
that an experienced contractor could not reasonably
foresee, or if reasonably foreseeable could not
reasonably make provision for or insure against, insofar
as such risks are not normally insurable on the
insurance market and are mentioned in the general
exclusions of the policy of insurance taken out under
GCC Clause 37;
(b)
any use not in accordance with the Contract, by the
Purchaser or any third party;
(c)
any use of or reliance upon any design, data, or
specification provided or designated by or on behalf of
the Purchaser, or any such matter for which the
Supplier has disclaimed responsibility in accordance
with GCC Clause 21.1.2,
the Purchaser shall pay to the Supplier all sums payable in
respect of the System or Subsystems that have achieved
Operational Acceptance, notwithstanding that the same be
lost, destroyed, or damaged. If the Purchaser requests the
Supplier in writing to make good any loss or damage to the
System thereby occasioned, the Supplier shall make good the
same at the cost of the Purchaser in accordance with GCC
Clause 39. If the Purchaser does not request the Supplier in
writing to make good any loss or damage to the System
thereby occasioned, the Purchaser shall either request a
change in accordance with GCC Clause 39, excluding the
performance of that part of the System thereby lost,
destroyed, or damaged, or, where the loss or damage affects
a substantial part of the System, the Purchaser shall
terminate the Contract pursuant to GCC Clause 41.1.
35.3 The Purchaser shall be liable for any loss of or damage to
any Supplier’s Equipment which the Purchaser has
authorized to locate within the Purchaser's premises for use
in fulfillment of Supplier's obligations under the Contract,
except where such loss or damage arises from acts or
omissions of the Supplier, its employees, or subcontractors.
36. Loss of or
36.1 The Supplier and each and every Subcontractor shall abide
60
Section IV. General Conditions of Contract
Damage to
Property;
Accident or
Injury to
Workers;
Indemnification
by the job safety, insurance, customs, and immigration
measures prevalent and laws in force in the Purchaser’s
Country.
36.2 Subject to GCC Clause 36.3, the Supplier shall indemnify
and hold harmless the Purchaser and its employees and
officers from and against any and all losses, liabilities and
costs (including losses, liabilities, and costs incurred in
defending a claim alleging such a liability) that the Purchaser
or its employees or officers may suffer as a result of the
death or injury of any person or loss of or damage to any
property (other than the System, whether accepted or not)
arising in connection with the supply, installation, testing,
and Commissioning of the System and by reason of the
negligence of the Supplier or its Subcontractors, or their
employees, officers or agents, except any injury, death, or
property damage caused by the negligence of the Purchaser,
its contractors, employees, officers, or agents.
36.3 If any proceedings are brought or any claim is made against
the Purchaser that might subject the Supplier to liability
under GCC Clause 36.2, the Purchaser shall promptly give
the Supplier notice of such proceedings or claims, and the
Supplier may at its own expense and in the Purchaser’s name
conduct such proceedings or claim and any negotiations for
the settlement of any such proceedings or claim. If the
Supplier fails to notify the Purchaser within twenty-eight
(28) days after receipt of such notice that it intends to
conduct any such proceedings or claim, then the Purchaser
shall be free to conduct the same on its own behalf. Unless
the Supplier has so failed to notify the Purchaser within the
twenty-eight (28) day period, the Purchaser shall make no
admission that may be prejudicial to the defense of any such
proceedings or claim. The Purchaser shall, at the Supplier’s
request, afford all available assistance to the Supplier in
conducting such proceedings or claim and shall be
reimbursed by the Supplier for all reasonable expenses
incurred in so doing.
36.4 The Purchaser shall indemnify and hold harmless the
Supplier and its employees, officers, and Subcontractors
from any and all losses, liabilities, and costs (including
losses, liabilities, and costs incurred in defending a claim
alleging such a liability) that the Supplier or its employees,
officers, or Subcontractors may suffer as a result of the death
or personal injury of any person or loss of or damage to
property of the Purchaser, other than the System not yet
Section IV. General Conditions of Contract
61
achieving Operational Acceptance, that is caused by fire,
explosion, or any other perils, in excess of the amount
recoverable from insurances procured under GCC Clause 37
(Insurances), provided that such fire, explosion, or other
perils were not caused by any act or failure of the Supplier.
36.5 If any proceedings are brought or any claim is made against
the Supplier that might subject the Purchaser to liability
under GCC Clause 36.4, the Supplier shall promptly give the
Purchaser notice of such proceedings or claims, and the
Purchaser may at its own expense and in the Supplier’s name
conduct such proceedings or claim and any negotiations for
the settlement of any such proceedings or claim. If the
Purchaser fails to notify the Supplier within twenty-eight
(28) days after receipt of such notice that it intends to
conduct any such proceedings or claim, then the Supplier
shall be free to conduct the same on its own behalf. Unless
the Purchaser has so failed to notify the Supplier within the
twenty-eight (28) days, the Supplier shall make no admission
that may be prejudicial to the defense of any such
proceedings or claim. The Supplier shall, at the Purchaser’s
request, afford all available assistance to the Purchaser in
conducting such proceedings or claim and shall be
reimbursed by the Purchaser for all reasonable expenses
incurred in so doing.
36.6 The party entitled to the benefit of an indemnity under this
GCC Clause 36 shall take all reasonable measures to
mitigate any loss or damage that has occurred. If the party
fails to take such measures, the other party’s liabilities shall
be correspondingly reduced.
37. Insurances
37.1 The Supplier shall at its expense take out and maintain in
effect, or cause to be taken out and maintained in effect,
during the performance of the Contract, the insurance set
forth below. The identity of the insurers and the form of the
policies shall be subject to the approval of the Purchaser,
who should not unreasonably withhold such approval.
(a)
Cargo Insurance During Transport
as applicable, 110 percent of the price of the
Information Technologies and other Goods in a freely
convertible currency, covering the Goods from
physical loss or damage during shipment through
receipt at the Project Site.
62
Section IV. General Conditions of Contract
(b)
Installation “All Risks” Insurance
as applicable, 110 percent of the price of the
Information Technologies and other Goods covering
the Goods at the site from all risks of physical loss or
damage (excluding only perils commonly excluded
under “all risks” insurance policies of this type by
reputable insurers) occurring prior to Operational
Acceptance of the System.
(c)
Third-Party Liability Insurance
On terms as specified in the SCC, covering bodily
injury or death suffered by third parties (including the
Purchaser’s personnel) and loss of or damage to
property (including the Purchaser’s property and any
Subsystems that have been accepted by the Purchaser)
occurring in connection with the supply and installation
of the Information System.
(d)
Automobile Liability Insurance
In accordance with the statutory requirements
prevailing in the Purchaser’s Country, covering use of
all vehicles used by the Supplier or its Subcontractors
(whether or not owned by them) in connection with the
execution of the Contract.
(e)
Other Insurance (if any), as specified in the SCC.
37.2 The Purchaser shall be named as co-insured under all
insurance policies taken out by the Supplier pursuant to GCC
Clause 37.1, except for the Third-Party Liability, and the
Supplier’s Subcontractors shall be named as co-insured
under all insurance policies taken out by the Supplier
pursuant to GCC Clause 37.1 except for Cargo Insurance
During Transport. All insurer’s rights of subrogation against
such co-insured for losses or claims arising out of the
performance of the Contract shall be waived under such
policies.
37.3 The Supplier shall deliver to the Purchaser certificates of
insurance (or copies of the insurance policies) as evidence
that the required policies are in full force and effect.
37.4 The Supplier shall ensure that, where applicable, its
Subcontractor(s) shall take out and maintain in effect
adequate insurance policies for their personnel and vehicles
and for work executed by them under the Contract, unless
Section IV. General Conditions of Contract
63
such Subcontractors are covered by the policies taken out by
the Supplier.
37.5 If the Supplier fails to take out and/or maintain in effect the
insurance referred to in GCC Clause 37.1, the Purchaser may
take out and maintain in effect any such insurance and may
from time to time deduct from any amount due the Supplier
under the Contract any premium that the Purchaser shall
have paid to the insurer or may otherwise recover such
amount as a debt due from the Supplier.
37.6 Unless otherwise provided in the Contract, the Supplier shall
prepare and conduct all and any claims made under the
policies effected by it pursuant to this GCC Clause 37, and
all monies payable by any insurers shall be paid to the
Supplier. The Purchaser shall give to the Supplier all such
reasonable assistance as may be required by the Supplier in
connection with any claim under the relevant insurance
policies. With respect to insurance claims in which the
Purchaser’s interest is involved, the Supplier shall not give
any release or make any compromise with the insurer
without the prior written consent of the Purchaser. With
respect to insurance claims in which the Supplier’s interest is
involved, the Purchaser shall not give any release or make
any compromise with the insurer without the prior written
consent of the Supplier.
38. Force Majeure
38.1 “Force Majeure” shall mean any event beyond the
reasonable control of the Purchaser or of the Supplier, as the
case may be, and which is unavoidable notwithstanding the
reasonable care of the party affected and shall include,
without limitation, the following:
(a)
war, hostilities, or warlike operations (whether a state
of war be declared or not), invasion, act of foreign
enemy, and civil war;
(b)
rebellion, revolution, insurrection, mutiny, usurpation
of civil or military government, conspiracy, riot, civil
commotion, and terrorist acts;
(c)
confiscation,
nationalization,
mobilization,
commandeering or requisition by or under the order of
any government or de jure or de facto authority or
ruler, or any other act or failure to act of any local state
or national government authority;
(d)
strike, sabotage, lockout, embargo, import restriction,
64
Section IV. General Conditions of Contract
port congestion, lack of usual means of public
transportation and communication, industrial dispute,
shipwreck, shortage or restriction of power supply,
epidemics, quarantine, and plague;
(e)
earthquake, landslide, volcanic activity, fire, flood or
inundation, tidal wave, typhoon or cyclone, hurricane,
storm, lightning, or other inclement weather condition,
nuclear and pressure waves, or other natural or
physical disaster;
(f)
failure, by the Supplier, to obtain the necessary export
permit(s) from the governments of the Country(s) of
Origin of the Information Technologies or other
Goods, or Supplier’s Equipment provided that the
Supplier has made all reasonable efforts to obtain the
required export permit(s), including the exercise of due
diligence in determining the eligibility of the System
and all of its components for receipt of the necessary
export permits.
38.2 If either party is prevented, hindered, or delayed from or in
performing any of its obligations under the Contract by an
event of Force Majeure, then it shall notify the other in
writing of the occurrence of such event and the
circumstances of the event of Force Majeure within fourteen
(14) days after the occurrence of such event.
38.3 The party who has given such notice shall be excused from
the performance or punctual performance of its obligations
under the Contract for so long as the relevant event of Force
Majeure continues and to the extent that such party’s
performance is prevented, hindered, or delayed. The Time
for Achieving Operational Acceptance shall be extended in
accordance with GCC Clause 40 (Extension of Time for
Achieving Operational Acceptance).
38.4 The party or parties affected by the event of Force Majeure
shall use reasonable efforts to mitigate the effect of the event
of Force Majeure upon its or their performance of the
Contract and to fulfill its or their obligations under the
Contract, but without prejudice to either party’s right to
terminate the Contract under GCC Clause 38.6.
38.5 No delay or nonperformance by either party to this Contract
caused by the occurrence of any event of Force Majeure
shall:
Section IV. General Conditions of Contract
65
(a)
constitute a default or breach of the Contract;
(b)
(subject to GCC Clauses 35.2, 38.3, and 38.4) give rise
to any claim for damages or additional cost or expense
occasioned by the delay or nonperformance,
if, and to the extent that, such delay or nonperformance is
caused by the occurrence of an event of Force Majeure.
38.6 If the performance of the Contract is substantially prevented,
hindered, or delayed for a single period of more than sixty
(60) days or an aggregate period of more than one hundred
and twenty (120) days on account of one or more events of
Force Majeure during the time period covered by the
Contract, the parties will attempt to develop a mutually
satisfactory solution, failing which, either party may
terminate the Contract by giving a notice to the other.
38.7 In the event of termination pursuant to GCC Clause 38.6, the
rights and obligations of the Purchaser and the Supplier shall
be as specified in GCC Clauses 41.1.2 and 41.1.3.
38.8 Notwithstanding GCC Clause 38.5, Force Majeure shall not
apply to any obligation of the Purchaser to make payments to
the Supplier under this Contract.
H. CHANGE IN CONTRACT ELEMENTS
39. Changes to the
System
39.1 Introducing a Change
39.1.1 Subject to GCC Clauses 39.2.5 and 39.2.7, the
Purchaser shall have the right to propose, and
subsequently require, the Project Manager to order
the Supplier from time to time during the
performance of the Contract to make any change,
modification, addition, or deletion to, in, or from the
System (interchangeably called “Change”), provided
that such Change falls within the general scope of
the System, does not constitute unrelated work, and
is technically practicable, taking into account both
the state of advancement of the System and the
technical compatibility of the Change envisaged
with the nature of the System as originally specified
in the Contract.
A Change may involve, but is not restricted to, the
substitution of updated Information Technologies
66
Section IV. General Conditions of Contract
and related Services in accordance
GCC Clause 23 (Product Upgrades).
with
39.1.2 The Supplier may from time to time during its
performance of the Contract propose to the
Purchaser (with a copy to the Project Manager) any
Change that the Supplier considers necessary or
desirable to improve the quality or efficiency of the
System. The Purchaser may at its discretion
approve or reject any Change proposed by the
Supplier.
39.1.3 Notwithstanding GCC Clauses 39.1.1 and 39.1.2, no
change made necessary because of any default of the
Supplier in the performance of its obligations under
the Contract shall be deemed to be a Change, and
such change shall not result in any adjustment of the
Contract Price or the Time for Achieving
Operational Acceptance.
39.1.4 The procedure on how to proceed with and execute
Changes is specified in GCC Clauses 39.2 and 39.3,
and further details and sample forms are provided in
the Sample Forms Section in the Bidding
Documents.
39.1.5 Moreover, the Purchaser and Supplier will agree,
during development of the Project Plan, to a date
prior to the scheduled date for Operational
Acceptance, after which the Technical Requirements
for the System shall be “frozen.” Any Change
initiated after this time will be dealt with after
Operational Acceptance.
39.2 Changes Originating from Purchaser
39.2.1 If the Purchaser proposes a Change pursuant to GCC
Clauses 39.1.1, it shall send to the Supplier a
“Request for Change Proposal,” requiring the
Supplier to prepare and furnish to the Project
Manager as soon as reasonably practicable a
“Change Proposal,” which shall include the
following:
(a) brief description of the Change;
(b) impact on the Time for Achieving Operational
Acceptance;
Section IV. General Conditions of Contract
67
(c) detailed estimated cost of the Change;
(d) effect on Functional Guarantees (if any);
(e) effect on any other provisions of the Contract.
39.2.2 Prior to preparing and submitting the “Change
Proposal,” the Supplier shall submit to the Project
Manager an “Change Estimate Proposal,” which
shall be an estimate of the cost of preparing the
Change Proposal, plus a first approximation of the
suggested approach and cost for implementing the
changes. Upon receipt of the Supplier’s Change
Estimate Proposal, the Purchaser shall do one of the
following:
(a) accept the Supplier’s estimate with instructions
to the Supplier to proceed with the preparation
of the Change Proposal;
(b) advise the Supplier of any part of its Change
Estimate Proposal that is unacceptable and
request the Supplier to review its estimate;
(c) advise the Supplier that the Purchaser does not
intend to proceed with the Change.
39.2.3 Upon receipt of the Purchaser’s instruction to
proceed under GCC Clause 39.2.2 (a), the Supplier
shall, with proper expedition, proceed with the
preparation of the Change Proposal, in accordance
with GCC Clause 39.2.1. The Supplier, at its
discretion, may specify a validity period for the
Change Proposal, after which if the Purchaser and
Supplier has not reached agreement in accordance
with GCC Clause 39.2.6, then GCC Clause 39.2.7
shall apply.
39.2.4 The pricing of any Change shall, as far as
practicable, be calculated in accordance with the
rates and prices included in the Contract. If the
nature of the Change is such that the Contract rates
and prices are inequitable, the parties to the Contract
shall agree on other specific rates to be used for
valuing the Change.
39.2.5 If before or during the preparation of the Change
Proposal it becomes apparent that the aggregate
impact of compliance with the Request for Change
68
Section IV. General Conditions of Contract
Proposal and with all other Change Orders that have
already become binding upon the Supplier under this
GCC Clause 39 would be to increase or decrease the
Contract Price as originally set forth in Article 2
(Contract Price) of the Contract Agreement by more
than fifteen (15) percent, the Supplier may give a
written notice of objection to this Request for
Change Proposal prior to furnishing the Change
Proposal. If the Purchaser accepts the Supplier’s
objection, the Purchaser shall withdraw the proposed
Change and shall notify the Supplier in writing of its
acceptance.
The Supplier’s failure to so object to a Request for
Change Proposal shall neither affect its right to
object to any subsequent requested Changes or
Change Orders, nor affect its right to take into
account, when making such subsequent objection,
the percentage increase or decrease in the Contract
Price that any Change not objected to by the
Supplier represents.
39.2.6 Upon receipt of the Change Proposal, the Purchaser
and the Supplier shall mutually agree upon all
matters contained in the Change Proposal. Within
fourteen (14) days after such agreement, the
Purchaser shall, if it intends to proceed with the
Change, issue the Supplier a Change Order. If the
Purchaser is unable to reach a decision within
fourteen (14) days, it shall notify the Supplier with
details of when the Supplier can expect a decision.
If the Purchaser decides not to proceed with the
Change for whatever reason, it shall, within the said
period of fourteen (14) days, notify the Supplier
accordingly.
Under such circumstances, the
Supplier shall be entitled to reimbursement of all
costs reasonably incurred by it in the preparation of
the Change Proposal, provided that these do not
exceed the amount given by the Supplier in its
Change Estimate Proposal submitted in accordance
with GCC Clause 39.2.2.
39.2.7 If the Purchaser and the Supplier cannot reach
agreement on the price for the Change, an equitable
adjustment to the Time for Achieving Operational
Acceptance, or any other matters identified in the
Change Proposal, the Change will not be
Section IV. General Conditions of Contract
69
implemented. However, this provision does not
limit the rights of either party under GCC Clause 6
(Settlement of Disputes).
39.3 Changes Originating from Supplier
If the Supplier proposes a Change pursuant to GCC
Clause 39.1.2, the Supplier shall submit to the Project
Manager a written “Application for Change Proposal,”
giving reasons for the proposed Change and including the
information specified in GCC Clause 39.2.1. Upon receipt
of the Application for Change Proposal, the parties shall
follow the procedures outlined in GCC Clauses 39.2.6 and
39.2.7. However, should the Purchaser choose not to
proceed or the Purchaser and the Supplier cannot come to
agreement on the change during any validity period that the
Supplier may specify in its Application for Change Proposal,
the Supplier shall not be entitled to recover the costs of
preparing the Application for Change Proposal, unless
subject to an agreement between the Purchaser and the
Supplier to the contrary.
40. Extension of
Time for
Achieving
Operational
Acceptance
40.1 The time(s) for achieving Operational Acceptance specified
in the Schedule of Implementation shall be extended if the
Supplier is delayed or impeded in the performance of any of
its obligations under the Contract by reason of any of the
following:
(a)
any Change in the System as provided in GCC
Clause 39 (Change in the Information System);
(b)
any occurrence of Force Majeure as provided in GCC
Clause 38 (Force Majeure);
(c)
default of the Purchaser; or
(d)
any other matter specifically mentioned in the
Contract;
by such period as shall be fair and reasonable in all the
circumstances and as shall fairly reflect the delay or
impediment sustained by the Supplier.
40.2 Except where otherwise specifically provided in the
Contract, the Supplier shall submit to the Project Manager a
notice of a claim for an extension of the time for achieving
Operational Acceptance, together with particulars of the
event or circumstance justifying such extension as soon as
reasonably practicable after the commencement of such
70
Section IV. General Conditions of Contract
event or circumstance. As soon as reasonably practicable
after receipt of such notice and supporting particulars of the
claim, the Purchaser and the Supplier shall agree upon the
period of such extension. In the event that the Supplier does
not accept the Purchaser’s estimate of a fair and reasonable
time extension, the Supplier shall be entitled to refer the
matter to the provisions for the Settlement of Disputes
pursuant to GCC Clause 6.
40.3 The Supplier shall at all times use its reasonable efforts to
minimize any delay in the performance of its obligations
under the Contract.
41. Termination
41.1 Termination for Purchaser’s Convenience
41.1.1 The Purchaser may at any time terminate the
Contract for any reason by giving the Supplier a
notice of termination that refers to this GCC
Clause 41.1.
41.1.2 Upon receipt of the notice of termination under GCC
Clause 41.1.1, the Supplier shall either as soon as
reasonably practical or upon the date specified in the
notice of termination
(a) cease all further work, except for such work as
the Purchaser may specify in the notice of
termination for the sole purpose of protecting
that part of the System already executed, or any
work required to leave the site in a clean and
safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to GCC
Clause 41.1.2 (d) (ii) below;
(c) remove all Supplier’s Equipment from the site,
repatriate the Supplier’s and its Subcontractors’
personnel from the site, remove from the site any
wreckage, rubbish, and debris of any kind;
(d) in addition, the Supplier, subject to the payment
specified in GCC Clause 41.1.3, shall
(i)
deliver to the Purchaser the parts of the
System executed by the Supplier up to the
date of termination;
(ii)
to the extent legally possible, assign to the
Section IV. General Conditions of Contract
71
Purchaser all right, title, and benefit of the
Supplier to the System, or Subsystem, as at
the date of termination, and, as may be
required by the Purchaser, in any
subcontracts concluded between the
Supplier and its Subcontractors;
(iii) deliver to the Purchaser all nonproprietary
drawings, specifications, and other
documents prepared by the Supplier or its
Subcontractors as of the date of
termination in connection with the System.
41.1.3 In the event of termination of the Contract under
GCC Clause 41.1.1, the Purchaser shall pay to the
Supplier the following amounts:
(a) the Contract Price, properly attributable to the
parts of the System executed by the Supplier as
of the date of termination;
(b) the costs reasonably incurred by the Supplier in
the removal of the Supplier’s Equipment from
the site and in the repatriation of the Supplier’s
and its Subcontractors’ personnel;
(c) any amount to be paid by the Supplier to its
Subcontractors in connection with the
termination of any subcontracts, including any
cancellation charges;
(d) costs incurred by the Supplier in protecting the
System and leaving the site in a clean and safe
condition pursuant to GCC Clause 41.1.2 (a); and
(e) the cost of satisfying all other obligations,
commitments, and claims that the Supplier may
in good faith have undertaken with third parties
in connection with the Contract and that are not
covered by GCC Clauses 41.1.3 (a) through (d)
above.
41.2 Termination for Supplier’s Default
41.2.1
The Purchaser, without prejudice to any other
rights or remedies it may possess, may terminate
the Contract forthwith in the following
circumstances by giving a notice of termination
and its reasons therefore to the Supplier, referring
72
Section IV. General Conditions of Contract
to this GCC Clause 41.2:
(a) if the Supplier becomes bankrupt or insolvent,
has a receiving order issued against it,
compounds with its creditors, or, if the Supplier
is a corporation, a resolution is passed or order is
made for its winding up (other than a voluntary
liquidation for the purposes of amalgamation or
reconstruction), a receiver is appointed over any
part of its undertaking or assets, or if the
Supplier takes or suffers any other analogous
action in consequence of debt;
(b) if the Supplier assigns or transfers the Contract
or any right or interest therein in violation of the
provision of GCC Clause 42 (Assignment); or
(c) if the Supplier, in the judgment of the Purchaser,
has engaged in corrupt, fraudulent, collusive,
coercive or obstructive practices, in competing
for or in executing the Contract, including but
not limited to willful misrepresentation of facts
concerning ownership of Intellectual Property
Rights in, or proper authorization and/or licenses
from the owner to offer, the hardware, software,
or materials provided under this Contract.
For the purposes of this Clause:
(i)
“corrupt practice”1 is the offering, giving,
receiving or soliciting, directly or
indirectly, of anything of value to
influence improperly the actions of
another party;
(ii)
“fraudulent practice”2 is any act or
omission, including a misrepresentation,
that knowingly or recklessly misleads, or
attempts to mislead, a party to obtain a
financial or other benefit or to avoid an
1
“Another party” refers to a public official acting in relation to the procurement process or contract
execution]. In this context, “public official” includes World Bank staff and employees of other
organizations taking or reviewing procurement decisions.
2
A “party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement process
or contract execution; and the “act or omission” is intended to influence the procurement process or
contract execution.
Section IV. General Conditions of Contract
73
obligation;
(iii) “collusive practice”1 is an arrangement
between two or more parties designed to
achieve an improper purpose, including to
influence improperly the actions of
another party;
(iv) “coercive practice”2 is impairing or
harming, or threatening to impair or harm,
directly or indirectly, any party or the
property of the party to influence
improperly the actions of a party;
(v)
“obstructive practice” is
(aa) deliberately destroying, falsifying,
altering or concealing of evidence
material to the investigation or
making
false
statements
to
investigators in order to materially
impede a Bank investigation into
allegations of a corrupt, fraudulent,
coercive or collusive practice; and/or
threatening, harassing or intimidating
any party to prevent it from
disclosing its knowledge of matters
relevant to the investigation or from
pursuing the investigation; or
(bb) acts intended to materially impede
the exercise of the Bank’s inspection
and audit rights provided for under
Sub-Clause 9.8.
41.2.2 If the Supplier:
(a) has abandoned or repudiated the Contract;
(b) has without valid reason failed to commence
work on the System promptly;
(c) persistently fails to execute the Contract in
accordance with the Contract or persistently
neglects to carry out its obligations under the
1
“Parties” refers to participants in the procurement process (including public officials) attempting to
establish bid prices at artificial, non competitive levels.
2
A “party” refers to a participant in the procurement process or contract execution.
74
Section IV. General Conditions of Contract
Contract without just cause;
(d) refuses or is unable to provide sufficient
Materials, Services, or labor to execute and
complete the System in the manner specified in
the Agreed and Finalized Project Plan furnished
under GCC Clause 19 at rates of progress that
give reasonable assurance to the Purchaser that
the Supplier can attain Operational Acceptance
of the System by the Time for Achieving
Operational Acceptance as extended;
then the Purchaser may, without prejudice to any
other rights it may possess under the Contract, give a
notice to the Supplier stating the nature of the
default and requiring the Supplier to remedy the
same. If the Supplier fails to remedy or to take steps
to remedy the same within fourteen (14) days of its
receipt of such notice, then the Purchaser may
terminate the Contract forthwith by giving a notice
of termination to the Supplier that refers to this GCC
Clause 41.2.
41.2.3 Upon receipt of the notice of termination under GCC
Clauses 41.2.1 or 41.2.2, the Supplier shall, either
immediately or upon such date as is specified in the
notice of termination:
(a) cease all further work, except for such work as
the Purchaser may specify in the notice of
termination for the sole purpose of protecting
that part of the System already executed or any
work required to leave the site in a clean and
safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to GCC
Clause 41.2.3 (d) below;
(c) deliver to the Purchaser the parts of the System
executed by the Supplier up to the date of
termination;
(d) to the extent legally possible, assign to the
Purchaser all right, title and benefit of the
Supplier to the System or Subsystems as at the
date of termination, and, as may be required by
the Purchaser, in any subcontracts concluded
Section IV. General Conditions of Contract
75
between the Supplier and its Subcontractors;
(e) deliver to the Purchaser all drawings,
specifications, and other documents prepared by
the Supplier or its Subcontractors as at the date
of termination in connection with the System.
41.2.4 The Purchaser may enter upon the site, expel the
Supplier, and complete the System itself or by
employing any third party. Upon completion of the
System or at such earlier date as the Purchaser
thinks appropriate, the Purchaser shall give notice to
the Supplier that such Supplier’s Equipment will be
returned to the Supplier at or near the site and shall
return such Supplier’s Equipment to the Supplier in
accordance with such notice. The Supplier shall
thereafter without delay and at its cost remove or
arrange removal of the same from the site.
41.2.5 Subject to GCC Clause 41.2.6, the Supplier shall be
entitled to be paid the Contract Price attributable to
the portion of the System executed as at the date of
termination and the costs, if any, incurred in
protecting the System and in leaving the site in a
clean and safe condition pursuant to GCC
Clause 41.2.3 (a). Any sums due the Purchaser from
the Supplier accruing prior to the date of termination
shall be deducted from the amount to be paid to the
Supplier under this Contract.
41.2.6 If the Purchaser completes the System, the cost of
completing the System by the Purchaser shall be
determined. If the sum that the Supplier is entitled
to be paid, pursuant to GCC Clause 41.2.5, plus the
reasonable costs incurred by the Purchaser in
completing the System, exceeds the Contract Price,
the Supplier shall be liable for such excess. If such
excess is greater than the sums due the Supplier
under GCC Clause 41.2.5, the Supplier shall pay the
balance to the Purchaser, and if such excess is less
than the sums due the Supplier under GCC
Clause 41.2.5, the Purchaser shall pay the balance to
the Supplier. The Purchaser and the Supplier shall
agree, in writing, on the computation described
above and the manner in which any sums shall be
paid.
76
Section IV. General Conditions of Contract
41.3 Termination by Supplier
41.3.1 If:
(a) the Purchaser has failed to pay the Supplier any
sum due under the Contract within the specified
period, has failed to approve any invoice or
supporting documents without just cause
pursuant to the SCC, or commits a substantial
breach of the Contract, the Supplier may give a
notice to the Purchaser that requires payment of
such sum, with interest on this sum as stipulated
in GCC Clause 12.3, requires approval of such
invoice or supporting documents, or specifies the
breach and requires the Purchaser to remedy the
same, as the case may be. If the Purchaser fails
to pay such sum together with such interest, fails
to approve such invoice or supporting documents
or give its reasons for withholding such
approval, fails to remedy the breach or take steps
to remedy the breach within fourteen (14) days
after receipt of the Supplier’s notice; or
(b) the Supplier is unable to carry out any of its
obligations under the Contract for any reason
attributable to the Purchaser, including but not
limited to the Purchaser’s failure to provide
possession of or access to the site or other areas
or failure to obtain any governmental permit
necessary for the execution and/or completion of
the System;
then the Supplier may give a notice to the Purchaser
of such events, and if the Purchaser has failed to pay
the outstanding sum, to approve the invoice or
supporting documents, to give its reasons for
withholding such approval, or to remedy the breach
within twenty-eight (28) days of such notice, or if
the Supplier is still unable to carry out any of its
obligations under the Contract for any reason
attributable to the Purchaser within twenty-eight
(28) days of the said notice, the Supplier may by a
further notice to the Purchaser referring to this GCC
Clause 41.3.1, forthwith terminate the Contract.
41.3.2 The Supplier may terminate the Contract
immediately by giving a notice to the Purchaser to
that effect, referring to this GCC Clause 41.3.2, if
Section IV. General Conditions of Contract
77
the Purchaser becomes bankrupt or insolvent, has a
receiving order issued against it, compounds with its
creditors, or, being a corporation, if a resolution is
passed or order is made for its winding up (other
than a voluntary liquidation for the purposes of
amalgamation or reconstruction), a receiver is
appointed over any part of its undertaking or assets,
or if the Purchaser takes or suffers any other
analogous action in consequence of debt.
41.3.3 If the Contract is terminated under GCC
Clauses 41.3.1 or 41.3.2, then the Supplier shall
immediately:
(a) cease all further work, except for such work as
may be necessary for the purpose of protecting
that part of the System already executed, or any
work required to leave the site in a clean and
safe condition;
(b) terminate all subcontracts, except those to be
assigned to the Purchaser pursuant to
Clause 41.3.3 (d) (ii);
(c) remove all Supplier’s Equipment from the site
and repatriate the Supplier’s and its
Subcontractor’s personnel from the site.
(d) In addition, the Supplier, subject to the payment
specified in GCC Clause 41.3.4, shall:
(i)
deliver to the Purchaser the parts of the
System executed by the Supplier up to the
date of termination;
(ii)
to the extent legally possible, assign to the
Purchaser all right, title, and benefit of the
Supplier to the System, or Subsystems, as
of the date of termination, and, as may be
required by the Purchaser, in any
subcontracts concluded between the
Supplier and its Subcontractors;
(iii) to the extent legally possible, deliver to the
Purchaser all drawings, specifications, and
other documents prepared by the Supplier
or its Subcontractors as of the date of
termination in connection with the System.
78
Section IV. General Conditions of Contract
41.3.4 If the Contract is terminated under GCC
Clauses 41.3.1 or 41.3.2, the Purchaser shall pay to
the Supplier all payments specified in GCC
Clause 41.1.3, and reasonable compensation for all
loss, except for loss of profit, or damage sustained
by the Supplier arising out of, in connection with, or
in consequence of such termination.
41.3.5 Termination by the Supplier pursuant to this GCC
Clause 41.3 is without prejudice to any other rights
or remedies of the Supplier that may be exercised in
lieu of or in addition to rights conferred by GCC
Clause 41.3.
41.4 In this GCC Clause 41, the expression “portion of the
System executed” shall include all work executed, Services
provided, and all Information Technologies, or other Goods
acquired (or subject to a legally binding obligation to
purchase) by the Supplier and used or intended to be used for
the purpose of the System, up to and including the date of
termination.
41.5 In this GCC Clause 41, in calculating any monies due from
the Purchaser to the Supplier, account shall be taken of any
sum previously paid by the Purchaser to the Supplier under
the Contract, including any advance payment paid pursuant
to the SCC.
42. Assignment
42.l Neither the Purchaser nor the Supplier shall, without the
express prior written consent of the other, assign to any third
party the Contract or any part thereof, or any right, benefit,
obligation, or interest therein or thereunder, except that the
Supplier shall be entitled to assign either absolutely or by
way of charge any monies due and payable to it or that may
become due and payable to it under the Contract.
Section V. Special Conditions of Contract
79
SECTION V. SPECIAL CONDITIONS OF CONTRACT (SCC)
Table of Clauses
A. Contract and Interpretation .......................................................................................... 81
1.
2.
3.
4.
5.
6.
Definitions (GCC Clause 1) ..................................................................................... 81
Contract Documents (GCC Clause 2) ...................................................................... 81
Interpretation (GCC Clause 3) ................................................................................. 81
Notices (GCC Clause 4)........................................................................................... 82
Governing Law (GCC Clause 5).............................................................................. 82
Settlement of Disputes (GCC Clause 6) .................................................................. 82
B. Subject Matter of Contract ............................................................................................ 83
7.
8.
9.
10.
Scope of the System (GCC Clause 7) ...................................................................... 83
Time for Commencement and Operational Acceptance (GCC Clause 8) ............... 83
Supplier’s Responsibilities (GCC Clause 9) ............................................................ 83
Purchaser’s Responsibilities (GCC Clause 10)........................................................ 83
C. Payment............................................................................................................................ 84
11.
12.
13.
14.
Contract Price (GCC Clause 11) .............................................................................. 84
Terms of Payment (GCC Clause 12) ....................................................................... 84
Securities (GCC Clause 13) ..................................................................................... 85
Taxes and Duties (GCC Clause 14) ......................................................................... 85
D. Intellectual Property ....................................................................................................... 85
15.
16.
17.
Copyright (GCC Clause 15)..................................................................................... 85
Software License Agreements (GCC Clause 16)..................................................... 86
Confidential Information (GCC Clause 17) ............................................................. 87
E. Supply, Installation, Testing, Commissioning, and Acceptance of the System ......... 87
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
Representatives (GCC Clause 18) ........................................................................... 87
Project Plan (GCC Clause 19) ................................................................................. 87
Subcontracting (GCC Clause 20)............................................................................. 89
Design and Engineering (GCC Clause 21) .............................................................. 89
Procurement, Delivery, and Transport (GCC Clause 22) ........................................ 89
Product Upgrades (GCC Clause 23) ......................... Error! Bookmark not defined.
Implementation, Installation, and Other Services (GCC Clause 24) ....................... 90
Inspections and Tests (GCC Clause 25) .................................................................. 90
Installation of the System (GCC Clause 26) ............................................................ 90
Commissioning and Operational Acceptance (GCC Clause 27) ............................. 90
F. Guarantees and Liabilities .............................................................................................. 90
28.
29.
Operational Acceptance Time Guarantee (GCC Clause 28) ................................... 90
Defect Liability (GCC Clause 29) ........................................................................... 91
80
Section VI. Technical Requirements
30.
31.
32.
33.
Functional Guarantees (GCC Clause 30) ................................................................. 91
Intellectual Property Rights Warranty (GCC Clause 31) ......................................... 91
Intellectual Property Rights Indemnity (GCC Clause 32) ........................................ 91
Limitation of Liability (GCC Clause 33) ................................................................. 91
G. Risk Distribution ............................................................................................................. 92
34.
35.
36.
37.
38.
Transfer of Ownership (GCC Clause 34) ................................................................. 92
Care of the System (GCC Clause 35) ....................................................................... 92
Loss of or Damage to Property; Accident or Injury to Workers; Indemnification (GCC
Clause 36) ................................................................................................................. 92
Insurances (GCC Clause 37) .................................................................................... 92
Force Majeure (GCC Clause 38) .............................................................................. 92
H. Change in Contract Elements......................................................................................... 93
39.
40.
41.
42.
Changes to the System (GCC Clause 39) ................................................................. 93
Extension of Time for Achieving Operational Acceptance (GCC Clause 40) ......... 93
Termination (GCC Clause 41) .................................................................................. 93
Assignment (GCC Clause 42) .................................................................................. 93
Section V. Special Conditions of Contract
81
Special Conditions of Contract
The following Special Conditions of Contract (SCC) shall supplement or amend the General
Conditions of Contract (GCC). Whenever there is a conflict, the provisions of the SCC shall prevail
over those in the General Conditions of Contract. For the purposes of clarity, any referenced GCC
clause numbers are indicated in the left column of the SCC.
A. CONTRACT AND INTERPRETATION
1.
Definitions (GCC Clause 1)
GCC 1.1 (a) (ix)
The applicable edition of the Procurement Guidelines is dated: May
2004, Revised Oct 2006 and May 2010.
GCC 1.1 (b) (i)
The Purchaser is: Ministry of Healthcare and Social Development of
the Republic of Kazakhstan.
GCC 1.1 (b) (ii)
The Project Manager is: Tsoy Aleksey Vladimirovich, Vice Minister
of Healthcare and Social Development of the Republic of
Kazakhstan
GCC 1.1 (e) (i)
The Purchaser’s Country is: Republic of Kazakhstan.
GCC 1.1 (e) (iii)
The Project Site(s) is/are: as specified in the List of Project Sites
in the Technical Requirements Section.
GCC 1.1 (e) (x)
The Contract shall continue in force until the Information System and all
the Services have been provided unless the Contract is terminated earlier
in accordance with the terms set out in the Contract.
GCC 1.1. (e) (xii) The Post-Warranty Services Period is 0, starting with the completion of
the Warranty Period.
2.
GCC 2
Contract Documents (GCC Clause 2)
There are no Special Conditions of Contract applicable to GCC Clause 2.
3.
GCC 3.1.1
Interpretation (GCC Clause 3)
The Contract's governing language is English.
If the contract is awarded to the firm of Purchaser’s country, basing on
bidders consent the Purchaser can conclude the contract in Russian. In
this case the Purchaser shall furnish English version of the contract to
82
Section VI. Technical Requirements
the Bank.
4.
GCC 4.3
Notices (GCC Clause 4)
Address of the Contract Manager: 010000, Astana, the Republic of
Kazakhstan, Orynbor Str 8, 5-6th entrances, office 1128 , tel. + 7 (7172)
742906, fax: + 7172 743608, e-mail. sh.zhumabaeva@mzsr.gov.kz
with copy to:
010000, Kazakhstan, Astana city, Imanov str 19, office 504,
tel. + 7172 787 235, fax. + 7172 787 247,
e-mail: kazhealth.procurement@gmail.com
5.
GCC 5.1
The Contract shall be interpreted in accordance with laws of the Republic
of Kazakhstan
6.
GCC 6.1.4
GCC 6.2.3
Governing Law (GCC Clause 5)
Settlement of Disputes (GCC Clause 6)
International non-profit association "European Arbitration
Chamber"
Belgium, Brussels, Avenue Louise 146
Tel.\Fax +38 044-581-30-77 / 55
secretary@chea-taic.be
The rules of procedure for arbitration proceedings are:
(a) if the Supplier is foreign (including a Joint Venture when at least one
partner is foreign): Any dispute, controversy or claim arising out of or
relating to this Contract, or breach, termination or invalidity thereof,
shall be settled by arbitration in accordance with the UNCITRAL
Arbitration Rules as at present in force. The place of arbitration shall not
be in the Purchaser’s or Supplier’s country;
(b) if the Supplier is a national of the Purchaser’s country: Any dispute
between the Purchaser and a Supplier who is a national of the
Purchaser’s country arising in connection with the present Contract shall
be referred to adjudication or arbitration in accordance with the laws of
the Purchaser’s country.
Section V. Special Conditions of Contract
83
B. SUBJECT MATTER OF CONTRACT
7.
GCC 7.3
Scope of the System (GCC Clause 7)
No recurrent costs.
At the same time, the Supplier shall before entering into the Contract to
provide a letter of guarantee that, if necessary, the Purchaser may hire
the Supplier for provision of services in the post-warranty period at the
rates specified in the bid.
8.
Time for Commencement and Operational Acceptance (GCC Clause 8)
GCC 8.1
The Supplier shall commence work on the System within: 15 days from
the Effective Date of the Contract.
GCC 8.2
Operational Acceptance will occur on or before:
Operational
Acceptance date consistent with the Implementation Schedule in the
Technical Requirements Section.
9.
GCC 9.9
Supplier’s Responsibilities (GCC Clause 9)
The Supplier shall have the following additional responsibilities:
- Purchase and provision of licenses database management systems used
in the proposed decision.
- Purchase and provision of licenses for all third-party information
systems and applications.
- Provide technical support and warranty for 3 years.
- If annual license is required for any part, the cost of these licenses for
the first 3 years should be scheduled in the cost of technical
support.
- Training of Purchaser’s staff on how to use and configure all
components, applications, services, solutions.
10.
GCC 10.12
Purchaser’s Responsibilities (GCC Clause 10)
The Purchaser shall have the following additional responsibilities: none.
84
Section VI. Technical Requirements
C. PAYMENT
11.
GCC 11.2 (b)
Adjustments to the Contract Price shall be as follows: none
12.
GCC 12.1
Contract Price (GCC Clause 11)
Terms of Payment (GCC Clause 12)
Subject to the provisions of GCC Clause 12 (Terms of Payment), the
Purchaser shall pay the Contract Price to the Supplier according to the
categories and in the manner specified below. Only the categories
Advance Payment and Complete System Integration relate to the entire
Contract Price. In other payment categories, the term "total Contract
Price" means the total cost of goods or services under the specific
payment category as defined in the “Price Schedule Forms”. Within
each such category, the Contract Implementation Schedule may trigger
pro-rata payments for the portion of the total Contract Price for the
category corresponding to the goods or services actually Delivered,
Installed, or Operationally Accepted, at unit prices and in the currencies
specified in the Price Schedules of the Contract Agreement.
(a)
Advance Payment
Ten percent (10%) of the entire Contract Price shall be paid
against receipt of a claim accompanied by the Advance Payment
Security specified in GCC Clause 13.2.
(b)
Information technology, materials and other goods, including
customized software products and customized materials:
forty percent (40%) of pro-rata Contract Price is paid for this
category upon delivery;
thirty percent (30%) of pro-rata Contract Price is paid for this
category upon installation;
(c)
Services:
seventy percent (70%) of pro-rata Contract Price for provided
services is paid against System installation. the list of services is
set in R12 of Section VI “Technical Requirements” for lots # 1-9
and R13 of Section VI “Technical Requirements” for lot # 10.
(d)
Complete System Integration
twentypercent (20%) of the entire Contract Price (without accounting
all recurrent costs) shall be paid as a final tranche against
Section V. Special Conditions of Contract
85
operational acceptance of the system as Entire Integrated System
GCC 12.3
The Purchaser shall pay to the Supplier interest on the delayed payments
at a rate of: 0.01 % of delayed amount per day for every day of delay
GCC 12.4
The Supplier will invoice the Purchaser in the currency used in the
Contract Agreement and the Price Schedules it refers to.
13.
Securities (GCC Clause 13)
GCC 13.2.1
The Supplier shall provide within twenty-eight (28) days of the
notification of Contract award an Advance Payment Security in the
amount and currency of the Advance Payment specified in SCC for GCC
Clause 12.1 above.
GCC 13.2.2
The reduction in value of the Advance Payment Security are calculated
as follows:
P*a/(100-a), where “P” is the sum of all payments effected so far
to the Supplier (excluding the Advance Payment), and “a” is the
Advance Payment expressed as a percentage of the Contract
Price pursuant to the SCC for GCC 12.1.
GCC 13.3.1
The Performance Security shall be denominated in Contract’s
currency for an amount equal to 10 (ten) percent of the Contract Price.
GCC 13.3.4
During the Warranty Period (i.e., after Operational Acceptance of the
System), the Performance Security shall be reduced to 5 (five) percent of
the Contract Price.
14.
GCC 14
Taxes and Duties (GCC Clause 14)
There are no Special Conditions of Contract applicable to GCC Clause
14.
D. INTELLECTUAL PROPERTY
15.
GCC 15.3
Copyright (GCC Clause 15)
The Purchaser may assign, license, or otherwise voluntarily transfer its
contractual rights to use the Standard Software or elements of the
86
Section VI. Technical Requirements
Standard Software, without the Supplier’s prior written consent, under
the following circumstances:
to the Purchaser’s structural units (oblast and rayon health facilities) and
all successors in case of any reorganizations of the Purchaser in
accordance with legislative acts of the Purchaser’s Country.
GCC 15.4
The Purchaser’s and Supplier’s rights and obligations with respect to
Custom materials or their components are as follows:
none
GCC 15.5
No software escrow contract is required for the execution of the
Contract
16.
GCC 16.1 (a)
(iii)
Software License Agreements (GCC Clause 16)
The Standard Software license shall be valid: throughout the territory of
the Purchaser’s Country
GCC 16.1 (a) (iv) Use of the software shall be subject to the following additional
restrictions:
none
GCC 16.1 (b)
(vi)
The Software license shall permit the Software to be disclosed to and
reproduced for use (including a valid sublicense) by support service
suppliers or their subcontractors, exclusively for such suppliers or
subcontractors in the performance of their support service contracts as
well as the playback of software products for use by specified persons (as
well as on the basis of the current sublicense), subject to the same
restrictions set forth in this Contract.
GCC 16.1 (b)
(vii)
In addition to the persons specified in GCC Clause 16.1 (b) (vi), the
Software data may be disclosed to, and reproduced for use by for those
involved in the development of UHIMS, subject to the same restrictions
as are set forth in this Contract.
GCC 16.2
The Supplier’s right to audit the Standard Software will be subject to the
following terms:
if on-site audits are acceptable, the Purchaser may specify conditions on
the duration and number of audits per year; the hours or days during
which audits may be conducted; the categories of software subject to
audit; the procedures for access to Purchaser’s hardware or software; the
number and affiliation of individual auditors; the timing and terms of
advance notice; the indemnity by Supplier for losses, liabilities, and
costs incurred by the Purchaser as a direct result of the audit; etc.
Section V. Special Conditions of Contract
17.
87
Confidential Information (GCC Clause 17)
GCC 17.1
There are no modifications to the confidentiality terms expressed in
GCC Clause 17.1
GCC 17.7
The provisions of this GCC Clause 17 shall survive the termination, for
whatever reason, of the Contract for the period specified in the GCC.
E. SUPPLY, INSTALLATION, TESTING, COMMISSIONING, AND
ACCEPTANCE OF THE SYSTEM
18.
Representatives (GCC Clause 18)
GCC 18.1
The Purchaser’s Contract Manager shall have the following additional
powers and / or limitations to his or her authority to represent the
Purchaser in matters relating to the Contract: no additional powers or
limitations.
GCC 18.2.2
The Supplier’s Representative shall have the following additional
powers and / or limitations to his or her authority to represent the
Supplier in matters relating to the Contract: no additional powers or
limitations.
19.
GCC 19.1
Project Plan (GCC Clause 19)
Chapters in the Project Plan shall address the following subjects:
(а) Plan of the Project management organization containing
described roles and responsibilities of personnel of the Supplier,
the names and the number of working hours (person-months), and
what actions of management unit and staff of a health facility are
necessary for successful implementation of the Project;
(b) System (s) implementation Plan in a health facility that would
prove that all Purchaser’s requirements for delivered
Systems are met, and this is confirmed by facility beneficiary, and that the systems are certified in accordance
with the Purchaser’s requirements
(c) Methodology and Plan for development / configuration,
testing, installation, trial operation and certification of
Systems supplied
(d) Methodology and User training Plan specifying the methods
and programs of study, the number of hours, training venue
and transfer of technology for both users and managers of
88
Section VI. Technical Requirements
the enterprise.
(e) Data migration Plan (if such data is available)
(f) Response plans for warranty service, and provision of
professional services for piloting: what is the response time
to eliminate errors and queries, to indicate where the staff of
the supplier will be, how many people will be involved, and
on what schedule.
(g) Methodology and support plan for all included software and
component both during implementation and during the trial operation
GCC 19.2
Within thirty (30) days from the Effective Date of the Contract, the
Supplier shall present a Project Plan to the Purchaser. The Purchaser
shall, within fourteen (14) days of receipt of the Project Plan, notify the
Supplier of any respects in which it considers that the Project Plan does
not adequately ensure that the proposed program of work, proposed
methods, and/or proposed Information Technologies will satisfy the
Technical Requirements and/or the SCC (in this Clause 19.2 called
“non-conformities” below). The Supplier shall, within: seven (7) days
of receipt of such notification, correct the Project Plan and resubmit to
the Purchaser.
The Purchaser shall, within seven (7) days of
resubmission of the Project Plan, notify the Supplier of any remaining
non-conformities. This procedure shall be repeated as necessary until
the Project Plan is free from non-conformities. When the Project Plan is
free from non-conformities, the Purchaser shall provide confirmation in
writing to the Supplier. This approved Project Plan (“the Agreed and
Finalized Project Plan”) shall be contractually binding on the Purchaser
and the Supplier.
GCC 19.5
The Supplier shall submit to the Purchaser the following
progress reports, summarizing:
(a)
quarterly
quarterly progress reports, summarizing:
(i)
results accomplished during the prior period;
(ii)
cumulative deviations to date from schedule of
progress milestones as specified in the Agreed and
Finalized Project Plan;
(iii) corrective actions to be taken to return to planned
schedule of progress; proposed revisions to planned
schedule;
(iv) other issues and outstanding problems; proposed
actions to be taken;
(v)
resources that the Supplier expects to be provided by
the Purchaser and/or actions to be taken by the
Section V. Special Conditions of Contract
89
Purchaser in the next reporting period;
(vi) other issues or potential problems the Supplier
foresees that could impact on project progress and/or
effectiveness.
(b)
reports on training activities and outcomes (assessment)
(c) Implementation Completion Report
(d) monthly magazines with registration of requests on outcomes
of challenge solution
(e) report on outcomes of testing and certification
20.
GCC 20
Subcontracting (GCC Clause 20)
“There are no Special Conditions of Contract applicable to GCC Clause
20.”
21.
Design and Engineering (GCC Clause 21)
GCC 21.2
The Contract shall be executed in accordance with the edition or the
revised version of all referenced codes and standards current at the date
60 (sixty) days before bid submission.
GCC 21.3.1
The Supplier shall prepare and furnish to the Project Manager the
following documents for which the Supplier must obtain the Project
Manager’s approval before proceeding with work on the System or any
Subsystem covered by the documents: none
22.
Procurement, Delivery, and Transport (GCC Clause 22)
GCC 22.4.3
The Supplier shall be free to use transportation through carriers
registered in any eligible country and shall obtain insurance from any
eligible source country.
GCC 22.5
The Supplier shall provide the Purchaser with documents as specified in
the GCC as well as the following documents: Equipment Quantity
Evaluation Certificate signed by Contract parties.
90
Section VI. Technical Requirements
24.
Implementation, Installation, and Other Services (GCC Clause 24)
GCC 24
There are no Special Conditions of Contract applicable to GCC Clause
24.
25.
GCC 25
Inspections and Tests (GCC Clause 25)
There are no Special Conditions of Contract applicable to GCC Clause
25.
26.
GCC 26
Installation of the System (GCC Clause 26)
Necessary and reasonable provisions:
none
27.
GCC 27.2.1
Commissioning and Operational Acceptance (GCC Clause 27)
Operational Acceptance Testing shall be conducted in accordance with
the following:
pre-operational testing of System and its sub-systems on sites shall be
done in line with the section of Technical Requirements:
R14 – for lots №1-9 and R15 – for lot №10.
GCC 27.2.2
If the Operational Acceptance Test of the System, or Subsystem(s),
cannot be successfully completed within ninety (90) days from the date of
Installation or any other period agreed upon by the Purchaser and the
Supplier, then GCC Clause 27.3.5 (a) or (b) shall apply, as the
circumstances may dictate.
F. GUARANTEES AND LIABILITIES
28.
GCC 28.2
Operational Acceptance Time Guarantee (GCC Clause 28)
Liquidated damages shall be assessed at 1 percent per week. The
maximum liquidated damages are 10 percent of the Contract Price, or
relevant part of the Contract Price as defined in the price schedule if the
liquidated damages apply to an activity/component. Terms of Delivery
and Installation of equipment are specified in Section VI «Technical
Requirements», in Implementation Schedule table.
Section V. Special Conditions of Contract
GCC 28.3
91
Liquidated damages shall be assessed with respect to the stage of
Operational acceptance basing on provisions set in Section VI, Chapter
D.
29.
Defect Liability (GCC Clause 29)
GCC 29.1
For Software, exceptions or limitations to the Supplier’s warranty
obligations shall be as follows: None.
GCC 29.3 (iii)
The Supplier warrants that the following items have been released to the
market for the following specific minimum time periods: “No specific
minimum time requirements are established for this Contract other than that
the Information Technologies must have been previously released to the
market”
GCC 29.4
The Warranty Period (N) shall begin from the date of Operational
Acceptance of the System or Subsystem and extend for 3 years in
accordance with R12.4. and R13.4 respectively
GCC 29.10
During the Warranty Period, the Supplier must commence the work
necessary to remedy defects or damage within 15 (working) days of
notification.
30.
GCC 30
There are no Special Conditions of Contract applicable to GCC Clause
30.
31.
GCC 31
Intellectual Property Rights Warranty (GCC Clause 31)
There are no Special Conditions of Contract applicable to GCC Clause
31.
32.
GCC 32
Intellectual Property Rights Indemnity (GCC Clause 32)
There are no Special Conditions of Contract applicable to GCC Clause
32.
33.
GCC 33
Functional Guarantees (GCC Clause 30)
Limitation of Liability (GCC Clause 33)
There are no Special Conditions of Contract applicable to GCC Clause
33.
92
Section VI. Technical Requirements
G. RISK DISTRIBUTION
34.
GCC 34
Transfer of Ownership (GCC Clause 34)
There are no Special Conditions of Contract applicable to GCC Clause
34.
35.
GCC 35
36.
Care of the System (GCC Clause 35)
There are no Special Conditions of Contract applicable to GCC Clause
35.
Loss of or Damage to Property; Accident or Injury to Workers; Indemnification (GCC
Clause 36)
GCC 36
There are no Special Conditions of Contract applicable to GCC Clause
36.
37.
GCC 37.1 (c)
GCC 37.1 (e)
The Supplier shall obtain Third-Party Liability Insurance in the amount
of 150 000 USD with deductible limits of no more than 10 000 USD.
The insured Parties shall be staff of the Ministry of Health and Social
Development of the Republic of Kazakhstan, local MHSD objects,
Health Informatization Center, sub-contractors of enlisted above
agencies and all Parties of Consultants and Suppliers. The Insurance
shall cover the period from the beginning date, in terms of the date of
Contract Effectiveness until expiration date.
There are no Special Conditions of Contract applicable to GCC Clause
37.1 (e).
38.
GCC 38
Insurances (GCC Clause 37)
Force Majeure (GCC Clause 38)
There are no Special Conditions of Contract applicable to GCC Clause
38.
Section V. Special Conditions of Contract
93
H. CHANGE IN CONTRACT ELEMENTS
39.
GCC 39
40.
GCC 40
Changes to the System (GCC Clause 39)
There are no Special Conditions of Contract applicable to GCC Clause
39.
Extension of Time for Achieving Operational Acceptance (GCC Clause 40)
There are no Special Conditions of Contract applicable to GCC Clause
40.
41.
GCC 41
There are no Special Conditions of Contract applicable to GCC Clause
41.
42.
GCC 42
Termination (GCC Clause 41)
Assignment (GCC Clause 42)
There are no Special Conditions of Contract applicable to GCC Clause
42.
Annex to Section V. Special Conditions of Contract
Clause GCC 41.2.1: The provisions in clause GCC 41.2.1 (c) of Section IV. General Conditions of
Contract are replaced with the following:
94
Fraud
Corruption
Section VI. Technical Requirements
and
41.2.1 (c)
If the Purchaser determines that the Supplier and/or
any of its personnel, or its agents, or its Subcontractors, consultants,
service providers, suppliers and/or their employees has engaged in
corrupt, fraudulent, collusive, coercive or obstructive practices, in
competing for or in executing the Contract, then the Purchaser may,
after giving 14 days notice to the Supplier, terminate the Supplier's
employment under the Contract and cancel the contract, and the
provisions of GCC Clause 41.1 shall apply as if such expulsion had
been made under GCC Sub-Clause 41.1.2.
(a)
For the purposes of this Sub-Clause:
(i)
“corrupt practice” is the offering, giving, receiving or
soliciting, directly or indirectly, of anything of value to
influence improperly the actions of another party1;
(ii)
“fraudulent practice” is any act or omission, including
a misrepresentation, that knowingly or recklessly
misleads, or attempts to mislead, a party to obtain a
financial or other benefit or to avoid an obligation2;
(iii)
“collusive practice” is an arrangement between two or
more parties3 designed to achieve an improper purpose,
including to influence improperly the actions of
another party;
(iv)
“coercive practice” is impairing or harming, or
threatening to impair or harm, directly or indirectly,
any party or the property of the party to influence
improperly the actions of a party4;
(v)
“obstructive practice” is
(aa)
deliberately destroying, falsifying, altering or
concealing of evidence material to the
investigation or making false statements to
1
“Another party” refers to a public official acting in relation to the procurement process or contract execution.
In this context, “public official” includes World Bank staff and employees of other organizations taking or
reviewing procurement decisions.
2
“Party” refers to a public official; the terms “benefit” and “obligation” relate to the procurement process or
contract execution; and the “act or omission” is intended to influence the procurement process or contract
execution.
3
“Parties” refers to participants in the procurement process (including public officials) attempting to establish
bid prices at artificial, non competitive levels.
“Party” refers to a participant in the procurement process or contract execution.
4
Section V. Special Conditions of Contract
95
investigators in order to materially impede a
Bank investigation into allegations of a corrupt,
fraudulent, coercive or collusive practice; and/or
threatening, harassing or intimidating any party
to prevent it from disclosing its knowledge of
matters relevant to the investigation or from
pursuing the investigation; or
(bb)
acts intended to materially impede the exercise
of the Bank’s inspection and audit rights
provided for under GCC Clause 9.8.
Should any employee of the Supplier be determined to have engaged
in corrupt, fraudulent, collusive, coercive, or obstructive practice
during the purchase of the Goods, then that employee shall be
removed.
Clause GCC 9.8: The provisions in clause GCC 9.8 of Section IV.
General Conditions of Contract are replaced with the following:
9.8
The Supplier shall permit, and shall cause its Subcontractors and
Inspections and 9.8
Audit by the consultants to permit, the Bank and/or persons appointed by the Bank to
inspect the Supplier’s offices and all accounts and records relating to the
Bank
performance of the Contract and the submission of the bid, and to have such
accounts and records audited by auditors appointed by the Bank if requested
by the Bank. The Supplier’s and its Subcontractors and consultants’
attention is drawn to GCC Clause 41.2.1 (c), which provides, inter alia, that
acts intended to materially impede the exercise of the Bank’s inspection and
audit rights provided for under this GCC Sub-Clause 9.8 constitute a
prohibited practice subject to contract termination (as well as to a
determination of ineligibility pursuant to the Bank’s prevailing sanctions
procedures).
96
Section VI. Technical Requirements
SECTION VI. TECHNICAL REQUIREMENTS (INCLUDING
IMPLEMENTATION SCHEDULE) - FOR LOTS NO. 1-9
A. Background
0.1
The Purchaser
0.1.1 The Implementing Agency of this contract is the Ministry of Healthcare and Social
Development of the Republic of Kazakhstan. The Ministry of Healthcare and Social
Development of the Republic of Kazakhstan (MHSD) is a state agency of the Republic of
Kazakhstan implementing regulation in healthcare, medical and pharmaceutical science and
education, sanitary and epidemiological welfare of population, turnover of medicines, care
quality control. MHSD acts according to the Constitution of the Republic of Kazakhstan and its
Laws, Acts of the President and the Government of Kazakhstan (GOK), other regulatory acts
as well as Regulation on the MHSD of the Republic of Kazakhstan ratified by the Decree of the
GOK dated September 23, 2014, No. 1005.
0.1.2
Stakeholders of the project implemented as the result of this contract are as follows:
- MHSD defines e-health strategy and provides the Supplier with required regulations and
official documents for successful Contract implementation and is to adjust legal background if
required.
- Health facilities in Kazakhstan as beneficiaries of the Contract shall apply Contract outcomes
in practice. Detailed information on a certain health facility shall be presented to the Bidders
upon request.
0.2
Objectives of the Purchaser
0.2.1 MHSD general objective in e-health area is as follows:
E-health implementation shall provide an option of getting automated up-to-date, accurate and
complete information to ensure safe, fair, high quality, reliable patient need oriented health
system. It will be achieved through provision of health facilities and MHSD departments with
secure and high-speed access to completely interoperable systems of e-healthcare, based on
paperless technologies using the unified system of the Electronic Health Records (EHR).
National e-healthcare repository will be created on a central level and contain:
1)
EHR as a central component promoting integration of IS in health facilities.
2)
Data repository with accumulated high-quality statistic data, analytical and financial
data.
Section VI. Technical requirements
97
“Comprehensive Health Information Systems for out-patient clinics, hospitals and mixed health
facilities” (the Systems) purchased under the Contract shall greatly contribute to this vision.
The Systems shall automate clinical and non-clinical processes undergoing in various health
facilities, namely in policlinics, hospitals and mixed health facilities.
0.2.2 Objectives of Kazakhstan e-health.
Based on priority needs of Kazakhstan health system, defined in the State Health Development
Program "Salamatty Kazakhstan 2011–2015" and priorities defined in health section of
"Kazakhstan Strategy 2050", for e-health the following objectives are defined:
1. Support of clinical (medical) decision-making.
2. Reduction of medical mistakes.
3. Increasing availability and improving continuity of health services;
4. Improvement of health services quality;
5. Improving quality and efficiency of taken financial, managerial, politic decisions;
6. Ensuring environment for continuous professional growth in health area;
7. Improving public access to information about health and management of their privacy;
8. Increase of profitability and efficiency of investments and operational expenditures related to
healthcare.
0.2.3 The System purchased within this Contract shall allow:
-
Increasing readiness and accuracy of reports submitted to health departments;
Reduce ineffective work time devoted to documentation (making discharge lists, filling in
registers, reports forming);
Increase quality of taken managerial decisions based on evidence as well as their
monitoring;
Increase quality of care due to informational support to medical actions and as a result
reducing the number of professional errors;
Improving links between care phases through e-referrals, prescriptions, notifications for
continuous and qualitative care achieving;
Savings in clinic-diagnostic studies due to reduced number of repeated ad irrational
actions;
Saving costs for lab and radiological studies through effective use of expensive
equipment;
Saving costs for drugs and medical devices through rational use of drugs, strict control
over their dissemination and planning of procurement procedures;
Improving performance of health facilities (increasing throughput capacity, care waiting
time decrease as well as cure time, complications and death cases);
-
Reducing forfeit amounts imposed in case of defects revealed during care provision;
-
Control over targeted use of health resources;
98
Section VI. Technical Requirements
Increasing efficiency in getting outcomes of studies from labs and other diagnostic
departments;
-
Removing double entry of similar information;
Better control over the use of drugs and reducing side effect and drug incompatibility
cases.
Patient safety assurance through transparency of diagnostic processes and prescribed
treatment; as well as confidentiality of patient data.
0.2.4. Potential Beneficiaries from the System.
Potential direct beneficiaries are:
Health professionals – doctors and nurses using the System for patient data keeping
during clinical decisions (context aid as clinical guidelines and diagnostic and treatment
protocols and etc.);
-
Health managers using data collected out of various sources and objects;
MHSD experts using data for political decision making and regulatory framework
amending basing on evidence as well as adequate health service funding;
All IS in e-health environment using EHR, data, classifiers, services within SOA
architecture;
-
Third-party IS using data stored in e-health applications;
Potential indirect beneficiaries are:
-
All Kazakhstan citizens served by health specialists using the System;
-
Researchers that use data on care and prophylactic process received through the System.
Potential number of work places by Modules is set in Annex 2.
0.2.5. Information systems of the MHSD
The following systems belong to IS of the MHSD:
1.
IS «Hospitalization Bureau»
2.
IS «Additional component to PHC tariff»
3.
IS «Drug provision»
4.
IS «Register of pregnant and fertile age women»
5.
IS «Health service quality management system»
6.
IS «Medical equipment management system»
7.
IS «Resource management system»
8.
IS «E-register of dispensary patients»
9.
IS «E-register of cancer patients»
Section VI. Technical requirements
99
10.
IS «E-register of hospital patients»
11.
IS «Out-patient care»
12.
IS «Register of attached population»
13.
IS «Register of patients with renal failure»
14.
IS «Register of patients with mental diseases»
15.
IS «Register of narcological patients»
16.
Drug provision management system
17.
AIS «Policlinics»
18.
IS «National Register of TB patients»
19.
IS «National Register «Diabetes»»
20.
Health Informatization and Interoperability Platform
Interaction with IS of MHSD (above indicated IS in para.1-19) shall be done using service of
Health Informatization and Interoperability Platform.
0.3
Acronyms used in the Technical Specifications
Term
Meaning
HB
Hospitalization Bureau
DB
Data Base
HIV
Human immunodeficiency virus
MCB
Medical Consultative Board
Tertiary care
Tertiary care
ACPCT
Additional component of per capita tariff
RCSA
Healthy life style
Register of civil status acts
Healthy life style
IIN
ICT
Individual Identification Number
Information and Communication Technology
Medical devices
Medical devices
IS MHSD RK
IS
Information Systems of the Ministry of Healthcare and Social
Development of the Republic of Kazakhstan
Information System
Interoperability
Feature or option of different systems to work together
100
Section VI. Technical Requirements
Term
Meaning
CDS
Consulting Diagnostic services
LIS
Lab Information System
CPF
Curative prevention facility
Drugs
Drugs
MHSD
Ministry of Healthcare and Social Development
HIS
Health Information Systems
ICD
INN
International Classification of Disease
International non-proprietary name of drugs
MSE
Medical and Social Expertise
Side effect of drugs
Side effect of drugs
Platform
PHC
Health Informatization and Interoperability Platform
Primary Health care
RK
Republic of Kazakhstan
ADSP
Average duration of stay of patient
P4P
Capitation Pay for performance
Care subject
Care subject
CQMS
Care quality management system
Full name
EMR
Full name
Electronic Medical Record
EHR
Electronic Health Record
ERDP
E-Register of Dispensary patients
ERHP
DS
E-Register of Hospital patients
Digital signature
ADO.NET
Technology ensuring access to data for applications based on Microsoft
.NET. It is not a development of earlier technology ADO.
ASP
Active Server Page – a technology proposed by Microsoft 1996
BAM
Business activity monitoring
BP
Business Process
BPM
Business Process Management
bps
Bits per second
Section VI. Technical requirements
Term
101
Meaning
BRMS
Business Rule Management System is an IS used for entry, maintenance
and execution of business rules of the firm
CDA
Clinical Document Architecture
CPU
Central Processing Unit
CRUD
Create Read, Update, Delete operations
CSS
Cascading Style Sheets — a formal language of description of external
view of the document written using markup language
DICOM
Digital Imaging and Communication in Medicine is a Sectoral standard
for creation, storage, transmission and visualization of medical images
and documents of examined patients
DOM
Document Object Model — is an interface independent from Platform
and the language which allows the software and scripts to get access to
the content of HTML, XHTML and XML-documents as well as to
change the content, structure and arranging of such documents
ESB
Enterprise Service Bus
FHIR
Standard of electronic exchange of health information. Standard FHIR –
is a new specification from HL7 based on advanced approaches in ehealth area which nevertheless accounts total accumulated experience
(real needs, successful solutions and typical challenges) of defining and
implementing standards HL7 v2, HL7 v3, CDA. (Fast Healthcare
Interoperability Resources)
GB
Gigabyte
GUI
Graphical User Interface
HC
Healthcare
Help Desk
Maintenance which summarizes and covers a lot of services used by
enterprises to help the users of technology products and services
HL7
Standard of e-health data exchange, management and integration (Health
Level 7)
HTML
Hypertext Markup Language
IaaS
Infrastructure as a Service
ICPC
International Classification in Primary Care
IDE
Integrated Development Environment
IHE
Integrating Healthcare Enterprise
IP
Internet Protocol
102
Section VI. Technical Requirements
Term
Meaning
ISO
International Standards Organization
ITI
IT Infrastructure
JDBC
Platform independent industrial standard of interaction of Javaapplications with various DBMS (Java Database Connectivity)
KB
Kilobyte
LAN
Local area network
LDAP
Lightweight Directory Access Protocol to the service of catalogues
X.500 developed by IETF as a simplified version of designed ITU-T
protocol DAP
LOINC
Universal standard for identification of medical and lab outcomes
(Logical Observation Identifiers Names and Codes)
MB
Megabyte
MDX
the language for simple, effective access to multidimensional structures
of data like the language SQL for relational data bases (MultiDimensional eXpressions Language)
ODBC
Program interface for access to data bases developed by Microsoft in
cooperation with Simba Technologies basing on specifications Call Level
Interface, which were developed by SQL Access Group, X/Open and
Microsoft. (Open Database Connectivity)
OLAP
Data processing technology aimed at preparing summary data based on
great massive of data structured according to multi-dimensional principal
(Online Analytical Processing)
OLTP
Transactional system – processing of transactions in real time. A method
of organizing a database in which the system works with small size
transactions, but reaching a large flow, and thus the client requires a
minimum of system response time (Online Transactional Processing)
OWASP
Open Web Application Security Project
PaaS
Platform as a Service
PDQ
Patient Demographic Query
PIX
Patient Identifier Cross-Reference (IHE profile)
PKI
Public Key Infrastructure
PMI
Patient Master Index
RAM
One of types of computer memory that allows simultaneous access to any
cell by its address to read or write (Random Access memory)
REST
Representational State Transfer
Section VI. Technical requirements
Term
103
Meaning
SaaS
Software as a Service
SAML
Security Assertion Markup Language
SDK
Software development kit that enables software professionals to create
applications for a certain software package, software, basic software
development, hardware platform, computer system, video game consoles,
operating systems and other platforms (Software Development Kit).
SNOMED-CT
Systematized Nomenclature Of Medicine Clinical Terms
SOA
Service-oriented architecture
SOAP
Protocol of exchange of structured messages in distributed computing
environment (Simple Object Access Protocol)
SQL
Universal computer language used to create, modify and manage data in
relational databases (Structured Query Language)
SSL
Cryptographic protocol that provides secure communication. It uses
asymmetric cryptography to authenticate the key exchange, symmetric
encryption for confidentiality (Secure Sockets Layer)
SSO
Single Sign On – is a technology, using which a user moves from one
section of the portal to another without re-authentication
TCP
One of basic communication protocols, Internet data, for controlling the
transfer of data in networks and subnetworks TCP / IP. It serves as the
transport layer protocol in stack of TCP / IP protocols (Transmission
Control Protocol)
TCP/IP
Set of protocols to control data exchange between computers with access
to Internet (Transmission Control Protocol / Internet Protocol)
TLS
The level of Secure Sockets Layer - cryptographic protocols that provide
a protected communications between nodes on the Internet (Transport
Layer Security)
UML
Graphic description language for object modeling in the field of software
development (Unified Modeling Layer)
Unicode
The standard of character encoding, which allows to introduce signs of
almost all written languages (Unicode)
URL
standardized method of recording the address of the resource on the
Internet (Uniform resource locator)
VPN
Generalized name of technologies to provide one or more network
connections over a different network. (англ. Virtual Private Network)
104
Section VI. Technical Requirements
Term
Meaning
WADL
XML description for web applications operating according to HTTP
protocol (as a rule, REST web services). It is positioned as the equivalent
of WSDL for REST. WADL models recourses supplied by the server and
their interaction (Web Application Description Language)
WCAG
Web Content Accessibility Guidelines
WLAN
Wireless LAN
WS
Web Service
WSDL
Web Services Description Language and their access based on XML
XCA
Cross-Community Access (profile IHE)
XD-LAB
Cross Enterprise Document Sharing of Lab Reports (profile IHE)
XDS
Cross-Enterprise Document Sharing (profile IHE)
XDS-MS
Cross Enterprise Document Sharing of Medical Summaries (profile IHE)
XML
Markup language recommended by Consortium of Internet (Extensible
Markup Language)
XPHR
Exchange of Personal Health Records
XSL
Recommendations of consortium W3C describing the languages of
transformation and visualization of XML-documents (Extensible Style
sheet Language)
B. BUSINESS FUNCTION AND PERFORMANCE REQUIREMENTS
The aim of the Section is to define business requirements and functional requirements for the
purchase of the System.
1.1
Business requirements to the System
1.1.1
Current situation in MHSD ICT area
1.1.1.1. MHSD policy in e-health area
Government of Kazakhstan approved a new strategy "Concept for E-health
Development for 2013-2020 years" which specifies key areas of focus for Kazakhstan e-health
transformation. In compliance with this strategy, it is expected that transformation will be
based on a new architecture, which has the following basic features:
E-health will be based on collaboration framework consisting of such components as:
common terminology and data glossaries; common classifiers and references aimed at
creation of common information/semantic interoperability in e-health environment,
etc.;
Section VI. Technical requirements
-
-
-
105
Generation of common indexes, used in entire e-healthcare environment: Main patient
index, Index of healthcare professionals, Index of medical facilities, indexes of the other
resources;
Creation of unified detachable Electronic Health Records (EHR) system, which would
be centralized and contain health records (electronic records) of all patients with an
option of replication to local servers, if necessary, and assure collection, storage and use
of lifelong information by this bringing to continuous medical service provision;
Set-up computing infrastructure consisting of two Data Centers able to interchange
each other automatically to provide high resilience;
Install a background for possible use of cloud computing technology in future to
automate computing services: Infrastructure as a Service (Infrastructure as a Service –
IaaS), Platform as a Service (Platform as a Service – PaaS), Software as a Service
(Software as a Service – SaaS);
Operating based on service-oriented architecture (SOA) and provision of re-usage of
existing system functionality, including links to e-government services;
Integration of existing systems and web-applications (portals) on a new Health
Informatization and Interoperability Platform and etc.
New approaches to e-health systems generation shall address the following issues:
-
Information systems for e-health will not be developed only by funds from central
budget, health facilities are to participate as they are to purchase IS and applications at
national market;
For interoperability ensuring, a set of interoperability requirements is to be developed
(Book of IT rules for e-health) and all information systems shall be certified to comply
to these rules;
To develop local market, government shall provide special grants for development of
IT sector of health facilities and define co-financing rules;
The government will assess and monitor potential risks and make decisions on risk
prevention (such as unsatisfactory traffic-carrying capacity, ICT aligning to health
needs, support and provision of interoperability, etc.);
MHSD shall accelerate the process of rules, standards and regulations design and
approval to improve interaction between e-health participants;
General architecture of National EHR system is demonstrated in Pic. 1 below. The System
purchased under this Bidding is coded as CHIS (in pink color) in a yellow square in right lower
part of Pic. 1.
106
Section VI. Technical Requirements
Patient’s Personal
Cabinet
Personal health professional’s
cabinet
e-Government
services
BI and Analytical tools Classifiers and Nomenclatures
Management
Existing Information systems
RAP
OPC
MSQMS
RMS
DPMS
RPWFA
ERHP
ACPCT
MEMS
ERDP
HB
DIS
Single data repository
EHR Repository
Analytical warehouse
Master patient index,
healthcare facilities
index, healthcare
professionals index
Classifiers and
nomenclatures
e-Government Gate
Integration bus
ERCP
NRD
Integration bus
External Information systems
Health facility level modules (within this contract)
District doctor
Admission
Meals
Pharmacy
Human Resources
Hospital Doctor
Reception
Day-hospital
Hospital
administrator
Profile specialist
Procedures and
manipulations
Hospital nurse
Diagnostic studies
Admin
Prophylactic exams
Lab IS
PACS (Picture
Archiving and
Communication
System)
Medical statistics of
policlinic
Head of Policlinic
department
Head of hospital
department
Medical Statistics
for Hospital
Legend
Existing information systems
Platform components
e-Government Gate and services
Health facility level modules
Pic. 1.Architecture of purchased CHIS interlinks with national recourses of e-health.
More details can be found in the document "Concept for E-health Development for 2013–2020
years", accessible on MHSD web-site.
Section VI. Technical requirements
107
1.1.2 Principles for System design
The following principles shall be applied in design, configuration and use of the System:
Principle of Legality that presupposes design, use and maintenance of IS in line with national
legal background and international standards;
-
Data Security Principle – System data entry only through checked authorized channels;
Information Security Principle – assuring appropriate level of integrity, selectivity,
accessibility and efficiency for data protection from loss, modification, destruction and unauthorized
access;
Data Confidentiality Principle – guaranty access to data only in line with national policy and
international standards to confidentiality of personal data, access by patient consent, possibility to
code saved data;
Transparency - the System is a modular structure that shall use transparent / open standards in
ICT area;
Enlargement Principle – that means extension and improving the System by new options and
improving current functionality;
First Person Priority Principle/Unique Center – existence of high level official who has rights
enough to make decisions and coordinate activities for System design, integration and application;
Scalability Principle – permanent efficiency of applications and interlinks with growing data
and patient scope;
User Simplicity and Convenience – System functions and tools for targeted roles shall be
based on visual instruments, ergonomic and intuitively clear.
1.1.3. Business requirements to the System
Note 1. The following keywords (i.e., normative verbs) SHALL be used to convey conformance
requirements.
• SHALL – to indicate a mandatory requirement to be followed (implemented) in order to conform.
Synonymous with ‘is REQUIRED to’. Another used synonym is MUST .
• SHALL NOT –to indicate a prohibited action. Synonymous with ‘prohibited’.
• SHOULD - to indicate an optional recommended action, one that is particularly suitable, without
mentioning or excluding others. Synonymous with ‘is permitted and recommended’.
• MAY- to indicate an optional, permissible action. Synonymous with ‘is permitted’.
Note 2. In tables with business and functional requirements the following categories (types ) are used:
M – means minimal mandatory requirement; delivered solution shall obligatory correspond to such
requirement; full or partial lack of compliance to such requirement shall lead to rejection of Bid.
108
Section VI. Technical Requirements
D – means desirable requirement; lack of compliance to such requirement shall not lead to Bid
rejection, however, its correspondence allows to heighten Bid competitiveness.
I – information to clear up other requirements.
Reference to requirements in the text shall clearly differ from references to sections and parts:
Reference to requirements shall clearly indicate the word «Requirement», «req.» or R, as R1.1 –
reference to Requirement 1.1;
References to sections shall be with prefix «Chapter», «Section» or р, as «p.1.1.1» indicates reference
to Section 1.1.1 and is not a Requirement.
Table below has list of business requirements to be followed by the System and related
systems/services.
1.1.3.1. General business requirements
R1
General business requirements
R1.1
M
Licensing mechanism for the System under this contract shall provide the right to
use all modules and compounds in the concrete Health Facility for number of
users sufficient for full scale functioning of a health facility (size of health
facility could be evaluated basing on description in the Annex 2), for unlimited
time, unlimited number of servers, and excluding any other possible limitations.
It is not accepted annual license fees; the only cost for license is the initial license
cost, which includes all costs.
R1.2
M
Within this Contract System interoperability shall be assured with national ehealth system according to requirement R 7. General scheme of interaction with
national e-health system is set in the Pic. 1
R1.3
M
The System shall correspond to general architecture of Comprehensive Health
Information System set in Pic. 2
R1.4
M
System modules and/or its compounds shall have option of data exchange using
http(s) - protocol
R1.5
M
the System shall have SOA-oriented architecture that supports only defined and
platform independent interfaces for interaction
R1.6
M
At least following functional assigned for use by wide range of users (patients,
distanced doctors, managers) shall be implemented as web-application:
- patient’s demographic data
- patient complaints
- entry of allergic anamnesis
Section VI. Technical requirements
109
- entry of life anamnesis
- entry of suffered diseases
- entry of anamnesis of current illness
- entry of objective state of patient examination
- entry data on reactions to drugs
- entry referrals to lab studies
- entry prescriptions
- entry referrals to diagnostic services
- review lab studies results
- review diagnostic results
- reporting
- doctor’s records keeping
R1.7
M
The System shall have fine configuration to assure adjusting to health facility
needs without design of a new system (or small refinement of the System)
R1.8
M
The Supplier under this Contract shall carry out works to ensure interoperability
of the System with National EHR (EHR repository, national classifiers and
indicators, analytic repository, EHR-web-services) according to requirement R7
R1.9
M
System integration shall be ensured with introduced accounting system 1C. Level
of integration shall be determined during implementation of the Contract and
agreed with the agency where System is introduced.
R1.10
M
The System shall ensure confidentiality of personal data: encryption of personal
data in DB, encryption data while transmission by channels, use of safe
transmission protocols and etc.
R1.11
M
The System shall use digital signature to sign and authorize e-documents, files
and parts of the documents. Need in digital signature shall be configurable at
System admin level. More details on requirements to digital signature are set in R
5.15.
R1.12
M
The system shall be entirely operational “on turnkey basis” according to R 14.2.
For this the Supplier shall if it is necessary add missing parts, functionality and
solutions including cost of missing parts in Price Table in item for «others»
R1.13
M
The Supplier shall provide at least, but not limited to configuration, roll-out,
installation, testing of the System. The Supplier shall provide trainings for users
110
Section VI. Technical Requirements
and administrators (and other staff if needed)
R1.14
M
The Supplier shall take part in System attestation together with the Supplier of
Platform to check and certify interoperability with national resources and EHR
tools during procedures of System attestation and testing.
R1.15
M
The Supplier shall provide warranty service for the System within 3 years from
the acceptance date according to R 12.4.
R1.16
M
If additional software is required for System operation “on a turnkey basis” the
Supplier shall provide licenses (for complete System operating “on a turnkey
basis”) at his own expense and delivery it to the Purchaser ownership within this
Contract.
R1.17
M
The Supplier shall deliver System configuration to health facilities according to
Table 1. System components are set in Table 2.
R1.18
M
Minimal requirements for each module shall correspond to Section R2
R1.19
M
In Bidding Documentation the Bidder shall present edited technical specification
set within the format and structure of this Technical Requirements
R1.20
М
The system shall be able to integrate with development environments (IDE), at
least for Java and Net Framework. The system shall have a complete
development kits (SDK), which includes: documentation, sample code at least
for Java and Net Framework, to configure the system functions. An Option shall
be available to extend functionality of systems using development tools (SDK),
included into the system.
R1.21
М
Mechanism of licensing for System under this contract should not limit the
changes made with the help of development tools (SDK), included into the
System. entering Changes using development tools (SDK), included into the
System, should not affect the terms of warranty service for System. Changes to
the System by experts of the Client shall be allowed after system commissioning.
R1.22
M
The Supplier shall provide service and technical support, including provision of
new versions of the products (according to R12.3).
R1.23
М
Response time services and system components shall be no more than 3-5
seconds, for at least 80% cases of input data or requests for data browsing (at a
rate of channel 1 Mb / s and a response time of less than 100 ms).
Section VI. Technical requirements
111
R1.24
I
Option of automated notification of patients (using e-mail and/or SMS) means
available functionality for this in the System. This requirement does not cover
payment of costs for SMS sending and/or arranging access to Internet.
R1.25
М
The supplier shall document and transmit electronically the configuration files
and source code, components, systems developed under this contract
R1.26
М
The system shall have Thin Client to communicate with the equipment allowed
to use the Thick client.
R1.27
M
The System shall meet following requirements to reporting:

All analytic forms and reporting forms shall have option of export into
formats .xls, xlsx, .docx, doc, .pdf, .csv, .html, .xml.
 Time for formulation of analytic and reporting forms shall not exceed 1
min. While for 95 % of cases time for formulation of analytic and
reporting forms shall not exceed 30 seconds.
 The System shall have an option to make up analytic and reporting forms
according to set timetable.
The System shall have an option to send created analytic and reporting form to
specified e-mail address.
112
Section VI. Technical Requirements
application Целевая архитектура е-здравоохранения
Patient’s Personal
Cabinet
Personal health professional’s
cabinet
BI and Analytical tools
e-Government
services
Classifiers and Nomenclatures
Management
Existing information systems
Single data repository
RAP
OPC
MSQMS
RMS
DPMS
RPWFA
ERHP
ACPCT
EHR Repository
Analytical warehouse
Master patient index,
healthcare facilities
index, healthcare
professionals index
Classifiers and
nomenclatures
e-Government Gate
MEMS
ERDP
HB
DIS
NRD
ERCP
Acute coronary syndrome
register
Automated information system
policlinic
Integration bus
Integration bus
External Information systems
LIS
RPCRF
HIS
Unified payment system
Legend
Existing Information systems
Platform components
e-Government Gate and services
External Information systems
HIS (Health information system)
Pic.2. Summarized architecture of Comprehensive Health Information System
Table 1. Type of delivered configuration for health facilities – beneficiaries
Lot Title of health
№ facility –
beneficiary
1
Address and
contact
Municipal
Starokozhev Yury
hospital №1 Ust- 8-7232-75-28-87
Kamenogorsk city EKO, UstKamenogorsk
Abai str, 18
Type of System
configuration (according
to table 2)
Hospital
Notes
Section VI. Technical requirements
113
2
Amanov Anuar
Municipal Clinic +7 (727) 3003601
Hospital
№4 Almaty, Turksib
Almaty city
rayon, Papanin
str., 220
Hospital
3
Mother and Child Rakhimova Raya
Center Ust8-7232-57-38-76,
Kamenogorsk city Ust-Kamenogorsk
city, Utepova Str.,
35, 37
Hospital + Outpatient
clinic
4
Municipal
Policlinic №11
Almaty city
Outpatient clinic
Karibayeva
Gulzhan
8-7272-52-21-21
Almaty, Zhetysu
rayon,
Zhumabayeva str.,
87
5
Regional
Kuralbayev
Diagnostic Center Bekmakhan
Almaty city
8-7273-75-26-12
Almaty, Auezova
Str., 57
Outpatient clinic
6
Policlinic №1
Kostanay
Igimbayeva Olga
Outpatient clinic
Central rayon
hospital,
Zhualynsky
rayon, Zhambul
oblast
Zhumashev
Seitkhan
7
8 7142 56-82-23
Kostanay, Alfarabi, 112
Hospital + Outpatient
clinic
(8-726-35) 2-2149, 2-21-98
Zhualynsky rayon,
Zhambul oblast,
B.Momyshuly
village,
S.Beybarys Str, 1
8
Policlinic № 7
Astana city
Kuanysheva Aigul Outpatient clinic
8-7172-79-36-23
Astana, Sh.
Kudaiberdyuly
av., 25,29
consists of 36
remote
branches
situated in one
rayon
114
9
Section VI. Technical Requirements
Municipal
Hospital No. 1 of
Astana city
Abduov Marat,
8-7172-23-16-01
Hospital + Outpatient
clinic
Astana,
Koshkarbayev av.,
66
Table 2. Modular composition of HIS for various health facilities
Module
Hospital
Policlinic
Module «1. Reception »
-
+
Module «2. District doctor»
-
+
Module «3. Prophylactic exams»
-
+
Module «4. Profile specialist»
-
+
Module «5. Head of Policlinic department»
-
+
Module «6. Medical statistics of policlinic»
-
+
Module «7. Admission»
+
-
Module «8. Hospital Doctor»
+
-
Module «9. Hospital nurse»
+
-
Module «10. Meals»
+
-
Module «11. Day-hospital»
+
+
Module «12. Head of hospital department»
+
+
Module «13. Hospital administrator»
+
+
Module «14. Medical Statistics for Hospital»
+
+
Module «15.Procedures and manipulations»
+
+
Module «16. Admin»
+
+
Module «17. Lab IS»
+
+
Module «18. PACS» (Picture Archiving
and Communication System)
+
+
Section VI. Technical requirements
115
Module «19. Diagnostic studies»
+
+
Module «20. Pharmacy»
+
+
Module «21. Human Resources»
+
+
1.1.3.2. Requirements to processes supported and automated by the System
Note 1:
Division into modules is rather conditional and not mandatory for strict execution. Mandatory
requirement is obligatorily presence of these functions.
Note 2:
Forms referred to with the prefix /у relate to (primary) accounting forms approved by MOH order
№907 as of 23.11.2010 «On approval of forms of primary medical documentation for health
facilities».
Forms referred to without the prefix /у relate to (secondary) accounting forms (monthly, quaterly,
annual) approved by MOH order №128 as of 06.03.2013 «On approval of forms for collection of
administrative data of health facilities».
R2
Requirements to automated processes
R2.1
Module 1 «Reception»
R2.1.1
М
Management of doctor’s schedule of work, services, equipment use. This
process includes:
R2.1.1.1
M
Making schedule of doctor work with possibility to choose doctor data (name,
position, specialty, department) out of list of specialists
R2.1.1.2
M
Check for availability of already made schedule for this period of time (date,
time), for this doctor, room, equipment, and informing the user if it is available
while making up the schedule for doctor work, service provision or equipment
use
R2.1.1.3
M
Search for schedule among already existing by date, time, doctor, doctor
specialty, service, equipment or their combinations
R2.1.1.4
M
While making up the schedule for doctor work, service provision or equipment
use to set an option to interlink doctor, service and equipment. This interlink is
116
Section VI. Technical Requirements
not mandatory for filling in.
R2.1.1.5
M
while making up the schedule for service provision to plan the option of service
selection out of service list for which health facility or a doctor has the right
R2.1.1.6
M
While making schedule for equipment use to have option to choose equipment
out of list of the health facility
R2.1.1.7
M
Option of schedule generation, edition and removal
R2.1.1.8
M
While schedule removal or editing if the patients are attached thereto, to have
an option of automated choice of possible nearest time at similar specialist and
option of choice of definite time by user
R2.1.1.9
M
While schedule removal or editing to have an option of automated notification of
patient on changed date, time, place of admission by e-mail and/or SMS
R2.1.1.10
M
Making up following reports:
1.
Summary information on schedule of work of doctors by subdivisions,
shifts, service provision, equipment use
2.
Report on changes in patient records due to changed schedules.
R2.1.2
М
Registration for doctor examination with handed out admission card. This
process includes at least:
R2.1.2.1
M
Registration of the patient by receptionist, by doctor during examination, by
Patient through Internet with issuance of admission card
R2.1.2.2
M
Registration of new patients with filling in personal data, including transferring
these data from IS MHSD RK
R2.1.2.3
M
Choice of patient out of patient DB of Health Facility by name, IIN, date of birth
R2.1.2.4
M
Printing routing chart for issued cards with indication of doctor, room, date and
time of examination, some specific additional information (way of getting ready
for exam for patient and other).
R2.1.2.5
M
Registration of patient’s ambulatory card handing out and receiving
R2.1.2.6
M
Cancellation of registration by receptionist, doctor, patient by Internet
Section VI. Technical requirements
117
R2.1.2.7
M
Making up «Waiting list» to take vacant place because of cancellation of time
for doctor examination with automated notification of the patient by e-mail and
SMS in case of registration for vacant place
R2.1.2.8
M
Option to book time for examination in a schedule (solely or in group) with
regulated time to cancel reservation
R2.1.2.9
M
Automated preventing of patient registration to several doctors by the same time,
and prevention of registration of several patients to one and the same doctor
R2.1.2.10
M
Search of time for registration in existing schedules by date, time, doctor,
specialty, services, equipment and their combinations
R2.1.2.11
M
Following Reports making:
1. Report on number of registered (by doctor, service, equipment,
department, health facility)
2. Report on number of free places (by doctor, service, equipment,
department, health facility)
3. Report on cancelled visits
4. Report on not appeared patients
5. Report on preservation of visits.
6. Report on visited patients (within reported period, by referred health
facilities, by specialists, services)
R2.1.3
M
Management of Book for calls at home. This process includes at least:
R2.1.3.1
M
Registration of call at home accepted by phone, by Internet and patient’s visit to
a health facility
R2.1.3.2
M
Registration of cancel of call at home initiated by the patient
R2.1.3.3
M
Registration of transferring call at home to the doctor
R2.1.3.4
M
Registration of execution of the call with details
R2.1.3.5
M
Registration of need in second visit and its date
R2.1.3.6
M
Making up the list of non-distributed calls: by districts, by health facility in
general
118
Section VI. Technical Requirements
R2.1.3.7
M
Making up the list of calls for the doctor with indication of patients name,
diagnosis, address, phone, notes
R2.1.3.8
M
Report making:
1. Report on calls at home (opened, accepted, executed, cancelled) by
doctor, patient, district
2. Report on time of calls accepted and executed
R2.1.4
M
Record keeping in the Book of active information (calls at patient’s home by
initiative of medical specialists). It includes, at least:
R2.1.4.1
M
Dividing active information by groups – hospital, policlinic, newborn,
emergency, pregnant women, newly born women
R2.1.4.2
M
Registration of active information received by phone, Internet
R2.1.4.3
M
Registration of active information group by file import – table of established
type
R2.1.4.4
M
Registration of active information cancel
R2.1.4.5
M
Registration of transferring active information to the doctor
R2.1.4.6
M
Registration of the fact of execution with outcome details
R2.1.4.7
M
Registration of the need in second visit and its date
R2.1.4.8
M
Making up the list of non-distributed active information by districts, health
facility
R2.1.4.9
M
Making up the list of active information for the doctor with indication of patients
name, diagnosis, address, phone, notes
R2.1.4.10
M
Reports making:
1. Report on active information (opened, accepted, executed, cancelled) in a
breakdown by doctor, patient, district
2. Report on time of active information accepted and executed.
R2.1.5
M
Management of primary accounting documents at the level of Reception in line
with normative legal acts of the RK. It includes the following registration
Section VI. Technical requirements
119
formats:
R2.1.5.1
M
Form 040/y
Form 025-4/ у
Form 025-9/у
Form 025-5/у
Form 031/у
R2.1.6
M
Analytic tables formation on the Reception level as well as statistic tables in line
with current legal acts of the RK
R2.1.7
M
Interaction with IS MHSD RK, it includes at least:
R2.1.7.1
M
Transfer of information on schedules of doctor’s work, service provision,
equipment use
R 2. 18
M
Registration of facts of population attachment/ detachment from a health facility
R2.2
Module 2 «District doctor»
R2.2.1
М
Patient’s ambulatory card management. It includes, at least:
R2.2.1.1
M
Review of patients list that appointed time for doctor exam
R2.2.1.2
M
Making up Patient’s ambulatory card
R2.2.1.3
M
Making up and editing templates such as making medical papers and records,
consultations, exam protocols, diary records using templates and option to attach
files (images, video, audio) with link of user template to user account
R2.2.1.4
M
Making medical records basing on standard and user’s templates
R2.2.1.5
M
Editing and removal of medical records signed by digital signature shall be
blocked
R2.2.1.6
M
Printing filled in medical records to form paper version of ambulatory card
R2.2.1.7
M
Option of selection of medical records by certain parameters (visits, diagnosis,
date, diagnostic studies, lab analysis, service, funding source and etc.)
120
Section VI. Technical Requirements
R2.2.1.8
M
Report on changes in patient’s numerical data by time (anthropometric index,
functional index, lab data and etc.)
R2.2.2
M
Making up internal (within one health facility) and external (to other health
facilities) referrals to consulting and diagnostic services. This includes, at least:
R2.2.2.1
M
Making referrals to consulting and diagnostic services within one health facility
with possibility to register by certain time
R2.2.2.2
M
Making referrals to consulting and diagnostic services to other health facilities
with possibility to register by certain time
R2.2.2.3
M
Agreement of referrals for certain types of services with the Head of Department
R2.2.2.4
M
Recommendations making up to get prepared to consulting and diagnostic
services basing on standard templates
R2.2.2.5
M
Removal of referrals (wrong, by patient’s initiative, automatically due to
patient’s absence)
R2.2.2.6
M
Control over execution of consulting and diagnostic services prescribed for a
patient, review data on executed prescription including its results.
R2.2.2.7
M
Agreement and rejection of requests for additional consulting and diagnostic
services
R2.2.2.8
M
Report forming:
1. Report on referrals created (internal, external) by services, funding
source, level of care provision (rayon, oblast/city, national)
2. List of patients by names referred to consulting and diagnostic services
3. Report on referrals (opened, executed, rejected, internal, external)
R2.2.3
M
Making up planned hospitalization (24 hours hospital and substitute care). This
includes, at least:
R2.2.3.1
M
Making up patient summary from ambulatory card (Form 027/у)
R2.2.3.2
M
Making up of:
- templates on minimal standards of studies at pre-hospital stages by levels of
health facilities
Section VI. Technical requirements
121
- referral and card for planned hospitalization
R2.2.4
M
Making up doctor prescriptions for drugs and/or procedures, manipulations. This
includes at least:
R2.2.4.1
M
Creation of prescriptions (paid, unpaid) for medicines and narcotic drugs with
limited access of a certain category of doctors and with description of uptake
method and doses and etc.
R2.2.4.2
M
Control over prescriptions basing on set max once-only doses depending on age,
sex, weight and etc.
R2.2.4.3
M
Control over prescriptions basing on formulary of a health facility and
republican drug formulary. Results of Benefit Drug provision to dispensary
patients and other categories of population
R2.2.4.4
M
Signing prescriptions by digital signature
R2.2.4.5
M
Check for drug availability in pharmacy. Such requirement shall be implemented
through interaction with Module “Pharmacy”.
R2.2.4.6
M
Making up referrals to procedures with specification of medicines and their
doses
R2.2.4.7
M
Making up recommendations to prepare to procedures basing on standard
templates
R2.2.4.8
M
Control over prescription execution and drug release
R2.2.4.9
M
Submission of reference information by recommended prescriptions according
to approved clinical guidelines and diagnostic and treatment protocols
R2.2.4.10
M
Making up the list of doctor’s prescriptions (Form 004-1/у)
R2.2.4.11
M
Report making:
1. Report on generated receipts (INN, form, dose, uptake method, and etc.)
2. List of patients by names who got receipts
3. List of patients by names who got receipts under benefit category
R2.2.5
M
Management of initial registration documentation at district doctor level basing
on regulatory norms of the RK. This includes the following forms, at least:
122
R2.2.5.1
Section VI. Technical Requirements
M
001-2/у, 001-3/у, 001-4/у, 001-5/у, 001-6/у, 003-2/у, 004-1/у, 025/у (025-1,
025-2, 025-3, 025-4), 025-2/у, 025-3/у, 025-5/у, 025-7/у, 025-8/у, 026/у,
026-1/у, 026-2/у, 030/у, 032/у, 036/у, 038/у, 038-1/у, 038-2/у, 039/у, 040/у,
052/у, 053/у, 054/у, 058/у, 060/у, 063/у, 064/у, 070/у, 072/у, 075/у, 076/у,
086/у, 088/у 088-1/у, 094/у, 095/у 095-1/у, 106/у-12, 106-2/у-12, 112/у, 130/у,
132/у, 133/у, 138/у, 278/у, ТB 15/у, ТB 05/у,
R2.2.6
M
Making up analytic tables at district doctor level as well as statistic tables basing
on regulatory norms. This includes the following forms, at least:
R2.2.7
M
1. Statement for accounting patient visits to policlinic, dispensary,
consultations and at home (039/у) including in breakdown by district
doctors at PHC level
2. Report on executed screenings according to MOH order № 685 as of
10.11.2009 including in breakdown by district doctors at PHC level
3. Monitoring of execution of annual mandatory fluorography inspections
for population including in breakdown by district doctors at PHC level
4. Monitoring of execution of monthly and annual plans on immune
prophylactic actions by Form №5, 6 MOH order No.128 as of 6.03.2013
including in breakdown by district doctors at PHC level
5.
Report post vaccination complications in the context of primary care
physicians by types of prophylactic vaccinations by age and outcomes,
including in the context of district doctors at PHC
6. Report on dispensary patients flow including in breakdown by district
doctors at PHC level
7. Report on flow of dispensary patients with chronic renal insufficiency
with indication of substitute therapy (gemodialiaz or peritoneal, kidney
transplantation, etc.) including in breakdown by district doctors at PHC
level
8. Report on birth rate including in breakdown by district doctors at PHC
level
9. Report on mortality including in breakdown by district doctors at PHC
level
10. Report on invalid patients including in breakdown by district doctors at
PHC level
11. Report on referral and hospitalization including planned hospitalization
in breakdown by district doctors at PHC level
12. Report on Healthy life style actions including in breakdown by district
Section VI. Technical requirements
123
doctors at PHC level
13. Report on quantity and structure of attached population including in
breakdown by district doctors at PHC level
14. Report on quantity of diseases of patients living in the district attached to
a health facility and cohort of patients under dispensary control (Form
56, 12) including in breakdown by district doctors at PHC level
15. Report on cohort of patients receiving hospital substitute care (Form 24)
including in breakdown by district doctors at PHC level
16. Report on care to children (Form 31) including in breakdown by district
doctors at PHC level
17. Report on child disability (Form 52) including in breakdown by district
doctors at PHC level
18. Report on use of bed fund of health facility (hospital and day care)
(Form 21) including in breakdown by district doctors at PHC level
19. Report on patients brought by emergency care staff including in
breakdown by district doctors at PHC level
R2.2.8
M
Management of lists of temporary disability (sick lists). This includes at least:
R2.2.8.1
M
Registration of list of temporary disability
R2.2.8.2
M
Prolongation of list of temporary disability
R2.2.8.3
M
Closing of list of temporary disability
R2.2.8.4
M
Sending the list of temporary disability to Head of Department or Medical
Consultative Board for approval
R2.2.8.5
M
Making up referral to MSE (Form 088/у)
R2.2.8.6
M
Reports making up:
1. Report on issued lists of temporary disability
2. Report on referrals to MSE
R2.2.9
M
Interaction with IS MHSD RK. It includes at least:
R2.2.9.1
M
Data exchange according to EMR and EHR standards. More details in R7.2.1
R2.2.9.2
M
Data exchange on hospitalization
R2.2.9.3
M
Data exchange on executed services
124
Section VI. Technical Requirements
R2.2.9.4
M
Clinical information exchange (conclusive diagnosis, consultations, screenings,
etc.)
R2.2.9.5
M
Data exchange on referrals to consulting and diagnostic services
R2.2.9.6
M
Data exchange on assigned procedures
R2.2.9.7
M
Data exchange on receipts
R2.3
Module 3 «Prophylactic screening»
R2.3.1
М
Forming contingents subject to preventive exams from targeted group of
population (screening) and register its performance basing on regulatory norms.
This includes at least:
R2.3.1.1
M
Making up lists of patients by names for preventive examination (screening) out
of population attached to a health facility in line with regulatory documents
R2.3.1.2
M
Option of automated notification of patients (by e-mail and/or SMS) on
necessity to pass screening
R2.3.1.3
M
Make up router list for screening passing
R2.3.1.4
M
Mark on execution of studies in screening with indication of outcomes and/or
conclusion
R2.3.1.5
M
Automated making up of referrals to specialists under the screening framework
R2.3.1.6
M
Filling in card of screening
R2.3.1.7
M
Making up conclusion on passed screening
R2.3.1.8
M
Reports:
1. Report on cohort of population subject to screening (by types of screening,
district, age-sex structure)
2. Report on passed screening
3. Report on diseases revealed during screening
R2.3.2
M
registration of other types of preventive examination, regular and periodic, used
for employment. It includes at least:
Section VI. Technical requirements
125
R2.3.2.1
M
Making up lists of patients by names for preventive exams
R2.3.2.2
M
Making up router lists for preventive exams
R2.3.2.3
M
Mark on execution of studies in preventive exam with indication of outcomes
and/or conclusion
R2.3.2.4
M
Automated forming of referrals to specialists to pass preventive exam
R2.3.2.5
M
Fill in card of preventive exam
R2.3.2.6
M
Making up conclusion on passed preventive exam with issuance of certificate
R2.3.2.7
M
Reports:
1. Report on passed preventive exams (by types of screening, district, age-sex
structure)
2. Report on diseases revealed during preventive exam
3. Report on cohort of population subject to regular screening
R2.3.3
M
Management on initial registration documentation at doctor level basing on
regulatory norms. This includes at least the following forms:
R2.3.3.1
M
025/у, 025-1/у, 025-2/у, 025-4/у, 025-5/у, 025-7/у, 025-8/у, 030/у, 032/ у,
040/у, 086/у, 108/у, 108-1/у, 112/у, 131/у, 245/у
R2.4
Module 4 «Profile specialist»
R2.4.1
М
Patient’s ambulatory card management using data of national EHR. This
includes at least:
R2.4.1.1
M
Review of patients lists appointed for exam
R2.4.1.2
M
Templates making up and editing including medical statements and records,
consultations, exam protocols, diaries and option of file attachment (image,
video, audio) with link to user account
R2.4.1.3
M
Making medical records using standard or user templates
R2.4.1.4
M
Medical records editing and removal of those which are not signed
126
Section VI. Technical Requirements
R2.4.1.5
M
Printing of filled in medical records for paper version of ambulatory card
R2.4.1.6
M
Option to select medical records by certain parameters (encounters, diagnosis,
dates, diagnostic studies, lab analysis, services, funding source and etc.)
R2.4.1.7
M
Report on changes in patient’s numerical signs by time (anthropometric index,
functional index, lab data, etc.)
R2.4.2
M
Making up internal (within one health facility) and external (to the other health
facilities) referrals to consultative and diagnostic services. This includes at least:
R2.4.2.1
M
Making up referrals to additional consultative and diagnostic services by
referrals issued by PHC department within a facility with option to appoint time
R2.4.2.2
M
Adding additional consultative and diagnostic services without agreement with
PHC department
R2.4.2.3
M
Making up an request for additional types of studies to be approved by PHC
department
R2.4.2.4
M
Mark on performed consultative and diagnostic services
R2.4.2.5
M
Making up protocols of consultations, exam, operation basing on standard and
user templates
R2.4.2.6
M
Formulate recommendations on getting prepared to consultative and diagnostic
services
R2.4.2.7
M
Removal of referrals (wrong, by patients initiative, automated if the patient did
not appear)
R2.4.2.8
M
Control over consultative and diagnostic services execution. Registration of
firstly coming dispensary patient and transferring this data to district doctor,
recommendations on periodicity of monitoring and examination
R2.4.2.9
M
Reports:
1. Report on created referrals (internal, external) by services, funding
sources
2. List of patients by names referred to consultative and diagnostic services
3. Report on rendered consultative and diagnostic services
Section VI. Technical requirements
127
4. List of patients by names which got consultative and diagnostic services
R2.4.3
M
Make up doctor prescriptions for drugs and/or procedures and manipulations. It
includes at least:
R2.4.3.1
M
Making up receipts for drugs (paid, unpaid) with description of uptake method,
dosing and etc.
R2.4.3.2
M
Control over prescriptions in line with set maximal once-only doses depending
upon age, sex, weight and etc.
R2.4.3.3
M
Control over prescriptions basing on health facility and republican drug
formulary
R2.4.3.4
M
Signing prescriptions by digital signature
R2.4.3.5
M
Check for drug availability in pharmacy
R2.4.3.6
M
Making up referrals to procedures
R2.4.3.7
M
Making up recommendations to prepare to procedures basing on standard
templates.
R2.4.3.8
M
Control over prescription execution and drug release
R2.4.3.9
M
Submission of reference information by recommended prescriptions according
to approved clinical guidelines and diagnostic and treatment protocols
R2.4.3.10
M
Report making:
1. Report on generated receipts (INN, form, dose, uptake method, and etc.)
2. List of patients by names who got receipts
3. List of patients by names who got receipts under benefit category
4. List of patients by names who got medical devices
5. List of patients by names referred to consultative and diagnostic service
6. Report on referrals to procedures (opened, under execution, executed,
rejected, external, internal).
R2.4.4
M
Management of initial registration documentation at profile specialist level
basing on regulatory norms. This includes the following forms, at least:
128
R2.4.5
Section VI. Technical Requirements
M
001-3/у, 001-4/у, 001-5/у, 001-6/у, 001-7/у, 025/у, 025-1/у, 025-2/у, 025-3/у,
025-4/у, 025-5/у, 025-7/у, 025-8/у, 025-9/у, 027-2/у, 030/у, 030-1/у, 030-2/у,
030-6/у, 036/у, 037/у, 037-1/у, 039/у, 039-2/у, 039-3/у 040/у, 045/у, 048/у,
052/у, 053/у, 054/у, 058/у, 060/у, 065/у, 065-1/у, 069/у, 070/у, 071/у, 073/у,
083/у, 084/у, 086/у, 088/у, 089/у, 090/у, 094/у, 095/у, 095-1/у, 098/у, 111/у,
112/у, 128/у, 130/у, 132/у, 133/у, 138/у, 278/у,
R2.4.6
M
Management of lists of temporary disability. This includes at least:
R2.4.7
M
Registration of list of temporary disability
R2.4.7.1
M
Prolongation of list of temporary disability
R2.4.7.2
M
Closing of list of temporary disability
R2.4.7.3
M
Sending the list of temporary disability to Head of Department or Medical
Consultative Board for approval.
R2.4.7.4
M
To make up a report on issued lists of temporary
R2.4.7.5
M
To draw a referral to Medical Social-Expert Commission (MSEC), creation and
editing templates for MSEC
R2.4.8
M
Making up analytic tables at profile specialist level as well as statistic tables
basing on regulatory norms. This includes the following forms, at least:
R2.4.8.1
M
1. Statement for accounting patient visits to policlinic, dispensary, consultations
and at home (039/у)
2. Report on executed screenings according to MOH order № 685 as of
10.11.2009
3. Report on dispensary patients flow
4. Report on invalid patients
5. Report on adult invalid patients
6. Report on planned hospitalization
7. Report on quantity of diseases of patients living in attached district and
cohort of patients under dispensary control (Form 56, 12
8. Report on cohort of patients who get substitute care (Form 24)
9. Report on care to children (Form 31)
Section VI. Technical requirements
129
10.Report on child disability (Form 52)
11. Report on use of bed fund of health facility (hospital and day care) (Form
21)
R2.5
Module 5 «Head of Department in Policlinic»
R2.5.1
М
Confirming or rejection of referrals for certain types of services using digital
signature
R2.5.2
М
Management of initial registration documentation at Head of Department level
basing on regulatory norms. This includes the following forms, at least:
R2.5.2.1
M
1. 035/у
2. 035-1/у
3. 035-2/у
4. 035-3/у
5. 095/у
6. 094/у
R2.5.3
М
Making up analytic tables at Head of Department level as well as statistic tables
basing on regulatory norms. This includes the following forms, at least:
R2.5.3.1
M
Report making up:
1. Making up analytic tables in a breakdown similar to the tables of
department staff
2. Report on attached population by districts
3. Report on age-sex structure of attached population
4. Report on staff composition of districts doctors
5. Report on main district performance indexes
6. Form 12
7. Report on the structure of visits (in terms of disease, preventive
screenings, dispensary patients, for a visit to doctor examination, at
home, providing substitute care technology, visits to nursing staff, in first
aid room, a treatment room, on preventive vaccination)
8. Report on hospitalization of people from attached to a health facility area
9. Structure of consulting exams by profile specialists in breakdown by the
districts of attached population
130
Section VI. Technical Requirements
R2.5.4
М
Agreement of list of temporary disability, minutes of MCB. This includes, at
least:
R2.5.4.1
M
Agreement of long-term lists of temporary disability
R2.5.4.2
M
Creation of MCB minutes
R2.5.4.3
M
Make up MCB conclusions
R2.5.4.4
M
Signing of MCB conclusion by digital signature
R2.5.4.5
M
Reports:
1. Report on issued lists of temporary disability
2. Report on quantity of patients passed through MCB
3. Report on quantity of patients referred to re-certification in MSE
R2.6
Module 6 «Medical Statistics in Policlinics»
R2.6.1
M
Monitoring of initial registration documentation management in a health facility
R2.6.2
M
Making up analytic tables at the level of a specialist in health statistics as well as
statistic tables basing on regulatory norms. This includes at least the following:
R2.6.2.1
M
Constructor of reports with option to generate new reports and edit existing ones
R2.6.2.2
M
Report making up:
1. Form 039/у
2. Form 007/у
3. Report on attached population and its age-sex structure
4. Report on executed screenings
5. Report on staff composition of participants
6. Report on activities to attach population to a district
7. Reporting forms 21, 12, 17, 24, 30, 31, 32, 43, 47, 52, 59, 4, 5, 6
R2.7
R2.7.1
Module 7 «Admission»
М
Registration of patients addresses. This process includes, at least:
Section VI. Technical requirements
131
R2.7.1.1
M
Demographic data adjusting
R2.7.1.2
M
Data check and entry on insurance category and payment
R2.7.1.3
M
Registration of medical referral and/or rejection in care provision
R2.7.1.4
M
Medical documents making up and issuance
R2.7.1.5
M
Setting links between referrals doubles
R2.7.1.6
M
Distribution of patients by specialised departments and rooms
R2.7.1.7
M
Preliminary attachment of a patient to doctor in charge
R2.7.1.8
M
Confirming readiness to accept the patient
R2.7.2
M
Management of patients EMR. It includes, at least:
R2.7.2.1
M
Full description of processes and requirements to EMR management in line with
national standard of EMR (approved by MOH order №75 as of 10.02.2014 «On
approval of technical documentation in e-health issues»)
R2.7.2.2
M
Minimal obligatory set of data from EMR is given to national EHR basing on
national standard of EHR
R2.7.3
M
Clarification of services carried out before hospitalization. It includes at least:
R2.7.3.1
M
Review of patients EHR from national EHR repository
R2.7.3.2
M
Registration of diagnosis, procedures, prescriptions and other data on medical
services carried out prior to hospitalization but not entered into the System
R2.7.4
M
Management of initial registration documentation at Admission level basing on
regulatory norms. This includes the following forms, at least:
R2.7.4.1
M
001/у, 003/у, 003-3/у, 004-1/у, 045/у, 058/у, 060/у, 069/у, 264/у
R2.7.5
M
Making up analytic tables at Admission department level. This includes the
following forms, at least:
R2.7.5.1
M
Reports:
132
Section VI. Technical Requirements
1.
Report on scope of performed services, manipulations, exams
2.
Report on drugs and vaccination
3.
Report on performed work (quantity of applied patients, quantity of
hospitalized patients in planned and extraordinary way, to day hospital,
rejections from hospitalization, patients delivered by emergency care, sent by
PHC or self-reversal patients)
4.
Report on active information submitted to policlinic
5.
Tables of bed fund of a health facility with indication of vacant beds
R2.7.6
M
Interaction with IS MHSD RK. It includes, at least:
R2.7.6.1
M
Data exchange on executed services in admission department before
hospitalization
R2.7.6.2
M
Data exchange on hospitalization and rejection from it
R2.7.6.3
M
Data exchange on state of bed fund
R2.7.6.4
M
Data exchange with IS MHSD RK according to interoperability requirements of
MHSD
R2.8
Module 8 «Hospital Doctor»
R2.8.1
М
Management of patients EMR. It includes, at least:
R2.8.1.1
M
Full description of processes and requirements to EMR management in line with
national standard of EMR (approved by MOH order №75 as of 10.02.2014 «on
approval of technical documentation in e-health issues
R2.8.1.2
M
Minimal obligatory set of data from EMR is given to national EHR basing on
national standard of EHR
R2.8.1.3
M
Disease case study based on a standard template for the appropriate number of
beds (personal data, medical history, personal history, past illnesses, the results
of the initial inspection, prescriptions)
R2.8.1.4
M
Preliminary plan of treatment and additional studies if required
R2.8.1.5
M
Registration of patients visits and examination by doctor in charge
R2.8.2
M
Management of referrals to consultative and diagnostic services. It includes, at
Section VI. Technical requirements
133
least:
R2.8.2.1
M
Adjusting plan of treatment, use plan during treatment, changes in plan if
required
R2.8.2.2
M
Make up referrals to lab studies, study results and (if required) interpretations
giving
R2.8.2.3
M
Make up referrals to diagnostic services, study results and (if required)
interpretations giving
R2.8.2.4
M
Make up referrals to other doctors, study conclusion of specialists
R2.8.2.5
M
Monitoring of referrals state and identification of delays and rejections
R2.8.3
M
Diagnosis putting. It includes at least:
R2.8.3.1
M
Case review from national EHR repository
R2.8.3.2
M
Analysis results review
R2.8.3.3
M
Diagnosis adjusting and registration: diagnosis of sent health facility (referral),
admission diagnosis (preliminary), the final clinical diagnosis, complications,
comorbidities, the final, anatomopathological diagnosis
R2.8.3.4
M
Monitoring of execution of plan of treatment and its adjusting
R2.8.4
M
Make up doctor prescriptions for drugs and/or procedures and manipulations. It
includes at least:
R2.8.4.1
M
Study patients allergy
R2.8.4.2
M
Check for drug compatibility
R2.8.4.3
M
Make up prescriptions on drug using
R2.8.4.4
M
treatment and diagnostic procedures assigning
R2.8.4.5
M
Monitoring of prescriptions executed in a right way and in time by nurse and
involved into care parties
R2.8.4.6
M
Registration of side effect of drugs and complications from drugs and
134
Section VI. Technical Requirements
procedures
R2.8.5
M
Patient discharge. It includes at least:
R2.8.5.1
M
Determination of final diagnosis
R2.8.5.2
M
Make up Form 066/у
R2.8.5.3
M
Patient discharge making up
R2.8.5.4
M
Registration of vacant bed
R2.8.6
M
Making up analytic tables at doctor level. It includes at least:
R2.8.6.1
M
Reports:
1.
Report on carried out work (number of cases with outcomes)
2.
Report on number of carried out operations (including those with
complications)
3.
Report on number of carried out manipulations
Report on bed fund (bed operating, average duration of patient use of
bed, execution of bed-days, death cases)
4.
5.
Report on use of diagnostic studies
6.
Report on rehabilitation procedures
R2.8.6.2
M
Analytic tables making up
R2.8.7
M
Management of initial registration documentation at hospital doctor level basing
on regulatory norms. This includes the following forms, at least:
R2.8.7.1
M
003/у, 003-3/у, 004-1/у, 005/у, 008/у, 011/у, 011-1/у, 011-2/у, 011-3/у,027/у,
066/у, 066-4/у,
R2.9
Module 9 «Hospital Nurse»
R2.9.1
M
Management of patients EMR. It includes, at least:
R2.9.1.1
M
Full description of processes and requirements to EMR management in line with
national standard of EMR (approved by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in e-health issues”)
Section VI. Technical requirements
135
R2.9.1.2
M
Minimal obligatory set of data from EMR is given to national EHR basing on
national standard of EHR (approved by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in e-health issues”)
R2.9.1.3
M
Demographic data adjusting
R2.9.1.4
M
Case treatment plan study
R2.9.1.5
M
Registration on required referrals (appointing to doctor for exam) to lab,
diagnostic rooms and other specialists according to referrals and doctor
prescriptions
R2.9.1.6
M
Reports:
1.
Report on drugs and medical devices
2.
Report on carried out procedures
3.
Report of dressing/aid room
R2.9.2
M
Mark on execution of prescriptions and care plan, it includes, at least:
R2.9.2.1
M
Mark on drugs taken by patients
R2.9.2.2
M
Report on made procedures (for extraordinary cases when there are no work
places in treatment room)
R2.9.2.3
M
Mark on made operations (for extraordinary cases when there are no work places
in operating room)
R2.9.2.4
M
Entry of results of lab analysis and diagnostic tests (if there are no work places
in relevant rooms for registration of results)
R2.9.3
M
Monitoring of patient state. It includes, at least:
R2.9.3.1
M
Mark on made assessment over patient state (temperature, complaints and etc.)
R2.9.3.2
M
Monitoring of treatment plan execution
R2.9.3.3
M
Warning in urgent cases
R2.9.4
M
Management of initial registration documentation at nurse level. This includes,
at least:
136
Section VI. Technical Requirements
R2.9.4.1
M
R2.9.4.2
M
Printing of referrals and plan of treatment
The System shall be able to manage following registration forms:
1.
004/у, 004-1/у, 007/у, 009/у, 029/у,
2.
Register for blood intake for HIV
3.
Register for recipients transfer to policlinic
4.
Register of medication
5.
Register of dressing material
6.
Requirements to pharmacy
7.
Register for ethanol
8.
Register for narcotic drug, psychotropic substances and precursors
(Decree of GOK № 396 as of 30.03.2012)
R2.9.5
M
Analytic tables making at nurse level.
R2.9.5.1
M
Drawing up the following reports:
R2.10
1.
Report on used medications, including drugs and ethanol
2.
Report on used medical devices
3.
Report on identification of Blood group
4.
Report on revealed infectious patients
5.
Report on transfusion of blood and blood products
6.
Report on blood sampling and other parts of organism for study
7.
Report on biopsy sampling
8.
Report on referrals to external studies
Module «10 Meals»
R2.10.1
M
Every day menu forming. It includes, at least:
R2.10.1.1
M
Forming menu – requirement, editing, protection from editing upon approval
R2.10.1.2
M
Forming menu handed out to tables with indication of dishes, editing and
protection from editing upon approval
R2.10.1.3
M
Review of list of dishes for each type diet (Table)
Section VI. Technical requirements
137
R2.10.1.4
M
Review of patients selected by diets, rooms, departments and etc.
R2.10.1.5
M
Review of patients and medical staff comments towards meal quality
R2.10.2
M
Calculator of every day, monthly consumption of food for menu. It includes, at
least:
R2.10.2.1
M
Calculation of required food products for each day, given listed quantity of
patients in a health facility
R2.10.2.2
M
Adjusting number of portions (with logging of changes) for each type of diet
R2.10.2.3
M
Automated estimation of required food quantity and composition
R2.10.2.4
M
Printing order for food delivery
R2.10.2.5
M
Review of above data for previous periods (data adjusting is possible by special
permission of Hospital Administrator given for limited time period)
R2.10.2.6
M
Possibility to review log in case of manual changes in quantity of portions
R2.10.3
M
Estimation of nutrition value of dishes in ration. This includes, at least:
R2.10.3.1
M
Estimation of dish nutrition value given standard of waist and loss during
culinary processing
R2.10.3.2
M
Automated prompting on composition and food value for various diets
R2.10.3.3
M
Report on feed value by each diet and assigning recommended standards for
each diet
R2.10.4
M
Making references of food products. It includes, at least:
R2.10.4.1
M
Handbook of basic food products and semi-finished products
R2.10.4.2
M
Reference of dish cards and composition
R2.10.4.3
M
Reference of dieted dish (tables 1-15)
R2.10.5
M
Patients diet management
138
Section VI. Technical Requirements
R2.10.5.1
M
Review of recommendations on diets from specialists and care doctors for each
patient
R2.10.5.2
M
Diet prescription (Table number)
R2.10.5.3
M
Diet change
R2.10.5.4
M
Review of patients and medical staff references on food quality
R2.10.6
M
Analytic tables forming for meals
R2.11
Module «11 Day Hospital»
R2.11.1
M
Management of patients EMR. It includes, at least:
R2.11.1.1
M
Full description of processes and requirements to EMR management in line with
national standard of EMR (approved by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in e-health issues”)
R2.11.1.2
M
Minimal obligatory set of data from EMR is given to national EHR basing on
national standard of EHR (approved by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in e-health issues”)
R2.11.1.3
M
Disease case study
R2.11.1.4
M
Preliminary plan of treatment
R2.11.1.5
M
Registration of patients visits and examination by doctor in charge
R2.11.2
M
Creation of referrals to consultative and diagnostic services. It includes, at least:
R2.11.2.1
M
Adjusting plan of treatment, use plan during treatment, changes in plan if
required
R2.11.2.2
M
Make up referrals to lab studies, study results and (if required) interpretations
giving
R2.11.2.3
M
Make up referrals to diagnostic services, study results and interpretations giving
R2.11.2.4
M
Make up referrals to other doctors, study conclusion of specialists
R2.11.2.5
M
Monitoring of referrals state and identification of delays and rejections
Section VI. Technical requirements
139
R2.11.3
M
Registration of doctor prescriptions and execution. It includes at least:
R2.11.3.1
M
Study patients allergy anamnesis
R2.11.3.2
M
Check for drug compatibility
R2.11.3.3
M
Make up prescriptions on drug using
R2.11.3.4
M
Procedures assigning
R2.11.3.5
M
Mark on execution of procedures
R2.11.3.6
M
Monitoring of prescriptions executed in a right way and in time by nurse or
helping persons
R2.11.3.7
M
Registration of side effect of drugs and complications from medicines and
procedures
R2.11.4
M
Management of initial registration documentation at Day Hospital level basing
on regulatory norms. This includes the following forms, at least:
R2.11.4.1
M
001-3/у, 001-4/у, 003-2/у, 004-1/у, 027/у, 029/у, 066-4/у
R2.11.5
M
Making up analytic and statistic tables at Day Hospital level in line with
normative legal acts. It includes at least:
R2.11.5.1
M
Reports:
1. Report on carried out work (number of cases with outcomes)
2. Report on number of carried out operations (including those with
complications)
3. Report on number of carried out manipulations
4. Invoice for reported period specifying cost of treatment by nosology forms
5. Report on average duration of stay in hospital
R2.11.6
M
Interaction with IS MHSD RK. It includes at least:
R2.11.6.1
M
Data exchange on executed services
R2.11.6.2
M
Clinical information exchange (diagnosis, consultations and examinations
results, etc.)
140
Section VI. Technical Requirements
R2.11.6.3
M
Data exchange on referrals
R2.11.6.4
M
Data exchange on receipts
R2.12
Module «12 Head of Hospital Department»
R2.12.1
M
Confirming or rejection of referrals for certain types of services using digital
signature
R2.12.2
M
Management of initial registration documentation at Head of Department level
basing on regulatory norms. This includes the following forms, at least:
R2.12.2.1
M
The System shall be able to register information of following initial accounting
forms:
035/у, 035-1/у, 035-2/у, 035-3/у, 094/у, 095/у
R2.12.3
M
Making up analytic tables at Head of Department level as well as statistic tables
basing on regulatory norms by forms and similar tables of department
specialists. List of analytic and statistic forms shall be agreed with the Client at
the stage of System design.
R2.12.4
M
Agreement of lists of disability, records of council of physicians. It includes at
least:
R2.12.4.1
M
Agreement of long-term lists of disability
R2.12.4.2
M
Creation of records of council of physicians
R2.12.4.3
M
Make up council of physicians conclusions
R2.12.4.4
M
Signing council of physicians conclusion by digital signature
R2.12.4.5
M
Reports:
1. Report on issued lists of temporary disability
2. Report on patients passed through council of physicians
3.
Report on operating factors of bed fund of a department
4.
Report on treated patients
5.
Structure of treated cases by groups of nosology and age
6.
Report on services rendered by codes of tarrificator
Section VI. Technical requirements
R2.13
141
Module 13 «Hospital Administrator»
R2.13.1
M
Making up analytic tables at Hospital Administrator level as well as statistic
tables basing on regulatory norms. List of analytic and statistic forms shall be
agreed with the Client at the stage of System design. This includes the following
forms, at least:
R2.13.1.1
M
Monitoring of initial documentation maintenance in a health facility
R2.13.1.2
M
Analytic tables and reports accessible to all health facility departments by
division into departments
R2.14
Module 14 «Medical Statistics for Hospital»
R2.14.1
M
Bed fund management. It includes, at least:
R2.14.1.1
M
Management of bed fund referral by units, rooms, beds
R2.14.1.2
M
Setting up bed fund use (bed installing, bed folding, temporary beds, setting
maximal number of beds in room, management of information on bed profiles,
bed profile change, bed closing and reducing)
R2.14.1.3
M
Entry of additional information on bed, room (male, female)
R2.14.2
M
Making up analytic tables at Medical statistic level as well as statistic tables
basing on regulatory norms.
R2.14.2.1
M
Forming initial reports and forms:
1.
Every day :007/у, 007-1/у,
2.
Monthly: 016/у
3.
Form 21
4. Form 14 annual (ICD-10 and ICD-9)
5. Form 32 annual
6. Form 30 annual
7. List of cured cases at tertiary level with indication of operations
8. Hospital activity report
9. Work of departments by bed profiles;
10. Composition of patients, terms and outcomes;
142
Section VI. Technical Requirements
11. Main indicators for hospital work;
12. Information on structure of all types of secondary care;
13. Composition of patients by groups of diagnosis;
14. Composition of cured patients by outcomes;
15. Statistic data on work of resident doctors;
16. Surgery work by departments;
17. Analysis of surgery activity;
18. Summary information on operated patients by bed profiles;
19. Information on pre-surgical state;
20. Operations by surgery units;
21. composition of patients for surgical departments ;
22. analysis of activity of intensive care unit;
23. analysis of mortality and matches in clinical and post-mortem diagnoses;
24. analysis of diagnosis coincidence by referral and final one;
25. data on treated patients by districts and regions;
26. data on treated patients by referrals for “HB" ;
27. data on the types of injuries;
28. data on patients received in alcoholic state;
29. list of patients treated;
30. List of patients in the hospital;
31. list of the dead to be submitted to the registration service
32. list of the dead in the hospital at district level;
33. List of deaths by age;
34. information on treated villager inhabitants;
35 List of operated patients by departments;
36. list of patients operated on by doctors of the Department;
37. list of patients in breakdown by selected diagnoses;
38. list of patients with complications after surgery;
39. list of patients passing through resuscitation;
40. list of patients transferred to other hospital
41. list of treated patients who appeared to be healthy ;
42. list of patients having preferential category;
Section VI. Technical requirements
143
43. list of patients admitted again within a month;
44. sex and age composition of treated patients by profiles;
45. report on services delivered by diagnostic departments;
46. Structure of patients with circulatory diseases in breakdown by nosology,
age and outcome.
47. report on cured cases in breakdown by DRG.
R2.14.2.2
M
Monitoring of primary records maintenance of a health facility
R2.14.2.3
M
Report Designer with the ability to create new reports and modify existing
R2.15
Module 15 «Procedures and manipulations »
R2.15.1
M
Management of patients EMR. It includes, at least:
R2.15.1.1
M
Full description of processes and requirements to EMR management in line with
national standard of EMR (approved by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in e-health issues”)
R2.15.1.2
M
Minimal obligatory set of data from EMR is given to national EHR basing on
national standard of EHR (approved by the same order)
R2.15.1.3
M
Patient identifier
R2.15.1.4
M
Mark on executed procedures
R2.15.1.5
M
Appointing the patient by time if there is a need to get services again
R2.15.2
M
Management of initial documentation for rendered services and manipulations
according to regulations. It includes at least:
R2.15.2.1
M
029/у, 042/у,044/у, 046/у, 047/у, 058/у, 063/у, 064/у, 064-1/у, 064-2/у,
069/у, 150/у
R2.15.3
M
Making up analytic tables on carried out procedures and manipulations and
statistic tables according to regulations. It includes
R2.15.3.1
M
Reports:
Report on carried out services (by used equipment, executers, funding sources
types of services)
144
Section VI. Technical Requirements
R2.16
Module 16 «Admin»
R2.16.1
M
Database management. This process includes, at least:
R2.16.1.1
M
Monitor and optimize of database performance
R2.16.1.2
M
Database Management: Configuration of repository, database extension
R2.16.1.3
M
Managing users and passwords of database
R2.16.1.4
M
Access rights management to database in accordance with Annex 1
R2.16.1.5
M
Backing up data for a certain period of time
R2.16.1.6
M
Restoring the backup data on separate servers to find old data.
R2.16.2
M
Creating user groups and individual users of the system. This process includes,
as a minimum:
R2.16.2.1
M
Create, delete, and edit user accounts;
R2.16.2.2
M
Create, delete, and modify user roles;
R2.16.2.3
M
Attaching roles to specific users (the same user can have multiple roles)
R2.16.2.4
M
Add, change, or delete access rights of roles to modules, initial rights shall be
assigned in accordance with Annex 1.
R2.16.2.5
M
Temporary ban for user access to the System
R2.16.3
M
Manage authentication types (password, digital signature) This process includes,
at least:
R2.16.3.1
M
Initial password creation
R2.16.3.2
M
Change passwords for those users who are not able to change them
R2.16.3.3
M
Change Password Management Policy
R2.16.3.4
M
Using foreign keys
Section VI. Technical requirements
145
R2.16.3.5
M
View attempts to access with an invalid key
R2.16.4
M
Maintain system logs. This process includes, as a minimum:
R2.16.4.1
M
Log of created, modified, and deleted records in the database
R2.16.4.2
M
Log of the users input history
R2.16.4.3
M
Log of receiving reports
R2.16.4.4
M
Log of data viewing
R2.16.4.5
M
Log of archiving actions
R2.16.4.6
M
Log of Errors and emergency program stops
R2.16.4.7
M
Log of synchronization with external (national) directories, classifications,
indexes and registers
R2.16.5
M
Customization of medical records templates. This process includes, at least:
R2.16.5.1
M
Creating new templates
R2.16.5.2
M
Change (creating new versions) of existing templates
R2.16.5.3
M
Attaching templates to modules and their detachment
R2.16.5.4
M
The following functions are used when creating and editing the templates:
• change the font settings (style, size, bold, underline, italics, etc. )
• changing the font color
• the creation of complex patterns with subsections
• the ability to use any directory in the system for filling in fields in the template
• the ability to use any entity in the database for filling in fields in the template
• the ability to use any data selection from the database for filling in fields in the
template
• forming fill rules: only from the list, from the list with possible matches, in
free format, from the samples, etc.
• creating new directories used when completing the template
146
Section VI. Technical Requirements
R2.16.6
M
Customizing user interface. This process includes, at least:
R2.16.6.1
M
Controlling access to interface tools depending on user access rights
R2.16.6.2
M
Change the style (for example: colors, size of fields, fonts)
R2.16.6.3
M
Option of making up individual templates for each user including assigning
defaults to separate fields in pattern of this user
R2.16.7
M
Configuring user access. This process includes, at least:
R2.16.7.1
M
Adding, modifying, and deleting user rights on actions in the System
R2.16.7.2
M
Manage (add, edit and delete) access to data in the context of organizational
structure of enterprise: within structural unit attached to the user, within the
entire health facility, in accordance with organization structure of enterprise
R2.16.7.3
M
Fixing the right for user for view, creation, change and removal of data in certain
structural units
R2.16.7.4
M
Add, change, or delete user access to reports
R2.16.7.5
M
Time Management - Schedule of work of employees, during which the user has
access rights to the System
R2.16.7.6
M
Controlling access to patient data in accordance with the privacy policy of
personal data approved by MHSD RK.
R2.16.7.7
M
Installation privacy indication for those personal data that must be stored in a
database in encrypted form
R2.16.7.8
M
Viewing logs with the actions of specific users for a certain period of time
R2.16.7.9
M
Archiving and cleaning logs with data about user activity for a certain period in
accordance with the policies of MHSD RK
R2.16.7.10 M
Viewing log files
R2.16.8
M
Setting of connection to external programs. This process includes, at least:
R2.16.8.1
M
Allowing access for certain IP addresses
Section VI. Technical requirements
147
R2.16.8.2
M
Resolution of certain programs and services
R2.16.8.3
M
Change access passwords of external programs
R2.16.9
M
Managing directories (references). This process includes, at least:
R2.16.9.1
M
Changing content (add, edit) of local directories of the system
R2.16.9.2
M
Monitoring the synchronization of external (national) directories, indexes and
registers
R2.16.9.3
M
Monitoring of correctness (or potential problems ) of data exchange with
external data sources (national EHR, national analytical repository)
R2.16.9.4
M
Change the synchronization schedule with external information resources
R2.16.10
M
Create, edit reports using the Report Master, which allow create and edit of
reports with using of fields from System data base. This process includes, at
least:
R2.16.10.1 M
Creating Reports
R2.16.10.2 M
editing reports
R2.16.10.3 M
Deleting reports
R2.16.10.4 M
Setting user rights to use reports
R2.17
Module 17 «Lab IS»
R2.17.1
M
Registration of received material with the possibility of rejection. This process
includes, at least:
R2.17.1.1
M
Doing personified account of ongoing research, support of patient cards in the
LIS database
R2.17.1.2
M
Creating a new patient card by assigning a unique identification number after:
automatically retrieve of data from other modules on the flow of new patient,
automatically after receiving (reading) the referral, entry of patient data from the
referral manually
R2.17.1.3
M
Reading standard forms using: optical recognition of symbols, optical
148
Section VI. Technical Requirements
recognition of marks
R2.17.1.4
M
Registration of received material with reference to the patient
R2.17.1.5
M
Assigning a unique identification number to each material
R2.17.1.6
M
Ability to reject Receipt stating the reason (from the directory and / or manually)
R2.17.1.7
M
Generating reports:
1. Report on the quantity of incoming material
2. Report on quantity of rejected material for various reasons
R2.17.2
M
Barcoding material (creating barcode, identification by barcode). This process
includes, as a minimum:
R2.17.2.1
M
Assigning a barcode for material
R2.17.2.2
M
Assigning a barcode for individual samples
R2.17.2.3
M
Read barcode using stationary and portable bar code scanners
R2.17.2.4
M
Support for processing the data on the basis of the majority of these bar codes:
Code 39, Code 93, Code 128, Codebar, European Article Number (EAN), ITF14, MSI Barcode, Universal Product Code, as well as two-dimensional codes
PDF417, Aztec Code, Data Matrix, Maxi Code, QR-code, Microsoft Tag
R2.17.3
M
Formation of worksheets for laboratory analyzers and executors. This process
includes, at least:
R2.17.3.1
M
Formation of orders for analysis based on referrals received from HIS
R2.17.3.2
M
Formation of orders for analysis based on manual data entry
R2.17.3.3
M
Inclusion of several materials to one order
R2.17.3.4
M
Using of service profiles for ordering (multiple studies)
R2.17.3.5
M
Order of integrated services (one service with multiple materials)
R2.17.3.6
M
Automatic distribution of analysis on worksheets based on configurable criteria
(type of analysis, analysis time , executor)
Section VI. Technical requirements
149
R2.17.3.7
M
Manual distribution of analysis on work places
R2.17.3.8
M
Redistribution of analysis from selected worksheets to other worksheets
R2.17.3.9
M
Changing the executor in a worksheet
R2.17.3.10 M
Prints worksheets to perform manual research
R2.17.4
M
Interaction with laboratory equipment (export referrals to analysis, import of
analysis results). This process includes, at least:
R2.17.4.1
M
Connecting analyzers , sample preparation stations and other equipment that
have the ability to connect to LIS
R2.17.4.2
M
Submit orders to analyzers
R2.17.4.3
M
Getting results from the analyzers and their distribution in the patient cards
R2.17.4.4
M
Getting results of internal quality control from analyzers
R2.17.4.5
M
Viewing, editing, deleting, editing, approving of the results
R2.17.5
M
Manual entry of laboratory results. This process includes, at least:
R2.17.5.1
M
Setting up a result templates
R2.17.5.2
M
Manual entry of finished research results
R2.17.5.3
M
Adjustable calculation algorithm of the finished results based on input data
R2.17.5.4
M
Processing of the results of bacteriological analysis:
• The processing system must be open and allow the user within embedded in
the system classification to add independently the sections such as: antibiotics,
diagnoses, biomaterials, micro-organisms,
• A list of diagnoses in the system shall be composed by ICD-10, the list of
antimicrobials shall be drawn up according to international classification, the list
of taxons - on the latest edition of "Bergey's Manual of Determinative
Bacteriology"
• antibiogram shall be built based on the data entered by the user and received by
any of the methods (disk diffusion, by limiting concentrations or when
determining the minimum inhibitory concentration)
150
Section VI. Technical Requirements
• The processing system, based on embedded data on the natural stability of
individual organisms or their groups, on distribution among them acquired
resistance, as well as information about clinical efficiency of antimicrobial
agents, shall interpret the results of studies of antibiotic susceptibility, obtained
in vitro, to the degree of sensitivity (S, I, R) and, if necessary , correct them or
generate an error message
R2.17.5.5
M
Forming of reports:
1. Report on completed analysis
2. Report on antibiotic resistance of isolates (in general in a health facility and
by its units)
3. Report on types of lab studies (clinic, biochemical, hematological,
immunological, bacteriological and etc.)
4. 261 / y
5. 262 / y
6. Form # 1 POA (Report expensive services compared with plan)
R2.17.6
M
Validation of the results of laboratory research laboratories by authorized
employee. This process includes, at least:
R2.17.6.1
M
Viewing results of an analysis execution
R2.17.6.2
M
Comparison with the reference values with visual indication of deviations
R2.17.6.3
M
Construction of control charts to evaluate the quality of results
R2.17.7
M
Laboratory quality control (intralaboratory, interlaboratory, external). This
process includes, at least:
R2.17.7.1
M
Registration of the daily results of the control materials study
R2.17.7.2
M
Register reference values of control materials
R2.17.7.3
M
Comparison of obtained values with the reference values
R2.17.7.4
M
Formation of control materials research protocols for interlaboratory and
external comparisons
Section VI. Technical requirements
151
R2.17.8
M
Printing the results on the basis of approved legal acts for initial records . This
process includes, at least:
R2.17.8.1
M
Creating and editing templates, forms and logs
R2.17.8.2
M
Print the results in accordance with the approved (R2.18.10.1) and user’s forms
R2.17.8.3
M
Print the logs in accordance with the approved forms (R2.18.10.1)
R2.17.9
M
Input of laboratory reference values for all patients, by age and sex. This process
includes, at least:
R2.17.9.1
M
Input of reference values by age and sex
R2.17.9.2
M
Formation of the reference values of individual indicators based on statistical
processing of laboratory results
R2.17.9.3
M
Generating reports:
Laboratory reference values (by groups of patients and types of lab studies)
R2.17.10
M
R2.17.10.1 M
1. Management of initial registration documentation at laboratory level basing
on regulatory norms. This includes at least:
014/у, 027-3/у, 200/у, 201/у, 202/у, 204/у, 205/у, 206/у, 207/у, 208/у, 210/у,
211/у, 214/у, 215/у, 216/у, 216-1/у, 216-2/у, 217/у, 218/у, 219/у, 220/у, 221/у,
222-1/у, 223/у, 224/у, 227/у, 228/у, 230/у, 232/у, 233/у, 234/у, 235/у, 236/у,
237/у, 238/у, 239/у, 240/у, 240-4/у, 240-5/у, 240-6/у, 240-7/у, 240-8/у,
240-10/у, 240-11/у, 240-12/у, 241/у, 242/у, 244/у, 244-1/у, 244-2/у, 244-3/у,
245/у, 245-1/у, 248/у, 249/у,250/у, 252/у, 253/у, 253-1/у, 253-2/у, 254/у,
260/у,
251/у, 257/у, 259/у, 261/у, 262/у,280/у,
R2.17.11
M
Formation of analytical tables at the laboratory level, as well as statistical tables
in accordance with the legal regulations. This process includes, at least:
R2.17.11.1 M
Generating a report on completed analysis (Form 30)
R2.17.12
The ability to integrate the System with independent laboratory information
systems. This process presupposes compliance with required profiles of IHE
M
152
R2.17.13
Section VI. Technical Requirements
M
The transmission of information on completed research to EMR and EHR. This
process includes, at least:
R2.17.13.1 M
Transmission of data about laboratory tests performed and their results to EHR
in accordance with the standard requirements for EHR, approved by Order of the
Acting Minister of Health of 10.02.2014 № 75 "On approval of technical
documentation related to e-health"
R2.17.13.2 M
Transmission of laboratory tests performed and their results to the EMR in
accordance with the standard requirements for EMRs, approved by Order of the
Acting Minister of Health of 10.02.2014 № 75 "On approval of technical
documentation related to e-health"
R2.18
Module 18 «PACS» (Picture Archiving and Communication System)
R2.18.1
M
Data exchange with medical equipment. It includes at least:
R2.18.1.1
M
Data import pursuant to standard DICOM (sectoral standard for health image
creation, storage, transmission and visualization).
R2.18.1.2
M
Import directly from video outputs (if the necessary equipment is in place)
R2.18.2
M
Interaction with other modules and systems based on IHE profiles.
R2.18.3
M
Import / export of images. This process includes, at least:
R2.18.3.1
M
Supporting of at least DICOM, BMP, JPEG formats
R2.18.3.2
M
Support for at least DICOM Modality Worklist
R2.18.3.3
M
Ability to save images as attachments to CDA documents
R2.18.3.4
M
Supports scanning of paper and film images to produce an electronic archive
R2.18.3.5
M
Audit of imports and exports cases
R2.18.4
M
Working with images. This process includes, at least:
R2.18.4.1
M
Viewing single and series of images,
R2.18.4.2
M
Calling from the archive and the appearance of the image on the screen is not
later than 3-5 seconds after the request
Section VI. Technical requirements
153
R2.18.4.3
M
Identification of areas of interest in the image ,
R2.18.4.4
M
Overlay comments
R2.18.4.5
M
Image processing to improve the quality
R2.18.4.6
M
Quick search of patient data and images of the patient
R2.18.4.7
M
Interlinks between patient metadata and images
R2.18.4.8
M
Connection images with interpretation and diagnostic results
R2.18.4.9
M
Audit of Imagines View and Edit
R2.18.5
M
Maintain archive of images. This process includes, at least:
R2.18.5.1
M
The possibility of long-term storage of images
R2.18.5.2
M
Keeping the identity of the patient to avoid errors in assigning images to other
patients.
R2.18.5.3
M
The ability to integrate with other systems in health facility
R2.18.5.4
M
The ability to transmit image (if necessary) to other systems and to the national
EHR repository
R2.19
Module 19 «Diagnostic studies»
R2.19.1
M
View records on schedule of patients. This process includes, at least:
R2.19.1.1
M
View the schedule of patients
R2.19.1.2
M
Viewing of referrals to the diagnostic studies
R2.19.1.3
M
Getting a list of patients recorded to the study
R2.19.1.4
M
Cancellation or postponement of time of studies with indication of reasons for
the delay and stakeholders notification
R2.19.1.5
M
Reports generating:
1. Report on appointments
154
Section VI. Technical Requirements
2. Report on the canceled visits
3. Report on the services performed
4. Report on radiation doses for staff and patient
5. Report on priorities and term of waiting for diagnostic studies
6. Forming the list of patients in breakdown by rendered services by codes of
tarrificator
R2.19.2
M
Enter the results of research based on templates. This process includes, at least:
R2.19.2.1
M
Creating and editing templates for consultation, conclusions, results of research
R2.19.2.2
M
Filling of research results based on templates
R2.19.2.3
M
Search of previous patient conclusions
R2.19.2.4
M
Printing of research results according to approved forms
R2.19.2.5
M
Reports forming:
1. Report on services rendered (by equipment, executors, funding sources,
research types, referred divisions)
2. Report on radiation doses for staff and patient
3. List of patients in breakdown by rendered services by codes of tarrificator
R2.19.3
M
Management of initial registration documentation on diagnostic studies basing
on regulatory norms. This includes at least:
R2.19.3.1
M
001-4/у, 001-5/у, 028/у, 039-5/у, 039-7/у, 039-8/у, 050/у, 202/у, 203/у, 212/у,
213/у, 225/у, 226/у, 229/у, 231/у, 243/у, 243-1/у, 246/у, 247/у, 247-1/у, 2472/у, 247-3/у, 247-3/1/у ,247-3/2/у, 247-4/у, 247-5/у, 247-6/у, 247-7/у,
R2.19.3.2
M
Protocol for measuring individual doses (MOH order №902 as of 20.12.11)
R2.19.4
M
Formation of analytical tables for diagnostic tests, as well as statistical tables in
accordance with the legal regulations. The list of analytic and statistic forms
shall be agreed with the Client at the stage of System design
R2.19.5
M
The transmission of information on completed research to EHR and EMR. This
process includes, at least:
R2.19.5.1
M
Transmission of information on diagnostic tests performed and their results in
Section VI. Technical requirements
155
EHR in accordance with the standard for EHR approved by Order Acting
Minister of Health of 10.02.2014 № 75 "On approval of technical
documentation related to e-health "
R2.19.5.2
M
Transmission of information on diagnostic tests performed and their results in
the EMR in accordance with the standard requirements for EMRs , approved by
Order of the Acting Minister of Health of 10.02.2014 № 75 "On approval of
technical documentation related to e-health"
R2.19.5.3
M
Implementation of the exchange in accordance with IHE profiles
R2.20
Module 20 «Pharmacy»
R2.20.1
M
Record keeping for medicines at different levels: nurse’s station, office,
pharmacy warehouse (one or more), health facility. This process includes, at
least:
R2.20.1.1
M
Maintain full inventory control on one or more central warehouses
R2.20.1.2
M
Maintain full inventory control for each responsible person
R2.20.1.3
M
View stored remainings in each stock (by group of medicines, by
pharmacological and pharmacotoxic groups, on medicines, by supplier, by
department)
R2.20.1.4
M
Setting the number of minimum balances for each medication
R2.20.1.5
M
Establishing the baseline medication lists for each department
R2.20.1.6
M
Control over the implementation of minimum balances
R2.20.2
M
Automatic write-off of drugs when prescription is executed
R2.20.3
M
Ability to track expiration dates of medicines and medical devices.
R2.20.4
M
The possibility of forming a list of medicines (medical devices) required to
purchase in health facility.
R2.20.5
M
Formation of order to the pharmacy to get drugs (automatic urgent order if
medicine is in the treatment sheet but lack in the department, in case of reducing
the stock below the critical minimum). This includes at least:
156
Section VI. Technical Requirements
R2.20.6
M
Getting information about the presence of the drug in the departments. This
includes at least:
R2.20.7
M
Maintenance of the drug formulary of health facility. This process includes, at
least:
R2.20.7.1
M
Creation of the formulary of a health facility
R2.20.7.2
M
Adding medications into the formulary of a health facility with indication of
justification document
R2.20.7.3
M
Exclusion of drugs from formulary of a health facility with indication of
justification document
R2.20.8
M
Register of side effects of the drug. This process includes, at least:
R2.20.8.1
M
Forming of card-message (form №192-1/у by MOH order as of 3.11.2009,
№647)
R2.20.8.2
M
Register case in Log for revealed cases of side effect from drugs (Form №1923/у MOH order as of 03.11. 2009, № 647)
R2.20.8.3
M
Reports:
1.
Making up statistic reports on revealed cases of side effect from drugs
and lack of effectiveness of the drug in medical and pharmaceutical agency
(Form №192-4/у MOH order as of 03.11. 2009, №647)
R2.20.9
M
Monitoring of prescriptions of drugs. This process includes, at least:
R2.20.9.1
M
Viewing prescriptions of drugs in units of a health facility
R2.20.9.2
M
Sorting prescriptions by date, doctor, diagnosis, and other parameters
R2.20.9.3
M
View the links between diagnosis and drugs
R2.20.9.4
M
Enter the data about drugs, recommended clinical guidelines and protocols of
diagnosis and treatment
R2.20.9.5
M
Entering data on interaction of drugs to prevent joint prescription
R2.20.9.6
M
Comparison of prescriptions with the list in accordance with clinical protocols
and guidelines
Section VI. Technical requirements
157
R2.20.9.7
M
Sending messages with the recommendation to replace the drugs
R2.20.10
M
Setting maximum dosages for control purposes. This process includes, at least:
R2.20.10.1 M
Setting the maximum dosage in various forms (kg per body mass, single, daily,
etc.)
R2.20.10.2 M
Setting maximum dosages for different groups of patients with various age and
sex
R2.20.10.3 M
Setting maximum dosages for individual diseases
R2.20.10.4 M
Viewing applications for exceeding the specified maximum dosages
R2.20.10.5 M
Permission to exceed the specified maximum dosages with reasons
R2.20.11
Registration and execution of credit and debit invoices of hospital units and
pharmacies in accordance with the regulations. This process includes, at least:
M
R2.20.11.1 M
Create, edit, and check invoices
R2.20.11.2 M
Creating, editing and recording of credit and debit invoices
R2.20.11.3 M
Formation of requirements for medicines from senior nurses of a department,
including on the basis of registered prescriptions
R2.20.11.4 M
Making consignment statement for medicines and supplies according to the
requirements for the supply of medicines from senior nurses of departments
R2.20.11.5 M
Create, edit, and register the return of medicines from departments to the
warehouse
R2.20.11.6 M
Creating, editing and recording of orders to suppliers
R2.20.11.7 M
Creating, editing and recording of deferred credit and debit invoices to fulfill
orders for medicines
R2.20.12
M
Management of initial registration documentation on pharmacy level in
accordance with legal regulations.
R2.20.13
M
Formation of analytical tables at the pharmacy level, as well as statistic tables in
accordance with the legal regulations. The list of analytic and statistic forms
158
Section VI. Technical Requirements
shall be agreed with the Client at the stage of System design.
R2.20.14
M
Forming application for required medicines at the level of a department, outpatient clinic, hospital basing on served area
R2.20.15
M
Forming report on planning expenditures for medicines given the benefit
medicines
R2.20.16
M
Interaction with other Modules in case of need to exchange data on drugs
R2.21
Module 21 «Human Resources
R2.21.1
M
Communication with national indexes. It includes at least following indexes:
R2.21.1.1
M
“Register of Healthcare professionals”
R2.21.1.2
M
“Register of Health facilities”
R2.21.1.3
M
“Register of Addresses”
R2.21.1.4
M
“Health specialties”
R2.21.1.5
M
“List of positions (duties)”
R2.21.1.6
M
“List of medical services”
R2.21.2
M
Maintenance of organizational structure of health facility. It includes at least:
R2.21.2.1
M
Making up, editing, removal of units in health facilities (rooms, units,
departments, and etc. in line with organizational structure of facility)
R2.21.2.2
M
Maintenance of health facility staff schedule
R2.21.2.3
M
Making up statements for substitution of officials
R2.21.2.4
M
Linkages between rooms/ offices and specialists
R2.21.2.5
M
Linkage of units with the list of provided services
R2.21.3
M
Maintenance of doctors (health facility staff) registration card. It includes at
least:
Section VI. Technical requirements
R2.21.3.1
M
Employment of specialist
R2.21.3.2
M
Enter of following minimal information about the employee:
159
The history of labor relations, episodes of employment, personal information (ID
number , the number of the pension contract, marital status, family, place of
residence, place of registration, contact information, number of children, relation
to military service, the number of individual employment contract), information
about participation in hostilities, emergency response, disaster relief, promotion,
levy, knowledge of languages, information on social rewards, education,
professional certifications, trainings, academic degrees, science degrees.
R2.21.3.3
M
Registration of employees’ liability for damage
R2.21.3.4
M
Employment for the additional position
R2.21.3.5
M
Transfer to another position within the health facility
R2.21.3.6
M
Dismissal of an employee
R2.21.3.7
M
Management of Capacity building schedule
R2.21.3.8
M
View and print a list of employees selected according to certain criteria
R2.21.4
M
Keeping employees work mode. This process includes, at least:
R2.21.4.1
M
Planning and accounting of days off and vacations of employees
R2.21.4.2
M
Compilation of working regime given the weekends and holidays
R2.21.4.3
M
Accounting replacements and unscheduled absence
R2.21.4.4
M
Printing regime of work and schedule of vocations by individuals, rooms (health
service provision points), by departments, by facility
R2.21.4.5
M
Printing statement on actually period of work, vocation by individuals, rooms
(health service provision points), by departments, by facility
R2.21.5
M
Reference of services management. It includes, at least:
R2.21.5.1
M
Links with national index of services
160
Section VI. Technical Requirements
R2.21.5.2
M
Adding and removal of services out of facility service reference
R2.21.5.3
M
Service attaching to facility units
R2.21.5.4
M
Review and printing of list of services for each unit and facility
R2.21.6
M
Interaction with accounting IS (at list with «1C» software). It includes, at least:
R2.21.6.1
M
Data transfer on new specialists
R2.21.6.2
M
Data transfer on changed positions
R2.21.6.3
M
Data transfer on worked days (hours)
R2.21.6.4
M
Data exchange on vocations of specialists
R3
Requirements to System configuration
R3.1
Configuration to health facility needs
R3.1.1
М
Delivered system shall contain mandatory modules in its composition in
accordance with Table 1, depending on the type of health facility: Hospital,
Policlinic, Mixed type (Hospital+ Policlinic) (see also R1.17-R1.18)
R3.1.2
М
The System shall provide ability to control access to functionality based on roles.
The system shall allow to add / delete / edit the role and assign / cancel the right
of access to the system functionality
R3.1.3
М
The System shall have preset role in accordance with Table 3, with further
changes (adding new roles, edit or delete).
R3.1.4
М
Access rights to different modules and functions of the System shall be preinstalled in accordance with Table 4 with the ability to change access rights (add,
delete)
R3.1.5
М
Access right shall be configurable at least on the following aspects: all rights, to
create, to modify, to delete, to view
Table 3. System roles description
Section VI. Technical requirements
№
1.
Roles
Composer of schedules
Specialist is responsible for the formation of schedules of
services (counseling, equipment work).
Position: medical registration expert, senior nurse, head of
the department.
Specialist in outpatient registration unit in a health facility.
Performs the functions of reference as well as an
appointment to district doctors and profile specialists.
Receives and records the calls at home and transferred
active information.
Position: Nurse, medical registration expert.
Senior nurse
Specialist who coordinates nursing staff in department or
organization. Keeps track of spending medicines and
medical devices in department, draws requirements for
delivery of drugs and medical devices. May do functions of
nurse.
Position: Chief Nurse, senior nurse, Deputy Chief of
Nursing
3.
5.
Description
Medical receptionist
2.
4.
161
Head of policlinic department
District doctor
6.
Preventive department doctor
7.
Profile specialist
Specialist to coordinate the work of medical staff in the
department. Approves issuance of sheets of temporary
disability, involved into the work of MCB.
Position: Head of Department
PHC specialist. Manages EHR, provides professional care,
performs treatment and preventive measures as outpatients
in the clinic and at home. If necessary, creates a referral to
consultative and diagnostic care. Makes prescriptions for
free of charge drugs. Makes application for hospitalization.
Title: GPs, district therapist, district pediatrician
Preventive department doctor for targeted screening of
population, professional exams and other preventive
examinations. If necessary, creates a referral to consultative
and diagnostic care. Profile specialist can be both
therapeutic (GPs) and specialized.
Position: doctor in preventive unit, ophthalmologist,
otolaryngologist , gynecologist, therapist, urologist,
psychiatrist, dermatovenerologist, pathologist, surgeon, etc.
Profile specialist provides specialized care on outpatient
162
Section VI. Technical Requirements
level. Oversees dispensary treatment groups (target groups
of patients). If necessary, creates referrals to consultative
and diagnostic care.
Position: ophthalmologist, otolaryngologist , gynecologist,
therapist,
urologist, psychiatrist, dermatovenerologist,
pathologist, surgeon, etc.
8.
9.
10.
11.
12.
Health facility administrator
(chief doctor)
Medical statistic specialist in
policlinic
District doctor’s nurse
Preventive department nurse
Nurse of specialist
The first head of the organization. Takes management
decisions, determines policy of organization. Manages
personnel structure. Has the right to sign financial
documents
Position: Chief Doctor, General Director, Chairman of the
Board
Medical statistic specialist. Collecting, processing and
analysis of statistical data on the basis of primary records.
Generates accounting documents for submission to
authorities.
Position: Medical statistics, assistant medical statistics,
deputy chief physician for organizational and
methodological work, manager of organizational and
methodical department.
Specialist performing treatment and preventive measures to
population attached to the district under supervision of
district doctor
Position: nurse, paramedic
Specialist performing preventive measures to population
attached to the district under supervision of preventive
department doctor or profile doctor.
Position: nurse, paramedic
Specialist performing preventive measures to population
attached to the district under supervision of profile doctor.
Position: nurse, paramedic, obstetrician
13.
Doctor at admission’s
Specialist performs patient hospitalization into hospitals.
Produces hospitalization procedure and rejection in it.
Produces primary clinical examination and establishes
disease history.
Position: doctor, Head of Department
14.
Nurse at admission’s
Specialist helping in patient hospitalization, acts under
admission doctor governance.
Position: nurse, chief nurse
Section VI. Technical requirements
15.
Head of Hospital department
16.
Medical statistic specialist in
hospital
17.
Hospital doctor
18.
Hospital nurse
19.
Specialist in feeding department
20.
Admin
21.
Lab specialist’ assistant
22.
Lab specialist
23.
Laboratory Doctor
24.
Diagnostic department doctor
163
Specialist who coordinates work of medical staff in
department. Approves lists of temporary disability, takes
part in medical consultations.
Position: Head of Department
Specialist in medical statistics. Collecting, processing and
analysis of statistical data on the basis of primary records.
Generates accounting documents for submission to the
authorities.
Position: Medical statistics, assistant medical statistics,
deputy chief doctor for organizational and methodological
work, head of organizational and methodical office.
Specialist for provision of secondary and tertiary care in
hospital. If necessary, creates a referral to consultative and
diagnostic assistance in the hospital. Prepares documents
for hospitalization (disease history, form 066/y, discharge
summary)
Position: therapist, pediatrician, ophthalmologist,
gynecologist, internist, urologist, psychiatrist, skin and
venereal diseases, pathologist, surgeon, etc.
Specialist that performs prescription and direct care for the
patient.
Position: nurse in the medical point, nurse in treatment
room , nurse of specialist, senior nurse, chief nurse,
obstetrician
Specialist for estimation and preparing meals for patients.
Position: nutritionist, a nurse of nutritionist, cook
Specialist provides technical support for the system and its
configuration.
Position: Information Systems Specialist, Systems
Administrator, Programmer
Specialist performs laboratory tests under the supervision of
laboratory specialist or laboratory doctor
Position: laboratory technician, laboratory paramedic
Specialist performs laboratory tests under the supervision of
laboratory doctor
Position: Laboratory Specialist, paramedic
Specialist performing laboratory tests and control over their
reliability and quality.
Position: Laboratory Doctor
Specialist performs diagnostic tests according to doctors
referrals.
Position: radiologist, doctor of functional diagnostics,
ultrasound doctor
164
Section VI. Technical Requirements
25.
Pharmacist
26.
Chief Pharmacist
27.
Clinical pharmacologist
28.
1.1.4
HR specialist
Specialist in production, storage and sale of drugs working
under the supervision of chief pharmacist.
Position: pharmacist
Specialist in production, storage and sale of drugs.
Position: chief pharmacist
Specialist to assess the impact of drugs on the body of sick
person. Advises doctors about prescribing and adjusting
treatments.
Position: clinical pharmacologist
Specialist in registration of labor relations, personnel
records and their data
Position: Head of HR department, HR Specialist
Legal background
Minimal package of legal documents to be followed herein:
1)
Law of the RK «On national Security of the RK» № 527-IV as of January
(http://online.zakon.kz/Document/?doc_id=31106860);
6, 2012
2)
Decree of the President of the RK as of November 14, 2011, № 174 " On Concept of national
Security of the RK till 2016» (http://ru.government.kz/docs/u110000017420111114.htm);
3)
Code of the RK N 193-IV as of 18.09.2009 “On Health of population and Healthcare
system”;
4)
Law of the RK “on personal data and their protection” N 94-V as of 21 May
(http://online.zakon.kz/Document/?doc_id=31396226);
2013
5)
MOH RK order as of 23.11.2010, № 907 «On approval of forms of initial medical
documentation for health facilities»
6)
MOH RK order №75 as of 10.02.2014 г «On approval of technical documentation in ehealth». (https://www.mzsr.gov.kz/node/319759)
1.2
Requirements to functional features of the System
1.2.2. Non-functional requirements
1.2.2.1. Requirements to System feedback
Section VI. Technical requirements
165
The table below contains a list of functional requirements for system performance, which shall be
followed by delivered systems and related systems / services
Type Requirement
M
Patient search by name or IIN and patient-related data (results of the survey,
the results of laboratory tests, etc.) shall take no more than 3-5 seconds for
80% of cases
М
Potential Supplier during warranty period shall ensure the functioning of the
following options:
R4.2.1
М
The total downtime of System for the reason related to its operability shall
not exceed 24 hours per year.
R4.2.2
М
Onetime of System downtime for the reason related to its operability shall
not exceed 2 hours.
R4.2
1.2.2.2.
R5
Requirements to Informational Security
Requirements to Informational Security
R5.1.
M
Security requirements are defined by current legislation of the Republic of
Kazakhstan. The system shall meet requirements of information security to
ensure access threshold, protection from unauthorized access, etc.
R5.2.
M
The system shall provide protection of information from unauthorized
access, namely:
R5.3.
M
User authentication based on checking the name (login) and password
R5.4.
M
Ability to identify user based on digital certificates of open key
infrastructure
R5.5.
M
User authorization for access to system information and computing
resources requiring appropriate permissions
R5.6.
M
Personalized definition of the rights of users to input , corrections , viewing
of data
166
Section VI. Technical Requirements
R5.7.
M
Personalized definition of the rights of users to access system resources
R5.8.
M
Differentiation of system user rights by roles, groups and access levels
based on hierarchy of objects and attachment to organizational structure.
R5.9.
M
Logging of users work with system critical features and applications
R5.10.
M
Protect the system files from modification / damage by unauthorized users
and software processes
R5.11.
M
Control log shall be maintained of all updates of the system software
libraries
R5.12.
M
The system shall implement at least the following backup:
- Automatic backup with option to plan it
- Remote control over backup making
- Full and partial backups
R5.13.
M
The system shall ensure data integrity.
R5.14.
M
The system shall provide tools for encrypting sensitive data during storage
and during transmission to other systems.
R5.15.
M
Digital signature (registration certificate of user by National Authorizing
Center of the RK) shall be issued by NAC RK. The system shall provide
the tools for digitally signing of documents (objects) or portions of
documents, when / if it is needed, and the tools for authenticating
signatures. This feature shall be implemented in system services (if
necessary). To ensure confirmation of digital signature authenticity and
validity of opened key of digital signature, the System shall provide check
for e-signature authenticity using services of NAC RK
(http://pki.gov.kz/index.php/ru/).
R5.16.
M
System shall comply with the principle of "single access point" - the
architecture of the information infrastructure allows to have a common
access point (technology Single Sign On) to all its components and
resources that allows you to enter the username and password once and
gain access to all system components without re-entering the password.
R5.17.
M
The System shall provide authorization of users in the system, distinction
between the rights of users of the system by roles, groups and access levels
Section VI. Technical requirements
167
based on hierarchy of objects and accessories to organizational structure.
R5.18.
M
In accordance with legal and technical documentation for information
security, approved by the MHSD RK the following shall be implemented:
- The length of the password shall be at least 8 characters, numbers and
letters shall be present in upper and lower case;
- Forced password change function;
- Barring use as a password of "empty" password;
- password change independently by user;
- If wrong password is entered more than three times CAPTCHA method
shall be implemented;
- Journal of logging activities of all users for viewing the history of
changes of main event of the System;
- Function of interrupting session when inactive after N period of time
1.2.2.3.
N
Type
R6
Requirements to System quality attributes
Requirement
Requirements to System quality attributes
R6.1.
M
The system shall support input, transmitting and receiving data necessary
for operation of MHSD information systems used by the health facility and
eliminating the needs to re-enter data.
R6.2.
M
The system shall ensure preservation of all accumulated information at the
time of the refusal or failure in case of failure of any component of the
system, regardless of its destination, with recovery of data after repair and
restoration works
R6.3.
M
The system shall have flexibility to change settings in external environment
and specific user tasks without replacing modules.
R6.4.
M
The system shall be highly scalable and allow to work in an unlimited
number of users. Constraints can be driven only by technical characteristics
of the equipment, not by characteristics of System
R6.5.
M
All functional capabilities of the system shall be designed in the form of
services.
168
Section VI. Technical Requirements
R6.6.
M
Web services of the System shall be designed in accordance with SOA
architecture.
R6.7.
М
When implementing services interaction it is necessarily stick to the
standard of MHSD RK concerning information systems interaction
R6.8.
M
The system shall enable construction of templates for approved medical
forms available within the solution itself, which can be automated without
programming or changes of the program code.
R6.9.
M
The system shall be capable of resolving conflicts when parallel processing
system objects.
R6.10.
M
Requirements for user interfaces
R6.10.1
M
The interface shall be designed for the preferential use of manipulator
"mouse" , i.e., the system control shall be carried out using a set of onscreen menu, buttons, icons and similar items
R6.10.2
M
Keyboard input mode shall be used primarily during filling and / or editing
text and numeric fields screen forms. It shall also provide hotkeys to switch
between filled files.
R6.10.3
M
Ergonomic solutions and interface design as much as possible shall be
uniform for all system components and modules
R6.10.4
M
User interface systems shall be multilingual and organized with the support
of at least state (Kazakh) and Russian languages. Exceptions can only be
system messages not localized or standard administrative applications that
make up the system software
R6.10.5
M
Access to electronic operational documentation shall be available
R6.10.6
M
The context- sensitive help system shall be implemented in the System,
accessible from any web application, where links shall be submitted to
information (user manual , instructions , etc.), with possibility of
configuration without involvement of potential suppliers at the Purchaser
level;
R6.10.7
M
The UI system shall provide visual selection of screen attributes which are
available to the operator as read-only
Section VI. Technical requirements
169
R6.10.8
M
The UI system shall provide visual selection of screen attributes which are
mandatory for filling in
R6.10.9
M
The system shall ensure correct handling of emergencies caused by
incorrect user actions, incorrect format or invalid values input. In these
cases the system shall give the user a relevant message, and then return to
the operating state prior to incorrect (invalid) command or data entry
R6.10.10 M
System shall not allow duplication and repeated (incorrect) input of
homogeneous information. The system should ensure elimination of
duplication and re-enter the information contained in public databases and
information systems of state bodies
R6.10.11 M
The system shall provide the format-logical control of input data for all
values in the system. Format logical control of entered data means control
over format and content of entered data. The System shall provide
protection against erroneous actions:
- Choose only available to the user (in accordance with permissions)
functions;
- Enter only available to the user (in accordance with permissions) data
values;
- Input only certain format (eg, inability to input character data in the format
field "Date" or "Number").
1.3
№
Requirements to System interoperability
Type Requirement
R7
Requirements to System interoperability
R7.1.
General Requirements to System interoperability
R7.1.1
M
System solutions and application shall meet standards of interoperability,
including national standards and accepted international standards listed in
this chapter (and in this document).
R7.1.2
M
System components must conform to the national instruments of
semantics:
o References and classifiers
o Requirements for reference services
170
Section VI. Technical Requirements
o Requirements for registers and registers services
o Requirements for resource management and accounting
Details on the requirements for these instruments are given later in this
section (R7.3).
R7.1.3
I
R7.2.
R7.2.1
Some of interoperability tools, described below, are in the process of
development and the latest versions are available on request to potential
suppliers. Basic standards are listed on the MHSD site (Order №75 as of
10.02.2014 https://www.mzsr.gov.kz/node/319759
Compliance with standards
M
System components shall be compatible at least with the following
standards of MHSD RK:
1) Standard requirements for the electronic health record (requiring
compliance with EN 13940 )
2) Standard requirements for electronic medical records (requiring
compliance with EN 13940 )
3) Standard requirements for identification of stakeholders of health
systems used in e-health systems
4) Technical requirements for the interaction (communication) with the
information systems of e-health
5) Regulation on information
6) Standard requirements for single classifier of medicines, medical
devices and medical equipment
7) Standard requirements for implementation and management of
electronic directions
8) Regulation of interaction of stakeholders in order to ensure
interoperability of information systems and information management
9) Standard for regulation of e-receipts management
10) Standard for management of e-processes of diagnostic studies and
cure procedures
11) Standard for regulation of e-preventing of diseases
These
standards
and
regulations
https://www.mzsr.gov.kz/taxonomy/term/619
R7.2.2
M
are
available
on
System components shall be compatible with following international
Section VI. Technical requirements
171
standards:
a. EN 13940(regarding the need to comply with EHR and
EMR)
b. HL7 v3 (ISO/HL7 27831), HL7 (v2 or V3 or FHIR);
c. HL7 CDA R2 (ISO/ HL7 27932)
d.
R7.2.3
M
DICOM
the System shall meet the requirements of standards on Information
Security:
- ST RK ISO /IEC 27001-2008 «Security assurance methods and means
for Information Security Management System. Requirements»;
- ST RK ISO /IEC 27002-2009 «Information Technology. Support means,
Code of rules on information protection management».
R7.3.
R7.3.1
Requirements for compatibility with national standard identifiers
and classifiers / references
M
System components shall support and comply with the national
identifiers:
- Patient Identifier
- Identifier of health facilities
- Identifier of health specialists
- Identifier of medical equipment
R7.3.2
M
System components shall support and comply with at least the following
national classifiers and references:
1) The National Classification of medicines and medical supplies
(mapped to the ATC-DDD)
2) Classification of health services (based on ICD-9, a section on services
and manipulations)
3) Classification of laboratory results
4) Classification of services and their costs
5) Classification of diagnoses (ICD- 10)
6) Classification of primary care (ICPC- 2)
7) Mapping of ICPC- 2 and ICD-10
8 ) SNOMED, (only for the purpose of coding the connection between the
System and EHR Repository)
172
Section VI. Technical Requirements
9) Improved classification system must be determined at a later stage to
control diagnostic services;
10) Realized by MHSD national DRG system for classifying patients (for
specialized care);
11) Classification of registers of target groups of patients (dispensary
group)
12) care tarrificator;
13) Specialties in healthcare
14) List of positions.
R7.4.
R7.4.1
Requirements to compatibility / correspondence of data
M
System components shall provide a link between systems and National
Health Information and Interoperability Platform containing Repository
EHR based on the following data:
- The minimum data set for EHR (set in National Standards for EHR and
EMR)
- Other data not covered by semantic standards, but necessary under the
normative legal acts of the MHSD, such as Attached Special Records
(documents based on CDA)
R7.4.2
M
The system shall provide access to data stored in the EHR repository,
according to two types of EHR: Full EHR, short EHR. Details are
described in National Standard for EHR.
R7.4.3
M
Data is transferred between the system and Repository EHR in CDA
format
R7.4.4
M
Information transmitted in the EHR repository is organized on the basis of
ICPC- 2 codes that are used in encounters (and contacts in general) and
mapped to the ICD-10 for the purpose of statistics collecting. In EMR
information systems (except EHR/ PHC systems) professionals use ICD10 for diagnosis coding and mapping in the reverse direction is not
required, but desirable.
R7.4.5
I
Systems may have additional databases and repositories needed for full
implementation of functionality (called EMRs in MHSD context), but
they are kept separately from EHR repository database. EHR Repository
content shall strictly regulate the national standard for EHR .
R7.4.6
M
The system shall be opened enough to be able to provide interoperability
with existing IS, applications and services of IS MHSD (see also Section
Section VI. Technical requirements
173
1.4.2).
R7.5.
Requirements to information exchange
R7.5.1
M
The system shall interact with national system of EHR according to
National standards for EHR and EMR
R7.5.2
M
The system shall support (at least) interaction with the following sets of
services of e-health:
- Services of EHR Repository;
- Services of reference information;
- Services of registration and registers;
- Services of Clinical Nomenclature and classification of data;
- Services of safe exchange of data and messaging;
- Services of identification and authentication;
- Services for the monitoring and auditing of information exchange.
R7.5.3
M
The system shall correspond to at least following profiles of IHE
a) Infrastructural profiles of IHE:
- ATNA;
- XDS.b;
- PDQ;
- PIX;
b) lab profiles of IHE:
- LBL;
- LWT.
R7.5.4
M
The system should provide opportunities for interaction / integration with
at least the following protocols and specifications:
- Communication via SOAP (SOAP message and application), REST,
Message Transmission Optimization Mechanism;
- Support for standards and specifications of Web services (WS-Security,
WS-Addressing, WS-Reliable Messaging, WS-coordination, WSTransaction, WS-Secure Conversation);
- meet the standards of XML (XML, XSL, ebXML, and others.);
- maintain SSO and access control across the SAML v2, JWT;
174
Section VI. Technical Requirements
- supports common standards such as HTTP, HTTPS, TCP / IP, the
protocols Secure Sockets Layer (SSL v3) and TLS;
- allowing the use of WSDL, WADL;
- X.509;
- The digital signature (of NAC RK)
R7.5.5
M
the system shall support coding of at least UTF8
R7.5.6
M
The system shall interact with the Platform services at channel speed of 1
Mb / s and the response time less than 100 ms
R7.5.7
M
The system shall interact with Platform services in terms of:
- transmit / receive notifications and other information of informative
character on the gateway of "electronic government";
- sending of SMS-notifications, and other types of distribution via SMS
gateway of system of mobile government;
- sending emails to patients through a single e-mail system;
- information about the powers of attorney out of the state information
system Single Notary Information System;
- obtain information from the records to the doctor;
- obtain minimal information about the employee
M
R7.5.8
Information on main HIS is set in Annex 3
1.4
Associated information on technology of some issues
1.4.1 Use of national e-health resources and HII Platform tools
The System shall be able to use national resources and published services of Kazakhstan ehealth
№
Type Requirement
R8
Use of national e-health resources and HII Platform tools
R8.1.
M
System shall be able to operate in line with general e-health architecture (Pic
2)
R8.2.
M
The system shall be able to use functionality and web services, published at
the national level to communicate with e- Health resources
R8.3.
M
The system shall be able to use EHR repository, national classifications and
indexes (at least, Master Patient index, index of health facility units,
healthcare professional index, index of buildings, address index, index of
Section VI. Technical requirements
175
motor vehicles, medical equipment index), analytical repository and other
national resources required for integration of " turn-key " according to
national standards (listed in MoH order No. 75 from 10.02.2014)
R8.4.
M
The system shall maintain local copies of national resources and be able to
synchronize them on a regular basis (in accordance with a custom schedule)
or online. The system shall contain only information relating to the activities
of health facility. For example, Master patient index shall be kept locally for
only the list of patients served by this health facility.
1.4.2
№
Interaction with parties involved into certification process
type
R9
Requirement
Interaction with parties involved into certification process
R9.1.
I
Contract associated with the delivery of HII Platforms and national e-Health
resources is held in parallel with this contract. Access to national e-Health
resources will be provided to the System Supplier only after successful
implementation of HII Platform Contract. In order to facilitate parallel
implementation it is necessary to synchronize / coordinate joint actions. The
interaction of the parties involved is shown in Pic. 3. Actions taken by the
Supplier are described in column 4 «Private IT company»
R9.2.
M
System Supplier shall interact with the HII platform supplier, health facility
and MHSD for testing and certification of interoperability with national
resources and services.
R9.3.
M
System supplier shall coordinate the interaction of the parties involved in
accordance with Figure 3. Certification means to verify the installed system
for compliance with R7.2. The Client authorizes a special commission, which
together with the Platform provider and the supplier of the system, shall
conduct tests on compliance to standards of MHSD RK, to meet the
requirements of interoperability in accordance with national standards,
including the ability of correct interaction of delivered system with national
resources available within the Platform.
R9.4.
M
At the phase of System design (action 4.4) the Supplier shall comply with the
"Rules for Web Services development" and "Requirements for interaction with
the EHR Repository" provided by the Supplier of the HII Platform. Supplier of
System may request additional information if necessary to develop interaction
with e-Health resources.
R9.5.
M
During the testing / certification phase (action 4.6) System Supplier shall meet
requirements and standards of e-health R7.2.
176
Section VI. Technical Requirements
R9.6.
M
The Supplier shall certify the System before its acceptance into operation
R9.7.
M
In case of circumstances that hinder fulfillment of R9.6 occurred by no fault
from Supplier’s party, Acts of System acceptance shall be signed without
certification. With it, System Supplier is bounded to certify the System when
conditions for certifications appear, without any additional costs from the
Purchaser’s party
Section VI. Technical requirements
177
Pic 3. Interaction of parties involved into System implementation and certification
1.5. Requirements to Suppliers
N
type
Requirement
178
Section VI. Technical Requirements
R10
Requirements to Suppliers
R10.1. M
Supplier shall supply his own System (components or products of its) or be
authorized by the developer / owner of the System (components or products
of its) to provide, design, installation, maintenance of production in
accordance with this Contract.
R10.2. M
Supplier shall provide training in Purchaser’s country, associated with the
operation and administration of the system, as well as for all developed and
installed products. Language of trainings will be the state and Russian.
Details on training given in R12.2
R10.3. M
Supplier shall have an office in the Purchaser's country or have a partner
that is registered as a legal entity in the Purchaser's country having official
status of a developer / provider partner, or having a consortium agreement
associated with this Contract. This is necessary during the implementation,
deployment, training, and warranty period for smooth and reliable
implementation of the Contract.
R10.4. M
Supplier shall have team of experts for the Project, consisting of at least the
following specialists (if necessary, two positions can be taken by one
person, provided that the skills will be proved, but no more than 2 positions
per a specialist):
1) Business Analyst with experience of at least 3 years in IT projects in ehealth and experience in at least one similar project;
2) Project manager (team leader), with experience of at least 3 years in
project management and experience of more than 1 year in the project,
where the proposed solution has been implemented, Project manager shall
be certified in project management (eg, PMP or IPMI);
3) Specialist on DBMS who has at least 3 years of experience with database
work;
4) professionals with experience in work with standards for at least 2 years:
HL7, DICOM, CDA (R2), IHE;
5) User Interface Designer, with experience of at least 3 years;
6) Technical writer, who has worked for at least 2 years;
7) Specialist on Relations with experience in this area and at least 3 years of
general experience in IT, with an excellent command of English, Russian
and Kazakh languages;
8) Specialist on Testing with at least 3 years of experience in software
testing;
9) Specialist on Training with at least 3 years of experience in education;
All proposed experts shall have a degree in IT or related fields, Master's
degree preferred. The Supplier shall submit a list of experts, with applied
Section VI. Technical requirements
179
resumes, certificates to prove the experience and qualifications.
R10.5. M
the Supplier shall provide all documents (patents, licenses, certificate of
state registration of rights to the object of copyright, etc.) on the System (for
all components and products), demonstrating the owner's permission to use
the products for the contract or demonstrate ownership of the products
R10.6. M
Plan - schedule of services shall be authorized by the Purchaser and signed
by the Purchaser within twenty (20) business days after signing the
contract. Supplier shall promptly provide services by approved schedule.
R10.7. M
In the case of foreign companies participation, consortium is the most likely
appropriate form of participation in the tender (although not mandatory),
because some of the requirements involve knowledge and skills that
international suppliers may not have – experience of work in the country.
R10.8. M
Vendors shall have at least on certificate out of the following list:
Capability Maturity Model Integration (CMMI), ISO 9000 series, ST RK
ISO 9001: 2009 or equivalent for quality management (Bidder shall submit
copies of Certificate on compliance issued by the authorized body).
R10.9. M
The Supplier shall provide service and technical support and warranty,
including new versions of the products in accordance with the R12.3 and
R12.4.
R10.10. M
The Supplier shall prepare appropriate guidance for all components of the
System in English, Kazakh and Russian languages
R10.11. M
The Supplier shall have proven track record of working with the standards
used in this document: HL7 (v2, V3, FHIR), CDA (R2), IHE
R10.12. I
The contract related to supply HII Platform is carried out in parallel with
the present contract
R10.13. M
System Supplier shall have access to national resources of e-Health only
after the parallel contract is successfully implemented. In order to facilitate
parallel implementation it is necessary to synchronize / coordinate joint
actions with the Platform provider. If the circumstances do not allow to
meet the requirements for interaction with the Platform due to delayed
implementation of contract for delivery of Platform, the System Supplier
undertakes to implement the interaction, when there will be conditions,
without additional cost to the Purchaser.
C. Technical specification
180
Section VI. Technical Requirements
2.1. GENERAL TECHNICAL SPECIFICATIONS TO THE SYSTEM
N
Type
Requirement
GENERAL TECHNICAL SPECIFICATIONS TO THE SYSTEM
R11
R11.1.
M
System shall be able to work with a local server via a local area network
used in one health facility
R11.2.
M
The server part of System shall be running at least on Windows operating
systems family.
R11.3.
M
The client part of the System shall be running at least in the operating
systems of Windows (2008/VISTA/7/8) (x86/x64)
R11.4.
M
A relational database shall be used to save the information in the system
R11.5.
M
Database systems shall support the standard SQL, compliant with the ANSI
/ ISO / IEC 9075-1992
R11.6.
M
Supplier shall provide service and technical support, including provision of
new product releases prior to the expiration of warranty service.
R11.7.
M
The system shall provide the ability to operate on a remote infrastructure
and cloud (virtualized) Operating Environment
R11.8.
M
The System shall provide an option of authentication using SSO technology
2.2 SERVICE SPECIFICATION
R12
Specification of services
R12.1.
Requirements to inherit data and functionality.
R12.1.1
M
In the case of supply and implementation of the System different from
those operating by the Purchaser the Supplier provides a full range of
necessary work on the inheritance of data and functions of the
Information System modules used by the Purchaser with connection to
the System of used by the Purchaser software and hardware means of
automatization, medical and laboratory equipment.
R12.1.2
M
All costs associated with providing inheritance of data and functionality
are paid by Supplier.
R12.2.
Trainings and training materials
Section VI. Technical requirements
R12.2.1
M
181
the Supplier shall prepare a training plan for the following groups:
a) System users;
b) System admins
c) developers,
d) admins of databases.
Training plan and training materials for each group shall be agreed with
the Purchaser prior to the training start.
The Supplier shall provide equipment, presentation materials, and
guidelines needed for training
R12.2.2
M
R12.2.3
M
System Supplier shall provide educational materials in the form of
manuals, books, presentations, knowledge bases in the Kazakh and
Russian languages.
R12.2.4
M
Supplier shall provide training for at least 80 hours for each group of
admins of the System, developers, admins of database and 20 hours for
users of each health facility, which implements systems. The number of
hours can be increased and shall be sufficient for the transfer of
knowledge and skills
R12.2.5
M
Supplier shall conduct a separate training for users and system
administrators, developers and admins of databases. Indicative number
of students is determined by multiplying the total number by 2 of
general number of workstations from Appendix 2. Location of training legal address of the healthcare facility - the beneficiary. Groups of
students should include no more than 10 people
R12.2.6
M
Training plan for the group (a) - users of the system - shall contain a
detailed explanation of automated business processes, the use of all
components of the system, a detailed description of the functions and
interactions between the different users and roles; statements and other
necessary information. Training will also include practical training for
understanding of the material.
R12.2.7
M
Training plan for the group (b) - System administrators - shall contain
description of administration tools of system components including the
important issues of systems support, and aspects of technical support
R12.2.8
M
The Supplier shall conduct for the group (c) designers – one
introductory course and capacity building course on provided tools of
development and components planned as part of this contract
R12.2.9
M
The Supplier shall conduct for the group (d) DB admins - one
introductory and one advanced training course on provided DBMS
R12.2.10
M
Training for groups (a) - (d) shall be conducted in Russian or state
language specified by the Purchaser.
R12.2.11
M
All trainings shall be conducted by trainers in Astana or in another place
specified by the Purchaser
182
Section VI. Technical Requirements
R12.2.12
M
For all carried out training sessions, the Supplier shall conduct the
appropriate tests and issue certificates
R12.2.13
I
The above number and duration of training are minimum requirements.
Supplier at the request of the Purchaser can increase these values (in
hours) to achieve an adequate level of skills for the staff at no additional
cost to the Purchaser. During the preparation phase of the project the
exact number of hours, groups and content of the courses will be agreed
with the Supplier.
R12.3.
User Support Service
R12.3.1
M
Supplier shall arrange a user support service to advise on matters arising
during the operation, for the duration of implementation and warranty
services providing
R12.3.2
M
Support System and its users should be carried out by the Supplier in
operation regime of 24 hours a day, 7 days a week, for 2 years from the
date of signing the acts system commissioning
R12.4.
Warranty service
R12.4.1
M
Supplier of the System shall provide warranty service to the Purchaser
within three years, starting immediately after approval of the
Operational Acceptance Certificate by Purchaser
R12.4.2
M
R12.4.3
M
The Supplier shall provide the resolution of queries:
a) for the critical issues relating to operability of systems and leading to
data corruption, the problem should be solved by no more than 2 hours;
b) for non-critical problems to 2 days
Warranty service will include, but not limited to, following categories of
services:
- correction of errors in the System;
- help the health facility to correctly all problems with data, arising as
result of mistaken function of applications;
- technical support in adjustment, configuration of applications or
changing default parameters;
- provide necessary technical assistance to trained staff and re-train, if
disclosed that they cannot solve all problems after received training
R12.4.4
R12.4.5
M
M
The forms of intervention can be one of the following most appropriate
from the viewpoint of quality and efficiency:
- telephone calls;
- e-mail;
- Skype or other video messenger;
- On-site work;
- Remote work.
The Supplier shall provide during the warranty period a team of
Section VI. Technical requirements
183
consultants available in Purchaser’s country including one manager and
at least one specialist, and provide all necessary specialists from the
distance for remote help (per needs).
R12.4.6
M
The total System downtime due to reasons related to its capacity for
work should not exceed 24 hours per year.
R12.4.7
M
Time of a single system downtime due to reasons related to its capacity
for work should not exceed 2:00
2.3. Requirements to documentation
N
Type
R13
R13.1
Requirement
Requirements to documentation
M
The Supplier shall provide the following documents :
- Program and methods of testing ;
- Form (main characteristics, completeness and information on the
operation of the deposited software);
- Description of the most common mistakes and how to prevent them;
- Description of the structure of the database;
- Guide to install the software;
- Administrator's Guide;
- User’s Guide.
R13.2
M
Language of the document shall be at least the Kazakh and Russian.
R13.3
M
The Supplier shall provide 5 sets of documents in paper and electronic
form in English, Russian and Kazakh languages.
Electronic versions should support the ability to search basing on context
R13.4
M
the Supplier shall prepare an information system and regulatory and
methodological documentation for attestation for compliance with
information security requirements in accordance with Article 5 of the Law
of the Republic of Kazakhstan dated January 11, 2007 "On
Informatization" and Decree of the Government of the Republic of
Kazakhstan dated December 30, 2009 № 2280 "On approval of Rules for
provision of certification of government information systems and nongovernment information systems integrated with public information
systems for compliance with information security requirements and
accepted on the territory of the Republic of Kazakhstan standards "and to
be commissioned in accordance with Article 17 of the Law of the Republic
of Kazakhstan dated January 11, 2007" On informatization ".
184
Section VI. Technical Requirements
D. Testing and requirements to quality
3.1. System testing and Requirements to Quality
R14
System testing and Requirements to Quality
R14.1.
Pre-commissioning
R14.1.1 M
System Supplier shall perform standard installation tests to verify the
correctness of System installation
R14.1.2 M
Supplier shall offer in the technical offers a list of tests, test conditions,
success criteria and other for the System testing.
R14.1.3 I
Quality of testing is one of the criteria for technical evaluation. The list of
tests will include tests for each module and tests for the whole System.
R14.1.4 M
Systems Supplier shall held detailed milestone tests, including tests of
performance, response time, System throughput, together with an
organization authorized by the Purchaser, according to tests provided by the
Supplier.
R14.1.5 М
The supplier shall hold a demonstration of the System with the participation
of representatives of the Purchaser and the organization authorized by the
Purchaser according to the scenario of System testing.
R14.1.6 М
Suppliers shall draw up the demonstration results in the form of
demonstrations Protocol agreed with the Purchaser. The protocol shall be
signed by all participants of demonstration.
Place of demonstration shall be agreed with the Purchaser and organization
authorized by the Purchaser.
R14.1.7 М
The Supplier shall fix a troubles detected during the demonstration and
repeat demonstration as often as needed to have a Protocol of successful
demonstration.
Timeframe for fixing the troubles shall be agreed with Purchaser.
R14.1.8 M
Testing shall be conducted in accordance with one of the standards IEEE
829/1009, BS 7925, ISO / AS 9100 and developed document "Program and
methods of testing" ST RK 1089-2002
R14.1.9 M
The supplier shall test the system in accordance with the Web Content
Accessibility Guidelines (WCAG) 2.0. the Supplier shall provide detailed
information on the results of testing
R14.1.10 M
The Supplier shall test the system security in accordance with the OWASP
Top 10 vulnerabilities. Supplier shall provide detailed information on the
results of testing
R14.1.11 M
the Supplier shall agree with the Purchaser the test script and provide a
Section VI. Technical requirements
185
report on the results of each test
R14.2.
Acceptance into operation
R14.2.1 M
Certificate of acceptance is signed by the Purchaser based on the trouble-free
operation under normal operating conditions for the System within three
months. In case of errors in the functioning of the period Supplier shall make
the necessary changes and re- operation of the system within three months.
Operating errors are critical errors which do not allow to run the System
R14.2.2 M
The Supplier must commence the work necessary to remedy defects or
damage within 10 working days for non-critical errors. For critical errors the
supplier must commence the work necessary to remedy defects or damage
within 3 working days, provide fixing time and report on fixing progress
hourly during the operational as well as warranty period.
Critical errors: System is not operational or stable. Important functional
component is down or un-available. Loss of Data or interruption in the main
process flow. System component unusable due to failure or incorrect
functionality. Users are not able to perform any work.
R14.2.3 M
Mandatory condition for acceptance into operation is certification of the
System pursuant to requirements of R.9
3.2. REQUIREMENTS TO CONTROL BY PURCHASER
R15
Requirements to control assurance by the Purchaser
R15.1
М
Supplier shall at intervals specified in the schedule provide Purchaser a progress
report during the period.
R15.2
М
The report shall contain information on the works of the Supplier for the period, in
accordance with the approved schedule including warranty service with attached
approved documents, including official correspondence in paper and electronic form
(at least in PDF format).
R15.3
М
The report shall be agreed with organization authorized by the Purchaser.
R15.4
М
Purchaser may at any time of the Contract implementation carry out control over the
contract to check Supplier measures and quality of services under the contract
186
Section VI. Technical Requirements
E. IMPLEMENTATION SCHEDULE
Implementation Schedule Table
procurement of lots 1-9
Line
Item
No.
Subsystem / Item
Configuratio
n Table No.
Site / Site
Code
Delivery
(Bidder to
specify in
the
Preliminar
y Project
Plan)
Installation
(weeks from
Effective
Date)
Acceptance
(weeks from
Effective
Date)
Liquidate
d
Damages
Milestone
1
Delivery and implementation of
Comprehensive
Health
Information System for Municipal
hospital №1 Ust-Kamenogorsk
city
41
54
Yes
2
Delivery and implementation of
Comprehensive
Health
Information System for Municipal
Clinic Hospital №4 Almaty city
41
54
Yes
Section VI. Technical Requirements
187
3
Delivery and implementation of
Comprehensive
Health
Information System for Mother
and
Child
Center
UstKamenogorsk city
41
54
Yes
4
Delivery and implementation of
Comprehensive
Health
Information System for Municipal
Policlinic №11 Almaty city
41
54
Yes
5
Delivery and implementation of
Comprehensive
Health
Information System for Regional
Diagnostic Center Almaty city
41
54
Yes
6
Delivery and implementation of
Comprehensive
Health
Information System for Policlinic
№1 Kostanay
41
54
Yes
7
Delivery and implementation of
Comprehensive
Health
Information System for Central
rayon hospital, Zhualynsky rayon,
Zhambul oblast
41
54
Yes
8
Delivery and implementation of
Comprehensive
Health
Information System for Municipal
policlinic №7 Astana city
41
54
Yes
188
9
Section VI. Technical Requirements
Delivery and implementation of
Comprehensive
Health
Information System for Municipal
Hospital No. 1 of Astana city
41
54
Yes
Section VI. Technical requirements
189
System Inventory Table (Supply and Installation Cost Items) 0
System, Subsystem, or lot number: Lots 1-9
Component
No.
Component
Relevant Technical
Specifications
No.
Additional Site Information
(e.g., building, floor,
department, etc.)
Quantity
1
Delivery and implementation of Comprehensive Health
Information System for Municipal hospital №1 UstKamenogorsk city
1
2
Delivery and implementation of Comprehensive Health
Information System for Municipal Clinic Hospital №4
Almaty city
1
3
Delivery and implementation of Comprehensive Health
Information System for Mother and Child Center UstKamenogorsk city
1
4
Delivery and implementation of Comprehensive Health
Information System for Municipal Policlinic №11 Almaty
city
1
5
Delivery and implementation of Comprehensive Health
Information System for Regional Diagnostic Center
Almaty city
1
6
Delivery and implementation of Comprehensive Health
Information System for Policlinic №1 Kostanay
1
7
Delivery and implementation of Comprehensive Health
Information System for Central rayon hospital,
Zhualynsky rayon, Zhambul oblast
1
190
Section VI. Technical Requirements
Component
No.
Component
Relevant Technical
Specifications
No.
Additional Site Information
(e.g., building, floor,
department, etc.)
Quantity
8
Delivery and implementation of Comprehensive Health
Information System for Municipal policlinic №7 Astana
city
1
9
Delivery and implementation of Comprehensive Health
Information System for Municipal Hospital No. 1 of
Astana city
1
Section VI. Technical requirements
191
Site Table(s)
System, Subsystem, or lot number: Procurement of entire System
Site
Code
Site
Ust-
City / Town / Region
Primary Street Address
EKO, Ust-Kamenogorsk
Abai str, 18
Almaty
Turksib rayon, Papanin str., 220
EKO, Ust-Kamenogorsk
Utepova Str., 35, 37
1
Municipal hospital №1
Kamenogorsk city
2
Municipal Clinic Hospital №4
Almaty city
3
Mother and Child Center
Kamenogorsk city
4
Municipal Policlinic №11 Almaty
city
Almaty
Zhetysu rayon, Zhumabayeva
str., 87
5
Regional
Diagnostic
Almaty city
Almaty
Auezova Str., 57
6
Policlinic №1 Kostanay
Kostanay
Al-farabi, 112
7
Central
rayon
Zhualynsky rayon,
oblast
Ust-
Center
hospital, Zhualynsky rayon, Zhambul
Zhambul
oblast
B.Momyshuly village,
S.Beybarys Str, 1
8
Municipal policlinic №7 Astana
city
Astana
Sh. Kudaiberdyuly 25, 29
9
Municipal Hospital No. 1 of
Astana city
Astana
Koshkarbayev str, 66
Drawing
Reference No.
(if any)
192
Section VI. Technical Requirements
Holidays and other days-off
Month
2015
2016
1
1, 2, 7
1, 2, 7
8, 21, 22,
23
8, 21, 22,
23
1, 7, 9
1, 7, 9
7
6
6
8
30
30
16, 17
16, 17
2
3
4
5
6
9
10
11
12
Section VI. Technical Requirements
193
G. Technical Responsiveness Checklist
Note to Bidders: The following Checklist is provided to help the Bidder organize and
consistently present its Technical Bid. For each of the following Technical Requirements,
the Bidder shall describe how its Technical Bid responds to each Requirement. In addition,
the Bidder shall provide cross references to the relevant supporting information, if any,
included in the bid. The cross reference should identify the relevant document(s), page
number(s), and paragraph(s). The Technical Responsiveness Checklist does not supersede
the rest of the Technical Requirements (or any other part of the Bidding Documents). If a
requirement is not mentioned in the Checklist, that does not relieve the Bidder from the
responsibility of including supporting evidence of compliance with that other requirement in
its Technical Bid. One- or two-word responses (e.g. “Yes,” “No,” “Will comply,” etc.) are
normally not sufficient to confirm technical responsiveness with Technical Requirements.
194
Section VI. Technical Requirements
Technical Responsiveness Checklist
Number
R1
R1.1
R1.2
R1.3
R1.4
Description
General business requirements
Licensing mechanism for the System
under this contract shall provide the right
to use all modules and compounds in the
concrete Health Facility for number of
users sufficient for full scale functioning
of a health facility (size of health facility
could be evaluated basing on description
in the Annex 2), for unlimited time,
unlimited number of servers, and
excluding any other possible limitations.
It is not accepted annual license fees; the
only cost for license is the initial license
cost, which includes all costs.
Within
this
Contract
System
interoperability shall be assured with
national e-health system according to
requirement R 7. General scheme of
interaction with national e-health system
is set in the Pic. 1
The System shall correspond to general
architecture of Comprehensive Health
Information System set in Pic. 2
System modules and/or its compounds
shall have option of data exchange using
Mandatory (M)/ Clause
Desirable (D)
Number
M
M
M
M
Bidder’s technical
reasons
supporting
compliance:
Bidder’s
references
supporting
information
Technical Bid:
cross
to
in
Section VI. Technical Requirements
R1.5
R1.6
R1.7
R1.8
http(s) - protocol
the System shall have SOA-oriented
architecture that supports only defined and
platform independent interfaces for
interaction
At least following functional assigned for
use by wide range of users (patients,
distanced doctors, managers) shall be
implemented as web-application:
- patient’s demographic data
- patient complaints
- entry of allergic anamnesis
- entry of life anamnesis
- entry of suffered diseases
- entry of anamnesis of current illness
- entry of objective state of patient
examination
- entry data on reactions to drugs
- entry referrals to lab studies
- entry prescriptions
- entry referrals to diagnostic services
- review lab studies results
- review diagnostic results
- reporting
- doctor’s records keeping
The System shall have fine configuration
to assure adjusting to health facility needs
without design of a new system (or small
refinement of the System)
The Supplier under this Contract shall
carry out works to ensure interoperability
of the System with National EHR (EHR
195
M
M
M
M
196
R1.9
R1.10
R1.11
R1.12
R1.13
Section VI. Technical Requirements
repository, national classifiers and
indicators, analytic repository, EHR-webservices) according to requirement R7
The System integration shall be ensured
with introduced accounting system 1C.
Level of integration shall be determined
during implementation of the Contract and
agreed with the agency where System is
introduced.
The System shall ensure confidentiality of
personal data: encryption of personal data
in DB, encryption data while transmission
by channels, use of safe transmission
protocols and etc.
The System shall use digital signature to
sign and authorize e-documents, files and
parts of the documents. Need in digital
signature shall be configurable at System
admin level. More details on requirements
to digital signature are set in R 5.15.
The system shall be entirely operational
“on turnkey basis” according to R 14.2.
For this the Supplier shall if it is necessary
add missing parts, functionality and
solutions including cost of missing parts
in Price Table in item for «others»
The Supplier shall provide at least, but not
limited
to
configuration,
roll-out,
installation, testing of the System. The
Supplier shall provide trainings for users
and administrators (and other staff if
needed)
M
M
M
M
M
Section VI. Technical Requirements
R1.14
R1.15
R1.16
R1.17
R1.18
R1.19
R1.20
The Supplier shall take part in System
attestation together with the Supplier of
Platform
to
check
and
certify
interoperability with national resources
and EHR tools during procedures of
System attestation and testing.
The Supplier shall provide warranty
service for the System within 3 years from
the acceptance date according to R 12.4.
If additional software is required for
System operation “on a turnkey basis” the
Supplier shall provide licenses (for
complete System operating “on a turnkey
basis”) at his own expense and delivery it
to the Purchaser ownership within this
Contract.
The Supplier shall deliver System
configuration to health facilities according
to Table 1. System components are set in
Table 2.
Minimal requirements for each module
shall correspond to Section R2
In Bidding Documentation the Bidder
shall present edited technical specification
set within the format and structure of this
Technical Requirements
The system shall be able to integrate with
development environments (IDE), at least
for Java and Net Framework. The system
shall have a complete development kits
(SDK), which includes: documentation,
sample code at least for Java and Net
197
M
M
M
M
M
M
М
198
R1.21
R1.22
R1.23
R1.25
R1.26
Section VI. Technical Requirements
Framework, to configure the system
functions. An Option shall be available to
extend functionality of systems using
development tools (SDK), included into
the system.
Mechanism of licensing for System under
this contract should not limit the changes
made with the help of development tools
(SDK), included into the System. entering
Changes using development tools (SDK),
included into the System, should not
affect the terms of warranty service for
System. Changes to the System by experts
of the Client shall be allowed after system
commissioning.
The Supplier shall provide service and
technical support, including provision of
new versions of the products (according to
R12.3).
Response time services and system
components shall be no more than 3-5
seconds, for at least 80% cases of input
data or requests for data browsing (at a
rate of channel 1 Mb / s and a response
time of less than 100 ms).
The supplier shall document and transmit
electronically the configuration files and
source code, components, systems
developed under this contract
The system shall have Thin Client to
communicate with the equipment allowed
to use the Thick client.
M
M
М
М
М
Section VI. Technical Requirements
R.1.27
R2
R2.1
R2.1.1
R2.1.1.1
R2.1.1.2
The System shall meet following
requirements to reporting:
•
All analytic forms and reporting
forms shall have option of export into
formats .xls, xlsx, .docx, doc, .pdf, .csv,
.html, .xml.
•
Time for formulation of analytic
and reporting forms shall not exceed 1
min. While for 95 % of cases time for
formulation of analytic and reporting
forms shall not exceed 30 seconds.
•
The System shall have an option to
make up analytic and reporting forms
according to set timetable.
The System shall have an option to send
created analytic and reporting form to
specified e-mail address
Requirements to automated processes
Module 1 «Reception»
Management of doctor’s schedule of М
work, services, equipment use. This
process includes:
Making schedule of doctor work with M
possibility to choose doctor data (name,
position, specialty, department) out of list
of specialists
Check for availability of already made M
schedule for this period of time (date,
time), for this doctor, room, equipment,
and informing the user if it is available
while making up the schedule for doctor
work, service provision or equipment use
199
200
R2.1.1.3
R2.1.1.4
R2.1.1.5
R2.1.1.6
R2.1.17
R2.1.1.8
R2.1.1.9
R2.1.1.10
Section VI. Technical Requirements
Search for schedule among already
existing by date, time, doctor, doctor
specialty, service, equipment or their
combinations
While making up the schedule for doctor
work, service provision or equipment use
to set an option to interlink doctor, service
and equipment. This interlink is not
mandatory for filling in.
while making up the schedule for service
provision to plan the option of service
selection out of service list for which
health facility or a doctor has the right
While making schedule for equipment use
to have option to choose equipment out of
list of the health facility
Option of schedule generation, edition and
removal
While schedule removal or editing if the
patients are attached thereto, to have an
option of automated choice of possible
nearest time at similar specialist and
option of choice of definite time by user
While schedule removal or editing to have
an option of automated notification of
patient on changed date, time, place of
admission by e-mail and/or SMS
Making up following reports:
1. Summary information on schedule of
work of doctors by subdivisions, shifts,
service provision, equipment use
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
201
2. Report on changes in patient records
due to changed schedules.
R2.1.2
R2.1.2.1
R2.1.2.2
R2.1.2.3
R2.1.2.4
R2.1.2.5
R2.1.2.6
R2.1.2.7
R2.1.2.8
Registration for doctor examination with
handed out admission card. This process
includes at least:
Registration of the patient by receptionist,
by doctor during examination, by Patient
through Internet with issuance of
admission card
Registration of new patients with filling in
personal data, including transferring these
data from IS MHSD RK
Choice of patient out of patient DB of
Health Facility by name, IIN, date of birth
Printing routing chart for issued cards
with indication of doctor, room, date and
time of examination, some specific
additional information (way of getting
ready for exam for patient and other).
Registration of patient’s ambulatory card
handing out and receiving
Cancellation
of
registration
by
receptionist, doctor, patient by Internet
Making up «Waiting list» to take vacant
place because of cancellation of time for
doctor examination with automated
notification of the patient by e-mail and
SMS in case of registration for vacant
place
Option to book time for examination in a
schedule (solely or in group) with
М
M
M
M
M
M
M
M
M
202
R2.1.2.9
R2.1.2.10
R2.1.2.11
R2.1.3
R2.1.3.1
R2.1.3.2
R2.1.3.3
Section VI. Technical Requirements
regulated time to cancel reservation
Automated
preventing
of
patient
registration to several doctors by the same
time, and prevention of registration of
several patients to one and the same
doctor
Search of time for registration in existing
schedules by date, time, doctor, specialty,
services,
equipment
and
their
combinations
Following Reports making:
1.
Report on number of registered
(by
doctor,
service,
equipment,
department, health facility)
2.
Report on number of free places
(by
doctor,
service,
equipment,
department, health facility)
3.
Report on cancelled visits
4.
Report on not appeared patients
5.
Report on preservation of visits.
6.
Report on visited patients (within
reported period, by referred health
facilities, by specialists, services)
Management of Book for calls at home.
This process includes at least:
Registration of call at home accepted by
phone, by Internet and patient’s visit to a
health facility
Registration of cancel of call at home
initiated by the patient
Registration of transferring call at home to
the doctor
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.1.3.4
R2.1.3.5
R2.1.3.6
R2.1.3.7
R2.1.3.8
Registration of execution of the call with
details
Registration of need in second visit and its
date
Making up the list of non-distributed
calls: by districts, by health facility in
general
Making up the list of calls for the doctor
with indication of patients name,
diagnosis, address, phone, notes
Report making:
1. Report on calls at home (opened,
accepted, executed, cancelled) by doctor,
patient, district
203
M
M
M
M
M
2. Report on time of calls accepted and
executed
R2.1.4
R2.1.4.1
R2.1.4.2
R2.1.4.3
R2.1.4.4
R2.1.4.5
R2.1.4.6
Record keeping in the Book of active
information (calls at patient’s home by
initiative of medical specialists). It
includes, at least:
Dividing active information by groups –
hospital, policlinic, newborn, emergency,
pregnant women, newly born women
Registration of active information
received by phone, Internet
Registration of active information group
by file import – table of established type
Registration of active information cancel
Registration of transferring active
information to the doctor
Registration of the fact of execution with
M
M
M
M
M
M
M
204
R2.1.4.7
R2.1.4.8
R2.1.4.9
R2.1.4.10
R2.1.5
R2.1.5.1
Section VI. Technical Requirements
outcome details
Registration of the need in second visit
and its date
Making up the list of non-distributed
active information by districts, health
facility
Making up the list of active information
for the doctor with indication of patients
name, diagnosis, address, phone, notes
Reports making:
1. Report on active information (opened,
accepted, executed, cancelled) in a
breakdown by doctor, patient, district
2. Report on time of active information
accepted and executed.
Management of primary accounting
documents at the level of Reception in
line with normative legal acts of the RK.
It includes the following registration
formats:
Form 040/y
M
M
M
M
M
M
Form 025-4/ у
Form 025-9/у
Form 025-5/у
Form 031/у
R2.1.6
R2.1.7
Analytic tables formation on the M
Reception level as well as statistic tables
in line with current legal acts of the RK
Interaction with IS MHSD RK, it includes M
at least:
Section VI. Technical Requirements
R2.1.7.1
R2.1.8
R2.2
R2.2.1
R2.2.1.1
R2.2.1.2
R2.2.1.3
R2.2.1.4
R2.2.1.5
R2.2.1.6
R2.2.1.7
R2.2.1.8
Transfer of information on schedules of
doctor’s
work,
service
provision,
equipment use
Registration of facts of population
attachment/ detachment from a health
facility
Module 2 «District doctor»
Patient’s ambulatory card management. It
includes, at least:
Review of patients list that appointed time
for doctor exam
Making up Patient’s ambulatory card
Making up and editing templates such as
making medical papers and records,
consultations, exam protocols, diary
records using templates and option to
attach files (images, video, audio) with
link of user template to user account
Making medical records basing on
standard and user’s templates
Editing and removal of medical records
signed by digital signature shall be
blocked
Printing filled in medical records to form
paper version of ambulatory card
Option of selection of medical records by
certain parameters (visits, diagnosis, date,
diagnostic studies, lab analysis, service,
funding source and etc.)
Report on changes in patient’s numerical
data by time (anthropometric index,
functional index, lab data and etc.)
205
M
M
М
M
M
M
M
M
M
M
M
206
R2.2.2
R2.2.2.1
R2.2.2.2
R2.2.2.3
R2.2.2.4
R2.2.2.5
R2.2.2.6
R2.2.2.7
R2.2.2.8
Section VI. Technical Requirements
Making up internal (within one health
facility) and external (to other health
facilities) referrals to consulting and
diagnostic services. This includes, at least:
Making referrals to consulting and
diagnostic services within one health
facility with possibility to register by
certain time
Making referrals to consulting and
diagnostic services to other health
facilities with possibility to register by
certain time
Agreement of referrals for certain types of
services with the Head of Department
Recommendations making up to get
prepared to consulting and diagnostic
services basing on standard templates
Removal of referrals (wrong, by patient’s
initiative, automatically due to patient’s
absence)
Control over execution of consulting and
diagnostic services prescribed for a
patient, review of data on execution of
prescription including its results
Agreement and rejection of requests for
additional consulting and diagnostic
services
Report forming:
1.
Report on referrals created
(internal, external) by services, funding
source, level of care provision (rayon,
oblast/city, national)
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.2.3
R2.2.3.1
R2.2.3.2
R2.2.4
R2.2.4.1
R2.2.4.2
R2.2.4.3
R2.2.4.4
2.
List of patients by names referred
to consulting and diagnostic services
3.
Report on referrals (opened,
executed, rejected, internal, external)
Making up planned hospitalization (24
hours hospital and substitute care). This
includes, at least:
Making up patient summary from
ambulatory card (Form 027/у)
Making up of:
- templates on minimal standards of
studies at pre-hospital stages by levels of
health facilities
- referral and card for planned
hospitalization
Making up doctor prescriptions for drugs
and/or procedures, manipulations. This
includes at least:
Creation of prescriptions (paid, unpaid)
for medicines and narcotic drugs with
limited access of a certain category of
doctors and with description of uptake
method and doses and etc.
Control over prescriptions basing on set
max once-only doses depending on age,
sex, weight and etc.
Control over prescriptions basing on
formulary of a health facility and
republican drug formulary. Results of
Benefit Drug provision to dispensary
patients and other categories of population
Signing prescriptions by digital signature
207
M
M
M
M
M
M
M
M
208
R2.2.4.5
R2.2.4.6
R2.2.4.7
R2.2.4.8
R2.2.4.9
R2.2.4.10
R2.2.4.11
R2.2.5
R2.2.5.1
Section VI. Technical Requirements
Check for drug availability in pharmacy.
Such requirement shall be implementing
using
interaction
with
Module
“Pharmacy”
Making up referrals to procedures with
specification of medicines and their doses
Making up recommendations to prepare to
procedures basing on standard templates
Control over prescription execution and
drug release
Submission of reference information by
recommended prescriptions according to
approved
clinical
guidelines
and
diagnostic and treatment protocols
Making up the list of doctor’s
prescriptions (Form 004-1/у)
Report making:
1.
Report on generated receipts (INN,
form, dose, uptake method, and etc.)
2.
List of patients by names who got
receipts
3.
List of patients by names who got
receipts under benefit category
Management of initial registration
documentation at district doctor level
basing on regulatory norms of the RK.
This includes the following forms, at
least:
001-2/у, 001-3/у, 001-4/у, 001-5/у, 0016/у, 003-2/у, 004-1/у, 025/у (025-1, 0252, 025-3, 025-4), 025-2/у, 025-3/у, 0255/у, 025-7/у, 025-8/у, 026/у, 026-1/у,
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.2.6
R2.2.7
026-2/у, 030/у, 032/у, 036/у, 038/у, 0381/у, 038-2/у, 039/у, 040/у,
052/у, 053/у, 054/у, 058/у, 060/у, 063/у,
064/у, 070/у, 072/у, 075/у, 076/у, 086/у,
088/у 088-1/у, 094/у, 095/у 095-1/у,
106/у-12, 106-2/у-12, 112/у, 130/у,
132/у, 133/у, 138/у, 278/у, ТB 15/у, ТB
05/у,
Making up analytic tables at district M
doctor level as well as statistic tables
basing on regulatory norms. This includes
the following forms, at least:
1. Statement for accounting patient M
visits to policlinic, dispensary,
consultations and at home (039/у)
including in breakdown by district
doctors at PHC level
2. Report on executed screenings
according to MOH order № 685 as of
10.11.2009 including in breakdown
by district doctors at PHC level
3. Monitoring of execution of annual
mandatory fluorography inspections
for population including in breakdown
by district doctors at PHC level
4. Monitoring of execution of
monthly and annual plans on immune
prophylactic actions by Form №5, 6
MOH order No.128 as of 6.03.2013
including in breakdown by district
doctors at PHC level
5. Report
post
vaccination
209
210
Section VI. Technical Requirements
complications in the context of
primary care physicians by types of
prophylactic vaccinations by age and
outcomes, including in the context of
district doctors at PHC
6. Report on dispensary patients flow
including in breakdown by district
doctors at PHC level
7. Report on flow of dispensary
patients
with
chronic
renal
insufficiency with indication of
substitute therapy (gemodialiaz or
peritoneal, kidney transplantation,
etc.) including in breakdown by
district doctors at PHC level
8. Report on birth rate including in
breakdown by district doctors at PHC
level
9. Report on mortality including in
breakdown by district doctors at PHC
level
10. Report
on
invalid
patients
including in breakdown by district
doctors at PHC level
11. Report
on
referral
and
hospitalization including planned
hospitalization
in breakdown by
district doctors at PHC level
12. Report on Healthy life style
actions including in breakdown by
district doctors at PHC level
13. Report on quantity and structure of
Section VI. Technical Requirements
R2.2.8
R2.2.8.1
R2.2.8.2
attached population including in
breakdown by district doctors at PHC
level
14. Report on quantity of diseases of
patients living in the district attached
to a health facility and cohort of
patients under dispensary control
(Form 56, 12) including in breakdown
by district doctors at PHC level
15. Report on cohort of patients
receiving hospital substitute care
(Form 24) including in breakdown by
district doctors at PHC level
16. Report on care to children (Form
31) including in breakdown by district
doctors at PHC level
17. Report on child disability (Form
52) including in breakdown by district
doctors at PHC level
18. Report on use of bed fund of
health facility (hospital and day care)
(Form 21) including in breakdown by
district doctors at PHC level
19. Report on patients brought by
emergency care staff including in
breakdown by district doctors at PHC
level
Management of lists of temporary M
disability (sick lists). This includes at
least:
Registration of list of temporary disability M
Prolongation of list of temporary M
211
212
R2.2.8.3
R2.2.8.4
R2.2.8.5
R2.2.8.6
R2.2.9
R2.2.9.1
R2.2.9.2
R2.2.9.3
R2.2.9.4
R2.2.9.5
R2.2.9.6
R2.2.9.7
R2.3
R2.3.1
R2.3.1.1
Section VI. Technical Requirements
disability
Closing of list of temporary disability
Sending the list of temporary disability to
Head of Department or Medical
Consultative Board for approval
Making up referral to MSE (Form 088/у)
Reports making up:
1. Report on issued lists of temporary
disability
2. Report on referrals to MSE
Interaction with IS MHSD RK. It includes
at least:
Data exchange according to EMR and
EHR standards. More details in R7.2.1
Data exchange on hospitalization
Data exchange on executed services
Clinical information exchange (conclusive
diagnosis, consultations, screenings, etc.)
Data exchange on referrals to consulting
and diagnostic services
Data exchange on assigned procedures
Data exchange on receipts
Module 3 «Prophylactic screening»
Forming contingents subject to preventive
exams from targeted group of population
(screening) and register its performance
basing on regulatory norms. This includes
at least:
Making up lists of patients by names for
preventive examination (screening) out of
population attached to a health facility in
M
M
M
M
M
M
M
M
M
M
M
M
М
M
Section VI. Technical Requirements
R2.3.1.2
R2.3.1.3
R2.3.1.4
R2.3.1.5
R2.3.1.6
R2.3.1.7
R2.3.1.8
R2.3.2
R2.3.2.1
R2.3.2.2
R2.3.2.3
R2.3.2.4
line with regulatory documents
Option of automated notification of
patients (by e-mail and/or SMS) on
necessity to pass screening
Make up router list for screening passing
Mark on execution of studies in screening
with indication of outcomes and/or
conclusion
Automated making up of referrals to
specialists under the screening framework
Filling in card of screening
Making up conclusion on passed
screening
Reports:
1. Report on cohort of population subject
to screening (by types of screening,
district, age-sex structure)
2. Report on passed screening
3. Report on diseases revealed during
screening
Registration of other types of preventive
examination, regular and periodic, used
for employment. It includes at least:
Making up lists of patients by names for
preventive exams
Making up router lists for preventive
exams
Mark on execution of studies in
preventive exam with indication of
outcomes and/or conclusion
Automated forming of referrals to
specialists to pass preventive exam
213
M
M
M
M
M
M
M
M
M
M
M
M
214
R2.3.2.5
R2.3.2.6
R2.3.2.7
R2.3.3
R2.3.3.1
R2.4
R2.4.1
R2.4.1.1
R2.4.1.2
R2.4.1.3
Section VI. Technical Requirements
Fill in card of preventive exam
Making up conclusion on passed
preventive exam with issuance of
certificate
Reports:
1. Report on passed preventive exams (by
types of screening, district, age-sex
structure)
2. Report on diseases revealed during
preventive exam
3. Report on cohort of population subject
to regular screening
Management on initial registration
documentation at doctor level basing on
regulatory norms. This includes at least
the following forms:
025/у, 025-1/у, 025-2/у, 025-4/у, 025-5/у,
025-7/у, 025-8/у, 030/у, 032/ у, 040/у,
086/у, 108/у, 108-1/у, 112/у, 131/у, 245/у
Module 4 «Profile specialist»
Patient’s ambulatory card management
using national EHR data. This includes at
least:
Review of patients lists appointed for
exam
Templates making up and editing
including medical statements and records,
consultations, exam protocols, diaries and
option of file attachment (image, video,
audio) with link to user account
Making medical records using standard or
user templates
M
M
M
M
M
М
M
M
M
Section VI. Technical Requirements
R2.4.1.4
R2.4.1.5
R2.4.1.6
R2.4.1.7
R2.4.2
R2.4.2.1
R2.4.2.2
R2.4.2.3
R2.4.2.4
R2.4.2.5
R2.4.2.6
Medical records editing and removal of
those which are not signed
Printing of filled in medical records for
paper version of ambulatory card
Option to select medical records by
certain parameters (encounters, diagnosis,
dates, diagnostic studies, lab analysis,
services, funding source and etc.)
Report on changes in patient’s numerical
signs by time (anthropometric index,
functional index, lab data, etc.)
Making up internal (within one health
facility) and external (to the other health
facilities) referrals to consultative and
diagnostic services. This includes at least:
Making up referrals to additional
consultative and diagnostic services by
referrals issued by PHC department within
a facility with option to appoint time
Adding additional consultative and
diagnostic services without agreement
with PHC department
Making up an request for additional types
of studies to be approved by PHC
department
Mark on performed consultative and
diagnostic services
Making up protocols of consultations,
exam, operation basing on standard and
user templates
Formulate recommendations on getting
prepared to consultative and diagnostic
215
M
M
M
M
M
M
M
M
M
M
M
216
R2.4.2.7
R2.4.2.8
R2.4.2.9
R2.4.3
R2.4.3.1
R2.4.3.2
R2.4.3.3
R2.4.3.4
Section VI. Technical Requirements
services
Removal of referrals (wrong, by patients
initiative, automated if the patient did not
appear)
Control over consultative and diagnostic
services execution. Registration of firstly
coming
dispensary
patient
and
transferring this data to district doctor,
recommendations on periodicity of
monitoring and examination
Reports:
1. Report on created referrals (internal,
external) by services, funding sources
2. List of patients by names referred to
consultative and diagnostic services
3. Report on rendered consultative and
diagnostic services
4. List of patients by names which got
consultative and diagnostic services
Make up doctor prescriptions for drugs
and/or procedures and manipulations. It
includes at least:
Making up receipts for drugs (paid,
unpaid) with description of uptake
method, dosing and etc.
Control over prescriptions in line with set
maximal once-only doses depending upon
age, sex, weight and etc.
Control over prescriptions basing on
health facility and republican drug
formulary
Signing prescriptions by digital signature
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.4.3.5
R2.4.3.6
R2.4.3.7
R2.4.3.8
R2.4.3.9
R2.4.3.10
R2.4.4
R2.4.5
Check for drug availability in pharmacy
Making up referrals to procedures
Making up recommendations to prepare to
procedures basing on standard templates.
Control over prescription execution and
drug release
Submission of reference information by
recommended prescriptions according to
approved
clinical
guidelines
and
diagnostic and treatment protocols
Report making:
1. Report on generated receipts (INN,
form, dose, uptake method, and etc.)
2. List of patients by names who got
receipts
3. List of patients by names who got
receipts under benefit category
4. List of patients by names who got
medical devices
5. List of patients by names referred to
consultative and diagnostic service
6. Report on referrals to procedures
(opened, under execution, executed,
rejected, external, internal
Management of initial registration
documentation at profile specialist level
basing on regulatory norms. This includes
the following forms, at least:
001-3/у, 001-4/у, 001-5/у, 001-6/у, 0071/у, 025/у, 025-3/у,
025-4/у, 025-5/у, 025-7/у, 025-8/у, 0259/у, 027-2/у, 030/у, 030-1/у, 030-2/у,
217
M
M
M
M
M
M
M
M
218
R2.4.6
R2.4.7
R2.4.7.1
R2.4.7.2
R2.4.7.3
R2.4.7.4
R2.4.7.5
R2.4.8
R2.4.8.1
Section VI. Technical Requirements
030-6/у, 036/у, 037/у, 037-1/у, 039/у,
039-2/у, 039-3/у 040/у, 045/у, 048/у,
052/у, 053/у, 054/у, 058/у, 060/у, 065/у,
065-1/у, 069/у, 070/у, 071/у, 073/у,
083/у, 084/у, 086/у, 088/у, 089/у, 090/у,
094/у, 095/у, 098/у, 111/у,
112/у, 128/у, 130/у, 132/у, 133/у, 138/у,
278/у,
Management of lists of temporary
disability. This includes at least:
Registration of list of temporary disability
Prolongation of list of temporary
disability
Closing of list of temporary disability
Sending the list of temporary disability to
Head of Department or Medical
Consultative Board for approval.
To make up a report on issued lists of
temporary
To draw a referral to Medical SocialExpert Commission (MSEC), creation and
editing templates for MSEC
Making up analytic tables at profile
specialist level as well as statistic tables
basing on regulatory norms. This includes
the following forms, at least:
1. Statement for accounting patient visits
to policlinic, dispensary, consultations and
at home (039/у)
2. Report on executed screenings
according to MOH order № 685 as of
10.11.2009
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.5
R2.5.1
R2.5.2
R2.5.2.1
R2.5.3
3. Report on dispensary patients flow
4. Report on invalid patients
5. Report on adult invalid patients
6. Report on planned hospitalization
7. Report on quantity of diseases of
patients living in attached district and
cohort of patients under dispensary
control (Form 56, 12
8. Report on cohort of patients who get
substitute care (Form 24)
9. Report on care to children (Form 31)
10.Report on child disability (Form 52)
11. Report on use of bed fund of health
facility (hospital and day care) (Form 21)
Module 5 «Head of Department in
Policlinic»
Confirming or rejection of referrals for
certain types of services using digital
signature
Management of initial registration
documentation at Head of Department
level basing on regulatory norms. This
includes the following forms, at least:
1.
035/у
2.
035-1/у
3.
035-2/у
4.
035-3/у
5.
095/у
6.
094/у
Making up analytic tables at Head of
Department level as well as statistic tables
basing on regulatory norms. This includes
219
М
М
M
М
220
R2.5.3.1
R2.5.4
R2.5.4.1
R2.5.4.2
Section VI. Technical Requirements
the following forms, at least:
Report making up:
1.
Making up analytic tables in a
breakdown similar to the tables of
department staff
2.
Report on attached population by
districts
3.
Report on age-sex structure of
attached population
4.
Report on staff composition of
districts doctors
5.
Report
on
main
district
performance indexes
6.
Form 12
7.
Report on the structure of visits (in
terms of disease, preventive screenings,
dispensary patients, for a visit to doctor
examination,
at
home,
providing
substitute care technology, visits to
nursing staff, in first aid room, a treatment
room, on preventive vaccination)
8.
Report on hospitalization of
people from attached to a health facility
area
9.
Structure of consulting exams by
profile specialists in breakdown by the
districts of attached population
Agreement of list of temporary disability,
minutes of MCB. This includes, at least:
Agreement of
long-term lists of
temporary disability
Creation of MCB minutes
M
М
M
M
Section VI. Technical Requirements
R2.5.4.3
R2.5.4.4
R2.5.4.5
R2.6
R2.6.1
R2.6.2
R2.6.2.1
R2.6.2.2
Make up MCB conclusions
Signing of MCB conclusion by digital
signature
Reports:
1. Report on issued lists of temporary
disability
2. Report on quantity of patients passed
through MCB
3. Report on quantity of patients referred
to re-certification in MSE
Module 6 «Medical Statistics in
Policlinics»
Monitoring
of
initial
registration
documentation management in a health
facility
Making up analytic tables at the level of a
specialist in health statistics as well as
statistic tables basing on regulatory
norms. This includes at least the
following:
Constructor of reports with option to
generate new reports and edit existing
ones
Report making up:
1.
Form 039/у
2.
Form 007/у
3.
Report on attached population and
its age-sex structure
4.
Report on executed screenings
5.
Report on staff composition of
participants
6.
Report on activities to attach
221
M
M
M
M
M
M
M
222
R2.7
R2.7.1
R2.7.1.1
R2.7.1.2
R2.7.1.3
R2.7.1.4
R2.7.1.5
R2.7.1.6
R2.7.1.7
R2.7.1.8
R2.7.2
R2.7.2.1
R2.7.2.2
R2.7.3
Section VI. Technical Requirements
population to a district
7.
Reporting forms 21, 12, 17, 24, 30,
31, 32, 43, 47, 52, 59, 4, 5, 6
Module 7 «Admission»
Registration of patients addresses. This
process includes, at least:
Demographic data adjusting
Data check and entry on insurance
category and payment
Registration of medical referral and/or
rejection in care provision
Medical documents making up and
issuance
Setting links between referrals doubles
Distribution of patients by specialised
departments and rooms
Preliminary attachment of a patient to
doctor in charge
Confirming readiness to accept the patient
Management of patients EMR. It includes,
at least:
Full description of processes and
requirements to EMR management in line
with national standard of EMR (approved
by MOH order №75 as of 10.02.2014 «On
approval of technical documentation in ehealth issues»)
Minimal obligatory set of data from EMR
is given to national EHR
basing on
national standard of EHR
Clarification of services carried out before
hospitalization. It includes at least:
М
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.7.3.1
R2.7.3.2
R2.7.4
R2.7.4.1
R2.7.5
R2.7.5.1
R2.7.6
Review of patients EHR from national
EHR repository
Registration of diagnosis, procedures,
prescriptions and other data on medical
services
carried
out
prior
to
hospitalization but not entered into the
System
Management of initial registration
documentation at Admission level basing
on regulatory norms. This includes the
following forms, at least:
001/у, 003/у, 004-1/у, 045/у, 058/у,
060/у, 069/у, 264/у
Making up analytic tables at Admission
department level. This includes the
following forms, at least:
Reports:
1. Report on scope of performed services,
manipulations, exams
2. Report on drugs and vaccination
3. Report on performed work (quantity of
applied patients, quantity of hospitalized
patients in planned and extraordinary way,
to day hospital, rejections from
hospitalization, patients delivered by
emergency care, sent by PHC or selfreversal patients)
4. Report on active information submitted
to policlinic
5. Tables of bed fund of a health facility
with indication of vacant beds
Interaction with IS MHSD RK. It
223
M
M
M
M
M
M
M
224
R2.7.6.1
R2.7.6.2
R2.7.6.3
R2.7.6.4
R2.8
R2.8.1
R2.8.1.1
R2.8.1.2
R2.8.1.3
R2.8.1.4
R2.8.1.5
R2.8.2
Section VI. Technical Requirements
includes, at least:
Data exchange on executed services in
admission
department
before
hospitalization
Data exchange on hospitalization and
rejection from it
Data exchange on state of bed fund
Data exchange with IS MHSD RK
according to interoperability requirements
of MHSD
Module 8 «Hospital Doctor»
Management of patients EMR. It includes,
at least:
Full description of processes and
requirements to EMR management in line
with national standard of EMR (approved
by MOH order №75 as of 10.02.2014 «on
approval of technical documentation in ehealth issues
Minimal obligatory set of data from EMR
is given to national EHR
basing on
national standard of EHR
Disease case study based on a standard
template for the appropriate number of
beds (personal data, medical history,
personal history, past illnesses, the results
of the initial inspection, prescriptions)
Preliminary plan of treatment and
additional studies if required
Registration of patients visits and
examination by doctor in charge
Management of referrals to consultative
M
M
M
M
М
M
M
M
M
M
M
Section VI. Technical Requirements
R2.8.2.1
R2.8.2.2
R2.8.2.3
R2.8.2.4
R2.8.2.5
R2.8.3
R2.8.3.1
R2.8.3.2
R2.8.3.3
R2.8.3.4
R2.8.4
R2.8.4.1
R2.8.4.2
and diagnostic services. It includes, at
least:
Adjusting plan of treatment, use plan
during treatment, changes in plan if
required
Make up referrals to lab studies, study
results and (if required) interpretations
giving
Make up referrals to diagnostic services,
study
results
and
(if
required)
interpretations giving
Make up referrals to other doctors, study
conclusion of specialists
Monitoring of referrals state and
identification of delays and rejections
Diagnosis putting. It includes at least:
Case review from national EHR
repository
Analysis results review
Diagnosis adjusting and registration:
diagnosis of sent health facility (referral),
admission diagnosis (preliminary), the
final clinical diagnosis, complications,
comorbidities,
the
final,
anatomopathological diagnosis
Monitoring of execution of plan of
treatment and its adjusting
Make up doctor prescriptions for drugs
and/or procedures and manipulations. It
includes at least:
Study patients allergy
Check for drug compatibility
225
M
M
M
M
M
M
M
M
M
M
M
M
M
226
R2.8.4.3
R2.8.4.4
R2.8.4.5
R2.8.4.6
R2.8.5
R2.8.5.1
R2.8.5.2
R2.8.5.3
R2.8.5.4
R2.8.6
R2.8.6.1
R2.8.6.2
R2.8.7
Section VI. Technical Requirements
Make up prescriptions on drug using
treatment and diagnostic procedures
assigning
Monitoring of prescriptions executed in a
right way and in time by nurse and
involved into care parties
Registration of side effect of drugs and
complications from drugs and procedures
Patient discharge. It includes at least:
Determination of final diagnosis
Make up Form 066/у
Patient discharge making up
Registration of vacant bed
Making up analytic tables at doctor level.
It includes at least:
Reports:
1.
Report on carried out work
(number of cases with outcomes)
2.
Report on number of carried out
operations
(including
those
with
complications)
3.
Report on number of carried out
manipulations
4.
Report on bed fund (bed operating,
average duration of patient use of bed,
execution of bed-days, death cases)
5.
Report on use of diagnostic studies
6.
Report
on
rehabilitation
procedures
Analytic tables making up
Management of initial registration
documentation at hospital doctor level
M
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.8.7.1
R2.9
R2.9.1
R2.9.1.1
R2.9.1.2
R2.9.1.3
R2.9.1.4
R2.9.1.5
R2.9.1.6
R2.9.2
basing on regulatory norms. This includes
the following forms, at least:
003/у, 004-1/у, 005/у, 008/у, 011/у, 0112/у, 011-3/у,027/у, 066/у, 066-4/у
Module 9 «Hospital Nurse»
Management of patients EMR. It includes,
at least:
Full description of processes and
requirements to EMR management in line
with national standard of EMR (approved
by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in ehealth issues”)
Minimal obligatory set of data from EMR
is given to national EHR
basing on
national standard of EHR (approved by
MOH order №75 as of 10.02.2014 “On
approval of technical documentation in ehealth issues”)
Demographic data adjusting
Case treatment plan study
Registration
on
required
referrals
(appointing to doctor for exam) to lab,
diagnostic rooms and other specialists
according to referrals and doctor
prescriptions
Reports:
1.
Report on drugs and medical
devices
2.
Report on carried out procedures
3.
Report of dressing/aid room
Mark on execution of prescriptions and
227
M
M
M
M
M
M
M
M
M
228
R2.9.2.1
R2.9.2.2
R2.9.2.3
R2.9.2.4
R2.9.3
R2.9.3.1
R2.9.3.2
R2.9.3.3
R2.9.4
R2.9.4.1
R2.9.4.2
Section VI. Technical Requirements
care plan, it includes, at least:
Mark on drugs taken by patients
Report on made procedures (for
extraordinary cases when there are no
work places in treatment room)
Mark
on
made
operations
(for
extraordinary cases when there are no
work places in operating room)
Entry of results of lab analysis and
diagnostic tests (if there are no work
places in relevant rooms for registration of
results)
Monitoring of patient state. It includes, at
least:
Mark on made assessment over patient
state (temperature, complaints and etc.)
Monitoring of treatment plan execution
Warning in urgent cases
Management of initial registration
documentation at nurse level. This
includes, at least:
Printing of referrals and plan of treatment
The System shall be able to manage
following registration forms:
1.
004/у, 004-1/у, 007/у, 009/у,
029/у,
2.
Register for blood intake for HIV
3.
Register for recipients transfer to
policlinic
4.
Register of medication
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.9.5
R2.9.5.1
R2.10
R2.10.1
R2.10.1.1
R2.10.1.2
R2.10.1.3
5.
Register of dressing material
6.
Requirements to pharmacy
7.
Register for ethanol
8.
Register for narcotic drug,
psychotropic substances and precursors
(Decree of GOK № 396 as of 30.03.2012)
Analytic tables making at nurse level.
Drawing up the following reports:
1.
Report on used medications,
including drugs and ethanol
2.
Report on used medical devices
3.
Report on identification of Blood
group
4.
Report on revealed infectious
patients
5.
Report on transfusion of blood and
blood products
6.
Report on blood sampling and
other parts of organism for study
7.
Report on biopsy sampling
8.
Report on referrals to external
studies
Module «10 Meals»
Every day menu forming. It includes, at
least:
Forming menu – requirement, editing,
protection from editing upon approval
Forming menu handed out to tables with
indication of dishes, editing and
protection from editing upon approval
Review of list of dishes for each type diet
229
M
М
M
M
M
M
230
R2.10.1.4
R2.10.1.5
R2.10.2
R2.10.2.1
R2.10.2.2
R2.10.2.3
R2.10.2.4
R2.10.2.5
R2.10.2.6
R2.10.3
R2.10.3.1
R2.10.3.2
R2.10.3.3
Section VI. Technical Requirements
(Table)
Review of patients selected by diets,
rooms, departments and etc.
Review of patients and medical staff
comments towards meal quality
Calculator of every day, monthly
consumption of food for menu. It
includes, at least:
Calculation of required food products for
each day, given listed quantity of patients
in a health facility
Adjusting number of portions (with
logging of changes) for each type of diet
Automated estimation of required food
quantity and composition
Printing order for food delivery
Review of above data for previous periods
(data adjusting is possible by special
permission of Hospital Administrator
given for limited time period)
Possibility to review log in case of manual
changes in quantity of portions
Estimation of nutrition value of dishes in
ration. This includes, at least:
Estimation of dish nutrition value given
standard of waist and loss during culinary
processing
Automated prompting on composition and
food value for various diets
Report on feed value by each diet and
assigning recommended standards for
each diet
M
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.10.4
R2.10.4.1
R2.10.4.2
R2.10.4.3
R2.10.5
R2.10.5.1
R2.10.5.2
R2.10.5.3
R2.10.5.4
R2.10.6
R2.11
R2.11.1
R2.11.1.1
R2.11.1.2
R2.11.1.3
Making references of food products. It
includes, at least:
Handbook of basic food products and
semi-finished products
Reference of dish cards and composition
Reference of dieted dish (tables 1-15)
Patients diet management
Review of recommendations on diets from
specialists and care doctors for each
patient
Diet prescription (Table number)
Diet change
Review of patients and medical staff
references on food quality
Analytic tables forming for meals
Module «11 Day Hospital»
Management of patients EMR. It includes,
at least:
Full description of processes and
requirements to EMR management in line
with national standard of EMR (approved
by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in ehealth issues”)
Minimal obligatory set of data from EMR
is given to national EHR basing on
national standard of EHR (approved by
MOH order №75 as of 10.02.2014 “On
approval of technical documentation in ehealth issues”)
Disease case study
231
M
M
M
M
M
M
M
M
M
M
M
M
M
M
232
R2.11.1.4
R2.11.1.5
R2.11.2
R2.11.2.1
R2.11.2.2
R2.11.2.3
R2.11.2.4
R2.11.2.5
R2.11.3
R2.11.3.1
R2.11.3.2
R2.11.3.3
R2.11.3.4
R2.11.3.5
R2.11.3.6
R2.11.3.7
R2.11.4
Section VI. Technical Requirements
Preliminary plan of treatment
Registration of patients visits and
examination by doctor in charge
Creation of referrals to consultative and
diagnostic services. It includes, at least:
Adjusting plan of treatment, use plan
during treatment, changes in plan if
required
Make up referrals to lab studies, study
results and (if required) interpretations
giving
Make up referrals to diagnostic services,
study results and interpretations giving
Make up referrals to other doctors, study
conclusion of specialists
Monitoring of referrals state and
identification of delays and rejections
Registration of doctor prescriptions and
execution. It includes at least:
Study patients allergy anamnesis
Check for drug compatibility
Make up prescriptions on drug using
Procedures assigning
Mark on execution of procedures
Monitoring of prescriptions executed in a
right way and in time by nurse or helping
persons
Registration of side effect of drugs and
complications from medicines and
procedures
Management of initial registration
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.11.4.1
R2.11.5
R2.11.5.1
R2.11.6
R2.11.6.1
R2.11.6.2
R2.11.6.3
R2.11.6.4
R2.12
R2.12.1
documentation at Day Hospital level
basing on regulatory norms. This includes
the following forms, at least:
001-3/у, 001-4/у, 003-2/у, 004-1/у,
027/у, 029/у, 066-4/у
Making up analytic and statistic tables at
Day Hospital level in line with normative
legal acts. It includes at least:
Reports:
1. Report on carried out work (number of
cases with outcomes)
2. Report on number of carried out
operations
(including
those
with
complications)
3. Report on number of carried out
manipulations
4. Invoice for reported period specifying
cost of treatment by nosology forms
5. Report on average duration of stay in
hospital
Interaction with IS MHSD RK. It includes
at least:
Data exchange on executed services
Clinical information exchange (diagnosis,
consultations and examinations results,
etc.)
Data exchange on referrals
Data exchange on receipts
Module
«12 Head of Hospital
Department»
Confirming or rejection of referrals for
certain types of services using digital
233
M
M
M
M
M
M
M
M
M
234
R2.12.2
R2.12.2.1
R2.12.3
R2.12.4
R2.12.4.1
R2.12.4.2
R2.12.4.3
R2.12.4.4
R2.12.4.5
Section VI. Technical Requirements
signature
Management of initial registration
documentation at Head of Department
level basing on regulatory norms. This
includes the following forms, at least:
The System shall be able to register
information
of
following
initial
accounting forms:
035/у, 035-1/у, 035-2/у, 035-3/у, 094/у,
095/у
Making up analytic tables at Head of
Department level as well as statistic tables
basing on regulatory norms by forms and
similar tables of department specialists.
List of analytic and statistic forms shall be
agreed with the Client at the stage of
System design.
Agreement of lists of disability, records of
council of physicians. It includes at least:
Agreement of long-term lists of disability
Creation of records of council of
physicians
Make up council of physicians
conclusions
Signing council of physicians conclusion
by digital signature
Reports:
1. Report on issued lists of temporary
disability
2. Report on patients passed through
council of physicians
3.
Report on operating factors of bed
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.13
R2.13.1
R2.13.1.1
R2.13.1.2
R2.14
R2.14.1
R2.14.1.1
R2.14.1.2
R2.14.1.3
fund of a department
4.
Report on treated patients
5.
Structure of treated cases by
groups of nosology and age
6.
Report on services rendered by
codes of tarrificator
Module 13 «Hospital Administrator»
Making up analytic tables at Hospital
Administrator level as well as statistic
tables basing on regulatory norms. List of
analytic and statistic forms shall be agreed
with the Client at the stage of System
design. This includes the following forms,
at least:
Monitoring of initial documentation
maintenance in a health facility
Analytic tables and reports accessible to
all health facility departments by division
into departments
Module 14 «Medical Statistics for
Hospital»
Bed fund management. It includes, at
least:
Management of bed fund referral by units,
rooms, beds
Setting up bed fund use (bed installing,
bed folding, temporary beds, setting
maximal number of beds in room,
management of information on bed
profiles, bed profile change, bed closing
and reducing)
Entry of additional information on bed,
235
M
M
M
M
M
M
M
236
R2.14.2
R2.14.2.1
Section VI. Technical Requirements
room (male, female)
Making up analytic tables at Medical M
statistic level as well as statistic tables
basing on regulatory norms.
Forming initial reports and forms:
M
1.
Every day :007/у, 007-1/у,
2.
Monthly: 016/у
3.
Form 21
4. Form 14 annual (ICD-10 and ICD-9)
5. Form 32 annual
6. Form 30 annual
7. List of cured cases at tertiary level with
indication of operations
8. Hospital activity report
9. Work of departments by bed profiles;
10. Composition of patients, terms and
outcomes;
11. Main indicators for hospital work;
12. Information on structure of all types of
secondary care;
13. Composition of patients by groups of
diagnosis;
14. Composition of cured patients by
outcomes;
15. Statistic data on work of resident
doctors;
16. Surgery work by departments;
17. Analysis of surgery activity;
18. Summary information on operated
patients by bed profiles;
19. Information on pre-surgical state;
20. Operations by surgery units;
Section VI. Technical Requirements
21. composition of patients for surgical
departments
22. analysis of activity of intensive care
unit;
23. analysis of mortality and matches in
clinical and post-mortem diagnoses;
24. analysis of diagnosis coincidence by
referral and final one;
25. data on treated patients by districts
and regions;
26. data on treated patients by referrals for
“HB" ;
27. data on the types of injuries;
28. data on patients received in alcoholic
state;
29. list of patients treated;
30. List of patients in the hospital;
31. list of the dead to be submitted to the
registration service
32. list of the dead in the hospital at
district level;
33. List of deaths by age;
34. information on treated villager
inhabitants;
35 List of operated patients by
departments;
36. list of patients operated on by doctors
of the Department;
37. list of patients in breakdown by
selected diagnoses;
38. list of patients with complications
after surgery;
237
238
R2.14.2.2
R2.14.2.3
R2.15
R2.15.1
R2.15.1.1
Section VI. Technical Requirements
39. list of patients passing through
resuscitation;
40. list of patients transferred to other
hospital
41. list of treated patients who appeared
to be healthy ;
42. list of patients having preferential
category;
43. list of patients admitted again within a
month;
44. sex and age composition of treated
patients by profiles;
45. report on services delivered by
diagnostic departments;
46. Structure of patients with circulatory
diseases in breakdown by nosology, age
and outcome
47. Report on cured cases in breakdown
by DRG.
Monitoring of
primary records
maintenance of a health facility
Report Designer with the ability to create
new reports and modify existing
Module
15
«Procedures
and
manipulations»
Management of patients EMR. It includes,
at least:
Full description of processes and
requirements to EMR management in line
with national standard of EMR (approved
by MOH order №75 as of 10.02.2014 “On
approval of technical documentation in e-
M
M
M
M
Section VI. Technical Requirements
R2.15.1.2
R2.15.1.3
R2.15.1.4
R2.15.1.5
R2.15.2
R2.15.2.1
R2.15.3
R2.15.3.1
R2.16
R2.16.1
R2.16.1.1
R2.16.1.2
R2.16.1.3
health issues”)
Minimal obligatory set of data from EMR
is given to national EHR
basing on
national standard of EHR (approved by
the same order)
Patient identifier
Mark on executed procedures
Appointing the patient by time if there is a
need to get services again
Management of initial documentation for
rendered services and manipulations
according to regulations. It includes at
least:
029/у, 042/у,044/у, 046/у, 047/у, 058/у,
063/у, 064/у, 064-1/у, 064-2/у,
069/у, 150/у
Making up analytic tables on carried out
procedures and manipulations and statistic
tables according to regulations. It includes
Reports:
Report on carried out services (by used
equipment, executers, funding sources
types of services)
Module 16 «Admin»
Database management. This process
includes, at least:
Monitor and optimize of database
performance
Database Management: Configuration of
repository, database extension
Managing users and passwords of
database
239
M
M
M
M
M
M
M
M
M
M
M
M
240
R2.16.1.4
R2.16.1.5
R2.16.1.6
R2.16.2
R2.16.2.1
R2.16.2.2
R2.16.2.3
R2.16.2.4
R2.16.2.5
R2.16.3
R2.16.3.1
R2.16.3.2
R2.16.3.3
R2.16.3.4
R2.16.3.5
R2.16.4
R2.16.4.1
Section VI. Technical Requirements
Access rights management to database in
accordance with Annex 1
Backing up data for a certain period of
time
Restoring the backup data on separate
servers to find old data.
Creating user groups and individual users
of the system. This process includes, as a
minimum:
Create, delete, and edit user accounts;
Create, delete, and modify user roles;
Attaching roles to specific users (the same
user can have multiple roles)
Add, change, or delete access rights of
roles to modules, initial rights shall be
assigned in accordance with Annex 1.
Temporary ban for user access to the
System
Manage authentication types (password,
digital signature) This process includes, at
least:
Initial password creation
Change passwords for those users who are
not able to change them
Change Password Management Policy
Using foreign keys
View attempts to access with an invalid
key
Maintain system logs. This process
includes, as a minimum:
Log of created, modified, and deleted
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.16.4.2
R2.16.4.3
R2.16.4.4
R2.16.4.5
R2.16.4.6
R2.16.4.7
R2.16.5
R2.16.5.1
R2.16.5.2
R2.16.5.3
R2.16.5.4
records in the database
Log of the users input history
Log of receiving reports
Log of data viewing
Log of archiving actions
Log of Errors and emergency program
stops
Log of synchronization with external
(national) directories, classifications,
indexes and registers
Customization of medical records
templates. This process includes, at least:
Creating new templates
Change (creating new versions) of
existing templates
Attaching templates to modules and their
detachment
The following functions are used when
creating and editing the templates:
•change the font settings (style, size, bold,
underline, italics, etc. )
• changing the font color
• the creation of complex patterns with
subsections
• the ability to use any directory in the
system for filling in fields in the template
• the ability to use any entity in the
database for filling in fields in the
template
• the ability to use any data selection from
the database for filling in fields in the
template
241
M
M
M
M
M
M
M
M
M
M
M
242
R2.16.6
R2.16.6.1
R2.16.6.2
R2.16.6.3
R2.16.7
R2.16.7.1
R2.16.7.2
R2.16.7.3
R2.16.7.4
R2.16.7.5
Section VI. Technical Requirements
• forming fill rules: only from the list,
from the list with possible matches, in
free format, from the samples, etc.
• creating new directories used when
completing the template
Customizing user interface. This process
includes, at least:
Controlling access to interface tools
depending on user access rights
Change the style (for example: colors, size
of fields, fonts)
Option of making up individual templates
for each user including assigning defaults
to separate fields in pattern of this user
Configuring user access. This process
includes, at least:
Adding, modifying, and deleting user
rights on actions in the System
Manage (add, edit and delete) access to
data in the context of organizational
structure of enterprise: within structural
unit attached to the user, within the entire
health facility, in accordance with
organization structure of enterprise
Fixing the right for user for view,
creation, change and removal of data in
certain structural units
Add, change, or delete user access to
reports
Time Management - Schedule of work of
employees, during which the user has
access rights to the System
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.16.7.6
R2.16.7.7
R2.16.7.8
R2.16.7.9
R2.16.7.10
R2.16.8
R2.16.8.1
R2.16.8.2
R2.16.8.3
R2.16.9
R2.16.9.1
R2.16.9.2
R2.16.9.3
R2.16.9.4
Controlling access to patient data in
accordance with the privacy policy of
personal data approved by MHSD RK.
Installation privacy indication for those
personal data that must be stored in a
database in encrypted form
Viewing logs with the actions of specific
users for a certain period of time
Archiving and cleaning logs with data
about user activity for a certain period in
accordance with the policies of MHSD
RK
Viewing log files
Setting of connection to external
programs. This process includes, at least:
Allowing access for certain IP addresses
Resolution of certain programs and
services
Change access passwords of external
programs
Managing directories (references). This
process includes, at least:
Changing content (add, edit) of local
directories of the system
Monitoring the synchronization of
external (national) directories, indexes and
registers
Monitoring of correctness (or potential
problems ) of data exchange with external
data sources (national EHR, national
analytical repository)
Change the synchronization schedule with
243
M
M
M
M
M
M
M
M
M
M
M
M
M
M
244
R2.16.10
R2.16.10.1
R2.16.10.2
R2.16.10.3
R2.16.10.4
R2.17
R2.17.1
R2.17.1.1
R2.17.1.2
R2.17.1.3
R2.17.1.4
R2.17.1.5
R2.17.1.6
Section VI. Technical Requirements
external information resources
Create, edit reports using the Report
Master, which allow create and edit of
reports with using of fields from System
data base. This process includes, at least:
Creating Reports
editing reports
Deleting reports
Setting user rights to use reports
Module 17 «Lab IS»
Registration of received material with the
possibility of rejection. This process
includes, at least:
Doing personified account of ongoing
research, support of patient cards in the
LIS database
Creating a new patient card by assigning a
unique identification number after:
automatically retrieve of data from other
modules on the flow of new patient,
automatically after receiving (reading) the
referral, entry of patient data from the
referral manually
Reading standard forms using: optical
recognition
of
symbols,
optical
recognition of marks
Registration of received material with
reference to the patient
Assigning a unique identification number
to each material
Ability to reject Receipt stating the reason
(from the directory and / or manually)
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.17.1.7
R2.17.2
R2.17.2.1
R2.17.2.2
R2.17.2.3
R2.17.2.4
R2.17.3
R2.17.3.1
R2.17.3.2
R2.17.3.3
R2.17.3.4
R2.17.3.5
Generating reports:
1. Report on the quantity of incoming
material
2. Report on quantity of rejected material
for various reasons
Barcoding material (creating barcode,
identification by barcode). This process
includes, as a minimum:
Assigning a barcode for material
Assigning a barcode for individual
samples
Read barcode using stationary and
portable bar code scanners
Support for processing the data on the
basis of the majority of these bar codes:
Code 39, Code 93, Code 128, Codebar,
European Article Number (EAN), ITF-14,
MSI Barcode, Universal Product Code, as
well as two-dimensional codes PDF417,
Aztec Code, Data Matrix, Maxi Code,
QR-code, Microsoft Tag
Formation of worksheets for laboratory
analyzers and executors. This process
includes, at least:
Formation of orders for analysis based on
referrals received from HIS
Formation of orders for analysis based on
manual data entry
Inclusion of several materials to one order
Using of service profiles for ordering
(multiple studies)
Order of integrated services (one service
245
M
M
M
M
M
M
M
M
M
M
M
M
246
R2.17.3.6
R2.17.3.7
R2.17.3.8
R2.17.3.9
R2.17.3.10
R2.17.4
R2.17.4.1
R2.17.4.2
R2.17.4.3
R2.17.4.4
R2.17.4.5
R2.17.5
R2.17.5.1
R2.17.5.2
R2.17.5.3
Section VI. Technical Requirements
with multiple materials)
Automatic distribution of analysis on
worksheets based on configurable criteria
(type of analysis, analysis time , executor)
Manual distribution of analysis on work
places
Redistribution of analysis from selected
worksheets to other worksheets
Changing the executor in a worksheet
Prints worksheets to perform manual
research
Interaction with laboratory equipment
(export referrals to analysis, import of
analysis results). This process includes, at
least:
Connecting analyzers , sample preparation
stations and other equipment that have the
ability to connect to LIS
Submit orders to analyzers
Getting results from the analyzers and
their distribution in the patient cards
Getting results of internal quality control
from analyzers
Viewing, editing, deleting, editing,
approving of the results
Manual entry of laboratory results. This
process includes, at least:
Setting up a result templates
Manual entry of finished research results
Adjustable calculation algorithm of the
finished results based on input data
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.17.5.4
R2.17.5.5
Processing of the results of bacteriological M
analysis:
• The processing system must be open and
allow the user within embedded in the
system classification to add independently
the sections such as: antibiotics,
diagnoses, biomaterials, micro-organisms,
• A list of diagnoses in the system shall be
composed by ICD-10, the list of
antimicrobials shall be drawn up
according to international classification,
the list of taxons - on the latest edition of
"Bergey's Manual of Determinative
Bacteriology"
• antibiogram shall be built based on the
data entered by the user and received by
any of the methods (disk diffusion, by
limiting
concentrations
or
when
determining the minimum inhibitory
concentration)
• The processing system, based on
embedded data on the natural stability of
individual organisms or their groups, on
distribution among them acquired
resistance, as well as information about
clinical efficiency of antimicrobial agents,
shall interpret the results of studies of
antibiotic susceptibility, obtained in vitro,
to the degree of sensitivity (S, I, R) and, if
necessary , correct them or generate an
error message,
Forming of reports:
M
247
248
R2.17.6
R2.17.6.1
R2.17.6.2
R2.17.6.3
R2.17.7
R2.17.7.1
R2.17.7.2.
R2.17.7.3
R2.17.7.4
R2.17.8
Section VI. Technical Requirements
1. Report on completed analysis
2. Report on antibiotic resistance of
isolates (in general in a health facility and
by its units)
3. Report on types of lab studies (clinic,
biochemical,
hematological,
immunological, bacteriological and etc.)
4. 261 / y
5. 262 / y
6. Form # 1 POA (Report expensive
services compared with plan)
Validation of the results of laboratory
research laboratories by authorized
employee. This process includes, at least:
Viewing results of an analysis execution
Comparison with the reference values
with visual indication of deviations
Construction of control charts to evaluate
the quality of results
Laboratory
quality
control
(intralaboratory, interlaboratory, external).
This process includes, at least:
Registration of the daily results of the
control materials study
Register reference values of control
materials
Comparison of obtained values with the
reference values
Formation of control materials research
protocols for interlaboratory and external
comparisons
Printing the results on the basis of
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.17.8.1
R2.17.8.2
R2.17.8.3
R2.17.9
R2.17.9.1
R2.17.9.2
R2.17.9.3
R2.17.10
R2.17.10.1
approved legal acts for initial records .
This process includes, at least:
Creating and editing templates, forms and
logs
Print the results in accordance with the
approved (R2.18.10.1) and user’s forms
Print the logs in accordance with the
approved forms (R2.18.10.1)
Input of laboratory reference values for all
patients, by age and sex. This process
includes, at least:
Input of reference values by age and sex
Formation of the reference values of
individual indicators based on statistical
processing of laboratory results
Generating reports:
Laboratory reference values (by groups of
patients and types of lab studies)
Management of initial registration
documentation at laboratory level basing
on regulatory norms. This includes at
least:
014/у, 027-3/у, 200/у, 201/у, 202/у,
204/у, 205/у, 206/у, 207/у, 208/у, 210/у,
211/у, 214/у, 215/у, 216/у, 216-1/у, 2162/у, 217/у, 218/у, 219/у, 220/у, 221/у,
222-1/у, 223/у, 224/у, 227/у, 228/у,
230/у, 232/у, 233/у, 234/у, 235/у, 236/у,
237/у, 238/у, 239/у, 240/у, 240-4/у, 2405/у, 240-6/у, 240-7/у, 240-8/у,
240-10/у, 240-11/у, 240-12/у, 241/у,
242/у, 244/у, 244-1/у, 244-2/у, 244-3/у,
249
M
M
M
M
M
M
M
M
M
250
R2.17.11
R2.17.11.1
R2.17.12
R2.17.13
R2.17.13.1
R2.17.13.2
Section VI. Technical Requirements
245/у, 245-1/у, 248/у, 249/у,250/у, 252/у,
253/у, 253-1/у, 253-2/у, 254/у, 260/у,
257/у, 259/у, 261/у, 262/у,280/у,
Formation of analytical tables at the
laboratory level, as well as statistical
tables in accordance with the legal
regulations. This process includes, at
least:
Generating a report on completed analysis
(Form 30)
The ability to integrate the System with
independent
laboratory
information
systems. This process presupposes
compliance with required profiles of IHE
The transmission of information on
completed research to EMR and EHR.
This process includes, at least:
Transmission of data about laboratory
tests performed and their results to EHR
in accordance with the standard
requirements for EHR, approved by Order
of the Acting Minister of Health of
10.02.2014 № 75 "On approval of
technical documentation related to ehealth"
Transmission
of
laboratory
tests
performed and their results to the EMR in
accordance
with
the
standard
requirements for EMRs, approved by
Order of the Acting Minister of Health of
10.02.2014 № 75 "On approval of
technical documentation related to e-
M
M
M
M
M
M
Section VI. Technical Requirements
R2.18
R2.18.1
R2.18.1.1
R2.18.1.2
R2.18.2
R2.18.3
R2.18.3.1
R2.18.3.2
R2.18.3.3
R2.18.3.4
R2.18.3.5
R2.18.4
R2.18.4.1
R2.18.4.2
R2.18.4.3
health"
Module 18 «PACS» (Picture Archiving
and Communication System)
Data exchange with medical equipment. It
includes at least:
Data import pursuant to standard DICOM
(sectoral standard for health image
creation, storage, transmission and
visualization).
Import directly from video outputs (if the
necessary equipment is in place)
Interaction with other modules and
systems based on IHE profiles.
Import / export of images. This process
includes, at least:
Supporting of at least DICOM, BMP,
JPEG formats
Support for at least DICOM Modality
Worklist
Ability to save images as attachments to
CDA documents
Supports scanning of paper and film
images to produce an electronic archive
Audit of imports and exports cases
Working with images. This process
includes, at least:
Viewing single and series of images,
Calling from the archive and the
appearance of the image on the screen is
not later than 3-5 seconds after the request
Identification of areas of interest in the
251
M
M
M
M
M
M
M
M
M
M
M
M
M
M
252
R2.18.4.4
R2.18.4.5
R2.18.4.6
R2.18.4.7
R2.18.4.8
R2.18.4.9
R2.18.5
R2.18.5.1
R2.18.5.2
R2.18.5.3
R2.18.5.4
R2.19
R2.19.1
R2.19.1.1
R2.19.1.2
R2.19.1.3
R2.19.1.4
Section VI. Technical Requirements
image ,
Overlay comments
Image processing to improve the quality
Quick search of patient data and images of
the patient
Interlinks between patient metadata and
images
Connection images with interpretation and
diagnostic results
Audit of Imagines View and Edit
Maintain archive of images. This process
includes, at least:
The possibility of long-term storage of
images
Keeping the identity of the patient to
avoid errors in assigning images to other
patients.
The ability to integrate with other systems
in health facility
The ability to transmit image (if
necessary) to other systems and to the
national EHR repository
Module 19 «Diagnostic studies»
View records on schedule of patients. This
process includes, at least:
View the schedule of patients
Viewing of referrals to the diagnostic
studies
Getting a list of patients recorded to the
study
Cancellation or postponement of time of
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.19.1.5
R2.19.2
R2.19.2.1
R2.19.2.2
R2.19.2.3
R2.19.2.4
R2.19.2.5
R2.19.3
studies with indication of reasons for the
delay and stakeholders notification
Reports generating:
1. Report on appointments
2. Report on the canceled visits
3. Report on the services performed
4. Report on radiation doses for staff and
patient
5. Report on priorities and term of waiting
for diagnostic studies
6. Forming the list of patients in
breakdown by rendered services by codes
of tarrificator
Enter the results of research based on
templates. This process includes, at least:
Creating and editing templates for
consultation, conclusions, results of
research
Filling of research results based on
templates
Search of previous patient conclusions
Printing of research results according to
approved forms
Reports forming:
1. Report on services rendered (by
equipment, executors, funding sources,
research types, referred divisions)
2. Report on radiation doses for staff and
patient
3. List of patients in breakdown by
rendered services by codes of tarrificator
Management of initial registration
253
M
M
M
M
M
M
M
M
254
R2.19.3.1
R2.19.3.2
R2.19.4
R2.19.5
R2.19.5.1
R2.19.5.2
Section VI. Technical Requirements
documentation on diagnostic studies
basing on regulatory norms. This includes
at least:
001-4/у, 001-5/у, 028/у, 039-5/у, 039-7/у,
039-8/у, 050/у, 202/у, 203/у, 212/у,
213/у, 225/у, 226/у, 229/у, 231/у, 243/у,
243-1/у, 246/у, 247/у, 247-1/у, 247-2/у,
247-3/у, 247-3/1/у ,247-3/2/у, 247-4/у,
247-5/у, 247-6/у, 247-7/у,
Protocol for measuring individual doses
(MOH order №902 as of 20.12.11)
Formation of analytical tables for
diagnostic tests, as well as statistical
tables in accordance with the legal
regulations. The list of analytic and
statistic forms shall be agreed with the
Client at the stage of System design
The transmission of information on
completed research to EHR and EMR.
This process includes, at least:
Transmission of information on diagnostic
tests performed and their results in EHR
in accordance with the standard for EHR
approved by Order Acting Minister of
Health of 10.02.2014 № 75 "On approval
of technical documentation related to ehealth "
Transmission of information on diagnostic
tests performed and their results in the
EMR in accordance with the standard
requirements for EMRs , approved by
Order of the Acting Minister of Health of
M
M
M
M
M
M
Section VI. Technical Requirements
R2.19.5.3
R2.20
R2.20.1
R2.20.1.1
R2.20.1.2
R2.20.1.3
R2.20.1.4
R2.20.1.5
R2.20.1.6
R2.20.2
R2.20.3
R2.20.4
R2.20.5
10.02.2014 № 75 "On approval of
technical documentation related to ehealth"
Implementation of the exchange in
accordance with IHE profiles
Module 20 «Pharmacy»
Record keeping for medicines at different
levels: nurse’s station, office, pharmacy
warehouse (one or more), health facility.
This process includes, at least:
Maintain full inventory control on one or
more central warehouses
Maintain full inventory control for each
responsible person
View stored remainings in each stock (by
group of medicines, by pharmacological
and pharmacotoxic groups, on medicines,
by supplier, by department)
Setting the number of minimum balances
for each medication
Establishing the baseline medication lists
for each department
Control over the implementation of
minimum balances
Automatic write-off of drugs when
prescription is executed
Ability to track expiration dates of
medicines and medical devices.
The possibility of forming a list of
medicines (medical devices) required to
purchase in health facility.
Formation of order to the pharmacy to get
255
M
M
M
M
M
M
M
M
M
M
M
M
256
R2.20.6
R2.20.7
R2.20.7.1
R2.20.7.2
R2.20.7.3
R2.20.8
R2.20.8.1
R2.20.8.2
R2.20.8.3
Section VI. Technical Requirements
drugs (automatic urgent order if medicine
is in the treatment sheet but lack in the
department, in case of reducing the stock
below the critical minimum). This
includes at least:
Getting information about the presence of
the drug in the departments. This includes
at least:
Maintenance of the drug formulary of
health facility. This process includes, at
least:
Creation of the formulary of a health
facility
Adding medications into the formulary of
a health facility with indication of
justification document
Exclusion of drugs from formulary of a
health facility with indication of
justification document
Register of side effects of the drug. This
process includes, at least:
Forming of card-message (form №192-1/у
by MOH order as of 3.11.2009, №647)
Register case in Log for revealed cases of
side effect from drugs (Form №192-3/у
MOH order as of 03.11. 2009, № 647)
Reports:
1.
Making up statistic reports on
revealed cases of side effect from drugs
and lack of effectiveness of the drug in
medical and pharmaceutical agency (Form
№192-4/у MOH order as of 03.11. 2009,
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.20.9
R2.20.9.1
R2.20.9.2
R2.20.9.3
R2.20.9.4
R2.20.9.5
R2.20.9.6
R2.20.9.7
R2.20.10
R2.20.10.1
R2.20.10.2
R2.20.10.3
R2.20.10.4
R2.20.10.5
№647)
Monitoring of prescriptions of drugs. This
process includes, at least:
Viewing prescriptions of drugs in units of
a health facility
Sorting prescriptions by date, doctor,
diagnosis, and other parameters
View the links between diagnosis and
drugs
Enter the data about drugs, recommended
clinical guidelines and protocols of
diagnosis and treatment
Entering data on interaction of drugs to
prevent joint prescription
Comparison of prescriptions with the list
in accordance with clinical protocols and
guidelines
Sending
messages
with
the
recommendation to replace the drugs
Setting maximum dosages for control
purposes. This process includes, at least:
Setting the maximum dosage in various
forms (kg per body mass, single, daily,
etc.)
Setting maximum dosages for different
groups of patients with various age and
sex
Setting maximum dosages for individual
diseases
Viewing applications for exceeding the
specified maximum dosages
Permission to exceed the specified
257
M
M
M
M
M
M
M
M
M
M
M
M
M
M
258
R2.20.11
R2.20.11.1
R2.20.11.2
R2.20.11.3
R2.20.11.4
R2.20.11.5
R2.20.11.6
R2.20.11.7
R2.20.12
R2.20.13
Section VI. Technical Requirements
maximum dosages with reasons
Registration and execution of credit and
debit invoices of hospital units and
pharmacies in accordance with the
regulations. This process includes, at
least:
Create, edit, and check invoices
Creating, editing and recording of credit
and debit invoices
Formation of requirements for medicines
from senior nurses of a department,
including on the basis of registered
prescriptions
Making consignment statement for
medicines and supplies according to the
requirements for the supply of medicines
from senior nurses of departments
Create, edit, and register the return of
medicines from departments to the
warehouse
Creating, editing and recording of orders
to suppliers
Creating, editing and recording of
deferred credit and debit invoices to fulfill
orders for medicines
Management of initial registration
documentation on pharmacy level in
accordance with legal regulations.
Formation of analytical tables at the
pharmacy level, as well as statistic tables
in accordance with the legal regulations.
The list of analytic and statistic forms
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.20.14
R2.20.15
R 2.20.16
R2.21
R2.21.1
R2.21.1.1
R2.21.1.2
R2.21.1.3
R2.21.1.4
R2.21.1.5
R2.21.1.6
R2.21.2
R2.21.2.1
R2.21.2.2
R2.21.2.3
R2.21.2.4
shall be agreed with the Client at the stage
of System design.
Forming
application
for
required
medicines at the level of a department,
out-patient clinic, hospital basing on
served area
Forming report on planning expenditures
for medicines given the benefit medicines
Interaction with other Modules in case of
need in exchange of information on drugs
Module 21 “Human Resources”
Communication with national indexes. It
includes at least following indexes:
“Register of Healthcare professionals”
“Register of Health facilities”
“Register of Addresses”
“Health specialties”
“List of positions (duties)”
“List of medical services”
Maintenance of organizational structure of
health facility. It includes at least:
Making up, editing, removal of units in
health
facilities
(rooms,
units,
departments, and etc. in line with
organizational structure of facility)
Maintenance of health facility staff
schedule
Making up statements for substitution of
officials
Linkages between rooms/ offices and
specialists
259
M
M
M
M
M
M
M
M
M
M
M
M
M
M
260
R2.21.2.5
R2.21.3
R2.21.3.1
R2.21.3.2
R2.21.3.3
R2.21.3.4
R2.21.3.5
R2.21.3.6
R2.21.3.7
R2.21.3.8
Section VI. Technical Requirements
Linkage of units with the list of provided
services
Maintenance of doctors (health facility
staff) registration card. It includes at least:
Employment of specialist
Enter of following minimal information
about the employee:
The history of labor relations, episodes of
employment, personal information (ID
number , the number of the pension
contract, marital status, family, place of
residence, place of registration, contact
information, number of children, relation
to military service, the number of
individual
employment
contract),
information about participation in
hostilities, emergency response, disaster
relief, promotion, levy, knowledge of
languages, information on social rewards,
education, professional certifications,
trainings, academic degrees, science
degrees
Registration of employees’ liability for
damage
Employment for the additional position
Transfer to another position within the
health facility
Dismissal of an employee
Management of Capacity building
schedule
View and print a list of employees
selected according to certain criteria
M
M
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R2.21.4
R2.21.4.1
R2.21.4.2
R2.21.4.3
R2.21.4.4
R2.21.4.5
R2.21.5
R2.21.5.1
R2.21.5.2
R2.21.5.3
R2.21.5.4
R2.21.6
R2.21.6.1
R2.21.6.2
R2.21.6.3
R2.21.6.4
R3
Keeping employees work mode. This
process includes, at least:
Planning and accounting of days off and
vacations of employees
Compilation of working regime given the
weekends and holidays
Accounting
replacements
and
unscheduled absence
Printing regime of work and schedule of
vocations by individuals, rooms (health
service provision points), by departments,
by facility
Printing statement on actually period of
work, vocation by individuals, rooms
(health service provision points), by
departments, by facility
Reference of services management. It
includes, at least:
Links with national index of services
Adding and removal of services out of
facility service reference
Service attaching to facility units
Review and printing of list of services for
each unit and facility
Interaction with accounting IS (at list with
«1C» software). It includes, at least:
Data transfer on new specialists
Data transfer on changed positions
Data transfer on worked days (hours)
Data exchange on vocations of specialists
Requirements to System configuration
261
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
262
R3.1
R3.1.1
R3.1.2
R3.1.3
R3.1.4
R3.1.5
R4.1
R4.2
Section VI. Technical Requirements
Configuration to health facility needs
Delivered system shall contain mandatory
modules in its composition in accordance
with Table 1, depending on the type of
health facility: Hospital, Policlinic, Mixed
type (Hospital+ Policlinic) (see also
R1.17-R1.18)
The System shall provide ability to
control access to functionality based on
roles. The system shall allow to add /
delete / edit the role and assign / cancel
the right of access to the system
functionality
The System shall have preset role in
accordance with Table 3, with further
changes (adding new roles, edit or delete).
Access rights to different modules and
functions of the System shall be preinstalled in accordance with Table 4 with
the ability to change access rights (add,
delete)
Access right shall be configurable at least
on the following aspects: all rights, to
create, to modify, to delete, to view
Patient search by name or IIN and patientrelated data (results of the survey, the
results of laboratory tests, etc.) shall take
no more than 3-5 seconds for 80% of
cases
Potential Supplier during warranty period
shall ensure the functioning of the
following options:
М
М
М
М
М
M
М
Section VI. Technical Requirements
R4.2.1
R4.2.2
R5
R5.1.
R5.2.
R5.3.
R5.4.
R5.5.
R5.6.
R5.7.
R5.8.
The total downtime of System for the
reason related to its operability shall not
exceed 24 hours per year.
Onetime of System downtime for the
reason related to its operability shall not
exceed 2 hours.
Requirements to Informational Security
Security requirements are defined by
current legislation of the Republic of
Kazakhstan. The system shall meet
requirements of information security to
ensure access threshold, protection from
unauthorized access, etc.
The system shall provide protection of
information from unauthorized access,
namely:
User authentication based on checking the
name (login) and password
Ability to identify user based on digital
certificates of open key infrastructure
User authorization for access to system
information and computing resources
requiring appropriate permissions
Personalized definition of the rights of
users to input , corrections , viewing of
data
Personalized definition of the rights of
users to access system resources
Differentiation of system user rights by
roles, groups and access levels based on
hierarchy of objects and attachment to
organizational structure.
263
М
М
M
M
M
M
M
M
M
M
264
R5.9.
R5.10.
R5.11.
R5.12.
R5.13.
R5.14.
R5.15.
R5.16.
Section VI. Technical Requirements
Logging of users work with system
critical features and applications
Protect the system files from modification
/ damage by unauthorized users and
software processes
Control log shall be maintained of all
updates of the system software libraries
The system shall implement at least the
following backup:
- Automatic backup with option to plan it
- Remote control over backup making
- Full and partial backups
The system shall ensure data integrity.
The system shall provide tools for
encrypting sensitive data during storage
and during transmission to other systems.
Digital signature (registration certificate
of user by National Authorizing Center of
the RK) shall be issued by NAC RK. The
system shall provide the tools for digitally
signing of documents (objects) or portions
of documents, when / if it is needed, and
the tools for authenticating signatures.
This feature shall be implemented in
system services (if necessary). To ensure
confirmation
of
digital
signature
authenticity and validity of opened key of
digital signature, the System shall provide
check for e-signature authenticity using
services of NAC RK
(http://pki.gov.kz/index.php/ru/)
System shall comply with the principle of
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R5.17.
R5.18.
"single access point" - the architecture of
the information infrastructure allows to
have a common access point (technology
Single Sign On) to all its components and
resources that allows you to enter the
username and password once and gain
access to all system components without
re-entering the password.
The System shall provide authorization of M
users in the system, distinction between
the rights of users of the system by roles,
groups and access levels based on
hierarchy of objects and accessories to
organizational structure.
In accordance with legal and technical M
documentation for information security,
approved by the MHSD RK the following
shall be implemented:
- The length of the password shall be at
least 8 characters, numbers and letters
shall be present in upper and lower case;
- Forced password change function;
- Barring use as a password of "empty"
password;
- password change independently by user;
- If wrong password is entered more than
three times CAPTCHA method shall be
implemented;
- Journal of logging activities of all users
for viewing the history of changes of main
event of the System;
- Function of interrupting session when
265
266
R6
R6.1.
R6.2.
R6.3.
R6.4.
R6.5.
R6.6.
R6.7.
R6.8.
Section VI. Technical Requirements
inactive after N period of time.
Requirements to System quality attributes
The system shall support input,
transmitting and receiving data necessary
for operation of MOH information
systems used by the health facility and
eliminating the needs to re-enter data.
The system shall ensure preservation of
all accumulated information at the time of
the refusal or failure in case of failure of
any component of the system, regardless
of its destination, with recovery of data
after repair and restoration works
The system shall have flexibility to
change settings in external environment
and specific user tasks without replacing
modules.
The system shall be highly scalable and
allow to work in an unlimited number of
users. Constraints can be driven only by
technical characteristics of the equipment,
not by characteristics of System
All functional capabilities of the system
shall be designed in the form of services.
Web services of the System shall be
designed in accordance with SOA
architecture.
When implementing services interaction it
is necessarily stick to the standard of
MHSD RK concerning information
systems interaction
The system shall enable construction of
M
M
M
M
M
M
М
M
Section VI. Technical Requirements
R6.9.
R6.10.
R6.10.1
R6.10.2
R6.10.3
R6.10.4
R6.10.5
R6.10.6
templates for approved medical forms
available within the solution itself, which
can be automated without programming or
changes of the program code.
The system shall be capable of resolving
conflicts when parallel processing system
objects.
Requirements for user interfaces
The interface shall be designed for the
preferential use of manipulator "mouse" ,
i.e., the system control shall be carried out
using a set of on-screen menu, buttons,
icons and similar items
Keyboard input mode shall be used
primarily during filling and / or editing
text and numeric fields screen forms. It
shall also provide hotkeys to switch
between filled files.
Ergonomic solutions and interface design
as much as possible shall be uniform for
all system components and modules
User interface systems shall be
multilingual and organized with the
support of at least state (Kazakh) and
Russian languages. Exceptions can only
be system messages not localized or
standard administrative applications that
make up the system software
Access
to
electronic
operational
documentation shall be available
The context- sensitive help system shall
be implemented in the System, accessible
267
M
M
M
M
M
M
M
M
268
R6.10.7
R6.10.8
R6.10.9
R6.10.10
R6.10.11
Section VI. Technical Requirements
from any web application, where links
shall be submitted to information (user
manual , instructions , etc.), with
possibility of configuration without
involvement of potential suppliers at the
Purchaser level;
The UI system shall provide visual
selection of screen attributes which are
available to the operator as read-only
The UI system shall provide visual
selection of screen attributes which are
mandatory for filling in
The system shall ensure correct handling
of emergencies caused by incorrect user
actions, incorrect format or invalid values
input. In these cases the system shall give
the user a relevant message, and then
return to the operating state prior to
incorrect (invalid) command or data entry
System shall not allow duplication and
repeated
(incorrect)
input
of
homogeneous information. The system
should ensure elimination of duplication
and re-enter the information contained in
public databases and information systems
of state bodies
The system shall provide the formatlogical control of input data for all values
in the system. Format logical control of
entered data means control over format
and content of entered data. The System
shall provide protection against erroneous
M
M
M
M
M
Section VI. Technical Requirements
R7
R7.1.
R7.1.1
R7.1.2
R7.2.
R7.2.1
actions:
- Choose only available to the user (in
accordance with permissions) functions;
- Enter only available to the user (in
accordance with permissions) data values;
- Input only certain format (eg, inability to
input character data in the format field
"Date" or "Number").
Requirements to System interoperability
General
Requirements
to
System
interoperability
System solutions and application shall M
meet standards of interoperability,
including national standards and accepted
international standards listed in this
chapter (and in this document).
System components must conform to the M
national instruments of semantics:
o References and classifiers
o Requirements for reference services
o Requirements for registers and registers
services
o Requirements for resource management
and accounting
Details on the requirements for these
instruments are given later in this section
(R7.3).
Compliance with standards
System components shall be compatible at M
least with the following standards of
MHSD RK:
1) Standard requirements for the
269
270
Section VI. Technical Requirements
electronic health record (requiring
compliance with EN 13940 )
2) Standard requirements for electronic
medical records (requiring compliance
with EN 13940 )
3)
Standard
requirements
for
identification of stakeholders of health
systems used in e-health systems
4) Technical requirements for the
interaction (communication) with the
information systems of e-health
5) Regulation on information
6) Standard requirements for single
classifier of medicines, medical devices
and medical equipment
7)
Standard
requirements
for
implementation and management of
electronic directions
8) Regulation of interaction of
stakeholders in order to ensure
interoperability of information systems
and information management
9) Standard for regulation of e-receipts
management
10) Standard for management of eprocesses of diagnostic studies and cure
procedures
11) Standard for regulation of epreventing of diseases
These standards and regulations are
available
on
https://www.mzsr.gov.kz/node/319759
Section VI. Technical Requirements
R7.2.2
R7.2.3
R7.3.
R7.3.1
R7.3.2
System components shall be compatible
with following international standards:
a. EN 13940(regarding the need to comply
with EHR and EMR)
b. HL7 v3 (ISO/HL7 27831), HL7 (v2 or
V3 or FHIR);
c. HL7 CDA R2 (ISO/ HL7 27932)
d. DICOM
the System shall meet the requirements of
standards on Information Security:
- ST RK ISO /IEC 27001-2008 «Security
assurance methods and means for
Information
Security
Management
System. Requirements»;
- ST RK ISO /IEC 27002-2009
«Information Technology. Support means,
Code of rules on information protection
management
Requirements for compatibility with
national
standard
identifiers
and
classifiers / references
System components shall support and
comply with the national identifiers:
- Patient Identifier
- Identifier of health facilities
- Identifier of health specialists
- Identifier of medical equipment
System components shall support and
comply with at least the following
national classifiers and references:
1) The National Classification of
medicines and medical supplies (mapped
271
M
M
M
M
272
R7.4.
R7.4.1
Section VI. Technical Requirements
to the ATC-DDD)
2) Classification of health services (based
on ICD-9, a section on services and
manipulations)
3) Classification of laboratory results
4) Classification of services and their
costs
5) Classification of diagnoses (ICD- 10)
6) Classification of primary care (ICPC2)
7) Mapping of ICPC- 2 and ICD-10
8 ) SNOMED, (only for the purpose of
coding the connection between the System
and EHR Repository)
9) Improved classification system must be
determined at a later stage to control
diagnostic services;
10) Realized by MHSD national DRG
system for classifying patients (for
specialized care);
11) Classification of registers of target
groups of patients (dispensary group)
12) care tarrificator;
13) Specialties in healthcare
14) List of positions
Requirements
to
compatibility
/
correspondence of data
System components shall provide a link M
between systems and National Health
Information and Interoperability Platform
containing Repository EHR based on the
following data:
Section VI. Technical Requirements
R7.4.2
R7.4.3
R7.4.4
R7.4.6
R7.5.
R7.5.1
- The minimum data set for EHR (set in
National Standards for EHR and EMR)
- Other data not covered by semantic
standards, but necessary under the
normative legal acts of the MHSD, such
as Attached Special Records (documents
based on CDA)
The system shall provide access to data
stored in the EHR repository, according to
two types of EHR: Full EHR, short EHR.
Details are described in National Standard
for EHR.
Data is transferred between the system
and Repository EHR in CDA format
Information transmitted in the EHR
repository is organized on the basis of
ICPC- 2 codes that are used in encounters
(and contacts in general) and mapped to
the ICD-10 for the purpose of statistics
collecting. In EMR information systems
(except EHR/ PHC systems) professionals
use ICD-10 for diagnosis coding and
mapping in the reverse direction is not
required, but desirable.
The system shall be opened enough to be
able to provide interoperability with
existing IS, applications and services of IS
MHSD (see also Section 1.4.2).
Requirements to information exchange
The system shall interact with national
system of EHR according to National
standards for EHR and EMR
273
M
M
M
M
M
274
R7.5.2
R7.5.3
R7.5.4
Section VI. Technical Requirements
The system shall support (at least) M
interaction with the following sets of
services of e-health:
- Services of EHR Repository;
- Services of reference information;
- Services of registration and registers;
- Services of Clinical Nomenclature and
classification of data;
- Services of safe exchange of data and
messaging;
- Services of identification and
authentication;
- Services for the monitoring and auditing
of information exchange.
The system shall correspond to at least M
following profiles of IHE
a) Infrastructural profiles of IHE:
- ATNA;
- XDS.b;
- PDQ;
- PIX;
b) lab profiles of IHE:
- LBL;
- LWT.
The system should provide opportunities М
for interaction / integration with at least
the following protocols and specifications:
- Communication via SOAP (SOAP
message and application), REST, Message
Transmission Optimization Mechanism;
- Support for standards and specifications
of Web services (WS-Security, WS-
Section VI. Technical Requirements
R7.5.5
R7.5.6
R7.5.7
Addressing, WS-Reliable Messaging,
WS-coordination, WS-Transaction, WSSecure Conversation);
- meet the standards of XML (XML, XSL,
ebXML, and others.);
- maintain SSO and access control across
the SAML v2, JWT;
- supports common standards such as
HTTP, HTTPS, TCP / IP, the protocols
Secure Sockets Layer (SSL v3) and TLS;
- allowing the use of WSDL, WADL;
- X.509;
 - The digital signature (of NAC
RK).
the system shall support coding of at least М
UTF8
The system shall interact with the М
Platform services at channel speed of 1
Mb / s and the response time less than 100
ms
The system shall interact with Platform М
services in terms of:
- transmit / receive notifications and other
information of informative character on
the gateway of "electronic government";
- sending of SMS-notifications, and other
types of distribution via SMS gateway of
system of mobile government;
- sending emails to patients through a
single e-mail system;
- information about the powers of attorney
out of the state information system Single
275
276
R8
R8.1.
R8.2.
R8.3.
R8.4.
Section VI. Technical Requirements
Notary Information System;
- obtain information from the records to
the doctor;
- obtain minimal information about the
employee.
Use of national e-health resources and HII
Platform tools
System shall be able to operate in line
with general e-health architecture (Pic 2)
The system shall be able to use
functionality and web services, published
at the national level to communicate with
e- Health resources
The system shall be able to use EHR
repository, national classifications and
indexes (at least, Master Patient index,
index of health facility units, healthcare
professional index, index of buildings,
address index, index of motor vehicles,
medical equipment index), analytical
repository and other national resources
required for integration of " turn-key "
according to national standards (listed in
MoH order No. 75 from 10.02.2014)
The system shall maintain local copies of
national resources and be able to
synchronize them on a regular basis (in
accordance with a custom schedule) or
online. The system shall contain only
information relating to the activities of
health facility. For example, Master
patient index shall be kept locally for only
M
M
M
M
Section VI. Technical Requirements
R9
R9.2.
R9.3.
R9.4.
the list of patients served by this health
facility.
Interaction with parties involved into
certification process
System Supplier shall interact with the M
HII platform supplier, health facility and
MHSD for testing and certification of
interoperability with national resources
and services.
System supplier shall coordinate the M
interaction of the parties involved in
accordance with Figure 3. Certification
means to verify the installed system for
compliance with R7.2. The Client
authorizes a special commission, which
together with the Platform provider and
the supplier of the system, shall conduct
tests on compliance to standards of
MHSD RK, to meet the requirements of
interoperability in accordance with
national standards, including the ability of
correct interaction of delivered system
with national resources available within
the Platform.
At the phase of System design (action 4.4) M
the Supplier shall comply with the "Rules
for Web Services development" and
"Requirements for interaction with the
EHR Repository" provided by the
Supplier of the HII Platform. Supplier of
System
may
request
additional
information if necessary to develop
277
278
R9.5.
R9.6.
R9.7.
R10
R10.1.
R10.2.
R10.3.
Section VI. Technical Requirements
interaction with e-Health resources.
During the testing / certification phase
(action 4.6) System Supplier shall meet
requirements and standards of e-health
R7.2.
The Supplier shall certify the System
before its acceptance into operation
In case of circumstances that hinder
fulfillment of R9.6 occurred by no fault
from Supplier’s party, Acts of System
acceptance shall be signed without
certification. With it, System Supplier is
bounded to certify the System when
conditions for certifications appear,
without any additional costs from the
Purchaser’s party
Requirements to Suppliers
Supplier shall supply his own System
(components or products of its) or be
authorized by the developer / owner of the
System (components or products of its) to
provide, design, installation, maintenance
of production in accordance with this
Contract.
Supplier shall provide training in
Purchaser’s country, associated with the
operation and administration of the
system, as well as for all developed and
installed products. Language of trainings
will be the state and Russian. Details on
training given in R12.2
Supplier shall have an office in the
M
M
M
M
M
M
Section VI. Technical Requirements
R10.4.
Purchaser's country or have a partner that
is registered as a legal entity in the
Purchaser's country having official status
of a developer / provider partner, or
having a consortium agreement associated
with this Contract. This is necessary
during the implementation, deployment,
training, and warranty period for smooth
and reliable implementation of the
Contract.
Supplier shall have team of experts for the M
Project, consisting of at least the
following specialists (if necessary, two
positions can be taken by one person,
provided that the skills will be proved, but
no more than 2 positions per a specialist):
1) Business Analyst with experience of at
least 3 years in IT projects in e-health and
experience in at least one similar project;
2) Project manager (team leader), with
experience of at least 3 years in project
management and experience of more than
1 year in the project, with proposed
solution, Project manager shall be
certified in project management (eg, PMP
or IPMI);
3) Specialist on DBMS who has at least 3
years of experience with database work;
4) professionals with experience in work
with standards for at least 2 years: HL7,
DICOM, CDA (R2), IHE;
5) User Interface Designer, with
279
280
Section VI. Technical Requirements
experience of at least 3 years;
6) Technical writer, who has worked for
at least 2 years;
7) Specialist on Relations with experience
in this area and at least 3 years of general
experience in IT, with an excellent
command of English, Russian and Kazakh
languages;
8) Specialist on Testing with at least 3
years of experience in software testing;
9) Specialist on Training with at least 3
years of experience in education;
All proposed experts shall have a degree
in IT or related fields, Master's degree
preferred. The Supplier shall submit a list
of experts, with applied resumes,
certificates to prove the experience and
qualifications.
R10.5.
R10.6.
the Supplier shall provide all documents M
(patents, licenses, certificate of state
registration of rights to the object of
copyright, etc.) on the System (for all
components and products), demonstrating
the owner's permission to use the products
for the contract or demonstrate ownership
of the products
Plan - schedule of services shall be M
authorized by the Purchaser and signed by
the Purchaser within twenty (20) business
days after signing the contract. Supplier
shall promptly provide services by
Section VI. Technical Requirements
R10.8
R10.9
R10.10
R10.11
R10.13
approved schedule.
Vendors must be certified for Capability
Maturity Model Integration (CMMI), ISO
9000 series, ST RK ISO 9001: 2009 or
equivalent for quality management
(Bidder shall submit copies of Certificate
on compliance issued by the authorized
body).
The Supplier shall provide service and
technical support and warranty, including
new versions of the products in
accordance with the R12.3 and R12.4.
The Supplier shall prepare appropriate
guidance for all components of the
System in English, Kazakh and Russian
languages
The Supplier shall have proven track
record of working with the standards used
in this document: HL7 (v2, V3, FHIR),
CDA (R2), IHE
System Supplier shall have access to
national resources of e-Health only after
the parallel contract is successfully
implemented. In order to facilitate parallel
implementation it is necessary to
synchronize / coordinate joint actions with
the
Platform
provider.
If
the
circumstances do not allow to meet the
requirements for interaction with the
Platform due to delayed implementation
of contract for delivery of Platform, the
System Supplier undertakes to implement
281
M
M
M
M
M
282
R11
R11.1.
R11.2.
R11.3.
R11.4.
R11.5.
R11.6.
R11.7.
R11.8.
R12
R12.1.
Section VI. Technical Requirements
the interaction, when there will be
conditions, without additional cost to the
Purchaser.
GENERAL
TECHNICAL
SPECIFICATIONS TO THE SYSTEM
System shall be able to work with a local
server via a local area network used in one
health facility
The server part of System shall be running
at least on Windows operating systems
family.
The client part of the System shall be
running at least in the operating systems
of Windows (2008/VISTA/7/8) (x86/x64)
A relational database shall be used to save
the information in the system
Database systems shall support the
standard SQL, compliant with the ANSI /
ISO / IEC 9075-1992
Supplier shall provide service and
technical support, including provision of
new product releases prior to the
expiration of warranty service.
The system shall provide the ability to
operate on a remote infrastructure and
cloud
(virtualized)
Operating
Environment
The System shall provide an option of
authentication using SSO technology
Specification of services
Requirements to inherit data and
functionality.
M
M
M
M
M
M
M
M
Section VI. Technical Requirements
R12.1.1
R12.1.2
R12.2.
R12.2.1
R12.2.2
R12.2.3
R12.2.4
In the case of supply and implementation
of the System different from those
operating by the Purchaser the Supplier
provides a full range of necessary work on
the inheritance of data and functions of
the Information System modules used by
the Purchaser with connection to the
System of used by the Purchaser software
and hardware means of automatization,
medical and laboratory equipment.
All costs associated with providing
inheritance of data and functionality are
paid by Supplier.
Trainings and training materials
The Supplier shall prepare a training plan
for the following groups:
a. System users;
b. System admins
c. developers,
d. admins of databases.
Training plan and training materials for
each group shall be agreed with the
Purchaser prior to the training start.
The Supplier shall provide equipment,
presentation materials, and guidelines
needed for training
System Supplier shall provide educational
materials in the form of manuals, books,
presentations, knowledge bases in the
Kazakh and Russian languages.
Supplier shall provide training for at least
80 hours for each group of admins of the
283
M
M
M
M
M
M
284
R12.2.5
R12.2.6
R12.2.7
Section VI. Technical Requirements
System, developers, admins of database
and 20 hours for users of each health
facility, which implements systems. The
number of hours can be increased and
shall be sufficient for the transfer of
knowledge and skills
Supplier shall conduct a separate training M
for users and system administrators,
developers and admins of databases.
Indicative number of students is
determined by multiplying the total
number by 2 of general number of
workstations from Appendix 2. Location
of training - legal address of the
healthcare facility - the beneficiary.
Groups of students should include no
more than 10 people
Training plan for the group (a) - users of M
the system - shall contain a detailed
explanation of automated business
processes, the use of all components of
the system, a detailed description of the
functions and interactions between the
different users and roles; statements and
other necessary information. Training will
also include practical training for
understanding of the material.
Training plan for the group (b) - System M
administrators - shall contain description
of administration tools of system
components including the important
issues of systems support, and aspects of
Section VI. Technical Requirements
R12.2.8
R12.2.9
R12.2.10
R12.2.11
R12.2.12
R12.2.13
R12.3.
R12.3.1
technical support
The Supplier shall conduct for the group
(c) designers – one introductory course
and capacity building course on provided
tools of development and components
planned as part of this contract
The Supplier shall conduct for the group
(d) DB admins - one introductory and one
advanced training course on provided
DBMS
Training for groups (a) - (d) shall be
conducted in Russian or state language
specified by the Purchaser.
All trainings shall be conducted by
trainers in Astana or in another place
specified by the Purchaser
For all carried out training sessions, the
Supplier shall conduct the appropriate
tests and issue certificates
The above number and duration of
training are minimum requirements.
Supplier at the request of the Purchaser
can increase these values (in hours) to
achieve an adequate level of skills for the
staff at no additional cost to the Purchaser.
During the preparation phase of the
project the exact number of hours, groups
and content of the courses will be agreed
with the Supplier.
User Support Service
Supplier shall arrange a user support
service to advise on matters arising during
285
M
M
M
M
M
I
M
286
R12.3.2
R12.4.
R12.4.1
R12.4.2
R12.4.3
Section VI. Technical Requirements
the operation, for the duration of
implementation and warranty services
providing
Support System and its users should be
carried out by the Supplier in operation
regime of 24 hours a day, 7 days a week,
for 2 years from the date of signing the
acts system commissioning
Warranty service
Supplier of the System shall provide
warranty service to the Purchaser within
three years, starting immediately after
approval of the Operational Acceptance
Certificate by Purchaser
The Supplier shall provide the resolution
of queries:
a) for the critical issues relating to
operability of systems and leading to data
corruption, the problem should be solved
by no more than 2 hours;
b) for non-critical problems to 2 days
Warranty service will include, but not
limited to, following categories of
services:
- correction of errors in the System;
- help the health facility to correctly all
problems with data, arising as result of
mistaken function of applications;
- technical support in adjustment,
configuration of applications or changing
default parameters;
- provide necessary technical assistance to
M
M
M
M
Section VI. Technical Requirements
R12.4.4
R12.4.5
R12.4.6
R12.4.7
R13
R13.1
trained staff and re-train, if disclosed that
they cannot solve all problems after
received training;
The forms of intervention can be one of
the following most appropriate from the
viewpoint of quality and efficiency:
- telephone calls;
- e-mail;
- Skype or other video messenger;
- On-site work;
- Remote work.
The Supplier shall provide during the
warranty period a team of consultants
available in Purchaser’s country including
one manager and at least one specialist,
and provide all necessary specialists from
the distance for remote help (per needs).
The total System downtime due to reasons
related to its capacity for work should not
exceed 24 hours per year.
Time of a single system downtime due to
reasons related to its capacity for work
should not exceed 2:00
Requirements to documentation
The Supplier shall provide the following
documents:
- Program and methods of testing ;
Form
(main
characteristics,
completeness and information on the
operation of the deposited software);
- Description of the most common
mistakes and how to prevent them;
287
M
M
M
M
M
288
R13.2
R13.3
R13.4
Section VI. Technical Requirements
- Description of the structure of the
database;
- Guide to install the software;
- Administrator's Guide;
- User’s Guide.
Language of the document shall be at least M
the Kazakh and Russian.
The Supplier shall provide 5 sets of M
documents in paper and electronic form in
English, Russian and Kazakh languages.
Electronic versions should support the
ability to search basing on context
the Supplier shall prepare an information M
system and regulatory and methodological
documentation
for
attestation
for
compliance with information security
requirements in accordance with Article 5
of the Law of the Republic of Kazakhstan
dated
January
11,
2007
"On
Informatization" and Decree of the
Government of the Republic of
Kazakhstan dated December 30, 2009 №
2280 "On approval of Rules for provision
of certification of government information
systems and non-government information
systems
integrated
with
public
information systems for compliance with
information security requirements and
accepted on the territory of the Republic
of Kazakhstan standards "and to be
commissioned in accordance with Article
17 of the Law of the Republic of
Section VI. Technical Requirements
R14
R14.1
R14.1.1
R14.1.2
R14.1.4
R14.1.5
R14.1.6
R14.1.7
Kazakhstan dated January 11, 2007" On
informatization ".
System testing and Requirements to
Quality
Pre-commissioning
System Supplier shall perform standard
installation tests to verify the correctness
of System installation
Supplier shall offer in the technical offers
a list of tests, test conditions, success
criteria and other for the System testing.
Systems Supplier shall held detailed
milestone tests, including tests of
performance, response time, System
throughput, together with an organization
authorized by the Purchaser, according to
tests provided by the Supplier.
The supplier shall hold a demonstration of
the System with the participation of
representatives of the Purchaser and the
organization authorized by the Purchaser
according to the scenario of System
testing.
Suppliers shall draw up the demonstration
results in the form of demonstrations
Protocol agreed with the Purchaser. The
protocol shall be signed by all participants
of demonstration.
Place of demonstration shall be agreed
with the Purchaser and organization
authorized by the Purchaser.
The Supplier shall fix a troubles detected
289
M
M
M
М
М
М
290
R14.1.8
R14.1.9
R14.1.10
R14.1.11
R14.2
R14.2.1
Section VI. Technical Requirements
during the demonstration and repeat
demonstration as often as needed to have
a Protocol of successful demonstration.
Timeframe for fixing the troubles shall be
agreed with Purchaser.
Testing shall be conducted in accordance
with one of the standards IEEE 829/1009,
BS 7925, ISO / AS 9100 and developed
document "Program and methods of
testing" ST RK 1089-2002
The supplier shall test the system in
accordance with the Web Content
Accessibility Guidelines (WCAG) 2.0. the
Supplier
shall
provide
detailed
information on the results of testing
The Supplier shall test the system security
in accordance with the OWASP Top 10
vulnerabilities. Supplier shall provide
detailed information on the results of
testing
the Supplier shall agree with the
Purchaser the test script and provide a
report on the results of each test
Acceptance into operation
Certificate of acceptance is signed by the
Purchaser based on the trouble-free
operation under normal operating
conditions for the System within three
months. In case of errors in the
functioning of the period Supplier shall
make the necessary changes and reoperation of the system within three
М
М
М
М
M
Section VI. Technical Requirements
R14.2.2
R14.2.3
R15
R15.1
R15.2
months. Operating errors are critical
errors which do not allow to run the
System
The Supplier must commence the work
necessary to remedy defects or damage
within 10 working days for non-critical
errors. For critical errors the supplier must
commence the work necessary to remedy
defects or damage within 3 working days,
provide fixing time and report on fixing
progress hourly during the operational as
well as warranty period.
Critical errors: System is not operational
or stable. Important functional component
is down or un-available. Loss of Data or
interruption in the main process flow.
System component unusable due to failure
or incorrect functionality. Users are not
able to perform any work
Mandatory condition for acceptance into
operation is certification of the System
pursuant to requirements of R.9
Requirements to control assurance by the
Purchaser
Supplier shall at intervals specified in the
schedule provide Purchaser a progress
report during the period.
The report shall contain information on
the works of the Supplier for the period, in
accordance with the approved schedule
including warranty service with attached
approved documents, including official
291
M
M
М
М
292
R15.3
R15.4
Section VI. Technical Requirements
correspondence in paper and electronic
form (at least in PDF format).
The report shall be agreed with М
organization authorized by the Purchaser.
Purchaser may at any time of the Contract М
implementation carry out control over the
contract to check Supplier measures and
quality of services under the contract
Section VI. Technical Requirements
293
H. Annexes
Annex 1
Roles’ access right to Modules functions
1.
1.1.
Module «Reception»
Roles
Management of doctors’ work schedule, service Schedule composer
provision, equipment use time
Medical receptionist
Chief nurse
Head of outpatient clinic department
1.2.
Registration of a patient for doctor’ examination, to Patient (through Internet)
hand out a card for exam
District doctor
Doctor from preventive medicine
department
Profile specialist
Medical receptionist
1.3.
Management of Register for calls at home
Medical receptionist
District doctor
Profile specialist
Head of outpatient clinic department
Chief nurse
1.4.
Management of Registers for active information Medical receptionist
(calls at home initiated by medical men)
District doctor
Head of outpatient clinic department
Chief nurse
1.5.
Management of primary accounting documentation Medical receptionist
at Reception level according to regulatory papers
District doctor
Doctor from preventive medicine
department
Profile specialist
Head of outpatient clinic department
293
294
Section VI. Technical Requirements
Chief nurse
1.6.
Making analytic tables at Reception level and Medical receptionist
statistic tables according to regulatory acts
District doctor
Doctor from preventive medicine
department
Profile specialist
Hospital administrator
Medical statistician in polyclinic
Head of outpatient clinic department
Chief nurse
2.
Module «District doctor»
2.1.
Patient’s ambulatory card
District doctor
Doctor from preventive medicine
department
Profile specialist
District doctor’s nurse
Profile specialist
Head of outpatient clinic department
2.2.
Generation of referrals to consulting and diagnostic District doctor
services internal (within one health facility) and Doctor from preventive medicine
external (in other health facilities)
department
Profile specialist
District doctor’s nurse
Head of outpatient clinic department
2.3.
Creation of planned hospitalization (24 hour hospital District doctor
and substitute technology)
Doctor from preventive medicine
department
Profile specialist
District doctor’s nurse
Head of outpatient clinic department
Section VI. Technical Requirements
2.4.
295
Creation of doctor’s prescriptions for drugs and/or District doctor
procedures and manipulations
Profile specialist
Head of outpatient clinic department
2.5.
Management of primary accounting documentation District doctor
at district doctor level according to regulatory acts
Doctor from preventive medicine
department
Profile specialist
District doctor’s nurse
Head of outpatient clinic department
2.6.
Making analytic tables at district doctor level and District doctor
statistic tables according to regulatory acts
Doctor from preventive medicine
department
Profile specialist
Nurse
Head of outpatient clinic department
Medical statistician in polyclinic
2.7.
Management of temporary disability leave
District doctor
Profile specialist
Head of outpatient clinic department
2.8.
Interoperability with IS MHSD RK relating to data
exchange on performed services, clinical
information, referrals, prescriptions according to
regulatory acts
3.
Module «Preventive examinations»
3.1.
Making up cohorts of targeted groups subject to District doctor
preventive exam (screening) and registering its Doctor from preventive medicine
performance according to regulatory acts
department
Profile specialist
Nurse from preventive medicine
department
Head of outpatient clinic department
295
296
3.2.
Section VI. Technical Requirements
Registration of other type preventive exams
District doctor
Doctor from preventive medicine
department
Profile specialist
Nurse from preventive medicine
department
Head of outpatient clinic department
3.3.
Management of primary accounting documentation District doctor
at doctor level according to regulatory acts
Doctor from preventive medicine
department
Profile specialist
Nurse from preventive medicine
department
Head of outpatient clinic department
4.
Module «Profile specialist »
4.1.
Patient’s ambulatory card
Profile specialist
Specialist’s nurse
Head of outpatient clinic department
4.2.
Generation of referrals to consulting and diagnostic Profile specialist
services internal (within one health facility) and Specialist’s nurse
external (in other health facilities)
Head of outpatient clinic department
4.3.
Creation of doctor’s prescriptions for drugs and/or Profile specialist
procedures and manipulations
Head of outpatient clinic department
4.4.
Management of primary accounting documentation Profile specialist
at profile specialist level according to regulatory
Nurse
acts
Head of outpatient clinic department
4.5.
Management of temporary disability leave
Profile specialist
Head of outpatient clinic department
4.6.
Making analytic tables at profile specialist level and Profile specialist
statistic tables according to regulatory acts
Section VI. Technical Requirements
297
Head of outpatient clinic department
Hospital administrator
Medical statistician in polyclinic
5.
Module «Head of Polyclinic department»
5.1.
Confirming or rejection for referrals for some types Head of outpatient clinic department
of services by using digital signature
5.2.
Management of primary accounting documentation Head of outpatient clinic department
at the level of Head of Polyclinic department
according to regulatory acts
5.3.
Making analytic tables at the level of Head of Head of outpatient clinic department
Polyclinic department and statistic tables according Medical statistician in polyclinic
to regulatory acts
5.4.
Approval
for
temporary
management of MCB records
6.
Module «Medical statistics in Polyclinics»
6.1.
Monitoring of primary accounting documentation Medical statistician in polyclinic
management in a health facility
Head of outpatient clinic department
disability
leave, Head of outpatient clinic department
Hospital administrator
6.2.
Making analytic tables at the level of Medical Medical statistician in polyclinic
statistician in polyclinic and statistic tables Head of outpatient clinic department
according to regulatory acts
Hospital administrator
7.
Module «Admission»
7.1.
Registration of patients admission
Doctor from Admission
Nurse from Admission
Head of hospital department
7.2.
Management of patients EMR
Doctor from Admission
Nurse from Admission
Head of hospital department
297
298
7.3.
Section VI. Technical Requirements
Clarification of
hospitalization
services
performed
before Doctor from Admission
Nurse from Admission
Head of hospital department
7.4.
Management of primary accounting documentation Doctor from Admission
at Admission level according to regulatory acts
Nurse from Admission
Head of hospital department
Medical statistician in hospital
7.5.
Making analytic tables at Admission level and Doctor from Admission
statistic tables according to regulatory acts
Nurse from Admission
Head of hospital department
Medical statistician in hospital
7.6.
Interoperability with MOH IS
8.
Module «Doctor in hospital»
8.1.
Patient’s EHR management
Doctor in hospital
Head of hospital department
8.2.
8.3.
Management for referrals
diagnostic services
to
consulting
Diagnosis
and Doctor in hospital
Head of hospital department
Doctor in hospital
Head of hospital department
8.4.
Creation of doctor’s prescriptions for drugs and/or Doctor in hospital
procedures and manipulations
Head of hospital department
8.5.
Patient discharge
Doctor in hospital
Head of hospital department
8.6.
Making analytic tables at doctor level
Doctor in hospital
Head of hospital department
Medical statistician in hospital
8.7.
Management of primary accounting documentation Doctor in hospital
Section VI. Technical Requirements
at hospital doctor level
299
Head of hospital department
Medical statistician in hospital
9.
Module «Nurse in hospital»
9.1.
Patient’s EHR management
Nurse in hospital
9.2.
Mark on performed prescription and treatment
Nurse in hospital
9.3.
Monitoring of patient’s state
Nurse in hospital
9.4.
Management of primary accounting documentation Nurse in hospital
at hospital nurse level
9.5.
Making analytic tables at nurse level and statistic Nurse in hospital
tables according to regulatory acts of the RK
Medical statistician in hospital
10.
Module «Meals»
10.1.
Make up a daily menu
Doctor in hospital
Head of hospital department
Nurse in hospital
Specialist in nourishment department
10.2.
Calculator of every day, month spending of food for Specialist in nourishment department
menu
10.3.
Estimation of food value in ration
Specialist in nourishment department
10.4.
Making up the reference for main food products
Specialist in nourishment department
10.5.
Patients’ diet management
Specialist in nourishment department
10.6.
Making up analytic tables for food
Specialist in nourishment department
Medical statistician in hospital
11.
Module «Day hospital»
11.1.
Patient’s EMR management
Doctor in hospital
Nurse in hospital
299
300
Section VI. Technical Requirements
Profile specialist
Specialist’s nurse
Head of outpatient clinic department
Head of hospital department
11.2.
Making up referrals to consulting and diagnostic Doctor in hospital
services
Profile specialist
Head of outpatient clinic department
Head of hospital department
11.3.
Registration of prescriptions and execution
Doctor in hospital
Nurse in hospital
Profile specialist
Specialist’s nurse
Head of outpatient clinic department
Head of hospital department
11.4.
Management of primary accounting documentation Doctor in hospital
at day hospital level according to regulatory Nurse in hospital
documents
Profile specialist
Specialist’s nurse
Head of outpatient clinic department
Head of hospital department
11.5.
Making analytic tables at day hospital level and Doctor in hospital
statistic tables according to regulatory acts
Nurse in hospital
Profile specialist
Specialist’s nurse
Head of outpatient clinic department
Head of hospital department
11.6.
Interaction with MOH IS
12.
Module «Head of hospital department»
12.1.
Confirming or rejection for referrals for some types Head of hospital department
Section VI. Technical Requirements
301
of services by using digital signiture
12.2.
Management of primary accounting documentation Head of hospital department
at the level of Head of hospital department
according to regulatory acts
12.3.
Making analytic tables at the level of Head of Head of hospital department
hospital department and statistic tables according to
regulatory acts
12.4.
Approval of disability leave, medical consultation Head of hospital department
records
13.
Module « Hospital administrator »
13.1.
Making analytic tables at the level of Hospital Hospital administrator
administrator and statistic tables according to
regulatory acts
14.
Module «Medical statistics in hospital»
14.1.
Bed fund management
14.2.
Making analytic tables at the level of medical Hospital administrator
statistics office and statistic tables according to Head of hospital department
regulatory acts
Medical statistician in hospital
15.
Module «Procedures and manipulations»
15.1.
Patient’s EMR management
Medical statistician in hospital
Doctor in hospital
Nurse in hospital
Head of hospital department
15.2.
Management of primary accounting documentation Doctor in hospital
on provided procedures and manipulations Nurse in hospital
according to regulatory acts
Head of hospital department
15.3.
Making analytic tables on provided procedures and Doctor in hospital
manipulations and statistic tables according to Nurse in hospital
regulatory acts
Head of hospital department
301
302
Section VI. Technical Requirements
Medical statistician in hospital
16.
Module «Admin»
16.1.
Data Base management
16.2.
To make up user groups and some independent Admin
System users
16.3.
Management of authentication types (password, Admin
digital signiture)
16.4.
System logs management
Admin
16.5.
Adjusting patterns of medical documentation
Admin
16.6.
Adjusting user interface
Admin
16.7.
Adjusting user access
Admin
16.8.
Set-up of external programs connection
Admin
16.9.
Reference management
Admin
Admin
16.10. Report making, editing user Report Master
Admin
17.
Module “Lab Information System”
17.1.
Registration of received material with option to Technician
screening
Lab specialist
Doctor – laboratory assistant
17.2.
Bar-coding for material
identification by bar-code)
(making
bar-code, Technician
Lab specialist
Doctor – laboratory assistant
17.3.
Making up business sheets for lab analyzers and Technician
executors
Lab specialist
Doctor – laboratory assistant
17.4.
Interaction with lab equipment (export of referrals to
Section VI. Technical Requirements
303
examination, import of exam results)
17.5.
Manual entry of lab research results
Technician
Lab specialist
Doctor – laboratory assistant
17.6.
Confirmation for lab research results validity by lab Lab specialist
specialist
Doctor – laboratory assistant
17.7.
Quality control for lab studies (intralab, interlab, Lab specialist
external)
Doctor – laboratory assistant
17.8.
Option of results printing according to approved Technician
regulatory documents for primary accounting Lab specialist
documents
Doctor – laboratory assistant
17.9.
Making reference values for lab for all patients and Lab specialist
by age-sex groups
Doctor – laboratory assistant
17.10. Management of primary accounting documentation Technician
at lab level according to regulatory acts
Lab specialist
Doctor – laboratory assistant
17.11. Making analytic tables at lab level and statistic Technician
tables according to regulatory acts
Lab specialist
Doctor – laboratory assistant
Medical statistician in hospital
17.12. Option of system integration with independent Lab
IS
17.13. Transfer of information on made studies into EHR
and EMR
18.
Module
«PACS»
(Picture Archiving
and Communication System)
18.1.
Exchange of data with medical equipment
303
304
Section VI. Technical Requirements
18.2.
Interaction with other modules and systems basing on
rules for IHE profiles
18.3.
Image import/export
18.4.
Work with images
District doctor
Profile specialist
Head of outpatient clinic department
Doctor in hospital
Head of hospital department
18.5.
Making archive of images
19.
Module «Diagnostic studies»
19.1.
View of patients registered according to the Doctor from diagnostic department
schedule
Specialist’s nurse
Head of hospital department
19.2.
Entry of studies results using patterns
Doctor from diagnostic department
Specialist’s nurse
Head of hospital department
19.3.
Management of primary accounting documentation Doctor from diagnostic department
on diagnostic studies according to regulatory acts
Specialist’s nurse
Head of hospital department
19.4.
Making analytic tables on diagnostic studies and Doctor from diagnostic department
statistic tables according to regulatory acts
Specialist’s nurse
Head of hospital department
Medical statistician in hospital
19.5.
Data transfer on made studies into EHR and EMR
20.
Module «Pharmacy»
20.1.
Drug registration at different levels: point, room, Pharmacy technician
department, pharmaceutical storehouse (one of Pharmacist
several), health facility
Clinical pharmacologist
Section VI. Technical Requirements
305
20.2.
Automated charge-off drugs when the prescription is
executed
20.3.
Option to trace terms of drugs and medical devises Pharmacy technician
validity
Pharmacist
Clinical pharmacologist
20.4.
Option to form the list of drugs (medical devices) Pharmacy technician
required for procurement in health facilities
Pharmacist
Clinical pharmacologist
20.5.
Making requirements for pharmacy to procure drugs Specialist’s nurse
(automated urgent requirements for drugs)
District doctor’s nurse
Nurse in hospital
Pharmacy technician
Pharmacist
Clinical pharmacologist
20.6.
Getting information on availability of drug in health Specialist’s nurse
facilities
District doctor’s nurse
Nurse in hospital
Pharmacy technician
Pharmacist
Clinical pharmacologist
20.7.
Drug formulary management in health facility
Pharmacy technician
Pharmacist
Clinical pharmacologist
20.8.
Registration of side effect of drug according to
procedures set in regulation documents
District doctor
Profile specialist
Head of outpatient clinic department
Doctor in hospital
Head of hospital department
Doctor from diagnostic department
305
306
20.9.
Section VI. Technical Requirements
Monitoring of drug prescriptions
Clinical pharmacologist
20.10. Setting maximal doses for control over prescriptions Clinical pharmacologist
20.11. Registration of incoming and outcoming
documentation of the department and pharmacy
according to regulatory acts
District doctor’s nurse
Specialist’s nurse
Nurse in hospital
District doctor
Profile specialist
Head of outpatient clinic department
Doctor in hospital
Head of hospital department
Doctor from diagnostic department
20.12. Management of primary accounting documentation Pharmacy technician
at pharmacy level according to regulatory acts
Pharmacist
Clinical pharmacologist
20.13. Making analytic tables at pharmacy level and Pharmacy technician
statistic tables according to regulatory acts
Pharmacist
Clinical pharmacologist
Medical statistician in hospital
21.
Module «Human resources»
21.1.
Communication with national indexes
HR specialist
21.2.
Management of organizational structure of health
facility
HR specialist
21.3.
Management of doctor’s accounting card (health
facility employee)
HR specialist
21.4.
Management of work schedule
HR specialist
21.5.
Management of service references
HR specialist
21.6.
Interlink with Accounting IS
HR specialist
Section VI. Technical Requirements
307
Annex 2
Approximate composition and quantity of System Modules for health facilities
Municipal hospital №1 Ust-Kamenogorsk city
Module
Quantity of AWP
Module «Reception »
Module «District doctor»
Module «Prophylactic exams»
Module «Profile specialist»
Module «Head of Policlinic department»
Module «Medical statistics of policlinic»
Module «Admission»
8
Module «Hospital Doctor»
72
Module «Hospital nurse»
42
Module «Meals»
5
Module «Day-hospital»
8
Module «Head of hospital department»
25
Module «Hospital administrator»
6
Module «Medical Statistics for Hospital»
10
Module «Procedures and manipulations»
25
Module «Admin»
5
Module «Lab IS»
17
307
308
Section VI. Technical Requirements
Module «PACS» (Picture Archiving
and Communication System)
8
Module «Diagnostic studies»
17
Module «Pharmacy»
5
Module «Human Resources»
5
Total
258
Municipal Clinic Hospital №4 Almaty city
Module
Quantity of AWP
Module «Reception »
Module «District doctor»
Module «Prophylactic exams»
Module «Profile specialist»
Module «Head of Policlinic department»
Module «Medical statistics of policlinic»
Module «Admission»
15
Module «Hospital Doctor»
31
Module «Hospital nurse»
12
Module «Meals»
2
Module «Day-hospital»
3
Module «Head of hospital department»
13
Module «Hospital administrator»
7
Module «Medical Statistics for Hospital»
6
Section VI. Technical Requirements
309
Module «Procedures and manipulations»
13
Module «Admin»
2
Module «Lab IS»
5
Module «PACS» (Picture Archiving
and Communication System)
4
Module «Diagnostic studies»
4
Module « Pharmacy»
2
Module «Human Resources»
4
Total
123
Mother and Child Center Ust-Kamenogorsk city
Module
Quantity of AWP
Module «Reception »
15
Module «District doctor»
11
Module «Prophylactic exams»
32
Module «Profile specialist»
32
Module «Head of Policlinic department»
5
Module «Medical statistics of policlinic»
8
Module «Admission»
34
Module «Hospital Doctor»
75
Module «Hospital nurse»
48
Module «Meals»
8
Module «Day-hospital»
13
309
310
Section VI. Technical Requirements
Module «Head of hospital department»
22
Module «Hospital administrator»
1
Module «Medical Statistics for Hospital»
12
Module «Procedures and manipulations»
26
Module «Admin»
4
Module «Lab IS»
18
Module «PACS» (Picture Archiving
and Communication System)
11
Module «Diagnostic studies»
16
Module «Pharmacy»
9
Module «Human Resources»
5
Total
405
Municipal Policlinic №11 Almaty city
Module
Quantity of AWP
Module «Reception »
10
Module «District doctor»
31
Module «Prophylactic exams»
6
Module «Profile specialist»
37
Module «Head of Policlinic department»
13
Module «Medical statistics of policlinic»
11
Module «Admission»
-
Module «Hospital Doctor»
-
Section VI. Technical Requirements
311
Module «Hospital nurse»
-
Module «Meals»
-
Module «Day-hospital»
3
Module «Head of hospital department»
Module «Hospital administrator»
9
Module «Medical Statistics for Hospital»
-
Module «Procedures and manipulations»
6
Module «Admin»
1
Module «Lab IS»
10
Module «PACS» (Picture Archiving
and Communication System)
Module «Diagnostic studies»
5
Module «Pharmacy»
1
Module «Human Resources»
2
145
Total
Regional Diagnostic Center Almaty city
Module
Module «Reception »
Quantity of AWP
9
Module «District doctor»
Module «Prophylactic exams»
Module «Profile specialist»
32
Module «Head of Policlinic department»
10
311
312
Section VI. Technical Requirements
Module «Medical statistics of policlinic»
8
Module «Admission»
1
Module «Hospital Doctor»
6
Module «Hospital nurse»
3
Module «Meals»
1
Module «Day-hospital»
7
Module «Head of hospital department»
1
Module «Hospital administrator»
4
Module «Medical Statistics for Hospital»
1
Module «Procedures and manipulations»
1
Module «Admin»
2
Module «Lab IS»
7
Module «PACS» (Picture Archiving
and Communication System)
6
Module «Diagnostic studies»
37
Module «Pharmacy»
1
Module «Human Resources»
2
139
Total
Policlinic №1 Kostanay
Module
Quantity of AWP
Module «Reception »
14
Module «District doctor»
34
Section VI. Technical Requirements
313
Module «Prophylactic exams»
7
Module «Profile specialist»
17
Module «Head of Policlinic department»
8
Module «Medical statistics of policlinic»
11
Module «Admission»
Module «Hospital Doctor»
Module «Hospital nurse»
Module «Meals»
Module «Day-hospital»
7
Module «Head of hospital department»
Module «Hospital administrator»
3
Module «Medical Statistics for Hospital»
Module «Procedures and manipulations»
7
Module «Admin»
3
Module «Lab IS»
15
Module «PACS» (Picture Archiving
and Communication System)
7
Module «Diagnostic studies»
27
Module « Pharmacy»
3
Module «Human Resources»
2
Total
165
Central rayon hospital, Zhualynsky rayon, Zhambul oblast
313
314
Section VI. Technical Requirements
Module
Quantity of AWP
Module «Reception »
4
Module «District doctor»
24
Module «Prophylactic exams»
49
Module «Profile specialist»
25
Module «Head of Policlinic department»
2
Module «Medical statistics of policlinic»
9
Module «Admission»
2
Module «Hospital Doctor»
13
Module «Hospital nurse»
13
Module «Meals»
1
Module «Day-hospital»
2
Module «Head of hospital department»
8
Module «Hospital administrator»
1
Module «Medical Statistics for Hospital»
3
Module «Procedures and manipulations»
9
Module «Admin»
5
Module «Lab IS»
3
Module «PACS» (Picture Archiving
and Communication System)
1
Module «Diagnostic studies»
7
Module « Pharmacy»
2
Section VI. Technical Requirements
315
Module «Human Resources»
2
185
Total
Municipal Policlinic №7 Astana city
Module
Quantity of AWP
Module «Reception »
6
Module «District doctor»
26
Module «Prophylactic exams»
3
Module «Profile specialist»
40
Module «Head of Policlinic department»
12
Module «Medical statistics of policlinic»
8
Module «Admission»
-
Module «Hospital Doctor»
Module «Hospital nurse»
Module «Meals»
Module «Day-hospital»
3
Module «Head of hospital department»
Module «Hospital administrator»
1
Module «Medical Statistics for Hospital»
Module «Procedures and manipulations»
4
Module «Admin»
2
315
316
Section VI. Technical Requirements
Module «Lab IS»
8
Module «PACS» (Picture Archiving
and Communication System)
3
Module «Diagnostic studies»
16
Module «Pharmacy»
2
Module «Human Resources»
3
137
Total
Municipal Hospital No.1 of Astana city
Module
Quantity of AWP
Module «Reception »
Module «District doctor»
Module «Prophylactic exams»
Module «Profile specialist»
Module «Head of Policlinic department»
Module «Medical statistics of policlinic»
Module «Admission»
20
Module «Hospital Doctor»
65
Module «Hospital nurse»
22
Module «Meals»
Module «Day-hospital»
Module «Head of hospital department»
22
Module «Hospital administrator»
8
Module «Medical Statistics for Hospital»
6
Section VI. Technical Requirements
317
Module «Procedures and manipulations»
Module «Admin»
5
Module «Lab IS»
4
Module «PACS» (Picture Archiving
and Communication System)
14
Module «Diagnostic studies»
10
Module «Pharmacy»
4
Module «Human Resources»
5
185
Total
Annex 3
Server hardware and software for health facilities
Server
M001
Quantity of servers : 1
M002
Performance per a server : rack, at least 2U
M003
Number of processors on one server bit: at least 2, at least 8-core processor 2,6 GHz.
M004
Installed operating memory per one server: at least 64 GB
M005
Max scope of memory per one server : at least 768 GB, at least 24 slots of memory
M006
Type of RAM on the server unit: PC3-12800RDIMMDDR3-16000 МГц, ECCcorrection of multi-bit error, mode lock-step. Support modules UDIMM.
M007
RAID controller in the server unit: SAS, not less than 8 ports, 512MB cache memory,
317
318
M008
M009
M010
Section VI. Technical Requirements
support for RAID levels 0, 1 + 0; failover ROM, online migration between the levels of
RAID, increasing the capacity of non-stop work, online increasing the size of existing
logical volumes. Support for up to 2GB flash cash memory
Disk sub-system per a server: at least 2 х 300GB 10KSAS 2.5 “.
Type of supported disks: SAS, SATA, SSDSAS, SSDSATA.
max number of disks: at least 25 disks of format 2.5" (SFF) or at least 12 disks of
format 3.5" (LFF).
M011
FC adapter per a server : at least 2-х 8Gbit SingleportFibre Channel Adapter
M012
max number of slots per a server : at least 6 PCI-Express
M013
network interface per a server: at least 4 installed ports 1GbEthernet
M014
Management: Tools for remote control and monitoring of the server: independent of
operating system remote text and video console, virtual media, support scripts to automate
software updates, power management, command line and web-based interface, dedicated
port 10/100, supporting SSH, SSL for a secure connection to the server, support for
DHCP / DNS / WINS
Proactive monitoring of RAM and hard drives.
Remote management of mobile devices based on the operating system iOS, Android.
Remote monitoring without pre agents under OS.
M015
Video subscription per a server: integrated
M016
Parameters of supply per a server: at least two pieces 750Vatt, hot replacement of at
least N + 1. Support for power supplies to be connected to the DC or AC. Support of
supply units is at least 1200 W
M017
Interface : at least seven units of USB, one unit of SD, one unit of Serial, two units of
Video.
M018
Licensed Software: the operating system Microsoft Windows Server Standard 2012 R2,
the virtualization software licenses for 2 processors. The software must be installed,
registered and activated
M019
Requirements for the contents of your package: package includes a complete set of
Section VI. Technical Requirements
319
drivers for the installed devices, CD-ROMs for the operating system distributions
MicrosoftWindowsServerStandard 2012. The kit should include all necessary cables for
supplying electric power.
LAN switch:
M020
quantity: at least 1 pc.
M021
quantity of ports: at least 24 pc.
M022
Port rate : at least 10/100/1000 EthernetGbit/s.
M023
Memory and processor : at least 1 GB SDRAM, size of package buffer: 4 MB, flesh
memory 512 MB
M024
Throughput capacity: at least 155 mln packages per a sec
M025
Performance: at least 208Gbps
M026
M027
Quantity of MAC-addresses: at least 32000
Size of rout table: at least 16000 lines
M028
Functions: Layer 2 and Layer 3.
UPS
M029
quantity: 1
M030
performance: to install into server board
M031
max output capacity per one UPS : at least 3000W/3300VA
319
320
Section VI. Technical Requirements
M032
Nominal output voltage per one UPS : at least 230V+/- 10
M033
Performance: at least 95%.
M034
Output frequency (synchronized with current network): 50/60 Hz -10%, + 6%
M035
Work time under load 50%: at least 12 min
Data storage system for server
M036
Performance: to install into server board .
M037
Quantity and type of installed disks: at least 8 disks 300GB 15KrpmSAS 6 Gb/s
M038
Max volume of disk subsystem: at least 192 TB
M039
The controller for connecting disk rack to the server: At least 2 active controllers,
support RAID levels 0, 1, 3, 5, 6, 10, 50; support of expansion for up to at least 48- hard
drives 3.5 ", hard drives 99 , 2.5”.
M040
Cache memory: cache size per controller - not less than 4GB. The cache memory should
be used only for storing data and control information, the cache memory cannot be used
for operating system tasks array. The cache must be mirrored between controllers through
internal channels (use of access channels to the disks for mirroring cache is not allowed).
Unrestricted by time support of safety of content of cache - in the event of a power failure
(the use of disk space to store cache is not allowed). Cache array must support ECC error
correction
M041
Supported disks: two port disks : 146/300/450/600/900/1000/1200 GB 2,5” SAS, 1/2/3/4
TB 3,5” SAS.
M042
Interface of controller: FC, 8 Гб/с. at least 2 ports.
Section VI. Technical Requirements
321
M043
Quantity of supported hosts: Support simultaneous connection to 64-servers
M044
Support of logic disks: Simultaneously to at least 512 logical drives; The ability to create
logical drives up to at least 128 TB.
M045
Software:
M046
The array must be maintained at the hardware level to create local copies of volumes of
two types - snapshot (snapshot) and snapclone (complete copy). Support of at least 512
"snapshots" of the data. The structure includes a license for 64 snapshots.
The array must support at hardware-level replication of data between two arrays of the
same type in asynchronous mode.
The array must support replication "many-to-one": up to 4 storage systems from remote
locations to one.
The disk array management software must support the integration VMwarevCenter, disk
array administrator shall be able to create / expand / delete repository of array and create
virtual machines from vCenter.
It should be possible to track the current status and performance of the array from
vCenter.
Capacity of array: In order to reduce energy consumption disk array must maintain the
ability to automatically stop or slow the rotation of the drive (if for some time the disks
are not being accessed).
Support for redundant disks (sparedisks), both global and dedicated for a specific RAIDgroup.
The array must be able to connect servers at least two ways to duplicate the access
channels (pathfailover), load balancing should also be supported between different access
paths (loadbalancing).
The required software for the duplication and balancing channels should be included in
the package.
The array shall support update from previous generation by replacing the controller, while
the drives and shelves from the previous generation must be fully supported by the new
controllers;
M047
Fail safety: The array must have a fully redundant architecture, the array have complete
redundancy of all active components and access paths. As a minimum, controllers should
be duplicated as well as input-output units, fans and power supplies, channel of
connection of a controller shelf with disk shelf of expansion.
M048
Fans and power supplies: Dual hot-swappable.
The array must be able to support connecting to networks of alternating current and direct
current networks.
Server board
321
322
Section VI. Technical Requirements
M049
Server board shall be on floor to install equipment 19''
M050
Hieght: not more 21U
M051
dimensions: no more 600х1000 mm.
M052
configuration:
 front side:
o single-wing door - the glass in a steel frame
o Swivel handle with profile standard DIN
o universal key type EK 333,
o multi-point locking mechanism, opening 180 degrees
 back side:
o single-wing door - solid steel sheet;
o Swivel handle with profile standard DIN,
o universal key type EK 333,
o multi-point locking mechanism
o 2 side panels, steel carcas of 2 mm,
o universal key
o without a roof, the bottom - type Z,
o it should be ready for the installation of air conditioning, the degree of
protection of at least IP54
o 19 'vertical guides not more than two pairs of A-type
o it shall be equipped with grounding kit,
o at least 28 mounting kits
o Load: not less than 1500 kg

Bottom:
o to have rectangular hole (max 300x100 mm) for cable entry
o closed by removable steel caps
M053
The framework for the separation of cold air: the framework for separation of cold
zone in front of 19 "guides for cabinets with guide of A-type, changeable depth of cold
zone for enclosures with a minimum height of 21U, width of at least 600 mm
M054
Air Flow deflector: available deflector airflow for cooling unit AC, installed in the
cabinet with a minimum width of 600 mm; compatible with the separation frame 150mm
M055
Delivered package: switch board shall be delivered in package with a set of systems
of at least :
 Cooling System
Section VI. Technical Requirements



323
Local fire-fighting system
Monitoring System
Access Control System
Requirements to cooling system
M056
Type: Board (installation on the roof of the switching board), direct cooling, no external
power
M057
Cooling capacity: at least 5 200 Vt
M058
Max operating current: no more 4,6
M059
energy consumption: at least 2 540
M060
Air consumption in board: at least 1 720 liters
M061
Fan: radial
M062
Heat exchanger: is available
Requirements to local system of fire-fighting
M063
Local fire-extinguishing system should include the main unit (MASTER), including
the control panel, at least two sensors and cylinder with extinguishing mixture:
•
Sensors located inside the cabinet should detect a fire without delay and at an
early stage
• The procedure for extinguishing should start immediately after the discovery of fire.
• The process of extinguishing should be safe for the equipment.
• Ease of installation must allow easy connection to a power supply system of the cabinet.
• The system should be recommended for use in cabinets IP30 protection level and higher.
• due to ability to gain access to the detector and the modular structure of the system it
shall simplify the procedure for inspection and maintenance.
• The main unit must be equipped with a detailed easy-to-read LED display board
• size of the device must not exceed a height of 3U cabinet 19 "
• There should be a built-in rechargeable battery provides operation of the system during
323
324
Section VI. Technical Requirements
a power failure
M064
width of device: no more 19"
M065
height of device: no more 2,5U
M066
Depth of basic part: no more 382 mm
M067
Max depth of device (in case of pulling back console with) : no more 750 mm
M068
range of operating temperature: from ‑5 °C to +50 °C
M069
relative humidity of air: no more 95 % without condensate
M070
Operating mode: constant
M071
Input capacity: no more 40ВА
M072
Protection degree: at least IP30
M073
Voltage of main supply unit: no more 230 V ± 15 %
M074
frequency of main supply unit: no more 50 Hz
M075
Max current supplied by main unit: no more 1,25 A
M076
Current in waiting mode: no more 210 мА
M077
Current consumption in preliminary alarm mode : no more 300 мА
Section VI. Technical Requirements
325
M078
Current consumption in alarm mode : no more 2 A
M079
Max consumption of current in waiting mode : no more 40 мА
M080
Maximum current consumption in alarm output: no more 0,5 A
M081
The maximum output voltage at the terminal X32 (recharge the internal battery): up
to 13,7 V
M082
Maximum current from the terminal X32 (recharge the internal battery): 200 mA
M083
Redundant power supply: 12V / 7,2Ach
M084
Maximum volume of the board (degree of protection - min. IP30): not more than 1.5
m3
M085
Maximum volume of the board (closed) : not more 3 м3
Requirements to monitoring system
Controller
M086
Intelligent ports (Input/output): at least 8
M087
front panel expansion: at least 4
M088
port Modbus (RS-485): Yes
M089
port USB 2.0 for connection of GSM-modem, adapter Bluetooth or Wi-Fi: Yes
325
326
Section VI. Technical Requirements
M090
Installing height: no more 1U
M091
Voltage: no more 7 – 9 V of current, 3 A
M092
Energy consumption: not more than 5.025 W 0,67 A
M093
Memory card slot (SD): on the front
M094
Power is provided by all accessories: Controller
M095
Built-in TCP / IP protocol and a Web server
M096
available virtual sensors to monitor the power of third-party devices on the Modbus
or SNMP
M097
accuracy of the system time and date is provided by built-in rechargeable battery
M098
Full support of Modbus: Modbus Master/Slave, Modbus RTU, Modbus on TCP/IP
M099
Integration into the network management system: Yes
M0100
Sensor: 1-wire temperature and humidity sensor (Cable - 30cm, coupling RJ-45)
M0101
It should unite all the existing monitoring system on 10 objects into a single system
M0102
License: up to 99 sensors
M0103
Support renewal: no less than 5 years
Section VI. Technical Requirements
327
M0104
Visualization: The software must support the loading of the image / map and
location of the object icons sensors / detectors on the map
M0105
Access control: no less than full control of individual user accounts and user groups
M0106
Integration into the network management system by: at least SNMPv1 and
EncryptedSNMPv3.
Requirements for access control system into the board
Controller
M0107
Control RDU extension modules per controller: max 100 RDU
M0108
in series RDU connection to one expansion port: no more 25 RDU
M0109
Intelligent Sensor port: no more 2х
Electronic door lock
M0110
Electronic door lock: available electronic door lock with profile half-cylinder and
built-card reader (EM & HIDProx format 125kHz), with a cable of at least 4.5 m
M0111
(Optional) Expander for connecting: an option should be able to install the expander to
connect at least two locks in one port
M0112
Reader Programming: USBDesktopCardReader (EM & HIDformat 125kHz) for
programming cards;
M0113
Access Map: HIDProxCards, 125kHz of at least 30 pieces per set of equipment
327
328
Section VI. Technical Requirements
M0114
Requirements for experts on this type of equipment: potential supplier shall have for
at least 2 certified experts on the proposed equipment for the following equipment: a disk
array, server equipment, active network equipment.
M0115
Installation: Installation of all equipment under “a turnkey basis” in the server room of a
health facility by certified professionals.
M0116
Warranty: At least 3 years of 24 hours warranty, including holidays, reaction time not
exceeding 4 hours during 24 hours a day for equipment.
Section VI. Technical Requirements
329
Technical requirements (including implementation
schedule) – Lot № 10
«Medical information system for registration of donors,
recipients and individuals waiting for transplantation»
Technical requirements
A. Background
0.1
Purchaser
0.1.1 Implementing entity of the present contract is the Ministry of Health and
social development of the Republic of Kazakhstan. Ministry of Health and
social development of the Republic of Kazakhstan is central executive body of
the Republic of Kazakhstan, implementing state regulation in the area of
population health care, medical and pharmaceutical science, sanitary
epidemiological wellbeing of population, drugs circulation, control over
quality of medical services. The Ministry carries out its activity according to
Constitution and laws of the Republic of Kazakhstan, enactments of President,
Government of the Republic of Kazakhstan, other regulatory acts, as well as
Provisions on the Ministry of the Republic of Kazakhstan approved by Decree
N 1005 of the Government of the Republic of Kazakhstan dated 23 September
2014.
0.1.2 Project stakeholders, which will be realized as a result of this tender are the
following:
 MHSD of the RK (https://www.mzsr.gov.kz/), which will define e-health strategy,
and provide the supplier with required regulatory acts and corresponding orders for
successful contract implementation and refinement of regulations if necessary.
 Health facilities of the Republic of Kazakhstan, which will be beneficiaries of the
Contract, and will be using results of the Contract in practical activity (hereinafter –
facility).
Additional details on engagement of stakeholders into contract implementation are
presented in the following chapters.
0.2
Purchaser’s goals
0.2.1 General goal of the MHSD of the RK in the area of e-health:
Provide computerized support of collecting actual, precise and full information to
ensure safe, equitable, high standard and sustainable health system, oriented at patient
needs. It will be reached by providing to the health facilities and departments of the
MHSD of the RK of high performance access to fully functional interoperable ehealth systems based on paperless technologies using unified e-health record. At
central level national e-health repository will be set, it will contain: (I) e-health record
as a central component of data integration from scattered health facility information
329
330
Section VI. Technical Requirements
systems and (II) storage of high standard statistical analytical and financial
information.
«Medical information system» to register donors, recipients and individuals waiting
for transplantation (hereinafter the System), purchased under existing contract and it
will contribute considerably to achieve this vision. The system is provided to
automate processes of e-register of donors, patients in the waiting list, and recipients,
automation of coordination service business processes on transplantation, automation
of processes of matching donor-recipient pair.
0.2.2 Main goals of the Republic of Kazakhstan e-health. Based on analysis of
priority needs of Kazakhstan health system outlined by main directions of
State health development program Salamatti Kazakhstan for 2011-2015, and
key priorities, stated in «Kazakhstan strategy by 2050», in relation to
healthcare, the following main tasks are set for e-health:
1.
support to clinical (medical) decision making process;
2.
medical errors reduction;
3.
increasing accessibility and refining medical care continuity;
4.
increasing medical services quality;
5.
improving quality and effectiveness of political, managerial and
financial decision making;
6.
ensuring conditions for continuous professional health development;
7.
increasing access of population to information about their health and to
their confidentiality management issues;
8.
increasing profitability and effectiveness of investments and
operational expenses in the health care.
0.2.3 System, supplied within this tender will ensure such advantages as
follows:
 Effective information collection about tissues, donors, recipients and persons
needed transplantation;
 Currency of information about available tissues and organs;
 Statistical information accumulation;
 ordinary monitoring of current recipients’ state;
 ordinary monitoring of current state, patients needed in transplantation;
 automation of building register of donors, patients, needed transplantation and
recipients;
 automation of transplantation coordination service business processes,
 automation of donor-recipient pair matching processes.
0.2.4. System potential beneficiaries.
The system direct potential beneficiaries are the following:
 medical staff-doctors, nurses, using system for storage and use of information
about patients in clinical decision making using contextual help in the form of
clinical protocols etc.
 health managers, using information, collected from different data sources and
different facilities;
 MHSD of the RK staff, using data for political decision making and
incorporating amendments to regulatory framework based on evidences for
correct financing of medical services;
 external information systems, using data, stored in e-health applications;
Section VI. Technical Requirements
331
System following potential indirect beneficiaries:
 all Kazakhstan citizens, served by medical staff using the System;
 researchers, using data about curative preventive process obtained with the
help of the System.
0.2.5. Information systems of the MHSD
The following systems belong to IS of the MHSD:
1.
IS «Hospitalization Bureau»
2.
IS «Additional component to PHC tariff»
3.
IS «Drug provision»
4.
IS «Register of pregnant and fertile age women»
5.
IS «Health service quality management system»
6.
IS «Medical equipment management system»
7.
IS «Resource management system»
8.
IS «E-register of dispensary patients»
9.
IS «E-register of cancer patients»
10.
IS «E-register of hospital patients»
11.
IS «Out-patient care»
12.
IS «Register of attached population»
13.
IS «Register of patients with renal failure»
14.
IS «Register of patients with mental diseases»
15.
IS «Register of narcological patients»
16.
Drug provision management system
17.
AIS «Policlinics»
18.
IS «National Register of TB patients»
19.
IS «National Register «Diabetes»»
20.
Health Informatization and Interoperability Platform
Interaction with IS of MHSD (above indicated IS in para.1-19) shall be done using service of
Health Informatization and Interoperability Platform.
0.3
Acronyms, used in these technical requirements
Term
Description
DB
Data base
IIN
Individual identification number
ICT
Information communication technologies
IS
Information system
DRG
Diagnosis related group
CPF
Curative preventive facility
MOH
Ministry of health and social development of the Republic of
Kazakhstan
ICD
International classification of diseases
RF
Regulatory framework
RITD
Resuscitation and intensive therapy department
PHC
Primary health care
SW
software
RK
Republic of Kazakhstan
331
332
Section VI. Technical Requirements
Term
Interoperability
SOA
TSS
FN
EMR
EHR
EDS
ADO.NET
ASP
BAM
Description
Feature or capability of various systems jointly operate
Service oriented architecture
Provider technical support service
Full name
Electronic medical record
Electronic health record
Electronic digital signature
Technology that provides data access to applications based on
Microsoft .NET. it is not development of earlier ADO
technology.
Active Server Page
Business activity monitoring
BP
BPM
bps
BRMS
Business Process
Business Process Management
Bits per second
Business Rule Management System
CDA
Clinical Document Architecture
CPU
Central Processing Unit
CRUD
CSS
DICOM
Create Read, Update, Delete operations
Cascading Style Sheets
Digital Imaging and Communication in Medicine
DOM
Document Object Model
ESB
Enterprise Service Bus
FHIR
Fast Healthcare Interoperability Resources – a standard created
by the High Level Seven International
GB
Gigabyte
Section VI. Technical Requirements
GUI
Graphical User Interface
HC
Healthcare
Help Desk
Help desk.
HL7
HTML
Health Level 7
Hypertext Markup Language
IaaS
Infrastructure as a Service
ICPC
International Classification in Primary Care
IDE
Integrated Development Environment
IHE
Integrating Healthcare Enterprise
IP
Internet Protocol
ISO
International Standards Organization
ITI
IT Infrastructure
JDBC
KB
Java Database Connectivity
Kilobyte
LAN
Local area network
LDAP
Lightweight Directory Access Protocol
LOINC
Logical Observation Identifiers Names and Codes
MB
Megabyte
MDX
Multi-Dimensional eXpressions Language
ODBC
Open Database Connectivity
OLAP
Online Analytical Processing
OLTP
Online Transactional Processing
OWASP
333
Open Web Application Security Project
PaaS
Platform as a Service
PDQ
Patient Demographic Query
333
334
Section VI. Technical Requirements
PIX
Patient Identifier Cross-Reference
PKI
Public Key Infrastructure
PMI
Patient Master Index
RAM
Random Access memory
REST
Representational State Transfer
SaaS
Software as a Service
SAML
SDK
SNOMED-CT
Security Assertion Markup Language
Software Development Kit
Systematized Nomenclature Of Medicine Clinical Terms
SOA
Service-oriented architecture
SOAP
Simple Object Access Protocol
SQL
Structured Query Language
SSL
Secure Sockets Layer
SSO
Single Sign On
TCP
Transmission Control Protocol
TCP/IP
Transmission Control Protocol / Internet Protocol
TLS
Transport Layer Security
UML
Unified Modeling Layer
Unicode
Unicode
URL
Uniform resource locator
VPN
Virtual Private Network
WADL
Web Application Description Language
WCAG
Web Content Accessibility Guidelines
WLAN
Wireless LAN
WS
Web Service
Section VI. Technical Requirements
WSDL
XCA
XD-LAB
XDS
XDS-MS
Web Services Description Language
Cross-Community Access
Cross Enterprise Document Sharing of Lab Reports
Cross-Enterprise Document Sharing
Cross Enterprise Document Sharing of Medical Summaries
XML
Extensible Markup Language
XPHR
Exchange of Personal Health Records
XSL
335
Extensible Style sheet Language
335
336
Section VI. Technical Requirements
B. BUSINESS FUNCTIONS AND PERFORMANCE REQUIREMENTS
The goal of this section is to define key business and functional requirements to supply and
installation of the System.
1.1.
System business requirements
1.1.1. ICT of the MHSD of the RK current state
1.1.1.1.
Proposed Kazakhstan e-heath changes
Government of the RK adopted a new strategy “Kazakhstan e-health development
concept” for 2013-2020, which defines main directions of e-health changes. According to
this strategy, it is expected that new architecture will serve as a basis for all transformations.
Main new solution properties are narrated:
- E-health will be based on principles of interoperability, including: general
dictionaries, classifiers, nomenclature, aimed at creating unified information/semantic
interoperability in e-health area;
- Creation of common and jointly used identifiers for Kazakhstan e-health: Identifier of
patients, medical staff (specialists), health facilities, other resources;
- Creation of common e-health record system which will be located in the center and
contains all patient health records and if necessary will be replicated to local servers;
- Provision of computing infrastructure consisting of 2 database processing centers
capable to substitute other in case of incidents;
- Setting cloud computing technology, enabling to provide corresponding cloud
services: infrastructure as a service (IaaS), platform as a service (PaaS) and software
as a service (SaaS);
- Maintenance based on service oriented infrastructure, enabling to reuse functional
capabilities of existing systems and provide connection to Kazakhstan e-government;
- Integration of existing systems and web applications in health
integration/interoperability platform (hereinafter, platform) etc. Some of approaches
on building e-health provide the following:
- E-health systems will be developed not only centralized out of republican budget, but
health facilities will have possibility to purchase information systems and applictions
out of their own funds;
- To ensure interoperability, a set of compatibility requirements will be developed and
information systems will be certified for compliance with standards of the MHSD of
the RK;
- To stimulate e-health market development, government will set up special grants and
co-financing regulations for health facilities which are intended to computerize their
medical activity;
- Government will evaluate and control potential risks and take decisions which will
mitigate risk (for example, communication channels capacity, alignment between ICT
and health sector needs, ensuring compatibility etc.);
- The MHSD will speed up process for setting regulations and standards for enhanced
interoperability between e-health process participants.
Section VI. Technical Requirements
Patient’s Personal
Cabinet
Personal health professional’s
cabinet
337
BI and Analytical tools
e-Government
services
Classifiers and Nomenclatures
Management
Existing Information systems
Single data repository
RAP
OPC
MSQMS
RMS
DPMS
RPWFA
ERHP
ACPCT
MEMS
ERDP
HB
DIS
NRD
ERCP
EHR Repository
Analytical warehouse
Master patient index,
healthcare facilities
index, healthcare
professionals index
Classifiers and
nomenclatures
e-Government Gate
Integration bus
Integration bus
External Information systems
RPCRF
LIS
HIS
Legend
Existing Information systems
Platform components
e-Government Gate and services
External information systems
HIS (Health information system)
Fig.1. General national e-health architecture
More detailed description is in the Kazakhstan e-health development concept for 2013-2020,
accessible on the MHSD of the RK website.
1.1.2. The System’s principles to be complied with
The following principles are applied to development, configuration and use of the
System:
 Legality principle, which assumes creation, use and maintenance of information
systems according to national legal framework and international standards and
regulations in this area;
 Multi-level architecture principle, which assumes sub-systems self-development
according to each level interface standards;
 Data security principle, which ensures data management in to the System only
through secured, authorized channels;
 Information security principle, which assumes ensuring adequate integrity,
selectivity, accessibility and effectiveness to secure data from failure, changes,
deletion and unsanctioned access;
337
338
Section VI. Technical Requirements
 Data confidentiality principle, which assumes performing procedures which will
guarantee access to data only according to national policy and international standards
to personal data confidentiality, access according to patient consent, option to code
saved data;
 Transparency principle, which assumes, that the System is module structure and it
will use ICT transparent/open standards;
 Extension principle, which assumes extension and improvement of the System with
a help of new functions and improvements of existing functionality;
 First person/unique center priority principle, which assumes existence of high
ranked official entitled to make decisions and coordinate activities on creation,
integration and use of the System;
 Scalability principle, which assumes uniform performance of applications and
linkages with data and user augmentation;
 Simplicity and user friendly principles, which assumes that all functions and tools
available for target roles are based on visual tools, they are ergonomic and intuitively
comprehensible.
1.1.3. Business requirements to the System
Note 1. The following key words (normative verbs) SHALL BE used, to communicate
compliance requirements.
• SHALL – to indicate mandatory requirement, subject to execution (implementation) for
compliance. Synonym is «REQUIRED». Another used synonym is «MUST».
• SHALL NOT – to indicate prohibited action. The synonym is «forbidden».
• SHOULD - to indicate additional recommended action, which fits without reference or
exclusion of others. Synonym is «allowed and recommended».
• MAY – to indicate non mandatory, admissible actions. Synonym is «allowed».
Note 2. In tables with business and functional requirements the following categories are used
(types) or requirements:
M – means minimal mandatory requirement; such requirement, supplied solution is to be
complied therewith; full or partial absence of compliance with such requirement may result
in participant’s proposal rejection.
D – desirable requirements; absence of compliance with the requirement shall not result in
participant’s proposal rejection, and compliance will enable to increase proposal
competitiveness.
I – means information, is added for clarification of other requirements.
Reference to requirements in the text will be different from reference to chapters and parts
explicitly:
Reference to requirements explicitly will contain word «requirement», «req.» or R, for
example, R1.1 - Reference to requirements 1.1;
- reference to chapter will be with prefix «chapter», «section», or р, for example, «p.1.1.1»
indicates section 1.1.1 and is not requirement.
Table below contains list of business requirements, which shall conform to supplied System
and related systems/services.
1.1.3.1.
General business requirements
№
type requirement
Section VI. Technical Requirements
339
R
1.
R
1.1.
M
Licensing mechanism for the System under this contract shall
provide the right to use all modules and compounds for a number of
users, which allow full functioning of the Health Facility
(approximate scope of Health Facilities is given in description of
Appendix 17) for unlimited time, unlimited number of servers, and
excluding any other possible limitations. Annual license fees are not
admitted; full license cost includes all costs for system licensing.
R
1.2.
M
Within this Contract an interoperability of the System with national
e-health system shall be ensured according to requirement R7.
General interaction scheme with national e-health system is
represented in Fig.1.
R
1.3.
М
Generalized comprehensive health information system architecture
the system shall comply with is shown in Fig 2
R
1.4.
М
System shall be represented as a web application
R
1.5.
М
System shall have capability of fine tuning to provide configuration
for specific needs of concrete facility without necessity to develop
new one (or including minor development)
R
1.6.
М
Supplier under this Contract shall ensure System interoperability
with national EHR tools (EHR repository, national classifiers and
identifiers, analytical storage, EHR web services) according to R8
R
1.7.
М
System shall ensure confidentiality of personal data in the process of
saving and sending: coding of confidentially data in database, data
coding during transmission via channels, use of secure transmission
protocols etc.
R
1.8.
М
System shall ensure using a digital signature for signing and
authentication of e-documents, files and parts of documents. The
need to use digital signature shall be configurable at the level of
system administrator.
R
1.9.
М
System shall be fully “turnkey” operational according to R15.2.
R
1.10.
М
The Supplier shall provide at least, but not limited to configuration,
deployment, installation, testing of the System. The Supplier shall
provide trainings for users and administrators (and other staff if
needed)
R
1.11.
М
Supplier shall participate in the process of certification of the System
jointly with Supplier of Platform to test and certify interoperability
with national resources and EHR tools as well as participate in
General business requirements
339
340
Section VI. Technical Requirements
attestation and testing of the system
R
1.12.
М
Supplier shall provide guaranteed service of the system within 3
years from the date of the system operational acceptance by the
Purchaser according to R13.4.
R
1.13.
М
If additional licensed software is required for the system turn-key
operation the Supplier shall ensure availability of all licenses at the
expense of Supplier and their transfer to the Purchaser’s ownership
under this contract.
R
1.14.
М
Minimum requirements for each module must comply with
requirements of section R2
R
1.15.
D
System shall have capabilities of integration with development
environment (IDE) at least for Java and Net framework. System shall
have in a package development tools (SDK) including documents,
examples of code for at least Java and Net Framework for
configuration of system unction. An option of extending system
functionality shall be available using development tools (SDK)
which are included into the system composition.
R
1.16.
M
Licensing mechanism for the system within this contract shall not
restrict changes which are made using development tools (SDK) that
are included into the system composition. Making changes using
development tools (SDK) which are included into the system
composition shall not have effect on guarantee service of the system.
Making changes into the system by specialists of the Purchaser is
allowed upon the system operational acceptance.
R
1.17.
M
Supplier shall ensure service and technical support including
provision of new product versions (according to R13.3).
R
1.18.
M
Service response tome and system components response time shall
not be more than 3-5 seconds for not least 80% of cases of data entry
or inquiries for data view (under channel speed 1 Mb/s and response
time not more than 100 ms).
R
1.19.
M
Supplier shall document and submit in electronic format
configuration files, original code of system components developed
within this contract.
R
1.20.
M
System shall have thin client for interaction with equipment it is
allowed to use thick client.
Section VI. Technical Requirements
Patient’s Personal
Cabinet
Personal health professional’s
cabinet
341
e-Government
services
BI and Analytical tools Classifiers and Nomenclatures
Management
Existing Information systems
RAP
OPC
MSQMS
RMS
DPMS
RPWFA
ERHP
ACPCT
MEMS
ERDP
HB
DIS
Single data repository
EHR Repository
Analytical warehouse
Master patient index,
healthcare facilities
index, healthcare
professionals index
Classifiers and
nomenclatures
e-Government Gate
Integration bus
ERCP
NRD
Integration bus
External information systems
Health facility lev el modules (w ithin this contract)
Monitoring of individuals
who were performed
transplantation
Inpatient transplantation
coordinator
Generation of analytical
and statistical tables
Administration
Registration of Individual
needed transplantation
Lab testing
Republican transplantation
coordinator
Transplantation brigade
Regional transplantation
coordinator
Legend
Existing Information systems
Platform components
e-Government Gate and services
Health facility level modules
Fig.2. generalized System architecture.
1.1.3.2.
Requirements to composition of processes, maintained and automated by
the System
Republican coordinating center on transplantation (hereinafter RCCT) is health facility which
coordinates health facilities in the area of tissue transplantation and/or organs (parts of
organs). Brief information about RCCT is attached in Appendix 1 to the technical
specification.
Note 1:
341
342
Section VI. Technical Requirements
Division to modules is provisional and not mandatory for strict adherence. Mandatory is
availability of these functions.
Note 2:
Forms with prefix “/у” are account forms that approved by order of acting minister of health
№907 dated 23 November 2010 “on approval of primary medical document forms of health
facilities”
Note 3:
Possible donor – patient with severe injury/disease of brain with artificial pulmonary
ventilation.
Potential donor – patient suspected for brain death or with injury/disease incompatible with
life instable hemodynamics against conducted complex resuscitation and intensive therapy
with occurring brain death diagnostics.
Actual donor – donor with established brain death or irreversible blood circulation stagnation
and with obtained written consent of donor legal representatives to recover tissues and (or)
organs (parts of organs)
Health facility in the Republic of Kazakhstan which carries out coordination of health
facilities in tissue and (or) organs (part of organs) transplantation is the Republican
coordination center of transplantation” (hereinafter RCCT). Information about RCCT is
stated in Appendix 1 to the present technical specification.
Note 1: Division into modules is conditional and not mandatory for strict compliance. The
requirement is presence of these functions.
Note 2: While referring to the forms with prefix “/у” registered forms approved by order of
the acting minister of health of the RK №907 of November 23, 2010 «On approving primary
medical documentation forms of health facilities» have been described
Note 3. The following terminology is used in the text:
-
-
-
Possible donor – patient with severe injury/brain disease, who is under artificial lung
ventilation.
Potential donor – patient with suspicion for death of brain or with injury/disease
incompatible with life, instable hemodynamics who has been undertaken complex
resuscitation care and supporting intensive therapy with commenced diagnostics of
brain death.
Actual donor – donor with confirmed death of brain or irreversible blood circulatory
arrest with a received written consent for tissue and (or) organs (parts of organs)
extraction received from authorized donor representatives.
Management –create, entry, view, edit, delete data.
№
R2
R2.1
Тyp
e
Requirement
Requirements to automated processes
Module «Administration»
Section VI. Technical Requirements
R2.1.1
М
Adjustment of system user accounts. This process includes as minimum:
R2.1.1.1 M
Create user accounts
R2.1.1.2 M
Edit user accounts
R2.1.1.3 M
Delete user accounts
R2.1.2
М
343
Adjustment of system users’ rights and strict designation of
responsibilities based on regional and administrative criteria. This
process includes as minimum:
R2.1.2.1 M
Personalized designation of user access rights
R2.1.2.2 M
Designation of system user rights based on roles, groups and access
level with regard to hierarchy of objects and ownership to organizational
structure
R2.1.2.3 M
Edit user access rights
R2.1.2.4 M
Delete user access rights
М
Configuration of criteria for automatic selection of appropriate recipient
from the waiting list. This process includes as minimum the following:
R2.1.3.1 M
Edit (add/delete) criteria for automatic selection of appropriate recipient
from the waiting list
R2.1.3.2 M
Edit weight coefficients (score points) of criteria for automatic selection
of appropriate recipient from the waiting list
М
Configuration of recipient/donor registration forms. This process
includes as minimum the following:
R2.1.4.1 M
Edit (add/delete fields, edit existing fields) in the entry forms for
registration of recipient/donors/individuals needed transplantation
R2.1.4.2 M
Add/delete entry forms for registration of recipient/donor/individuals
needed transplantation
R2.1.4.3 M
Use of the following functions to create, edit the entry forms to register
recipient/donor/individuals needed transplantation:
R2.1.3
R2.1.4
343
344
Section VI. Technical Requirements

Change in font setting (style, size, bold, underline, italic etc.)

Change font color

Create complicated entry forms with subsections

Possibility of using any reference book in the system for filling
in the field in the entry form

Possibility of using any content in the database for filling in the
field in the entry form

Possibility of using any sampling from the database for filling in
the field in the entry form

Setting rules for filling in the entry form: only from the list, from
the list with possibility of add-in in a free form, from the sample
etc.

Create new reference books, used in filling in the entry form
R2.1.5
М
Import data into the system from at least xls, xml file formats.
R2.1.6
M
System journal management. This process includes as minimum the
following:
R2.1.7
M
Journal to create, change and delete data in the database
R2.1.8
M
Journal of user’s entry history
R2.1.9
M
Journal of received reporting forms
R2.1.10 M
Journal of data view
R2.1.11 M
Journal of data processing (create, change, delete)
R2.1.12 M
Journal of archive history
R2.1.13 M
Journal of program errors and emergency shut down
R2.1.14 M
Journal of synchronization with external (national) reference books,
classifiers, indexes and registers
R2.1.15 M
Journal archiving
R2.2
R2.2.1
Module «Registration of an individual needed transplantation»
М
Registration
in
the
«waiting
list» of
an
individual,
needed
Section VI. Technical Requirements
345
transplantation according to Appendices 1-1, 1-2, 1-3 to the present
technical specification. Possibility of registration of one patient in
several waiting lists. This process includes as minimum the following:
R2.2.1.1 M
Registration in the «waiting list» of an individual needed transplantation
according to the form of Appendix 1-1 to the present technical
specification
R2.2.1.2 M
Registration in the «waiting list» of an individual needed liver
transplantation according to the form of Appendix 1-2 to the present
technical specification
R2.2.1.3 M
Registration in the «waiting list» of an individual needed kidney
transplantation according to the form of Appendix 1-3 to the present
technical specification
R2.2.1.4 M
Registration of one patient in several waiting lists (if necessary)
R2.2.1.5 M
Possibility of printing patient information according to Appendices 1-1,
1-2, 1-3 to the present technical specification.
R2.2.1.6 M
Possibility of export patient information according to Appendices 1-1,
1-2, 1-3 to the present technical specification to at least pdf, xls, doc
format documents.
R2.2.2
M
Automated receipt of information about necessity to be registered in the
waiting list of an individual needed transplantation based on the
information received from IS of the MHSD of the RK (this functionality
shall be implemented as soon as required functionality of the stated
above IS will be ready for interaction). This process includes as
minimum the following:
R2.2.2.1 M
Automated receipt of information from IS of the MHSD of the RK
about the necessity for the patient to be registered in the waiting list
R2.2.2.2 M
Patient registration in the waiting list according to Appendices 1-1, 1-2,
1-3 to the present technical specification based on information of IS of
the MHSD of the RK
R2.2.2.3 M
Registration of one patient in several waiting lists (if necessary).
R2.2.2.4 M
Possibility of printing patient information according to Appendices 1-1,
1-2, 1-3 to the present technical specification.
345
346
Section VI. Technical Requirements
R2.2.2.5 M
Possibility of export patient information according to Appendices 1-1,
1-2, 1-3 to the present technical specification to at least pdf, xls, doc
format documents.
М
Manage information about current state of individual needed
transplantation (improving or worsening of the course of the disease
with regard to progress, development of complications, concomitant
disease and other). This process includes as minimum the following:
R2.2.3.1 M
Search of patient based on full name, IIN, organ/part of organ and/or
tissue, blood group, Rh and other criteria.
R2.2.3.2 M
Manage information about current state (improving or worsening of the
course of the disease with regard to progress, development of
complications, concomitant disease and other).
R2.2.3.3 M
Store in the system of the history of changes in the patient condition
R2.2.3.4 M
View the history of changes in the patient condition
R2.2.3.5 M
Option to print information about the patient condition.
R2.2.3.6 M
Option to print the history of changes in the patient condition.
R2.2.3.7 M
Option to export information about patient condition to at least pdf, xls,
doc format documents.
R2.2.3.8 M
Option to export the history of changes in the patient condition to at
least pdf, xls, doc format documents.
М
Waiting list monitoring. This process includes as minimum the
following:
R2.2.4.1 M
Search patient based on full name, IIN, organ/part of organ and/or
tissue, blood group, Rh and other criteria.
R2.2.4.2 M
View waiting list (including generation of daily information by regions
about the number of adult and child patients, number of dropped from
the waiting list with a reason indication, number of new cases).
R2.2.3
R2.2.4
Section VI. Technical Requirements
347
R2.2.4.3 M
Sort and filtrate the «waiting list» based on patient full name, patient
age, sex, date of patient entry to the waiting list, region, health facility,
organ/tissue to be transplanted and another criterion.
R2.2.4.4 M
Option to print the waiting list (including filtrated and/or sorted).
R2.2.4.5 M
Option to export the waiting list (including filtrated and/or sorted) into
at least pdf, xls, doc format documents.
R2.3
Module «Inpatient transplantation coordinator»
М
Registration of possible donor under a form according to Appendix 2 to
the present technical specification. This process includes as minimum
the following:
R2.3.1.1 M
Registration of possible donor according to Appendix 2 to the present
technical documentation
R2.3.1.2 M
Manage information about possible donor examination results
R2.3.1.3 M
View of earlier registered possible donors with possibility of sorting and
filtration by patient age, sex, diagnosis, entry date and other criteria.
R2.3.1.4 M
Possibility of printing information about possible donor.
R2.3.1.5 M
Possibility of export of possible donor information into at least pdf, xls,
doc format documents.
М
Registration of potential donors under form according to Appendix 2 to
present technical specification. This process includes as minimum the
following:
R2.3.2.1 М
Registration of potential donor according to Appendix 2 to the present
technical specification
R2.3.2.2 М
Manage information about potential donor examination results
R2.3.2.3 М
View of earlier registered potential donors with possibility of sorting
and filtration based on patient age, sex, intensive therapy department
admission date, tissue/organ to be extracted and other criteria.
R2.3.1
R2.3.2
347
348
Section VI. Technical Requirements
R2.3.2.4 М
Possibility of setting summary reporting forms of registered potential
donors over a certain period of time
R2.3.2.5 M
Possibility of printing summary reporting forms of registered potential
donors over certain period of time
R2.3.2.6
Possibility of printing potential donor information
R2.3.2.7 М
Possibility of export of summary reporting forms of registered potential
donors over a certain period of time into at least pdf, xls, doc format
documents
R2.3.2.8 М
Possibility of export of potential donor information into at least pdf, xls,
doc format documents
М
Registration of actual donor under a form according to Appendix 2 to
the present technical specification. This process includes as minimum
the following:
R2.3.3.1 М
Registration of actual donor according to Appendix 2 to the present
technical specification
R2.3.3.2 М
Manage information about actual donor examination results
R2.3.3.3 М
View of earlier registered actual donors with possibility of sorting and
filtration based on patient full name, age, sex, organ/tissue, to be
extracted and other criteria.
R2.3.3.4 М
Setting summary reporting forms of registered actual donors over a
certain time period
R2.3.3.5 М
Possibility of printing summary reporting forms of registered actual
donors over certain time period
R2.3.3.6 М
Possibility of printing information about actual donor
R2.3.3.7 М
Possibility of export of summary reporting forms on registered actual
donors into at least pdf, xls, doc format documents
R2.3.3.8 М
Possibility of export of actual donor information into at least pdf, xls,
doc format documents
М
Manage information about current objective donor status (possible,
potential, actual) This process includes as minimum the following:
R2.3.3
R2.3.4
Section VI. Technical Requirements
349
R2.3.4.1 M
Manage information about current objective donor status
R2.3.4.2 M
View of donor objective status change history
R2.3.4.3 M
Possibility of printing information about donor objective status
R2.3.4.4 M
Possibility of printing donor objective status change history
R2.3.4.5 M
Possibility of exporting information about donor objective status into at
least pdf, xls, doc format documents.
R2.3.4.6 M
Possibility of export donor objective status change history into at least
pdf, xls, doc format documents.
R2.4
Module «lab testing»
М
Managing performed lab testing results including but not limited to the
information about high, medium, low performance immunological
tissue typing testing results of individuals recommended for
transplantation and potential donors (form №410-10/у), information
about individual cross match results of potential donors and individuals
recommended for transplantation (form №410-11/у), leucocyte
antibodies testing results of candidates for transplantation (form №4109/у). This process includes as minimum the following:
R2.4.1.1 M
Search of patient based on full name, IIN, organ/part of organ and/or
tissue, blood group, Rh and other criteria.
R2.4.1.2 M
Manage performed lab testing results including but not limited to the
information about high, medium, low performance tissue
immunological typing testing results of individuals recommended for
transplantation and potential donors (form №410-10/у), information
about individual cross match results of potential donors and individuals
recommended for transplantation (form №410-11/у), leucocyte
antibodies testing results of candidates for transplantation (form №4109/у). Entry of performed lab testing results
R2.4.1.3 M
View earlier entered lab testing results
R2.4.1
349
350
Section VI. Technical Requirements
R2.4.1.4 M
Option of printing lab testing results including but not limited to the
information about high, medium, low performance tissue
immunological typing molecular & serological testing results of
individuals recommended for transplantation and potential donors (form
№410-10/у), information about individual cross match testing results of
potential donors and individuals recommended for transplantation (form
№410-11/у), leucocyte antibodies testing results of candidates for
transplantation (form №410-9/у).
R2.4.1.5 M
Option of export lab testing results into at least pdf, xls, doc format
documents.
R2.5
Module «regional transplantation coordinator»
М
Setting request to be dropped from the waiting list with a reason
indication (death, change of place of living, no need in transplantation,
contradictions to transplantation etc). This process includes as minimum
the following:
R2.5.1.1 M
Entry request to be dropped from the waiting list with a reason
indication (death, change of place of living, no need in transplantation,
contradiction to transplantation, rejection to have transplantation etc.)
R2.5.1.2 M
Edit/delete request to be dropped from the waiting list which was not
sent to the republican transplantation coordinator
R2.5.1.3 M
Sending a request to be dropped from the waiting list to the republican
transplantation coordinator for consideration
R2.5.1.4 M
Option of printing request to be dropped from the waiting list.
R2.5.1.5 M
Option of export the request to be dropped from the waiting list into at
least pdf, xls, doc format document.
М
Monitoring of donors (possible, potential, actual, as well as voluntary).
This process includes as minimum the following:
R2.5.2.1 M
View a list of possible donors with option of sorting and filtration based
on patient age, sex, diagnosis, admission date, other criteria.
R2.5.2.2 M
View a list of potential donors with option of sorting and filtration based
on patient age, sex, intensive therapy department admission date,
tissue/organ to be extracted and other criteria.
R2.5.1
R2.5.2
Section VI. Technical Requirements
351
R2.5.2.3 M
View a list of actual donors with possibility of sorting and filtration
based on patient full name, age, sex, organ/tissue to be extracted and
other criteria.
R2.5.2.4 M
View a list of voluntary donors with option of sorting and filtration
based on patient age, sex, registration date and other criteria.
R2.5.2.5 M
Search patient based on full name, IIN, organ/part of organ and/or
tissue, blood group, Rh and other criteria.
R2.5.2.6 M
View a list of individuals who were dropped from the list of voluntary
donors (rejection to donate, contradictions to donation, death and other
reasons).
R2.5.2.7 M
View possible donors list change history
R2.5.2.8 M
View potential donors list change history
R2.5.2.9 M
View actual donors list change history
R2.5.2.10 M
View voluntary donors list change history
R2.5.2.11 M
Manage daily report data according to Appendix 6 to the present
technical specification
R2.5.2.12 M
Setting summary reporting forms for registered donors (possible,
potential, actual) over certain time period
R2.5.2.13 M
Setting summary reporting forms for registered voluntary donors over
certain time period
R2.5.2.14 M
Option of printing summary reporting forms for registered donors
(possible, potential, actual).
R2.5.2.15 M
Option of printing summary reporting forms for registered voluntary
donors.
R2.5.2.16 M
Option to export summary reporting forms by registered donors
(possible, potential, actual) into at least pdf, xls, doc format documents
R2.5.2.17 M
Option to export summary reporting forms by registered voluntary
donors into at least pdf, xls, doc format documents
351
352
Section VI. Technical Requirements
R2.5.2.18 M
Option to print summary reporting forms by registered donors (possible,
potential, actual, voluntary).
R2.5.2.19 M
Option to export information about registered donors (possible,
potential, actual, voluntary) into at least pdf, xls, doc format documents
М
Registration of voluntary lifetime donors (individuals who had agreed to
extract one of their pair organs or part of organ/tissue) with possibility
to check availability of notary certified consent/denial through
interacting with state information system “Unified notary information
system” via health informatization and interoperability platform
according to Appendix 2-1 to the present technical specification. This
process includes as minimum the following:
R2.5.3
R2.5.3.1 M
Manage information on voluntary lifetime donor
R2.5.3.2 M
Selecting concrete recipient as a voluntary lifetime donor (according to
donor’s perception)
R2.5.3.3 M
Checking the availability of notary certified consent to be a donor
through interacting with state information system “Unified notary
information system” via health informatization and interoperability
platform
R2.5.3.4 M
Manage information on denial to be a donor
R2.5.3.5 M
Checking the availability of notary certified denial to be a donor through
interacting with state information system “Unified notary information
system” via health informatization and interoperability platform
R2.5.3.6 M
Option to print information on voluntary lifetime donor.
R2.5.3.7 M
Generating summary reporting forms on registered voluntary donors
over specific period of time
R2.5.3.8 M
Option to print summary reporting forms on registered voluntary donors
R2.5.3.9 M
Option to export summary reporting forms on registered voluntary
donors into at least pdf, xls, doc format documents.
R2.5.3.10 M
generating summary reporting forms on registered denials to be donors
over specific period of time
Section VI. Technical Requirements
353
R2.5.3.11 M
Option to print summary reporting forms on registered denial to be
donors over specific period of time
R2.5.3.12 M
Option to export summary reporting forms on registered denial to be
donors into at least pdf, xls, doc format documents.
R2.5.3.13 M
Option to export summary reporting forms on registered voluntary
lifetime donors into at least pdf, xls, doc format documents.
М
Registration of voluntary postmortal donors (individuals who had
agreed with retrieval of their organ/part of organ and/or tissue after their
death) with possibility to attach a scanned copy of notary certified
consent/denial according to Appendix 2-1 to the present technical
specification. This process includes as minimum the following:
R2.5.4
R2.5.4.1 M
Manage information about voluntary postmortal donor
R2.5.4.2 M
Selection of concrete recipient as voluntary postmortal donor (according
to donor perception)
R2.5.4.3 M
Attachment of scanned notary certified copy of consent
R2.5.4.4 M
Manage information about denial to be donor
R2.5.4.5 M
Attachment of scanned notary certified copy of denial
R2.5.4.6 M
Option to print information about voluntary post mortal donor.
R2.5.4.7 M
Option to export information on voluntary postmortal donor into at least
pdf, xls, doc format documents.
R2.5.4.8 M
generating summary reporting forms on registered voluntary donors
over specific period of time
R2.5.4.9 M
Option to print summary reporting forms on registered voluntary donors
R2.5.4.10 M
Option to export summary reporting forms on registered voluntary
donors to at least pdf, xls, doc format documents.
R2.5.4.11 M
Generating summary reporting forms on registered denials to be donors
over specific period of time
353
354
Section VI. Technical Requirements
R2.5.4.12 M
Option to print summary reporting forms on registered denial to be
donors over specific period of time
R2.5.4.13 M
Option to export summary reporting forms on registered denial to be
donors into at least pdf, xls, doc. format documents
R2.6
R2.6.1
module Republican transplantation coordinator
М
Manage register of donors of organs/part of organ and/or tissue (create,
edit, delete, view) This process includes as minimum the following:
R2.6.1.1 M
Manage information on donors of organs/part of organ and/or tissue
R2.6.1.2 M
Dropping a donor from the register with reason indication
R2.6.1.3 M
Searching patient by family name, IIN, organ/part of organ and/or
tissue, blood group, Rh etc.
R2.6.1.4 M
Option to print information on donors of organs/part of organ and/or
tissue.
R2.6.1.5 M
Option to export information on donors of organs/part of organ and/or
tissue into at least pdf, xls, doc format documents
R2.6.1.6 M
Generating summary reporting forms on registered donors of
organs/part of organ and/or tissue
R2.6.1.7 M
Option to print summary reporting forms on registered donors of
organs/part of organ and/or tissue
R2.6.1.8 M
Option to export summary reporting forms on registered donors of
organs/part of organ and/or tissue into at least pdf, xls, doc format
documents
R2.6.1.9 M
generating summary reporting forms on donors of organs/part of organ
and/or tissue dropped from the register
R2.6.1.10 M
Option to print summary reporting forms on donors of organs/part of
organ and/or tissue dropped from the register
R2.6.1.11 M
Option to export summary reporting forms on donors of organs/part of
organ and/or tissue dropped from the register to at least pdf, xls, doc
format documents.
Section VI. Technical Requirements
R2.6.2
М
355
Manage waiting list (create, edit, delete, view options). This process
includes as minimum the following:
R2.6.2.1 M
Manage the waiting list
R2.6.2.2 M
Reviewing request to be dropped from the waiting list of regional
transplantation coordinator
R2.6.2.3 M
Dropping the patient from the waiting list with reason indication
R2.6.2.4 M
Option to print information about individuals needed transplantation
R2.6.2.5 M
Option to export information about individuals needed transplantation
into at least pdf, xls, doc format documents
R2.6.2.6 M
Generating summary reporting forms on registered individuals needed
transplantation over specific period of time
R2.6.2.7 M
Option to print summary reporting forms on registered individuals
needed transplantation
R2.6.2.8 M
Option to export summary reporting forms on registered individuals
needed organ/tissue transplantation over specific period of time into at
least pdf, xls, doc format documents.
R2.6.2.9 M
generating summary reporting forms on patients dropped from the
waiting list over specific period of time
R2.6.2.10 M
Option to print summary reporting forms on patients dropped from the
waiting list
R2.6.2.11 M
Option to export summary reporting forms on patients dropped from the
waiting list into at least pdf, xls, doc format documents.
М
Automated sending by e-mail of reminder to carry out scheduled
quarterly testing. This process includes as minimum the following:
R2.6.3.1 M
Automated generation of a list of patients for scheduled quarterly
leucocytal antibodies testing, 10 days prior to the planned test date.
R2.6.3
355
356
Section VI. Technical Requirements
R2.6.3.2 M
Automated sending by e-mail to a candidate for transplantation of a
reminder to carry out scheduled quarterly testing upon 10 days prior to
the planned test date.
R2.6.3.3 M
Automated sending by e-mail of a reminder to the regional and
republican transplantation coordinator of lists of patients to carry out
leucocytal antibodies testing 10 days prior to planned test date
М
Automated calculation of score points to define a position in the waiting
list based on criteria table according to Appendix 3 to the present
technical specification. This process includes as minimum the
following:
R2.6.4.1 M
Automated calculation of score points to define a position in the waiting
list based on criteria table according to Appendix 3 to the present
technical specification
R2.6.4.2 M
Regular (at least once a day and if actual donor is found) automated
recalculation of score points to define position in the waiting list based
on criteria table according to Appendix 3 to the present technical
specification
М
Automated selection of the group of potential recipients against donor.
This process includes as minimum:
R2.6.5.1 M
Searching donor by family name, IIN, organ/part of organ and/or tissue,
blood group, Rh etc.
R2.6.5.2 M
Automated selection of the group of potential recipients against donor.
R2.6.5.3 M
Option to print information about individuals selected as potential
recipients against donor.
R2.6.5.4 M
Option to export information about individuals selected as potential
recipients against donor into at least pdf, xls, doc format documents.
М
Automated selection of the group of potential recipients against donor
with regard to several organs/tissues. This process includes as
minimum:
R2.6.6.1 M
Searching donor by family name, IIN, organ/part of organ and/or tissue,
blood group, Rh etc.
R2.6.4.
R2.6.5
R2.6.6
Section VI. Technical Requirements
357
R2.6.6.2 M
Automated selection of the group of potential recipients against donor
with regard to several organs/tissues.
R2.6.6.3 M
Option to print information about individuals selected as potential
recipients against donor with regard to several organs/tissues
R2.6.6.4 M
Option to export information about individuals selected as potential
recipients against donor with regard to several organs/tissues into at
least pdf, xls, doc format documents.
М
Automated selection of the group of donors against patient needed
transplantation. This process includes as minimum:
R2.6.7.1 M
Searching patient by family name, IIN, organ/part of organ and/or
tissue, blood group, Rh and other or selection of a patient from the
waiting list.
R2.6.7.2 M
Automated selection of the group of donors against patient needed
transplantation.
R2.6.7.3 M
Option to print information on individuals selected as potential donors
against the patient.
R2.6.7.4 M
Option to export information about individuals selected as potential
donors against the patient into at least pdf, xls, doc format documents.
М
Automated selection of the group of donors against the patient needed
transplantation with regard to several organs/tissues. This process
includes as minimum:
R2.6.8.1 M
Searching patient by family name, IIN, organ/part of organ and/or
tissue, blood group, Rh and other or selection of a patient from the
waiting list.
R2.6.8.2 M
Automated selection of the group of donors against patient needed
transplantation with regard to several organs/tissues.
R2.6.8.3 M
Option to print information about individuals selected as potential
donors against patient with regard to several organs/tissues.
R2.6.8.4 M
Option to export information about individuals as potential donors
against patient with regard to several organs/tissues into at least pdf, xls,
doc format documents.
R2.6.7
R2.6.8
357
358
Section VI. Technical Requirements
М
Manage information about council of physicians’ decision about
transplantation. This process includes as minimum:
R2.6.9.1 M
Manage information about council of physicians (participants, venue,
date etc)
R2.6.9.2 M
Manage council of physicians’ decision about transplantation
R2.6.9.3 M
Option to print information about council of physicians and decision
taken.
R2.6.9.4 M
Option to export information about council of physicians and decision
taken into at least pdf, xls, doc format documents.
R2.6.9
R2.7
R2.7.1.
module Transplantation brigade
М
Manage information on donor organs and tissues withdrawn. This
process includes as minimum:
R2.7.1.1 M
Manage information on donor organs withdrawn
R2.7.1.2 M
Manage information on donor tissues withdrawn
R2.7.1.3 M
Manage information on surgery for organ withdrawal (health facility
name, where the surgery was carried out, ICD-9 code, information about
anesthesia etc)
R2.7.1.4 M
Option to print information about donor organs and tissues withdrawn.
R2.7.1.5 M
Option to print information about surgery on organ withdrawn
R2.7.1.6 M
Option to export information about donor organs and tissues withdrawn
into at least pdf, xls, doc format documents.
R2.7.1.7 M
Option to export information about surgery on organs withdrawn into at
least pdf, xls, doc format documents.
R2.7.1.8 M
generating summary reporting forms on organs and tissues withdrawn
over specific period of time
R2.7.1.9 M
Option to print summary reporting forms on organs and tissues
withdrawn
Section VI. Technical Requirements
359
R2.7.1.10 M
Option to export summary reporting forms on organs and tissues
withdrawn into at least pdf, xls, doc format documents.
R2.7.1.11 M
Generating summary reporting forms on carried out surgery operations
for organs/tissues withdrawn over specific time period
R2.7.1.12 M
Option to print summary reporting forms on carried out surgery
operations for organs/tissues withdrawn
R2.7.1.13 M
Option to export summary reporting forms on carried out surgery
operations for donor organs/tissues withdrawn into at least pdf, xls, doc
format documents.
М
Manage information on carried out organ and tissue transplantation.
This process includes as minimum:
R2.7.2.1 M
Manage information on donor organs/tissues transplanted to the
recipient
R2.7.2.2 M
Manage information on surgery on organ transplantation (health facility
name, where surgery operation was carried out, ICD-9 code,
information about anesthesia etc)
R2.7.2.3 M
Manage information about pre and post surgery operation period,
immunosuppressive therapy, post surgery complications.
R2.7.2.4 M
Option to print information about donor tissue/organ transplanted to the
recipient.
R2.7.2.5 M
Option to print information about surgery operation on organ
transplantation
R2.7.2.6 M
Option to export information about donor organ/tissue transplanted to
the recipient into at least pdf, xls, doc format documents
R2.7.2.7 M
Option to export information about surgery operation on organ
transplantation to at least pdf, xls, doc format documents
R2.7.2.8 M
Generating summary reporting forms on donor organs and tissues
transplanted over specific time period
R2.7.2.9 M
Option to print summary reporting forms on donor organs and tissues
transplanted over specific time period
R2.7.2
359
360
Section VI. Technical Requirements
R2.7.2.10 M
Option to export summary reporting forms on donor organs and tissues
transplanted over specific time period into at least pdf, xls, doc format
documents
R2.7.2.11 M
generating summary reporting forms on carried out operations for
organ/tissue transplantation to the recipient over specific time period
R2.7.2.12 M
Option to print summary reporting forms on carried out operations for
organ/tissue transplantation to the recipient over specific time period
Option to export information on transplanted donor organ/tissue to the
recipient into at least pdf, xls, doc format documents
R2.8
М
module “monitoring of the condition of individuals whom
transplantation was carried out
R2.8.1.1 M
Manage register of individuals who were carried out with
transplantation (create, edit, view). This process includes as minimum:
R2.8.1.2 M
Manage information about individuals who were carried out with
transplantation
R2.8.1.3 M
Monitoring of the condition of the donor from whom transplantation
was performed.
R2.8.1.4 M
Searching a patient by full name, IIN, organ/part of organ and/or tissue
transplanted, blood group, Rh and other.
R2.8.1.5 M
Option to print information about patients who were carried out with
transplantation
М
Option to export information about patients who were carried out with
transplantation into at least pdf, xls, doc format documents.
R2.8.2.1 M
Monitoring of patients who were carried out with transplantation. This
process includes as minimum:
R2.8.2.2 M
Manage information about patients who were carried out with
transplantation
R2.8.2.3 M
Manage the history of change in the health status of the patients who
were carried out with transplantation
R2.8.1
R2.8.2
Section VI. Technical Requirements
361
R2.8.2.4 M
Monitoring of the condition of the individuals who were carried out
transplantation from the same donor.
R2.8.2.5 M
Viewing the history of change in the health status of the patients who
were carried out with transplantation with option to sort and filtrate by
patient age, sex, registration date, organ which was transplanted and
other criteria.
R2.8.2.6 M
Searching patient by full name, IIN, transplanted organ/part of organ
and/or tissue, blood group, Rh and other criteria.
R2.8.2.7 M
Option to print information on health status of the patients who were
carried out with transplantation
R2.8.2.8 M
Option to print history of change in the health status of the patients who
were carried out with transplantation
R2.8.2.9 M
Option to export information about patients who were carried out with
transplantation into at least pdf, xls, doc format documents
R2.9
module Generating analytical and statistical tables
R2.9.1
М
Report on carried out allogenic relative transplantations (recipient,
donor, and outcome family name list)
R2.9.2
М
Report on carried out allogenic non relative transplantations (recipient,
donor, and outcome family name list)
R2.9.3
М
Report on lethal outcomes of patients included in the waiting list (by
age, death reason, death date)
R2.9.4
М
Report on carried out transplantation: information on retrieved organs,
reasons for not performed selection, health facility where retrieval was
carried out
R2.9.5
М
Report on cases of statement of potential donor brain circulation
death/arrest (family name list, death date)
R2.9.6
М
Monthly reports according to Appendix 4-5 to the present technical
specification
R2.9.7
М
Daily report of regional transplantation coordinator according to
Appendix 6 to the present technical specification
361
362
Section VI. Technical Requirements
R2.9.8
М
All output forms shall have an option to print out and save in at least xls,
pdf, doc format.
1.1.4. Legal documents
Minimum set of regulations to be observed:
1) "law of the RK «on national security of the RK» № 527-IV dated 6 January 2012
(http://online.zakon.kz/Document/?doc_id=31106860);
2) President decree dated 14 November 2011 № 174 " On 2016 Kazakhstan information
security concept » (http://ru.government.kz/docs/u110000017420111114.htm);
3) Code of the RK N 193-IV dated 18 September 2009 “On people’s health health
system”;
4) Law “on personal data and their protection” N 94-V dated 21 May 2013
(http://online.zakon.kz/Document/?doc_id=31396226);
5) Order of acting minister of health of the RK dated 23 November 2010 № 907 «On
approval of health facility primary medical document forms»
6) Order of acting minister of health of the RK №75 dated 10.02.2014 “on approval of
technical documents on e-health issues».
(http://www.mz.gov.kz/index.php?option=com_content&view=article&id=662&Item
id=1001&lang=ru)
7) Order of minister of health of the RK dated 29 March 2013 № 199 «on measures of
organ and tissue transplantation service development in Kazakhstan»;
8) National regulatory framework defining requirements to EHR, EMR, e-health
processes and technical requirements on interacting with central components and
Kazakhstan е-health IS.
9) National regulatory framework defining requirements to processes of donation and
transplantation of tissue and (or) organs (parts of organs).
1.2.
Requirements to system configuration
#
Ty
pe
requirement
R
3
Requirements to system configuration
R
3.1
Configuration to health facility needs
R
3.1.1 М
The System shall provide an option to manage access to functionality based on
roles. System shall enable add/delete/edit roles and designate/cancel access right
to the system functionality.
R
3.1.2 М
System shall have preinstalled roles according to 1.2.1. of the present technical
specification with option of further adjustment (add, edit or delete new roles).
Section VI. Technical Requirements
363
R
3.1.3 М
Access rights to different system modules and functions must be preinstalled
according to Table 1 with option to change access rights (add, delete)
R
3.1.4 М
Access right must be at least configurable on the following aspects: all rights,
create, change, delete, view.
R
3.1.5 M
System shall include master of reporting forms, enabling to create and edit
reports using fields from the system database
1.2.1. Role description
1. Registering staff of an individual needed transplantation is a profile specialist who
constantly monitors the patient with regard to certain disease who has been included
into the waiting list. Positions: head of department, profile specialist, physician,
freelance specialist of health department, inpatient transplantation coordinator,
regional transplantation coordinator, republican transplantation coordinator
2. Inpatient transplantation coordinator – controller and initiator of donorship of tissues
and (or) organs (part of organs) in health facilities, who is full time inpatient staff
member. Position: inpatient transplantation coordinator.
3. Lab technician is lab staff member, who is in charge of entering into the System of
lab testing data of donors, recipients, and individuals needed transplantation. Position:
lab technician, lab physician, lab specialist.
4. Regional transplantation coordinator is a physician, organizer of interhospital
cooperation of health facilities in the area of tissue and (or) organs (part of organs)
transplantation in oblast centers of the RK. Position: Regional transplantation
coordinator.
5. Republican transplantation coordinator is health facility staff member who
coordinates activity of health facilities in the area of tissue and/or organ (parts of
organs) transplantation. Position: physician coordinator, RCCT staff member.
6. Physician is health specialist, who carries out constant monitoring the patient’s
certain disease which is the reason of putting this patient into the waiting list and also
he provides medical care to the patient after transplantation. Positions: head of
department, profile specialist, physician, freelance specialist of health department.
7. Administrator is specialist administering the System (account setting, access right
distribution etc). Positions: TCCT staff member.
Table 1 – roles access right to module functions
№
1.
1.1.
Requirement
Roles
module “Registration of an individual needed
transplantation”
Registration in the waiting list of an individual needed Registering staff member
transplantation according to the form stated in of an individual needed
Appendix 1-1, 1-2, 1-3 to the present technical transplantation
specification. Option to register one patient in several
363
364
Section VI. Technical Requirements
waiting lists.
1.2.
Automated receipt of information about necessity to Registering staff member
be registered in the waiting list of an individual needed of an individual needed
transplantation based on the information received from transplantation
IS of the MHSD of the RK (this functionality shall be
implemented as soon as required functionality of the
stated above IS will be available for interaction).
1.3.
Entry of information about current state of individual Registering staff member
needed transplantation (improving or worsening of the of an individual needed
course of the disease with regard to progress, transplantation
development of complications, concomitant disease
and other).
1.4.
Waiting list monitoring.
2.
Registering staff member
of an individual needed
transplantation
module Inpatient transplantation coordinator
2.1.
Registration of possible donor under the form Inpatient transplantation
according to Appendix 2 to the present technical coordinator
specification.
2.2.
Registration of potential donor under the form Inpatient transplantation
according to Appendix 2 to the present technical coordinator
specification.
2.3.
Registration of actual donor under the form according Inpatient transplantation
to Appendix 2 to the present technical specification.
coordinator
2.4.
Entry of information about current donor objective Inpatient transplantation
status (possible, potential, actual),
coordinator
3.
3.1.
4.
module Lab testing
Entry of performed lab testing results including but not Lab technician
limited to the information about high, medium, low
performance immunological tissue typing testing
results of individuals recommended for transplantation
and potential donors (form №410-10/у), information
about individual cross match results of potential donors
and individuals recommended for transplantation (form
№410-11/у), leucocyte antibodies testing results of
candidates for transplantation (form №410-9/у).
module Regional transplantation coordinator
Section VI. Technical Requirements
365
4.1.
Generating request to be dropped from the waiting list Regional transplantation
with a reason indication (death, change of place of coordinator
living, no need in transplantation, contradictions to
transplantation etc).
4.2.
Monitoring of donors (possible, potential, actual, Regional transplantation
voluntary).
coordinator
4.3.
Registration of voluntary lifetime donors (individuals Regional transplantation
who had agreed to extract one of their pair organs or coordinator
part of organ/tissue) with possibility to check
availability of notary certified consent/denial through
interacting with state information system “Unified
notary information system” via health informatization
and interoperability platform according to Appendix 21 to the present technical specification.
4.4.
Registration of voluntary postmortal donors Regional transplantation
(individuals who had agreed with retrieval of their coordinator
organ/part of organ and/or tissue after their death) with
possibility to attach a scanned copy of notary certified
consent/denial according to Appendix 2-1 to the
present technical specification.
5.
module Republican transplantation coordinator
5.1.
Manage register of organ/part of organ and/or tissue Republican transplantation
donors (create, edit, delete, view).
coordinator
5.2.
Manage waiting list (create, edit, delete, view).
5.3.
Automated sending by e-mail of reminder to carry out
scheduled quarterly testing.
5.4.
Automated calculation of score points to define a
position in the waiting list based on criteria table
according to Appendix 3 to the present technical
specification
5.5.
Automated selection of the group of potential Republican transplantation
recipients against donor.
coordinator
5.6.
Automated selection of the group of potential Republican transplantation
recipients against donor with regard to the need in coordinator
several organs/tissues.
Republican transplantation
coordinator
365
366
Section VI. Technical Requirements
5.7.
Automated selection of the group of donors against a Republican transplantation
patient needed transplantation.
coordinator
5.8.
Automated selection of the group of donors against a Republican transplantation
patient needed transplantation with regard to the need coordinator
in several organs/tissues.
5.9.
Manage council
transplantation.
6.
of
physicians’
decision
about Republican transplantation
coordinator
module Transplantation brigade
6.1.
Manage information about donor organs and tissues Transplantation brigade
retrieved.
6.2.
Manage information about performed organ/tissue Transplantation brigade
transplantation.
7.
module Monitoring
transplantation
of
individuals
received
7.1.
Manage
register
of
individuals,
transplantation (create, edit, delete, view).
7.2.
Monitoring of health status of individuals received Republican transplantation
transplantation.
coordinator
Regional
transplantation coordinator
8.
received Republican transplantation
coordinator
module Generating analytical and statistical tables
8.1.
Report on cases of statement of potential donor brain Republican transplantation
circulation death/arrest (family name list, death date)
coordinator
Regional
transplantation coordinator
8.2.
Monthly reports according to Appendix 4-5 to current Republican transplantation
technical specification
coordinator
Regional
transplantation coordinator
8.3.
Monthly report of regional transplantation coordinator Republican transplantation
according to Appendix 6 to present technical coordinator
specification
Regional transplantation
coordinator
8.4.
All output forms must have option to print and save in Republican transplantation
at least xls, pdf, doc format.
coordinator
Regional
transplantation coordinator
9.
module Administration
Section VI. Technical Requirements
367
9.1.
Setting System user account.
9.2.
Setting system user rights and strict designation of administrator
responsibilities based on regional and administrative
criteria.
9.3.
Configuration of criteria for automatic selection of administrator
appropriate recipient from the waiting list..
9.4.
Configuration of registration forms of recipients/ administrator
donors.
9.5.
Data import to system from at least xls, xml file administrator
formats.
9.6.
Manage system journals.
1.3.
administrator
administrator
Requirements to system response time
#
type
requirement
Requirements to system response time
M
Search of patient by full name or IIN and patient related data
(examination results, lab test results etc) shall not be more than 5
seconds for 80% of cases
R 4.2
М
Supplier during guaranteed period of service shall ensure the
following system performance parameters:
R 4.3
М
Total system shutdown time for the reason related to its operability
shall not be more than 24 hours per year.
R 4.4
М
One time system shutdown for the reason related to its operability
shall not be more than 2 hours.
1.2.3 Requirements to the system information security
Тyp
e
R
5
requirement
Requirement to information security
R 5.1
M
Requirement of security are defined by existing law of the RK. System
shall comply with information security requirements in terms of
providing threshold access, protection from unsanctioned access etc.
R 5.2
M
Information protection from unsanctioned access means shall be
provided in the system namely:
367
368
Section VI. Technical Requirements
R 5.2.1
M
User identification based on user name (login) and password
validation
R 5.2.2
M
Option to identify user based on public key infrastructure digital
certificates
R 5.2.3
M
User authorization for access to system information resources, that
require appropriate authorizations
R 5.2.4
M
Personified user right determination for data management, fine-tuning,
view
R 5.2.5
M
Personified user right determination for system resource access
R 5.2.6
M
Designation of system user rights by roles, groups and access level
with regard to object hierarchy and organizational structure ownership.
R 5.2.7
M
User work protocol maintenance with System critical functions and
applications
R 5.2.8
M
System file protection from change/damage by unauthorized users and
program processes
R 5.2.9
M
Control journal of all updates in system program libraries shall be
maintained
R 5.3
M
The following minimum backup means shall be realized in the system:
- automated backup with option of planning
- remote control of backup creation
- full and partial backup
R 5.4
M
System shall provide data integrity.
R 5.5
M
System shall provide tools for data confidentiality coding during
storage and in the process of transfer to other systems.
R 5.6
M
Electronic digital signature (hereinafter registration certificate of user
by National Authorization Center of the Republic of Kazakhstan,
EDS) shall be issued by NAC RK. The system shall provide the tools
for digital signature of documents (objects) or portions of documents,
when / if it is needed, and tools for signature authentication. This
option shall be implemented in the system services (if necessary). To
ensure EDS authenticity and public key validity, the System shall
provide check for EDS authenticity using services of NAC RK
(http://pki.gov.kz/index.php/ru/).
R 5.7
M
System shall conform to the “single access point” principle
information structure architecture enabling to have single access point
(Single Sign On) to all its components and resources, enabling to enter
login and password once and get access to all system components
Section VI. Technical Requirements
369
without entering password once again.
R 5.8
M
System shall provide user authorization in the System, designation of
system user rights by roles, groups, access level with regard to object
hierarchy and organizational structure ownership.
R 5.9
M
According to regulatory documents on information security approved
by the MHSD of the RK, the following shall be realized:
− Password length shall not be less than 8 symbols, letters
and numbers must be in upper and lower case;
− Forced password change function;
− Empty password lockout function;
− User password self-change;
− CAPTCHA be realized for incorrect password entry for
3 times;
− All user actions log in journal for viewing history of all
system main events changed;
− functionality of session interruption if inactive in N
time period.
1.2.4 Requirements to system quality attributes
N
type
Requirement
R
6
Requirements to system quality attributes
R
6.1.
M
System must support entry, receipt and transfer of data required
for work of IS of the MHSD of the RK used by health facility and
avoid double data entry.
R
6.2.
M
System shall ensure saving of all accumulated information at the
moment of shutdown or failure of any system component
regardless its assignment, with follow-up recovery after repair and
recovery work
R
6.3
M
System shall have option of soft fine-tuning in changing
environment and user specific tasks without replacing the
modules.
R
6.4
M
System shall be highly scalable and enabling operation of
unlimited number of users. Restrictions can be conditioned only
by hardware technical characteristics and not by the System
characteristics
R
6.5
M
All system functional features must be developed as services.
R
6.6
M
System web services must be developed according to SOA
architecture.
R
6.7
М
In realization of interoperability services it is required to follow
369
370
Section VI. Technical Requirements
the standard of the MHSD of the RK concerning interoperability
of IS
R
6.8
M
System shall provide possibility of designing of approved medical
form templates available within the solution itself which could be
automated without programming or incorporating modifications
to the program code.
R
6.9
M
System shall provide conflict resolution under parallel system
object processing.
1.2.5 Requirements to user interface
N
type
R
7
requirement
Requirement to user interface
R 7.1
M
Interface shall be provided for prevailing use of mouse
manipulator meaning that system control shall be using screen
menu, buttons, icons and similar elements
R 7.2
M
Keyboard mode must be used mainly in filling in and/or editing
text and numeric fields of screen forms. Also hot buttons must be
provided for moving between fields to be filled in.
R 7.3
M
Ergonomic solutions and interface design must be uniform for all
system components and modules as possible
R 7.4
M
System user interface must be multilingual ad organized with
support of at least state (Kazakh) and Russian languages.
Exclusions could be system messages which are not subject to
localization or standard administrative applications included into
system software
R 7.5
M
Access to electronic package of maintenance documentation must
be available
R 7.6
M
Context sensitive reference system must be realized in the system,
accessible from different web application pages where references
to information must be provided (user guidebook, manual etc.),
for work with possibility of configuration without engagement of
potential supplier at the level of purchaser;
R 7.7
M
In the system user interface screen visual highlight of attributes
must be provided for operator only for reading
R 7.8
M
In the system user interface screen visual highlight of attributes
required for filling in must be provided
R 7.9
M
System shall provide correct processing of emergency situations
caused by incorrect user actions, incorrect format or invalid entry
Section VI. Technical Requirements
371
data. In the above mentioned cases the system must deliver
corresponding messages to the user, then go back to operation
mode, that preceded incorrect (inadmissible) command or
incorrect data entry
R 7.10
M
System shall not allow for backup and reentry (incorrect entry) of
uniform information. System shall ensure exclusion of backup and
reentry of information contained in state database and information
systems of state bodies
R 7.11
M
System shall provide format-logic control of data entry. Format
logical control of entered data means control of format and
content of entered data. During operation the system shall provide
for protection from mis-actions:
- selection of only user accessible functions according to access
rights;
- entry only user accessible values (according to access rights);
- certain format data entry (for example, impossibility to enter
symbol data into the date or number format fields).
1.3 Requirement to system interoperability
№
type
requirement
R
8
Requirement to system interoperability
R
8.1
General requirements to system interoperability
R
8.1.1
M
System solutions and applications must comply with
interoperability standards including to national standards and
adopted international standards listed in this chapter (and in this
document).
R
8.1.2
M
System components must comply with national semantic tools:
o Reference books and classifiers
o Requirements to reference book services
o Requirements to registers and register services
Details on requirements for these tools are given in this
section below (R8.3)
R
8.1.3
I
Some of compatibility tools described below are in the process of
development and last versions are provided to potential suppliers
as requested. Main standards are given in website of the MHSD
of
the
RK
(Order
№75
dated
10.02.2014
https://www.mzsr.gov.kz/node/319759
R
8.2
R
8.2.1
Compatibility with standards
M
System components must be compatible at least with the
following standards of the MHSD of the RK:
371
372
Section VI. Technical Requirements
1) standards requirements to e-health record (requiring
compliance with EN 13940)
2) standard requirements to e-medical record (requiring
compliance with EN 13940)
3) standard requirements to identification of existing health
parties, used in e-health systems
4) technical requirements to interoperability (message transfer)
with e-health information systems
5) regulations for ensuring information security
6) Standard requirement’s to single classifier of drugs, medical
supplies and medical equipment
7) Standard requirement’s to realization and regulation of edirections
8) Regulation for interaction of stakeholders to ensure
interoperability of information systems and information flow
management
9) Standard for regulation of e-receipts management
10) Standard for management of e-processes of diagnostic
studies and cure procedures
11) Standard for regulation of e-preventing of diseases
The mentioned standards and regulatory documents are available
at https://www.mzsr.gov.kz/taxonomy/term/619
R
8.2.2
M
System components must be compatible with the following
international standards:
a. EN 13940 (on the part of compliance with
standards of EHR and EMR)
b. HL7 v3 (ISO/HL7 27831) HL7 (v2 orV3 or
FHIR);
c. HL7 CDA (ISO/ HL7 27932)
d. DICOM
8.2.3
M
System shall comply with requirements of standards on
information security:
 ST RK ISO/IEC 27001-2008 «methods and tools of
ensuring safety of information security management
system. Requirements»;
 ST RK ISO/IEC 27002-2009 «Information technology.
Tools of assurance. Guidebook on information protection
management».
R
8.3
R
8.3.1
Requirements to compatibility with national identifiers and
standard classifiers/reference books
M
System components must support and comply with requirements
to national identifiers:
- patient identifier
Section VI. Technical Requirements
373
- health facility identifier
- medical staff identifier
- medical equipment identifier
R
8.3.2
M
System components must support and comply with requirements
for at least under the following national classifiers and reference
books:
1) national classifier of drugs and supplies (mapped to АТСDDD )
2) medical service classifier (based on ICD-9, section on services
etc)
3) lad testing results classifier
4) service and their cost classifier
5) diagnosis classifier (ICD-10)
6) PHC classifier (ICPC-2)
7) mapping ICPC-2 and ICD-10
8) SNOMED, only for coding of communication between
System and EHR repository)
9) to manage diagnostic services enhanced classification system
shall be defined at the later stage;
10) national DRG system for patient classification implemented
by the MHSD of the RK (in providing specialized care);
11) classifier of target patient group registers (dispensary
groups).
12) rater of medical services;
13) list of health specialties;
14) list of positions
R
8.4
R
8.4.1
M
System components must provide communication between the
system and platform containing EHR repository based on the
following data:
- minimum set of data for EHR (given in Appendix to National
EHR standard and national EMR standard)
- other data, not covered by semantic standards, but required
according to regulatory acts of the MHSD of the RK such as
attached special records (documents based on CDA)
R
8.4.2
M
System must provide access to data stored in EHR repository
according to 2 EHR types: full EHR, short EHR. Details are
described in national EHR standard
R
8.4.3
M
Data are transferred between the system and EHR repository in
CDA format
R
8.4.4
M
System shall provide data transfer to EHR repository based on
ICPC-2 codes, which are used in visits (and in contacts in
Requirements to compatibility/data conformity
373
374
Section VI. Technical Requirements
general) and mapped to ICD-10 for the purpose of statistics
collection. In information systems of EMR (except for EHR
/PHC systems) specialists use ICD-10 for diagnosis coding, and
mapping in reverse order is not mandatory but desirable.
R
8.4.5
I
Systems could have additional database and repositories required
for full functionality (so called EMR in the context of MHSD of
the RK, but they are stored separately from EHR repository
database. EHR repository content is strictly regulated by the
national EMR standard.
R
8.4.6
M
System shall be sufficiently public to provide interoperability
with existing IS of the MHSD of the RK, applications and
services
R
8.5
R
8.5.1
M
System shall interact with national HER system according to
National standards of EHR and EMR
R
8.5.2
M
System shall support as minimum interoperability with the
following e-health service sets:
- EHR repository service;
- reference information services;
-registration and register services;
-clinical nomenclature and data classification services;
- Secure information exchange and message exchange services;
- Identification and authentication services;
- monitoring and audit for information exchange services
R
8.5.3
M
The system shall comply with at least the following IHE profiles:
a) IHE infrastructure profiles:
 ATNA;
Requirements to information exchange
 XDS.b;
 PDQ;
 PIX;
R
8.5.4
M
System shall ensure option of interaction/integration using at
least the following protocols and specifications:
a. Communication through SOAP (and message SOAP
with application), REST, Message Transmission
Optimization Mechanism;
b. Support of standards and specifications of web services
(WS-Security, WS-Addressing, WS-Reliable Messaging,
WS-coordination,
WS-Transaction,
WS-Secure
Conversation);
Section VI. Technical Requirements
375
c. Compliance with XML (XML, XSL, ebXML, и др.);
d. Support SSO and control of access through SAML v2,
JWT;
e. Support general standards such as HTTP, HTTPS,
TCP/IP, (SSL v3) and TLS;
f. Enable using WSDL, WADL;
g. X.509;
Digital signatures (EDS NAC RK).
R
8.5.5
System shall support coding of at least UTF8.
R
8.5.6
M
System shall interact with platform services under speed of
channel 1 Мb/s and response time not more than 100 ms
R
8.6
M
Intersystem communication
R
8.6.1
M
Interaction with IS of MHSD of the RK in receipt of date of
health facilities, functional departments and health facility staff,
as well as general reference information used in the IS MHSD of
the RK РК
R
8.6.2
M
Interaction with IS of MHSD of the RK on receiving data about
individuals who are dispensary registered
R
8.6.3
Interaction with IS of MHSD of the RK on receiving data about
individuals and their attachment, death (reason of death, date of
death)
R
8.6.4
Interaction with IS of MHSD of the RK on receiving information
about patient staying in hospital (form № 066/у)
R
8.6.5
System shall interact with platform services on the part of:
 transfer/receipt of notifications and other information to
e-government service;
 sending SMS-notification and other messages through
SMS service of mobile government system;
 sending e-letters to patients though single e-mail system;
 receiving information about power of attorney from state
information system Unified notary information system;
 receiving information from information about registered
visit at doctor;
 receiving minimum information about staff member.
375
376
Section VI. Technical Requirements
1.3.3 Accompanying information about technology of some issues
1.3.4 Use of national e-health resources and platform tools
System shall be able to use national resources and published Kazakhstan e-health
services.
N
Тype
Requirement
R 9
Use of national e-health resources and platform tools
R 9.1
M
System shall be able to function according to general e-health
architecture (Fig 2)
R 9.2
M
System shall be able to use functionality and web services,
published on national level for interaction with e-health
resources.
R 9.3
M
System shall be able to use EHR repository national classifiers
and indexes (as minimum main patient index, health facility
department index, staff index, building index, address index,
vehicle index, medical technique index), analytical storage and
other national resources required for turnkey integration
according to national standards (listed in MOH of the RK order
№75 dated 10.02.2014)
R 9.4
M
System shall support local copies of national resources and be
able synchronize them on a regular basis (according to
adjustable schedule) or online. System shall contain only
information concerning health facility operation. For example,
main patient index must be contained locally only for the list of
patients who receive care in that facility.
1.3.5 Interaction with parties involved into certification process
№
R 10
R 10.1
Тype
I
R 10.2
M
R 10.3
M
requirement
Interaction with parties involved into certification process
Contract related to supply of platform and national e-health
resources is carried out with present contract in parallel.
Supplier of platform will be provided with access to national
e-health resources only after parallel contract will be
implemented successfully. To ease parallel implementation it
is necessary to synchronize/coordinate joint activities.
Interaction of involved parties is described in Fig 3. Activities
undertaken by supplier are described in 4th column “Private
IT companies”
System supplier must interact with supplier of platform,
health facility and MHSD of the RK to test and certify
interoperability with national resources and services.
Supplier must coordinate interaction of involved parties
according to Fig 3. Certification based on evaluation of
implemented System compliance with requirements of R8.2.
The Purchaser shall establish special Committee that jointly
with the Platform Supplier and Supplier of this system shall
make tests in line with Rule Book for compliance to
Section VI. Technical Requirements
R 10.4
M
R 10.5
M
R 10.6
M
R 10.7
M
377
M
interoperability requirements according to national standards
including possibility for correct interaction of delivered
system with national resources delivered within the Platform.
At the stage of system design (activity 4.4) Supplier must
comply with requirements of regulations for web service
development” and requirements to interoperability with EHR
repository provided by platform supplier. System supplier
may request additional information if needed for development
of interaction with e-health resources.
At the stage of testing/certification (activity 4.6) system
Supplier must comply with requirements of guidebook
published by MOH of the RK e-health standardization unit
The Supplier shall certify the System before its acceptance
into operation
In case of circumstances that hinder fulfillment of R10.6
occurred by no fault on the side of the Supplier, Acts of
System acceptance shall be signed without certification. With
it, System Supplier is bounded to certify the System when
conditions for certifications have appeared, without any
additional costs on the side of the Purchaser
System shall provide option of functioning on remote
infrastructure and in cloud (virtualized) operating
environment
I
Contract related with supply of platform of health
informatization and interoperability (hereinafter platform) is
carried out in parallel with the present contract.
R 10.8
R 10.9
R 10.10
M
The system supplier shall be granted with access to national
e-health resources only after parallel contract will be
successfully realized. To ease parallel implementation it is
necessary to synchronize/coordinate joint activities with
platform supplier. In case of circumstances arisen that impede
performance of requirements on interaction with the platform
due to delay in Platform supply contract performance, system
supplier is obliged to implement interaction when conditions
will appear without additional costs on the side of the
Purchaser.
377
378
Section VI. Technical Requirements
Fig. 3. Interoperability of involved parties during the System implementation and
certification.
1.4 Requirements to suppliers
N
Тype
requirement
R
11
Requirements to suppliers
R
11.1 M
Supplier will supply his own system (components or products
constituting it) or he will be authorized by developer/owner of this
Section VI. Technical Requirements
R
11.2
M
R
11.3
M
R
11.4
M
379
system (components or products of its) for supply, development,
installation, support of products according to this Contract.
Supplier will train in the country of Client which is related to System
use and administration, and also of all developed and installed
products. Training languages will be Russian and Kazakh. Training
details are given in R13.2.
Supplier shall have office in Purchaser country or have a partner
registered as a legal entity in the Purchaser country having an official
status of a partner developer/supplier or having agreement about
consortium in relation with this specific contract. It is required during
realization, deployment, training and guaranteed period for smooth
and reliable contract implementation.
Supplier shall have his own project implementation team comprising
at least the following specialists (if needed two positions may be
taken by one specialist provided his skills will be proved but not
more than 2 positions for a specialist):
1) business analyst, having work experience of at least 3 years in IT
e-health projects and work experience in at least one similar project;
2) project management specialist (team leader), having at least 3
years of experience in project management and 1 year in the project
when supplied solution was implemented and he should have project
management certificate (for example, PMP or IPMI at least);
3) DBMS specialist with at least 3 years of work experience with
DBMS;
4) specialists with work experience of at least 2 years with standards:
HL7, DICOM, CDA (R2), IHE;
5) user interface designer, with at least 3 years of work experience;
6) technical writer, with work experience of at least 2 years;
7) specialist on communications, with work experience in this area of
at least 3 years of general IT experience with excellent knowledge of
English, Russian and Kazakh;
8) Specialist on testing, having at least 3 years of experience in
software testing;
9) Specialist on training, having at least 3 years’ experience in
carrying out training;
All supposed specialists shall have higher education in IT or related
areas, Master’s degree is preferred. Supplier shall provide a list of
specialists with CV attached, certificates to provide work experience
and qualification.
R
11.5
M
Supplier shall submit all documents (patents, licenses, certificates of
state registration of rights to copyright, etc.) for System (for all
components and products), demonstrating authorization of owners to
379
380
Section VI. Technical Requirements
use products for this contract or demonstrating ownership rights.
R
11.6
M
Plan schedule of services provided must be agreed with authorized
organization of the purchaser and signed by Purchaser within 20
(twenty) working days after signing the contract. Supplier must
provide service in time according to approved plan schedule.
R
11.7
I
R
11.8
M
R
11.9
M
In case of participation of foreign companies consortium is the most
appropriate form of participation in the tender (while it is not
mandatory), since some requirements assume knowledge and skills
which are not possessed by international suppliers like work
experience in the country.
Software manufacturers shall have certificates of Capability Maturity
Model Integration (CMMI), ISO 9000 series, ST RK ISO 9001:2009
or equivalent for quality management processes (the Bidder shall
submit copies of certificates for compliance issued by authorized
body)
Supplier shall ensure service and technical and guarantee support
including provision of new product versions according to R13.3 and
R13.4.
R
11.10
M
Supplier shall prepare corresponding guidelines for all system
components in English, Kazakh and Russian.
R
11.11
M
Supplier shall have proven experience with standards used in the
present document: HL7 (v2, V3, FHIR), CDA (R2), IHE.
Section VI. Technical Requirements
381
C. Technical specifications
2.1. General technical requirements to the system
N
type
Requirement
R 12
General technical requirements to the system
R
12.1
М
System shall have centralized architecture and be developed in
the form of web application where the client is browser and
server is web-server.
R
12.2
М
Access to client application must be done though any of the
following internet browsers: MS Internet Explorer, Google
Chrome, Opera, Safari, Mozilla Firefox
R
12.3
M
System server part must support work of at least in operational
systems of Windows family.
R
12.4
M
System client part must support work of at least in operational
systems Windows (2008/VISTA/7/8) (x86/x64)
R
12.5
M
To store information in the system relational database shall be
used.
R
12.6
M
System database must support standard SQL, compatible with
ANSI/ISO/IEC 9075-1992 standard
R
12.7
M
Supplier shall provide maintenance and technical support
including provision of new product versions until guaranteed
period expiration
R
12.8
System shall provide option of authentication using Single Sign
On
2.2 service specification
N
Тype
R
13
R
13.1
R
13.1.1
M
R
13.1.2
M
R
R
13.2
13.2.1
M
requirement
Service Specification
Requirement to inheritance of data and functionality.
In case of system supply and implementation different from
exploited by the client the performer carries out full complex of
required works related to inheritance of data and functionality
used IS modules by the client with connection to the system of
software and automated technical means, medical and lab
equipment used by the client.
All costs related to data and functionality migration is incurred by
the performer.
Training and training materials
Supplier shall prepare curriculum for training of the following:
System users;
System administrators;
Developers;
381
382
Section VI. Technical Requirements
Database administrators.
Curriculum and training materials on each group shall be agreed
with Purchaser before the training starts.
Supplier shall provide equipment, presentation materials and
textbooks for the training.
System supplier shall provide training materials as guidelines,
textbooks and presentations, knowledge bases in state language
and Russian.
Supplier shall carry out training for at least 80 hours for each
group of system administrators, developers,
database
administrators and 20 hours for the users of each health facility,
where system implementation takes place. Number of hours
could be increased and must be sufficient for knowledge and
skills transfer.
Supplier shall carry out separate training for system users and
administrators, developers, database administrators. Indicative
number of trainees is defined by multiplication by 2 of total
number of automated work places from Appendix 7. Place of
training is legal address of health facility-beneficiary. Groups of
trainees shall include not more than 10 specialists.
For all carried out trainings, Supplier must carry out testing and
issue certificates correspondingly.
Training plan for group (а) – system users – shall contain detailed
explanation of automated business processes, sue of all system
components, detailed description of function and interactions
between different users and roles; reporting and other required
information. Training also will contain practice trainings for
material understanding
R
13.2.2
M
R
13.2.3
M
R
13.2.4
M
R
13.2.5
M
R
13.2.6
M
R
13.2.7
M
R
13.2.8
M
Training plan for group (b) – system administrators - shall
contain description of system components administration tools
including important system maintenance issues and technical
support aspects.
R
13.2.9
M
Supplier shall carry out one introductory course and one inservice training for group (c) developers on supplied
development tools and components provided within this contract.
R
13.2.10
M
Supplier shall carry out for group (d) database administrators one
introductory course and in-service training course on supplied
DBMS.
R
13.2.11
M
Training for groups (a) - (d) shall be carried out in Russian or
Kazakh at the Purchaser’s request.
R
13.2.12
M
For all carried out trainings, Supplier shall carry out
corresponding testing and issue certificates.
R
13.2.13
I
The number stated above and duration of training are minimum
requirements. Supplier at the Purchaser’s request can increase
these figures (in hours) to reach adequate skills level for the staff
Section VI. Technical Requirements
R
R
13.3
13.3.1
M
R
13.3.2
M
R
R
13.4
13.4.1
M
R
13.4.2
M
R
13.4.3
M
R
13.4.4
M
R
13.4.5
M
R
13.4.6
M
R
13.4.7
M
383
without extra costs incurred by the Purchaser. During this stage
of project preparation precise number of hours, groups and course
content will be agreed with the Supplier.
User support service
Supplier shall organize user support service for consulting on
issues arisen during exploitation for the whole period of
guaranteed service implementation and maintenance.
System technical support shall be organized by the Supplier 27/7
within 3 years upon the acceptance act agreed by the Purchaser.
Guaranteed service
System supplier will provide guaranteed service of the Purchaser
within 3 years starting right after agreement by the Purchaser of
the acceptance act.
Supplier shall ensure resolution of issues:
A)
For critical problems related to system operation that
has led to data damage, the problem shall be solved within
at most 2 hours;
B)
For noncritical problems it is to be rectified within not
more than 2 days.
Guaranteed service includes but it is not limited by the following
service categories:
- correcting errors in the system;
- help to the health facility in correct rectification of all
problems with data arisen as a result of wrong application
functions;
- providing technical support in adjustment of applications
or modifying default parameters;
- providing required technical support to qualified staff
and retraining if it is founded out that they could not solve
their problems after received training;
Forms of interference could be one of the following most
appropriate from the perspective of quality and effectiveness:
○
Phone calls;
○
By e-mail;
○
Skype or other Video Messenger;
○
Remote access to user;
○
Work on site.
Supplier must provide during guaranteed period a group of
consultants available in Purchaser’s country including one
manager and at least one technical specialist and provide all
required specialists for remote assistance if needed.
Total system idle time under reasons related to its operation shall
be greater than 24 hours.
One time system time out under reasons related to its operation
shall not be greater than 2 hours.
383
384
Section VI. Technical Requirements
2.3. REQUIREMENTS TO DOCUMENTS
N
type
requirement
R
14
requirement to documents
R
14.1
M
Supplier is required to provide the following package of
documents:
● Program and method of tests;
● formulary (main characteristics, kitting and deposit
software maintenance information);
● description of most widespread mistakes and their
mitigation ways;
● description of database structure;
● guideline for software installation;
● administrator guideline;
● user guideline.
R
14.2
M
Document languages shall be at least state and Russian
languages.
R
14.3
M
Supplier shall provide 5 packages of documents in hard copy and
electronic format in English, Kazakh and Russian.
E-version shall support context search option.
R
14.4
M
Supplier shall prepare information system and regulatory
documents to carry out attestation for compliance with
requirements of information security according to article 5 of
Law of the Republic of Kazakhstan of 11 January 2007 «On
informatics» and Resolution of the Government of the Republic
of Kazakhstan of 30 December 2009 № 2280 «On approving
rules for carrying out attestation of state information systems and
nongovernment information systems to be integrated with state
information systems for compliance with requirements of
information security and standards adopted in the territory of the
Republic of Kazakhstan» and enter into force according to
Article 17 of the Republic of Kazakhstan of 11 January 2007
“On informatics”.
Section VI. Technical Requirements
385
D. TESTING AND REQUIREMENTS TO QUALITY GUARANTEE
3.1. SYSTEM TESTING AND REQUIREMENTS TO QUALITY GUARANTEE
N
type
requirement
15
System testing and requirements to quality guarantee
R
R
15.1.
Pre-starting works
R
15.1.1
M
System supplier shall carry out standard installation tests for
testing correct system installation.
R
15.1.2
M
Supplier shall provide a list of tests, testing conditions, success
criteria etc for system testing under technical proposal.
R
15.1.3
I
Quality of testing is one of criteria for technical evaluation. A list
of tests will include tests for each module and tests for the whole
system.
R
15.1.4
M
R
15.1.5
М
R
15.1.6
М
R
15.1.7
М
R
15.1.8
M
System supplier will carry out phased detailed testing including
performance tests, response time test, capacity test, jointly with
organization authorized by the purchaser according to tests
provided by Supplier.
Supplier shall demonstrate the system with participation of
purchaser representatives and organization authorized by the
Purchaser according to system testing scenarios.
Supplier shall outline demonstration results in the minutes on
demonstration under the form agreed with the Purchaser. Minutes
must be signed by all demonstration participants.
Venue of demonstration shall be agreed with Purchaser and
organization authorized by the Purchaser.
Supplier shall eliminate all remarks received during
demonstrations and carry out repeated demonstrations until
receiving minutes about successful demonstration.
Timeframe for elimination of remarks is agreed with the
Purchaser.
Testing shall be carried out according to one of standards IEEE
829/1009, BS 7925, ISO/AS 9100 and developed document
“testing programme and methodology» of ST RK 1089-2002.
R
15.1.9
M
Supplier shall test the system according to the Web Content
Accessibility Guidelines 2.0. Supplier shall provide detailed
information about testing results.
R
15.1.10
M
Supplier shall test system on safety according to Open Web
Application Security Project) Top 10 vulnerability. Supplier shall
provide detailed information about testing results.
R
15.1.11
M
Supplier shall agree with Purchaser a testing scenario and provide
report on each testing result с Покупателем сценарий
тестирования и предоставить отчёт по результату каждого
тестирования.
R
R
15.2
15.2.1
M
Acceptance to exploitation
System acceptance act is signed based on trouble free operation
385
386
Section VI. Technical Requirements
under normal conditions of exploitation for the system within 3
months. In case of the system malfunctioning in the period
supplier shall incorporate all necessary modifications and carry
out repeated system exploitation within 3 months. Operating
errors are critical errors which do not allow to run the System
R
15.2.2
M
Supplier shall start all required work to eliminate defects or
damages within 10 working days for non critical errors. For
critical errors Supplier shall start work to eliminate damages or
defects within 3 working days, ensure time record and report on
progress record every hour during operation and guaranteed
period.
Critical errors: system does not work or it works unstable.
Important functional component does not work or it is
inaccessible. Data damage or interruption of main flow process.
System component is inapplicable due to failure or incorrect
functionality. Users could not perform any work.
3.2. Requirement to ensuring control by the Purchaser
N
Тype
Requirement
R
16
R
16.1
М
Supplier shall periodically defined in the plan schedule provide
regular progress report to the Purchaser.
R
16.2
М
Report shall contain information about work performed by the
Supplier over reporting period, according to approved plan
schedule including services on guaranteed support as well as on
technical support service of suppliers with attachment of all
approved documents over the reporting period during contract
implementation including official correspondence in hard copy
and electronic format (in at least pdf format).
R
16.3
М
Report shall be agreed with organization authorized by the
purchaser.
R
16.4
М
Purchaser can carry out control of contract performance and
quality of services under the contract by the Supplier in any time.
requirement to ensuring control by the Purchaser
Section VI. Technical Requirements
387
E. Implementation Schedule
Implementation Schedule Table
System, Subsystem, or lot number: procurement of lot 10
Line
Item
No.
10
Subsystem / Item
Medical information system for
registration
of
donors
and
recipients and individuals waiting
for transplantation
Configuration
Table No.
Site / Site
Code
Delivery
(Bidder to
specify in the
Preliminary
Project Plan)
Installation
(weeks from
Effective Date)
Acceptance
(weeks from
Effective Date)
Liquidated
Damages
Milestone
41
54
Yes
387
388
Section VI. Technical Requirements
System Inventory Table (Supply and Installation Cost Items)
System, Subsystem, or lot number: Lot 10
Component
No.
10
Component
Medical information system for registration of donors
and recipients and individuals waiting for
transplantation
Relevant Technical
Specifications
No.
Additional Site Information
(e.g., building, floor,
department, etc.)
Quantity
1
Section VI. Technical Requirements
389
Site Table(s)
System, Subsystem, or lot number: Lot 10
Site
Code
10
Site
City / Town / Region
Primary Street Address
Republican coordination Center on
transplantation
Astana
Almaty rayon, Sileti St, 30
Drawing
Reference No.
(if any)
389
390
Section VI. Technical Requirements
Holidays and other days-off
Month
2014
2015
1
2
3
1, 2, 7
1, 2, 7
8, 21, 22,
23
8, 21, 22,
23
1, 7, 9
1, 7, 9
6
30
6
30
16, 17
16, 17
4
5
6
7
8
9
10
11
12
Section VI. Technical Requirements
391
G. Technical Responsiveness Checklist
Note to Bidders: The following Checklist is provided to help the Bidder organize and
consistently present its Technical Bid. For each of the following Technical Requirements,
the Bidder shall describe how its Technical Bid responds to each Requirement. In addition,
the Bidder shall provide cross references to the relevant supporting information, if any,
included in the bid. The cross reference should identify the relevant document(s), page
number(s), and paragraph(s). The Technical Responsiveness Checklist does not supersede
the rest of the Technical Requirements (or any other part of the Bidding Documents). If a
requirement is not mentioned in the Checklist, that does not relieve the Bidder from the
responsibility of including supporting evidence of compliance with that other requirement in
its Technical Bid. One- or two-word responses (e.g. “Yes,” “No,” “Will comply,” etc.) are
normally not sufficient to confirm technical responsiveness with Technical Requirements
391
Раздел VI. Технические требования (График реализации)
Technical Responsiveness Checklist
#
Mandatory
(M)/
Preferred
(P)
Description
R1
General
requirements
business
R1.1
Licensing mechanism for the M
System under this contract shall
provide the right to use all
modules and compounds for a
number of users, which allow
full functioning of the Health
Facility (approximate scope of
Health Facilities is given in
description of Appendix 17) for
unlimited
time,
unlimited
number
of
servers,
and
excluding any other possible
limitations. Annual license fees
are not admitted; full license
cost includes all costs for
system licensing.
R1.2
Within this Contract an M
interoperability of the System
with national e-health system
shall be ensured according to
requirement
R7.
General
interaction
scheme
with
national e-health system is
represented in Fig.1.
R1.R1.3
Generalized
comprehensive М
health
information
system
architecture the system shall
Item #
cross
references
to
supportin
Costs
g
required to
informati
ensure
on on cost
technical
of
compliance
ensuring
technical
complianc
e:
Section VI. Technical Requirements
393
comply with is shown in Fig 2
R1.4
System shall be represented as a М
web application
R1.5
System shall have capability of М
fine
tuning
to
provide
configuration for specific needs
of concrete facility without
necessity to develop new one
(or
including
minor
development)
R1.6
Supplier under this Contract М
shall
ensure
System
interoperability with national
EHR tools (EHR repository,
national
classifiers
and
identifiers, analytical storage,
EHR web services) according to
R8
R1.7
System
shall
ensure М
confidentiality of personal data
in the process of saving and
sending:
coding
of
confidentially data in database,
data coding during transmission
via channels, use of secure
transmission protocols etc.
R1.8
System shall ensure using a М
digital signature for signing and
authentication of e-documents,
files and parts of documents.
The need to use digital
signature shall be configurable
at the level of system
administrator.
R1.9
System shall be fully “turnkey” М
operational according to R15.2.
R1.10
The Supplier shall provide at М
least, but not limited to
393
394
Section VI. Technical Requirements
configuration,
deployment,
installation, testing of the
System. The Supplier shall
provide trainings for users and
administrators (and other staff if
needed)
R1.11
Supplier shall participate in the М
process of certification of the
System jointly with Supplier of
Platform to test and certify
interoperability with national
resources and EHR tools as well
as participate in attestation and
testing of the system
R1.12
Supplier
shall
provide М
guaranteed service of the
system within 3 years from the
date of the system operational
acceptance by the Purchaser
according to R13.4.
R1.13
If additional licensed software М
is required for the system turnkey operation the Supplier shall
ensure availability of all
licenses at the expense of
Supplier and their transfer to the
Purchaser’s ownership under
this contract.
R1.14
Minimum requirements for each М
module must comply with
requirements of section R2
R1.15
System shall have capabilities D
of integration with development
environment (IDE) at least for
Java and Net framework.
System shall have in a package
development
tools
(SDK)
including documents, examples
of code for at least Java and Net
Framework for configuration of
system unction. An option of
extending system functionality
Section VI. Technical Requirements
395
shall be available using
development tools (SDK) which
are included into the system
composition.
R1.16
Licensing mechanism for the М
system within this contract shall
not restrict changes which are
made using development tools
(SDK) that are included into the
system composition. Making
changes using development
tools (SDK) which are included
into the system composition
shall not have effect on
guarantee service of the system.
Making changes into the system
by specialists of the Purchaser
is allowed upon the system
operational acceptance.
R1.17
Supplier shall ensure service М
and technical support including
provision of new product
versions (according to R13.3).
R1.18
Service response tome and М
system components response
time shall not be more than 3-5
seconds for not least 80% of
cases of data entry or inquiries
for data view (under channel
speed 1 Mb/s and response time
not more than 100 ms).
R1.19
Supplier shall document and М
submit in electronic format
configuration files, original
code of system components
developed within this contract.
R1.20
System shall have thin client for М
interaction with equipment it is
allowed to use thick client.
R2
Requirements to automated
395
396
Section VI. Technical Requirements
processes
R2.1
Module «Administration»
R2.1.1
Adjustment of system user М
accounts. This process includes
as minimum:
R2.1.1.1 Create user accounts
M
R2.1.1.2 Edit user accounts
M
R2.1.1.3 Delete user accounts
M
R2.1.2
Adjustment of system users’ М
rights and strict designation of
responsibilities
based
on
regional and administrative
criteria. This process includes
as minimum:
R2.1.2.1 Personalized designation of user M
access rights
R2.1.2.2 Designation of system user M
rights based on roles, groups
and access level with regard to
hierarchy of objects and
ownership to organizational
structure
R2.1.2.3 Edit user access rights
M
R2.1.2.4 Delete user access rights
M
R2.1.3
Configuration of criteria for М
automatic
selection
of
appropriate recipient from the
waiting list. This process
includes as minimum the
following:
R2.1.3.1 Edit (add/delete) criteria for M
automatic
selection
of
appropriate recipient from the
Section VI. Technical Requirements
397
waiting list
R2.1.3.2 Edit weight coefficients (score M
points) of criteria for automatic
selection
of
appropriate
recipient from the waiting list
R2.1.4
Configuration
of М
recipient/donor
registration
forms. This process includes as
minimum the following:
R2.1.4.1 Edit (add/delete fields, edit M
existing fields) in the entry
forms for registration of
recipient/donors/individuals
needed transplantation
R2.1.4.2 Add/delete entry forms
registration
recipient/donor/individuals
needed transplantation
for M
of
R2.1.4.3 Use of the following functions M
to create, edit the entry forms to
register
recipient/donor/individuals
needed transplantation:

Change in font setting
(style,
size,
bold,
underline, italic etc.)

Change font color

Create
complicated
entry
forms
with
subsections

Possibility of using any
reference book in the
system for filling in the
field in the entry form

Possibility of using any
content in the database
for filling in the field in
the entry form

Possibility of using any
397
398
Section VI. Technical Requirements
sampling
from
the
database for filling in
the field in the entry
form

Setting rules for filling
in the entry form: only
from the list, from the
list with possibility of
add-in in a free form,
from the sample etc.

Create new reference
books, used in filling in
the entry form
R2.1.5
Import data into the system М
from at least xls, xml file
formats.
R2.1.6
System journal management. M
This process includes as
minimum the following:
R2.1.7
Journal to create, change and M
delete data in the database
R2.1.8
Journal of user’s entry history
R2.1.9
Journal of received reporting M
forms
R2.1.10 Journal of data view
M
M
R2.1.11 Journal of data processing M
(create, change, delete)
R2.1.12 Journal of archive history
M
R2.1.13 Journal of program errors and M
emergency shut down
R2.1.14 Journal of synchronization with M
external (national) reference
books, classifiers, indexes and
registers
Section VI. Technical Requirements
R2.1.15 Journal archiving
399
M
R2.2
Module «Registration of an
individual
needed
transplantation»
R2.2.1
Registration in the «waiting М
list» of an individual, needed
transplantation according to
Appendices 1-1, 1-2, 1-3 to the
present technical specification.
Possibility of registration of one
patient in several waiting lists.
This process includes as
minimum the following:
R2.2.1.1 Registration in the «waiting M
list» of an individual needed
transplantation according to the
form of Appendix 1-1 to the
present technical specification
R2.2.1.2 Registration in the «waiting M
list» of an individual needed
liver transplantation according
to the form of Appendix 1-2 to
the
present
technical
specification
R2.2.1.3 Registration in the «waiting M
list» of an individual needed
kidney
transplantation
according to the form of
Appendix 1-3 to the present
technical specification
R2.2.1.4 Registration of one patient in M
several
waiting
lists
(if
necessary)
R2.2.1.5 Possibility of printing patient M
information
according to
Appendices 1-1, 1-2, 1-3 to the
present technical specification.
R2.2.1.6 Possibility of export patient M
399
400
Section VI. Technical Requirements
information
according
to
Appendices 1-1, 1-2, 1-3 to the
present technical specification
to at least pdf, xls, doc format
documents.
R2.2.2
Automated
receipt
of M
information about necessity to
be registered in the waiting list
of an individual needed
transplantation based on the
information received from IS of
the MHSD of the RK (this
functionality
shall
be
implemented as soon as
required functionality of the
stated above IS will be ready for
interaction).
This
process
includes as minimum the
following:
R2.2.2.1 Automated
receipt
of M
information from IS of the
MHSD of the RK about the
necessity for the patient to be
registered in the waiting list
R2.2.2.2 Patient registration in the M
waiting list according to
Appendices 1-1, 1-2, 1-3 to the
present technical specification
based on information of IS of
the MHSD of the RK
R2.2.2.3 Registration of one patient in M
several
waiting
lists
(if
necessary).
R2.2.2.4 Possibility of printing patient M
information
according
to
Appendices 1-1, 1-2, 1-3 to the
present technical specification.
R2.2.2.5 Possibility of export patient M
information
according
to
Appendices 1-1, 1-2, 1-3 to the
present technical specification
Section VI. Technical Requirements
401
to at least pdf, xls, doc format
documents.
R2.2.3
Manage information about М
current state of individual
needed
transplantation
(improving or worsening of the
course of the disease with
regard to progress, development
of complications, concomitant
disease and other). This process
includes as minimum the
following:
R2.2.3.1 Search of patient based on full M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
and other criteria.
R2.2.3.2 Manage information about M
current state (improving or
worsening of the course of the
disease with regard to progress,
development of complications,
concomitant disease and other).
R2.2.3.3 Store in the system of the M
history of changes in the patient
condition
R2.2.3.4 View the history of changes in M
the patient condition
R2.2.3.5 Option to print information M
about the patient condition.
R2.2.3.6 Option to print the history of M
changes in the patient condition.
R2.2.3.7 Option to export information M
about patient condition to at
least pdf, xls, doc format
documents.
R2.2.3.8 Option to export the history of M
changes in the patient condition
401
402
Section VI. Technical Requirements
to at least pdf, xls, doc format
documents.
R2.2.4
Waiting list monitoring. This М
process includes as minimum
the following:
R2.2.4.1 Search patient based on full M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
and other criteria.
R2.2.4.2 View waiting list (including M
generation of daily information
by regions about the number of
adult and child patients, number
of dropped from the waiting list
with a reason indication,
number of new cases).
R2.2.4.3 Sort and filtrate the «waiting M
list» based on patient full name,
patient age, sex, date of patient
entry to the waiting list, region,
health facility, organ/tissue to
be transplanted and another
criterion.
R2.2.4.4 Option to print the waiting list M
(including
filtrated
and/or
sorted).
R2.2.4.5 Option to export the waiting list M
(including
filtrated
and/or
sorted) into at least pdf, xls, doc
format documents.
R2.3
Module
«Inpatient
transplantation coordinator»
R2.3.1
Registration of possible donor М
under a form according to
Appendix 2 to the present
technical specification. This
process includes as minimum
the following:
Section VI. Technical Requirements
403
R2.3.1.1 Registration of possible donor M
according to Appendix 2 to the
present technical documentation
R2.3.1.2 Manage
possible
results
information about M
donor examination
R2.3.1.3 View of earlier registered M
possible donors with possibility
of sorting and filtration by
patient age, sex, diagnosis,
entry date and other criteria.
R2.3.1.4 Possibility
information
donor.
of
about
printing M
possible
R2.3.1.5 Possibility of export of possible M
donor information into at least
pdf, xls, doc format documents.
R2.3.2
Registration of potential donors М
under form according to
Appendix 2 to present technical
specification. This process
includes as minimum the
following:
R2.3.2.1 Registration of potential donor М
according to Appendix 2 to the
present technical specification
R2.3.2.2 Manage
potential
results
information about М
donor examination
R2.3.2.3 View of earlier registered М
potential donors with possibility
of sorting and filtration based
on patient age, sex, intensive
therapy department admission
date,
tissue/organ
to
be
extracted and other criteria.
R2.3.2.4 Possibility of setting summary М
403
404
Section VI. Technical Requirements
reporting forms of registered
potential donors over a certain
period of time
R2.3.2.5 Possibility of printing summary M
reporting forms of registered
potential donors over certain
period of time
R2.3.2.6 Possibility of printing potential
donor information
R2.3.2.7 Possibility of
export
of М
summary reporting forms of
registered potential donors over
a certain period of time into at
least pdf, xls, doc format
documents
R2.3.2.8 Possibility of export of potential М
donor information into at least
pdf, xls, doc format documents
R2.3.3
Registration of actual donor М
under a form according to
Appendix 2 to the present
technical specification. This
process includes as minimum
the following:
R2.3.3.1 Registration of actual donor М
according to Appendix 2 to the
present technical specification
R2.3.3.2 Manage information about М
actual
donor
examination
results
R2.3.3.3 View of earlier registered actual М
donors with possibility of
sorting and filtration based on
patient full name, age, sex,
organ/tissue, to be extracted and
other criteria.
R2.3.3.4 Setting
summary
reporting М
Section VI. Technical Requirements
405
forms of registered actual
donors over a certain time
period
R2.3.3.5 Possibility of printing summary М
reporting forms of registered
actual donors over certain time
period
R2.3.3.6 Possibility
of
printing М
information about actual donor
R2.3.3.7 Possibility of
export
of М
summary reporting forms on
registered actual donors into at
least pdf, xls, doc format
documents
R2.3.3.8 Possibility of export of actual М
donor information into at least
pdf, xls, doc format documents
R2.3.4
Manage information about М
current objective donor status
(possible, potential, actual) This
process includes as minimum
the following:
R2.3.4.1 Manage information about M
current objective donor status
R2.3.4.2 View of donor objective status M
change history
R2.3.4.3 Possibility
of
information
about
objective status
printing M
donor
R2.3.4.4 Possibility of printing donor M
objective status change history
R2.3.4.5 Possibility
of
exporting M
information
about
donor
objective status into at least pdf,
xls, doc format documents.
405
406
Section VI. Technical Requirements
R2.3.4.6 Possibility of export donor M
objective status change history
into at least pdf, xls, doc format
documents.
R2.4
Module «lab testing»
R2.4.1
Managing performed lab testing М
results
including but not
limited to the information about
high, medium, low performance
immunological tissue typing
testing results of individuals
recommended
for
transplantation and potential
donors (form №410-10/у),
information about individual
cross match results of potential
donors
and
individuals
recommended
for
transplantation (form №41011/у), leucocyte antibodies
testing results of candidates for
transplantation (form №4109/у). This process includes as
minimum the following:
R2.4.1.1 Search of patient based on full M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
and other criteria.
R2.4.1.2 Manage performed lab testing M
results including but not limited
to the information about high,
medium, low performance
tissue immunological typing
testing results of individuals
recommended
for
transplantation and potential
donors (form №410-10/у),
information about individual
cross match results of potential
donors
and
individuals
recommended
for
transplantation (form №41011/у), leucocyte antibodies
Section VI. Technical Requirements
407
testing results of candidates for
transplantation (form №4109/у). Entry of performed lab
testing results
R2.4.1.3 View earlier entered lab testing M
results
R2.4.1.4 Option of printing lab testing M
results
including but not
limited to the information about
high, medium, low performance
tissue immunological typing
molecular & serological testing
results
of
individuals
recommended
for
transplantation and potential
donors (form №410-10/у),
information about individual
cross match testing results of
potential donors and individuals
recommended
for
transplantation (form №41011/у), leucocyte antibodies
testing results of candidates for
transplantation (form №4109/у).
R2.4.1.5 Option of export lab testing M
results into at least pdf, xls, doc
format documents.
R2.5
Module
«regional
transplantation coordinator»
R2.5.1
Setting request to be dropped М
from the waiting list with a
reason indication (death, change
of place of living, no need in
transplantation, contradictions
to transplantation etc). This
process includes as minimum
the following:
R2.5.1.1 Entry request to be dropped M
from the waiting list with a
reason indication (death, change
407
408
Section VI. Technical Requirements
of place of living, no need in
transplantation, contradiction to
transplantation,
rejection to
have transplantation etc.)
R2.5.1.2 Edit/delete request to be M
dropped from the waiting list
which was not sent to the
republican
transplantation
coordinator
R2.5.1.3 Sending a request to be dropped M
from the waiting list to the
republican
transplantation
coordinator for consideration
R2.5.1.4 Option of printing request to be M
dropped from the waiting list.
R2.5.1.5 Option of export the request to M
be dropped from the waiting list
into at least pdf, xls, doc format
document.
R2.5.2
Monitoring of donors (possible, М
potential, actual, as well as
voluntary).
This
process
includes as minimum the
following:
R2.5.2.1 View a list of possible donors M
with option of sorting and
filtration based on patient age,
sex, diagnosis, admission date,
other criteria.
R2.5.2.2 View a list of potential donors M
with option of sorting and
filtration based on patient age,
sex,
intensive
therapy
department admission date,
tissue/organ to be extracted and
other criteria.
R2.5.2.3 View a list of actual donors M
with possibility of sorting and
Section VI. Technical Requirements
409
filtration based on patient full
name, age, sex, organ/tissue to
be extracted and other criteria.
R2.5.2.4 View a list of voluntary donors M
with option of sorting and
filtration based on patient age,
sex, registration date and other
criteria.
R2.5.2.5 Search patient based on full M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
and other criteria.
R2.5.2.6 View a list of individuals who M
were dropped from the list of
voluntary donors (rejection to
donate,
contradictions
to
donation, death and other
reasons).
R2.5.2.7 View possible
change history
donors
list M
R2.5.2.8 View potential
change history
donors
list M
R2.5.2.9 View actual donors list change M
history
R2.5.2.1 View voluntary donors
0
change history
list M
R2.5.2.1 Manage daily report data M
1
according to Appendix 6 to the
present technical specification
R2.5.2.1 Setting summary reporting M
2
forms for registered donors
(possible, potential, actual) over
certain time period
R2.5.2.1 Setting summary reporting M
3
forms for registered voluntary
409
410
Section VI. Technical Requirements
donors over certain time period
R2.5.2.1 Option of printing summary M
4
reporting forms for registered
donors (possible, potential,
actual).
R2.5.2.1 Option of printing summary M
5
reporting forms for registered
voluntary donors.
R2.5.2.1 Option to export summary M
6
reporting forms by registered
donors (possible, potential,
actual) into at least pdf, xls, doc
format documents
R2.5.2.1 Option to export summary M
7
reporting forms by registered
voluntary donors into at least
pdf, xls, doc format documents
R2.5.2.1 Option to print summary M
8
reporting forms by registered
donors (possible, potential,
actual, voluntary).
R2.5.2.1 Option to export information M
9
about
registered
donors
(possible, potential, actual,
voluntary) into at least pdf, xls,
doc format documents
R2.5.3
Registration
of
voluntary М
lifetime donors (individuals
who had agreed to extract one
of their pair organs or part of
organ/tissue) with possibility to
check availability of notary
certified consent/denial through
interacting
with
state
information system “Unified
notary information system” via
health informatization and
interoperability
platform
according to Appendix 2-1 to
Section VI. Technical Requirements
411
the
present
technical
specification. This process
includes as minimum the
following:
R2.5.3.1 Manage
information
voluntary lifetime donor
on M
R2.5.3.2 Selecting concrete recipient as a M
voluntary
lifetime
donor
(according
to
donor’s
perception)
R2.5.3.3 Checking the availability of M
notary certified consent to be a
donor through interacting with
state
information
system
“Unified notary information
system”
via
health
informatization
and
interoperability platform
R2.5.3.4 Manage information on denial M
to be a donor
R2.5.3.5 Checking the availability of M
notary certified denial to be a
donor through interacting with
state
information
system
“Unified notary information
system”
via
health
informatization
and
interoperability platform
R2.5.3.6 Option to print information on M
voluntary lifetime donor.
R2.5.3.7 Generating summary reporting M
forms on registered voluntary
donors over specific period of
time
R2.5.3.8 Option to print summary M
reporting forms on registered
voluntary donors
411
412
Section VI. Technical Requirements
R2.5.3.9 Option to export summary M
reporting forms on registered
voluntary donors into at least
pdf, xls, doc format documents.
R2.5.3.1 generating summary reporting M
0
forms on registered denials to
be donors over specific period
of time
R2.5.3.1 Option to print summary M
1
reporting forms on registered
denial to be donors over
specific period of time
R2.5.3.1 Option to export summary M
2
reporting forms on registered
denial to be donors into at least
pdf, xls, doc format documents.
R2.5.3.1 Option to export summary M
3
reporting forms on registered
voluntary lifetime donors into at
least pdf, xls, doc format
documents.
R2.5.4
Registration
of
voluntary М
postmortal donors (individuals
who had agreed with retrieval
of their organ/part of organ
and/or tissue after their death)
with possibility to attach a
scanned copy of notary certified
consent/denial according to
Appendix 2-1 to the present
technical specification. This
process includes as minimum
the following:
R2.5.4.1 Manage information about M
voluntary postmortal donor
R2.5.4.2 Selection of concrete recipient M
as voluntary postmortal donor
(according to donor perception)
Section VI. Technical Requirements
413
R2.5.4.3 Attachment of scanned notary M
certified copy of consent
R2.5.4.4 Manage information
denial to be donor
about M
R2.5.4.5 Attachment of scanned notary M
certified copy of denial
R2.5.4.6 Option to print information M
about voluntary post mortal
donor.
R2.5.4.7 Option to export information on M
voluntary postmortal donor into
at least pdf, xls, doc format
documents.
R2.5.4.8 generating summary reporting M
forms on registered voluntary
donors over specific period of
time
R2.5.4.9 Option to print summary M
reporting forms on registered
voluntary donors
R2.5.4.1 Option to export summary M
0
reporting forms on registered
voluntary donors to at least pdf,
xls, doc format documents.
R2.5.4.1 Generating summary reporting M
1
forms on registered denials to
be donors over specific period
of time
R2.5.4.1 Option to print summary M
2
reporting forms on registered
denial to be donors over
specific period of time
R2.5.4.1 Option to export summary M
3
reporting forms on registered
denial to be donors into at least
413
414
Section VI. Technical Requirements
pdf, xls, doc. format documents
R2.6
module
Republican
transplantation coordinator
R2.6.1
Manage register of donors of М
organs/part of organ and/or
tissue (create, edit, delete, view)
This process includes as
minimum the following:
R2.6.1.1 Manage information on donors M
of organs/part of organ and/or
tissue
R2.6.1.2 Dropping a donor from the M
register with reason indication
R2.6.1.3 Searching patient by family M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
etc.
R2.6.1.4 Option to print information on M
donors of organs/part of organ
and/or tissue.
R2.6.1.5 Option to export information on M
donors of organs/part of organ
and/or tissue into at least pdf,
xls, doc format documents
R2.6.1.6 Generating summary reporting M
forms on registered donors of
organs/part of organ and/or
tissue
R2.6.1.7 Option to print summary M
reporting forms on registered
donors of organs/part of organ
and/or tissue
R2.6.1.8 Option to export summary M
reporting forms on registered
donors of organs/part of organ
and/or tissue into at least pdf,
Section VI. Technical Requirements
415
xls, doc format documents
R2.6.1.9 generating summary reporting M
forms on donors of organs/part
of organ and/or tissue dropped
from the register
R2.6.1.1 Option to print summary M
0
reporting forms on donors of
organs/part of organ and/or
tissue dropped from the register
R2.6.1.1 Option to export summary M
1
reporting forms on donors of
organs/part of organ and/or
tissue dropped from the register
to at least pdf, xls, doc format
documents.
R2.6.2
Manage waiting list (create, М
edit, delete, view options). This
process includes as minimum
the following:
R2.6.2.1 Manage the waiting list
M
R2.6.2.2 Reviewing request to be M
dropped from the waiting list of
regional
transplantation
coordinator
R2.6.2.3 Dropping the patient from the M
waiting list with reason
indication
R2.6.2.4 Option to print information M
about
individuals
needed
transplantation
R2.6.2.5 Option to export information M
about
individuals
needed
transplantation into at least pdf,
xls, doc format documents
R2.6.2.6 Generating summary reporting M
forms on registered individuals
415
416
Section VI. Technical Requirements
needed transplantation
specific period of time
over
R2.6.2.7 Option to print summary M
reporting forms on registered
individuals
needed
transplantation
R2.6.2.8 Option to export summary M
reporting forms on registered
individuals needed organ/tissue
transplantation over specific
period of time into at least pdf,
xls, doc format documents.
R2.6.2.9 generating summary reporting M
forms on patients dropped from
the waiting list over specific
period of time
R2.6.2.1 Option to print summary M
0
reporting forms on patients
dropped from the waiting list
R2.6.2.1 Option to export summary M
1
reporting forms on patients
dropped from the waiting list
into at least pdf, xls, doc format
documents.
R2.6.3
Automated sending by e-mail of М
reminder to carry out scheduled
quarterly testing. This process
includes as minimum the
following:
R2.6.3.1 Automated generation of a list M
of patients for scheduled
quarterly leucocytal antibodies
testing, 10 days prior to the
planned test date.
R2.6.3.2 Automated sending by e-mail to M
a candidate for transplantation
of a reminder to carry out
scheduled quarterly testing
Section VI. Technical Requirements
417
upon 10 days prior to the
planned test date.
R2.6.3.3 Automated sending by e-mail of M
a reminder to the regional and
republican
transplantation
coordinator of lists of patients
to
carry
out
leucocytal
antibodies testing 10 days prior
to planned test date
R2.6.4.
Automated calculation of score М
points to define a position in the
waiting list based on criteria
table according to Appendix 3
to
the
present
technical
specification. This process
includes as minimum the
following:
R2.6.4.1 Automated calculation of score M
points to define a position in the
waiting list based on criteria
table according to Appendix 3
to
the
present
technical
specification
R2.6.4.2 Regular (at least once a day and M
if actual donor is found)
automated recalculation of
score points to define position
in the waiting list based on
criteria table according to
Appendix 3 to the present
technical specification
R2.6.5
Automated selection of the М
group of potential recipients
against donor. This process
includes as minimum:
R2.6.5.1 Searching donor by family M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
etc.
417
418
Section VI. Technical Requirements
R2.6.5.2 Automated selection of the M
group of potential recipients
against donor.
R2.6.5.3 Option to print information M
about individuals selected as
potential recipients against
donor.
R2.6.5.4 Option to export information M
about individuals selected as
potential recipients against
donor into at least pdf, xls, doc
format documents.
R2.6.6
Automated selection of the М
group of potential recipients
against donor with regard to
several organs/tissues. This
process includes as minimum:
R2.6.6.1 Searching donor by family M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
etc.
R2.6.6.2 Automated selection of the M
group of potential recipients
against donor with regard to
several organs/tissues.
R2.6.6.3 Option to print information M
about individuals selected as
potential recipients against
donor with regard to several
organs/tissues
R2.6.6.4 Option to export information M
about individuals selected as
potential recipients against
donor with regard to several
organs/tissues into at least pdf,
xls, doc format documents.
R2.6.7
Automated selection of the М
group of donors against patient
Section VI. Technical Requirements
419
needed transplantation. This
process includes as minimum:
R2.6.7.1 Searching patient by family M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
and other or selection of a
patient from the waiting list.
R2.6.7.2 Automated selection of the M
group of donors against patient
needed transplantation.
R2.6.7.3 Option to print information on M
individuals selected as potential
donors against the patient.
R2.6.7.4 Option to export information M
about individuals selected as
potential donors against the
patient into at least pdf, xls, doc
format documents.
R2.6.8
Automated selection of the М
group of donors against the
patient needed transplantation
with
regard
to
several
organs/tissues. This process
includes as minimum:
R2.6.8.1 Searching patient by family M
name, IIN, organ/part of organ
and/or tissue, blood group, Rh
and other or selection of a
patient from the waiting list.
R2.6.8.2 Automated selection of the M
group of donors against patient
needed transplantation with
regard to several organs/tissues.
R2.6.8.3 Option to print information M
about individuals selected as
potential donors against patient
with
regard
to
several
organs/tissues.
419
420
Section VI. Technical Requirements
R2.6.8.4 Option to export information M
about individuals as potential
donors against patient with
regard to several organs/tissues
into at least pdf, xls, doc format
documents.
R2.6.9
Manage information about М
council of physicians’ decision
about transplantation. This
process includes as minimum:
R2.6.9.1 Manage information about M
council
of
physicians
(participants, venue, date etc)
R2.6.9.2 Manage council of physicians’ M
decision about transplantation
R2.6.9.3 Option to print information M
about council of physicians and
decision taken.
R2.6.9.4 Option to export information M
about council of physicians and
decision taken into at least pdf,
xls, doc format documents.
R2.7
module
brigade
R2.7.1.
Manage information on donor М
organs and tissues withdrawn.
This process includes as
minimum:
Transplantation
R2.7.1.1 Manage information on donor M
organs withdrawn
R2.7.1.2 Manage information on donor M
tissues withdrawn
R2.7.1.3 Manage information on surgery M
for organ withdrawal (health
facility name, where the surgery
was carried out, ICD-9 code,
Section VI. Technical Requirements
421
information about anesthesia
etc)
R2.7.1.4 Option to print information M
about donor organs and tissues
withdrawn.
R2.7.1.5 Option to print information M
about
surgery on
organ
withdrawn
R2.7.1.6 Option to export information M
about donor organs and tissues
withdrawn into at least pdf, xls,
doc format documents.
R2.7.1.7 Option to export information M
about surgery on organs
withdrawn into at least pdf, xls,
doc format documents.
R2.7.1.8 generating summary reporting M
forms on organs and tissues
withdrawn over specific period
of time
R2.7.1.9 Option to print summary M
reporting forms on organs and
tissues withdrawn
R2.7.1.1 Option to export summary M
0
reporting forms on organs and
tissues withdrawn into at least
pdf, xls, doc format documents.
R2.7.1.1 Generating summary reporting M
1
forms on carried out surgery
operations for organs/tissues
withdrawn over specific time
period
R2.7.1.1 Option to print summary M
2
reporting forms on carried out
surgery
operations
for
organs/tissues withdrawn
421
422
Section VI. Technical Requirements
R2.7.1.1 Option to export summary M
3
reporting forms on carried out
surgery operations for donor
organs/tissues withdrawn into at
least pdf, xls, doc format
documents.
R2.7.2
Manage information on carried М
out
organ
and
tissue
transplantation. This process
includes as minimum:
R2.7.2.1 Manage information on donor M
organs/tissues transplanted to
the recipient
R2.7.2.2 Manage information on surgery M
on organ transplantation (health
facility name, where surgery
operation was carried out, ICD9 code, information about
anesthesia etc)
R2.7.2.3 Manage information about pre M
and post surgery operation
period,
immunosuppressive
therapy,
post
surgery
complications.
R2.7.2.4 Option to print information M
about
donor
tissue/organ
transplanted to the recipient.
R2.7.2.5 Option to print information M
about surgery operation on
organ transplantation
R2.7.2.6 Option to export information M
about
donor
organ/tissue
transplanted to the recipient into
at least pdf, xls, doc format
documents
R2.7.2.7 Option to export information M
about surgery operation on
organ transplantation to at least
Section VI. Technical Requirements
423
pdf, xls, doc format documents
R2.7.2.8 Generating summary reporting M
forms on donor organs and
tissues
transplanted
over
specific time period
R2.7.2.9 Option to print summary M
reporting forms on donor organs
and tissues transplanted over
specific time period
R2.7.2.1 Option to export summary M
0
reporting forms on donor organs
and tissues transplanted over
specific time period into at least
pdf, xls, doc format documents
R2.7.2.1 generating summary reporting M
1
forms on carried out operations
for organ/tissue transplantation
to the recipient over specific
time period
R2.7.2.1 Option to print summary M
2
reporting forms on carried out
operations for organ/tissue
transplantation to the recipient
over specific time period
R2.8
module “monitoring of the
condition of individuals whom
transplantation was carried
out
R2.8.1
Manage register of individuals М
who were carried out with
transplantation (create, edit,
view). This process includes as
minimum:
R2.8.1.1 Manage information about M
individuals who were carried
out with transplantation
R2.8.1.2 Monitoring of the condition of M
423
424
Section VI. Technical Requirements
the
donor
from
whom
transplantation was performed.
R2.8.1.3 Searching a patient by full M
name, IIN, organ/part of organ
and/or tissue transplanted, blood
group, Rh and other.
R2.8.1.4 Option to print information M
about patients who were carried
out with transplantation
R2.8.1.5 Option to export information M
about patients who were carried
out with transplantation into at
least pdf, xls, doc format
documents.
R2.8.2
Monitoring of patients who М
were
carried
out
with
transplantation. This process
includes as minimum:
R2.8.2.1 Manage information about M
patients who were carried out
with transplantation
R2.8.2.2 Manage the history of change in M
the health status of the patients
who were carried out with
transplantation
R2.8.2.3 Monitoring of the condition of M
the individuals who were
carried out transplantation from
the same donor.
R2.8.2.4 Viewing the history of change M
in the health status of the
patients who were carried out
with transplantation with option
to sort and filtrate by patient
age, sex, registration date, organ
which was transplanted and
other criteria.
Section VI. Technical Requirements
425
R2.8.2.5 Searching patient by full name, M
IIN, transplanted organ/part of
organ and/or tissue, blood
group, Rh and other criteria.
R2.8.2.6 Option to print information on M
health status of the patients who
were
carried
out
with
transplantation
R2.8.2.7 Option to print history of M
change in the health status of
the patients who were carried
out with transplantation
R2.8.2.8 Option to export information M
about patients who were carried
out with transplantation into at
least pdf, xls, doc format
documents
R2.8.2.9 Option to export history of M
change in the health status of
the patients who were carried
out with transplantation into at
least pdf, xls, doc format
documents.
R2.9
module Generating analytical
and statistical tables
R2.9.1
Report on carried out allogenic М
relative
transplantations
(recipient, donor, and outcome
family name list)
R2.9.2
Report on carried out allogenic М
non relative transplantations
(recipient, donor, and outcome
family name list)
R2.9.3
Report on lethal outcomes of М
patients included in the waiting
list (by age, death reason, death
date)
425
426
Section VI. Technical Requirements
R2.9.4
Report
on
carried
out М
transplantation: information on
retrieved organs, reasons for not
performed selection, health
facility where retrieval was
carried out
R2.9.5
Report on cases of statement of М
potential donor brain circulation
death/arrest (family name list,
death date)
R2.9.6
Monthly reports according to М
Appendix 4-5 to the present
technical specification
R2.9.7
Daily report of regional М
transplantation
coordinator
according to Appendix 6 to the
present technical specification
R2.9.8
All output forms shall have an М
option to print out and save in at
least xls, pdf, doc format.
R3
Requirements to system
configuration
R3.1
Configuration
facility needs
R3.1.1
The System shall provide an М
option to manage access to
functionality based on roles.
System
shall
enable
add/delete/edit
roles
and
designate/cancel access right to
the system functionality.
R3.1.2
System shall have preinstalled М
roles according to 1.2.1. of the
present technical specification
with
option
of
further
adjustment (add, edit or delete
new roles).
to
health
Section VI. Technical Requirements
R3.1.3
Access rights to different М
system modules and functions
must be preinstalled according
to Table 1 with option to change
access rights (add, delete)
R3.1.4
Access right must be at least М
configurable on the following
aspects: all rights, create,
change, delete, view.
R3.1.5
System shall include master of M
reporting forms, enabling to
create and edit reports using
fields from the system database
R4
Requirements to system
response time
R4.1
Search of patient by full name M
or IIN and patient related data
(examination results, lab test
results etc) shall not be more
than 5 seconds for 80% of
cases
R4.2
Supplier during guaranteed М
period of service shall ensure
the
following
system
performance parameters:
R4.3
Total system shutdown time for М
the reason related to its
operability shall not be more
than 24 hours per year.
R4.4
One time system shutdown for М
the reason related to its
operability shall not be more
than 2 hours.
R5
Requirement to information
security
R5.1
Requirement of security are M
427
427
428
Section VI. Technical Requirements
defined by existing law of the
RK. System shall comply with
information
security
requirements
in terms of
providing threshold access,
protection from unsanctioned
access etc.
R5.2.
Information protection from M
unsanctioned access means
shall be provided in the system
namely:
R5.2.1
User identification based on M
user name (login) and password
validation
R5.2.2
Option to identify user based M
on public key infrastructure
digital certificates
R5.2.3
User authorization for access to M
system information resources,
that
require
appropriate
authorizations
R5.2.4
Personified
user
right M
determination
for
data
management, fine-tuning, view
R5.2.5
Personified
user
determination
for
resource access
R5.2.6
Designation of system user M
rights by roles, groups and
access level with regard to
object
hierarchy
and
organizational
structure
ownership.
R5.2.7
User
work
protocol M
maintenance
with
System
critical
functions
and
applications
right M
system
Section VI. Technical Requirements
429
R5.2.8
System file protection from M
change/damage
by
unauthorized users and program
processes
R5.2.9
Control journal of all updates in M
system program libraries shall
be maintained
R5.3
The
following
minimum M
backup means shall be realized
in the system:
- automated backup with option
of planning
- remote control of backup
creation
- full and partial backup
R5.4
System shall
integrity.
provide
data M
R5.5
System shall provide tools for M
data confidentiality coding
during storage and in the
process of transfer to other
systems.
R5.6
Electronic digital signature M
(hereinafter
registration
certificate of user by National
Authorization Center of the
Republic of Kazakhstan, EDS)
shall be issued by NAC RK.
The system shall provide the
tools for digital signature of
documents (objects) or portions
of documents, when / if it is
needed, and tools for signature
authentication. This option
shall be implemented in the
system services (if necessary).
To ensure EDS authenticity and
public key validity, the System
shall provide check for EDS
authenticity using services of
429
430
Section VI. Technical Requirements
NAC
RK
(http://pki.gov.kz/index.php/ru/
).
R5.7
System shall conform to the M
“single access point” principle
information
structure
architecture enabling to have
single access point (Single Sign
On) to all its components and
resources, enabling to enter
login and password once and
get access to all system
components without entering
password once again.
R5.8
System shall provide user M
authorization in the System,
designation of system user
rights by roles, groups, access
level with regard to object
hierarchy and organizational
structure ownership.
R5.9
According
to
regulatory M
documents on information
security approved by the
MHSD of the RK, the
following shall be realized:
− Password length
shall not be less than 8
symbols, letters and
numbers must be in
upper and lower case;
− Forced password
change function;
− Empty password
lockout function;
− User password
self-change;
− CAPTCHA be
realized for incorrect
password entry for 3
times;
− All user actions
log in journal for
viewing history of all
Section VI. Technical Requirements
431
system main events
changed;
− functionality of
session interruption if
inactive in N time
period.
R6
Requirements
to
quality attributes
R6.1.
System must support entry, M
receipt and transfer of data
required for work of IS of the
MHSD of the RK used by health
facility and avoid double data
entry.
R6.2
System shall ensure saving of all M
accumulated information at the
moment of shutdown or failure
of any system component
regardless its assignment, with
follow-up recovery after repair
and recovery work
R6.3
System shall have option of soft M
fine-tuning
in
changing
environment and user specific
tasks without replacing the
modules.
R6.4
System shall be highly scalable M
and enabling operation of
unlimited number of users.
Restrictions can be conditioned
only by hardware technical
characteristics and not by the
System characteristics
R6.5
All system functional features M
must be developed as services.
R6.6
System web services must be M
developed according to SOA
architecture.
system
431
432
Section VI. Technical Requirements
R6.7
In realization of interoperability М
services it is required to follow
the standard of the MHSD of the
RK concerning interoperability
of IS
R6.8
System shall provide possibility M
of designing of approved
medical
form
templates
available within the solution
itself which could be automated
without
programming
or
incorporating modifications to
the program code.
R6.9
System shall provide conflict M
resolution under parallel system
object processing.
R7
Requirement to user interface
R7.1
Interface shall be provided for M
prevailing use of mouse
manipulator
meaning
that
system control shall be using
screen menu, buttons, icons and
similar elements
R7.2
Keyboard mode must be used M
mainly in filling in and/or
editing text and numeric fields
of screen forms. Also hot
buttons must be provided for
moving between fields to be
filled in.
R7.3
Ergonomic
solutions
and M
interface design must be
uniform
for
all
system
components and modules as
possible
R7.4
System user interface must be M
multilingual ad organized with
support of at least state
(Kazakh)
and
Russian
Section VI. Technical Requirements
433
languages. Exclusions could be
system messages which are not
subject to localization or
standard
administrative
applications
included
into
system software
R7.5
Access to electronic package of M
maintenance
documentation
must be available
R7.6
Context sensitive reference M
system must be realized in the
system,
accessible
from
different web application pages
where references to information
must
be
provided
(user
guidebook, manual etc.), for
work with possibility of
configuration
without
engagement of potential supplier
at the level of purchaser;
R7.7
In the system user interface M
screen visual highlight of
attributes must be provided for
operator only for reading
R7.8
In the system user interface M
screen visual
highlight of
attributes required for filling in
must be provided
R7.9
System shall provide correct M
processing
of
emergency
situations caused by incorrect
user actions, incorrect format or
invalid entry data. In the above
mentioned cases the system
must deliver corresponding
messages to the user, then go
back to operation mode, that
preceded
incorrect
(inadmissible) command or
incorrect data entry
433
434
Section VI. Technical Requirements
R7.10
System shall not allow for M
backup and reentry (incorrect
entry) of uniform information.
System shall ensure exclusion of
backup
and
reentry
of
information contained in state
database
and
information
systems of state bodies
R7.11
System shall provide format- M
logic control of data entry.
Format logical control of
entered data means control of
format and content of entered
data. During operation the
system shall provide for
protection from mis-actions:
- selection of only user
accessible functions according
to access rights;
- entry only user accessible
values (according to access
rights);
- certain format data entry (for
example, impossibility to enter
symbol data into the date or
number format fields).
R8.
Requirement
to
interoperability
R8.1.
General
requirements
system interoperability
R8.1.1
System
solutions
and M
applications must comply with
interoperability
standards
including to national standards
and
adopted
international
standards listed in this chapter
(and in this document).
R8.1.2
System
components
must M
comply with national semantic
tools:
o Reference books
and classifiers
system
to
Section VI. Technical Requirements
435
o Requirements to
reference book
services
o Requirements to
registers
and
register services
Details on requirements for
these tools are given in this
section below (R8.3)
R8.2
Some of compatibility tools M
described below are in the
process of development and last
versions are provided to
potential suppliers as requested.
Main standards are given in
website of the MHSD of the RK
(Order №75 dated 10.02.2014
https://www.mzsr.gov.kz/node/
319759
R8.2.1
Compatibility with standards M
R8.2.2
System components must be M
compatible at least with the
following standards of the
MHSD of the RK:
1) standards requirements to ehealth
record
(requiring
compliance with EN 13940)
2) standard requirements to emedical
record
(requiring
compliance with EN 13940)
3) standard requirements to
identification of existing health
parties, used in e-health systems
4) technical requirements to
interoperability
(message
transfer)
with
e-health
information systems
5) regulations for ensuring
information security
6) Standard requirement’s to
single classifier of drugs,
medical supplies and medical
equipment
7) Standard requirement’s to
realization and regulation of e435
436
Section VI. Technical Requirements
directions
8) Regulation for interaction of
stakeholders
to
ensure
interoperability of information
systems and information flow
management
9) Standard for regulation of ereceipts management
10) Standard for management of
e-processes
of
diagnostic
studies and cure procedures
11) Standard for regulation of epreventing of diseases
The mentioned standards and
regulatory
documents
are
available
at
https://www.mzsr.gov.kz/taxon
omy/term/619
R8.2.3
System components must be M
compatible with the following
international standards:
e. EN 13940 (on
the
part
of
compliance with
standards
of
EHR and EMR)
f. HL7
v3
(ISO/HL7
27831) HL7 (v2
orV3 or FHIR);
g. HL7 CDA (ISO/
HL7 27932)
h. DICOM
R8.3
System shall comply with M
requirements of standards on
information security:
 ST RK ISO/IEC 270012008 «methods and
tools of ensuring safety
of information security
management system.
Requirements»;
 ST RK ISO/IEC 270022009 «Information
technology. Tools of
assurance. Guidebook
Section VI. Technical Requirements
437
on information
protection
management».
R8.3.1
Requirements to compatibility M
with national identifiers and
standard
classifiers/reference
books
R8.3.2
System
components
must M
support and comply with
requirements
to
national
identifiers:
- patient identifier
- health facility identifier
- medical staff identifier
- medical equipment identifier
R8.4
System
components
must M
support and comply with
requirements for at least under
the
following
national
classifiers and reference books:
1) national classifier of drugs
and supplies (mapped to АТСDDD )
2) medical service classifier
(based on ICD-9, section on
services etc)
3) lad testing results classifier
4) service and their cost
classifier
5) diagnosis classifier (ICD-10)
6) PHC classifier (ICPC-2)
7) mapping ICPC-2 and ICD-10
8) SNOMED, only for coding
of communication between
System and EHR repository)
9) to manage diagnostic
services enhanced classification
system shall be defined at the
later stage;
10) national DRG system for
patient
classification
implemented by the MHSD of
the
RK
(in
providing
specialized care);
11) classifier of target patient
437
438
Section VI. Technical Requirements
group registers (dispensary
groups).
12) rater of medical services;
13) list of health specialties;
14) list of positions
R8.4.1
Requirements
to M
compatibility/data conformity
R8.4.2
System
components
must M
provide
communication
between the system and
platform
containing
EHR
repository based on the
following data:
- minimum set of data for EHR
(given in Appendix to National
EHR standard and national
EMR standard)
- other data, not covered by
semantic standards, but required
according to regulatory acts of
the MHSD of the RK such as
attached
special
records
(documents based on CDA)
R8.4.3
System must provide access to M
data stored in EHR repository
according to 2 EHR types: full
EHR, short EHR. Details are
described in national EHR
standard
R8.4.4
Data are transferred between the M
system and EHR repository in
CDA format
R8.4.6
System shall provide data M
transfer to EHR repository
based on ICPC-2 codes, which
are used in visits (and in
contacts in general) and mapped
to ICD-10 for the purpose of
statistics
collection.
In
information systems of EMR
(except for EHR /PHC systems)
specialists use ICD-10 for
diagnosis coding, and mapping
Section VI. Technical Requirements
in reverse order is
mandatory but desirable.
439
not
R8.5
Systems could have additional M
database
and
repositories
required for full functionality
(so called EMR in the context
of MHSD of the RK, but they
are stored separately from EHR
repository
database.
EHR
repository content is strictly
regulated by the national EMR
standard.
R8.5.1
System shall be sufficiently M
public
to
provide
interoperability with existing IS
of the MHSD of the RK,
applications and services
R8.5.2
Requirements to information M
exchange
R8.5.3
System shall interact with M
national HER system according
to National standards of EHR
and EMR
R8.5.4
System shall support as M
minimum interoperability with
the following e-health service
sets:
- EHR repository service;
reference
information
services;
-registration
and
register
services;
-clinical nomenclature and data
classification services;
- Secure information exchange
and message exchange services;
Identification
and
authentication services;
- monitoring and audit for
information exchange services
R8.5.5
The system shall comply with at M
least the following IHE profiles:
b) IHE
infrastructure
439
440
Section VI. Technical Requirements
profiles:
 ATNA;
 XDS.b;
 PDQ;
 PIX;
R8.5.6
System shall ensure option of М
interaction/integration using at
least the following protocols
and specifications:
h. Communication through
SOAP (and message
SOAP with application),
REST,
Message
Transmission
Optimization
Mechanism;
i. Support of standards and
specifications of web
services (WS-Security,
WS-Addressing,
WSReliable
Messaging,
WS-coordination, WSTransaction, WS-Secure
Conversation);
j. Compliance with XML
(XML, XSL, ebXML, и
др.);
k. Support
control
through
JWT;
SSO
and
of
access
SAML v2,
l. Support
general
standards such as HTTP,
HTTPS, TCP/IP, (SSL
v3) and TLS;
m. Enable using WSDL,
WADL;
n. X.509;
Digital signatures (EDS NAC
RK).
Section VI. Technical Requirements
441
R8.6
System shall support coding of M
at least UTF8.
R8.6.1
System shall interact with M
platform services under speed
of channel 1 Мb/s and response
time not more than 100 ms
R8.6.2
Intersystem communication
R8.6.3
Interaction with IS of MHSD of M
the RK in receipt of date of
health facilities, functional
departments and health facility
staff, as well as general
reference information used in
the IS MHSD of the RK РК
R8.6.4
Interaction with IS of MHSD of M
the RK on receiving data about
individuals who are dispensary
registered
R8.6.5
Interaction with IS of MHSD of M
the RK on receiving data about
individuals
and
their
attachment, death (reason of
death, date of death)
R9
Use of national e-health
resources and platform tools
R9.1
System shall be able to function M
according to general e-health
architecture (Fig 2)
R9.2
System shall be able to use M
functionality and web services,
published on national level for
interaction
with
e-health
resources.
R9.3
System shall be able to use M
EHR
repository
national
classifiers and indexes (as
minimum main patient index,
health facility department index,
M
441
442
Section VI. Technical Requirements
staff index, building index,
address index, vehicle index,
medical
technique
index),
analytical storage and other
national resources required for
turnkey integration according to
national standards (listed in
MOH of the RK order №75
dated 10.02.2014)
R9.4
System shall support local M
copies of national resources and
be able synchronize them on a
regular basis (according to
adjustable schedule) or online.
System shall contain only
information concerning health
facility operation. For example,
main patient index must be
contained locally only for the
list of patients who receive care
in that facility.
R10
Interaction
with
parties
involved into certification
process
R10.2
Contract related to supply of M
platform and national e-health
resources is carried out with
present contract in parallel.
Supplier of platform will be
provided with access to national
e-health resources only after
parallel contract will be
implemented successfully. To
ease parallel implementation it
is
necessary
to
synchronize/coordinate
joint
activities.
Interaction
of
involved parties is described in
Fig 3. Activities undertaken by
supplier are described in 4th
column “Private IT companies”
R10.3
System supplier must interact M
with supplier of platform, health
facility and MHSD of the RK to
test and certify interoperability
Section VI. Technical Requirements
443
with national resources and
services.
R10.4
Supplier
must
coordinate M
interaction of involved parties
according to Fig 3. Certification
based
on
evaluation
of
implemented
System
compliance with requirements
of R8.2. The Purchaser shall
establish special Committee that
jointly with the Platform
Supplier and Supplier of this
system shall make tests in line
with Rule Book for compliance
to interoperability requirements
according to national standards
including possibility for correct
interaction of delivered system
with
national
resources
delivered within the Platform.
R10.5
At the stage of system design M
(activity 4.4) Supplier must
comply with requirements of
regulations for web service
development” and requirements
to interoperability with EHR
repository provided by platform
supplier. System supplier may
request additional information if
needed for development of
interaction
with
e-health
resources.
R10.6
At
the
stage
of M
testing/certification
(activity
4.6) system Supplier must
comply with requirements of
guidebook published by MOH
of
the
RK
e-health
standardization unit
R10.7
The Supplier shall certify the M
System before its acceptance
into operation
R10.8
In case of circumstances that M
hinder fulfillment of R10.6
443
444
Section VI. Technical Requirements
occurred by no fault on the side
of the Supplier, Acts of System
acceptance shall be signed
without certification. With it,
System Supplier is bounded to
certify the System when
conditions for certifications
have appeared, without any
additional costs on the side of
the Purchaser
R10.10
System shall provide option of M
functioning
on
remote
infrastructure and in cloud
(virtualized)
operating
environment
R11
Requirements to suppliers
R11.1
Supplier will supply his own M
system (components or products
constituting it) or he will be
authorized by developer/owner
of this system (components or
products of its) for supply,
development,
installation,
support of products according to
this Contract.
R11.2
Supplier will train in the M
country of Client which is
related to System use and
administration, and also of all
developed
and
installed
products. Training languages
will be Russian and Kazakh.
Training details are given in
R13.2.
R11.3
Supplier shall have office in M
Purchaser country or have a
partner registered as a legal
entity in the Purchaser country
having an official status of a
partner developer/supplier or
having
agreement
about
consortium in relation with this
specific contract. It is required
Section VI. Technical Requirements
445
during realization, deployment,
training and guaranteed period
for smooth and reliable contract
implementation.
R11.4
Supplier shall have his own M
project implementation team
comprising
at
least
the
following specialists (if needed
two positions may be taken by
one specialist provided his skills
will be proved but not more
than 2 positions for a
specialist):
1) business analyst, having
work experience of at least 3
years in IT e-health projects and
work experience in at least one
similar project;
2)
project
management
specialist (team leader), having
at least 3 years of experience in
project management and 1 year
in the project when supplied
solution was implemented and
he
should
have
project
management certificate
(for
example, PMP or IPMI at least);
3) DBMS specialist with at least
3 years of work experience with
DBMS;
4) specialists with work
experience of at least 2 years
with standards: HL7, DICOM,
CDA (R2), IHE;
5) user interface designer, with
at least 3 years of work
experience;
6) technical writer, with work
experience of at least 2 years;
7)
specialist
on
communications, with work
experience in this area of at
least 3 years of general IT
experience
with excellent
445
446
Section VI. Technical Requirements
knowledge of English, Russian
and Kazakh;
8) Specialist on testing, having
at least 3 years of experience in
software testing;
9) Specialist on training, having
at least 3 years’ experience in
carrying out training;
All supposed specialists shall
have higher education in IT or
related areas, Master’s degree is
preferred. Supplier shall provide
a list of specialists with CV
attached, certificates to provide
work
experience
and
qualification.
R11.5
Supplier shall submit all M
documents (patents, licenses,
certificates of state registration
of rights to copyright, etc.) for
System (for all components and
products),
demonstrating
authorization of owners to use
products for this contract or
demonstrating ownership rights.
R11.6
Plan schedule of services M
provided must be agreed with
authorized organization of the
purchaser and signed by
Purchaser within 20 (twenty)
working days after signing the
contract. Supplier must provide
service in time according to
approved plan schedule.
R11.7
In case of participation of M
foreign companies consortium
is the most appropriate form of
participation in the tender
(while it is not mandatory),
since
some
requirements
assume knowledge and skills
which are not possessed by
international suppliers like work
Section VI. Technical Requirements
447
experience in the country.
R11.8
Software manufacturers shall M
have certificates of Capability
Maturity Model Integration
(CMMI), ISO 9000 series, ST
RK
ISO
9001:2009
or
equivalent
for
quality
management processes (the
Bidder shall submit copies of
certificates for compliance
issued by authorized body)
R11.9
Supplier shall ensure service M
and technical and guarantee
support including provision of
new product versions according
to R13.3 and R13.4.
R11.10
Supplier
shall
prepare M
corresponding guidelines for all
system components in English,
Kazakh and Russian.
R11.11
Supplier shall have proven M
experience with standards used
in the present document: HL7
(v2, V3, FHIR), CDA (R2),
IHE.
R12
General
technical
requirements to the system
R12.1
System shall have centralized М
architecture and be developed in
the form of web application
where the client is browser and
server is web-server.
R12.2
Access to client application М
must be done though any of the
following internet browsers: MS
Internet
Explorer,
Google
Chrome, Opera, Safari, Mozilla
Firefox
R12.3
System server part must support M
work of at least in operational
447
448
Section VI. Technical Requirements
systems of Windows family.
R12.4
System client part must support M
work of at least in operational
systems
Windows
(2008/VISTA/7/8) (x86/x64)
R12.5
To store information in the M
system relational database shall
be used.
R12.6
System database must support M
standard SQL, compatible with
ANSI/ISO/IEC
9075-1992
standard
R12.7
Supplier
shall
provide M
maintenance and technical
support including provision of
new product versions until
guaranteed period expiration
R12.8
System shall provide option of M
authentication using Single
Sign On
R13
Service Specification
R13.1
Requirement to inheritance of
data and functionality.
R13.1.1 In case of system supply and M
implementation different from
exploited by the client the
performer carries out full
complex of required works
related to inheritance of data
and functionality used IS
modules by the client with
connection to the system of
software
and
automated
technical means, medical and
lab equipment used by the
client.
R13.1.2 All costs related to data and M
functionality
migration
is
incurred by the performer.
Section VI. Technical Requirements
R13.2
Training
materials
and
449
training
R13.2.1 Supplier
shall
prepare M
curriculum for training of the
following:
System users;
System administrators;
Developers;
Database administrators.
Curriculum
and
training
materials on each group shall be
agreed with Purchaser before
the training starts.
R13.2.2 Supplier
shall
provide M
equipment,
presentation
materials and textbooks for the
training.
R13.2.3 System supplier shall provide M
training materials as guidelines,
textbooks and presentations,
knowledge bases in state
language and Russian.
R13.2.4 Supplier shall carry out training M
for at least 80 hours for each
group of system administrators,
developers,
database
administrators and 20 hours for
the users of each health facility,
where system implementation
takes place. Number of hours
could be increased and must be
sufficient for knowledge and
skills transfer.
R13.2.5 Supplier shall carry out separate M
training for system users and
administrators,
developers,
database
administrators.
Indicative number of trainees is
defined by multiplication by 2
of total number of automated
work places from Appendix 7.
Place of training is legal address
of health facility-beneficiary.
Groups of trainees shall include
449
450
Section VI. Technical Requirements
not more than 10 specialists.
R13.2.6 For all carried out trainings, M
Supplier must carry out testing
and
issue
certificates
correspondingly.
R13.2.7 Training plan for group (а) – M
system users – shall contain
detailed
explanation
of
automated business processes,
sue of all system components,
detailed description of function
and
interactions
between
different users and roles;
reporting and other required
information. Training also will
contain practice trainings for
material understanding
R13.2.8 Training plan for group (b) – M
system administrators - shall
contain description of system
components
administration
tools
including
important
system maintenance issues and
technical support aspects.
R13.2.9 Supplier shall carry out one M
introductory course and one inservice training for group (c)
developers
on
supplied
development
tools
and
components provided within
this contract.
R13.2.1 Supplier shall carry out for M
0
group
(d)
database
administrators one introductory
course and in-service training
course on supplied DBMS.
R13.2.1 Training for groups (a) - (d) M
1
shall be carried out in Russian
or Kazakh at the Purchaser’s
request.
Section VI. Technical Requirements
451
R13.2.1 For all carried out trainings, M
2
Supplier shall carry out
corresponding testing and issue
certificates.
R13.3.
User support service
R13.3.1 Supplier shall organize user M
support service for consulting
on
issues
arisen
during
exploitation for the whole
period of guaranteed service
implementation
and
maintenance.
R13.3.2 System technical support shall M
be organized by the Supplier
27/7 within 3 years upon the
acceptance act agreed by the
Purchaser.
R13.4.
Guaranteed service
R13.4.1 System supplier will provide M
guaranteed service of the
Purchaser within 3 years
starting right after agreement by
the Purchaser of the acceptance
act.
R13.4.2 Supplier shall ensure resolution M
of issues:
C)
or critical problems
related
to
system
operation that has led to
data
damage,
the
problem shall be solved
within at most 2 hours;
D)
or noncritical problems
it is to be rectified
within not more than 2
days.
F
F
R13.4.3 Guaranteed service includes but M
it is not limited by the
following service categories:
451
452
Section VI. Technical Requirements
- correcting errors in the
system;
- help to the health
facility
in
correct
rectification
of
all
problems with data
arisen as a result of
wrong
application
functions;
- providing technical
support in adjustment of
applications
or
modifying
default
parameters;
- providing required
technical support to
qualified
staff
and
retraining if it is founded
out that they could not
solve their problems
after received training;
R13.4.4 Forms of interference could be M
one of the following most
appropriate
from
the
perspective of quality and
effectiveness:
○
Phone calls;
○
By e-mail;
○
Skype or other Video
Messenger;
○
Remote access to user;
○
Work on site.
R13.4.5 Supplier must provide during M
guaranteed period a group of
consultants
available
in
Purchaser’s country including
one manager and at least one
technical specialist and provide
all required specialists for
remote assistance if needed.
R13.4.6 Total system idle time under M
reasons related to its operation
shall be greater than 24 hours.
R13.4.7 One time system time out under M
Section VI. Technical Requirements
453
reasons related to its operation
shall not be greater than 2 hours
R14
requirement to documents
R14.1
Supplier is required to provide M
the following package of
documents:
● Program and method of
tests;
● formulary (main
characteristics, kitting
and deposit software
maintenance
information);
● description of most
widespread mistakes and
their mitigation ways;
● description of database
structure;
● guideline for software
installation;
● administrator guideline;
● user guideline.
R14.2
Document languages shall be at M
least
state
and
Russian
languages.
R14.3
Supplier shall provide 5 M
packages of documents in hard
copy and electronic format in
English, Kazakh and Russian.
E-version shall support context
search option.
R14.4
Supplier
shall
prepare M
information
system
and
regulatory documents to carry
out attestation for compliance
with
requirements
of
information security according
to article 5 of Law of the
Republic of Kazakhstan of 11
January 2007 «On informatics»
and
Resolution
of
the
Government of the Republic of
453
454
Section VI. Technical Requirements
Kazakhstan of 30 December
2009 № 2280 «On approving
rules for carrying out attestation
of state information systems and
nongovernment
information
systems to be integrated with
state information systems for
compliance with requirements
of information security and
standards adopted in the
territory of the Republic of
Kazakhstan» and enter into
force according to Article 17 of
the Republic of Kazakhstan of
11
January
2007
“On
informatics”.
R15
System
testing
requirements
to
guarantee
R15.1
Pre-starting works
and
quality
R15.1.1 System supplier shall carry out M
standard installation tests for
testing
correct
system
installation.
R15.1.2 Supplier shall provide a list of M
tests, testing conditions, success
criteria etc for system testing
under technical proposal.
R15.1.4 Quality of testing is one of M
criteria for technical evaluation.
A list of tests will include tests
for each module and tests for
the whole system.
R15.1.5 System supplier will carry out М
phased
detailed
testing
including performance tests,
response time test, capacity test,
jointly
with
organization
authorized by the purchaser
according to tests provided by
Supplier.
Section VI. Technical Requirements
455
R15.1.6 Supplier shall demonstrate the М
system with participation of
purchaser representatives and
organization authorized by the
Purchaser according to system
testing scenarios.
R15.1.7 Supplier
shall
outline М
demonstration results in the
minutes on demonstration under
the form agreed with the
Purchaser. Minutes must be
signed by all demonstration
participants.
Venue of demonstration shall be
agreed with Purchaser and
organization authorized by the
Purchaser.
R15.1.8 Supplier shall eliminate all М
remarks
received
during
demonstrations and carry out
repeated demonstrations until
receiving
minutes
about
successful demonstration.
Timeframe for elimination of
remarks is agreed with the
Purchaser.
R15.1.9 Testing shall be carried out М
according to one of standards
IEEE 829/1009, BS 7925,
ISO/AS 9100 and developed
document “testing programme
and methodology» of ST RK
1089-2002.
R15.1.1 Supplier shall test the system М
0
according to the Web Content
Accessibility Guidelines 2.0.
Supplier shall provide detailed
information
about
testing
results.
R15.1.1 Supplier shall test system on М
1
safety according to Open Web
Application Security Project)
Top 10 vulnerability. Supplier
455
456
Section VI. Technical Requirements
shall
provide
information
about
results.
R15.2
detailed
testing
Supplier shall agree with
Purchaser a testing scenario and
provide report on each testing
result.
R15.2.1 Acceptance to exploitation
M
R15.2.2 System acceptance act is signed M
based on trouble free operation
under normal conditions of
exploitation for the system
within 3 months. In case of the
system malfunctioning in the
period supplier shall incorporate
all necessary modifications and
carry out repeated system
exploitation within 3 months.
Operating errors are critical
errors which do not allow to run
the System
R16
requirement
to
ensuring
control by the Purchaser
R16.1
Supplier shall periodically М
defined in the plan schedule
provide regular progress report
to the Purchaser.
R16.2
Report
shall
contain М
information
about
work
performed by the Supplier over
reporting period, according to
approved
plan
schedule
including
services
on
guaranteed support as well as
on technical support service of
suppliers with attachment of all
approved documents over the
reporting period during contract
implementation
including
official correspondence in hard
copy and electronic format (in
at least pdf format).
Section VI. Technical Requirements
R16.3
Report shall be agreed with М
organization authorized by the
purchaser.
R16.4
Purchaser can carry out control М
of contract performance and
quality of services under the
contract by the Supplier in any
time.
457
457
458
Section VI. Technical Requirements
H. APPENDICES
Appendix 1
On republican coordination transplantation center
1.
Entity «Republican transplantation coordination center” established to
implement plan of activities of the state health development program “Salamatti
Kazakhstan” for 2011-2015, approved by decree of government of the Republic of
Kazakhstan dated 29 January 2011 № 41, to organize effective activities on predtransplantation preparation including on retrieving and distribution of tissues and (or) organs
(part of organs) into state health facilities, performing activity on specialty “transplantology”
according to license.
2.
In present document the following main definitions are used:
1)
Transplantation coordination – organization of activities on receiving and
managing information about presence of potential donors and recipients as well as retrieving
conservation and distribution and transportation of tissues and (or) organs (part of organs)
into transplantation centers after receiving donor recipient matching results;
2)
Transplantation center – health facility, performing activity on specialty
“transplantology” according to licenses;
3)
Donor inpatient facility – health facility, in which retrieval of tissues and (or)
organs (parts of organs) from cadaveric donor is done;
4)
Brigade on retrieving organs – group of specialists on retrieving tissues and
(or) organs (part of organs) by surgery operation from cadaveric donor to transplant;
5)
Recipient waiting list – information database about recipients needed
transplantation of tissue and (or) organs (part of parts);
6)
Register of donors of tissues and (or) organs (part of organs) – information
database about persons expressed their lifetime consent for retrieval after their death of
tissue and (or) organs (part of organs) to transplant;
7)
HLA-typing – blood test to detect human leucocyte antigens;
8)
Cross matching reaction – measuring the level of recipient blood antibodies
and antigens located on the surface of potential donor blood cells. Corss typing of donor
lymphocytes and recipient blood serum.
3.
In its work RCCT is governed by Constitutions of the Republic of
Kazakhstan, code of the RK “On people’s health and health system”, regulatory leal acts of
the RK.
Main RCCT tasks and functions
1.
Main RCCT task is to provide and conduct operative activities on creating
effective tissues and (or) organs (part of organs) donorship system in Kazakhstan to
transplant and save lives as well as recover health of citizens, prevention of illegal trade
with tissues and (or) organs (part of organs) of human being.
2.
Main RCCT functions are as follows:
1)
Ensuring quick and high standard tissues and (or) organs (part of organs)
transplantation process form the moment of finding potential donor to organ transplantation
from this donor to the recipient;
2)
Coordination of activities on retrieving, conservation, distribution and of
Section VI. Technical Requirements
459
tissues and transportation of (or) organs (part of organs) for transplantation to
transplantation centers;
3)
Organization of training of persons performing transplantation coordination
as well as medical staff of donor inpatient facilities on issues of law of Kazakhstan in the
area of transplantology, donor management, communication with relatives of potential
donor, human death statement based on irreversible brain death;
4)
Management and updating of recipient waiting list as well as register of
donors of tissues and (or) organs (part of organs);
5)
Monitoring of using donor tissues and (or) organs (part of organs) in
transplantation centers, including registration and analysis of complications and side effects;
6)
Participation in organization and implementation of information programs in
mass media, interaction with representatives of religious confessions on tissues and (or)
organs (part of organs) donorship advocacy among population of the RK;
7)
Interaction with public bodies, NGOs and international organizations on
issues of donorship and tissues and (or) organs (part of organs) transplantation in the RK;
8)
Submission of proposals to the authorized body in the area of health on
refining legal acts in the area of tissues and (or) organs (part of organs) transplantation;
9)
Preparation and carrying out republican seminars, symposiums, conferences,
as well as participation in republican and international conferences on issues of organ
donorship and tissues and (or) organs (part of organs) transplantation.
RCCT organization
3.
RCCT organizes its activity according to layout of health facility interaction
on tissues and (or) organs (part of organs) transplantation, according to annex 4 to the order
№ 199 dated 29.03.2013 «on activities to develop tissues and organs transplantation service
in the RK» (with amendments and additions on 13.08.2013.)
4.
RCCT interacts with donor inpatient facilities in part of organization of
surgery extraction of tissue and (or) organs (part of organs) from cadaveric donor and
transplantation bodies on carrying out tissues and (or) organs (part of organs) transplantation
to the recipient, as well as provide emergency run-out of brigade on organ extraction.
5.
Republican coordination center of air ambulance provides timely
transportation by brigade of organ extraction as well as tissues and (or) organs (part of
organs) on emergency call received by RCCT.
6.
RCCT is closely interacts with health facilities performing their activity in
blood service on issues of carrying out HLA-typing, cross matching of donors’ tissues and
(or) organs (part of organs) and the recipients as well as with infection control lab.
7.
Transplantation coordination is carried out by RCCT staff having medical
education functions of which are:
1)
Receiving from regional transplantation coordinator primary information
about availability of potential donor in certain donor inpatient facility;
2)
Making decision jointly with regional transplantation coordinator about
character of tissues and (or) organs (part of organs) extraction from cadaveric donor;
3)
Informing of transplantation centers about possibility and character of
extraction of tissues and (or) organs (part of organs) extraction from cadaveric donor;
4)
Distribution (before extraction) of tissues and (or) organs (part of organs) and
selection of the recipients with regard to HLA- typing and cross matching of “donorrecipient” reaction;
5)
Organization of call and sending organ extraction brigade to donor inpatient
459
460
Section VI. Technical Requirements
facility;
6)
Organization of recipient call for tissues and (or) organs (part of organs)
transplantation if needed organization of his clinical lab diagnostics;
7)
Management and updating recipient waiting list and register of tissue and (or)
organs (part of organs) donors;
8)
Management of time study from the moment of extraction of donor tissues
and (or) organs (part of organs) up to recipient transplantation.
8.
Heads of donor inpatient facilities provide 24/7 information delivery to the
RCCT on available donors through regional transplantation coordinators.
9.
Medical staff performing regional transplantation coordination functions, are
the following:
1)
Detection of potential donor of tissues and (or) organs (part of organs) under
close coordination with staff of anesthesiology/resuscitation, neurology, neurosurgery
department etc.;
2)
Interaction with spouse, close relatives or potential donor law representatives
to receive consent for extraction of tissues and (or) organs (part of organs) for follow-up
transplantation to the recipients;
3)
Timely delivery of information by phone to the RCCT about possibility of
tissues and (or) organs (part of organs) extraction from cadaveric donor under receiving
consent of his close relatives;
4)
Information delivery to the donor inpatient facility or person in charge of
availability of potential donor and possibility of tissues and (or) organs (part of organs)
extraction for follow-up transplantation to the recipients;
5)
Ensuring participation of forensic pathologist and (or) pathologist during
extraction of tissues and (or) organs (part of organs) from cadaveric donor;
6)
Organization of sending biological material of potential donor tissue and (or)
organs (part of organs) to lab for detection of transfusion infections (HIV, HVB HVC,
syphilis, cytomegalovirus), as well as for HLA-typing and cross matching;
7)
Management of statistical reporting on donor for extraction of tissue and (or)
organs (part of organs).
10.
Transplantation centers provide monitoring of recipient condition before and
after surgery intervention as well as their timely examination.
11.
In transplantation centers surgery brigades for extraction of organs working
around the clock are set.
12.
RCCT is governed by official with professional medical education having
certificate of specialist on “social hygiene and health organization”, designated for the
position and resigned from the post based on agreement with health authorized body.
13.
Head of RCCT performs the following functions:
1)
Ensures realization of RCCT functions set by present provisions;
2)
Submits quarterly report on RCCT performance to health authorized body of
the RK;
3)
Performs other functions provided by legislation of the RK.
14. Transplantation coordination is done around the clock.
15.
Regional RCCT branches are established in oblast centers and/or republican
status cities where there are more than one state health facility carrying out transplantation
according to license.
16.
RCCT funding is done at the expense of republican budget.
Section VI. Technical Requirements
461
Recommended staffing and material technical base of RCCT
17. The following staffing is recommended: 2 deputy director, 5 republican
transplantation coordinators, 16 regional transplantation coordinators, 64 inpatient
transplantation coordinators, lawyer, system administrator and auxiliary services.
18. Recommended material technical base:
Donor inpatient facilities
National scientific surgery center
of A.N.Syzganov JSC Almaty city
Transplantation centers
Republican scientific
production center of
transfusiology
Republican scientific emergency
care center JSC Astana city
Republican scientific neurosurgery
center JSC Astana city
Republican scientific emergency
care center JSC Astana city
National scientific surgery center
of A.N.Syzganov JSC Almaty city
Republican coordination
center on
transplantation
National scientific cardiosurgery
center JSC Astana
GBE Municipal clinical hospital #7
Almaty
National scientific medical center
JSC Astana
National scientific medical center
JSC Astana
National scientific cardiosurgery
center JSC Astana
Health facilities of oblasts, Almaty
and Astana cities providing
inpatient care (as agreed)
Republican coordination
center on sanitary
aiviation
National scientific center of
maternity and childhood JSC
Astanа
RGE Scientific center of pediatrics
and child surgery, Almaty
Fig. А1. Interaction of health facilities on transplantation of tissue and (or) organs (part of organs) in the
RK
461
462
Section VI. Technical Requirements
Appendix 1-1
INDIVIDUAL NEEDED HEART TRANSPLANTATION REGISTRATION FORM
Reg. №. _______
«___»__________201__.
IIN
Family name
Name
Father’s name
Health facility name
Information about cardiologist of the patient attached
Post
Office tel.
Mobile tel.
e-mail
General information about patient
IIN
nationality
Date of birth
(dd/mm/yyyy)
Sex
Age
Registration date
Urgency status
Social status: 1 – employee, 2 - worker, 3 –
agriculture worker, 4 - retired, 5 - student, 6
- housekeeper, 7 – individual self-employed,
8 – minister of religion, 9 - unemployed, 10
- other.
Family name
Name
Father’s name
Benefit category: disabled world war II
veteran - 1, world war II veteran - 2,
Afghanistan war soldier - 3, disabled from
childhood - 4, disabled due to disease - 5,
individuals imposed to radiation - 6,
individuals same as world war II veteran –
7, draftee - 8, disabled from professional
occupation - 9, migrants - 10, other - 99.
oblast
Patient contact details
Mobile tel.
Residence tel.
Office tel.
Patient address information
Registration address
rayon
Community name
street
building
apt
oblast
Residence address
Community name
street
building
apt
Family name
name
e-mail
rayon
Section VI. Technical Requirements
Mobile tel
Residence tel
463
Office tel
e-mail
Patient examination information
diagnosis (main)
name
ICD-10 code
Additional diagnosis
№.
ICD-10 code
Blood group
Rh factor
RW
HIV
Serum sampling date
A
B
А
А
A*
B*
ELISA
IgM
ToxoIgM
HBsAg
HBcAg
HBeAg
HCV total
EBV IgM
HSV IgM
Ао мах
LV мах
PA мах*
name
height
weight
BMI
BSA
Control date of the next
serum sampling
HLA-typing (medium resolution)
Cw
Dw
HLA-typing by serologic method (medium resolution)
В
Cw
HLA-typing by molecular method (medium resolution)
В
DRB1
HLA-typing (high resolution)
DRB1*
DRQB1*
% sensibilization
serology
CMV
IgG
toxoplasmosis
ToxoIgG
Hepatitis В
aHBs
aHBcIgG
aHBcIgM
Hepatitis C
aHCVIgM
aHCVIgG
EBV
EBV IgM
Simple herpes virus
HSV IgG
CVP
sampling
Ао min
Ао med
LV min
LV EDP
PA min
PA med
463
464
RVмах
RA мах
VCI мах
BP syst
SatO2
PVR (Wood)*
HR
EDV
Creatinine
Total bilirubin
GPT
INR
TSH
Т4 св
Hb
platelet
creatinine
НЛА, сенсит %
ДЛА мах*
Section VI. Technical Requirements
RV min
RA min
VCI min
RV med
RA med
VCI med
BP diast
SatO2 RA
CO*
ДЗЛК
cardiogram
EDD
LVEF
Lab tests
urea
Direct bilirubin
AST
glucose
Т3 св
Thyroperoxidase
antibodies
Leucocytes
ProBNP
urea
LVEF %
PVR (W)
Note
Section VI. Technical Requirements
465
Appendix 1-2
INDIVIDUAL NEEDED LIVER TRANSPLANTATION REGISTRATION FORM
Reg. №. _______
«___»__________201__.
Physician information
position
Office tel
Mobile tel
e-mail
IIN
Family name
Name
Father’s name
Health facility name
General patient information
IIN
nationality
Date of birth
(dd/mm/yyyy)
Age
Urgency level
Family name
Name
Father’s name
sex
Health facility
admission
Death date
Death reason
Health facility attached
Social status: 1 – employee, 2 - worker, 3 – agriculture worker, 4 retired, 5 - student, 6 - housekeeper, 7 – individual self-employed, 8
– minister of religion, 9 - unemployed, 10 - other.
Benefit category: disabled world war II veteran - 1, world war II
veteran - 2, Afghanistan war soldier - 3, disabled from childhood 4, disabled due to disease - 5, individuals imposed to radiation - 6,
individuals same as world war II veteran – 7, draftee - 8, disabled
from professional occupation - 9, migrants - 10, other - 99.
Patient contact person
Mobile tel
Res.tel
Office tel.
Patient address information
Registration address
Family name
name
e-mail
oblast
rayon
Name of community
street
buil
ding
apt
street
Buil
ding
apt
Residence address
oblast
rayon
Name of community
465
466
Section VI. Technical Requirements
Mobile tel
Resid.tel
Office tel
e-mail
Patient examination information
Diagnosis a basis for
transplantation
Diagnosis of liver
failure
name
ICD-10 code
name
ICD-10 code
Additional diagnoses
№.
ICD-10 code
Blood group
Rh factor
abdominal
circumference
RW
HIV
PRA level (%) by
ELISA method
PRA level (%) by
serology method
Specificity of PAG 1
class HLA by ELISA
method
name
height
weight
Chest
circumference
Varicose veins
of esophagus
Virus hepatitis markers
VH vaccination
Date of Blood test for
PRA level (%) by
ELISA
Date of blood test for
PRA (%) level by
serology method
Total bilirubin
(mcmol/l)
HLA-typing by serology method (medium resolution)
B
Cw
HLA-typing by molecular method (medium resolution)
A
B
DRB1
Cross matching
Cross matching
Sample date
Donor IIN
A
Transplantation center
Reserve transplantation center
Expected transplantation (from alive person
and cadaver)
supposed donor
Transplantation information
transplantation
Donor IIN
Transplantation date
Health facility name, where
transplantation was done
Section VI. Technical Requirements
467
467
468
Section VI. Technical Requirements
Appendix 1-3
INDIVIDUAL NEEDED KIDNEY TRANSPLANTATION REGISTRATION FORM
Reg. №. _______
«___»__________201__.
Physician name
position
Office tel
Mobile tel
e-mail
IIN
Family name
name
Father’s name
Health facility name
Patient general information
IIN
nationality
Date of birth
(dd/mm/yyyy)
age
Urgency level
Family name
name
Father’s name
sex
Health facility
registration date
Outpatient facility
Hemodialysis start date
attached
Death date
Death reason
Health facility the patient is attached
Social status: 1 – employee, 2 - worker, 3 – agriculture worker, 4 retired, 5 - student, 6 - housekeeper, 7 – individual self-employed, 8
– minister of religion, 9 - unemployed, 10 - other.
Benefit category: disabled world war II veteran - 1, world war II
veteran - 2, Afghanistan war soldier - 3, disabled from childhood 4, disabled due to disease - 5, individuals imposed to radiation - 6,
individuals same as world war II veteran – 7, draftee - 8, disabled
from professional occupation - 9, migrants - 10, other - 99.
Patient contact person
Mobile tel
Residence tel
Office tel
Patient address information
Registration address
Family name
name
e-mail
oblast
rayon
Community name
Residence address
street
buil
ding
apartment
Section VI. Technical Requirements
oblast
rayon
Mobile tel
Residence tel
469
Community name
street
buil
ding
apartment
Office tel
e-mail
Patient examination information
diagnosis (basis for
transplantation)
diagnosis (main is the
reason for
transplantation)
name
ICD-10 code
name
ICD-10 code
Additional diagnosis
№.
ICD-10 code
Blood group
Rh
RW
HIV
PRA (%) byELISA
PRA (%) by serology
method
name
height
weight
Virus hepatitis marker
VH vaccination
Blood sample for
determination of PRA
(%) by ELISA
Blood sample for
determination of PRA
(%) by serology method
Specificity of PAG class HLA by ELISA
HLA-typing by serology method (medium resolution)
A
B
Cw
HLA-typing by molecular method (medium resolution)
A
B
DRB1
Cross matching
Cross matching
Sample date
IIN of supposed donor
Supposed transplantation center
Reserve transplantation center
Supposed transplantation (from alive and
cadaver)
Supposed donor
Transplantation information
Transplantation type
IIN donor
Transplantation date
Health facility name, where
transplantation was done
469
470
Section VI. Technical Requirements
Section VI. Technical Requirements
471
Appendix 2
DONOR REGISTRATION FORM
Reg. №. _______
«___»__________201__.
Information about person filling in form
position
Office tel
Mobile tel
e-mail
IIN
Family name
Name
Father’s name
Health facility name
Possible donor
sex
age
№ disease history
Birth date (dd/mm/yyyy)
Admission date
(dd/mm/yyyy)
Diagnosis main
name
ICD-10 code
Additional diagnosis
№
ICD-10 code
name
note (including cadaver, patient moved to
department, relatives’ denial etc.)
Potential donor
RITU admission date
Period of stay in RITU
Blood group
Rh
Death/irreversible circulation arrest statement date
Conditioning
Consent of relatives for
extraction of organs/lifetime
consent
note (including cadaver, patient moved to
department, relatives’ denial etc.)
List of organs/tissues to be retrieved
№
name
note
Actual donor
name
Father’s name
IIN
Family name
note (including cadaver, moved to department,
relatives’ denial etc.)
List of organs/tissues to be retrieved
№
name
note
471
472
Section VI. Technical Requirements
Section VI. Technical Requirements
473
Appendix 2-1
VOLUNTARY DONOR REGISTRATION FORM
Reg. №. _______
«___»__________201__.
Information about applicant
position
Office tel
Mobile tel
e-mail
IIN
Family name
Name
Father’s name
Health facility name
patient general information
IIN
nationality
Date of birth
(dd/mm/yyyy)
age
Family name
name
Father’s name
sex
Attached health facility
Social status: 1 – employee, 2 - worker, 3 – agriculture worker, 4 retired, 5 - student, 6 - housekeeper, 7 – individual self-employed, 8
– minister of religion, 9 - unemployed, 10 - other.
Benefit category: disabled world war II veteran - 1, world war II
veteran - 2, Afghanistan war soldier - 3, disabled from childhood 4, disabled due to disease - 5, individuals imposed to radiation - 6,
individuals same as world war II veteran – 7, draftee - 8, disabled
from professional occupation - 9, migrants - 10, other - 99.
Document identifying person
Document
(passport,
#
Issued by
identity card)
Valid until
Patient contact person
Mobile tel
Residence tel
Office tel
Patient address information
Registration address
Family name
name
e-mail
oblast
Issued when
rayon
Community name
street
buil
ding
apartment
street
buil
ding
apartment
Residence address
oblast
rayon
Community name
473
474
Section VI. Technical Requirements
Mobile tel
Residence tel
Office tel
e-mail
Patient examination information*
Blood group
height
Rh
weight
RW
Virus hepatitis markers
HIV
VH vaccination information
HLA-typing by serology method (medium resolution)
A
B
Cw
HLA-typing by molecular method (medium resolution)
A
B
DRB1
Cross matching
Cross matching
Sampling date
IIN of proposed recipient
Registration date
Death date
Type of consent for using organs/part of organs and/or tissues** (consent for
lifetime use for relative with indication of concrete person, consent for
lifetime use to any of the patients from health facility, consent for post
mortal use to any of persons from health facility)
List of organs/part of organs and/or tissues
Transplantation type
organs/part of organs and/or
IIN of proposed recipient
tissues
note
*scanned copy of discharge to be attached, it is issued not later than 1 month from the
registration date and containing the following information:
− height
− weight
− blood group
− rhesus
− absence of cancer disease;
− absence of active TB;
− determination of blood group and rhesus крови based on ABO
− total blood count test
− total urine count test
− total protein, Alpha and gamma globulin count
Section VI. Technical Requirements
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
−
475
albumin test
bilirubin test
creatinine test
glucose test
urea test
albumin test, Ca, Mg, P
determination of GGT active
determination of ALP active
determination of blood electrolyte concentration ( К,Na, Ca, Cl)
Determination of acid base condition parameters
Determination of ALT active
Determination of AST
Determination of alpha amylase
Determination of lipid spectrum
hemostasis testing: aPPT, AST, determination of activated partial tromboplastin
time, protrombin time, international normalized ratio, thrombin time, determination
of fibrinogen concentration and soluble fibrin monomeric complex, d-dimers,
antitrombin III, protein «С» and «S», if agents available.
ELISA anti CMV (IgM+G)$,if agents available.
ELISA for HIV markers (antiHIV and HIV Ag);
HLA typing 1 class (HLA-A,B) and II class (HLA-DR);
Testing for preceding HLA antibodies
ELISA for HBsAg and summary antibodies to core-antigen HBV;
(PCR) for HBV-DNA (if positive HBsAg);
ELISA for antibodies to HBc Ig class М and summary Ig (if positive HBsAg);
ELISA for HBeAg (if positive HBsAg);
ELISA for anti-HBe (if positive HBsAg);
ELISA for Anti-HDV IgM,G (if positive HBsAg);
PCR for HDV-DNA (if positive ELISA for anti-HDV);
ELISA for anti-HCV;
for HCV-RNA (if positive ELISA for anti-HCV);
ELISA for EBV IgM;}
ELISA for EBV IgG;}
if agents available
ELISA for CMV IgM;}
ELISA for CMV IgG;}
ELISA for HIV-Ag and ELISA for anti-HIV;
ELISA for HIV-RNA if positive ELISA for anti-HIV
Complex serology reactions for syphilis (anti-T/pallidum, RW)
Bacteriological testing of mucous membrane of fauces, nose and vagina; urine;
faeces ( for salmonella, shigella, stap.auresus , fungus), sputum if present.
electrocardiograph (ECG)
chest x-ray
heart ultrasound (echocardiography)
abdominal cavity organs ultrasound
spirography (as indicated)
chest cavity organs x-ray
fiberoptic gastroduodenoscopy (ФГДС)
retrograde or MR cholangiography (if indicated)
colonoscopy (if indicated)
475
476
Section VI. Technical Requirements
− multidetector computer tomography КТ-64)- three phased angiographic study of
abdominal cavity organs
− chest CT (if indicated)
− brain CT
− determination of oncomarker- alpha fetoprotein (AFP)
− determination of oncomarker СА-19-9
− determination of cancer embryonal antigen (CEA)
− determination of prostate specific antigen (if indicated)
− Doppler of kidney and liver
− Liver biopsy
− Diagnostics of enzyme defect
− Determination of anti mitochondrial antibodies (АМА М2)
− Determination of antinuclear antibodies (ANA)
− Determination of anti neutrophil antibodies (ANCA)
− Determination of antibodies to liver and kidney microsomes (anti LKM-1), if agents
available
− Glucose tolerance test ( if indicated)
− Physician consultation}
− Cardiologist consultation} if these specialists are available in hospital
− Gastroenterologist consultation}
− otorhinolaryngologist consultation
− physiotherapist consultation
− consultation of infectious disease physician, if these specialists is available in hospital
− immunology specialist consultation
− hematology specialist consultation
− endocrinologist consultation
− surgeon and transplantologist consultation
− anaesthesiologist consultation
**scanned copy of notary certified written expression of will shall be attached
Section VI. Technical Requirements
477
Appendix 3
Table of criteria for selection of potential recipient from the waiting list
criterion
Score points
9 points for 100% compatibility under А,В,Cw,DRB1
HLA-compatibility
7 points for 100% compatibility under В or DRB1
5 points for non-compatibility under one of antigens В or
DRB1
2 points for non-compatibility under two of antigens В or
DRB1
Pre-existing
antibodies
age
4 points for over 80% and negative cross matching sample
4 points to the patient younger than 40 years
3 points to the patient in the age of 41 to 63
According to council of physicians
urgency
Keeping other conditions the same priority is given to the
region population living in the area of concrete
transplantation center
1 point for compatible blood group of the patient with the
longest waiting period
Waiting time
1 extra point for every consecutive year of being in waiting
list
1 extra point, if the patient was organ donor in the past
477
*PDR
**DER
***TCER
note
Transplantation coordination efficiency ratio ***
Donorship efficiency ratio **
Potential donorship ratio*
Number of carried out non-relative transplantation
Number of carried out relative transplantation
Number of actual donors
Number of potential donors
Number of possible donors
Total number of cadaver in RITU
Number of cadaver in resuscitation and intensive
therapy unit over the 1-7-th day period
Health facility name
478
Section VI. Technical Requirements
Appendix 4
Coordinating physician’s monthly report
Potential donorship ratio (ratio of cadaver people over the 1-7th-day period to
the total number of cadaver in RITU*100)
Donorship efficiency ratio (ration of actual donors to the number of cadaver
donors over the 1-7-th day period*100)
Transplantation coordination efficiency ratio (DER to PDR ratio)
total:
Number of deaths
Number of r allogenic pancreas
transplantation, pancreatic islet
Number of allogenic heart
transplantation
Number of non relative allogenic
liver transplantation
Number of relative allogenic liver
transplantation
Number of non relative allogenic
kidney transplantation
Number of relative allogenic kidney
transplantation
Health facility legal name
region
Section VI. Technical Requirements
479
Appendix 5
Report on allogenic organ transplantation
479
№
List of ex planted organs
Organ ex plantation date
age
IIN
Blood group and rhesus factor
Period of staying in resuscitation and
intensive thrapy dpt
conditioning
Consent of relatives for extraction organs
lifetime consent
Family name
sex
age
Diagnosis (ICD code)
admission date
age
diagnosis (ICD code
№ disease history
Health facility name (legal name)
480
Section VI. Technical Requirements
Appendix 6
Regional transplantation coordinator daily report
POSSIBLE
POTENTIAL donor
ACTUAL donor
donor
note
(including
the
cadaver,
moved to
department
, denial of
relatives
etc.)
Раздел VI. Технические требования (График реализации)
Appendix 7
Estimated number of system users by modules breakdown
№
Requirement
1
Module «Registration of an individual needed transplantation» – 133 users.
2
Module «Inpatient transplantation coordinator» – 19 users
3
Module «lab testing» – 2 users
4
Module «regional transplantation coordinator» – 16 users
5
module Republican transplantation coordinator – 6 users
6
module Transplantation brigade – 10 users
7
module “monitoring of the condition of individuals whom transplantation was
carried out – 21 users
8
module Generating analytical and statistical tables – 21 users
9
Мodule «Administration» – 3 users
482
Section VI. Technical Requirements
Section VII. Sample Forms
483
SECTION VII. SAMPLE FORMS
Notes to Bidders on working with the Sample Forms
The Purchaser has prepared the forms in this section of the Bidding Documents to suit
the specific requirements of the System being procured. They are derived from the forms
contained in the World Bank’s Standard Bidding Documents for the Supply and Installation
of Information Systems. In its bid, the Bidder must use these forms (or forms that present in
the same sequence substantially the same information). Bidders should not introduce
changes without the Purchaser’s prior written consent (which may also require the clearance
of the World Bank). If the Bidder has a question regarding the meaning or appropriateness
of the contents or format of the forms and/or the instructions contained in them, these
questions should be brought to the Purchaser’s attention as soon as possible during the bid
clarification process, either at the pre-bid meeting or by addressing them to the Purchaser in
writing pursuant to ITB Clause 10.
The Purchaser has tried to provide explanatory text and instructions to help the
Bidder prepare the forms accurately and completely. The instructions that appear directly on
the forms themselves are indicated by use of typographical aides such as italicized text within
square brackets as is shown in the following example taken from the Bid Submission Form:
Duly authorized to sign this bid for and on behalf of [ insert: name of Bidder ]
In preparing its bid, the Bidder must ensure all such information is provided and that
the typographical aides are removed.
The sample forms provide a standard set of documents that support the procurement
process as it moves forward from the stage of bidding, through Contract formation and onto
Contract performance. The first set of forms must be completed and submitted as part of the
bid prior to the deadline for bid submission. These include: (i) the Bid Submission Form; (ii)
the Price Schedules; (iii) the Manufacturer’s Authorizations and key Subcontractor
agreements; (iv) the List of Proposed Subcontractors; (v) the form(s) for securing the bid (if
and as required); and other forms as found in sub-sections 1 through 4 of this Section VII of
the Bidding Documents.

Bid Submission Form: In addition to being the place where official confirmation of
the bid price, the currency breakdown, the completion date(s), and other important
Contract details are expressed, the Bid Submission Form is also used by the Bidder to
confirm - in case adjudication applies in this Contract - its acceptance of the
Purchaser’s proposed Adjudicator, or to propose an alternative. If the bid is being
submitted on behalf of a Joint Venture, it is essential that the Bid Submission Form be
signed by the partner in charge and that it be supported by the authorizations and
power of attorney required pursuant to ITB Clause 6.2. Given widespread concern
about illegal use of licensed software, Bidders will be asked to certify in the Bid
Submission Form that either the Software included in the bid was developed and is
483
484
Section VII. Sample Forms
owned by the Bidder, or, if not, the Software is covered by valid licenses with the
proprietor of the Software.

Price Schedules: The prices quoted in the Price Schedules should constitute full and
fair compensation for supply, installation, and achieving Operational Acceptance of
the System as described in the Technical Requirements based on the Implementation
Schedule, and the terms and conditions of the proposed Contract as set forth in the
Bidding Documents. Prices should be given for each line item provided in the
Schedules, with costs carefully aggregated first at the Subsystem level and then for
the entire System. If the Price Schedules provide only a summary breakdown of
items and components, or do not cover some items unique to the Bidder’s specific
technical solution, the Bidder may extend the Schedules to capture those items or
components. If supporting price and cost tables are needed for a full understanding of
the bid, they should be included.
Arithmetical errors should be avoided. If they occur, the Purchaser will correct them
according to ITB Clause 26.2 (ITB Clause 38.2 in the two-stage SBD) without
consulting the Bidder. Major omissions, inconsistencies, or lack of substantiating
detail can lead to rejection of a bid for commercial non-responsiveness. Presenting
prices according to the breakdown prescribed in the Price Schedules is also essential
for another reason. If a bid does not separate prices in the prescribed way, and, as a
result, the Purchaser cannot apply the domestic preference provision described in ITB
Clause 29 (ITB Clause 41 in the two-stage SBD), if they are applicable in this
bidding, the Bidder will lose the benefit of the preference. Once bids are opened,
none of these problems can be rectified. At that stage, Bidders are not permitted to
change their bid prices to overcome errors or omissions.

Manufacturer’s Authorizations and written agreements by key Subcontractors: In
accordance with ITB Clauses 6.1 (b) and (c), a Bidder may be required to submit, as
part of its bid, Manufacturer’s Authorizations in the format provided in the Bidding
Documents, and agreements by Subcontractors proposed for key services, for all
items specified in the Bid Data Sheet. There is no particular format (or sample form)
for Subcontractor agreements.

List of Proposed Subcontractors: In accordance with ITB Clause 6.3, a Bidder must
submit, as part of its bid, a list of proposed subcontracts for major items of
Technologies, Goods, and/or Services. The list should also include the names and
places of registration of the Subcontractors proposed for each item and a summary of
their qualifications.

List of Software and Materials: In accordance with ITB Clause 13.1 (e) (vi) (ITB
Clauses 13.1 (c) (vi) and 25.1 (e) (vi) in the two-stage SBD), Bidders must submit, as
part of their bids, lists of all the Software included in the bid assigned to one of the
following categories: (A) System, General-Purpose, or Application Software; or
(B) Standard or Custom Software. Bidders must also submit a list of all Custom
Materials. If provided for in the Bid Data Sheet, the Purchaser may reserve the right
to reassign certain key Software to a different category.
Section VII. Sample Forms
485

Qualification information forms: In accordance with ITB Clause 6, the Purchaser
will determine whether the Bidder is qualified to undertake the Contract. This entails
financial, technical as well as performance history criteria which are specified in the
BDS for ITB Clause 6. The Bidder must provide the necessary information for the
Purchaser to make this assessment through the forms in this sub-section. The forms
contain additional detailed instructions which the Bidder must follow.

Securing the bid: If the BDS for ITB Clause 17 (ITB Clause 29 in the two-stage
SBD) requires that bids be secured, the Bidder shall do so in accordance with the type
and details specified in the same ITB/BDS Clause, either using the form(s) included
in these Sample Forms or using another form acceptable to the Purchaser. If a Bidder
wishes to use an alternative form, it should ensure that the revised format provides
substantially the same protection as the standard format; failing that, the Bidder runs
the risk of rejection for commercial non-responsiveness.
Bidders need not provide the Performance Security and Advance Payment Security
with their bids. Only the Bidder selected for award by the Purchaser will be required to
provide these securities.
The following forms are to be completed and submitted by the successful Bidder
following notification of award: (i) Contract Agreement, with all Appendices;
(ii) Performance Security; and (iii) Advance Payment Security.

Contract Agreement: In addition to specifying the parties and the Contract Price, the
Contract Agreement is where the: (i) Supplier Representative; (ii) if applicable,
agreed Adjudicator and his/her compensation; and (iii) the List of Approved
Subcontractors are specified. In addition, modifications to the successful Bidder’s
Bid Price Schedules are attached to the Agreement. These contain corrections and
adjustments to the Supplier’s bid prices to correct errors, adjust the Contract Price to
reflect – if applicable - any extensions to bid validity beyond the last day of original
bid validity plus 56 days, etc.

Performance Security: Pursuant to GCC Clause 13.3, the successful Bidder is
required to provide the Performance Security in the form contained in this section of
these Bidding Documents and in the amount specified in accordance with the SCC.

Advance Payment Security: Pursuant to GCC Clause 13.2, the successful Bidder is
required to provide a bank guarantee for the full amount of the Advance Payment - if
an Advance Payment is specified in the SCC for GCC 12.1 - in the form contained in
this section of these Bidding Documents or another form acceptable to the Purchaser.
If a Bidder wishes to propose a different Advance Payment Security form, it should
submit a copy to the Purchaser promptly for review and confirmation of acceptability
before the bid submission deadline.
The Purchaser and Supplier will use the following additional forms during Contract
implementation to formalize or certify important Contract events: (i) the Installation and
Operational Acceptance Certificates; and (ii) the various Change Order forms. These and the
procedures for their use during performance of the Contract are included in the Bidding
Documents for the information of Bidders.
485
486
Section VII. Sample Forms
Table of Sample Forms
1. Bid Submission Form (Single-Stage Bidding) ..............................................................488
2. Price Schedule Forms .....................................................................................................492
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Preamble .................................................................................................................493
Grand Summary Cost Table....................................................................................495
Supply and Installation Cost Summary Table ........................................................496
Recurrent Cost Summary Table ..............................................................................498
Supply and Installation Cost Sub-Table [ insert: identifying number ]Error! Bookmark not defined.
Recurrent Cost Sub-Table [ insert: identifying number ] .....................................500
Country of Origin Code Table ................................................................................500
3. Other Bid Forms and Lists.............................................................................................501
3.1 Manufacturer’s Authorization .................................................................................502
3.2 List of Proposed Subcontractors .............................................................................503
3.3 Software List ...........................................................................................................504
3.4 List of Custom Materials ........................................................................................505
3.5.1 General Information Form ......................................................................................506
3.5.2 General Information Systems Experience Record ..................................................507
3.5.2a Joint Venture Summary........................................................................................508
3.5.3 Particular Information Systems Experience Record ...............................................509
3.5.3a Details of Contracts of Similar Nature and Complexity ......................................510
3.5.4 Summary Sheet: Current Contract Commitments / Work in Progress ..................511
3.5.5 Financial Capabilities..............................................................................................512
3.5.6 Personnel Capabilities .............................................................................................514
3.5.6a Candidate Summary .............................................................................................515
3.5.7 Technical Capabilities .............................................................................................516
3.5.8 Litigation History ....................................................................................................517
4. Bid-Securing Declaration ...............................................................................................518
4A. Bid Security (Bank Guarantee) ..................................................................................519
4B. Bid Security (Bid Bond) ...............................................................................................520
5. Contract Agreement .......................................................................................................521
Appendix 1. Supplier’s Representative...........................................................................525
Appendix 2. Adjudicator .................................................................................................526
Appendix 3. List of Approved Subcontractors ...............................................................527
Appendix 4. Categories of Software ...............................................................................528
Appendix 5. Custom Materials .......................................................................................529
Appendix 6. Revised Price Schedules ............................................................................530
Appendix 7. Minutes of Contract Finalization Discussions and Agreed-to Contract
Amendments ...........................................................................................................531
6. Performance and Advance Payment Security Forms..................................................532
Section VII. Sample Forms
6.1
6.2
487
Performance Security Form (Bank Guarantee).......................................................533
Advance Payment Security Form (Bank Guarantee) ..............................................535
7. Installation and Acceptance Certificates ......................................................................537
7.1
7.2
Installation Certificate .............................................................................................538
Operational Acceptance Certificate ........................................................................539
8. Change Order Procedures and Forms ..........................................................................540
8.1
8.2
8.3
8.4
8.5
8.6
Request for Change Proposal Form ........................................................................541
Change Estimate Proposal Form .............................................................................543
Estimate Acceptance Form .....................................................................................545
Change Proposal Form ............................................................................................547
Change Order Form ................................................................................................549
Application for Change Proposal Form ..................................................................551
487
488
Section VII. Sample Forms
1. BID SUBMISSION FORM (SINGLE-STAGE BIDDING)
Date:
Loan/Credit No.:
IFB:
Contract:
[ Bidder insert: date of bid ]
[ Purchaser insert: number ]
[ Purchaser insert: IFB title and number ]
[ Purchaser insert: name of Contract ]
To: [ Purchaser insert: name and address of Purchaser ]
Dear Sir or Madam:
Having examined the Bidding Documents, including Addenda Nos. [ insert
numbers ], the receipt of which is hereby acknowledged, we, the undersigned, offer to
supply, install, achieve Operational Acceptance of, and support the Information System
under the above-named Contract in full conformity with the said Bidding Documents for the
sum of:
plus
[ insert: amount of local
currency in words ]
([ insert: amount of local currency
in figures from corresponding Grand
Total entry of the Grand Summary
Cost Table ])
[ insert: amount of foreign
currency A in words ]
([ insert: amount of foreign
currency A in figures from
corresponding Grand Total entry of
the Grand Summary Cost Table ])
[ as appropriate, add the following ]
plus
[ insert: amount of foreign
currency B in words ]
([ insert: amount of foreign
currency B in figures from
corresponding Grand Total entry of
the Grand Summary Cost Table ])
plus
[ insert: amount of foreign
currency C in words ]
([ insert: amount of foreign
currency C in figures from
corresponding Grand Total entry of
the Grand Summary Cost Table ])
or such other sums as may be determined in accordance with the terms and conditions of the
Contract. The above amounts are in accordance with the Price Schedules attached herewith
and made part of this bid.
Section VII. Sample Forms
489
We undertake, if our bid is accepted, to commence work on the Information System
and to achieve Installation and Operational Acceptance within the respective times stated in
the Bidding Documents.
If our bid is accepted, and if these Bidding Documents so require, we undertake to
provide an advance payment security and a performance security in the form, in the amounts,
and within the times specified in the Bidding Documents.
[ As appropriate, include or delete the following paragraph ]
“We accept the appointment of [ Purchaser insert: name of proposed Adjudicator
from the Bid Data Sheet ] as the Adjudicator.”
[ and delete the following paragraph, or, as appropriate, delete the above
and include the following, or, if no Adjudicator is stated in the Bid Data
Sheet, delete both the above and the following ]
“We do not accept the appointment of [ Purchaser insert: name of proposed
Adjudicator from the Bid Data Sheet ] as the Adjudicator, and we propose instead that
[ insert: name ] be appointed as Adjudicator, whose résumé and hourly fees are attached.”
We hereby certify that the Software offered in this bid and to be supplied under the
Contract (i) either is owned by us, or (ii) if not owned by us, is covered by a valid license
from the proprietor of the Software.
We agree to abide by this bid, which, in accordance with ITB Clauses 13 and 16,
consists of this letter (Bid Submission Form) and the enclosures listed below, for a period of
[ Purchaser insert: number from Bid Data Sheet ] days from the date fixed for submission
of bids as stipulated in the Bidding Documents, and it shall remain binding upon us and may
be accepted by you at any time before the expiration of that period.
Commissions or gratuities, if any, paid or to be paid by us to agents relating to this
Bid, and to Contract execution if we are awarded the Contract, are listed below:
Name and Address
of Agent
Etc.
Amount and
Currency
Purpose of
Commission or
Gratuity
[if none, state: “none”]
Until the formal final Contract is prepared and executed between us, this bid, together
with your written acceptance of the bid and your notification of award, shall constitute a
binding contract between us. We understand that you are not bound to accept the lowest or
any bid you may receive.
Dated this [ insert: ordinal ] day of [ insert: month ], [ insert: year ].
489
490
Section VII. Sample Forms
Signed:
Date:
In the capacity of [ insert: title or position ]
Duly authorized to sign this bid for and on behalf of [ insert: name of Bidder ]
ENCLOSURES:
Price Schedules
Bid-Securing Declaration or Bid-Security (if and as required)
Signature Authorization [plus, in the case of a Joint Venture Bidder, list all other
authorizations pursuant to ITB Clause 6.2]
Attachment 1. Bidder’s Eligibility
Attachment 2. Bidder’s Qualifications (including Manufacturer’s Authorizations and
Subcontractor agreements if and as required)
Attachment 3. Eligibility of Goods and Services
Attachment 4. Conformity of the Information System to the Bidding Documents
Attachment 5. Proposed Subcontractors
Attachment 6. Intellectual Property (Software and Materials Lists)
[if appropriate, specify further attachments or other enclosures]
Section VII. Sample Forms
491
Bid Table of Contents and Checklist
Note: Purchasers should expand and modify (as appropriate) the following table to reflect
the required elements of the Bidder’s bid. As the following note to Bidders explains, it is in
both the Purchaser’s and Bidder’s interest to provide this table and accurately fill it out.
Note: Bidders should expand and (if appropriate) modify and complete the following table.
The purpose of the table is to provide the Bidder with a summary checklist of items that must
be included in the bid as described in ITB Clauses 13.1 and 16, in order for the bid to be
considered for Contract award. The table also provides a summary page reference scheme to
ease and speed the Purchaser’s bid evaluation process.
Item
present: y/n
page no.
Bid Submission Form......................................................
Price Schedules ...............................................................
Bid-Securing Declaration / Bid-Security (if and as
required) ..........................................................................
Signature Authorization (for Joint Ventures additionally
including the authorizations listed in ITB Clause 6.2)....
Attachment 1 ...................................................................
Attachment 2 ...................................................................
Manufacturer’s Authorizations .................................
Subcontractor agreements .........................................
Attachment 3 ...................................................................
Attachment 4 ...................................................................
Attachment 5 ...................................................................
Attachment 6 ...................................................................
.........................................................................................
491
492
Section VII. Sample Forms
2. PRICE SCHEDULE FORMS
Note: in information systems procurement, the Contract Price (and payment schedule)
should be linked as much as possible to achievement of operational capabilities, not just to
the physical delivery of technology.
Section VII. Sample Forms
493
2.1
Preamble
Note: Purchasers should highlight any special requirements of the System and Contract in
a Preamble to the Price Schedules. The following is an example of one such
preamble.
General
1.
The Price Schedules are divided into separate Schedules as follows:
2.2
Grand Summary Cost Table
2.3
Supply and Installation Cost Summary Table
2.5
Supply and Installation Cost Sub-Table(s)
2.7
Country of Origin Code Table
[ insert: any other Schedules as appropriate ]
2.
The Schedules do not generally give a full description of the information technologies
to be supplied, installed, and operationally accepted, or the Services to be performed
under each item. However, it is assumed that Bidders shall have read the Technical
Requirements and other sections of these Bidding Documents to ascertain the full scope
of the requirements associated with each item prior to filling in the rates and prices.
The quoted rates and prices shall be deemed to cover the full scope of these Technical
Requirements, as well as overhead and profit.
3.
If Bidders are unclear or uncertain as to the scope of any item, they shall seek
clarification in accordance with the Instructions to Bidders in the Bidding Documents
prior to submitting their bid.
Pricing
4.
Prices shall be filled in indelible ink, and any alterations necessary due to errors, etc.,
shall be initialed by the Bidder. As specified in the Bid Data Sheet, prices shall be
fixed and firm for the duration of the Contract.
5.
Bid prices shall be quoted in the manner indicated and in the currencies specified in
ITB Clauses 14 and 15 (ITB Clauses 27 and 28 in the two-stage SBD). Prices must
correspond to items of the scope and quality defined in the Technical Requirements or
elsewhere in these Bidding Documents.
6.
The Bidder must exercise great care in preparing its calculations, since there is no
opportunity to correct errors once the deadline for submission of bids has passed. A
single error in specifying a unit price can therefore change a Bidder’s overall total bid
price substantially, make the bid noncompetitive, or subject the Bidder to possible loss.
The Purchaser will correct any arithmetic error in accordance with the provisions of
ITB Clause 26.2 (ITB Clause 38.2 in the two-stage SBD).
493
494
7.
Section VII. Sample Forms
Payments will be made to the Supplier in the currency or currencies indicated under
each respective item. As specified in ITB Clause 15.1 (ITB Clause 28.1 in the twostage SBD), no more than three foreign currencies may be used. The price of an item
should be unique regardless of installation site.
Section VII. Sample Forms
495
2.2
Grand Summary Cost Table
[ insert: Local
Currency ]
Price
1.
Supply and Installation Costs (from
Supply and Installation Cost Summary
Table)
2.
Grand Totals (to Bid Submission Form)
[ insert: Foreign
Currency A ]
Price
[ insert: Foreign
Currency B ]
Price
[ insert: Foreign
Currency C ]
Price
Name of Bidder:
Authorized Signature of Bidder:
495
496
Section VII. Sample Forms
2.3
Supply and Installation Cost Summary Table
System or Subsystem number: [ if a multi-lot procurement, insert: Subsystem number; otherwise state “entire System
procurement” ] [ as necessary for supply, installation, and achieving Operational Acceptance of the System, specify items in the
Table below, modifying, deleting, or expanding the sample line items and sample table entries as needed. ]
Costs MUST reflect prices and rates quoted in accordance with ITB Clauses 14 and 15 .
Supply & Installation Prices
Locally
supplied
items
Line
Item
No.
Subsystem / Item
Supply and
Installation
Cost SubTable No.
[ insert:
Local
Currency ]
Price
Items supplied from outside the Purchaser’s Country
[ insert:
Local
Currency ]
Price
[ insert:
Foreign
Currency A]
Price
[ insert:
Foreign
Currency B]
Price
[ insert:
Foreign
Currency C]
Price
1
1.1
1.2
1.3
SUBTOTALS
TOTAL (To Grand Summary Table)
Note:
- - indicates not applicable. “ indicates repetition of table entry above. Refer to the relevant Supply and Installation Cost Sub-Table
for the specific components that constitute each Subsystem or line item in this summary table
Section VII. Sample Forms
497
Name of Bidder:
Authorized Signature of Bidder:
497
498
Section VII. Sample Forms
2.4
Recurrent Cost Summary Table – Not Applicable
2.5
Supply and Installation Cost Sub-Table №
System or Subsystem number: entire System procurement
Line item number:
[ as necessary for supply, installation, and achieving Operational Acceptance of the System, specify: the detailed components and
quantities in the Sub-Table below for the line item specified above, modifying the sample components and sample table entries as
needed. Repeat the Sub-Table as needed to cover each and every line item in the Supply and Installation Cost Summary Table that
requires elaboration. ]
Prices, rates, and subtotals MUST be quoted in accordance with ITB Clauses 14 and 15. Unit prices for the same item appearing
several times in the table must be identical in amount and currency.
Unit Prices / Rates
Supplied
Locally
Compo- Component Country Quannent
Description of Origin
tity
No.
Code
[ insert:
local
currency]
Supplied from outside the Purchaser’s
Country
[ insert:
local
currency]
[ insert:
[ insert
[ insert:
foreign
foreign
foreign
currency currency currency
A]
B]
C]
Subtotals (to [ insert: line item ] of Supply and Installation Cost Summary Table)
Note: - - indicates not applicable.
Total Prices
Supplied Supplied from outside the Purchaser’s Country
Locally
[ insert:
[ insert:
local
local
currency] currency]
[ insert:
foreign
currency
A]
[ insert:
foreign
currency
B]
[ insert:
foreign
currency
C]
Section VII. Sample Forms
499
Name of Bidder:
Authorized Signature of Bidder:
499
500
Section VII. Sample Forms
2.6
Recurrent Cost Sub-Table – Not Applicable
2.7
Country of Origin
Country
Code
Country of Origin Code Table
Country of Origin
Country Code
Country of Origin
Country
Code
Section VII. Sample Forms
501
3. OTHER BID FORMS AND LISTS
501
502
Section VII. Sample Forms
3.1
Manufacturer’s Authorization
Invitation for Bids Title and No.:
[If applicable:] Lot, Slice, Subsystem No(s).:
To: ________________________________
WHEREAS _______________________________________ who are official producers of
_______________________________________________ and having production facilities at
__________________________________________________________ do hereby authorize
__________________________________________________________________ located at
_____________________________________________________ (hereinafter, the “Bidder”)
to submit a bid and subsequently negotiate and sign a Contract with you for resale of the
following Products produced by us:
.
We hereby confirm that, in case the bidding results in a Contract between you and the
Bidder, the above-listed products will come with our full standard warranty.
Name
In the capacity of
Signed
Duly authorized to sign the authorization for and on behalf of : ________________________
Dated on _______________________________ day of ______________________, ______.
Note: This authorization should be written on the letterhead of the Manufacturer and be
signed by a person with the proper authority to sign documents that are binding on the
Manufacturer.
Section VII. Sample Forms
503
3.2
Item
List of Proposed Subcontractors
Proposed Subcontractor
Place of Registration &
Qualifications
503
504
Section VII. Sample Forms
3.3
Software List
(select one per item)
Software Item
System
Software
GeneralPurpose
Software
Application
Software
(select one per item)
Standard
Software
Custom
Software
Section VII. Sample Forms
505
3.4
List of Custom Materials
Custom Materials
505
506
Section VII. Sample Forms
3.5.1 General Information Form
All individual firms and each partner of a Joint Venture that are bidding must complete the
information in this form. Nationality information should be provided for all owners or
Bidders that are partnerships or individually owned firms.
Where the Bidder proposes to use named Subcontractors for highly specialized components
of the Information System, the following information should also be supplied for the
Subcontractor(s), together with the information in Forms 3.5.2, 3.5.3, 3.5.3a, 3.5.4, and 3.5.5.
Joint Ventures must also fill out Form 3.5.2a.
1.
Name of firm
2.
Head office address
3.
Telephone
Contact
4.
Fax
Telex
5.
Place of incorporation / registration
Year of incorporation / registration
Nationality of owners¹
Name
Nationality
1.
2.
3.
4.
5.
¹/
To be completed by all owners of partnerships or individually owned firms.
Section VII. Sample Forms
507
3.5.2 General Information Systems Experience Record
Name of Bidder or partner of a Joint Venture
All individual firms and all partners of a Joint Venture must complete the information in this
form with regard to the management of Information Systems contracts generally. The
information supplied should be the annual turnover of the Bidder (or each member of a Joint
Venture), in terms of the amounts billed to clients for each year for work in progress or
completed, converted to U.S. dollars at the rate of exchange at the end of the period reported.
The annual periods should be calendar years, with partial accounting for the year up to the
date of submission of applications. This form may be included for Subcontractors only if the
Bid Data Sheet for ITB Clause 6.1 (a) explicitly permits experience and resources of (certain)
Subcontractors to contribute to the Bidder’s qualifications.
A brief note on each contract should be appended, describing the nature of the Information
System, duration and amount of contract, managerial arrangements, purchaser, and other
relevant details.
Use a separate page for each partner of a Joint Venture, and number these pages.
Bidders should not enclose testimonials, certificates, and publicity material with their
applications; they will not be taken into account in the evaluation of qualifications.
Annual turnover data (applicable activities only)
Year¹
Turnover
US$ equivalent
1.
2.
3.
4.
5.
¹/
Commencing with the partial year up to the date of submission of bids
507
508
Section VII. Sample Forms
3.5.2a Joint Venture Summary
Names of all partners of a Joint Venture
1. Partner in charge
2. Partner
3. Partner
4. Partner
5. Partner
6. etc.
Total value of annual turnover, in terms of Information System billed to clients, in US$
equivalent, converted at the rate of exchange at the end of the period reported:
Annual turnover data (applicable activities only; US$ equivalent)
Partner
1. Partner
in charge
2. Partner
3. Partner
4. Partner
5. Partner
6. Etc.
Totals
Form
Year 1
3.5.2
page no.
Year 2
Year 3
Year 4
Year 5
Section VII. Sample Forms
509
3.5.3 Particular Information Systems Experience Record
Name of Bidder or partner of a Joint Venture
On separate pages, using the format of Form 3.5.3a, the Bidder is requested to list contracts
of a similar nature, complexity, and requiring similar information technology and
methodologies to the contract or contracts for which these Bidding Documents are issued,
and which the Bidder has undertaken during the period, and of the number, specified in the
BDS for ITB Clause 6.1 (a). Each partner of a Joint Venture should separately provide
details of its own relevant contracts. The contract value should be based on the payment
currencies of the contracts converted into U.S. dollars, at the date of substantial completion,
or for ongoing contracts at the time of award.
509
510
Section VII. Sample Forms
3.5.3a Details of Contracts of Similar Nature and Complexity
Name of Bidder or partner of a Joint Venture
Use a separate sheet for each contract.
1.
Number of contract
Name of contract
Country
2.
Name of Purchaser
3.
Purchaser address
4.
Nature of Information Systems and special features relevant to the contract for which the
Bidding Documents are issued
5.
Contract role (check one)
Prime Supplier

Management Contractor
 Subcontractor
 Partner in a
Joint Venture
6.
Amount of the total contract/subcontract/partner share (in specified currencies at completion,
or at date of award for current contracts)
Currency
7.
Currency
Currency
Subcontract: $_______;
Partner share: $_______;
Equivalent amount US$
Total contract: $_______;
8.
Date of award/completion
9.
Contract was completed _____ months ahead/behind original schedule (if behind, provide
explanation).
10.
Contract was completed US$ _________ equivalent under/over original contract amount (if
over, provide explanation).
11.
Special contractual/technical requirements.
12.
Indicate the approximate percent of total contract value (and US$ amount) of Information
System undertaken by subcontract, if any, and the nature of such Information System.
Section VII. Sample Forms
511
3.5.4 Summary Sheet: Current Contract Commitments / Work in
Progress
Name of Bidder or partner of a Joint Venture
Bidders and each partner to an Joint Venture bid should provide information on their current
commitments on all contracts that have been awarded, or for which a letter of intent or
acceptance has been received, or for contracts approaching completion, but for which an
unqualified, full completion certificate has yet to be issued.
Name of contract
Purchaser,
contact
address/tel./fax
Value of
outstanding
Information
System (current
US$ equivalent)
Estimated
completion date
Average monthly
invoicing over last
six months
(US$/month)
1.
2.
3.
4.
5.
etc.
511
512
Section VII. Sample Forms
3.5.5 Financial Capabilities
Name of Bidder or partner of a Joint Venture
Bidders, including each partner of a Joint Venture, shall provide financial information to
demonstrate that they meet the requirements stated in the BDS for ITB Clause 6.1 (a). Each
Bidder or partner of a Joint Venture shall complete this form. If necessary, separate sheets
shall be used to provide complete banker information. A copy of the audited balance sheets
shall be attached.
Autonomous subdivisions of parent conglomerate businesses shall submit financial
information related only to the particular activities of the subdivision.
Banker
Name of banker
Address of banker
Telephone
Contact name and title
Fax
Telex
Summarize actual assets and liabilities in U.S. dollar equivalent (at the rates of exchange
current at the end of each year) for the previous five calendar years. Based upon known
commitments, summarize projected assets and liabilities in U.S. dollar equivalent for the next
two calendar years, unless the withholding of such information by stock market listed public
companies can be substantiated by the Bidder.
Financial
information in
US$ equivalent
Actual:
Projected:
Previous five years
Next two years
5
1. Total assets
2. Current assets
3. Total
liabilities
4. Current
liabilities
5. Profits before
taxes
6. Profits after
taxes
4
3
2
1
1
2
Section VII. Sample Forms
513
Specify proposed sources of financing, such as liquid assets, unencumbered real assets, lines
of credit, and other financial means, net of current commitments, available to meet the total
construction cash flow demands of the subject contract or contracts as indicated in the BDS
for ITB Clause 6.1 (a).
Source of financing
Amount (US$ equivalent)
1.
2.
3.
4.
Attach audited financial statements—including, as a minimum, profit and loss account,
balance sheet, and explanatory notes—for the period stated in the BDS for ITB Clause 6.1 (a)
(for the individual Bidder or each partner of a Joint Venture).
If audits are not required by the laws of Bidders' countries of origin, partnerships and firms
owned by individuals may submit their balance sheets certified by a registered accountant,
and supported by copies of tax returns,
513
514
Section VII. Sample Forms
3.5.6 Personnel Capabilities
Name of Bidder
For specific positions essential to contract management and implementation (and/or those
specified in the Bidding Documents, if any), Bidders should provide the names of at least
two candidates qualified to meet the specified requirements stated for each position. The
data on their experience should be supplied on separate sheets using one Form 3.5.6a for
each candidate.
Bidders may propose alternative management and implementation arrangements requiring
different key personnel, whose experience records should be provided.
1.
Title of position
Name of prime candidate
Name of alternate candidate
2.
Title of position
Name of prime candidate
Name of alternate candidate
3.
Title of position
Name of prime candidate
Name of alternate candidate
4.
Title of position
Name of prime candidate
Name of alternate candidate
Section VII. Sample Forms
515
3.5.6a Candidate Summary
Name of Bidder
Position
Candidate

Candidate
information
Name of candidate
Prime

Alternate
Date of birth
Professional qualifications
Present
employment
Name of Employer
Address of Employer
Telephone
Contact (manager / personnel officer)
Fax
Telex
Job title of candidate
Years with present Employer
Summarize professional experience over the last twenty years, in reverse chronological
order. Indicate particular technical and managerial experience relevant to the project.
From
To
Company/Project/ Position/Relevant technical and management experience
515
516
Section VII. Sample Forms
3.5.7 Technical Capabilities
Name of Bidder
The Bidder shall provide adequate information to demonstrate clearly that it has the technical
capability to meet the requirements for the Information System. With this form, the Bidder
should summarize important certifications, proprietary methodologies, and/or specialized
technologies which the Bidder proposes to utilize in the execution of the Contract or
Contracts.
Section VII. Sample Forms
517
3.5.8 Litigation History
Name of Bidder or partner of a Joint Venture
Bidders, including each of the partners of a Joint Venture, shall provide information on any
history of litigation or arbitration resulting from contracts executed in the last five years or
currently under execution. A separate sheet should be used for each partner of a Joint
Venture.
Year
Award FOR Name of client, cause of litigation, and matter in Disputed
amount
or AGAINST dispute
(current value, US$
Bidder
equivalent)
517
518
Section VII. Sample Forms
4. BID-SECURING DECLARATION
Not Applicable
Section VII. Sample Forms
519
4A. Bid Security (Bank Guarantee)
[The Bank shall fill in this Bank Guarantee Form in accordance with the instructions
indicated.]
________________________________
[Bank’s Name, and Address of Issuing Branch or Office]
Beneficiary: ___________________ [Name and Address of Purchaser]
Date: ________________
BID GUARANTEE No.:
_________________
We have been informed that [name of the Bidder] (hereinafter called "the Bidder") has
submitted to you its bid dated (hereinafter called "the Bid") for the execution of [name of
contract] under Invitation for Bids No. [IFB number] (“the IFB”).
Furthermore, we understand that, according to your conditions, bids must be supported by a
bid guarantee.
At the request of the Bidder, we [name of Bank] hereby irrevocably undertake to pay you any
sum or sums not exceeding in total an amount of [amount in figures] ([amount in words])
upon receipt by us of your first demand in writing accompanied by a written statement
stating that the Bidder is in breach of its obligation(s) under the bid conditions, because the
Bidder:
(a)
has withdrawn its Bid during the period of bid validity specified by the Bidder in the
Form of Bid; or
(b)
having been notified of the acceptance of its Bid by the Purchaser during the period of
bid validity, (i) fails or refuses to execute the Contract Form; or (ii) fails or refuses to
furnish the performance security, if required, in accordance with the Instructions to
Bidders.
This guarantee will expire: (a) if the Bidder is the successful bidder, upon our receipt of
copies of the contract signed by the Bidder and the performance security issued to you upon
the instruction of the Bidder; or (b) if the Bidder is not the successful bidder, upon the earlier
of (i) our receipt of a copy of your notification to the Bidder of the name of the successful
bidder; or (ii) twenty-eight days after the expiration of the Bidder’s Bid.
Consequently, any demand for payment under this guarantee must be received by us at the
office on or before that date.
519
520
Section VII. Sample Forms
This guarantee is subject to the Uniform Rules for Demand Guarantees, ICC Publication No.
458.
_____________________________
[signature(s)]
4B. BID SECURITY (BID BOND)
Not Applicable
Section VII. Sample Forms
521
5. CONTRACT AGREEMENT
THIS CONTRACT AGREEMENT is made
the [ insert: ordinal ] day of [ insert: month ], [ insert: year ].
BETWEEN
(1)
[ insert: Name of Purchaser ], a [ insert: description of type of legal entity,
for example, an agency of the Ministry of . . . ] of the Government of
[ insert: country of Purchaser ], or corporation incorporated under the laws
of [ insert: country of Purchaser ] and having its principal place of business
at [ insert: address of Purchaser ] (hereinafter called “the Purchaser”), and
(2)
[ insert: name of Supplier], a corporation incorporated under the laws of
[ insert: country of Supplier] and having its principal place of business at
[ insert: address of Supplier ] (hereinafter called “the Supplier”).
WHEREAS the Purchaser desires to engage the Supplier to supply, install, achieve
Operational Acceptance of, and support the following Information System [ insert: brief
description of the Information System ] (“the System”), and the Supplier has agreed to such
engagement upon and subject to the terms and conditions appearing below in this Contract
Agreement.
NOW IT IS HEREBY AGREED as follows:
Article 1.
Contract
Documents
1.1
Contract Documents (Reference GCC Clause 1.1 (a) (ii))
The following documents shall constitute the Contract between
the Purchaser and the Supplier, and each shall be read and
construed as an integral part of the Contract:
(a)
This Contract Agreement and the Appendices attached to
the Contract Agreement
(b)
Special Conditions of Contract
(c)
General Conditions of Contract
(d)
Technical Requirements (including Implementation
Schedule)
(e)
The Supplier’s bid and original Price Schedules
(f)
[ Add here: any other documents ]
521
522
Section VII. Sample Forms
1.2
Order of Precedence (Reference GCC Clause 2)
In the event of any ambiguity or conflict between the Contract
Documents listed above, the order of precedence shall be the
order in which the Contract Documents are listed in Article 1.1
(Contract Documents) above, provided that Appendix 7 shall
prevail over all provisions of the Contract Agreement and the
other Appendices attached to the Contract Agreement and all the
other Contract Documents listed in Article 1.1 above.
1.3
Definitions (Reference GCC Clause 1)
Capitalized words and phrases used in this Contract Agreement
shall have the same meanings as are ascribed to them in the
General Conditions of Contract.
Article 2.
2.1
Contract Price
and Terms of
Payment
Contract Price (Reference GCC Clause 1.1(a)(viii) and GCC
Clause 11)
The Purchaser hereby agrees to pay to the Supplier the Contract
Price in consideration of the performance by the Supplier of its
obligations under the Contract. The Contract Price shall be the
aggregate of: [ insert: amount of foreign currency A in
words ], [insert: amount in figures ], plus [ insert: amount of
foreign currency B in words ], [insert: amount in figures ],
plus [ insert: amount of foreign currency C in words ], [insert:
amount in figures ], [ insert: amount of local currency in
words ], [ insert: amount in figures ], as specified in the Grand
Summary Price Schedule.
The Contract Price shall be understood to reflect the terms and
conditions used in the specification of prices in the detailed price
schedules, including the terms and conditions of the associated
Incoterms, and the taxes, duties and related levies if and as
identified.
Article 3.
Effective Date
for
Determining
Time for
Operational
Acceptance
3.1
Effective Date (Reference GCC Clause 1.1 (e) (ix))
The time allowed for supply, installation, and achieving
Operational Acceptance of the System shall be determined from
the date when all of the following conditions have been fulfilled:
(a)
This Contract Agreement has been duly executed for and
on behalf of the Purchaser and the Supplier;
(b)
The Supplier has submitted to the Purchaser the
performance security and the advance payment security, in
accordance with GCC Clause 13.2 and GCC Clause 13.3;
(c)
The Purchaser has paid the Supplier the advance payment,
in accordance with GCC Clause 12;
Section VII. Sample Forms
523
(d)
[ specify here: any other conditions, for example,
opening/confirmation of letter of credit ].
Each party shall use its best efforts to fulfill the above conditions
for which it is responsible as soon as practicable.
Article 4.
3.2
If the conditions listed under 3.1 are not fulfilled within two (2)
months from the date of this Contract Agreement because of
reasons not attributable to the Supplier, the parties shall discuss
and agree on an equitable adjustment to the Contract Price and
the Time for Achieving Operational Acceptance and/or other
relevant conditions of the Contract.
4.1
The Appendixes listed below shall be deemed to form an
integral part of this Contract Agreement.
4.2
Reference in the Contract to any Appendix shall mean the
Appendixes listed below and attached to this Contract
Agreement, and the Contract shall be read and construed
accordingly.
Appendixes
APPENDIXES
Appendix 1.
Appendix 2.
Appendix 3.
Appendix 4.
Appendix 5.
Appendix 6.
Appendix 7.
Supplier’s Representative
Adjudicator [if there is no Adjudicator, state “not applicable”]
List of Approved Subcontractors
Categories of Software
Custom Materials
Revised Price Schedules (if any)
Minutes of Contract Finalization Discussions and Agreed-to Contract
Amendments
523
524
Section VII. Sample Forms
IN WITNESS WHEREOF the Purchaser and the Supplier have caused this Agreement to be
duly executed by their duly authorized representatives the day and year first above written.
For and on behalf of the Purchaser
Signed:
in the capacity of [ insert: title or other appropriate designation ]
in the presence of
For and on behalf of the Supplier
Signed:
in the capacity of [ insert: title or other appropriate designation ]
in the presence of
CONTRACT AGREEMENT
dated the [ insert: number ] day of [ insert: month ], [ insert: year ]
BETWEEN
[ insert: name of Purchaser ], “the Purchaser”
and
[ insert: name of Supplier ], “the Supplier”
Section VII. Sample Forms
525
Appendix 1. Supplier’s Representative
In accordance with GCC Clause 1.1 (b) (iv), the Supplier’s Representative is:
Name:
[ insert: name and provide title and address further below, or state “to be
nominated within fourteen (14) days of the Effective Date” ]
Title:
[ if appropriate, insert: title ]
In accordance with GCC Clause 4.3, the Supplier's addresses for notices under the Contract
are:
Address of the Supplier's Representative: [ as appropriate, insert: personal delivery,
postal, cable, telegraph, telex, facsimile, electronic mail, and/or EDI addresses. ]
Fallback address of the Supplier: [ as appropriate, insert: personal delivery, postal,
cable, telegraph, telex, facsimile, electronic mail, and/or EDI addresses. ]
525
526
Section VII. Sample Forms
Appendix 2. Adjudicator
In accordance with GCC Clause 1.1 (b) (vi), the agreed-upon Adjudicator is:
Name: [ insert: name ]
Title: [ insert: title ]
Address: [ insert: postal address ]
Telephone: [ insert: telephone ]
In accordance with GCC Clause 6.1.3, the agreed-upon fees and reimbursable expenses are:
Hourly Fees: [ insert: hourly fees ]
Reimbursable Expenses: [ list: reimbursables ]
Pursuant to GCC Clause 6.1.4, if at the time of Contract signing, agreement has not been
reached between the Purchaser and the Supplier, an Adjudicator will be appointed by the
Appointing Authority named in the SCC.
Section VII. Sample Forms
527
Appendix 3. List of Approved Subcontractors
The Purchaser has approved use of the following Subcontractors nominated by the Supplier
for carrying out the item or component of the System indicated. Where more than one
Subcontractor is listed, the Supplier is free to choose between them, but it must notify the
Purchaser of its choice sufficiently in advance of the time when the subcontracted work
needs to commence to give the Purchaser reasonable time for review. In accordance with
GCC Clause 20.1, the Supplier is free to submit proposals for Subcontractors for additional
items from time to time. No subcontracts shall be placed with any such Subcontractors for
additional items until the Subcontractors have been approved in writing by the Purchaser and
their names have been added to this list of Approved Subcontractors, subject to GCC
Clause 20.3.
[ specify: item, approved Subcontractors, and their place of registration that the Supplier
proposed in the corresponding attachment to its bid and that the Purchaser approves that
the Supplier engage during the performance of the Contract. Add additional pages as
necessary. ]
Item
Approved Subcontractors
Place of Registration
527
528
Section VII. Sample Forms
Appendix 4. Categories of Software
The following table assigns each item of Software supplied and installed under the Contract
to one of the three categories: (i) System Software, (ii) General-Purpose Software, or
(iii) Application Software; and to one of the two categories: (i) Standard Software or
(ii) Custom Software.
(select one per item)
Software Item
System
Software
GeneralPurpose
Software
Application
Software
(select one per item)
Standard
Software
Custom
Software
Section VII. Sample Forms
529
Appendix 5. Custom Materials
The follow table specifies the Custom Materials the Supplier will provide under the Contract.
Custom Materials
529
530
Section VII. Sample Forms
Appendix 6. Revised Price Schedules
The attached Revised Price Schedules (if any) shall form part of this Contract Agreement
and, where differences exist, shall supersede the Price Schedules contained in the Supplier’s
Bid. These Revised Price Schedules reflect any corrections or adjustments to the Supplier’s
bid price, pursuant to the ITB Clauses 18.3, 26.2, and 33.1 (ITB Clauses 30.3, 38.2, and 45.1
in the two-stage SBD).
Section VII. Sample Forms
531
Appendix 7. Minutes of Contract Finalization Discussions and Agreed-to
Contract Amendments
The attached Contract amendments (if any) shall form part of this Contract Agreement and,
where differences exist, shall supersede the relevant clauses in the GCC, SCC, Technical
Requirements, or other parts of this Contract as defined in GCC Clause 1.1 (a) (ii).
531
532
Section VII. Sample Forms
6. PERFORMANCE AND ADVANCE PAYMENT SECURITY FORMS
Section VII. Sample Forms
533
6.1 Performance Security
[The bank, as requested by the successful Bidder, shall fill in this form in accordance with the instructions
indicated]
Date: [insert date (as day, month, and year) of Bid Submission]
ICB No. and title: [insert no. and title of bidding process]
Bank’s Branch or Office: [insert complete name of Guarantor]
Beneficiary: [insert complete name of Purchaser]
PERFORMANCE GUARANTEE No.:
[insert Performance Guarantee number]
We have been informed that [insert complete name of Supplier] (hereinafter called "the
Supplier") has entered into Contract No. [insert number] dated [insert day and month],
[insert year] with you, for the supply of [description of Goods and related Services]
(hereinafter called "the Contract").
Furthermore, we understand that, according to the conditions of the Contract, a Performance
Guarantee is required.
At the request of the Supplier, we hereby irrevocably undertake to pay you any sum(s) not
exceeding [insert amount(s1) in figures and words] upon receipt by us of your first demand
in writing declaring the Supplier to be in default under the Contract, without cavil or
argument, or your needing to prove or to show grounds or reasons for your demand or the
sum specified therein.
This Guarantee shall expire no later than the [insert number] day of [insert month] [insert
year],2 and any demand for payment under it must be received by us at this office on or
before that date.
1
The Bank shall insert the amount(s) specified in the SCC and denominated, as specified in the
SCC, either in the currency(ies) of the Contract or a freely convertible currency acceptable to the
Purchaser.
2
Dates established in accordance with Clause 18.4 of the General Conditions of Contract (“GCC”),
taking into account any warranty obligations of the Supplier under Clause 16.2 of the GCC
intended to be secured by a partial Performance Guarantee. The Purchaser should note that in
the event of an extension of the time to perform the Contract, the Purchaser would need to
request an extension of this Guarantee from the Bank. Such request must be in writing and must
be made prior to the expiration date established in the Guarantee. In preparing this Guarantee,
the Purchaser might consider adding the following text to the Form, at the end of the penultimate
533
534
Section VII. Sample Forms
This guarantee is subject to the Uniform Rules for Demand Guarantees, ICC Publication No.
458, except that subparagraph (ii) of Sub-article 20(a) is hereby excluded.
[signatures of authorized representatives of the bank and the Supplier]
paragraph: “We agree to a one-time extension of this Guarantee for a period not to exceed [six
months] [one year], in response to the Purchaser’s written request for such extension, such
request to be presented to us before the expiry of the Guarantee.”
Section VII. Sample Forms
535
6.2 Bank Guarantee for Advance Payment
[The bank, as requested by the successful Bidder, shall fill in this form in accordance with
the instructions indicated.]
Date: [insert date (as day, month, and year) of Bid Submission]
ICB No. and title: [insert number and title of bidding process]
[bank’s letterhead]
Beneficiary: [insert legal name and address of Purchaser]
ADVANCE PAYMENT GUARANTEE No.: [insert Advance Payment Guarantee no.]
We, [insert legal name and address of bank], have been informed that [insert complete name
and address of Supplier] (hereinafter called "the Supplier") has entered into Contract No.
[insert number] dated [insert date of Agreement] with you, for the supply of [insert types of
Goods to be delivered] (hereinafter called "the Contract").
Furthermore, we understand that, according to the conditions of the Contract, an advance is
to be made against an advance payment guarantee.
At the request of the Supplier, we hereby irrevocably undertake to pay you any sum or sums
not exceeding in total an amount of [insert amount(s)1 in figures and words] upon receipt by
us of your first demand in writing declaring that the Supplier is in breach of its obligation
under the Contract because the Supplier used the advance payment for purposes other than
toward delivery of the Goods.
It is a condition for any claim and payment under this Guarantee to be made that the advance
payment referred to above must have been received by the Supplier on its account [insert
number and domicile of the account]
This Guarantee shall remain valid and in full effect from the date of the advance payment
received by the Supplier under the Contract until [insert date2].
1
The bank shall insert the amount(s) specified in the SCC and denominated, as specified in the
SCC, either in the currency(ies) of the Contract or a freely convertible currency acceptable to the
Purchaser.
2
Insert the Delivery date stipulated in the Contract Delivery Schedule. The Purchaser should note
that in the event of an extension of the time to perform the Contract, the Purchaser would need to
request an extension of this Guarantee from the bank. Such request must be in writing and must
be made prior to the expiration date established in the Guarantee. In preparing this Guarantee,
the Purchaser might consider adding the following text to the Form, at the end of the penultimate
535
536
Section VII. Sample Forms
This Guarantee is subject to the Uniform Rules for Demand Guarantees, ICC Publication No.
458.
_____________________
[signature(s) of authorized representative(s) of the bank]
paragraph: “We agree to a one-time extension of this Guarantee for a period not to exceed [six
months][one year], in response to the Purchaser’s written request for such extension, such
request to be presented to us before the expiry of the Guarantee.”
Section VII. Sample Forms
537
7. INSTALLATION AND ACCEPTANCE CERTIFICATES
537
538
Section VII. Sample Forms
7.1
Installation Certificate
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name and number of Contract ]
To: [ insert: name and address of Supplier ]
Dear Sir or Madam:
Pursuant to GCC Clause 26 (Installation of the System) of the Contract entered into
between yourselves and the [ insert: name of Purchaser ] (hereinafter the “Purchaser”)
dated [ insert: date of Contract ], relating to the [ insert: brief description of the
Information System ], we hereby notify you that the System (or a Subsystem or major
component thereof) was deemed to have been correctly installed on the date specified below.
1.
Description of the System (or relevant Subsystem or major component: [ insert:
description ]
2.
Date of Installation: [ insert: date ]
Notwithstanding the above, you are required to complete the outstanding items listed
in the attachment to this certificate as soon as practicable. This letter shall not relieve you of
your obligation to achieve Operational Acceptance of the System in accordance with the
Contract nor of your obligations during the Warranty Period.
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state: “Project Manager” or state the title of a higher level authority
in the Purchaser’s organization ]
Section VII. Sample Forms
7.2
539
Operational Acceptance Certificate
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name and address of Supplier ]
Dear Sir or Madam:
Pursuant to GCC Clause 27 (Commissioning and Operational Acceptance) of the
Contract entered into between yourselves and the [ insert: name of Purchaser ] (hereinafter
the “Purchaser”) dated [ insert: date of Contract ], relating to the [ insert: brief description
of the Information System ], we hereby notify you the System (or the Subsystem or major
component identified below) successfully completed the Operational Acceptance Tests
specified in the Contract. In accordance with the terms of the Contract, the Purchaser hereby
takes over the System (or the Subsystem or major component identified below), together with
the responsibility for care and custody and the risk of loss thereof on the date mentioned
below.
1.
Description of the System (or Subsystem or major component):
description ]
2.
[ insert:
Date of Operational Acceptance: [ insert: date ]
This letter shall not relieve you of your remaining performance obligations under the
Contract nor of your obligations during the Warranty Period.
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the Purchaser’s
organization ]
539
540
Section VII. Sample Forms
8. CHANGE ORDER PROCEDURES AND FORMS
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name or System or Subsystem and
number of Contract ]
General
This section provides samples of procedures and forms for carrying out changes to the
System during the performance of the Contract in accordance with GCC Clause 39
(Changes to the System) of the Contract.
Change Order Log
The Supplier shall keep an up-to-date Change Order Log to show the current status of
Requests for Change and Change Orders authorized or pending. Changes shall be
entered regularly in the Change Order Log to ensure that the log is kept up-to-date. The
Supplier shall attach a copy of the current Change Order Log in the monthly progress
report to be submitted to the Purchaser.
References to Changes
(1)
(2)
(3)
(4)
(5)
Request for Change Proposals (including Application for Change Proposals) shall
be serially numbered CR-nnn.
Change Estimate Proposals shall be numbered CN-nnn.
Estimate Acceptances shall be numbered CA-nnn.
Change Proposals shall be numbered CP-nnn.
Change Orders shall be numbered CO-nnn.
On all forms, the numbering shall be determined by the original CR-nnn.
Annexes
8.1
8.2
8.3
8.4
8.5
8.6
Request for Change Proposal Form
Change Estimate Proposal Form
Estimate Acceptance Form
Change Proposal Form
Change Order Form
Application for Change Proposal Form
Section VII. Sample Forms
8.1
541
Request for Change Proposal Form
(Purchaser’s Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem or number
of Contract ]
To: [ insert: name of Supplier and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
With reference to the above-referenced Contract, you are requested to prepare and
submit a Change Proposal for the Change noted below in accordance with the following
instructions within [ insert: number ] days of the date of this letter.
1.
Title of Change: [ insert: title ]
2.
Request for Change No./Rev.: [ insert: number ]
3.
Originator of Change: [ select Purchaser / Supplier (by Application for Change
Proposal), and add: name of originator ]
4.
Brief Description of Change: [ insert: description ]
5.
System (or Subsystem or major component affected by requested Change): [ insert:
description ]
6.
Technical documents and/or drawings for the request of Change:
541
542
Section VII. Sample Forms
Document or Drawing No.
Description
7.
Detailed conditions or special requirements of the requested Change:
description ]
8.
Procedures to be followed:
9.
[ insert:
(a)
Your Change Proposal will have to show what effect the requested Change will
have on the Contract Price.
(b)
Your Change Proposal shall explain the time it will take to complete the requested
Change and the impact, if any, it will have on the date when Operational
Acceptance of the entire System agreed in the Contract.
(c)
If you believe implementation of the requested Change will have a negative
impact on the quality, operability, or integrity of the System, please provide a
detailed explanation, including other approaches that might achieve the same
impact as the requested Change.
(d)
You should also indicate what impact the Change will have on the number and
mix of staff needed by the Supplier to perform the Contract.
(e)
You shall not proceed with the execution of work related to the requested Change
until we have accepted and confirmed the impact it will have on the Contract
Price and the Implementation Schedule in writing.
As next step, please respond using the Change Estimate Proposal form, indicating how
much it will cost you to prepare a concrete Change Proposal that will describe the
proposed approach for implementing the Change, all its elements, and will also address
the points in paragraph 8 above pursuant to GCC Clause 39.2.1. Your Change Estimate
Proposal should contain a first approximation of the proposed approach, and
implications for schedule and cost, of the Change.
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the Purchaser’s
organization ]
Section VII. Sample Forms
8.2
543
Change Estimate Proposal Form
(Supplier’s Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name of Purchaser and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
With reference to your Request for Change Proposal, we are pleased to notify you of
the approximate cost of preparing the below-referenced Change in accordance with GCC
Clause 39.2.1 of the Contract. We acknowledge that your agreement to the cost of preparing
the Change Proposal, in accordance with GCC Clause 39.2.2, is required before we proceed
to prepare the actual Change Proposal including a detailed estimate of the cost of
implementing the Change itself.
1.
Title of Change: [ insert: title ]
2.
Request for Change No./Rev.: [ insert: number ]
3.
Brief Description of Change (including proposed implementation approach): [ insert:
description ]
4.
Schedule Impact of Change (initial estimate): [ insert: description ]
5.
Initial Cost Estimate for Implementing the Change: [insert: initial cost estimate]
543
544
6.
Section VII. Sample Forms
Cost for Preparation of Change Proposal: [ insert: cost in the currencies of the
Contract ], as detailed below in the breakdown of prices, rates, and quantities.
For and on behalf of the Supplier
Signed:
Date:
in the capacity of: [ state: “Supplier’s Representative” or other higher level authority in
the Supplier’s organization ]
Section VII. Sample Forms
545
8.3
Estimate Acceptance Form
(Purchaser’s Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name of Supplier and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
We hereby accept your Change Estimate and agree that you should proceed with the
preparation of a formal Change Proposal.
1.
Title of Change: [ insert: title ]
2.
Request for Change No./Rev.: [ insert: request number / revision ]
3.
Change Estimate Proposal No./Rev.: [ insert: proposal number / revision ]
4.
Estimate Acceptance No./Rev.: [ insert: estimate number / revision ]
5.
Brief Description of Change: [ insert: description ]
6.
Other Terms and Conditions:
In the event that we decide not to order the Change referenced above, you shall be
entitled to compensation for the cost of preparing the Change Proposal up to the
545
546
Section VII. Sample Forms
amount estimated for this purpose in the Change Estimate Proposal, in accordance with
GCC Clause 39 of the General Conditions of Contract.
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the Purchaser’s
organization ]
Section VII. Sample Forms
547
8.4
Change Proposal Form
(Supplier’s Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name of Purchaser and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
In response to your Request for Change Proposal No. [ insert: number ], we hereby
submit our proposal as follows:
1.
Title of Change: [ insert: name ]
2.
Change Proposal No./Rev.: [ insert: proposal number/revision ]
3.
Originator of Change: [ select: Purchaser / Supplier; and add: name]
4.
Brief Description of Change: [ insert: description ]
5.
Reasons for Change: [ insert: reason ]
6.
The System Subsystem, major component, or equipment that will be affected by the
requested Change: [ insert: description ]
7.
Technical documents and/or drawings for the requested Change:
547
548
Section VII. Sample Forms
Document or Drawing No.
8.
Description
Estimate of the increase/decrease to the Contract Price resulting from the proposed
Change: [ insert: amount in currencies of Contract ], as detailed below in the
breakdown of prices, rates, and quantities.
Total lump sum cost of the Change:
Cost to prepare this Change Proposal (i.e., the amount payable if the Change is not
accepted, limited as provided by GCC Clause 39.2.6):
9.
Additional Time for Achieving Operational Acceptance required due to the Change:
[ insert: amount in days / weeks ]
10.
Effect on the Functional Guarantees: [ insert: description ]
11.
Effect on the other terms and conditions of the Contract: [ insert: description ]
12.
Validity of this Proposal: for a period of [ insert: number ] days after receipt of this
Proposal by the Purchaser
13.
Procedures to be followed:
(a)
You are requested to notify us of your acceptance, comments, or rejection of this
detailed Change Proposal within [ insert: number ] days from your receipt of this
Proposal.
(b)
The amount of any increase and/or decrease shall be taken into account in the
adjustment of the Contract Price.
For and on behalf of the Supplier
Signed:
Date:
in the capacity of: [ state: “Supplier’s Representative” or other higher level authority in
the Supplier’s organization ]
Section VII. Sample Forms
549
8.5
Change Order Form
(Purchaser’s Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name of Supplier and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
We hereby approve the Change Order for the work specified in Change Proposal No.
[ insert: number ], and agree to adjust the Contract Price, Time for Completion, and/or other
conditions of the Contract in accordance with GCC Clause 39 of the Contract.
1.
Title of Change: [ insert: name ]
2.
Request for Change No./Rev.: [ insert: request number / revision ]
3.
Change Order No./Rev.: [ insert: order number / revision ]
4.
Originator of Change: [ select: Purchaser / Supplier; and add: name ]
5.
Authorized Price for the Change:
Ref. No.: [ insert: number ]
Date: [ insert: date ]
549
550
Section VII. Sample Forms
[ insert: amount in foreign currency A ] plus [ insert: amount in foreign currency
B ] plus [ insert: amount in foreign currency C ] plus [ insert: amount in local
currency ]
6.
Adjustment of Time for Achieving Operational Acceptance: [ insert: amount and
description of adjustment ]
7.
Other effects, if any: [ state: “none” or insert description ]
For and on behalf of the Purchaser
Signed:
Date:
in the capacity of: [ state: “Project Manager” or higher level authority in the Purchaser’s
organization ]
For and on behalf of the Supplier
Signed:
Date:
in the capacity of: [ state “Supplier’s Representative” or higher level authority in the
Supplier’s organization ]
Section VII. Sample Forms
8.6
551
Application for Change Proposal Form
(Supplier’s Letterhead)
Date: [ insert: date ]
Loan/Credit Number: [ insert: loan or credit number from IFB ]
IFB: [ insert: title and number of IFB ]
Contract: [ insert: name of System or Subsystem and
number of Contract ]
To: [ insert: name of Purchaser and address ]
Attention: [ insert: name and title ]
Dear Sir or Madam:
We hereby propose that the below-mentioned work be treated as a Change to the
System.
1.
Title of Change: [ insert: name ]
2.
Application for Change Proposal No./Rev.:
[ insert: date ]
3.
Brief Description of Change: [ insert: description ]
4.
Reasons for Change: [ insert: description ]
5.
Order of Magnitude Estimation: [ insert: amount in currencies of the Contract ]
6.
Schedule Impact of Change: [ insert: description ]
7.
Effect on Functional Guarantees, if any: [ insert: description ]
[ insert:
number / revision] dated:
551
552
8.
Section VII. Sample Forms
Appendix: [ insert: titles (if any); otherwise state “none” ]
For and on behalf of the Supplier
Signed:
Date:
in the capacity of: [ state: “Supplier’s Representative” or higher level authority in the
Supplier’s organization ]