Number
Answers to questions under contract # KHSTTIRP-D / SW-06
«Delivery of Blood service information system». Series 1.
Qquestion
Purchaser's clarification
1. Section 1.1.6
R1.28 – At present the most popular languages are: Java,
С\С++, Python, NET, Ruby and others. Mandatory
requirement for provision of SDK with support of these
development tools severely limit possible architectures
and system implementation languages. In some cases, an
indication of mutually exclusive technologies Java and
.NET as a requirement of their simultaneous presence,
and not as one of alternative options, might assume that
the technical solution is where during the application
system development business logic and data access were
deliberately simplified to ensure interoperability
between .NET and Java. It is preferable, in this case to
indicate the number of languages, combining it with the
requirement to support at least 2 of the required to
provide an option to the Client and not to limit the
system implementation languages by the Supplier.
2. Section 2.6.
R7.2 - the phrase " Interaction between central and local
components of the System shall be carried out on
secured channels using HTTPS protocol» limits possible
architecture of the system implementation. In case of
using interaction with the client components, such
requirement would be feasible Simple requirement of
channel encryption according to SSL or TLS, is also
appropriate and adequate. However, the application of
HTTPS for intersystem communication channel, while
there are many other mechanisms -. JMS, AMQP, ECP,
Oracle AQ, MSMQ, etc.., severely limit the options,
quality and reliability of the exchange mechanism
Addition / clarification
The technical specification requires the presence of SDK for
integrating development tools using common development
languages Java and NetFramework, that does not limit the
use of other development languages. There are no other
mandatory requirements for SDK and development
languages in the technical specification.
« The system components in which in accordance with their
functionality it is provided to develop program code shall
have capabilities of integration with development
environments at least for Java and Net Framework. The
system shall have SDK in a kit, including: documents,
examples of code at least for Java and Net Framework»
Clarification
In accordance with the requirements for information
exchange (R2.5), system must meet the profiles IHE (
R2.5.3), to ensure interoperability / integration using the
protocols and specifications in accordance with the
requirements of R2.5.4 and have a service-oriented
architecture (SOA), in accordance with the requirements of
R1.5. According to these requirements the use of the
HTTPS protocol is the agreed requirements and it does not
impose restrictions on the use of other mechanisms in the
implementation of systems such as: JMS, MSMQ, and
others.
Clarification
implementation.
3. Section 2.9.
R10.1.5.7 - a mandatory requirement to the DMBS
limits the choice of possible database options, on which
the system can be built. The requirement for highperformance during processing of XML documents is
relevant to the target system, but not to the underlying
nuances of its implementation.
4. Section 2.9.2
R10.3.5 - indicates a specific implementation of
services, which are not conditioned by a requirement of
the subject area. Acceptable option of wording "services
developed by the supplier must provide the following
functions..", while specific implementation of the
mechanism of services is the supplier’s responsibility,
without degrading the performance of the system. For
example, an alternative implementation may imply
combination of "service for registration and obtaining
information about blood donors and donations" and
"Service for management of blood donor status" as a
single service. In this case, the services are already
separated and imply only a unique implementation
structure.
The same applies to the requirements R10.4.14, R10.5.7,
R10.6.5, R10.7.4, it is desirable to specify the required
service functions, but not the architectural
implementation of these services.
XML support is necessary for the storage and processing of
medical documents in the CDA R2 format (ISO / HL7
27932: 2009). Currently, XML support is available in a
variety of databases such as: Oracle, MS SQL, PostgreSQL
and others.This requirement (R10.1.5.7) is not excessive or
restrictive.
«R10.1.5.7 The DBMS shall be high performance and
effective on the part of processing and saving XML
documents or other similar formats for storage of connected
hierarchy data (CDA R2 format). The DBMS shall ensure
capability of indexing and searching the connected
hierarchy data on XML fields of document or another
similar format»
In the technical specification the functions of services are
separated logically, the bidder may offer a solution with
another division of the service functions. A mandatory
requirement is availability of all service functions specified
in the bidding documents.
Clarification
Clarification
5. Section 2.10
In accordance with R11.1.29.1, the requirement for the Clarification
R11.1.29.1 - unreasonable requirement for having number of concurrent users has been established. This
exactly 100 concurrent users, no estimates in accordance requirement is not applied to the local component
DBMS licensing on the part of using competitive
with the automation facilities provided.
licenses. Requirements for DBMS licensing is given in
R11.1.29.12 - R11.1.29.14.
6. Section 2.10
The requirement to support the version of Internet Explorer Addition
R 11.2.7 in most implementation options is contrary to has been changed.
the restriction in the requirement to support HTML5 and
Internet Explorer 9 as the appropriate API for that
browser has not been implemented, and therefore the
requirement R9.2 is incorrect since it means additional
components and not just a HTML5 standard.
7. Section 3
The comment is taken into consideration.
Addition
R12.5 - an indication of English as a compulsory to The wording of R12.5 has been changed to the following:
provide guidance for all components of the system is the " Supplier shall prepare corresponding guidelines for all
limiting factor. Given the fact that this language is not a system components in English, Kazakh, Russian languages
according to requirements R20, R21.»
state and none of the users categories uses this as their
Paragraph R20.2 changed to the following:
primary language, this requirement seems excessive for " Supplier shall prepare corresponding guidelines for all
the intended system operation and especially in the case system components in Kazakh, Russian languages
where the supplier does not use the system, originally according to requirements R20, R21. "
designed for English-speaking users.
8. Sections 3 and 5
Items R12.15, R12.16 and R12.17 are dropped from Addition
Requirements R12.15, R12.16, R12.17 - imply the the bidding documents.
presence of the Supplier's prototype at the time of
bidding publication that includes all basic modules and
system components closely similar to the TS system.
Given the uniqueness of the project and difference of its
requirements from the regional standard automated blood
service architectural features and requirements specified in
the TOR, a list of system modules, data attributes used, list of
documents and reporting forms (even without taking into
account the visual requirements for reporting forms) allow us
to conclude the possibility of availability of the development
at the time of bidding based on the technical specifications or
closely similar to it. If the above requirements can be
matched, and R12.6, it can be assumed that under the
contract a greater system adjustment has occurred, and
not its subject area or technological part and,
consequently, it increases the possibility of the
development existence, which was created in parallel
with the writing of technical specifications and may
have preference with respect to other developments. The
most controversial point is the need for "a demonstration
of required functional capabilities on the basis of the
developed prototype" in the R12.15, which may
contradict with paragraph "e" of the requirement R15.1,
namely "the development (or deployment of the
existing)," which excludes the development and
presumes the "deployment of the existing" modules and
services.